近年、システムを自社内で開発する「内製化」に切り替える企業が増えてきています。
もし今現在、外部の会社に開発を依頼しているなら、内製化にあたって注意しておくことがいくつかあります。
今回はシステムの引き継ぎをキーワードに会話形式でご紹介します。
藤沢真人、IT業界20年のベテランエンジニアで40歳。
請負開発の会社でプログラマー、システムエンジニア、プロジェクトマネージャーとしての経験を積む。
その後、中小企業のIT支援をするために小さな会社を設立。
現在はITを活用したい会社のためのアドバイザーとして、複数の会社のコンサルティング業務を行なっている。
モットーは「すべての会社にITを」。
小さなウェブ制作会社に勤める営業マン、52歳。お願い上手のお調子者。
営業歴30年の超ベテランだが、気軽に相談しやすいことから、サイト制作以外の話もよく受けている。
ただ専門的なことはわからないので、いつも真人にお願いして困らせている。
口癖は「仲の良いお客さんだから断れないんだよ。」
なぜシステムの内製化が失敗するのか？
大船さん真人君、聞きたいことがあるんだけど。
真人大船さん、どうしました？
大船さん僕のお客さんで、システム内製化を進めている会社があって。
真人外部への依頼してたシステムを自社内での開発に移行ということですね。
大船さんただ失敗したんだって。
真人あっ、そうなんですね…。
大船さんでも再チャレンジしたいらしくって、僕のところに相談があったんだ。
真人なるほど。
その原因を私に探れということですね？
大船さんそうなんだ。
お願いできるかな？
真人わかりました。
詳しく聞かせてください。
外部開発から内製化するには引き継ぎが必要
真人内製化とは言いましたが、新規でシステムを作り始めたんでしょうか？
大船さんいや、元々はアウトソーシングしていたらしい。
真人ということは、元々は別の会社がシステムの請負を？
大船さんみたいだね。
開発自体はうまくいってたようだけど、コストが気になっていたようなんだ。
真人なるほど、内製化で開発コストを下げようとしたんですね。
大船さんうん。
それで、お客さんの方でエンジニアが採用できた時点で、外部の開発会社の利用は辞めたそうだ。
真人エンジニアを採用してすぐに、外の開発会社からシステムを引き上げたんですか？
大船さんそうらしい。
大船さん内製化が始まって今で半年ぐらい。
ただ採用したエンジニアが何の成果も出せてないって、社長が怒っててさ。
真人うーん、それで？
大船さんそのエンジニアくんが言うには、全然人手が足りないって。
半年経った今もずっと調査をしているとかなんとかで。
大船さんそれで社長が僕にぼやくんだよ…。
彼の経歴は嘘なんじゃないかって。
真人えっと、ああ、そうなんですね…
真人聞かなかったことにしよう。
大船さんちゃんと開発会社から、システムを開発するのに必要な技術を聞いて、その技術に見合ったエンジニアを雇ったらしいんだけどね。
真人なるほど。
大船さんそんなわけで、人手も足りないって言うし、新しいエンジニアをさらに二人雇ったんだけど芳しくないっていうことで、今に至るわけなんだ。
真人…わかりました。
おそらくは引き継ぎ不足ですね。
大船さん引き継ぎ？
でも、開発に必要な情報は開発会社から提供されたはずだけど。
真人いえ、それだけでは十分とは言えないでしょう。
真人雇ったエンジニアがいまだに調査に時間を割いているということは、もらった情報だけでは足りていなかったのだと思います。
大船さんプログラミング言語とフレームワークが分かれば開発できるんじゃないの？
真人もちろん、フレームワークのようなベースになる技術の情報は大事ですが、どちらかというと知りたいのは、そのシステム特有の知識です。
真人なぜこのようなサーバーの配置になっているのか、なぜこのようなファイル構成で、このような書き方をしていて、なぜ…というのが無数にあるはずです。
大船さんそうなのかい。
真人プログラミング言語を習得していても、新しいプロジェクトやそのシステムに慣れるのはまた別です。
本来であれば、システムを最初に開発したエンジニアがいて、その人が新しいエンジニアに引き継ぎを行います。
もし教える人が誰もいなかったら、既に動いてるシステムを解析して理解していくしかありません。
大船さんうーん、どういうこと？
真人フレームワークって有名なものであれば、ネットで調べれば使い方がわかりますが、一方、お客さんのシステムついてはネットで検索してもわかりませんよね。
もしソースコードが外に公開されていれば、とんでもないことになります。
真人例えば、そのシステムになぜそのフレームワークを採用したのか、非効率的なコードがあったとして、なぜそのままにしているのか、といったことがあるとしたら、それはネットで検索しても理由はわからないんですよ。
知っているのは当時開発した担当者だけです。
大船さんなるほど、少しわかってきたよ。
真人そのシステムの歴史の理解や業務知識がないと、いくら技術を扱えるエンジニアを集めても開発は早くなりませんよ。
大船さんお客さんのシステム特有の情報の引き継ぎが必要だったわけだ。
真人ええ、エンジニアが今行っている調査というのは、ネットで調べてもわからない情報を読み解く作業を行っているのでしょう。
内製化にあたって、外部開発から社内開発に切り替えるなら、引き継ぎは必須になります。
特に自社内にエンジニアがおらず、開発業務を全て外部に依頼していたのであれば、知識の空白が生まれるのは避けられません。
引き継ぐべき情報には、システムに使われている技術だけでなく、システム特有の業務知識も含んでいることに注意してください。
システムの引き継ぎ期間を設定する
大船さんそれじゃあ、今からでも引き継ぎをお願いした方が良さそうだね。
真人ええ、ただ外部の開発会社が快く受けてくれるかどうかは分かりません…。
大船さんどういうことだい？
真人システム開発は信頼関係の元で行われます。
私の印象では、突然開発の依頼を辞めたように聞こえました。
大船さんうーん、まぁそうだね。
真人良くも悪くもスパッと辞めたわけだから、開発会社の手からは完全に離れたと言ってもいい。
真人当時の担当者は違うプロジェクトにアサインされているだろうし、終わったプロジェクトの情報を持ち続けるのも管理上のリスクになるので、資料を廃棄している可能性もあります。
真人それと、開発会社の「やっぱりうちが開発続けた方が良かったんじゃないか」という気持ちが透けて見えますよね。
大船さんああ、うん。
そうだね…。
真人と少し意地悪な感じになりましたが、もし間に合うのであれば一度、当時の開発会社に相談した方がいいでしょう。
大船さんわかった。
進言しておくよ。
大船さんそうなると、改めて引き継ぎをするわけだけど、具体的にはどうすればいいんだろうか？
真人まずは当時開発に関わっていたエンジニアさんから、情報を提供していただく時間が必要でしょう。
大船さんなるほど、情報というのは、さっきの話にあったシステム特有の内容ってことだよね？
真人そうです。
ただ、全てを教わろうとは思わないでください。
大船さんどういうことだい？
真人理由は簡単で、膨大な量になるからです。
一度や二度、ミーティングしただけでは足りないことがあります。
大船さんそうなのか…。
ではどうすればいいんだろう？
真人調査を始めて半年、エンジニアも3名に増えているとのことですから、今現在でも、不明な点を重点的に聞くのがいいでしょう。
大船さんうん？
それは当たり前じゃないのかい？
真人私が言いたいのは、システムの仕様などを全て資料に起こしてもらうようなことはしなくていい、ということです。
これは大変な作業工数になります。
大船さんなるほど。
では、実は調査が全く進んでなかったとしたらどうすればいい？
真人その場合は、開発会社のエンジニアさんにも開発に入ってもらいましょう。
社内のエンジニアがシステムを理解するまで、開発会社さんに手伝ってもらいながら進めていくしかありません。
大船さんそうなるのか。
わかった。
引き継ぎにあたって、システム開発の資料が全てそろっているプロジェクトはほとんどありません。
必ずどこか抜け落ちている情報が存在します。
場合によっては、機能追加が優先されて、ドキュメントの整備が全く進んでいないこともあります。
どちらにしても、文書だけの引き継ぎでは不十分で、担当のエンジニアがしばらく横について教えるようなやり方が理想的といえます。
「何がわからないのかわからない」という状況がしばらく続くので、引き継ぎ期間は長めに確保すべきでしょう。
社内のエンジニアは自社の業務に詳しくないといけない
大船さんお客さんと話してきたよ。
真人どうでしたか？
大船さん社長は「今さら頭を下げてお願いするなんて…。」と渋ってたけど、社内エンジニアの圧力で、もともとお願いしてた開発会社さんに手伝っていただくことになったよ。
真人受けてもらえたようで良かったですね。
大船さんそうだね。
ただ、また問題がありそうで。
大船さん開発会社のエンジニアさんが、お客さんの社員よりお客さんの業務に詳しいんだよね。
真人ああ、なるほど。
それはよくありますね。
大船さんそれでお客さんが「あのエンジニア、うちに引き抜けないかな」とか言うもんだから困っちゃって。
真人それは完全にアウトだと思うけど…。
真人少なくとも合意のない引き抜きはやめてください、と冗談は置いときますけど。
課題は社内エンジニアの業務理解ですね。
大船さん業務理解？
エンジニアは開発ができればいいんじゃないの？
真人いえ、それは違います。
業務理解がなければ、そのシステムに必要な機能の開発はできません。
業務を理解できなければ、仕様の勘違いも起こりやすくなるし、良い提案もできないんですよ。
大船さんでも作りたいものは指示しているから、提案とかも別にいらないと思うけど。
真人ええ、もちろん、社内から上がってくる要望をもとに機能開発は行われるでしょう。
とはいえ、それをシステムに落とし込むのはエンジニアの仕事。
要望をそのままシステムに変換するのは無理で、その隙間をうまく埋めてあげる必要があるんです。
大船さん…うーん、どう言うこと？
真人例えば、「洗い替え」と言うキーワードがあったとき、エンジニアに知識がないと、システム内で変な名前をつけたりしてしまいます。
言葉の意味がわからないと、システムで何を実現したいのかわからなくて、開発が進まなくなります。
大船さんまぁ、そんなものか。
それでエンジニアの引き抜きが難しいなら、どうすればいい？
真人引き抜きはスルーしよう。
真人社内のエンジニアには業務知識をつけてもらいましょう。
例えば、関係部署の業務を1日体験してみたり、担当社員から話を聞いたり、開発をするだけではなく、自社業務の理解に時間を割くんです。
大船さんなるほど。
それはいいアイデアだね。
大船さんところで、何で開発会社のエンジニアはそんなにお客さんの業務に詳しいんだろう？
真人開発に必要な業務の詳細を確認していたのでしょう。
担当期間が長くなればなるほど、業務に詳しくなっていくのはよくあることです。
真人特に初期の開発者は、お客さんのユースケースをかなり把握しているはずです。
実装にあたって正常系と異常系の両方も把握しているはずですし、まさにその業務のプロと言えるでしょう。
大船さん…開発に必要だからというのはわかったよ。
でも、続きの話は何だか難しそうだからまた今度でいい？
真人…別にいいですけど。
エンジニアが自社業務を理解してないと、システム開発はうまく進みません。
例えば、会計ソフトを作るにあたって、勘定科目の意味がわからなければ、ベースになる業務知識が足りず、開発が滞ることが目に見えます。
特にシステム設計を行うときに、「ユーザーがどのように利用するか」を想像できなければ、良いシステムを作るのは不可能と言っても過言ではありません。
他のメンバーが対応できるように開発や運用の資料を作成する
大船さん真人君、また問題が起こった！！
真人どうしたんですか、そんなに慌てて。
大船さん最初に採用したエンジニアが辞めてしまったんだ！
真人ああ、そうなんですね。
でもあと二人、エンジニアがいましたよね？
大船さんそうなんだけど、彼らは辞めたエンジニアから指示を受けていてね。
コーディングはできるけど、システムや業務の理解はまだ浅いんだ。
真人なるほど…。
でも、経験を積んでいる段階なら急がなくてもいいのでは？
もう少し様子を見るべきです。
大船さんそうは言ってられない。
システムメンテナンスの定常業務は辞めたエンジニアしかできないんだ。
真人そう言うことですか…。
外部のエンジニアは、まぁ、引き継ぎのための開発の手伝いはしても、手放したシステムの運用をすることはないですよね。
内製化を手伝うための要員ですから。
大船さんそうなんだよ。
でも今回はその外部エンジニアくんに頼るしかない…。
またお客さんとこの社長が怒りそうだ。
真人そんなに頼るのが嫌なのか。
確かに追加の作業費は必要になるだろうけど…。
大船さんそれで今後なんだが、どうやったらこの事態を防げたと思う？
真人そうですね…例えば、資料を用意するとか。
誰かが辞めても大丈夫なように、運用の手順書を作るべきです。
大船さんそうは言っても、まだプロジェクトを始まって半年ちょっとだ。
そんな余裕はないと思うけど。
真人気持ちはわかりますが、そうは言ってられません。
必ず誰かが辞めることを想定して、プロジェクトを回していく必要があるんですよ。
大船さん…資料作成のために、エンジニアのみんなに残業をしろと。
君はそう言うわけだね？
真人いえ、そうは言いませんが…。
人員を多めに用意したり、スケジュールに余裕を持たせるというやり方もできるでしょう。
真人最終的には経営判断ですが、システム開発を失敗させたくなければ、人が辞めてもうまく回るようにあらかじめ準備しておかないと。
大船さんわかった。
お客さんに進言してみるよ。
システム開発の理想は、「どんどん開発して、どんどん機能追加をする」なのですが、なかなか上手くいかないものです。
理由としては、開発メンバーのスキルに差があったり、今回のようにシステムを引き継いだばかりで、開発だけに集中できないといったこともあるでしょう。
これはシステム開発に限りませんが、「主要メンバーがいなくなったらどうするか」を念頭に置いて、プロジェクトを進める必要があります。
特にシステム開発は専門性が高いものでもあるため、後任・後釜と言える人材を育てておくことも重要になるでしょう。
システム内製化も結局は急がば回れ
大船さんこれからは開発のための資料も作って、後任のエンジニアの教育にも力を入れることになったよ。
真人そうですか。
であれば、ひとまずは安心ですね。
大船さんそうなんだけど…
真人何か問題でもありましたか？
大船さん結局、外部の開発会社にお願いした方が楽だったねという話になったんだよね。
真人ああ、まぁ、それもわかりますけれど。
餅は餅屋ということですね…。
真人けれども、これでシステム開発の知見が得られたでしょう。
例えまた外部に依頼し直すにしても、もっと的確にシステム開発の要件を伝えることができるはずです。
大船さんそうだね！
社長が「外部に投げっぱなしじゃなくて、社内のエンジニアといっしょに開発を進めるのがいいかもな」って言ってたから。
真人そうですね。
ところで、バス係数、もしくはトラック係数というGoogle発祥の言葉があるんですが、ご存知でしょうか？
大船さんいや、初めて聞いたよ。
真人ある業務で誰かが辞めても継続できるかどうかを表している指標なんですけど、バスとかトラックはただの例えなので、要は重要な業務に対しての代わりの人材はいるかどうかで考えてもらったらいいでしょう。
大船さんふーん、とにかく、今回のようにすぐに引き継ぎができる体制を整えたり、代わりに作業できる人がいれば良いってことだよね？
真人そういうことですね。
大船さんわかった！
いろいろと苦労したけれど、今回も助かったよ。
ありがとう！
ファンブリューでは神奈川県藤沢市を拠点に、全国各地のシステム開発を請け負っております。
システム担当者の方で、
現在こんなお悩みはありませんか？
開発会社にお願いをしているけれど、なんだか反応が良くない…
気軽に相談できない
開発後もしっかりサポートしてほしい
ファンブリューでは血の通ったシステム開発を行っています。
お客様との将来的な関係を見据えて、お仕事をお受けしています。
信頼関係を大切にした開発にご興味がある方は、今すぐ下のボタンからお問い合わせください。
確認次第、折り返しメールでご連絡を差し上げます。
