#RSGT2024 day2 memo
day1に続き、終了直後に直さないままとりあえず投稿。
前日（day1）
day2
Keynote: Solving The Value Equation
Regional Scrum Gathering Tokyo 2024 - Solving The Value Equation | ConfEngine - Conference Platform
- 今日の話は他と違う。いつもはレガシーコードとか技術負債の話が多いけど。アジャイルアジャイル言われる前から携わってる。
- 今日は価値について、ソフトウエア開発で価値がどのように発現するかを語る
- より良い組織化や働きかたから始める必要がある
- システムで起こる問題は市場や組織からおこる。
- マッキンゼーが記事を書いた。開発者の生産性は測定できると言ってるが、賛否両論あった
- アジャイルコミュニティで２つの議論がおこった。ケント・ベックらは反論する記事を書いた
- 個人をを測定すると悪い作用が起こる。競争を生む、という主張
- 一人が問題を解決するのではなくたくさんのスキルを持った人々が解決する。
- 生産性そのものは価値では無い。ここが今日のスタート。
- 価値とは？
- スクラムでもソフトウエア開発でもよく起こる。ビジネスでも話がある。
- 開発者の生産性についての疑義
- まずお客様の課題を特定し、コードをかいてFeatureを本番化し、デリバリーして解決する。
- お客様が受け入れることで価値が発生する。
- チームのモラルが上がるなどのことも発生する。
- 努力し、アウトプット、その結果アウトカム、インパクトと続く
- インパクトが重要だが、多くのエンジニアはアウトプットを測定したがる。どの程度のコード量かとか。
- アウトプットを改善するためにトレーニングとかそういう対応をおこなう。
- 価値というのはなにか？生まれたものから喜ばれるもの。価値には様々な共通点があって、見えて感じ、測定できること。
- 会社が小さいと開発者のしごとぶりはよく分かる。小さな会社では生産性に問題が起こることはあまりない。
- 開発者の生産性を見るに当たって、どれだけうまく開発できているか、底に見えていないものは？
- 価値の発現の距離が見えていない。
- 距離の側面。社会的な距離、他の人に引き継がれ、最終的に勝ちになるまで時間がかかる。
- 構造的な距離もある。マイクロサービスの一部がお客様に対面しているが、背後には様々なシステムが絡んでいる。
- 時間的な距離もある。誰かがほしいといったときからデリバリーされるまでの時間。
- 様々なタイプの距離が我々から価値を遠ざけている。
- 負荷の側面。クライアントが複数アレば、プライオリティが下がってる可能性がある。負荷が大きければ大きいほど。
- システムの設計をする際にはこれらを考える必要がある
- 価値の種類について
- お客様に対する価値
- ビジネスとしての売上、市場についての価値
- 技術的の価値。システムが壊れれば影響するという価値
- 倫理的・社会的価値。社会やユーザーに対する影響の価値
- イノベーションと学びの価値。継続する必要がある。
- 文化の価値。
- ROI。投資対効果。計測できるように、めりっとが出るのかを見る必要がある。
- これらの価値の種類の共通性はあるのか？
- 計測と連携
- 目標にちゃんと連携しているのか？はみたほうがいい
- オーバーエンジニアリングみたいなパターンがある。目標に連携していない。良いことと思えるけど。お客様の価値に連携していない。
- しかし最善を尽くしたいという気持ちがエンジニアリングにはあるのでそういうトレードオフをしながらいい方向を目指さなければ行けない
- ぐっとハートの法則
- プロクシーふぇいりあ
- あるところで効果的でも別で問題がある可能性（副作用的な？）
- 他のものが犠牲になるというのは否めない
- 機能は短く小さくするのが良いと言える。でも…
- 例えばとても小さい関数でも、関数名は内容と合致していない。関数が15行以上書いてはいけないというルールがかかれて、犠牲をこうむった
- 継続が目標になっちゃうこともある
- 特定の目標があるとして最終的に着地はするが。思ったところに着地しないことがある。
- プロクシーふぇいりあ
- 干渉
- 組織の一部で問題が見えなくなる状況がアリ得る。他では見えるのに…
- 問題のドメイン・レイヤー
- みんななにか一つを解決すれば全てが解決すると思いがち、しかし、すべてのレイヤーで問題に取り組まないと行けない
- 価値の発現
- 何度もやることで解決に近づく。
- 問題の解決する方法は大きな問題を小さな問題に分割する
- 問題の大きさは組織の大きさに比例する。
- チームが大きくなるとコミュニケーションコストが高いので小さく分割する。
- チームが大きくなるとトレードオフが発生する。
- チームサイズのスイートスポットとして、
- ダンバー数。
- チームサイズ
- モジュール数
- デリバリーインクリメント
- Experimentation
- 大きなソフトウェアを小さく分解し、どうピースをはめるかと同じように組織も同じ様に解決しようとした。
- お客様と近いことが重要。価値の発現までの距離を縮めることが重要
- 様々なピースを作らなければならないが、重要なピースでも価値を見出すのが難しい。バリューチェーンが長い。
- こういう部分に分ける場合に辛さがあるときがある。分割するのが良いとわかっていてもやリたくないと想うことが多い。どんなシステムも大きくなると、複雑になるが、迂回するにしてもサイズ制約はどうしても発生してしまう。
- 大きいプロダクトに機能を入れるのは時間と技術的困難がある。
- プロダクトを小さく保つのは成功すればするほど難しい。顧客はより多くの機能を求める。
- アマゾンは非常に大きなECの会社だが、興味深いのは早い時期にくらうどこんぴゅーてぃんぐが必要と発見した。
- 社内でクラウドを作るろうとしたが、非常に巨額の投資をしなければならない。ECサイトなのに。このような対立する問題が発生する。
- アマゾンはAWSを作り、クラウドコンピューティングの会社をつくり、販売をおこなった。これが成功しなければならない。
- 業界のために仕事した。
- 投資してECビジネスとして使うとなると、価値の距離が遠い。業界のために出すことで価値の距離を引き寄せた。
- テスラ
- バッテリーのサプライヤーを選ぶより、バッテリーをつくるようにした。
- 優れたバッテリーを作ったら自分の車に使えるし、それをサプライできる。
- 価値をどう届けるのか、最大限活用できるのか。
- 何を最大限にするのか？
- アジャイルは時間あたりの質を最大限にしている。
- （ちょっと追いつかない）
- バリューチェーンのマップ。わーどりーマップ
- ケーパビリティの問題
- 結論
- QA
- Q: 成長と熟達度のどちらを取るか？ビジネスにおいて成長を期待することがほとんどだと想うけどすべてのビジネスを持ってる事業者は成長すること、ソリューションではなく、熟達することが成長（ーーーーー）
- アジャイルカンファレンスで初めて感じるのはみんながワクワクしている。発見し、持ち帰る、そして抵抗が起こる・摩擦が起こる
- 熟達した企業は必ずしも新しいことをやる必要がない。回せてしまう。
- そこそこに楽しみたいって人がいる中で少ない中にカンファレンスに参加する人がいる。
- そういう成熟した企業にいる人がスタートアップにいったら何が起こってるかわからなくなってくるうう。
- 逆にスタートアップの人が成熟した企業に行くとつまらなくなる。ゲームしたくなる。
- それぞれの会社にはそれぞれのライフサイクルがあるからそれを考慮する必要がある。
- 成長を是が非でもと進めるのは問題。安定的な会社になれば成長しづらくなる。
- アメリカの航空会社の事業内容で国内の規制によってマージンが薄い。結局金融機関とおなじになってる。マイレージが副次的なビジネスになる。そしてこれを売買することによって大きなビジネスになり、本来の輸送が二の次になっている。
- Q: 安定＝サスティナブルでは無いと思っている。様々な変化は起こる中、歓迎をもって受け入れる状況にしなればならない（なのかな？？判別できない）
- 価値の提供手法はどんどん変わっていく。
- 今日のアジャイルは未来に影も形もない形になっている可能性がある。
- Q: ラダーについて。それは期待されてるものか、そうでないもの、探索するもの、作り上げていくものなのか？
- 概念としては大きいものがいい。マルチユースのほうが価値の選択の幅がある。
- 企業の問題として、お客様の言う通りに作ってしまうという状況になっている
- +alphaをもっていくことがじゅうようでは無いだろうか
- Q: 一段づつ上がっていくのがアジャイルっぽいのかな
- アジャイルでは探査的・後発的に詰めていくけど、目標を持って進めるのが良いのかなと。
- やるべきことはやるけど、保険を掛ける形で同時に価値を持てないか、という。
- 大きいやらなければいけないことと別に小さいものを並行していけないか、先を見据えていこう
- 何を将来プロダクトに入れていくかを考えていこう。
- Q: VCみたいなところと付き合うとなると、成長しろというプレッシャーが強い。人数増やし、拡大するために価値を置き去りにするみたいなムーブしがちだけど、どう見ている？どう離れればいい？
- 何年も前からこういう状況になるのはわかっていたと想う。
- 我々はおごりをしてしまっていた。
- インクリメンタルな開発を辞める必要は無いが、目標に対してもっと配慮する必要がある
- 課題を解決するという事業がどんどん伸びていく。
- Q: 会社の中でも価値や価値創造、価値検証など、価値というのはつまり何なのかというを説明できる人がすくない。冒頭のOutcomeやimpactがそうなのか、とおもうけどどう考えてる？
- 価値定義は困難。
- 主体は人や人の集まり。そこから発生する。
- 一例として、砂。集まればシリコンチップができる。集まれば価値が発生する。熱意が集まる。
- Q: スタートアップは市場が拡大する課題を見つける必要があると言ってたが、VCから投資を受けるためにはスケールする可能性の課題とかを認知してもらう必要があるが、必要な価値に対するアクションはなに？
- VCを説得する立場に居なかったので、考えてこなかった。
- 我々が置かれているVC環境は相当違う
- 既知の課題は新規性を求められているとおもう
- ビジョンを広く持つことで価値を獲得しやすいのでは。そうなれば価値を拾いやすくなる
- ビジョンをもつ必要がある。
- しかしVCはそれを認識しない可能性はあるが、無いより良い（？？）
- VCは人ににお金をはってるは街はいない
- Q: 最初のキャリアは一人のプログラマーや技術的課題を解決するところから、が多いと想うが、そういう人たちはビジョンやチームとどうこれから付き合えば良い？
- ぜひ問題解決係として臨んでほしい
- 仕事で抱えている背景をよく知り、よく学ぶ。そのことでより良い解決手法を提案できると想う。
- 技術的な能力を磨くのも必要だけど、いろんな業界の手法を学ぶのが必要。
- 技術的な単純な問題を解決することもあるし、ビジネスサイドの問題を解決するんだということもできるかもしれない。
- 総合的に問題解決をできるように研鑽しよう
- Q: 成長と熟達度のどちらを取るか？ビジネスにおいて成長を期待することがほとんどだと想うけどすべてのビジネスを持ってる事業者は成長すること、ソリューションではなく、熟達することが成長（ーーーーー）
感想
- 価値の距離の話が面白かった。アマゾンの例はめっちゃわかりやすい。
- 作っているものの価値のシナジーを考えるという視点はあまり考えたことがなかった。短期的視点を脱するのに良い思考だなぁ
- ドメイン・レイヤーの話は分析とアクションを説明するのに使えそう。あと、過去自分は一つのレイヤーだけを解決しようとした感があるので反省した。
Living Process -ビジネスとチームと組織が自律的に連携と成長するフレームワーク-
- 組織全体の話をする
- チームの外の話
- 組織変革。
- どうやって我々は具体的に組織の壁を超えるのか、組織のきっかけとなるか
- スプリントで行う行為はどうやって決定しているか？
- 各種イベントいろんな側面で発生するよね
- どうやって意思決定しているのか、もしくはしていないのか。
- よくある議論
- ビジネス側で、次の四半期に売上1.3xしたいけど難しいかな。
- 技術的負債返さなきゃ
- こういう話をしてるだろうし、やるのが難しい
- リーダーがわかってくれるとやりやすいので経営陣もエンジニア出身だと…
- ビジネス側の問題、エンジニア側の問題、組織の問題を話すのはなかなかなかった
- 我々のチームはそういうことに直面することが多くなった。そこの解決策やアイディアの話をする。
- 思ったのは自分たちも相手も組織に不満がある、ならば自分を変えればよいが、立ち向かえない場合もある。目と耳を傾けるというのが今日機能のキーノーt−
- そういう課題に直面したときどういう状態になるか：硬直する
- みんな本気で向き合っている。
- 経営層の中で、チームで、意見が食い違う。困ってる、どうやって合意形成している？
- そもそも合意形成という言葉に頼りすぎている。
- 会話は前提だけど、会話で硬直状態を溶けるかというとそうでもない。
- ポジション争いじゃない、大切なのは世界をより良くすること
- 課題の全体を素早くことが大事
- そうじゃないと自分の殻にとじこもり、会話ができない人達になる
- リーンキャンキャンバスでまとめて、全体をみえるようにしている。
- なぜ課題か
- ヒト・モノ・カネが全て枯渇していく世界になる。過剰な状態は終わっている。
- 今までの手法・示唆はヒト・モノ・カネがあることを前提としている。その前提が成り立たない。
- これは日本だけではなく、世界で起きる。しかし日本が一番最初にぶち当たるのはチャンスではある。
- 揮発性が低い、コントローラブルな要素は順調だけど、その逆は不調。
- 揮発性が低く、コントローラブルな技術的な課題は今解決するべき課題ではない
- スクラムから離れようとした
- 実際はどうだったか
- Living management
- いろんなマネジメントはみえるようになった
- はっきりとした構造は見えなかった
- どのように関連し、作用し、行動を促すのか？
- 時系列も見えるようになったが、既存の振り返り手法では見えない、
- 既存の振り返り手法はタイムライン性が低い
- それぞれの意見や立場があるからコンフリクトしてしまう。こういうのはある種の自嘲？
- 対立してるひとどおしのプロトコルがないことに目を向けていない。
- プロセスはあってもプロセスをデザインするツールが無い。
- リーダーはがんばって読み取りをしている、それでもできなければ、専門家を雇うが、しかし専門家も隣の領域は知らない
- しかし我々はヒト・モノ・カネはこれから使えない。
- 新しい人、価値観が出てきても想像範囲外のプロセスをデザインする方法
- プロセスを生成するためのプロセス、何かをデザインするための仕組みを作らないと対立はのこったまま。
- まずは特定領域で用意されたプロセスからジェネラルなプロセスを作る。
- どんな手法が来てもジェネラルに取り組める枠組みを作る、。そして次にメタプロセスを作る
- すべてを一つにまとめて見れる。個別にダッシュボードを作らない、本当に集中するべきことにリソースを踏む
- 大量のメトリクスをどうせいりするか？
- 揮発性とコントローラブルの軸で整理した。
- 技術負債を解消としても全体をみて決定できているのか、そういう会話ができるマトリクス
- メトリクスを見て課題をアイゼンハワーマトリクスで優先順位付け
- エンジニア向けのHMWQでアイディアを作って優先順位付け
- 全体制を保ち、ロードマップで判断する
- 一部だけ変えることが重要。キャンバスのこの一つを変えるを生成し、あらいんしているかを見ていく。
- まとめ
- 既存概念や手法は整合させるためのプロセスがデザインされてない
- アジリティを保った形でデザインされている組織なのか
- 常に全体と部分をデザインできる必要がある
- まずはジェネラルなプロセス・プロトコルを提案した
- 次回はまた来年
QA
- Q:このプロセスを作り上げるに至るための苦悩は？
- 今回のモデルを作るために、2回モデルを変えた。
- 最初は振る舞いの振り返りをやった。メトリクスで振り返りをやった。
- どうもうまく行かない。なぜかと思ったらカテゴリが良くないという形になった
- 各ロールが興味のママに見るだけの振り返りをしてしまう。これは非常に無駄だと感じた。
- 組織として成長が鈍化する。
- 全体を見る必要があると感じたのでリーンキャンバスにのった
- Q: どうしても各領域の組織にマネージャーがいて、マネージャーとしてのチームがあるのですが、やはり言語が違うと感じてしまっています。これを一致させないと全体が一致がしないように感じています。何かいいやり方はありますか？
- そういったことをまとめるために何らかのキャンバスが必要。
- いろんなチームがあると想うんだけど、今はビジネス・チーム・オペレーションだけど、ほかの領域があるなら乗っけていけばいいともう。多くなったら階層化する必要はある。だいたい3つまでぐらいが認知負荷がひくいとおもう。まず全部乗っけて、階層化する。
- Q: キャンバス見たいけど来年？
- Yes。進化したすがたを見せます。
- Q: 当事者として、それぞれがやっていることに課題意識をもっているのでアレばプロトコルを作ろうとなるが、多くの会社は自分の領域ぐらいしか見れないと想うけど、どうやったら働きかけをできる？
- ヒト・モノ・カネがすべて枯渇するという話をする。
- 第三者からどう見えるというモチベーションをつくるのはできなくは無いが、多くの企業を動かすという感じではない。そもそもお金払わない可能性。
- そもそももうそんなに世の中ハッピーではないのことをどう伝えるのか。5年でたたむなら良いけど、続けるならどうする？
- Q: あなたの組織はもっと使えるものがなくなるんだよ、だから備えたほうがいいと伝えるということ？
- Yes
感想
- Yes
- Q:このプロセスを作り上げるに至るための苦悩は？
いろんな指標や手法が合ってもどっかで歪があるのを認識はしていたけど、そういうアプローチで検討していくかーという発見。
- 間をつなぐプロトコルが無いので、職人感覚でじゃあ今回はこれをとるかみたいなアプローチが多いイメージだけどこれがまとまれば、より自分たちにとって意味のある手法を選択し、計測し、意思決定できる期待感がある。
- 最後のQAで働きかけのためにヒト・モノ・カネの枯渇を出すのは、小さい企業にとってタイムスパンが長い話なのかなぁ。来年不便なく生き残るぐらいしか考えられない小さい組織だとどうなんだろうか。
1897年（明治30年）設立、老舗製薬企業のスクラムマスター増産計画
- 企業内でアジャイル展開をしている、しようとしている人のために具体的な手法。
- オフィスワークへのアジャイル展開の話
- 会社説明
- 製薬系
- 大阪と東京に本社
- 連結5600名
- 3500-5500億円
- 合併あり
- 医薬品以外の領域を持ったいる
- 医薬品業界の特性
- アジャイル展開を始めた理由
- 製薬事業は成功確率は低いし、金はかかるし、時間もかかる。
- 画期的な薬を早く患者さんに届けたい
- 思いがけないこと
- アジャイルが身近になる出来事
- アジャイル展開を始めた理由
- 厳しい事業環境
- 高い目標の実現
- 身近なアジャイル実践者
- 何をやったのか
- 社内展開時の課題と解決策
- アジャイルを展開する中での課題
- 知らんはいらん
- とかくいそがしい
- 新しい取り組みを入れる隙間がない
- 他の取り組みと抱き合わせる
- いつも会社の中で改善活動はしているからそれと抱き合わせる。
- 問題が起こった状況を打開する手段としてやってみよう
- レトロスペクティブやってみよう、とか。
- こだわりを手放す
- あくまで手段。手放すことも必要
- やらんとわからん
- 体験しないと価値が伝わらない
- 実績を積み続ける
- 行動をつづける。傾きをつけつづける
- 広報し続ける
- 仲間を増やす
- 一人でやるには実績の限界もあるので、仲間をふやしていく
- アジャイルを展開する中での課題
- スクラムマスター養成講座の概要
感想
- 製薬系のアジャイルというめちゃくちゃ大変そうな内容だった
- レビューっていったところで難しい気もするのでそのあたりどうやってるんだろうというのを聞けばよかったというのを今更気づいた
- アジャイル推進、やっぱりそれなりに根気よくやらなければなぁ。兼務でやるにはやっぱり難しい雰囲気を感じている。
「困っていることはありません」は物事の見方を変えるチャンス
- 困っていることの背景に知らないことは知らないと仮定したところから。
- 体験の共有。
- 関わっているチームの状況
- 頻繁にデプロイしてる
- リードタイム短い
- いい感じのよくできたチーム。
- モブワークをやっている。他のチームからも参考にされるようなチーム
- 「困っていることはありませｎ」という言葉がでるようになった
- プロジェクトにアサインされて、フォーカスし、集中するというスタイル。
- プロジェクトがリリースされると、落ち着くタイミングでそういう言葉が出るようになった。
- なんとなくもやもやするところがあった。
- 困ってることの例
- ランタイムのバージョンが古い
- テストコードstubしすぎ
- などなど…
- 結構困ってることってあるのでは…？？？
- なぜ違いが出るのか？
- チームはプロジェクトドリブンだけど、自分はプラプラしてるので視点がちがう
- 視点が違うということは、プロジェクト以外の視点をもつともっと楽しく強くなるのか？
- 困っていることはどんな状態？
- 本当に困っていることがない
- そんな状態はないと思っている
- 理想を掲げてる以上、なにか困っているからそうなっているのでは。
- 困っていることがあっても気づいてない
- こっちが今回の本丸。
- 本当に困っていることがない
- 問題発見力を鍛えるという本
- 問題も答えもない、問題はあるが答えはない、問題も答えもある
- 問題も答えもないから問題はあるが答えはないの状態に持っていくのが重要
- 問題を発見するということ。
- スコープを調節した問いかけ
- 困っていることはアリませんか？ー＞開発ワークフローで困っていることはありませんか？みたいに範囲を絞り込む
- 問いかけに着目した理由：問のデザインにかかれている。問の基本性質
- 問の設定によって導かれる答えは変わりうる
- 1on1でやってみた
- 最近困っていることありますか？
- 特に無いですね
- 開発ワークフローで困っていることはありますか？
- 承認フローのAの部分が面倒
- ー＞答えが変わった。
- 聞き方に工夫を与えると答える面白さ
- 最近困っていることありますか？
- 失敗例
- たくさん質問を投げかけたら、その質問の意図はなにかと返された。
- 連発するのも良くないが、意図が伝わっていないのはその通り。
- チームと自分に距離があるからコミュニケーションが密でもない。
- 理想のチーム状態が伝わっていないし。
- チーム
- 機能をつくってリファクタリングの計画もちゃんと組み込めるチームだから、課題にはちゃんと向き合っている。
- 問のスコープは良かったと想う
- スコープの調節に意識を向けることで問を発する側にも内省が促された。質問のタイミングを考えるようになった。
- 意図が伝わっている状態の重要性に気づけた。理想の状態はきくがわも持ってると良かったと想う。
- 現在の状態も知らなければならない
- 理想に対して本当に必要な問いなのか？
- まず観察する必要がある。
- 困ってるけど、気づいているけど、言えない状態というのもアリうる
- まとめ
- スコープを調節した問いかけは部分的に有効
- 意図が伝わっている状態の重要性を学んだ
- 観察が以下に大事なものかを学んだ
- 見立てる・組み立てる・xxx（問いの作法）
感想
- 自分も1on1でよく「いやー特に無いっすね」って言いがちなので、自分もスコープを制限して思考するのは結構有効だなとおもった。
- 逆も然りで、問いかけするときにあまりにもオープンなクエスチョンをするときってだいたい自分が用意してないときだなという感じがある。観察が足らないからふわっとした質問しかできてないなという感じ。
- 問いがいっぱい出てくるようなチームの視点を広げる方法も考えてみたいなぁ
スクラムとデッドライン、壊れゆくチームをつなぎとめるもの
kakehashi_Scrum and Deadlines - Speaker Deck
- デットラインとは
- ぜったいに超えられない期限
- 12月に冷やし中華はてきせつでは無いよね。
- どのようにデットラインが生まれる？
- 法改正とか、繁忙期・閑散期とか、ステークホルダーの要望だったり、競合のリリースにぶつけるとか…
- 荒ぶる四天王
- 時間・予算・品質・スコープ
- 時間に関わるのがデットライン
- 効能
- 優先順位を判断しやすい、集中、ほｇへほげ
- 課題
- 品質犠牲。柔軟性を失う、ストレス
- これらの課題は短い期限とか、非機能要件とか運用考慮されなくひかれる期限
- ということは、ちゃんと時間だけではなくもう３つも見る必要がある
- スクラムチームはどう開発するか？
- プロダクトや自分たちの不確実性に対して検査と適応をつかい進める
- デッドラインは何を生む？
- 価値貢献を生む
- 新生活シーズンに間に合わせたらその人の生活をより良いものにできるとか…
- 価値貢献を生む
- スコープと締め切りとリソースと品質
- 我々はなぜここにいるのか？
- デッドラインのWHYを明らかにする
- PO、ステークホルダーに聴く。
- 「守る必要ありますか？」みたいなBoolな質問はだめ。意味は見出してるに決まってる。
- なぜ今かを自問してみる。なぜそのタイミングか？後ろにずらしたら？ずらして失われる価値は？
- 狙っている効果を教えてください、間に合わない場合の機会損失は？
- これを明らかにすればモチベにもつながる
- デッドラインはわかったけどスコープで調整した居けどいい？で通じる？
- 自分たちの都合しかない
- 人なら追加するから！みたいな話になりがち。間に合わせるのが君の仕事だよ！っていわれたり。
- ブルックスの法則
- 要因追加は長くすることは合っても短くすることはない。完璧な作戦だけど不可能。
- ブルックスの法則を持ち出してもだめ。
- 知識の披露じゃない。
- こういう情報があって、健全性を保つやり方で合意すること。
- 人を追加しない理由を丁寧に説明する
- WHYに合わせてスコープ縮小を提案する
- その狙いならこの機能はリリース後追加できるよ、もちろんフィードバックをもらって優先順位を変えることもできるという伝え方
- トレードオフスライダーはどうする？
- デッドラインが発生している場合は時間がMAX。
- 予算品質スコープどうする？おすすめ
- 予算は慎重にするために3番目。
- 品質を2番目
- スコープが一番低い
- とにかく検査と適応。
- 顧客の体験価値に悪影響を及ぼさない程度の品質の妥協は発生するのは仕方ない。リリース後の借金返済計画を立てていく必要がある。
- デッドラインを乗り越えたら、トレードオフスライダーをもとに戻す。
- デッドラインが複数発生した！
- 複数ステークホルダーがチームに依存している場合に、別々の要望がやってきて、同じ締切を設定されるパターン。
- 優先順位を決められるか？
- 公平にやろうとしたら全部が間に合わない。
- 一つづつやっていくか？でも間に合わないものがある。
- 普段ペアでやってるけど、分業するか？コードレビューは適当に…？
- プランニング
- 独立したアイテムに着目してるから対話が発生しない
- デイリー
- 一応共有するけど、相手のことが全然わからないし、助けられない
- レビュー
- ステークホルダーは間に合いそうだから良し、メンバーもまあ他の人はよくわからん
- 振り返り
- 頑張ってるねー大変だねーみたいな謎のねぎらい。学びが得られづらい
- 結果的にスクラムイベントは機能不全を起こす。
- 集まる意味がなくなる。開発に集中したいし、朝会やめようとかになる
- どんどんコミュニケーション量が減る
- なんとかデッドラインを乗り越えられた先に待つもの
- チームはバラバラになってしまった。
- そもそも前提としてデッドラインが間に合う見通しが立つのか？
- チームはそれぞれの得意領域が集まった集合
- 結果的にチームを殺す
- プランニング
- 俺たちはスクラムチームだ。
- 自分たちが一番パフォーマンスを出すやり方を知っている
- ケーパビリティ以上のアウトプットを無理に出すとチームは崩壊する。
- どうステークホルダーと向き合う？
- 大事じゃないというふうにいわれたら？
- 大事大事じゃないとかじゃなくて、緊急度の問題。
- このやり方が最善だとわかってもらう
- 過去の実績や自分たちのやり方を信頼してもらう
- 他のチームは個別でやってるよ？っていわれたら？
- 1スプリントください、このチームのやり方を見てください、レビューを参加してみてください
- デッドラインが予測できるなら事前にチームを強化するのも手。
- 実際のケーススタディ
- ナビゲーションアプリ
- ヘルステック
- EMとしてジョイン。
- 他のチームからヘルプ要請があった。PMF目指していたのでデッドラインっぽいのはなかったけど、別のチームからエンジニアをヘルプしてほしいというやつ
- ヘルプは賛成だけど一人ではなくちーむで行きたい。属人性になっちゃったりするし。
- しかしチームで向き合うことは、自分のチームでやってることが泊まることを意味する。
- 一人だけだとオンボーディングコストも良くない。チームも壊れる可能性がある。
- 頭の中のPdMはなんとか両立してよ、って言ってたけど、実際にはいいよって言ってもらえた。
- 4sprintやった。一人ではとても終わらないボリュームだった。
- PdMは不安はなかったらしい。インサイトもできたし結果的には良かった。思った以上に早かったという感じ。
- 断っていたら…
- ビジネス的に厳しい
- 一人だったら
- 属人化がおこった
- 結果的にチームがチームであり続けられた。
- まとめ
感想
- 元気が良いTalkだったｗ
- 過去を思い出した感じがある。検査と適応ができないよね、というのは当時も感じててメンバーにも伝えてたなぁ。
- 頭の中でムリポより、実際の事例をみてると同じこと聞いてみても良いかもってきもちになった。あと煽らない。
プロダクトをあきらめるとき
Regional Scrum Gathering Tokyo 2024 - プロダクトをあきらめるとき | ConfEngine - Conference Platform
- 立ち上げる話はよくあるけど、逆の話をあえて。
- 標準的なスクラムの話じゃない。
- プロダクトのライフサイクル
- 黎明期
- 諦めたりしない。ひたすら次を確かめる
- 成熟期
- ユーザーが居て、大した機能作らなくてもお金はいる
- 最後
- 次の置き換えプロダクトのタイミングなので諦めない
- 諦めるタイミングは２番めのグロース期
- 黎明期
- 多くのプロダクトは成功できない
- 95%は失敗。
- 想定の結果を得られない。
- そう簡単にはすすまない
- なぜコケるのか？
- ニーズがないとか…資金が尽きたとか…チームの問題とか…
- 最大はニーズがない。42%
- キャッシュバーンレート
- プロダクトが単黒になれば増えることがあるけど、基本は右肩下がり。
- 経営者がめっちゃ無茶言うときはいがキリキリしているだろうなぁ
- 着地すれば会社がぶっ飛ぶ
- それまでに資金調達をする必要がある
- プロダクトが失敗する理由は資金とニーズがないことによる
- プロダクトデスサイクル
- 誰も使わない
- 不足機能をきく
- 不足機能を開発する
- （最初に戻る）
- 買ってないユーザーに不足機能を聞いてもだめ。いずれにせよ買わない。
- プロダクトは継続すべき？
- どう判断するのか？ニーズがない判断は難しい。
- キャッシュが尽きる前に成功できるのか？
- 費用対効果
- 取り戻すことではない。
- 追加でかける費用にメリットがあるのか？
- しかし「これまでいくらまで使っちゃったし…」と考える。
- そこまでかけたことが無駄になるのがすごく人間は嫌。これまでにかけた費用にめっちゃ意識が向く（サンクコスト）
- しかしどれだけ費用をこれまでかけたかはこれからのプロダクトの成功に寄与しない。
- でもそういうことを言う人はキャッシュバーンレートを見ている
- プロダクトバックログ
- 知識を得るためのPBI
- ユーザー獲得するためのPBI
- 使ってくれる人を確保する
- 収益を獲得するためのPBI
- はやくかくとくする
- 収益を改善するためのPBI
- コストを削減するためのPBI
- PBIの見積もり
- どんだけ手間なのか
- どれくらいメリットや利益があるのか
- ニーズが無いことを判断するのは難しい
- プロダクトリリースの半ばで
- マーケットあるっぽいし、リリースもできた
- ユーザーもまぁまぁ取れてる。しかし売上が足りない。プレッシャーがかかる中、どんなPBIを投入するか？
- キャッシュフローの誘惑
- なんとか石・なんとかクーポン・なんとかポイント…
- 実際にやくにはたつ。キャッシュフローは良くなるしね。
- しかしこのタイミングでやると大変しんどい状況に陥る
- ローンチ前に諦めるのは比較的かんたんだが、お金取った状況ではなかなかいきなりやめられない。そのための仕事もある
- ラーメン屋、1000-1500万で開店できるけどやめるとき…
- 予告期間分の家賃
- 従業員の解雇予告の給与
- 原状復帰
- 廃棄物
- など
- プロダクトを終了させるときの費用をPBIに計上する必要がある。
- なんとか石とか…
- 有償で出したら半年で止めるとか無理。お片付け費用
- お片付けするPBI
- 実行可能な状態で下の方に見積もっておく必要がある。
- 店じまいするためのPBI
- Tear Down PBI
- プロダクトを諦めるとき
- 諦めるときに慌てても間に合わない。
- 諦めたときにやらなければいけないことを先に合意する必要がある。
- 状況が悪化してからやっても洗い出せないし、その行為が嫌になる。
- そうしないとずるずるいってしまう。
- ほうって置くことでプロダクトは長くのこってしまい、会社のキャッシュフローを圧迫する
- 解決したい話題
- PoC死
- マーケットに行きたがらない。めっちゃお片付け大変になるので。
- ゾンビプロダクト
- 生ける屍。やめられないので人を剥がせない。撤退費用に投資したがらない。
- チームが専任できない一つ。兼任で乗り切ろうとする。新規プロダクトの足を引っ張られる。
- PoC死
- 新規プロダクトの稟議でお片付け費用を稟議の対象にしているか？
- 本当は乗っけなきゃいけない。稟議を通すというのはそのリスクを取ることである。
- まとめ
- あなたのプロダクトはいつでも殺せるようにしておけ
- そうすれば続けられる。
- 有耶無耶にすると、どこまでやればいいかわからなくなる。
- 諦めずに頑張れる時間が確保できるよ。
- あなたのプロダクトはいつでも殺せるようにしておけ
- プロダクトはたまたま継続的に会社に利益をもたらさなかったから、死んだだけ。
- 次のプロダクト、なるべく諦めずに続けていけるようにしよう。
- QA
- Q: プロダクトの撤退費用を稟議につむより条件は出したりして遠ちゃってる場合、あとからその費用を出すためにできることは？
- 本当にプロダクトがヤバい状態になる前に積んで置けば良い。バックログリファインメントでやる。
- この機能やったら便利だけど、じゃあこれを撤退するときにこれが影響するのはなに？とか。
- あとはころしやすいプロダクトにしておく。
- 20個新しいフィーチャーを追加したら一番ヒットしないフィーチャーは消すみたいなことやると、撤退費用も抑えられるし、コードの質も良くなる。
- Q: いろいろころしてきたが、終わらせるときって、そのときにどうやるかと考えてやってたりしながら翌週これも必要だったと気づくことが多い。知ってる範囲でどういうタスクが考えられるか？
- サービスを終了するときのプレスリリースをかいてみる。
- そのプレスリリースはいつまでにだして、どの程度時間をのこす？
- 縮退の方針は？
- 不吉な、って想うけどプロダクトの成功に集中できる手でもある
- サービスを終了するときのプレスリリースをかいてみる。
- Q: すでにゾンビになったプロダクトをどう対応する？ずるずるになって引くに引けない状況になっているのでは。
- ちゃんと辞めますが言えれば…
- （オフレコ）というウルトラアイディア
- 何らかの理由で止められると言えれば良いとおもう。代替サービスを見つけるとか。
- Q: ニーズの見つけ方とかも改善できるのか？
- Q: プロダクトの撤退費用を稟議につむより条件は出したりして遠ちゃってる場合、あとからその費用を出すためにできることは？
感想
- 新鮮な発表だった。なかなかない視点。先に費用を計上することで、逆に勇気をもらえるという発想は面白かった。
- キャッシュフローの誘惑が発生したときに同時にそのお片付けPBIを検討するというのは結構重要な視点なきがする。
- ユーザーに機能を聞いてはいけない…
