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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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