この記事のプロジェクト規模や立場の前提
本記事で想定しているのは、プロジェクトメンバーが100人規模（1か月あたり）の大規模な開発プロジェクトです。この規模になると多くのチームが必要になり、チームリーダーも階層化され、リーダー数も多くなります。この状態で起きる、とある課題をどうマネージすべきかについて触れていきます。
課題に載せにくい、”人”に関する課題
課題管理台帳を運用しているプロジェクトで、「この課題、台帳に載せるべきかな？」と判断に迷う瞬間があります。特に悩ましいのが、人の能力や状況に関する課題です。
例えば、家庭の事情で勤怠に制約があるメンバー、退職の意向を持っているメンバー、メンバー間の人間関係の問題、技術知識やスキル・マインドが不足しているメンバーなど、こうした課題はプロジェクトの成否に直結する重要な問題です。しかし、みんなが参照できる課題管理台帳には載せづらい。PM/PMOとして、このジレンマに直面した経験はないでしょうか。
仕様や技術的な課題は迷わず台帳に載せられます。一方で、人に関する課題は慎重な扱いが求められます。万が一、人に関する課題が、見られてはいけない人に見られてしまうと、ぎくしゃくした関係が生まれるなどプロジェクトに深刻なリスクを抱えることになります。
人に関する課題はクローズドな課題管理台帳で管理すべき？
人の能力や状況に関する課題について、現場ではリーダーメンバーだけが見られるクローズドな台帳で管理することが多く見られます。
クローズドな台帳で管理する理由は明確です。みんなが参照できる課題台帳だと、特定の個人を責める記述にならないよう問題をはっきり書かなくなるためです。「Aさんのスキル不足により設計品質が低下している」とは書けず、「設計品質の向上が必要」といった曖昧な表現になってしまいます。これでは本質的な問題が見えなくなり、適切な対策が打てません。
そこで、リーダー層だけがアクセスできる台帳を用意します。
クローズドな台帳なので、センシティブな話題についても具体的に表現できるようになります。「スキル不足」ではなく「SQLの基礎知識が不足しており、データ抽出に時間がかかっている」と具体的に書けます。「コミュニケーション面に課題がある」ではなく「質問に対する回答が曖昧で、認識齟齬が頻発している」と明確に記述できます。問題が具体的になれば、対策も具体的に考えることができるようになります。
クローズドな管理台帳の問題点
しかし、クローズドな台帳で管理するアプローチには、いくつかの問題点があります。
１．課題の対象者によって公開範囲を変えた台帳をバラバラと作る必要がある例えば、リーダー間で共有する、プロジェクトメンバーに関する課題管理台帳があったとします。リーダーの一部に課題がある場合、その台帳はリーダー間で共有しているのでその課題は記載できません。その結果、課題のあるリーダーを抜いた台帳を作ることになります。
２．台帳が分散して管理が煩雑になる
結果として、更に上位のPM・PLメンバーだけが見られる台帳を作る、というようにどんどん細分化していってしまい、複数の管理台帳を運用することになってしまい、管理が煩雑になっていきます。また、時間の経過とともにメンバークラスだった人がリーダーになり、リーダーグループに参加することになった、とします。その場合、過去、リーダーメンバーで管理していた台帳も参照できるようになりますが、その人に関するセンシティブな内容がないか？などと気を付ける必要があります。
結局のところ、大規模な開発プロジェクトでチームリーダーが多くいるような場合には、個人のスキル・状況に関する課題は台帳管理に向かないと言わざるを得ません。
Slackのプライベートチャネルなどクローズドコミュニケーションで人の課題を見える化する
そこで私自身が実践したのは、Slackのプライベートチャンネルなどのクローズドなコミュニケーションで人の課題を管理するという方法です。
この方法を実践する上で、いくつか重要な注意点があります。
まず、必要以上にクローズドな会話を増やさないことです。
気を使いすぎてクローズドな会話が増えると、コミュニケーションパスが増え、煩雑で風通しが悪くなります。本当にクローズドにすべきかを常に問い直す必要があります。 ではどういう場合にそうせざるを得ないのか。
その判断軸となるのが、
・「その情報が公になった場合に、プロジェクトにマイナスの影響を与えるかどうか」
・ 「その情報が公になることを、本人が望むか」
です。
例えば、ネガティブな理由でキーマンが退職するという情報は、現場でのモチベーション低下を招きかねません。この場合は、限定メンバーでのクローズドな管理が必要です。一方、3ヶ月後に産休に入る、育休に入るというケースは、本人が嫌でなければ隠す必要はありません。むしろオープンに共有して、チーム全体で体制を考えるべきです。
次に、SlackなどのチャットツールではDMでなくプライベートチャネルを作成します。
DMだと過去のやり取りを見つけづらくなるため、プライベートチャネルで履歴を残しやすくします。メンバーは必要最小限に絞り、課題の対象者や影響範囲に応じて柔軟に設定します。
最後に、プライベートチャネルのメンバー構成は定期的に見直すことです。 プロジェクトの進行に伴い、課題の対象者や関係者は変わります。古いメンバー構成のまま放置すると、不適切な情報共有になるリスクがあります。あるいは新しく加えたメンバーが自分に関する過去のやりとりを目にしてしまうのも気まずいものです。
見える化こそが課題コントロールの第一歩
課題管理において最も重要なのは、見える化されたものは解決することができるという原則です。
プロジェクトにとって、見えていないものがリスクです。人の能力や状況に関する課題を「載せにくいから」「言いづらいから」と放置すれば、それは多くの場合、後日、プロジェクトの足を引っ張ることになります。
一般的な課題管理台帳では、仕様や技術的な課題は載せやすいものの、人に関する課題は見落とされがちです。なぜなら、台帳に載せにくいからです。結果として、プロジェクトの成否を左右する重要な課題が、一部の人が抱えたまま悪化していきます。
プライベートチャネル、対面も組み合わせて、適切な範囲で情報を共有し、センシティブな課題も具体的に議論できるようにすることで、問題を見える化して適切な対策を打つことができます。
ただし、何でもかんでもクローズドにすればよいわけではありません。「公になった場合にマイナス影響があるか」「本人が公開されることに拒否感はないか」という基準で判断し、本当に必要な場合にのみクローズドな管理を行う。このバランス感覚が、PM/PMOには求められます。
完璧な正解はありません。しかし、人に関する課題から目を背けず、その課題を見える化し、適切に管理するという姿勢こそが、プロジェクトを成功に導く鍵となります。
