5回のなぜ
何か問題に直面したとき、立ち止まって「なぜ」を5回繰り返してみる
目的
5回「なぜ」を問うたら、表面的な症状の裏に隠された真因をつかむことができる
協力して働くとはどういうことかをチームに浸透させる
チーム内に共通の理解と視点を醸成し、メンバー間の距離を小さくする情報を明らかにする方法
あとは真因を潰す策を講じるだけ
sta.icon ここが重要
「明日からこうしよう」 ← こんな感じで スピーディーにプロセスやルールを修正できねばならない
前提
関係者が互いを信頼し、任せる環境であること
満たしてなさそうなら訓練する。以下ルールを課せばいいらしい
1: 初回はどんなミスをしても寛大に接する
2: 同じミスは絶対に繰り返さない
きちんと実行してもらえること
権限を持つ人が同席して指示するなど
つまり会社の上層部がこのプロセスを支持し、導入を推進しなければ順応性の高い組織はつくれない
マネージャーやチームリーダーの賛同を得ること
読者諸君も注意してほしい
sta.icon 言うねぇ
注意点
5回のだれ（悪者探し）にならないよう注意
スタートは小さく
我々は、顧客に直接関係がない社内のテストツールからひとつをえらい、その問題の診断に使ってみた。
お荷物問題（風土病）には適用しない
言い換えると 新しい問題が起きた時 に検討会を開く
関係者は必ず全員出席させる
検討会冒頭では毎回このプロセスの目的と原理を簡単に説明する
成功事例も示せるとなおよし
5回のなぜはスキルの習得に時間がかかる
sta.icon らしい。比例投資の勘所とか、検討会で全員を一致団結させるまでがしんどいとか、そういうこと？
Q&A
Q: 5回のなぜを促進したいのですが良い方法はありますか？
Ans: 責任者を置く
この人が議長になり、どの防止策を実施するのか、検討会後の何をフォローワップすべきなのかを決める
それができるだけの権限が必要
しかし参加できないほど職位が高くてもいけない
IGN の例でも責任者は必須みたい
sta.icon ガチで推進するマンがいないと「よくわかっていない人」を導けない？
方法
全員を集めて真因を追求する
会議室はとても混むかもしれないが、これはどうしても必要だ。
sta.icon そうかなぁ。対面だと言えない人もいるんじゃない？僕も対面で言うの苦手（タイミング計りづらいし会議時間伸ばしたくない）（それよりも非同期で書きたい）
参加しない人がいるとその人が悪者になる
若手だった場合 → 代わりはいくらでもいる
CEO だった場合 → 変えるのは無理だと思ってしまう
プロセスとは
IMVU では新人エンジニアに初日にプロダクション環境の変更をやらせる
ここで働く初日に壊せるほどプロセスがヤワだったら、それはそうしてしまった我々の責任だ
sta.icon このレベル。割と厳密に定めてる印象だなぁ。（社長さんが書いた本にあった）無印のマニュアルもそんな感じだったが
強いストレスを感じるが、このおかげで開発プロセスが堅牢になり、心配することなく創造的に働けるようになる……らしい
sta.icon うーん。そういうものかなぁ。大まかな道筋は示してほしいけど、細かい部分は自由にやらせてほしいと僕は思うが（でないと創造性死にません？）
成功例
sta.icon 個人的に非常にわかりやすかったのでまとめたい
……と思ったが、長いのでやめるw
要点
なぜブログ記事を追加したり編集したりできないのか
比例投資として決まったこと
API 対応
CMS をもっとユーザーフレンドリーにする
バグのある gem を取り除く
gem 管理に bundler を使うよう修正する
API と CMS の FT を行うコードを書く（同じことをしたらわかるようにする）
デイビッドが承認しない限り、fri sat sun の prod 環境の変更を禁止する（＆これは #継続的デプロイメント 完全自動化が終わったあとに再び見直す） sta.icon 要するにちゃんと原因と向き合って、一つずつ泥臭く解決していこうぜってことだよなぁ
怠け者の人間心理的には「めんどくせえ」「いいから先に進ませろよ」となるが、こうやって解決していった方が結局は近道
全員がこの認識を持って日々議論・改善していると心理的安全性も醸成されていく
なるほどなぁ