兼務による体制構築はプロジェクトの効率を損なわせる
ソフトウェア開発プロジェクトは、「兼務」を用いるチーム編成が多用されやすい対象ではないでしょうか。エンジニアであれば誰もが経験したことがあるでしょう。1人で複数のプロジェクトやチームを掛け持ちするあれです。マネージャーであれば、組織の人的リソース配置を考える時の手段の1つとして用いたことが何度かあるはずです。
しかし、兼務が引き起こす様々な弊害や問題については、あまり意識されないまま多用されているように感じます。
たとえば、兼務者本人にとってプロジェクトの掛け持ちは、仕事のマルチタスク化やミーティングの増加に苦しむ原因になります。組織の観点からも、兼務への依存は、知識の偏りや負荷の偏りという弊害をもたらすことに繋がりかねません。プロジェクトの観点から見ると、兼務という形での「人的リソースの共有」は、プロジェクト間での「リソースの競合」を引き起こしやすく、それが市場投入までの時間を長くする要因となり得ます。
本記事では、自社ソフトウェアプロダクト開発において兼務体制を採用する背景と、そこで生じる問題を深堀りし、解決策について考えてみようと思います。
兼務が多用される背景
1人で複数のプロジェクトやチームを掛け持ちするいわゆる「兼務」は、めずらしい編成ではありません。組織設計の視点で言えば、これは複数チーム間での「メンバー共有」です。さらに言い換えれば、「人的リソースの共有」と表現できます。
ヒト・モノ・カネなど、その種類に関わらず、リソース（経営資源）は有限だからこそ、マネージャーらは日々、頭を悩ませます。組織が最大のパフォーマンスをあげるために、もっとも効率の高いリソースの分配、配置を見出すことに苦心するのです。
様々なリソースの中でも人的リソースは、組織設計やチーム設計を進める上で、効果的な配置が難しい存在です。一人ひとりがユニークな存在だからです。単純に、頭数だけ揃えれば良いというものではありません。
人的リソースのこうした有限性やユニーク性を背景としつつ、兼務という手段の選択にいたる代表的な理由として、次の4つがよく見られます。
エンジニア不足を補う
エンジニアのリソース効率を高める
エキスパートを活用する
エースを活用する
背景1: エンジニア不足を補う
ソフトウェア開発組織では、一時的、あるいは常態的にエンジニア不足が起こるものです。組織が複数のプロジェクトを常に抱えているからです。並走するプロジェクトの数は一定ということはなく、少ない時期もあれば多い時期もあります。プロジェクトの規模も様々でばらつきがあります。この2つの要因によって、組織全体で必要となる人的リソース量が一定になることはありません。こうして、組織のキャパシティを超えることがしばしば起きるのです。
こうした人手不足の状況に対して、マネージャーは、兼務ながらもメンバー数を揃えることでチームを機能させようとすることがあります。もちろん、兼務によって組織の人的リソース量が増えるわけではありません。外部からのリソース調達も見込めない中の苦肉の策です。兼務することになったメンバーの業務負荷が一時的に高まることは理解しながらも、各プロジェクトへのリソース配分やスケジュールを上手く調整したり、アサインするタスクを上手く工夫することで、負荷の削減に繋げることを期待して配置するのです。
背景2: エンジニアのリソース効率を高める
兼務は、エンジニアのリソース効率を高めるために利用されることもあります。限りあるエンジニアの業務時間を無駄にせず、できる限り隙間なくプロジェクトに関する業務で埋め尽くそうという試みです。1つのプロジェクトだけでは100%の稼働に満たないメンバーは、他のプロジェクトにもアサインすることでリソース効率を高めることができます。こうして1人のメンバーが、2つ、3つと複数のプロジェクトを掛け持ちする体制を作りあげるのです。
背景3: エキスパートを活用する
組織に存在する希少なエキスパートをできる限り活用しようとして、彼らにプロジェクトを掛け持ちさせることもあります。ここでのエキスパートとは、特定の領域において専門性の高いスキルや深い知識を有しているエンジニアです。そういった存在は多くいるものではありません。特に、数少ないエキスパートが存在する領域に、複数のプロジェクトが関係している時、エキスパートはそれらのプロジェクトを掛け持ちすることになります。
エキスパートによる兼務は、チーム異動を起因として発動することもあります。何らかの理由でエキスパートを別のチームに異動させることになった時、元のチームに籍を置いたまま、別のチームにも参加させるのです。ただ一人しかいないエキスパートがチームから抜けると、担当していた業務の効率が著しく損なわれたり、業務の継続が不可能な状況に陥ってしまうという理由です。エキスパートがチームを掛け持ちすれば、これを補うことができます。これは、属人化によって生じる兼務です。
背景4: エースエンジニアを活用する
エキスパートと同様に、エースエンジニアの存在も希少価値であるため、プロジェクトの掛け持ちによって、彼らの活躍の場を増やそうとすることもあります。飛び抜けて優秀なエンジニアのパフォーマンスは、とてつもなく高いものです。平均的なエンジニアと比べて2.5倍、もっともパフォーマンスが低いエンジニアと比べて10倍のパフォーマンスがあるとも言われています。マネージャーとしてはやはり、可能な限りエースに活躍して欲しいと考えます。こうして優秀なエンジニアは、多くのプロジェクトに関わることになるのです。
兼務によって生じる弊害
兼務によるチーム間でのメンバー共有は、マルチタスク、ミーティングの増加、知識の偏り、負荷の偏りなど、様々な症状として組織にあらわれます。
弊害1: マルチタスク
プロジェクトを掛け持ちするメンバーが、マルチタスクで作業を進める現場は多くあります。あるプロジェクトからアサインされたタスクに取り組んでいる最中に、また別のプロジェクトのタスクに着手するのです。そうして複数のタスクをまんべんなく進めていきます。
兼務によるマルチタスクは、いずれのプロジェクトのタスクを優先すべきかの明確な基準がなく、判断が本人に委ねられている時に発生しやすい問題です。それぞれのプロジェクトからは「最優先でお願いします」という形で仕事が渡されることが多いため、兼務者はアサインされたそれぞれのプロジェクトのタスクに同時に対応することになります。
マルチタスクは、タスクの終了日を遅らせる要因となります。
たとえば、3日で終了する仕事が2つあったとしましょう。シングルタスクで1つずつ直列に進めたなら、1つめのタスクは3日後に終了し、2つめのタスクはそこからさらに3日が経過した6日後に終了します。同じタスクをマルチタスクで並列にこなした場合、両方のタスクが6日後以降に終了することになります。
シングルタスクであれば、少なくとも1つのタスクは3日後に終了していたところを、マルチタスクでは両方のタスクが6日後以降に終了することになります。「6日後」ではなく「6日後以降」である理由は、マルチタスクによるオーバーヘッドがあるからです。
弊害2: ミーティングの増加
兼務者が参加しなければならないミーティングが増加するという症状は、考えてみれば当たり前のことです。プロジェクトにはそれぞれ定例ミーティングやアドホックに招集されるミーティングがあります。したがって、掛け持ちするプロジェクトの数に比例して、参加するミーティングの数が増えてしまいます。
ミーティングの数が増えるということは、兼務者にとってそれだけコミュニケーションコストが増え、開発や保守、運用といった実務時間にあてられる時間が奪われるということです。
さらに、プログラミングなどの合間にミーティングが入ることも多くなり、その都度、集中力が奪われることになります。これも、オーバーヘッドによるムダを生じさせます。その様子については、以前の記事で次のように述べました。
彼らがひとたび仕事に取り掛かれば、数時間はその作業をやり続けます。時間とともに徐々に集中力が高まっていき、頭の中ではいま取り掛かっている作業に関する考えが次々に処理され、構造化されていきます。その間は、できることなら誰にも邪魔されたくない。無理な割り込みが入れば、頭の中で組み立てた論理構造が霧散してしまうからです。そんなことになれば、また時間を掛けて一から組み立て直すことになってしまいます。
プロジェクトを掛け持ちするエンジニアらからは、こうして開発時間が削られることが辛いという声をきくことがよくあります。
だからと言ってミーティングへの参加をひかえると、コミュニケーション不足によって仕事の品質が落ち始めます。必要な情報を得ることができず、意見交換もできないからです。だから、兼務者は実務時間が取れなくても、多くのミーティングに参加せざるを得なくなるのです。
弊害3: 知識の偏りと負荷の偏り
エキスパートやエースに頼りきったフォーメーションは、属人化を深刻にし、組織の中での知識やスキルの偏りを悪化させます。特定の技術や領域の知識やスキルが、その仕事を専門で担うエキスパートやエースにしか蓄積されないからです。それ以外のメンバーらには、成長の機会が与えられないということです。
また、このようなフォーメーションは、組織の中に負荷の偏りも生じさせます。あちこちのプロジェクトから引っ張りだこになり、エキスパートやエースの負荷が高い状態が続くのです。
安易に兼務を用いることの問題点
兼務によって生じる最大の問題は、共有されたメンバーを挟んでそれぞれのプロジェクトのフロー効率が下がり、それが市場投入までの時間（T2M, time-to-market）を長くすることにあります。
問題点1: フロー効率の低下による市場投入までの時間の悪化
マルチタスクが、すべてのタスクの終了日を遅らせることは先述のとおりです。3日で終了する仕事を2つ同時に進めると、両タスクともに6日以上のリードタイムを要することになります。本来は3日で完了する仕事なので、2倍以上の時間がかかっています。
その原因の多くは、一方のタスクに取り組んでいる間、もう一方のタスクの進捗が止まることで生じる細かな待ち時間です。これは、フロー効率がとても悪い仕事の進め方です。リードタイムのうち50%程度が待ち時間なのですから。
しかし、これをシングルタスクで進めたとしても、少なくとも一方のプロジェクトのフローは改善されません。タスクを後回しにされたプロジェクトは、優先プロジェクトのタスクが終わるまで3日間待つことになるからです。それがクリティカルパスであれば、プロジェクトの完了予定日は後ろに3日間ずれることになります。
加えて、プロジェクト間での調整という行為事態が、そこで消費する時間によってスケジュールに悪影響を与えることもあります。調整が難航し、プロジェクト間で何度も話し合うこともあり得るからです。
エキスパートやエースに関するリソース調整・スケジュール調整は、なおさらです。希少価値ゆえに調整は難航し、タスク着手時期はプロジェクトが期待するよりかなり遅くなってしまうからです。
問題点2: プロジェクトをまたいだ遅延の連鎖
兼務者を介して、掛け持ちするプロジェクトが遅延の連鎖を起こすことにも注意が必要です。これには2つのパターンがあります。1つは、兼務者が先行タスクの遅延の影響を受けるパターン。もう1つは、兼務者自身がタスクを遅延させるパターンです。
先行タスクが遅延したら、それを待つ兼務者は、予定日に担当タスクを開始できなくなります。その影響で、担当タスクの完了も遅延することになります。そうしてる間にも、掛け持ちする別プロジェクトの担当タスクの開始日になってしまい、そちらの開始も遅延してしまいます。
兼務者自身が担当タスクを遅らせてしまった時も同様です。遅延を取り戻そうと頑張っている間に、別プロジェクトの担当タスクに取り掛かる予定日になってしまうからです。
このように、ひとつのプロジェクトの進捗の遅れが、兼務者を介して複数のプロジェクトに飛び火していくのです。
問題点3: コミュニケーションコストの増大による実務時間減少
兼務者は、参加しなければならないミーティングが増加することで、実務時間が奪われる上に、集中力が途切れることによるオーバーヘッドも支払っています。タスクの進捗が、その分だけ遅くなることは明らかでしょう。
問題点4: 高負荷とオーナーシップ欠如による内部品質への悪影響
品質面、特に内部品質についても不安があります。
複数のプロジェクトを掛け持ちすることによって、兼務者の負荷があまりに高くなると、彼らが取り組むひとつひとつの作業の仕上がりが粗くなってしまうこともあります。エンジニアのリソース効率を高めることを目的としてプロジェクトを掛け持ちさせるケースがこれに該当します。そうしてスケジューリングされたエンジニアらは、息をつく暇もないほど次から次へとタスクをこなさなければならなくなります。内部品質に向き合う余裕など、あるはずもありません。
複数のプロジェクトを兼務することで、プロジェクトに対してオーナーシップを持ちづらい環境では尚さらです。内部品質を高めようという動機やモチベーションが弱くなってしまいます。
エキスパートやエースであっても、あちらこちらのプロジェクトから声が掛かって負荷が限界を超えれば、さすがに品質面に問題が生じ始めるでしょう。
兼務をなくす
兼務が必要になる状況は様々ありますが、その中でも最も一般的、かつ日常的にその状況を作り出す原因は、組織がプロジェクトチーム制でソフトウェアプロダクト開発を進めていることです。このアプローチには、プロジェクトの並列数と規模に制限がなくなりやすいという問題があるからです。
プロジェクトチーム制では、組織に必要な人員数が一定にはならず、常に変動します。同時に多くのプロジェクトを走らせることが可能であり、またその規模もプロジェクトごとにばらつきがあります。それゆえに、全体のリソース管理が複雑になります。特に、プロジェクトごとに異なるスキルセットが必要になることも多く、人材の適切な配置を難しくします。
この問題への対応策の1つとして、組織とマネージャーは、エンジニアを複数のプロジェクトに掛け持ちさせるという手段に頼り切るようになるのです。しかし、「兼務」は魔法の杖ではありません。先述したように、様々な弊害を生じさせるのです。
プロジェクトチーム制がいつでも問題だと言っているわけではありません。新しいソフトウェアプロダクトの開発プロジェクトのような、一時的に集中的な人的リソース投下が必要なプロジェクトでは有効に機能するでしょう。既存プロダクトのリニューアルもそうです。プロトタイプ開発のような、従来のプロダクト開発とは性質のことなるプロジェクトを走らせる時にも上手くいきます。
しかし、内製する社内ソフトウェアプロダクトの日常的な機能開発までプロジェクトチーム制で進めてしまうと、人的リソース管理の煩雑さと非効率性に起因して、プロジェクトのフロー効率を悪化させやすくなり、市場投入までの時間を長くする要因となってしまいます。
組織やチームの設計に次の3点を組み込むことで、兼務が必要になる状況を減らしていくことができると考えています。
チームを安定させる
チームの担当領域を決める
企画と開発を一体化する
ステップ1: チームを安定させる
まずは、チームを安定させます。プロジェクトチーム制では、プロジェクトが発足するたびに新しいチームが編成されますが、それをやめるのです。数名からなるチームを、プロジェクトのライフタイムとは関係なく立ち上げておきます。チームの顔ぶれが頻繁に変わるようなことはなく、チームメンバーが長く一緒に働くことができる環境を作ります。プロジェクトには、チームとして取り組み、プロジェクト終了後もチームメンバーが一緒に次のプロジェクトに移行できるようにします。
ステップ2: チームの担当領域を決める
次に、プロダクトごとに担当チームを決めます。ひとつのチームで開発できる規模のプロダクトでないならば、それぞれのチームに担当領域を割り当てます。
配備先を決めた当初は、担当領域に対する専門性をチームが十分に有していないかもしれませんが、安定したチームとして長く取り組むことで、専門性を獲得するはずです。
ステップ3: 企画と開発を一体化する
そして最後は、チーム内で開発計画やリリース計画が立てられるよう、企画と開発を一体化した機能横断型チームを作ります。
チームの外で開発計画やリリース計画が作られると、「並列数と規模に制限がなくなりやすい」というプロジェクトチーム制の問題が継続されてしまいます。企画メンバーが様々なプロジェクトを並列で立ち上げ、開発チームがそれらのプロジェクトを掛け持ちすることになってしまうからです。
企画と開発による機能横断型チームには様々な形態がありそうですが、実現難易度が比較的に低そうなのは、企画体制の「顧客/プロダクトオーナー分離」です。開発メンバー主体で組成された安定したチームに、プロダクトオーナーとして企画メンバーを加入させます。そして、残った企画メンバーで構成される企画チームを、「顧客」と見立てます。
こうすることで、顧客たる企画チームからの要求を、プロダクトオーナーがプロダクトバックログで管理できるようになります。あとは、プロダクトバックログに優先順位を付け、プロダクトオーナーを含む機能横断型チームが、「誰が何を、いつ、どのように⾏うか」を決めながら開発を進めていくのです。人的リソースに余裕があるなら、追加の企画メンバーやデザイナー、QAメンバーなども入れて、プロダクトバックログの詳細化をチーム単独で担えるようにしても良いでしょう。
リソースの競合を避け健全な働き方を推進する
エンジニアの兼務が組織にとって一般的な手法となっていますが、その裏には多くの弊害が潜んでいます。兼務による負担は、個々のエンジニアの生産性やモチベーションを低下させるだけでなく、プロジェクト全体の効率や市場投入までの時間にも影響を及ぼします。
組織としては、プロジェクトチーム制の見直しや、「安定したチーム」の導入を検討することで、兼務の必要性を減らすことが可能です。長期的なチーム編成、領域（ドメイン）ごとの分割、スケーラブルなチーム構造などの施策を取り入れることで、より安定した人的リソース管理と効率的なプロジェクト運営が期待できます。
また、エンジニア自身も、自分の負荷をコントロールしやすくなり、専門分野に集中することでスキルの向上やキャリア成長を図ることができます。
組織全体でのリソースの競合を避け、健全な働き方を推進するにはどうすれば良いか。組織とエンジニアが共に成長し、より良いプロダクトを生み出すために、兼務の弊害を理解し、適切な対策を講じることが重要だと思います。
この記事が気に入ったらサポートをしてみませんか？