PMは認知負荷を甘く見てはいけない

2022年4月1日 19:22

どうもVoicyプロダクトマネージャーのエモジマ(@kitajima_snooze)です。

PMがタスク管理をどれくらいキッチリやりたがるか？はタイプが分かれますが、ボクは結構キッチリしたいタイプです。
理由はシンプルで、ルールがはっきり決まった運用はコミュニケーションの負荷を低減し、クリエティブな議論に時間を割けるからです。

生産性を考える上で、認知負荷やコミュニケーションコストを甘く見てはいけないというお話です。

※この記事は、Voicy PdM Teamのマガジンにまとめられています。気になったらマガジン自体もフォローしてね！

ボクはプロジェクトマネージャーから少し脱皮したい

Voicyのプロダクトチーム内でのボクの役割は、どちらかというとPjM(プロジェクトマネージャー)寄り。

どんなプロダクトを作るか？を考えるよりも、開発現場を回すことを注力することが多いポジションです。
(以下図は、弊社PMチームのリーダーの記事より)

直近のボクの課題は、

・開発PJではなく、よりプロダクトと向き合う時間を増やしていく
・そのために現場マネジメントを、開発者に権限委譲していく

といったことが挙げられます。
(上図でいうと、左から右に軸足をズラしていく感じ)

プロジェクトマネージャー(以下PjM)の仕事のメインは、コミュニケーションだと思っています。

同時進行する開発の状況を1番分かっているのはPjMであり、それぞれのタスクの概要や進行状況などを網羅的に把握しています。
そのため、実装するエンジニアと確認の頻度は多く、他部署のステークホルダーとも関わりが多くなるため、必然的にコミュニケーション量が多くなります。

つまり、PjMは簡単にボトルネックになりやすいということです。
PjMの確認待ちで、エンジニアの手が止まるといった状況は容易に起こり得るのです。

そのためチーム状況把握にかかる認知負荷が低い状態を保ち、可能な限り不要なコミュニケーションを減らすことは非常に重要です。

１つのタスクにおいて、確認する観点は複数存在します。

これらをタスク管理ツールで管理するとして、１つのタスクの状況を把握するにおいて認知負荷のレベルを以下に段階わけします。

１→ 4 にかけて認知負荷は高まり、理解するまでに時間がかかります。
また、誰かに確認しないと理解できない、もしくは決まっていないといった状態の場合にコミュニケーションが発生します。

例えばタスク管理ツールで、以下のタスクが起票されていたとします。

佐藤さんが対応している不具合修正のタスクであることは、ぱっと見で直ぐにわかります。
優先度はリスト表示には出ていませんが、１クリックで詳細欄を覗けば見ることが出来るので、簡単に把握できます。

しかし、このタスクが今どこまで進捗をしているのか？は、佐藤さんに確認しないと把握できません。
また、具体的な不具合の内容は別のシートを参照して確認してからでないと会話ができません。別シートを探すのに手間がかかり、連絡をする前にもう少し時間がかかります。

タスク管理のルール化、習慣化が出来ていないと、このような認知負荷の高いタスクの確認に時間がかかり、いたずらにコミュニケーションコストは高くなっていきます。

チームの人数が増え、捌かれるタスクの量が多くなればなるほど、負債として積み上がっていくのです。

これらの課題を解決するために、まずタスク管理ツールの使い方をチーム全体に周知し、運用の習慣化を試みることに。

そして、ひとつひとつのタスクを管理する責務をエンジニアが持つように組織体制を変えました。
PjM１人がハブになってタスクを管理する体制から、エンジニア全員がタスクの進行管理と進捗報告するようシフトチェンジしたのです。

そうすることで、PjMがコミュニケーション上のボトルネックになるのを防ぎ、かつエンジニアも開発に対してより当事者意識を持てるようになります。

デイリーでタスク状況を報告する際にも、エンジニアが持ち回りでファシリテートし、チーム全員がお互いが何をしているかを把握できるようになりました。

世間じゃこれを単に”スクラム”と呼んだりするのかもしれません。
しかし巷で流行りのフレームワークを考えなし導入したわけではなく、ボクの立場からは、「認知負荷」「コミュニケーションコスト低減」という観点を重視した結果だったと言えます。

この記事が気に入ったらサポートをしてみませんか？