今回は、ファシリテーションをテーマに開催された「testingOsaka #11」のLTでお話しした内容を文章化してお届けします。
私自身、「人が協働するための技術」としてのファシリテーションに非常に強い関心を持っています。
実際に日本ファシリテーション協会に加入して学習を深めたり、様々な人が協働し、時には対立するような場面に介入するための「プロセスワーク」やシステムコーチング®️などの技術を学んだりしてきました。
今回は、そうした学びも踏まえながら、テストと対話の関係性について考えてみたいと思います。
ソフトウェア開発の現場でよく見る場面があります。
テスター「これはバグです」 別の人は「それは仕様です」
両者はまったく同じ「一つの事実」を見ているはずなのに、認識が食い違っています。
ここで、本質的な、そして正しい議論を避けてごにゃごにゃと曖昧に話を進めてしまうとどうなるか。
結果として、顧客が全く望んでいないものが出来上がってしまったり、誰も全体像を把握できないカオスなシステムが生まれたりしてしまいます。
多くの人は思い当たるでしょう。
私は、こうした問題は「対話の力が足りないことで起きる悲劇」だと考えています。
「テストとは何か」
私の中にはある程度明確な解があります。
そのひとつとして、「テストを実行する」という行為そのものは「何らかの事実を見ること」だと定義しています。
そして、事実を見るだけであれば、私たち人間は比較的簡単に実行することができます。(“簡単”といっても専門的な技術がある上での簡単であることは言うまでもありません)
一方、私が本当に難しいと感じているのは、「その見つけ出した事実をどう扱うか」です。
事実をシステム開発に活かすためには、大抵の場合、人間の認識を通した対話や認識合わせが必要不可欠になります。
目の前に全く同じ事実があるにも関わらず、そこに違いが発生する。
それを他者に正しく伝え、同時に他者の認識を受け入れ、理解する。
その「対話の力」が不足しているがゆえに、現場で悲劇が起きてしまう。
私はこれまで、そうした光景を何度も目の当たりにしてきました。
テストケースには、必ず「期待結果（Expected Behavior）」がありますよね。
典型的なテスト実行のプロセスは、この期待結果と、実際の動作である「実際の結果（Actual Behavior）」を比較する行為です。
この場はtestingOsakaなので、少し立ち止まって考えてみてほしいです。
その「期待結果」、つまりソフトウェアの「正しさ」というのは、一体誰が決めるのでしょうか？
あるいは、本質的には、何が決めるのでしょうか？
我々が扱っているシステムは、どうあるべきなのでしょうか？
ここで、今から13年前の「テスト設計コンテスト2013 関西地域予選 招待公演」で、西康晴さんが語った言葉をご紹介します。
「テストとは納得してもらうことである」
これは、「テストを何のために行うのか」という本質を見事に言語化したものです。
参考
テストの捉え方には、いくつかのスタンスがあります。 「テストとは行動である」というスタンスもあれば、「テストとは説明である」というスタンスもあります。
そして、3つ目のスタンスとして「テストとは納得してもらうこと」というものがあります。
私はこれを支持します。
テストは、関係者間の「納得感」を作るためのプロセスの一つだということです。
だからこそ、正しく対話する技術を身につけ、それによって関係者間で「建設的に納得感を醸成する方法」を身につける。
ここでいう「対話」とは、単なる言葉のやり取りだけを指すのではありません。そこには言葉以外の様々な要素が含まれており、多様なアプローチが存在します。
これは、にしさんが直接この答えをくれたわけではなく、あくまで私の考えです。
そして、皆さんに考えていただきたいのは「納得感を醸成するプロセス」についてです。
ここで、身も蓋もない話もしましょう。
「納得感」テストの現場に限ったことではありませんよね。
私たちのソフトウェア開発のさまざまな場面、エンジニアコミュニティ、友人関係、家族、など、あらゆる場面で直面するテーマです。
誰かを論破して説得することでもなく、誰かを自分の思い通りに操ることでもない。正しい対話のあり方を模索し、多様な関与の仕方でその場を築き上げていく。 それこそが、私が考える「ファシリテーション」です。
「システムコーチング®」は、CRR GlobalおよびCRR Global Japanが所有する登録商標です。