開発フェーズでプロジェクトマネージャーは何をするのか？「任せきり」で失敗しないための実務

要件定義と設計が終わり、いよいよ開発フェーズに入る。ここまで来ると、「あとはエンジニアが作ってくれるのを待つだけ」という気分になりがちです。

しかし実際には、開発フェーズでプロジェクトマネージャーの仕事がなくなることはありません。むしろ、やり方を間違えると、このフェーズこそがプロジェクトで最も危険な期間になります。

今回は、開発フェーズでPMが何をするのかを、私自身の失敗も交えながら整理していきます。

そもそもITプロジェクトの「開発」とは

ITプロジェクトにおける「開発」とは、プログラマーがコーディングを行い、プログラムを構築していく工程を指します。

PMBOKでの位置づけ

PMBOKの中では、開発は実行プロセスに該当します。

ただし注意しておきたいのは、PMBOKは世界のあらゆるプロジェクトに共通する知識をまとめたものなので、ITプロジェクト特有の開発の進め方までは書かれていないという点です。開発をどう進めるかについては、PMBOKとは別のところから知見を得る必要があります。

共通フレームでの位置づけ

日本のソフトウェア開発の共通言語である「共通フレーム」では、「開発」という言葉そのものは使われていません。該当するのは、ソフトウェア設計を適切に反映した実行可能なソフトウェアユニットを作り出すことを目的とする「ソフトウェア構築プロセス」です^[1]共通フレーム2013、160頁。。

共通フレームでは、このプロセスを終えたときに次の状態になっていることが求められます。

• 要件に対して検証基準が、すべてのソフトウェアユニットに定義されている
• 外部設計・内部設計によって定義されたソフトウェアユニットが作られている
• ソフトウェアユニットと、要件・外部設計・内部設計との間に、一貫性および追跡可能性が確立されている

定義した要件や設計の仕様に基づいたシステムが構築されていれば、開発は完了したと言えます。

なお開発の手法としては、ウォーターフォールモデルとアジャイル開発が代表的です。どちらを採るかによって、後述する進捗の見方や報告の周期も変わってきます。

開発フェーズに入ると、話す相手が変わる

ここからが本題です。開発フェーズに入ると、PMの仕事は「なくなる」のではなく「相手が変わる」というのが私の実感です。

要件定義や設計のフェーズでは、コミュニケーションの中心はクライアントでした。何を作るのかを決めるフェーズなので当然です。

ところが開発フェーズに入ると、クライアントとの定例は半分以下の回数になります。代わりに増えるのが、コーダーやプログラマーといった、実際に手を動かす人とのやり取りです。

クライアントに対しては、マイルストーンの達成を報告する

回数が減るとはいえ、クライアントへの報告がなくなるわけではありません。あらかじめマイルストーンとして決めた機能が、予定どおり作られているかを報告していきます。

開発チームに対しては、進捗を「見に行く」

一方、コーダーとの間では、必ずしも毎回ミーティングを開くわけではありません。私の場合は、バージョン管理ツールを共有してもらい、そこで進捗を確認して、遅延が発生していないかを見るようにしています。

会議を増やすことが目的ではなく、状況が分かる状態を作っておくことが目的です。手を動かしている人の時間を奪わずに把握できる方法があるなら、そちらのほうがお互いにとって健全だと思います。

私が新人時代にやらかした「報告日の朝」

「実装は任せておけばいい」と考えていた頃の話です。

私は開発の中身に立ち入らず、コーダーに任せきりにしていました。そして進捗報告の日の朝、こう告げられました。

「機能がまったく完成していません」

コーダーが途中で行き詰まっていたことに、私はまったく気づいていませんでした。もちろん、その日の報告は成立しません。

この経験から学んだのは、行き詰まりは自己申告されるとは限らない、ということです。作業している側からすれば「もう少しで解決できるかもしれない」と思っているうちに時間が過ぎていくことも、言い出しづらい空気があることもあります。だからこそ、こちらから状況が見える仕組みを作っておく必要があります。

開発チームとの距離感をどう取るか

とはいえ、細かく口を出せばいいという話でもありません。ここは多くのPMが悩むところだと思います。

技術面に明るくない場合、開発に踏み込みすぎると嫌われてしまうことがあります。
「大してわかりもしないのに、口だけ出すな」と言われてしまった経験が私にもあります。
さらに、技術的な判断に踏み込む場面では、相応の知識がなければ、指摘そのものが的外れになりかねません。

一方で、ほったらかしにしてうまくいったためしは、ほとんどありません。

もちろん、何も言わなくても期日までにチェックまで終えたものをきちんと出してくれる方はいます。ただ、私の経験ではそうした方は少数派です。多くの場合、進捗を見に行かなければ、状況は見えないままです。

私が意識しているのは、中身の作り方には口を出さないが、状況は必ず把握するという線引きです。「その実装はこうすべきだ」と技術的な指示を出すのではなく、「今どこまで進んでいるか」「詰まっているところはないか」を確認する。役割の境界をこう捉えると、お互いにやりやすくなるように思います。

品質のチェックは「動く状態」で見る

開発フェーズにおける品質の確認について、私が実務で守っていることが2つあります。

中間報告の場を設ける

「ここまでにこの機能は見せてください」という中間報告のポイントを、あらかじめマイルストーンとして設定しておきます。

そして、そこから外れてしまい、かつ改善の見込みが立たない場合は、人員の交代を含めた抜本的な対応が必要になると考えています。厳しい判断ですが、期日が動かせない以上、遅れが分かった時点で手を打たなければ、しわ寄せは後工程とチーム全体に向かいます。

必ず動く状態で確認する

もうひとつが、必ず動く状態で見せてもらうことです。

「コードはできています」と言われて安心していたら、いざ動かしてみるとバグで動かなかった、というのはよくある話です。悪意があるわけではなく、書き上げたところで力尽きて、動作確認まで手が回っていないというケースがほとんどです。

ですから、進捗の確認は画面や動作で行います。コードが書かれていることと、動くことは、まったく別の状態だと考えておいたほうがよいと思います。

なお、こうしたチェックの基準は、あらかじめ定めた品質マネジメント計画書に沿って行います。その場の思いつきで確認項目を増やすと、開発チームからの信頼を失います。

まとめ

開発フェーズは、プロジェクトマネージャーにとって「一段落する期間」ではありません。コミュニケーションの相手がクライアントから開発チームに移り、仕事の中身が変わるだけです。

やることを整理すると、次の3つに絞られます。

1. クライアントには、マイルストーンの達成状況を報告する
2. 開発チームの進捗は、こちらから見に行く（自己申告を待たない）
3. 品質は、必ず動く状態で確認する

そして、技術の中身には踏み込みすぎず、しかし状況の把握は手放さない。この距離感を保てるかどうかが、開発フェーズを乗り切れるかどうかの分かれ目になると感じています。