2005年06月23日
Brooks, Frederick P. Jr., “The Mythical man-month: essays on software engineering Anniversary Edition,“ Addison-Wesley Publishing Company, Inc., 1995.（邦訳：滝沢徹・牧野祐子・富澤昇、『人月の神話－－狼人間を撃つ銀の弾はない』、アジソン・ウェスレイ・パブリッシャーズ・ジャパン、1996年.）
Brooks, Frederick P. Jr., “The Mythical man-month: essays on software engineering Anniversary Edition,“ Addison-Wesley Publishing Company, Inc., 1995.（邦訳：滝沢徹・牧野祐子・富澤昇、『人月の神話－－狼人間を撃つ銀の弾はない』、アジソン・ウェスレイ・パブリッシャーズ・ジャパン、1996年.）
全体を通してのブルックスの主張は，本書の副題である「狼人間を撃つ銀の弾はない」ことである。すなわちソフトウェア開発には特効薬ともいうべき、決定的な解決手法は存在しないことを指摘している。
第一に、「人数を増やせば納期を早くできる」、すなわち進捗(月)を労力(人)で代替できるという神話を適用することの誤りを指摘している。人月表示では計算上、“3人×8カ月”も“6人×4カ月”も同じ「24人月」となるが、ソフトウェア開発の作業は要員間のコミュニケーションの比重が大きく、人員追加はメンバー間意思疎通の効率を低下させるため、必ずしも納期短縮につながらないとする。むしろ、遅延しているプロジェクトへの増員は更なる遅延を招くというブルックスの法則を提示している。
第二に、「コンセプトが統合されているシステムはより早く開発されテストできる」ことを指摘している。コンセプトの完全性を実現するためには、1人または互いに意見が共鳴している極少数の頭脳からプログラミングデザインが考え出される必要があるとしている。具体的な解決法として、①アーキテクチャの労力とインプリメンテーションから切り離すこと、②チーフプログラマーを擁する外科手術チーム編成が柔軟な組織を作るということであり、総生産性の向上が得られることを指摘している。
大規模プロジェクトに関しては、少数精鋭では遅くなるために人手が必要であり、コミュニケーションとそこから生成される組織が必要であると述べている。コミュニケーションの方法には公式（ミーティング）、非公式（電話）、文書（手引書）を挙げている。組織の目的は、「コミュニケーションを不要にするための作業の分割と機能の専門化を具体化したものである。」としている。またリーダーシップとして、各サブプロジェクトには、製作主任(マネージャ－)の役割と技術主任(アーキテクト)の役割が必要と述べている。
また、開発というと、ウォータフォール型として，ライフサイクルのフェーズごとに確認をして，１回のサイクルで開発するものだとされるが、ソフトウェア開発は異なることを指摘している。プログラミングは、利用者のニーズに応えるものであり、実際の使用によりテストされ、要求によって変化に応える必要がある。そのため、変化に備えてシステムをデザインし、組織を構成する必要を挙げている。当初は「一つは捨石」と述べていたが、後にこの表現を変更し、上流に向かう動きが重要だと指摘している。
ソフトウェア構築を、本質(エッセンス)-複雑な概念構造体あるいはソフトウェアの実体-と、偶有的(副次的、アクシデント)-抽象的実在をプログラミング言語で表現すること-に分けることがすべての出発点であると述べている。ソフトウェア構築の困難は前者にあるとし、これこそが他の創造的な仕事と大きく違う所以であり、「銀の弾」がない理由だと論じている。自分自身を変えたり、他の物と容易に結びつくことができ、また、外界を変化させられる「現代の魔法」は、ソフトウェア開発に伴う困難が常についてまわるということになるとしている。
【コメント】(修士１年 脇谷康宏)
製作と技術の主任の重要性は経験上感得できます。では、２人１組のリーダーシップが望ましいというソフトウェア開発に、「三人寄れば文殊の知恵」の日本的思考はどう対応するかが要検討課題だとも感じました。全体として、やはり知的財産の創出の何たるかというように読みましたが、ソフトウェアに変化と困難が不可避の特質であるということは、変化性のある知的財産の創出は永遠に「面白い」場とも言えるとは思いましたが。そのためには、ランドマークの徹底やデザインの文書化、組織化など、自身への課題が山積みです。
オープン・アーキテクチャ戦略
國領二郎、『オープン・アーキテクチャ戦略』、ダイヤモンド社、1999年.
システムに無駄がないということは、そのシステムを構成する各部位の相互依存性が高いということであり、統合度が高まることを意味する。 1980年代に日本の製造業は統合度の高い製品を統合度の高い組織でつくってきた。 これは日本の製造業の全体として、モジュール化を否定することで発展してきたと言える。 モジュール化は、企業が得意領域に経営資源を集中し、それ以外については大胆な提携によって他社資源を活用する、オープン型経営を採用することと密接に関係している。 具体的にはアウトソーシングやパッケージソフトの導入、事業部門の売却や合併などである。 情報技術が急激に発展しつつある今日の情報技術は分散的な協同を強力に支援する。 ネットワーク上では次の3つの要因が相互作用し合って多様な主体が発信する情報を結合させることで価値がうまれる経済が形成している。 ①機械系システムと人間系システムの処理能力向上のアンバランス（情報過多）、②ネットワークの普及による情報の不対称性の構造変化、③情報と媒体のアンバンドルによる情報の非物財的特性の表面化である。情報システムのモジュール構造は資源利用の無駄を許容しながら、独立した組織は分散的な開発を行うことによって生じる創造性の増大できる。
オープン・アーキテクチャ戦略は本来複雑な機能を持つ製品やビジネスプロセスを、ある設計思想（アーキテクチャ）に基づいて独立性の高い単位（モジュール）に分解し、モジュール間を社会的に共有されたオープンなインターフェースでつなぐことによって汎用性を持たせ、多様な主体が発信する情報を結合させて価値の増大を図る企業戦略のことである。 オープン・アーキテクチャ戦略はネットワークの特性を最大限に活用し、その価値を最大化することができる。 オープン・アーキテクチャ戦略という視点をもつ多くのビジネスのモデルからは特にSCM（Supply Chain Management:供給連鎖管理)とCRM(Customer Relationship Management:顧客関係性管理)に関連しているテーマをあげながら多様な主体の情報結合に必須のフラットフォームを提供するビジネスについて議論している。 本書では、情報産業における水平展開型ビジネスモデルと顧客参加型ビジネスモデルをあげている。 水平展開型ビジネスモデルは得意領域に経営資源を集中投入しつつ、足りない機能についてはそれを最も得意としている企業に補完してもらうことである。 それは、多様な主体がもつ情報を結合させ、価値の増大を図るメカニズムである。水平展開型モデルへの展開を思考する場合に重要なのが、インターフェースのオープン化である。 自社システムのインターフェースを世の中のデファクト・スタンダードとしていくのが有効である。 オープン・アーキテクチャ戦略の一形態になりえる。 一方、顧客参加型モデルは顧客が手にする情報の量や質の変化により、かつて販売者と顧客の間に情報の非対称性が逆転しつつある。 顧客間のインタラクションおよび電子市場の新たな関係性を通じて顧客は新たな価値を生産している。単なる消費者であった顧客を積極的な価値の生産者にしていく。 様々な企業や個人の情報を結合させることは簡単にできるのではない。 それをビジネス化したのがフラットフォームビジネスである。 フラットフォームビジネスは①取引の探索、②信用（情報）の提供、③経済価値評価、④標準取引手順、⑤物流など諸機能の統合の５つの機能を提供する。以上のようなオープン・アーキテクチャ戦略は分散・自律的なシステムを構築が可能になり、社会において協同モデルを提示する。
＜コメント＞
オープン・アーキテクチャ戦略は組織・社会において自律・分散的なシステムを可能にすることができると思う。それによって、企業及び組織間においてはその関係性がます重要になってくるのではないかと思う。つまり、各々の自律・分散的な有機体（企業・組織・社会）が他の有機体（企業・組織・社会）との協同的な関係を有効に構築するためには「関係性」を明確にする必要があると思う。関係性の理解は各有機体の間とのコミュニケーションとそのツールの理解は同じことであろう。 <池 銀貞＞
Frederick P.Brooks,Jr. The Mythical Man-Month ESSAYS ON SOFTWARE ENGINEERING （1995）(邦題：人月の神話 オオカミ人間を撃つ銀の弾はない 新装版』、ピアソン・エデュケーション、2002年）.
■概要
本書は、IBMのOS/360開発のマネージャを努めた筆者が、大規模コンピュータプログラム開発について分析したものである。1975年の初版(中心論文：「人月の神話」)発行から20年後に、「銀の弾などない」(86年)等を再録したうえで記念贈訂版が刊行されていることからも明らかなように、現在にも通ずる指摘が多く、筆者はその理由のひとつを「どのように人がチームで物を作るか」を扱っているからとする。
ソフトウェアプロジェクトで「人」と「月」が相互に交換可能と考えるのは危険な神話であり、時間(月)を短縮しようと、プロジェクトに要員(人)を追加することは、再配分作業とそのための中断、新しい要員の訓練、新たな相互コミュニケーションにより全体の労力を増大させ、かえって完成時期(月)を遅らせる。人は少数精鋭チームが望ましく、大規模システムを構築するためには、外科手術チームのように1-2名の執刀医と副執刀医が全デザイン及び全コードを理解し、仕事のコンセプトを統合することが重要である。システムデザインで最も重要なのはコンセプトの完全性だ。そのためアーキテクチャデザインは一人またはごく少数の頭脳から考え出されなければならない。アーキテクチャを、インプリメンテーション、実現から分離することが必要で、これらは同時並行で進めることが可能だ。アーキテクチャに一貫性を持たせるため、仕様書は一人か二人でとりまとめ、定義に形式的表記を使用する。電話やミーティング、プロジェクト手引書(目的、外部仕様書、インターフェース仕様書、技術標準、内部仕様書)等でコミュニケーションを図ること、及び必要となるコミュニケーションと調整作業の量を減らすために組織が必要であり、組織のリーダーとしてはマネージャー(製作主任)とアーキテクト(技術主任)の２種が必要だ。インプリ・実行過程では、捨石覚悟のパイロットプログラムの必要性を認識したうえで、高水準言語と自己文書技法を使って、変更により誘発されるエラーを抑制すること、変化に備えた組織計画も必要だ。マネージャは、コンピュータ設備、高水準言語(生産性とデバッグのスピードをあげる)と対話型プログラミング等を用意する。バグ回避のためにも、システム構築をアーキテクチャとインプリメンテーション及び実行に分けて考えること、これをトップダウン方式で進めること、構造化プログラミング(個別の分岐文ではなく制御構造全体として考えようとすること)も有効だ。システムデバックは困難であるがゆえに系統だったアプローチをとること、また大規模プロジェクトをコントロールするため、スケジュールそのものを用意することが重要だ。
ソフトウエア構築には、概念構造体を作り上げる本質的作業と、それを機械言語に写像する付随(偶有)作業がある。困難なのは、ソフトウエアが複雑で、人間が作り出した他の人工物に同調しなくてはならず、可変性を要求され、不可視であるという本質的特徴を持っている点だ。高水準言語等、偶有的困難を取り除く進歩はあるが、デザインの本質的複雑性を解決する銀の弾はない。問題は人間の問題であり、偉大なデザイナーを育成する方法を開発することだ。
1970年代のソフトウェア構築工程は、マイクロプロセッサ革命等の技術革新により、偶有的困難の多くが除去された。しかしソフトウェアシステムは、人間の作りだしたもののうちで最も複雑なものであり、ソフトウェアエンジニアリングに特有な問題は75年と変わらず、引き続き展開させていくことが必要だ。
■コメント
OS/360の時代にはモジュール化したパーツの統合(アーキテクチャ)は、 トップダウン、少数のアーキテクトにより、デザインルールとして(初期段階に)確立することが必要だった。自律分散のインターネット時代に、アーキテクトは今後もごく少数であるべきか。自身の研究分野で、地域住民を巻き込みながらたった１人の監督(アーキテクト)が映画を作成するケースと、プロデューサー(本書ではマネージャー、製作主任)が全体を統括しつつ、多数のアーキテクトが自由にTV番組を製作するケースがある。両者の長短を比較検討しながら、最終デザインを多数の参加者が担う、人工物設計のあり方を考えてみたい。 （2005年6月23日 高橋明子）
Frederick P.Brooks,Jr. The Mythical Man-Month ESSAYS ON SOFTWARE ENGINEERING （1995）(邦題：人月の神話 オオカミ人間を撃つ銀の弾はない
大規模ソフトウェアシステムの制作における労働力の単位として人月を用いるのは危険である。これはソフトウェアシステムにおける根本的要素であり固有の性質としての①複雑性、②同調性、③可変性、④不可視性に起因する。ソフトウェアはどの部分においても同一ではなく、その①複雑性は偶有的なものではない。さらに大規模プロジェクトにおける複雑性の非線形な増加によって、コミュニケーションコスト、スケジュールの予想の難しさ、コンセプトの非統一といった問題を誘発する。また周囲のニーズ、環境に合わせた開発が必要であり（②）ソフトウェアは機能の具現化そのものであり、純粋な思考の産物であることで融通性に富むため常に変化を迫られることとなる。（③）加えて構造を幾何学的に示すのが困難（④）であるため概念上のツールの作成が阻害されている。これはデザインプロセス、コミュニケーションの妨げとなる。
これらの問題の解決方法（銀の弾）として外科手術チームのモデル等によるアーキテクトトインプリメーションの切り離し、マネジャーとアーキテクト二つのリーダーシップの必要性などが提唱されているがこれらはが改善するのは偶有的困難のみである。技術的な点ではこれまでの高水準言語、タイムシェアリング、統一プログラミング環境といった三段階の発展がみられる。加えて高水準言語の進歩、オブジェクト指向プログラミング、人工知能、環境とツールの整備などが研究されている。なかでもAIには二通りの定義①従来人間の知能によって解決されていた問題の解決の為のコンピュータの使用、②自己発見的なプログラム技法群の使用、のうち特に後者のエキスパートシステムはプログラム自体とアプリケーションの分離が可能であるという利点に期待を寄せている。開発においてコンピテンシーの抽出が必要であるため専門家の確保と行動指針の言語化が不可欠となるが、これによって経験と知識の共有が可能となる。さらに概念構造体の本質への有望な攻略としてはアウトソーシングによるカスタマイズ、要件の洗練と迅速プロトタイピング、（フィードバックサイクル）、漸増的開発、デザイナーの育成（単独での創造的プロセス）等が上げられている。しかし、ソフトウェアシステムは根本的要素によって開発における困難を解決する術はないように思われる。しかし単純化することで現象を説明する自然科学の手法は用いることができないが複雑な事物も何らかの秩序原則の影響を受けること、自然な写像は得られないまでも図式を思考とデザインの支援に使用することなど登場しそうにない解決策をまつのではなく生産性を向上させる改善を進めるべきである。
■ コメント
デザインルールに比べコンピュータの複雑性を悲観的に受け止めているように思う。文中にもあるように挙げられている手法は多様なプロジェクトにおいて有効なものもあった。プロトタイピングや漸増的開発などはボトムアップの要素もあるように感じられ、生物的進化との類似も感じられた。（小池由理）