第３回『組織を変える５つの対話』読書会｜アジャイル読書会@札幌
アジャイル読書会@札幌は、札幌でアジャイル開発を実践する（したい）メンバーが集まる、熱い読書会です。
参加者同士のディスカッションを経て、自分の仕事に活かすヒントを見つけることを目的に活動しております。
現在『組織を変える５つの対話』を読み進めております。
読書会の形式は、書籍の各章に毎回担当者を割り当てて、事前に発表のスライドを作成し、当日発表、その後ディスカッションのような形式です。
今回は１０人の参加となりました。
個人的な振り返りとして、読書会を通じて感じたことや、読書会後に振り返った事を、以下にまとめています。
第５章 WHYを作り上げる対話
くまごろーさんの発表。
【結論（まとめ）】
本書のまとめとしては以下の①②③でした。
①本質的な関心事と表向きの主張を区別し、表向きの主張をめぐって議論が行き詰まった時に本質的な関心事に光を当てる
②意見表明と問いかけを組み合わせて、自己開示するべく自分自身の見解を共有しながら他者理解を目指して相手の見解に関心を持てるようにする
③チームのWHYのようなソリューションは共同設計する
【概要】
・【重要】それまでの（第３章、第４章）が成立していないと、この章の対話は成り立たない。
┗第３章は「信頼を築く対話」
┗第４章は「不安を乗り越える対話」
・「WHYから始めよ！」という名著がある。これはWHYから始めよと言っているが、本書では「いきなりWHYに手をつけない」とある。一体どっちなんだ？
┗答え）信頼と不安の問題を先に取り除く必要がある
・アップルの「Think Different.」
【①本質的な関心事と表向きの主張を区別し、表向きの主張をめぐって議論が行き詰まった時に本質的な関心事に光を当てる】
・対話中に表向きの主張と本質的な関心事を区別することで、実りのない議論が果てしなく続くことを避けられるようになる。
┗[表向きの主張][本質的な関心事]の２列の表を作って整理すると良い
【②意見表明と問いかけを組み合わせて、自己開示するべく自分自身の見解を共有しながら他者理解を目指して相手の見解に関心を持てるようにする】
・ペリーメイスンの罠
理由を説明したり、背景にある自分の見解を述べたりすることなく、立て続けに質問をしてしまうと、対話の相手を何か罠に嵌めようとしているように思われてしまうかもしれない
┗この罠を避けるために「自分の表向きの主張の意見表明と対話相手の表向きの主張についての問いかけを組み合わせることを目指しましょう。
┗このことは以下の図書でピーター・センゲンが提唱
【③チームのWHYのようなソリューションは共同設計する】
・共同設計のプロセス
共同設計のプロセスのためには、以下の５つが重要なポイント
(1) できるだけたくさんの人を巻き込む
(2) 真摯な質問をする
(3) 反対の意見を求める
(4) 議論のタイムボックスを設定する
(5) 誰が最終決定を下すかを定めて伝える
・それでは、アジャイル開発のプラクティスである、インセプションデッキは、何も準備をしないままに「共同設計」を始めてしまうという、愚かな行為なのでは？
┗結論としては別物として考えるべき。インセプションデッキはオリエンテーションの意味合いで、ワークショップを実施する際に採用される手法であるから、WHYを共同設計するプロセスとは違うのではないか。チームビルド初期にインセプションデッキのワークショップを行うが、３ヶ月後に再度インセプションデッキを再度行って、最初と比較した完成度の向上の度合いを見ることなど、オリエンテーションの中で生かされること（信頼関係の構築）が重要である。
【結論（まとめ）WHYのための手順】
表向きの主張（表向きの主張が衝突を続ける間は、議論が何も前に進まない。理由：それは本質的な議論ではないため）
⇩
本質的な関心事へ論点を移す（表向きの主張と本質的な関心事を分けて整理することで、本質的な関心事へ議論が向かうようにファシリテートする）
⇩
意見表明と問いかけを組み合わせ、自己開示と他者理解を重視して対話を前に進める（ペリーメイスンの罠に陥らないように！本質的な議論を前に進めるために、意見表明と問いかけを組み合わせたコミュニケーションを！）
⇩
チームで共同で意思決定を行う（共同設計には５つの重要なポイントがあるので意識して行うこと！）
第６章 コミットメントを行う対話
ミヨシさんの発表。
【概要】
・【重要】それまでの（第３章、第４章、第５章）が成立していないと、この章の対話は成り立たない。
┗第３章は「信頼を築く対話」
┗第４章は「不安を乗り越える対話」
┗第５章は「WHYを作り上げる対話」
【コンプライアンス対コミットメント】
・コンプライアンスとは、言われた通りにすること、ただ流れに身を任せること。ルーチンワーク。
・コミットメントとは、新しいチャレンジによって新しいビジネス価値を創造する必要があるシーンなどで、全身全霊を注ぐこと。
・チーム内で信頼を築けていない状態、チームがコミットメントを果たせなかった場合の影響について計り知れない不安を頂いている状態、WHYを設計することから外されてしまっている状態、にあるのであれば、コミットメントを行うことができない
┗コンプライアンスモードであり、フューチャー工場の姿である。
【意味について合意する】
・例を挙げるなら「完了」の定義を明確に行う。以下①②のようなビジネスサイドと開発者サイドの認識のずれはとても生じやすい。これを事前に言語化して合意することが、コミットメントを行うために重要である。
定義①：開発者側の試験を全て完了することで、開発完了とする
定義②：リリースされたサービスを不具合無くユーザーが使用可能な状態を、開発完了とする
【ウォーキングスケルトン】
・ウォーキングスケルトンを用いることで、コミットメントをどう書いて伝えれば良いかがわかるので活用する。ただし、ウォーキングスケルトンとMVPは混同しやすいので気を付けること
・MVPとウォーキングスケルトンは何が違うのか
・ウォーキングスケルトン・・・システムの最小限のエンドツーエンドの実装。基本的なアーキテクチャコンセプトの概念実証であり、実際に動作し、テスト可能なもの
・MVP・・・製品の最小限の機能を持つバージョンであり、ユーザーからのフィードバックを得るためにリリースされる
・ウォーキングスケルトンはシステム全体の骨組みを早期に構築することを目的とし、MVPは市場からのフィードバックを得ることを目的としている
【予測可能性と生産性】
・組織にはコントロールの欲求があるため、予測可能性が高くなるように管理を強めていく引力がある。管理が強まれば生産性が下がっていく（予測可能性と生産性の間にはトレードオフの関係がある）。
・最も予測可能性が高いとされる組織は、NASAである。NASAの開発者は開発者１人あたり年間数百行しかコードを書かない。
【コミットメントを行うために】
・「信頼」「不安」「WHY」の問題にまず取り組む
┗みんなが慣れ親しんだ、既存のコミットメントプロセスが、コンプライアンスモードではないだろうか？
・全員には受け入れられないことを念頭に取り組む
┗何をやってもコンプライアンスモードから抜け出せない社員がいる
┗コミットメントは必要なし
┗内発的コミットメントを得た社員がいる
┗推進者や伝道師となり、他の人たちにも献身的に試みるように促すようになる→結果的にプロジェクトは成功する
【私の痛い過去の経験を振り返る】
・出来立てホヤホヤのチームのMGを務めた時のこと。チームビルドのために、信頼関係の構築ができておらず、不安を取り除くこともできていないチームに対して、私からの中央集権的な働きかけで（チームの姿をこういう風に定義したいという結論ありきの相談にて）、コミットメントや、WHYの共同設計に着手する会議体を積極運用して、破綻させてしまった経験がある。
本書をここまで読み進めると、過去に私がどれだけ愚かなマネジメントであったかが、わかってしまいますね。
どういう形となるかわからないが、次にまたチームを持つ機会があれば、この経験や学びをもとに、リベンジしたいところ。
■懇親会の様子
お待ちかねのご飯です。
全７品。ボリュームタップリで美味しかったです。
■次回開催
ここまで読んでいただきありがとうございました。
次回の開催日は１０月１日を予定しています（日程確認中）
興味を持たれた方は、ぜひご参加ください！
この記事が気に入ったらサポートをしてみませんか？