【実録】課題の進捗管理の罠

PMになって1ヶ月が過ぎようとしています。

今まで、設計フェーズから関わっていたのですが、

企画やプロジェクトのキックオフに関わるようになり、課題管理が結構大変になってきました。

と言うのも、

運営側は「なんでもっと速く開発できないのだろう」と思っていて

開発側は「いや、計画通りにやってるぜ！」と思ってる。

この認識のズレが一番大変でした。

そして、現在は運用側と開発側の認識を一緒にすべく「課題管理」と言うのを1から考えて、今実施している最中です。

そこで、今の状況から学んだことなどをまとめたので、私と同じ境遇の方の手助けになればと思っています。

課題作成前に持っておくべき考え

私のように、いきなり課題管理をしろと言う状況になった方もいらっしゃるともいます。

その方は、課題を作成する以前の背景に注目するといいかも知れません。

具体的には

• ①課題管理は会社の特色がモロに出る

• ②「工数」と「スケジュール」は必ずズレる

この2つが重要と思っています。

それでは、1つずつ解説していきます。

ちなみに、私とクライアント間ではbacklogとnotionを使っています。

①課題の進め方は会社の特色がモロに出る

ただ、課題を作って進捗を確認するだけなら楽ですが、そうは行きません。

なぜなら、課題の進め方には会社の特色がモロに出ちゃうから。

例えば、ベンチャーなど「とにかく早くリリース」を求められる会社の場合。

イケイケな会社だと、正常系テストした後にはリリースしてユーザーの意見を貰いながら進めるとこもあるみたいです。

このように、リリースまでのスケジュールを設定したとして、設計、実装、テストの工数って明確にならないまま勢いでリリースまで持っていくことが多くなります。

一方、大規模開発や決済、金融系に関わる開発は、リリースまでに特に慎重なプロセスを踏む必要があります。

金融の決済処理や金額が間違えていたら、最悪の場合営業停止になっちゃいますからね。

そのため、課題は子課題に分けてかなり細かく管理しすることになります。

②「工数」と「スケジュール」は必ずズレる

backlogなど子課題を作りやすい場合は、なるべく小分けにしています。

そして、親課題には"スケジュール"を期日にして、子課題には"工数"を期日にするように定義しています。

なぜなら、「工数」と「スケジュール」をごちゃ混ぜにしたくないから。

そもそも「スケジュール」とは、開発した納品物をリリースして運用するまでの日数。

そこには、開発工数だけでなく、テストも含まれるし、運用側とのやり取りも含まれるはず。

しかし、工数は開発だけにかかる日数のことです。

これをはっきりと分離せずにクライアントと話しちゃうと

クライアント：「あれ？スケジュールから遅れていない？」

開発：「いやいや、工数通りの進捗ですよ。」

みたいなミスコミュニケーションが生まれる可能性があります。

これはお互い幸せになれないので、まずは「工数」と「スケジュール」は別物ということを共有しておきましょう。

実際に効果的だった課題管理方法

課題作成にあたっての大事な考えを共有したところで、実際にどうしたらいいのでしょうか？

それは、実際にチームと話し合って見つけていくのが一番。

でも、基本的にこうした方がいいかも。という方法はあります。

私の経験から

①子課題に分ける
②「差し込み対応」の調整方法を定義しておく
③課題進捗前にコミュニケーションをとる

この方法が一番効果的でした！

今から詳しく説明します。

①子課題に分ける

子課題化は鉄板だけど一番効果的だと思います。

バックログなどは子課題が可視化できるため、開発外の方も一目で分かるし、先ほど言った「工数」と「スケジュール」の認識を共有することができます。

しかし、どれくらいの粒度まで分けるのかは、開発規模や開発方法よって変わると思っています。

例えば、私の場合はスクラム開発のため、課題作成→完了までが早く、

「今この子課題で何日までには完了です」のような日数単位での進捗報告になっています。

しかし、大規模開発やウォータフォール開発だと、1つの課題完了まで時間が掛かることもあり、

「この課題、進捗何%です」というようなパーセンテージレベルで分けることが多いです。

子課題化は、子課題にするまでは簡単ですが、進捗管理は会社ごとのにカスタマイズする感覚がいいかもしれません。

②「差し込み対応」の調整方法を定義しておく

工数管理で一番大変なのが「差し込み対応」の調整です。

ある課題の開発をエンジニアに任せており、そのエンジニアが突然のバグ対応をしなくてはいけない場合、

工数は必ずズレます。

ズレるだけだったらいいけど、リリース日が近いと、運営側に急遽連絡して調整しなくてはいけません。

それが複数の課題で起こると、正直お手上げです。

それを防ぐために、課題管理は差し込み対応まで事前に決めておくべきだと思います。

具体的には
・工数にバッファを持たせる
・バグ対応の担当を決める
・スケジュール挑戦の連絡する人を確認する

以上が挙げられます。

正直、差し込み対応って予測できない分、事前に決めても対応できない場合もあります。

でも、差し込み対応の質と交流アップのためにも、叩き台を作る感じで、最初に決めておいた方が後々楽です。

③課題進捗前にコミュニケーションをとる

課題進捗って作る前に進捗が決まると思ってます。

課題作って、ドキュメント貼って、やり取りを見せて、はいやってね。

みたいなやり方は最悪です。

私は、課題作成前か課題作成後すぐくらいに開発担当に開発の背景やポイント、ゴールを全て伝えます。

すると、進捗は進むし、進捗が悪いと連絡をしていただけます。

また、プロジェクトに参加して自分の知見が足りないと感じたら、先輩エンジニアに相談して、完全に設計に落とし込むまで調査やミーティングを行います。

もしも、不明点満載のまま開発担当の方に振ったらきっと崩壊するでしょう。

課題管理は気遣いがかなり重要。

その気遣いを形にするのがコミュニケーションです。

課題管理を行う立場の方は、ゴリゴリにコミュニケーションをとっていきましょう！

【まとめ】認識の齟齬をなくす。話はそれからだ。

私も手探りの状態ですが、とりあえず今の課題管理で上手くいった方法や考え方を共有してみました。

そして、課題管理を振り返って一番思ったのが、

開発や運営側、外部の人間と「認識の齟齬」をいかに無くせるかがキーポイントだと思います。

これからもたくさん壁にぶつかると思いますが、それも楽しんでPMという仕事をやっていきます。

最後まで読んでいただきありがとうございました。