投稿元:
レビューを見る
36年前に上梓された本とは思えない。
それぐらい含蓄のある名著。
逆に言うと、この36年間、ソフトウェアエンジニアリングの世界は何をやっていたんだという軽い絶望感を味わえる本。
本文中にもあったと思うけど、ソフトウェア開発ってのは大規模になればなるほどステークホルダーとして多くの人間が関係し、人と人とのトランザクションが発生する。
そういった意味で、エンジニアリングとはいうものの、多分に社会科学的な要素を含むんだろうな。
コンピュータサイエンスみたいな自然科学寄りの分野の進歩と比較しても仕方ないのかも。
だからこそ、ソフトウェア開発に携わる人間としては、ソフトウェアエンジニアリングの技術的側面だけでなく、心理学であったり社会学であったりマーケティングであったり組織論であったりEQであったりリーダーシップであったり、そういったもやっとしたウェットな領域もカバーしないといけないんだなと。
これからの道筋が少し見えた気がします。
投稿元:
レビューを見る
・遅延したプロジェクトに人員を追加しても、さらに遅延するだけである。
・人と月が交換可能なのは、多くの作業者の間でコミュニケーションを図らなくても仕事分担が出来る作業のみ。
・相互コミュニケーションが必要な作業は人が増えるとむしろ作業コストがあがる。
・プログラムを作ることは以下五種類の喜びを与えてくれる。
-物を作る喜び
-他の人に役立つ物を作る喜び
-パズルのような組み合わさって作動する部品でできたものを作る喜び
-つねに学ぶ、という繰り返しがない作業の喜び
-実在して動き働くもので仕事ができる喜び
・優秀なプログラマの生産性は出来の良くないプログラマの10倍違う。
・少数精鋭チームが最高である。
・コンセプトの一貫性、完全性が重要。
・コミュニケーションの重要性。
・働きやすい環境にすることにコストをかける。
投稿元:
レビューを見る
全てではないが、「あ、これ、あるある!」の連続。しかし、この本が書かれたのは1975年のこと。当時こうやって指摘されていたソフトウェア開発の問題点が現代にも生き残っているというのは残念な話。
投稿元:
レビューを見る
ソフトウェア開発のプロジェクトの本質的な複雑さについて述べている。
「人月」という一人当たり一ヶ月でどれだけのモノが生産出来るか、という単位がある。
一人が六ヶ月作業するのと、二人が三ヶ月作業する量は同じ、という単位。
これに対して疑問を投げかけている。
実際には人が多くなるにつれて組み合わせの数だけ情報共有の手間がかかり、多くなればなるほど一人当たりの生産性は落ちる、という。
また、ソフトウェア開発の複雑性についても述べている。
環境によるもので、解決可能な複雑性なのか、それとも本質的に複雑で不可避なのか。
プログラムは非常に複雑な背景があり、動いている。
それを記述するのは非常に楽にはなっているが、その組み合わせは無限にある。
複雑な部品が集まり、一塊の意味のあるものを作り、それを組み合わせてひとつのモノを作り上げる。
単純に組み合わせで考えるだけでも無限にあり、非常に複雑になる。
また、プログラムは物質的に存在する建築物などと異なり変更が容易なため、必要に応じて変更を要求される。
しかし、その複雑さは建築物にも劣らない。
このように様々な複雑さや難解さを解説する。
これに対する解決方法、狼男を倒せる「銀の弾」はないのだろうか。
無い。
しかし、前に進む方法はある。
本書が書かれた当時から何十年も経っているが、内容は具体的なことはともかく本質的な部分では全く古くは無い。
「銀の弾」は無いが、多くの人が時間をかけて協力することで解決出来る一般的な方法が生まれるのだろう。
そのための問題提起を行っている本として読む価値がある。
投稿元:
レビューを見る
いかにも「古典」という感じ。「ピープルウェア」で述べられている内容と被る部分が多く目新しい知識はあまり無く感じた。
投稿元:
レビューを見る
要するに、プロジェクト遂行とは大規模並列計算と同じなのだと。
分割可能なタスクは並列演算、ベクトル演算可能。
アムダールの法則に従えば、並列化率を上げれば、作業効率は上がる。
基本的に分業できる部分は分業したほうがいい。
しかし、実際の並列計算において意外にコストがかかるのは、個々のノードの演算ではなくて、ノード間の通信時間、オーバーヘッド。
大規模演算を行うために並列数を増やせば、通信コストは増す。
まして人間ではコンピュータ以上に通信のコストは高い。
通信のプロトコルが正確とは限らないから、エラーが出まくりの、オーバヘッドが膨大なのである。
したがって、安易に並列数を増やすより、各々のノードの実行効率を上げるほうが効果的。
SIerやエンジニアリング業者の個人の仕事量が多いのは、そのためである。
仕事が多いことが腑に落ちた。
そして、一人で大量のタスクをこなせる高機能CPUが必要となる。
「偉大な旋盤工は、平均的な旋盤工の数倍の給料を支払う価値があります。しかし、ソフトウェアコードの偉大な書き手は平均的な書き手の一万倍の価値があるのです。」
というゲイツの言葉が思い出される。
どうしても並列数を増やしたければ、プログラミング(組織を作る)の際にノード間の通信量をなるべく少なくするように、アルゴリズムを組む必要がある。
そうすれば実行速度の低下も抑えられる。
プロジェクトマネージャーの機能の一つが並列コンピューティングのプログラマ。
少ないCPU間の通信で同じ演算結果を得られるように工夫しなければならない。
あと、インターフェースとかオペレータとかの役割もあるのだろう。
オペレーションも命令系統が機能するような組織を編成するべし。
いくつかの案が提案されていた。
また、プロジェクトの成果物のコンセプトを一貫したものにするためには、コンセプトの決定権を集約しなけらばならない。
コンセプトを決める人は一人。
設計者はコンセプトは触らない。
いかにコンセプトを実現するかという部分に裁量を持ち、自己主張せねばならない。
投稿元:
レビューを見る
40年近く前に書かれているため、技術的には古く参考となる部分は多くない。しかし、考え等は今でも十分に通用するどころか非常に示唆にとんでおり参考となる部分が多い。
投稿元:
レビューを見る
レビューはブログにて
http://ameblo.jp/w92-3/entry-11236629979.html
投稿元:
レビューを見る
大規模ソフトウェア開発に関する古典とも言える書。かなり古い言葉も出てくるが、本質的な状況は変わっていない気がする。銀の弾はないということか。
投稿元:
レビューを見る
数十年前に書かれたものだが現在でも名が上がるほどの本,
ということで一回読んでみた.
システムの開発に関して,開発を遅らせる原因やチームを作る難しさについて記してある.現在の自分の立場ではあまりイメージできないところではあるが将来そのような職に就くことがあればもう一度この本を理解したいと思う.ソフトウェア開発以外でも当てはまる事は多いと思う.
投稿元:
レビューを見る
遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ。これぞ至言。チーム開発の難しさが痛いほど分かる本。もちろん真に理解するには経験が必要なのだろうけど理論を知れただけでも勉強になった。もし自分がプロジェクトを管理する立場になったら再読しよう。
投稿元:
レビューを見る
1975年(なんと僕の生まれる前)に出版されたソフトウェア開発の古典。
時間がなければ、16章以降から読めば良い。
ソフトウェア構築の作業を「本質的作業」「偶有的作業」に分け、ソフトウェア構築の困難さはその「本質的」な部分が複雑が故であるという。
ソフトウェア開発には銀の弾はないが
①購入できるものを構築しない
②プロトタイプの作成
③機能を追加しながら、システムを育成させる開発手法
④システムデザイナーの発掘、育成
を説く。
上記4点は2012年にしても成し遂げられておらず、現在でも十分に有効な提言だと考える。
①共通化、標準化がないことにより、度重なる同一機能の作成
②③相変わらずのフォーターフォールによる開発。もはや時代遅れ・・
④プロマネ至上主義、上流工程こそが価値があるといった考え、システムデザインを描ける人材の軽視、育成不足
投稿元:
レビューを見る
[読んだ理由]==================
「100人のプロが選んだソフトウェア開発の名著」にあった。工数に関する一般的な考え方が知りたかったので。「100人の~」からの引用:ブルックスの法則として知られる「遅れつつ有るソフトウェア開発プロジェクトにおいては、人の増員はかえって遅れをひどくするばかりである」というのがあります。これは延べ人数という概念からは相反します。しかし実情は、増員は後期を殆ど短縮しないということが知られています。
[読んだ後の感想]==============
思っていたより当たり前の内容が、思っていたより平易な文章で書かれていた印象。なので思っていたよりは読みやすい。特に印象的だったのは下記。
・遅れているプロジェクトへの要員追加は、更に遅らせるだけ。それは追加要員の教育やコミュニケーション、タスクの細分化?断片化?、システムテストの増加を招くため。
・コンセプトの完全性・統合が重要。その為にはデザイナーは1人or少数であるべき。
・アーキテクチャとインプリメンテーションとは切り離すべき。
・大規模ソフトは「構築」から「育成」の時代へ。
・偉大なマネージャと同等以上に、偉大なデザイナーは重要。
18章にそれまでの各章のまとめがあるので、まずそこから読んで、興味出た章だけ読んでみるのも良いかも。
[備忘録]======================
■第一章:タールの沼
■第二章:人月の神話
得意先の希望する納期に合わせた間違ったスケジューリングは、他のどのエンジニアリング分野よりも、ソフトウェアエンジニアリングで頻繁に行われている。定量分析てき手法に由来しない、データの裏付けも殆ど無い、主としてマネージャーの感だけの保証による見積もりを、力強く、もっともらしく、又仕事を危険にさらしてまでその妥当性を主張することは、極めて難しい。
必要不可欠なソフト受けあプロジェクトが予定より遅れていたら、どうするだろうか。当然、要員を増やすことだろう。しかし、仕事を変更せずに、要員の追加により元々の期日内で完成させようとすることは破滅的である。新しく追加された要員は、如何に優秀で、どれほど迅速に補充されようと、経験ある人からその仕事に関する教育・訓練を受けなければならない。(3名追加する場合)これに一ヶ月かかるとすると、三人月は元の見積もりにはなかった仕事に費やされてることに成る。しかも仕事は本来3つに分けられていた所を5つに分け直さなければならず、既に完了している仕事で無駄になるものも出てくる上、システムテストをより長くしなければならない。
遅れているソフトウェアプロジェクトへの要員追加は、更に遅らせるだけだ。
■第三章:外科手術チーム
経験を積んだプログラマグループの実績を測定した。其のグループの中だけでも、最高と最低の実績比率は生産性にして平均10:1、プログラム開発のスピードと量とではなんと5:1であった。要するに、年間2万ドルのプログラマが年間1万ドルのプログラマの10倍も生産性が高いということである。
効率性とコンセプトの完全性の観点から見れば、デザインと政策は少数精鋭で行���たい。だが、大規模なシステムでは、製品をタイムリーに発表できるように、できるだけ大量の要員を投入する方法が望ましい。この2つのニーズはどのようにして折り合いを付けることができるのだろうか。
■第四章:貴族政治、民主主義、そしてシステムデザイン
アーキテクチャは、インプリメンテーションとは注意深く区別される必要がある。
「アーキテクチャは何が起こるかを語るのに対し、インプリメンテーションは如何にして起こせるかを語るのだ」
アーキテクチャの労力をインプリメンテーションから切り離すことは、非常に大規模なプロジェクトでコンセプトの完全性を得るとても強力な方法である。
■第五章:セカンドシステム症候群
■第六章:命令を伝える
アーキテクトは、自分が記述した機能のインプリメンテーション方法の一つぐらいはいつでも示せるようでなければいけないが、インプリメンテーションそのものを指示しようとしてはならない。
インプリメンテーションが進むに連れて、仕様書が如何に的確であるとしても、アーキテクチャの解釈に関する数え切れない疑問が出てくる。
勝手に推察して先に進むのではなく、理非をわきまえている担当アーキテクトに電話して疑問を正すようにさせることは必要不可欠なことだ。
こういう時、アーキテクト側で電話の記録を残す仕組みを考えておくと良い。其の中にすべての質問と答を記録する。毎週、アーキテクトの記録を纏めて転載し、利用者と実現者に配る。この仕組はごく非公式のものだが、スピーディでしかも判りやすいものである。
■第七章:バベルの塔は、なぜ失敗に終わったか
■第八章:予告宣言する
■第九章:五ポンド袋に詰め込んだ十ポンド
■第十章:文書の前提
マネージャーの仕事は、計画を作成してそれを実現することだ。だが、文書化された計画のみが明確で伝達可能だ。
マネージャーの基本的な仕事は、全員を同じ方向へ進ませることなのだから、主要な日課は、意思決定ではなくてコミュニケーションを図ることなのだ。文書があれば、その負担が大いに軽減される。
■第十一章:一つは捨石にするつもりで
大抵のプロジェクトでは、最初に完成したシステムはほとんど使いものにならない。遅すぎたり、大きすぎたり、使いにくかったりする。酷いものになると、この3つ全てが当てはまっていることもある。
管理上の問題とは、パイロットシステムを作成して、それを廃棄するかどうかと言うことではない。当然そうすべきなのだ。
システムプログラムの作成は、エントロピーを減らす過程だから、本来準安定なものである。他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
■第十二章:切れ味の良い道具
■第十三章:全体と部分
最も有害で捉えにくいバグは、それぞれのコンポーネントを書く人々の間に存在する前提の不整合から発生するシステムのバグだ。
製品に対するコンセプトの完全性こそが、製品を使いやすくするばかりでなく、構築を容易にしてバグから逃れやすくもするのである。
■第十四章:破局を生み出すこと
人は、プロジェクトのスケジュールが破滅的に遅れていると訊くと、大変な不幸が続け様に起こったに違いないと想像する。しかし大抵の場合、そういう破滅的状況は竜巻のような突発的なものではなく、シロアリのようにじわじわ忍び寄ってくるものが原因である。スケジュールは、情け容赦なくではなく、ごくわずかずつ遅れてきたのだ。
マイルストーンの決定に関し、関係する規則は1つだけだ。それは、マイルストーンを具体的かつ明確で測定可能なイベントとして、ナイフの歯のような鋭さを持って定義しなければならないということである。
マイルストーンを鋭利な刃のように曖昧な所をなくすことは、上司が確かめられるようにすることより重要だ。人は、マイルストーンが自分も欺けないくらいえいろだと思えば、マイルストーンの進捗をごまかそうとはめったにしない。しかしマイルストーンがファジーなら、上司はしばしば報告を提出した本人とは異なる意味に解釈してしまう。悪い知らせを喜んで伝えようとするものなどもいないわけで、ごまかそうと言うつもりはなくても表現を和らげてしまいがちだ。
■第十五章:もう一つの顔
実際の所、フローチャートを書くことは、騒がれているほどには、実践されていない。プログラムを書き始める前に詳細なフローチャートを決まって書く熟練プログラマにお目にかかったことがない。
■第十六章:銀の弾などない 本質と偶有
ソフトウェア製作者が顧客のために行う最も重要な仕事は、製品の要件を繰り返し抽出し、洗練していくことだ。実際の所、顧客自身何を希望しているのかわかっていないものだ。カレラは通常、どんな質問に答えなくてはならないかを理解しておらず、指定しなければならない問題の詳細さについて考えたことなど殆ど無い。
ソフトウェアを構築ではなく、育成する:建築に例えることはもう有用さを失ってしまった。再び代えても良い時期である。
どのソフトウェアシステムも漸増的開発によって育成されるべきだ。つまり、そのシステムがたとえ適当なダミーサブプログラムのセットを呼び出すこと以外役立つことは何もしないとしても、先ず動くように作られるべきである。それから少しずつシステムを肉付けしていく。
私達にできる最も重要な努力は、偉大なデザイナーを育てる方法を開発することだと思っている。
ソフトウェアが医者なら、この挑戦を無視できないだろう。優秀なマネージャーは、数は少ないとしても、優秀なデザイナーよりは多いはずだ。偉大なデザイナーと偉大なマネージャーは、どちらも非常に稀な存在である。大抵の会社は、管理面で有望な人材を見つけて育成することには相当の時間を費やしている。だが、偉大なデザイナーの発見と育成について、同様の努力を費やしている会社を私は知らない。製品の卓越した努力は本質的に彼らに依存するのだが。
■第十七章:「銀の弾などない」再発射
■第十八章:「人月の神話」の命題 真か偽か
■第十九章:「人月の神話」から二十年を経て
投稿元:
レビューを見る
人と月が交換可能なのは多くの作業者の間で意思疎通を図らなくても、仕事が分担できる場合だけ、どう頑張ってもシステムプログラム開発には当てはまらない。
スケジュールの目安
計画1/3
コーディング1/6
単体結合1/4
システムテスト1/4
投稿元:
レビューを見る
システム開発の現場では、1人1人の動きとチームワークが成否を左右する。改めて、すごい開発ツールやマネジメント手法ではなく、人の育成や人同士の関係性が重要であることに気づかされた。