リスケ地獄から抜け出すプロジェクトマネジメント手法

初めに

こんにちわ、ランサーズでプロジェクトマネージャをしている @autumnlike です。
リスケリスケでプロジェクトマネジメントがうまく行かないチームの参考になれば幸いです。

前提情報

プロジェクトマネージャとは

プロジェクトで設定したゴール達成のための推進者である と考えています。
そのため、目標達成のために何でもやります。

• もし、プロダクトマネージャがいなければ企画も要件も目標設定も行います。自らできない場合は調達します。
• もちろん、予定外の要件が発生したり、遅延が発生したら開発推進します。（エンジニアと兼務の場合もあるので、もともと開発タスクを持っているケースもありますね）

ランサーズのプロジェクト

ランサーズでは、小さいもので1週間くらい、大きいもので2ヶ月ほどの開発期間のサイクルでプロジェクトが動いています。この記事では、そういったプロジェクトの進め方について書いていきます。

半年や、一年という単位のプロジェクトマネジメントには参考にならないかもしれません。

体制と役割

役割	責務
プロダクトマネージャ	企画とゴールの設定、要件の策定、企画における意思決定
プロジェクトマネージャ	ゴール達成の推進
デザイナ	要件を満たす、UI/UXを生み出す
エンジニア	要件を満たし、技術負債を改善しながら仕組みを構築する

ランサーズのプロダクト開発は、主に上記の4つの役割で開発が進みます。
上記とは別に、プロダクトオーナーやビジネスオーナーも存在しますが、企画が意思決定してからは殆どの場合、登場しません。

本題：リスケ地獄から抜け出すプロジェクトマネジメント手法

プロジェクト開始からリリースまでを大きく3つに分けて紹介します。

• 企画フェーズ: 目標設定・要件の確立、ステークホルダーとの合意
• 設計・計画フェーズ: タスクの規模見積り
• 開発フェーズ: 進行中の運用（メンテナンス）

※ リリース後の改善などはこちらでは扱いません。

企画フェーズ: 目標設定・要件の確立、ステークホルダーとの合意

目標と要件

企業において、開発するということは、何らか課題解決が前提として必ずあります。
課題解決されたということを示すものが目標です。（目標の更に上に目的が存在します）

目標の抽象度が大きい場合は、目標の要素として、満たすべき要件が必要になります。

目標達成のために推進するプロジェクトマネージャとしては、その課題やなぜ今これをやるのか？を自分ごととして捉え、メンバーにも誤解なく会話できる必要があるので、これを腹落ちするまで理解し、プロダクトマネージャと認識をすり合わせる必要があります。

ランサーズでは、担当者ごとのブレや漏れをなくすために、企画書フォーマットを作っており、開発するものにおいて、なんの観点で何を検討、調査し、どういうフォーマットでまとめるのかを定義しております。

ステークホルダーとの合意

自部署内だけで完結する場合は不要ですが、影響する組織が発生する場合は、目標や要件において相違ないか合意を取ることが必要です。合意をとってないと、開発途中やリリースした後に予想もしないちゃぶ台返しに合うリスクを孕みます。

影響するかどうかの判断ができなければ、とりあえず聞いてみることです。将来的には、各組織における責務を理解しておくと判断が付きやすいと思います。

キックオフ

上記を終えたら、開発チームとキックオフを行い、企画の背景から、目標や要件の共有、不明点の質疑応答を行います。

ここで全ての疑問ができることはありません。開発をすすめる上で細かい不明点は随時出るものですが、まずはこういう目的でやっていくんだという儀式的な観点と全体の認識合わせが目的です。

設計・計画フェーズ: タスクの規模見積り

僕がプロジェクトマネジメントとして最も重要だと思っていることは、常に見通しを良くすることです。確定情報と未確定情報がなんなのか、プロジェクトの状態に手触りがある状態を維持し続けること だと考えています。

タスクの洗い出し・タスク管理

昨今は様々なツールがあるし、Github Issueでも実行は可能ですが、以下の理由からタスク管理は Google Spread Sheet を選んでます。

• 一覧性: 各観点のタスクを網羅できてるか確認できる
• 分類性: 上記の観点だが、分類・整理できる
• 整理性: 並び替えが容易にできる
• 操作性: かんたんにタスクを増やせる、アサインできる

タスク管理や進捗を確認するのは、必ず1つのシートのみとします。個々人の性格もありますが、タスク管理とガントチャート、Github Issue を別でメンテナンスしないといけないなど、複数になった瞬間、漏れが発生し、何が正解なのかわからなくなるため、メンテできなくなるためです。1つのタスクシートだけ更新していれば必ず最新の状態がわかる ようにします。ほかは間違っても良い。タスクシートを元に反映すれば良いのです。

なお、タスクシートの項目、内容は以下。

列	意図
分類	タスクをまとめる分類。場合により、大分類、中分類と作る場合もあります。網羅的に洗い出せてるかどうかを確認するための要素です。
タスク	実際に対応するタスクの内容
担当	タスクをクローズする担当者
状態	wip: 着手中, ir: レビュー中, done: 完了
規模	タスクを閉じる規模。工数ではない
期日	計画において完了すべき日。週次で管理するので、基本的に週の終わりの日を入れてます
予定	完了予定日。週次で担当者が入力する。
完了	完了した日

まずは、要件に合う分類の項目を洗い出し、漏れが無いことを確認できたら、分類を完成させるタスクを洗い出すことで漏れなくタスクを出しやすいです。

Google Spread Sheet で利用しているので、タスクの追加や分解、削除や変更が一覧の中で即座にできるため、メンテナンスが苦ではありません。

タスク規模の見積もり

（PHP Conference で mediba さんのブースにていただいたプランニングポーカーを活用させていただいてます!）

開発チームで要件を一通り確認し、タスクの洗い出しができたらタスクごとに開発規模の見積りを行います。2名〜4名位でやるのがちょうどよいです。やり方は一般的なプランニングポーカーでの方法で行います。

1. ベースとなる規模の内容を決める。基準値は3ptとしてます。
2. タスク毎にポーカーでポイントを出す。低い人と高い人の意見を出して納得したポイントを置く。曖昧な場合は、高いポイントを置く。
3. ポイントが5pt以上だとタスクを分解する。※

※ タスクの粒度は基本的に1日で完了するものとしてます。これは、1日以上かかるものは状況が見えないからです。デイリーで進捗の状況をメンテナンスするので、1日以上のタスクを持ってると、順調だと思ってても1日立ったら違ったとなると1日出遅れることになります。そのため、1日以内のタスクで細かく分解して、着手中が1日以上経過しているものそのものが遅延とわかるようにします。

また、1日以上マージできない規模のタスクがあると、開発者としても進んでいる実感が得にくいことも一つの要因となります。

出した規模をタスクシートの規模に記入して完了です。

モブプログラミングの活用

全員の知識や技術力が一定以上ないと、見積りするのも難しい場合があります。
その場合は、一度、基礎機能のモブプログラミングを行い、知識と開発内容の認識合わせをすることをおすすめします。

新メンバーが入ったときも同様に効果的です。

計画の策定

全体の規模見積りができたら、計画を立てます。フェーズを切って、細かくリリースしていくか？まとめてリリースするのか？ それぞれの予定リリース日を出します。

そこで必要になるのが、規模とチームのベロシティです。過去数ヶ月開発してきたチームなら、デイリーや週次の消化できるポイントが出てるので、それを参考に計画を立てます。

全体の規模が 150pt で デイリーのチームの合計ベロシティが 5pt なら、 150pt / 5pt = 30営業日 となります。もし、新規チームなのであれば、少なくとも2週間は計測時間を取り、その後に計画を立てると良いです。

ここで重要なことは、基本的に初めに立てた計画・タスク通り行かないということです。開発を進めていく中で発見することや、タスクの漏れが必ずと行っていいほどあります。これは個人によりかわりますが、完璧に初めから用意することはできないので、僕は、出てきた規模を 1.5倍して計画を立てています。この1年間の実績ですが、この計画で大体ちょうどおさまります。

チームの予定ベロシティを元に、週単位の期日を設定して完了です。

ベロシティの管理

先のタスクシートの完了日と規模を元に、ベロシティの集計を行います。担当者も入れているので、個人別のベロシティの集計も可能なので、実績を元に、個々のベロシティ毎にアサインする規模が調整できるようになります。

開発フェーズ: 進行中の運用（メンテナンス）

そもそも人間は未来を完璧に予期することなんてできないので、プロジェクトが初めに立てた計画通り進むことはない。という前提で考えております。そのため、ある程度の粒度で計画して、常にメンテナンスをし、柔軟に動いていく必要があります。

ここでは、週の初めと終わり、デイリーでのメンテナンスについて書いていきます。

週初めのメンテナンス

プロジェクト開始週は不要の場合もありますが、週次で KPT（Keep/Problem/Try）の振り返りをすることをおすすめします。ランサーズでは、以下のように行っています。

• 今の状態の確認
  • 前週の目標達成状況の確認
  • プロジェクトの目標状況の確認
• 振り返りKPT
• 今週の目標の設定

月曜日: 今の状態の確認

今の状態を知り、チームとして向き合う現状の認識をあわせます。
このチームは、プロジェクトの目標達成のためのチームなので、目標達成状況の確認。前週決めた目標（※後述）がどうだったのかを把握します。

振り返りKPT

• Keep: 継続していきたいこと、良かったこと。
• Problem: 問題だと思っていること、良くなかったこと。

上記をそれぞれ付箋に書いてから発表し、それぞれの視点での認識を共有します。チームワークを高めるために必要なことは、チームについて、目標についての内容を語ることはもちろんですが、個人的な体調が良い悪いや、困っていること、などの状況をシェアすることが重要です。お互いの実態を見せ合うことで個々の理解が深まり、心理的安全性を作っていきます。

そして、最後に、チームとしてのTryを決めます。多く出しても全部やることは難しいので、1つか、２つだけ選ぶのがおすすめです。

今週の目標の設定

これまでの内容を元に、チームとして、今週に何を達成すべきか？を目標から逆引きの視点で設定して完了です。
最終的に、以下のようなボードを用意し、朝会や夕会で確認しながら状況を会話することで、日々意識できるのでおすすめです。

毎日: 日次のメンテナンス

毎日の終わりに、メンバーそれぞれが各自の担当タスクの状態を更新します。
プロジェクトマネージャは、予定通り進んでいるかどうかを確認し、遅れが出ている場合の要因を確認します。

何度も言いますが、基本的に、予定通りには行きません！そのため、うまく行っていることに一喜一憂するのではなく、遅れている理由を適切に吸い出し、要因を潰していきます。必要に応じて、アサインの変更やペアプロなどして解決していきます。

また、予定より進んでいる場合も安堵せず、なぜ進んでいるのかの要因を確認し、規模の見直しや開発漏れがないかどうかを確認していきます。

プロジェクトマネージャは、常に、今週何がゴールでそのためにやるべきが何なのかが頭に入っている状態が理想です。

金曜日: 週の終わりのメンテナンス

週の終了には、翌週の予定を開発メンバーに記入してもらいます。予定の進捗によっては、計画自体を見直したり、優先度を変更し、アサインの調整をします。

来週のイメージができたら、ゆっくり休みましょう。

開発フェーズのまとめ

• 日々変化する状況を把握し、常に最新の状態に更新する。
• 把握することは、開発の進捗だけではなく、メンバーの状態も含める。

Tips

最後に、気にしておくと良い考え方を共有したいと思います。

規模見積りが違ってた！要件が増えた！

前述の通り、計画通り行くことはほぼありません。規模見積りが違うことも日常茶飯事です。そのため、常に状況をモニタリングして、新たにわかったことから規模を見積り直し、更に計画を修正することが重要です。

要件が増えたり、緊急の差し込みで開発が進めれなかった場合も同様に、再度計画をし直す。見通しを修正しましょう。

目標達成からの逆引きで常に考える

計画通りにリリースすることは、二の次です。プロジェクトの目標達成のためなら、ひいた計画を捨てて、新たに計画を作り直すという思考が重要です。

そもそも立てた、企画や要件の前提が間違ってた場合、立てた計画をそのまま続けても、目標達成はできません。そういうときはやり直す勇気を持って進めます。

まぁいいかはNG

「ちょっと進捗が見えないけど、明日聞こう」、「これを確認しないと、計画が遅延するけど、忙しそうだからちょっと待とう」といった遠慮はNGです。ちょっとでも不安があるものは、改善のチャンスです。

余力を残しておく

メンバーの体調不良や予想外のトラブル、要件の追加など、目標達成するためにはいろんな予定外が発生します。それを残業などの時間での解決するのは、長期的にチームが衰退しますし、クリエイティブな仕事ができなくなり、結果的に負債だらけのシステムが積み上がります。

そのためにも、メンバーもそうですが、プロジェクトマネージャには一定の余力を残した計画を立てておき、余裕があるときは先のプロジェクトの計画や、メンバーのパフォーマンスを最大化することに力を使いましょう。

予定外のときにサブプレイヤーとして開発者などいろんな役割に転向して推進します。