世の中に開発は2種類、「内製か、内製以外か」
はじめに、一昨日の初投稿は自己紹介の内容にも関わらずスキやフォローを頂いた方々にお礼申し上げます。とても励みになります。ありがとうございます。
今回は電脳随想録としてソフトウエアの開発のお話を書きたいと思います。
お題はソフトウエア開発ですが、自分でやるか人にお願いするかを考えるときの検討材料の話なので、読んで頂く方のお仕事に当てはめて読んで頂ければ嬉しいです。
「内製」とは自分や自組織で作ること、内製以外とは外部の人や会社にお願いして作ってもらうこと、多くの場合は「外注」と言うと思います。
実際には必ずしもタイトルのような二択ではなく、内製といいつつ外部のプログラマさんがグループで常駐したり、期間限定で準委任契約したプログラマさんがチームの一員としてコーディングしていたり形態は様々だと思います。
「システムは内製した方が良いのか？それとも外注した方が良いのか？」という問いは私が社会人になった1990年代には既に「以前からある古くて新しい問題」と言われていたヴィンテージものの課題ですが、どのような観点で整理したら良いのかという一例を共有したいと思います。
はじめに
スマートフォンの普及と、ここ数年のクラウドサービスの充実により、企業の競争力は、ICTインフラ（サーバやネットワーク）を持っているかどうかよりも、どのようなアプリケーションをいち早く提供できるかということにシフトしています。
そのため、企業独自のサービスを差別化するためには、自社でソフトウェアを開発することが重要視されています。しかし「内製化のメリットがよく分からない」という意見に対して合理的な回答ができなかったり、また現場のエンジニアによっても意見が分かれることがあります。そのため、組織内で共通の指標を持って意識を合わせることが大切です。
では、システムを自社で開発すべきかどうかはどのように考えればいいでしょうか。以下では内製開発のメリットとデメリット（≒リスク）について５つずつ私見を書かせて頂きます。
ただし、今回はコストのことについては触れませんのでご了承ください。ソフトウェアを自社で作る際には、作りたい製品がもたらす利益や便利さを考慮して、コストの範囲を決める必要があります。具体的な考え方については、別の機会にまとめる予定です。
内製開発のメリット
＜①アジリティ（敏しょう性）＞
開発の内製化においてはこのアジリティの高さが最大の利点だと思っています。これはお金をかければ上げられる納期までの「スピード」ではなく、何かの変化に対する反応速度やプロジェクトの立ち上げまでの時間を指します。
例えば、ソフトウェアを作りたいと思った時、外部に発注するために企画書を作成し、説明を行い、社内で承認を得るというプロセスに時間を費やす代わりに、「プロトタイプを作ってみました」ということが内製で可能になります。また、少し修正したい、少し不便だと感じるといった場合でも、我慢する必要なくすぐに修正できるというのも内製の利点です。
＜②フリクエンシィ（頻度）＞
①のアジリティと合わせて、システムや機能を高頻度で変更・改善する場合、また新しい機能を追加する場合には、月間や年間など単位時間当たりの頻度が高いほど自社で行うことの利点が大きくなります。
たとえば、数年に一度しか機能改修が必要ないシステムは、外部に任せたりパッケージソフトを使えば良いですが、定期的に機能を改善することで利便性を高められるシステムは、自社で内製開発することの利点が大きいと考えています。
＜③クオリティ（品質）＞
開発成果物の品質を自社の努力で上げることができるという点も内製のメリットです。もちろん、製作されたソフトウエアの品質は内製要員のスキルによっても影響を受けます。一方、他社が製作した場合、初期品質が低かったり不具合が生じても、品質改善や不具合解消のためのソフトウェア修正をただ待つしかありません。
特に、ソフトウエア開発のV字モデル（注１）では、機能モジュールを作り、それらを組み合わせることで機能を実現します。しかし、最小単位のソフトウエアは個々で動作しても、組み合わせるとシステムがうまく動かないことがあります。
多くの場合、機能を分解して作る際には、他のパートのことまで考えられず、完成部品を集めて動かすまで分からないというシンプルな理由があります。規模が大きくなるほど、品質管理が難しくなります。
こうしたプロセスを指揮する人と作る人が同じ場所にいる利点を活かせれば、完成品の品質を向上させることができるでしょう。これが内製のメリットです。
注１：ソフトウェア開発の基本的なプロセスを表すモデルです。要件定義からテストまでの各工程をリンクさせ、検証作業を効率的に実施することを目的としています。
＜④オリジナリティ（独創性）＞
オリジナリティのメリットには２つの意味があると思います。
１つは、自社のニーズに合わせて作ることができるという点です。パッケージソフトウェアでは、ローカライズやカスタマイズが難しいですが、内製ソフトウェアでは自由に作ることができます。
もう１つは、市場で需要がなく他の企業が作ってくれない機能を、社内のニーズに合わせて作ることができるという点です。市場ニーズがない機能でも、自社が必要なら内製で実現できます。
この項目には「仕様設計ができれば外注でも作れる」という考え方もありますが、前述の①〜③を加味すると総合的には内製化のメリットを享受できると思います。
＜⑤プロパティ（財産）＞
社員が日々学んで技術力を高めることは企業にとっても社員本人にとっても有益であることは事実であると思います。蓄積された技術力や実装ノウハウは自社開発にとって重要であり、ベンダ製品の選定や目利きにも役立ちます。
航空機や産業機械の試験工程を作る人は試験対象物をゼロから設計できる人でないと製品レベルがあがらないと聞いたことがあります。同様に、システムやサービスをゼロから作れる人材は他企業が作るサービスやシステムを選定する際にも役立ちます。
また、システム開発の過程で生まれたアイディアやノウハウは知的財産権として保護すれば収益をもたらすことができます。これにより、開発部門が「稼げる部門」になることができます。
内製開発のデメリット／リスク
ここまではメリットについて書いてきましたが、システムを自社内で開発することにはデメリットやリスクもあります。ここでは私が考えるシステム内製化の５つのデメリットについて説明します。
内製開発の是非を検討する時には、メリットだけでなく、これらのデメリットやリスクをどのように排除するかという戦略も考える必要があります。
＜⑥権利侵害リスク＞
自社で開発したサービスや機能を実装することによるリスクとして、権利侵害やライセンスの違反、また競合他社と類似のサービスや機能を後発で実装することでの評判悪化などが考えられます。
自社で開発したソフトウエアは世界標準の仕様に従って実装していれば権利侵害のリスクはないと思われがちです。しかし、先行開発していた企業が標準必須特許の権利を保持しておりライセンス料を請求されるケースがあります。
またGPLライセンスのオープンソースソフトウエアをコード改変して利用したためにプログラムの開示義務が生じてしまうなどの可能性もあります。この問題については業界でもライセンスコンプライアンスの遵守について長年取り組んでおり管理プロセスがISO 5230として標準化されています。
ベンダ製品やサブスクリプション契約を利用する場合には、責任はベンダ側にあるため安心ですが、自社で開発したシステムでは全ての責任を負う必要があります。これを十分に認識しておくことが大切です。
＜⑦利用ユーザ数＞
自社固有のシステムは他社のシステム、特にグローバル展開する製品と比べて利用ユーザ数や使い方のバリエーションが少ないため、不具合を見つけることや機能を改善する要望を受けることが少ないです。
他社のソフトウェア製品は、ライセンス料や保守費を支払っていれば「世界の誰かが発見した不具合（特にセキュリティ問題）が知らないうちに修正されている」とか「気づかなかった便利な機能が追加された」というハッピーを享受できますが、内製システムにはそのようなセレンディピティ（偶然の幸福）は生じず、全てを自分たちで解決し進化させなければなりません。
＜⑧適正リソースの変動＞
内製するシステムの開発規模が一定もしくは拡大トレンドにある段階では、社員だけでは足りないリソースを必要な分だけ外部委託で調達すれば問題ありません。
しかし、業務のピークに合わせて人員を配置すると、必要な開発工数が削減されたりシステム開発数が減少した場合、リソースが余剰になることがあります。人だけではなく、開発拠点の設備や開発環境（計算機やネットワーク）も同じです。
多くのリソースを抱えてしまうと組織維持のために開発プロダクトを探すという本末転倒な状態が生じたり、不要不急の機能開発を始めざるを得なくなったりします。そのため、開発の中長期的な計画と必要なリソースの適正な規模を見極める必要があります。
＜⑨開発スキルの属人化リスク＞
スポーツや音楽などの趣味を一緒に始めても、個々人の才能や努力の差によって、一定期間後の成績やスキルには違いが生じます。同じように、システム開発の技術力や開発マネージメントのノウハウにも個人差が生じます。
これにより、社内の競争やスキルの差別化が生まれて全体の品質を向上させるという効用も期待できますが、大きな差が生まれてしまう状況は好ましくありません。
その人しかできない技術になってしまう「属人化」の反対語として業務の「標準化」という考え方があります。ただし、プログラミング言語を操る能力はある種の語学力ですので人のスキルに大きな依存性があり、すべてを標準化していくのは簡単ではありません。
事業を安定的に継続運営していくためには、知識やノウハウを継続的に共有し、人の入れ替わりに対して、また世代を超えてノウハウを引き継ぐ仕組みを作ることが必要です。
＜⑩育成/学習コスト vs 外部人材の〇〇パ＞
外部の人材を使うことは、時間や難易度が高い技術習得のためにかかるコストや学習コストを考えると、コストパフォーマンス（コスパ）やタイムパフォーマンス（タイパ）の点でも魅力的な選択肢となりえます。
つまり、自社の従業員が内部で仕事をするよりも外部の人材を使う方が効果的である場合があります。自社での組織運営や人材育成はコストが掛かりますし、前述のメリットを得ることができなければなりません。ソフトウェアプロダクトのオーナーは、常に内製化の意義やメリットを説明できるように考えなければなりません。
おわりに
内製開発を進める組織やエンジニアは、受託開発企業のエンジニアと同じ技術力を持ちながら、社内でしかできないことを付加価値化し差別化する戦略的育成が求められます。
一方で、ノーコードやローコードという開発手法も今後は一般的になり、サービスも増えると思われます。また、生成AIの進化によって社内開発者に一定のスキルがあれば必要十分なアプリケーションや業務用Webシステムを作れるようになっていきますので内製化には追い風の要素も多いです。
「内製か、内製以外か」
この問いに対しては、企業の戦略やポリシーに加えて、様々な制約条件を考慮して最適な方法を検討する必要があります。また企業としてプロダクトのどこに魂を入れるのか、外部のサービスや製品をどこまで利用するかも注意深く考慮する必要があります。
例えば毎日使う大切なツールだからといってノートPCやオフィスソフトを内製にしましょうとはなりません。完成度とコストの観点から言えば、既製品を利用する方がより良い選択だからです。
私が今回書いたメリットとデメリット／リスクは、現時点での私の意見であり、前述の項目以外にも多くの視点やアプローチがあると思いますので、皆さんが考えるときの参考にして頂ければ嬉しいです。
最後までお読み頂きありがとうございました。
この記事が気に入ったらサポートをしてみませんか？