以前にもPLの経験談を書いたのですが、またPLの機会を担うことになったので思ったことを書き残しておきます。前回とはまた違った苦悩がありました。

タスク内容/役割

案件としては、2か月半で設計からリリースまでを行うプロジェクトでした。他案件も掛け持ちする人もいますが、メンバーは4~5人です。役割とタスク内容は以下の通りです。
・PL
・進捗会議進行
・お客様対応・会議出席
・上長への報告/他チームとの連携
・タスク管理/進捗管理
・ドキュメント作成
・レビュー（設定書、ソース、テスト設計）
・テストのサポート

難しいと思えたこと

①コントロールできない事象の対処

プロジェクトが進行していると、たいていハプニングが発生します。プチハプニングから、やばいハプニングまで多種多様です。その中でも難しいのは、コントロールできない（しづらい）ハプニングの対処です。例えば、体調不良が続いて作業時間がかなり少なくなってしまったり、他案件に作業時間を持っていかれることなどです。

仕方ないことですが、プロジェクトの期限は延びません。だから、コントロールできないことは潔く諦めて、コントロールできることに注力するにようにしていました。

時間や予算には限りがあり、変更するにしても合意形成まで時間がかかったりしてコントロールしづらいものです。一方、タスクの割り振りはリーダーのもとでコントロールできます。なので、どの順番で誰がどんなタスクを担当すると効率がいいのか、検討します。

＊

メンバーそれぞれ得意分野があります。メンバーそれぞれが得意分野を作業できるように担当をどんどん変えていきます。はじめの計画がよくなかったのではなく、進捗や報告を考慮しながら、最適化をし続けるイメージです。また、機能や画面構成が似ているタスクを振り分けて、キャッチアップにかかる時間を減らすようなタスク割り振りも考えます。

さらに、作業の手を止めないように、次のタスクを事前に伝えます。こうすることで、向こう数日のタスクイメージをつけることができます。タスクはWBSに記載されていますが、事前に、次のタスクの詳細や注意点を伝えるイメージです。いくつかタスクを指示すると、各自が自主的に次のタスクに手をつけてくれます。指示待ちの時間を削減でき、シームレスに次のタスクに移ることができます。

②突発対応が多く、自分のタスクができないとき

メンバーや他チームからの質問対応、お客様からの問い合わせなどは突然やってきます。そして、各種会議への参加や会議資料の作成などのタスクが差し迫ってきます。会議の数が増えてくると、自分のタスクを行うまとまった時間がとりづらくなります。自分のタスクを途中でやめたり、手を付けづらくなります。

かといって、会議や突発対応のために、自分のタスクの進捗を出せないでは困ってしまいます。自分遅れが次の人に影響してしまい、チーム全体の動きが鈍くなってしまいます。

＊

難しさを感じたのは、突発対応をしながら、スケジュール通りに自分のタスクを終わらせることです。中途半端なところでタスクを切り上げると、思い出すのに時間がかかったり、頭の切り替えがスムーズにできず初動が遅くなります。さらに、日中帯は会議や突発対応に追われて、連絡が少ない夕方以降にタスクを一気に片づけることもありました。もっと短い時間で一気に終わらせるようにしたいですね。

③どこまで指摘するか悩んだとき

レビューでも難しさを感じました。仕様書として間違っているもの、書き方としてチームのルールが守れていないものは指摘します。迷うのは、「間違っているわけではないけど、工夫の余地がある記載への指摘」です。

精度の高い仕様書を作成したいですが、スケジュールは守りたいです。その微妙なさじ加減が難しかったです。また、指摘の意図がうまく伝えられず、修正したものが指摘と違っていていたことも難しさを感じました。

＊

スケジュールが迫っていたこともあったので、結局、「最低ラインを守れていればOKとする」「2回目以降の指摘で誤字脱字や日本語の使い方のミスはこちらで直してしまう」とざっくり方針を決めて対処しました。この方針は時間の経過とともに微調整してもいいかなと思いました。

気を付けたこと

①誰がどんな情報にアクセスできるのか、考えてから話すこと

リーダーは様々な会議に出席します。よって、プロジェクトに関する情報が入ってきやすいです。一方で、メンバーや他チームの方はすべての会議に出席するわけではないので、すべての情報にアクセスできません。つまり、情報量に格差が生じます。

＊

リーダーの役割の1つに「適切なタイミングで、適当な人に情報を伝えること」があると思います。スケジュール通りに進めるために、他チームや上長の指示、お客様からの要望などメンバーにタイムリーに伝える必要があります。伝わっていないと、タスクが止まってしまいます。

ちゃんと情報を回せるように、「この人は何を聞いているのか、知っているのか」考えてから、進捗ミーティングに出席するようにしました。コツとしては、誰が情報にアクセスできるのかを考えることです。どの会議に誰が出席しているのか、フォルダへの閲覧権限が誰についているのか、を把握するようになるとみえてきます。

＊

情報格差があることを前提にすると、指示の背景を丁寧に説明するようになったり、必要なことの伝達漏れを防げたりします。会議の欠席者に決定事項などを伝えられるようになります。また、事前に情報を伝えられるようになります。情報格差を気を付けるようになって、ちょっとだけ視野が広がったような気がしました。

②改善を繰り返すマインドを持つこと

思ったように順調に進むことはあまりありません。大なり小なり何かしらの問題が振っては沸いてきます。だから、「また出たか！」と思って、その都度対策を考えて、改善を続けます。毎日、関わっている人などみんながハッピーになるには何をどうするればいいのか考え続けます。

だから、なるべく負担がかかりすぎないように、それでいて期限内に質の良いものをつくれる方法を考えます。特にチームメンバーがそろう朝会が勝負です。指示だしや調整などでチームに貢献することがPLの役割だと思います。プロジェクト最後の日まで、問題を検知して、原因を調査して、改善し続けるようと思いました。

③メモを画面共有すること・早く伝えること

リモートワークでしたので、会議は毎回オンラインで実施していました。オンラインで会議を行うときは、必ずメモを画面共有し、文字を見ならが説明するようにしていました。声だけの会議にならないように、WBSや仕様書を画面に映したりすることを心がけました。

会議は毎回、何を伝えるか準備をした上で望んでいました。朝会など進捗確認会では、簡単なメモを毎回作って、報告内容をメモに書き込んでいました。さらに、連絡事項もメモに含めて、タスクや連絡事項の伝え忘れがないようにしていました。朝会が終わると、メモをチャットに流して、後からメンバーが見返すことができるようにもしていました。

＊

お客様との会議も準備を大事にしていました。もちろん、資料を事前に作成して、会議の前日にはアジェンダとともに資料を共有するようなことは毎回続けいました。また、かなり先の予定でも早く伝えるようにしていました。こちらから見えないところで、様々な調整をしているだろうし、準備の時間を十分にとってもらって、お客様タスクの精度を上げるためです。

さらに、期限が近付いたらタスクをプッシュしていました。お客様とて遅れることはざらにあるので、ここは手を抜かずプッシュしていました。自分たちの計画だけ守れればいいのではないので。

気を付けたいこと

指示の出し方・粒度

指示の出し方がうまくなく、スムーズにタスクを進められなかったシーンがあったので、反省もかねて記載します。指示の出し方がざっくりとしすぎたことがありました。一部を抜粋すると具体的には、「WBSを確認しておいて」「仕様書を読んでおいて」「わからなかった、質問して」などです。

この指示の出し方だと、時々クリティカルな問題を発生させてしまいます。想定されうる問題は
・「そもそも確認していない」
・「確認しているが、見ている箇所が違う」
・「確認しているが、解釈が異なる」
・「質問しようにも問いを立てられない」などです。

その結果、レビューの時点で出戻りが発生したり、スケジュールを圧迫させてしまいます。

＊

指示には2つの意味があるように思えます。1つは、作業内容・優先順位・期限などタスクを進めるための必要な情報を伝えることです。もう1つは、意識づけです。さらに精度を高めるために気を付けるべき追加情報の伝達です。1つ目が最低限必要な情報で、2つ目が品質をさらに高めるための追加情報のイメージです。

「WBSを確認しておいて」だと、2つ目の「品質を高める付加情報」をまったく伝えられません。個人の能力によって精度にバラツキが出ますし、優秀な人でも勘所をつかめていないととんちんかんなものが出来上がってしまいます。

だから、以下のようことを気をつけたいです。
①「タスクを進めるための必要な情報を伝える」
・画面や機能などWBSに書かれていることを声に出して改めて伝えること
・タスクのゴールを確認すること
・進捗報告の仕方を確認すること（何をもって進捗率を測るか）
・対象機能について、仕様書の読み合わせを簡単にすること
・ゴールを確認し、共通認識を持つ
・期限を確認すること

②「品質を高める付加情報を伝える」
・注意したいポイント、難しそうなポイントをあらかじめ伝える
・どう動くのか最善なのかイメージ合わせを行う

指示の出し方に価値を見出すマネジメントになればいいなと思いました。次に指示に出すときは、これを思い出して実行するつもりです。

おわりに

プロジェクトを進めると、大なり小なりさまざまな問題が発生するものです。問題がわかったら、原因を探り、あの手この手で対策を打っていきます。設計でも、実装であってもどの段階でも、「プロジェクトの進捗の良さ」が「品質の良さ」につながります。前倒しで進められれば、テストを厚くしてバグの修正に時間をかけることができます。

＊

プロジェクトやシステムは思った以上に「生き物」でした。調子のいい悪いがありますし、思わぬところでバグが出現してきたりします。想定外の動きをされて、とても振り回されます。

ただ、プロジェクトを整えるのも人です。コミュニケーション1つでチームの雰囲気が変わったり、一事が万事のこともあります。毎回違うメンバーで違うことをしても、以前の経験を活かせることがあります。

プロジェクトを開始するときは、直近のプロジェクトの振り返りをみて、何に気を付けるのか検討を付けてはじめることもよいかなと思いました。経験をこの記事に込めてみました。少しの積み重ねを続けていくと、遠くまでいけると信じてます。

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