#目次
- はじめに
- 当時のプロジェクトの会議体
- 心に刻んでおきたい言葉【進捗管理編】
- 1.予定と実績の差を明確にする
- 2.残タスク・残課題が常にわかるようにしておく
- 3.進捗が遅れた原因は何？
- 4.どうやって遅れを取り戻すの？
- 5.今後発生しそうなリスクは何？
- おわりに
#はじめに
こんにちは。某スマホアプリのバックエンド開発をしているアラサーエンジニアです。
以前配属されていたプロジェクトに、かなりできるPLの方（Hさん）がいました。
当時の私はプレイングマネージャーとして、Hさんの下で開発チームのリーダーをやっていて、Hさんからビシバシありがたいご指導をいただいていました。
そのおかげもあって、人間的にもエンジニアとしてもかなり成長できたと思うので、その際に言われたことを忘れないように、つらつら書いていこうと思います。
今回は進捗管理編となります！
駆け出しTLやマネジメントしてる方はもちろん、プレイヤーの方にも何かしら参考になったら良いなと思います。
（進捗管理編と言っていますが、本来の進捗管理の意味からはずれた内容もあるかもしれません。基本的に過去、進捗会議の場で言われたことを記載しています。）
■これまでに書いた関連する記事↓↓
** ●１つ目の記事**
過去にPLから言われた心に刻んでおきたい５つの言葉【要件定義編】
** ●２つ目の記事**
過去にPLから言われた心に刻んでおきたい５つの言葉【進捗管理編】←今ココ★
** ●３つ目の記事**
過去にPLから言われた心に刻んでおきたい６つの言葉
#当時のプロジェクトの会議体
私は以前配属されていたプロジェクトで２つの定例の進捗会議に参加していました。
１つ目は週次でのPLとの進捗会議です。
参加者は私とPL（Hさん）の二人だけで、現在の進捗やチーム状況、今後の予定等を報告していました。
当時は、Microsoft Projectを使用してスケジュール管理をしていました。
２つ目は月次での各チーム（他の開発チーム、運用保守チーム、CSチーム）のTLと、PL（Hさん）が参加する進捗会議です。
ここでも１つ目（週次の進捗会議）と同様、現在の進捗やチーム状況、今後の予定等を報告していました。
ただ週次の進捗会議よりは報告の粒度は粗めでした。
「はじめに」でも記載しましたが、本記事では基本的に↑２つの進捗会議の際に言われた内容を記憶を頼りにまとめています。
#心に刻んでおきたい言葉【進捗管理編】
##1.予定と実績の差を明確にする
進捗管理の第一歩は予定と実績の差を明確にすることです。
予定と実績の差を明確にするには、当然ですが実行する前に予定を立てていないといけません。
「不明瞭すぎて見積もりができないタスク」や「見積もりの最中に手が空いている他のメンバが、先行して行なっているタスク」でも、そのタスクがいつ終わるのか、ざっくりでも良いのでタスクに取り掛かる前に期限を宣言しておく必要があります。
一旦仮でも良いので期限を切ることで、そのタイミングがチェックポイントとなり、状況をヒアリングすることで「成果物は何もないが時間だけがズルズルと過ぎていく」のような状態になるのを防ぐことができます。
また、予定と実績の差は定量的に測る必要があります。
日数や時間の差はもちろんのこと、「タスクを完了するには○個の作業が必要で、内の□個が現在完了しています。」のようにタスクを更に細分化して進捗率を明確にしておくことで、仮に遅れが発生した場合でもいつ頃完了できるかの目安を把握することができます。
よく進捗を割合（100%中の○○％）で表現して管理することがあるかと思いますが、その場合はチーム内で共通の指標がないと、メンバが感覚で入力してしまい進捗管理上は意味のない情報となってしまうので注意が必要です。
（チーム内で共通の指標を作成することで、各タスクの終了条件も同時に明確にできるので尚良しです！）
##2.残タスク・残課題が常にわかるようにしておく
リーダーは残タスク・残課題のステータス(誰がボールを持っているか含む)と期限を常に把握できていないといけません。
そして定期的にチームメンバ全員で棚卸しすることが重要です。
スケジュールやチケット化されて常にみんなが意識する媒体の上に存在していれば良いですが、気がついた時にのみ確認する管理簿などに記載されているようでしたらその残タスク・残課題は棚卸しするまで全員の頭から消えてしまうでしょう。
またタスク・課題が生まれたら、誰が対応するのかと期限がいつまでなのかをすぐに決めるのも重要です。この際、アサインするメンバは必ず1人にしましょう。
「〇〇チーム」や「複数人で協力・分担する」のようなアサインをすると、責任の所在が不明瞭になって**「結局誰も手をつけていない」**状態になってしまいます。
ちなみに私たちのチームではタスクと課題については下記のように区別していました。
タスク：やらなければならない作業（作業の内容まで明確になっているもの）
課題 ：解決しなければならない問題
（タスクレベルまで落とし込めていないもの、検討が必要なもの）
課題については対応者と期限の他に、次にどのようなアクションを取るのかまで決めておくとスムーズな動き出しができるようになります。
##3.進捗が遅れた原因は何？
プロジェクトに遅れは付きものです。
私の担当していたプロジェクトもかなり遅延していた時期があり、進捗会議のたびにこの質問を投げかけられました。
当然ですが、ただ「進捗遅れてます！」と伝えただけでは、何も解決しませんし管理する人も困ってしまいます。
遅れた原因が明確になっていないと、何も対策を打つことができません。
今後もズルズルと遅れていく可能性もあります。
ただ遅れた原因を明確にすると言っても、表面的な原因にばかりフォーカスしていては有効な対策を打つことができません。
根本原因を明確にして、その原因を解決する対策を打つ必要があります。
この際、私のチームでは**「なぜなぜ分析」**を行っていました。
なぜその事象が発生したのか？なぜ上手くいかなかったのか？と原因を深掘りしていくものです。
これがまた難しく、私は全然上手にはできませんでしたが、根本原因を考える癖はつけることができました。
もちろん、どうやっても回避不可能だった遅れもあるかと思います。
その場合でも根本原因を明確にして、自信を持って管理する人に原因を伝えられるようにしましょう。
##4.どうやって遅れを取り戻すの？
**「進捗が遅れている。。でも根本原因まで明確にして対策も打ったし、今後は遅延しないので完璧！」**とはなりません。
今、遅れているこの状況を何とかしないといけないのです。
何かしらリカバリー案を考えてアクションを起こさないと、時間が勝手に解決してくれるわけでもなければ、誰かがリカバリー案を教えてくれるわけでもありません。
自分で何とかする必要があります。
ただ、リカバリー案を考えると言っても進捗が遅れている際に取れる策なんて、そう多くはありません。
下記の７つくらいかと思います。
・スケジュールを調整する。
→ 一部テストと実装を並行して進める。等
・バッファで補う。（バッファがあればの話ですが。。）
・稼働を上げる。
→ 残業や休日出勤する。等
・納期を調整する。
→ 納期を後ろにずらしてもらう、段階的にリリースする。等
・スコープを調整する。
→ 優先度の低い機能を削る。等
・品質を落とす。
→ 試験のテストケースを削る。等
・人を追加する。（逆に大変になることも。。）
上記の７つの中で現実的で効果のある案を、なる早で実行していくしかないのです。
１つの案でリカバリーできなければ２つ、３つと複数の案でリカバリーするしかありません。
##5.今後発生しそうなリスクは何？
最後の５つ目は未来の予測についてです。
今、進捗通りに進んでいて順調でも、これがずっと続くわけではありません。
進捗が遅れている時はもちろんですが、順調に進んでいるときも、この**「今後発生しそうなリスク」**を予測するのが重要になってくると思います。
基本的に仕事を進める上で、後手に回って良いことなんて一つもありません。
リーダーは今後発生しそうなリスクを常に考え、先手先手で対策を取っていく事が求められます。
イベント事（リリースや移行）や新しいことをする時は、必ず何かしらの問題が発生すると思って臨んだ方が良いでしょう。
そのリスクをあらかじめ明確にし、説明する事ができれば事前にバッファを確保しておくことができるかもしれません。
バッファがあれば、その問題が実際に発生した時にドタバタ慌てずに対応できます。
（発生しなかったらしなかったで、スケジュールに余裕が生まれますし、他の本当の不測の事態が発生した時に、そのバッファが使えるので悪いことなんて一つもありません！）
**「備えあれば憂いなし」**です。
リスクを予測して、事前の対応でリスクを回避・低減できるように先手を取っていきましょう。
#おわりに
以上が、「過去にPLから言われた心に刻んでおきたい５つの言葉【進捗管理編】」です。
この記事を書いていて、ちょっぴり憂鬱だった進捗会議を思い出しました。
進捗が遅れている時の進捗会議ほど憂鬱なものはないですよね。。
進捗報告をされる側の人は、進捗報告をする側の人が報告しやすい雰囲気を作るのも大事かなと思います。
嘘の報告をされても何も意味がありませんからね。
（嘘をつく方も、もちろん悪いですが。。）
本記事の5つの言葉を心に刻んで、今後も安心安全な進捗管理をしていきましょう！