最近、あちこちで業務システムの内製化を推奨する記事を見かけるようになりました。
まぁ、変化の早い時代ですから、すばやく開発するには内製化しないと間に合わないというのがその理由ですね。
こんにちは！ 松田軽太です。
･･･と言いながら、日経クロステックにこんな記事が載っていました。
社内における外注状態とは、ユーザー部門が情報システム部門にシステムを「外注」しているような状態を指す。
発注者意識のまま内製に取り組めば、受発注の関係がそのまま社内で構築され、結局は外部に「丸投げ」しているのと変わらない。
互いがリスクを避けるために「ITのことは分からないので情報システム部門に任せる」「ユーザー部門から文句を言われないよう納期を保守的に見積もる／言われた機能だけを実装する」などの状況に陥りやすいという。
う～ん、怖いですよね。
ってことでTwitterにこんなつぶやきをしてみました。
これ、けっこうヤヴァイっすね！
RPA、VBA、ローコード開発などで内製化した場合、しばらくしたらこうなるリスク高し。
これ、けっこうヤヴァイっすね！
— 松田軽太 5550 (@matudakta) 2021年12月17日
RPA、VBA、ローコード開発などで内製化した場合、しばらくしたらこうなるリスク高し。
無理解のまま進める内製シフトのリスク、「社内外注」に陥る危険も https://t.co/37VDWbMc0g
この内製化リスク、実は当ブログ記事でたびたび取り上げていた内容です。
規模に関わらずEUCによる業務システム内製化を経験されている人であれば、特に不思議ではない話でしょうね。
ただし今回のように大きなメディアで取り上げられたということは、徐々に問題が大きくなったということなのでしょうね。
ではTwitterに寄せられた声をご紹介していきます。
ヤヴァイですねー…ヘーシャもこんな状態ですよ。
IT歴の浅いヘーシャでは社内でのIT格差は激しいですからね…。自分達でも学びながら社内外注してくれたらいいけど、豪速球で丸投げしてくる人ばっかりですからねw
ヤヴァイですねー…ヘーシャもこんな状態ですよ。
— きったん@ノーコードツールの申し子(自称) (@KK80979809) 2021年12月17日
IT歴の浅いヘーシャでは社内でのIT格差は激しいですからね…。自分達でも学びながら社内外注してくれたらいいけど、豪速球で丸投げしてくる人ばっかりですからねw
皆さんの仰る通り、目的が明確で会社組織で連携できる体制とやり方をしっかりしないと、社内外注で冷えた関係になりそうですね。
しかもうまく回る前に技術者が転職して確保難に陥って中折れしてしまいそうです。
皆さんの仰る通り、目的が明確で会社組織で連携できる体制とやり方をしっかりしないと、社内外注で冷えた関係になりそうですね🤔しかもうまく回る前に技術者が転職して確保難に陥って中折れしてしまいそうです😫
— うさみこ@愛犬好き情シス (@usamiko) 2021年12月18日
このツイートでも上げられる問題ですが、業務システム化を丸投げしてくる人がいかに多いことか。
社内にはITに疎い人の方が圧倒的に多いですから、要求する側の度が過ぎると、そのシステム化を押しつけられた側が「なんでお前らを楽チンにさせる為に、ワイだけが苦労せなアカンのじゃ！」と我に返るとモチベーションがダダ下がりになります。
そして、その状況を見て見ぬふりして放置すると、ヘタすりゃその人、辞めちゃいます。
このようにして野良システムが増えていくことになるのです。
システム内製化は所詮は「DIYシステム」なので管理基準が明確じゃない
では特定の人だけに負担が掛からないようにするにはどうすれば良いのでしょう。
なんか解るそうなるとやはりコンサルが一定程度かかわったほうが良いと思えてしまう。 ローコード、内製は良いところだけではないんだなー。 ガイドラインやドキュメント無く進めてると危険は更に高まると思う。 内製のお作法みたいなものが必要だと思う…
なんか解るそうなるとやはりコンサルが一定程度かかわったほうが良いと思えてしまう。
— ロボティク子 (@robotic_ko) 2021年12月18日
ローコード、内製は良いところだけではないんだなー。
ガイドラインやドキュメント無く進めてると危険は更に高まると思う。
内製のお作法みたいなものが必要だと思う… https://t.co/u2baS4t6lH
システム内製化って所詮は「DIYシステム」だから、システムの作り方もツールの品質も道具もバラバラです。
運用まで考えて設計できる人もいるだろうし、とりあえず動くものを作る人もいるでしょう。
それは仕方がないことです。鉄板のノウハウがあるワケではないですから。
DIYシステムという言葉は言い得て妙ですな。とはいえ 、全てを大工さんにやってもらうかというとそれも否。見極めが肝心ということですな。
DIYシステムという言葉は言い得て妙ですな。とはいえ 、全てを大工さんにやってもらうかというとそれも否。見極めが肝心ということですな。 https://t.co/8sbHSKigZP
— Tas (@tas26942737) 2021年12月18日
いくら業務システムの内製化が流行っているからといって、何でもかんでも内製化すれば良いというものでもありません。
例えば家で考えてみしょう。
大雨や猛暑の灼熱から身を守る家自体をDIYで作ろうと考える人は少ないでしょう。
家は建築のプロに頼んで建ててもらった方が安全です。
業務システムで家にあたるのは何かというと販売管理システムや在庫管理システムや会計システムといった基幹系のシステムでしょう。
いわゆるSoR領域といわれる記録システムです。この部分にあたるシステムは正しく記録することが大事です。なんせお金や商品の管理をするビジネスの肝になる部分ですから。
なのでパッケージソフトやERPを使う方が無難だと言えます。
ではシステム内製化に向いているのはどういうものでしょう。
こちらも家にたとえるから本棚とかテーブルといった家具でしょう。
これらであれば各自が使いやすく便利なように自分で設計して作ってみても大きな問題はなさそうです。
いわゆるSoE領域といわれる差別化システムにあたります。
業務システムの内製化で怖いのは、作った人が退職して動いているシステムの中身が分からず誰も面倒をみれなくなった場合です。
それがお金や在庫を管理するシステムなら経営自体に大きな影響を与えます。
業務システムを使うということは「動いてる間は面倒を見れる」ことが大事なのです。
要件定義できる人を育てるという方法もある
要は「人」の問題なのです。
それについてはこういう意見もあります。
うまく解決したいなら、ユーザ部門内から代表で要件定義担当を出させてIT教育するのがベター 僕はユーザ部門内である程度仕事を覚えて、それからマクロ内製やっているんだが、両方知ってるから適切な要件なのかを想像→判断ができる ユーザ部門のバックグラウンドが分かるキーマン作りがカギだね
うまく解決したいなら、ユーザ部門内から代表で要件定義担当を出させてIT教育するのがベター
— やろまい (@yaromai_) 2021年12月18日
僕はユーザ部門内である程度仕事を覚えて、それからマクロ内製やっているんだが、両方知ってるから適切な要件なのかを想像→判断ができる
ユーザ部門のバックグラウンドが分かるキーマン作りがカギだね https://t.co/Zn8O8qZ2HB
システム構築で一番肝心なのは「何をしたいのか、それをどう実現するのか」を考えることです。
そう、要件定義が大事になります。
しかしいきなり「要件定義をしましょうね」と言われてもどうして良いか分かりませんよね。
いくらDIYシステムとはいえ、設計しないと材料も分かりませんよね。
なので、こういう書籍を読んで、まずシステム開発に必要なお作法を知っておくべきだと思います。
「システム構築をできる」というのは特殊な技能を持った人を大事にしよう
要件定義をできるというだけで、特殊な能力だといえます。
次に問題となるのは、システム構築できる人のモチベーションをどう維持させるかでしょう。
要求～設計～コードまで分かる総合人材の給料アップ・裁量権・働きやすいようになって欲しいほっとした顔
結局わかる人に丸投げでこき使うみたいなので人は流出するのだから
要求～設計～コードまで分かる総合人材の給料アップ・裁量権・働きやすいようになって欲しい😌
— だーちー🤾エンジニア備忘録 (@daa_tiii) 2021年12月18日
結局わかる人に丸投げでこき使うみたいなので人は流出するのだから#駆け出しエンジニアと繋がりたい https://t.co/Y5PH4pY2al
業務システムの構築には想定外は付き物です。
後出しジャンケンみたいな要件が湧いてくるからです。
その時に大事になるのが待遇です。
予算も権限も何も与えられないと必要なことができません。
それが続くとイヤになって退職してしまいます。
せめて必要な道具は使えるようにしてあげることが大事です。
いずれにせよDXブームに乗って慌ててシステム内製化をすると、あとあとろくなコトになりません。
人材確保、待遇、裁量といった働く環境を整える必要があります。
場合によっては組織変更も必要です。現在、IT人材はどこも不足しています。
ところが非IT系の事業会社の標準的な賃金テーブルでは、そうした優柔なIT人材を獲得できない可能性が高いのです。
しかし他の部門と大きな賃金格差があっては「不公平だ！」と不満が出るかもしれません。
それを避けるには、たとえば別会社に分けてしまうという手もあります。
残念ながら「安い給料で優秀なIT人材の確保する」は現実的はないですから。
DXブームが終わった先に待つ本当の恐怖
現在はDXブームで内製化が流行している状態です。
しかしブームはいずれ終わります。
コンピューター業界にもファッションと同じようにブームがあります。
内製、外注、分散、集中 などなど。
それらの過去の流れを考えるとシステム内製化ブームも終わる時を迎えるかもしれません。
終わる理由はさまざまでしょう。
人材確保が難しくなった。
内製化できそうな業務が尽きた。
内製化をしてみたものの品質がよくなくて期待外れだった。
よく考えたら内製しなくても売ってるツールを使えば良かった。
問題になるのは数年後に
「昔、内製で作った業務システムがまだ使われているんだけど、作った人が辞めちゃって誰も中身の仕組みが分からない。ITベンダーに相談したけど、相手にしてくれない。でも業務はこのシステムありきで廻っているから無いと仕事にならない。どうしよう」
という状況だと思います。
内製化の最大の恐怖はそれをメテナンスできる人が居なくなった時の野良化なのです。
だから最低限の設計書は用意すべきだし、そういう知識は知っておく必要があるのです。
だぶん数年後には内製化ブームで作ったシステムの野良化が問題になると思います。
そう、「DX－2025年の崖」でのレガシーシステム問題みたいに。
