銀の弾とアジャイルについてのメモ (Agile is a Silver Bullet)
2018年10月9日
要点
- 1986年にソフトウェアエンジニアリングについて書かれたフレデリック・P・ブルックス氏（以下、Brooks）『人月の神話』「銀の弾はない」はすごい（久しぶりに読み返した）。まじリスペクト。
- 本質的な困難と、その攻略を通じて、アジャイル開発を理解するとスッキリする（個人的な見解です）。
はじめに
アジャイル開発は、ソフトウェアエンジニアリングにおいて迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。
アジャイル開発の「なぜなのか(WHY)」や「どのような問題を解こうとしているのか」を、自分なりに整理したかった。その時、Brooks『人月の神話』を改めて読んで、びっくりした。これは、すごいと。
2018年10月9日に書いたメモがある。まだまだ整理や考える余地はあるけれど、少し読めるようにして、とりあえず公開してみる。
アジャイルは、どんな問題を解いているのか
2001年に「アジャイル」と名付けられたソフトウェア開発手法のアジャイルソフトウェア開発宣言（以下、マニフェスト、もしくはアジャイルマニフェスト）が公開されている。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
マニフェストは、どのような問題を解いているのであろうか。なぜ右側のことがらに価値がおくのだろうか。その結果、導かれるアジャイルのマインドセットやプラクティスの解釈や評価基準はなんであろうか。
銀の弾はない
銀の弾はない (No Silver Bullet) は、1986年に Brooksによって発表された、今（2018年）から30年以上も前だ。この論文は、広く知られていて、ソフトウェアエンジニアリングにとって大切な古典である。
狼人間は慣れ親しんでいるものを不意に恐怖に変えてしまうからだ。だから、私たちはこの狼人間を魔法のように鎮めることができる銀の弾を探し求める。
ソフトウェアエンジニアリングにおいても問題を簡単に解決できる方法やツール「銀の弾」が話題になる。しかしながら、そのような解決策は、継続的な効果がなく消えていくことが多い。本質的な問題を理解し、根気強く持続的に取り組むしかない。
困難の種類
ソフトウェアテクノロジーにおける難しさを本質的なものと偶有的なものにわけた。「難しさの本質とはソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、実現するとき派生するが本来備わっているものではない困難のことである。」
- 本質的な困難： ソフトウェアは、組み合わさったコンセプトで構成されている。その同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。それにもかかわらず、非常に正確で十分に詳細なものである。
- 偶有的な困難： 実現するとき派生する本来備わっているものではない困難
ソフトウェア構築において困難な部分は、概念構造体の仕様作成とデザインおよびテストにあって、表現することやその表現に忠実かをテストすることではないと考えている。 本質的に銀の弾という特効薬がない。
つまり、「ソフトウェアは妄想の産物である（大槻氏）」にあるように、概念構造体とその操作が難しいことが本質的な困難であるといえよう。
本質的な困難における固有の性質
本質的な困難は、このような4つの性質があるとされている。
- 複雑性： 規模の拡大は、異なる要素の数が増える。たいていの場合、その要素は互いに非線形で影響し合う。全体としての複雑性の増加は線形どころではない。本質的な複雑性と、その複雑性が非線形に増大することに由来。数学や物理学は、複雑な現象を単純化したモデルを構成…この方法でうまくいったのは、モデルで無視された複雑性が現象の本旨的な性質ではなかったからだ。複雑性が本質の場合は、この方法は使えない。
- 同調性： インターフェースを人間の慣習や社会制度に順応させなければならない
- 可変性： 純粋な思考の産物であってきわめて融通性に飛んでいる。慣習や媒体といった文化的マトリックスにすっかり はめ込まれている。それらは絶えず変化し続ける。
- 不可視性： ソフトウェア実体は本質的に空間に埋め込めない。ソフトウェアの構造は、一つではなく複数の一般的な有向グラフで構成され、それらが互いに重なり合っている。
（不可視性についての「複数の一般的な有向グラフで構成され、互いに重なり合っている」だけで、深く味わえる。たとえば、ソフトウェアエンジニアで使われるUMLやモデル、さらには数学の圏論も有向グラフで構成されている。）
なお、同調性は、仕様書や要求への順応ではなく、人間の慣習や社会制度である人間の慣習や社会制度である。この表現は、顧客にとっての価値と解釈することに違和感を感じない。
本質的な困難への攻略
見込みのあるソフトウェア問題の本質を衝く攻略として紹介されているものとして、1. 購入対自主製作、 2. 要件の洗練と迅速プロトタイピング、3. 漸増的開発（ソフトウェアを構築ではなく、育成する）、 4. 偉大なデザイナーが紹介されている。
| 攻略 |
困難 |
攻略の説明 |
| 要件の洗練と迅速プロトタイピング |
もっとも困難な部分は、何を構築するのかを的確に決定すること |
プロトタイプと製品の開発および仕様作成を反復しながら進めること |
| 漸増的開発（ソフトウェアを構築ではなく、育成する） |
私たちの構築する概念構造体が複雑すぎて、前もって的確に指定することができず、複雑すぎて欠陥なしに構築することができない |
（生き物の複雑さを参照して） そのソフトウェアシステムも漸増的開発によって育成されるべき。複雑な実体を育成できることがわかった |
両方ともに、アジャイル開発のコンセプトと本質的に同一であろう。本質的な問題（複雑性、同調性、可変性、不可視性）に対して、局所化と探索によって回避するアプローチ と理解できる。
世界観や価値観が異なっていることから、アプローチの違いが生み出される。マインドセットや文化と呼ばれることもある。あくまで私の解釈で哲学や思想を背景にこれらを雑に分類してみる（これらの世界観の比較は、たくさんの引用文献と相当に長いリストになり、かつ、それぞれの丁寧にマッピングする必要がある。しかしながら、ここでは大胆に捨象している）。
| 世界観 |
ウォーターフォール |
アジャイル |
| 科学アプローチ |
いわゆる古典的科学 |
いわゆるシステム科学・生物学的アプローチ |
| 全体と部分 |
全体は部分の集合によって説明可能 |
全体と部分は異なる性質を持つ |
| 認識 |
変化しない |
変化する |
| 分離・分類可能性 |
分離可能 |
分離不可能・分類困難 |
| 事実・真理 |
事実・真理が自分たちの外にある |
事実・真理は関係の中での解釈にすぎない |
| デザイン |
機能 |
意味 |
| コミュニケーション形態 |
一方向 |
双方向 |
今までは、全体を認識できると前提を置いていたため、その全体を分離することによって局所化していたが、全体が説明できないことがわかったため、その主観的な関心に対して、相互にコミュニケーションを行いながら探索する世界観へ移行している。
銀の弾になるためのアジャイル開発
Brooksの『銀の弾はない』『人月の神話』は、1986年に公開されている。本人を含むさまざまな人が、さまざまなタイミングでレビューしている。
「要件の洗練と迅速プロトタイピング」や「漸増的開発」、「偉大なデザイナー」といい、アジャイルと深く関連する攻略だ。2001年にアジャイルマニフェストを作ったメンバー全員は、間違いなく読んでいるはずだ。
Brooks『銀の弾はない』が、アジャイルの源流のひとつか、少なくとも関連している と私は思った（時間と興味があったら後で調べる）。
このメモでは、システム開発標準のV字型モデルのような、要件定義書や仕様書をあらかじめ完全にモレなく書くことを目指すスタイルをウォーターフォール開発と書いている。ウォーターフォール開発に近いアジャイル開発もあるし、ウォーターフォール開発でもアジャイルのスタイルを取り入れていることも多いため、厳密な分離は難しい。そのため「いわゆる」と雑な分類になっている。
いわゆるウォーターフォール開発とアジャイル開発の主たるアプローチを比べてみよう。
| アプローチ |
局所化 |
コミュニケーション |
| ウォーターフォール |
領域の分割＋統治 |
完全な文書 |
| アジャイル |
価値の中心＋迅速なフィードバックによる探索 |
双方向のやりとり（主体的・対話的で深い学び） |
つまり、アジャイルマニフェストにおいて「変化への対応」は、同調性や可変性への対応への主張ともとらえられる。また、いわゆるウォーターフォール開発でもうまくいくためにやっていることも評価できるだろう。
本質的な困難を通じて、アジャイルマニフェストに追加してみた。元になっている文章は、イタリック（斜体）で表記している：
ソフトウェアエンジニアリングが持つ本質的な困難を攻略するため、よりよい開発方法を見つけだそうとしている。
- 不可視性： 重なり合っている複数の一般的な有向グラフで構成された概念構造体は、空間に埋め込めず見ることはできないため、プロセスやツールよりも個人と対話に価値を置く。
- 同調性： インターフェースを人間の慣習や社会制度との順応（顧客から見た品質）を調べるため、包括的なドキュメントよりも動くソフトウェアに価値を置く。
- 複雑性： 本質的に複雑なソフトウェアに対して、相互のコミュニケーションを通じて攻略するため、契約交渉よりも顧客との協調に価値を置く。
- 可変性： 慣習や媒体といった変化する文化的マトリックスに はめ込められているため、計画に従うことよりも変化への対応に価値を置く。
「なぜなのか」の解釈を加えたアジャイル開発の原則
銀の弾にある本質的な困難からみた『アジャイル宣言の背後にある原則（アジャイルの原則）』は、このように理解できるだろう：
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
- 人間の慣習や社会制度に順応する同調性を向上させるため、顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 組み込まれている文化的マトリックスは固定ではない（可変性がある）ため、要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- リリースして同調性を確認しつつ可変性を確保するため、動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
- 組み合わさった概念構造体の不可視性を攻略するため、コミュニケーションを密にします。ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 不可視性を攻略するため 健康的で効果的なコミュニケーションを用いるので、意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 組み合わさった概念構造体によって生み出される複雑性を、ノンバーバル（非言語）を含めたコミュニケーションによって攻略するため、情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- リリースしたソフトウェアと社会との同調性を計測するため、動くソフトウェアこそが進捗の最も重要な尺度です。
- 本質的な困難を回避する特効薬（銀の弾）などなく、反復しながら育成する必要があるため、アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 本質的な困難を攻略するための土台を作り、価値を担保するため、技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- 複雑性を攻略するための心がけとして、シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 組み合わさったコンセプトで構成される概念構造体を重ね合わせ、統合していくプロセスが含まれる（複雑性を用いた同調性の獲得）ため、最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- 同調性を生み出す可変性を調整するため、チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
本質的な問題（複雑性、同調性、可変性、不可視性）に対して、局所化と探索によって攻略するアプローチ として、とても良くできている。
本質的な困難の攻略を支援する道具たち
コミュニケーションを支援する環境・技術（例）
双方向のコミュニケーションを実現するために、このようなことが言われている（例）。
- 心理的安全による支援
- 主体性の獲得による実現
- 組織構造による支援（ティール組織やホラクラシー組織）
アジャイル開発のプラクティスが支援する仕組み（例）
アジャイル開発のプラクティスは、本質的な困難をどのように攻略しようとしているのか、の観点を加えると使いどころがより明確になるのではないだろうか。
- スプリント計画・スプリントレビュー
コミュニケーションによって価値の探求と探索を実現するものとして有効に活用する。
- プロダクトオーナー
外に真実があるのではなく、コミュニケーションの中で価値がわかる。それを実現するため「オーナー」は、システムの中に入って主体性の獲得を目的とする有効なプラクティス名である。
- 「完了(DONE)」の定義
領域を分割しているわけではないため、それぞれの行動について、その都度の領域を決める必要がある。
アジャイル開発（プラクティスのセット）は、うまく行くための支援するノウハウが詰まっているため、有効に使おう。ただし、アジャイル開発をやることを目的にしてしまうと、本末転倒になりがちである。アジャイルである(be-agile)ようにしよう。
おわりに
本質的な困難へのアプローチ、という観点でアジャイルマニフェストとその原則やプラクティスを整理すると、アジャイル開発の「なぜなのか(WHY)」や目的がすっきり理解できた。
アジャイル開発も含むソフトウェアエンジニアリングは、たくさんの経験や知見を通じて進化している。そのため、1986年の『銀の弾はない』の議論で止まることがいいわけではない。さまざまな知見や経験を通じて、さらなる進化が大切である。
病気治療の第一ステップは、悪霊信仰を細菌説によって生理学的理論に置き換えることだった。このステップこそ希望の始まりであり、すべての魔法のような解決策の夢を打ち砕いた。
医療従事者は、進歩は段階を追いながら多大な努力を払って遂げるもので、健康回復には持続的で根気強い介護がなされなければならないと教え込まれた。今日のソフトウェアエンジニアリングにおいても、それは変わらない。
アジャイルは銀の弾である、少なくともポテンシャルはある、と言えるかもしれない。ただし、特効薬や弾ではなく、じっくり効果を発揮していくのでやっぱり銀の弾ではない、とも言えるかもしれない。
とりあえず、今日のところはここまで。
おいしいものを食べようよ。
参考資料
- Brooks, Frederick P., (1975). The Mythical Man-Month. Addison-Wesley. ISBN 0-201-00650-2.
- Brooks, Frederick P., (1986). “No Silver Bullet — Essence and Accident in Software Engineering”. Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.
- フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、宮澤昇 (訳) 『人月の神話 狼人間を撃つ銀の弾はない (20周年記念増訂版、新装版)』 ピアソン・エデュケーション、2002年。ISBN 978-4-89471-665-0
本記事における引用は、20周年記念増訂版を用いている。
追記・コメントなど
- 2018/11/04「銀の弾はない」は、1975年との記載は誤りで、1986年が適切です。お詫びして訂正いたします（本文中は訂正しました）。ご指摘ありがとうございました。
