内製開発に必要なのは、エンジニアではなく“Engineer”


2021年12月06日  更新

稲葉徹(情報戦略テクノロジー) 山川大志(情報戦略テクノロジー)

ユーザー企業だけでは賄えない部分をベンダーが支援する「共創型内製」が増えてきている。

その際のパートナー探しには、アウトソース時とは異なるポイントがあるという。

 システム開発の必要性が生じたときに、社内の技術者のみで完結させることを「内製」といい、ビジネスが変化するスピードが速くなっている昨今、外部ベンダーへのアウトソースから内製化に舵(かじ)を切る企業が増えています。しかしエンジニア不足の折、完全な内製が実現できる企業は数えるほど。外部ベンダーと「共創」で内製を進める企業が大半でしょう。

  そして、そういった企業の多くが、現状、大手ベンダーを内製パートナーとして選んでいると思います。ですが、大手ベンダーの傘下に「内製支援に対応できるエンジニアはほぼいない」ということはご存じでしょうか。 

日本のデジタル化を妨げている3つの要因



日本のSEが、海外でいうところの“Engineer”に該当するのですが、実態はその多くが“Technician”です。ちなみに“SystemEngineer”は和製英語で、海外にSEという職業は存在しません

海外の“Engineer”と、日本の「エンジニア」

 まず、「日本のエンジニアの多くは、海外の“Engineer”とは別物である」というお話をさせてください。 海外の定義では、日本のIT技術者(SE、PG)の多くは、“Engineer” ではなく “Technician” という存在です。 

        参考リンク    技術者教育認定制度が目指すもの (電子情報通信学会)

海外で定義する “Engineer” は、「高度な知識を持ち、ビジネスサイドと対等にコミュニケーションを取りながら知識を応用し、デジタルビジネスを創っていく人のこと。

ビジネスサイドと共に、どうすれば最善のシステムが作れるか考え、ときに提案し、ときにいさめ、場合によっては反論も辞さない「ものいう技術者」です。 

  対する “Technician” は、「“Engineer” 指示を受けてシステムを作る人」です。

開発だけ担当する技術ベースの人で、途中でシステムが失敗すると分かっていても指示通りに動く従順な存在です。


上段は「POの指示通り作る受発注関係」なので、開発がうまくいくかどうかはPOの技術知見レベル次第。下段は「“Engineer”がビジネスサイドと技術サイドの間を取り持ち、コミュニケーションを取り合いながら作るパートナー関係」なので、POの技術知見レベルを問わず開発がうまくいく確率が高くなります。“Engineer”が、PCのOSのような翻訳者としての役割を果たしています

  ビジネスサイドと技術者サイドがコミュニケーションを取り合って作っていくことが大前提である内製は、“Engineer” と一緒にやっていかなければ、うまくいきません。

  過去に多くのシステム開発が失敗してきた要因も、根本は技術知見がないエンドユーザーのプロダクトオーナー(PO)と“Technician”の間に “Engineer” がいないことが要因でした (COCOA の場合は、“PO”と“Engineer”の間に大手SIerがいて分断されてしまったことが失敗要因だったようですが)。

システム要件が最初からカッチリ決まっている場合は、開発だけ技術担当者に依頼すればいいので、プロダクトオーナー(PO)と “Technician”だけでうまくいくこともあります。

しかし、システム要件が決まりきっていない、開発しながら決めていく場合は、POと“Technician”の間に “Engineer” が必要です。 

 基幹システムのような、要件通りに開発していくシステムに適しているのは “Technician”

ビジネス変化に対応しながら開発していく、完成後も永続的に改善し続けていく内製スタイルに適しているのは “Engineer” です。


* 日本で“Engineer”が育たないメカニズム

 “Engineer” は「ビジネスサイドと提案相談しながら創造する技術者」、対して “Technician” は「提案相談はせず、製造に専念する技能者」という言い方もできます。

  なぜ “Technician” は提案相談しないのでしょうか。理由は大きく2つあると考えます。

 a. 経験が少ないから

 b. 提言しようにも権限がない、もしくは聞いてもらえないから

 これらの要因の一つが、システムインテグレーション業界の多重下請け構造です。 

多重下請け構造とは、大手SIerを頂点としたピラミッド構造です。

 一次請け企業がエンドユーザーと要件の整理、二次請け企業が要件に合ったシステムの設計とプロジェクト管理、三次請け以降が二次請けの指示に従って開発を行う仕組みになっており、エンジニアの多くが三次請け以降に所属しています。

つまりエンジニアは、一次請けのコンサルやベンダーが固めた仕様の通りシステムを作ることが仕事です。

  

エンジニアは三次請け以下に所属。上流企業が決めた通りに作る“Technician”化しています。

システムインテグレーション業界は日本国内に2万7000社以上あるといわれていますが、一次、二次請け企業は数えるほどしか存在せず、その多くが三次請け以降です 

             関連記事  多重下請け構造であえいでいるエンジニアが知っておきたいIT業界の仕組み


【参考】多重下請け構造であえいでいるエンジニアが知っておきたいIT業界の仕組み

三次請け以降の位置にある企業に勤務しているエンジニアの悩みは、どのようなものだろうか。

人それぞれではあるが、典型的なものは「手掛けるフェーズが限られていてキャリアアップを図りづらい」「上の商流のエンジニアと同じ業務を手掛けていながら給与が低い」といったところではないだろうか。

 例えば、システム開発における上流工程である方式設計、要件定義、基本設計といったフェーズは元請けが行い、詳細設計以降フェーズ詳細設計~コーディング~テストは下請けに発注するのが一般的だ。

すなわち、三次請け以降にいる限り、要件定義はおろか、基本設計すら手掛けるチャンスは巡ってこない可能性があるのだ。

また、企業は自社に委託された業務を自社のエンジニアだけで賄えればいいが、足りない分はさらに下請けの企業から調達する。

そうなると、同じ現場で同じ仕事をしているにもかかわらず、中間マージンが抜かれている分、会社が受注する単価が安くなる。

必然的に、そこで働くエンジニアの給与も低くなってしまう。 


 三次請け以降の企業が多重下請け構造全体の9割以上、2万数千社存在するといわれており、a.パターン(経験が少ない)の人の受け入れ場所としてなっています。

 また、最初は “Engineer” として成長していきたいと願っていた人が、三次請け以降に所属することで b.パターンになってしまうこともあります。

システム開発に真摯(しんし)に向き合い、おかしいところはおかしいと提言しても、このような構造であるため、提言がエンドユーザーや一次請け企業に届かず、届いたとしても返事が返ってくるのが数カ月後ということもザラです。

“Engineer” の目がどんどん死んでいき、“Technician” として要望通りのモノを作る人になっていくのは必然です。

  エンジニアの 約8割がシステムインテグレーション業界で働き、その多くがいわれた通りに作る “Technician” になっているというのが、日本の現状です。 

Copyright © ITmedia, Inc. All Rights Reserved.


メール・BLOG の転送厳禁です!!  よろしくお願いします。