ソフトウェア開発を「製造」と呼ぶな

どうも、エンジニアのgamiです。

最近、じっくり時間をかけて読んでいた『ソフトウェア・ファースト』という本を読み終えました。

昨今、「すべての企業がIT企業になる」とか、「DXが必要」とか盛んに言われています。そんな言説に対して正直ピンと来ていない、そんな人に対しておすすめするにはとても良い本でした。

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略

中でも、製造業とソフトウェアのモノづくりに関する比較が印象的でした。DXが語られている文脈でも散々言われているように、新しい技術を受容するには、ビジネスモデル、業務プロセス、組織も含めてその技術を前提としたものに変革する必要があります。その変革について、製造業とソフトウェアの違いを紹介する中で明らかにされていきます。

今回は、『ソフトウェア・ファースト』の内容を土台に置きながら、「すべての企業がIT企業になる」とはどういうことかについて考えます。

インターネットに常時接続されたソフトウェア

まず、「すべての企業がIT企業になる」というときの「IT」とは何かについて考えます。といっても、ITの定義について今更語りたいわけではありません。『ソフトウェア・ファースト』というタイトルからも分かるように、すべての企業が受容すべきITとは、（今のところは）主に「ソフトウェア」に関するテクノロジーです。

さらに『ソフトウェア・ファースト』で度々語られているように、そこで想定されているソフトウェアは、どちらかというとスタンドアローンで動くインストール型のパッケージソフトウェアではありません。Webアプリケーションとしてインターネットを介して利用されるSaaSのようなソフトウェアです。ただし、本書では割と「SaaS」と言い切っていますが、SaaSという言葉は主にBtoBのソフトウェアについて使われます。このnoteでは、広く「インターネットに常時接続した状態で使われるソフトウェア」としておきます。

ちなみにこの「インターネットに常時接続した状態で使われるソフトウェア」というのは、「デジタル」という言葉が持つニュアンスともとても近いと思います。

最近の「デジタル」という言葉は「コンピュータが扱える領域をリアルワールドにもっと広げていくための技術や活動」という意味を帯びている

多様で日夜変化する現実世界の細部にまでコンピュータが扱う領域を広げるなら、柔軟に形を変える "ソフト" ウェアが主役になるのは納得です。さらに現実世界が物理的につながっているように、ソフトウェアを使うデバイスもインターネットに常時接続され細かくデータを送受信することになります。

蒸気エンジンから電気モーターへ

ということで、DXの文脈で多くの企業が受容すべき新しいテクノロジーとは、「（インターネットに常時接続した状態で使われる）ソフトウェア」に関するテクノロジーでした。日本企業よ、ソフトウェアを活用してDXしよう。

一方で、「受容すべき対象がわかったら自社のビジネスモデルや業務プロセスや組織をどう変えればいいのかもすぐにわかるよねー」とは普通なりません。一般的な感覚としては、「スマホのアプリとかは使うけど、ソフトウェアが自社をどう変革するかは想像もつかない」という感じじゃないでしょうか？

こうした「新技術を企業や社会がどのように受容するか？」みたいな話については、最近読んでいる『未来を実装する』という本が最高だったので合わせて紹介します。

『未来を実装する』によると、今では当たり前に使われている「電気」という新技術が社会にちゃんと受容されるまで約50年かかったと書かれています。

電気の需要にとって特に重要だったのは、それまで蒸気エンジンで動いていた工場が電気モーターをフル活用できるようになるための変化でした。面白いのは、電気を最大限活かすための工場とは、「巨大な蒸気エンジンがあった場所に代わりに巨大な電気モーターを置いただけの工場」ではないということです。そうではなくて、電気モーターの利点を活かすためには工場のレイアウトや作業の仕方自体を変革する必要があったといいます。

電気モーターの場合、蒸気機関と違ってエネルギー消費量の多い機械を動力源の近くに置く必要もなくなりました。その結果、従来の蒸気エンジンを中心に考える工場と比べて、全く異なる配置の工場設計ができるようになりました。これによって「流れ作業方式」と呼ばれる大量生産のやり方が確立したのです。ヘンリー・フォードは「機械を作業順に置くことができるようになり、作業の効率が2倍になった」と述べています。
（『未来を実装する』2. 社会実装とはなにか）

現代の日本で語られているDXの話も、これと全く同じです。新しい技術が登場したとき、その技術を活用するには単に技術力さえあればいいという誤解がされがちです。しかし実際に重要なのは、その技術のポテンシャルを最大限引き出すために、その技術の存在を前提とした仕事のやり方や組織のあり方に変えていくことなのです。

ソフトウェアと、ビジネスモデル

ここからは、「インターネットに常時接続した状態で使われるソフトウェア」の活用を前提とした場合に企業の何が変わるのかについて考えます。まあ要はDXに関して世の中で語られていることの全てなのですが、特に「インターネットへの常時接続」という観点を軸に改めて整理します。ここでは、主要な2つのトピックに分けて書きます。

まずわかりやすいのは、ビジネスモデルの変化です。ソフトウェア産業の中でも、お金のとり方がパッケージソフトの売り切り型からサブスクリプション型へ変化しています。

そもそも「使った分だけお金を払う」ということが実現できれば、ユーザーにも企業にもメリットがあります。ユーザーは安価で気軽に使い始めることができますし、企業もユーザーが長く使ってくれれば継続的な収益を得ることができます。

一方で、こうしたサブスクリプション型課金を実現するには、ソフトウェアを使う度に「このユーザーのサブスクリプションは今でも有効か？」というのを毎回チェックする必要があります。「インターネットへの常時接続」が当たり前になったことで、これが実現可能になったわけです。

また、フリーミアムモデルによるソフトウェアの提供も増えてきました。フリーミアムとは、見込み顧客に対してとりあえず無償で商品を使ってもらって、その利用データを元に有償化を促すというビジネスモデルです。これも、「インターネットへの常時接続」によってオンラインでいつでも課金を開始できるとか、ユーザーの利用データを常に得ることができるという前提の上に成り立っています。

ご存知のように、こうしたビジネスモデルの変化はソフトウェア産業以外にも波及しています。よく言われる「as a Service化」というのはまさにこの辺の話で、「所有」と「利用」を切り離し、「利用」の部分をサブスクリプション化し、ソフトウェアを介して課金管理をするというビジネスモデルが増えています。

「所有するのをやめる」という要素を含んだ事業やサービスも数え切れないほど登場しています。家電を所有せずに借りるRentio、洋服を所有せず借りるairCloset、家具を所有せずに借りるsubsclifeなど。これまで当たり前に所有していたものを、われわれはどんどん「シェア」で済ますようになっています。

ソフトウェアと、モノづくりのフィードバックサイクル

前述のように、インターネットへの常時接続を前提とすると、ユーザーの利用データを常に得られるようになります。この点については、『ソフトウェア・ファースト』でも製造業モデルとの大きな違いとして紹介されています。

利用データを最大限活用しようとすると、モノづくりの最適なプロセスも変化します。

製造業や初期のソフトウェア開発では、各工程を順番に進んでいき、前の工程に戻るということは滅多にありません。もちろん、販売した結果として売上やユーザーの反応がわかり、次の製品企画に活かされるということはあります。しかし、そのフィードバックサイクルが一周する期間は一般に長く、数ヶ月から数年はかかります。

一方で、「プロダクトをリリースして初めてわかること」というのはかなり多くあります。できればリリース後に学習した内容を開発にすぐフィードバックしてプロダクトに反映できた方が、ユーザーのニーズに応えたりコストを下げたりすることができます。インターネットへの常時接続を前提とした場合、リリース後の利用データを継続的に取得することができるので、「色々と作り込む前にまずリリースしてから改善し続ける」というプロセスを取りやすくなります。そこでは、利用データを元にしたフィードバックを前工程に対して日々かけていくことになります。このフィードバックサイクルを、最短で数時間から数日単位で回せるようになるわけです。

（『ソフトウェア・ファースト』より）

継続的に使われるソフトウェアの開発においては、一度リリースした後は工程を分けることはあまり意味を持たず、運用をしながら様々な粒度で企画、設計、開発が常にぐるぐる回っているという状態が合理的になりやすいです。一般に、「最初に自分たちが考えた最強のプロダクトを作り切ってしまう」という戦略は、とてもリスクが高いです。そうではなくて、利用データを元にした継続的な改善を前提にリリース戦略を組むことで、こうした大きな意思決定を分割し遅延させることができます。

逆に言えば、継続的に使われ日々改善が求められるソフトウェアをガチガチに工程管理して開発するような行為は、従来の工場の蒸気エンジンがあった場所にそのまま電気モーターを置くようなものです。新しい技術には、そのポテンシャルを活かすための使い方を適用する必要があります。もちろん従来の仕事の仕方のまま新しい技術を導入することは可能です。しかし、他社がより適した方法を採用しているとすれば、競合優位性はどんどん失われていきます。

なお、従来のソフトウェア産業以外でも、デバイスがインターネットに接続されていることで利用データが得られる例は増えています。たとえば僕が持っているWithingsの体重計は、乗る度にwifiに接続され体重のログがサーバーに送られます。もちろん、商品やサービスの中にハードウェアや不動産の提供が含まれる場合、全工程を数日単位でやり直すというのは難しいでしょう。一方で、なるべくソフトウェアで制御できる領域を広く持っておくことで、「意思決定を遅延できる」というソフトウェアの強みを取り入れることができます。たとえばテスラの自動車には定期的にソフトウェア アップデートが配信され、乗車体験が日々良くなっていくようです。

ソフトウェア アップデート

ソフトウェア開発を「製造」と呼ぶな

以上が、ソフトウェアを前提としたビジネスモデルやプロダクト開発の進め方の例でした。

さて、システムやソフトウェアの開発に関するお固めの文書を読んでいると、たまにソフトウェアの開発について「製造」という言葉が使われていることがあります。一方で、製造業のモノづくりとソフトウェアのモノづくりとでは、色々と勝手が違います。特にインターネット接続を前提とした、フィードバックループを高速に回して改善し続けるべきソフトウェアの開発については、その様相が大きく変わってきます。全く違うものを同じ名前で読んでしまうと、人間の思考は従来の考え方に引っ張られてしまいます。この点については、『ソフトウェア・ファースト』でもプロダクトのコンセプトに関する文脈で言及があります。

開発中のプロダクトを既存のカテゴリーにあてはめて命名するのはよくあります。しかしその瞬間から、人間の考えは固定されてしまいます。（中略）開発中のプロダクトにどんなに新しいコンセプトを入れ込もうとしても、既存のプロダクトカテゴリーの名称で呼んでしまった途端に手垢のついた枠組みの中でしか考えられなくなってしまうのです。
（『ソフトウェア・ファースト』3章 ソフトウェア・ファーストの実践に必要な変革 より）

ここまで述べてきたように、新しい技術を受容する上で最も重要なのは、その技術自体というより、その技術を前提とした考え方を受け入れることです。

これまで説明したプロダクト開発の手法は、ソフトウェアの価値を理解した上でプロダクト／事業開発を前に進めていくための一部にしか過ぎません。また、これらも日々変化しています。必要なのは、手法の理解ではなく、思想や姿勢です。これが本書のタイトルにもなっているソフトウェアファーストです。
（中略）
リアルな世界でのビジネスはインターネットで完結するビジネスとは勝手が違う部分も多くあります。ソフトウェア開発の手法が活かせる領域は多いものの、ソフトウェアだけでは解決できないものも見えてきました。そのような中、事業やプロダクト開発を成功させるには、ソフトウェアの流儀を知り、ソフトウェアの可能性も知りつつも、現状のソフトウェアが抱える限界も理解して開発に臨む姿勢が必要なのです。

「電気」の流儀が「流れ作業を前提とした工場のレイアウトや作業プロセス」であったように、「ソフトウェア」の流儀を前提にビジネスモデルや組織を組み替える必要があります。ソフトウェアの流儀を基本のやり方として受け入れることが、ソフトウェア・ファーストであり、現在の事業開発や事業変革にとって重要な戦略だということでした。

新しい技術を従来の何かに当てはめて理解するのではなく、本質的に新しいものとして理解しようとする姿勢が重要です。その流儀を自分たちが体現できるようになって初めて、その技術のポテンシャルを最大限引き出すことができるわけです。

『ソフトウェア・ファースト』とはどんな本か？

以上が、『ソフトウェア・ファースト』を読んで僕が考えたことでした。

最後に、マガジン購読者の方に向けて、本書の好きな点や物足りなかった点を補記します。

まずは好きな点。前述のように、製造業との比較の中で現在の日本のレガシーなソフトウェア開発の現状が語られていたのが良かったです。おそらく日本には「あの頃は良かった」的な製造業信奉が根強く残っています。その中での筆者の主張は、「製造業のやり方を中途半端にソフトウェア開発に持ち込むなよ」ということであり、その主張の一貫性やわかりやすさはとても好きです。よくTwitterでもお見かけします。

#ソフトウェア・ファースト にも書かせて頂いていますが、日本は製造業を模範とするのは良いですが、中途半端に模範にしています。製造業のサプライチェーンを真似するならば、現地現物の精神で、自社の重要なシステムがどのように作られているかをしっかりと管理するべきです。

— 及川卓也 / Takuya Oikawa (@takoratta) January 30, 2021

特にSIerへの外注にべったり依存した日本企業がまず目指すべきは内製化ではなく「手の内化」であるという主張は、内製と外注の二項対立になりがちな議論に対して現実的な選択肢を提示している感じで良いです。

一方で、レガシーな企業がITを手の内化するまでの具体的なステップについてはよくわかりませんでした。職種別の動き方やプロダクト開発のフレームワークの紹介はありましたが、まだ「色々並べました」という感じで、「では我々は明日から何すればいいのか？」みたいな疑問に答える本では無かった印象です。もちろん、それは各社の状況や事業ドメインによって異なるので自分で考えましょうという話こそがDXの本質であり、そもそも汎用的に語り得ない可能性はあります。それでも、具体的なDXの成功事例が増えてきたら、そのケーススタディを盛り込んだ『ソフトウェア・ファースト2』を書いてほしいなあと思いました（願望）。

他には、「エンジニアとプロダクトマネージャーの話に寄り過ぎている」という批判はありそうだなと思いました。これは筆者の経験に引っ張られている部分と、とはいえソフトウェア企業に変化する上で一番足りない部分がここであるという部分の両面がありそうです。とはいえこうした職種の人と一緒に働いたことがない読者の中には、「ソフトウェア企業に変化する上で一番足りない部分がここである」ということがすんなり腑に落ちない人もいそうだなあとは思いました。

あれこれ書きましたが、「すべての企業がIT企業になる」と言われている中で、現代のソフトウェア開発企業の在り方を身を持って知らない人には全力でおすすめしたい良い本でした。ぜひ読んで感想を聞かせてくださいね。

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略