ソフトウェアファースト第2版

バブル経済崩壊後の日本における「失われた30年」の間に、こうした日本市場の軽視、あるいは無視が増えていきました。筆者は、日本の国際競争力の低下を防げなかった戦犯とも言える世代の１人なのだと自覚しています。

プロダクトマネジメントとは、プロダクトを成功に導く仕組みや考え方であり、プロダクトマネジメントを実践する組織では、専門職としてプロダクトマネジャーというプロダクトの責任者が存在しています。 　プロダクトマネジメントにおけるプロダクトとは、顧客の課題を解決したり、顧客に新たな価値を創出するものです。その定義に基づくと、私たちの身の周りにある多くの営みは、プロダクトとして捉えることができます。

新規事業開発を成功させるには、その事業でのビジョンの明確化、リーダーシップの発揮、そして、必要な専門能力の獲得が不可欠です。いずれか１つが欠けていたら新規事業はうまくいきません。

さて、ＤＸではどうでしょう？ ＩＴやデジタルの話になった途端、「私はＩＴの専門家じゃないから分からない」と思考停止し、あるべきものを見失ってはいないでしょうか。ＤＸに失敗している企業は、ＤＸに取り組む強い意志とビジョン、組織全体の協力体制や文化の醸成、それを率いるリーダーシップ、知見に基づいた技術的スキル、そして主体性──これらのどれか、もしくはいずれもが欠如しています。 　つまり、ＤＸに失敗する企業には、「ＤＸとは何か」への基本的な理解が不足しているのです。ＤＸとは、単にデジタルを活用することでも、新しい技術を導入することでもありません。ビジネスモデルや業務プロセスを根本的に見直し、デジタル技術を活用してこれらを変革することです。

ハーツの失敗は、ソフトウェアファーストな体制と適切なプロジェクト管理の重要性を浮き彫りにしています。まず、プロジェクトマネジメントをＳＩｅｒに「ほぼすべて委託したこと」。これだと事実上の丸投げで、効果的な監視や指導が行われず、プロジェクトが軌道から外れる原因となりました。外部の専門家の力を有効活用するのは大切ですが、最終的な意思決定は自社で行うべきです。 　また、「使用された技術の適切性」も疑問視されています。これもＳＩｅｒに一任するのではなく、ハーツ自身が技術選定に関与し、適切なアドバイスを受けつつ、自社のニーズに合わせて最終決定を下すべきでした。 　アウトソーシング先のスキルセットと経験を「正しく評価すること」も、このプロジェクトからの重要な教訓です。ハーツは、プレゼンテーションでの印象にとらわれず、ＳＩｅｒのチームの質を十分に調査するべきでした。また、定期的な評価とフィードバックを行い、提供されるサービスが契約通りであることを継続的に確認し、問題が発生した時点で迅速かつ適切に対応できる体制を整えておくべきでした。

図2-2：日米欧のソフトウェアに対する考え方の違い

日本企業: “標準化された設計パターンに従い、元の条件からはほとんど変更しないカスタムまたはセミカスタム・アプリケーションの複数バージョンを大量生産するのに向いており、現在も活躍している。（中略）しかし、それが世界を変えることはないし、だれかが大富豪になるということもない”

米国企業: “米国人ほどソフトウエアをビジネスとして捉えている国民はほかにはいまい。（中略）会社を作って「まあまあ良質」の製品を作り、業界標準を打ち立て、その過程で大儲けしようとしている”

欧州企業: “製品をマス・マーケットに出荷して、自分たちの素晴らしい技術からなるべく多くの利益を生み出そうとするよりも、むしろソフトウェア設計における美を達成することに多くの力を注いでいる”

ソフトウェア開発では、設計と開発を一体として捉え、「行きつ戻りつしながら」進めることが求められます。このアプローチにより、現実の技術変化と市場のニーズに即した柔軟な対応が可能になり、より適切な製品開発が行えるようになるのです。

このような一部の極端なユーザーに限って、「声が大きい」ことです。満足しているユーザーは、わざわざ声を上げて満足していることを表明しません。サポート窓口に連絡してくる人や、ソーシャルメディアで感想を言う人の多くは、不満を持つ人です。このようなユーザーを「ボーカルマイノリティ」と呼びます。この状況だけ見ていると、つい批判的な意見が大多数なのだと勘違いしてしまうものですが、その声に惑わされないように意識して、ターゲットとなるユーザーの声に耳を傾ける必要があります。

ジョブ型雇用に対して、決められた仕事しかしない人が増え、隣に困っている人がいても気にしないような組織になるという懸念を持つ人がいます。しかし、筆者がいた組織では、そのようなことはありませんでした。この懸念については、チームスポーツにおける各プレーヤーの役割と同じように考えると良いでしょう。 　例えば、野球。守備中なら、自分の守備範囲を超えた場合でも、勝つためにはボールを追います。サッカーでも、自分のポジションがオフェンス（攻撃）であっても、ディフェンス（守備）を一切しないプレーヤーは登用されないでしょう。チームの目的（勝利）のためには、必要に応じて主な役割を超えて動くことが欠かせないのです。

１つは、事業会社側がＩＴをなぜか特別な技術と思い込み続けていることです。事業の成長に不可欠な新しい要素があれば自ら学んで活用するのに、ＩＴになった途端にそのような発想をしなくなり、専業のＩＴ企業に委託してしまうのです。また、それが成立するほどに日本のＩＴ業界が成長し、機能し続けてしまったというのも要因の１つでしょう。さらには、ＩＴ業界が製造業の構図を模倣した多重下請け構造で案件を回すようになり、事業会社がこの多重下請け構造化した「コミュニティ」に入っていくのが難しかったという点も挙げられます。

これを筆者は二階建てモデルと呼んでいます。製品は汎用性を持つものにし、できるだけ個別カスタマイズ不要なものとします。これが一階部分です。この一階部分はそのままで多くの顧客に使われることを目指します。これで営業利益率が上がります。一方で、顧客は汎用製品をそのままの状態では使えないことも多く、自社の事情に合わせたカスタマイズが必要です。ここが二階部分です。

ＤＸを進めることで、ＩＴリテラシーの低い人がついてこれなくなることを心配する声が上がるかもしれません。確かに、急速に高齢化が進む日本においては、技術に疎い人が多数派を占める場合もあるかもしれません。リテラシーの低い人を見捨てないという意味で「誰一人取り残さない」というフレーズが使われることもあります。確かにこの考えは重要ですが、学ばない人に逃げ道を作るための免罪符になってはいけません。

一般的なソフトウェア開発では、なぜ作るのか（Why）、何を成すべきか（What）を考えるのは事業サイドの企画職やプロダクトマネジャーの役割だとされています。その意向を受けてどう作るか （HOw）を考え、実装するのがソフトウェアエンジニアの役割です。これはこれで、役割分担を明確にしてスピーディーに開発を進める

やり方ですが、分業が進み過ぎるとソフトウェアエンジニアがHowしか考えない存在になってしまいます。その行き着く先が、企業の情報システム部門が経営陣と外部委託先との間で調整役にしかなっていないという状況を生んでいるように思います。

星野リゾートの場合、エンジニアは星野リゾートの目指す世界観に共感し、高いモチベーションで働いています。彼らの多くは自身の旅行体験から課題意識を持ち、それを解消するアイデアを持っています。つまり、自らがプロダクトのユーザーであり、当事者として課題を捉え、解決策を提案しているのです。これが顧客ニーズに迅速に対応できる要因の1つとなっています。さらに、星野リゾートのシステム開発チームは、現場経験者とエンジニアの混成チームです。この構成により、現場の具体的な課題を的確に捉えたシステム開発が可能となっています。現場と開発の連携を強化し、理想的なプロダクトチームを実現しているのです。

詩人のW・1・オーデン氏が言うように「見る前に跳ぶ」ことが必要なのです。