JaSST23 Shikoku 講演資料「新たなテスト技術の導入がうまく進まないのは何故か」

JaSST23 Shikokuの講演資料です。

Transcript

1. 新たなテスト技術の導⼊が 上⼿く進まないのは何故か？ ican.lab 熊川 ⼀平
2. 導⼊
3. 注意事項とご案内 ◈ 本講演はあくまでも個⼈事業主( 屋号：ican.lab ）としての個⼈的⾒解に基づく発表と なります。 ◈ 講演者の所属する団体等における意向などは⼀切含んでおりません。 ◈ 本講演の内容はSNS などのWeb に投稿しても構いません。但し、前述の2 点について注 意して投稿してください。 ◈ チャットは（使えれば）⾃由に使ってください。皆さんのコメントなども⾒ながらお 話できるとより理解しやすい話にできると思います。 （例：いまのところ良くわかんな かったです。 ） ◈ チャット欄での誹謗中傷や、誹謗中傷につながるような表現はおやめください。多い にボケていただいて構いませんがスベった際の補償はできかねます。 ◈ 講演の最後に質疑応答の時間（⽬標10 分) をとります。質問は⼝頭‧チャットの両⽅で 受け付けますが、チャットは流れてしまうかもしれませんのであしからず。
4. ⾃⼰紹介 ◈ 熊川 ⼀平 ( くまがわ いっぺい) ◈ 国内⼤⼿SIer にて、⼤規模⾦融機関向けのシステム開 発に従事した後、ソフトウェアテスト/ 品質保証に関す る専⾨家として様々なR&D 活動を実施。並⾏して多数 のプロジェクトの建て直しや改善を進め、その成果を 公表することで多数の表彰を獲得。 ◈ 現在は某団体に所属し、ソフトウェア品質保証のエキ スパートとして活動しながら個⼈事業主としての活動 も実施。 ◈ 連絡先 kumagawa.ican@gmail.com
5. ◈ 1 〜2 ⽇/ 週をベースに副業として活動中。 ◈ 個⼈事業主として主に以下の活動を実施。 ソフトウェアテスト‧品質保証/ 管理に関してのアドバ イザリー業務 品質改善/ ⽣産性向上に向けたプロセス改善/ 組織変⾰の コンサルティングおよび教育業務 アジャイル開発などのモダンな開発スタイルへの移⾏⽀ 援 社員教育/ 意識改⾰に向けた研修‧講演‧ワークショッ プなど その他、ソフトウェア開発をよりよくするためのお⼿伝 い ◈ HP https://icanlab.net
6. 受賞歴 ◈ JaSST Tokyo ( ソフトウェアテストシンポジウム東京) JaSST’14 Tokyo ベストスピーカー賞 ◈ 探索的テストを活⽤したシステム開発⼿法の提案 JaSST’19 Tokyo ベストスピーカー賞 ◈ 意図的にバグを混⼊させたソフトウェアを⽤いた研修の実践と効 果 JaSST’21 Tokyo ベストスピーカー賞 ◈ Excel ⽅眼紙を廃し，仕様書のレビュー効率‧品質を向上した事 例 JaSST’22 Tokyo ベストスピーカー賞 ( ※共同執筆者） ◈ 「３４プロジェクトが⾃分の⼿で開発プロセスをモダナイズした 話」 ◈ SQiP シンポジウム ( ソフトウェア品質シンポジウム) SQiP Best Report Effective Award(2017 年) ◈ Session Based Test Management による探索的テストの実 践 SQiP Best Paper Effective Award (2019 年) ◈ SONAR Testing 効率と客観性を両⽴した新たなテスト⼿法 SQiP Best Presentation Award (2020 年) ( ※共同執筆 者) ◈ コード⾏数を⽤いない品質分析技術と開発速度を落とさな い品質管理⼿法の提案 ◈ IPA/SEC 先進的な設計‧検証技術
7. いままでのキャリア ◈ 特定のプロダクト/ システムに対しての活 動 ◈ 全社的/ チーム横断での活動 ＜組織A 組織B 組織C 組織D
8. どんな⽀援をしてきたか 下記のような依頼を受け、個別にコンサルティングしながら改善活動を推進してきた。 ◈ いままでウォーターフォールのトラディショナルな開発をしてきた ◈ 開発⽅法を変えることによって問題を解決したい 1. ⽣産性を上げたい （原価を下げたい） 2. 品質問題を解決したい 3. 納期短縮要求に対応したい 4. アジャイル開発に挑戦したい/ うまくいかないので改善したい 5. トレンドの開発技術を追いかけたい/ トラディショナルな開発⽅法を脱却したい
9. テストプロセス改善の例 ◈ とにかくテストケースが多い。 ◈ ⽣産性をあげたいから改善してくれない か？ ◈ テスト設計以前の問題として、アーキテク チャの意図や根拠がない。 ◈ プロセス⾃体の⾒直しをしようとすると拒 否反応が出る。 結合テストはxx するもんでしょ？ （後⼯程でやることが減るとしても）単体テ ストのケース数を削減するなんて何事か！
10. 探索的テストは⽐較的導⼊しやすい 「なぜ⼤規模SIer で探索的テストを推進しているのか？ 〜NTT データが⽬指すソフトウェアテストの世界〜」 https://jasst.jp/symposium/jasst22hokuriku/pdf/A3.pdf JaSST’22 Hokkaido/ 熊川 ⼀平
11. 探索的テストの例 「なぜ⼤規模SIer で探索的テストを推進しているのか？ 〜NTT データが⽬指すソフトウェアテストの世界〜」 https://jasst.jp/symposium/jasst22hokuriku/pdf/A3.pdf JaSST’22 Hokkaido/ 熊川 ⼀平
12. ⾃動テストの例 ◈ どこから聞いてきたのか 「⾃動テストは⼯数削減できる」 というあいまいな情報から相談開始。 ◈ 単体テストはやらなくても結合テストでカ バーできるという理論が根強く、単体テ ストの⾃動化は受け⼊れられない。 ◈ 「やってほしいことは決まっている」 「そのための⼈⼿と技術を持つ⼈が欲し い」 「新たな提案など不要」 ◈ そもそも回帰テストは良くも悪くも勘と 経験で実施しているWF 開発 ◈ ところで開発者のどんな痛みを取り除き たいのか具体的に教えてもらえますか… ？
13. アジャイルテストの改善例 ◈ アジャイル開発(Scrum) におい て、どうやって品質を保っていくの かわからない。 ◈ 今までのウォーターフォール的な考 え⽅で重厚⻑⼤なゲートを設置しが ち。 ◈ とはいえ開発スピードも落とせない ので結局ゲートが機能しない。
14. アジャイルテストの改善例 Scrum チームの責務 ベータ版として先 ⾏リリースして担 保 ◈ プロダクトが成⻑していく過程の全 体を捉えて、如何にして改善してい くかを考える。 ◈ 例えばリリース戦略を⾒直し、リ ターンを超えるリスクが⽣まれない ように、リスク低減策を考える。 例：Developer preview や、クロー ズドベータ版として⼀部ユーザの利 ⽤によって確認をしていく。 何をどこでリスク低減するか考え る。 ◈ 開発⾃体が変わっていくのだか ら、テストや品質に関する考え⽅も 変えていかねば。
15. 新たな技術や考え⽅を導⼊する重要性 変化を受け⼊れることによるリスク ◈ 現場作業の混乱 ◈ ⼀時的な⼯数/ 作業量増 ◈ なれない作業によるミス ◈ 導⼊反対派による抵抗/ 分断… ＜変化しないことによるリスク ◈ 技術者のモチベーション低下 ◈ 相対的な⽣産性低下/ 品質低下 ◈ 技術者確保の難易度増 ◈ 更なる技術発展への追従が困難 に
16. 技術導⼊がうまくいかない事例
17. ⽇経の調査結果 ◈ 左記の調査結果は2011 年のものと古いが 依然としてWF 開発を継続しているPJ の多 くの状況は変わっていない。 ◈ 多少贔屓⽬に⾒ても、結合テストツールの 利⽤率はトラディショナルなWF 開発をし ていれば50% に満たないだろう。 ◈ このような結合テストツールの導⼊のよう に、なぜテストツールをはじめとして新た な技術が導⼊できないか事例をもとに考え ていきたい。 開発⽀援ツール徹底調査2011 テスト編/ ⽇経SYSTEMS https://xtech.nikkei.com/it/article/COLUMN/20110512/360286/ 結合テストのツール利⽤率（有効回答1648 ）
18. プロスペクト理論 ◈ ⻑期的な利益よりも短期的な利益 どちらがほしい？ ◈ いま貰える10 万円 ◈ 1 年後にもらえる12 万円 ◈ 損失を過⼤評価する どちらを選ぶ？ ◈ 100% もらえる100 万円 ◈ 50% の確率でもらえる220 万円
19. 新たな技術や考え⽅を導⼊する重要性 変化を受け⼊れることによるリスク ◈ 現場作業の混乱 ◈ ⼀時的な⼯数/ 作業量増 ◈ なれない作業によるミス ◈ 導⼊反対派による抵抗/ 分断… ＞変化しないことによるリスク ◈ 技術者のモチベーション低下 ◈ 相対的な⽣産性低下/ 品質低下 ◈ 技術者確保の難易度増 ◈ 更なる技術発展への追従が困難 に 損失は回避したい ⻑期的なリターンは評価しにくい
20. 10 年前によく⾒た事例‧相談 なんか最近テスト⾃動化って流⾏ってるんでしょ？ うちもやってみたいからよろしく頼むよ。
21. 初期の私の対応 ◈ 丸投げが何かマズそうな気がしたが、⾔語化できなかった。 ◈ それでも「何も⾏動しないよりはマシ」と思っていた。 ◈ 少しでも興味を持ってくれるなら協⼒しよう。それで丸投げが変わってくれればい い。
22. 結果どうなったか ◈ ⾃分が⽀援をしている間はテスト ツールが活⽤され、成果を上げてい る。 ◈ ⾃分がいなくなったら途端に使われ なくなっていて、腐っている。
23. ソフトウェアであっても腐る ◈ 雑草や害をなす植物は世話をしないでも無駄に育つが、育てたい草⽊は適切に世話を してあげなければ腐ってしまう。 ◈ 適切な運⽤、保守が⾏われなければ例えソフトウェアであっても腐ってしまうし、気 づけば雑草という名の今までの運⽤や開発スタイルが⽣い茂る状況になってしまう。 ◈ なぜ、運⽤‧保守が⾏われなかったのか？そこまで考えて⽀援してあげないと成功し ない。 5. ⾃動テストシステムの開発は継続的におこなうものである テスト⾃動化に関わる苦労を10 とすると、⾃動テストシステムが完成するまでが3 、残りの7 は 運⽤に関するコストである。テスト対象の変化への追従、テストケース、テストタイプ⾃体の 追加、変更に対する適応、といった、今あるものが継続的に効果を発揮するための活動はもと より、⾃動テストのターンアラウンドタイムの向上、信頼性の向上、などなど、システムの価値 を向上させていくための活動など、やるべきことは多岐に亘る。テスト⾃動化システムの提供 はプロジェクトというよりサービスとしてとらえるべきである。 テスト⾃動化の8 原則 https://sites.google.com/site/testautomationresearch/test_automation_principle
24. なぜ運⽤‧保守は実施されなかったのか ◈ ⼿段と⽬的をはき違えてしまっていたか ら。 ◈ 「テスト⾃動化」は何か別の⽬的を果たす ための「⼿段」であったはずが、導⼊⾃体 が「⽬的」になってしまっていた。 ◈ すなわち、この事例であれば私が⽀援して 導⼊した時点で「⽬的」は達成できてし まっていた。
25. ⾃動テストの例 ◈ どこから聞いてきたのか 「⾃動テストは⼯数削減できる」 というあいまいな情報から相談開始。 ◈ 単体テストはやらなくても結合テストでカ バーできるという理論が根強く、単体テ ストの⾃動化は受け⼊れられない。 ◈ 「やってほしいことは決まっている」 「そのための⼈⼿と技術を持つ⼈が欲し い」 「新たな提案など不要」 ◈ そもそも回帰テストは良くも悪くも勘と 経験で実施しているWF 開発 ◈ ところで開発者のどんな痛みを取り除き たいのか具体的に教えてもらえますか… ？
26. 誤った⽬的の作り⽅ ◈ 「⽬的」が⼤事だ！と理解しつつも、誤った⽬的を作る⼈が後を絶たない。 ◈ 特に多い誤った⽬的の考え⽅。 ⼿段を決め打ちしてから、後付けで⽬的を作る。 ⼿段に対する理解が浅く、⽬的に対して効果を発揮するか⾒極められていない。 ⽬的の検討範囲も、⼿段の捜索範囲も極めて狭い。 具体的に誰のどんな痛みがなくなるのか？を考えよ う。 具体的な症状もないのに薬を処⽅するべきではない。
27. うまくいかない原因の構造その１ ⼿段 ⽬的 解 決 す べ き 問 題 の 順 序
28. 技術導⼊がうまくいかない事例その２
29. ⽬的からやってみた事例 ◈ しっかりと取り組みの背景を聞き出し、改 善順序を提案するコンサルティングを開 始。 ◈ 以下のようなことについて話し合い、⽬標 を決めてから改善活動を実施。 今回取り組みを開始することになった背景 は？ 取組みによって解決したい具体的なことは？ 短期的な⽬標と中⻑期的な⽬標は何か？ 現在想定している取組みで解決するのか？ 他にやるべき改善はないか？
30. ⼀⾒うまくいく⽀援 ◈ コンサルティングをすることで、⽬的意識 を共有し、間違いのない⼿段を選択できる ようになった。 ◈ また、⽬的が中⻑期で合意できていれ ば、助けてもらってオシマイではなく、中 ⻑期的に活動を続けてくれるようになっ た。 ◈ だが、うまくいくPJ とそうでないPJ が⽣ま れるようになった。
31. ⽣まれた新たな問題 ◈ 取組みがスケールしない ひとりで⼿助けできる範囲は 限られている ⼤企業であればあるほど、助けるべき組織は⼭ほど存在す る。 ビジネス上の成果としても、多くを助ける必要がある。
32. 技術導⼊がうまくいかない事例その３
33. 問題は標準化？ ◈ 当初、スケールさせるために標準化を⾏うべきだと考えた。 ◈ 開発⽅法が標準化されれば、多くの組織にとって解決すべき問題が共有できると思っ ていた。 ⼿段 ⽬的 開発⼿法の標準化？ 解 決 す べ き 問 題 の 順 序
34. 現代における標準化の難しさ ◈ いわゆる前時代的な開発標準はもはや通⽤しない時代になっている。 （個⼈の感想） 開発する⼈や組織形態の多様化 （オフショア‧ニアショア‧委託‧内製‧‧‧） 開発⽅法の多様化 （Scrum ‧SAFe ‧ウォーターフォール‧‧‧） 開発環境の多様化 （Java ‧TypeScript ‧Python ‧ABAP ‧Low-code ‧‧‧） 開発に⽤いる製品の多様化 (Spring Boot ‧SAP ‧AWS ‧Salesforce ‧React ‧‧‧‧） 重要となる開発メトリクスの多様化 （アジリティ‧ストーリーポイント‧DDP ‧信頼度成⻑ 曲線‧‧‧） 5M の要素 ソフトウェア開発における 理解 Man 開発者‧開発組織 Method 開発⽅法 Machine 開発ツール‧⾔語 Materials ライブラリ‧製品‧サービ ス
35. 標準化の弊害 ◈ 標準化は難しいだけでなく、様々な弊害も引き起こしていた。 標準に書いてあるからというだけで従い、その背景を理解しない ◈ まったく標準を適⽤すべきでない開発であっても、それが理解できない。 標準外の知識を得ようとしなくなる。忌避してしまう。 共通理解を作るために肥⼤化し、読む気もなくなるドキュメントになる（形骸化する） 。 改版に多くのユーザのコンセンサスが必要となり、時代に追従できなくなる。
36. テストプロセス改善の例 ◈ とにかくテストケースが多い。 ◈ ⽣産性をあげたいから改善してくれない か？ ◈ テスト設計以前の問題として、アーキテク チャの意図や根拠がない。 ◈ プロセス⾃体の⾒直しをしようとすると拒 否反応が出る。 結合テストはxx するもんでしょ？ （後⼯程でやることが減るとしても）単体テ ストのケース数を削減するなんて何事か！
37. 何を標準化すべきなのか ◈ 細かな⼿法や、箸の上げ下げのような⼿順ではなく、組織として⼤事にしたい「思 想」や「哲学‧考え⽅」こそが標準化すべき内容であった。 ◈ 「何を⼤事に考えるのか？」といった同じ思想や哲学をもっているからこそ、改善の ⽬的を共有することができるはず。 ⼿段 ⽬的 開発思想‧考え ⽅ 解 決 す べ き 問 題 の 順 序
38. 思想や哲学を共有している例 ◈ 「How to 」か ら「Why ‧What 」へ https://www.aboutamazon.jp/about-us/leadership-principles ◈ 2 枚のピザルール https://www.pmi-japan.shop/shopdetail/000000000028/
40. 少しずつスケールする取組み ◈ 開発思想‧哲学を共有することによって、ちゃんとした改善の⽬的を定義できる組織 が増えた。 （定義した⽬的は正解でないかもしれないが、構わない） ◈ ちゃんとした⽬的を定義できることによって、改善⼿段の選定を間違えることが少な くなった。 ◈ ⾃主的に改善を進める組織が⽣まれはじめ、改善がスケールしはじめた。 ◈ ただ、それでもやらない組織は動かなかった。 ◈ 思想や考え⽅は浸透させ/ 布教していくことが⾮常に難しかった。
41. 技術導⼊がうまくいかない事例その４
42. 基本的な知識の充⾜ ◈ ⾃⾝の知識‧経験と、現代的な開発⽅法‧考え⽅にあまりにもギャップがあるせい で、標準化した開発思想を受け⼊れられない⼈が出ていた。 例：テストではキャプチャをペタペタするものなんだから、それを辞めるなんてとん でもない。 ◈ 思想‧考え⽅の前に、現代的な考え⽅や開発⽅法を改めて学んでもらう必要があっ た。 なおかつ、押しつけではなく、⾃主的にやってもらう必要があった。 ⼿段 ⽬的 開発思想‧考え⽅ 学習‧知識‧モチベー ション 解 決 す べ き 問 題 の 順 序
43. 学習の仕組み化 ◈ ⼿の届く範囲から、少しずつ学び、その成果が確認できる「学習の仕組み」を考えた。 ◈ 押し付けの研修や、⼀過性のある取組みではダメ。持続する取り組みでないと、すぐに時 代に置いて⾏かれてしまう。 ◈ なので、⾃主的に勉強してもらう‧⽇常的に勉強することを継続してもらう仕組みが必要 だった。
44. 参考にしたもの ◈ 学習の楽しさ‧競い合い ◈ 学習の順序や進捗がわかる ◈ ⽇常⽣活に溶け込ませる⼯夫（短時間‧⼿軽） ◈ パパ‧ママは「勉強しなさい」というだけではダメですよ？ https://smile-zemi.jp/shogaku/ https://sho.benesse.co.jp/sho1/touch/
45. それでもやらない⼈がいる ◈ やらない⼈はやらない？ ◈ レイトマジョリティやラガードは遅れて やってくるだろう？で、いいのだろう か。 ◈ 教育などこれまでやってきた取組み は、経営層からみると「投資」 。果たし てこの投資はレイトマジョリティが参加 するまで持続するのだろうか。 ◈ いま取り組んでくれている⼈も、何年か 後にまた動かなくなるのではないか？ https://www.utokyo-ipc.co.jp/column/innovation- theory/
46. いままでのおさらい ◈ うまくいっている⼈といかない⼈の違いはなに？ ◈ ⾃分がコンサルに⼊って「成功するPJ 」と「失敗するPJ 」の違いは何だった？ 綺麗に答えようとするのではなく、素直に正直に答えるとなんだ？ ⼿段 ⽬的 開発思想‧考え⽅ 学習‧知識‧モチベー ション 解 決 す べ き 問 題 の 順 序
47. どうすればよいのか
48. アジャイルテストの改善例 Scrum チームの責務 ベータ版として先 ⾏リリースして担 保 ◈ プロダクトが成⻑していく過程の全 体を捉えて、如何にして改善してい くかを考える。 ◈ 例えばリリース戦略を⾒直し、リ ターンを超えるリスクが⽣まれない ように、リスク低減策を考える。 例：Developer preview や、クロー ズドベータ版として⼀部ユーザの利 ⽤によって確認をしていく。 何をどこでリスク低減するか考え る。 ◈ 開発⾃体が変わっていくのだか ら、テストや品質に関する考え⽅も 変えていかねば。
49. 組織⽂化＝カルチャーを変える ◈ 成功する組織とそうでない組織では明らかに「空気」が違った。 ◈ 「新たな技術を学習すること」 ‧ 「変化に挑戦すること」に前向きな⽂化があった。 ⼿段 ⽬的 開発思想‧考え⽅ 学習‧知識‧モチベー ション 組織⽂化‧⾵⼟ 解 決 す べ き 問 題 の 順 序
50. どうやったら変わるのか ◈ 個⼈的には以下の２パターンがあると考えている。 1. 個⼈の強烈なカリスマ性とリーダーシップによって 新たなカルチャーを作り上げる 2. 組織⽂化の出来上がり⽅‧仕組みをハックして、⼈ 為的にカルチャーを作り上げる カルチャーモデル 最⾼の組織⽂化のつくり⽅ 単⾏本– 唐澤 俊輔( 著)
51. 組織⽂化の出来上がり⽅ ◈ カルチャーは⽇々の⾏動‧⾔動のア ウトプットである。 ◈ すなわち、従業員/ 開発者の「⽇々の ⾏動‧⾔動」を変えるようなイン プットを与える必要がある。 また⾯倒なことがはじまったよ         or ⾯⽩そうだからやってみようぜ ◈ ⽇々の⾏動‧⾔動を変えるために は、その組織のMVV が⼤事になる。 https://www.cultibase.jp/articles/12667
52. MVV の重要性と誤解 ◈ ミッションだのビジョンだの、どうせ綺麗ごと並べて 俺たちの仕事には何ら関係ねーし。 ◈ もしそう思っていたのなら、それはMVV の作り⽅や内容が悪かったのでは？ ⼀⽅的に与えられるミッション。 与えられたミッションの中でしか考えられない‧作れない‧共感できないビジョン ⼋⽅美⼈すぎて誰のためのものだかわからないバリュー ◈ 本当に⾃分たちのMVV が確⽴できているのであれば、そもそもそれを共感できない⼈ は採⽤すべきではない。
53. カルチャーの重要性 ◈ ビジネスモデルだけ上⼿に考えたところ で、カルチャーモデルがついてこないと 成功に⾄らない。両輪の関係である。 EC を中⼼としたビジネスモデルにしてい た会社が、突然新たなビジネスモデルと して訪問販売を始めたとしても、営業組 織にはそんなカルチャーがないので成功 しない。 伝統と信頼で商売してきた⼈たちが、突 然に挑戦と変⾰を旗印にしても、現場の ⼼がついていかない。 現場が１つになるカルチャーがあったと しても、それをうまく実⾏せしめるビジ ネスモデルがなければ成功しない。 https://www.cultibase.jp/articles/12667
54. ⽂化を⽣み出す仕組み ◈ 前述の書籍ではマッキンゼーの7S を ベースとした7S フレームワークが提 案されている。 ◈ いくらMVV が素晴らしいものであっ たとしても、それを実⾏していく仕 組みがなければ機能しない。 ⼈事評価もされないのに取り組む意 義がない。 失敗が過度に咎められる⾵⼟があ る。 考え⽅が違う⼈ばかり⼊社してく る。 ピラミッド構造で上からの指⽰に従 わざるを得ない。
55. 具体的な活⽤⽅法 こんなMVV/ カルチャーを持つ会社の構造はどうなっているか な？ こんな会社の構造だと、どんなＭＶＶ/ ⽇々の⾏動になるかな？ 理想との ギャップ
56. ⽂化を変え‧仕組みを変える ⼿段 ⽬的 開発思想‧考え⽅ 学習‧知識‧モチベー ション 組織⽂化‧⾵⼟ 解 決 す べ き 問 題 の 順 序 ギャップを解決して 新たな組織⽂化を作りあげ る
57. でも、こう⾔いたいですよね？ それって経営層の⼈とか、組織の偉い⼈ が考えたり、できることですよね。 僕たちにできることなんてないし、 ほとんど関係ないんじゃね？ あきらめろってことか？
58. 全社的なものじゃなくてもいい ◈ ⾃分の⼿の届く範囲の⼩さな組織でカルチャーを作ろう。 ⾃分たちのチームのMVV は何だ？ ⾃分たちが働く意義は？そのプロダクトをわざわざ苦労して作る意味は？ チームの構造はどうなっている？ チーム内での評価はどうなっている？ チームの運営⽅針は？ どうやって共通の価値観を共有する？
59. ＋α ⼤事なこと ◈ 組織⽂化‧⾵⼟を変えるような取り組みをするためには、まず⼼理的安全性を⾼めな いといけない。⾃由な発⾔ができない組織で、かような改善活動など進むわけがな い。 ◈ ⼼理的安全性が重要だといわれる⼤きな理由はここにあるのでは？ ⼿段 ⽬的 開発思想‧考え⽅ 学習‧知識‧モチベー ション 組織⽂化‧⾵⼟ ⼼理的安全性 解 決 す べ き 問 題 の 順 序
60. エドモンドソンの 「４つの⼼理的安全性を損なう要因と特徴⾏動」 （１）無知だと思われる不安（Ignorant ） 質問や確認をしたくても「こんなことも知らないのかと思われないか」と不安になり、その 結果、気になることがあっても質問しづらくなってしまいます。 （２）無能だと思われる不安（Incompetent ） ミスや失敗した時に「仕事ができないと思われるのでは」と不安になり、⾃分の失敗や弱点 を認めなかったり、ミスを報告しなかったりするようになります。 （３）邪魔をしていると思われる不安（Intrusive ） ⾃分が発⾔することで「話の邪魔をしていると思われないか」不安になり、提案や発⾔をし なくなっていきます。 （４）ネガティブだと思われる不安（Negative ） 改善を提案したくても「他の⼈の意⾒を批判していると否定的に捉えられるのでは」と不安 になり、現状の批判をしなくなったり、意⾒があっても⾔わなくなったりします。 https://www.recruit-ms.co.jp/glossary/dtl/0000000230/
61. 全会⼀致の幻想 ◈ ⼈間は集団の中で意思決定をする際に、できる だけ和を乱さないように動いてしまう。 ◈ 特に⼼理的安全性が担保されていない組織にお いては、⼈に迷惑をかけたくない、余計なお世 話だって⾔われちゃうかも、⾃分の発⾔で遅延 を産んでしまうかもしれない、これ⾔ったらあ の⼈怒っちゃうかな… そう考えてしまうと、批 判的な意⾒は中々⾔えない。
62. 満場⼀致のパラドックス ◈ 統計学においては、全ての意⾒が⼀致すると逆に そのデータの信頼性が下がるということが知られ ている。 ◈ 通常、⼈は多様な意⾒を持ったり、誤った判断を するものなので、⾃然な状態では満場⼀致は極め て発⽣しづらい。 ◈ ⼼理的安全性が低く、⾃由な発⾔ができない場で あれば、全会⼀致が発⽣し、信頼性の低い判断が なされてしまう。 ◈ すなわち、組織⽂化を作るという議論すら、しっ かりできないということになる。
63. ⼼理的安全性を作るための⼯夫 ◈ （１）⼼理的安全性を体験できる仕組みをつくる （２）特定の⼈に偏らず発⾔できるようにする （３）何のために発⾔するのか共通した価値観を持つ （４）アサーティブ‧コミュニケーションを⼼掛ける （５）飲み会や⾷事会を実施する ◈ 悪魔の代弁者を⽤意する あえて批判ばかりする、反対の意⾒を述べるサクラを作る。 ⽇替わりでサクラを変える。 サクラであることは公⾔する。 https://www.recruit-ms.co.jp/glossary/dtl/0000000230/
64. 伝えたかったことのまとめ ◈ 新たな技術の導⼊だけでなく様々な新しい取り組みが成功しないときは深くまでその 原因を考えよう。より深いところから活動できれば、持続的に改善が進めていけるで しょう。 ◈ いきなり⼤きく活動するのが難しければ、⾃分の周りからだけで始めてみよう。 ⼿段 ⽬的 開発思想‧考え⽅ 学習‧知識‧モチベー ション 組織⽂化‧⾵⼟ ⼼理的安全性 解 決 す べ き 問 題 の 順 序
65. 伝えたかったことのまとめ ◈ 今回紹介したロジックはあくまでも私の⾒解にすぎません。 ◈ 皆さんならではの原因のピラミッドがあるのではないでしょうか？ 「結局xx が悪いから無駄」などと思考停⽌するのではなく、原因を考えてみましょ う。 ？ ？ ？ ？ ？ ？ 解 決 す べ き 問 題 の 順 序
66. さぁ？あなたは明⽇から何をしますか？ ⼿段 ⽬的 開発思想‧考え⽅ 学習‧知識‧モチベー ション 組織⽂化‧⾵⼟ ⼼理的安全性 解 決 す べ き 問 題 の 順 序
67. ご清聴ありがとうございました https://icanlab.net