設計についてあれこれ考えたこと
About
本記事は、設計についてここ一年で考えたことの備忘録です。ADR、問題空間、ペースレイヤリング、Wardlley Mapsなどの話題を扱っています。
1. 意思決定行為は記録できるか？
Whyをどこまで/どうやってドキュメントするのか問題
「実装されたコードは意思決定の結論(What)は語るが、意志決定のコンテキストや結論を支持する論理(Why)は語らない」的な話をソフトウェア開発の文脈でしばしば耳にします。
そのような情報を永続化するためには、コメントあるいはソフトウェア外のドキュメントという形で自然言語で情報を残す必要がありますが、特に後者の方法、つまりドキュメントを作るに際しては「どれくらいのボリュームのものを作る？」「更新し続けることは可能？」などの話について意見が分かれることが多かった印象です。*1
Arthitecture Decision Record (ADR)
Arthitecture Decision Record (ADR) *2 が普及するにつれて、「設計意図を残すドキュメントのレベル感としてはこれぐらいがいい塩梅だね」というコンセンサスが徐々に普及しつつありますように見えます。*3
ADRは優れた手法ですが、使う際の目的感がきちんとしていないと形骸化するリスクを孕んでいると自分は考えます。自分が考えるADRの本質的な価値は以下です。大雑把にいうと「何を解決したいのか/なぜこの方法で解決できると考えるのかを背景/仮定/推論という形式で記録し、事後的に検証できるようにする」が大事なポイントかな、と。
原文
Writing a doc is not a perfunctory gesture, and asking for a doc on something is not a punishment or a mechanism for control. Writing a doc is a way of i) surfacing requirements and assumptions, ii) driving clarity of reasoning stemming from those requirements and assumptions. Without this step, our software has little hope of delivering the results we want over the long term.
和訳
ドキュメントを書くことは形式的な行為ではないし、何らかのモノづくりの際にドキュメントの作成を要求することは罰でもなければ、無意味な管理メカニズムでもない。 ドキュメントは、i) 要件と前提を明らかにし、ii) それらの要件と前提から生じる推論を明確にするために作成される。 このステップを怠れば、私たちのソフトウェアは私たちが望む成果を長期で達成できないだろう。
2. 検討にどれくらいの時間を投資するべきか？
あるモノのカタチを決める時に、実際に実装を始める前の設計検討にどれくらいの時間を投資するべきか？ という問題があります。
「ウォーターフォールだと時間をかけていい、アジャイルだと時間をかけなくていい、だと乱暴すぎる気がする。じゃあ、どういう観点で考えればいいのかな？」とモヤモヤしていた時に、Amazonの One-way-door vs Two-way-doorという考え方に出会ったのですがこの考え方のおかげで、自分の中で指針めいたものが得らました。設計検討をする時に押さえておくべき、有用性の高い考え方に思います。
3. 問題空間、理解のカバレッジ、集団の英知
優れた設計をするためには、問題空間に占める理解のカバレッジを一定以上にすることが大事です。
ここでいう 問題空間 とは、大雑把にいうと「あるもののカタチを決める時に考慮すべき事項の集合」です。また、理解とは「気にすべき課題を既知にできている。その問題をどのような道筋で考えるべきか/考えるべき課題の全体感がつかめている」です。
このような状態に人間一人の頭で至ることは極めて難しく、集団の英知を頼ることが現実的です。設計レビューでみんなでわいわい話していると、個人では思いつかなかったような優れた観点が手に入った経験がみなさんにもありませんか？
これが自分が考える「集団の叡智に頼る」のイメージです。このような多様な観点は多様性のある集団から生まれます。ですから、優れた設計をするためには多様性のある集団が大事とも言えます。
詳細は、書籍『多様性の科学』 を参照ください。
4. 問題空間を時間方向に広げる
前項で上げた 問題空間 という概念は、「ある特定の時点において、その時点で決めないといけないもののカタチを、その時点での与件に従い検討する」的なイメージでした。
それよりも、より広い視座 - 意志決定を行う時点では見通すことが難しい、将来の外部環境・要求仕様の変更、システムの拡張など - を見通してもののカタチを決めている人たちにしばしば出会います。すごいなーと思います。
「この説明だとピンとこない」という方もいると思いますので、具体的にイメージしてもらえるよう、以下に小説からの引用を添えます。*4
何故こんな無駄があるのか？とびっくりするようなストラクチャを見たことがあった。島田は真賀田博士に、その疑問を実際にぶつけた。この部分が無駄だと思う、と意見をしたのだ。そのとき、博士は、微笑んでこう答えた。 「貴女が生きている間は、無駄かもしれませんね」 そのときは、何かの皮肉だと思った。自分にはそれが無駄にしか見えない。生きている間はずっとわからないだろう、という意味に取った。それが、今ではそうではないことが理解できる。世界中でまだ、真賀田四季が初期に作ったシステムが稼働しているのだ。それに代わるものが現れない。多少の変更が必要だけれど、その変更も見越して作られている。新たなデバイスにも対応している。ハードの進歩を予想していたかのように、適切なエリアが割り当てられている。 それがかつての島田には無駄に見えた部分なのだ。
『χの悲劇』森博嗣
ここで上げられた 時間の経過を前提に設計を考える というはすごく面白いテーマです。
ペースレイヤリング
このような観点で考える際に有益なツールの1つに、ペースレイヤリングというフレームワークがあります。ペースレイヤリングでは、「時間の経過に応じた変化の発生のしやすさ」という観点でシステムをレイヤー分けします。そして、依存は「時の経過に応じて変わりやすいもの」から「変わりにくいもの」への片方向にのみ発生させるというルールを設定することで、システムの変更容易性を保とうとします。
参考 : 「依存性逆転の原則」の自分なりの解釈
Wardley Maps
また、Wardlery Maps という考え方も異なる観点ですが有益なツールに思います。Wardley Mapsは、バリューチェーンとそれを構成する個別の技術要素を可視化し、技術革新によりバリューチェーン全体がどのように変わっていくかを描き出します。ペースレイヤリングとは異なるアプローチですが、ここでも「時間の経過に応じたカタチの変化」が主題になっています。
*1:この問題について詳しく知りたい時は Living Documentation という本がおすすめです
*2:ADRの概要についてはこちらの記事がわかりやすいです。 -> https://qiita.com/fuubit/items/dbb22435202acbe48849
*3:昨今、欧米のTech系企業を中心にドキュメントのフォーマットにADRを採用する企業が増えつつある印象です -> https://twitter.com/shin_matsuzaki/status/1542136436182630401?s=21&t=Ja7_lJUq320l1Bqgi5dMpg
*4:「それって拡張性の話で、別に新しい話題ではないよね」という指摘もごもっともかと思います。そのうえで自分としては、そのような機能追加やスケーラビリティなどのカテゴリに考える範囲を閉じずに、もっと広範なパースペクティブ/視点でこの問題を考えられるといいなと思っています。もやったした言い方ではありますが。。
