今回の記事では、主に事業会社の情報システム部門で働く人たちをターゲットに、私が個人的に提唱する「ゆるい内製化」の特徴やメリットを紹介していきます。
「ゆるい内製化」ってなんだ？
SNSなどでは、事業会社の社内システムを内製で作るべきか、外注に任せるべきかがよく議論されています。
このような議論では白か黒かの極端な話に飛躍しがちですが、実際に上手く社内システムの運用を回しているのは、白でも黒でもなく、その中間です。
社内システムを内製することによるメリットとデメリットがあり、メリットとしては以下の特徴があります。
- 社内システムの新規開発、改修、保守に伴うコストの軽減
- システム開発や改修時の対応の迅速化
- 社内業務の変化に合わせたフレキシブルな開発や改修
- プログラミングやシステム設計に関するノウハウの保持及び育成
- 社内システムの内部仕様やデータ構造に対する理解
社内システムの内製をすることで得られるメリットは非常に大きく、現代の企業経営においてこれらのメリットを上手く活用することで、その企業の競争力の向上に繋がります。
ただし、社内システムを全面的に内製することは簡単なことではなく、内製対象を広げれば広げるほど、情報システム部門の負担や、システムを運用することによるリスクが大きくなっていきます。
今回の記事で提唱する「ゆるい内製化」とは、主要な社内システムは外注し、それ以外の社内システムや業務アプリケーションを局所的に内製していく社内ITの運用方針を指します。
具体的な「ゆるい」ポイント
当項では、前述した「ゆるい内製化」の具体的なゆるいポイントを紹介していきます。
主要な業務システムは基本的に外注
社内システムの内製化といえば、自社で利用する業務システムを自社の社員がバリバリと開発していくイメージですが、「ゆるい内製化」では、自社の多くの従業員が利用する業務システムは内製しません。
そういったシステムを構築し、高い品質で安定して稼働させるには、高度なシステム設計の知識と、高いプログラミングの技術が必要です。
また、画面数や機能の数などのシステム規模によっては、まとまった人数の開発者を社内で抱えることが必要になります。
システム開発会社顔負けの開発部隊を揃えていたり、効率的に分業しながら開発できる体制が構築してあるなら別ですが、そのような組織を作るには、潤沢な予算と経営陣の覚悟が必要になります。
よって、「ゆるい内製化」では、無理に自社で主要な業務システムの開発まで手を広げることはせず、プロである外部のシステム開発会社にお任せしていきます。
開発対象はバッチ処理がメイン
システムの「内製」と聞くと、データ入力画面やデータ表示画面のある業務システムの開発をイメージしますが、「ゆるい内製化」では、主だった開発対象はバッチ処理です。
一般的なシステム開発において、画面設計も含めた実装は難易度が大きく上がります。
仮にデータ入力画面を作るとなった場合、フォームを大きさはどうするのか？
テキストボックスにはどのような入力値の制限を設けるのか？
選択項目ではラジオボタンとチェックボックスとリストボックスのどちらが適切か？
などと、ユーザーの使いやすさや入力データの正常性の担保を画面設計に落とし込もうとすると、かなりの労力や経験が必要になります。
また、設計が済みコードを書いていく段階でも、これらの画面の制御に関する実装もそれなりのコード量が必要になります。
プログラミング経験のない人にとって、データの入力画面や表示画面を作ることの手間はイメージし辛いのですが、実際には上記のように簡単ではないと言えます。
かたや、バッチ処理の場合は、以下の特徴があります。
- 画面設計や実装が不要
- 用途ごとに機能を実装可能
- 任意のタイミングで自動起動が可能
まず、大きな特徴としては、画面を作る必要がありません。
そのため、前述したような画面の大きさや各コントロールの配置に頭を悩ます必要はなく、そのようなコードを書く必要もありません。
よって、比較的低いプログラミングスキルであっても少ない労力で作ることができます。
また、特定の機能をピンポイントで実装することができます。
ファイルをリネームするだけ、特定のテーブルのデータを更新するだけ、外部サービスのAPIのメソッドを実行するだけ、といったように目的に応じて必要な機能のみを実装します。
よって、バッチ処理は非常に合理的であると言えます。
また、Windows系OSであれば「タスクスケジューラ」、Linux系OSであれば「cron」を利用することで、指定したタイミングで、バッチ処理を自動的に起動させて実行することができます。
データベースのデータを大量に更新するバッチ処理であれば、ユーザーが使用していない深夜に実行されるようにしたり、特定のフォルダのファイルの有無をチェックして、ファイルがあれば移動やリネームをするバッチ処理であれば、実行タイミングを30分おきや10分おきのように短い間隔にすることで、同期処理的に機能させることも可能です。
これらのように「ゆるい内製化」では、アプリケーションの内製対象をバッチ処理に特化することで、最小限の労力やプログラミングスキルで、業務の効率化や自動化に寄与していきます。
コンパイル不要のスクリプト系言語を使用
「ゆるい内製化」では、アプリケーション開発を行う際にプログラミング言語として「スクリプト系言語」を使用します。
具体的には以下の言語を活用していきます。
- PowerShell
- VBScript
- Python
- シェルスクリプト
- DOSコマンド
厳密に言えば、スクリプト系言語とは異なる括りのものも含まれていますが、要するに、事前にソースをコンパイルして実行ファイルを作る必要がなく、OSの標準機能として組み込まれていたり、大半のディストリビューションに組み込まれており、言語仕様や構文が難解ではないプログラミング言語、またはそれに類する機能を総称して、今回の記事では「スクリプト系言語」と呼んでいます。
これらの言語等の特徴としては、これ単体では画面のあるアプリケーションは作れないところです。
前項のバッチ処理の項目で説明したように、「ゆるい内製化」では画面のあるアプリケーションの開発は可能な限り外注します。
よって、これらの言語に備わっている機能だけで十分要件を満たせます。
また、C#やJavaなどのコンパイルが必要な言語では、コンパイル後の実行ファイルをテキストエディタで開いても、なかのソースを読むことはできません。
よって、適切にプログラムのソースコードが共有されていない場合、プログラムの作成担当者の退職とともに、実行ファイルのソースコードも消失してしまい、そのプログラムの処理内容の解析や改修が一切できなくなるといった悲劇も生まれます。
かたやスクリプト系言語の場合は、事前にコンパイルしてexeファイルなどの実行ファイルを作る必要がなく、スクリプトを書き込んだファイルをテキストエディタで開くことで処理内容を確認したり、必要によって処理内容を容易に修正することができます。
バッチ処理を作って運用する場合でも、スクリプト系言語を使用して作成したほうが、より手軽、且つ柔軟に運用することが可能です。
また、これらの言語では言語仕様もわかりやすくて、プログラミング経験のない人であっても、比較的簡単に習得することができます。
よって、ソース管理の手軽さや習得難易度の低さといった観点から、「ゆるい内製化」では、「スクリプト系言語」を活用したプログラミングを推奨しています。
業務アプリケーション開発では限られた範囲にユーザーを限定
当記事では、内製対象として「バッチ処理」を推奨してきましたが、バッチ処理の内製だけでは、ユーザーの業務の自動化や効率化はできても、業務のデジタル化といった観点ではカバーしきれない部分もあります。
よって、内製対象として、何らかの入力画面があったり、データを表示するようなUIを持つ業務アプリケーションを作れるようにしておくことはとても大事です。
業務アプリケーションを内製する場合によく利用されるツールや環境としては、EUC(End-User Computing)でよく利用されるExcel VBAやAccessなどのMicrosoft Office製品があります。
自社のデータベースサーバーなどと連携することで、本格的な業務アプリケーションが作れます。
より高度なプログラミング能力があるなら、C#、Java、ASP.NETなどのプログラミング言語やプラットフォームを使用してアプリケーションを開発しても構いません。
当記事ではスクリプト系言語を推奨しますが、開発した業務アプリケーションを適切に管理、運用できるのであれば問題はないかと思います。
また、Microsoft社の「PowerApps」やサイボウズ社の「kintone」のようなローコード開発プラットフォームを利用するのも良いでしょう。
どんなツール、プラットフォームで開発をするにしても、「ゆるい内製化」では、内製した業務アプリケーションは可能な限りユーザーを限定して局所的な利用にとどめ、安易に全社に展開することは避けます。
全社的に利用する業務アプリケーションにおいて必要な要件としては以下です。
- 信頼性の高いシステムであること。
- 高い負荷にも耐えられるシステムであること。
- 様々な環境下での動作が保証されていること。
- 万人にとって使い勝手が良いこと。
全社で利用する業務アプリケーションであれば、トラブルや不具合などでそのシステムが停止してしまうと、社内の多くの人の業務も停止することになり、その影響は甚大です。
よって、その業務アプリケーションについては高い信頼性が求められます。
また、全社的に利用される業務アプリケーションであれば、そのアプリケーションを稼働させるアプリケーションサーバーや、データベースと連携させるためのデータベースサーバーを利用することになります。
社内全体で利用するアプリケーションであれば、サーバーには相応の負荷が掛かる可能性があり、負荷への対策を怠った業務アプリケーションを稼働させることで、他のシステムや業務への影響が発生する可能性があります。
また、会社によっては、社員が使用するパソコンのOSが統一されていなかったり、Windows端末だけではなく、iPadなどのタブレット端末を使用しているケースもあります。
また、社員が使用するパソコンのスペックもバラバラであったり、端末にインストールされているソフトウェアもユーザーや部署によって異なっている場合も多いです。
内製した業務アプリケーションを全社的に利用させるということは、このような様々な端末環境に対して動作保証を広げることが必要になると言えます。
また、業務アプリケーションを全社的に利用することになれば、パソコンの得意な人から苦手な人、ベテラン社員から新入社員、事務系部署の人から営業などの現場系部署の人など、様々な社員がそのアプリケーションを使用することになります。
このように様々な社員から広く満足を得られる使い勝手の業務アプリケーションを開発するのは簡単ではなく、また何かを変更するにしても、その変更に対するコンセンサスを得るのも一苦労です。
このように、内製した業務アプリケーションを全社的に利用させようとした場合は大変な部分も多く、安定的に運用しようとした場合、小規模な情報システム部門だけではリスクや、それに伴う労力が大き過ぎます。
「ゆるい内製化」では、利用規模が大きくなるアプリケーション開発はプロである外部のSIerに任せるべきだと考えます。
「ゆるい内製化」で開発した業務アプリケーションを社内に展開する場合、利用者を限られた部署や特定のユーザーグループに限定します。
また、部署ごとや細分化された業務ごとに小さな業務アプリケーションを作成し、それらを管理していきます。
よって一つの業務アプリケーションごとの利用ユーザー数は数名からせいぜい20名程度の規模を想定しています。
また、個々のアプリケーションの機能は必要最低限とし、画面数で言えば数個程度のシンプルなものしか作りません。
このように小規模な業務アプリケーションを局所的なユーザーグループに限定して使用させる方針をとることにより、以下のようなメリットがあります。
- システムの障害やトラブルの影響範囲が限定される。
- ユーザーの細かい要望をアプリケーションに反映させることができる。
- 情報システム部門の目の届く範囲内で業務アプリケーションを運用できる。
- 最小の開発工数で業務をシステム化できる。
このように「ゆるい内製化」では、情報システム部門などシステム管理者の目が行き届く範囲内のユーザーや利用部署に限定し、内製した業務アプリケーションを運用します。
先ずは自部署、次に情報システム部門と役割が近いバックオフィス系部署、次に営業などの現場系部署、というように、関係の近い部署やユーザーが利用する業務を優先して内製していきましょう。
外注に丸投げせず開発プロセスには積極的に関与する
これまで説明してきたように、「ゆるい内製化」では、社内の主要な業務システムなどの開発は外部のシステム開発会社に委託します。
社内でも利用するユーザーの多いシステムや、業務上重要度の高いシステムでは、高い信頼性が求められることもあり、これらを内製してしまうことで、情報システム部門の負担も大きくなります。
よって、安易な内製化は避け、「システム開発のプロ」にお任せするべきです。
ただし、外部のシステム開発会社はIT技術に関するプロであり、顧客である我々事業会社の事業や業務に関するプロではありません。
事業や業務のプロはもちろん顧客である我々です。
よって、システム開発を外注する場合であっても、すべての開発工程を丸投げするのではなく、可能な限り積極的に開発プロセスに関与し、自社の業務にフィットするシステムをシステム開発会社と一緒になって作っていく必要があります。
また、開発したシステムが生成する様々なデータは、そのシステム単体で利用されるだけではなく、データを集計して二次的に活用したり、他のシステムと連携させることで、さらにシステムの利便性が向上し、自社の業務効率化に繋がるなどの相乗効果が見込めます。
システム開発会社では、顧客の一部のシステム構成や業務内容を知っているだけであり、それではシステム間の連携やデータの二次利用といった提案は難しいです。
その会社がどのようシステムを利用して業務を行っているのか、その会社でどのようなデータが生成されるとデータの二次利用に活かせるのかを理解しているのは、顧客である我々です。
よって、システム開発を外部のシステム開発会社に委託する場合でも、要件定義から基本設定、詳細設計、テーブル設計、運用設計など、様々な開発工程や、各工程で作成される成果物の内容について積極的に関与をして、より自社にとって有益なシステムになるように努める必要があります。
「ゆるい内製化」において社内システムの開発を外注する場合、全てを外部の業者にお任せするのではなく、情報システム部門はそのプロジェクトにおける「プロジェクトマネージャー」となり、業者の作成する成果物を適切に管理しながら、一緒にシステムを作っていくような役割を担うことが大事です。
最後に
今回の記事では、私が個人的に推奨する「ゆるい内製化」についてまとめてみました。
企業のIT運用方針として、内製することは事業継続上のリスクにもつながるため、すべての企業にオススメできるものでもないのですが、自社の様々なITを内製することによるメリットも非常に大きいため、軽微な作業であれば、内製という選択肢をいつでも取れるようにしておくことは重要だと考えます。
今回の記事でも説明したように、バランスが大事であり、内製を担当する作業者のスキルレベルや情報システム部門の業務量なども踏まえて、無理のない範囲で必要最低限の箇所に限定して内製していくのが、「ゆるい内製化」を上手く回していくポイントです。
また、手を動かしてプログラミングなどを行い、バッチ処理や業務アプリケーションを自ら作成して自社内で稼働させたり、社内のユーザーに使用してもらうことは、ITエンジニアとしての仕事のやりがいにもつながります。
その意味でも、チャンスがあれば積極的に内製にもチャレンジしていってほしいと思っています。
今回も長々と呼んでいただきましてありがとうございました。
この記事が誰かの参考になれば幸いです。
それでは皆さまごきげんよう！
