最近ソフトウェア開発の内製化が話題に成っていますが、実際に内製化に取り組まれている企業はどのような結果を出しているのでしょうか？
こんにちは。
ライジングサン・システムコンサルティングの岩佐です。
システム開発の内製化を進める上で、ぜひ手にとっていただきたい本があります。
それが、日経BP社マーケティングより出版されている「開発・改良の切り札 システム内製を極める」です。
本書は恐らく、国内でも「システム開発の内製化」に特化して書かれた唯一の書籍と思われます。初版が2011年の7月と若干古い書籍ですが、実際に読み解いていけば極めて普遍的。
現在でも十分に通用する内容だと思います。
この記事は、本書の書評も込めて、システム開発内製化の先進企業から学ぶ３つの教訓というテーマでお伝えしたいと思います。
本書から私達が学ぶことのできる教訓は、つぎの３つの点です。
1.適切なポートフォリオを組むことの重要性
2.適切な開発プラットフォームを選択することの重要性
3.変化に対応することの重要性
本書の特徴は、実際に内製化へ舵（かじ）を切った企業の具体的な取り組み、そして実際に現場を指揮した情報システム責任者やエンドユーザの声が豊富に伝えられていることです。
そこには理屈だけの内製化ではありません。非常に泥臭く、そして人間味あふれるドラマが展開されています。それだけに、非常に記憶に残りやすく、深い学びを得ることができます。
本書ではシステム開発の内製化をより解りやすく「ユーザ主体開発」と表現しています。
これは、物理的な設計やプログラミングまでを内製化しなくとも、上流工程においてユーザ企業がイニシアティブを握る体制を取っていることが重要という意味を込めてのものだと思います。
目次
本書を読み進める上での３つの問い
今回は、下記３つの問いを立て、それに答える形で本書を解説してみたいと思います。
まず問１として、「ユーザ主体開発とは、具体的にどのような行動を伴うものなのか？」
次の問２として、「具体的にどのような分野のシステムを内製で開発しているのか？」
最後の問３として、「具体的にどんな成果を得ているのか。そして収益性の向上に役だっているのか？」
…としました。
恐らくこれらの問いは、内製化を検討している、もしくは具体的に取り組み始めている企業にとって共通の問かと思われます。
それでは、それぞれの問いに答える形で本書を解説し、最後のまとめで私達なりの意見を書いてみたいと思います。
問１：ユーザ主体開発とは、具体的にどのような行動を伴うものなのか？
まず本書で語られる「ユーザ主体開発」とは、具体的にどのような行動を伴うものなのかを見て行きたいと思います。
ここで「具体的な行動」に着目したのは、「主体」という言葉が非常に抽象的な概念だからです。
まず本書を読み通すと、内製化に取り組む企業の具体的な行動については３つのパターンが見られました。
ひとつは、RFPやユーザインタフェース、業務設計といった、一般的に言われる上流工程までを自社で行い、具体的なプログラミングや設計に関しては、アウトソーシングするパターン。
次に、超高速開発ツールと呼ばれる開発プラットフォームを用いて、システム開発から運用・保守まで全てを自社で内製するパターン。
最後に、一般的な開発ベンダーと同等の開発プラットフォーム、そして同等レベルの開発体制を構築して、ベンダー顔負けレベルのシステムを内製しているパターン。
概ねこの３つのパターンに分類されます。
そして、この３パターンのどれにも共通していることはユーザ企業がイニシアティブを握るという点は当然として…
特筆すべきは「外部ベンダーを非常にうまく活用している」という点です。
パターン１：上流工程のみを内製化
例えばパターン１の上流工程のみを内製化している企業に関しては、自分たちでプログラミングはしていません。また、システムリリース後の運用・保守も基本的にはベンダーにアウトソーシングしています。
しかし、自分たちでRFPを書き、業務設計を行い、そしてユーザインタフェースの設計までをユーザ主体で実践しています。
さらに重要なのは、どのケースもベンダーからもたらされたソフトウェアを自分たちの手でしっかりとテストしていることです。
これは至極当たり前のように思えますが、実は非常に重要な事です。
ユーザ企業の中には、テストを面倒くさがり、形ばかりの検収ですませるケースが散見されます。しかしこれは「ベンダー丸投げ」の象徴のようなものです。
さらにここで確認しておきたい事があります。
それは、この上流工程と呼ばれるフェーズを担当しているのが「情報システム部門」では無いということです。
事例として出てくる宮田眼科病院は、現場の看護師や検査員が、自らBPRを推進し、そして自らがPowerPointを使ってユーザインタフェースを設計していました。
そして、ベンダーが開発したソフトウェアを、自分たちで評価し、そして具体的にフィードバックすることでソフトウェアの完成度を高めていった様子が紹介されています。
これまでも、上流工程は自社で行い、実際の開発はベンダーに任せるというスタイルで開発をしてきた企業は多いと思われます。
しかし、この場合の上流工程を受け持つ部署はほとんどが情報システム部門でした。
一方、今回紹介されていた事例は、情報システム部門ではなくエンドユーザ自身が、この上流工程を担当していました。
これには私達も非常に驚きました。専門知識のないエンドユーザがここまでできるのかと…
しかし、これにはしっかりとしたセーフティーネットがありました。
いずれの事例も、外部のコンサルタントがしっかりとその活動をフォローしていました。
このように、内製化がうまく行っているケースでは、外部ベンダー・外部ブレーンとうまく付き合っています。
これは、パターン２・パターン３のケースでも、共通して確認できたことです。
内製化がうまく行っている企業は、自分たちが果たすべき責任と、ベンダーの果たすべき責任を明確に定義し、それぞれの立場でプロとしての仕事をしていることが読み取れます。
パターン２：超高速開発ツールを導入して開発・運用の全てを内製化
パターン２の超高速開発ツールを活用した内製化についても、ベンダーとの良好な付き合いが欠かせないようです。
なぜなら、ツールの持つ特性を引き出し、より開発生産性を高める、ツールの向き不向きに合わせて設計を柔軟に調整するといった部分に置いては、やはりツールに精通しているベンダーに一日の長があるからです。
また、いくら有能なツールを用いての開発とは言え、大規模な開発養成や、スタッフの退職・異動等で一時的に人手が足りなくなることも出てきます。
そんな時に、自社のことをよく理解しているベンダーであれば、一時的なヘルプを依頼することもできます。
このようにして、内製化を成功させている企業は外部ベンダーを非常にうまく使っているという印象を受けました。
パターン３：メインストリームにある開発プラットフォームで全フェーズを内製化
パターン３のベンダー顔負けの本格的な開発体制を構築しての内製化においても、やはりベンダーとの上手な付き合いは欠かせないようです。
その理由は、自社のプログラマだけでは対応しきれない緊急性の高い開発案件、及び難易度の高い実装要求が出てきた場合の大きな助けになるからです。
ここで重要なのは、外部ベンダーに仕事を依頼する時に「何をどのように依頼すれば、どういった品質・スピードでアウトプットが得られるのか」を委託側がしっかりと理解し、そしてコントロールできるということです。
また蛇足ですが、例えば会計システムや給与計算システムは、恐らく内製化しているのではなく、パッケージシステムを使っていると思います。
内製化しているのは、あくまでも自社の競争優位性を伸ばすソフトウェアであり、収益性の向上に貢献するシステムだということです。
そして、これに該当しないシステムをいくら内製化しても、そこから得られるビジネス的なメリットはあまり無いと思います。
問２：具体的にどのような分野のシステムを内製化しているのか
実際に内製化を検討している、もしくは内製化に取り組み始めた企業において、他の企業が具体的にどのような分野のシステムを内製化しているのかは気になるところだと思います。
まず「どのような分野」であるが、これは内製化に取り組む業態と、そこで開発されるシステムの種類に大きく分類されると思います。
本書に登場した事例は、宮田眼科病院のような地方の医療法人もあれば、村田製作所や小松製作所といった世界的な製造業もあれば、良品計画や東急ハンズといった極めて大規模な流通業もあれば、大前研一先生率いるビジネス・ブレークスルーといった教育サービス業もあればと、非常にバラエティ豊かな企業が名を連ねていました。
また、登場するシステム自体も大規模な基幹システムから、中小規模の計数管理ツールというレベルまで様々でした。
ここで言えることは「内製化に向く業種・向かない業種」や「内製化に向くシステム・向かないシステム」というのは基本的に無いということです。
よく「うちの会社は特別だから…」「うちの会社の業務は特殊だから…」という声を聞くことがあるが、これはフルアウトソーシングが主流になる前に聞かれた声と全く同じです。
これらは変化を拒絶するための言い訳にすぎません。
もちろん、一般的な企業が会計システムや給与計算システムを内製化することによって得られるメリットはほぼ無いと考えらます。
なので、これらのシステムは一般的には「内製化に向かない」システムと言って良いと思います。
しかし業態ということに目を向ければ、今やどんなビジネスでも情報システムと無縁でいることはできません。
そういった意味では、内製化に向かない業種・業態は無いのではないかと私達は考えます。
また、あえて事例として本書に無かった分野を上げるとすれば、コーポレートサイトに関する内製化の事例です。
私達は、自社のコーポレートサイトは使い方によっては非常に企業の競争優位性を高める武器になるので、積極的に内製化すべきという考えです。
しかし、本書の初版が2011年と若干古いこともありこういった事例は掲載されていませんでした…
それでは具体的に、どのようなシステムの事例が掲載されているのかを、印象的な事例から幾つかピックアップしたいと思います。
上流工程を内製化した事例
まず、宮崎県都城市にある宮田眼科病院は、内製で開発した予約管理システムの導入効果で、患者の平均待ち時間が37%も短縮化。
顧客満足度の向上による再来患者が増加したことで、医療収入の前年同月比はプラスになったそうです。
こちらのプロジェクトでは、先述した通り情報システム部門ではなく、現場の看護師や検査員が業務設計やユーザインタフェースを設計するという主体的な取り組みによってプロジェクトを成功に導きました。
そして、ベンダーとユーザの間をうまく橋渡ししたITコンサルタントの存在も忘れてはいけません。
自社で詳細な技術がわからない場合は、このように利害が対立することのない第３者のコンサルタントやファシリテーターを間に入れてプロジェクトを円滑に回すという方法は極めて有効な手段です。
実は私達も、FileMakerプラットフォームでの開発を始める前は、この立場でプロジェクトをサポートしていた時期があります。
現在はこの分野のビジネスはクローズしているが、「ITコーディネーター」とよばれる職種の方々は、基本的にこのポジションのビジネスを展開されている方です。
GeneXusの事例
次に超高速開発ツールであるGeneXusを利用したプロジェクト事例が豊富に掲載されていたのも印象的でした。
GeneXusとは、南米ウルグアイのITベンダーであるアルテッチが開発・販売するアプリケーション自動生成ツールです。
データ項目や画面、業務ルールといった設計情報を入力すると、対応するプログラミング言語のソースコードを自動的に生成するコードジェネレータです。
実は私達もこのGeneXusは数年前から気になっており、つい先日、GeneXusの開発で有名な株式会社ウイング様をお尋ねして、紹介セミナーを受講してきた。その様子はまた別の機会にでもレポートしたいと思います。
そしてこのGeneXusを活用した内製化の事例として、鈴廣蒲鉾、丸善、ドトールコーヒー、三菱重工業等の事例が紹介されています。
特に株式会社鈴廣蒲鉾本店の内製化に関する取り組みは非常に詳細に紹介されています。
同社はグループ全体の年商規模が106億円とかなり大きな企業であるにもかかわらず、15ある業務システムの開発・運用・保守は、情報システム部門の５名のスタッフで全て切り盛りしているようでした。
これは、同社の情報システム部門のスタッフ様が、自社の業務とITの両方に精通した非常に優秀なビジネスパーソンであられると同時に、GeneXusという優れた高速開発ツールをうまく活用されていることが要因のひとつだと思います。
内製化を検討している、もしくは具体的に始めている企業に関しても、極めて少人数での社内開発の成功事例として大いに勇気づけられるはずです。
ユニケージ開発手法の事例
次に、最近メディアにも非常に多く露出されている東急ハンズ（現ハンズラボ株式会社）の取り組みを紹介させていただきます。
こちらはなんと、情報システム部門に現場からリクルートしてきた非技術者を短期間でシステム開発ができる技術者に育成し、各種計数分析システム等を内製化しているということでした。
現場からリクルートしてきた理由がまた刺激的ですね…
そしてその理由は「プログラマが現場の仕事をおぼえるよりも、現場のスタッフがシステム開発を覚えたほうが早いから」。
これは経験豊富な技術者ほど否定したい意見だと思います。
しかし、これは私達の経験上からも同意せざるを得ません。
残念ながら、一般的なプログラマやシステムエンジニアと呼ばれる職種の方は、コミュニケーションが極めて不得手で、エンドユーザとの会話が成立しないことが頻繁にあります。
単純に降りてきた設計書通り、要件定義書通りのドキュメントやプログラムを書くことが仕事であれば、それほど困らないかもしれません。
しかし内製化であれば、エンドユーザと作り手が近い距離で親密にコミュニケーションをとることが重要です。
それができないのであれば、いっそ現場のスタッフにシステム開発の教育をしたほうが目的地に早く到達できるという理屈は極めて全うに思えます。
逆を言えば、それほど、現在の超高速開発ツールは進化しているということです。
同社は、Linuxのシェルスクリプト、シェルコマンドだけでシステムを開発するユニケージ手法とよばれる開発手法・開発プラットフォームを導入しています。
さらにこの手法では、データはプレーンなテキストファイルで管理されています。
データベース管理ソフトなどは全く使用しないため、学ばなければならない分野が極めて少ないようですね。
このように内製化に適切なツールの選択は非常に重要な要素になることが、これらの事例からも学ぶことができる。
問３：具体的にどんな成果を得ているのか。そして収益性の向上に役だっているのか？
本書で紹介されている事例では、その効果が必ず次の３つのどれかに当てはまっています。
その３つとは以下のとおりです。
①開発スピードの向上
②システム開発・運用コストの軽減
③高付加価値なソフトウェア開発の実現
これらは全て企業の収益性向上に直結するものです。
もちろん個々の会社の決算書レベルでBefore/Afterを調べたわけではないので完璧な証跡があるわけではありません。
しかし、本書で述べられている「私はこう考える（関係者の回帰録）」には、共通して内製化のメリットが語られており、それは開発スピードの向上、システム開発・運用コストの軽減、そして高付加価値なソフトウェア開発の実現のどれかに当てはまっています。
そして具体的な効果が語れれているプロジェクトもいくつかありました。
宮田眼科病院の事例では、ユーザ主体開発による予約管理システムの導入で、医療収入が前年同月比でプラスになりました。
鈴廣かまぼこの事例では、超高速開発ツールのひとつであるGeneXusを用いることで、VBで社内開発していた時と比較して２倍の開発生産性向上を達成していました。
東急ハンズの事例では、「外部委託する場合に比べて、開発費用は５分の１、開発期間は半分になった」と述べられています。
このように、内製化を通じて、確実に企業の収益性向上に貢献するソフトウェアを開発している企業は確実に存在します。
先進企業から学ぶ３つの教訓
私達は本書から３つの教訓を得ました。
1.適切なポートフォリオを組むことの重要性
内製化はあくまでも企業の収益性向上のため、企業の競争優位性向上のための「手段」です。
そのための内製化であり、そのためのアウトソーシングであり、その為の情報システム投資なのです。
そして「投資」という文脈で語られる以上、やはりポートフォリオを最適化することは極めて重要です。
ポートフォリオとは金融投資の世界で使われる考え方で、投資家がリスク分散のために自らの資産を複数の金融商品に分散して投資する手法です。その金融商品の組合せのことをポートフォリオと呼びます。
ソフトウェアを開発し、それを利活用することで企業の収益性向上を図ること、これは情報システム投資です。
たとえ話で、投資の世界では、「同じ卵をひとつのカゴに入れてはいけない」という教えがあります。
そして情報システム投資でも、それと全く同じことが言えそうです。
自社の全てのシステムをアウトソーシングすることに大きなリスクがあるのと同時に、全てのシステムを内製化することも大きなリスクを伴う。
あくまでも達成すべきゴールは、自社の競争優位性を伸ばすことに貢献するソフトウェアを利活用して、実際に収益性を向上させることなのです。
2.内製化に適切な開発プラットフォームを選択する。
本書ではGeneXusやユニケージ手法といった超高速開発ツールが多数紹介されており、そのツールを利活用した内製化の成功事例が多数掲載されていました。
これらのプロジェクトが、一般的なベンダー企業が使うような開発言語や開発ツールを使っていたら、今日の成功は極めて困難だったと思います。
残念ながら本書にはFileMakerプラットフォームを活用した事例は紹介されていませんでした。
しかし、FileMakerジャパンのWebサイトにあるユーザストーリーでは、内製化によるプロジェクトの成功事例が多数掲載されているので、ぜひそちらもご参照頂きたいと思います。
ここで重要な事は、「何のための内製化か？」といった上位概念の目的が先にあり、その目的を具体的に達成する最も適した開発プラットフォームを選択するという戦略思考です。
「取りあえず何でもできそうだから、◯◯を選んでおけば大丈夫だろう」「世の中でたくさん使われているから、取り敢えず◯◯を選んでおけば大丈夫だろう」という思考は全く戦略的ではありません。
ぜひ、実装まで含めた内製化を検討するのであれば、広くその開発プラットフォームを調査・研究してほしいと思います。
3.変化を受け入れる重要性。
現在のフルアウトソーシングのトレンドは、約２０年前の「ダウンサイジング」や「オープン化」、そしてインターネットの台頭に端を発します。
それまでビジネスで使われる情報システムは、主にメインフレームやオフコンと呼ばれるもので、開発言語はCOBOLやPL/1といったOA化を目的に開発された言語でした。
これらの言語はある意味良く出来ていました。
記述するコードにはビジネスロジックの割合が多く締めており、ネットワークが切断されるであったり、データベースに接続できないであったり、時にはOSのバグに対応するといったエラーハンドリングロジックを書くケースはほとんどありませんでした。
プログラマはビジネスロジックの記述に集中することができ、プログラミングにOSやネットワークの知識はそれほど必要ではありませんでした。。
また、当時リレーショナル・データベースはまだ珍しく、データベースと言ってもISAMファイルやNDBといった原始的な仕様のファイルを処理することでOA化を実現できてました。
つまり、プログラマはプログラミング技術の習得にそれほど多くの時間を割く必要はなく、その分を、ビジネスや業務の理解に費やすことができました。
そんなところに、ダウンサイジングとオープン化の波が押し寄せてきました。
これによって、システム開発・運用のプラットフォームは劇的に安価になりました。
しかし、それと引き換えに、プログラマがビジネスロジック以外の様々なことを考慮しながらプログラミングすることが求められるようになりました。
システム開発・運用環境が安価になった代償として、プログラマに求められるプログラミングの知識や技術が膨大に増えたのです。
IT業界は、これに対応するために分業化が図られました。
ネットワーク専任のエンジニア、データベース専任のエンジニア、サーバ構築専任のエンジニアなどが登場しました。
また、プログラミング言語もインターネット技術の台頭、さらにシステム開発・運用環境やインフラの多様化によって爆発的に増え、そしてその言語のスペシャリストがそれぞれ登場しました。
これらの専門家を全て社内でまかなっていては膨大な人件費が必要になってしまいます。
そこでアウトソーシングという考え方が主流になってきました。
当時「戦略的アウトソーシング」という言葉が頻繁に使われ、アウトソーシングこそが企業の競争力優位になると謳われていました。
そしてその波は、不景気とともにさらに増大しました。
さらには人件費…すなわち固定費を削減するために、できるだけ社内には技術者を確保せず、「持たない経営」としてフルアウトソーシングという考え方が出てきた。
これが、ここ15〜20年のビジネスシーンにおけるITのアウトソーシングの歴史です。
しかし、このトレンドが再び内製化に振れようとしています。
その背景は、時代の要請です。
そしてその要請とは「スピード」です。
現在のトレンドになっているフルアウトソーシングでは、ビジネスの変化・スピードに対応できないのです。
例えばフルアウトソーシングにおいては、受託者・委託者お互いのリスクを軽減するため、契約プロセスを慎重に進めます。
このプロセスに極めて多くの時間と労力が割かれます。
このことで、契約プロセスの詰め…
つまり商談に半年以上を費やし、実際の開発プロジェクトは３ヶ月で終了…
…なんてことも発生しています。
本来であれば、この商談に費やした半年の間に、システムを開発・リリースし、既にリターンを得るフェーズに入れるだけの時間を費やしているのです。
今の日本ではこのようなことがあちこちで散見されています。
商談も契約書も、ビジネス的な価値、つまり収益を上げるという点では全くの無価値です。
そして情報システム投資において価値が有るのは唯一、実際に動くソフトウェアだけです。
この実際に価値を生むソフトウェアを、より早く、より経済的に調達するには、やはり内製化は避けて通ることができないと思います。
そもそも、フルアウトソーシングの流れも、その本質は「スピード」を追い求めた結果です。
当時は、一人の技術者にネットワーク設計、データベース構築、サーバ構築、データモデリング、プログラミングといった広大なスキルを短期間で獲得させることは非常に難しい時代でした。
そこで、分業化を進めることで技術者の育成を早め、その結果がアウトソーシングにつながりました。
時代が要請することの本質は常に同じ、スピードなのです。
変化の痛みを乗り越えて強みに変える
これまでフルアウトソーシングに慣れ親しんできている企業にとって、この変化への対応は、かなりの痛みを伴うと思います。
これまでは「ベンダーマネジメント」であったり、「社内調整」といった仕事がメインだったにも関わらず、設計やプログラミングのスキルが急速に必要になってきたからです。
実際、本書の事例でも、設計やプログラミング経験の無い現場のスタッフや、情報システム部門スタッフの苦労ぶりが紹介されています。
恐らく実際の現場では、様々な衝突・葛藤・混乱があったことだと思います。
しかし、その苦労を乗り越えた企業は、それに相応しい成果を手に入れていることも確かです。
重要なのは変化を受け入れるということです。
ダーウィンは進化論の中で、「生き残るのは強いものではなく、変化に最も対応できるもの」と説きました。
恐らくこれは、ビジネスにおいても同じです。
今や、ビジネスとITは不可分のもの。
なので、自社の競争力を優位に保つため、そして自社の強みをより強化するためのシステムを、自らの手で開発・運用できる企業が、競争上において優位であることは疑いようのない事実です。
この長い文章をここまで読んで頂いたあなたであれば、内製化に対する熱い思い、そして強い信念をお持ちのことだと思います。
このブログ記事が、あなたにとって有益な情報であれば幸いです。
※この記事を読まれた方には、こちらの記事もおすすめです。
