RSGT2024 Day1 memo
終了直後に直さないままとりあえず投稿。
day1
keynote: Dynamic Reteaming, The Art and Wisdom of Changing Teams
- （翻訳なし）
- タックマンモデル、キャッチーなフレーズだが、安定的に保っていればパフォーマンスが保てると聞こえは良い
- そんなに簡単にできる？
- アイディアは良い。うまく行けば簡単。
- 時間が経てばパフォーマンスがあがって魔法のような成果が出る。
- 一定にチームを保てれば素晴らしい。
- 現実はリチームが頻繁に起こる
- 新たなメンバーが加わったりいなくなったり。
- 深く考えてみた、たった一人の増減でもチームを変化させる。以前とはチームの雰囲気も力学も変わる。
- みんなの経験、過去一ヶ月どうだった？リチームあった？
- ほら、よくあることだよね
- こういったチームの変化は不可避である。
- いろんな手法を使ってよりうまいリチーミングが必要であると考える。
- チームが変わるのは時間の問題。
- 別にカンファレンスのあとにチームを変えろとか頻繁に変えるということではない。
- チームを変えるのも簡単ではない。僅かな変化が簡単でも大きく時間でかわっていく。、
- しかし、チームが変わるのは選択肢として持っておく。避けられない事象でもあると認識する必要がある。
- ソフトウェアで20年SaaSにいた。いくつかは上場や買収もあった。
- 15->800、10->900で退社したことがあるが、最初は一つのチームでもたくさんのチームに分かれる。
- 縮小することもある。
- 今は変化を経験しているチームのコーチングをロサンゼルスにすみながらやっている。
- 今回はダイナミックリチーミングを紹介し、どのようにコーチングするかを紹介する。
- 過去四年では縮小する会社も見たことがあるのでそういうサポートもできる
- チームの変化のエコサイクル、ダイナミックリチーミングの5つのパターン、どうやったらうまく変化できるか、アドバイスを今回はこれを伝える
- part1 エコサイクル
- リバりてィングストラクチャー？という本からの図
- まず始まりは落ちたどんぐりが埋まり、うまく成長できなければ貧困のトラップにハマるが、水などがアレば成長する。若年期
- 成長期。成長していく中で問題にあたり硬直の罠にハマる。
- 雷や稲妻などの想像できない破壊ののち、再生の段階に入る。
- これをチームに当てはめるとどうなるか？
- 新しいチームがうまれ、誕生期。
- 成長し、強力なチームに鳴っていく
- 成熟したチームになっていき、ソフトウェアでお客様が大好きなものを提供できる
- しかしプロダクトや会社が成長して採用で人が増えると意思決定がスローダウンする。硬直の罠。停滞している
- メンバーにはチームを分けたほうが良いのではという話になり、変化が入る。創造的破壊。
- その上で２つのチームが誕生する。この繰り返し。
- チームが変わるのは当然ということをこれから話す。
- 他のパターンもある。縮小とかも。後で話す
- 個人レベルでも発生する。個人、チーム、チームofチーム、組織、会社
- 様々な変化が様々なレイヤーで行われる。ダイナミックリチーミングは様々なレイヤーで発生する。
- なぜチームは変わるのか？
- 成長した、縮小した
- 新しい仕事が発生した。
- ナレッジ共有のため。チームの冗長性
- 停滞や学習のため、
- びっくりすること。コロナ禍みたいな事象。
- あとは…
- 新しいリーダーの就任。一緒に働きたい人を連れてくるとか
- Part2 5 patuerns of ダイナミックリチーミング
- one by one
- 一人ずつ
- 誰かが参加した、脱退したなど。
- 参加したときにできること
- 成功するためにオンボーディングでサポートする。逆のサポートもある。オフボード。
- この場合は二人一組で働くことがおすすめ。
- ペアプロなど。
- ひとりではないんだということを新しく入った人に認知させることができる。
- MarketOfSkillsActivity
- 自分が共有できることのポスターを作る。スキルとか趣味とか、教えられること、何を教えてほしいかなど。
- みんなが共通の話題を持つこともできる。ハイキングをしたりね。
- オンラインでもできる。ホワイトボードでも。
- 去るときにできること
- ORSCという組織から学んだこと。
- なにかをリリースしたら海辺で叫ぶみたいなことをやっていた。
- PdMがやめるが新しいPｄMは海に叫ぶという行為はJDに入ってないが、その慣習を残し続けることで、旅立ちを祝福できる。
- 誰がはいるか、去るかによってやることが変化し、実行が困難になることがある
- grow and spirit
- なぜ成長したら分割するのか？
- わざと大きくしたのかもしれない。
- チームがあまりにも大きくなるとファシリテーションを忘れることがある。
- ファシリテーションの仕方を変えなければ行けない。
- プランニングが30->90minになったりする。特定の人しか喋らなくなる。意思決定が難しい。コンセンサスを得るのに時間がかかる、関連性の無い仕事が増える。
- あえて戦略として、特定の仕事の仕方があって、違う仕事の仕方を取り入れたいという場合、分割するという手は使える。一部のチームがスクラムを使ってみたいみたいな感じとか。
- 意識的に成長させて分割する。アイディアを広めるために分割する。
- 仕事を覚えて分割する。
- 色々なパターンがある
- チームの分割をする前に
- 誰がチームに入れるか、誰をどのチームに入れようかを考える。
- チーム間で共有するメンバーがいるのか？
- オーナーシップはどうするか？ミッションと責任範囲は？
- チームを分割するならいつまでにやるかスケジュールしてタイムラインを作る。計画する。
- チェックリストを作って分割をするパターンがあった（Appforlioの事例）
- コードどうする
- チームを分割したあとに
- チームの分割と終了を祝う。
- フェローシップのスプリット。
- 貢献に対し感謝を示すいいタイミングといえる。
- 分割はレトロスペクティブで出てきたことが多い。
- レトロスペクティブでかけてるのはチーム編成に関する会話が少ない。
- フィッシュボールレトロスペクティブをやったりしている。
- チームメンバーの声はなんなんおか？どのように仕事をやりたいかアイディアを持っている。
- 全く違うオペレーションをする必要もない。
- merging
- 成長分割の逆パターン
- 会社が縮小するときに取りうる。
- やることが一時停止したり、去る人が出たり、悲しさのストーリー。
- 複数のチームが一つになる。
- なぜ起きるのか？
- Story Owe Team
- マージされたチームで、サポートするために、歴史を共有するために、チームごとのタイムラインを書く。個人がチームに参加した時期と名前を書き、何をおこない、何を達成したのかをスマホで録音する。何を誇りに思っていたのか。
- 歴史を共有できる。そうでもしないと、歴史を知り得ない。
- 1hぐらい。60名、ホワイトボードとかmiroでも良い。
- 前向きさにつながる。状況の不安を取り除くこともできる。
- Coach Larger Teams Of Organize
- some teams can do this easily
- other te.....
- isolation 隔離
- チームの脇につくる。
- 他のチームと違うやり方を作るのが重要。その自由を与えることが重要
- 緊急の問題を解決するために組織し、収束したら元のチームに戻る。
- 新しいプロダクトを作るために。他のチームと違うリズムで働けることが重要。
- より集中できる。気が散らない。
- SoSに行かずともどくりつしたチームとして存在できる
- サイロのメリットもある。一般に悪いみたいに言われるが良い作用を持つことがある。
- AppFolioの最初のチームは不動産のためのソフトウェアを作っていた。別のプロダクトを作りたくなったので、隔離して別のチームをつくった。
- そのチームにいることで特権のように感じる短所もあった。
- 不動産チームは2wスプリントでやっていたがSecuredocsのチームはそれでは遅すぎるので、新しいチームを作り、1daySprintでやっていくということにした。
- 不動産チームに合ってた方法はSecureDocsに合ってなかっただけ。
- 自由を与え、ミーティングに参加させるなみたいな交渉をした。
- 脇によったチームから始まり、新しいメンバーがはいって部署になり、別会社になり、買収された。
- マクドナルドの事例
- 1989のTeamworkという本
- マックナゲットはインディアナ州でうれてなかった。製品に問題があった。
- コンサルを雇ってコンサルが小さなチームを作り、全く違う場所で働くようにした。孤立したチーム。
- マクドナルドの官僚主義に影響されない独立したチーム。
- 隔離の戦術
- 会議室の中で仕事をしていた。他のチームに邪魔されず、自由に仕事した
- switching きりかえ
- one by oneに近い
- one by oneは新たな人の入退社。switchingは自分が情熱を傾けられることに向かっていく。やりがいと学習に向いている。
- 違うことを学びたい、違う人と働いてみたい。
- チームを変えないことは、喜びを制限しているのではないか。選択肢が合っても良いのではないか。
- なぜおきるのか？
- 戦略的に行うこともある
- 情報を広めたい。
- 誰かが情報を結果的に独占していて、やめるってなったときに失われることがある。
- その場合はペアワークやグループワークで情報を広める
- チームが情報を結果的に独占しているパターンもある。
- 切り替わることでOpportunityを共有できる。キャリア構築やチームの空きがあるときに誰に話せばいいのか。切り替えでOpportuniyを見せることでリテンションすることもできる
- Procoreのケース
- 50のチームがあった。
- チームが情報を共有したいという要求でプロダクトを開発していた。
- 二週間メンバーを募集していた。そういうサポートをやったりしている
- 二週間たってもっといたいとかの話をマネージャーと話したりした。
- 別のチームを試したりできた。
- one by one
- Part3コーチング戦術
- チームが変わることは避けられない性質
- より良くするためにどうするか？
- 変化を受け入れることも必要だが不快に思う人もいる。人間だしね。怖いだったりワクワクだったり。
- なるべく平準化・標準化していきたい。適応できるかどうかは人それぞれ
- 新しい始まりは凸凹するかもしれない。自分でやったり、気に入らない変化だったり。でもとりあえずやらなければ行けないときがある。
- 80名くらいの人が2クラスタのTeamOfTeamで新しい人がはいり3つにさいへんしようとしたケース
- どう適応し、どう採用し、どこに配置するか。
- 永遠にこの検討が続くかと思った。
- みんなが見れるところにこの議論を出しておいた。どう反応するか怖かったけど。他のチームメンバーもどのように感じるか、どうしたいかを考えてもらいたかった。
- あるソフトウェアエンジニアがホワイトボードをみて、こうしたほうが良いみたいなアイディアを持っていた。それを表明したことで変わった。
- 意思決定にみんなが関われる状況を作れた。
- 最初は怖かったけど、いろんなフィードバックやアイディアをもらえた。
- よりオープンにリチーミングする方法がある。
- 徐々に変わることのほうが簡単ではあるが急激な変化を取らなければいけない。
- リーダーは忍耐が必要である。
- 変化をみんなにオーナーシップを持たそうとした。オープンスペースのイベントとかカンファレンスをひらいて問題を解決したり。
- 共通のプロセス改善や課題がある。
- OSCやったり。
- コミュニティをクロスさせる。チームが再編したときに初対面ではない状態を作る。
- お客さんの課題を解決するためにソフトウェアエンジニアを雇っているわけだが、お願いすれば、人に関する課題を解決するために動いてくれることもある。
- QA
- Q: 所属しているところで編成の権限がなく、リチーミングに対してアクションをおこせない。そういう状態で編成に対してアクションを起こす方法があるでしょうか？
- なぜパターンとかで解決したい問題をきちんとする。マネージャーやメンバーとはなせるか？解決策を3つPro/conだしたり。
- じぶんだけではなく、複数の人間でコンセンサスを取る。声を大きくし、自分自身にも勇気をもたせる
- スペシャリストがたりないとか、依存が複雑ならマージしたら良いんですよというアイディアを出したり
- 自分の興味のあるところを調べ、まわりを巻き込む。
- 決済者に実験することを認めてもらう、結果をもって発表する。発表することで他の人が試したくなったり普及したりする足がかりになる。
- Q: チーム編成に取り組んでいる。ビジネスサイドではどのように取り組んだら良い？IT系はスクラムよりにチーム編成できているが、ビジネスサイドはWFっぽい感じに進んでいる。成長路線にズレが生じて苦労している。ビジネスサイドはとにかく早く仕事を勧めていかなければ行けないという状況だが…
- IT側にいるとビジネスからとおざかっている状況があるとおもう。
- ビジネスサイドのプレッシャーをIT側でも共感する必要がある
- 共感をもち、団結する必要がある。
- 上層部経営陣のレベルでも起こる。事業部長が他の事業部長の状況を理解していないということだったり。
- お互いどういうプレッシャーを感じているか、チームレベルでどう協力するかということを考えることが必要。
- Q: リチーミングの検討状態を共有し、オーナーシップ持っているのやってみたいと思っていた。見れる状態にはしているが、アナウンスをしたことがなかった。他にオーナーシップを持つためにいいアイディアは？
- レトロスペクティブで有益なことが出てきたらそれを外に発信することでより有益性がます
- 発信することがとにかく大事
- Q: QAの立場から。テスターというのは、アジャイルで大きく変わった。QA組織からチームの中に入り込む状況whole teamになったはずだが、チームがQAを弾き出すみたいな形になることがある。リチーミングでのトライとして、どういうふうに考える？
- プロダクトマネージャーやエンジニアがシフトレフトする中で変わること。受け入れ条件やリファインメントを前倒しし、QAがより活躍できる範囲を広げることができると思う。
- ランズワークというエクササイズがある。体制における関係づくりのためのコーチング。
- 共感の気持ちをどう強めるか。役割が違うところで、このエクササイズが良い。
- Q: 所属しているところで編成の権限がなく、リチーミングに対してアクションをおこせない。そういう状態で編成に対してアクションを起こす方法があるでしょうか？
感想
- Dynamic Reteaming邦訳だしてほしい
- チーム形態の変化のパターンがとても良くまとめられていた。
- 組織的な圧力で移動とかあるけど、この前提を持っていればもっとポジティブに組織変更を捉えられるんだろうなぁ
- 古今東西意思決定にみんなが関わるというのはよく言われることではあるけど、チームサイズや互いの信頼がない状態でいきなりやっても崩壊しそうなので常日頃の互いの関係性をまずは整備することがいますぐできることなんだろうなぁ。
Badプラクティスを選んで失敗しながら進めた新規プロダクト開発
- 新規開発事例をあまり聞いたことがない
- 成功のためにBadプラクティスを選択していたのをコミュニティに還元したい
- 自己紹介
- ゆのまえさん
- VPoE、EM
- 去年３月入社
- しいばさん
- フルスタックエンジニア
- 去年入社
- 最近メタル気になってる
- ゆのまえさん
- 会社紹介
- 医療関係。
- 医療社会をより良くするためのサービスを開発している。
- 現在薬局向けをリリースしている。今後広げていく
- 去年の4-10月の話
- チームは3月結成。
- フルリモート
- 人
- EM・SM。PdM フルスタックEngｘ2の4名
- 何をやったか
- Readyを待たない
- 見積もりしない
- タスクがスプリントで終わらない
- 仕掛中のUserStoryがいっぱい
- 新規開発とスクラム
- スクラムで新しいプロダクトを開発しようとした
- しかし見積もりをしなかった。
- 新規開発っていっぱいやることある。どのスプリントで何をやるかがきっちり決まりがち
- 最初のうちはなんとかなるかなと思ったら、わかっていないことが実はたくさん入ってる。
- 新しい情報がたくさん入ることもある。
- わかっていないことを取り出して調査用のスプリントを設けた。
- 調査と実装のスプリントが別れているので実装上で出てきたわからないことが調査スプリントまでまちになる
- Readyになるのを待たないでやったら早くできると思ったが、不安になる。見通しがたちずらい
- 不安は合ったが、EMからやってみようということでやることになった。否定されると思ったが…
- なんで良いと思ったのか。
- 本人がいいと思ったやり方をやるのが良いと思った。実際実装する人の経験を生かした方法をとった。わざわざ反対するより、間違ってたら振り返れば良いと思った
- なのでReadyをまたない見積もりをしない開発を採用した
- とはいえ見通しつかないので、全体マップを作った
- ストーリーマップのようなもの。横軸がログインや、外部連携などの大きな機能単位
- どういうものを作っていくかと言うのを共有していきたい状態にしたかった
- 実際すごくいいなと思った。バックログは一次元で上から下まで並ぶ感じになるので、全体感がわからない。二次元になることで、プロダクト全体を俯瞰できるようになった
- ユーザーストーリー以外のバックログをスケジューリングしたら、MVPの機能開発に一ヶ月しかなかった。全体3,4ヶ月あるのに…
- MVPのスライスをおこなった。なんとか1ヶ月に収まるような感じにした。
- どんなチームをつくったか
- コンセプトは「ドリームチーム」
- ゆのまえさんはEM、SM。
- EMは組織の構築と成長に責任を持つ。人を集め、開発体制を作る
- SMはスクラムの推進改善。集めた人で開発を進める・改善する
- どんなチームにしようかなというコンセプト
- いいチームが良いプロダクトを作るドリームチーム＝＞技術力ｘ顧客価値
- いつも顧客価値に楽しそうに向きあうチームをつくりたかった
- EMとしてどのように魅力ある人を集めるか
- 開発コストを可能な限り抑えること。
- 方向性が定まらない中で失敗できるようにするために。
- コスト要因
- 方針転換が多い
- 人が多くなると開発コストとコミュニケーションコストが高まる
- 次の基準を設けて採用した
- コミュニケーションが円滑
- フルスタック
- 技術力が高い
- しいばさんは、バックエンド・インフラが得意。もう一人、フロントエンドが得意なフルスタックエンジニアがいた。
- 少なくともMVPが完了するまでは採用基準を変えず、積極的にふやさないようにした
- コミュニケーションコストがふえるから
- ふやしたら？と言われても大丈夫！といっていたが、いうても不安ではある。
- むやみに増やしたところで成功する道も無いので、これで行くという覚悟を決めていた
- SMとしてチームをどう整備したか
- ≒顧客価値にどう楽しそうに向き合うか？
- 状況が変わることにチームを変化させる
- リリースまでに4つのフェーズ
- たちあげ 2m
- 何が必要か不明瞭なので、調査をタスク化した。情報の透明性を担保。
- 漏れ・ダブりなくゴールまでスムーズな道のりを作れた
- リズム形成 2m
- どれくらいで開発できるかが必要なので、おおよその見積もりをした
- この時点で間に合わないことを気づけたのはポジティブ
- 機能量産 2m
- ある程度ベロシティが安定したが、機能開発以外のタスクが山積みだった。セキュリティ診断とか。
- 機能開発以外SMが巻き取ることで開発スピードが安定した。
- リリース 2m
- いろんな予期せぬことが起きる。不具合とか。
- とにかくバッファを設けて、気になることを気軽に話せるように整備した。
- リリース直前にやばめの不具合を見つけてギリギリセーフした
- たちあげ 2m
- チームの状況を見ながらなめらかに変化させていった
- BADプラクティスを進んで勧めた新規開発
- Readyを待たない・見積もりをしない
- 土台作り
- わからないことだらけ。方針も難しい。
- 事前に調べてとかやったら、素早くできない。
- 見積もりが終わった頃には実装が終わったりする。
- とりあえず飛び込んで手を動かして、土台を構築できた
- スプリント内でタスクが終わらない
- そもそもそんなにスプリントを気にしていない
- 一個一個終わらすことに集中した。
- 一週間はちょっと長い。Dailyでプランニングする形
- なので残ってるところであんまり気にならない
- 仕掛中のユーザーストーリーがたくさんある
- バックエンド開発は二回実装した。一回目で実現可能性をとにかく全部詰め込んで実装して、エラー処理もロギングもしないで、やった。
- 二回目で構造を整備して、実装をし直した
- 実現可能性を早い段階でチェックできた。全体を見ながら本番レベルの実装ができた。
- Readyを待たない・見積もりをしない
- 何れにせよ踏み外すと危ない。
- スプリントレビューで動くものを見せるのは意識していた。
- レビューの区切りとしてレビュを意識した。
- 何ができて、何がまだできていないかをはっきりし、全体マップを見ながら現在地を更新した。
- 動くもの・新しい情報・方針転換
- 動くモックを早い段階でプロダクトマネージャーに見せていた
- PdMが薬局にいってモックを触ってもらっていた。
- こうしたほうが良さそうというPdMのことばですぐ仮実装する。
- 6月終わった時点で半分終わってない感じで8月終わらない雰囲気がでた。
- 計画づくりをするときの大原則
- 最初の計画がうまくいくわけではない。
- 計画を立てるときは基本的に情報が足りていない。
- 現実を受け止め、今の延長線上でゴール達成できるだろうか、と考えた。
- スケジュールの見直しは何度もやるものではない
- そもそもリスケジュールは時間かかる。一回しかやりたくないので大胆に一回で済ます。
- やばいのは早い段階でわかっていたが、見直しするためには条件を満たす必要がある
- やらなければいけないことがすべて洗い出せているか
- ベロシティは安定しているか
- チームの危機感は十分仕上がっているか
- 人入れればマネージャー的に体裁整えられるとかおもわなかった？
- 負けだな、というのはあるが、オンボーディングコストと、コミュニケーションコストがかかる。採用にも時間とコストがかかるので、今のパフォーマンスでやることが大事
- 再計画づくり
- 全体マップを眺めながらストーリーの洗い出し
- ３点見積もりをおこなって機能開発の着地点を出した
- リリース準備期間をふくめ1mのバッファをとった
- リリース予定日の肌感をすり合わせ
- ステークホルダーへの説明
- 結果として8末リリースを10中の1.5m延期。
- このあとは大きなスケジュール変更リスクもなく、予定通りクローズドベータを10中でリリースした
- エンジニアとしてバッファを積むのはしのびなかった
- すでに送らせてしまっているので
- EMが一ヶ月いるでしょ、といってもらえてよかった
- まとめ
- Badプラクティスも武器にする
- 状況に合わせて最適化し続ける
- 全体マップは有効だった
- チーム全員が意識をもてて、助け合えた。
感想
- ある程度安定したビジネスモデルの中で、新規プロダクト開発という状況下のなかでどう対処したのかという具体的なケースが聞けた。
- 特に再計画とかは新規プロダクト開発やってると結構気分が重い話なので、そのケースが聞けたのは良かった。
- Badプラクティスをあえて入れるというのは自分もやっている方法で、一歩踏み外すとやばいというのは結構共感がすごかった
Outcomeに向き合う中で出会っている出来事とその解決案
Outcomeにフォーカスするチームへのジャーニー / A Journey to an Outcome-Focused Team - Speaker Deck
- ゴール
- Outcomeを中心に活動するための取り組みや考え方を一つ知る
- Outcomeは結構話してる内容ではある
- 特定の現場や組織の話ではない！！！
- セッション中のOutcomeの定義
- 利用者の課題が解決したか？
- 利用し者のやりたかったことができるようになったか？
- 利用者の世界がどう変わったか？
- Outcome・Output・impactの違い
- output: 提供した機能
- impact: どれだけ儲かったか
- 近い概念ではある。
- Output/outcomeは対立構造ではない。outputが出てない中でoutputが、は説得力がない。
- outcome/impactは関連している。impactはマーケティングとかにも影響されるけど。
- outputがoutcomeをgenerateし、impactを次にgenする
- 最小のoutputで最大のoutcomeを得るのが最高
- outcomeにむきあわなかったら？
- 誰得なプロダクト、
- 気力を奪う
- 事業継続できない
- しかしoutcome向き合うのは難しい。
- 関心も持たない・持てない
- outputに関心が向いてしまってる、もしくはoutputに忙しい。
- そもそも組織がoutputにだけ期待する構造になっている。チームスキルもoutputを出すものに偏っている
- outcomeに関心を持てない負のサイクルが発生する
- 計測が難しい
- うまくいったことが定義するのが難しい、変化が遅すぎて定義してもわからない、結果がわかるまで時間がかかる
- インセンティブが無い
- 人事評価関連
- コード書いてなんぼだったり、マネージャーもそういう価値観で会話する。
- エンジニアがエンジニアリングを成長するのは悪いことでは無いけどoutcomeにパワーを残すのも重要
- outcomeが人事評価に含まれない。outcome/impactが大きくても評価されない。
- プロダクトめっちゃ良くなっても…って感じ。
- 関心も持たない・持てない
- どうやって向き合うか？
- 領域を越境する
- 隣接領域に関心を持とう。学ぶ時間を取ろう。プロ級になる必要はない。会話ができる、一緒に関心を持つぐらいの内容。
- 薄い本でもなんでもいい。
- 興味を持ってユーザーを知る
- ユーザー行動の観察
- 話を深く聴く
- ユーザーになりきる
- 自分の中にユーザーをおろす
- 関心をoutcomeに寄せる
- 作る前にoutcomeを考える。どう測る？とかも。
- フィードバックを早く、前段階の一部でも得る方法を検討する。
- 意思決定をoutcome中心に。
- 向き合える環境を作る
- 経営やマネージャーの支援
- 機会を設ける、学習などの時間・金銭的支援
- outcomeに向き合うような評価精度
- ここまで来ると文化の話になる。
- 領域を越境する
- まとめ
- 自分と違うロールの人の考えてることに関心を持って日常の会話をするのもアリ
- 作る前に知ろう・考えよう・想像仕様
- outputがユーザーにとってどうだったか知ろう
- ちゃんと向き合うために自分の情熱や意思が必要。
感想
- 軽く耳の痛い話ではあった。outcomeに忙しいというのもそうだけど、向き合おうとしてないというのはたしかになぁ。
- 向き合わない人が悪いのではなく、その構造に着目したアクションが紹介されていたので明日から選択しやすいなぁというのと、自分が説明し易い形でまとめられていたのがよかった。
ブッダに学ぶ、いのちだいじにアジャイル推進するためのマインド
- 宗教の話ではない。
- もともとプログラミングが好きで入ったら、炎上案件にめっちゃご縁がある
- 楽しく開発したいがなかなかうまく行かない
- 最近はSMと社内で勝手にアジャイル推進
- 6年やってるがしかし難しい
- 一人ひとり主観が違う。アジャイルもスクラムも一人ひとり違う認識。
- アジャイル推進も下手すりゃ押し付けになる。
- どうやって対話を進めれば良いのか疲れることもある。
- ここでブッダ。
- 人の心を分析してきた。ブッダがどのように分析してきたかを考え、主観の違うことを乗り越える方法があるかを見ていく。
- 主観はどのように生まれる？
- 全経験領域（一切）が全体としてある。何かをインプットし、主観としてアウトプットする流れがある
- 人の5つの構成様相。
- 色
- 受（経験の影響を受ける）
- 想（経験の影響を受ける）
- 行
- 識
- input（六根）
- 5感と意
- 内部処理（六境）
- output(主観）
- これらが一瞬で回って判断している。
- 例：スラダン
- 絵を見て内部処理がすぐ走る。
- 好きとか嫌いの印象を受ける。
- 言葉では一言だが、その背景に色々な経験や背景がある
- 背景は掘り出さないと分からない。ちなみに主観は間違ってるとかではなく受け入れるしかない。
- 主観の違いを悲観するとつらくなる。四苦八苦
- こんなにすごいのにつたわらない！！が強くなると自分でかってにつらくなる。
- 主観の違いを乗り越えて命大事に緩やかに変化に向かうための3つのマインド
- 相手の経験領域を知ろうとする
- 経験領域を深ぼるインタビューをしてみる。印象に残ってるプロジェクトはなに？とか。どんな言葉が思い浮かぶ？心地よいものだった？どんなことを得た？自分が変化した点ってある？
- 「泣いていた君を見なかったことにはしない」（ヒロアカ）
- 人は変わる、私にできることはきっかけを作ることだけ
- 受・想に働きかけることで人は変わっていく、
- ちょっときっかけを作る、ちょっとさわるぐらいしかできない。
- 新たな挑戦、一緒に体験、異なる主観の共有、一緒に考える
- 「面白いものだな。その百分の一がお前を変えたんだ」（フリーレン）
- 変わらなかったとしても私達のせいではない。きおうな。
- 私が想う正しさにとらわれていないだろうか
- 自分自身が変化し続けているだろうか？
- 俯瞰的に自分たちの活動を見ていくと良いかもしれない
- 「人は絶えず変化するもの〜」（攻殻機動隊）
- 相手の経験領域を知ろうとする
- fearless changeとか良いかも。
- 大事なこと
- 人生一度、ロールバック不可。ゴール見すぎないように疲れすぎないように。
感想
- 前職アジャイル推進っぽい事やってたのできょうかんが深い。自分は四苦八苦になった感じがあった（そもそも推進することに集中もできてなかった感じもあるが）
- 相手と自分の主観の差というものをどのように分解し、どう寄り添うかというのは結構「他者と働く」にも通じるものがあるなぁ
よいチームをよい雰囲気を保ったままよい組織にスケールさせていくためにできること
- あるチームはアジャイルやプラクティスを用いて困難をこえ、良いチームが生まれた。平和が訪れた
- 「チーム増やして」と言われる。
- アジャイルはじまり23年、アジャイルは始めやすい、習熟しやすくなった。
- 良いチームの事例もききやすくなった。
- 良いチームを増やしたいという欲求。組織から。理解はできる。もっと増やしたい。
- ニーズはわかるが、やってて個人としてはチームをスケールとかマネジメントとかにあんまり興味持てないとかある。
- 大規模アジャイルとかぜんぜん違うもののようにも聞こえる。
- 良いチームができたあとのアフターストーリー。スケールさせるためにできることとは？
- 良いチームができたあとに何が起きるのか？のストーリー
- SBC
- 良いチームができた先の世界を見たい。
- タックマンモデル。個人で見るとき、タックマンモデルはある程度それっぽい線を持つ。
- 移動や、転職で最初に戻ってしまう。個人で転職してしまっては先の世界に行けない。
- なにか問題があっていいチームができるが、移動・転職で一からまた作る。虚しい。
- チームが解散するかもしれないというタイミングでチーム転職をやったりした。
- チーム転職してよかったことは、オンボーディングもモブで進められたり、環境が変わってもスピーディーだったり。
- チームとチームの外との境界が濃くなってしまって、自分たちがいくら気をつけても周りがそう対応してくる。
- チームが長いと3年で生産性が降下する。外とのコミュニケーションが減る。
- 周りから孤立した存在になる。
- 良いチームができたということは、良いプロダクトができるみたいな他責っぽい意識になる可能性がある。
- いいチームで問題解決をしたいのは当然として、チームの外に良い影響を与えられるチームになるという目標
- ホロラボで、良いチームを増やしたいというニーズを受けた。
- 自分たちはAgileコミュニティ、となりのチームはunreal engineコミュニティ
- 今までは組織の配下でチームのしごとをしていたが、現在は組織を飛び出し、会社の範囲までカバーしている
- 2022振り返りで、会社をハックしたいみたいな経営に関わりたいという発言がでて、狙い通りだったが、組織やマネジメントを聞いてうっとなった。
- めんどい仕事が増える。本来やりたいことに時間をさけない。
- そもそも本来やりたいこととは？
- 良いチームができた先の世界。
- 勝手につらいマネージャーのイメージが浮かんだ。
- いろんな取り組みの中で手伝うなどの姿勢は主体性を放棄している。聞こえは良いけど。
- その方針で行けば確かにチームは孤立していく。
- チームメンバーが組織や経営に関わることで孤立せず、チームの範囲に組織やビジネスを入れてみようとなっている
- コミュニティづくりは苦では無いという自己の特性
- 期待しないことから始める。
- ロールが変わったから何かが変わるわけではない。マネージャーだから1on1やるとかでもそういうかんけいせいではない。
- 1on1やるけど、続けたいかは相手に判断を委ねる。あとは雑談。コーチングやってるので観察とか。
- メンバーに共通していたもの
- いずれのチームもコミュニティが好き
- ものづくりが好き、喜んでくれると嬉しい
- もっとうまくなりたい
- そういう人たちのための場を作るためにやったこと
- 見えてきた変化
- なにやってたか：成功循環モデルをやった
- 関係の質から始めると良い結果になる。バグ0を求める結果の質から始めると失敗の循環を起こす
- 問題解決から組織づくりを始めない。組織から問や仮説が生まれるようになると良いかも。結果はあとから付いてくれば良いやぐらいの感覚であること。
- たまたまいい人があつまっただけじゃね？ー＞そうっすね
- 底にいるための組織を作ればいいよ
- プレイングマネージャーどう？
- 優先順位の話だと思っている。
- マネージャーとして意識してること
- 水を運ぶ役割。相手に求めない。興味を持ってもらうように自ら働きかける役割。
- うまく行ってから考える。再現性・属人化・組織論とか今考えても仕方ない。
- 組織やマネジメントに過度に期待しない。
- うまくいったというのはレベルが上がる。打席に立ち続けることが重要。
感想
- そもそも自分がそこまでいってないのですげえ話だと思いつつ、たしかにループに陥ってる感じがあるなぁと思った。
- 今はまだ小さいけど、OST文化はめっちゃ良いなぁと思った。内容よりも盛り上がりに着目するというところは発見だった。
ベロシティ Deep Dive
Regional Scrum Gathering Tokyo 2024 - ベロシティ Deep Dive | ConfEngine - Conference Platform
【資料公開】ベロシティ Deep Dive | Ryuzee.com
- 勝手に仮説を持っている。スクラムチームのなかで生産性やベロシティという話が出るほど価値は反比例しているのでは？
- あまり良くない状況なのでは
- ベロシティにDeepdiveするのであればプロダクトに集中して
- ゲームに勝つのはフィールドに集中する選手であってスコアボードではない
- 適切な使い方とアンチパターンを紹介
- ベロシティとは？
- よくないベロシティの使い方
- 生産性の指標として使う
- やめる。やめろ。やめろ
- 生産性という単語の胡散臭さ。よく使われるけど。同じものをイメージしてるようで全然違うことが往々にしてある
- 生産性= 算出/投入
- 物的生産性: 生産したものの数や量をもとにしたもの
- 付加価値生産性: 生産したものが生み出した付加価値をもとにしたもの。金銭とか
- 一言で生産性は議論が噛み合わない元。DXとかビックデータと同じような言葉。きちんと定義を揃えることは重要になる。
- 生産性= 算出/投入
- スクラムは何を目指している？
- 数字の上下に一喜一憂
- すくらむにおける見積もりはだいたいいい感じを目指す。
- フィボナッチ数列使っていると大きければ誤差がでかいという前提
- 個別の誤差のお陰でだいたい収まる感じになる。
- 厳密性を求めたら見積もりの精緻化に時間をつかって価値を生み出さない。
- すくらむにおける見積もりはだいたいいい感じを目指す。
- 目標ベロシティを設定して届かないと問題とみなす
- ベロシティを誰かに報告する
- いくつかパターンがある
- 開発者がPOに報告する
- POがステークホルダーに報告する
- そもそもチームの外にベロシティを出すのは無意味と考える。
- いくつかパターンがある
- 評価に使う
- チーム間で使う
- 生産性の指標として使う
- 「言ってることはわかるけど組織がいろいろ言うんです。定量的じゃないと報告できない」
- 組織がSMARTを求める
- 目標設定とかタスク分解のときに使われる。
- やたらと計測可能なところだけ重要と言われる。本当は関連性が重要だよね
- 「何も図らないよりなにか測った方がいい？そんなことはない。重要でないものの正確な尺度より、重要なものの曖昧な尺度のほうが必要」
- 「測定できないものは管理できない、と考えるのはあやまりである。これは代償の大きい誤解だ」
- 正確な数値である理由はあまりない。そこを脱却する。
- アジャイルソフトウェア開発宣言の原則「動くソフトウエアこそが進捗のもっとも重要な尺度です」
- 実物見せたほうが良いでしょ！
- SMの出番では
- 外側から色々言われてる状況は、SMの組織に対する働きかけの責務範囲。
- 「複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう」
- SMはちゃんと組織に対する働きかけ・教育をやる。
- 数値出せと揉めてるとき、なぜそれが必要か、何につかうか、その数値を使うリスクはなにかをちゃんと整理しよう。代行して出すのも一歩踏み込みが足りない。
- 外側から色々言われてる状況は、SMの組織に対する働きかけの責務範囲。
- レビューに来てもらう
- そんなに気になるなら来てもらおう。
- インクリメントを毎回届けて、信頼されれば、数値報告は要求されてない。
- 逆に言えば、数値報告を要求された場合は、インクリメントを出せてないし、信頼されてない。
- それでも定量的な指標が必要なら？
- Effort: 計画づくりなんかいやった。PR数 etc
- Output: 出来上がった計画、、、、 etc
- Outcome: ユーザー行動変容
- impact: 生み出された価値
- こんな感じで分解したときに、どこを測るか？
- 最終的にはImpactが必要だけど難しければ逆順に辿っていく。Impact, Outcomeを狙うのが一番良い。
- 「サイクルの早い段階で測定するほど測定は簡単だが、結果は予期しないものになる」ケント・ベック
- プロダクトの価値と関連する指標（付加価値生産性につながる指標を選ぶ
- NSM,KGI，KPI
- しかし遅行指標が多いので、先行指標をチームで検討する。
- SPACE FW
- 満足度、パフォーマンス、アクティビティ、コミュニケーションとコラボレーション、効率とフロー
- 選択した複数のカテゴリを計測し、定性も含めて全体像を適切に把握できるようにしよう。
- （例はスライドで補足）
- 多角的な観点でメトリクスをみよう。一つの数値だけで同行しようとするな！
- いい使い方
- スクラムチームが計画の材料に使う
- 事実ベースの計画に使える。
- 誤差があるのでだいたいこんなもんという目安。厳密に使おうとしない。
- めいいっぱい積みたいというチームはあるが、スプリントの目的はスプリントゴール達成しか無いので、別にめいいっぱい埋める必要はない。
- 単に数値を見るのではない。どんな出来事があったか、どんなコンテキストがあったかという情報を一緒に入れることで振り返りに使える。
- スクラムチームが将来の見通しを立てるために使う
- 直近の実績を平均して今後の見通しを立てるために使う。
- 初めの方になればなるほど、あてにならない。常時見通しを更新する。繰り返しやる。
- スクラムチームが自分たちの検査をするために使う
- ベロシティのデータを見ながら自分たちのパフォーマンス改善のために。
- 上下は激しければ、未完成を次のスプリントで完成させることが状態化してないかとか、特定のバックログアイテムの見積もり精度が変とか。
- スクラムチームが計画の材料に使う
- まとめ
- 生産性の指標として使わない。
感想
- ところどころ笑いつつ、わかり味が深い内容だった。
- ふわっとそうだよねというのを見事に言語化した感じがある。
- ちゃんとスクラムガイドに立ちかえり、解説できるあたりやっぱり、スルメのような文章だなぁとおもった。
エンジニア組織の経営論 〜エモい開発と売上数字は両立するか〜
- 対立構造じゃないはずだけど、経営とエンジニア組織は遠そう
- つよそう
- 支配しようとしてそう
- いい感じにバランス取れたらすてき
- でも現実は甘くない
- プレッシャー感じる。売上上がったの？
- リーダーはジレンマある
- 顧客の満足、自分たちの満足、どっちか一個しか取れない場合どっち取る？
- 顧客の満足と自社の売上。どっちとる？
- 自社の利益と自分の給与。どっち取る？
- 自社の売上と、エモい開発。どっち取る？
- 正解はない。
- 今日は「お金や資本 v.s. ひとやチーム」について議論していこう
- 超一流の研究
- 天賦の才はあるのか？
- すごい人っていっぱいいる。スポーツとか、才能に秀でてる人たち。
- どういうものでそうなるのか？国籍？環境？遺伝？
- 答えは無い
- 共通していることは３つある
- 1万時間（10年）没頭している。練習の差が能力の差。
- 限界的な練習を続けている。ちょっと上の練習の継続。独自の工夫がある
- 新しい方式を常に学び続けている。そしてフィードバックを受けている。アウトプットして自己評価。
- 夢中と成長が重要。
- 夢中の研究
- 夢中でエモいやつの特徴
- 今が優秀ではない。
- ずっと続けてるひとは長期的に外発的動機を凌ぐ
- 圧倒的没頭で熟達
- 内発的動機同士で惹きつけ合ってチームがある
- 心が健康
- 天賦の才はあるのか？
- 夢中でエモいエンジニアが本能的に嫌いそうな経営側の話題
- 数値
- マネジメント
- 資本政策
- 事業計画
- 給与制度
- すべて外発的動機っぽくない…？
- 報酬の研究
- 報酬とモチベーションの関係
- 報酬で釣るとアンダーマイニング効果が発生する。エモさがなくなって、やりがいで始めたのに、報酬が目的になってしまう。３年ぐらいでだいたいそうなったりする。
- 報酬はエンハンシング効果。単純作業とか一回目は効果的。
- お金って心理的に大事にしたいワクワク感・エモさに繊細に反応する。
- 報酬制度はエモさを破壊しかねない劇薬。経営陣はお金で支配した感じに行ってくるけどね…
- 会社は伸びるが、現場は不幸なのがダサい経営。持って3年。
- 夢中なひとの最高の報酬って？
- エモい仲間と価値のある仕事と、自信の成長
- 成長の研究
- 技術屋もビジネスサイドも成長していかなければ行けない。
- 技術屋がわかりやすいだけ。
- ビジネスサイドのひとほどめっちゃ勉強している。そしてずっと維持しなければ行けない。
- 一個に固執しすぎず、変化し続けなければ行けない。
- 何かを成してしまったりしまうと、やらなくなるのは結構あるある
- マインドセットで行動は変わる。いつでもかわれる。
- グロースマインド（将来が楽しみな老若男女）
- 何歳でもなんでも学べる
- できるひとを尊敬する
- 挑戦し、失敗から学ぶ
- ーーーーー
- グロースマインド（将来が楽しみな老若男女）
- 記憶力と年齢の関係
- 前頭葉を劣化させる環境
- マイナスオーラを浴びたり浴びせたり
- 単純作業を考えずに繰り返したり
- ごまかす・妥協する・あきらめる
- 逆に前頭葉が衰えない環境
- 毎日プラスのサプライズ
- 将来を楽しみにしている
- 良い仲間と繋がっている
- 未来を憂いてるやつは全員排除したほうがいい
- 勉強方法の研究
- 本読むだけじゃなくて、アウトプットすることが重要。
- フルスイングで技術を社会実装する。ビジネス側に全力で投げ込む
- ちょっと経験すると「PoCです」とかいって、本気で実装しなくなる
- 外と繋がり、外部に発振する。コミュニティとか、異業種・異文化の人たちにアウトプットし、フィードバックをもらう。
- 最初の一歩は色々ある。blogもinstagramも、twitterも、PRも勉強会の主催も、出社でも。
- 良質なアウトプットは良いフィードバックを得られる。
- ビジネス側って実際どう？
- めんどくさそうって本当にそう？
- 本当をしらないでビビってるだけじゃない？
- お金の話ばっかりしてるって思ってる？それは本当？
- そもそもエンジニアがお金の話をもちだしてない？
- ゴールは？
- 課題は？
- 売上は？
- ・・・・
- 外発的動機っぽい話をさせてるのはエンジニア側では？
- ビジネス側もちゃんとエモい。
- 金だけ好きな人はシカトするとして…
- 何がすきか？どれだけすきか？そういうエモい部分ちゃんと聞こうぜ
- スタートアップと仕事しようとしているビジネス側ほどエモいぞ。
- システム作ることばかりをゴールにしているのでは。
- いうて全員オタク。（拝金主義はいない前提だけど）
- 中身がわからないだけで。
- 話は通じる。
- ビジネスサイドはドメインの製品が好きでやっている。
- 数値だけじゃわからない、デジタルビジネスの先にエモい魂がある。
- オタク同士は感動できる。
- 共感がアレばエモく繋がれる。
- 向こうも本気。互いに真剣に取り組んでる。
- 尊敬しあう。
- この経験は金じゃ買えない。
- お客さんも数値に侵されている、エンジニアはビジネスサイドに寄り添いすぎている。もっと没頭した、オタクの話。ビジネスサイドを洗脳する義務がエンジニアにある。
- 経営陣をエモいDX人材に巻き込んじゃえ。
- エモいエンジニア組織の経営
- 金中心から人中心にシフト。
- 資本市場を意識せず、内発的動機を邪魔しない環境を徹底している
- 売上目標撤廃
- 営業組織廃止
- エモい仕事のみ受注
- 最高の技術と品質
- 顧客満足度至上
- 結果：ちゃんと伸びた。裏では色々失敗してるけどいろいろ努力はしている
- エモい開発と売上は並立できる。
- エンジニアこそビジネス側に飛び込もう
- 数字に従属しない。本気にエモく生きる。そうしたらエモい仕事がくる。
感想
- エモい発表だったけど、勇気が出る内容だった
- むしろエンジニア側が数値の話を持ち出しているという視点は新鮮だった。
- そうだよなぁ、ビジネス側も数値とかじゃなくこれをしたいという動機からスタートアップやってるもんなぁ
