今回、社内案件で初めてPMを担当しました。

結果として、開発スケジュール内に収まり、受入試験に出すところまで進めることができました。一方で、プロジェクトの進め方については改善すべき点が多くありました。

当初は、それぞれを個別の問題として捉えていました。

  • GE（Gemini Enterprise）に関する技術知識が不足していた
  • MTGのファシリテーションがうまくできなかった
  • 要件定義書の合意を十分に取れないまま進めた
  • 追加要件への対応が後手になった
  • メンバーに明確なタスクを渡せなかった
  • メンバーが能動的に動ける状態を作れなかった

しかし、プロジェクト全体を振り返ると、これらには共通する原因があったように思います。

それは、不確実性や曖昧さを十分に整理しないまま、次の工程へ進めてしまったことです。

未知の技術領域に対して、完成イメージを持てないまま進めた

今回の案件では、Gemini Enterpriseを活用した提案支援エージェントを開発しました。

顧客となる社内部署は、アイデアソンの段階から業務フローや課題を整理してくれていました。そのため、解決したい課題自体は比較的早い段階で把握できました。

一方で、私自身がGEを使った開発経験を持っていませんでした。

そのため、

「顧客がやりたいことは分かるが、それを最終的にどのようなシステムとして実現するのか」

という部分について、明確な完成イメージを持てていませんでした。

例えば、

  • GEで何が実現できるのか
  • どこまで標準機能で対応できるのか
  • どこからカスタム開発が必要になるのか
  • どの技術を採用するのか
  • 技術的に難しいポイントはどこなのか

といった点が整理できていませんでした。

その結果、次に何を検討すべきか、誰に何を調査してもらうべきかについても判断が難しくなりました。

当時は「GEについてもっと勉強していればよかった」と考えていました。

現在でも、技術的な知識を持つこと自体は重要だと考えています。

ただし、今回の経験から、PMが全ての技術を実装レベルまで理解する必要があるとは限らないとも考えるようになりました。

技術は日々変化するため、PMが全ての技術を深く習得することには限界があります。

重要なのは、技術を知らない状態でも、

  • どこが不確実なのか
  • 何を調査する必要があるのか
  • 技術検証が必要なのか
  • PoCを先に実施すべきなのか

を判断できることだと思います。

今回の場合、技術的な不確実性が大きいにもかかわらず、それを前提としたプロジェクト計画を作れていませんでした。

ウォーターフォールで進める前提自体を見直せなかった

当初は、一般的な開発プロセスに沿ってウォーターフォール型で進めようとしていました。

要件定義を行い、設計を行い、その後に実装するという進め方です。

しかし、今回の案件では、そもそも完成イメージや技術的な実現方法が十分に固まっていませんでした。

そのため、要件定義から設計へ進もうとしても、設計すべき内容が明確になりませんでした。

途中から、実際に動くものを作り、触りながら確認するというアジャイルに近い進め方へ変更しました。

結果として、この進め方の方が案件には適していました。

一方で、途中で開発プロセスを変更したことで、実装開始にも遅れが発生しました。

今振り返ると、問題は「アジャイルの経験がなかったからウォーターフォールを選んだ」ことだけではありません。

そもそも、

「この案件はウォーターフォールで計画できるほど不確実性が低いのか」

という判断ができていませんでした。

未知の技術領域で、完成イメージも十分に固まっていないのであれば、最初から技術検証やPoCを計画に組み込む方法もありました。

アイデアソンで得た情報を、要件に落とし込むための深掘りが不足していた

要件定義の最初にアイデアソンを実施しました。

顧客となる部署では、業務フローや課題を事前に整理してくれていました。

アイデアソンでは時間が余ったため、その時点では必要な情報はある程度揃ったと考えていました。

しかし、後から振り返ると、業務フローの一部を十分に分解できていませんでした。

今回エージェント化しようとしていたのは、提案業務の中の「リサーチ」という工程でした。

しかし、一言でリサーチと言っても、

  • 何を目的としたリサーチなのか
  • どのような種類があるのか
  • 目的ごとにどのデータソースを使うのか
  • どのような情報を取得できればよいのか
  • その情報を提案活動のどこで利用するのか

といった点を整理する必要がありました。

当時はそこまで細分化できていませんでした。

ただ、ここについては「アイデアソンの場で全て聞き出すべきだった」と考えるのも少し違います。

当時の自分には、どこまで細分化すれば十分なのかを判断するだけの経験がなかったからです。

そのため、今振り返ると、アイデアソン終了後に社内で一度、

「今回のMTGで何が分かったのか」

「まだ何が分かっていないのか」

「次回の顧客MTGで何を確認すべきか」

を整理する時間を設けるべきでした。

そこで不明点が大きければ、追加ヒアリングを行います。

技術的な不確実性が大きければ、PoCや技術検証を行います。

そのように、次のアクションを決めてから設計に進むべきでした。

MTGのファシリテーション以前に、MTGの目的を定義できていなかった

プロジェクト中、社内MTGが「ふわっと終わる」と感じることが何度かありました。

話し合いはしているものの、何が決まったのかが明確ではありません。

当初は、これをファシリテーションの問題だと考えていました。

しかし、振り返るとファシリテーション以前の問題でした。

そもそも、

「このMTGで何を明確にするのか」

を定義できていませんでした。

例えば、

「リサーチを目的別に分類する」

「各リサーチで利用するデータソースを整理する」

「リサーチ結果として必要なアウトプットを定義する」

など、具体的な論点まで落とせていれば、会議の進め方も変わります。

つまり、ファシリテーションのスキル以前に、議論すべき論点を設定する力が不足していたということです。

この点は、今後PMとして経験を積む上で意識したい部分です。

メンバーが能動的に動けなかった原因も、タスクの曖昧さ

プロジェクト途中では、メンバーがあまり能動的に動かない状況もありました。

当時は、メンバーの主体性について考えることもありました。

ただ、これも振り返ると、まずPM側の問題がありました。

完成イメージが曖昧で、設計方針も十分に固まっていません。

その状態では、具体的なタスクを切り出すことも難しくなります。

結果として、

「次に何をやればいいのか」

がメンバーから見ても分かりにくい状態になっていました。

その状態で、

「もっと主体的に動いてほしい」

と考えるのは適切ではありませんでした。

能動的に動くためには、少なくとも、

  • 何を作るのか
  • 何を検討するのか
  • いつまでにやるのか
  • 何をもって完了とするのか

がある程度明確になっている必要があります。

途中、PMOからプロジェクト全体に対して働きかけがあり、チームの動きが改善しました。

この経験からも、メンバーの意識を変えること以前に、メンバーが動ける状態をPMが作ることが重要だと考えるようになりました。

要件合意を十分に取らないまま進めたことで、後から追加要件が発生

もう一つ大きな反省点が、要件定義書の合意です。

要件定義書について、十分に認識を揃えた状態で合意を取る前に、次の工程へ進めてしまいました。

その後、追加要件が発生しました。

追加要件そのものはプロジェクトでは珍しいことではありません。

問題は、どこまでを当初の要件とし、どこからを追加要件として扱うのかを明確にできていなかったことでした。

さらに、追加要件の詳細ヒアリングが遅れたことで、自身の夏季休暇期間と重なってしまい、PMOへ経緯を整理した上で対応を引き継ぐことになりました。

この経験から、要件変更を完全になくすことよりも、

  • いつまでに要件を固めるのか
  • 何をもって合意とするのか
  • 合意後に変更が発生した場合どう扱うのか
  • 追加要件の詳細確認をいつまでに行うのか

を事前に決めておくことの重要性を認識しました。

今回の問題は、それぞれ独立していなかったかもしれない

ここまで振り返ると、今回の反省点はそれぞれ独立した問題ではありませんでした。

技術的な実現可能性を判断できない。

↓

完成イメージが曖昧になる。

↓

要件を十分に具体化できない。

↓

設計に入っても何を作るのか明確にならない。

↓

具体的なタスクを切り出せない。

↓

メンバーが動きづらくなる。

↓

MTGでも何を決めるべきか分からない。

↓

議論がふわっとする。

というように、一つの問題が別の問題を引き起こしていました。

つまり、今回の大きな課題は、

曖昧な状態を解消しないまま、プロジェクトを次の工程へ進めてしまったこと

だったと考えています。

今後、同じような案件ではどうするか

今回の経験を踏まえると、未知の技術領域で案件を開始する場合、最初から詳細なスケジュールを引くことよりも、まず不確実性を整理することを優先したいと考えています。

具体的には、以下のような進め方を考えています。

① まず完成イメージをチームで揃える

顧客から説明を受けた後、そのまま設計に入るのではなく、

「我々は最終的に何を作ると理解しているのか」

をチームで確認します。

メンバーごとに認識が異なるのであれば、その時点で論点として扱います。

② 「分からないこと」を明示する

要件、技術、運用などの観点で、

  • 決まっていること
  • 決まっていないこと
  • 調査が必要なこと

を整理します。

特に「決まっていないこと」を問題として扱うことが重要だと考えています。

③ 不確実性に応じて進め方を決める

不確実性が低ければ通常のウォーターフォールでも問題ありません。

一方で、

「完成形が分からない」

「技術的に実現できるか分からない」

という状態であれば、PoC、技術検証、プロトタイプなどを計画に入れます。

つまり、最初にウォーターフォールかアジャイルかを決めるのではなく、プロジェクトの不確実性に応じて開発アプローチを選択するという考え方です。

④ MTGでは「何を明確にするか」を決める

MTGのゴールを、

「○○について話す」

ではなく、

「○○を決める」

「○○を整理する」

「○○の不明点を洗い出す」

という形で設定します。

⑤ メンバーが動ける粒度までタスクを落とす

PM自身が完成イメージを持てていない状態で、メンバーに主体性を求めるのではなく、

「何を、いつまでに、どの状態まで持っていくか」

を明確にします。

おわりに

今回のプロジェクトは、結果として開発スケジュール内に収まり、受入試験まで進めることができました。

一方で、その過程では、プロジェクトの進め方について多くの改善点がありました。

今回の経験から、PMに必要な技術知識について一つの答えが出たわけではありません。

GEについても、今後さらに理解を深める必要があります。

ただし、今回の経験から少なくとも一つ明確になったことがあります。

それは、PMの役割は、決まったことを管理するだけではなく、決まっていないことを見つけて整理することでもあるということです。

要件が曖昧であれば、何が曖昧なのかを整理します。

技術的に不明確であれば、何を検証すべきかを整理します。

完成イメージが揃っていなければ、認識の差分を整理します。

そして、その結果に応じて、追加ヒアリングをするのか、PoCをするのか、要件を見直すのか、設計に進むのかを判断します。

今回の自分には、この「一度立ち止まって曖昧さを整理する」という判断が不足していました。

今後PMとして経験を積む中では、技術知識を増やすことと並行して、プロジェクトの不確実性を見つけ、次に取るべきアクションへ落とし込む力を身につけていきたいと考えています。

今回の案件を、単に「初めてPMを経験した案件」として終わらせるのではなく、次のプロジェクトで具体的な進め方を変えるための経験として活かしていきたいと思います。