ソフトウェアエンジニアリングの世界では、エンジニアに、チームをまたいでプロジェクトやプロダクトを掛け持ちさせるアサインメントを強いることがある。いわゆる兼務と呼ばれるものの一形態だ（以降、この形態による兼務を単に「兼務」と呼ぶ）。
組織設計においてマネージャーを大いに悩ませるのは、人材面での制約だろう。人的リソース（human resource, 人的資源）と呼ばれるように、資源には限りがある。他の経営リソースと違って個々が無二の存在であるから、その制約はさらに、個別の事情までもが複雑に絡み合う。だから兼務による人的リソースのアロケートは、マネージャーにとって、複雑で厳しい制約に柔軟性を持たせる魔法の杖となる。
しかし、兼務には大きなコストがつきまとう。そのコスト自体の可視性が低いためか、組織を設計する上で、兼務に伴うコストが軽視されているように感じている。
いや、兼務者が、参加するチームそれぞれに100%の時間を割けないことは自明だ。これは、兼務を選択する上での前提条件であり、十分に理解されているだろう。そうではなく、兼務がチームの独立性を落とすことが問題なのだ。それがチームの足を引っ張り、プロジェクトを遅らせる。
このトレードオフによるコストを十分に評価した上で、兼務するか否かの意思決定が行われるべきだろう。コストが効果を上回るなら、その兼務は破棄すべき選択肢となる。
本稿ではこのトレードオフを扱う。兼務がどのようにチームの独立性を阻害するのか、どのようなコストを支払うことになるのかをひも解いていく。また、兼務という選択が正しい判断であるかをケースごとに検討し、より良い選択の模索を試みる。
兼務の問題点
チームの独立性はパフォーマンスの源泉
エンジニアリング組織を設計する上で、チームの独立性は、何より重視すべきパラメータだと考えている。独立性の高いチームは、チーム外部の影響を受けることなく、プロジェクトの計画を決め、実行できる。ユーザー価値、ビジネス価値を迅速に生み出せるということだ。
このように独立性は、チームのパフォーマンスを左右する重要なファクターなのだが、その評価は難しい。それ自体が、定量的な尺度ではないためだ。
しかし、いくつかの観点をもとに、チームの独立性の高低を見極めることはできる。そのひとつが、チームによる「リソースの利用」に対する独立性だ。
チームが責務を果たすには、その実行に足る権限とともに、リソースが必要だ。人材や設備、予算、情報が揃っていなければならない。これらの要素のいずれかひとつでもチームの単独判断で利用できないなら、それがチームの活動を阻害する大きな要因となる。兼務を問題視しているのは、この「人材の利用」の独立性に抵触する組織設計だからだ。
兼務によるチーム間結合度の上昇と独立性の低下
兼務は、複数のチームで人的リソースをシェアするアーキテクチャだ。シェアすれば必然的に、リソース利用にコンフリクトが生じる。このコンフリクトの解決や、そもそもコンフリクトさせないための合意アルゴリズムの導入、あるいはスケジューリングの必要性が、チームとチームの結合度を高めてしまう。
ソフトウェア設計では、モジュール間の結合度を下げることが、モジュールの独立性を高める上で良いとされている。組織設計もその原則は同じだ。チーム間の結合度が高いと、チームの独立性は低くなる。兼務は、兼務者を挟んでチームとチームを結合し、互いを縛り付けるチェーンのようなものだ。これではあまりに身動きが取りづらい。兼務の選択は、チームの独立性を失うこととトレードオフの関係にあるのだ。
では、兼務によってチーム間の結合度が上がり、チームが独立性を失うことで、具体的にどのようなコストを支払うことになるのだろうか。
兼務のコスト
チーム間の密結合状態が生むコスト
チーム間の密結合状態が直接的な原因となって生じるコストは、主に、「調整コスト」と「遅延コスト」の二種類が考えられる。
調整コスト
兼務者の作業時間をいつからいつまで確保するかは、チームの一存では決められない。兼務者を挟んで結合されたチーム間で調整することになる。この調整を行う中で消費される時間やお金といったリソースを、調整コストと言う。
ソフトウェア開発プロジェクトは、常に不確実性との戦いだ。計画に無い出来事が次々と発生する。だから、兼務者のスケジュールをチーム間で厳格に取り決めてしまうと、プロジェクトが立ち行かなくなってしまう。トラブルへの適宜対応が可能となるよう、スケジュールを臨機応変に組み替えられるようにしたい。しかし、その実現と引き換えに、調整コストはさらに大きく膨らむこととなる。
遅延コスト
調整コストを支払ったからといって、兼務者の作業時間がチームの思い通りになるわけではない。その影響は、プロジェクトのスケジュールとして現れる。
兼務者の作業時間の都合がつかないために、プロジェクトの開始予定日を、チームの希望より後ろ倒しにせざるを得ないこともある。また、兼務者という制約がクリティカルチェーンとなって、計画上のプロジェクト期間をより長くさせてしまうこともある。いずれにしても、リリース予定日は、チームの希望より先延ばしになるだろう。
ソフトウェアプロジェクトが価値を生み出すのは、その成果物がリリースされてからだ。リリースが先延ばしになればなるほど、ユーザーやビジネスが本来得られるはずであった価値が目減りする。こうして失われる利益を遅延コスト（CoD, Cost of Delay）と言う（参考『遅延コスト回避中心のPBIライフサイクルマネジメント』）。
遅延コストにつながる兼務の制約は、プロジェクトの計画に影響を及ぼすものだけでない。プロジェクトの実行にも強い影響力がある。プロジェクトの進捗に遅れが生じた時に、兼務者を介してその影響が通常より酷くなる傾向があるのだ。
例えば、先行タスクが遅延したとしよう。兼務者は予定日に担当タスクを開始できなくなる。それを待っている間に、別チームの担当タスクの開始日になってしまう。こうなると、マルチタスクで進めるか、いずれかのタスクの予定を変更するか、何らかの手段で乗り切ることになる。どちらにしても、プロジェクトの進捗は大きく遅延する。
兼務者自身がタスクを遅らせてしまった時も同様だ。遅延を取り戻そうと頑張っている間に、別のチームのタスクに取り掛かる予定日になってしまう。
このように、ひとつのプロジェクトの進捗の遅れが、複数のチームに飛び火していく。こうしてリリースが遅れ、遅延コストが膨らんでいく。
その他のコスト
チーム間の密結合状態が直接的な原因ではないが、「コミュニケーションコスト」と「スイッチングコスト」も、兼務によって増加するコストとして挙げられる。
コミュニケーションコスト
プロジェクトはたいてい、それごとに複数の会議体を持っている。兼務者は、兼務しているチームの数に比例して、参加しなければならない会議の数が増える。
こうして増加したコミュニケーションコストにより、兼務者の開発時間は大きく削られることになる。
スイッチングコスト
兼務者の業務は、マルチタスクが起こりやすい。マルチタスクが、コンテキストスイッチによるオーバーヘッドを生むことはよく知られている。このオーバーヘッド時間がスイッチングコストだ。
ジェラルド・M・ワインバーグによると、タスクの並列数が2になると、スイッチングコストによって稼働時間の20%をロスし、並列数が3だと40%をロスするという（『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』 ジェラルド・M・ワインバーグ（著） 増田信爾（訳） 共立出版 1994）。
兼務の再考
兼務を選択した目的
ここまでで、兼務によって失うものを見てきたが、逆に、兼務によって得ようとしたものとは何だったのだろうか。
兼務を選択した目的として考えられる代表的なものを、以下に挙げる。
エンジニア不足を補う
組織は複数のプロジェクトを抱えているものだ。その数や規模に対し、一時的、あるいは常態的にエンジニア不足が起きているケースも多いだろう。
こういう状態にある組織のマネージャーは、兼務ながらもメンバー数を揃えることで、チームを機能させようとする。
エキスパートに頼る
どこのチームにも、特定の領域に精通したエキスパートが存在する。そして、唯一の存在であることが多い。それゆえに、ただ一人しかいないエキスパートがチームから抜けると、担当していた業務の効率が著しく損なわれたり、業務の継続が不可能な状況に陥ってしまう。
だから、エキスパートを別のチームに参加させなければならなくなった時、元のチームに籍を置いたまま、別のチームにも参加させることを考える。そうすることで、業務効率を落とすことなく現状を維持できる。
エースに頼る
飛び抜けて優秀なエンジニアの生産性は、とてつもなく高い。平均的なエンジニアに比べ、数倍の違いがあるとも言われている。エースと呼ばれるエンジニアたちだ。
マネージャーとしてはやはり、可能な限りエースに活躍して欲しいと考えるだろう。こうして優秀なエンジニアは、多くのプロジェクトに関わることになる。
稼働率を上げる
チーム内でのタスク割り当てだけでは、一部のエンジニアが時間を持て余してしまうことがある。マネージャーにとって、エンジニアの稼働率が低い状態が続くことは、ムダに思えてしまう。
このようなケースでは、稼働率が低いエンジニアの余った時間を他のチームの業務にあてることが、全体最適だと考えることは自然だ。その手段として、チームメンバーを他のチームに兼務させることになる。
兼務以外の選択肢
はたして、兼務を選択した目的はそもそも課題定義として正しかったのだろうか。先述のケースそれぞれの原因をもう一段深掘りし、兼務以外の選択肢を検討してみよう。
現状に対するエンジニア不足を補うより、選択と集中を
エンジニア不足は、ビジネスやプロダクト開発に戦略が無いからかもしれない。
「不足」とは、相対的な尺度だ。人的リソースはそもそも制約であり、プロジェクトすべてに理想的で完全なリソースを割り当てることはできない。だから、プロジェクトに優先順位を付け、今やるべきことを絞り込み、そこにリソースを集中的にあてる。この優先順位付けのアルゴリズムこそが、戦略だと考えて良い。
したがって、戦略が無ければ優先順位付けアルゴリズムも存在しない。あらゆるプロジェクトが、同列で稼働することになる。やることを絞り込んでいないから、リソースは分散する。結果、エンジニア不足に陥る。
これが当てはまるなら、戦略を立て、やるべきことの絞り込みに取り組むと良い。
とは言え、複数のチームを取りまとめる立ち場にあるマネージャーでなければ、この取り組みを進めることは難しい。そのような立ち場にないならば、適切な人物に現状を説明して協力を仰ぐのが懸命だろう。
ただ一人のエキスパートに頼るより、属人化を解消する
エキスパートが一人しか存在しない状態は、業務の属人化が深刻である証だろう。この状態を問題としてとらえ、解決しようとすると、それなりの時間を要してしまう。兼務という選択肢を選んだのは、その時間や、一時的な効率悪化を嫌ってのことだろう。
業務が属人化することを「どんな場合でも悪である」とは思わないが、少なくとも三つの観点で問題を抱えることを念頭に置く必要がある。
一つめは、リスクマネジメントの観点。属人化した業務は、会社からそのエキスパートが去ると、継続が困難になる。
二つめは、ビジネス戦略の観点。戦略が変われば組織も変わる。変化に応じて、柔軟に人を配置させたい。しかし、属人化した領域にあるエキスパートは、その領域に固定されたままとなる。結果、人材配置の面で自由が奪われ、変革が不十分なものとなってしまう。
三つめは、キャリア形成の観点。長期間、特定のエンジニアを一つの業務に縛り付けることは、エンジニアとしての可能性を奪うことになりかねない。属人化という形であれ、エキスパートになるほどだから、優秀な人材に違いない。それに、チームが手放さない人物であるからには、まわりからの信頼も厚いのだろう。だからこそ、いつまでも一所に留めておくには惜しい才能だ。これは、本人にとっても会社にとっても好ましい状態とは言えない。
属人化してしまった業務からは、あえてエキスパートを引き剥がす勇気も必要だ。一時的に業務効率は落ちるかもしれないが、長期的に見れば良い結果につながるだろう。
常にエースに頼るより、チームメンバー全体に経験を積むチャンスを
エースに頼り過ぎると、周囲のエンジニアは簡単な仕事しか経験できなくなる。その状態が続くと、エースとそうでないエンジニアの差は益々広がる。この状態も、ある意味では属人化と言える。
エースでなくとも、エンジニアは、経験し、失敗することで成長を続けられる。それはエンジニアとして働く上での彼らの権利でもある。
それに、後進が育たなければ、将来のいずれかの時点で組織が破綻することは目に見えている。目先の利益を優先するばかりでなく、将来を見据えた体制作りも考えるべきだろう。
目先の稼働率を上げるより、チームや役割の責務を見直す
ビジネスの目的を「ユーザーに価値を届けること」だと捉えると、注目すべきは「人の稼働状況」よりも「タスクの進行状況」だ。プロジェクトは、成果物をリリースするまで価値を生み出さない。そして、リリースが遅れるほど、その期間に得られるはずであった価値が、無となってしまう。だから、プロジェクトを最短距離でゴールに導くことこそ最優先とすべきなのだ。兼務によってチームの独立性を落とし、タスクの進行状況を悪化させることは、可能な限り回避したい。
業務時間を持て余すのであれば、それは組織設計を見直すべきだろう。チームのメンバー数を減らした上で役割を集約することや、チームの責務を広げるといった方法で、適正な業務量が割り当たるようになるだろう。
最後に
本稿では、兼務がどのようにチームの独立性を阻害するのか、どのようなコストを支払うことになるのかをひも解いてきた。また、兼務という選択が正しい判断であるかをケースごとに検討し、より良い選択の模索を試みた。これらを読み終えて、兼務というアサインメントの選択に対し、これまでより慎重になっただろうか。
また本文では触れなかったが、兼務について考えるなら、兼務者のメンタル面についても注意しなければならないだろう。
兼務者は、プロジェクトにオーナーシップを持てているだろうか。会議やスイッチングコストに時間を取られ、開発が進まないことにストレスはないだろうか。自分がチームのボトルネックになっていると感じていないだろうか。
1on1などを通じてケアを続けているとは思う。しかし、ただでさえ把握することが難しいメンタル面の動きを、兼務はより複雑にしかねない。これは、マネジメントコストを拡大する。そして、チームメンバーが不安定な状況にあると、チームの舵取りも難しくなる。失敗すれば、プロジェクトは価値を損なう。
兼務が直接的、間接的に引き起こす相互作用は複雑だ。ソフトウェア設計と同じように、組織設計もシンプルなアプローチを選択する方が良いだろう。
