少数の原理を活用する（その１）

概要

2011年～2015年の間に、日本科学技術連盟のSQiP関係者が週イチのペースでリレー・エッセイ風に『ソフトウェア品質のホンネ』というタイトルで記事を連載していました。全部で171回続きました。
『ソフトウェア品質のホンネ』には、多くのソフトウェア品質エキスパート（多くの人は、4回＝一カ月、書いていますので40人くらいでしょうか）の記事が並び、とても貴重なものだと思っていました。ところが、諸行無常と言いますか、SQiPのウェブサイトがリニューアルしたときに、消えてしまいました。（「復活してよ」と何度か頼んだことはあるのですが、ずっと調整中のままです……。泣　。＞＜。）
”ソフトウェア品質のホンネ”でググると、辰巳さんの記事とか、いくつか、個人的に公開しているものが読めます。

ということで、本エントリーは、2011年の夏ごろに私が寄稿した4編のひとつです。残りについても順次再公開します。

テーマである『少数の原理を活用する』について

私が、自社関連企業以外のソフトウェアテストの支援を始めたのは、2004年4月13日から、福岡にあるX社で、ということになります。それは、2003年6月の品質工学研究発表大会で「HAYST法」の発表をしたことがきっかけで始まりました。
このときは、私一人が半年間で10回に分けてHAYST法の技術的な説明をしました。当時は、HAYST法に関する書籍はありませんでしたので、今にして思うと周辺の技術を含めて丁寧に説明し、毎回宿題を出してくるといった『講義形式』で行いました。以上のように、このときは、X社の業務支援ではなく、一方的な講義だったのです。（一応、昼食会の場などで1時間程度、非公式に実業務のよろず相談を受けていましたが）
その後、2005年から、今度は、神奈川にあるY社への支援が始まりました。こちらは、吉澤正孝さん（2019年現在は品質工学会の副会長を務めていらっしゃいます）と私の2人が、HAYST法の講義だけではなくY社の実際のソフトウェアテストに対してHAYST法やそのツールを適用するという形式をとりました。
X社の時にはHAYST法の講義を中心としていた支援が、Y社の時には問題解決が中心の活動になっていました。X社の時には、HAYST法を教え活用できるようになることが目的でした。最終的にX社では自社でHAYST法のツールを開発し活用するようになりましたので目的は達成しました。
一方、Y社の場合、HAYST法はソフトウェアテストプロセス改善のきっかけであり、問題解決の手段の一つにすぎません。もちろん、因子・水準の選択の仕方や、直交表への割り付け技術の移転も実施しましたが、それよりもソフトウェアテストにまつわる様々な問題が議論されました。

ソフトウェアテストにまつわる様々な問題は、Y社の参加メンバーから語られるのですが、最初のうちは「どこから手を付けていいかわからない」とか「何が問題かわからないが上手くいっていない」という漠然なものが多かったように思います。そのような漠然とした質問に対して一緒に支援した吉澤さんは、もつれた毛糸を解きほぐすように問題を特定し、解決策を提示していました。
吉澤さんは品質管理（TQM）や、品質工学、プロセス改善のスペシャリストでしたが、ソフトウェアの専門家ではありませんでした。ソフトウェアテストの本も、MyersとLee Copelandと高橋寿一氏の本は読んでいましたが、それでも、ソフトウェアの開発経験やソフトウェアテストの実務経験はゼロに等しいものでした。にもかかわらず、問題解決の切り口やスピードは適切で速いものだったのです。

ソフトウェアについては吉澤さんよりも詳しいと自負していた私は、とうとう我慢ができなくなって、ある日、聞いてみました。
「どうして、専門家でないのに、ソフトウェアテストの問題を解きほぐして解決に導くことができるのですか？」と。
吉澤さんは言いました。「秋山君。それはね。小さくて自明ないくつかの原理を習得して、それをどんな時にでも確実に使えるように磨き上げておくんだ。そして、その正しい原理にそって考えるんだ」「たとえばどんな原理ですか？」「そうだな。たとえばQC 7つ道具で言えば、層別が一番基本で最も役に立つだろうな。層別の原理を正しく理解していなければ何かを層別するのはとても難しい」「そんなものですか」……。
この時には半信半疑でそれ以上の話はしなかったのですが、それから吉澤さんと同行するときはもちろんのこと、書籍を読んだ後、セミナーやシンポジウムで良い話を聞いた後に“今の話のなかで使われている原理はなんだろう？”、“これまで知っている原理を組み合わせるだけではダメかな？”ということを考えるようになりました。

本エントリーでは、問題解決に特に役立つものについてご紹介したいと思います。各章のタイトル（原理名）は適当です。原理は抽象化度が高いので、そのままで使えるものではありませんが、何か考えるときに原理を使うとつかわないとでは大きな差となります。
また、問題が作りこまれる前の工程に対してこれらの原理を適用すれば問題の数自体が少なくなります。

上下の原理

最初に紹介する原理は、私が“上下の原理”と呼んでいるものです。これは、何かをみたら必ず上下を考えるということです。実際には、“下”を考え尽した後に“上”を考えます。

・　下を先に考える

『下を先に考える』というのは、何だか分からないあるものを何とかしようと思った時に、まずは、下方向に分解してみるということです。
有名な問題解決方法に「なぜなぜ5回」というのがあります。これは、ある問題（たとえばバグ）が与えられたときに、「なぜそれは、発生したのですか？」と質問を繰り返していくことで原因分析をする方法です。「なぜなぜ5回」は、問題をより詳細化し、具体的にしていく良い方法です。
他にも、たとえば、XDDPのUSDMでは要求に対して「理由」をつけて要求を補強していますが、これも下方向への分解となります。なぜ、この要求が挙がったのか具体的理由を示しているからです。USDMで、要求を仕様に具体化・詳細化するのも、もちろん下方向への分解です。

さて、問題の一番の厄介な点はその複雑さにあります。上述の「どこから手を付けていいかわからない」もその一つでしょう。まずは、事実を基に下方向に問題を分解していくことによって問題の複雑さを減らし、問題を正しく理解し、誰でも対処できる小さな問題にすることが目的です。なお、本問題解決手法はデカルト思考とも呼ばれています。

・　下の次に、上を考える

下を考えて、問題を分解して問題の原因を出し尽くせば、問題解決の基盤が明らかになります。見つかった原因をつぶし尽せば、次回から同じ問題は発生しなくなるでしょう。
しかし、問題の解決方法として見つかった原因のすべてに対処することがはたして効率的といえるでしょうか？　また、その問題は解決したとしても似たような別な問題に苦しんだという経験はありませんか？　そしてなにより、下を掘り下げる問題解決手法だけでは、経験したことがない問題に対応することは困難なのではないでしょうか？？
そんなときは、下の次に、上を考えてみましょう。問題をなぜと掘り下げ終わったら、見つかった原因を眺めながら「ということは、どうしたらよいか？」と考えてみるということです。
たとえば、ある仕様に対して、その仕様が要求された背景や解決したい問題といった「理由」を具体的に掘り下げた後に、「そもそも、この仕様が果たすべき目的はどんなものだろうか？　この要求ですべてなのだろうか？？」と根本について考えていくのです。
そうすることであるべき姿を起点とした問題の理解や解決方法の立案が可能となります。問題は「あるべき姿と現状とのギャップ」といいます。もし、あるべき姿がわからなければ、どこまで改善すればよいか分からないことでしょう。

まとめ

今回は、私が“上下の原理”と呼んでいるものについて説明しました。実は、HAYST法のFV表にある「目的機能」は、仕様の上方向を考えて、その結果を記述することにほかなりません。本質的なお客様の機能の使用目的を考えて検証範囲を広げることが目的です。それは、ソフトウェアテストでは、商品がリリースしたあとの想定外の使われ方や、予期せぬ環境変化に対しても十分な品質が確保できたことを示す必要があるからです。