選択と集中で開発プロジェクトを成功に導く

仕様の変更と開発プロジェクトの遅延

昔から仕様を追加/変更することやプロジェクトの遅延はよくある話でした。

しかし、最近になって悪意なく意図的にこれを起こしている人たちがいることに気がつきました。

それは、アジャイル開発と銘打って、プロジェクト推進をし始める勘違いばかりのプロジェクトオーナーたちです。

この人たちが勘違いしたこと

マイルストーンを決めない

ウォーターフォール開発であれば、納期からの逆算も踏まえて各ステップの期日をかなり緻密に組み立てることができます。

しかし、勘違いアジャイルの場合は定期レビューもせず、マイルストーンの期日を「なるはや」として設定しているケースがあります。

この「なるはや」という曖昧なワードは、そのタスクのデッドエンドがいつかわからずに走り続けることを表し、ある程度走り終わったあとに振り返ってみると残タスクに対して期間が短すぎるという状況に陥ります。

そして、プロジェクトメンバーは「ようやく気がついたかFu○k」という気持ちになっています。

仕様変更の対応期間が極端に短い

仕様追加や変更の規模によっては半日や1日のペースで修正可能です。

しかし、「やっぱり顧客管理も必要だね。顧客管理も修正期間（2日）でできるようにしておいて」みたいなレベルで言われると、CRUDって知っていますか、UI設計って知っていますか、と言いたくなって思わず手がグーになってしまいます。*1

そもそも計画時に何でこんなに短くてOKだったのか疑問を持ちます。

仕様を変えてもQCDの要求が変わらない

勘違いプロジェクトオーナーはアジャイルが万能かのように思い、開発中にどんどんアイディアや改善を出して、それをすべて取り込もうとします。

プロジェクトマネージャーとメンバーたちはできる限り対応できるように工夫をしますが、現実として上手くいくことは少ないです。

そこで、なんとか品質（Q）を担保するために、期間（D）を伸ばす交渉をしますが、勘違いしているプロジェクトオーナーは「アジャイルでやるって言ったのに何言ってんの？」という目で見てくるわけです。

当然、期間（D）を伸ばすということはコスト（C）が付帯されてくるので、許可が下りることは難しいです。

また、お客様に納品するようなプロジェクトであればなおさらで、期間（D）は一歩も譲れない状況だったりします。

そこで、プロジェクトリーダー、メンバーはデスマーチに突入して無理やり仕様の追加や変更をねじ込み、期間（D）も守れず品質（Q）も低いという最悪の結果で着地する姿を見てきました。

選択と集中をせよ

プロジェクトには必ず目的があるはずです。

プロジェクトオーナーは何が達成される必要があるか、その主軸に「集中」し、仕様などを決めていく「選択」の必要があります。

これを守らずに目的以外のものまで手を出して発散してしまうと、本来の目的の達成が中途半端な状況に陥るなど、最悪の場合は本末転倒となりかねません。

また、要件が固まっていない開発プロジェクトはQCDのいずれかに問題が出るので、短いスパンで状況のチェックと見直しを入れる前提で進める必要があります。

いずれにせよ、経験や勘だけではなく、現場の人の意見を取り入れて手堅く開発プロジェクトを推進していただきたいものです。

*1:このグーになった手を相手にぶつけると犯罪です。