普段スクラムを一緒に走り抜けてる阿吽の呼吸でコミュニケーションが取れるチームなら、もしかしたらWHATからの議論でも問題なく行くこともあるかもしれないけど、異なるチームとか、Roleとか、はたまた社外とか色々関係者が広がると、WHYの重要性はとても高いなと感じる今日このごろ
WHYを意識していると思っていたけど、実はWHATを話してしまっていたり自戒することは多々あるくらい、意外とWHYとWHATが混合しやすい気持ちもある。何事も混ぜるな危険だとおもうので、混ぜて話してしまうと聞き手からしたらそれWHATじゃない?WHYじゃないよね?え?僕としてはWHATだよみたいな本質からそれた場所を議論することになるので、WHY is 何という根本の土台と整えてから、WHYについて議論していくことはこれから意識していかないとと思っています。
> [!info] プロダクトマネージャーが書いたPRDの通りに機能をつくる?|小城久美子 / ozyozyo|note
> 私はPRD(Product Requirement Document)が嫌いでした。概念としてのPRDは好きですが、ドキュメントとしてのPRDが苦手、という話を聞いてください。 ① プロダクトマネージャーの仕事はPRDを書くことです、という誤解 実際に会社によってはそれをプロダクトマネージャーの主な責務にしているところもあるでしょう。しかし、私は .
> [https://note.com/ozyozyo/n/na3c85d4e64ff#0Np3x](https://note.com/ozyozyo/n/na3c85d4e64ff#0Np3x)
こちらのNote内にも書かれているんだけど、WHATはあくまでWHYを解決するための一つの方法で、一つのWHYには複数のWHATが存在している事があると思います。WHY無しでWHATを議論すると、同じ課題の為だったり、他の課題のためだったり色々解決したい事が混ざった状態で、方法論まで混ぜて議論することになるので、論点が上下左右しまくってしまうことは多いのかなと。
なので、書かれている通りまずはWHYの認識を揃えて、戦うWHYの順番を決めてうごくってシンプルだけど、なかなかできてない気がしていて、それができるだけで不安とか不満とか、なんのためにやってるんだろう?とかそういう悩み事を意識することなく、どうやったらよさそうか?とか、早く実現したいよね!とかポジティブに脳を使って、コミュニケーションもとれるいい状態になるんじゃないかなーとかは改めて思うことが多いです。
自分がWHYと思うことであっても、自分にたいして「WHY?」と聞くことでこれは、意見が混じったWHATだったなとか結構出てくるので、しんどいけど自分にWHYを聞き続けることは大切だなと感じてます。
例えば「コンテナ化する」というWHATがあった場合、WHYと聞くと「コンテナ化することで、runtimeの再現性や配布しやすさを高めたいから」という回答が生まれるかもしれないけど、これはWHYに見えて、実はWHATの「コンテナ化する」の説明をしてるだけだよね。という難しさがあるなと思ってます。「開発では動くけど、本番では動かない問題を解決したい」「稼働中の環境にデプロイして再起動とか、セキュリティパッチ会ってて再起動とか、復活しないリスクがあって怖い」とかそういうWHYがあると、たしかにそういうWHYには、「コンテナ化」も一つの手段だよね!やってみよう!とかって認識をあわせて前を向いて議論がしやすくなるなと思う反面、WHYを話すときには説明をWHYとしてしまったりする難しさがむずいなというのは確かにあるので、WHYを考えるときはFACTも意識すると、コンテナ化するとどうなる(という未来)ではなく、コンテナ化してない状態(現在)はどうなのかという風に整理していけていいなと
Dr.STONEのWhy-manってわけじゃないけど、「WHY?WHY?WHY?」と自問し続けることで、コミュニケーションを円滑に進めれることにもつながるなと思って、雑なメモとして書いてみました。雑でHow Toにもならず :bow: