プロジェクト管理 |
作成日：2000-02-18 最終更新日： |
このページでは、異例だが口上を述べる。
私はかつてプロジェクトのリーダーを受け持ったことがあった。 それはそれはひどいリーダーで、自分だったらこんな奴のもとで働きたくないというほどだった。 プロジェクトが終了し、後継のプロジェクトが発足した。 当然のことながら私は後継プロジェクトを離れた。
現在はスタッフ部門でプロジェクトの進め方について客観的に観察できる立場にある。 そんなことでここをやっと書く気になった。
なお、他のページ、たとえばソフトウェア品質や、プログラミングにも、 関連する本を紹介している。
ソフトウェアのプロジェクトマネージャーで、 この本を知らない者はモグリだというほどの有名な本。 「人を2倍に増やせば工期が1/2に短縮される」誤りなど、すでに明らかになっている。
これまた有名な本。なんといっても表題が言い得て妙である。
デスマーチの定義が硬いので驚くが、厳密な定義をしておけば、
先に議論しやすくなるということなのだろう。
この本では、軸となっていることば、triage
（トリアージュ）を中心に、話題が展開する。
（読んでそうとうたつので忘れてしまいました）
読んでそうとうたつので忘れてしまった。 そこでひさしぶりに本書を取り出してちらちら見てみたら、作者ワインバーグが作った次の格言があった。
「プログラミングは、チェスや女性や音楽にも劣らぬほど、男を幸福にする。」
チェスを将棋に置き換えれば、私にはあてはまる。ただ女性はどうかな。(2001-07-15)
表題になっている話のほか、エレベーターの問題を解決する話、暗号を解く話など、 本当にあってもいいようだし、またあるとは思えないような気もするしでとにかく楽しい。 私が好きな話は、大学キャンパスの駐車場問題を解決する話である。しかし、この本でも触れられている通り、 大多数の当事者は、駐車場問題を解決すべき問題と認識しているのだろうな。残念なことだ。
まじめにこの本を見てプロジェクトの見積をしようとしたのだが、 見積に必要な各種の資料、条件があまりにも不足しているので困ってしまった。 たとえば、ファンクションポイント法というのがありますね。 あの見積に当たって見積もるべき基礎資料がないのだ。
受験対策本を並べるのは気が引ける。しかし、こういう気が引けることをするからには、合格したいと思うのだ。 さて、この本はプロジェクトマネージャーを受けるにあたり、最初に買った本である。 今だからいうが、プロジェクトマネージャーとしての心がまえなど、なかった。 プログラマーとして留まりたい、そんな思いがあった。 しかし、メンバーをまとめる役目を引き受けざるを得なくなった。 それはつらかった。
この本でも、別の本でも、まじめに勉強すればよかったのだろう。 また、上司に願い出て、プロジェクトマネージャーたる 教育を受けさせてくれと頼んでみるべきだったのだろう。 しかし私は、どちらもしなかった。 ひたすら、プログラマとしての自分にこだわった。結果は、デスマーチであった。 見事にヨードンの定義にあてはまるデスマーチだった。
ぐちはまだ続く。しかし、それは試験の勉強を通して解消しよう。 一つ、役にたったのは、p.316から322で述べられている、変更依頼票の書式だった。これを叩き台にして、 なんだかんだいわれながらバグ管理データベースを作った。これは現リーダーに変わった今でも使われている。
'98年版は前期の本から一年後に買った。でも、まじめに勉強しなかったなあ。 2000年半は今年（2000年）に買った。しかし、すべてを勉強したわけではない。
背水の陣で買った本だが、どこまで活用できるかな。 教科書的に知りたい、と思ったことは教科書的には出ている。 たとえば、「開発方針」を決めよ、と言われたとき、私は途方に暮れた。で、何をきめればよいかというと、 この本を見てみる。すると「プロジェクト方針」の項目、という項で、以下が挙げられている。
この本は前著（アンチパターン）と合わせて、プロジェクトのアンチパターンとしても読むことができる。 事例のところを問答ふうに読めば、 そのままプロジェクトマネージャーの午後 I の問題となりそうだ。 ちなみに、「アンチパターン」は買ったはずなのに見つからない。 引越しのときに捨てたのかもしれない。
菅野先生にはソフトウェアに関する著作が数多くある。しかし、 先生の著作を手に入れたのは今回この本が初めてだ。 なかなか過激な、しかし真実に満ちた言説があちこちにちりばめられている。 過激な例として、この本に最後にある「リーダとして不適格な者の使い道」というおまけをあげておこう。
さて、一読した後の感想は、「俺はプロジェクト・リーダとして不適格だ」ということだった。 なぜか。いくつか俺にあてはまることがあるからだ。
その他、挙げれば挙げるほど、俺の資質ではないもの、俺に向いていない性格が、 プロジェクト・リーダにふさわしい、 あるいはプロジェクト・リーダとして身に付けなければならないものとしてあちことに出てくる。 著者は有能なプロジェクト・リーダであり、現在もそうなのであろう。その証拠に、自身が「非難を恐れない」 ことを公言しているからである。そこで、俺は非難というほどのことでもない、二三気付いた点を書き付ける。 この列挙は「重箱の隅をつつく」類いのものであるから、俺がリーダに向いていない証拠にもなる。
2000年始めに注目された、プロジェクトの品質に関する指針である。概略だけ、そっと示しておこう。
ISO 10006 という、プロジェクトマネジメントに関する品質の指針は、エンジニアリング業界、建設業界を
中心に現在注目を集めている。そんなわけで、とりまとめはエンジニアリングの団体である。
解説の中に、国内業界の動向なる章がある。ここにある業界はエンジニアリング業界と建設業界だけであり、
ソフトウェア産業は存在しないのだ。
別の用語解説の章で、かろうじてソフトウェア産業に関する言及があるにすぎない。そこは、
configuration management を、ソフトウェアでは構成管理と訳す
とある箇所だ
そういえば、先日飲んだある方は、ソフトウェアをやる人など、
人間扱いされなかったといっていたなあ。
この無色透明なプロジェクトマネジメントの指針に対して、ソフトウェアの目から見た、 際どい本を、誰か書いてくれないかなと私は期待している。
ソフトウェアの二者間取引に使われることを目的として作った、御墨付きを与える本。 しかし、今の世の中、この本をまじめに使って取引をしている会社など、いるのだろうか。 ひょっとしたら、IPA から業務依託を受ける会社は、これに従わないといけないのだろうか。 それにしても、業務を依託し使う側を取得者ということ、 依頼され納める側を供給者というのだ。 なかなかこんがらがりそうだ。
そういえば、どこかの組織が共通フレームの改定を進めるという話だった。 しかし、2007年になって、まだ実現できていない。
と書いたら、共通フレーム 2007 が登場した(2013-01-22)。
さらにその後、共通フレーム 2013 が刊行されている(2014-05-05)。
まりんきょ学問所 ＞ コンピュータの部屋 ＞ コンピュータの本 ＞ プロジェクト
