進捗を管理する際に大切なことはとにかく具体化

3 min読了の目安(約2900字IDEAアイデア記事

1.はじめに

ここ数年進捗管理を担当することが増えてきました。
当然のことながら、上手くいくこともあれば上手くいかないこともあります。
その中で得た学びを具体化していこうと思います。

キーワードは具体化です。

前提として、私はマネジメント専門というわけではなくどちらかというと手を動かしてきた経験が長いです。
そのため、諸先輩方にとっては当然のことであったり抜け漏れがあったりするかもしれません。
今後このあたりについても体系的に学んでいく所存ですので、もしそういったことがあったら優しくご教示いただけたら嬉しく思います。

ちなみに私はWebアプリケーション開発に携わることが多いためそのあたりの実例を多く含んでいます。
進捗管理はある程度汎用的なスキルではあると思いますが、プロジェクトの種類や性質によっては的外れな事項も含まれるかもしれません。
あらかじめご了承ください。

2.タスクを具体化する

プロジェクトを進めていく上でほぼ必ずタスクを洗い出すと思います。
プロジェクトの完了という曖昧な状態を複数のタスクとして分解するわけですね。
そのときに具体化すべき事項について整理していきます。

2.1.目標を具体化する

何を成し遂げればこのタスクが完了したといえるのかを設定します。
そういう意味では成果物の定義ともいえるかもしれません。

逆にいうと、何を成し遂げればいいのか曖昧なタスクを設定することは避けた方がよいということです。
作業者が結局何をすればよいのかわからなかったり誤解してしまったりすると多くの場合残念な結果になります。

一方で、抽象度の高いタスクを設定しないといけないこともあるかもしれません。
しかし、私の経験上目標を具体化することが一切合切不可能であることは基本的にありませんでした。
したがって、目標の設定作業を無条件で放棄すべきではないというのが私の考えです。

2.2.背景を具体化する

そのタスクをなぜ成し遂げないといけないのかを設定します。
背景を設定するメリットの一つは、タスク完了に向けて的外れな手段を作業者が講じづらくなることです。

たとえば、SQLのチューニングタスクがあるとします。
そのタスクの生まれた背景が、とある画面の表示速度向上にあるとしたらキャッシュの利用等SQLを直接いじる以外の手段を作業者含め検討することができます。
一方で、コードの保守性を高めたいというものが背景にあったらSQL自体をいじる必要性がどうしてもあるかもしれません。
つまりキャッシュの検討自体が的外れになることも背景によってはありうるわけです。

このように、背景をしっかり具体化することで的を外さないタスクの遂行が可能になるわけです。

2.3.工数を具体化する

そのタスクを成し遂げる上でどのくらいの工数がかかるのかを設定します。

こちら当然といえば当然なのですが、タスクの洗い出しにいっぱいいっぱいで工数の策定まで手が回らないこともあったので記載させていただきました。
この事項の難しさは、やってみないとわからない部分がどうしても生じやすいところにあります。
工数の見積もりは大変奥が深いため、マネージャーとしての振る舞いとして私が大切だと経験を通して思ったことについて簡単に触れるにとどめます。

それは作業者を積極的に巻き込むことです。
作業者と見積もり者が異なることで無責任な見積もりが跋扈する光景を多く見てきました。
私自身マネージャーとして当然作業者のことを考えない無責任な見積もりをすべきではないと理解しているつもりではあります。
しかし、やはり作業者としての視点を積極的に取り入れないと危険だと考えています。
そのため、私は工数見積もりのときは可能な限り作業者となる方々と一緒に見積もりを行うかレビューをしてもらうことを意識しています。

2.4.納期を具体化する

そのタスクがいつ完了させるのかを設定します。

こちらも当然といえば当然ですが、このあたりから作業者の割り当てやクリティカルパスなどを考えるようになるのでかなり具体的な話になります。

3.進め方を具体化する

実際にタスクを設定したら次は実際にそのタスク完了に向けて各作業者が動き出すわけです。
が、ここまで具体化していてもうまくいかないときはうまくいきませんでした。
それを回避するために具体化するとよかったことを整理します。

3.1.ツールの使い方を具体化する

「いつ」「誰が」「何を」するのかレベルまで各種ツールの使い方を具体化します。

Backlogなどのタスク管理ツールやSlackなどのチャットツール、GitHubなどのバージョン管理ツールなど様々なツールを使うと思います。
そのツールの使い方はそれこそ会社さんやプロジェクトや個人によって千差万別です。

ツールの使い方を具体化していないばかりに手痛い失敗をしたことがあります。
バージョン管理ツールについてです。
私は幸か不幸か機能ごとにブランチを切り分けてプルリクを出してレビューするといういわゆる王道パターンから入りました。
それが当たり前だと思っていたのでその運用方法について特に触れずあるプロジェクトの実装工程が開始しました。

もうだいたい想像がつくかもしれませんが全機能が1ブランチで運用されていました。
レビュー時点で気づいたのですがもう後の祭りで複数機能が載った大きなブランチができていました。
レビューは困難を極め、差分も大きいのでレビューもしづらく作業者もどこを修正したのかいちいち共有しなくてはいけない始末でした。
それ以来私は、王道パターンがあったとしても必ず運用方法について細かく設定するよう意識するようになりました。

3.2.現状を具体化する

そのタスクが今どういった状態なのかを具体化します。

そのタスクが今どこまで終わっていてどこが終わっていないかというレベルまで具体化するのがポイントです。
これらを具体化せず「だいたい終わっています」などの報告を鵜呑みにして、いざ納期になったら致命的な部分に詰まっていて大きな遅延につながるといったケースはよくあるので注意しましょう。

3.3.問題を具体化する

その問題の原因は何かを具体化します。

プロジェクトは往々にして問題が生じます。
納期に遅れたり予想外の状態に陥ったりするわけです。
どんなに小さな問題であっても先延ばしにすると後々ほぼ確実に大きな問題として我々を襲うので原因分析は欠かさないようにしましょう。
作業者を追い詰めるのではなくあくまでプロジェクトの問題として個人の問題とは切り離すことが大切です。
(まあこれが綺麗事だと思わせてしまうくらいひどい作業者もいないこともないのですが...)

4.おわりに

ざっくりではありますがこんな感じです。
他に注意すること等ございましたら、ぜひぜひコメント等でご教示ください。

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