人月ビジネスが先細りする中、SIer「共創」という言葉を使い、お客様との新たな関係を模索しています。
「共創」とは、2004年、米ミシガン大学ビジネススクール教授、C.K.プラハラードとベンカト・ラマスワミが、共著『The Future of Competition: Co-Creating Unique Value With Customers（邦訳：価値共創の未来へ-顧客と企業のCo-Creation）』で提起した概念と言われています。企業が、様々なステークホルダーと協働して共に新たな価値を創造するという概念「Co-Creation」の日本語訳です。
複数の企業が成果を共有し、新たな組合せを、組織を超えて創り出し、従来にない価値を生みだすことを目指す取り組みです。
本来の意味通りに「共創」という言葉が使われるかどうかはあやしいのですが、このチャートにある「共創型モデル」が、この業界における「共創」となるでしょう。
「受発注型モデル」の対象となるシステムをユーザー企業が作る目的は、コストの削減が中心になります。一方、「共創型モデル」は、収益機会の拡大や売上の増大などを目的とし、ユーザー企業の事業部門が主導して内製チームを組織して、システムを開発することが増えるでしょう。
内製にするのは、システムの開発や改善が自分たちの事業の業績に直結するからであり、顧客のニーズの変化に迅速に対応しなければならないからです。
もちろん、全ての人材を内製で賄うことは容易なことではありません。当然、ベンダー企業の協力を必要とするユーザー企業もあるでしょう。このようなニーズに応えるのが、ベンダー企業にとっての「共創」事業となるわけです。
「共創」に組みするベンダー企業は、ユーザー企業の「事業に貢献する」こと、あるいは「事業を成功させること」を目指します。注意しなければならないのは、「システムを作ること」を目指すのではないということです。内製チームの一員として、一緒になって「事業の成功」のために仕事をすることが「共創」です。つまり、要求に応じて「システムを作るための工数を提供する」のではなく、何をすべきかを一緒に考え、「事業を成功させるために自分たちのプロフェッショナリティを提供する」ことへと変わるわけです。これは、「工数を増やして収益を拡大すること」から「できるだけ少ないコードで事業目的を実現すること」への転換を伴います。
そのためには、アジャイル開発やDevOps、クラウドやサーバーレス、コンテナやマイクロサービスといった「作らない技術」が前提となります。そんな技術力や専門スキルを持つ人材でなければ、内製チームで役割を果たせません。従来のような企業の規模や組織力ではなく、個人力つまりバイネームでチーム・メンバーは選別されることになるでしょう。
「作らない技術」が、成熟してきたことで、小規模なIT企業や内製でも、システムを実装できる時代になりました。従って、大手SI事業者でなければできなかった「組織力で工数を集められる能力」は、その価値を失いつつあります。
「共創型モデル」は、スキルだけではなく、そのカルチャーも「受発注型モデル」と大きく異なります。
さらにDXレポート2.1が提言しているのは、その先にある「デジタル企業型モデル」へのシフトです。ユーザー企業とベンダー企業という区別を持たず、「各企業がそれぞれのデジタルケイパビリティを磨き、市場で売買しつつ、新たな価値を創出する中で成長していく企業」であり、それら企業が構成する産業を「デジタル産業」と呼んでいます。
社会全体でデジタル化が進む中で、企業はこの不可逆的な変化に適応し、データとデジタル技術を駆使して新たな価値を産み出すことが求められています。
「共創型モデル」を実践するための「8つの転換」
「共創型モデル」を実践するために必要な、「8つの転換」について説明します。
転換１：「工数で稼ぐ」から「技術力で稼ぐ」へ
ユーザー企業は、デジタルを前提に事業を創出し、収益機会の拡大や売上の増大などを積極的に推し進めようとしています。「共創型モデル」とは、この取り組みを支援することを目的としています。
この取り組みは、事業収益に直結すること、また、顧客のニーズの変化に迅速に対応しなければならないことから、ユーザー企業の事業部門が主導して内製チームを組織し、システムを開発することが増えると考えられます。
内製ですから、自分たちでエンジニアを雇用し、開発や運用をおこないます。クラウド・サービスやオープン・ソース・ソフトウエア（OSS）の普及、さらにはAI駆動開発の技術革新により、少ない人的リソースでも対処できる環境が整ったことで、内製するためのハードルは大きく下がりました。ただ、その前提は、クラウドやOSS、AI駆動開発ツールなどを使いこなし、少ないエンジニアであってもシステムを維持できる技術力です。
このために、多くの企業からも共通して期待されるのは、「アーキテクト」でしょう。アーキテクトは、経営とIT全体を見据えた全体の仕組みの設計者であり、システムの最終的な仕上がりを左右してしまうほど重要な存在です。例えば、次のような知識やスキルを有する技術者のことです。
- 事業や経営の基盤となるデータベースやトランザクション、ネットワークなどを設計できる
- アジャイル開発やDevOpsなどを運営できる仕組みを設計できる
- ITサービスやツールなどを目利きし実践の現場で使える仕組みを設計できる
- AI駆動開発やAIエージェントを使ったシステム開発環境を構築する
- AI前提の新しい開発や運用の仕組みを示現できる など
経営や事業の言葉が分かり、幅広いテクノロジーやサービスに精通し、なによりも、コンピューター・サイエンスやソフトウェア工学の基本をしっかりとおえていなければできません。内製をすすめる上での技術的基盤を確かなものにするために、要となる存在です。
他にもUXデザインやプロダクト・マネージメント、デザイン思考、データサイエンス、AIなど、お客様が内製するために必要となるスキルやノウハウは、いろいろあります。
それぞれの専門に長じた人材は、限られています。だからこそ、必要とされているのです。そういう人材が、お客様主導の内製チームで、指導的立場あるいは教師として、お客様にスキルをトランスファーすることで、お客様自身の知識やスキルを底上げし、内製力を向上させることが求められています。そこに、大きな潜在的な需要があるわけです。
SIerであれば、多くのプロジェクトで様々な知見を得る機会に恵まれますから、これを活かしてスキルやノウハウを積み上げることができれば、ユーザー企業にはできない高い専門性を手に入れ、これを提供することができます。ここに事業機会を見出すことが可能となります。
転換２：「工数を増やす」から「エンジニアの単価を上げる」へ
収益を拡大するには、「工数を増やして売上を増やし、結果として、利益を増やす」というのが、SIerのこれまでの収益拡大のシナリオでした。単金を上げることも収益の拡大につながりますが、クラウドや自動化、AI駆動開発の台頭、事業者間の厳しい価格競争もあり、単金の値上げ交渉は、容易なことではありません。
そこで、転換１で述べた高い技術力を提供し、「高くてもいいから是非とも仕事を頼みたい」という利益率を高くできる案件を増やすことです。
「売上を増やして、結果として利益を増やす」のではなく、はじめから「高い利益率で単金を設定し、収益率の高いビジネスを目指す」ことです。
こういう事業戦略を実践するには、「技術力の高いエンジニア」の数を増やすことが必要です。そのためには、エンジニアに対しても高いインセンティブを提供することや組織体制の見直しも必要になるでしょう。また、「技術力の高いエンジニア」が積極的に情報を発信し、新しいことに取り組んでいる姿を示し、社外から向上心の高い人材を惹き付けることも、重要な取り組みとなります。
転換３：「規模を大きくする」から「スピードを上げる・付加価値を高める」へ
工数規模を拡大できないからといって、売上規模を諦める必要はありません。「共創＝内製化支援」のサイクルを早め、短期で成果をあげて、ひとつのお客様や案件を早期に離脱して、数多くのお客様や案件をこなしていくことです。
転換２で述べたとおり、単金は高いわけですから、さらに経験を積み上げてノウハウを蓄積し、生産性を高めて作業量を減らし、これを高速に回してゆくことで、結果としてビジネスのボリュームを増やしてゆくことができます。
もちろんその前提は、「高い技術力を持ったエンジニア」を集め、育ててゆくことです。
転換４：「結果を重視する」から「プロセスを重視する」へ
結果を軽視してもいいという主旨ではありません。結果は大切なのですが、内容を伴わないカタチだけの結果に終わらせないことを意識しなくてはなりません。例えば、QCD（Quality:品質・Cost:費用・Delivery:納期）を達成するとして、CとDというすぐに分かるカタチを優先し、テスト項目を省いてQをおろそかにして、本番時にトラブルを招くなど、あってはならないわけです。
高い技術力を武器に内製化を支援するのですから、このような事態は致命的です。そこで、開発プロセスで品質を作り込むことを徹底して行う「アジャイル開発」は、その有効な手立てとなります。本書では、詳細は割愛しますが、アジャイル開発は、開発の過程で段階的に品質の積み上げることで、品質を保証する仕組みを内包しています。「なんちゃってアジャイル開発」ではなく、正しい手順あるいは正しいプラクティスを実践することで、バグフリーを実現する開発手法でもあります。
このスキルやノウハウを身につけることは、お客様の教師、あるいは指導者としての役割を果たす上でも重要になるはずです。
転換５：「マネージメントがQCDを管理し達成させる」から「実行者（チーム）がQCDを管理し達成させる」へ
これもまた転換４で述べたアジャイル開発の基本的なプラクティスです。アジャイル開発は、その名の通り「変化に俊敏に対応する」ことを目指した開発の考え方であり、これを実践する手法の総称です。そんなアジャイル開発を可能にするのは、変化を最も敏感に感じ取ることができる現場のチームに大幅に権限を委譲し、彼らに、即決、即断、即実行できる状況を提供しなくてはなりません。
だからと言って何をやってもいいと言うことではなく、彼らのやっていることの透明性を徹底して担保することが必要です。うまく行っていることも、直面する課題も、あるいは失敗も、つねにビジネス・オーナーやまわりの関係者に正直に、そしてリアルタイムに見えるようにしておき、彼らとの同じ情報を共有して対話しながら、すすめてゆくことができなくてはなりません。
転換６：「仕様書に合意し記載項目を100%達成する」から「目的やビジョンを共有しビジネス目的を達成する」へ
大切なことは、お客様の事業を成功させ、業績を改善することです。そのためならは、当初想定した仕様を変更することは、当然のことです。
変化が速く、将来の予測が困難な時代には、「変更などあり得ない完璧な仕様」など予め用意することはできません。もちろん、その時点で最適だと考えられる仕様を作ることは大切です。しかし、それはあくまで仮説であって、絶対ではありません。ですから、目的やビジョンをユーザーと徹底して議論して共有した後は、状況の変化に合わせて、目的やビジョンを達成するために合理的かつ最適な仕様へと変更することができなくてはなりません。
このようなやり方は、「ウオーターフォール開発」の前提である「仕様を確定し凍結してから開発する」やり方では難しく、業務プロセス全体を重要度に応じて細分化し、その細分化された業務プロセスごとに開発サイクルを回してゆく開発の考え方と手法である「アジャイル開発」が有効な手だとなります。
転換７：「監視と管理で規律を保つ」から「相互のリスペクトと心理的安全性で創造性を促す」へ
心理的安全性とは、「チームの他のメンバーが自分の発言を拒絶したり、罰したりしないと確信できる状態」のことです。言い換えれば、「プロ同士が、安心して全力で、知的殴り合いができる状態」と言えるでしょう（詳細は、本章のコラムで解説していますので、そちらをご覧下さい）。
内製化支援は、新たな収益機会を生みだすことが、主たる任務であるとすれば、創造性は、絶対の要件です。その能力を高めのためにも、心理的安全性は、チームの土台に据えなくてはなりません。
転換８：「失敗をさせない」から「失敗から学び、それを共有する」へ
内製化支援は、新しいことへのチャレンジを伴います。失敗は、つきものです。また、ビジネス・スピードを上げるには、アイデアが湧いたらやってみて、その結果から議論して、改善を積み上げ、その時々の最善を維持しなくてはなりません。
不確実性が高い時代には、石橋を叩いても確実に成功する保証はありません。ならば、いち早くやってみて、失敗か成功かを確かめて、失敗ならば直ちに修正してやり直す、成功ならば、これに磨きをかけてまたやってみる。これを繰り返すしかありません。
これを、小さなビジネス・プロセス単位で、高速に繰り返し実践することが必要です。その結果、失敗は、学びのサイクルに組み込まれてゆきます。単位が小さく高速に回せますから、仮に失敗しても大きな痛手を回避することができるので、失敗を許容しやすくなります。
失敗からは、成功以上にたくさんの学びがあります。つまり、失敗すればするほどに学びの加速度は増してゆきます。
SIerがお客様に対してDXの看板を背負う以上は、自らもまた変革に立ち向かわなくてはなりません。そんな現実を考える上で、この「８つの転換」が、自分たちの実践を考える上でのたたき台になればと願っています。
【図解】これ1枚でわかる最新ITトレンド・改訂第5版
生成AIを使えば、業務の効率爆上がり？
このソフトウェアを導入すれば、DXができる？
・・・そんな都合のいい「魔法の杖」はありません。
神社の杜のワーキング・プレイス 8MATO
8MATOのご紹介は、こちらをご覧下さい。
