チーム内の重複する役割の管理

はじめに

責任が重なる根本の原因は、多くの場合、役割の境目があいまいなことにあります。マーケターが開発者とやり取りし、デザイナーがアナリストと並んで働くような部門横断のプロジェクトでは特にそうです。こうした現場では、誰が決めるべきなのか本当にわからない「グレーゾーン」が自然にできあがります。

役割の進化が、この状況をさらに複雑にします。1年前には一人の担当者だけで済んでいた仕事が、今では何人もの専門家の意見を必要とすることがあります。技術が変わり、プロセスが込み入ってくるうちに、以前ははっきりしていた境目がぼやけていきます。

独立への意欲が三つ目の要因です。経験のある社員ほど、他の人が動かずにプロジェクトがつまずくのを待つより、自分で引き受けてしまいがちです。個人として見れば無理もない判断ですが、チームとしては同じ作業が二重に行われ、連携も崩れます。詳しくはこちら：エンジニアチーム向けプロジェクト管理ソフトウェア。

不明確な責任のコスト

• 次のステップは痛みのポイントを特定することです。チームに、誰が責任を負っているかについて混乱が生じた過去1ヶ月の状況を思い出すように依頼します。そのようなケースの数は通常、最初の期待を超えます。

RACIマトリックス

RACIマトリックスは、プロセスごとに各メンバーの役割を決めておく表です。効果が出るかどうかは、決めたルールをぶれずに使い続けられるかにかかっています。

RACIの意味:

• Responsible(実行者)：実際に手を動かす人です。一つのタスクに複数の実行者がいてもかまいません。
• Accountable(所有者)：結果に責任を持ち、主な判断を下す人です。Accountableはタスクごとに必ず一人に絞ります。
• Consulted(アドバイザー)：意見を聞いておくべき人で、たいていは隣の分野の専門家です。
• Informed(オブザーバー)：状況を知らせておく必要はあるものの、判断にあたって意見を求める必要はない人です。

実践的なアプローチ:まずは新しい社員の採用や新機能のリリースなど、具体的なプロセスを一つ選んでRACIマトリックスを作ります。チームが実例を通じて考え方をつかんだら、対象を広げていきましょう。

応用例:新機能のリリースなら、Responsibleは開発者、Accountableはプロダクトマネージャー、Consultedはデザイナーとアナリスト、Informedは経営陣とカスタマーサポートといった割り振りが考えられます。

重要な制約:どのタスクにもAccountableはちょうど一人です。二人を所有者にすると、実際にはどちらも責任を持たなくなります。

毎週の同期

定例のチームミーティングは調整のための仕組みですが、その価値はほぼ進め方で決まります。よくあるスタンドアップは、細かい議論が長引いて時間ばかりかかり、肝心の足並みはそろわないまま終わりがちです。

効果的な毎週の同期フォーマット:

• 私が計画していること(1人あたり3分):その週の主なタスクを手短に共有する
• 私が助けを必要としている場所(1人あたり2分):サポートや相談をしてほしい点を具体的に伝える
• 潜在的な重複(全体で5分):同僚の作業に影響しそうなタスクを話し合う

この形なら15〜20分で終わり、何時間分もの二重作業を防げます。組織の規模を問わず、割に合う時間の使い方です。

能力マトリックス

どのチームにも、特定のテーマについて周りから相談される非公式の専門家がいます。この専門性をはっきり書き出して公式なものにすると、誰に相談すればよいのか、意見が割れたときに誰が決めるのかで迷わなくなります。

能力マトリックスでは三つのレベルを決めます。

• エキスパート：この分野で最終的な判断を下し、同僚の相談に乗り、チーム全体の力を伸ばす責任を持ちます
• 実践者：通常のタスクを一人でこなし、必要なときはエキスパートの代わりを務められます
• 初心者：この分野を学んでいる段階で、エキスパートか実践者の指導を受けながら作業します

このマトリックスがあれば、質問を誰に持っていくか、意見が割れたときに誰がまとめるかがすぐにわかります。同じ人がある分野ではエキスパートで、別の分野では初心者ということもあります。構造としてごく自然なことで、運用のうえでも役に立ちます。関連情報：会社管理。

プロセスの透明性

プロジェクト管理ツールをきちんと設定しておくと、誰が何をしているのかがはっきりし、重複が対立や二重作業に発展する前に見つけられます。押さえておきたい原則は次のとおりです。

• 統一された情報空間:すべてのタスクとそのステータス、担当者を、チーム全員が見られる一か所にまとめます。
• ワークロードの透明性:同僚がいま何に取り組み、どれくらい手がふさがっているかを、誰でも確認できるようにします。
• 自動通知:タスクに変更があれば、手作業で連絡しなくても、システムが関係者に知らせるようにします。
• ツールのシンプルさ:きちんと手入れされたシンプルなシステムは、チームの半分が使いこなせていない高機能なシステムに勝ります。ツールの価値は、どれだけ使われているかで決まります。

ただし、問題をオープンに話し合う文化がなければ、どれほど作り込んだプロセスもあまり役に立ちません。ツールで根本のあいまいさを解消するには、その前に、自分の責任がはっきりしないと気軽に口にできる雰囲気が必要です。

関連記事:

柔軟なプロジェクト管理方法については、アジャイルプロジェクト管理:効果的なプロジェクトをお読みください。

構造化されたプロセスがどのように効率を高めるかを理解するには、PMワークフロー:プロジェクトの成功を合理化するための手順をお読みください。

分散チームを効果的に組織化する戦略については、長期的なリモートワークのためのチームの組織方法をお読みください。

結論

チームが大きくなり、プロジェクトが複雑になるにつれて、責任の境目は定期的に見直し、調整の進め方も少しずつ改善していく必要があります。目指すのは重複がまったくない仕組みではありません。すべての重複を把握して管理し、共通の成果につなげることです。構造のあいまいさや、各自がばらばらに下した判断から重複が生まれる状態をなくすことが目標です。