さて、前回に引き続き今回もシステム内製化をテーマにします。
こんにちは！ 松田軽太です。
先日、Twitterでこんなことをツブやいてみたところ、たくさんのご意見をいただきました。
業務部門の人が自力で内製したExcelやACCESSの業務システムを「属人化ガー！」と問題視され、ITベンダーから見積もりとったら数億円と提示されて絶句した…っていう話はお伽話のようにアチコチで聞く。
— 松田軽太 5550 (@matudakta) 2021年11月10日
これがどういうコトかを説明していきたいと思います。
誰もメンテナンスできなくなった野良システムの悲しい末路
業務部門のスタッフが手間の掛かる仕事をどうにかして効率よくしようと思って、独学でExcel-VBAやデータベースソフトのACCESSで、業務システムを作りました。
そして改良に改良を重ね数年が経ち、今やその職場の業務になくてはならない業務システムに育ちました。
あるとき、その業務システムを作った人が職場を異動（もしくは退職）することになり、手作り業務システムのお守りから外れました。
作った人は居なくなっても手作り業務システムは使い続けられます。
まぁ、だからといっていきなりそれで困ることはありません。
しかし事業は生き物ですので、いつどう変化するか分かりません。
そうなんです。問題なのは事業の変化に伴って、その手作り業務システムを改修する必要が出たときになって初めて「作った人がもう居ない」という危機に気がつくのです。
なにしろ手作り業務システムの稼働から数年経って、今やその「手作り業務システムを使う前提で業務が組み立てられている」のですから、手作り業務システムを使わずに業務を行うなんて考えられないのです。
そうなると、もうその部署単独の問題ではなく、火の粉が大きくなって経営層の耳に入ることになります。
そして経営陣はこう怒り出すのです。
「なんでそんな属人化するようなことをしたんだ！」と。
とはいえ経営陣が怒り狂っても問題は解決しないのでこう指示が出ます。
「このまま放っておくわけにもいかないから、すぐ情報システム部に相談しろ！」と。
そうです、情報システム部がこの話に足を突っ込むことになるのはここまでコジれまくったタイミングなのです。
とはいえ、手作り業務システムを見てもどんな構造になっているのかなんて情報システム部には分かりません。
大抵、こういうDIY的に作られた手作り業務システムには設計図や仕様書といったドキュメントはありません。
長い年月をかけて運用しながら機能拡張しているので、データは構造化されておらず、謎の係数らしき数字がハードコーディングされていたりして、もうハウルの動く城みたいになっています。
そして情報システム部では手に負えない案件だと気がつき、付き合いのあるITベンダーに泣きつきます。
「これと同じ機能をオタクでシステム開発してもらえるかな」
実際問題、最近の情報システム部はパッケージソフトを運用していて社内で開発する経験を積む機会が減っており、自分で開発できるようなスキルのある人は少ないのです。
そしてITベンダーがその複雑怪奇な手作り業務システムの機能をざっくり数えて見積もりを出すと、なんと数億円もの巨額の見積もり金額が記されているのを見て、みんな腰を抜かすのです。
なぜならこういう作業が必要だからです。
非ITのユーザーが作った仕様も規約も何もないブラックボックスを解析してヒアリングして要件定義して設計に落として全部作り直してテストしてUATで出る仕様変更に対応して納品する費用が入ってるからね。
非ITのユーザーが作った仕様も規約も何もないブラックボックスを解析してヒアリングして要件定義して設計に落として全部作り直してテストしてUATで出る仕様変更に対応して納品する費用が入ってるからね。 https://t.co/TQMxQuyVam
— 天野遠景@がんばれない (@tokagetail) 2021年11月11日
社内で片手間にチョコチョコっと作った業務システムだから大した金額にはならないと勘違いする人もいますがそう話は単純ではないのです。
適切なメンテナンスを行うことの出来ずに、野良化した内製システムの末路はこんな感じで厄介者扱いされてしまうのです。
あれだけ便利に使われていたにも関わらず･･･
野良システムをどうするかは最終的には会社が判断すること
そうは言っても作った人は責任感が強いと自分を責めてしまうことがあります。
例えばこのツイートのように。
億はないけど、○千万と言われたことがある。。
自分がいなくなったら業務が破綻するから、外注したいが予算なし。
どうすりゃいいんだ？
億はないけど、○千万と言われたことがある。。
— cf_clinical_engineer (@S10CF) 2021年11月10日
自分がいなくなったら業務が破綻するから、外注したいが予算なし。
どうすりゃいいんだ？ https://t.co/LGSMgppxas
しかし、です。
業務が破綻するほどの重要な道具（業務システム）にかけるお金を用意できずに、
結果として業務が破綻したら、それは会社の判断ですから、実は責任は会社側にあると思います。
とっても大事な業務システムだと思うなら、情報化投資をすべきなのです。
だから作った人は必要以上に自分を責める必要はないのです。
内製したシステムを野良化させない方法はあるか？
では内製化した業務システムを野良化させない方法はあるのでしょうか？
Twitterにその答えがありました。
だからせめて、要件定義から運用まで一気通貫でできる人になって最後まで責任を持って作ってほしいんですよね
本人しか中身が分からない状況のままなのに、会社に評価されたらトンズラして、動かなくなったら全く関係ない情シスに丸投げされる地獄絵図を何度も見てきたので…
ホントそうなんです
— お ι″ ゃ (@oja_project) 2021年11月11日
だからせめて、要件定義から運用まで一気通貫でできる人になって最後まで責任を持って作ってほしいんですよね
本人しか中身が分からない状況のままなのに、会社に評価されたらトンズラして、動かなくなったら全く関係ない情シスに丸投げされる地獄絵図を何度も見てきたので…
そうなのです、適切な設計書が整備されていれば、手作り業務システムのデータ項目や機能が分かるのでメンテナンスもできるし、もしくは再構築することも可能になるのです。
すなわち業務システムを内製化するのであれば、のちのちまで運用できるように最低限のドキュメントを整えておくべきなのです。
しかしそういう話をすると
「いやいや、それは大昔から行われている時代遅れのウォーターフォール開発の話でしょ？今やアジャイル開発の時代。作っては修正し作っては修正し･･･の繰り返しだから仕様書なんて作るだけムダムダムダーーーー！！」
と反論されたります。
ではアジャイル開発だから仕様書はまったく無くても良いのでしょうか？
せめて業務システムの使用目的（要件）、データモデルが分かるER図、画面設計や画面遷移図くらいは作っておくべきでしょう。
興味がある人はこういう本を参考にしてみてください。
そうしないと、いきなり手作り業務システムの面倒を見ろと言われても、引き継げなくなります。
結論としては「業務システムを手作りする場合は、運用まで含めて考えよう」ということだと思います。
「業務システムを運用する」というのは、稼働してからその業務がなくなるまで長い旅を続けるということですから。
ちなみに業務システムを手作りしてみようと思っているのであれば、こういう本が参考になります。
前回のお話はこちらです。
