JaSST Review'19の見どころ紹介3「『違和感のつかまえかた』 ～組み込みシステムの開発者（テスター）としてやっていること～」 #JaSSTReview

JaSST JaSSTReview 勉強会

はじめに

11/1にJaSST Review'19 が開催されます。

www.jasst.jp

そこで、何回かにわたり、JaSST Review'19での見どころを紹介します。

深谷さん(miwaさん)のセッション紹介

今回紹介するセッションは、miwaさんによる講演「『違和感のつかまえかた』 ～組み込みシステムの開発者（テスター）としてやっていること～」です。

セッション内容として、下記のように書かれています。 *1

みなさんは「なんとなくだるい」「寒気がする」「熱っぽい」というような違和感を感じた時、どうしますか？症状がひどくならないよう行動を変える方が多いのではないでしょうか。

開発の現場で感じる違和感も同じです。違和感は『注目すべきシグナル』です。より良い製品を作るため、みなさんは行動を起こさなくてはなりません。

本セッションでは、私がいつ、どこで、何を見て違和感を感じているのかを紹介します。また違和感をつかまえるために大事なこと、違和感をつかまえやすくするコツや工夫についてもお伝えする予定です。

今よりももっと違和感に敏感になりたい、違和感をもっと製品開発に活かしたい、そんな方の参考になればうれしいです。

見どころ

miwaさんがブログなどでも発信している*2「違和感」に着目して発表する点が見どころです（勝手に思っています）。

普段から違和感を言語化することを大切にしている、miwaさんならでは発表になると思います。

レビューツールだけに囚われない、「現場で感じる違和感」をどのように発表で伝えてくれるのか楽しみです！

おわりに

JaSST Review'19はまだまだ申し込み受付中です！（直球な宣伝）

www.jasst.jp

今まで無意識的に行なってきた内容を改めて考え直すきっかけになると思うので、違和感をつかまえて製品へ活かす方法が気になっている方は、ぜひ11/1に赤坂でmiwaさんの講演を聞きに来てください！

*1:JaSSTソフトウェアテストシンポジウム-JaSST Review'19-タイムテーブル より

*2:miwa719.hatenablog.com

JaSST Review'19の見どころ紹介2「レビューツールの利用とプロセスのあり方」 #JaSSTReview

JaSST JaSSTReview 勉強会

はじめに

11/1にJaSST Review'19 が開催されます。

www.jasst.jp

そこで、何回かにわたり、JaSST Review'19での見どころを紹介します。

岡野さん（あさこさん）のセッション紹介

今回紹介するセッションは、あさこさんによる講演「レビューツールの利用とプロセスのあり方」です。

セッション内容として、下記のように書かれています。 *1

ソフトウェア開発の中で、レビューは多くのプロジェクトで実施されます。ツールを利用される方もいらっしゃるのではないでしょうか。「なんでこのツールなんだっけ？」のような疑問を持ちながら利用していることはありませんか？

その疑問・違和感は、なぜおきているのでしょう？

利用したいシーン・動機（問題・課題）に合致した目的・用途ごとにレビューツールの強み・弱点をしり、選択・利用する必要があります。

私が所属するSEPGでは、ツール利用の推進も行っております。

その際にどのような点を考慮しているか、現場ではどのような課題が多いのか、についてお話させていただきます。

レビューだけではなく、他のプロセスでも共通する考えでもありますが、レビュープロセスに照らし合わせて、一緒に考えていきましょう！

見どころ

レビュー利用の推進をするにあたり、ただ「このツールを使え」ではなく、どのような点を考慮しているかを言語化して発表する点が見どころです（勝手に思っています）。

去年登壇して頂いた白水さん*2もそうですが、レビュー利用に関して企業で組織的に行っていることを言語化して伝えていただく機会は非常に少ないので、貴重な発表だと思います。

私自身もそのような発表を聞くのが今までなかなか無かったので、非常に楽しみです！

おわりに

JaSST Review'19はまだまだ申し込み受付中です！（直球な宣伝）

www.jasst.jp

他のJaSSTでも積極的に発表されている方で分かりやすいと思いますので、レビューツールをどのように考えて導入すれば良いか気になっている方は、ぜひ11/1に赤坂であさこさんの講演を聞きにきてください！

*1:JaSSTソフトウェアテストシンポジウム-JaSST Review'19-タイムテーブル より

*2:JaSSTソフトウェアテストシンポジウム-JaSST Review'18-レポート より

JaSST Review'19の見どころ紹介1「文書校正におけるReviewと活用するための分類およびルール化」 #JaSSTReview

JaSST JaSSTReview 勉強会

はじめに

11/1にJaSST Review'19 が開催されます。

www.jasst.jp

そこで、何回かにわたり、JaSST Review'19での見どころを紹介します。

津田先生のセッション紹介

最初は、筑波大学の津田先生による講演「文書校正におけるReviewと活用するための分類およびルール化」です。

セッション内容として、下記のように書かれています。 *1

ソフトウェアは多種多様であるため，各工程の成果物は組織やプロジェクトによって様々に表現されている．また，レビューするソフトウェア関係者の背景知識やスキルもばらばらなため、指摘事項も一定ではない．そのため，ソフトウェアレビューに関するノウハウには規則性が乏しく，ルール化が困難であり，多くは個人の経験と勘という暗黙知として蓄積されている．

そこで本講演では，規則性に乏しくルール化が困難な人間の文章作成における"間違い"をルール化することで，文書校正支援システムを実現したプロセスを紹介する．このプロセスで実現した仕組みは，Microsoft Wordなどの中でスペルチェックシステムのベースとなっている．この開発における最大の課題は，"間違い"という偶発的であり意図としない事象を形式化することであった．このノウハウを紹介することが，ソフトウェアレビューの知識化の一助となれば幸いである．

見どころ

文書校正支援システムを実現したプロセスが見どころです（勝手に思っています）。

Microsoft Wordなどで文章を書くと、下記画像のように赤波線が入ると思います。

f:id:nihonbuson:20191007200918p:plain
Wordでよく見る赤波線

津田先生はこの赤波線のシステムのベースを開発した人です。

システムを作った背景や、どのようにしてこのシステムを作ったのか、過去の経験からどのようなものをシステム化できると考えられているのか、などなどを聞ければと考えています。

おわりに

JaSST Review'19はまだまだ申し込み受付中です！（直球な宣伝）

www.jasst.jp

津田先生のお話を一度聞かせていただいたのですが、ご自身の経験の話もそこからの思考の話もすごい良かったので、興味がある方はぜひ11/1に赤坂で講演を聞きにきてください！

*1:JaSSTソフトウェアテストシンポジウム-JaSST Review'19-タイムテーブル より

技術書典7で頒布しました＆2F→3Fへの移動経路の話 #技術書典

目次

はじめに

先日、9/22に池袋サンシャインシティで行われた「技術書典7」で本を頒布しました。

techbookfest.org

本記事では、今回の頒布物の話と、2F→3Fの移動経路の話をします。

頒布物

今回私は、合同誌と個人誌を執筆しました。

合同誌

技術書典5,6に続き、Crabinkとして『300 Multiple Choices』という、複数人のテストエンジニアが書いた合同誌第3弾を頒布しました。

f:id:nihonbuson:20190927020319p:plain
300 Multiple Choices

書かれている内容のラインナップとしては以下の通り。

  • アジャイル
  • 開発者に伝えるテストの研修
  • ファシリテーション
  • プロジェクト運営
  • テスト会社への発注
  • リスク分析
  • テスト自動化
  • テスト計画
  • QA活動
  • 海外で働くことについて

非常に多岐に渡っています。

おそらく、今までのCrabinkで一番テスト要素が多いんじゃないかとの噂です。

まだ、物理本が余っていますので、また別のイベントで頒布するかもしれません。

個人誌

そして今回は、個人誌も頒布することにしました！

タイトルは『事例で学ぶ ソフトウェアテストと品質』です。

f:id:nihonbuson:20190927020953p:plain
事例で学ぶ ソフトウェアテストと品質

こちらは100部用意したのですが、2時間足らずですべて頒布しました！

頒布終了後も「もう無くなっちゃったんですか？」「電子版は無いんですか？」「再販しないんですか？」と多くの方からお声をかけていただきました。申し訳ないと思いつつ、そのように言ってくださり嬉しい限りです。

何よりも印象的だったのは、

「こんな表紙の言葉なんてただの煽りで、中身は大したこと無いんだよ」

と話していた2人組が、本の中身を読んだ上で購入に至ったことです。*1　眉唾物で読み始めた人にも買う価値があると感じてもらえたのはすごい嬉しいです！

少し加筆修正を加えた上で、より多くの方に届けられるように検討したいと思います。

2F→3Fへの移動経路について

我々のサークルの位置

SNS上でも話題になっている2F→3Fへの移動経路ですが、我々のサークルは一番その状況を把握していたかもしれません。

なぜならば、我々のサークルは一番、2Fから3Fへの移動待機列のところに一番近かったサークルだからです。（下の地図の赤矢印の部分は我々のサークルです）

f:id:nihonbuson:20190927022957p:plain
サークルの位置

待機列の状況

2F→3Fへの移動待機列は、図のオレンジ領域の部分に形成していました。

元々、「入場待機スペース（Cホール）」と書かれた部分全体が、移動の待機列として用意していたスペースだと思われます。

しかし実際には2列×25名程度の塊が2つ分ぐらい（計100名程度）しか、混雑している時でも並んでいませんでした。

動線の影響

そして、この導線の煽りを我々のサークルも少しだけ受けました。

本来、出口もしくは移動待機列へ通る動線を地図上で見ると、必ず我々のサークル前を通ります。

しかし実際には、青矢印の部分が開けていたため、我々のサークル前を通らずに出口へ向かえるようになっていました。

なので、我々のサークルを見ないで帰ってしまう人が多かったことが分かります。

それと同時に、やはりあの動線では、2F→3Fへの移動待機列には気付くことすらできなかったのではないかと考えられます。

おわりに

今回は運営も混乱し、一般参加者も目の前を通らないという条件の中、個人誌は無事に頒布終了になりました。

次回はまた改善された技術書典になることを期待しておりますし、そこでまた頒布できるように頑張りたいと思います！

*1:ただ、この2人組が購入した瞬間、私は残念ながら離席していたので、売り子をしていた人に後から聞いた話ですが…。

7payの会見から学ぶソフトウェアテストの7原則

技術

目次

はじめに

話題になっている7payの話を、ソフトウェアテストの知見（ソフトウェアテストの7原則）を使って、反面教師として次に活かせる形にして書いてみます。

ただし、「これを知れば事前に防げる！」と主張したいのではなく、（エンジニアも経営層も）意識して臨まないといけないという意味も込めて書きます。

この記事の元ネタ

教訓の元にした7pay会見の記事はこちら

www.itmedia.co.jp

ソフトウェアテストの7原則の説明はこちら（昨年に改定された版を引用しています）

【リンク】ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J02

教訓1:「脆弱性はなかった」という発言


セブン＆アイの清水健執行役員は「あらゆるサービスについて、事前にセキュリティ審査をやっている。7payもきちんと確認したが、脆弱性（ぜいじゃくせい）はなかった」と繰り返し強調した。

この部分から活かせる教訓は2つ。

ソフトウェアテストの7原則の1.テストは欠陥があることは示せるが、欠陥がないことは示せない

テストによって導き出せるのは、欠陥があることのみです。悪魔の証明ってやつですね。

上記の発言が「（セキュリティ審査の中では）脆弱性がなかった」という報告であれば良いです（結果としては良くないけど）。

ただし、「セキュリティ審査はやった。だから脆弱性はない」という主張であれば、明確に「テストは『欠陥があること』しか示せない」という原則を理解していないことが分かります。

ソフトウェアテストの7原則の7.「バグゼロ」の落とし穴

「バグがない＝素晴らしいとは限らない」ということです。

特に今回のように、「セキュリティ審査では1件も問題が出なかった」という報告は（特に経営陣は）安心材料になったのかもしれないです。

ただし、そこには落とし穴があり得るという理解が必要です。

教訓2:仕様・設計の段階での指摘


そもそも「明らかに問題がありそうな仕様・設計」について、現場担当者レベルで誰も気付かなかったのかという疑問は残る。

この部分から活かせる教訓はこれ。

ソフトウェアテストの7原則の3.早期テストで時間とコストを節約

テストに関しては初期部分から入ることが重要です。

今回の場合は仕様策定や設計段階で気づくべき内容を、リリース後まで放置していたためにこれだけ大ごとになってしまっています。

仕様レビューの段階で「これってどうなの？」という話し合いがあれば、きっと小1時間で修正できたでしょう。*1

（「現場は修正したかったが、政治的なことがあって…」とかは邪推できますが、一旦その話は置いときます）

教訓3:決済系のサービスに対するテスト


今回の大規模な不正アクセス被害で多くの利用者の信頼を失ったのも事実だろう。「スマートフォン決済全体の信頼を損なう出来事ではないか」と指摘されると、小林社長は「（今回の件は）残念な事象。スマートフォン決済は安心、安全、便利と思ってもらえるよう、早急に立て直したい」と答えた。

この部分から活かせる教訓はこれ。

ソフトウェアテストの7原則の6.テストは状況次第

全ての製品・サービスにおいて同じテストを当てはめれば良いのではなく、状況によって変わっていきます。

生命を扱う製品・機能と、使いやすさを追求するだけの製品・機能では、テストの工数や方法なども変わっていきます。

今回の場合は決済というお金を扱う部分が含まれているにも関わらず、テストがきちんと行われていなかったように思われます。

セブンイレブンの場合、2007年に「お取り寄せ便」というサービスを開始しています。（現在のサービス名は「セブンミール」）

7-11net.omni7.jp

しかし当時のクレジットカード決済はそこまで使われていたとは思いにくく*2、お金を取り扱っているという意識は少なかった（商品をお届けするためのサービスという位置づけだった）のではないでしょうか？

そういう状況であれば、乗っ取りが発生しても各ユーザーに甚大な被害は起きなかった可能性が高いです。（いや、個人情報とかがあれば、それはそれで問題だけど）

決済というお金を扱う部分も含めていることで、もっとその部分に関して重点的に考えるべきではなかったかと思います。*3

おわりに

今回は7payの会見を元に、ソフトウェアテストの7原則に当てはめて書いてみました。

とはいえ今回の記事は、こうやって事象が起きた後ならば、いくらでも書ける内容であることは確かです。

「はじめに」でも書きましたが、あくまでも今回の事象を教訓に自分の製品でもあてはめて考えてみたいです。

そして、実際に開発・テストをするのは現場とはいえ、経営層も含めてソフトウェアテストの7原則を意識すべきだと思います。

【リンク】ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J02

*1:えっ？なんでレビューの話をしてるの？と思われる方もいるかもしれませんが、ISTQBのシラバスでは静的テスト活動の1つとしてレビューが書いてあります。

*2:経済産業省の資料によると、2008年当時クレジットカードの支払額は全支出の12%程度でした。また、支払額での比率のため、セブンイレブンの利用者層はもっとクレジットカード利用率が低かったのではないかと思います。

*3:そもそもオムニ7の時点で…という意見はまさにその通りだと思いますが、先述の「セブンミール」から開発が続いていた場合、お金を扱う意識がそこまで無いまま作っていった可能性があります。あくまで推測ですが。

JJUG CCC 2019 Springで色々な工夫を凝らしつつ、テストについて発表してきました！ #jjug_ccc #ccc_e4

勉強会 技術 発表 JJUG

5月18日に開催された「JJUG CCC 2019 Spring」で「テストエンジニアが教える JUnitを書き始める前に考えるべきテスト」というタイトルで発表してきました！

www.java-users.jp

発表をするにあたり考えていたことや工夫したことを記事にしておきます。

目次

発表資料

speakerdeck.com

テストエンジニアなのにJJUGに発表しようと思ったきっかけ

主に以下の2点。

  • PHPカンファレンス福岡でQAの知り合いであるリナさんがほぼ毎年登壇しており、「QAでも言語系カンファレンスに登壇してもいいんだー」と思ったから underscore42rina.hatenablog.com

  • XP祭りの運営もされている山口さんが、「アジャイル系のイベントにテストエンジニアが参加してくれて嬉しい」と言っていたので、テスト系以外のイベントでも受け入れられるんだーと思ったから

発表前

CfPが採択されたものの、まさかの一番大きな会場に割り当てられました…！

事前アンケートで「聞きたい！」と言ってくれた方が多くいらっしゃった結果なので、嬉しさ半分、しっかりとしたものを発表しなきゃという想いが半分でした。

めっちゃ緊張してました…ｗ

なにせテスト系のイベントではなく開発系のイベントなので、聴講者はどんな雰囲気・目的で聞きに来ているのか分からなかったからです。

また、「本当にこんなコンテンツを聞きに来てくれるのだろうか…？」と思ってましたが、結局、私の発表は280名の満席に近いセッションとなりました。圧倒的感謝…！

発表時の仕掛け

おそらく聴講者の皆さんが普段聞き慣れていないであろう「テストの話」を、ただ発表するだけではつまらないだろうと思い、2つの仕掛けをしました。

仕掛け1. menti.comでたくさんの回答を貰うための仕掛け

今回の発表では menti.comを利用し、聴講者の皆さんとインタラクティブな発表を目指しました。

www.menti.com

より効果的かつ盛り上がるコンテンツにするためには、何よりもできるだけ多くの聴講者にこのサービスを利用してもらう必要があります。

そのために色々な工夫をしました。

工夫その1. 講演前、講演中にサイトへの誘導を行う

上記のようなツイートを行い、また講演開始前に会場でもアナウンスを行いました。

そして講演が始まってからも、私の自己紹介のスライドの一番上に常にサイトへのアクセス方法を書いておくようにしました。

工夫その2. 最初は簡単な操作を要求することで入りやすい状況を作る

今回、menti.comでは3つのコンテンツを用意しました。

  • コンテンツ1. ハートをクリックする
  • コンテンツ2. 二者択一のアンケートに答える
  • コンテンツ3. 自由記述のアンケートに答える

いきなり自由記述のアンケートに答えるのは難易度が高いです。

そこでまずは「ハートをクリックする」という単純な操作を体験してもらうことで、「自分が手元で操作した行動が、こうやって投影している部分に反映されるのか」と体験してもらいました。

次に「二者択一のアンケートに答える」ことで、「アンケートに答えると投影している部分に反映される＝アンケートに答えると何かしらのリアクションが返ってくるんだ」と体験してもらいました。

こうすると「自由記述のアンケートに答える」ときには、参加者の多くが答えやすい状況になっています。

工夫その3. その場で変化の実況を行う

工夫2で書いた「何かしらのリアクションが返ってくるんだ」を増幅させるために、あえて大げさにリアクションをしました。

例えば、以下のように言ってました。

  • 「ああっ！どんどんハートが増えてくる！100名を超える皆さんに参加してもらえてますね！ありがとうございます！」（コンテンツ1の時）
  • 「おっ！圧倒的に開発者の方が多く、テストエンジニアが今回の参加者の5%ぐらいしかいない！つまり私はアウェーの中で発表しているということですね」（コンテンツ2の時）
  • 「おおー！色々書いていますね！『品質保証』なるほどー！『バグを見つけるため』そうですよねー！」（コンテンツ3の時）
結果

実に多くの方にmenti.comを利用していただきました！

それぞれのコンテンツ結果は以下のようになりました。

自由記述の時（コンテンツ3）でも、216名の方に回答いただけており、離脱率が少ない状態を保たれていることが分かります。

f:id:nihonbuson:20190520004655j:plain
二者択一の結果

f:id:nihonbuson:20190520004732j:plain
自由記述の結果

また、menti.comを使うことで、聴講者の皆さんがどんな心持ちで聞きに来たのか把握することができました。

こんなことも一発で聴講者にも分かってもらえますｗ

仕掛け2. ペアワークで活発な意見を出してもらうための仕掛け

今回はmenti.comの利用だけでなく、講演中にペアワークを入れてみました。

今までもペアワークを取り入れた講演をしたことはあったのですが、以下の2つの条件により、今までのペアワークの講演の中で最難関でした。

  • 参加者数が300名弱と、過去最多
  • 講演時間が45分間しかない

そのため、これに対してもいくつか工夫をしました。

工夫その1. 講演前に隣の人と自己紹介をしてもらう

隣の人がどんな人か全く知らない状態でペアワークを始めても、きっと会話が弾まないでしょう。

そこで、講演開始前に会場でアナウンスを行い、隣の人と自己紹介をしてもらいました。

特に、Javaは様々な現場で使われていることが多い言語ですので、普段の業務は何をやっているのかについても話してもらうことにしました。

工夫その2. 自己紹介しやすい空気を作る

いきなり「普段の業務について話せ」と言われてもなかなか話しづらい人もいるかもしれません。

そこで自己紹介しやすい空気を作るために、「自分の名前と一緒に普段の業務についても話してみてください。あっ、ただ例えば『実はCIAのスパイなんだ』みたいな言えない事情は言わなくて大丈夫ですよー」と言ってみました。

そうすることで、「あんな変なことを言ってもいいんだ」と、自己紹介に変なプレッシャーを感じなくする効果があると思ってます。

結果

結果として、ペアワークに価値を感じてくれた方が何名かいらっしゃったようです。

発表後

menti.comの利用、そしてペアワークの実施など、様々な仕掛けを45分間でしてみました。

結果として、このセッションやテストに対してポジティブな感情を抱いてくれたようです。

もしもテストに興味を持った方がいましたら、ぜひWACATEにも参加してくださいね！

wacate.jp

また、明日はWACATEの体験版となる勉強会も開催予定ですので、気になる方はぜひ！

wacate.connpass.com

おわりに

最初は「言語系カンファレンスにテストの話を発表するのはいいのかな…？」と不安でしたが、色々な仕掛けをすることで、概ね良い結果になったと思います。

ただしこのような結果になったのは、wi-fiを設置してmenti.comに繋ぎやすい環境だったり、講演開始前にもかかわらず色々なアナウンスを快く受け入れてくださったJJUGのスタッフの皆さんのおかげだと思っています。本当にありがとうございました！

今回言語系カンファレンスでの発表は初めてでしたが、他の言語系カンファレンスでも発表していきたいと思います！

また、今回は45分という短い時間だったので一部しか話せませんでしたが、「もっと聞きたい！」という方は、お気軽にご相談ください。twitterのDMでOKです！

個別・会社内・勉強会問わず相談に乗りたいなと思ってます。お待ちしております！

「ファシリテーション101」聴講レポート

技術 勉強会

先日、社内で澤さんによるファシリテーション講座があり、「SNSでの投稿自由」「ブログでの公開自由」という話を頂いたので、ブログに公開します。

目次

発表者

  • 澤 円
  • 日本マイクロソフト テクノロジーセンター センター長
  • インターネットラジオ「Voicy」配信中
    • 現在、379日連続で配信している。
    • 普段は文字起こししてからしゃべる。
    • 喋っている途中でVoicyの収録をしたいと思っている
      • 途中でスマホを取り出すけど気にしないでください。
    • 今回の発表の一部も既にUPされています。

voicy.jp

講演内容について

  • 講義は60〜70分
  • 完全にスクラッチで資料を作成した
    • ある意味ベータ版
  • 質問したい場合は止めてほしい
  • 今回はファシリテーションに関する情報をお伝えしたいと思う

ファシリテーションとは？

  • 議論を整理する人
  • Wikipedia
    • ファシリテーション（英: Facilitation）は、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の１つ。
  • リーダーとしての振る舞いが求められる
  • ただの司会者ではない

田原総一朗はファシリテータか？

  • 朝まで生テレビの田原総一朗がファシリテーターだと思う人？違う人？
    • 会場の意見…感想を喋っている・自分の意見を喋っているから違う
  • 自分の意見を言うからというより、求められる結果が違うから。
    • テレビ映えするように煽っているだけ。
    • 見ている人がいる時点でちょっと違う
  • やっている行為はファシリテーターに近いが、皆さんに求められているものとは違う

ファシリテーションに必要なこと

  • 私なりに考えたり感じたことを中心に話す
  • まずはゴールの共有が大事

会議が多すぎる国、日本

  • 日本は会議多すぎ
    • 会議をすること自体は悪くないが、ゴールの共有がない会議が多い
  • 報告の会議が多すぎ。起きていることは会議にすることはなく、どこかにまとめれば良い
  • 報告のために集めず、その先のために会議をすべき。

ゴールのために、ビジョンを決める。

  • 北極星を見つけてから出港する。

  • ココで言っているのはゴールではなく、方向性だけ

    • 方向性とゴールの違いの例
      • 方向性…デザインについて決める
      • ゴール…デザインのラフ案について決める

  • ファシリテーションの先にゴールが見える。

    • 最初からゴールが見えているわけではない。
  • マイルストーンを決めるだけで、形まで決めるのはファシリテーターのしごとではない。
  • 方向性を決めるのがファシリテーターのしごと
    • それをしないと、みんなが違う線路に乗ってしまう。

テキトーに線路を敷設させないことが大事。

  • 進んでいったときに、戻してあげるのもファシリテーターのしごと
  • 議論が発散することはよくあることだと思うが、予め決めたビジョンに従って元に戻す
  • なので、ビジョンは言葉に落としておくことが重要
  • 漠然と、ぼんやりと、はダメ。

会議室を出た後に、同じ絵を描けるようにする。

  • 言語化できていないと、再現性がないものになってしまう。
  • 本人の解釈によって、全然違う情報が伝達されてしまう。

「議事録が大事」ではない

  • 議事録を取るのが大事なのではない。
  • 議事録を取るとしても、事細かに取る必要はない
    • そしたら録音すれば良い
  • キーワードを残しておけば良い。

ゴールは未来にあることを確認する

  • エンジニアなど何か作る人達は、「今無いものを作るようにする」「今あるものを良くするようにする」ということが仕事。
  • なので未来の話に時間を使うべき
  • エンジニアの場合、限られた人生の中で最大のものを作る必要がある
  • MTGではAsIsの話はしない
  • 最終的にどういったものがあればよいのか言語化する。
    • これを共通認識にしないといけないし、ファシリテーターはそちらに常に軌道修正しないといけない。

過去の話を議論しがち

  • 議論で話すのは、殆どが過去の話になっている。なぜなら、過去の経験を元に話すから。
  • しかし、「ゴールは未来だよね」ということを示す必要がある。
  • 徹底的に未来の話をしよう。
  • 今までの話で議論している暇は無い
  • みんながなんとなく思っている共通認識を蒸し返す必要はない。

傾聴のマインドセット

  • ふるまいとして必要になるのが、傾聴というマインドセット
  • ファシリテーターはとにかく傾聴する
  • 傾聴とは、音として聞くのではなく、アイディアを探すために聞く
    • アイディアの種を探して、こういうこと？と質問すること
    • 決めつけることではない
  • エンジニアリングにするヒントを聞く
  • そのためには相当集中して聞く必要がある
    • 常に質問をする体勢になる。
    • さり気なく質問をする。
  • ぼんやりと聞くのと集中して聞くのは違う。

決めつけることをしてはいけない。

  • 決めつけるならば、「最初からお前がやれよ」となってしまう。
  • これは本当に意識しないとすぐに忘れる。

参加者が混乱していたら整理する

  • やっているうちに、参加者に理解度の差が出てくることがある。
    • 過去の経験差などが原因。
  • そのために、ファシリテーターは表情を常に確認することが大事。
  • 全体の理解度を常に確認する
  • せっかく集まっているなら、同じ理解度になるようにする
  • 少なくとも、MTG内で語られているのは同じ理解度になっていること
  • 参加者自身が「分かっていないことが分かっている」ようになれば最高
    • そこについて勉強できるから
  • 「分からなかったらこれだけメモっといて」「このURL先を読んどいて」「○○さんに聞いといて」とヒントだけ渡す
    • ここで説明しちゃうと、分かっている人は内職を始める

発言量の調整

  • MTG時間、バッファ時間、参加人数という3つのパラメータがある
  • (MTG時間-バッファ時間)/参加人数=一人あたりの上限持ち時間
    • これが最大値。
  • バッファ時間を抜く人がいるが、ちゃんと考慮する必要がある
    • バッファ時間とは、仲裁や考えをまとめる時間など
  • バッファ時間はどれぐらいの割合か、というのは絶対的なものはない。
    • MTG参加者の経験によって違うから。

MTGを早く終わりにして、時間を返す

  • 早くMTGが終わりそうな場合は、そのまま早めにMTGを終わらせる。
  • 外資系の企業の場合、MTG時間を1時間とって45分で終わったら「15分返すね」という風に言ったりする。
  • MTGはお互いに時間を借りているという認識を持つこと。
    • 物事を借りている場合は、基本的に大事にするし、早めに返しますよね？それと同じ。

  • このマインドが起きると、仕事がどんどん圧縮される。

  • 別に、喋り始めたときにストップウォッチを出す必要はない。

    • あくまでも目安で良いが、それを考えておくことが大事。
  • 20人が出たMTGが30分だった場合、1人あたり1.5分になる。
  • 喋る人と喋らなくなる人が多くなる。
    • 喋らない人は会議室にいる必要がない。大いなる機会損失に繋がるので、あとで共有すれば良い。
    • プロセスを知る場合は必要かもしれない。

  • ただし、「とりあえず参加してもらう」というマインドだったら「とりあえず呼ばない」にしてください。

  • Emailが無い時代と同じMTGをする昭和な会社がまだまだ多い。

  • 時間というパラメータを軽視しているからそうなる。

黙ってもらうのも大事な仕事

  • 「黙れ！」というのは、一発で黙ると思うが、人間関係が悪くなる
  • 黙らせ方も大事。「一人あたり○分だから、気を付けてね」と予め言っておく

「ぼっち」を作らない

  • 本来だったら発言して欲しい人が喋らない状態を作らない

間違って呼んだら帰す

  • また、間違って呼んでしまったら、帰してあげる

    • 自分から「関係ないから退室しますね」というのはなかなか難しい。
    • アメリカでは「なんでこんな会議に呼んだの？」と怒る人がいるぐらい。

  • 最近は会議そのものに出なくなった。

  • チームMTGを定例で設定していない。今の所集まったのが1回だけ。その時は「惑星直列」と表現したぐらい珍しいことだった。
  • 集まったときは楽しい話しかしない。

ファシリテーターはイメージを作る手伝い

  • 言葉に落ちきる前のイメージを脳内に作るもののお手伝いをする

  • そのためには、関連を明らかにする。

  • ホワイトボードにキーワードをピックアップして板書していく。
  • そこに矢印や図形を用いて表現していく
  • イメージができないと原理主義者の戦いになる
    • 「○○理論によると」とか喋りだす人がいる
ポストイット最高！
  • 順番を変えられるから
  • 板書にすると、書き直しが出てくる
  • ポストイットだと復活させることもできる
  • これぐらいだったら総務の人も買ってくれるでしょ

ファシリテーターが目指すべき・調整すべきこと

合意に至ったことを確認する

  • 会議室を出た後が勝負。
  • 出た後に配れるものを復習する
  • 場合によっては、ミッシングピースが明確になることもある。
    • わからないものがわかった時点で価値がある。
  • 所感が入った状態で伝播しないようにする。
    • 事実をまずは伝えられるようにする。その後の所感が違う場合はOK。
  • 良くないのは、出ていった後に不満を言う状態

ノリだけで終わらせない

  • 本当に欠けているものを忘れている可能性がある。
  • 逆側をやる、違う視点を考えることも大事。
  • 「ウェーイ」となったときこそ気をつける。
  • ノリだけで終わっている場合は、合意に至ったことを確認できていない場合よりも厄介。
    • 肝心なことが考慮されていないことが多い。
    • 後で後悔することが多い。
  • ファシリテーターは場の雰囲気をかわさないようにしつつ、問題点がないかどうかもう一度確認する
  • 基本は傾聴する。

  • 傾聴した上であらを見つける。

  • システムと向き合っているときは問題点にほとんど気付かない。

  • サービスを使うユーザーしか見ていない。
    • サービス外のことを考慮してないことが多い。
    • 世の中、自分たちが提供しているサービスを四六時中使っているわけではない。
  • こういうことをファシリテーターがきっかけを与える存在になると良い
  • ファシリテーターが力不足であれば、ファシリテーターを補佐しても良い。

具体的な言葉・数字にしておく

  • 部屋を出ていった後で共有できる状態にしましょう
  • 抽象的な言葉になると、人によって全然捉え方が違う。
    • 「なるはや」ではなく「1分後」なのか「1週間後」なのか。
  • 期日を決められない場合は、未決定事項として共通認識にしよう。
    • 具体的に落とし込んでいない部分こそ「これは決まってないんだよ」という決定事項にしよう
  • 経営がうまくいっている企業・組織は、それを徹底的にしているから
  • 「頑張っているから」は評価軸ではない。頑張っているがアウトプットが出ていない場合は「向いていない」という評価になる。
  • そこにゴチャゴチャ言う人に対しては、反証を持ってきてもらう

オーナーが誰なのかはっきりさせる

  • もう一つ大事なのはWHO。
  • オーナーシップ。誰がオーナーなのか。
  • 日本の場合は組織に持ってしまう。
  • 外資系の場合、名前が書いていないプロジェクトに承認を出せない。
    • もしうまくいかない場合は、責任はすべてオーナーが持つ。
    • もしうまく言った場合は、オーナーが手柄総取り。
  • オーナーは、できる限り一人の名前で書く。

ファシリテーションべからず集

ファシリテーターが喋りすぎない

  • とっとと議論をはじめて、傾聴し、キーワードを拾うことに徹する

自分の議論に引っ張り込まない

  • ファシリテーターは責任を感じすぎないようにする
  • 予定調和な会議をしがち。
  • 議論の途中で出てくる想定との違いを受け入れる

正誤のジャッジをしない

公開処刑、ダメ、絶対

ファシリテーターに不要なもの→（過去の実績からくる）プライド

  • 一番邪魔。
  • 「俺に言わせりゃ」という人
    • →他所でやってくれ
  • 過去の経験を活かせるなら別だし、情報として提供するのはあり。
    • プライドも一緒に載せると、否定に対して過剰反応してしまうから。

質問

Q.研修講師として、習っている人の理解度のぼんやりや凸凹にも有効か？

  • 超有効になる。
  • 同じ道の上なので、スピードが違うが、時間をかけることで同じところに到着するはず。

Q.過去の話をしないについて。KPTはまさに過去の話をしていると思うが。

  • NGではなく、圧縮すれば良い。
  • シートを事前に共有する。そしてMTGでは理解度をチェックするのみにしたらよい。

Q.過去の話って、自分も良くすると思うが、気付くポイントがあれば教えて欲しい。

  • 全部ファシリテーターが知っておく必要がない。
  • 「それって未来にどう繋がるの？」と聞けば良い。
  • もしも答えられなければ、もっと端的に話してもらうように促せば良い。

Q.参加者が混乱していたら、整理するという話があったが、ファシリテーター自身が理解していない場合は？

  • 「私は分からないけど、皆さん分かる？」と聞いてみる。

  • 「私はここまで理解している」という風に示すことが大事。

  • 料理をする側にとって辛いのは

  • 「何が食べたい？」→「分からない」もしくは「なんでも良い」

  • という会話。

  • 「ここまでは分かる」という話し方をすることで、議論が進む。

  • 「うん、分かった」ではなく、「こういうことですね」と自分で口に出すことが大事。
  • もしもわからない部分が残っている場合は、それが宿題になる

Q.確認をすると思うが、「分かっているつもり」を判別するには？

  • 分かってないことを「分からない」というのは勇気がいる
  • Next Stepを決めておく。
  • 次の時までにできていないと焦る→「助けてくれ」となる。そしたら、その人を責めず導いてあげる。
  • 合間合間でマイルストーンで「進捗どうですか？」と聞いてあげる。

Q.人数について質問したい。チーム全体について決定したいが、全員が集まるのは大変だと思う。

  • 議論したいならMAX6,7人だと思う。多くても10人。
  • 30人で決めるのは難しい。

Q. ゴール設定に対して。最初に決めるだけではなく、議論を進める上でゴールになる場合があると思うが…。

  • First phaseでゴールを決める。
  • なかなかゴールを決まらなくて時間切れになることはあると思う。
  • その時は、Blocking issueを探す。ただし、人を責めない。

Q.人数について。10人を超えているような組織で、少人数で決定をすると、ちゃぶ台返しをする人が出てくる

  • 異論を許す会議を行うこと自体が良くない。
  • 人数が増えると、事前に共有するものが増えていくことを認識する必要がある。
  • 決定事項に対しては、ちゃぶ台返しは禁止。
  • ちゃぶ台返しをするなら、その人がオーナーになれば良い

Q.決定事項のちゃぶ台返し禁止という合意をどうやって取れば良い？

  • エグゼクティブスポンサー（役員）に合意をとっておく

Q.ティール型の場合は？

  • ティール型の場合、他の人が議論を止める必要はない
  • 人数が多いなら、組織を半分に割りましょう。

Q. どこまで脱線を許すのか

  • バッファ時間の計算の範疇で行う

Q. 発散した後に収束するコツはあるか？

  • 合意したビジョンに戻すことが大事

Q. AvsBでお互いを論破し会えない場合は？

  • 今日はそういう日だったんだと思って。
  • また、ディベートでよくやるのは立場を逆にする方法。
    • 自分を信じてない案を持って議論する。

Q. 自分の結論に引っ張り込まないとあるが、MTG準備をしっかり行った結果、MTGの進み方を仮説する際に自分なりの結論ができてしまう。結論を引っ張り込まないようにするにはどうすればよいか？

  • 最初のビジョンとゴールの話で、準備してきた仮説の結論をゴール設定にしてしまえば良い。
    • 「こういう結論になると私は考えたのですが、この結論を聞いてどう考えますか？」
  • 議論の中でひっくり返ることができる

Q. ファシリテーターが不在の場合どうするのか？

Q. 過去に澤さんが経験したファシリテーション不全の話を聞きたいです。

  • 交通系日本企業勤務・28歳の衝撃の言葉
    • 「みんな会議で発言するんですね。会議で何かが決まるのを初めて見ました」

何かを決断するときに、ファシリテーターではない人が多いと思うが、参加者側の立場として注意すべきことは何か？

  • 「参加者はファシリテーターに対峙しているわけではない。戦うわけではない」というマインドを持つことが大事。
  • 日本の国会は最悪なMTGだが、「議長の存在が大事だ」と思っているのは参考になる部分。
  • イギリスの国会は非常に参考になる。「イギリス議会　面白い」とかでググってみると良い。

Q.会議に参加していて、ファシリテーションを機能していない場合、代えるのはありか？

  • それは仕方がないのでピッチャー交代。
  • 今は会議に特化して話しているが、組織がうまく動かすということを考え、「今日は私がピッチャー交代するね」と言ってあげる
  • そのためには、その前に人間関係を作っておく

Q.連絡だけをする会議について。どうすれば良いか。

  • 報告・連絡・相談には時系列がある。
    • 報告…過去のことなので、データ化しておいてあらかじめシェアすれば良い。
    • 連絡…現在のことなので、都度都度ツール（Slackとか）でやれば良い。
    • 相談…未来のこと。なので、相談に時間を使いましょう
  • また、報告・連絡・相談は性質が違う。
    • 報告は不変性。過去の話だから変わるはずがない。
    • 連絡は即時性。だからチャットが良い。
    • 相談は人間性。相談するのだから人と人の会話がある。だから時間を割くべき。

Q.澤さんはファシリテーション能力をどうやって獲得したか？

Q.全体朝会をやっている場合もあると思うが、それは必要だと思うか。

  • 例えば、ベンチャー企業ならばカルチャー醸成が大事。それには朝会が大事。
  • 会社は仕組みの中で生きる。
  • 能力が高い人は離職リスクが上がる。
  • カルチャーを育てることで、経営上のメリットがある。
  • もしも朝会が退屈な時間になっているなら、朝会の問題ではなく、コンテンツの問題。
    • ワクワクする話をした方が良い。
  • 社員がみんな集まるなら、直接関わっていないサービスのデモを見せた方が良い。

Q.ファシリテーションするのが怖いがどうすれば良い？やらざるを得ない

  • メンターを一人連れて来たほうが良い。
  • 最初のうちは二人三脚で、だんだんと独り立ちしていく
  • ファシリテーション（パブリックスピーキング）が怖いのは世間一般。
  • 助けを求めるのは、仕事をする上で一番大切なこと

Q.3,4人の会議でファシリテーターは必要か？

Q.目標設定にファシリテーションを入れられない

  • 何を持って成功とみなすか予め決めておく。
  • 例えば、アンケートを配ったり。

Q.定例MTGをやらないという話について。スクラムの中でDaily Scrumが不要に感じてしまう。

  • やることが目的になっていないか？
  • 必要であれば有意義に過ごす。
    • 誰かがお題を持ってくる。
    • デモを見せる。
    • 記事を共有するなど。
  • 一番良くないのは、なんとなく集まって駄弁ること。

Q.例えば、現状を知らないことに対して時間を使いたい場合は？

  • それは会議体にする必要がない。トレーニング枠を作るべき。
  • 世の中のスピードはバカとノロマで決まる。
  • これはバカやノロマになる人がいるのではなく、時と場合に誰でもバカやノロマになる。
  • バカやノロマになるポジションに置かないことが大事。
  • 外資系では、「育てる」という考え方が抜けているので、マッチしてるところしか就職しないし、マッチしなければ切り捨てられる。

Q.ファシリテーターを上手い人に固定すべきか？

  • MTGをうまく動かしたい場合には固定すべきだが、その人がいないときにリスクになる
  • 平穏な世の中である内に経験させる。それもマネージャの役割。