松田軽太の「一人情シスのすゝめ」#10：業務システムの内製化とその責任
松田軽太の「ひとり情シスのすゝめ」、タイトルだけ見るとひとり情シスを推奨しているように思われるかも知れませんが、思いはまったくの”逆”。様々な事情によりやむなく”ひとり情シス/ゼロ情シス”という状況になってしまっても頑張っていらっしゃる皆様のお役に立つような記事をお届けしたいと思っております。
さて今回は、『業務システムの内製化』についてのお話です。
「1日の感染者が1000人を超えた」「東京の感染者数が連日200人を超えた」など、新型コロナウィルスに関して連日マスコミやメディアが掻き立てており、目先の「経済対策をどうするか」ということに主眼がおかれ、『DX-2025年の崖』問題などすっかり下火になってしまっていますが、確実にやってきます。
■業務システムを内製化するということ
DX-2025年の崖で、多く取り上げられているのは数十年も塩漬けしていたレガシーシステムの再構築という課題でしょう。
ドイツ製ERPの保守期限切れ問題など、企業の基幹となるシステムが動かなくなるという大きなリスクがありますから。しかし、それともう一つ、DX-2025年の崖で提唱されていたのが、ローコード開発ツールを活用した業務システムの内製化です。
むしろ中小企業の情シスにとっては、こちらの方がすぐに取り組むことができる内容ですね。
しかし！！
安易な気持ちで業務システムを内製化すると、後で大変なことになります。
何が大変なのか、それは「業務システムを作ったからには、そのシステムを使っている間は、ずっとそのシステムのお守りをしなくてはならない」ということです。
■業務を取り巻く環境は変わっていく
たとえば今だと新型コロナウイルスの影響で、人が集まらないように注意を払うようになりました。
ではそれが業務システムにどんな影響を与えるでしょうか？
アナタが総務から依頼されてお弁当発注管理システムを作ったとします。以前の記事にも書いた”お弁当発注管理”を例にして考えてみましょう。
新型コロナウイルス感染症対策として、ソーシャルディスタンスを意識する必要があるとして、原則として、食堂は利用停止し、弁当を各自のフロアで食べることを基本とする会社方針が出されたとしましょう。非常事態宣言前、各自、会社の食堂または販売所にて販売する弁当を食堂で食べることもできました。しかしながら、弁当購入時の密集のリスクヘッジをするため、各フロアの会議室で販売することになりました。そのため、お弁当業者にもフロア単位にお弁当を分けて置いてもらう必要があります。
さて、こうなるとより精度の高い購入見込みが求められるようになり、お弁当発注管理システムを作ったアナタに、総務からシステム機能の改造依頼が舞い込むことになるでしょう。
その際には、おそらくこんな会話が行われるのではないでしょうか。
総務「国からの要請で３蜜を避けることになって。経営陣からも、食堂事態だけでなく、食堂への移動も密集になるから、原則として各フロアごとにお弁当を食べるようにと指示されたんだよね」
アナタ「そうか、確かに食堂って三蜜な場所ですよね」
総務「こんな事情もあり、急いでお弁当発注管理システムを、各フロアごとへの配送に対応できるようにして欲しいんです！」
アナタ「えっ、いや、そんなことを急に言われても…。」
総務「もちろん急なお願いで悪いとは思っているのだけど…。でも経営陣からの指示だから、すぐにやってくれないだろうか！」
と、押し切られることになるのです。
■改造による影響範囲を考える
経営陣からの指示ということは会社命令なので、さすがに断るワケにはいきません。「そんなことをするよりも外部委託にしてしまい、個人決済で各フロア配送してもらった方が自由に好きなものを食べられるのに。」などとは心で思っていても、今の時点では決して口には出せません。ｗ
そのような理由でアナタは一年前に作ってすっかり忘れてしまっているお弁当発注管理システムをひっぱり出してくることになります。
- どんな機能への改造が必要なのか？
- その改造にはどんなデータ項目が必要なのか？
- その項目はマスタ化できるのか？
などなど、考えなければならないことが沢山、思い浮かぶハズです。とはいえ、ここでパニックを起こすと、仕様漏れになってしまうことも。
まずは変更すべき内容を書き出すことにしてみました。
- 食堂以外ではどこで食べているのか？
- どこでお弁当をピックアップするのか？
- どうやってお弁当業者にお弁当の仕分け配送をしてもらうのか？
この辺りを明確化する必要があります。
今回は食堂が使用禁止となり、原則として自席またはその周囲の会議室で食事をとるという会社方針があるため、①のどこで食べるかについては、自席もしくは周囲の会議室となります。その他の可能性としては近所の公園なども考えられます。
次に②のどこでピックアップするかですが、これは移動による密集を避ける意味もありますので、自席のあるフロアのお弁当配布用会議室となるでしょう。ということは「ピックアップ場所」という項目は増やしてもよいかもしれません。
またピックアップが集中して混雑させないためには、お弁当のピックアップに時差をつけるとよいかもしれません。時間の目安となる「順番（ないしはタイミング）」という項目も追加してよいでしょう。
さて、最後に③のお弁当業者に配布場所ごとに数を分けてもらう方法ですが、これまでの発注ではお弁当のメニューごとの総数だけしか書いてありませんでした。総数だけではフロアごとには分けられないので、納入フロア情報を発注書に記載する必要があります。
最終的には印刷フォームも改造しなければなりません。つまり、帳票の再設計が必要ということになります。
■業務システムを実際に改造してみる
アタマで整理した改修要件に則って、実際に業務システムを修正してみましょう。
- 社員マスタに食事場所という項目を追加する。
- 明細データに食事場所という項目を追加して、自動で値を取得するようにする。
- 発注書の印刷フォームに食事場所を出力する。
業務システムの内製化は思っているよりも大変
今回はお弁当の発注管理という簡単な改修でした。最悪、業務運用の開始に改修が間に合わなくても、数日くらいなら、手作業でも対応することは可能でしょう。（玉子屋システムのようにアナログでカバーすることも）
しかし、これが購買システムや在庫管理システムだったらどうでしょう？ 今回のような感染症等の影響で、普段、購入している材料が手に入らなくなり、初めての取引先に変わる可能性もあります。そうなると仕入れの管理や支払いの管理も変わってきます。
あるいは今までは商品在庫を一箇所で管理していたものの、感染症対策として、在庫場所を分散するなどの可能性もあります。
こういったビジネス環境の変化に合わせて、業務システムも迅速に対応する必要があるのです。
ITベンダーが売っているパッケージソフトやERPであれば、その対応も言葉が悪いかもしれませんが、お金を払えば丸投げすることも可能です。
しかし、社内でアナタが内製して作った業務システムは、アナタしか改造できないのです。
世間的には「これからは内製化の時代！」「業務ハック」などと言われますが、内製化した場合には、そのシステムの運用中は管理する責任が伴うことも意識しておく必要があります。
（ブラックボックス：属人化とのバランスが重要であり、一人のスキルに依存しない方が後々に良いことも？）
※本記事は松田軽太様許諾の元、「松田軽太のブロぐる」の記事をベースに再編集しております。
松田軽太（まつだ・けいた）
とある企業に勤務する現役情シス。会社の中では「何をしているのかナゾな職場」でもある情シス業務についてのTipsや基礎知識などを紹介する。
ブログ『松田軽太のブロぐる』を運営。
関連記事
