内製？ベンダ委託？システム開発のもう1つの選択肢

昨年までホットなワードであった「デジタルトランスフォーメーション（DX）」、最近は見聞きする機会が随分と減りました。
これは、DXの概念が企業に根付き、企業の“あたり前”になってきていることを示しているのかもしれません。

そんなDXの広がりを追い風に、急速に普及したのが「ローコードツール」です。
普及した理由を挙げるとすれば、以下でしょうか。

概念検証（PoC）の優先度や市況の変化のスピードが上がったことも背景に、開発期間を短縮できるクラウド（特にSaaS系サービス）系システムを優先する構成が増えた。
DX概念でもある「企業独自の価値」をカスタマイズ制限の多いSaaS系システムだけで実現することは難しく、開発期間短縮とカスタマイズを両立できるローコードツールの需要が増えた。

このローコードツールは、多くが「内製」か「ベンダ委託」の二択であったシステム開発にもう1つの選択肢をもたらしました。

内製とベンダ委託の“ハイブリッド開発”

ツールによる差異はありますが、ローコードツールの特徴は以下です。

ノーコード開発（画面部品等の視覚的な組み立て、プログラミングの自動生成等）できる範囲と、スクリプト開発（ユーザ独自の機能性を持たせるためのスクリプトやパラメータ等）できる範囲がある。
スクリプト開発範囲は、機能毎に設定領域が細分化・可視化されていて視覚的にも分かりやすく、スクリプトの影響範囲も限定されている。
設計書を自動出力することができ、いつでも最新の設定値を確認できる。

これらの機能的な特徴により、多くが「内製」「ベンダ委託」の二択であったシステム開発の選択肢に、第三の選択肢として「内製とベンダ委託のハイブリッド開発」を加えることができるようになりました。
内製できる範囲は自社で開発し、内製できない範囲はベンダに委託する、という方法です。

ハイブリッド開発の注意点

一見すると良いとこ取りのようなハイブリッド開発ですが、自社とベンダ双方で同じシステムを開発する手法のため、特に、以下の点での対策は必須です。

1. 内製範囲・ベンダ委託範囲を明確に定義する。

自社とベンダ、それぞれが開発する範囲を明確に定義することが1点目です。
内製できる範囲は企業（更に言うと開発メンバ）により様々ですが、内製できるからといって、自由にどこまでも内製して良い訳ではありません。
この定義範囲を超えた開発をしないことは絶対的なルールです。
（後述の事項を維持することができなくなります）

参考事例として、範囲定義をフェーズで切り替えたケースもありました。
初期開発はすべてベンダ委託とし、その後の修正や改修から内製を開始することとして、内製範囲をあらためて定義するようなケースです。

2. 開発範囲は、相互依存を極少にする範囲で定義する。

開発範囲定義は、二社それぞれがある程度独立性を持って開発できる範囲で定義することが2点目です。
それぞれの開発に相互依存・相互影響してしまうような範囲で定義してしまうと、開発効率が著しく下がります。
「画面で分ける」は分かりやすい例ですが、同じ画面であっても「スクリプト領域と、スクリプト影響のないノーコード領域で分ける」ことでハイブリッド開発した事例もあります。
範囲定義の目安は、テスト計画を明確に分離できる範囲です。

3. 開発計画・開発履歴を常に共有する。

開発計画（いつから・どの範囲に・どのような開発を）を常に最新の情報で共有するだけでなく、開発状況のステータスを含む開発履歴を、二社間で常に共有することが3点目です。
ベンダがテスト中に他の機能を内製で改修してしまう、そんなことが発生しないよう、言わずもがな、常に最新の計画・履歴情報を共有しておくことは当然ですね。

4. 責任分界点・保守範囲を定義（合意）する。

内製範囲に対する責任分界点・保守範囲（保守要件）をベンダと合意しておくことが4点目です。
障害発生時の一次調査や原因による対応の切り分け等、内製範囲も含めて保守委託する業務が少なからず発生します。保守範囲や条件を曖昧にせず、ベンダと事前に合意しておくことが必要です。

おわりに

冒頭のとおり、ローコードツールが普及した大きな要因の1つが「カスタマイズ制限の多いSaaS系システムだけで実現することは難しく」です。
近年では、この課題への解決策としてローコードツールを用いるのではなく、SaaS系サービスの組み合わせにカスタマイズ性や業界特有の独自性も加えたプラットフォーム（インダストリークラウド）を選択するケースも増えてきています。
今後も様々な選択肢が増えていきます。選択肢の特性を理解し、自社にとって最適な選択肢を選択していくことが大切です。