IT記者会講演再録

IT記者会Reportに掲載したインタビューと講演再録です

派生開発推進協議会代表・清水吉男氏 XDDPから「IoT」に挑むー困難な状況をチャンスに変えるー(派生開発カンファレンス2016)

 5月27日、横浜市の横浜開港記念会館で開催された「派生開発カンファレンス2016」(派生開発推進協議会主催)で、第7回目にして同協議会代表の清水吉男氏が初めて演壇に立ち、「XDDPから「IoT」に挑む」と題した基調講演を行った。派生開発/XDDPといえば既存のソフトウェアをベースに機能を強化・追加していく方法論と理解される。それがどのようにIoT(Internet of Things:モノのインターネット)と結びつくのか。「派生開発」に新しい概念が提示された、と見ることもできる。


派生開発推進協議会代表・清水吉男氏はカンファレンス6回目にしてが初めて演壇に立った

IoTはただのうねりじゃなく津波

清水 皆さん、こんにちは。やっと、といいますか何というか、派生開発カンファレンス6回目にしてお話する機会をいただきました。主催団体の代表がこういう場で話すというのは、普通はあまりないんですが、これだけは話させてほしいとお願いしました。
 いま世の中はどこに行ってもIoT、IoTで、IoTが大流行りです。IoTがどういうことを意味しているのか分かっているのか分かってないのか、さっぱり分からない(笑)。ですが無視はできませんので、冷静に考えてみましょう、ということです。
 簡単に自己紹介をしておきますと、私がこの世界に入ったのは1968年ですから、もうちょっとすると50年になります。長くやり過ぎたかな、と(笑)。人から給料をもらったのは最初の半年と1971年の1年間。あとは全部、自力で稼いでいます。
 1973年、XDDP(eXtreme Derivative Development Process)の基本要素である要求定義手法「USDM」(Universal Specification Describing Manner)を考案しました。最後の設計は1995年に発売された初代のカラリオセイコーエプソンの家庭用インクジェットプリンター)。以後22年間、1回も納期遅れを起こしていません。これが私のプライドになっています。そのお陰で体を壊さずに済みました。
 で、今日の話に入ります。
 IoT。このうねりはそうとう厄介です。ただのうねりではありません。もう津波といっていいですね。ところがIoTに対応するには、日本の開発現場は過去に大きな過ちを冒していて、そのためにうまく動けないでいる。そのように私は見ています。そうはいっても何かしなきゃいけないので、全くゼロから開発するのならともかくとして、XDDPを使いながら、派生開発で現状を維持しながら、どうやってIoTに乗せていくか、という至上命題が皆さんに課せられているんだろうと思います。

昨日競争から価値競争、さらにアジャイル

 話は変わりますが日銀のマイナス金利、にもかかわらず市中銀行の日銀への預金が増えているというおかしな現象が起こっています。資金需要が全くない、ということです。売るモノがない。売れるモノを作っていない。そういう中でのIoTです。そりゃぁ経営者は色めきたちますよ。IoTで何とかなるんじゃないか。それでどこかで講演があると、「ちょっと行って聞いてこい」と言うわけです。聞くんだけれど、具体的な話しになると何をやればいいのか分からない。そんな感じだろうと思います。
 実は1990年代に大きな変化が起こっています。それは機能の競争から価値の競争への転換です。多くの製品がデジタル化して、後発メーカーでも同じような製品を作ることができてしまう。ソニートリニトロンはアナログのブラウン管だったので同じ性能の製品を作るのは無理でした。けれど、テレビが液晶ディスプレーになって電子部品が手に入りさえすれば、シャープの亀山モデルの優位性は長続きしなかった。堺に工場を作ったあたり(2009年)が転換点でした。
 iPhoneが出たのは2007年1月、日本で発売されたのは2008年7月でした。お財布ケータイの機能はなかったけれど、多くの人が「なくてもいいじゃん」と言って購入した。機能の競争から価値の競争に変わったんですね。その背後にあったのが、チャッチャと製品を作って時宜を逃さず市場に投入する、不都合はソフトで直すというアジャイルの考え方でした。
 そうこうしているうちにセンサーが高度化し、通信が高速化した。私ごとですが、この前、家内に……え〜、メールを打たなくていい、声でしゃべれば文字に変換してくれるというので、スマホを買いました。スマホに向かってしゃべって、送信のボタンを押せばメールが送れる。彼女は自分の手の中にあるスマホが処理していると思っている。実際は瞬間的にサーバーに飛んで行って変換された文字が戻ってきている。

ソフトウェア・ディファインドの時代

 クラウドが安価で利用できる時代になった。それによって、「継続的な価値の提供」が可能になってきています。ソフトウエア・デファインド(Software-Defined)の時代です。アメリカのゼネラルエレクトリック社がすでに取り組んでいますが、世界中に設置されている自社製の機械の動きを24時間・365日、クラウドで監視していて、異常や故障の前兆が検知されたら予防保守をするか交換する。ユーザーは実質的に「故障しない製品」を買ったことになるのです。
 家電製品や家庭用電子機器。日本の家電メーカーはズタズタですよね(苦笑)。日本の家電製品というのは、私たち団塊世代をターゲットにしてきました。そのターゲット世代が今や高齢者です。機能がたくさん付いて、操作が難しい。だからソフトボタンにして、その人が必要な機能をセットできるようにしたり、若い人向き・年寄り向きの操作性が選べたり、機能が追加された時は買い替えじゃなくてソフトのダウンロードで済む、そういうようにならないものでしょうか。
 あるいはテスラ社の自動車。これまでは「いつ買うか」の判断が難しかった。来年になったらもっといい機能、いい性能の製品が同じ値段、ひょっとするともっと安くなっているかもしれない。ですがソフトウエア・デファインドですから早く買ったほうがいい、ということになるんです。
 日本の自動車メーカーは自動運転の機能を「機能」として考えています。いつまでも研究中、開発中です。「これでいい」という判断ができないんです。ところがテスラ社は「サービス」に位置付けて、できることからリリースして、あとからソフトで機能を追加すればいい。その手法でステラ社は、1台500万円近くする「モデル3」、それはまだ世の中のどこにも存在していなくて、生産拠点すらなくて、ユーザーの手に入るのは2017年の秋以後なのに、たった3週間で40万台も予約があった。
 このお客さんはあと1年半、他社のクルマに目移りしません。先に手に入れても損しないだけではなくて、限定的かもしれないけれど自動運転を楽しめる。まだ製品がないのに2兆円もの売上げと40万台のシェアを先取りしてしまった。そういう時代です。
 

約250人が参加、「派生開発」の考え方が理解され広がっていることが如実に分かる

プロセスと標準化に対応できなかった

 こういった事象が何を意味しているかというと、ハードウェアとソフトウェアの関係が変わる、ということです。これまでは小型・軽量化するために、メカニックな動きをソフトウェアに置き換えてきました。厳密に言うと「プログラム・コード」です。プログラム・コードはハードウェアに実装されて、初めて機能を発揮しました。
 これに対してIoTはソフトウェアが主導します。もちろんセンサーやCPUにプログラム・コードは実装されています。ですがIoTの仕掛けはソフトウェアとソフトウェアの連携で動きます。ハードウェアはソフトウェアの目的を達成するための手段になってきます。
 「ユーバー」(Uber)というサービスがありますね。スマホでタクシーを呼んで、地図をタップすると近くにいるドライバー迎えに来る、到着するまでの所要時間や料金も分かります。このサービスが広がって、自動運転になると、自動車メーカーは困りますねぇ。自動車が売れなくなります。免許証も要らなくなるので自動車学校も要らなくなる。こういう状況に日本の製造業は対応できるんですか、ということです。
 日本の製造業、1980年代はその品質が世界中から注目されました。その品質は何によってもたらされたかといえば、テストです。繰り返しのテストと修正が品質を生み出した。これに危機感を覚えた米国の企業は、プロセスで品質を作り込むことを考えました。正しい設計と正しい手順が正しい品質を生む、という考え方です。
 199年代に入って納期の短縮要求が出てきました。品質を維持しながら納期を短縮するには、どうすればいいか。標準化がその手法として脚光を浴びた。ソフトウェアに関連した話ではCASEツールです。日本にも売り込みがありました。現場に検討するように指示すると、何週間かして、「これは当社の現場に合いません」という答えが返ってくる。
 テストで品質を作るという長年にわたる成功体験が、プロセスで品質を高め標準化で納期を短縮するという手法を受け入れないんですね。「何を考えているんだろう、この人たちは」です。自分たちのプロセスを変えるんだ、ということが分からない。業務パッケージソフトもそうです。カスタマイズしたんじゃ、パッケージを採用する意味がないじゃないですか。
 2000年代に入って今度はコスト要求が出てきた。オフショアに仕事を出す、社員の給料を下げる、ベテランをリストラする。それによって何が起こりましたか? 技術の空洞化です。

IoTは自前で作るしかない

 技術が空洞化したままIoTに突入できますか? IoTはソフトウエア・デファインドの世界です。競争力の根源をオフショアで、外注で、というのはダメです。なぜならIoTは利益の源泉です。それをオフショア先や外注先が担保してくれるはずがありません。競争力というのは誰かに任せてはいけない。IoTは自前で開発するしかないんです。
 ロバート・コールという、日本の製造業を研究なさっている方が、カリフィルニア大学で講義をするために2年ほど前に書いた論文があります。たまたま読む機会がありました。そこには「日本のソフトウェア業はブルーカラーを作ってきた」と書いてある。ここでいうソフト業というのは製造業から分離したソフト会社だろうと思います。それとブルーカラーというのは、言われたことしかやらない労働者という意味です。
 そこでコールさんは「日本の製造業はソフトウェアでイノベーションは起こせない」と結論付けている。ソフト部隊の技術者が知識労働者でなく、言われたことしかやらないブルーカラーだからだ、というのです。日本の製造業の弱点を完全に見抜いています。
 それだけではなく、新規開発のパワーがない。1990年代の後半からこのかた、コスト抑制のためにオフショアに依存し過ぎてクリエイティブなエンジニアが育っていない。クリエイティブでないから守備範囲が狭い。ホンハイ(鴻海精密工業)がシャープのエンジニア3千人のリストラを発表しましたね? ホンハイから見たら、シャープのエンジニアの守備範囲が狭くて生産性が低い、そのように見えているんです。そういう中で現存システムの品質維持と機能改善は派生開発でまかなえるけど、新規開発までは手が回らない。人を2倍にするわけにはいかない。これでは勝負にならない。
 自前で何とかやるしかないというとき、当面は派生開発でいいでしょう。でも来年も再来年も「当面」というわけにはいきません。「当面」といえるのは現在だけです。その中で新規開発にどうやって取り組んでいくか、です。

XDDPで人を育て時間を作り出す

 さて、ここまでなら、他のIoTのセミナーで普通に聞くことができます(笑)。これから派生開発ならではの話をするわけですが、私が話すのですからXDDPをどう活かすか、ということは想像できますよね?(笑)
 XDDPというのは追加機能と変更を別のプロセスでやる手法です。追加機能については要求仕様書で対応する。USDMで作成するわけですが、このときにただ書くんじゃ意味がない。
 追加分ですから要求項目はそんなに多くない。数千から1万項目ぐらいでしょう。要求を階層化し、グループ化したうえで、1時間に何件ぐらい仕様を記述できるかに取り組んでほしいんです。1時間100件の壁を突破すると違った世界が見えてきます。品質も上がります。この技術を手に入れると、5万仕様だろうと10万仕様だろうとボリュームへの恐怖が解消します。
 設計段階で、例えば状態遷移が出てきても保守性を考慮して、私は「複雑度17を超えてはならない」という原則を貫いています。そうすることで「よい設計技術」を習得できます。良い設計は変更におけるリファクタリングに使えます。
 その上で変更に際してソースコードを読むと、読みやすいソースコードが分かってきます。なぜ読みやすいかを考えて、その真似をして、1時間80行の安定した変更作業を目標にする。実際、その方法を適用して、50時間で7千行をこなした実例があります。
 そうしながら現行システムを延命させるのではなく、例えば2020年までに作り替えるぞ、と決めて計画的に取り組んでいく。XDDPの目的は現行システムの延命でなく、将来につながる技術の獲得なんだということです。IoTに向けたヒントにしてください(拍手)