内製開発に必要なのは、エンジニアではなく“Engineer”:そのベンダー、内製を共創できますか?(1/3 ページ)
ユーザー企業だけでは賄えない部分をベンダーが支援する「共創型内製」が増えてきている。その際のパートナー探しには、アウトソース時とは異なるポイントがあるという。
そのベンダー、たぶん内製支援に対応できません。
問題
日本にはエンジニアが100万人いるといわれています。では、その内「内製支援に対応できるエンジニア」は、何人いるでしょうか。
回答
恐らく3万人以下
システム開発の必要性が生じたときに、社内の技術者のみで完結させることを「内製」といい、ビジネスが変化するスピードが速くなっている昨今、外部ベンダーへのアウトソースから内製化に舵(かじ)を切る企業が増えています。しかしエンジニア不足の折、完全な内製が実現できる企業は数えるほど。外部ベンダーと「共創」で内製を進める企業が大半でしょう。
そして、そういった企業の多くが、現状、大手ベンダーを内製パートナーとして選んでいると思います。ですが、大手ベンダーの傘下に「内製支援に対応できるエンジニアはほぼいない」ということはご存じでしょうか。
申し遅れました。私、「情報戦略テクノロジー」の稲葉と申します。SI業界の変革をテーマに掲げる企業の広報担当として、「スキルシート詐欺が起こるメカニズムとエンジニアが取れる対処法」など、IT業界のエンジニアに警鐘を鳴らす記事を書いています。今回は仲間の山川と共に、「内製支援に対応できるエンジニアやベンダーの探し方」を解説します。
ユーザー企業で内製を推進する立場の皆さんの参考になれば幸いです。
海外の“Engineer”と、日本の「エンジニア」
まず、「日本のエンジニアの多くは、海外の“Engineer”とは別物である」というお話をさせてください。
海外の定義では、日本のIT技術者(SE、PG)の多くは、“Engineer”ではなく“Technician”という存在です。
日本のSEが、海外でいうところの“Engineer”に該当するのですが、実態はその多くが“Technician”です。ちなみに“SystemEngineer”は和製英語で、海外にSEという職業は存在しません
海外で定義する“Engineer”は、「高度な知識を持ち、ビジネスサイドと対等にコミュニケーションを取りながら知識を応用し、デジタルビジネスを創っていく人」のこと。ビジネスサイドと共に、どうすれば最善のシステムが作れるか考え、ときに提案し、ときにいさめ、場合によっては反論も辞さない「ものいう技術者」です。
対する“Technician”は、「“Engineer”の指示を受けてシステムを作る人」です。開発だけ担当する技術ベースの人で、途中でシステムが失敗すると分かっていても指示通りに動く従順な存在です。
ビジネスサイドと技術者サイドがコミュニケーションを取り合って作っていくことが大前提である内製は、“Engineer”と一緒にやっていかなければ、うまくいきません。
過去に多くのシステム開発が失敗してきた要因も、根本は技術知見がないエンドユーザーのプロダクトオーナー(PO)と“Technician”の間に“Engineer”がいないことが要因でした(COCOAの場合は、“PO”と“Engineer”の間に大手SIerがいて分断されてしまったことが失敗要因だったようですが)。
上段は「POの指示通り作る受発注関係」なので、開発がうまくいくかどうかはPOの技術知見レベル次第。下段は「“Engineer”がビジネスサイドと技術サイドの間を取り持ち、コミュニケーションを取り合いながら作るパートナー関係」なので、POの技術知見レベルを問わず開発がうまくいく確率が高くなります。“Engineer”が、PCのOSのような翻訳者としての役割を果たしています
システム要件が最初からカッチリ決まっている場合は、開発だけ技術担当者に依頼すればいいので、POと“Technician”だけでうまくいくこともあります。しかし、システム要件が決まりきっていない、開発しながら決めていく場合は、POと“Technician”の間に“Engineer”が必要です。
基幹システムのような、要件通りに開発していくシステムに適しているのは“Technician”。ビジネス変化に対応しながら開発していく、完成後も永続的に改善し続けていく内製スタイルに適しているのは“Engineer”です。
この違いの大きさについて、ベンダーとの共創型内製を実践している企業にお話を伺いました。
セブン銀行 デジタルバンキング部 斉藤大明氏
スマートフォンアプリ「Myセブン銀行」は、UIやUXにこだわるため、デザイン思考やアジャイル開発を取り入れて進めていくという方針でスタートしました。外部企業へ請負契約で発注するというスタイルだと、「要件定義で定めたものを正しく作る」ことが目的になり、エンドユーザーのフィードバックを取り込んだり、新しいアイデアを反映させて作り込んだりしていくことが難しいため、内製開発という選択をしました。
ただ、ノウハウがない技術領域だったり、思い付いたアイデアが実現可能なのかどうか不明確だったりしたときに、気軽に相談や確認できる相手が必要でした。
しかし、その相手が“Technician”タイプだと「まず要件をまとめてください」から始まるため、内製のメリットであるスピード感が失われてしまいます。だからこそ、パートナーとして一緒に開発できる“Engineer”が必要でした。
テレビ東京コミュニケーションズ メディア事業開発本部 三浦智子氏
私たちがサービス開発をしている広告付き無料動画配信サービスの基盤となるシステムは、システムを内製できる社内の“Engineer”がシステム改修を担当していました。社内の“Engineer”の場合、業務内容やサービス理解も早く、ユーザーの声を反映させたユーザーフレンドリーなサービスを素早く構築することができます。しかし、社内だけでは“Engineer”の人員が不足しており、多くの開発タスクを素早いサイクルで回せない状況でした。
そこで私たちは外部企業へのアウトソースの検討を進めました。すると、ネックになっていたのは、「作り手=“Technician”の不足」ではなく、ビジネス側の事情と技術面での実現性を同時に考えられる「サービス改善提案や仕様決定ができる“Engineer”の不足」だったことが分かったのです。
ビジネスの目的やシステムを利用するユーザーを理解し、社内の“Engineer”のように私たちと寄り添ってサービス開発に伴走していただける“Engineer”が共創パートナーとして必要でした。
これまではシステムの仕様や要件を固めていくのは、PMやITコンサルの仕事でした。しかし、技術知見が十分ではない人の場合、日々のビジネス変化に合わせたスピーディーな仕様、要件変更には対応できません。そこで必要になるのが“Engineer”です。
しかし、日本国内には“Engineer”が、あまりいません。弊社の長年にわたる採用の経験から得た体感値では、エンジニア30人につき“Engineer”1人の割合です。日本にはエンジニアが100万人いるといわれていますので、内訳は“Engineer”が3万人/“Technician”が97万人なのではないかと考えています。
関連記事
- 特集:内製開発とベンダーマネジメント
- あるお役所がCOBOLで書かれた古いパッケージソフトを使い続けている理由
- 仕組みは作った、人はまだか
民間人材の登用、標準ガイドラインや工程レビュー。政府は健全なベンダーマネジメントを行うためにさまざまな施策を行ってきた。だがしかし、1番大きな問題がまだ残っている - 多重下請け構造であえいでいるエンジニアが知っておきたいIT業界の仕組み
わが社は、なぜ頂点を、せめて少しでも上のポジションを目指さないのだろうか――IT業界解説シリーズ、第2弾は「多重下請け構造」の闇に迫ります - スキルシート詐欺が起こるメカニズムとエンジニアマイナポータルの不具合、1円入札、COCOAのゴタゴタ──失敗の宝庫ともいえる政府ITの失敗と改善の歴史から、ベンダーマネジメントの勘所を学ぼうが取れる対処法
本当は持っていないスキルや経験を“盛って”しまうスキルシート詐欺。未経験や微経験エンジニアを襲う犯罪行為は、なぜなくならないのでしょうか
Copyright © ITmedia, Inc. All Rights Reserved.