2017/7/22(土)、【<ゆるっとファシリテーター>体験会】と【ゆるっとお茶会ワークショップ】に参加してきました。

@caori_tさん主催のファシリテーションイベントに参加してきました。
ファシリテーションをやっている様子を見学できる数少ない機会なので、ファシリテーションを体験するのと合わせて、ファシリテーターの考えを学ぶ目的で参加しています。

caorit.hatenadiary.com

イベントは2部に分かれて実施されました。

午前:<ゆるっとファシリテーター>体験会

今回は<ふりかえりをゆるファシってみるよ レベル1*1>ということで、参加者の一人を対象者として、対象者が「過去に実施したふりかえり」をふりかえる、という内容でした。他の参加者は見学者という形で参加しています。私は見学者の立場でした。

今回の体験会で特に面白いと感じたのは、見学者に対する注意事項でした。過去にやったときに、周りの発言によって対象者の問題が分かりにくくなることが理由です。そもそも、発言できる見学者が多くいる環境ってなかなか無いように思うので、注意事項が出てきたことにびっくりしました。

出てきた注意事項は以下のようなものです。

  • 手を出さない
  • 誘導しない
  • さえぎらない

対して、見学者がやってもいいのは以下のようなものでした。

  • 問いかけ(質問)
  • 確認

内容はふりかえりをKPT形式で行い、ファシリテーションによって対象者の理解を掘り下げる形式でした。Keep,Problem,Tryごとに使う付箋の色を変えるなどの工夫により、整理された情報の一覧性が向上していました。これが問題の理解/整理に一役買っていた思いました。対象者が本質的な問題に到達しやすいような配慮が窺えて、大変参考になりました。
私は見学者でありながら、結構口を出してしまったこと(質問/確認に留めたつもり…)が反省点です。

成果物の画像です。内容は個人情報に関わるため、ぼかしています。
f:id:toshimana:20170722124122j:plain

午後:ゆるっとお茶会ワークショップ

お茶を飲みながら個人が抱える問題と前向きに向き合える、午前の部に比べると気軽に体験できるワークショップになっていました

f:id:toshimana:20170722141519j:plain

内容は2部に分かれていました。

  • 前半:二人一組になって問題に向き合うワーク
  • 後半:お茶を飲みながら、前半を振り返るフリートーク(お茶会)

問題分析は「SaPID/SaPID+」に基づいて、@caori_tさんがお茶会用にアレンジした形式になっています。

SaPID+ - software-quasol ページ!

私も過去にSaPID+ BootCampに参加したことがあるので問題分析の全体像は把握しています。

toshimana.hatenablog.com

ですが、今回はお茶会というテーマに見合うくらい、範囲を絞って気軽に体験できるようにアレンジされていました。本格的な問題分析は十分な時間が必要なので初めての人には敷居が高くなってしまいます。対して、今回のお茶会ワークショップは短い時間で問題分析の入り口を体験できるので、とても面白い(価値のある)取り組みだと思いました。

私のペアは問題分析に時間がかかってしまい、前半の内容を後半も引き続き議論する形になりました。前半でもう少し時間が欲しかったですが、何とか個人の問題は明確になり、次のアクションが見えるところまでは検討することができました。

お茶とお菓子は美味しかったです。
f:id:toshimana:20170722150910j:plain

他の参加者レポート

@mhlyc さんがレポートを挙げてくださってます。

mhlyc.hatenablog.com

おわりに

私の知っている問題分析(ファシリテーション)は、重たいプロセスになりがちで気軽に体験するのは難しいものでした。今回のお茶会ワークショップは、工夫しながら、できる限り軽くなるように、問題解決の手法に容易に触れられるようになっているのは素晴らしいと感じました。気軽に問題分析手法に触れられることで、問題に対して向き合い、前進する人がもっと増えるようになると思います。

お茶会ワークショップはまだまだ始まったばかりなので、この先どのような進化をしていくかは凄く楽しみにしています。

*1:レベル1=初の試み

7/1(土)、オンライン勉強会「ドキュメントインスペクション」を開催しました。

開催しましたって書くと大げさですが、顔の見知ったメンバー数人でクローズドなオンライン飲み会勉強会を行いました。

前回はコチラ
toshimana.hatenablog.com

今回は「ドキュメントインスペクション」をテーマに議論しています。その時の学びをまとめておきます。

大きく2部構成で行いました。

  • @Unity1004 による「伝わりやすい文章」についての講義
  • ドキュメントレビュー大会

その1:「伝わりやすい文章」についての講義

@Unity1004 に良い文章を書くための色々な観点を教えていただきました。特に、レビューする側としてどういうところを見るか、という視点で色々まとめてくださいました。

勉強になることがたくさんあったのですが、特に興味深かったのは以下の2点です。

これまで作成した文章で困っていた項目をまとめておこう
  • 「伝わりやすいか」とか「情報の過不足がないか」などといった読み手の負担になるような項目を整理しておくと、どういう観点でレビューする側がドキュメントを見るのかが明確になり、良い指摘が出しやすくなる。
  • 上記項目を「明確性」や「妥当性」のように~性としてまとめておくと良い。また、その中で優先度をつけることで、今何をレビューするかをチームで認識合わせしやすくなる。
  • どのような項目が必要かは文章の種類や位置付けなど、状況によって異なる。自分たちが何に困っているかをチームで議論して、自分たちの項目を出そう。
書く前に文書設計をしよう
  • 文章を書くときは、いきなり書き出すのではなくて事前に情報を整理することが重要。
  • 「誰が」「何の為に」読む文章なのかを明確にする。
  • それを満たすために必要な情報を洗い出して、伝えるべき内容とそのレベルを検討する。
  • 特に「誰が」「何の為に」が定まらないと内容が収束せずに手戻りが発生しやすくなる。

その2:ドキュメントレビュー大会

あるドキュメントをベースに、みんなはどんなレビューをするか、っていうのをやりました。レビュー方針として「パラグラフ(段落)レベルの指摘を重視」することが挙げられました。全体構成の問題を先に洗い出すことで手戻りを減らすことが目的です、

出てきた観点は以下のようなものがありました。

誰の視点の言葉か
  • 人が話した内容を引用したりするときに、主語が書き手なのか話し手なのかが分かりにくくなる場合がある。主語が誰かを明確にしよう。人の話を長文で引用するときは、段落で分けるなど区切りを明確にするといい。
情報の過不足がないか
  • 文章を見る相手に過不足ない情報を与えて、内容を整理しやすくする。情報不足は情報の前後関係を適切に理解することができなくなる。情報過多は本筋以外の情報の関係が出てくるので整理が難しくなる。今回は特に読み手に関係のない情報がいくつか挙がっていた。
暗黙知が抜けていないか
  • 前提条件を明記しないで(暗黙知として)文章を書いてしまい、内容が相手に伝わらない場合がある。読み手がその知識を持っていないことを考慮して、説明をしてから本題に移ろう。暗黙知は書き手だと気付きにくいので、他の人にレビューをしてもらうと良い。

運営:準備不足

オンラインで勉強会をするのは2回目ですが、前回に比べて準備が不足していました。1回目が上手く行ったという油断があったのでしょう。貴重な時間を割いて参加してくれる人たちに余計な負担は掛けたくないので、しっかりしないといけない所です。

事前の連絡手段が複数存在していたため、情報が適切に伝わらなかった
  • 対策:全体への連絡手段は一本化する。
タイムスケジュールがグダグダだったので、脇道に逸れやすかった
  • 対策:簡単でいいので、やることを洗い出して事前にタイムスケジュールを用意する。

まとめ

伝えたいことが正しく伝わるドキュメントは誰もが求めるものです。しかし、それを作るためにはみんなで知恵を集めて、各々の感性を技術に昇華して、どうすれば良い文章が書けるかを切磋琢磨して考える必要があります。文章作成は未だにいろんな人が苦労します。また、読みやすい文章を書くための様々なアイディアをいろんな人が持っています。良い文章を作るためにどんなアイディアがあるのか、いろんな人ともっと話し合いたいですね。

オンライン勉強会をやってみた

テストクラスタの仲間うちだけのクローズドですが、オンラインで勉強会をやってみました。
適当にはじめた割には、北は北海道、西は福岡までいろんな方が集まってくれました。
最初は勉強会を行い、そのあとはグタグタお酒を飲む感じでした。

既に講演者の @____rina____ さんがブログにまとめてくれています。
underscore42rina.hatenablog.com

オンライン勉強会の環境

オンラインで参加者間をつなぐツールとして、以下の条件を満たすものを検討しました。

ビデオチャットツール

以下の候補が上がりましたが、今回はGoogleハングアウトを使用しました。

安心と信頼のGoogleビデオチャットツール。無料だと最大10人まで同時接続可能。参加者はGoogleアカウントが必要。知名度が高いので情報を探すのには困らない。

  • appear.in

アカウント不要なビデオチャットツール。無料だと最大8人まで同時接続可能。自分環境でGoogle Chromeの環境が古いと接続できない場合があった。

  • Zoom

会議用ビデオチャットツール。ホワイトボード機能など、多彩な情報共有ツールがある。最大50人まで同時接続可能。参加者は専用ツールをインストールする必要がある。ビデオチャットを開始する人はアカウントが必要だが、開始されたビデオチャットに参加するにはアカウント不要。無料だと1会議40分制限あり?

あとは、Skypeが使えるかもという案も出ていたけど未検証。


ちなみに、ビデオチャットを前提に環境を用意しました。そして、参加者8人の参加方法として、ビデオ1人、音声3人、チャットのみ4人という内訳でした。ビデオいらねぇ!

講演(@____rina____ さん)

以下の本の一部を抜粋し、良い文章を作るための技法に考え方についてお話いただきました。
「伝わる日本語」練習帳 | 阿部 圭一, 冨永 敦子 | 言語学 | Kindleストア | Amazon


元々、オフライン用に用意した資料を使って講演いただきました。
資料はMicrosoftのOffice Swayで作成されており、画面共有を使って参加者が講演者のスライドを見ながら話を聞くスタイルになりました。
参加者のほとんどが「Office Swayってなんだ?」って感じだったので、それについても講演いただきました。
sway.com

オフラインと違って参加者の反応が講演者に見えないから「講演が難しいのでは?」と危惧していました。しかし、実際にやってみると参加者がチャットを使って反応しており、講演者にフィードバックしながら講演をすすめることができました。話しているのが講演者一人ですが、チャットのテキストに反応しながら講演する様は、まるで「ニコニコ生放送」を見ているような感覚になりました。

講演内容は良い文章を書くために気を付けるポイントがまとめられており、「用語は一意になるようにする」や「難しい漢字を使わないようにする」などを例を含んで説明してくれており、実感とともに理解することができました。今回の資料には、参加者に解いてもらう問題も用意されていたのですが、いわゆる「もんたメソッド」に近い、回答を少しずつ見せていくやり方をしていました。それがオンラインにもマッチしていたため、楽しく学ぶことができました。

ふりかえり

今回の良かった/次に直したいポイントをまとめておきます。

良かったポイント

  • 講演者を決めて、最低限の音声担当枠を確保しておくのは良かった。ほかの人がチャットでも成り立っていた。
  • 画面共有が使用者のマウスカーソルなども反映してくれて便利だった。講演者のリズムでスライドが切り替わることでオフラインに近い感覚が得られる。ワークなどで参加者の画面を共有しても面白そう。
  • 夜中(22:00-)開催。遅い時間だが、自宅でできるので「あとは寝るだけ」の状態で参加できるのも嬉しい。「終わったら10秒で布団に入れる」というのは講演者の談。

次に直したいポイント

  • サドンデス(寝落ちするまでやる)飲み会。やりたい人がやっているのはいいのだが、次の日もあったりなので途中で抜けやすい空気を作りたい。
  • 次やる場合は人をどうやって集めるか。多すぎると無料枠でのオンラインチャットツールの人数上限を超えてしまう。有料にするとやりにくい。
  • 勉強会のログ保存方法の確認。いろいろチャットしたけど、Googleハングアウトの見返し方が分からなかった。

まとめ

SNSでは良く見るけど実際に会うには物理的に難しい人たちとも交流が取れるので地方勢としてはとても楽しい時間を過ごすことができたと思う。勉強会もとても参考になったので、定期的にやりたいと思えるイベントでした。

2017/2/25,26, 【SaPID+bootcamp】に参加しました。

プロセス改善の手法であるSaPIDを集中して学べるSaPID+bootcampに参加してきました。

安達さんが講師のもと、自分が仕事で抱えている問題を実際にSaPIDを用いて整理して、体験するができた二日間でした。

ワーク概要

自分が業務で抱えている問題をもとに、問題構造図を作成し、改善目標を検討するところまでを行いました。特に、洗い出した問題の精査が難しく、半日以上の時間がかけられていました。問題の精査の際には二人ペアでの作業となり、一方の問題に対してもう一方が質問をすることで問題を深掘りする手法で行われました。問題構造図を作成する技術だけでなく、相手の理解を深める助けをするSaPIDファシリテータの技術を学べるという、時間をかけられる合宿形式ならではの内容になっていました。

振り返り

二日間で振り返るポイントは山のようにありますが、特に問題構造の整理とファシリテーションに着目して振り返ります。

問題構造の整理

keep
  • 一通り、合宿をやりきれた。一日目の予定分が終わったときは中途半端に終わらないか不安だったが、ペアの人の協力などもあり最終的には一通り形にすることができた。まだまだ上手く整理できたものではないかもしれないけど、中途半端で終わらない、よりは未熟でも完了するほうが次に進めるため、個人的にはこのbootcampの最低限の目的を達成できた。
  • 洗い出しの最初の際に実務で感じた「良くない感覚」を頼りに問題を出せた。SaPIDの問題としてはとても浅いものではあるが、あとで深掘りするからこそ、「良くない感覚」を自覚するつもりでだせたため、広い範囲で問題を洗い出せたと感じた。
  • 問題がロジックツリーのように整理された形にならない、ということに気付けた。問題は人それぞれなので、必ずしも整理できる形で出てくるとは限らないことを理解できた。
  • 付箋に書き出した問題をまとめることができた。洗い出した問題の数が多くすぎて、全体の俯瞰が難しくなったが、まとめることで全体像の整理に注力することができた。SaPIDとしては問題は抽象的よりも具体的であることを推奨しているが、ある抽象的な問題に着目する必要が出てきたときに、まとめていた問題を分解すれば良い、という考えでやってみた。
  • 問題のグルーピング、構造化を早期に行った。カリキュラム的に先走った感があるので、ワーク的に妥当だったかは不安が残るが、グルーピングや構造化を行うことで、全体像を把握しやすくなり、問題をまとめることなどに貢献した。
problem
  • なかなか心の奥につっかえている問題を出すのが難しかった。こればかりは自分の心の壁を取っ払うしかないので、自分の問題に直面できる強さが必要があるかと感じた。表面に出てくる問題を解決できれば、根っこの問題が見えてくるかも。
  • 問題をまとめたこともあって、最終的な問題が抽象的になった。SaPIDでは具体的な問題整理を行うため、十分に学びきれたかに不安が残る。問題のスコープが広いこともあったため、どうしても問題が発散してしまったことが原因だと思われる。もう少しスコープを限定してやってみたい。
  • 問題の分類について理解が疎かになってしまった。問題ではなく手段も多く残ってしまった。問題と思って出したものが何なのかを吟味する必要がある。
  • 口頭でたくさん説明したが、その説明を問題として場に出すことが上手く行かない場合があった。口にだしたら即書き落とすことをもっと徹底すべきだった。
try
  • 問題が抽象的になってしまったため、より小さいスコープでやってみたい。
  • 問題をより具体的にしたい。NGワード(抽象的な言葉として良く出てくるもの)をいくつか教わったので、NGワードを分解するようにしたい。
  • 問題じゃないものを多く出してしまったため、出した項目が問題か、手段かを吟味したい。

ファシリテート

keep
  • ほかの人の問題をうまく深掘りできる質問ができたと思う。特にうまく行ったと思っているものとして、「相手が出した問題があったとして上手く行くケース」を例示することが挙げられる。それを例示することで、「いや、そうじゃないよな」と考えを深めてもらうことができたと思う。
  • 相手に教わる姿勢の重要性を学んだ。「おそらく相手はこういう問題を持っている」と予想していても、相手の捉え方が異なる場合が多々あった。事前に講師の安達さんから「相手に教わる姿勢が重要」と聞いていたが、その意味を体感することができた。
  • ペアの人がいてくれることで、感性的な問題を出しても深掘りしてくれる、という安心感があった。
problem
  • 相手が深掘りで詰まっているときに、例を出してしまい誘導をしてしまったことが何度かあった。例を出す場合は少なくとも2つ以上を出して、相手の思考停止を防ぐようにする必要があった。
  • ペアをしてくれる人に問題を話し過ぎて、自分がスルーしてしまう部分に対してペアの人もスルーしてしまうことがあった。話したことは書き落とすことを徹底すべきだった。
try
  • もっと相手のことを理解したい、という気持ちでどんどん教わりにいく。

まとめ

SaPID尽くしでしたが、学ぶことが多くてとても勉強になる二日間でした。SaPIDはもっと色々試して、自分のものになるように練習したいと思います。とても楽しい時間をありがとうございました!

2017/2/24(金)、「未来予想型チーム運営ワークショップ」に参加しました。

仕事をしていると、未経験の領域の作業をしなければならないことが多々あります。不確実性が高いため、正確な見積もりなどほぼ不可能な場合がほとんどですが、そんな中でも作業を見積もって、分からないなりに仕事をこなさないといけません。

今回はそんな不確実性の高い状況でも、自分たちのどのようになりそうかを予想しながら、問題を着実に解決し、理想的な未来のために前進するためのアイディアを学べる「未来予想型チーム運営ワークショップ」に参加してきました。
www.kokuchpro.com

問題解決のための手法である「SaPID」と「TOC」の融合という、これまでにない新しいアイディアであり、とても楽しみにしていたワークショップです。とても楽しく、非常に考えさせられる密度の濃い時間を過ごすことができました。

ワーク概要

TOCのワークショップである「CCPM×折り紙ワークショップ」がベースになっており、チームになって時間内に指定された折り紙を折る、という内容でした。折り紙のお題は最初の段階では到底達成できないと思えるような厳しい条件です。それをSaPIDをベースに起こりうることを予想して、起こりうる未来にはどんな問題があって、どのような要因から引き起こされるのかを整理します。得られた要因に対する対策を検討し、実際に折り紙を折ってみて、検討した対策について振り返りを行い、徐々に改善していきました。できないと思われた問題も、改善を繰り返していくことで効率良く進めることができ、結果的に当初の作業見積もりから大幅に短い時間で折り紙を折り切ることができました。
f:id:toshimana:20170224162739j:plain

感想

語りたいことはいっぱいありますが、その中でも特に心に残ったことを書き留めておきます。

予想した通りの結果になる

課題が厳しい条件だったため、起こりうることを予想した時も、失敗する予想が多く挙がりました。講師の安達さんから、「予想した通りの結果になる」とアドバイスをいただき、現実味があるかはともかく完成するためのストーリーも予想してみました。そういった予想が糸口となって、厳しい課題を達成できる改善案が見つけることができたため、どんなに厳しい条件でも成功するストーリーを想定することが実際に成功を手繰りよせるカギとなることを学びました。

流石にお花の折り紙が多いからと、ある参加者が「お花畑ができあがる」と予想したのが叶うとは思いませんでした。別の参加者が知らずにお花畑作ってました。
f:id:toshimana:20170224164022j:plain

言葉はできる限り具体的に

起こりうることを予想するとき、抽象度の高い言葉を使ってしまうと、問題やその要因がぼやけてしまい、具体的な改善策の検討が困難になります。予想を洗い出したあと、出てきた言葉を整理する作業がありましたが、自分では意識していなくても抽象度の高い言葉を使っていることに気づかされました。自分が予想した内容の文脈を明確にすることで、自分の頭の中も整理され、本質的な問題が見えるようになるんだということが分かりました。

SaPIDもTOCもやりたいことは同じ

SaPIDとTOCの2つの手法が上手く融合されていて、SaPIDの手法/TOCの手法が使い分けられていることを全く意識することなくワークをやり遂げることができました。お互いの強みを生かした構成になっていることもさることながら、異なる2つの手法がこんなに自然に繋がることに驚きを隠せませんでした。SaPIDもTOCもやりたいことは同じだからことできることでもあり、その2つをこんなに上手く融合させた講師の安達さん、水野さんは本当に凄いと思いました。

まとめ

折り紙のワークでは高度な改善を行ったにも関わらず、チームとして収支良い雰囲気でワークに取り組めました。実際の仕事では殺伐とすることも多かれ少なかれ存在しますが、良い雰囲気でも(むしろ良い雰囲気の方が)高度な改善が可能であることが本ワークで実感できました。
このように、成果が上がって皆が楽しめる場づくりをしていきたい、と強く感じた一日でした。

2016/11/19(土)「第二回盛岡ソフトウェア勉強会」に参加しました。

2016/11/19(土)の第二回盛岡ソフトウェアテスト勉強会の参加レポートです。

kokucheese.com


岩手では勉強会活動があまり盛んではない、というところから岩手出身の藤沢さんが岩手に縁のある方々を集めて開催しています。登壇者の浦山さつきさんは同じく岩手県出身、吉田さんは滝沢市にある株式会社ヴェスに勤務されています。私は岩手と直接の縁はありませんが、岩手出身の会社の人などと一緒に参加しました。

はじめに

ソフトウェアテストの勉強会だと、テスト技法についての話が多いです。しかし、今回は「ソフトウェアテストの第一歩」というテーマで、上流よりのテストの考え方について学ぶ勉強会となっています。講演者3者がテストプロセス、テストレベル、テストタイプについてそれぞれ語る形式となっています。

ソフトウェアテストことはじめ2016年ver

藤沢さんによるテストプロセスの要素である(テスト計画、テスト分析、テスト設計、テスト実装、テスト実行、テスト報告)についての説明と、藤沢さん自身の経験から考案したソフトウェアテスト活動簡易評価チェックリスト10か条の各項目の説明、という構成でした。

10か条は時間の都合で詳細な説明がされたのは5項目でしたが、機会があれば全部聞きたかったです。藤沢さんの経験に基づいているため、私含め参加者の皆様からしたらドキリとくる内容だったかと思います。いくつかピックアップしてみます。

テストに関する成果物のレビューを計画していること。また、計画通り実施していること。

テストに関する成果物に対して、必ず関係各位にレビューをしてもらおう。セキュリティ部門の方とか、開発の方とかにレビューをしてもらうことで、自分では気付かなかった成果物の問題点に気付くことができる。レビューを計画しても関係者とのスケジュール調整が困難な場合がある。しかし、レビューを実施しないことは危険であり、重要な人をピックアップして行うなどしてレビューは必ず実施する。

テストケースは、具体的なテスト実行手順を読み手に理解できるように記述していること。

検討したテストケースがテスト実行のフェーズになって実行できない問題が起きる場合がある。そのため、手順で使うツールや環境などの不明点は明確にした上で手順を検討する。細かい環境が分かっていないとテスト実行ができずに手戻りが発生する。

手戻り撲滅!テストからできる手戻り防止策

浦山さんからは開発のコストを下げるためのテスト側からのアプローチと受け入れテストについての考え方の話をお聞きしました。ワークが多く、ほかの参加者の方々と意見交換をすることができて楽しくみることができました。

開発コストとテスト

開発のコストとして、「製造コスト、予防コスト、評価コスト、内部失敗コスト、外部失敗コスト」に分けられる。製造コストを除いたものを品質コストと呼び、予防/評価コストを管理可能な品質コスト、内部失敗/外部失敗コストを管理ミスの品質コストとする。長期的な品質戦略としては管理ミスの品質コストを減らすことで、「機会損失」を減らすことが重要。そのために、要求分析や設計の段階からレビューにより不具合を検出して、手戻りを少なくすることが有効であるとされる。今回紹介された開発コストの分類は以下の書籍が出典となる。

受け入れテストの考え方

機能という言葉の2通りの解釈ができる。FunctionとFeatureの解釈があり、Functionはソフトウェア開発で使われる製品操作を指す言葉。対して、Featureはもとはマーケティング用語でユーザに「役に立つ」ことを指す言葉となる。テストの観点を抽出する目的としては、ユーザ視点側であるFeature側の機能を出すようにすると良い。テスト項目を洗い出した後に「これはユーザにとってどんな価値を与えるのだろう」という切り口を持つことで、新しい項目が出てきたり、その機能がどうあるべきかを見つめなおす切っ掛けとなる。

ユーザビリティの重要性

吉田さんからは様々テストの中から、テストケースでは表しにくいユーザビリティテストについての話を聞きました。エラー時の言葉の使い方や画面タップ時の挙動についての事例を紹介しながら、テストケースの手順や期待値では表せない「ユーザがどのように受け取るか」を検討することの重要性について解説いただきました。

おわりに

岩手の勉強会活動が盛んではない、という話でしたが土曜日にも関わらずたくさんの方が参加されていました。仙台からだと比較的参加しやすいので、次がありましたらまた参加したいと思います。

改善のジレンマ~ゲーム理論から学ぶ改善の勘所

改善活動がうまくいかない様がゲーム理論の「囚人のジレンマ」に似ていると感じたところから考えを整理してみました。異論は認める。どんとこい。

はじめに

勉強会に参加すると「職場の環境を改善したい」という意思を持っている人は結構見かけます。しかし「自分のチームが最高になりました」という話はなかなか聞きません。理想に近づくために改善活動を頑張っているのに、状況は一向に改善しない。自分は凄く頑張っているのに自分の周りは改善されない。頑張っているのに報われない、悩みを持っている人たちを多く見かけます。

その頑張っているのに報われない様をゲーム理論における「囚人のジレンマ」になぞり、問題の整理と改善のヒントを見つけることが今回の目的になります。

囚人のジレンマ

囚人のジレンマ」とは個人が自身にとって最適な選択を取ったとして、必ずしも全体最適にならない例のことです。

  • 共犯で重い罪を犯した二人が別件で逮捕された。警官が二人を別々の場所に隔離して取り調べを行い、それぞれに「もし相手が黙秘し、お前が重罪を自白したのなら無罪にしよう。」と取引を持ち出した。一方が黙秘し、もう一方が自白した場合、黙秘したほうは懲役10年、自白したほうは無罪となる。二人とも黙秘した場合は別件逮捕の件で懲役1年、二人とも自白した場合はともに懲役5年となる。

二人の囚人をそれぞれA,Bとします。囚人A,Bの懲役期間の表は以下のようになります。

囚人A\囚人B 黙秘 自白
黙秘 (-1,-1) (-10,0)
自白 (0,-10) (-5,-5)

仮に囚人Bが黙秘した場合は自身も黙秘すれば懲役1年、自身が自白すれば無罪になり、囚人Aにとって自白したほうが有利になります。囚人Bが自白した場合は自身が黙秘すれば懲役10年、自白すれば懲役5年となり、囚人Aにとって自白したほうが有利になります。つまり囚人Bの黙秘/自白に関わらず、「自白」することが囚人Aにとって最善の結果になります。
囚人Bにとっても同様に、囚人Aの黙秘/自白に関わらず、「自白」することが囚人Bにとって最善の結果になります。
そのため、各々が自身にとって最適な結果は「両方とも自白する」ことになります。
しかし、「両方とも自白する」ことにより共に懲役5年になるのに対し、「両方とも黙秘する」ことで懲役1年になるため、協力して「両方とも黙秘する」方が囚人にとって良い結果になります。

改善のジレンマ

改善活動を囚人のジレンマになぞって、以下のように仮定します。

  • 職場の環境に不満をもった二人の社員がいます。一方が改善活動をし、もう一方が改善活動をしなかった場合、改善活動をしたほうは改善効果より労力が勝るためマイナス、改善活動をしなかったほうは労せず改善効果が得られたためプラスとなる。二人とも改善活動をした場合はともに労力以上の改善効果がえられるためプラス、二人とも改善活動をしなかった場合は変化なしとなる。

二人の社員をそれぞれA,Bとします。社員A,Bの損得の表は以下のようになります。

社員A\社員B 改善活動する 改善活動しない
改善活動する (3,3) (-2,5)
改善活動しない (5,-2) (0,0)


社員Bが改善活動をする/しないに関わらず、社員Aにとっては「改善活動をしない」が最善手になります。同様に社員Bにとっても社員Aが改善活動をする/しないに関わらず、「改善活動をしない」が最善手になります。つまり、改善活動はしない方が良い、という結論になります!

...そんな訳ないですね。
協力して改善活動をする(3,3)ほうが、二人とも改善活動をしない(0,0)ことに比べて良い結果となります。しかし、個人レベルで見た場合は「改善活動をしない」ほうが相手の選択に関わらず良い結果となります。
この考えをもとに、あなたが改善活動をしていてもあなた以外が改善活動をしてくれないことを、ここでは「改善のジレンマ*1」と呼びます。あなた以外にとっては改善活動をしないほうが最も得をする選択なので、改善活動をしないのです。あなたはあなた以外が協力して改善活動をしてくれないことに憤りを感じることがあるかもしれません。しかし、あなた以外に悪意があるかどうかは関係なく、改善活動をしないのは自然なことなのです。

繰り返しゲーム

上記の「囚人のジレンマ」は1回だけのゲームを想定していますが、現実では同様のシチュエーションは何度も何度も訪れます。ここでは、時間経過と長期的な関係を扱う「繰り返しゲーム」を元に「改善のジレンマ」の対応策を検討します。

有限回の繰り返しゲーム

ゲームの回数が決まっている、有限回の繰り返しゲームについて整理します。T回の囚人のジレンマを繰り返し行ったときに、どのように行動すればよいかを考えます。結論からいうとT回の囚人のジレンマを行った場合、各囚人にとって「全ての回で自白する」ことが最適解になります。

  • 各囚人は最後のT回目のゲームでは過去にどんな選択をしたかに限らずに最適な行動である「自白」する行動をとります。
  • (T-1)回目のゲームでは、T回目のゲームを予想した上で、過去にどんな選択をしたかに限らずに最適な行動である「自白」する行動をとります。
  • ... (以下、1回目まで続く)

このように帰納的に考えることで、各囚人は「自白」する選択を取り続けることになります。
このことから改善のジレンマにおいても「改善活動をしない」ことを続けることが最善手になります。…いいのかコレ?

無限回の繰り返しゲーム

ゲームの回数が決まっている「有限回の繰り返しゲーム」では、協力を達成できません。しかし、恒常的な作業が「T回で終わる」という感覚をもっている人はほとんどいないと思います。改善活動などは「終わりがない」と考えている人がほとんどの筈です。そのため、より現実の感覚に近いゲームである「無限回の繰り返しゲーム」を元に「改善のジレンマ」の対応策を考えていきます。

「無限回の繰り返しゲーム」では、「有限回の繰り返しゲーム」のように一番最後のゲームから考えることができません。そのため、将来どのような結果になるかを予想する必要があります。その際、「将来得られる価値をどのように考えるか」によって結果が変わります。囚人のジレンマを例にして整理します。

  • ある囚人の「将来得られる価値」が「今得られる価値」より十分に低い場合、協力して「黙認」し続けることによる価値が低いため、現在の最適回が得られる「自白」することを選択します。
  • ある囚人の「将来得られる価値」が「今得られる価値」とほとんど変わらない場合、協力して「黙認」し続けることにより将来的に大きな価値が見込めるため、(戦略によっては)「黙認」することを選択します。

このことから、「将来得られる価値を重視する長期的な視野を持つもの同士なら協力を達成できる」と言えます。

改善の勘所

「無限回の繰り返しゲーム」では、「長期的な視野を持つプレイヤー同士」なら「協力が達成できる」とあります。つまり、「あなた以外が改善活動をする」ためには、「あなたが改善活動をする」だけではなく、「あなた以外が改善活動によって得られる将来的な価値を重要視しているか」を確認する必要があります。

つまり、改善のために何より必要なことは「あなたが改善活動を続けること」ではなく、「あなた以外と改善活動の価値を共有しつづけること」になります。改善活動の価値が共有できていないのであれば、あなたが改善活動を続けたところであなた以外は改善活動をしてくれないですし、そのことに嫌気がさしてあなた自身の改善活動が止まってしまうかもしれません。

おわりに

前の記事でかいた1項目「アンチパターン?:個人の問題を技術で解決する」に対する考察になります。
同じことに価値を感じ続けられるチームが作れたらどれだけ嬉しいことだろう、と考えながら書きました。
那須のチームに対して、何が羨ましいと思うのか - toshimana's diary

今回はゲーム理論のなかでも「囚人のジレンマ」について取り上げましたが、ほかにもゲーム理論には面白い話がたくさんあるので、それと改善との対応を整理してみるのも面白いかと思います。

参考文献

以下の文献を参考にしました。「囚人のジレンマ」や「繰り返しゲーム」の話はこちらの文献を元にしています。内容を簡単にするためにゲーム理論については詳細な説明を省いているところがありますので、細かく知りたい方は勉強してみてください。

ゼミナール ゲーム理論入門

ゼミナール ゲーム理論入門

*1:この記事でのみ使っている造語です