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

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

前回はコチラ
toshimana.hatenablog.com

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

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

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

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

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

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

これまで作成した文章で困っていた項目をまとめておこう

• 「伝わりやすいか」とか「情報の過不足がないか」などといった読み手の負担になるような項目を整理しておくと、どういう観点でレビューする側がドキュメントを見るのかが明確になり、良い指摘が出しやすくなる。
• 上記項目を「明確性」や「妥当性」のように～性としてまとめておくと良い。また、その中で優先度をつけることで、今何をレビューするかをチームで認識合わせしやすくなる。
• どのような項目が必要かは文章の種類や位置付けなど、状況によって異なる。自分たちが何に困っているかをチームで議論して、自分たちの項目を出そう。

書く前に文書設計をしよう

• 文章を書くときは、いきなり書き出すのではなくて事前に情報を整理することが重要。
• 「誰が」「何の為に」読む文章なのかを明確にする。
• それを満たすために必要な情報を洗い出して、伝えるべき内容とそのレベルを検討する。
• 特に「誰が」「何の為に」が定まらないと内容が収束せずに手戻りが発生しやすくなる。

その２：ドキュメントレビュー大会

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

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

誰の視点の言葉か

• 人が話した内容を引用したりするときに、主語が書き手なのか話し手なのかが分かりにくくなる場合がある。主語が誰かを明確にしよう。人の話を長文で引用するときは、段落で分けるなど区切りを明確にするといい。

情報の過不足がないか

• 文章を見る相手に過不足ない情報を与えて、内容を整理しやすくする。情報不足は情報の前後関係を適切に理解することができなくなる。情報過多は本筋以外の情報の関係が出てくるので整理が難しくなる。今回は特に読み手に関係のない情報がいくつか挙がっていた。

暗黙知が抜けていないか

• 前提条件を明記しないで(暗黙知として)文章を書いてしまい、内容が相手に伝わらない場合がある。読み手がその知識を持っていないことを考慮して、説明をしてから本題に移ろう。暗黙知は書き手だと気付きにくいので、他の人にレビューをしてもらうと良い。

運営：準備不足

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

事前の連絡手段が複数存在していたため、情報が適切に伝わらなかった

• 対策：全体への連絡手段は一本化する。

タイムスケジュールがグダグダだったので、脇道に逸れやすかった

• 対策：簡単でいいので、やることを洗い出して事前にタイムスケジュールを用意する。

まとめ

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

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

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

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

オンライン勉強会の環境

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

• 最大8人接続可能
• ビデオチャットが可能
• 画面共有が可能

ビデオチャットツール

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

• 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をベースに起こりうることを予想して、起こりうる未来にはどんな問題があって、どのような要因から引き起こされるのかを整理します。得られた要因に対する対策を検討し、実際に折り紙を折ってみて、検討した対策について振り返りを行い、徐々に改善していきました。できないと思われた問題も、改善を繰り返していくことで効率良く進めることができ、結果的に当初の作業見積もりから大幅に短い時間で折り紙を折り切ることができました。

感想

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

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

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

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

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

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

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

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

まとめ

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

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

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

kokucheese.com

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

はじめに

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

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

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

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

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

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

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

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

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

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

開発コストとテスト

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

クオリティ・マネジメント―よい品質をタダで手に入れる法

受け入れテストの考え方

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

ユーザビリティの重要性

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

おわりに

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

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

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

はじめに

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

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

囚人のジレンマ

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

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

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

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

仮に囚人Bが黙秘した場合は自身も黙秘すれば懲役１年、自身が自白すれば無罪になり、囚人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:この記事でのみ使っている造語です

那須のチームに対して、何が羨ましいと思うのか

2016/10/29(土)に行われた「ソフトウェアテスト勉強会～テスターと創る開発現場～」の参加レポートです。

東北デベロッパーズコミュニティ - イベント案内 | 2016-10-29 (土) ソフトウェアテスト勉強会～テスターと創る開発現場～

"テストの妖精"こと@miwa719さんと、"プロの無職"こと@m_sekiさんに彼らの開発現場について語っていただきました。

私たちの開発現場：@miwa719
speakerdeck.com

プロの前座(tohoku again)：@m_seki
speakerdeck.com

JaSST東北2014で初めて彼らにお会いして以来、何度か話を伺っています。彼らの話はいつも刺激的で、彼らのような開発現場をいつも羨ましく思って聞いています。彼らのチームは、私が知る限りにおいて"最高のチーム"を実現したようなチームだと感じています。

ふと、自分は彼らのチームの何を羨ましく思っているのだろうかと考えました。そこで今回は彼らのチームの何が凄いのか、何が羨ましいのかを整理してみました。

彼らのチームの何が凄いのか

2時間という時間がアッという間に過ぎるほど、今回も素晴らしい活動をたくさん話していただきました。

開発とテストが分かれていない

ソフトウェア開発はV字モデルに従って行われることが多いです。そのため、テストは"開発物が仕様通りに動くかどうか"を確認することになりがちです。しかし、彼らのチームは開発時にテストの設計も行います。テストの観点から開発設計に対して指摘をすることもよくあるそうです。また、テスターがあらかじめどのようなことを重点的にテストしたいかを伝えておくことで、開発者がその部分を意識するためバグを減らすことができているそうです。

忍者式テスト

過去のチケットを含めて毎日少量ずつテストを実施するという@m_sekiさん考案のテスト技法。テストを実施するチケットは一定期間ですべてのチケットが回るように工夫してあるとか。忍者式テスト自体は何度かお話伺ったことがありますが、てっきり"若いシステム"に対して有効な手段だと思ってました。今回、対象のシステムが15年以上のシステムだとの話を聞いて、軽く戦慄しています。

テストケースのメンテナンス

仕様が変更になった時、対象となるテストケースは同時期に修正されるのが一般的です。しかし、彼らのチームでは、テストケースの修正は気付いた時に実施するそうです。膨大なテストケースに対して、必要な変更をすべて洗い出すことに膨大な時間がかかることを理解しているからこその対応です。また忍者式テストによって、彼らのチームはすべてのチケットが一定期間で回り続けます。そのため、チケットが仕様変更の対象かどうか気付く機会が多いため、テストケースを適宜修正しても問題が起きないのだと思います。

彼らのチームの何が羨ましいのか

彼らの話を聞くたびに、「彼らは最高のチームである」と感じますし、「彼らのようなチームで働きたい」と感じます。そんな羨望の理由を自分なりに整理してみます。

何が"最高"なのか

彼らのチームは理想的な働き方を体現しています。彼ら以上に理想的な働き方ができているチームは知らないため、"最高のチーム"だと思っていますが、その漠然とした"最高"が何なのかをもう少し明確にしてみます。

• 技術が"最高"なのか

@m_sekiさんは一流の開発者ですし、@miwa719さんは一流のテスターであることは疑いようがありません。彼らがとても高い技術を持っていることは間違いがありませんが、彼らの技術に対して羨ましいと思っているわけではなさそうです。ことソフトウェアテストの分野で彼らに接する限り、技術を前面に押している印象はありません。もちろん彼らの活動が高い技術によって支えられている部分があるのですが、技術に関して言えばもっと技術を前面に押し出している人がいると考えています。そのため、自分が感じている"最高"は技術ではないのでしょう。

• 品質が"最高"なのか

彼らの活動から"品質が低いものができるはずがない"と確信しています。全員が良いものを作るために同じ方向を向いている彼らのチームは"最高"の品質を作りこめるレベルだと思います。しかし、彼らの製品は一般消費者向けではないので、自分が彼らの品質を体感できる機会はほぼありません。そのため、自分が感じている"最高"は品質ではないのでしょう。

最高のチームワーク

彼らのチームは、誰かの問題を自分の問題として真剣に向き合ってくれるメンバーで構成されています。トラブルが起きた時でもを全員の問題として捉え、知恵を出し合い、そのチームの中での最善手を選び続けているのだと思います。そんなところを羨ましいと感じています。

彼らのチームは、完璧なものなどないことを理解した上で、それでも理想に向かうために改善策を出し続けています。人はミスをしますし、完璧な成果物を作成することは不可能です。そのうえで、ミスを減らすにはどうすればいいのか、ミスが起きたことにどうやって早く気付くか、に注力しているように思います。そんなところが羨ましいと感じています。

そんな彼らのチームの「誰かの問題を全員の問題として捉え、知恵を出し合える」「人はミスをするという当たり前のことを当たり前のように受け入れ、その上で理想に向かうために変化し続ける」チームが羨ましいです。彼らのチームは私にとって"最高"に理想的な、最高のチームワークを持っているのだと思います。

どうすれば彼らのチームを超えられるのか

彼らのチームのどのようなところが羨ましいかが分かれば、それに対して自分たちにどのような改善が必要かが見えてきます。千里の道も一歩から。彼らのチームと自分のチームの差が千里あるとして、その一歩先を行くために、今の一歩を踏み出さないといけません。

• チームで問題を出し合える環境を作る

「言うは易し、行うは難し」の最たる例です。チーム内で問題を言い合おうとしても中々出てきません。出てきた問題を他人事に捉えられたり、問題を出したことで責められたり、そもそも自分の時間が惜しくて他人の話を聞くことに消極的になったり。話す側も聞く側も問題を出し合うことにメリットを感じにくいです。実際は良いものを作るうえでは必要でメリットが多いのだけど。
具体策はまだありませんが、ポイントは「心理的安全性」と「チームがどこを向いているか」あたりでしょうか。

• 現実に対して素直になる

完璧な環境で仕事をする。理想的かもしれませんが、現実にはそんな環境はありません。問題は「自分がうまくいかないのは、理想的な環境ではないから」だと責任を転嫁してしまい動けなくなってしまうことです。自分も他人も含め誰だってミスはしますし、出てきた成果に完璧なものなんてありません。それらから目を逸らさずに、その現実を踏まえた上で改善する方法を考え続けないといけません。

• アンチパターン？：個人の問題を技術で解決する

今回の考えを整理していて、最高のチームを作るうえで(IT的)技術そのものが重要ではないように感じました。求めるべきはチーム全員が一つの問題に向き合える環境であって、技術の高さではないかなと思います。では、技術が不要なのかというとそうではなく、チームの問題を解決するために技術が必要になる場面は必ず出てきます。チームの問題に昇華できていない個人の問題を技術で解決しようとすると、認識違いが起きてしまい、チームに良くない影響があるかもしれません。程度によると思いますが。
解決したい問題があったら、まずチームの問題として昇華してから解決する。その方針が良さそうかな、と思います。

まとめ

@miwa719さんと@m_sekiさんの開発現場は本当に魅力的で、話を聞くたび一緒に働かせてもらいたいと思います。そんな理想的な彼らのチームが何を大事にしているのかを理解して、自分でも同じところを大事にできると彼らのような理想的な開発現場が築けるのかな、と思います。