82号：テストのコンサルティング（前編）

≣ はじめに

「ASTERセミナー標準テキスト」についての記事ですが、第3章まで終わりましたので、今日はお休みして息抜きのnoteです。

どんなに好きな食べ物でも、それだけを食べ続けていたら飽きてしまい、別のものを食べたくなるようなものです。
たとえ名店のメニューであっても、2段重ねのうな重の松とか、食べ始めは美味しくても、途中で飽きてしまいますよね。うに丼は日本酒と合うから飽きる前に食べ終わっちゃうけど。
（ということは、蒲焼に合うお酒を探せばよいのか！👀）

ちなみに次回からはじまる第4章は「テスト技法」についてです。これまでに増して、JSTQB FLの受験生の便宜を無視して、重箱の隅をつついて行きたい所存です。（笑）

≪JSTQB FLの受験生へ≫

FL試験については、【キーワードの意味を知る】ことと【学習の目的】を果たすことが合格への近道と思います。
（アプリ等で模擬試験をして、自分が弱いところを知ることも効率よく知識を習得するうえで役に立つと思いますが、アプリは、補助的に使う方が良いと思います）
私がおすすめするJSTQB FLの学習方法は下記の通りです。

■　キーワードの意味を知る
シラバスの各章の初めにある「キーワード」、すなわち、第1章なら、「カバレッジ、デバッグ、欠陥、、、（略）、、、トレーサビリティ、妥当性確認、検証」のそれぞれについて、【自分なりの用語集】を作って暗記しましょう。JSTQBのテストについての用語は世界のデファクト標準と言えますので、暗記してしまうと仕事上でも便利です。

■　学習の目的
次に、「キーワード」に続いて記載されている「学習の目的」について、それを問題と思って、ノート（紙でも電子でも）にまとめましょう。
例えば、こんな具合です。

≪例≫
・　シラバスの「学習の目的」の記述
　　FL-1.1.1 （K1）テストに共通する目的を識別する。
・　問題に変える（4択問題にはしません）
　　　テストに共通する目的はなんですか？
・　上記問題に対する答えをシラバスから要約し、ノートにまとめる
　　　テストに共通する目的は、以下の7個。
　　　①　欠陥を防ぐ
　　　②　明確にした要件を検証する
　　　③　妥当性確認をする
　　　④　 品質が所定のレベルにあると確証する
　　　⑤　品質リスクレベルを軽減する
　　　⑥　ステークホルダーに意志決定のための十分な情報を提供する
　　　⑦　契約・法律・規制等の要件や標準に準拠していることを検証する

こうして、手を動かしながら自分なりの用語集とシラバスの要約を作ると、その過程で、合格（65点以上？）するに十分な知識が記憶に残ると思います。そして、その用語集と学習の目的の要約を、試験開始のギリギリまで、あきらめずに読み込むといいです。
なお、試験当日は、「忘れ物をしない」、「名前を書く・マーク箇所を間違えない」、「自分の経験でなくシラバスの記述から回答する」、「試験時間は目いっぱい使う（途中退室しないで何度も見直す、、、そのために問題シートの問題番号に「見直し不要マーク（×とか）」を付けておくと良いです）」、「迷ったら真っ当な（当たり前に思える）答えを選ぶ」で乗り切ってください。

ところが、周りの人のJSTQBに向けた試験対策の勉強の様子を見ていると、iPhoneの『JSTQB模擬試験』アプリ等をやり込む人が多いんですよね。あとは、『ソフトウェアテスト教科書 JSTQB Foundation』をひたすら読み込む人が多いです。
アプリの模擬試験はスキマ時間を使って楽しく学べるので、開発した方には感謝の気持ちでいっぱいですが、実際の問題（過去問非公開なので）との差はどのくらいあるのか（アプリの方が少し易しい？）、また、問題を解き続けるのは、どの程度効率が良くて、自身のスキルアップに結び付くのか知りたいです。（私の周りの人の合格者に話を聞くと「アプリでは何度もやってるので、ほぼ100点になっていました」という人が多いです）
『JSTQB教科書』は良い本ですので「読みこむのを止めよう」という気はないのですが、440ページなので（シラバスは、87ページ）、何度も読むのは少々大変です。シラバスで意味が分からないところを参考書として勉強する使い方が良いと思います。（著者は全員知り合いなので怒られちゃうかな。まぁ、こんなnote気にしないと思うけど）

ということで、今回は、「ASTERセミナー標準テキスト」を離れ、「テストのコンサルティング（前編）」についてです。

≣ 私の経験

私は、2004年から社外のテストのコンサルティング業務を行っています。2003年の品質工学会研究発表大会で、HAYST法の発表をしたところ、それを聴いた人から「詳しく教えて」と連絡が届いたからです。それが一番初めの社外コンサル経験となりました。

一番初めのコンサル先は、福岡県のとあるメーカー企業でした。前日の夜に飛行機で福岡空港に行き、博多駅まで地下鉄で2駅、晩御飯はたいてい自社の営業所の所長さんに案内されたお店で食べたのですが、どのお店に入っても当たりで素晴らしく、博多のファンになりました。

翌朝は一人でバスでお客様の事業所へ向かい、午前中に2時間くらい講義して、お客様と一緒に仕出し弁当を食べながらざっくばらんな情報交換（プチ相談会）をして、タクシー券と飛行機の回数券をいただいて帰宅。
と、そんなルーティーンでした。

当時は、「直交表？　なにそれ？？」の時代でした。また、自社で開発して使っていたツールは非売品（非公開品）だったので、そのツールをコンサル先の人が自作できる知識をお伝えする（※）ことが主目的でした。お客様の業務改善はもっぱら昼食時のプチ相談会で行いました。

（※）具体的には、「有限射影幾何と原始既約多項式と直交表」、「線点図の作り方と活用法」、「割付テクニック」、「禁則回避アルゴリズム」、「組合せテスト結果の統計解析方法と業務への展開方法」などについて全10回（各2時間なので計20時間程度）で講義しました。
半年後くらいに「ツール完成しました」と連絡を受けてほっとした記憶があります。お客様は、とてもまじめで一生懸命な人たちでした。
お伝えした知識は今となっては、「マニアックで説明する機会もなく消えゆくさだめの技術」なのだろうなと思います。
知っていてもおそらく「直交表をベースとした組合せ表作成ツール」の開発位にしか役に立ちませんし。

あれから16年経ちました。

私の希望として「コンサルティングは同時期並行最多2社で、期間は半年」というのがあります。このルールに則ると、年4社のペースとなりますが、リピートがありますので、64社とはならず50社くらいにお邪魔しました。

そのなかで、たまに「コンサルティングって、何をするんですか？」と質問を受けることがあるので、自分が経験したことを今回書きます。

ですから、「こんなのコンサルじゃない」とか、「それダメなやりかただよ。間違ってる」と思われたり、叱りたい気持ちになるかもしれませんが、凹むので叱らないでください。そもそもコンサルタントによってコンサルティングのアプローチは大きく違うようです……。

高度な技術を売るコンサルタントもいれば、個人や組織の力を引き出すコンサルタントもいます。新米のコンサルタントもいれば、ベテランもいます。
技術の売り方にしても自学習が困難な知識（例えば、上に書いた有限射影幾何）の解説を高橋 磐郎氏の『組合せ理論とその応用』の輪読を通して教授するタイプの（大学の研究室の輪読のような）コンサルタントもいれば、お客様のレベルに合ったテキストを自作して教えるコンサルタントもいます。

そのほかのタイプとして、海外の流行りの技術の伝道師のようなコンサルタントもいます。
また、「XX認証取得コンサル」がいます。よく聞くのは「ISO 9001認証を取れ」と言われて困ったスタッフがISO 9001認証取得コンサルティングを生業としている会社に頼むと、何をどうしたら良いのか、イチから十まで教えてくれる人を派遣してくださいます。（近頃は良い人が多いそうです。）

人としての切り口としては、「偉そう」、「腰が低い」、「口数が多い・少ない」、「あ○○い（笑）」などがあります。

誤解されないように書きますが、これらのコンサルタントが持つ特徴は、良い・悪いではなく、お客様とのマッチング（相性）です。ですから長期契約を結ぶ前に有償で数回のお試しコンサルをお願いするのが良いと思います。

≣ コンサルティング業務（コンサルを求める心理）

上に書いた通り、さまざまなタイプのコンサルタントがいますが、コンサルを求めるお客様（クライアント）の心理は大きく2つのタイプに分けられるように思います。「内部要求」と「外部要求」の2つです。

そうそう、今、自分で書いていて思ったのですが、コンサルタントの手口（好む基本的な手法！？）の一つとして、MECE（もれなくダブリなく分類する）があります。

「『内部要求』と『外部要求』の2つ」と言われると、「確かに内と外の2つに世界は分かれるよなあ、正しいことを教えてくれそう」と思わせるテクニックです。
似た手口に「XXはYYです。その理由は３つあります。イチ、なんとか。ニ、かんとか。サン、どうたら」があります。
実は「その理由は３つあります」と言った時点では何も思いついていない場合すらあるのですが、それまでの議論をまとめれば、2つはすぐに見つかります。全く知らない3つをいうよりも、知っている2つを混ぜたほうが喜ばれます。（議論の要約ができない人は、コンサルタントには向いていないかもしれません。「議論の要約」は練習すればなんとかなるようなものでもないと思います……。練習方法はあるようですが、どうかなあ？）
問題となるのは、「ニ、かんとか」と言った時点で、3番目だけでなく4番目の理由を思いついてしまった場合です（よくあります）。
その場合は、3番目と4番目を一つにまとめて「サン、どうたら」と言います。（3番目に言うことは、それまでの議論に出ていない、みんなを「ハッとさせる」ものにしてください。）

ですから、たまに書記さんが「すみません。メモ取れなかったのでもう一度お願いします」というと、「えっと、なんだっけ？」となるコンサルタントがいます。このテクニックを使うときには、自分も言うときにキーワードだけこっそりメモっておくといいですよ。

■　内部要求

内部要求とは、コンサルを求めた本人が「漠然とした不安」を抱えている場合をいいます。

例えば、これまでの商品開発では、納期も守ることができたし、リリース後に重要不具合も発生していない。しかし、「それはたまたま幸運が重なっただけなのではないか？」、「このまま放置しているといつか取り返しがつかないことが起こる」気がするという、“手放しで喜んでいられない漠然とした不安を抱えている状況”からコンサルの力を借りたいというケースです。

他にも「業務分析を実施し、対策案を立てて対策中だが不安なので、自分たちが選んだ（もしくは考案した）対策は客観的に見て正しいかどうかを知りたい。」等のバリエーションがあります。

いずれにしても「現状を良く（改善）したい」という明確な動機がありますので内部要求から依頼を受けたコンサルティングはしやすいものです。

■　外部要求

外部要求とは、経営者・政府・顧客等への答えを用意したい場合をいいます。言い換えると外からの要求へ対応したいというケースです。

例えば、社会インフラを支えている商品やサービスのソフトウェアが不具合を起こしてしまうと、担当省庁から「再発防止についての報告書」を求められることがあります。そのようなときに「コンサルタントの力でも借りようか。そうすれば業務を止めずに済むし、楽ができるから」という話になることがあります。

楽になるどころか、全部コンサルタントに任せて、コンサルタントから要求があったことだけに対応すればよいというメンタリティに陥りがちです。

再発防止策は問題を起こした（または見逃した）本人が作るのがベストですが、一般にコンサルタントはドキュメントを作って説得力があるプレゼンをするのが得意ですから要求をした「外」の誰かに対して「うん、再発防止策これでいいよ」と言ってもらえます。

でも、その再発防止策は、いわゆる“絵に描いた餅で”実行されなかったり、"換骨奪胎された何か"が実行されたりします。

いずれにしても、現場の改善のモチベーションが低い、外部要求から依頼を受けたコンサルティングはしたくないものです。

≣ コンサルティングの仕事のどこがおもしろいのか

コンサルタントは正直にいって、“うさんくさい職業”だと思います。だから自己紹介で「テストのコンサルタントをしている秋山です」ということが嫌で、いやで仕方ありませんでした。特に現場のエンジニアさんにはコンサルタントというだけで、警戒されますし。

だから、「コーチングしています」とか「テストの講習をしています」とか「テストのお手伝いに参りました」とか、そんなふうに言っていました。

でも、そのうち（10年くらいかかったかなァ……）、

「コンサルティングとは、お客様を言い負かすのではなく一緒に考えて"共感して"、両者の意見を超える"良い答え"を作ること。そして、お客様を笑顔にさせスッキリさせる仕事」

という考えに変わってきて、そのころから「コンサルタントと名乗ってやってもいいか」←　偉そう（笑）、、、と思うようになり、コンサルティングの仕事も面白くなってきました。

≣ 終わりに

今回は、「テストのコンサルティング（前編）」について書きました。

実は、このネタは1回で書くつもりだったのですが、長文になってしまいましたので、いったんここで終わります。

今回、書こうと思って書いていないことは、「なぜコンサルタントは、うさんくさいのか」、「コンサルタントの目線」、「コンサルタントが描く”図”・”グラフ”・”表”」です。

書こうとしたことの半分も書けていないので、続きは連載の4章が終わったときに書きます（たぶん）。