勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

錆びた弾丸

プロセスフローダイアグラム(PFD)について書かれた以下の記事を読んで思ったこと。銀の弾丸は売っていないけど、鉛の弾丸は自部門組織などから手に入れることはできる。ただし、それが錆びた弾丸かどうかは自分でチェックしないといけない。

PFDが明確に指摘することは、開発プロセスは設計すべき対象であり、各プロジェクトの現状に合うように柔軟であるべきことだ。

日本のSIが持つ標準プロセスは、WF型開発を基本としていて、業務標準化の名のもとに、「プロセスが固定」されている。
マーケットの変化によって、製品開発の内容が変わってしまえば、標準プロセスを一斉に適用するのはすごくリスクがある。
PFD(プロセスフローダイアグラム)で開発プロセスを設計する: プログラマの思索

ジャンク屋の野郎、サビ弾よこしやがって――
ポルコ・ロッソ

ソフトウェア開発においては、以前にうまくいった方法が必ずしも目の前のプロジェクトで有効かどうかはわからない。だから、毎回必ず「この方法でうまくいくか」について考察しなければならないし、やり方を設計しなおさなければいけない。他人から受け取った弾丸は、いうなれば錆びているかもしれないのだと思う。

アジャイルと規律」の「鉛の弾丸」の話を再び引用する。

アジャイル手法も計画駆動型手法も、フレッド・ブルックスが言うところのソフトウェア工学の「狼男」を退治するための「銀の弾丸」の方法論とはなりえない。(中略)アジャイルや計画駆動型のアプローチはどちらも「鉛の弾丸」程度にはなれるかもしれない。(中略)スピードの一段の加速が、次のような仮説が誤りであったことを浮き彫りにしつつある。「今年やってきた狼(ソフトウェア)はこの鉛の弾丸(ソフトウェア技法)でやっつけることができました。来年奴らの進化した子孫が現れたとしてもまた同じ弾丸でやっつけることができます」
アジャイルと規律 ?ソフトウエア開発を成功させる2つの鍵のバランス?

冒頭記事でも紹介されているPFDは、プロジェクトの進め方を設計する際にはとても有効である。綺麗に清書してWBSと一対一になるように作成するのは骨だけれども、まずは手元で構想する際にざっくり書いてみればよいと思う。もしくは、リスクが高い作業プロセスに限ってでも書いていけばいい(自分はそうしている)。