DXレポートにも書かれていた「外部ベンダーとの共創」。
「ベンダー」なので SIer へのオーダーが増えているのかと思いきや、どうやらコンサルが共創パートナーとして選ばれる傾向があるようです。
SIerはいまのお客の業務を知ってるし、現状をプラスアルファしていくというプロジェクトにおいては独壇場だった。でもDXって全部ぶっ壊してもいいじゃないですか。そうすると、お客はこれまで頼んでたNTTデータとか富士通とかNECとか日立製作所とかのSIerにいかないで、コンサルと一緒に新しいシステムを立ち上げるとかになりやすいです。
ダイヤモンドオンライン「DX狂騒曲 座談会総論1」
待ってください。
SIerをDXの共創パートナーにしないという判断は正しい。
ですが、共創パートナーに適しているのはコンサルではありません。
コンサルでは、アジャイル開発がうまくいかないからです。
その理由と、適切な共創パートナー会社をまとめました。
理想は、共創パートナーが不要な状態
DX・内製は本来、自社で雇用したエンジニアで完結することが望ましい。
DX・内製の基本となるアジャイル開発は、エンジニアと二人三脚で進めていく開発手法だからです。
また、自社で進めないとデジタル知見が蓄積していきません。ところが従来のシステム開発と同じく、DXをコンサルに丸投げしているケースが多発していると聞きます。多くの企業を担当しているコンサルは、一社一社に時間をかけることができません。コンサルに丸投げしていては威力半減。やはり、自社で回していく、が基本になります。
ですが、自社でエンジニアを採用し切るのは極めて困難。
DX・内製についていけるエンジニアは30人に1人です。日本にはエンジニアが100万人いると言われてますが、適切なエンジニアは3万人もいない状況です。その3万人をみんなで奪い合っている。1人のエンジニアに、200通以上のスカウトメールが一斉に送られてくる。
いえ、間違えました。
転職市場に出てくる人の割合は9.5％と言われるので、2850人を200企業以上が奪い合っている。
さらに、間違えました。
200企業中半分以上が紹介会社なので、実際は数千単位の企業で奪い合っているわけです。この競争率は嵐のライブチケット並みです。例えが古いですが。
さらにさらに、絶望的な事実があります。
優秀なエンジニアほど、数年以内に転職します。
エンジニアとは、次々と会社を移ることでスキルと実績を高めていくスキルワーカーです。優秀な人ほど、同じ会社で同じ仕事を繰り返すことなどありえません。逆に、転職しないエンジニアはサラリーマンエンジニアなので採用するほどの人ではなかったり。有名IT大手ですら、この優秀エンジニア転職問題に頭を抱えています。
こうした背景をふまえ、DXレポートに「外部パートナーとの共創が重要」と”仕方なく”書かれているわけですが、海外企業をモデルとするならば同じ社内で、エンジニアとビジネス側の人間が切磋琢磨する状態こそが理想です。
開発会社でなければDXはきびしい理由
DX共創パートナーに適しているのは、SIerでもコンサルでもなく、ソフトウェア開発会社です。
ただし、みなさんがイメージされる「SI業界の下請けソフトウェア開発会社」ではありません。「SI業界の下請けではなく、ユーザーと対等なパートナーとして仕事ができるソフトウェア開発会社」です。
なぜユーザーと対等なパートナーとして仕事ができるのか。優秀なエンジニアが集まるからです。優秀なエンジニアというのは、冒頭お伝えした、30人に1人のエンジニアのことです。結局、DX・プロジェクトがうまくいくいかないは、優秀なエンジニアが参画しているかどうかにかかっています。
ではなぜコンサルよりも、優秀なエンジニアがいる開発会社の方が良いのかお話していきます。
コンサルが入ると、アジャイル開発がうまくいかなくなる
大前提DXは、アジャイル開発が機能しなければうまくいきません。
アジャイル開発とは、専門的には「大きな単位ではなく、小さな単位で実装・テストをくりかえし開発を進めること」と説明されていますが、重要なのは、エンジニアとユーザーが直接話合いながら進めていくことです。「エンジニアとユーザーが直接話をしながら、作っては見せ、作っては見せ、提案・相談を繰り返しながら開発を進めること」です。言葉で話し合うより、作ってはモノを見て話しあったほうが早く進む、ということですね。
ここに、コンサルが入ってくると「エンジニアとユーザーが直接」がなくなります。
コンサルがシステム開発にくわしい場合、コンサルが入ってもあるいは成立するかもしれません。ですが、往々にして、コンサルはシステム開発に疎いです。システム開発に疎いということは「実現不可能なシステム像」をまとめあげてしまうということです。過去のさまざまな炎上事件が報道されましたが、元凶はまさにこういうことです。
なぜコンサルはシステム開発に疎いのか。理由は、
●コンサルが、エンジニア出身ではないことが多いから
●SEをITコンサルと言い換えていることも多く、上流経験のみで開発経験がないこともよくあるから
つまり、上流経験がメインだった人がコンサルになっているからです。エンジニアからコンサルへの転職を考える人もいますが、結局なれなかったり、仕事内容の違いから途中で辞めてしまったりするパターンが多いようです。
また、有名コンサルティングファームのエンジニア採用も激化しており、1年経験があれば採用しているという話も聞いたことがあります。開発経験は少ないでしょう。
そもそも、コンサルとエンジニアは仕事内容がまったく異なります。「エンジニア出身の人の資料は、手直しだけで一日かかる」とコンサルが言っていたというエピソードを聞いたことがあります。エンジニアはシステム開発のプロ。コンサルは資料作成のプロです。
社内意見を通していくためには、資料は重要です。ですが、しっかり資料を作りこみ、社内承認を得て、1ヶ月後開発が進みはじめるという仕事の進め方ははたしてアジャイル開発でしょうか。ちがいます。
「顧客のニーズに即座に対応する体制をつくる」とDXレポートにあるように、スピーディーな変化対応力を持つ企業を作っていくことがDXの目的です。そのために、不完全な状態で市場にリリースし、フィードバックを得て改良を重ねていくアジャイル開発が必要と言っているのです。
補足として、コンサルがまったく不要ということではありません。上記図の左：コンサルは、顧客のニーズ・市場変化の影響をそこまで受けない大型基幹システムの開発においては有効です。また、企業のビジネスモデルや戦略の見直しにおいても有効。ですが「どういうシステムを作るべきか」というところまで密接にコンサルが関わってくると、アジャイル開発は崩れてしまいがちです。
優秀なエンジニアがいれば、コンサルは不要
そもそもDXのモデルとなる海外企業は、ユーザーとエンジニアの間にコンサルは存在しません。エンジニアがコンサルと開発、両方担当しているからです。コンサルと開発の線引きがない、というほうが正確かもしれません。アジャイル開発によって、エンジニアはユーザーと柔軟にコミュニケーションを重ねながら開発を進めるため、コンサルの必要性がうすいのです。
ちなみに「優秀なエンジニア」の定義ですが「ビジネスの要件を、システムの要件に変換できるエンジニア」のことを指します。対する普通のエンジニアは「決められたシステム要件通りにプログラミングを組むエンジニア」のことを指し、海外では「テクニシャン」と呼びエンジニアとは区別されています。日本のエンジニア、SE・PGの多くはテクニシャンであり、優秀なエンジニアは30人に1人くらいの割合。おそらく3万人ほどしか存在しません。
つまり、システムを作るテクニシャンはたくさんいる。が、ビジネスの要件をシステム要件に変換できるエンジニアが不足している。そのため、コンサルに需要が集まっているわけですが、ここまでお話した通り、そもそもビジネス要件の変換はエンジニアの仕事の範囲内。優秀なエンジニアであれば対応可能であるため、そこにコンサルが割って入ること自体ちがうのです。
SEの定義についてくわしく書かれている「SEを極める50の鉄則 (日経BP社)」にも、
具体的な例を挙げれば、BPR (ビジネス・プロセス・リエンジニアリング) を含めた業務分析やシステムの要件定義を担うコンサルタント、新たなアプリケーションを動かすシステム基盤の要件を決めて、設計・導入作業・プロジェクト管理を請け負うシステム系のコンサルタントやエンジニアなどを指す。プログラマは除くことにする。
SEを極める50の鉄則 著者 馬場史郎 出版社 日経BP社
と書かれており、明確に「プログラマで終わらない、コンサル領域も含まれた職業」であることを示唆しています。
DXをリードするエンジニアベンダー
上記記載のような優秀なエンジニアがいれば、本当にコンサルは不要なのか。
実際、エンジニアとユーザーが直接仕事をする開発会社の一つである情報戦略テクノロジー社は、数々の国内有名大手の対等なパートナーとして実績を積み上げています。
●セブン銀行の内製体制を構築＋1週間でゼロトラストな開発環境を実現
https://atmarkit.itmedia.co.jp/ait/articles/2009/29/news003.html
→同内容が「日本のDX最前線 インターナショナル新書」にも掲載
●某大手企業の外部依存体制を2年で解消、技術的負債を3年で返済、セキュリティ機能部門を発足など、エンジニアが主体となりDXを推進する事例が多数
機密情報の関係上すべての取引先を社外公開していませんが、情報戦略テクノロジー社はすでに日本のITを担う有名大手の重要部分に関わっています。エンジニアがエンジニアの領域に留まらず、ユーザー企業のエンジニアの育成を行っていたり、出向社員というカタチでユーザー担当者の代わりにプロダクトマネジメントを行っていたり、まさにDXをリードする動きを取っています。
情報戦略テクノロジー社のエンジニア曰く、
「提案資料の質はコンサルに負けますが、提案内容はコンサルもエンジニアも変わりません。実現性を考えると、エンジニアの提案のほうが確実な分、手戻りが発生せず開発の進みが早くなります。提案資料づくりにかける時間を開発に回せる分、エンジニアを二人三脚でやっていく方が早く、コストもかかりません。」
とくにアジャイル開発においては、エンジニアと二人三脚でやっていかないとフットワークが軽くならず、アジャイル開発の良さが消えていってしまうでしょう。
問題は…共創できる開発会社が少ないこと
ここまで、DXの共創パートナーに適しているのは、優秀なエンジニアがいる開発会社であるという話をしてきました。
ただ問題は、その優秀なエンジニアがいる開発会社を見つけることは非常にむずかしいということ。まず、日本には2万数千社の開発会社が存在しますが、その中から数えるほどしか存在しません。また、各社とも自社に所属するエンジニアの情報は社外に公表しないようにしています。他社に引き抜かれてしまう可能性が出てきてしまうからです。ことさら「優秀なエンジニアがいるかどうかで」さがすのはむずかしい。
ということで、私たちが知りうる範囲で共創パートナーに適している開発会社をピックアップしました。
共創できる開発会社6選
私たちがよく知る300社の中からピックアップした6社です。
割合で言うと2％と少なめ。上流からできる開発会社のほとんどが大手SIerだからです。業界には2万7千社存在すると言われているので、SI業界全体では約500～600社は存在する可能性もあります。
ピックアップの基準は、
●ユーザー直の取引実績を持つこと
→一定以上の信用がなければユーザー直で取引する事はできない
→ユーザー企業の子会社との直取引は実質「二次請け」のためカウントしない
●対等なパートナーとして入っていること
→ユーザー企業の中で「テクニシャン」として動く開発会社はカウントしない
ユーザー直のプロジェクトでよく見かける開発会社をピックアップしているので、概ね間違えていないと思いますが、もし上記条件に当てはまる開発会社をほかにもご存知でしたらぜひ教えて下さい。
株式会社テコテック
FinTechサービスをはじめ、NFT発行・開発支援、ブロックチェーン技術を用いた暗号資産の取引システムや、決済認証システム、ソーシャルゲームの開発までを手掛ける開発会社。
株式会社SP
スマホ・業務用iPadアプリ等、企画・開発・運用まで一社一貫でのサービス提供。インバウンド対策にも注力し、海外向け広告の作成・翻訳・運用も行っている。
株式会社Sekappy
エンタメ系エンドユーザー取引多数。カードゲーム好きが集まって出来た会社でゲーム同様仕事でも、クライアントも含め共に活動する仲間への経緯と信頼を大切にするスタンス。
株式会社情報戦略テクノロジー
「0次システム開発」を標榜し、日本のシステム開発のあり方を再構築している開発会社。セブン銀行の内製体制構築をリードするなど、メディア掲載歴多数。
株式会社こだわり
行動指針「KODAWARI PRIDE」を掲げ、クライアントとの二人三脚での仕事を強く意識し【提案型】の考えを基本としお客様と直接向き合っていくことに価値を置き実績を重ねてきている。
Fabeee株式会社
「そろそろ、ITをわかりやすく。」専門用語を使わずクライアントと共に伴走することを標榜するソフトウェア開発会社。AIにくわしいCTOや、DXを推進するコンサルタントも在籍する少数精鋭開発企業。
まとめ
ここでピックアップさせていただいた開発会社の多くは、元々SI業界の下請け企業でした。ですがSIの下請けでは、大型基幹システムの受託業務しか仕事が得られません。レガシーな技術経験しか積めない・アジャイル開発を実行することができない・ユーザーと直接コミュニケーションが取れないなど、エンジニアにとっては成長できない牢獄です。そんな状況からの脱却を決意した結果、優秀なエンジニアが集まる会社へと変貌を遂げています。
もう一点重要なのがミッション。エンジニアが共感するミッションを掲げ、それを遂行する企業だからという理由で優秀なエンジニアが集まっているという側面もあります。エンジニアは、企業の大小関係なく、共感できるミッションを持つ会社かどうかを見て転職を決める傾向にあります。
冒頭お伝えしましたが、DX・内製体制は、自社雇用のエンジニアで完結していくことが一番理想的です。つまり、優秀なエンジニアが集まるような会社にしていくこともDXであり、そのためにはまずミッションの見直しからはじめるというのも一つのやり方かも知れません。
執筆者
リビルダーズ編集部
