今世の中は分業が加速している。というよりは、分業して、専門性に特化していかなければ、競合他社との差別化を図ることが難しいからだ。そもそもの原則として、分業した方が効率的に仕事を進めることができるのは明白である。
ただ、分業したばっかりに上手く行かないと感じることも結構多いんじゃないだろうか。つまり、分業にもデメリットはありますよ、というお話だ。
私が今のチームでよく感じるのは、分業が進みすぎたばかりに作業の重複が結構発生することである。システム開発なんかをやっていると、業務系のSEと基盤系のSEに分かれて分業することも多いのだが、結局結合試験とかを始め出すと、全く同じ試験を別々に二回やる、みたいなことが頻発する。
そもそもシステムの構造上、基盤システムの上に業務APが乗っかっているので、業務APの試験を実施するためには、基盤システムを動かさなければならないし、基盤システムの試験を実施するためには、何かしら業務APを利用しなければならない場合もあるのだ。
分業していなければこれらの試験は一度で済む。まぁ分業が悪い、というよりは分業するための仕掛け作りを怠っていることが真の原因なんだけど。特に分業しているものを連結する場合には、分業したまま進められる作業、一緒にやった方が効率的なものをキチンと仕分けておく必要がある。
でも、この「仕分け」という作業をほとんどの人が意識していない。なぜならば、分業した人たちの責任範囲を超えてしまっているからだ。自分たちが考えるべき範囲でもあるけど、相手が考えるべき範囲でもあるよね、という仕事は総じて責任が不明確になり、問題を起こしやすい。システム開発でもインタフェース部分で故障が多く発生するのはこういった人間の心理も大きく関係している。
なので、プロジェクトマネージャーならグレーゾーンについて注意をしなければならないし、もし自ら監視しきれないのであれば、キックオフ（プロジェクト開始）の段階で、チームの中で主となるチームを決めておくのが良いと思う。さっきの例で言えば、業務Tにも方式（基盤）Tにも影響があるものについては業務Tが主管とする、といった感じで。少しでも曖昧な部分を無くさなければならない。
同じような話として、分業体制にすると、自分たちの仕事を進める上で、他チームの情報なりスキルなりが必要になる場合が必ずある。この他チームへの依頼作業というのが不毛で、非常に骨が折れる。以下はかなり極端な例ではあるが、こんな感じである。
1日目：
「この資料を元に〇〇の設定を反映して下さい」（業務T → 方式T）
2日目：
「この資料だけだと具体的な設定値に落とし込むことができないので、条件を整理してください」（方式T → 業務T）
3日目：
「どういう形で整理すればいいのかわからないので、フォーマットを提供して下さい」（業務T → 方式T）
もはや、要件定義の縮図である。全く持っているスキルや知識が違うチームに対して何かを依頼して、期待通りの結果を得るというのは実は結構難しいのである。
加えて、これは私の予想だけど、どうも分業体制に慣れている社会人は自分がボールを持っている状態を必要以上に嫌う傾向がある。理由は簡単で、「この仕事については〇〇チームへ依頼中です。」と言えれば、自分たちには何も非がないように振る舞えるからだ。
よって、一度依頼が発生すると、本当の仕事が全く進まない不毛なキャッチボールが繰り広げられる。結果進捗が遅延すると、「そんなもん連帯責任だ」といってもほとんど響かない。分業体制は個々の責任を明確にしているだけに連帯責任は追求されにくいのだ。
分業をしていなければこうはならない。しかし、分業をしていても、こういった機会を極力少なく余地はあるように思う。
ほとんどの場合、特にチームレベルの分業なんてものは十分に最適化されていない。なんとなくこの仕事はこのチーム、あの仕事はあのチームぐらいで分けられている。
できれば、各チームが持ち得る情報とスキルを整理した上で分業した方が良い。体制を考える上で、その人が持っているスキルをベースで考えることが多いが、その人が持ち得る情報という観点もあった方が良いと個人的には思う。
なぜなら、ぼぼ全ての仕事は、必ずスキルと情報をセットにしなければ成し得ないからだ。この辺はプログラムと全く同じである。だから、情報のやりとりが煩雑になりすぎるようであれば、分業化する意味はない。情報を仕入れるルートを変更したり、そもそもの体制を見直す必要がある。
とりあえず、分業こそが最も効率的だ、と考えるのは浅はかで、分業化するからこそ注意しなければならない点があり、それは大きく、責任範囲の明確化と伝達情報量の極小化である。これらを踏まえて仕事を進めることが大切なんじゃないか。
