LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

参画してもらった業務委託のエンジニアが開発になじみ、成果も見えてきた。そこで、もう一つチームを作りたい、テストの自動化に詳しい人も加えたい——。こうした相談は、最初のチームが軌道に乗った頃に出てきがちです。業務委託エンジニアの参画後のチーム拡大とは、すでに加わっている社外のエンジニアを含むチームに対して、人数を増やしたり、足りない役割を加えたりして、体制を広げることを指します。

広げ方を決めないまま人を増やすと、説明の負担が既存のメンバーに集まり、かえって作業が進まなくなることもあります。本記事では、IPA（情報処理推進機構）のアジャイルプロジェクト実践ガイドブックとアジャイル開発外部委託モデル契約をもとに、広げる前に書き出すこと、広げ方の選び方、専門家の加え方、契約で確かめることを整理します。

参画後のチーム拡大とは

参画後のチーム拡大には、大きく2つの形があります。1つは、同じ種類の仕事をする人を増やし、チームの数や規模を大きくする形です。もう1つは、今のチームに無い技術や知識を持つ人を加え、役割を増やす形です。どちらも「人が増える」点は同じですが、決めることは異なります。

IPAのアジャイルプロジェクト実践ガイドブックは、アジャイルのチームが育つ段階を立ち上げ期・拡大期・定着期に分けています。拡大期については、1つ目のチームのビジネス成果が目に見えてくる前後で、チームの拡張や他のビジネス領域への適用など、チームへの要求が増えてくると説明しています。^*1 業務委託エンジニアの参画後に広げる話が出てくるのも、たいていはこの時期でしょう。

ガイドブックはアジャイル開発の組織づくりを念頭に置いた資料ですが、成果が出たチームに次の要求が集まり、広げ方を選ぶ必要が出てくるという流れは、ほかの進め方の開発にも当てはまります。本記事では、発注する側が決めることに絞って、広げる前の準備から契約の確認までを順に見ていきます。

広げる前に仕事の流れを書き出す

人を増やす前に確かめたいのは、今の作業がどこで止まっているかです。ガイドブックは、アイデアが生まれてからサービスや商品として顧客に届くまでのタスクや承認の流れ、承認のリードタイムなどを、Value Stream Map（価値が届くまでの流れの図）で見える形にすることを勧めています。プロセス、ツール、登場人物を明らかにしたうえで、計画を作る使い方です。^*1

あわせてガイドブックは、フィーチャーチーム適応マップを紹介しています。流れの図に出てくるプロセスを、チームの中でどこまで実施できるようにするかを計画するためのものです。言い換えると、チームの外にある手続き（たとえばリリースの承認や本番環境の作業）をチームに取り込むのか、必要なときに実施される環境を整えるのかを、先に決めておく考え方です。

流れを書き出すと、増やすべきものが人数なのか、別の部門の協力なのかが見えてきます。コードを書く人の手が足りないのか、レビューや承認の待ちが長いのかで、打つ手は変わります。待ちが原因なら、開発者を増やしても待つ人が増えるだけです。増員で縮む作業と縮まない作業の分け方は、開発要員の増員で縮む作業と縮まない作業の記事でも整理しています。

横に広げるか縦に広げるか

ガイドブックは、拡大期にチームへ集まる要求を大きく2つに分けると、それぞれの対策の方針を考えやすくなるとしています。1つ目は「横に広げる」で、チームが1つできたら2つに、2つできたら4つにという形で、チームの数を増やすことを期待される場面です。2つ目は「縦に広げる」で、これまでアジャイルを適用したことがない部門を巻き込む場面を指します。^*1

縦に広げる例としてガイドブックが挙げているのは、システムを開発する部門と運用する部門が分かれている会社で、運用する部門をアジャイルの組織に組み込む場合です。業務委託エンジニアが開発だけでなく運用の作業にも関わるようになる、といった広げ方がこれに近いでしょう。

どちらの形かによって、加える人に求めるものも変わります。横に広げるなら、今のチームと同じ種類の技術を持ち、すでにある進め方を受け入れられる人が中心になります。縦に広げるなら、相手の部門の業務の決まりや手続きを知っている人が欠かせません。広げる形を一つ選んでから人を探すと、求める経験を書き出しやすくなります。

人数を増やすときの組み方

横に広げるときの基本として、ガイドブックは「のれん分け方式」を挙げています。最初に作ったチームから数名を選び、次のチームの立ち上げに参画させる方式です。^*1 新しいチームを、まったく新しい人だけで始めない点がポイントです。最初のチームで固まった進め方や工夫を、移った人が新しいチームへ持ち込めます。

ガイドブックは、のれん分けに関わるメンバーに求められる素養として「他者に対するリスペクト」を挙げています。最初にチームを立ち上げたメンバーには、先駆者としておごらず常に学ぶ姿勢を、新しく加わるメンバーには、先達の工夫を受け入れる度量を求めています。^*1 人を選ぶときの観点として、技術の経験と並べて見ておきたい点です。

業務委託エンジニアが最初のチームにいる場合は、その人が新しいチームへ移るのか、元のチームに残って後から来る人に説明する側に回るのかを決めておきます。移ってもらうなら、元のチームに残る作業を誰が引き取るかも合わせて決めます。いずれの場合も、担当する作業の範囲が変わるなら、契約に書かれた業務の内容に収まっているかを確かめ、収まらなければ相手と話し合って契約を見直します。

役割を足すときの組み込み方

今のチームに無い技術を補いたいときは、専門家の関わり方を先に決めます。ガイドブックは、組織の中にアジャイルや技術領域のプロフェッショナルがいるケースはまれだとしたうえで、プロジェクトに必要となる技術要素や役割として、次の9つを挙げています。^*1

• スクラムコーチ
• 開発言語等の専門分野
• 組み込み・ハードウェア等の領域
• CI/CD（ビルドからリリースまでの自動化）などの開発環境整備
• テスト駆動開発
• リファクタリング
• テスト自動化
• クラウド技術
• ビジネス領域のプロフェッショナル

ガイドブックは、こうした領域のスペシャリストをプロジェクトのチームにフルで参画させることが難しい場合や、部分的な参加で十分な場合は往々にしてあるとし、チームを支える非常駐のメンバーとして体制に組み込むことを検討すべきだとしています。役割を足すからといって、毎日チームにいる人を1人増やす形だけが答えではない、ということです。

常駐しない専門家に加わってもらうときは、関わる頻度（週に何時間、月に何回の相談か）、相談を受ける窓口、助言を受けたあとに誰が作業するかを決めておきます。とくに最後の点があいまいだと、助言が出ても手を動かす人がいないまま止まります。チームのメンバーが作業し、専門家は確認と助言に回るのか、専門家が作業の一部まで受け持つのかを、依頼の前に書き出しておきます。

部門をまたぐときの判断の基準

縦に広げるときに起こりやすいのが、優先順位の食い違いです。ガイドブックは、開発する部門と運用する部門では、それぞれの部門のミッションを達成することが求められる一方、KPI（重要業績評価指標）が異なる場合が大半だと指摘しています。それぞれの部門のKPIをそのまま当てはめると、優先順位の争いがチーム内で起こり、チームの分裂を招く恐れがあるとしています。^*1

そのためガイドブックは、両方の組織の責任者が、チームの共通認識となるKPI（判断基準）を設定することを勧めています。整えるときには、担当業務や部門に適用される公式・非公式の業務プロセス、業務ルール、コンプライアンスなどに詳しいメンバーの協力を得ることが肝要だとしています。^*1 業務委託エンジニアが部門をまたいで作業するなら、どちらの部門の依頼を先に受けるかを、本人に任せず発注する側で決めておきます。

組織をまたぐ変更には、経営の判断が要る場面も出てきます。ガイドブックは、適切なタイミングで経営層へエスカレーションし、助力を得られるようなリーダーシップを発揮できる人材の参画が必要になるとしています。この役割は社外の人よりも、社内の権限を持つ人が担うほうが自然です。誰がその役を受け持つかを、広げる前に決めておきます。

参画中の人が別の人を連れてくるとき

チームを広げる場面では、すでに参画している人やその所属先から「知り合いのエンジニアにも手伝ってもらいたい」と提案されることがあります。受けた仕事の一部を別の人や会社に頼むことは、再委託と呼ばれます。IPAのアジャイル開発外部委託モデル契約は第13条で、受託した側は、発注する側から事前に書面で承諾を得た場合か、発注する側が指定した再委託先に頼む場合に、業務の一部を再委託できるとしています。^*2

同じ条文では、発注する側は合理的な理由がない限り承諾を拒否できないこと、受託した側は自分と同様の義務を再委託先に負わせる契約を結ぶこと、再委託先の作業についても自ら遂行した場合と同様の責任を負うことを定めています。ただし、発注する側が指定した再委託先については、受託した側に故意又は重過失がある場合を除き、責任を負わないとしています。^*2

解説では、アジャイル開発では両者の信頼関係が極めて重要で、再委託先の人もチームの一員としての役割を担うことになるとしています。そのうえで、受託した側が再委託先の能力を慎重に検討し、発注する側の評価・承認を得てから再委託を行うこととすべきだとしています。^*2 このモデル契約は企業どうしの契約を想定したひな形です。個人と結んだ契約で同じ場面になったときの扱いは、自社の契約の条文を確かめ、必要に応じて専門家に相談してください。

新しく加わる人と秘密情報

人が増えると、社内の情報に触れる人も増えます。同じモデル契約の第14条4項は、秘密情報を開示する相手を、契約の目的のために知る必要のある役員及び従業員（再委託先を含む）に限るとしています。そのうえで、開示を受けた人には、契約で負うのと同等の秘密保持の義務を、退職後も含めて課すとしています。^*2

解説では、開示を受ける人に秘密保持の誓約書を求めるなど、より具体的な方策を定めておくことも考えられるとしています。^*2 チームを広げるときは、新しく加わる人ごとに、どの情報を見る必要があるのかを決め、誓約書や契約の手続きが済んでから情報を渡す順番にしておくと、確認の漏れを防げます。

情報を見せる範囲が決まれば、渡すアカウントや権限もそれに合わせて決められます。非常駐の専門家のように関わる時間が限られる人ほど、要る範囲を絞りやすいはずです。アカウントの発行から削除までの手順は、業務委託エンジニアの受け入れ時の権限管理の記事でまとめています。広げたあとも、誰がどの情報を見られるかの一覧を、体制の変更のたびに更新していきます。

まとめ：参画後のチーム拡大で決める3つのこと

業務委託エンジニアの参画後にチームを広げるとき、発注する側が決めておきたいことは3つに整理できます。第一に、人を増やす前に仕事の流れを書き出し、手が足りないのか、待ちが長いのかを見分けること。第二に、チームの数を増やす横の広げ方、別の部門を巻き込む縦の広げ方、専門家の役割を足す広げ方のどれを選ぶかを決め、それぞれに合う組み方をすること。第三に、加わる人が増えるときは、再委託の承諾と秘密情報を見せる範囲を契約で確かめることです。広げ方が決まり、求める経験を書き出せたら、それに合う人を探す段階に進めます。

よくある質問

出典

1. *1　参考：IPA「アジャイルプロジェクト実践ガイドブック ITSS+ アジャイル領域」Ver1.1（PDF）（https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/agile-guidebook2022.pdf）。出典：独立行政法人情報処理推進機構（2023年4月第1刷・2024年5月第2刷）。Ⅴ.アジャイル組織の育て方のうち、アジャイルを組織に適応させる計画を作る（Value Stream Map、フィーチャーチーム適応マップ）、1.立ち上げ期「足りないものを適宜足していく」、2.拡大期（横に広げる・縦に広げる）を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：IPA「アジャイル開発外部委託モデル契約（解説付き）」（PDF）（https://www.ipa.go.jp/digital/model/ug65p90000001ldr-att/000081484.pdf）。出典：独立行政法人情報処理推進機構・経済産業省「情報システム・モデル取引・契約書（アジャイル開発版）」のうち、アジャイル開発外部委託モデル契約（2020年3月、2025年4月R1）。第13条（再委託）とその解説、第14条（秘密情報の取扱い）第4項とその解説を参照（確認日2026年10月2日）（2026年10月確認）

Tweet