システム内製化には引き継ぎが大事？失敗事例から学んで備えよう

近年、システムを自社内で開発する「内製化」に切り替える企業が増えてきています。

もし今現在、外部の会社に開発を依頼しているなら、内製化にあたって注意しておくことがいくつかあります。

今回はシステムの引き継ぎをキーワードに会話形式でご紹介します。

なぜシステムの内製化が失敗するのか？

真人君、聞きたいことがあるんだけど。

大船さん、どうしました？

僕のお客さんで、システム内製化を進めている会社があって。

外部への依頼してたシステムを自社内での開発に移行ということですね。

ただ失敗したんだって。

あっ、そうなんですね…。

でも再チャレンジしたいらしくって、僕のところに相談があったんだ。

なるほど。
その原因を私に探れということですね？

そうなんだ。
お願いできるかな？

わかりました。
詳しく聞かせてください。

外部開発から内製化するには引き継ぎが必要

内製化とは言いましたが、新規でシステムを作り始めたんでしょうか？

いや、元々はアウトソーシングしていたらしい。

ということは、元々は別の会社がシステムの請負を？

みたいだね。
開発自体はうまくいってたようだけど、コストが気になっていたようなんだ。

なるほど、内製化で開発コストを下げようとしたんですね。

うん。
それで、お客さんの方でエンジニアが採用できた時点で、外部の開発会社の利用は辞めたそうだ。

エンジニアを採用してすぐに、外の開発会社からシステムを引き上げたんですか？

そうらしい。

内製化が始まって今で半年ぐらい。
ただ採用したエンジニアが何の成果も出せてないって、社長が怒っててさ。

うーん、それで？

そのエンジニアくんが言うには、全然人手が足りないって。
半年経った今もずっと調査をしているとかなんとかで。

それで社長が僕にぼやくんだよ…。
彼の経歴は嘘なんじゃないかって。

えっと、ああ、そうなんですね…

聞かなかったことにしよう。

ちゃんと開発会社から、システムを開発するのに必要な技術を聞いて、その技術に見合ったエンジニアを雇ったらしいんだけどね。

なるほど。

そんなわけで、人手も足りないって言うし、新しいエンジニアをさらに二人雇ったんだけど芳しくないっていうことで、今に至るわけなんだ。

…わかりました。
おそらくは引き継ぎ不足ですね。

引き継ぎ？
でも、開発に必要な情報は開発会社から提供されたはずだけど。

いえ、それだけでは十分とは言えないでしょう。

雇ったエンジニアがいまだに調査に時間を割いているということは、もらった情報だけでは足りていなかったのだと思います。

プログラミング言語とフレームワークが分かれば開発できるんじゃないの？

もちろん、フレームワークのようなベースになる技術の情報は大事ですが、どちらかというと知りたいのは、そのシステム特有の知識です。

なぜこのようなサーバーの配置になっているのか、なぜこのようなファイル構成で、このような書き方をしていて、なぜ…というのが無数にあるはずです。

そうなのかい。

プログラミング言語を習得していても、新しいプロジェクトやそのシステムに慣れるのはまた別です。
本来であれば、システムを最初に開発したエンジニアがいて、その人が新しいエンジニアに引き継ぎを行います。
もし教える人が誰もいなかったら、既に動いてるシステムを解析して理解していくしかありません。

うーん、どういうこと？

フレームワークって有名なものであれば、ネットで調べれば使い方がわかりますが、一方、お客さんのシステムついてはネットで検索してもわかりませんよね。
もしソースコードが外に公開されていれば、とんでもないことになります。

例えば、そのシステムになぜそのフレームワークを採用したのか、非効率的なコードがあったとして、なぜそのままにしているのか、といったことがあるとしたら、それはネットで検索しても理由はわからないんですよ。
知っているのは当時開発した担当者だけです。

なるほど、少しわかってきたよ。

そのシステムの歴史の理解や業務知識がないと、いくら技術を扱えるエンジニアを集めても開発は早くなりませんよ。

お客さんのシステム特有の情報の引き継ぎが必要だったわけだ。

ええ、エンジニアが今行っている調査というのは、ネットで調べてもわからない情報を読み解く作業を行っているのでしょう。

システムの引き継ぎ期間を設定する

それじゃあ、今からでも引き継ぎをお願いした方が良さそうだね。

ええ、ただ外部の開発会社が快く受けてくれるかどうかは分かりません…。

どういうことだい？

システム開発は信頼関係の元で行われます。
私の印象では、突然開発の依頼を辞めたように聞こえました。

うーん、まぁそうだね。

良くも悪くもスパッと辞めたわけだから、開発会社の手からは完全に離れたと言ってもいい。

当時の担当者は違うプロジェクトにアサインされているだろうし、終わったプロジェクトの情報を持ち続けるのも管理上のリスクになるので、資料を廃棄している可能性もあります。

それと、開発会社の「やっぱりうちが開発続けた方が良かったんじゃないか」という気持ちが透けて見えますよね。

ああ、うん。
そうだね…。

と少し意地悪な感じになりましたが、もし間に合うのであれば一度、当時の開発会社に相談した方がいいでしょう。

わかった。
進言しておくよ。

そうなると、改めて引き継ぎをするわけだけど、具体的にはどうすればいいんだろうか？

まずは当時開発に関わっていたエンジニアさんから、情報を提供していただく時間が必要でしょう。

なるほど、情報というのは、さっきの話にあったシステム特有の内容ってことだよね？

そうです。
ただ、全てを教わろうとは思わないでください。

どういうことだい？

理由は簡単で、膨大な量になるからです。
一度や二度、ミーティングしただけでは足りないことがあります。

そうなのか…。
ではどうすればいいんだろう？

調査を始めて半年、エンジニアも3名に増えているとのことですから、今現在でも、不明な点を重点的に聞くのがいいでしょう。

うん？
それは当たり前じゃないのかい？

私が言いたいのは、システムの仕様などを全て資料に起こしてもらうようなことはしなくていい、ということです。
これは大変な作業工数になります。

なるほど。
では、実は調査が全く進んでなかったとしたらどうすればいい？

その場合は、開発会社のエンジニアさんにも開発に入ってもらいましょう。
社内のエンジニアがシステムを理解するまで、開発会社さんに手伝ってもらいながら進めていくしかありません。

そうなるのか。
わかった。

社内のエンジニアは自社の業務に詳しくないといけない

お客さんと話してきたよ。

どうでしたか？

社長は「今さら頭を下げてお願いするなんて…。」と渋ってたけど、社内エンジニアの圧力で、もともとお願いしてた開発会社さんに手伝っていただくことになったよ。

受けてもらえたようで良かったですね。

そうだね。
ただ、また問題がありそうで。

開発会社のエンジニアさんが、お客さんの社員よりお客さんの業務に詳しいんだよね。

ああ、なるほど。
それはよくありますね。

それでお客さんが「あのエンジニア、うちに引き抜けないかな」とか言うもんだから困っちゃって。

それは完全にアウトだと思うけど…。

少なくとも合意のない引き抜きはやめてください、と冗談は置いときますけど。
課題は社内エンジニアの業務理解ですね。

業務理解？
エンジニアは開発ができればいいんじゃないの？

いえ、それは違います。
業務理解がなければ、そのシステムに必要な機能の開発はできません。
業務を理解できなければ、仕様の勘違いも起こりやすくなるし、良い提案もできないんですよ。

でも作りたいものは指示しているから、提案とかも別にいらないと思うけど。

ええ、もちろん、社内から上がってくる要望をもとに機能開発は行われるでしょう。
とはいえ、それをシステムに落とし込むのはエンジニアの仕事。
要望をそのままシステムに変換するのは無理で、その隙間をうまく埋めてあげる必要があるんです。

…うーん、どう言うこと？

例えば、「洗い替え」と言うキーワードがあったとき、エンジニアに知識がないと、システム内で変な名前をつけたりしてしまいます。
言葉の意味がわからないと、システムで何を実現したいのかわからなくて、開発が進まなくなります。

まぁ、そんなものか。
それでエンジニアの引き抜きが難しいなら、どうすればいい？

引き抜きはスルーしよう。

社内のエンジニアには業務知識をつけてもらいましょう。
例えば、関係部署の業務を1日体験してみたり、担当社員から話を聞いたり、開発をするだけではなく、自社業務の理解に時間を割くんです。

なるほど。
それはいいアイデアだね。

ところで、何で開発会社のエンジニアはそんなにお客さんの業務に詳しいんだろう？

開発に必要な業務の詳細を確認していたのでしょう。
担当期間が長くなればなるほど、業務に詳しくなっていくのはよくあることです。

特に初期の開発者は、お客さんのユースケースをかなり把握しているはずです。
実装にあたって正常系と異常系の両方も把握しているはずですし、まさにその業務のプロと言えるでしょう。

…開発に必要だからというのはわかったよ。
でも、続きの話は何だか難しそうだからまた今度でいい？

…別にいいですけど。

他のメンバーが対応できるように開発や運用の資料を作成する

真人君、また問題が起こった！！

どうしたんですか、そんなに慌てて。

最初に採用したエンジニアが辞めてしまったんだ！

ああ、そうなんですね。
でもあと二人、エンジニアがいましたよね？

そうなんだけど、彼らは辞めたエンジニアから指示を受けていてね。
コーディングはできるけど、システムや業務の理解はまだ浅いんだ。

なるほど…。
でも、経験を積んでいる段階なら急がなくてもいいのでは？
もう少し様子を見るべきです。

そうは言ってられない。
システムメンテナンスの定常業務は辞めたエンジニアしかできないんだ。

そう言うことですか…。
外部のエンジニアは、まぁ、引き継ぎのための開発の手伝いはしても、手放したシステムの運用をすることはないですよね。
内製化を手伝うための要員ですから。

そうなんだよ。
でも今回はその外部エンジニアくんに頼るしかない…。
またお客さんとこの社長が怒りそうだ。

そんなに頼るのが嫌なのか。
確かに追加の作業費は必要になるだろうけど…。

それで今後なんだが、どうやったらこの事態を防げたと思う？

そうですね…例えば、資料を用意するとか。
誰かが辞めても大丈夫なように、運用の手順書を作るべきです。

そうは言っても、まだプロジェクトを始まって半年ちょっとだ。
そんな余裕はないと思うけど。

気持ちはわかりますが、そうは言ってられません。
必ず誰かが辞めることを想定して、プロジェクトを回していく必要があるんですよ。

…資料作成のために、エンジニアのみんなに残業をしろと。
君はそう言うわけだね？

いえ、そうは言いませんが…。
人員を多めに用意したり、スケジュールに余裕を持たせるというやり方もできるでしょう。

最終的には経営判断ですが、システム開発を失敗させたくなければ、人が辞めてもうまく回るようにあらかじめ準備しておかないと。

わかった。
お客さんに進言してみるよ。

システム内製化も結局は急がば回れ

これからは開発のための資料も作って、後任のエンジニアの教育にも力を入れることになったよ。

そうですか。
であれば、ひとまずは安心ですね。

そうなんだけど…

何か問題でもありましたか？

結局、外部の開発会社にお願いした方が楽だったねという話になったんだよね。

ああ、まぁ、それもわかりますけれど。
餅は餅屋ということですね…。

けれども、これでシステム開発の知見が得られたでしょう。
例えまた外部に依頼し直すにしても、もっと的確にシステム開発の要件を伝えることができるはずです。

そうだね！
社長が「外部に投げっぱなしじゃなくて、社内のエンジニアといっしょに開発を進めるのがいいかもな」って言ってたから。

そうですね。
ところで、バス係数、もしくはトラック係数というGoogle発祥の言葉があるんですが、ご存知でしょうか？

いや、初めて聞いたよ。

ある業務で誰かが辞めても継続できるかどうかを表している指標なんですけど、バスとかトラックはただの例えなので、要は重要な業務に対しての代わりの人材はいるかどうかで考えてもらったらいいでしょう。

ふーん、とにかく、今回のようにすぐに引き継ぎができる体制を整えたり、代わりに作業できる人がいれば良いってことだよね？

そういうことですね。

わかった！
いろいろと苦労したけれど、今回も助かったよ。
ありがとう！