エンジニアのプロジェクトリーダー、どうやり切る？

はじめに

エンジニアの M.Yoshiakiです。
最近、プロジェクトリーダー(PL)を担う機会が増えたので、これからPLを担当する方、したい方向けに、PLをやり切るためのポイントを自分なりにまとめてみました。
わかりやすいように、実際のプロジェクトを一例にあげて紹介します。

タスクの内容と役割

ご紹介する案件は、2か月半で設計からリリースまでを行うプロジェクトでした。メンバーは4~5人。他案件を掛け持ちするメンバーもいました。

・自身の役割：PL
・タスクの内容
進捗会議進行／お客様対応・会議出席／上長への報告／他チームとの連携
タスク管理／進捗管理／ドキュメント作成／レビュー（設定書、ソース、テスト設計）／テストのサポート

どんなところに難しさを感じたのか

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

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

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

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

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

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

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

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

かといって、会議や突発対応のために、自分のタスクが進行できないでは困ってしまいます。自分の遅れが次の人に影響してしまい、チーム全体の動きが鈍くなってしまいます。
また、中途半端なところでタスクを切り上げると、思い出すのに時間がかかったり、頭の切り替えがスムーズにできず初動が遅くなります。

こういった状況の解決方法は二つ。
夕方は会議が少なく、まとまった作業時間をとれることが多かったので、重たいタスクは夕方にまとめて行いました。1日のうち、業務サイクルを意識してタスクを割り当てていく方法です。
もう一つは資料のたたき台をかなり早めに作っておくことです。
資料の作り始めは時間がかかるので、作業を見越して早めに着手しておきます。その後資料の期限が近くなったら全体を見直してちょこちょことした修正を加える形で、進行に遅れが出ないよう調整をしていました。

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

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

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

どんなことに気を付けたのか

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

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

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

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

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

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

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

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

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

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

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

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

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

PLを経験して気づいた、細かいけど重要なこと

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

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

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

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

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

この気づきを反映して、情報伝達に必要なポイントをまとめてみました。

①タスクを進めるための必要な情報を伝える

・画面や機能などWBSに書かれていることを声に出して改めて伝えること
・タスクのゴールを確認すること
・進捗報告の仕方を確認すること（何をもって進捗率を測るか）
・対象機能について、仕様書の読み合わせを簡単にすること
・ゴールを確認し、共通認識を持つ
・期限を確認すること

②品質を高める付加情報を伝える

・注意したいポイント、難しそうなポイントをあらかじめ伝える
・どう動くのか最善なのかイメージ合わせを行う

指示の出し方に価値を見出すマネジメントになればいいなと思いました。

おわりに

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

プロジェクトやシステムは思った以上に「生き物」でした。
調子のいい悪いがありますし、思わぬところでバグが出現してきたりします。想定外の動きをされて、とても振り回されます。
ただ、プロジェクトを整えるのも人です。コミュニケーション一つでチームの雰囲気が変わったり、一事が万事のこともあります。違うメンバーで違うことをしても、それまでの経験を活かせることがあります。

プロジェクトを開始するときの振り返りとして、何に気を付けるべきか、自身の経験をこの記事に込めてみました。
最後まで読んでいただいた方、ありがとうございました。

※1：WBS＝Work Breakdown Structure(作業分解構成図)
プロジェクト全体を細かなタスクに分解し、粒度・順序をそろえたツリー構造で、タスクの抜け漏れ防止や全体像を把握する手法のこと。

※この記事は、Qiitaの記事を一部更新して転載しています。
https://qiita.com/aki_number16/items/9b67a709554c4b37ad9b