こんにちは、Hです。
先日、会社の採用面談に参加したのですが、その際この「プロマネ日誌」読んで
参考になりましたとご意見をいただきました。
多少リップサービスがあるかなと思いつつ、そういった言葉をいただけることは励みになります。
私自身もプロフェッショナルなプロマネとは程遠く、日々試行錯誤をしながら
またスケジュールとプレッシャーに追われながらシステム開発プロジェクトを
率いています。
読んでいただいている方々からのフィードバックを受けながら
教科書にはこう書いてあるけど、実際のところはどうなの？みたいな話を
続けていきたいと思います。
今日は実際にあった話でプロジェクトの見通しが全く立たずに
時間だけが過ぎていく、、、そんなお話をしたいと思います。
要件がまとまらない
皆さんも開発プロジェクトで要件が決まらずに苦労するといったことは多々あると思います。
要件定義のフェーズは終わり、設計書を記載しているのにあとから要件変更が入ってきて
それをどんどん取り込んでいるうちにどの状態が「正」なのかが分からなくなってしまいます。
また課題票だけがどんどんたまっていき、その課題票の内容が設計書に反映されたかどうかも
チェックできずに気づいたら埋もれている、、そんなこともあると思います。
機能数が少なければ、メンバー間のコミュニケーションでカバーしていけばよいと思います。
関係者も少なく、5名以内のチームで進めることができるのであれば実施できると思います。
しかしながら関係者が10名以上になったらどうでしょうか？
ある人には伝わっているけど、それがチーム全体には伝わっていない。
またチーム全体に伝えるために毎日1時間以上の夕会を開いて共有しなければいけない。
そして残業が続いて、体も疲れていき、最終的にはモチベーションの維持が難しくなっていく。
そんな流れ方が多くないでしょうか？
私が取った方法
私が担当しているプロジェクトもそうでした。
とっくに要件定義のフェーズは終わっているのに、いまだにレビューのたびに
要求が発生したり、機能漏れが発覚したり、業務上の考慮が漏れていたりと
日々レビュー管理票が更新されていき、その更新と対応だけで一日が終わる状態でした。
そして刻々と迫るスケジュールと次の工程の準備。
こんな時みなさんだったらどうしますか？
取れる手段は1つだけでなくいくつもあると思います。
もっと頑張って何とかすべての作業を実施する、スケジュールを変更してそれを承認いただく、
要件を無理やり区切って、それ以上は受け付けなくする等々。
どれが正解というのはないと思います。
その状況によってとる手段は変わるのだと思います。
私が取った手段は「作業を止めること」でした。
要件のレビュー、ヒアリング、設計書の作成、実装、すべて止めました。
そしてその日は反映していないドキュメントの最新化と
決まっていないことは何かを洗い出すことに専念してもらいました。
決まっていないことは顧客とも共有して、タスクに分割してスケジュール化しました。
分割したタスクはメンバー全員で話して、担当を決めました。
仕切りなおす意味
なぜその手段を取ったのか？
リリース時期だけ見たら、本当は先に進めたくて仕方がないです。
でもリリース時期だけを見て、足元がぐらついたまま開発を進めたら
プロジェクトが壊れてしまうからです。
リリース時期に間に合わすのは厳しいかもしれない、
でも何をする必要があるのか、関係者間で洗い出し、
すべてを共有する必要があると感じました。
そうしないとこのプロジェクトは不幸な結末を迎える、
そんな思いでした。
社会的に責任あるシステムを担当している今、この決断が正しいかどうかは
分かりませんが、少なくとも実際に利用される業務担当者の方や
一緒に開発を進める顧客、メンバーと終わった時に
大変だけどやってよかった、そんなプロジェクトにしていきたいと思います。
