社内システムを作ったのは、
エンジニアではなく管理部でした。

何を作ったのか

大きく3つです。

人事労務。勤務調整と社員マスタの管理です。すでに使っていた人事労務クラウドと連携させ、社員情報が自動で入ってくるようにしました。二重入力をなくすことを最優先にしています。この判断の背景と、あわせて先に決めておいたことは「労務管理システムを内製するとき、先に決める3つのこと」に書きました。

備品管理。全社の備品とソフトウェアライセンスの管理です。それまでは表計算ソフトと別システムに情報が散っていました。どこに何があるかを調べるのに、毎回人に聞く状態です。これを1か所に集めました。移行の順番と、現物から開く運用については「備品管理を内製したら、最初に困ったのは機能ではなくデータでした」で詳しく書いています。

グループウェアにあたる部分。社員が自分で開く社員ポータル、年間スケジュール、安否確認、そして通知と承認です。承認は、社員が普段使っているビジネスチャットの上で完結するようにしました。新しいツールを増やさない、という方針です。この線引きは「グループウェアを置き換えるとき、新しい画面を増やさない」にまとめました。

構成上、意識したこと

• 管理画面と社員ポータルの2モード。総務が見るものと、一般社員が見るものは違います。最初から分けました。
• グループ複数法人に対応。法人ごとに情報を分けつつ、総務側では横断して見られるようにしています。
• ログインは既存のシングルサインオン（1つのIDで社内の各システムにログインできる仕組み）に寄せる設計。社員に新しいIDとパスワードを覚えてもらわないためです。
• 通知・承認は普段使いのビジネスチャット上で完結。専用画面を開かせないほうが、実際に使われます。

既存のデータをどう持ち込んだか

新しく作るときに一番やっかいなのは、実は機能ではなくデータです。 備品の情報は、それまで使っていた別の業務アプリの中にありました。これを書き出して新しい仕組みへ移しています。 人事の情報は、人事労務クラウドから自動で取り込む形にしました。手で入れ直すことはしていません。

管理部が作り手になると、何が変わるのか

1. 仕様の議論が、ほとんど要らなかった

使う本人たちが作っているので、「この項目は本当に必要か」を会議で詰める工程が丸ごと消えました。 必要かどうかは、毎日その業務をしている人がすでに知っています。

2. 業務の言葉のまま作れた

現場で使っている呼び方を、そのまま画面の項目名にできます。 外部に頼むと、まず自社の言葉を相手に伝わる言葉へ翻訳する作業が発生します。ここで意図がずれることは、実際によくあります。

3. 直したいところを、その週に直せる

運用して初めて分かる不便があります。「この画面、毎回2回クリックするのが面倒」といった種類のものです。 小さいけれど毎日効いてきます。作り手が社内にいると、すぐ反映できます。

難しかったこと

よかった話だけでは判断材料になりませんので、つまずいた点も書きます。

• 作った人に依存しやすくなる。担当者が抜けたときに引き継げるかは、別で手当てをしないと解決しません。
• 止まったときに誰が直すのかを先に決める必要がある。社内システムだからといって影響が小さいわけではなく、日常業務に食い込んでいる分むしろ大きくなります。
• 権限設計は後回しにできない。誰が何を見られて、何を消せるのか。社内システムほど「身内だから」で曖昧になりがちです。社外のパートナーが同じ画面を使う場合はさらに難しく、その線引きを実際に設計した例は最適PRMの事例にまとめています。
• バックアップは「取れているつもり」になりやすい。確認になるのは、実際に復元を試したときです。

この4つに共通しているのは、どれも「作る」の話ではなく「持ち続ける」の話だという点です。 作るところは、業務を知っている人がいれば進みます。つまずくのは、その後を誰がどう支えるかを決めていなかったときでした。

この事例から言えること

• 社内システムの作り手は、必ずしもエンジニア部門である必要はありません。業務を一番よく知っている部署が主体になれます。
• 管理部が作り手になると、仕様の翻訳と会議が減り、改善が速くなります。
• ただし「作れる」と「安全に運用し続けられる」は別の話です。
• 現実的なのは、作る部分は自分たちで、点検と守りの設計は外から専門家を入れるという分け方です。

自社でやるか、外に頼むか。この二択で考えると動けなくなりますが、実際には間があります。 どこを自分たちで持ち、どこを人に任せるか。その線を引くところから始めるのが、いちばん近道だと考えています。