読書日記

　深沢隆司『デスマーチよ！さようなら！』（技術評論社, 2004）を読了。
　この種の情報システム開発方法論ものに万能の妙薬（あるいは銀の弾丸）はない、というのが定説だとはわかっちゃいるが、ついつい、なるほど、ふむふむ、などといいつつ読んでしまう。
　特にIT業界の現状として、改善すべきなのはプログラミング技術ではなく、マネジメントである、ということを（当たり前といえば当たり前かもしれないけれど）きっちり、主張しているのがすばらしい。と同時に、現場におけるモチベーションや、コミュニケーションの問題などを論じた部分は、システム開発という題材を通じて、一般的なマネジメントを論じたものとしても読める。プロジェクト・マネージャーの仕事は、実作業者の重荷を排除することだ、という言葉が、胸に突き刺さったり。部下に残業させておいて、こんなものを書いている私はいったい……。
　後半は、より詳細な開発手法（「スペックパターン開発プロセス」と呼ばれている）についての解説になるので、私のような発注側の立場の人間には少々実感が湧いてこない面もあり。それにしても、著者の主張する議事録の作り方はすごい。会議に議事録作成のためのPCと、会議参加者が議事録をその場で読むための複数のモニターを持ち込んで、その場で議事録を作成し、（表現なども含めて）出席者全員で内容を確認してしまう、ということを徹底すべきと主張している。後々、言った言わないの論争にしないために、個々の発言は、ICレコーダーで録音して、ファイルとして残す、という方法も併用。議事録は会議における決定・合意事項を確認するための記録であるべき、というのはその通りだと思うが、それをここまで徹底してやるべきだ、といわれると、ちょっと真似できない、という感じではある。といいつつ、確かに、ここまでやれば、後でもめることはないかもしれない。ちょっと真似してみたい誘惑に駆られるなあ。
　全体として、システム開発の過程で、発注側が仕様を確定できないことも含めて、開発側（受注側）の問題として捉える、という、ある意味で、私のような発注側の人間にとってはありがたい組立てになっている。このために、発注側のスキルが低過ぎる（私自身を含めて）という問題は、見えにくくなってしまうきらいもあるような。現実には、発注側のための開発方法論の方が、より必要とされているのでは、というか、ほしい。
　そういう意味では、ややフラストレーションがたまらないでもないが、マネージする側に立ったときに、どう行動すべきか、という意味では、勉強になった気がする。実際にできるかどうかは、また別の話だけど。