無い
以上終わり。
続きを読むふりかえりのマンネリ感に向けて
ふりかえりにマンネリ感がある
っていう話を聞いた。
確かに感じるところもある気がする。
これに対してどうしたらいいのか。
なぜそうなるのか。
----
どういう状態なのか？
----
そもそもまずいことなのか？
ふりかえりの目的、というかレトロスペクティブの目的。
プロセスなどを検査し、適応する。
なんかこれ自体はできている気はする。でもイマイチらしい。
----
似たような話題がスプリントにもあった気がする
スクラムガイド2020 版で導入された、「プロダクトゴール」
ともすれば毎スプリントごとに何かを作る野菜切り係となってしまうスクラム。
短期的な目標だけではなく、長期的な達成目標を設定しましょう、っていうやつ。
XP だと四半期サイクル、みたいな
日々の目の前のことだけじゃなく、長期的な目標が見えていることで、何に目を向ければわかるようになる。
ビジョンとかダイレクションとかで仕事の内容については語られることが多い気はする。
これがあるので森羅万象から自分たちが向かう方向が見えて、何を見て何を対応するのか日々判断できるようになる
----
これと同じことがチームにもあればいいんじゃないだろうか
要は、チームとしても、チームの長期的な目標を掲げる
要はミッションステートメントでしょ？はいそうです。
チームに名前をつけて、どういうチームになるのかを明確にする。
（あとはもちろん、人をコロコロ入れ替えない。）
自分たちがどういうチームになるのか。具体的に書いても面白いかもしれない。
小さいことから始めるなら、テックブログ書いて PV 何件、とかでも。
GitHub 年収予測でチーム総額がいくらになるとかだとちょっとアレかも。
----
これをやるとどうなるのか
自分の見ているチームでは、これをやることを提案してみよう。
（失敗したらひっこめよ）
観測範囲では、きちんとこういった目標を設定しているチームは士気が高い。
というか、やっていて士気が低いとか、戦闘力が低いチームは見たことがない。
あ、作りっぱなしでふりかえることのないチームはそうじゃないかも。
これはプロダクトゴールでも一緒なんだろうけど。
反復型開発とアジャイルは違う
反復型開発 イコール アジャイル開発ではないよね、という話
顧客価値の最大化を狙うとすると、思い込みで開発するよりも、より顧客について学習した状態で何を作るかを判断した方がいい。
そうなると、「何を作ればいいか」を継続的に探す必要が出てくる。
とはいえ仕様書で何を作ればいいかがわかるかというと、それも無理ゲーな話（できると思っているアタマユルイ人はいる）
となると、動くソフトウェアで触って確かめないといけない。
となると、動くソフトウェアを継続的に作る必要がある。継続的にドメインを学習するために。
＃継続的にソフトウェアを作る上で、小さいタイムボックス＆バッチで作るか、フローで作るかは選択の余地があり
そのため、アジャイル開発ではあるが、反復型開発ではない、というパターンは上記が実現できないので、おそらくない。
結果として、アジャイル開発であるなら、反復的に開発することが必要になる。
一方で、反復的に開発するというのは、コストがかかる。
ビルドの手間、リグレッションテスト、デプロイの手間、手戻りの際の管理の煩雑さ、漸進的な設計、、、
これらのものが意外とコンピュータリソースやクラウドやツールで何とかなってきたので、反復型開発が「ペイしやすく」なってきたので、反復型開発がしやすくなって気はする。
反復型開発のメリットは、アジャイル開発が実現できるだけではない。
スコープでコントロールするスタイルでトカゲの尻尾切りでプロジェクトをローンチできる。
いらない機能を作り込む代わりにコストと納期が伸びるのと、いらない機能を作らない代わりにコストと納期を約束できます、というのでは後者が望まれる場面も多い。
この場合は「要件定義」とかいうフェーズを済ませてしまう人も多い。
ヒアリングした結果のうち、優先度が高いものから反復的に作っていきましょう。
最悪の場合、作った結果を見てもらうこともない。
見てもらわないとなると、何のために反復型開発をしているのか、となるが、PJ をコントロールしやすくするため、となる。
金と納期は決まったから、最初に聞いた内容からできることだけ作ろうぜ。と。
それのどこが顧客の方を向いているのか、全く理解できない。ただのコントロール力不足じゃないですかね。
で、どうなるかというと、３割くらいは、検収・ユーザーテストで要件不足に気がつき炎上する。
こういうケースをアジャイル開発と呼んでいるケースが多く、「やっぱりアジャイルってさ〜」っていう人が割といる。いいかげんアジャイルアジャイル言われて久しいし。
いやアジャイルじゃなくてただの劣化スパイラルじゃないのそれ、と。RUP ですらないだろと。
反復型開発がアジャイル開発だ、と思っている人には、アジャイル開発がダメに見える。
アジャイル開発をしている人には、それってアジャイル開発じゃないよね、と見える。
側から見ると、アジャイルをやっている人は成功している物だけをアジャイル開発と呼んでいる、ように見えてしまう。
反復型開発はアジャイル開発の一側面であって全てではない、というのを理解していない人が多いので、名前も悪いよな、とか思いながらコーヒー飲んでいます。
漸進的探索とか目的に近い名前をつけておいた方が良いんだろうな、という気持ち。
『プロダクトマネジメント』を読んで
『プロダクトマネジメント』原題: Escaping The Build Trap を読みました。
良書でした。同時にビルドトラップを生み出す組織構造にも興味が沸いてきました。
翻訳は安心と信頼の Ryuzee さん。 -> Ryuzee.com
原題にも書かれている ”ビルドトラップ” とは、プロダクトを作ることが目的化している状態のこと。
一見プロダクトを作るということは正しいように見える。だってプロダクトで儲けてるんだし。
でもビジネスの目的はプロダクトを作ることではなく儲けること。
儲けるということは顧客が対価を支払うということになる。
ここでプロダクトが差し出す対価とは顧客の問題がプロダクトによって解決され流ことになる。
この辺りはジョブ理論の影響を受けていそう。
ジョブ理論 イノベーションを予測可能にする消費のメカニズム (ビジネスリーダー1万人が選ぶベストビジネス書トップポイント大賞第２位！ ハーパーコリンズ・ノンフィクション)
つまりビジネスの目的は、顧客の目的を解決することであって、プロダクトを作ることではない。
一方で、プロダクトを作ろうとする圧力は必ず生まれる。
そしてなんのためにプロダクトを作るのか、という観点が失われると、機能の開発が目的化する。
機能が増えれば品質を確保するためのコストは上がり、使いやすさは低下し、ユーザー離れを起こしかねない。
この辺りは実はアジャイル開発が苦手にしている分野だと思う。
（解決しようとしていない、と言った方が正しそう）
スクラムで言えば、初めにバックログありき。でプロセスが描かれる。
バックログを価値に変換するためにスクラムを組んだりして価値を届ける。価値。価値がある、はず。きっと。
この辺りを明確にアジャイル開発は語っていないことが多い。
なんせアジャイル ”開発” だし。どちらかというとリーンスタートアップとかデザイン思考とかが色強め。
アジャイル開発は改善も組み込まれているので簡単にベロシティは上がっていく。
ベロシティが上がると嬉しいことに(罠)、機能がたくさん作れる。やったね！
でもアジャイル開発がなぜ必要なのか、という資料に9999％の確率で現れる Chaos レポートの、64％ の機能は使われていません！という事実。（ちょっと古いけど。）
ベロシティをあげると、これらのゴミ、もとい使われない機能を実装できることになる。本末転倒では？
”開発” というスコープに視野を狭めてしまうと、非常にこういった罠にハマってしまいやすい。
本書ではそうなってしまう理由を解説している。
要は顧客の問題を理解しないまま作ることが目的化してしまうという。
プロダクトマネジメントは顧客のないを解決しなければいけないのか、プロダクトの機能の Why に集中すべし。とのこと。
顧客に会って、顧客の行動を観察して、何を解決しなければいけないのか、また、今わかっていないことはなんなのか、次にやることはなんなのか、という型を提示し、事例で示している。非常にわかりやすい。
この型を通じて活動することで、Unknown unknowns が見えてくることになる。
この領域がないと断じて作り始めてしまうと、顧客が求めていないものを作ることになり、ビルドトラップにはまる。
（あれ、これってなんかウォーターフォールみたいだな。ウォーターフォールって究極のビルドトラップなのかも。）
また、この書は明らかにプロダクトマネージャ、プロダクトオーナー向けの本だが、同時にエンジニアやデザイナー向けの本でもあると思った。
イソップ寓話でいうところのダメなレンガ職人になっていないかを常に考えないといけない。
というか、「これを作って」って言われたら、いつだって、「なんで？」って聞き返さないといけない。
「何を解決したいからこれが欲しいの？」がわからないまま、表面的に言われたものを作ったところで、使い物になる可能性は低い。だってわかってないんだから完了条件満たしてるかわからないじゃない。
「完了条件は Acceptance Criteria に書いておいて下さい。」とか言い出す人もいる。きっといる。間違いなくいる。今脳裏に3人くらい浮かんだ。
その発想はおそらく、”個人との対話よりもツールやプロセスを重視” している。態度がプロダクト開発に向いてない。
Outside-in 志向で仕事をする。最終形から逆算して必要なものを作る、という発想でものを作らないと、言われたものを作る思考になりやすい。
会話が面倒だからって言われたものだけを作ろうとするといつまで経っても「仕様変更が多すぎてクソだわうちの客」とか愚痴り続ける人生になりそう。
少し触れられているが、「何をするか」を指示するのではなく、「何を解決したいか」を提示し、どうそれを実現するかは任せてしまえ、とある。
個人的にはチケットは状態で定義せよとスクラムチームに言っているのと同じ内容だったので安心した。
エンジニアとしても、Why を理解し要とすると最終的には顧客の何を解決するのか？に行き着く。結果、ドメインに踏み込んだ理解をする形になる。
ここまでくれば次にドメインの構造が見えてくるから、まともな設計もできるようになってくる。結果として変更しやすく理解しやすく、説明不可能なロジックが生まれなくて済む。割と。まあ勘違いしてたなら直せばいいし。
この本の面白いところは、組織としてプロダクトマネジメントを阻害する要因にも触れている点で、プロダクト企業の経営層にいる人は常に自分たちがこの状態に陥っていないか、PdM が顧客と話しているか、上司の顔ばっかり見ていないかを常に考えるべしという警鐘にもなっている。リーンエンタープライズにも少し近しいところはある。
組織として、戦略として、プロダクトマネジメントを据え置く上でどう構えるのか、どう構えるのが NG なのか、この辺りは組織論としても非常に興味深かった。
（ツリー構造の組織だと途端に顧客を見なくなるフォースが起動するから正直うまくいくのかなーという気はしなくもない。）
改めて、良いものを作るためには何を作るべきでないのか、を理解しないといけないなあと思わされる本だった。
----
この本を読んだ直後に社内で新サービスの話が出たときに、作る前からビルドトラップが生まれていてうーんこれは意識しないと本当に自然にハマってしまうんやなあと納得した。怖い怖い。
改めて考えてみると、「なぜそれを作るのか」を理解していないならそれは “エンジニア“ ではなく“コーダー“ なのかもしれない。（個人の感想です）
ｰｰｰｰ
思い返してみると、5年くらい前か？新しくチームを立ち上げると言うので PMO（という名の何でも屋）で PL サポートした際に、前任者は言われたことを言われた通りにやる人間でクビになっていた。後任として入ったら、頼んだことをそのままやってくれず質問を返してくるのに答えてると自分が理解してないことが分かったのでよかった、ってだいぶ長い付き合いになった案件があった。
ビルドトラップもあんなもんなのかもしれない。言われた通りやるのって楽なんだけど。
でも考えてみると、目的を理解して仕事をしましょう、って新人研修あたりで言われるよな・・・・・・・（オチなし）
スプリントへの割り込みに悩まされた時に考えること
前回の続き
そもそもゴールに集中したら何を追加するかわかるじゃんっていう話をこの後に書いた
割り込む理由／どんな状況か／何を見て判断するか／対処方法
※ここに書いてあること以外にもいっぱいあるはず。
※割り込みが絶対にあってはいけないとは言わないですが、ヒステリックにゼロイチでないといけないということもないと思うので、割り込みが多いなって思ったら気にするくらいで。完璧なんてないので。 ※目安はスプリントゴールがもう無理ってなるかどうか
計画が立てられるほど見通しが良くない
こんな状況
- スプリント期間で何をやればいいのかを決め打ちできるほど、チームの置かれている状況の見通しが高くない。
- 必然的に、スプリントを進んできたところで新たな発見・ないしはやらなければいけない仕事に出会い、修正を余儀なくされる。
- 結果、割り込み誘発される。
- ウォーターフォールは変化に対応しにくいけど、同じ理由で変化に合わせたサイクルでないスプリントも変化に対応できない。
兆候
- 割り込みはスプリント後半に発生している
対処
- スプリント期間を短くする。
- またはタイムボックスで仕事をすることを諦める（フローで仕事をする。カンバンとか）
規律の乱れ
こんな状況
- PO が開発者（というか規律）に対する甘えを持っている。スプリントの途中で頼めばいいだろう、という発想でいる。
- 結果としてデリバリーが混乱し、チームの規律を乱すことを許し、プロダクトのアウトプットも低下する。結果として、ROI を最大化するという PO の責務を果たせていない、ということに気付いていない
- PO は常に一歩先、二歩先を見越して何を解決すべきかを考え続ける必要があるが、受託請負メンタルの PO には難しい。役割名通り、オーナーシップを持っていないとこの辺りのことを考えられない。
兆候
- 割り込みを追加する際にチームとしてルールや規律を設けていない
- 開発者は割り込みを受け入れることで、ゴール達成できなくてもしょうがなくない？というコミットメント放棄がバーターとして許されるという甘い罠にハマっているので、スプリントゴールの達成がされない
- スクラムマスターは見て見ぬふりをしている
対処
お前の目は節穴か
こんな状況
- スプリントのスコープがコロコロ変わる
- ドメインについてあまり理解していない PO や開発者で構成されている。受託みたいな。
兆候
- スプリントのいつでも割り込みがある
- PO はドメインについてあまり詳しくない
- スプリントレビューで初めてトンチンカンなもの作ってることに気づくことが多い
対処方法
結局のところ、ドメインの不確実性のためにアジャイルな構えが必要というのは、１だったり３だったりで複合的、というか、相対的なものなのかもしれない。
同じシステムを新人や未経験のチームに任せるということは、相対的にそのドメインがチームから見て不確実性が上がっているように見える、のかもしれない。知らんけど。
