LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

市場変化の速さが問う開発モデルの見直し

アジャイル・内製開発への転換とは、要件を固めてから開発する従来型の外注中心モデルから、反復的な開発サイクルと社内主導の体制へ移行する経営判断を指します。経済産業省が公表した「DXレポート2」では、デジタル技術と市場変化への迅速な適応の必要性から、アジャイル開発の重要性が提起されています^*1。

これまで多くの企業は、システム開発を外部ベンダーへ一括発注し、要件定義から納品までを請負契約で完結させる進め方を採ってきました。この方式は要件が明確な業務では有効ですが、市場や顧客ニーズの変化が速い領域では手戻りのコストが大きくなりやすいという弱点があります。

デジタル技術を前提にした競争では、サービスを出してから顧客の反応を見て改良を重ねるサイクルの速さが競争力を左右する場面が増えています。年単位の開発計画を前提にした従来モデルでは、この速度に追随しにくいと言えるでしょう。

こうした背景から、開発の進め方そのものをアジャイル型に見直し、あわせて開発機能を自社に取り込む内製化を検討する企業が増えています。両者は別々の論点に見えますが、実際には表裏一体の経営判断です。なぜなら、外部への一括発注を前提にしたままでは、反復的な開発サイクルを回しきれないケースが多いからです。

ウォーターフォールとアジャイル — 優劣でなく向き不向き

ウォーターフォール開発とは、要件定義・設計・開発・テストという工程を順番に完了させながら進める開発手法です。IPA（情報処理推進機構）が公表する「情報システム・モデル取引・契約書〈アジャイル開発版〉」では、ウォーターフォール型は「開発対象全体の要件や仕様を確定してから開発を行う」進め方と整理されています^*2。

一方のアジャイル開発は、短い期間の開発サイクルを繰り返しながら機能を段階的にリリースする手法です。同資料では「機能の追加・変更や優先順位の変更、先行リリース部分の改善などに柔軟に対応することができる手法」と説明されています^*2。

両者の違いは契約形態にも表れます。ウォーターフォール型は成果物の完成を約束する請負契約が中心である一方、アジャイル開発は専門家としての業務遂行そのものに対価を支払う準委任契約を前提とすることが一般的です^*2。契約形態が異なる以上、発注側の体制や社内規程も合わせて見直す必要が出てくるはずです。

ここで押さえておきたいのは、アジャイルがウォーターフォールより優れているわけではないという点です。要件が固まっている基幹システムの刷新や、法令対応のように仕様変更の余地が乏しい開発では、計画重視のウォーターフォールが適している場面が少なくありません。逆に、顧客接点のアプリケーションのように仕様を試行錯誤しながら磨き込みたい領域では、アジャイルの反復型アプローチが力を発揮しやすいでしょう。実務では両者を併用し、システムの性質ごとに使い分ける進め方も選択肢の一つです。

内製化がもたらすナレッジ蓄積と変化対応力

内製化とは、これまで外部ベンダーに委託していたシステム開発の一部または全部を、自社の人材で担う体制へ切り替える取り組みを指します。単なるコスト削減の手段ではなく、事業とシステムの一体運営を実現する手段として位置づけられます。

内製化の効果として第一に挙げられるのが、ナレッジの蓄積です。外部委託では仕様書や成果物は残っても、開発の過程で得た試行錯誤の経緯は社内に残りにくい傾向があります。内製化すれば、なぜその設計を選んだのかという判断根拠までが組織の知見として蓄積されるでしょう。

第二に、意思決定の速さが挙げられます。企画担当者と開発担当者が同じ組織に属していれば、仕様変更のたびに契約や見積もりを調整する手間が減るでしょう。この結果、顧客の反応を見ながら短いサイクルで改善を回すアジャイル開発と相性がよくなると考えられます。

一方で、内製化には見過ごせない留意点もあります。開発人材の採用・育成には相応の時間とコストがかかり、特にIT人材が不足する業界では確保自体が容易ではありません。開発体制を維持するための評価制度や、繁閑に応じた人員配置の設計も同時に求められるはずです。内製化は「外注をやめる」ことではなく、「自社が担う範囲と外部に委ねる範囲を再設計する」取り組みだと捉えるほうが実態に近いでしょう。

転換を判断する4つの軸

アジャイル・内製化への転換を検討する際、すべての開発領域を一律に切り替える必要はありません。対象領域ごとに次の4つの軸で判断すると、優先順位を整理しやすくなります。

軸1：差別化領域かどうか

顧客接点や独自サービスなど、競合との差別化に直結する領域は、内製化とアジャイル化の優先度が高いと言えます。差別化に関わらない定型業務のシステムまで内製化する必要性は相対的に低いはずです。

軸2：要件の不確実性の高さ

市場の反応を見ながら仕様を固めていく必要がある領域は、アジャイルとの親和性が高い領域です。逆に法令対応や会計処理のように仕様が固定的な領域は、ウォーターフォール型のままで問題が生じにくいでしょう。

軸3：改修頻度の高さ

年に数回程度しか改修しないシステムを内製化しても、体制維持のコストに見合う効果を得にくい場合があります。逆に月次・週次で改修が発生する領域は、内製化による意思決定の速さが効果を発揮しやすい領域です。

軸4：人材確保の見通し

内製化の可否を左右する最も大きな制約は人材です。採用市場での確保見込み、既存社員のスキル転換の可能性、育成にかけられる期間を具体的に見積もったうえで、転換のスコープを決める必要があるでしょう。

転換の進め方 — 小さく始めて比率を上げる

アジャイル・内製化への転換を経営判断として下した後も、全社のシステム開発を一斉に切り替える進め方は現実的ではありません。段階を踏んだアプローチが実務上の選択肢になります。

ステップ1：対象領域を1〜2件に絞って先行させる

前章の判断軸に照らして優先度の高い領域を選び、まずは小規模なプロジェクトで試行します。全社展開の前に、自社の体制でアジャイル開発が回せるかどうかを検証する狙いがあります。

ステップ2：評価制度と契約形態を見直す

ウォーターフォール型を前提にした人事評価や調達ルールのままでは、アジャイル型のチーム運営とかみ合わない場面が出てきます。準委任契約への切り替えや、成果物ではなくアウトカムを評価する仕組みへの見直しが必要になるでしょう^*2。

ステップ3：併用体制を前提に内製比率を段階的に高める

先行事例で得られた知見をもとに、内製化する領域を広げていきます。すべてを内製に置き換えるのではなく、コア領域は内製・周辺領域は外部活用という併用体制を前提に設計すると、無理のない拡大がしやすくなります。

立ち上げ期に外部の伴走を組み合わせる考え方

内製化の立ち上げ期は、アジャイル開発の経験を持つ人材が社内に十分揃っていない状態からスタートすることが珍しくありません。この状況で無理に内製だけで進めようとすると、プロジェクトの停滞や手戻りが発生しやすくなるおそれがあります。

ここで有効な選択肢が、外部パートナーとの伴走です。開発の立ち上げ期を外部の受託・伴走支援で加速させながら、並行して自社人材がプロジェクトに参加し、進め方やノウハウを吸収していく形です。全面的な外注でも全面的な内製でもない、移行期に適した体制と言えるでしょう。

外部パートナーを選定する際は、単発の開発実績だけでなく、アジャイル開発の進め方そのものを社内に定着させる支援ができるかどうかを確認する視点が欠かせません。契約形態も請負から準委任への切り替えを前提に、双方で認識をすり合わせておく必要があるでしょう。

なお、外部の開発チームにアジャイル開発を委託する進め方そのものについては、発注先の選定基準や進行管理の実務に絞って別途整理しています。本稿はあくまで「開発モデルと内製比率をどう転換するか」という経営判断に軸足を置く内容です。

まとめ：アジャイル・内製化転換で経営が握るべき軸

本稿では、アジャイル開発・内製化への転換を経営判断として捉え、その考え方と進め方を整理しました。要点を3つに集約すると次の通りです。第一に、ウォーターフォールとアジャイルは優劣ではなく、差別化領域か・要件の不確実性・改修頻度・人材確保の見通しという軸で使い分けるべき対象と言えるでしょう。第二に、内製化はナレッジ蓄積と意思決定の速さをもたらす一方、人材確保という制約を伴う経営判断です。第三に、転換は対象領域を絞った試行から始め、評価・契約の見直しを経て内製比率を段階的に高める進め方が現実的だと言えます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：経済産業省「DXレポート2（中間取りまとめ）」（2020年）
2. *2　出典：IPA（情報処理推進機構）「情報システム・モデル取引・契約書〈アジャイル開発版〉」https://www.ipa.go.jp/digital/model/agile20200331.html（2020年公表、2025年改訂）

Tweet