篠原新治氏の自己紹介
司会者：本日の登壇者はこちらの方々です。今回はテスト・アライアンス事業部の事業部長である石原さんと、エンタープライズ品質サービス事業部金融ソリューションサービスグループの副部長である畠山さんの2名にご登壇いただきます。Q＆Aコーナーのファシリテーターは、グループ開発事業推進部長の篠原さんに務めていただきます。
登壇者の石原さんは8月3日に『この1冊でよくわかるソフトウェアテストの教科書』という本を発売されました。先ほどAmazonを見たらソフトウェアカテゴリでベストセラー1位になっていました。今回そんな方々のお話を聞けるのが個人的にはすごく楽しみだなと思っています。
ではさっそくですが、発表に移りたいと思います。篠原さん、石原さん、準備をお願いします。
篠原新治氏（以下、篠原）：バルテス株式会社 グループ開発事業推進部で部長をしています篠原と申します。現在181名の方にご参加いただいています。お申し込みは300名を超えています。本当にありがとうございます。
上流工程は品質の確保に重要となりますが、上流工程でいろいろ改善をしたいなとお悩みの方もいれば、下流工程になってから「あ！」という気づきを実体験としてお持ちで、今日の勉強会を通じて今後の実務に活かせるところを持って帰りたいなと参加していただいている方もいると私たちは感じています。
前半のパートでは、石原からコツや考え方をお伝えして、後半は畠山から実際の事例として私たちの経験を踏まえた対策のポイントをお話しするかたちで進めていきたいと思います。
テストを通じて世の中のソフトウェア品質の向上を支えるバルテス株式会社
バルテスという会社を今回で知ったという方、名前を聞いたことがある方、いろいろいると思うので、私から簡単に自己紹介をしたあとに石原にバトンを移したいと思います。
あらためまして、当社はバルテス株式会社といいます。社名の由来は「Value created through Testing」で、2004年にソフトウェアのテストを通じて世の中のソフトウェア品質の向上を支えていこう、社会貢献をしていこうと設立しました。
おかげさまで現在19期目に入っています。私は入社して11年目ですが当時は100名そこそこだったところがグループ会社も4社増え、エンジニアの従業員も700名を超える企業体というかたちで東京・大阪・名古屋・福岡を中心に各事業会社さま、SIerさま等の開発工程におけるテスト・品質の部分を支えさせていただいている企業です。
特徴は画面左側の社名の下ですね。「国内で初の」というところですが、ソフトウェアテストにはJSTQBと呼ばれる資格があります。そちらの親団体であるインターナショナルのISTQBのGlobal Partnerという認定を国内で初めて受けたテスト専門企業が当社です。
先ほど紹介いただいたとおり、『ソフトウェアテストの教科書』などの出版事業や、各IT向けのサイトでの寄稿なども行ったりしています。
私たちの事業領域ですが、テストを通じてというところはブレず、特徴として青いソフトウェアテストの部分だと、特に製品・ドメインを問わずに幅広い領域でのご支援が可能です。
今日参加していただいている方々の中にも、Web開発の方、エンタープライズのいわゆる業務システムを担当している方、組み込み、IoT系の方などさまざまいらっしゃるかと思いますが、今日のこのあとのお話は、これまで経験してきた中から特に金融・業務システムの部分にフォーカスを当てたいと思っています。
私たちは現在、年間2,600ぐらいの開発プロジェクトにエンジニアが参画しており、経験・ノウハウ・ナレッジを溜め込んでいっているので、なにか1つでもお役に立つものがご提供できるのではないかと考えています。
そのほかは教育の支援だったり、昨今はセキュリティも品質の1つと謳われている時代なので、セキュリティ診断やWAFと呼ばれるWebアプリケーションファイアウォールの自社開発提供、テストの自動化に向けた「T-DASH」というものもご案内しています。
このようなかたちで品質にフォーカスを当てた企業活動を行っている中での事例を、このあと石原と畠山からお伝えしたいと思います。では石原さんよろしくお願いします。
石原一宏氏の自己紹介
石原一宏氏（以下、石原）：篠原さんどうもありがとうございました。では話し手が変わりまして、私からお話をスタートしようと思います。私は「上流工程における"少しの手間"で、品質とコストを大きく改善する勘所」と題してお話しします。
会社紹介があったので、もうすでに「テスト専門会社だよね？ でもなんで上流工程なの？」と、はてなマークがたくさん付いた方もいるかもしれません。私自身は下流工程でテストすること、かれこれ30年以上やっています。下流工程から眺めてみると、「上流工程でひと手間かけておいたらここまでプロジェクトが遅れたり、コストが出たりすることはなかったのにな」「品質ももうちょっと良かったのにな」と思うことがけっこう多いんですね。
なので今日は理論というよりかは経験則ですね。こういうことをやっている中でこういうことをやるとうまくいったよ、逆にこういうことをやらなかったらけっこうひどい目にあったよというところを、みなさまに共有して、Q＆Aでもお話をして、みなさまにはちょっとでも現場で品質とコスト、そして納期の改善、QCDの改善のヒントを持って帰っていただければなと。その勘所をお話できればなと思っています。
ということで石原と申します。先ほどのベストセラー（の話）、大変ありがたいです。（コメントを見て）チャットで「すごい人」、ぜんぜんすごくないです（笑）。ただ長くやっていただけで、それをちょっと本にまとめただけです。
本を書いたりソフトウェアの品質のコンサルタントという肩書も持っていて、（スライドには）大阪大学と産学連携でテストツール『Quimas』を開発と書いてあります。もちろんそれは事実ですが、私自身としてはさっきも言ったとおり、ソフトウェアの品質保証の畑をかれこれ30年以上ずっと歩いて来ました。前に立ってしゃべることが最近多くなっていますが、一エンジニアでもあると今も思っています。
なので現場ではお困りのみなさんと膝を詰め合わせて「なにに困っていますか？」「そういえばこんなことが私のほうでもありましてね」みたいな雰囲気でずっと話してきましたし、そんな感じで本もまとめてきました。今日のセミナーもそんな感じでみなさんと一緒に「なにに困っていますか？」「じゃあこういうところを……」（とお話ししていきたいと思っています）。（コメントを見て）「バイブルにしています」。ありがとうございます。
テストに関する教科書は昔からあまりなかったのでけっこう苦労しました。それをみなさんに共有できたらいいなと思って「教科書」を書いたので、今日もその延長で、なにかお役に立ててもらえる情報を共有できたらうれしいなと思ってお話ししていこうと思っています。
先ほど事務局の方にアイスブレイクで「趣味の話をしろ」と言われて、それを考えていたら胃が痛くなったんですが（笑）。コロナで出張がなくなったので、最近は以前出張した時に日本各地で食べたおいしいものの味の再現をけっこうやっています。
東京の有楽町にあるジャポネというパスタ屋さんのジャリコとかですね。名古屋の中華料理店味仙のにんにくチャーハンとか、大阪のビアホールのMunchenの唐揚げとか、食べたことがある方もいるかもしれませんが、おいしいですよね。あれをうちでできないかなと。外出できないからコピーを最近しています。Munchenの唐揚げと、ジャリコに関してはだいぶ再現率が高くなってきた気がします。この話で終わるわけにはいかないので、先に進もうと思います。
ひと手間をかけることで品質は良くなる
というわけで、やはり品質に関して困っている方はたくさんいるんじゃないかと思います。今日はPMの方が多いと思いますが、システム開発にかかるコストを減らしたい、もちろんそうですよね。あとはテストでバグが多いのでなんとかしたい、品質を上げたいと思っている方も大変多いと思っています。
がんばって開発をしているんだけど上流工程の品質が悪くて後工程を圧迫する、テスト工程でけっこうクリティカルなバグが出ちゃって手戻りしてしまって、厳しいなと思っている方もいると思います。
ここに書いていることは、私も自分が関わったプロジェクトで困っていることばかりです。その時にちょっとこういう工夫をすることでだいぶ改善できますよ。私は面倒くさがりなので、べき論は嫌いなんです。上流工程をきちんと設計したら良いものができる。そんな当たり前のことは誰も聞きたくないですよね。もうみんながんばっているわけですから。
みんな120パーセントの力でがんばっている。そこで「もう150パーセントがんばったら品質が良くなる」という話は誰も聞きたくないわけで、できれば100の力でやっていることを80とか70の力でできないかな。浮いた20、30で他の改善や新しい試みをしたい。私もそのつもりでずっとやってきました。
だからちょっと手間をかけるだけで少し楽になる。楽になった分だけまた改善ができる、元気もリソースも湧いてくるよねみたいな、そんなことをみなさんと一緒に考えていければなと思っています。（コメントを見て）「ジャポネ大好き」という方がいますね。「料理も科学」。そうですね。再現性を求めるという意味では科学に近いかもしれませんね。意外なところでけっこうウケていて恐縮でございます。
フェーズが1つ進むと修正コストは増加する
さて、ウォーターフォールもアジャイルも私は基本的には同じだと思っています。私たちはシステムテストやテストフェーズで仕事をすることが多いのですが、システムテストでクリティカルな不具合を見つけるとうれしくないですよね。私はリリースの3日前とかにけっこう仕様抜けをシステムテストで発見するんですが、「発見しました！」と言うと、みなさん喜ぶどころか顔が赤くなったり青くなったりして、人によっては「なんで見つけるんですか!?」なんて詰め寄られたりします。
つまり、設計・仕様抜けがテスト工程で見つかるのはうれしくないですよね。PMの方であってもSEの方であっても「それを防ぎたいからがんばっているんだ！」というところがあると思いますが、いかんせんやはり時間がないタイトな中でみなさんがんばっていて、どうすればそれが改善できるのかなという悩みの種はたくさんあると思います。手戻りって嫌ですよねというのがこの図で言いたいことです。
さらに嫌なのですが、品質保証のテストに携わる者が本当に胸に刻んでいる図です。これはいろいろな説がありますが1フェーズ後工程になるごとに、修正コストが倍近くにどんどん増加していく指数関数ですね。どんどん増えていく。レビューの時に不具合を見つけた修正コストを1や5にすると、単体テストでは10とか20。結合テスト、システムテストでは50とか。出荷後に見つかったものは100以上では済まないよという話です。
下流工程になればなるほど多大なコストを要する。時間がないからとりあえず上流工程はそこそこで済ませて、あとはテストでなんとかしようという戦略は時間がない時にやりがちですが、それをやると実はそのあとに手痛いしっぺ返しを食らうことが多いです。なのでよく「シフトレフト」、できるだけ左の上流工程からがんばろうという話はされていますが、「そうは言ってもじゃあ具体的にはどうするの？」。
設計だって時間がないし、レビューだってなかなか時間がないし、人もいないしみたいな話がありますよね。そこが今日ちょっとお話したいところ。これは理論ではなくて「実際にこんな事例がありました！」と私や畠山も含めてみなさんと一緒に（お話ししたいと思います）。本当はリアルで膝を詰めて話したいところですが、そんな雰囲気で考えていきたいと思っています。
上流工程で曖昧な仕様をつぶすための3つの方法
QCD（Quality・Cost・Delivery）を改善する方法を大きな戦略でいうと、私は3つしかないと思っているんですよ。設計工程・実装工程・テスト工程をそれぞれ上流・中流・下流とすると、できることは3つしかありません。上流工程で曖昧な仕様をなくす、中流工程でできるだけ実装と単体テストをがんばる、あるいはCIなどを行うことによって手戻りを最小化します。
そして、下流工程のテスト実行を効率化する。それぞれをお話しするだけでも長い時間になりますが、今日はタイトルにもあるとおりこの部分ですね。「上流工程で曖昧な仕様をつぶす」という、ワンポイントをみなさんに共有できればと思います。「なんでテスト会社が」という話ですが、下流工程で3日とか1週間の手戻りになってしまうみたいなことがけっこうあるんですよね。
やはり上流工程でひと手間考えておくだけでも、例えば10、15分でこんな資料を作るだけでも違います。その15分をちょっとみなさんにお伝えしたい。15分、30分がんばることで3日とか1週間とかの手戻りが防げるのであればけっこう安くつきますよねというのが今日のテーマです。なので「これ以上がんばる」ではなくて、今100でやっている仕事をなんとか80や70ぐらいで楽にできるようにして、浮いた分で早く帰るも良し、さらに高い品質や改善を目指すもよし、というそんなヒントを持って帰ってもらえればなと思っています。
「上流工程で曖昧な仕様をつぶすには」ということですが、今日の話で言いたいことはこの3つです。「仕様書に書かれていない見えない仕様を可視化しよう」「正常系の『できる』ことだけではなくて異常系や準正常では『できないこと』を考えてみよう」「できれば文章だけではなく図表も活用する」。実はこれらの根っこは同じことを言っています。
上流工程のひと手間で手戻りリスクが大きく減る。これは実はなにかというと、私たちテストをする人間がいつも心がけていることばかりなんです。下流工程で重点的に見るのはこういうことばかりなんですね。でもこれは先ほども言いました、下流工程のシステムテストで不具合が発見されるのと、実装前の上流工程でその足りないところが発見できるのとどちらがうれしいかというと、答えは明らかですよね。
上流工程のほうがコストが少なくて済みますよねという話です。メインは畠山さん「こんな痛い目にあいました！」みたいな事例をお話ししてもらいます。見ているだけでちょっと胃が痛くなる時もありますが、ちょっとひと手間をかけるだけでこれを回避できますというところをちょっとみなさんと一緒に考えていければなと思います。
私は品質管理・品質保証をずっとやっていました。基本的にはバルテスも含めて下流工程でがんばってバグを出すという仕事をやっているんですが、品質保証の根本の考え方は先ほどもあったとおり、上流工程でがんばったほうがはるかに効率が良いです。欠陥の作り込みを減らしましょうという話です。理屈はわかっている、べき論はわかっているよ。でもそれは時間がないからできないんじゃないか、人がいないからできないんじゃないか。
本当にそのとおりです。だったら時間がないなり、人が足りないなりにできる方法をちょっと考えましょうというのが今日一番言いたいことでもあります。
曖昧なものがちょっとでも残っていると、伝言ゲームでそれはどんどん間違いが大きくなっていくように、やはり修正コストというか不具合が加速度的に増えてくるというのが、先ほどの図をちょっと変えたこの図ですね。
このモレヌケというところが、新たなエントロピー、ノイズ、バグを作り出すイメージです。私も30年間はそればかりだったので、それをちょっとでも楽にする方法で考えていければなと思っています。
（次回へつづく）
