こんにちは、アドプラットフォーム事業で開発業務を行っているリードシステムエンジニアのまっちゃんです。
約１年ぶりですね。（前回の記事はこちら）
ちょうど一週間前に住んでいるマンションの水道管が破裂して部屋の一部が水浸しになりました。
奇跡的にパソコンや周辺機器は無事でしたが、他の家電や服、本の一部が駄目になりました。（不可抗力ですがこれもやらかしです）
冬の時期は水道管破裂が増えます、本日も関東平野部で広く積雪の予報となっていますので皆さん気をつけてください。
本日は 2022/10~2022/12 の期間でプロジェクトマネジメント、プロダクトマネジメントの一部を体験して、失敗という失敗をしてしまったのでふりかえりも兼ねて書きます。
ぜひプロジェクトリーダーをやっているエンジニアやアソシエイトプロダクトマネージャーに読んでほしいなーと思います。
どのようにしてプロジェクトが進んだか
簡単にプロジェクトについて書きます。
今回携わったプロジェクトはアフィリエイトサービスで新規価値を出すためのプロジェクトです。
開発自体は 2022/04~2022/09 の半年に着手もしてましたが他プロジェクトや開発を並行して進めていたため思うように進みませんでした。
今回は 2022/09~2022/12 の間で最低限の基盤開発を終わらせつつ、機能展開も行うことが最低限の完了の定義として決められていました。
そのために円滑なプロジェクトマネジメントが必要になっていきました。
実際にリリーストレインをもとに今回行ったことを簡単に紹介します。
前半 10 月頃までは不足している機能の開発をしました。
後半 11 月頃から 12 月は新機能開発や仮説検証を実施しました。
新規価値の結果を出すための体制変更が実施
もともとアドプラットフォーム事業でアフィリエイトサービス、リワードサービスの開発・運用を担っているアドテクノロジーディビジョンは下記のような体制でした。
ディビジョンではサービスの新規価値を提供し事業への影響を与えるという目標を掲げていました。
ところが、こちらの実績が計画以上に出なかったため、改善を担っていたチームを解体し新機能開発のリソースへ投入しました。（専門チームの変更は無いため省略）
チーム異動した線を除去するとこんな体制です。
アフィリエイトサービス、リワードサービスへリソース投入していることがわかります。
アフィリエイトサービスのライン２が自分が所属したプロジェクトチームです。
そしてなぜかこのチームだけユニットマネージャー*1（兼スクラムマスター）が不在です。
過去にも開発案件のリードを行ったり、小さいチームのプロジェクトリーダーも担ったりもしましたが、スクラムマスターが居ないとなると自分が回さないといけなくなるのでびっくりです。
（ちなみに有給休暇を消化するためにひたすらお休みを頂いていた時にこの体制になってました、信頼してくれるアツい組織ですね！）
自身がプロジェクトリーダーとしてプロジェクトマネジメントで取り組んだこと
2022/10 から「君、プロジェクトリーダーね」と言われ「さて、今回はどうしようか」と考える自分。
以下のことを取り組みました。
もちろん体制が変わった直後であり、最初の数スプリントはうまく回らなかったり改良の余地がありましたが、開発チームのメンバーが積極的に意見やアイデアを出してくれて円滑に進めることができました。
進行管理
プロジェクトを円滑に進めるためにタスク管理やディレクション、マネジメントを実施しました。
チームの KGI/KPI 作成
普段はチーム OKR をプロダクトチームで議論を行い決定をしています。 今回はプロダクトマネージャーが計画した完了の定義、リリーストレインの草案をベースに定量的に進捗を追えるよう KGI/KPI を考えて策定しました。
要件整理、要件決め
何を作るのかを決める作業です。
自身もエンジニアなのでどう作るかまでを考えてしまったり、こういう要件や実装だと開発工数がかかってしまう、費用対効果が悪いなと感じることが何度もありました。
スクラムイベントのファシリテーション
普段はスクラムマスターが進行したり、ファシリテーションをチーム内でローテーションなどをしています。
今回のチームはスクラムマスターがチーム内に不在だったことに加え、プロジェクトリーダーの意思決定する部分が多くあったため、プロジェクトリーダーがすべて進行を実施しました。
開発案件の動作確認
決定した要件通りに動くか、他機能などに影響が無いかの確認を行いました。
通常ならプロダクトオーナーやプロダクトマネージャーが行うチェックも自身が実施していました。
あまりにも順調な開発、爆速で成果物を出す開発チーム
プロジェクトの始めにプロダクトマネージャーが計画した完了の定義、リリーストレインをほぼ達成できるようになったのは 2022/11 の頭でした。
ある程度開発したい内容の要件も決め終え、開発チームがひたすら開発するフェーズだったのでいろいろお任せしつつ自身は夏季休暇でイタリアへ旅行に行きました。（ちなみにこの旅行でもやらかしが何度もありましたが話がそれてしまうので割愛......）
無事帰国して最初の仕事でタスク管理ツールを見ると衝撃の光景が広がってました。
「ほぼ終わっている、バックログのタスクがほぼ無いから次のタスクが無い、え？次何やるの？？」と。開発チーム、仕事が早すぎです。最高です。
（この時点で上振れ達成しているチーム KPI も存在してました）
ここでエンジニア次なにやるの問題が発生しました。
もちろん開発した内容のリファクタリングや改善も大いに有りなのですが、体制変更の内容が「新規価値の成果を出す、そのために技術改善を削る」という方針です。
エンジニアにとってもリファクタリングや改善業務などは自身の裁量で決めることができタスクを進めやすいのですが、体制変更の内容を反するのでここでの全投入はぐっと我慢して、新規価値をもっと生み出すためにできること、 2022/12 までにできることを考えることにしました。
（もちろん開発効率を上げるための改善は新規価値の開発をしながら進めてもらいました）
案件を生み出すためにプロダクトマネジメントで取り組んだこと
残り１ヶ月近く、 2022/12 の仕事を創り出すために！案件を生み出すために！自分はプロダクトマネージャーに片足突っ込むことになりました。
プロダクトマネージャーとしては下記のことを実施しました。
こうしてみるとあまりやってないですが、それぞれの作業量は多かった気がします。
アイディエーション
開発チーム、ステークホルダー、ディレクター、プロダクトマネージャーの全員を呼んで実施しました。
もともとはステークホルダー、ディレクター、プロダクトマネージャーの３ロールで実施する予定でしたが、開発チームも巻き込むように動きました。
とにかくこのプロジェクトでできそうなこと、仮説や学びをブレスト形式で挙げ、プロダクトマネージャーが判断しやすく、案件候補を出しやすくするためにマッピングを実施しました。
A/B テストの仮説検証
アイディエーションから A/B テストの仮説検証を行う開発案件が生まれました。
MVPキャンバス を作成し、データを絡めた条件やパターンの整理を行いました。
失敗談
ここまで見てくださった方はこう思ってるかもしれません。
「めちゃ順調じゃん！」
「成功してるやん！！」
「やるべきこと完了して、追加の開発もして素晴らしい！！！」
と
案件を生み出すためにプロダクトマネジメントで取り組んだこと、ここ、派手に失敗してます。
どう失敗していったのかを見ていきましょう。
失敗談１：的外れアイディエーション
帰国してアイディエーション実施する！！と思い立ったが吉日、すぐ準備に取り掛かりました。
そう、プロダクトマネージャーにどういうアイディエーションをするかも相談せずに......
その当時に書いたチャットをほぼ再現してみたので見てみましょう。
まっちゃん 2022/11/09 12:38:58
共有：新機能の開発について
開発が今止まっている状況なので下記で進行をしたいです
昨日ディレクターTさんと状況は確認しました
- ステータス
- 現状：アイディエーション
- 金曜会議：ブレスト
- 来週のどこか：決定予定（が不明）
- 動き
- 今日のスプリントレビューはエンジニアも含めてアイディエーションしてみる
- 案を出せるかは不明だが、出た場合はその内容を金曜日の会議に持ってきてもらう
- その次のスプリントレビューで決定の場を作る
- プロダクトマネージャーOさん、ステークホルダーCさんも呼ぶ
- スケジュールは押さえた
- 確度が高いものは軽く要件作って開発を始める（自分が作成してプロダクトマネージャーOさんチェック後に）
- Hoge機能とか
- 本日の夜か明日の朝に作って軽く確認をお願いしたい
プロダクトマネージャーO 2022/11/09 13:46:10
お、まじで。想定外の速さで嬉しい。
流れはおk。まっちゃんの方で巻き込んでくれてありがとう。良い動き。
見て分かる通りアイディエーションは実施するよ！でもどういうアイディエーションをするのかは全く記載がありません。
アイディエーションで何を達成したいのか、どういう観点でアイデアを出すのか、がこの内容からは不明です。
本当に開発することが無いからアイディエーションをやろう！という手段が先行してしまい目的を見失っています。
こうしてスプリントレビューの時間がやってきたのでアイディエーションを実施しました。
ゼロから発散することによってブレストの量はありますが、達成したいことや観点が無いため採用できるアイデアがほぼありませんでした。
最初にゴールを決められなかったのは仕方ないと言われますが、プロダクトマネージャーOさんともっとやり取りをすれば観点は絞れてブレストの量は減るものの、採用できるアイデアは増える可能性は高いと思います。
結局アイディエーション、アイディエーションからの開発物決定は２週に渡って実施され、その間にプロダクトマネージャーOさんが今後やりたいことや観点などをまとめてくれました。
２週に渡って開発チーム全員を巻き込んでおり、関係者も多いのでこの失敗は多くの方の時間を追加で使ってしまうことになりました。（＋１週）
（画像はイメージ図です、アイディエーションしてマッピングしてみました。）
失敗談２：いつまでも始まらない仮説検証
失敗談その２は上記アイディエーションから実施することになった仮説検証の開発についての失敗です。
開発チームだけで仮説や学びを決めようぜ！ → ビジネスがわかるプロダクトマネージャーやディレクターを巻き込みましょう
ここで改めて自分が所属しているチームの意思決定に関わるコミュニケーションについて見てみます。
プロジェクトの方向性や意思決定に関わるロールとして、プロジェクトリーダー、ディレクター、プロダクトマネージャーが居ます。（画像赤線）
ここでプロジェクトリーダー、なぜか血迷って開発チームのエンジニアだけで MVP キャンバスの仮説、学びを決めようとします。（画像緑線）
エンジニアだけで決めようとすることで下記の問題が発生しました。
- 実際のビジネスの状況や使われ方がわからない
- 営業出身のディレクターTさんやステークホルダーのCさんを呼ばない限りわからない
- これできるの？あれできるの？という話が堂々巡りして議論が着地しない
- 仮説検証の意思決定者は誰なのか問題
- 基本的にはプロダクトマネージャーが決めていくが、エンジニアリングマネージャーも兼務しており実質会議に参加できてない
暗中模索状態となり物事が進まなかったため、翌週にプロダクトマネージャー、ディレクター、ステークホルダーを呼びました。 なぜ最初から呼ばなかったのか......（＋１週）
最終的に MVP キャンバスの仮説、学びはプロダクトマネージャーがたたきを作りました。 次は検証するための条件を整理することになります。
プロジェクトリーダーが頑張って検証するためのパターンや条件を整理するぜ！ → もっとディレクターに相談しましょう
次はパターンや条件を考えることになります。
要件整理も行っていたので本領発揮！と思ってましたがとんでも無い過ちでした。
あれもこれもと条件に追加してしまい、開発作業量が肥大化してしまいました。
ディレクターに結局どこが大事なのか？どういう部分を追いたいか？などのヒアリングを実施してパターンや条件を減らすことにしました。（＋１週）
最終的に無駄な条件やパターンの削除を行い、シンプルなデータや条件に落ち着きました。
要因分析を行いやすくするために、パターンや条件はなるべく減らす方が良いです
よし！全部の材料揃ったから詳細を考えよう！ → 不確実であっても早く考えましょう
ここまでで MVP キャンバスの内容やパターンの整理が終わったので実際の素材についてディレクターに考えてもらうことになりました。
しかし、ここでも問題が。
「考えてみたものの、このパターンだと素材の差分が無いため差別化できず、 A/B テストができないですね......」
なんということでしょう、ここまで頑張って考えたのにまさかのパターンを考え直すというちゃぶ台返しが発生しました。（＋１週）
結局差分が出て差別化が出るパターンを作り、素材を考えることになりました。
もっと早く内容を考えることができればすぐ気づけたのに、なぜ最後に考えるという進め方をしてしまったのでしょうか。
不確実性を無くすことは大事ですが、結局足りない可能性もあるため、もっと早く考えることが大事です。
ここでようやく仮説検証が始められる状況になりました。
結局この失敗ってなんだったの？
結局仮説検証を始めるのに１ヶ月超かかりました。
もっと進め方を見直せばすぐに仮説検証を取り組むことができたと感じます。
これらの失敗を短期的に見るとプロダクトマネージャーとの認識不足やディレクターへの相談不足など「単純な報連相が不十分」と捉えることができます。
しかし長期的に見ると「戦略や軸がブレていた」とも言えそうです。
自身がプロダクトマネジメントをやってみて、「案件を創り出すこと」を目的としていたため、自分の中で大事にしたい軸が定まってなかったと思います。
目的を「いかにして新規価値を出すか」「データを組み合わせた施策を打てるか」などに設定して考えてみると、プロダクトマネージャーとの認識合わせやディレクターへの相談も自発的に行えたり、 MVP キャンバスも違う深さで考えることができたのかもしれません。
上記の話はエンジニアの技術選定や戦略に通ずる部分があると思います。
データを使った事業貢献が大事になるなら、投資として Dataform を活用するデータ基盤を作る必要がありますし、古いバージョンを使用して素早い開発ができないのであれば改善として最新のメジャーバージョンへアップデートをする必要があります。
これらに似たようなことをプロダクトマネージャーは考え、判断する必要がありそうです。
こういった部分からプロダクトマネジメントはエンジニアリングの延長線だなとしみじみ感じてます。
株式会社ADWAYS DEEE 設立、プロダクト組織へ
チームのふりかえりでは「チーム内に意思決定者が居ないから遅くなるのではないか？」という声も上がりました。
そんな中、今年１月から 株式会社ADWAYS DEEE が設立され、開発組織からプロダクト組織、良いプロダクトを作りプロダクトを成長させる組織へと変わっていきます。
直近のプロダクトチームの体制を簡単に紹介します。
もともと営業組織にディレクターチームがいましたが、アドテクノロジーディビジョンに所属し、プロダクトマネージャーチームとなります。
１つのプロダクトチームには必ず専任のプロダクトマネージャーを配置し、チーム内で意思決定をしていくことになります。
これによりもっと素早い仮説検証や開発に取り組むことができ、間違ったものを作ることのリスクを減らすことが見込めます。
最後に
自身がプロジェクトのマネジメントについて約３ヶ月やったことをふりかえりながら書いてみました。
この記事を見つけたプロジェクトリーダーをすることになった貴方、プロダクトマネージャーをすることになった貴方、幸運ですね！
他者の失敗談を読むことによって自分は気をつけようという感覚になると思います。
この記事を見た後にやってみて、失敗したとしてもそれは小さな失敗です、すぐに挽回できるものになるでしょう。
プロジェクトリーダー、プロダクトマネージャーは考えることも多く、とても大変ですが面白くて楽しくやりがいのある役割です。
良いプロジェクトリーダー、プロダクトマネージャーライフを！！貴方のプロジェクト、プロダクトに幸あれ！！
