天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

「銀の弾丸はない」を正しく理解するに参加してきた

architect-club.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

古典であるブルックスの「人月の神話」はエッセイ集で現代でも特に度々引用されるのが以下2つです。

・2章 人月の神話
・16章 銀の弾丸はない

このうち「銀の弾丸はない」はタイトル自体がキャッチーでそれ自体で用いられているため、単に「万能の解決策なんて無いよね」のような本来のコンテキストが失われた使われ方をされることがよくあります。

エッセイ「銀の弾丸はない」は、ソフトウェア開発にまつわる複雑さについて語っているものであって、世の中の生産性向上ソリューションは、もともと回避可能な偶有的複雑さにのみ有効で、ソフトウェアの本質的複雑さは何ら変わらない。ということを述べていて、よく読めば読むほど「万能の解決策なんて無いよね」とは随分と違った印象を受けます。 ということで、このコンテキストに沿って、偶有的複雑さの回避法や本質的複雑さへの対処の仕方について深掘りしている以下2つの論文・書籍も混じえつつお話したいと思います。

・Out of the Tar Pit
・Booch法:オブジェクト指向分析と設計

会の様子

銀の弾丸の原点と会を開いたきっかけ

「技術においても管理手法においても、それだけで十年間に生産性や信頼性と容易性での飛躍的な改善を一つでも約束できるような開発は一つとしてない」という内容が書いてあるという紹介がありました。

しかし、これが「万能の解決策なんて無い」として単に引用されることがあったり一種のメタファーではあるものの「銀の弾丸より金の弾丸」として書かれることがあったりして、本来の意味とはずれていないか?と思ってこの会を川島さんは開いたそうです。

ソフトウェア開発の難しさ

ソフトウェア開発の難しさは、本質的難しさと偶有的難しさ*1の2つに分かれるとブルックスは表現したという前提に関して話がありました。

この前提の上で、ソフトウェアの本質的難しさ*2に効くような銀の弾丸はないよね、という話をブルックスは言っており、本来的には銀の弾丸がないとは本質的な難しさに対してだということです。

一方で、偶有的難しさは幾つかの課題については乗り越えられてきたということで、

  • 高水準言語による高い抽象レベルのプログラミング
  • 一個の作業でCPUを専有しないようにするタイムシェアリング
  • プログラム同士を組み合わせて使えるようになった統合プログラミング環境

が具体例として挙がっていました。

そのため、単に「銀の弾丸はない」ことを言い切るのであれば、難しさについて90%未満の比率が偶有的難しさで示されている必要があるよねということで

というのはブルックスの言う銀の弾丸とはずれているよね、というお話がありました。

Out of the Tar Pit

Out of the Tar Pitでは、ブルックスが挙げていた4特性のうち、複雑さこそが唯一の重要なものであると結論づけ、本質的複雑さは「ソフトウェアにおける状態の多さ」「ロジックをつなげるコードや状態から計算するロジック」であり、偶有的複雑さは「コントロール」「導出が可能な状態」と定義したということでした。

なお、Out of the Tar Pitの話は矢野さんのブログが非常によくまとまっているので、詳細はそちらを確認すると良いということです。

tech.uzabase.com

偶有的複雑さを改めて考える

この話も踏まえて、偶有的複雑さの話を改めて考えていきました。

偶有的複雑さは究極的な理想環境ではなくなるものの、現実的にそのような環境に置かれていないがゆえに意図的に偶有的複雑さを抱える必要は実際の現場では出てくるということで、具体的な例として、

  • 口座エンティティにおける残高(取引を集計すれば残高は不要)
  • 暗黙の順序を作ってしまうコントロールフロー
  • 完全性/純粋性/性能すべてを満たすことができないトリレンマ

が挙げられていました。
偶有的複雑さは今日はトレードオフであるものの、明日は銀の弾丸が出てくるという可能性があるので知識のアップデートが重要だと川島さんは考えているそうです。

本質的複雑さに対する対処

最初に複雑さの定義のおさらいとして、シンプル*3の対義語だったり要素数の多さとして定義されるものだという話がありました。
そのため、コンポーネント分解などを実施することでエンティティあたりの複雑さは下げられても本質的複雑さの総量は低下しない(=本質的複雑さ保存の法則)という話がありました。

ただし、unknown unknownsを考えるとまずはエンティティあたりの複雑さを下げることは適切だということで、次のステップとしてコンポーネント数の多さに起因する複雑さ*4への対処方法が問題になってくるということです。

会全体を通した感想

こういった古典に立ち返って改めて原文の意味を解説する会は大好きなので、とても楽しかったです。

偶有的複雑さはトレードオフで終わらせるのではなく、銀の弾丸が生まれる可能性を考慮して常に学びをアップデートしていこうという川島さんの主張にはめちゃくちゃ共感しました。

*1:偶有的はアリストテレスが言い出した言葉。アリストテレスは実体(エンティティ)が本質的なものであり、そうではなくて存在が必須でない量, 質, 関係, 場所, 時間, 位置などを偶有的と表現した。

*2:コードで多くの状態表現が必要、恣意的に決められたルールや対象を持つ、変更がなされる、目に見えないため設計やコミュニケーションが難しい

*3:1つの役割、1つのタスク、1つの概念

*4:=高い認知負荷