DX(デジタルトランスフォーメーション)で後れを取る日本企業。デジタル化そのものへの対応も遅く「デジタル敗戦」ともいわれる状況に陥っている。DXでの成果が求められる今こそ、デジタル敗戦の要因を理解した上で「ソフトウェアファースト」、つまり「ソフトウェアの手の内化」に取り組む必要がある。連載第3回は「製造業とソフトウェアの開発工程の違い」についてより詳しく、注意点も含めて『ソフトウェアファースト第2版 あらゆるビジネスを一変させる最強戦略』(及川卓也著)より抜粋してお届けする。

 トヨタ自動車が編み出して世界中に広まっている「カンバン方式」や「カイゼン」など、製造業で生み出された工程(プロセス)は非常に洗練されており、ソフトウェアもそのプロセスを応用しながら開発手法を進化させてきました。

 製造業のプロセスと現代的なソフトウェア開発プロセスの類似点や相違点を図解して、理解を深めてみましょう。前回も掲載した製造業のプロセスを簡略化した図を以下に示します。

図1 製造業のモノづくりプロセスの詳細
図1 製造業のモノづくりプロセスの詳細
従来型製造業の企画から開発、製造に至るまでのプロセスの一例
画像のクリックで拡大表示

 まず、企画に基づき「先行開発」というプロセスでさまざまな試作品が作られます。この段階では、小規模な設計と開発が繰り返され、企画の意図に合致しているかどうかが検証されるとともに、量産に必要な条件が明らかにされます。量産化の承認が下りた後は、量産のための詳細設計に移ります。この設計作業は製品開発とも呼べるものですが、その結果得られるものは設計図であり、その設計図に基づいて製造ラインで量産を行うのが製造というプロセスになります。

 「生産技術」は、製造ラインの設計と準備を担う役割であり、製造技術開発、製造プロセス開発、製造現場(工場)の展開を含みます。この技術は実際の製造に先立って進められ、製造を支えるプロセスです。

 「研究開発」は、将来の製品や生産技術に必要な基盤技術を開発するプロセスであり、製品開発のみならず製造技術にも寄与します。

 また、「調達」や「開発委託」も製造業では重要な要素です。製造業はピラミッド型の産業構造を持ち、自社内ですべてを行うことは少ないため、外部から部品や完成品を取り入れ、それらを組み立てて製品を形成します。日本の製造業が高品質で知られる一因として、現場の品質に対しての絶え間ない努力がありますが、それに加えて外部調達品の品質管理の精度が非常に高いことも、その理由の1つです。

製造業に倣ったウォーターフォール型の開発

 この製造業のプロセスを踏襲したものが、ウォーターフォール型の開発と言えます。ウォーターフォール型の開発は、製造業のように手戻りが許されない開発には向くものの、それ以外には適さないと説明しました。それでも成功した製造業のようなスタンスでウォーターフォール開発を行っていれば、少なくともシステムインテグレーター(SIer)やITベンダーに丸投げしたり、自社でグリップが効かなくなる(制御できなくなる)ような状況には陥っていないでしょう。

 例えば、ソフトウェア開発を外注するというのは、図2の「開発」の外部委託に相当します。製造業の調達や開発委託では、自社で開発すべき部分と外部から調達する部分を、その希少性や競合優位性、品質、コストなどの多面から判断します。外部に委託する場合でも、極力依存度を抑え、1社に偏らないよう複数の調達先を確保することもあります。必要に応じて、自社で開発できるようにしているものもあります。このように、製造業では、戦略的な判断の元、外部からの調達を行っているのです。

図2 製造業とソフトウェア開発の詳細プロセス比較(1)~ウォーターフォール型のソフトウェア開発の場合
図2 製造業とソフトウェア開発の詳細プロセス比較(1)~ウォーターフォール型のソフトウェア開発の場合
従来型製造業の開発プロセス(上)と、パッケージソフトの企画から販売に至るプロセス(下)の比較
画像のクリックで拡大表示

 ソフトウェア開発を外注化する場合、ここまで戦略的に判断しているでしょうか。自社にはできないということで、安易に委託してしまっていることも多いのではないでしょうか。付き合いが長いというだけで、いつも同じSIerに委託してしまっていることはありませんか。製造業の調達や開発委託と同じ基準で考えるならば、ソフトウェア開発を安易に外注してしまうことが、どれほどのリスクになるかお分かりいただけるでしょう。

 製造業で言うところの「生産技術」は、製品を効率よく、高品質に作るための技術です。ソフトウェア開発においては、「開発基盤」という役割がこれにあたります。近年、「開発者体験」という概念が注目されており、これはソフトウェアを作る人々が快適に作業できるようにすることを指します。開発者体験を向上させるには、プログラミングしたソースコード(プログラムの元となるテキストファイル)を一か所に整理して保存したり、タスク管理システムを使って開発作業を効率化することが含まれます。さらに、プログラムを変更したら自動的にテストして、すぐに問題がないか確認できるような仕組みが整っていることも重要です。

 また、開発者が使用するコンピューターの性能も大きな要因です。古いスペックのマシンを使用していると作業効率が落ち、開発の進行にも悪影響を及ぼします。これらの開発基盤が整っていることで、開発者体験が向上し、より良い品質のソフトウェアが作られるのです。しかし、実際には多くの企業でこれらが軽視され、投資が後回しにされています。

 このように、ウォーターフォールであっても、従来の製造業が行っていたベストプラクティスをきちんと踏襲すれば、より良いプロダクトを生み出すことができます。ただし、サービスとしてユーザーに提供するソフトウェアを開発する場合は、「育てていく」という概念が加わり、これまでよりも素早く仮説検証を回す必要が出てきます。これにウォーターフォールで対応するのは少々難しい。そこで仮説検証に使われるのが、図3に記した、アジャイル開発やDevOps(デブオプス)となります。これが、製造業のプロセスと現代的なソフトウェア開発プロセスの最も大きな違いだと言っても過言ではないでしょう。

図3 製造業とソフトウェア開発の詳細プロセス比較(2)~サービスとして使われるソフトウェア開発の場合
図3 製造業とソフトウェア開発の詳細プロセス比較(2)~サービスとして使われるソフトウェア開発の場合
サービスとして使われるソフトウェア(SaaSなど)の場合は、開発プロセス間の境界が曖昧にな り、仮説検証のサイクルが組み込まれる
画像のクリックで拡大表示
(写真:Jane/stock.adobe.com)
(写真:Jane/stock.adobe.com)
ソフトウェアで新たな価値を生み出そうとする企業と、そうでない企業との差は、さらに開きつつあります。今こそソフトウェアを武器に真のDXに取り組む時です。 ソフトウェアの進化スピードと柔軟性を武器にして(手の内化して)、事業価値や顧客体験を向上させるプロダクト(製品やサービス)を生み出す方法を解説します。

及川卓也著、日経BP、2420円(税込み)