人月の神話 の商品レビュー

フレデリック・P.ブルックスJr.【著】,滝沢徹,牧野祐子,富澤昇【訳】

2013/04/01

システム開発の現場では、１人１人の動きとチームワークが成否を左右する。改めて、すごい開発ツールやマネジメント手法ではなく、人の育成や人同士の関係性が重要であることに気づかされた。

2018/10/20

業界人なら読んでて当然と言われる必読本を、今更ながら読了。初出が1975年なだけあって、挙げられる例が古すぎて理解し難い部分も多いが、立ち向かう問題はプログラミング製品開発に伴う本質的な困難であるため、今だ解決が見られない現状においては十二分に得られることはある。
本論は『炎上プロジェクトに人を突っ込んでもむしろ悪化する』という箇所ではなく、『抽象的なソフトウェア実体を構成する複雑な概念構造体を作り上げる』というソフトウェア構築の根本的な問題と組織の話。現代、というか自分が経験してきた各プロジェクトにおいて、そのまま当てはまる論とそうでない部分があるが、それについて考えることで、何が変わって、何が変わらなくて、今どうすべきなのか、必要な施策が透けて見える。
愚者は経験に学び、賢者は歴史に学ぶ。本書によって、場当たり的で科学のない、体育会系なプロジェクトが減ることを、切に願う。

2013/03/15

人と月が交換可能なのは多くの作業者の間で意思疎通を図らなくても、仕事が分担できる場合だけ、どう頑張ってもシステムプログラム開発には当てはまらない。
スケジュールの目安
計画1/3
コーディング1/6
単体結合1/4
システムテスト1/4

2013/01/08

数十年前に書かれたものだが現在でも名が上がるほどの本，
ということで一回読んでみた．
システムの開発に関して，開発を遅らせる原因やチームを作る難しさについて記してある．現在の自分の立場ではあまりイメージできないところではあるが将来そのような職に就くことがあればもう一度この本を理解したいと思う．ソフトウェア開発以外でも当てはまる事は多いと思う．

2012/11/29

1975年（なんと僕の生まれる前）に出版されたソフトウェア開発の古典。
時間がなければ、16章以降から読めば良い。

ソフトウェア構築の作業を「本質的作業」「偶有的作業」に分け、ソフトウェア構築の困難さはその「本質的」な部分が複雑が故であるという。
ソフトウェア開発には銀の弾はないが
①購入できるものを構築しない
②プロトタイプの作成
③機能を追加しながら、システムを育成させる開発手法
④システムデザイナーの発掘、育成
を説く。

上記4点は2012年にしても成し遂げられておらず、現在でも十分に有効な提言だと考える。
①共通化、標準化がないことにより、度重なる同一機能の作成
②③相変わらずのフォーターフォールによる開発。もはや時代遅れ・・
④プロマネ至上主義、上流工程こそが価値があるといった考え、システムデザインを描ける人材の軽視、育成不足

2012/07/28

遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ。これぞ至言。チーム開発の難しさが痛いほど分かる本。もちろん真に理解するには経験が必要なのだろうけど理論を知れただけでも勉強になった。もし自分がプロジェクトを管理する立場になったら再読しよう。

2012/05/26

大規模ソフトウェア開発に関する古典とも言える書。かなり古い言葉も出てくるが、本質的な状況は変わっていない気がする。銀の弾はないということか。

2012/05/02

レビューはブログにて
http://ameblo.jp/w92-3/entry-11236629979.html

2012/03/07

要するに、プロジェクト遂行とは大規模並列計算と同じなのだと。
分割可能なタスクは並列演算、ベクトル演算可能。
アムダールの法則に従えば、並列化率を上げれば、作業効率は上がる。
基本的に分業できる部分は分業したほうがいい。
しかし、実際の並列計算において意外にコストがかかるのは、個々のノードの演算ではなくて、ノード間の通信時間、オーバーヘッド。
大規模演算を行うために並列数を増やせば、通信コストは増す。
まして人間ではコンピュータ以上に通信のコストは高い。
通信のプロトコルが正確とは限らないから、エラーが出まくりの、オーバヘッドが膨大なのである。
したがって、安易に並列数を増やすより、各々のノードの実行効率を上げるほうが効果的。
SIerやエンジニアリング業者の個人の仕事量が多いのは、そのためである。
仕事が多いことが腑に落ちた。
そして、一人で大量のタスクをこなせる高機能CPUが必要となる。
「偉大な旋盤工は、平均的な旋盤工の数倍の給料を支払う価値があります。しかし、ソフトウェアコードの偉大な書き手は平均的な書き手の一万倍の価値があるのです。」
というゲイツの言葉が思い出される。
どうしても並列数を増やしたければ、プログラミング（組織を作る）の際にノード間の通信量をなるべく少なくするように、アルゴリズムを組む必要がある。
そうすれば実行速度の低下も抑えられる。
プロジェクトマネージャーの機能の一つが並列コンピューティングのプログラマ。
少ないCPU間の通信で同じ演算結果を得られるように工夫しなければならない。

あと、インターフェースとかオペレータとかの役割もあるのだろう。

オペレーションも命令系統が機能するような組織を編成するべし。
いくつかの案が提案されていた。

また、プロジェクトの成果物のコンセプトを一貫したものにするためには、コンセプトの決定権を集約しなけらばならない。
コンセプトを決める人は一人。
設計者はコンセプトは触らない。
いかにコンセプトを実現するかという部分に裁量を持ち、自己主張せねばならない。

2011/10/18

36年前に上梓された本とは思えない。
それぐらい含蓄のある名著。
逆に言うと、この36年間、ソフトウェアエンジニアリングの世界は何をやっていたんだという軽い絶望感を味わえる本。

本文中にもあったと思うけど、ソフトウェア開発ってのは大規模になればなるほどステークホルダーとして多くの人間が関係し、人と人とのトランザクションが発生する。
そういった意味で、エンジニアリングとはいうものの、多分に社会科学的な要素を含むんだろうな。
コンピュータサイエンスみたいな自然科学寄りの分野の進歩と比較しても仕方ないのかも。

だからこそ、ソフトウェア開発に携わる人間としては、ソフトウェアエンジニアリングの技術的側面だけでなく、心理学であったり社会学であったりマーケティングであったり組織論であったりEQであったりリーダーシップであったり、そういったもやっとしたウェットな領域もカバーしないといけないんだなと。
これからの道筋が少し見えた気がします。