ソフトウェア工程管理技法 の商品レビュー

高根宏士【著】

2012/02/07

著者に初めてお会いした時に、ものごとに対する切り込み方に流石だと思いました。

1　各作業の定義
　新しいメンバであるためプロジェクトの基本的な用語を知らない
2　作業の終了基準が不明確
3　各作業のつながりが曖昧
4　各作業に担当が割り当てられていない。または曖昧。
5　各作業担当の工期が適当か（担当の能力との相関）どうか確認
6　担当作業負荷、作業の重なり具合
7　環境（作業場所、支援システム、ツールなど）についての見通し

計画について，これだけ大事なことをすらすらと書かれているところが実務者らしい。

計画を，何のために書くかが分かっているか，わかっていないかの境界が分かるかも。

2010/02/13

この本は、私の、本当の意味での、職業プログラマとしての「出発点」となった本である。

私が、まだプログラマとして駆け出しだった頃、とても酷いデスマーチがあった。毎日が納期、「お前の会社潰したろか！」と取引先から言われ、何も言い返すことが出来ず、ただ愛想笑いをするしかなく、ただただ、アテも無く、時間が過ぎて自己満足になるまで、意味もなく頑張るしかなく、若かったので肉体的には大丈夫だったが、精神的に疲弊し、「自分は、ソフトの開発なんて出来ないんじゃないか？」と自信を失っていた時期がある。

自信を無くし、取引先からの厳しいプレッシャーと目に見える不信感、リーダである上司は、過労で入院を余儀なくされ、私は上司の引継をする事になったが、口だけの未熟な人間に何が出来ようか。

技術はあるつもりだった。が、結局は、取引先から強い不信を受けて、私の新人１年目は過ぎた。

なぜ、ソフト開発がうまく行かないのか。何がいけないのか。自問自答する中で、この本を見つけた。1992年か1993年位だったと思う。

この本を読んで、まず安心したのは、表現は適切ではないかも知れないが、「プロジェクト崩れ」は、割合起こり得る事なのだと知って、安心したのが本音である。コンピュータがどんどん社会に浸透する中で、自分だけが、ソフト開発出来ないんじゃないかと思っていた時に、コンピュータがどんどん浸透する裏では、「崩れたプロジェクト」があるのを知り、「自分だけじゃないんだ。。。」と、救われた気持ちになった。

この本には、

ここではプロジェクト崩れの定義として

「プロジェクト終了の見通しがその時点では立たなくなったプロジェクト」

と定義する。

と言う下りがある。これは、まさに私が経験した「プロジェクト崩れ」そのものである。１ヶ月遅れる「見込み」位では、まだ崩れていない。単に１ヶ月ズレただけである。

本当に恐いのは、「この開発が、いつ終わるか分からない」状態に入った時が一番恐い。目標を見失ったプロジェクトは、本当に危険である。

私は、プロジェクトのリーダとして、常に意識してきたのは、「メンバーにゴールを見せてあるのがリーダの役割」と言う事を常に意識してきた。技術があればリーダになれるかと言うと、それは明らかに違う。

見えるゴールがあれば、そこに向かって走れば良い。しかし、ゴールが見えない、またはゴールへの道のりが迷宮の様になっていれば、仮にゴールにたどり着いても、メンバーは疲弊しきり、もうついて来てはくれないだろう。

また、この本には、「崩れたプロジェクト」だけでなく、「復活するプロジェクト」についての記述もある。

良く言われることだが、人間は「失敗」から多くの事を学ぶ。「成功」からは、実はあまり多くを学ぶ事は出来ない。

外見的には「失敗」と見なされたプロジェクトがあっても、そこから多くを学び取り、次に活かせば、それは「復活するプロジェクト」と言える。ソフトウェア工程管理について書かれた本は色々あるが、この点まで言及している本は、どれくらいあるのだろうか。

最近の本は、工程管理のテクニックを紹介する事が多い様に見受けるが、「工程管理」は、テクニックだけの問題ではない。その事を、この本では実によく述べている。

この本は、第1版が1991年と、古い部類の本であるのに、現在でも十分に通用する。

逆を言えば、技術は進歩しても、「人間」はそんなに極端に進歩する訳ではないのが良く分かる。

この本は、探してでも手に入れるべき本である。