企業の情報システム部門では、自社内の業務システムの開発や、社内インフラの構築や運用を完全に他社のシステム会社に委託している場合と、他社に任せずに、自社内で実施する場合があります。
また、全て他社、全て自社という極端なケースだけではなく、部分的に他社、部分的に自社といったケースもあり、その企業の情報システムの管理、運用方針によって、この外注範囲、内製範囲の割合は様々です。
情報システム部門の方針として、度々以下の論点について語られることがあります。
情シスはどんどん内製化すべき！
情シスは外注のコントロールに専念すべき！
今回の記事では、社内システムの内製化に関するメリットやデメリットを明確にして、内製化に向いている組織や、内製化に成功させる為のポイントを紹介していきます。
社内システムの内製化とは
当項では、改めて「社内システムの内製化」について、内容を定義していきます。
社内システムの内製化って何？
社内システムの内製化ってそもそも何でしょうか？
「内製化」とは、自社で使用している顧客管理システムや販売管理システムなどの各業務システムの開発や、自社で使用しているネットワークやサーバー等の構築や運用を社外のシステム開発会社に依頼せず、自社の情報システム部署が自ら開発したり構築することを言います。
業務システムなどのアプリケーション開発では、プログラミングの専門的な知識や技術が必要になり、ネットワークやサーバーの構築にはその知識や技術が必要になります。
社内システムの内製化のメリットとデメリット
当項では、社内システムの内製化をした場合のメリットとデメリットを紹介していきます。
内製化のメリット
社内システムを内製化する場合のメリットを紹介していきます。
例えばアナログな業務や非効率な業務が存在し、それらの作業を自動化したり、効率化することを目的にシステム化することが多いです。
その場合、自社の社員であれば自社の業務を理解しており、もし理解していない業務であっても、同じ社内の業務である以上、業務内容を確認しながらその業務に適合したシステムを設計することは難しくありません。
社外のシステム開発業者に自社の業務システムの開発を依頼する場合に一番面倒なのは、システム化対象の業務をシステム開発会社に理解してもらう部分です。
システムを内製化する場合は、この手間を大きく軽減できます。
企業内には様々な業務が存在し、古くからある業務をそのままやり続けている進歩のない企業もあるかも知れませんが、本来はより業務を効率的に行えるように既存システムを改修したり、新しい事業や業務に合わせて新しく業務システムを構築します。
そういったときに、都度社外のシステム開発会社に発注してシステムを作ってもらっていると、どうしても実際にそのシステムを利用できるようになるまで時間が掛かってしまいます。
それでは、スピード感が求められる昨今のビジネスにおいて、機会損失を生んだり、他社に遅れを取ることになります。
社内でシステムを内製できる体制があれば、業務の変化や新事業に合わせて、すぐに最適なシステムを構築することができます。
社外のシステム開発会社にシステムの改修や構築を依頼する場合は当然お金が必要になります。
社内の社員に作ってもらう場合、サーバーの調達などは別にして、作業費用に関しては無料です。
ただ、実際には、そのシステムを改修したり、構築をする担当社員の労力を使う以上、目に見えない部分でコストは発生しています。
その為、場合によっては社外に頼んで作ってもらった場合の方が安上がりな場合もあるのですが、それでも、やはり表面上の費用が発生しないのは魅力的です。
内製化のデメリット
社内システムを内製化する場合のデメリットを紹介していきます。
システム開発会社にシステムの改修や構築を依頼する場合、そのシステム開発会社固有の品質基準があり、その品質基準を満たしたシステムを納品してきます(※建前上は)。
もし、予め取り決めた品質基準を満たさないレベルのシステムを納品された場合は、その基準に満たせるようにシステムの修正を依頼したり、作り直しを依頼することができます。
また、システム開発会社には、システム開発経験の豊富なプログラマーやSEなどのプロの技術者が対応することから、システム開発を依頼するシステム開発会社の選定を間違えない限りは、ある程度の品質のシステムが出来上がります。
非ITの事業会社がシステムを社内で内製して構築する場合は、システム開発会社の様にシステム開発時の成果物に対する厳格な品質基準を設けていない場合も多く、また、情シスとして別の業務をこなしながらプログラミングやシステム設計などもせざるを得ない場合も多いため、システム開発に専念できず、その結果作成したシステムの品質は低い場合があります。
また、内製担当の開発者自身も、「社内で使うシステムだから」とシステムテストを省略したり、実装すべきエラー処理を入れなかったりと、作成するシステムの品質に対して甘えがでたりします。
自社のシステムを内製する場合は、プログラミング等の専門的な技術や経験が必要になります。
よって、情報システム部門の社員を新しく雇おうとする場合は、上記の専門的な技術を持った技術者を雇う必要があり、非技術者と比べても、給与条件などは高くせざるを得ないため、社員の採用コストが高くなります。
また、採用コストが高くなる一方で、専門的な技術の保持者を募集することになるため、なかなか応募者が集まらず、人の採用に苦労することになります。
その為、即戦力を期待して社内の給与基準よりも高い年収を提示して高スキルの人材に入社してもらうか、自社の求める技術レベルに満たないが、入社後に教育することを前提として自社の給与水準に合う人材を採用するかの判断に悩まされることも多いです。
社内の基幹的役割の業務システムの場合、本来はある一定の期間を使用したら、どこかでリプレイスをした方が良いと考えています。
それは、長年使用してしてきたシステムは使われている技術も古くなり、場合によっては新しいOSやブラウザ、サーバーなどでその動作環境がサポートされなくなるからです。
また、それまでのシステムの運用を元に、システムの機能が業務に合っていない部分や、システム設計上無理が生じている部分なども考慮し、これまでのユーザーの積もり積もった要望や不満なども加味して、新しくシステムを設計し直して大規模なリプレイスを実施するのは、社内システムの運用における良いライフサイクルです。
ただ、内製メインで社内システムを運用している場合は、小規模なシステム改修は得意ですが、大規模なシステムのリプレイスを行うには技術者が足らず、社内のリソースの面からも実施は困難な場合が多いです。
また、古いシステムに問題があっても、小規模な改修を容易に繰り返していけるため、古いシステムの延命もされやすい体制だとも言えます。
システム開発会社のプログラマーは、様々な理由により、プロジェクトごとに採用するプログラミング言語は異なっている場合があります。
それは、顧客側からの要望などの制約に合わせてプログラミング言語を選定したり、また作成するシステムの特性などを元に最適なプログラミング言語を選定した結果です。
また、サーバー環境などは一般的にはシステム構築時に世に出回っている最新の環境や、そのひとつ前の環境を使用して構築することが多いです。
また、自社以外のシステム会社が関わるプロジェクトを経験したり、他社で働いていた技術者が自社に転職してきた場合は、他社のノウハウや技術を自社に取り入れるチャンスです。
この様に、システム開発会社の技術者は新しい技術を取り入れやすい環境にあります。
内製化で社内システムを運用している場合は、通常は複数のプログラミング言語を使い分ける必要が無いため、大体同じ言語を使用して社内の各システムを構築します。
また、システム開発会社ほど人の出入りが多くはなく、他社とシステム開発で協業する機会もありません。
その結果、新しい技術が自社に流入する機会が少なく、古い技術を使い続けて取り残される、IT技術の「ガラパゴス化」が進んでいきます。
それでも内製化をすすめる理由
前述したとおり、社内システムの内製化を推進した場合、メリットはもちろん有りますが、デメリットもあることがわかります。
それでも私は内製化を推進するべきであり、今後企業が事業の競争力を付けていくためには内製化は必要不可欠だと思っています。
その理由についてまとめます。
情シスを中心に社内が回るようになり全体最適が加速する
一般的な情シスはITを用いた「全体最適」を推進する役割が期待されますが、実際には「部分最適」ばかりの対応になることが多いです。
それは、システム化の要望や前提が各部署ごとの業務を中心に考えられ、それらを元にシステム開発会社に担当部署が直接発注していたり、情シスを介する場合でも、システム開発会社とのやり取りを仲介するだけの役割しかできていない企業も多くあります。
その場合は、社内の各システムは個々に分断され、各部署ごとでは最適化がされても、企業全体を包括して最適化されたシステムにはなりません。
内製で自社内のシステムを開発、構築している場合は、社内業務のシステム化に関する相談はすべて情シスに集約されます。
その結果、情シスが社内の業務を把握することに繋がり、個々の部署内の業務だけといった狭い範囲の設計ではなく、他部署で行っている業務なども加味したうえで、高い視点でシステム設計を考えることができるようになります。
例えば、全体最適の視点に立って考えた場合に、各部署で使われている個々のシステムは、メインシステムのモジュールであり、それらを統合したメインシステムを情シスが管理するようなイメージです。
実際にそのようなメインシステムは存在しなくても良いのです。
一つの考え方や概念なので、そのようなイメージで各部署のシステムを設計していけるようになるという意味合いになります。
その様な体制にすることで、例えばシステムだけではなく、個々の部署で実施している業務でも、類似している業務が存在していれば、それを指摘してどこかの部署に集約させ、業務自体を見直したうえで、更にそれらをシステム化していくといった進め方を取ることができるようになります。
市場や情勢の変化に合わせてシステムを見直していくことができる
昨今のビジネスの世界では「スピード感」が求められています。
例えば、スピード感を持ってビジネスを回せているのが、最近では中国系企業です。
商談一つとっても、日本企業であれば、商談を実施してその場で結論を出さずにいったん自社に結論は持ち帰ります。
相手に対して発注したり受注するとなった場合は、大量に承認フローがある社内決裁を通して、様々な段取りをしてからようやく取り引きが可能になります。
その為、非常に時間が掛かります。
中国系の企業であれば、取り引き開始の決断が早く、商談結果を社内持ち帰って何か月も掛けて進めるといったやり方はしません。
そういったスピード感のあるビジネスの進め方が現在の中国企業の躍進や、日本企業の国際市場での衰退の要因となっています。
企業の情報システムにおいてもスピード感は非常に重要であり、新しい事業を始めようとした場合、その事業に合わせて何らかのシステムを用意しないといけないケースにおいて、そのシステムを社外のシステム開発会社に作ってもらうと、要件定義から見積もりの作成、その見積もりの社内承認、発注から納品までに非常に時間が掛かります。
その為、あまりに時間が掛かると、要望したシステムの開発が完了して新規事業を始める頃には、他社がその事業の市場でシェアを大きく獲得してしまい、既に手遅れといったことも起こりかねません。
システムを内製で構築している場合は、新規事業に合わせたシステムを社内のリソースで素早く開発することができます。
システム規模にもよりますが、システム開発会社に発注して作ってもらうよりも確実に内製した方が早く作業に着手できて、システムのリリースも早いでしょう。
今後日本企業が国内外の企業との争いで勝ち残っていくには、そのような「スピード感」のあるシステム構築がとても重要になっていきます。
様々なデータを事業の改善に役立てやすくなる
現在の企業において、自社のシステムで蓄積したデータの活用は非常に重要です。
世の中ではAIという広義の言葉が広く浸透し、そのAIを事業に活かした事例も多く聞くようになりました。
そのAIはどのように最適化な解を導き出すかと言えば、それは蓄積された過去の様々なデータの分析です。
社外のシステム開発会社に自社のシステムを作ってもらっている場合、そのシステムで使用するデータベースはそのシステム開発会社が設計したものです。
情シスはそのデータベースに対してアクセスし、データを取得して集計するところまではできると思いますが、データの細かい仕様は、そのシステムを開発したシステム開発会社が最も理解しており、情シスは各テーブルの細かい仕様などまでは把握していないケースも多々あります。
社内で内製したシステムから生成されるデータであれば、そのデータの仕様は、そのシステムを開発した社内の開発者が最も理解しており、それを使ってデータを解析することも容易です。
社内のシステムにはどのようなデータが存在するかを把握することで、データの解析を効率的に行えるようになり、更にそれを発展させて、機械学習による傾向分析や未来予測や、ディーブラーニングによって、人間によるアナログ作業でしかできなかった領域の自動化といった、高度なITの活用の足掛かりになり得ます。
内製化を成功させるポイント
当項では、社内システムの内製化を成功させるポイントを紹介していきます。
バージョン管理システムを利用しよう
社内システムを内製化させていくにあたって、後から問題になるポイントとしては、各システムの改修時のバージョンやプログラム内部の差分が適切に管理できていない状況になるケースです。
最新のソースコードと思われるソリューションファイルが、担当者のPC内や共有フォルダなど色々な場所に点在していたり、過去のバージョンアップ時に適用された仕様変更や不具合修正箇所が履歴として管理されていないといった状況です。
この場合にどのような問題が起こるのでしょうか？
- ソースが様々な場所に保存される可能性があり、ソースを紛失してしまう恐れがある。
- 本番環境で稼働中のソース、本番未適用の最新のソース、過去のソースが区別できない。
- プログラムの不具合発生時に影響時期や範囲を改修履歴から追えない。
- プログラムの変更履歴をソース内のコメントで残すことになり、ソースが見辛い。
これらの問題が発生した結果、最終的には以下の状況に陥ります。
- 社内システムの品質が下がり、システムが不安定になる。
- 社内システムの不具合が増加し、社内全体の業務効率が低下する。
- 内製担当者の開発効率が悪化し、十分な設計、テストが行えなくなる。
まさにこのスパイラルに陥った場合は、「内製化の失敗」と呼べるでしょう。
それを回避するには「ソース管理」の仕組みを導入します。
まずはソース管理システム(バージョン管理システム)の概要や主だった製品を紹介します。
バージョン管理システム（英: version control system、VCS）はコンピュータ上でファイルの変更履歴を管理するシステムである。
ソフトウェアソースコード・ドキュメント・画像・音楽など、様々な電子ファイルは段階を経て編集される。編集の過程で履歴を保存しておけば、何度も変更を加えたファイルであっても過去の状態や変更内容を確認したり変更前の状態を復元したりできる。バージョン管理システムの基本的な機能は、このファイルの変更内容・作成変更日時の履歴保管である。
また編集は複数人により同時並行でおこなわれる場合もある（例: 商業的なソフトウェア開発、オープンソースプロジェクト）。複数の人間が複数のファイルを各々編集すると、それぞれのファイルの最新の状態がどれであるか分からなくなったり、同一ファイルに対する変更が競合（コンフリクト）したりするなどの問題が生じやすい。バージョン管理システムはこのような問題を解決する仕組みを提供する。
Wikipediaでは上記のように紹介されています。
管理対象は必ずしもプログラムソースだけではなく、それ以外のファイルも管理することができます。
特にテキストエディタで開くことができるファイルであれば、そのファイル内部の差分まで取得して管理が可能なので、汎用的に利用可能です。
この様なバージョン管理システムでは、プログラムソース一式を「リポジトリ」と呼ばれる管理領域にアップロードします。
そこから、必要によってプログラムソースのファイルをダウンロード(チェックアウト)してローカル環境内でプログラムを編集し、編集が完了したら、リポジトリに編集後のプログラムファイルをアップロード(チェックイン)します。
そのダウンロードとアップロードはすべて履歴で管理され、過去の状態にいつでも戻すことが可能です。
また、リポジトリ内でプログラムソースの管理ルールに合わせて特定の状態を「タグ」付けして保存したり(開発したアプリケーションの本番リリースしたバージョンナンバー事など)、本流のバージョン管理履歴から枝分かれさせて管理させる場合は「ブランチ」をリポジトリ内に作成します。
詳しいリポジトリ管理手法の詳細は割愛しますが、一般的なシステム開発会社では、何らかのバージョン管理システムを利用して、プロジェクトごとに開発するプログラムソースを管理します。
システム開発の現場では、一人で一つのアプリケーションを開発することは稀で、一般的には複数名で分担して開発します。
その場合は、各自が修正したプログラムファイルを上手く一つにマージすることが必要なり、また、変更履歴も一元的に管理できていないと、効率的なシステム開発が行えません。
その為、システム開発会社では、このようなバージョン管理システムは必要不可欠です。
ただ、残念ながら、非IT系の事業会社では、システムの内製化に舵を切っても、ソース管理をこういったツールを利用して実施することまでは出来ていない企業も多く、それによりプログラムの品質に問題を発生させていたり、効率的な開発が出来てないケースも多く見受けられます。
バージョン管理システムにおいて、有名な製品では以下があります。
Subversionは利用するにあたって、サーバーに対してSubversionのインストールや設定が必要になりますが、その作業は難しくはない為、インターネットで導入方法を調べて誰でも導入することが可能です。
システム開発会社ではなくても、プログラミングを行い、業務アプリケーションを開発することに変わりはないため、システム開発会社と同じようにバージョン管理システムを導入しておくことを強く推奨します。
ソースコードはシステム開発における財産です！
一元的に管理できる仕組みを必ず導入しておこう
ドキュメントをしっかり管理しよう
社内システムを内製化するにあたって、後から問題視されるようになるケースとして、「内製したシステムのドキュメントが存在しない」ということが多々あります。
一般的に社外のシステム開発会社に業務システムを作ってもらう場合は、そのシステム開発会社の成果物として、アプリケーション本体と共に、設計書などの開発したアプケーションに関する様々なドキュメントも納品されます。
そのドキュメントを見ることで、アプリケーションの内部仕様が確認できたり、アプリケーションの実際の挙動が設計書通りの動きになっているかの確認をすることができます。
ただ、内製でシステムを開発する場合は、顧客の依頼を元に有償で行う作業ではない為、実際に動くアプリケーションの開発のみが優先され、そのアプリケーションに対するドキュメントの作成は省略されてしまうことが多々あります。
これが、内製化に失敗するポイントの一つです。
ドキュメントを一切残さずに内製したシステムが稼働していくと、リリースした直後は特にドキュメントが無くても支障はありませんが、そのシステムがリリースされて数年の時間が経過し、リリース時に開発した担当者がその後辞めてしまい社内に存在しないといった状況になると、その後任のシステム担当者は、内部の処理が一切わからないままシステムの運用をせざるを得ない状態になります。
プログラムのソースコード自体は残されていても、実装されている処理のなかには、何のために実装しているのかわからないような処理も出てきます。
その処理を削除してしまって問題ないのか、自身の知らないところで重要な意味があり、削除することで別の処理に影響が出てしまうのかは、ドキュメントが残っていない限り、居なくなった前任者しかわかりません。
そういった処理の不明点が解消されないまま、後任の担当者が更にそのアプリケーションに別の処理を追加していき、その実装でもドキュメントが残されずに、その後に次の後任者がまた同様の問題に直面するといった負のループに陥る場合があり、そうなると、今実装されている処理の何が必要でどれが不要なのかもわからなくなり、そのシステムをメンテナンスするには、既存のソースコードを目視で解析して処理を都度追うことになり、容易に改修ができないシステムになってしまいます。
そうなると、結果的に内製化は失敗だったと言わざるを得ません。
内製におけるドキュメントは、社外の顧客に納品するものではない為、表紙を作ったり、体裁をきれいに整えることは必要ないのですが、もし自分の以外の別の人が対象のシステムの担当になった場合でも、そのドキュメントを見ることで、アプリケーションの挙動や内部仕様、参照先や更新先テーブルなどが把握できるレベルのものを可能な限り用意するべきです。
ドキュメントが存在しないシステムは仕様が存在しないのと同じです
社内開発のルールとして作るべきドキュメントも定義しておこう！
ノーコード・ローコード開発も活用していこう
「内製化」と聞くと、専門的な知識を持つIT技術者が様々なプログラミング言語を駆使してシステムを開発するイメージですが、今非常に注目されているのは「ノーコード開発」又は「ローコード開発」と呼ばれる、プログラムを一切書かなくても良い、又は最小限に抑えてアプリケーション開発が行える開発プラットフォームです。
語弊はあるかも知れませんが、以前から注目されている「RPA」なんかもノーコード開発プラットフォームの一つという認識です。
生粋のプログラマーやSEにとっては、この様な開発プラットフォームには魅力を一切感じないでしょう。
プログラマーであれば、元々プログラミングができるので、更に面倒なノーコード開発環境の独特な使い方を習得しなくても、アプリケーションを開発することは可能です。
ノーコード開発環境を勧めた理由は、情シス内で活用する想定ではなく、情シス以外の部署でも簡単な業務アプリケーションを作れる組織を提案したいがためです。
社内システムの内製化とは、何も情シスだけがシステムを作るということではありません。
情シス以外の部署であっても、情シスに頼ることなく、自分たちの使いたいシステムを作れる環境を提供するのも「内製化の推進」です。
これまでは社内システムが必要になった場合は、必ず情シスにお伺いを立てて、情シスが主導してシステムを作成してもらうことが常識でしたが、このようなツールを導入することで、情シス以外の部署でも業務システムが作れるようになる。
これは、大げさに言えば「業務システムの民主化」とも呼べるでしょう。
ただ、現実的な問題として、このようなツールを提供してそれを活用できる企業や組織は多くはありません。
これまでの経験から言って、ノーコード開発プラットフォームが企業や組織にフィットする条件としては以下です。
- 企業や組織を構成する年齢層が若く、思考が柔軟なこと。
- 企業や組織内でITの重要性や、システム化の必要性が浸透していること。
- 企業や組織内に新しい仕組みを取り入れることに抵抗が無いこと。
- 情シス以外にもITに適性のある社員が居ること。
これらの条件が合致するような企業や組織であれば、必ず業務の自動化やシステム化に前向きな社員は居ます。
ただ、それにはプログラミングという壁があり、一からプログラミングを習得してまでシステム化をするような業務上の余裕が無かったり、はなからプログラミングは別世界の技術だと諦めている人も多いです。
社内にノーコード開発プラットフォームを提供し、上記の様なITの素養がありそうな社員を教育して使い方を指導し、実際の活用例を作ることで、習得した社員がされに別の社員を教育し、多くの社員が簡易的な社内システムを作成できる組織が構築できます。
実際にそうなった場合は、既存の社内システムとの連携がされなかったり、情シスが把握していない「シャドー業務システム」が生まれたり、業務が逆に非効率になるようなシステムが出来上がってしまったりと、「ITやシステムの専門家ではない人たちが作ったシステム」に起因した問題は色々出てくることは十分考えられますが、そういった問題はあとから発生の都度潰していけばよいのです。
「RPA」があれだけ流行したのも、RPAが特別に革新的なツールだからではなく、RPAを導入することで、これまで社内システムは情シスが作るものという常識が覆り、非IT部門が自分たちの業務を自分たちで自動化できるようになるという点と、業務を自動化するにあたって、これまでの業務を見直して無駄な作業を排除したり、手順を簡略化するといった「業務の棚卸」が行われることで、作業者や管理者の意識改革に繋がったのが大きいと考えています。
今回提案した「ノーコード開発」もそういった側面でも期待ができます。
ノーコード開発プラットフォームは便利な反面高価です
導入前にしっかり製品比較をして、慎重に選定していこう！
最後に
今回は、社内システムの内製化のメリット、デメリットの紹介や、内製化の推進を推奨する理由を紹介しました。
ただ、今回の記事の内容は、全ての企業に当てはまるものではなく、企業によってはまったく的外れな提案となってしまう場合もありますし、内製化が企業内の風土や、事業規模、社内の体制などの面からそぐわない場合や、デメリットの方が強い場合もあるかも知れません。
なので、あくまで一つの考え方として受け止めていただければ結構です。
ただ、IT系のニュースを眺めていると、名のある大手企業や勢いのある有名企業は従来から内製を主体に社内システムを構築していたり、今後は内製化を推進すると公にアピールしている記事も頻繁に目にするようになりました。
よって、今回の記事は客観的に見て、それほど世間の流れや、現在のビジネスの実情から考慮しても、大きくずれていることは無いはずだと自負しています。
今回の記事が少しでも皆さまのお役に立てれば幸いです。
今回も読んでいただきましてありがとうございました。
それでは皆さま、ごきげんよう。
