ソフトウェアの内製化は社内システムの全てを自社で開発すれば良いというものでありません。
また、ソフトウェア開発業務にフォーカスしても、すべての業務を内製化すれば良いというものではありません。
こんにちは。
ライジングサン・システムコンサルティングの岩佐です。
ソフトウェアの内製化を検討するときは、より戦略的に…つまり投資対効果の低いムダな費用や時間、労力がかかるような開発をしないためには３つの視点で内製化の戦略を立てる必要があります。
その３つの視点とは、
・何の業務をサポートするシステムを内製化するか？
・どのような手段で内製化するか？
・誰が開発を担当するか？
の３つの視点です。
そしてこの３つの視点から考察する上で重要な事は、ぶれない判断基準を持つということです。
このぶれない判断基準はやはりシンプルに、QDCと呼ばれる品質・スピード（納期）・そしてコストのバランスで考えることが肝要だと思います。
ここで重要なのは、「システム開発」のQDCではなく、ビジネスや業務に関するQCDであるとうことです。
目次
1.何の業務をサポートするシステムを内製するか？
例えばあなたの会社が、物を製造してお客様に届けることが主たるビジネスであれば、お客様に届くモノの品質が向上する、お客様からご発注いただき、そして納品するまでの時間が短縮できる、そして製造原価が安くなるということに着目すべきということです。
例えば一般的に「製造業」と呼ばれるビジネスをしている企業に対して、会計業務や人事給与計算の業務に関するQDCを向上させたとしても、事業全体のQDCを向上させることは難しいでしょう。
それよりも、生産管理システムを構築して、お客様からいただいたオーダーの納期短縮をはかり、品質管理を徹底するための仕組みを導入して製造するアイテムの不良品率を下げるようなシステムを導入するほうが、そのビジネス全体のQDCの向上に貢献できることは容易に想像できます。
また極端な話ですが、会計業務や人事給与業務等の「間接業務」は、その気になれば100%アウトソーシングすることができます。
このような間接業務をいくら効率化したところで、そのビジネスの直接のサービス提供者であるお客様へのフィードバックはかなり小さなものでしょう。
如何に直接お金をいただくお客様に対して大きなフィードバックができるかどうか、その為に、自社業務のどの部分、もしくはどの流れのQDCを向上させる必要があるかという視点が極めて重要です。
また何の業務をサポートするシステムを内製化するか…を考えるときには、自社の業務全体を俯瞰すると同時に、業務の役割毎に要素分解しながら考えることが重要です。
今回は２つ視点。フロントエンド業務とバックエンド業務、そしてバリューチェーンによる要素分解についてご説明したいと思います。
1-1.フロントエンド業務とバックエンド業務に分解する
フロントエンド業務とは、お客様や見込み客と直接的な接触がある業務を表します。例えば営業は最もイメージしやすいフロントエンド業務のひとつでしょう。また、潜在顧客のニーズの掘り起こしや見込み客の開拓が主たる業務であるマーケティングもフロントエンド業務のひとつとして位置付けられるでしょう。
営業スタッフのQCDが向上することは、そのビジネスにもたらす直接的な収入が増大する可能性があります。例えば、50名の営業スタッフが現在抱えている商談の進捗状況や確度、問題点、顧客のニーズなどが全てデータベース化され、iPadやiPhone等のモバイル端末からいつでもその状況を参照できたりアップデートできたりすれば、これまで大量の紙とスタッフ同士の会話で共有していた情報の流れがスピードアップします。
また、情報も文字情報だけではなく、スマホのカメラで撮影した写真や動画などのメディアに対応したシステムであれば、情報そのものの質が著しく向上します。
さらに、過去の成功事例やお客様からのクレーム等がデータベース化されていて、それを誰もがどこからでも参照・更新できるような仕組みが構築されていれば、お客様に対する業務品質の向上も期待できるでしょう。
一方マーケティングに目を向けると、今どの会社も「新規顧客の開拓」「集客」のために、昔のような新規担当の営業が電話でアポイントを取って訪問して自社の商品を説明して…という売り込み型の営業が非常に嫌われる傾向にあります。
その為に、こちらからお客様の元に出かけていくのではなく、まずはお客様に有益な情報をご提供し、自社に対して興味を持ってもらい、お客様からコンタクトがあったらはじめてお会いする…というスタイルに変わりつつあります。
その為には、潜在顧客・見込み客に対して有益な情報、つまりコンテンツを継続的に、そして戦略的に届ける必要があります。そしてこのような手法を一般的に「コンテンツ・マーケティング」と呼びます。
これまでのマーケティングは、どちらかと言うと調査であったり企画であったりという側面が強かったのですが、ネット上でのコンテンツ流通の仕組みが完全に整ったことで、マーケティングの役割はより積極的に見込み客や潜在顧客にネット経由で接触し、自社が発信する情報に反応してもらい、そして自社に興味を持ってもらうことに変わってきています。
このような業務のQCD向上も、営業スタッフのQCD向上と同じく見込み客の獲得向上に貢献する業務分野です。
一方バックエンド業務とは、既存顧客や潜在顧客とは直接接触の無い業務を表します。
例えば製造業で言うと、原材料の仕入れや在庫管理を担当する購買部門、ものを作る製造部門、つくったものを出荷する物流部門などは、お客様と接触することはない業務なのでバックエンドに分類することができます。
また、バックエンド業務というと、これ以外にも経理部門や生産管理部門、総務や情報システム部門もバックエンド業務にあたるでしょう。ただ、ひと言でバックエンド業務と言ってもこれらの業務はその役割の違いから２つに分類することができます。
それが「主業務」と「支援業務」です。
1-2.バリューチェーンモデルの主業務と支援業務に分解する
バリューチェーンモデルとは、あるビジネスの最終アウトプットに必要な資源の調達から製品・サービスがお客様に届けられるまでのビジネス活動を、価値の連鎖として捉える考え方です。
これは経済学者のマイケル・E・ポーターが提唱した理論で、「バリューチェーン」と検索するとより詳しい情報が出てきます。
こちらは一般的な製造業のバリューチェーンを図式化したものです。
この図では、その企業の製品やサービスがお客様に届くまでの価値の連鎖が左から右に進んでいくことを著しています。
そして、その流れの中で、企業内にある様々な専門機能…ここでは業務と表現しても良いかもしれません。
その専門機能・業務がどの様に連鎖しているのかが表現されています。
さらにこの専門機能は、「主活動」と「支援活動」に分かれています。主活動は購買物流→製造オペレーション→出荷物流→マーケティングと販売→サービスという連鎖になっています。一方、支援活動は人事資源管理・技術開発・調達活動等、一般的に「間接部門」と呼ばれる機能を表しています。
自社の業務をこのバリューチェーンに当てはめた時、どの部分の業務、もしくはどの業務の流れのQCDを改善すれば、よりお客様に対するフィードバックが大きくなり、ひいては企業の収益性に貢献するでしょうか？
恐らくこの問に関する絶対的な答えは無いと思います。
なぜなら、その企業のマーケットにおける位置づけや、取り扱っている製品・サービスの性質、もしくはその企業が属するマーケットのSカーブ上のどこにいるかといった外部環境。さらには、間接費・販管費比率、支援活動のQCD向上が、主活動のQCD向上にどの程度貢献できるかの社内的な仕組みの問題といった内部環境の２つの変動要素が複雑にからみ合うからです。
なので、一概に「この部分がボトルネック！」と判断することは難しいでしょう。
これは、個々の企業の成熟度やマーケットの環境によって変わってくるので、よく分析する必要があると思います。
重要な事は「全体の流れ」をスムーズにすることと、ボトルネックを見つけてそこを改善することです。
2.どのような手段で内製するか？
ソフトウェアの内製化が語られる時に、とかく「シロウトにシステム開発なんてムリ」という論調があります。
しかし私達のクライアント企業様は、下手なシステム屋がつくるよりもよほどビジネスに貢献するソフトウェアを自分たちで構築しています。
ではなぜ、私達のクライアントは、下手なシステム屋がつくったソフトウェアよりもビジネス貢献度の高いソフトウェアを内製できるのでしょうか。
その理由は、ソフトウェア開発のどの部分を内製するか、そして何をつかって内製するかという視点。
つまり「何を（What）」と「どうやって（How）」という視点で整理すると、その戦略性が見えてきます。
2-1.ソフトウェア開発のどの部分を内製化するか：Whatの視点
そもそもソフトウェア開発の内製化回帰は、アウトソーシングの問題点を解決するための手段のはずです。このソフトウェア開発のアウトソーシングで最も解決したい問題は、開発スピードです。
ソフトウェア開発のアウトソーシングは、受託側と委託側の双方に大きなリスクが伴うので、そのリスクを最小化するために慎重に契約と商談が進められます。そしていざ開発に入っても、「いった・言わない」を避けるために、プログラム以上に大量のドキュメント…つまり言った・言わないの証跡となる文書を作成します。（もちろんドキュメントの製作目的は証跡だけではありません。）
このような「ソフトウェアで付加価値を生む」という本質的な部分ではない、枝葉的な部分に大量の時間と費用が発生し、そして開発スピードが著しく低下するのがソフトウェア開発におけるアウトソーシングの問題です。
これはアウトソーシングする範囲が大きければ大きいほどお互いのリスクが大きくなるので、この枝葉の部分に該当する作業に多大な時間とコストが発生します。
一方極端に考えて、全ての開発を内製化した時に、そもそも最初に解決したかった「開発スピードの向上」は実現できるでしょうか？
もし向上できるとしても、どの程度の向上が、どれぐらいの時間軸で実現できるでしょうか。
これについても一考の余地があります。
つまり、全てをアウトソーシングすることも、全てを内製化することも、「開発スピードをあげる」という目的…ひいてはソフトウェア開発のQCDを改善するという視点からは、どちらも得策ではないということです。
その為には、どこから何処までを内製化し、どこからどこまでをアウトソーシングするかといった視点が必要になります。
実際、こういった視点はこれまでもありました。そしてそのトレンドは、「IT化の企画や要件定義等の上流工程は内製化し、実際の開発はアウトソーシングする」というものでした。
しかし、このトレンドが産んだ結果は一体何だったのでしょうか。
実態としてソフトウェア開発のスピードは上がったのでしょうか。
もしくは、より開発スピードをあげようと思った場合、本当にこの考え方が最適なのでしょうか。
これもやはり一概にこうだという結果を提示することはできません。
なぜなら、その企業の状況や、企業文化、価値観、そして付き合いのある開発ベンダーとの関係性など、数多くの変動要素があるからです。
しかし確実に言えることは、それぞれの企業ごとに、内製化比率を調整していくことで、確実に開発スピードを最大限に高められる「スイートスポット」があるということです。
重要な事は、現状を良しとせず、より開発スピードを高めてマーケットやお客様からの要求に迅速に対応できる環境整備をすることです。
その実現の為に、一方的にベンダーに対して「速くつくれ！」とハッパをかけるだけでは実現できないことは容易に想像ができます。
極端な話「速くつくれ」「安くつくれ」は、小学生でも言えることです。これはナレッジワーカーとしては最悪の対応と言っても良いでしょう。
速く作るためにはどうすればよいか、その為に自分たちにできることは何か、ベンダーに要求できることは何か…と要素分解し、分析し、計画を立て、それぞれの役割ごとに、適切なアクションを取ることが重要なのです。
2-2.どのような道具を使って内製するか：Howの視点
私達のお客様が、「実装」と呼ばれる直接的なソフトウェアの開発までを内製される場合、FileMakerプラットフォームを採用されています。
ここで重要な事は、一般的なソフトウェア開発ベンダーが使うようなプログラミング言語やデータベース管理システムは使用していないとういことです。
ソフトウェア開発ベンダーは、その技術力をもってお客様からオーダーされたソフトウェアを完成させることに大きな責任を持つため、ありきたりの言葉を使うと「なんでもできる」道具を使って開発をする必要があります。
例えば、一般的なプログラミング言語やデータベース管理システムでは実現できて、FileMakerプラットフォームでは実現できないことは多々あります。
極端な話ですが、今最もホットな開発言語であるJavaScript、もしくはその流れをくむプログラミング言語でスーパーマリオを開発することはできますが、FileMakerでスーパーマリオを開発することはできません。
しかし、一般的なビジネスソリューションを開発する上での機能は必要十分に揃っています。
そして、FileMakerではどうしても実現できないことだけを、外部の専門家に別の開発言語で作るように依頼することも可能です。
これは家の建築に例えると、建物の基礎になる部分や骨組みの施行、もしくは全体の構造設計はプロに任せて、内装やウッドデッキなどはD.I.Y…つまり自前で作るという手法に似ています。
こうすることで、全体コストを下げることができますし、最も重要な「基礎」の部分はプロに任せることで、建物の安全性を担保することができます。
また、FileMakerプラットフォームは、一般的なプログラミング言語とデータベース管理システムの組合せでの開発と比較すると圧倒的にコーディング量が少ないのが特徴です。
その御蔭で、開発スピードの向上と、バグの内在率。つまり多大な労力をかけなくてもそれなりの品質でソフトウェアを構築することが可能なのです。
これも家づくりに例えると、ソフトウェア開発ベンダーが、その家１件のために、材料となる柱一本一本を切り出して、専用に採寸し、お客様の細かなオーダーに応えてものを作るのに対して、FileMakerプラットフォームでの開発は、決められたパーツを限られた技術をうまく組み合わせて、ソフトウェアの付加価値を最大化するスタイルになります。
その分、細かな融通は効きませんが、一方、ソフトウェアが完成するまでの時間とコストは大幅に短縮することができます。
また、ソフトウェア開発の内製化が語られる時、「どんなエンジニアを採用すればよいか」といった目利きが難しいという問題や、いざ採用した後の評価基準やキャリアパスの問題が語られることがあります。
こういった問題提起は素晴らしい視点ですし、実際多くの内製化を検討している企業が悩む部分だと思います。
しかし、この問題提起の背景にあるのは、一般的なプログラミング言語やデータベース管理システムといった、プロと同じ道具・プロト同じ手法を使うことが前提になっています。
ノンプロフェッショナルには、ノンプロフェッショナルにマッチした適切なツールを選択する視点を持つと、この問題もまた別の角度から眺めることができます。
内製化を実現するには、経験と技術のあるエンジニアを採用しなければならないという思い込みによって、別の可能性を遠ざけているのは非常にもったいないことです。
ぜひ、FileMakerプラットフォームに代表されるノンプロフェッショナルでも十分に使いこなせ、かつ必要十分なソフトウェアを開発できるツールを検討してみてください。
3.誰が開発を担当するか？
ソフトウェアの内製化を検討する場合、最後の問題として「誰がつくるか」という問題が残ります。
これには大きく２つの答えがあります。
それは、「情報システム部門」と「事業部門」です。
本来、情報システム部門と事業部門がひとつのプロジェクトチームとして機能するのが一番理想的なのですが、人材も予算も限られている中堅・中小企業が、大企業と同じようなフォーメーションで開発プロジェクトを組織することはあまり現実的ではありません。
特に年商が50億円未満の中小企業だと、情報システム部門そのものがないという企業も数多くあると思います。
3-1.情報システム部門が主体となる内製化のメリット
情報システム部門が主体となって内製化を進めるメリットはなんといっても専門性を活かせることと、そして、ソフトウェア開発そのものが「本業」となるので、事業部門と比較すると開発に充てられるリソースが豊富に取れるといいうことです。
これまでも、自社のビジネスに貢献するソフトウェア開発に主体的に関わってきた情報システム部門が、さらに実装スキルを身につけて開発スピードが加速すれば、ライバル企業に対して大きなアドバンテージになると思います。
しかし、今多くの情報システム部門は長年のアウトソーシングトレンドにより、自分たちだけでビジネスに貢献できるソフトウェアを作れるだけの技術力を持っているところが非常に少ないと言われています。
特に中堅・中小企業の情報システム部門はその傾向が強いようです。
また、包括的なビジネスソリューション開発のプロジェクトを経験している人材に乏しく、どちらかと言うと「パソコンが好きだから」「サーバ構築ができるから」という理由だけで、情報システム部門のスタッフにアサインされ、仕事としては日々のヘルプデスクやサーバ運用、社内PCのリプレースやIT機器の購買依頼の処理が主たる業務になっています。
もし開発プロジェクトに携わったとしても、社内意見の調整や予算管理のみで、具体的な設計ドキュメントを書いたり、プログラムを書いたりといった経験のある情報システム部門スタッフは極めて少ないのが現実のようです。
さらに、具体的なソフトウェアの開発を経験していたとしても、中堅・中小企業だとAccess/Excel・VBAといった15〜20年前にトレンドだったものがほとんど。例えば事業部門から、iPadやiPhoneで動くビジネスアプリケーションの開発を依頼されても対応できず、開発会社に丸投げというケースが多いようです。
このような状況なので、今の情報システム部門にソフトウェアの内製化を任せるには、相当の覚悟と周到な準備が必要になるでしょう。
少なくとも半年・１年で劇的に改善するほどの変化は求めるべきではないと思います。
もちろん、中堅・中小企業にある情報システム部門でも、常に技術トレンドを追いかけ、かつ自社の業務に大変明るく、継続的にビジネスの収益性向上に貢献するソフトウェアを生み出している情報システム部門もあると思います。
このような情報システム部門をお持ちの会社は、さらにライバル企業に差をつけ、ますます力強い成長をしていくことでしょう。
一方、付加価値の低い仕事ばかりやっている情報システム部門しか持っていない企業には大変厳しい現実が待ち受けていると思います。
3-2.事業部門が主体となる内製化のメリット
次に、事業部門が内製化の中心となることを考えてみましょう。
私達のお客様は、ほぼすべて事業部門や管理部門のスタッフ様が中心になって内製化を進められています。そしてその中には情報システム部門すら持っていない企業様もあります。
それでも、限られた時間と予算を最大限に活かして、どうすればビジネスが良くなるか、どうすれば売上が上がるか、どうすればお客様にご満足いただけるかという視点で、ソフトウェアを内製され、そしてそれを利活用し、実際に結果を出されています。
事業部門が主体となるソフトウェア開発と、情報システム部門が主体となるソフトウェア開発では、正直出来上がって来たソフトウェアの「迫力」が違います。
事業部門が主体となって開発したソフトウェアは、たとえ技術的に稚拙だったとしても、確実にビジネスが良くなるように作られています。
画面レイアウトが少々奇抜であろうが、内部構造が理想的でなかろうが、「これでビジネスを良くする！」という強力な動機付けがあるので、かなり具体的な結果が出ます。
一方、情報システム部門は技術的に正しい作り方や、洗練された開発手法にこだわるあまり、「ビジネスの収益性を向上する」というもっとも重要な視点がすっぽりと抜け落ちる傾向があります。言うなれば「誤ったシステムを正しく作る…」というなんとも残念な結果になるケースが少なくありません。
結果、事業会社がソフトウェア開発ベンダーにアウトソーシングするのと変わらないような結果になってしまい、かえって情報システム部門と事業部門の仲が悪くなってしまうという悲しい現実も見受けられます。
事業部門が内製化の主体となることのデメリットは、やはりソフトウェア開発そのものが「兼業」になってしまうということでしょう。
その現実を乗り越えるためには、先に述べた通り、内製化する業務の絞り込みや適切なツールの選択といった戦略的思考が重要になってきます。
私は一概に「情報システム部門が作るべき」もしくは「事業部門が作るべき」という絶対的な答えはないと思います。
しかし、どちらの部門が作るにしろ事業全体のQCDを改善する、ビジネスの収益性向上に貢献するという視点を常に持ち続けられるように、事業部門がより主体的に内製化に携わるほうが、望む結果が得られる可能性が高いのではないかと思います。
実際、私達のお客様でも事業部門の方の関与が強いほど、完成したソフトウェアの貢献度は高い傾向にあります。
まとめ
この記事では、ソフトウェア開発の内製化をより戦略的に考察し、そして実践していくために必要な幾つかの視点について説明してきました。
この戦略を立てる上での視点とは３つありました。
ひとつはどの業務をサポートするシステムを内製するかという視点
次にどのような手段で内製化するかという視点
最後に誰が主体的に内製化を進めるかという視点の３つでした。
そしてこれらの視点から考察する時の軸になるのは、常に事業の収益性に貢献する、事業全体のQCDを改善するために…という上位概念の目的を忘れてはならないということでした。
もちろん、現実にはこの記事に書いたこと以外にも、様々な考察ポイントがあります。
そしてその考察ポイントは、個々の企業の成熟度、マーケットでのポジション、企業文化など様々な変動要素でベターな回答が変わってきます。
マーケットの状況やお客さまからの要求といった外部環境は刻々と変化していきます。またそれに合わせて社内の組織体制や業務フローなどといった内部環境も同じく変換していきます。
このように複雑な問題に取り組むときには、まず問題を漠然と捉えるのではなく、幾つかの要素に分解して考えるということ。そして何よりも、具体的な行動を通したフィードバックから、さらに改善を重ねていくというPDCAサイクルを適切に、そして確実に回してくことが重要です。
このようにトライ・アンド・エラーを繰り返して学習するためには、スモールスタートで自分たちの身の丈にあったレベルで内製化を始めることが重要です。
この記事が、あなたの会社の内製化を具体的に検討する上での有益な情報となれば幸いです。
この記事を読まれた方は、こちらの記事もおすすめです。
