役割分担の罠

大規模プロジェクトが失敗する理由

プロジェクトというのは、関わる人の数が多ければ多いほど、成功させるのが難しくなる。何を持って成功とするか、失敗とするかという話もあるかと思うが、その話は一旦ここでは置いておく。規模の大きなプロジェクトの成功が難しくなる理由は様々あるけれど、人数が増えると全員で同じ共通認識を持つことが難しくなるというのが、成功を難しくする大きな要因になる。

人はそれぞれ考え方や価値観が違う。多様性が求められる時代において、考え方や価値観は人それぞれ違って構わないし、むしろいろんな考え方を持った多様な人材が集まる方が強い組織になるとよく言われている。
ただ、プロジェクトを進めていくにおいては、
・プロジェクトのゴール（目的や目標）
・ゴールへの進み方
・発生している課題と解決策
など、プロジェクトを成功に導くための大事な要素については全員で共通認識を持ち、かつ全員がその内容に納得している状態でないと、プロジェクトをスムーズに進めていくことは難しい。

小規模で関わる人数が少ないプロジェクトであれば、リーダーがプロジェクトメンバー全員とうまくコミュニケーションを取って、共通認識を持つように工夫すればある程度スムーズに進めることができる。
ただ、プロジェクトの規模が大きくなり、関わる人の数が多くなった場合、1人のリーダーが全員とコミュニケーションを取ることは実質不可能になり、機能や工程毎に役割を分担して作業を進めることになる。そうなった時、全員で共通認識を持ちながらプロジェクトを進めていくことは非常に難しく、コミュニケーション不足による認識の齟齬がおき、手戻りや想定外の事態が多く発生し、結果としてプロジェクトがうまく回らなくなる。

というのが、大規模なプロジェクトがうまくいかなくなる大きな要因。

とはいえ、プロジェクトの規模が大きくなって作業量が増えると、少人数で全ての作業をこなすのは時間がかかるし負担も大きくなる。必然的に人の数を増やし、役割分担をしながら作業を進めていくことになる。

役割分担というのは、作業を効率よく進めていくために当たり前に誰もがやていることだと思うけれど、きっちりと役割分担して作業を進めるのは、実は色々とリスクもあるように思う。最近、久しぶりに関わる人数の多い、いわゆる規模の大きなプロジェクトに関わっているのだけれど、その中で役割分担について色々と思うところがあった。すごく前置きが長くなってしまったけれど、今回は役割分担をすることのリスクについての話。

役割分担の罠

現在、そこそこ規模の大きなシステム開発のプロジェクトに参画している。私はまだプロジェクトに参加したばかりで、全体像は全く見えていないけれど、私の見えている範囲では既に４つの企業（私が所属する企業も含む）が関わっている。

その中で、
・プロジェクトを管理する人たち
・システムの仕様を決める人たち
・仕様に沿ってプログラムを作る人たち（開発部隊）
・作られたプログラムをテストする人たち（検証部隊）
と役割分担して作業を進めている。
さらには、その開発中のシステムと連携する別の外部システムを開発している人たちもいる。ちなみに私は開発部隊として、プログラムの開発を担当している。

こうやって明確に役割分担をすることで、他の工程のことを考えず自分の作業に集中することができ、一見全体の作業効率が上がりそうに見える。実際そういう側面は少なからずあるだろうと思う。けど、逆にいうと役割が分担されすぎていると、全体のことを考慮して作業する人はとても少なくなる。それが、役割分担をすることの罠なんじゃないかと思う。

人は皆、自分の都合で生きている。役割分担をして作業を進めるとき、基本的には自分が行うべき作業を中心に考えながら行動する。
設計をする立場の人は、システムの仕様をどうするかを中心に考えて行動していて、開発の人の立場や検証を行う人の立場についてはあまり考えない。
開発をする人は、どうやってプログラムを作るかを考えており、設計する人の立場や検証を行う人の立場についてはあまり考えない。
検証をする人は、検証のことを中心に考えており、設計や開発の立場についてはあまり考えない。
もちろん、全員が全員、他の工程のことを全く考えていないわけではないだろう。視野を広く持って、全体のことを俯瞰で見ながら作業をしている人もいるとは思う。ただ、明確に役割分担がされている状態では、どうしても視野は狭くなる。1人の人間が設計・開発・検証までを行うのであれば、必然的に全体のことを考慮せざるを得ないが、役割分担されている状態では、そもそも作業効率を上げることが目的なので、他の工程のことは必然的に考えなくなってしまう。

1人1人が、みんな自分の都合だけを考えて作業を進めていくとどうなるのか。当然、コミュニケーション不足による認識の齟齬が生まれる。そして、他の工程の作業をしている人たちに対しての不満が生まれる。
開発を担当している人は、設計担当者に対して、「なぜこんな雑な設計しかできないんだろう」といった不満が生まれる。
一方で設計を担当している人は、開発担当者に対して「なぜこの資料で伝わらないのだろう」といった不満が生まれる。
そして、その役割分担で組織が分かれているとより問題は厄介になる。
多くの場合、組織が違えば、その担当者がどういう人なのかを知るのが難しくなる。設計を担当している人は、開発をしている人や検証をしている人がどんな人なのか知らない。開発をしている人は、設計をしている人や検証をしている人がどんな人なのか知らない。
同じプロジェクトでありながら、一緒に働いている人がどういう人柄かも知らない、どういう経歴を持っているかも知らない、どんな顔なのかも知らない場合もある。どんな人なのかわからないが故に、自分の作業が思い通りに進まない時、相手に対してより一層不満が溜まりやすくなってしまう。

設計者には設計者の都合がある。開発者には開発者の都合がある。プロジェクトの中で作業をしている人は、みんな何かしら自分なりの都合や課題があり、それぞれの文脈やナラティブ（物語）があり、それぞれが自分なりの根拠を持って作業に取り掛かっている。
お互いがお互い、相手がどういう文脈で、どういう経緯でこの作業に取り組んでいるのかを理解しようとすれば、認識の齟齬や不満はきっと少なくなる。けど、そもそも相手の素性が全くわからない状態だと、その人の意図を汲み取ろうとすることすら面倒になる。

素性がわからない人どうして役割分担をしてしまうと、相手のことを理解しようとする気持ちがどうしても薄れてしまう。これが、プロジェクトの失敗につながる一つの要因になっているような気がする。

架け橋を作る人物

工程ごとにきっちりと役割分担をすると、他の工程のことを考えなくなるので、認識の齟齬や不満が発生しやすくなる。とはいえ、人数が多いプロジェクトで全員に全ての工程を経験させるのは流石に効率が悪すぎる。作業を効率よく進めるためには、役割分担というのはやはり必要なことだと思う。

お互いの人柄を理解するために、プロジェクトに関わる人たちみんなで飲みに行って親睦を深める。というのも一つの案としてなくもないけど、根本的な解決策としてはそういうことではないし、今はきっとそういう時代でもないだろうと思う。そもそも関わる組織が物理的に離れていることも珍しくない。

解決の鍵となるのは、それぞれの工程の架け橋を作る人物がいるかどうかだと思う。設計と開発で役割を分割するとき、設計と開発両方の知見がある人を両者の架け橋として置いておき、設計担当者と開発担当者はその人物を経由することによってお互いの認識の齟齬をなくす。これができれば、役割分担というのはきっとうまく回る。

その架け橋となる人物には、プロジェクトに関する知見とともに、それぞれの工程の立場を理解しようとする姿勢が重要になる。
以前、「他者と働く」という本の記事を書いたが、多分その内容がすごく参考になるのではないかと思う。

本来、この役割を担うのはプロジェクトマネージャーやプロジェクトリーダーと呼ばれる立場の人たちなんだと思う。

ただ残念ながら、今私が関わっているプロジェクトにおいては、このような架け橋の役割をに担っている人は見当たらない。そして、このような状態になっているプロジェクトはきっと数多くあるのだろうと思う。

久しぶりに関わる人の数が多いプロジェクトを経験して見ると、色々と学べるものがありますね。

他者と働く──「わかりあえなさ」から始める組織論 (NewsPicksパブリッシング)