“巨人の肩”を踏み台にもっと上へ　SEとQAが「顧客と一緒に価値を生み出す仕事」になるために必要なこと

ソフトウェアの教科書が見つかった

宮田一雄氏（以下、宮田）：富士通の宮田です。こんばんは。一言で言うと、私にとって今回のEssenceは、ソフトウェア工学の教科書が見つかった。そんな印象です。

日経BPの木村岳史さんは「日本のソフトウェア業界は、ゆでガエル状態のSIerとIT部門がずっとその状態のままでいるからぜんぜんダメなんだ」とずっと構造的な問題を指摘されています。私はSIerの立場ですが、悔しいけれど彼の指摘はある意味本質的なことを突いていて、これをなんとかしないといけないと思っています。

SIerを頂点とした多重下請けモデルで、ものすごく無駄なコストをかけてみんなで一生懸命やっているんだけど、それが価値につながらない。若者が3K職として（SEを）避けることに対しての指摘は、ちゃんと受け止めないといけないと思っているわけです。私世代は、SEの仕事はクリエイティブな仕事だったわけで、そういう仕事に戻したいと思っている1人です。

入社したのはエンジニアの教科書がなかった時代

少し自己紹介します。私が富士通に入社した頃は、SEって何？　という時代で、私自身もそう思いました。ハードのおまけとして、コンピューターに付けられて送り込まれたような時代です。

私自身、機械工学科出身で、就職先がなくて富士通に入って、SEになれと言われて「SEって何ですか？」って思ったときに、エンジニアなのに教科書がない。こういう時代でした。

私たちが学んだのは、IBMのマニュアルと『人月の神話』、それくらいのもので。当時は、構造化設計が入ってきて、メモリがない、IO性能がボトルネックになる、排他制御でオンライン性能が出ない。そんなことがあり、構造化をちゃんとしてアプリケーションや大規模なオンラインシステムを作るということを、我々世代は一生懸命やってきました。

たくさんの矛盾も感じながらやってきたわけですが、1990年後半にオブジェクト指向が出てきました。私たちも「なるほどな。これができたらいいな」「保守性の観点でいいな。すばらしいな」と思いましたけど、当時はオブジェクト指向でシステムを作ったら性能問題ができていて、やはりうまくいかないなと思いました。

大規模なオンラインシステムを作っている立場で言うと、リファクタリングって、現実的にできるのかなぁという疑問もあって。アカデミアの世界のエンジニアリングはなかなか現実では役に立たないなと思いました。それ以降、私自身は、マネジメントに注力して仕事をしてきたわけです。

SEはお客様と一緒に価値を創造する仕事

今年は小林さんを通じて、鷲崎さんたちと出会いました。この本を読んだとき、すばらしいと思いました。それはやっぱり巨人の肩の上に乗っているということですね。今、作者の爪先に立つだけでもいろいろなことがあるわけですが、巨人の肩の上に立つからこそ、そこを踏み台にしてもっと上に行けるんだけど。我々の仕事は、本当に同じことの繰り返しでぜんぜん進歩をしていなくて、無駄なことばっかりをやっている。システム開発をしている人たちの仕事もなかなか価値に結びつかない。こういう中で、原理原則が価値主導であると思いました。

私が本を読んで一番ビビッときたのは、「ソフトウェアエンジニアリングは顧客に価値を作り、提供するものなんだ。ということでできあがっている」でした。そういう意味で、ベンダーの我々SEも「お客様に言われたものを作る」から「一緒に価値を生み出す仕事」にこれから変化していかないといけないわけです。

そうすると顧客と価値を共創するうえで、やっぱり学ぶべきベースとなる教養レベルの教科書があったということは、非常すばらしいと思いました。

私はマネジメントに注力してきましたけど、もう一度エンジニアリングに基づいた共通言語でSIerとお客様が話し、これからの日本をよくしていきたい。そんなことを思い起こさせてもらえた教科書が見つかった。私はそんな気持ちでEssenceを捉えています。私からは以上です。

鷲崎弘宜氏（以下、鷲崎）：宮田さん、ありがとうございました。では続きまして富士通クオリティ・ラボの島田さんよりポジション表明をいただきたいと思います。

品質マネジメントシステムも変化している

島田さつき氏（以下、島田）：こんばんは。島田と申します。前者の宮田さんに続いて富士通から今出向しています。富士通クオリティ・ラボにいます。

自己紹介なんですけれども、私はずっと富士通の品質保証部門におりました。今でも品質保証の活動をしています。どちらかと言うとSI系というよりは組み込み系ですね。今話題の「富岳」から、PC、スパコン、携帯までいろいろな品質保証活動を、ソフトウェアを中心にやってきました。

最近はPMもさることながら、IoTだとかAIだとか、そしてアジャイル……私はDXの「品質って何なの？　どうやって保証したらいいの？」というようなお問い合わせをいただきます。

いつも考えてしまって、一言では言えなくて、モゴモゴしちゃっています。それこそいろいろな方法論があるとは思うんですけれども、答えがない中でどうやっていくか？を悩みながら進めているといった状況です。

私はずっと品質に携わってきた人間なので、今日はやっぱり日本の品質面からいろいろお話ししたいです。今、ベースとなっていく品質のマネジメントシステムもどんどん変わってきています。

我々は昔から世界トップ品質を絶対死守するんだって思っているんですけれども、最近はイノベーションマネジメントというような、ISO56002なんかが出ています。

Society5.0につながる社会ということで、私はそこの実現方法としてDXが出てきているのかなと考えています。その中で、今日参加しているみなさん、やはりこれからソフトウェアが担っていく時代なのかなと考えています。

そのソフトウェアも、先ほど話があったウォーターフォールモデルがだんだんアジャイルに変わっていく中で、やっぱりモデルが変わるだけじゃいけないと考えています。これなんかは、AIのソフト開発、探索的段階型などという話が出ているんですけれども。

組織や部門を越えて密な関係性を作っていく

これに加えて、下にちょっとあるんですが、スキルですよね。デザイン思考や、サービス企画、データ分析のスキルが必要だったり。あと組織の中での人と人の関わり方、あるいは組織を超えた関わり方がこれからは重要になると勝手に思っています。

いろいろな会社の組織体系や、役割があるので一概には言えないんですけれども、これまではQA部門って開発部門や営業やSEさんより、ちょっと離れたところにいる位置付けだったと思います。

これからはQAも中に入って一緒に、密に……密っていう言葉は今は禁止なんでしょうけど（笑）。やっぱり関係性は密にしていかないと進んでいかないって思っています。

そうなったときに、今DevOpsという言葉がいろいろなところで話題になっていますけれど、そこにQAを入れ込むことが必要なのではないかなと。DevQAOpsという表現もチラチラ出ていますが。

これは私の捉え方なので、批判がある方もいらっしゃるかもしれません。QAはチームの中で、イテレーションを1回回すときのテスト、検証屋さんというイメージですが、もっともっと広い意味で、品質保証、品質管理をやっていく人もちゃんとチームの中に入れ込んで、活躍をしてもらう必要があると思っています。

さらには保守運用の段階で、ほかの企業ともいろいろ情報連携をしたり、あるいは組織の違う部門のプロジェクトとも連携したりというようなことが、QAから行っていくことが重要だと思っています。

品質保証から見たEssenceの可能性

今回、こういう機会をいただきましてありがとうございます。実際に本を読みました。Essenceという7つのアルファですね。その中をQA、品質保証の観点から見ると、品質屋さんが入ることによって、もっと広がりが出たり深さが出たりするんじゃないかなと思います。

品質の観点から、お客様だったり、ソリューションだったり、活動だったり、それぞれの立ち位置できちんとしたプラクティスが出せるんじゃないかと勝手に思っています。

当たっているかどうかもわからないんですが、リスクを抽出するときにはISO25000の話が出てきたり、あるいは開発チームが駆動してPDCA回していくところではテスト屋さんも重要だし、品質管理屋さんも重要です。プロセスとプロダクトのQAが同期するときに作業のところでプラクティスをちゃんと定義できるのかなって思ったりもします。

そしてやっぱり、そういうデータですよね。データを分析する能力が優れているQAの方々は多いと思います。データを分析することによって、次の価値のインプットになるんじゃないか、フィードバックも含めてインプットになるんじゃないかと思っています。

こういう時代だからこそ、Essenceというか、ベース面の本質は必要だし、そこの基盤にも品質、クオリティはあるんじゃないかなと思います。クオリティをEssenceに入れてもらって、未来社会を実現できたらいいなと思っています。

第4回以降は品質に着眼しているコンテンツが入っていますので、ぜひみなさん、次回以降も聞いていただければうれしいなと思います。島田からは以上です。ありがとうございます。

（次回へつづく）