お気に入り箇所

アジャイルを言い換える

昨日の書籍でもあったが、アジャイルはエンジニアが推進することも多いうえアジャイル自体に専門用語が多い。それらの「わからないもの」が組み合わさることへの拒否反応というのは計り知れない。そういった言葉を、わかりやすい言葉にすることで拒否反応を減らすこともできる。

なにより、アジャイルプラクティスを単純に適用するのではなく自分達の組織に反映させるにはという視点を持ち、十分に咀嚼して反映することができる。

顧客中心主義を実現することで ~中略~ プロダクトエンジニアチームを超えてアジャイルを拡張できる共通言語を作り出す。

顧客の使う言葉を共通言語にするのはドメイン駆動などでも出てくることなので、共通言語を作り出すのは一石二鳥。また、「顧客との対話が最も学習効率が高い」という本書でのプラクティスを実践しやすくもなる一石三鳥の手法。

ただ、業界によってはユーザーによって使う言葉が違ったりするのでそういった言葉の違いが何で生じているのかを考えることでユーザーの層を考えることにもつながっていくので「言葉」と意識するのはとても大切になってくる。

自分のチームやサイロの中で心地よい、一番簡単な仕事を優先する

これは組織論の話。組織重力の第二原則とも言われている。本書では、この法則を応用し、横断的チームを作ることで、分野が違ってもコミュニケーションを増やすという手法を提案している。

チームかしていなくても話しやすい飲み会マンにチャットが集中するという悲しいことがあったりする。そういう意味でも明確に「チーム」というものを作ってあげるのがいいのだろう。

事件の起こる部屋

事件の起こる部屋の要件がこちら

本書では事件の起こる部屋と書いているが、「何かが決まる部屋」という方があっているのでは？という気がする。そう、何か意思決定をする時のMTGの条件がこれです。

個人的に好きなところが「会議と呼ばない」こと、単純に「会議」という言葉が便利すぎて議論をする場も意思決定をする場も全て「会議」とまとめられてしまう。

困ったことに、議論をする場と意思決定をする場ではMTGに向けての準備や覚悟が変わってくる。急に「意思決定します」と言われても「いや、下調べ十分じゃないけど...」となる人が出てくるのは目に見えている。

MTGを設定するときは「〇〇を決める」みたいなわかりやすい名前でMTGを入れよう。

あと、改めて見たけど人数は10人というのはちょっと多いんじゃないかという気がする。この本の発刊が2018年とオフラインでの仕事が中心だったというのはあるのかもしれないが、今は5,6人くらいがちょうどいい気がしている。

デイリースタンドアップの使い方

なんのためにデイリースタンドアップをやるのかの目的意識の共有。振り返りやアップデートの時間。特にデイリースタンドアップ自体をアップデートしていく。

アジャイル自体が経験知と改善の繰り返しなので、デイリースタンドアップはその練習をする場というイメージを受けた。改善するというのは意外と難しく、慣れが必要な所がある。そういう意味でも、毎日行いかつ短時間で失敗しても影響の少ないデイリースタンドアップで改善慣れをしていくのはとても合理的。

常に仮説を立てる

仮説を立てるとは考えようという話だけではなく、結果を比較し自分の中のバイアスに気づくための方法。バイアスに気づくのは本当に難しいので、様々な方法でバイアスに気づくきっかけを準備する必要がある。

また、仮説では「定量的・簡単なもの」より「ビジネスと顧客に最も必要な質問を始めよう」とされている。定量的や簡単なものだと目先の数字などで本質を見逃すためだと思われるので、この辺りはチームの強さ次第で切り替えていいと思う

継続的にプロダクトやチームを改善していくには、継続的に「自分の問題を告白し、対応する必要がある」

この辺の感情労働のコストを減らすためにも、心理的安全性が重要になってくる。組織重力の第二原則をうまく使うこともありだろうなー

ベロシティで重要なのは市場でのベロシティ

アウトプットよりもアウトカムという言説に近い気がする。消化したストーリーポイントとカウントされがちだが、それだけだとエンジニアの中で終わってしまう。みんなでアジャイルをするためには、実際に顧客に価値を提供しFBを得て改善するという動きを早くする必要がある。

そのために、会社内のベロシティではなく、市場に対して顧客に対してのベロシティが重要になってくるという話なんだろうな。

ただ、これを行うためにはストーリーバックログや優先順位もアウトカムベースで考える必要があるなどエンジニアも顧客中心主義を持つ必要がかなりある。

かっこうのブログ