設計してますか？
ぶっちゃけ「設計 is 何」ってよくわからないんだけど、設計はしてます。 で、その設計なんだけど、今の何かを満たすものだけでなく未来に備える系があるなと思った。 私の中では「決定の遅延」と「添木」と呼んでるものです。
決定の遅延
決定を遅延させるために行う設計があります。
現実はいろんなことが起こり、未来がどうなるかはわかりません。 少し待てば情報が増えることがわかっていることはあります。でもどのような情報が来るかは分かりません。
「すべての情報が揃ってから動けばいい」という選択もあり、これはこれで一理あります。 ですがそのようにしていると期限に間に合わないこともしばしばあります。 時間は融通が効かないので、他で融通を効かせる必要があります。
そういう時に「決定を遅延させる設計」を使うことがあります。 決まっている部分を進めて、決まっていない部分を後回しにするという当たり前のような手段ですが、往々にして決まっていることと決まっていないことはないまぜになっています。
そういう時にいろんな整理をします。
- 決まっていることと決まっていないことを分ける
- 決まっていない度合いで濃淡をつける
- 決まる時に取られうる選択肢を限定する
- ...
かたい部分はハードパーツって呼んだりするもののこともある。
（直接ここで書いているものとイコールではないが。）
あの手この手で決め難いところを柔らかく包み込んで、決定を遅らせることが可能なようにする。 単なる先送りではなく、重要な部分を決めるための時間を稼ぎ、決まった時に憂いなく取り組めるようにする準備を整える。 そんな感じ。
添木
プロジェクトの期間中に決定が訪れるものであり、それが待つ価値のあるものであれば、可能な限り遅延させられるようにして進めます。 それはそれとして決定が訪れないものもそれなりにあります。
「将来こうなるかもしれない」と考えるのは重要ではあるものの、なっていないことを前提に作るのはYAGNIと言われるアンチパターンです。（作るコストがAIで劇的に下がってるので「作っちゃえばいいじゃん」って話もありはしますが、本稿の趣旨ではないのでそれはそれとしてください。） でも考えるのはいいことなんです。 前提にした対応はしない、でも方向づけはする。 そういう設計を「添木」と呼んでいます。
具体例はうまく伝わるかわかんないのですが、構造や名前は添木の側面を持ちます。
たとえばパッケージ構造はクラスの増え方を方向づけします。 新規プロダクトで序盤に用意したどこからか借りてきたパッケージ構造が邪魔くさく感じたことはないでしょうか。 それはおそらく借りてくる元のコンテキストでは「その方向に進んでほしくない」というものです。意図的であれ結果的であれ。 そのコンテキストを踏襲するなら「邪魔くさい」と感じたのは何かしらアーキテクチャのルールに違反しているからでしょう。
たとえば名前は他の名前に影響を与えます。 「添木」という言葉があれば「鉢」とか「枝」とかが連想されるものです。 システム開発での名前選びは、今後の他の名前に何かしらの制約を与えます。具体例？触ったことあるシステムのクラス名とかを思い返して、新しいクラスを追加しようとしたらそれに引っ張られますよね。それです。
「添木」は存在を認識されないなど、伝わらないこともしばしばです。 実際の植物でも添木を無視して成長してることもままあるものですし、まぁ仕方ない。 「そうはならんやろ」と思うような方向に成長することも稀によくある。
添木で物足りないなら周りをしっかり囲いましょう。 ニュアンスや文化で伝えるのではなく、規約やルールでしっかり固めましょう。 どちらがいいかなーというのもまちまちだと思うんだけど、AIを前提にすると添木は主張が弱すぎて役に立たない気もしなくはない。
ルールや規約の話を出してしまったので「添木」がその系に読み取れなくもない気はするけど、あくまで「成長に方向性を与える」という設計パターンです。 「"今は決めない"と決めたもの」でも「成長するならこっち方向かなー」という意図を込める。そんな設計ってのもあるよなぁと。伝わるかなー。
補足: 仮止め
私の中で「仮止め」と呼んでいる設計パターンもあるので触れておく。
「仮止め」は家具を組み立てる時とかにネジを軽く締めておく、キツく締める前にやっておくあれです。 永続的ではなく一時的にその状態で固定して全体のバランスを調整したり、場合によってはやめたりするのだけど、とにかくそこを固定しないと他のことを考えようにも空中分解してしまうようなことはそれなりにあります。 「一旦これで決めて次に進めよう」という感じで決定はしているので、「決定の遅延」とは区別しています。
なおADRなどの軽量ドキュメントによる「取り消し可能な決定」も「仮止め」に近いけれど、そのままにする可能性があるのが「取り消し可能な決定」です。「仮止め」はその場所で固定するにしても「ちゃんと締める」は必須になる点が違ったりする。
しめ
どんな設計でも動けばいい。それはそう。動くのはいいこと。動かないのは話にならない。 とは言えコンピューターの発達に伴い、「動く」を満たした上で取れる選択肢も非常に広くなっている。 「こういう作りをしないとそもそも動くと言えない」のような制約は縮小し、超富豪的プログラミングも十分成立してしまう今日この頃。 そんな制約が少ない中での設計の考え方ってのもあるわけで。
決められるなら決めてしまえばいいことも多いのだけど、決めない方がいいこともそれなりにありはします。 そういう時に「決定を遅延」させられるようにし、さらに決めないまま方向性を主張する「添木」を配置する。 そんな感じの考え方をすることがなくはないなぁ、という話でした。
