「安直なシステム内製化に待った！」事前に知るべきアンチパターン3選

さまざまな現場で内製化システムやツールと対峙してきましたが、アンチパターンがちらほらと存在しました。今回はシステム内製化のアンチパターン3選と解決策についてお話をします。

[久松 剛，エンジニアリングマネージメント]

　業務効率化を巡る議論が活発化し、DX（デジタルトランスフォーメーション）の一角として日常の反復業務を自動化するためのツール開発も増えています。特に「Microsoft Excel」や「Google スプレッドシート」などで行われるルーティーンの手作業は、「VBA」（Visual Basic for Applications）や「GAS」（Google App Script）などにより作業ステップを減らせるため人気があります。

　企業を挙げて業種を問わずプログラムを書くことを奨励するケースも見られるようになりました。ユーザベースでは「プラスエンジニアリング手当」という制度があります。「MySQL」やExcelのマクロ、VBA・GAS・ローコードツールを用いた自動化であれば年収にプラス12万円、アプリケーション開発ができればプラス50万円やエンジニア職給与テーブルが適用され、プログラミングを奨励する動きが起きています。

　また、DXの文脈の中に存在する「内製化」のキーワードを根拠に、市販のSaaSなどではなく社内リソースを使って実装するケースもあります。

　私もさまざまな現場でこうした社内システム・ツールと対峙してきましたが、アンチパターンがちらほらと存在しているのが事実です。今回はシステム内製化のアンチパターン3選と解決策についてお話をします。

著者プロフィール：久松 剛（エンジニアリングマネージメント　社長）

　エンジニアリングマネージメントの社長兼「流しのEM」。博士（政策・メディア）。慶應義塾大学で大学教員を目指した後、ワーキングプアを経て、ネットマーケティングで情シス部長を担当し上場を経験。その後レバレジーズで開発部長やレバテックの技術顧問を担当後、LIGでフィリピン・ベトナム開発拠点EMやPjM、エンジニア採用・組織改善コンサルなどを行う。

　2022年にエンジニアリングマネージメントを設立し、スタートアップやベンチャー、老舗製造業でITエンジニア採用や研修、評価給与制度作成、ブランディングといった組織改善コンサルの他、セミナーなども開催する。

Twitter : @makaibito

運用後の悲劇を避ける、内製化アンチパターン3選

　安直な内製化はトラブルの温床になります。私の経験したトラブルでは、営業が制作したシステムが原因で、お客さまにFAXが無限に送られ続けるというトラブルがありました。ここからは、具体的なアンチパターンと解決策を紹介します。

内製対象システムのアンチパターン

　ごく希に内製した社内向けシステムを製品化し、事業化するケースはあります。しかし多くの場合、従業員の工数やその後のメンテナンスを踏まえると市販品を導入した方がよい傾向にあります。

　内製対象のシステムとして頻繁に上げられるのは「勤怠システム」です。社内制度にシステムを合わせていく方針があると内製に舵を切られる傾向があります。

　一見地味なシステムなので内製のハードルも低そうに見えますが、勤務時間修正や中抜け、勤怠承認、休暇申請、正社員・時短正社員・派遣・アルバイトなどの職種分解、月次締め処理などを考えていくとかなり複雑なシステムになります。また、フレックス制度でない限りは9〜10時にシステムの負荷が高まりやすい一方、サーバをプランアップするほどの予算もないため、「早めに出社して早めに打刻しましょう」というよく分からないルールも見たことがあります。

　勤怠システムを内製した際に遭いがちな問題として、「一斉退社打刻機能をつけてくれないか」などという、労基署にダイレクトにエスカレーションしたくなるリクエストが来ることもあります。

　社内システムには、法改正によるアップデートや上場準備の監査対応機能が必要なケースが少なくありません。なぜ内製をするのかということを考えていくと道理が通らないものが多く、労務や法務、財務経理などと連携しながら内製という選択肢が本当に正しいのかどうかを考えましょう。

ツール内製のアンチパターン

　社内システムほど重くはないためカジュアルにつくられがちなのが社内ツールです。カジュアルに作られやすいが故に、管理されない傾向にあり、トラブルの温床になる傾向があります。そして多くの場合、作成者がいなくなったときにトラブルが発生します。

　簡単なツールが多いため、安易に作り直しを選択するケースもありますが、仕様がないために想定以上に難航する傾向があります。また、プログラムをどこで実行しているのか分かりにくいことも多く、問題発現時に問題を特定するどころか発生地点を探すことから難航します。

　「Slack」の対話式プログラム「Slack bot」やGASなどでよく見られるのが、スケジューリングされたジョブが、作成者の退職に伴いアカウントが削除されたことでスケジューリングされたジョブも停止するというものです。特に、定期実行されないタイプのジョブは停止に気付かないことが多い傾向にあり、実に厄介です。

内製する組織のアンチパターン

　営業職メンバーが業務効率化の観点で作成したGASも問題の原因になりがちです。当該メンバーが退職後、GASでお客さまにFAXが無限に送られ続けるという、社外にも影響を及ぼすバグが発現しました。プログラムを確認したところ、複数のブログサイトなどからプログラムがコピペされた痕跡があり、エンジニアを数営業日貼り付けて修正することになりました。

　プログラムを書くことができる人材を社内で増やすのはよいものの、出来上がったものの監修はITエンジニアが担うようにしましょう。

エンジニアを入れて管理しよう

　全社を挙げて業務効率化をしようというのは、少子高齢化やITエンジニア不足の日本ではやむなしかと思います。リスキリングやリカレント教育の一環で既存従業員を教育するのも致し方ないでしょう。しかし、中長期的な視点で考えると上記のようなトラブルが発生します。

　私は過去の職場では選任のITエンジニアを監修役に据えた上で、下記の項目を実施しました。

• 既存ツールの棚卸し
• 社内ツールについてのコードレビュー
• GitHub（バージョン管理システム）の導入
• ドキュメンテーション管理
• bot運用を行う場合は個人のアカウントでの実施を禁止

　チーム開発経験のあるITエンジニアに任せることによって、前述したようなFAX問題の起きる可能性を大幅に低減できました。中長期的な成長を視野に、上記5点の施策を実施することを強くお勧めします。