プロジェクト管理心得ノート～XPやアジャイルを言う前に

　最近のアジャイル開発やＸＰの議論を聞くと、原理原則をいかに忠実に実行するか、というよりも、現実のプロジェクトにいかにカスタマイズして結果を出すか、という地に足を付けた議論が多くなっている。

　そんな中で、アジャイル開発の導入に否定的な人たちやそのプロジェクトでは、オブジェクト指向の技術に慣れていないのも原因の一つだろうが、それ以前に、プロジェクトの体制や開発プロセスの進め方というSIerとしてもっと基本的な部分でレベルが低いのではないか、という疑問を最近持っている。

　ふと下記の本を手にした。

　本の内容は、プロジェクトが失敗する事例からその原因と対策を説明している。
　ざっくり書いてみる。

１・プロジェクトの体制そのものに無理がある例：

・プロジェクトリーダーにその資質がない。
・プロジェクトリーダーを補佐する人がいない。
・チームにキーマン(牽引役)がいない。
・スケジュール管理ができていない。
・開発チームに問題児がいる。(顧客に問題児がいる場合もある)
　　そう言えば、ある人は、段取りの下手な開発者を嫌っていた。
　　そういう人がいると彼一人だけの問題ではなく、周りの雰囲気まで悪くなるから、と言っていた。

２・仕様調整で問題が出てくる

・システム構築の実現可能性の担保はどこで取るか？という観点がない設計。
　　枝葉の機能に囚われている、とか、パフォーマンスを考えていない、とか。
　
・仕様＝費用の認識がない。
　　仕様確定のコミットメントに、双方の認識のずれがある。

・顧客とのコミュニケーションギャップ。
　　顧客は自分の業務に忙しくて、業務のヒアリングが中途半端になってしまう。
　　　特にデータ移行、システム切り替えで問題が噴き出す。

　　あるいは、ヒアリング時に顧客の要望を明確に断らなかったために信頼関係に支障をきたす。

　現場を経験したことがある人なら、その事例はあったな、と頷くのではなかろうか？
　SEに技術力はあって当然で、仕様洗い出し・設計プロセスで噴き出した問題点、顧客・元請・下請の3社の利害関係者の調整をいかに制御して、問題を解決して、ゴールまで進めていくか、という政治力の方を求められている。

　XPやアジャイル開発は、上記の問題点に対する対策をいくつか用意している。
　ファシリテーション、イテレーション、計画ゲーム、Simple Is Bestという設計方針、など。
　それらのメソトロジーを使って、顧客・プロジェクトリーダーと掛け合って合意をもらって初めてアジャイル開発を導入できてチームが回転する。
　最近の事例を聞くと、そういう話題を聞く。
　対症療法の一つとして、アジャイル開発を考えた方がいいのではなかろうか？