>tokoroten: Will/Can/Must の例の３つの円と、アジャイルソフトウェア開発宣言が同一のものに思えてきた

> Mustしかないと大規模にやって大規模にコケる

> WillとCanがあると、ピボットして小さく実験できる

> なんか、そういうことなんだな…… それだけの話なんだな……

>perigsk: もしよろしければ、1枚目の図が掲載されている書籍を教えていただきたいです

>tokoroten: will can mustは様々な書籍やWebで紹介されているので、これといっておすすめの本はないのですが、この図は以下の書籍からです。

>tokoroten: つまり、なんで従来の企業が機能不全に陥っているのか、なぜDXをしなくてはいけないのかというと、 社会の変化速度が上がることで、Mustが機能不全を起こして、Mustをベースとした業務遂行ができなくなっている ソフトウェアのアジリティを生かすにはWillとCanが必須、Mustは次善 こういうことかなー

>nishio: 「Mustが機能不全を起こす」とはどういうこと？

>tokoroten: ソフトウェア会社の躍進による社会の変化速度の上昇 -> 不確実性の上昇 -> 事前の計画に基づく事業(Must)ではアジリティを保てなくなってきている -> 変更可能性の高いソフトウェアを支配下に置くことで、アジリティを獲得する必要がある

>nishio: 事前の計画に基づく事業(Must)がアジリティを保てないという時に、CanやWillはどう機能する？

>tokoroten: 失敗を伴う低コストな探索に対してコストを支払うことができるようになる

> Canが無ければ外注になり低コストにはできない

> Willが無ければ失敗による痛みに耐えられない

>nishio: なるほど、つまり「作業する一個人」に注目した場合に「やるべきことMust」が会社や上司から与えられ、できるようになり、実行するというやり方では遅くて、自分がやりたいWillできるCanことを先にやる必要があるがWillがなければ失敗回避するしCanがなければオーバーヘッドがでかい、と。

>tokoroten: その書き方だと現場が暴走しているように見えるので、デザイン思考による探索とか、アジャイル開発によるすり合わせとか、不確実性を前提に現場に権限移譲をする、という言い方かなー

>nishio: 「計画に従うことよりも変化への対応」の「計画」をMustと呼んでいて、それは「詳細度の高いMust」であり、マイクロマネジメント。もっと「抽象度の高いMust」「組織のOKR」だけ与えて詳細の決定を個人に移譲すれば個人のWillとCanに基づいて高速な試行錯誤ができる。

>nishio: 「詳細計画権の現場への移譲」

>tokoroten: なるほど、アジャイル宣言における「計画」と、Mustを過度にマッピングしすぎていたようですね

> 抽象度の高いMust（それはMustではなくObjectiveなのでは……）があればいいというのはそう

>tokoroten: WillとCanがあると、部署のObjectiveから個人のMustを作れる

> Mustは外から与えられる必要がなくなる

> 計画の詳細変更権を得ることができる

>

> なるほど、OKRの価値の一つはこれか

>nishio: 最初「Mustが機能不全」ってのがピンと来なかったのだが、事前に詳細にMustを言語化しようとしているなら、それが不確実性の高い状況で機能不全になるのはわかりやすい。不確実であるからMustの抽象度を上げる必要があり、それはObjectiveに近づいていく、ということね。

>nishio: なお僕のサイボウズにおけるMustは「中長期的視点でチームワークあふれる社会の創造に寄与すること」だと思ってます。それくらいの抽象度。まあ研究部門であることと長年の活動で細かい指示をしなくても有益そうなことをしそうだという信頼が培われてるって前提はあるので新入社員がどうかは別だが。