これからの開発で意識したい「美点を見つける」こと　DX時代のソフトウェア品質計測で重要になる価値

『製造分野DX推進ガイド』にまとめられていること

五味弘氏：3本目は一般的なDXの話なので、「こういう資料がある」（という）ことを紹介したいなと思っています。

（スライドを示して）『製造分野DX推進ガイド』が示す中小製造業のDXで、組込みではなくさらに特化した製造業に関して、「今DXをどのようにやっていますか」「DXを推進するためには、こういうふうにやっていけばどうですか」というガイドをまとめています。

なので、みなさまのお客さんの中に製造業がいれば、中小に限らず適用できる可能性もあるので、ぜひすすめてもらえればなと思います。

ガイドは右側にこういうふうに書いてあります。「左側に書かれたこういう（ことの）ためにはこういうガイドがあります」ということです。冊数はすごく多いです。「マンガでわかるFAQ」というちょっと怪しいのもありますが、それを見てもらえればわかりやすくなっています。

FAQの中には、おもしろいものがいっぱいあります。「DXってお金儲かるの？」とか「DXっていくらかかるの？」とか。そういったよく来る質問から、組込み（の話）だと「カイゼンとどう違うんですか？」とか「IoTのDXとはどういう関係ですか？」という質問がよく来るので、その答えというか、「一緒に考えましょう」的なことが書いてあります。

製造分野のDXとは

（スライドを示して）ここには「『DX』と『IoT』はどう違うの？？」ということが書いてあります。「IoTはシステムですよ」という一言で終わればいいんですけれど、「IoTは概念だ」と言う人がいるので、そうなるとDXとの違いを言わなくちゃいけません。

DXは継続・持続する。ずーっとやることです。IoTは、概念としてのIoTも1回作れば1つの完成になるということが違うんじゃないかなと。そういうFAQが書かれています。

（スライドを示して）製造分野の対象範囲を書いています。製造業をDXで目指す姿、中間目標としてはスマートファクトリー、スマートプロダクト、スマートサービスの3つで、「どれか1つではなく、3つのうちの何個かを選んで進めればいいですよ」と。それぞれについての事例やステップ例をガイドに書いてあります。

製造分野のDX度チェック

（スライドを示して）それから、私たちは製造分野のDX度チェックを作っています。「あなたの製造業の会社はどの段階で、どこがDXとして弱いか」ということがエクセルシートになっていて、ポンポン入れてもらえれば評価できるものがあります。

このあたりでは製造業に限らずにDX推進指標というものがありますが、あれの製造業に特化したものです。あちらは経営層まで入っていますが、現場に近い部門でやる（ものと）、両方やってくださいというようになっているものがあります。

（スライドを示して）概要はこういうかたちで、9つの項目でレベル0からレベル3でそれぞれ当てはまるものをポンポンポンポン入れてくださいと。そうすると「レベルアップするためには例えばこういう事例がありますよ」ということをエクセルシートで（出すことが）できるようになっています。

DX度をチェックして、次のアップするための事例が載っているので、それをぜひ参考に（してもらう）ということを製造業の方におすすめしてもらえればと思っています。

中小製造業14社を対象にしたヒアリング結果

（スライドを示して）実は人気があるコンテンツはこれです。2年前、2020年のコロナが始まる前に、それぞれ中小製造業14社に対して「おたくのDXまたはデジタル化はどうなっていますか？」とヒアリングしていて、それを書いています。ダウンロード数がすごく多いです。こういうのは、みなさん見て「真似できるところがないか」と、よく取り上げてもらっています。

ここでソフトウェアもけっこう出てきますね。知っている方もいると思いますが、製造業はいわゆる工場設備のOT（運用技術）、工場設備のITと、それから営業や総務のいわゆる一般的なIT、ITとOTの戦い。究極を言えば、工場と非工場、製造部門と非製造部門の戦いが多少あるんですよね。

OTとITはコンピュータ的につながっていないので、まず同じ会社間でOTとITを連結させるところから始まる、というような苦労話がこの14社で語られているので、OTとか、そういうところをやっている方はぜひ見てもらえればなと思います。

（スライドを示して）実際の施策が書いてあります。中小製造業に行くと、人材（について）がとにかく言われます。DX人材、データ人材をどう確保すればいいのかは、答えはあまりありませんが、施策があった会社が4つぐらいありました。大手メーカーの早期退職者を採ってくるとか、そういう手段しかありませんでしたが、そういうことが書いてあります。

あとはデータの見える化で、これはすごく大事です。工場の設備はパイロットランプ、行燈とも言いますが、あれでさえネットワークにつながらないという、20世紀時代のマシンがいっぱいあります。あれをどうデジタルデータにして、かつクラウドまでいかなくてもいいですが、ネットワークでクラウドにどうつなぐか、そこで苦労されています。

ビデオカメラで画像認識させる、光センサーを買ってきてやる、ベンダーからちょっと手助けしてやっていた、というような事例がいろいろ掲載してあります。

「マンガでわかる製造分野DX」に書かれているDX化ステップの例

（スライドを示して）「マンガでわかる製造分野DX」には、ステップ例がこう書いてあります。「いらすとや」さんのイラストを使って、4コママンガ風に書いてあります。今52問か53問ぐらいあって、このFAQの数はたぶん多いほうだろうと思っています。

だから、DXに関していろいろ質問があれば、（これは）製造分野にだいぶ特化していますが、ほとんどこのFAQに52個で答えられるようにしています。もしみなさんがDXについて聞くことがあったら、このFAQを見てもらえればなんとか答えられる、見栄を張れるんじゃないかなと思います。

ソフトウェア開発と品質

ということで、これで3本立てが全部終わったことになりますが、後段です。

最初のところを思い出してほしいのですが、DXにおけるソフトウェア開発はどうあるべきだったか。（スライドを示して）ソフトウェア開発というと、特に組込みは匠の世界・職人気質というものがあって、なおかつ日本人が得意な品質重視、それからウォーターフォールで管理しやすいからウォーターフォールでやっていた。

DXになって大規模化や複雑化、短納期化、並行開発というような大きな波が来て、結局はDX世界、DX気質、速度重視・変化重視、アジャイルソフトウェア開発へという流れになります。

ソフトウェア品質は生産性や機能信頼性、これはリリース後のバグのことですが。最初の質問にもありましたが、DXになるとそんなことより早く作ること、俊敏に作ること、価値が大事。バグがあっても（それよりも）価値がもっと大事で。コストではなく価値（のほう）が大事です。「でも価値をどう測るんだ？」ということで最初の疑問、質問に戻ってしまいますが、目指すところはこちらと言っています。

（スライドを示して）ソフトウェア品質計測ですべきことは、DXの時に価値が大事ということになると、今まで上流はだいたいレビュー中心、下流はいわゆるテストで欠点を見つけるところを中心にやっていましたが、（これからは）美点、価値を見つけることが大事ではないか、ということで（資料に）書いてあります。

価値が計測不可能で、定量的（な分析）には不可能。価値というのは難しいので、ちょっと美しい点というふうに変えて、（定量的に計測できそうな美しい点を）見つけてあげてください。レビューで「ここはすばらしいです」と。

まぁコードが美しいんじゃなくて「ここはユーザーにとって価値がある」「これは今後弊社にとって使いまわしができる」という価値、美点を見つけてあげてくださいねと言ってはいます。

では具体的にどう見つけるんですか（ということについては）「5W1Hで見つけろ」と書いてありますが、どう見つけるのかは非常に難しいです。先ほどの直交欠陥分析のように、美点を見つけるとよく項目が出てきます。よく似たものは1個にまとめなくちゃいけないので、直交性は非常に重要になってくるかなと思います。

（スライドを示して）DXに限らず継続は大事です。品質、データを集めて蓄積してこそ資産になるので、「ウォーターフォールの意味はない」「生産性の価値はない」「今後アジャイルになるからウォーターフォールの計測データは捨ててしまえ」と、まぁそこまで言う人はいないでしょうが、「ほっとけ」と言うのがありますが、それも資産です。

すべてが100パーセントアジャイル開発になるわけではありません。なので、ウォーターフォールの資産は絶対に置いておいて、これからも集めていったほうが、ある程度はもちます。最初に言ったこととちょっと違いますけれど。

アジャイルでの品質計測

（スライドを示して）アジャイルでの品質計測です。生産性。アジャイルでは仕様変更は当たり前です。これはすでに質問のところで同じことを言っていますが、今までは分析データ集ではSLOC（Source Lines Of Code）、（つまり）行数やファンクションポイントで数えていましたけれど、意味はありません。これはもうわかっています。

付録にしてあります。アジャイルというかこれはほとんどスクラムですが、ストーリーポイントのベロシティを測って相対的な生産性は評価できますが、他社を入れてのベンチマークには使えません。

信頼性はまだまだ使えるんじゃないかと。特にリリース後のバグについては、アジャイル開発でも重要視されるだろうということです。でも将来はバグより価値と言われるかもしれません。

先ほどの自動化にもあったように、アジャイルだからコストをかけてということではなく、「計測の共通化をして自動化はとにかくどんどんしてきてください」ということになっています。

（スライドを示して）総まとめです。DXに求められる品質とその計測（について）、後段でお話しました。

残り5秒ありますが、IPAからのお知らせです。メールマガジン「DX SQUARE」、それからTwitterをやっています。（スライドを示して）こういうことをつぶやいているので、ぜひ参考にしてもらえればなと思います。

ちょっと最後の質問時間がなくなりましたが、ちょうど時間となったのでこれで終わりたいと思います。ご視聴どうもありがとうございました。