2023年8月1日にオンラインセミナー『事例に学ぶ内製化、DevOps戦略 〜DXパートナーとの連携がプロセス変革や人材育成の鍵〜』を開催いたしました。
この記事では当日用いた資料を公開し、そのポイントを紹介しています。
目次
NCDCの内製化支援事例
はじめに「お客様がなぜ内製化に取り組んだのか」という背景とともに3つのプロジェクトをご紹介します。
（ひとくちに内製化の支援といっても、その内容は体制構築のコンサルティングや、内製チームの人材確保の支援、内製チームへの技術移管、DevOpsを実現するための環境構築支援など、さまざまな要素があります。そのため、次に挙げる3つの事例も内製化の実現に向けてNCDCが担った役割はそれぞれ異なります）
事例1.保険の申込みサイトの内製化
ライフネット生命保険様では、営業担当者（人）が保険を売る代わりにWebサイトがその役割を担っているので、Webサイトの改善施策を素早く実施できるかどうかが保険契約の獲得数に大きく影響します。
そのため、ライフネット生命保険様では「フロントエンド(ユーザーが目にする画面など)の開発」と「サーバーサイド（目に見えない裏側）の開発」を分離して、まずフロントエンドの方から柔軟に素早く改修できるように内製化することをめざしていました。
関連記事
システムアーキテクチャの刷新とアジャイルの導入で、ビジネス要求への迅速な対応を実現
事例2.工場の業務改善のためのアプリの内製化
本田技研工業様のある工場では、従来、業務用アプリの開発をシステム開発会社に外注されていました。その当時は発注時の要求を満たすアプリが仕上がってきても、現場に導入すると業務でうまく活用されない（不便なためにユーザーに使ってもらえない）というケースが多々あったそうです。
そこで、業務用アプリの開発を外注するのではなく、自分達で開発して、使いながら継続的に機能追加などをできる体制づくりをめざして内製化に取り組まれていました。
関連記事
アジャイルと内製化で実現するユーザーが本当に欲しいシステム
事例3.業務アプリの内製化に備えた人材育成
非公開の事例なので社名は伏せますが、ある製造業のお客様は「クラウドサービスの進化などにより以前と比較して簡単にアプリ開発ができる環境が整ってきた」という背景を踏まえて、将来は業務改善に必要なツールを自社でつくりたいとの考えをお持ちでした。
そこで、まずはDXチームの数名の方を中心として、将来のシステム内製化に備えた人材育成の取り組みをはじめられました。
なぜ内製化なのか？
先に挙げた3つのNCDCの内製化支援事例からもわかるとおり、内製化によって実現したいゴールは企業ごとに違います。
しかし、一般的に内製化の目的として共通する要素はいくつか挙げることができます。
よくある内製化の目的
- 柔軟な仕様変更を可能にしたい
- ソフトウェア開発のノウハウを獲得したい
- 品質、期間、コストなどを自分たちでコントロールしたい
先述した3つの事例の中では、ライフネット生命様と本田技研工業様の主な目的は「1.柔軟な仕様変更を可能にしたい」にあてはまります。
製造業（社名非公開）のお客様は「2.ソフトウェア開発のノウハウを獲得したい」を主な目的とされています。
「柔軟な仕様変更が可能」になると何が良いのか？
内製化による「柔軟な仕様変更」とはどういうことでしょうか？
従来型のシステム開発と「柔軟に方向性を調整しながら開発する場合」の違いは以下の通りです。
（従来は）要件定義から一方向で開発を進める
従来型のウォーターフォールと呼ばれる進め方では、最初に全体の要件定義を行い、その後は決まった要件を一気に開発していく流れになります。水が上から下へ一方向に流れるように、要件定義が終わった後は仕様の検討に戻れない進め方です。
そのため「もしかしたら必要になるかも」程度の機能も含めて、要件定義時に過剰な要求を詰め込みがちな傾向があります。
ウォーターフォール型の進め方は予め決めたものを寄り道せずに作りあげていくので、コスト・期間は相対的に小さくなるのがメリットですが、できあがったシステムが必要十分なものかどうかは「要件定義次第」になってしまうことがデメリットだといえます。
要件定義が完全ならば問題ないですが、もし要件定義に不足があって後から重要なユーザーの意見が出てきた場合にこの進め方は対応できません。また、要件定義が過剰だと作った機能の多くが実際には使われない無駄だらけのシステムになることもありえます。
柔軟に方向性を調整しながら開発する場合
アジャイルと呼ばれる進め方の場合は、まず小さな要件だけ決めて、短期間で（たとえば2週間程度で）開発を行い、できたものをすぐテストするというサイクルを繰り返してシステムをつくっていきます。
この場合、従来型のウォーターフォールと異なり途中で仕様変更が可能です。テストのやり方はさまざまですが、いずれにしても小さな規模の開発をしては検証をして、フィードバックを得ながら次に進めるので、ウォーターフォールと比べると要件の不足や過剰が起こりにくく「必要十分」なシステムになっている可能性が高いといえます。
ただし、作っては試し、時には方向転換をして、いわばたくさんの寄り道をしながらシステムをつくるので、相対的にコスト・期間は余分にかかることになります。
一概にどちらが正解とはいえないので「最初の要件定義で必要十分なシステムを決められるようなものであればウォーターフォールで」「試しながら作らないと必要十分なシステムの実現が難しい場合はアジャイルで」というふうに、目的によって使い分けるのがおすすめです。
なぜ「ソフトウェア開発のノウハウ獲得」をめざすのか？
最近は業務改善でも新規事業開発でもソフトウェア開発がほぼ必須になっています。そのため業務や事業内容を理解していて、かつソフトウェア開発の勘所もつかんでいるような人材を社内で育成できているかどうかが、プロジェクトの成否を決めるとても重要な要素になってきています。
内製化によりノウハウを自社内に得ることはさまざまなメリットがありますが、とくに次の2つは大きな要素です。
- プログラミングやAWSなどクラウドを活用する技術的なスキルが貯まる
- システム開発において「これを作るとしたら何が難しい／ 簡単」という判断が自社でできるようになる
開発の難易度を自社で判断できるメリット
2つめに挙げたメリットはわかりにくいかもしれないので、少し詳しく説明します。
たとえば、システム開発を外注した時に「思ったより費用が高い。本当にこんなにかかるのか？」と疑問を感じた経験はないでしょうか？
ソフトウェア開発の見積もりでは「この機能の開発は2日でできそうだが、想定外のエラーに引っかかると半日は潰れるので、バッファをみて2.5〜3日で計算する」ということがよく行われます。
開発を外注している場合、このバッファをどの程度とるべきか外注先が判断しており、開発工程に入ったら発注者の知らないうちに外注先の人が工数のやりくりしていることがほとんどです（いちいち発注者に「3日で見積もったけど開発は2日で十分だった」等の報告がされることはないはずです）。
その結果、発注者側にはなかなか本当の実装難易度の知見は溜まりません。
自分達で実際に開発にも取り組んでみることで、たとえば「この機能は AWSが提供するサービスがそのまま使えるから1日で十分だ」とか「このUIはあのライブラリを使えばすぐ実装できるはずだ」ということが判断できるようになります。
柔軟性獲得のためにもノウハウは必要
内製化により柔軟に変更を取り入れるといっても予算や期間が無制限ではないはずなので、計画内で収まるよう内製チームが開発の難易度を適切に判断できる必要があります。そのため、開発の途中で方針変更を求める意見が出たら、その変更が本当に必要なのかや、変更したらスケジュールにどう影響するのかを短期間で判断できる知識は重要です。
また、コストや期間の妥当性が判断できるようになることは、開発を外部に委託した際の外注先のコントロールにも役立つので、自社ですべてを内製しない場合でもこうしたノウハウを社内に獲得しておくのは有用です。
「品質、期間、コストなどのコントロール」とは？
よくある内製化の目的の3つ目として挙げた「品質、期間、コストなどを自分たちでコントロールしたい」については、前述した「ノウハウの獲得」と似たところはありますが、もう少し詳しく説明します。
従来のやり方（開発を外注先に依存していた場合）だと、システムの実現にどのくらいの期間や費用がかかるのかは外部ベンダーに見積もってもらうまで全くわからない上に、外注先の都合によって開発の着手時期が先延ばしになってしまったり、完成品を見てからイメージしていたものとのズレが発覚したりするケースもあったのではないでしょうか。
システム開発の主要部分を外部に依存している限りはこの問題の解消は難しいため、内製化により自分たちでシステム開発の主導権を握るような体制を目指すのが「品質、期間、コストなどのコントロール」です。
内製化のよくある課題
つづいて内製化の取り組みをはじめた企業のよくある課題を2つご紹介します。
開発者が変わっただけで柔軟性がない
ひとつめのよくある課題は「開発を内製化しても柔軟な対応ができていない」という問題です。
これは、内製化しても、開発プロセスが外部に開発を委託していたときと変わらない場合に生じがちな問題です。
最初に要件定義をしたあとはしばらく開発チームだけで作業を進めて、ユーザー（たとえば発注者の位置にいる事業部）は最後の受入れテスト時だけ登場するという進め方では、せっかく内製化しても柔軟なシステム開発は実現できません。「作ってはユーザーに試してもらい、時には方向転換をする」というプロセスがないためです。
また、「業務とITの間の壁」も問題の原因としてよく出てきます。
内製化に際して、従来はシステムの発注者という立場だった「業務側の人」を開発チームの重要なポジション（プロダクトオーナーなど）に据えるケースは多いようです。しかし、重要なポジションの人が既存業務で忙しくて開発に深く参画できないようだと、めざすべきプロセスが機能しなくなってしまいます。
反対に「IT側の人」がプロダクトオーナーに立つ場合は、「業務側の人」がITのことは専門家に任せておけばいいとのマインドから抜け出せず、結局は内製化しても「業務とITの間の壁」が取り払えないという問題が起きがちです。
こうした背景から、内製化はしたものの柔軟な対応が実現できていないケースはよくあるようです。
いつまで経っても開発が完了しない
もうひとつの内製化のよくある課題は「スケジュールがどんどん遅延して、いつまでも完了しない」です。
アジャイルで開発を進める場合、短期間（1〜2週間）で開発を区切り、一度つくったものを振り返る確認の会（スプリントミーティング）を行うのですが、この会議の度に大きな変更が発生すると、いつまでもリリースに至らないという問題が起こりえます。
理由のひとつとして、開発しているサービスの目的などについて関係者の認識が不揃いであることが考えられます。たとえば開発チームが作ったものを関係者にテストしてもらう際に、本来検証すべき点と全く違う論点ばかり持ち出されてしまうと、プロジェクトはなかなか前に進まなくなります。
また、関係者からで出てきた変更要望の重要度をプロダクトオーナーが正しく判断できないために重要ではない対応に時間を割いてしまったり、反対に重要な変更をためらってしまったりすることで開発が進まないケースもあるのではないでしょうか。
内製化に必要なもの
これらの「内製化のよくある課題」を考慮して、内製化を成功させるために必要な要素をご紹介します。それは次の3つです。
- 対象プロジェクトの選定
- どのような体制でやるか
- どのような開発プロセスでやるか
対象プロジェクトの選定
内製化を成功させるには、まず内製化に適したプロジェクトとそうでないものを正しく見極めることが重要です。
最初に挙げたライフネット生命保険様のように「フロントエンドの開発」と「サーバーサイドの開発」を分離して一方だけ内製化するという判断をするのは、とても重要な戦略だといえます。
この戦略と、すでに社内で保有している技術やノウハウ、開発対象となるプロダクトの特性などの条件を加味して内製化の対象を判断するのがおすすめです。
下図は内製化対象プロジェクトの選定方法の例です。
開発の難易度と、柔軟性が求められる（予め要件を決めるのが難しい）プロジェクトかどうかの二軸で考えます。柔軟性が必要かつ自社で有するスキルやノウハウから考えて開発の難易度が低い領域が内製化に適していると判断できます。
図の例でいうと、社内向けの小規模な業務改善アプリのようなものは、柔軟に社内ユーザーの意見を取り入れながら、自社で有するスキルだけで開発できそうなので内製化に適しているといえます。
一方で、会計システムのようなものは関連法に沿ったシステムであることが前提になるため柔軟性よりも必要な機能を計画通りにつくることが重要ですし、規模も比較的大きいシステムなので（難易度が高いので）、内製化には向いていないと判断できます。
（上記の二軸はあくまでも一例として挙げたものでテンプレートではありません。どのような評価軸を用いるかは自社の内製化の目的に合わせて検討する必要があります。）
とはいえ、こうした戦略や、作りたいシステムと社内で保有している技術との相性を考えるのもそう簡単ではありません。
内製化のはじめの頃は既存のITパートナーやコンサルティング会社にどのプロジェクトを内製化の対象とすべきか相談してみるのも良いと思います（NCDCでも内製化対象プロジェクトの選定から支援した実績があります）。
どのような体制でやるか
先に紹介した本田技研工業様は、製造部門の中に工場で使う業務用のアプリケーションなどを開発するITチームをつくられていました。
このチームはプロダクトオーナーとフロントエンドエンジニア、バックエンドエンジニア、デザイナーなど8人程度のメンバーで構成されていて、1チームで独立してシステム開発を進められる体制をとっています。最終的にはそのようなチームが複数つくられていました。
このケースでは「1チームで独立してシステム開発を進められる体制」が重要だったのですが、その詳細は別記事で詳しく紹介しているので、ぜひ併せてご覧ください。
従来システム開発を外注していた企業が「内製化するならそのチームだけでシステム開発を進められるメンバーをそろえた方が良い」と言われても、社員だけでいきなりそのようなチームをつくるのは難しいでしょう。
その場合、既存のITパートナーなどに人的な支援を相談してみるのも良いと思います。実際に、本田技研工業様の内製チームも社員のエンジニアと外部に業務委託したエンジニアが混在した体制でした。NCDCも必要に応じてコンサルタント、エンジニア、UX/UIデザイナーを内製チームに参画させるようなかたちでサポートしていました。
どのような開発プロセスでやるか
開発プロセスとは、簡単にいうとアジャイル的な進め方でやるのかウォーターフォール的な進め方でやるのかを考えることです。
先述の通り、一概にどちらが正解ということはないので目的によって使い分けるのがおすすめですが、柔軟性の獲得を内製化の目的に含む場合はやはりアジャイル的な手法は重要です。
その場合、途中で方向転換はあるにしても、何が達成できているのか、当初の計画とのギャップはどの程度あるかなどを定期的にチェックする工程が必要になります。
先に「開発しているサービスの目的などについて関係者の認識が不揃い」という問題がよく生じると紹介しましたが、最初から関係者の認識が揃っていなければ達成度やギャップを把握することは到底できないので、最後に、その対策として重要な「インセプションデッキ」をご紹介します。
インセプションデッキとはチームが共通認識を持つために行う一般的なアジャイルの工程のひとつです。検索していただくと多くの情報が見つかると思いますが、ここではNCDCがよく用いるものを3つ簡単にご紹介します。
私たちはなぜここにいるのか
NCDCがアジャイル開発に取り組む際は「私たちはなぜここにいるのか、何を達成しようとしているのか」を定義する作業を最初に行います。該当プロジェクトの存在理由をメンバー全員で確認することで、共通の認識と目標を持ってプロジェクトに取り組むことをめざします。
エレベーターピッチ
NCDCではエレベーターピッチという手法もよく用います。エレベーターピッチとは、短時間で自分の意見を的確に伝えるプレゼンのことを指しており、投資家とエレベーターに乗りあわせた15〜30秒の短時間で投資の同意を得られるくらい的確にプロジェクトの魅力を説明するということを意味します。
社内のプロジェクトにおいては30秒で同意を得ないといけない状況はあまりないでしょうが、作ろうとしているサービスを簡潔に説明できるように資料をまとめてチーム内の共通認識とするためにこの手法を応用できます。
やらないことリスト
NCDCでは、やらないことリストもよく作成します。
これは、少なくともプロジェクトの初期においては「これはやらない」というものを決めておくことで、目的がぶれるのを防ぐ手法です。
必ず30秒で説明できる資料を用意しなければならないとか、やらないことリストがないとプロジェクトが進まないということはないので、これらも目的によって使い分けるものです。
ただ、最初にこれから作るサービスの意義を簡潔に定義し、関係者の合意形成しておくことはとても重要です。NCDCではワークショップなどを行ってこうした合意形成を図る支援を行なっており、ワークショップのコンサルティングやファシリテーションを提供している実績もあります。
効果的な関係者間の合意形成手法に迷われた際はご相談ください。
DevOpsも内製化の重要テーマ
内製化やアジャイルをかたるにはDevOps（開発と運用の一体化）も切り離すことはできません。
DevOpsの重要性や、具体的にどのように実現していけばよいのかは、別記事で詳しく紹介しているので、ぜひ併せてご覧ください。
内製化やDevOpsのご相談はNCDCへ
NCDCは、AWSの「内製化支援推進AWSパートナー」に参加しており、豊富な実績と知識で内製化をサポートすることが可能です。
クラウドネイティブなシステムの設計や、柔軟なシステム運用を可能にする先進的な開発手法などの知見・技術をお伝えすることで、ユーザー企業が自走できる開発チームを社内に立ち上げる支援をしています。
内製化についてお悩みの方は、ぜひ一度NCDCにご相談ください。
