The Mythical man-month

20周年記念増補版です。

キモは16章です。

銀の弾とは、生産性や信頼性と容易性での飛躍的な改善を一つでも約束できるような開発

のことである。


ソフトウェア構築作業の、本質的(essencial)性質と、付随的(accidental)性質。


accidentalは「偶有的」と訳されている。聞いたことのない言葉になっているのは理由がある。
この accidental という語は、アリストテレスが使ったのに従った用法であるのだ。
この語は「偶然発生した、災難」といった意味ではなく、「副次的な・付随的な」という意味であると、
17章で説明されているので、ここではわかりやすく「付随的」と書く。

「付随的な性質」とは、プログラミング言語で表現しハードウェアのメモリにロードされ実行される、
といったことで、これらに関する改善はやり易い。
例)ハードウェアの制約、言語の扱いにくさ、機械使用時間の不足など

本質的な性質とは、

抽象的なソフトウェア実体(entity)を構成する複雑な概念構造体を作りあげる事

としている。

そして、この本質的な性質に対する改善はなされていないし、今後もなされる見込みはない、
それが「(今後10年間は)銀の弾などない」と言った根拠なのである。

銀の弾候補


1995年にかかれた事に注意。

  • オブジェクト指向プログラミング(C++)

  • ウォーターフォールではなく、スパイラルな開発プロセス
    • システムを漸増させ、育てていく。

  • 迅速なプロトタイピング

  • データベース

  • PC(マイクロコンピュータ革命)

  • インターネット、WWW、ハイパーテキスト


  • WIMPインタフェース(Windows, Icons, Menus, Pointing Interfaces)
    • ただし現状には否定的。音声入力に取って代わると言っている。


オープンソース、Email,BBS,Wikiなどについて、どう考えているだろうか?
特にオープンソースについて聞いてみたいところだ。



サーチしてみたら、オープンソースは銀の弾じゃない、と言っている人が一人いた。

一方、下記のような人もいる。



ネット流、すなわちオープン・ポリシー
http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040401/1/

上記のコラムは、某大手丼物チェーンの宣伝文句よろしく「安い・速い・上手いのシステム構築術」と題されています。
楽天とヤフージャパンが成功例として挙げられていますが、私が着目したいのは、その両社が共に熱心なオープンソース・ソフトウェア・ユーザである、という点です。
もちろん、このエントリの主旨は、ソフトウェアにおけるオープンソースとプロプライエタリの優劣を論じることではありません。じっさいの本旨は、オープンソース・ソフトウェアに見られる開発手法が「安い・速い・上手い」システム構築に寄与しているのではないかということです。

開発人員をより多く投入すると生産性が逆に後退するという問題は、『人月の神話―狼人間を撃つ銀の弾はない』で述べられており、これは情報システム開発におけるベーシックな論点となっています。にもかかわらず、先に挙げた2社は、より多くの開発人員を投入することにより生産性を高め、かつコストダウンを実現しようとしています。

多くの人員を投入すれば生産性が落ちる元となるのは、意志伝達における齟齬の問題です。新しく入ってきたメンバーと以前からいるメンバーとの間では、コミュニケーションのスキルや方法論といった面にある差異が避けられないのがふつうです。これが、オープンソース・ソフトウェアに見られる「オープン・インターフェース」を介することにより、よりスピーディに仕様を認識でき、また、ソフトウェア・プロジェクトを構成する複数のモジュールの相互関係を速やかに理解することが可能になります。したがって、新たに加入した開発者も、オープンなインターフェース仕様を理解できれば、速やかに開発メンバーの一員として活躍できるようになるという仕組みです。

私の過去のエントリ http://www.dmtj.net/pm/comments.php?id=22_0_1_20_C でも触れたように、オープンソース・コミュニティに見られるモチベーションを介したディストリビューション~コラボレーション~イノベーションの循環ができてくるようになると、ソフトウェアの生産のみならず、産業全体に好影響を及ぼすのではないかという観測をしています。


やはりコミュニケーションである。「オープン・インターフェース」とかいうものが、一体何なのかはよくわからないが、
仕様書やコーディング規約のような、開発者の基準となるなにか、あるいはAPIのようなものだろう。

これは、プログラミングにおけるクラスの隠蔽のように、直接変数を操作する事を許さず、必ず公開しているAPIを経由することを要求する。
とりあえずインタフェースだけ作っておいて、「準備中」とでもいう値を返すようにしておけば、仮結合もできよう。

タグ:

+ タグ編集
  • タグ:

このサイトはreCAPTCHAによって保護されており、Googleの プライバシーポリシー利用規約 が適用されます。

最終更新:2005年10月30日 00:26
ツールボックス

下から選んでください:

新しいページを作成する
ヘルプ / FAQ もご覧ください。