こんにちは！ウォンテッドリーでバックエンドエンジニアをしている市古 (@sora_ichigo_x) です。

この記事はWantedly Advent Calendar 2024の5日目の記事です。昨日は林さんの「データサイエンティストがGoを使った開発を経験することで学んだ、Python開発の改善点」でした。

この記事では、プロジェクトリードという局所的なスキルを深ぼって自分が普段実践していることを紹介します。個人的に 2024 年は複数のプロジェクトをリードする機会を頂くことができ、自分なりに「こうすれば上手くいく」というスキーマを整理できた1年になりました。担当したプロジェクトの中には緊急度の高いものもありましたが、そのような状況下でいかにして最速を目指したのか？という観点で話せればと思います。

前提：プロジェクトマネジメントではない？

このブログではプロジェクトリードはプロジェクトマネジメントの部分集合であると定義します。

• プロジェクトマネジメント：プロジェクトの目的達成に責任を持つ
• プロジェクトリード：プロジェクトの完遂に責任を持つ

プロジェクトマネジメントは完遂に対する責任を内包しますが、同時にチーム外との調整や計画の観点でも責任を持ちます。一方でプロジェクトリードはチームの内側にフォーカスします。

環境次第ではありますが、実装面でそれなりに自走できるようになると次はプロジェクトリードをやることが多いのではないでしょうか。

なぜ最速でなければならないのか

一般論として、開発が遅れるほど新たな課題が生じる構造が存在します。

緊急プロジェクトにどれだけ強くなれるか

緊急プロジェクトは予期できないので、既存プロジェクトに影響を与えることがほとんどです。既存プロジェクトに影響を与えるということは進捗やリソースの状況が乱れます。そして、安定性を欠いた状態で別の問題が発生すると更に対処が難しくなり、新たな緊急プロジェクトが発生します。普段なら安心して対処できる問題であっても、状況が違えば緊急プロジェクトになりうるのです。

こういった負の連鎖を断ち切る一番の方法は、発生した緊急プロジェクトを最速で終わらせて他への影響を最小限に抑えることです。自明ですが大事なことです。

製品開発は学習の邪魔

強い言葉にびっくりしたかもしれませんが、これは『Running Lean ―実践リーンスタートアップ』で紹介されている考え方です。

リーンプロダクト開発の考え方に則り、継続的な学習サイクルこそがプロダクト価値を最大化すると仮定すれば単位時間あたりの学習量というのは重要な要素になります。最も学習できるのがリリース後であることは言うまでもありませんが、開発で学習できることが無いということは案外忘れがちではないでしょうか。もちろん開発を無くすことは不可能ですが、要求からリリースまでのサイクルタイムを短くすることでプロダクト開発全体の学習を加速できるのです。

実践編：6原則

ここからは私が普段のプロジェクトで最速を目指すために実践していることを紹介します。

なるべく包括的に書いたので、ここでの6原則を押さえておけばかなりの確率でプロジェクトを加速できるのではないかと思います。

1. 情報の非対称性をなくす
2. スコープと期日を決めるまで開発を始めない
3. ロードマップは「いつ何をやるか」ではなく「いつまでに何を達成するか」
4. 20%の時間で80%の困難に向き合う
5. ゴール駆動開発
6. 具体的なタスクの可視化は徹底的に

原則 1. 情報の非対称性をなくす

「この人は知っているけど、あの人は知らない」は極力ゼロにしましょう。このような情報の非対称性はプロジェクト進行において予想外のトラブルをもたらす大きなリスクとなります。

例えば自分の場合、プロジェクトキックオフで主要なステークホルダが各々の理解について共有する時間を作っています。

事例. 実際にあったプロジェクトのキックオフ資料

プロジェクトのキックオフは毎回実施しますが、やっていることは究極的には情報の非対称性をなくしているだけです。プロジェクトゴールや期日など情報の非対称性があると特にまずい項目は明示的に用意しますが、それ以外にもフリーセクションを設けて自由に会話できる状態を作っておくと漏れ対策になるでしょう。

また、プロジェクト進行中も常に相談・共有しやすい場所作りを心がけましょう。自分の場合は以下の対応をよく行います。

• プロジェクト専用の定例 MTG を作る
• • ただし15分以内に収める努力をする
  • ※プロジェクトの数だけ定例があるとカレンダーがパンクしてしまうため
• 専用の Slack チャンネルを作る
• • 流量多く、雑なコメントでも気にせず投稿できる非同期コミュニケーションの場所を作る
• 仕様相談など、事前に必要性が予測できるコミュニケーションは専用の GitHub Discussion を作るなどして場所を整えておく

※もちろん、一定以上の規模を超えたプロジェクトでメンバーが全ての知識をキャッチアップするのは効果的とは言えません。しかしそのような状況下においても、情報の非対称性に対して自覚的であるかどうかは予想外のトラブルを防ぐという意味で重要です。

原則 2. スコープと期日を決めるまで開発を始めない

プロジェクトのスコープと期日が分からなければ信頼できるロードマップは組めません。

自分の場合は、プロジェクトの第1週に必ずスコープと期日を決定するよう心がけています。この2つが終わっていなければ、後続の開発に手を出してはいけないという強い気持ちが必要です。

原則 3. ロードマップは「いつ何をやるか」ではなく「いつまでに何を達成するか」

いわゆるリソース効率とフロー効率の話です。
参考: フロー効率性とリソース効率性について #xpjug | PPT

ロードマップ策定における難しさとして「1. ゴール達成のために最適なステップ」と「2. 人的リソースの調整」という両面を同時に考えることが挙げられます。

「1. ゴール達成のために最適なステップ」から考えた例

「2. 人的リソースの調整」から考えた例

この時、自分はあくまで前者に合わせる形で後者を考えることが多いです。

1. 「ゴール達成のために最適なステップ」を考え、ロードマップに落とし込む
2. 各ステップで必要な能力をラベリングする（バックエンド必要 or フロントエンド必要 or デザイン必要 or ...）
3. 完成したロードマップをもとに他プロジェクトのロードマップとパズルする

3番では個々のリソース同士のパズルではなく、ロードマップ同士のパズルを解いていると考えることが肝です。

「2. 人的リソースの調整」から考えると「10/1~10/14：バックエンド開発、10/17~10/31：フロントエンド開発、...etc」のようなロードマップを引きがちです。しかし結局リソース効率優先になってしまうので、問題解決の最短経路は取りにくくなります。また、職能同士のコミュニケーションコストを勘定に入れないと実績が見積りより膨らんでしまうというリスクもあります。

原則 4. 20%の時間で80%の困難に向き合う

いわゆる理想的な不確実性の減らし方の話です。上手くいっているプロジェクトほど進行するにつれて余裕が生じてくるという経験がある人も多いのではないでしょうか。

自分の場合は、プロジェクトの第2週までにそのプロジェクトの技術的 (あるいはそれ以外の) 困難を80% 解消したといえるよう "頑張る" ことが多いです。

"頑張る" ということが重要で、実際のところこのロケットスタートを実現するためにはそれなりのガッツが求められます。

あまり大きな声では言えませんが、自分の場合はプロジェクトの第2週くらいまでは多少無理をして、その代わり普段なら2週間かけるようなサイズの問題を2日で解決することが多いです。もちろん一定の能力は必要ですが、能力以上に実際には多少の "頑張り" でガッツを出すという側面が強いです。

日本ではラストスパート志向が強いですが、プロジェクトリードにおいて不確実性を効率的に下げるためにはロケットスタートの方が適しています。

余談ですが、自分のこのやり方は『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』という本で紹介されているロケットスタートという方法に影響を受けています。個人の時間術の本にはなりますが問題解決という見方をすればプロジェクトリードにも応用できます。

補足: とはいえ、プロジェクト終盤でなんとかやり切る力も大事

プロジェクトにトラブルはつきもので、百発百中でトラブルを回避できるとも限りません。

しかしビジネスにおいて「トラブル発生したので諦めました」が通ることは稀です。トラブル発生時には何とかそれを乗り越えるための強いコミットメントが必要です。最速がテーマのこの記事では深く扱いませんが、これも重要な能力の一つです（ただし濫用注意。燃え尽き症候群に陥りやすいので、頑張ってやり切った後はしっかり休んで、同じトラブルが起こらないように振り返りを徹底しましょう）

原則 5. ゴール駆動開発

正しく策定したロードマップがあれば、個別ステップで定義した状態をそのまま週ごとのゴールに当てはめることができるはずです。

自分の場合は、1週間を1イテレーションと定義して毎週ゴールを設定して開発を進め、その達成率を見てロードマップを軌道修正していくようにしています。例えば1週間のMTG運用は以下のように進めています。なおスクラムガイドの語彙に合わせていますが、厳密に運用しているわけではなくあくまで目的中心に簡易的な形をとっています。

月曜：プランニング

• 目的：
• • 今週のゴールを決める
  • 今週のゴール達成に必要なタスクを分解する
• ゴールの例：
• • 「XXページでOOが出来るようにする」
• 「XX実装をする」に気をつける
• • 実装担当者以外は「XX実装とは..？」となりプロジェクトが上手くいっているのか判断がつかなくなる
  • せめて「XX実装をマージする」など完了条件を明示的にすることを心がける

例. プランニング&レビューの議事録テンプレート

火〜木曜：デイリーシンクアップ

• 目的：
• • 今週のゴールを達成できそうか？厳しければどう対策するか？を把握する
• フォーマットの例：
• • 今週のゴールの再確認
  • タスクのステータス確認
  • 今週のゴールを達成できそうか？を判断
  • 相談事項
• ※「タスクのステータス確認」については原則6で詳しく紹介

例. デイリーシンクアップの議事録テンプレート

金曜：レビュー

• 目的
• • 今週のゴールに対する達成度合いを確認する
  • 実績に応じてロードマップを調整する
• プランニングで記載した今週のゴールに追記する形で「どうなったか」を書く
• • 絵文字でラベリングするとわかりやすい
• 自分が使っているフォーマット
• • ✅ 達成
  • 🏃 未達成だが全体スケジュールに影響なし
  • ☔ 未達成かつ全体スケジュールに影響する

上記の MTG に限らず今週のゴールを達成するためにはどうすべきか？を問いながら意思決定すると良いでしょう。よくあるケースとして「この実装のレビューは非同期で行うべきか、同期で行うべきか」という場面がありますが、こういった場合でも以下のように今週ゴールから逆算して意思決定することを心がけましょう。

• 今週のゴールを達成するためには、いつまでにこの実装をマージする必要があるのか
• そのために、どのレベルのスピード感が求められているのか

6. 具体的なタスクの可視化は徹底的に

原則5のプランニングでタスク分解を行って、それで終わりにしないようにしましょう。

自分の場合は、以下のようなボードをデイリーシンクアップで同期的にアップデートすることでタスク状況のキャッチアップを行っています。

ここでの目的は2つです。

1. デイリーシンクアップで「タスクのステータス確認」をスムーズに行えるようにする
2. タスクの抜け漏れやボールが落ちることを防ぐ

原則5の繰り返しになりますが、完了条件の設定は気をつけましょう。例えば「XX実装を行う」と書いてはいけません。これでは「実装を行う」がレビュー依頼までを指しているのかマージまでを指しているのか判断がつきません。正しくは「XX実装をマージする」と書きましょう。「XXの仕様を考える」も同様です。「XX仕様を確定させる」と書きましょう。

ボードは毎週月曜のプランニング後にその週の分を作り直しています。今週達成したいゴールが複数ある場合は、ゴールごとの担当がタスク分解してボードに積みます。タスク分解の精度に懸念があれば、プロジェクトリーダーが一緒になってタスク分解を行うこともあります。