【情シスコラム】社内システムの内製化を成功させるポイントや注意点

昨今では、非IT系の事業会社でも、社内のシステムを外部のシステム開発会社に委託して開発するのではなく、自社でプログラマーを雇用し自社で開発する企業が増えてきています。

DXを本格的に進めようとする場合は、非IT系の事業会社であっても、一般的なシステム開発会社に負けないぐらいの技術力が求められます。

また、事業の変化に合わせてフレキシブルに社内システムを改善したり立ち上げることをできるようにするには、自社でシステム開発までやってしまうのが一番合理的です。

このような最近の風潮を踏まえて、今後は内製化を進めていきたいと考えている企業も多いのではないでしょうか。

そこで、今回の記事では、新しく社内システムの内製化を進めていこうとする場合に、内製化を成功させるポイントや注意点を紹介していきます。
 
 

システムの内製化を成功させるポイント

当項では、非IT系の事業会社が社内システムの内製化を進めるにあたって意識してほしいポイントや注意点を紹介していきます。
 

内製化に必要なのはプログラミングだけではない

蕎麦打ちを趣味にしているおじさんがいるとします。

急に脱サラして蕎麦屋を開店したいと相談されたら、9割の人は、まずは冷静になって考え直せとおじさんを諭すことでしょう。

お店を開店するなら、蕎麦を打てるだけではダメです。
美味しい蕎麦を打てても、それだけではお店を繁盛させることはできません。
お店を運営して持続させるのには、蕎麦を打つのとは別のノウハウや知識が必要になります。

システム開発の場合も同様です。
プログラミングのできる社員が居るから、社内システムを内製化しようと短絡的に考えると、必ず失敗します。

システム開発において、プログラミングはすべての工程における一部分でしかありません。

ウォーターフォール型の開発手法では、一般的に以下の工程に分けてシステムを開発します。

プログラミング能力が備わっているだけでは、十分な品質のシステムを開発することはできません。
むしろ、業務システムの開発において、プログラミング以外の工程がシステムの質に大きく影響する重要な要素であると言えます。

プログラミング以外の開発工程が十分に実施されないことによる影響例は以下です。

プログラミング以外の工程を疎かにしてしまった場合、使い勝手の良いシステムになる可能性は低く、信頼性の低いシステムが出来上がる可能性が高くなります。
そのようなシステムが出来上がってしまった場合、その内製は失敗だったと言っても過言ではないでしょう。

よって、社内のシステムを内製する場合であっても、プログラミング以外の開発工程を疎かにすることなく適切に実施することが非常に重要です。

また、一般的なウォーターフォールモデルにおけるシステム開発の工程以外にも、自社で社内システムの内製化を進めていく場合に知っておくべき知識は色々あります。

例えば、システム開発会社が顧客から依頼を受けてシステムを開発する場合に、多くのシステム開発会社で共通しているプロジェクトの管理手法や、個々の会社ごとのノウハウがあります。

具体的には以下のような内容です。

こういった手法やノウハウは、システム開発を事業として行うにあたって、多くのシステム開発会社で必要なものであったり、個々の会社ごとの経験則から合理的に、又は安全にシステムを開発したり導入する場合に必要なものです。

内製担当の人員が過去にシステム開発会社に勤務した経験があり、上記を十分理解しているなら問題はないのですが、このようなノウハウを把握している人員がいない場合は問題があります。

プログラムのソースコード管理やバージョン管理手法を知らなければ、プログラムの変更によってデグレードを発生させてしまったり、ソースコードがNASなどに点在し、最新のソースコードがわからなくなるような状況に陥る可能性があります。

受託開発をメインでやっているシステム開発会社では、その会社独自のフレームワークを用意して利用しているケースも多々あり、合理的な開発が可能です。
内製で社内のシステムを作っていくのであれば、自社独自のフレームワークを作り、それをシステム間で共有しながら活用するノウハウも習得しておくべきでしょう。

プロジェクト毎に作成する設計書などのドキュメントも具体的には様々な種類があります。
システム開発で使用されるドキュメントにどのような種類があって、どのような内容を記載するのかを理解しておく必要があります。

また、実施する作業や求められる技術内容をもとに、どのような人員をその作業にアサインするかも、各社のノウハウの一つです。

システムの本番環境に対して変更を加える場合に、必ず作業手順書を作成して事前に上位者のレビューを受けたり、実際の作業を二人一組で実施するなどのルールを設けているシステム開発会社も多くあります。

こういった手法やノウハウは、自社のシステムを内製する場合でも、そのまま活かすことができる知識です。
 

システム開発会社のノウハウの学び方

個人的に一番おススメしたいノウハウの学び方としては、システム開発会社の技術者を自社に常駐してもらい、一定期間、社内システムの内製化を支援してもらいつつ、システム開発における工程管理方法や各種ツール類の使い方などを教わるという案です。

技術者が自社に常駐することで相応の費用が発生しますが、その技術者のメイン作業は自社の社内システムを開発してもらうことであり、その合間にシステム開発におけるノウハウの教えを乞うのであれば、費用は無駄にはなりません。

また、技術者を提供するシステム開発会社では、自社の技術者が顧客の企業の内部で常駐することになるため、顧客側の業務やシステムの知識が付きます。

更に、顧客の企業内で上手く立ち回ることで、その会社のなかの従業員と仲良くなるなど、良好な人間関係を構築できる可能性もあります。

この場合、常駐契約が終了したあとも、内製ではやりきれない開発案件を受注したり、気軽にシステムに関する相談をもらえるような関係を作ることにも繋がり、システム開発会社側でもメリットはあります。

社内システムを内製主体で開発していく場合も、やはりその道のプロであるシステム開発会社からの支援がもらえるかは、その内製化の成功の可否に大きく関係します。

よって、内製化を進める場合であっても、外部のシステム開発会社とは良好な関係を築いていくことはとても重要です。

因みに、当ブログでは過去に「システム開発費用が高い理由などのシステム開発会社の裏側く」を記事にまとめています。
もし興味があればこちらもご一読ください。

 
 

すべての開発工程を自社で行うことだけが内製化ではない

社内システムを内製化する場合、必要になる技術として真っ先に思い浮かぶのは「プログラミング」だと思います。

ただし、前項でも解説しましたが、システム開発の工程においてプログラミングが占める割合は一部分だけであり、要件定義や設計、テストなどの工程も併せて重要です。

また、プログラミングは本来高度な技術であり、普段からプログラムを書くことに慣れている人と慣れていない人では、作業の速さに雲泥の差があります。
システム開発会社のプログラマーであれば、毎日仕事としてプログラムを書いているため、当然作業は速いです。

であれば、プログラミング作業だけをシステム開発会社に委託し、要件定義や設計、テストといった工程を内製として自社が主体となって行う手法もあります。

IT業界では、受注したシステム開発案件で必要になる作業を細かく切り出し、プログラミングなど下流工程の作業を下請けのシステム開発会社に委託するような分担がよく行われます。

それと同様に、自社のシステムを開発するにあたり、上流工程である「要件定義」や「基本設計」などの工程を自社内で実施し、プログラミングやテストといった下流工程のみをシステム開発に委託するといったことも可能です。

この方法であれば、自社の社員がプログラミングスキルを有していなくても作りたいシステムを作ることが可能です。
また、要件定義から導入までのすべての工程をシステム開発会社に委託する方法と比べた場合、その開発費用は大きく軽減できます。

社外のシステム開発会社が主体となってシステムをまるっと作ってもらうのではなく、システムを使う自社が主体となり、社外のシステム開発会社に必要な作業だけ指示をしてやってもらうイメージです。

社外のシステム開発会社に依頼する作業は、プログラミングやテストだけではなく、詳細設計なども依頼して良いですし、他の工程も依頼しても良いかと思います。

大事なのは以下の点です。

自社のシステムを自社の社員でプログラミングして作ることだけが「内製化」ではなく、自社の社員が主体となってシステム開発プロジェクトをコントロールすることも「内製化」です。

 
 

システム開発費用を軽減する目的で内製化をするのは間違い

企業の経営者や経営陣が社内システムを内製化したいと考える理由として良くあるのは以下です。

• 高い作業費用をシステム開発会社に払いたくない。
• お金を掛けずに社内システムを運用したい。

社内システムを自社の社員で開発するのであれば、確かに社外のシステム開発会社にお金を支払うことはなくなりますが、それを目的に内製化を目指しても上手くはいかないかもしれません。

社内システムを内製していくにあたり、これまで社外のシステム開発会社に支払っていた費用を払わなくてもよくなる代わりに、以下のようなコストが掛かるようになります。

• 情シスの業務量が増えることよる人件費増加
• 情シスの業務が高度化することによる教育コスト増加
• 業務に必要なITスキルの高度化による採用コスト増加
• 開発スキルが満たない場合は社内全体の業務効率低下

社内システムの内製化をすることで、情シスや担当部署の業務量は大きく増加することになり、その増加した業務量は会社を経営するための人件費として跳ね返ってきます。

自社でシステムを作るようにするなら、他部署から非IT職種の人材を移動させて情シスの業務を習得させることも困難になります。

新卒採用や中途採用で情シスの人材を雇う場合も、必要になるITスキルは高くなり、高い賃金を提示しないと採用ができなくなります。

また、内製担当者に十分な開発スキルがないと、社内システムは十分な品質を確保できなくなり、システム障害の要因になります。
不安定な社内システムでは、会社全体の業務効率は低下してしまいます。

社内システムの内製化は、上手く回せば結果的にこれまで発生していたシステム開発費用を抑えることにも繋がりますが、それはあくまで内製化の幾つかあるメリットのなかの副次的な効果程度として考えておくべきです。

社内システムを内製化する本来のメリットは、当記事の冒頭でも記載したように、「積極的なDXの推進」や「事業の変化に併せてシステムの見直しが可能」といった側面です。

社内システムの運用に「攻め」と「守り」があるなら、コスト軽減目的の施策は「守り」の施策です。
しかし、本来社内システムの内製化は「攻め」で有るべきです。

社内システムの内製化における「メリット」と「デメリット」を適切に理解しないまま内製化を進めてしまう場合、内製化の目的やゴールを見誤ります。

よって、内製化の「メリット」と「デメリット」を十分理解したうえで進めることが必要です。

当ブログでは過去に「社内システムの内製化におけるメリット、デメリットく」を記事にまとめています。
良ければこちらもご一読ください。

 
 

システム改修に関する「費用」のブレーキが掛からない

自社内でシステムを開発する場合、ユーザーの要望の細かくシステムに落とし込むことができるようになります。
また、業務の変化に合わせてフレキシブルにシステムを改修したり構築することができるようになり、それらの特徴はシステムの内製化における大きなメリットです。

ただし、要件定義や業務の見直しを適切に実施できていなければ、結果的にユーザーの業務効率が低下したり、複雑で非効率なシステムが出来上がってしまうおそれがあります。

社内システムに対するユーザーの要望は、あくまでそのシステムの使用者としての要望であり、ITの専門的な知識や経験を踏まえた内容ではありません。

そのため、ユーザーの要望に対して、内容の精査をしないまま社内システムに実装した場合、以下のような懸念があります。

• システム全体の最適化が考慮されていない機能が実装される。
• 本来業務自体を見直すべき内容までシステムへ無理に反映させてしまう。
• システム間のデータの整合性が考慮されず不整合なデータが出来上がる。
• 長期的な視点が欠け短絡的な要望で合理的ではない機能が実装されてしまう。

外部のシステム開発会社に開発を委託するのであれば、経験の豊富なSEが顧客の要望を確認したうで、各要望が対応すべき合理的な内容か否かを精査します。

要望内容をもとに、既存のシステムの仕様なども考慮して、より低い難易度で実装できるように要望内容の変更を顧客の担当者と調整したり、システム全体の機能や生成されるデータなども考慮したうえで、SEの視点で実装するべきではないと考えられる要望内容の場合は、より適切な要望案を提示して変更を促します。

また、そもそもシステムの機能で対応するものではなく、ユーザーの業務自体を見直すべき要望内容であれば、そのように提案して必要性の低いシステム改修を回避するような調整も行います。

システム開発会社側では、システムに対する要望の一つ一つに対して作業工数を算出し、それを元に作業費用を提示することになるため、必然的に要望を厳格に精査することになります。
また、要望を出す顧客側でも、その要望ごとに作業費用が掛かり、あれもこれもと要望を切りなく提示してしまうと、その作業費用の見積もりも当然高額になってしまうため、本当に必要な要望だけを依頼するようにブレーキが掛かります。

社内システムを内製化している場合、この「費用」によるブレーキが掛かりません。
それにより、ユーザーは必要性の低いシステム改修をいくつも依頼してきたり、非常に大きい工数が掛かるわりに効果の少ない要望を平然と出してくるようになります。

システムに対するユーザーの要望を適切に管理できないと、不必要な労力が発生するだけではなく、システムの内部的な仕様が複雑になったり、頻繁に改修を繰り返して不具合が混入したりして、システムの品質にも大きく影響を与えます。
 
 

年功序列の給与テーブルや評価制度はIT人材と相性が悪い

もう何年も前から、IT人材が足りていないと言われており、その傾向は年々増しています。
あらゆる物事の価値は需給バランスで成り立つため、人手不足のIT業界では、技術者の賃金も上昇し続けています。

そんな社会情勢のなかで内製化を進めようとする場合に必ず問題になるのが「賃金と待遇」です。

システム開発会社などのIT企業であれば、本人の能力や経験に応じて、柔軟に賃金の額面を調整できます。
IT企業の場合、その社員の技術力がその人の価値であり、それで報酬額が決まるのは当然です。

但し、今回の記事で想定している非IT系の事業会社の場合はそういうわけにはいきません。

最近では事業会社でも年功序列を廃止し、本人の能力や仕事の成果に応じてフレキシブルに給与の金額を調整する企業も増えてはきていますが、まだ依然として年功序列の賃金制度で運用している企業は多く存在しています。

そのような企業では、一部の社員に高い能力があったり、自社に大きく貢献できていたとしても、同じ年次の社員達と横並びの給料です。
せいぜいボーナスでいくらか調整が入る程度です。

これは一般職や総合職という大きな分類分けをしたうえで、全社共通の「給与テーブル」をもとに、年次により基本給が決まっているからです。

また、定期昇給もありますが、その金額は僅かであり、その人の年収を大きく上げるには、役職を付けて役職手当のように基本給以外で賃金を加算する必要があります。

社内システムの内製化を進めるために、今後はIT技術者を積極的に採用していこうと考えている企業にとって、このような「横並びの賃金」、「年次による評価制度」は必ず問題になります。

当項の冒頭でもお伝えした通り、世の中はIT人材不足であり、IT業界では仕事も豊富にあります。
圧倒的に求職者有利の状況です。

転職サイトを覗けば、魅力的な条件の求人が並んでいます。
特にIT企業の場合は、求職者のスキルに見合った高待遇を提示できるため、同程度の規模の企業で比較した場合、非IT系の事業会社はどうしても見劣りしてしまいます。

また、上手く優秀な技術者を採用できた場合や、自社で育成して一人前の技術者に育った場合も、やはり非IT職の社員と横並びの給与テーブルでは、何れそれが不満に繋がります。

また、当項でお伝えした通り、一般的な非IT系の事業会社では、組織のなかで給料を大きく上げるには、本人の能力や技術を高めるのではなく、出世をして役職を付けることが必要です。
ただし、本来はITの能力と組織のマネージメント能力は異なる特性の能力であり、組織のマネージメントは苦手だけど、ITの高い能力を持つ社員がいた場合、その能力を評価して賃金に反映させる制度がありません。

また、役職を付与できる人数はその組織の規模によって決まっており、その組織の役職に空きができないと役職を与えることはできません。

このような場合は、自身の能力を認めてくれて、より条件の良い企業へ転職してしまう可能性は高いです。

では、情報システム部門やIT職種の社員だけ特別扱いをしろと言っても、そんなことをしてしまうと、今度は他の部署や他の職種の社員が不満を持つようになります。

良くも悪くも日本の企業では、担当している仕事の難易度や重要性に関わらず、報酬は平等です。

企業の人事部門では、IT人材の稀少性や重要性を理解していても、それによってIT人材のみを優遇するような給与テーブルを設けることはできないでいます。

そこで当記事でオススメしたいのは、マネージメント能力による評価とは別で、業務の専門性やスペシャリストとしての評価をするための「専門職」用給与テーブルを新設する案です。
 

「専門職」としての給与テーブルの新設

当案では、情シスなどのIT人材に適用することを前提としたものではなく、経理や人事など、非IT職種の人たちにも同様に当てはめることができる評価テーブルです。

従来の給与テーブルは、部下や組織の管理といったマネージメント業務を評価対象とした給与テーブルですが、当案では、部下や組織の管理ではなく、その個人の能力や技術の高さを評価の対象とし、その能力や技術をどのように社内で活かしたのか。
また、新しくどのような能力や技術を獲得したのかや、自社のノウハウとして文章化や共有化などが適切に行えたのかなどを評価するようにします。

それにより、役職を付けて部下や組織の管理をしないと給与が上がらない状況を改善し、専門性の高い職種におけるスペシャリストの育成を促します。

出世以外のロードマップを提示することで、管理職を目指すのではなく、今の技術や能力を高めていきたいと考えている技術志向の社員を適切に評価できるようになります。

ここまでやらないといけないのかと思われる経営幹部もいるかもしれませんが、社内システムを内製化したいと考えた場合、これぐらいの覚悟をもって取り組むべきだと考えます。
 
 

内製による属人化は事業継続の危機に繋がる

企業内の業務において、「俗人化」を如何に回避するかは非常に重要です。

「業務の俗人化」とは、「この作業は〇〇さんしかできない。」とか、「この情報は〇〇さんしか持っていない。」といったように、特定の従業員に社内業務の一部を依存し、その人がいないと業務が回らない状態を指します。
俗人化は、大きな企業より、個人の業務範囲が広い中小企業で顕著です。

難しい仕事や高度な技術を必要とされる仕事であれば、俗人化は必然にも感じますが、実際には、誰でもできる簡単な仕事内容にも関わらず、業務マニュアルや作業手順書が整備されていないがために俗人化していたり、業務の電子化が遅れて手作業のアナログ作業を廃止できないがために俗人化しているケースも多くあります。

本来企業の情報システム部門の仕事では、自社内の俗人的で非効率な業務を電子化して効率化することも重要な役割の一つではありますが、得てしてその情シス内の業務自体が俗人化していくケースも多いです。

特に社内システムを内製化していくとなった場合、この「俗人化」が進んでしまうことで、場合によってはその企業の事業継続すら危うい状況に陥る可能性もあるため、注意が必要です。

外部のシステム開発会社に自社で使用する業務システムの開発や運用を委託しているのであれば、そのシステムでトラブルや問題が発生した場合に、その開発した会社に問い合わせをして、必要な対応をお願いすることができます。

もしも内製したシステムで問題が発生した場合、当然外部のシステム開発会社で何か対応をしてもらえることはありません。
自社内で何とか復旧したり問題を解消させることが必要です。

そのシステムを開発した社員がその場に居れば対応もできますが、その社員が退職して既に居ないケースも十分起こり得ます。
システムに問題が発生した場合のトラブルシューティングは、システムを開発するよりも更に高度な技術と経験が要求されます。

その様な優秀な人員が自社に居ればよいですが、そうではない場合、そのシステムの問題が解消しないままになることも考えられます。
その問題が解消しない限り、システムを利用できないとなった場合は、そのシステムを利用した業務が回らなくなり、事業の継続する危ぶまれる危険性もあります。
 

社内システムの内製化における属人化排除のポイント

内製化における属人化は非常にリスクが大きいとお伝えしましたが、属人化を回避するヒントはシステム開発会社のノウハウから学ぶことができます。

IT技術者は個人の能力差が大きい職種です。
その能力差を適切に埋めてあげないと、複数のプロジェクトを効率よく進めることはできません。
また、前任者が別のプロジェクトへ移動になることで、これまで一切関わりのない顧客のシステムの面倒を見ないといけなくなるケースもあります。

システム開発会社では、上記のようなケースにおいて、如何にして属人化を回避しているのでしょうか。

ポイントは以下です。

 

当記事のなかでも説明しましたが、システム開発会社では、その会社独自のフレームワークを作り、それを活用してプログラミング作業を効率よく進めているところも多いです。

フレームワークには、特定の顧客やシステムに依存しない汎用的な処理を組み込んでおきます。
そのフレームワークを各プロジェクト間で共有して利用することで、全てのプログラムを1から作らずに済み、効率よく開発作業が進められます。

これはプログラミング作業を効率化する目的もありますか、プログラミング能力の差を埋める目的でも非常に有効です。

例えば、データベースへ接続する処理は本来色々なやり方があり、プログラミング経験が浅い場合は、適切な接続方法を選択するのが難しいです。
また、接続方法や仕組みを理解して実装するのも知識や経験が必要になります。

フレームワークのなかに、データベースへ接続するための共通処理を用意しておくことで、開発者は難しい仕組みを理解する必要はなくなり、そのフレームワークの使い方だけ覚えれば開発ができるようになります。

フレームワークは一例ですが、技術の属人化を回避するには、上記の例のように、スキルの低い人でも高スキルな人と同じように作業ができる仕組みを作ることが非常に重要です。
 

システム開発会社では、顧客のシステムを開発する際に、様々なドキュメントを作成します。

これはプログラミングをして作成したアプリケーションと同様に、開発時の納品物として予め決められていることが大半です。
これからも作るアプリケーションの仕様に対する合意形成を得る用途や、作成したアプリケーションを納品した以降に、アプリケーションの仕様を顧客側で確認してもらうために用意します。

このように、ドキュメントは顧客にとって非常に重要な資料ですが、実はシステム開発会社側でも重要です。

そのシステムの開発に関わった技術者であれば、そのアプリケーションがどのような用途で使用され、どのような経緯で今の仕様になっているかを当然理解していますが、そもそもシステム開発会社では、新しくシステムを開発する部隊と、開発後のシステムの運用や保守をする部隊が異なるケースも多く、顧客のシステムに関する情報が技術者の頭の中だけにしかない状況は許されません。

そこで役に立つのが、顧客のシステムを開発する際に作成し顧客に納品した、要件定義書やシステム構成図、テーブル定義書、基本設計書や詳細設計書といった各種ドキュメントです。

それらのドキュメントを読み返すことで、そのシステムの開発に携わっていない人であっても、必要な情報を得ることができるようになります。

情報の属人化を回避するには、情報をドキュメントとして残していくことが重要です。

このように、システム開発会社では、「技術の属人化」「情報の属人化」に陥らないように、様々な工夫をしながらプロジェクトを回しています。

このようなノウハウは事業会社の内製化にとっても参考になるものが多いです。
もしそういった見地を得る機会があれば、積極的に吸収することをオススメします。
 
 

最後に

今回の記事では、非IT系事業会社が社内システムを内製化する場合に知っておいてほしいことや、成功させるためのヒント、注意点をまとめました。

システムの内製化は、本来プロであるシステム開発会社がお金をもらって行う作業を自社の社員だけで進めようとする取り組みです。

当然簡単な話ではないのですが、だからこそチャレンジをして上手く行ったときの事業にもたらす効果は大きいです。

自社のDXを進めたければ、社内に内製部隊を新設して臨むぐらいの心持ちを経営者には持ってほしいと思います。

今回の記事が、どなたかの参考になれば幸いです。

今回も長々とした記事を最後まで読んでいただきましてありがとうございました。
それでは皆さまごきげんよう！