RSGT2018初参加してきた
かなり時間が経ってしまったんだけど1/11-13にRegional Scrum Gathering Tokyo 2018に参加してきた。
せっかくなのでレポート的なものをまとめてみる。
その前に2017年の振り返り
2017年の抱負にスクラムちゃんと実践できるようになる、という話を書いていたけど、去年はそれなりにいろいろ勉強して試行錯誤してきたので1年の区切り的な意味合いも込めて参加してきた。
スクラムについては2015年にCrowdWorksに転職してからなんとなく開発チーム全体でやる空気になってたんだけど、プロセス改善の知見がチームに閉じていたのでわりと長い期間なんちゃってスクラムをやっていた気がする。（当時のGMはスクラムが目的化しないようにあえてスクラムというものについて細かく体系的な知識はインプットしなかったんだと思うけどちゃんと実践できるところまで自己組織化するのは長い道のりだったんだろうなあと今になって思う）
2017年はチームリーダー的なロールだったのでどうやって成果を出せるチームに変わっていくかということを考えてたんだけど、実際には結構大きな壁（プロダクト自体やチームを取り巻く組織の壁）にぶち当たってて本質的な改善ができていない感がとてもあった。そこでチームでゼロから学び直そうということでSCRUM BOOT CAMPの読書会をやったりした。
- 作者: 西村直人,永瀬美穂,吉羽龍太郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/02/13
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 13回
- この商品を含むブログ (33件) を見る
学び直していく過程でプランニングやふりかえりで成り行きで電子化してしまっていたものを紙ベースでやりなおしたり、教科書通りにプロセスの見直しを行った。
この取り組みからは約半年くらい同じチームで動いてきたが、個人的には自分たちにとってのスクラムとはなんなのかみたいな問いへの明確な答えにはたどり着けなかった。この問いは深い（今はなんとなく答えはある）。また、チームとして大きな成果を出すみたいなところも多少あるけどMVPをとれるほどのなにかは残せなかった。
でも明確に変わったことは成果に向かう状態は作れたということだった。
以上が僕が最初にスクラムとちゃんと向き合った最初の経験でした。
そこからまたチームが変わり人が増えて、よりチーム運営の難易度があがった。その辺りからPOが忙しすぎて施策が追いつかないみたいな状況が発生しそうだったのでPOにジョブチェンジして施策とプロセスの両面を考えてきた。
当時のアウトプットとしては、こんなものがあります。モブプロ楽しかった。 Process Improvement with AAR x SMART Goals x Mob Programming - クラウドワークス エンジニアブログ
そんなかんじで1年が過ぎ、現在は引き続きPOとして仕事をしているのだが、まだまだ社内でプロセス改善についてごりごりやっている人が少ないので、業界の最前線でチャレンジしている人の話を聞いてきて社内で広めようと思って参加したのが発端でした。
RSGT2018メモ
参加したセッション
- Day 1
- Day 2
- 敢えて属人化せよ！エキスパートの集団こそが最強のチーム(Embrace Collaboration and Fun of Coding)
- スクラムチームとして、妨害リスト（Impediments List ) を運用して見えてきた課題解決方法
- 「ふりかえり」の始め方と続け方
- Smug? Oyatsu Shrine ~ Improvement patterns seen through practicing "Oyatsu Shrine" ~ どや！？オヤツ神社 ～実践しているオヤツ神社を通して見る改善パターン～
- がんばれスクラムマスター（流しが見てきたスクラムマスターの理想と現実）
- Panel - 実感駆動でものづくり ー 協調学習過程としてのスクラム。欲しいものを、どうやって知るか。
- Day 3
Day 1 基調講演
Detail
Slide
Memo
- Joy in business
- エンジニアのJoy
- = 作ったものが世の中に出て人の役に立つこと
- エンジニアの悲しいこと
- = 一生懸命作ったものが世の中に出ないこと
- 本や動画をinputして勉強した
- 喜びはビジネスに結びつくか
- メンロー立ち上げ
- メンローオフィス
- 壁を取り去る
- オープンオフィスではなくオープンカルチャー
- オープンカルチャーを体現したに過ぎない
- 騒音を受け入れる
- 雑談ではなく仕事に関する騒音
- チームワークが見える
- 柔軟であれ、見える化せよ
- 机の移動も柔軟
- それぞれのチームが机をどこに置くかはチームが決める
- 承認はいらない
- 「日本にいる間僕（社長）の机はどこかに移動しているだろう」
- 学びを受け入れる
- 学ぶ組織を作った
- 本は重要な存在だがそれ以上に人と繋がることが重要
- やっていること
- ペアプロ
- 5営業日ごとに入れ替わる
- 全社員とペアプロ
- コミュニケーション
- デイリースタンドアップ
- バイキングヘルメット
- ペア作業なのでペアとバイキングヘルメットを持って報告する
- 70人のMTGが全員喋るが13分で終わる
- 顧客との会話（show & tell）
- 顧客がソフトを見せてくれるのを見る
- そうすることで集中できる
- 計画ゲーム
- タスクを紙に書く
- 紙の大きさはボリュームを示している
- 顧客に1週間のスケジュールの上に置いていく
- 追加と削除だけ
- プランに入ってないものがなにかもわかる
- スケジュールシートに乗らないものは対応しないというものが明確にわかる
- トレードオフが見える化しながら進められる
- 顧客とのコラボレーションが起きる
- シンプルなインデックスカードでやる
- なぜ手書きがいいのか
- 手書きのものは読まなければいけない
- 集中できる
- カードをボードに貼る
- スケジュールは線を引いて進捗を見える化する
- ユーザーストーリーマッピングのリリーススライス的な
- カードのステータス管理
- 開始したら黄色のシール
- 終わったと思ったらオレンジ
- QAが判断
- OKならグリーン→joy
- NGならレッド
- ペルソナマップ
- ユーザーの重要度を定義している
- 実験することが重要
- 学習する組織
- 競合よりも素早く学ぶ能力だけが組織の持続的な競争力の源泉 - ピーター・センゲ
- ペアプロ
- 壁を取り去る
所感
他のセッションでも似たようなことが言われていたけど「実験してみることが大事」というフレーズが印象的だった。 喜びという言葉だけみるとエモいんだけど実際には開発者やマネージャーとしての大変な経験からロジカルに楽しく開発するには、ということを突き詰めた結果の話なのでむしろ現場から出てきた話なんだろうなと思った。こういう雰囲気で仕事をできたらめっちゃいいなーと思った。
心が折れてもソシキ・カイゼンを続けられるたった一滴の魔法
Detail
Slide
Memo
- 自己紹介
- やっていること
- アジャイルワーク
- 越境ワーク
- やっていること
- ヴァル研の見える化
- ヴァル研がメンローに近づくためには6年くらいかかってる
- 普通に心折れる
- 復活するための3つの価値観
- 学ぶことが好き
- 知的好奇心
- 学び＝良いこと
- コーチの経験
- 小学生のサッカーのコーチ
- 自己組織化
- 育成は儲からない
- 見返りを求めない、学ばない者には資格はない
- オーストラリア
- リフレーミング
- 気にしない
- 学ぶことが好き
- 続けられる2つの理由
- どうやってそういう人間になるか
- カイゼンジャーニー
- 一人から始める、チームで強くなる、みんなを巻き込む
- カイゼンジャーニー
- 続けられる魔法
- どんな未来があるか、どんな貢献ができるかを自分に問う
- 好きな人を増やす
所感
モブプロの見学で一度ヴァル研さんにはお邪魔したことがあったんだけど、社内の雰囲気とか見える化の掲示物とかからうちにはない安定感みたいなものを感じて、この話を聞いてこの6年の積み重ねからきているものだったのかな？と思った。 この熱意を継続できるのは本当にすごいし見習いたい。
サーバント・リーダーシップを掘り下げて考えましょう
Detail
Slide
Memo
- 経緯
- 新技術導入を成功させるための文化的習慣
- Be lazy
- リスクや間違いを受け入れる
- 不確実性を受け入れる
- サーバントリーダーシップ
- セルフマネジメント
- 従業員への信頼
- 個人の自信
- 階層関係のパワーバランス
- Speakerがみんなに教えられるもの
- 文化の違い
- 一般的なアメリカの働き方や人事管理
- ソフトスキル、コミュニケーション
- リーダーシップ
- サーバントリーダーシップの定義
- サーバントは押してやるという意味が強い
- サーバントリーダーシップがなぜ必要か
- サーバントリーダーシップのインパクト
- 研究された概念
- 収益改善、パフォーマンス向上に効果があることがわかっている
- ...
- という話をすると、サーバントリーダーシップの研修やってよという話がくるが、
- 上の人が変わるのを待つのは永久に変わらない可能性がある
- まず自分から変わらなければいけない
- スクラムマスターとサーバントリーダーシップ
- スクラムマスターには権力、肩書きのパワーはない
- サーバントリーダーシップはメンバーにとっても役に立つ
- 究極の人間関係スキル
- 人に命令するのはスキルいらない
- 肩書きなしに説得するにはスキルが必要
- グーグルで成功する人の特徴
- ほとんど人間関係スキル
- 最後に技術力の要素
- サーバントリーダーシップの素質
- 去年からアップデートしてる
- 去年はもっと抽象的で理想的なものだった
- 素質の分類
- 緑は日本人が得意
- 青はアメリカと同じくらい
- 赤は日本人苦手
- 日本人は勇気が必要
- サーバントリーダーはどういう行動をとるのか
- 相手に考えさせる質問をする
- チームメンバーに考えさせる
- → 個人としてチームメンバーを知る
- リラックスした雰囲気でやっていくのがよい
- 期待したものが返ってこない場合もっと考えてもらうしかない
- もっと準備してほしかったとか時間をおいて再度依頼する
- フィードバックスキル
- 一番改善余地がある
- フィードバックを依頼する
- 会議のファシリテーション
- 発言のバランシング
- チェックリストを毎日見直そう
- レトロスペクティブでチームメンバーからのフィードバックをもらうことが重要
所感
今後のチーム開発でめっちゃ重要だなと思った。 とくにフィードバックをメンバーからもらうことの重要性はとても共感して、すぐ実践に移していきたいと思った。 紹介されていたScrum Masteryという本も気になった。
ゲーム開発現場の中心で心理的安全性を叫ぶ
Detail
Slide
ゲーム開発現場の中心で心理的安全性を叫ぶ [RSGT2018]
Memo
- テーマ
- 勉強会
- 課題感とか
- xxやりたい→やったらいいやん
- サポートなし
- 言ったもん負け
- よくある
- 言える化聞ける化できてない
- 勉強会のハードル高い
- ゲーム以外のイベントへの参加はまれ
- なんで？とか何持ち帰るのかとか
- xxやりたい→やったらいいやん
- 言わずに勝手に決めていることが多い
- 言える化、やれる化できるように不安を取り除きたい
- 組織の空気を変える
- 複数の小さなグループや個人からアプローチ
- 関わる人を増やして当たり前化する
- LT開催
- ハードル下げる
- オープンスペースでやる
- 会議室だと途中から入りづらい
- やってたら人が寄ってくるような雰囲気づくり
- イベント参加報告をレポートからLTに
- 楽になったし早くなった
- まとめ
- 外の人より中の人を大事にしていけばいい
- テーマ
- 心理的安全性
- ゲームとアジャイルは相性いい
- 実際つくって手触りとか確かめて軌道修正するので
- 余談
- 心理的安全性とは
- 仲間に背中を預けてチャレンジできる状態
- チャレンジは一人ではできない
- 仲間の手助けがあってチャレンジできる
- そういう状態があると、透明性高めてもこのチームなら大丈夫となる
- たとえば
- 失敗してもこのチームなら大丈夫
- 上司の理解
- 信頼貯金
- チームの身の丈を知っている
- 個人的な不安の払拭
- 具体的にやってきたこと
所感
単に透明性をあげればいいということではない、というのはたしかに、と思った。 モスバーガーの看板法よさそう。 ふりかえりでありがとうが出るかという指標も参考になりそう。
Scrum プロジェクト開始のベストプラクティス
Detail
Slide
Scrumプロジェクト開始のベストプラクティス #RSGT2018 | SlideHub @ryuzee
Memo
- スプリント開始前に何を用意するといいのか
- スクラム始める前にやること
- よくあるやつ
- インセプションデッキ
- 書けばいいのか
- 作ることは目的ではない
- 共通理解の形成が目的
- 観点
- プロダクト
- 人
- 技術や品質
- 計画、マネジメント
- 観点は相互に影響しあう
- プロダクト
- 人
- 技術と品質
- プラクティスの選択
- スクラムは全部
- XPは必要なものを取り入れればよい
- 全部いれすぎない
- 計画、マネジメント
- 全体の規模感を最初に把握しておく
- スコープは可変なので最初との差分をわかるようにするため
- 初期フェーズの進め方
- スプリント1を開始するための準備期間
- 1ヶ月が目安
- 全部の項目の検討を同じ重み付けでやるわけではない
- 重要なものからやる
- どこまで決まったら終わりでいいかを決める
- 準備期間もスクラムの考え方でやる
- スプリント1を開始するための準備期間
所感
新規立ち上げの際やチームが変わったりした場合にはインセプションデッキやったりプラクティスや進め方的には結構やってる内容が多かった。 ただそれを効果的にやれているかはまた別の話で、いかに質の高いものにできるかなどはファシリ力次第なんだろうなーと思った。 プロジェクト発足当初は結構忙しいのでその中でもどれだけ効率的に立ち上げられるかは経験値を貯めていくしかないのかなーと感じた。
Day2 基調講演 敢えて属人化せよ！エキスパートの集団こそが最強のチーム(Embrace Collaboration and Fun of Coding)
Detail
Slide
資料なし
Memo
- MSで日本からUSに移った人
- USの環境
- 個室からオープンスペースになった
- 最初は嫌がった
- レイテンシのないコミュニケーション大事
- が、また個室に戻った（オフィス改装に伴い）
- モニター5枚
- 個室もいいところがある
- どっちもメリデメある
- チームの雰囲気みながらマネジメントしていったほうがいい
- マインド
- 作るの楽しい
- そのためには環境がいる
- 超人の同僚、いいマネージャ
- 広い机と速いマシン
- 家にいるより会社にきたほうがいいマシンがないと会社にくる意味がないよね
- あがる給料、正当な評価
- ネトゲしながらコード書いてる同僚もいる
- 当初
- アジャイル開発はバックログと共に生きること
- どうやってチームがウォーターフォールからアジャイルに切り替えたか
- App Serviceの開発プロセスの変遷
- DevOpsは今はやってない
- デプロイメントのチームがボトルネックになる
- バグをみつけたらすぐ修正してリリースしたい
- Dev+Supportになった（うちと一緒？）
- 評価システム
- 5段階評価
- 1がよくて5がサヨナラ
- マネージャが全員を成績順に並べる
- あるとき全部やめた
- チームメンバーどうしの競争につながる
- やめたら他の誰かに追われるという感覚がなくなって働きやすくなった
- マネージャは部下をどう評価するか
- 評価はマネージャの力量が問われる
- チームの価値はどれだけお客さんに届けることができたか
- もう一つの課題
- 上司が自分を正当に評価してくれない・・
- 自分がパフォーマンスを発揮できないマネージャはどうするか
- 上司を評価するシステムがある
- 上司への評価は上司の上司にいく
- パフォーマンスを発揮できない、発揮させることができていない場合チームを移るとか会社を移るとかの選択肢がある
- 人材の流動性は結構ある
- そんな環境でセキュリティ対策どうしてるか
- ハッカソンの力
- ガチでやってる
- 1週間業務止める
- マネジメントががっちり固めてる
- 楽しいからいいものを作れる
- テーマ募集すると40個くらい出てくる
- 共感してくれる人を巻き込んでフィーチャを作ってしまう
- 実際にそこから新しいプロダクトができちゃう
- 業務と直接関係ないところにエンジニアのポテンシャルを生かせる場が用意されてる
- マネジメントのバックアップが必ず必要
- マネージメントの力
- どこがゴールなのか
- なぜ必要なのか
- これをやるとどうお客さんが喜ぶのか
- こういうメッセージをマネージメントは日々発信し続けることが重要
- 変わらないことは「変化することだけ」
- スイッチを切り替えるべし
所感
ここでもやはりとにかくやってみるということが重要であると言われていた。 楽しんで開発しているということも度々言われていていい環境だなーと感じた。 やはり自信を持ってうちで開発するの楽しいよ！！って言える組織にしていかないと。
Scrumが難しいのは幻想 -情熱の再定義-
Detail
Slide
Scrumが難しいのは幻想-情熱の再定義- を講演してきました。 #RSGT2018 - うさぎ組
Memo
- 導入
- ある日の会話
- 情熱が足りないとか言われるけど情熱で開発しているわけじゃない
- POは情熱という言葉で片付けがち
- 情熱とはなんなのか突き詰めて考えようとした
- はじまり
- やったことなど
- プロダクト、チームが変わるとどうなるか
- フルタイムじゃない人がいたり、スキルレベルが違ったり
- 共感駆動
- PDCAの前に共感がないとチームビルディングができない
- チームと苦楽を共にして同じ言葉で会話できるようにならないといけない
- 技術的プラクティス
- 基本チームにまかせる
- レトロスペクティブ
- メトリクスをとらないようにしたので、ふつうにKPT
- 最初から変えたこと
- 1時間スプリント
- 専用プロジェクトルーム
- 課題
- 1時間スプリントのわりに改善できてない
- 1時間でも1日でもマネジメントの質があがっていない
- なにを改善すればいいのかわからない
- 理想像を定義する
- やみくもな改善は局所最適
- 改善の前にゴールを設定
- プロジェクト最適ではなく、ソフトウェア工学の１ページを追加したいと思っている
- 超個体へのチャレンジ
- 情熱の再定義につながる
- 軍隊アリは情熱で動いているわけではない
- こうしたいと思うことを情熱に頼るのはよくない
- 情熱がある人を観察すると、
- xxxが発生したらyyyをする
- 的なルールで動いていることがわかる
- システムと一緒
- 情熱がある人を観察すると、
- 会話ってなぜコンパイルエラーにならないの？
- 私と仕事どっちが大事なの？型エラー！とかなってほしい
- 情熱をシステムとして再定義する
- 無駄であふれている
- あの人はああいうやり方は好まないからこういう言い方で相談してみよう・・とか考えるのは無駄
- 1時間スプリントで1分の遅れって致命的
- タイムボックスは受動的でいい
- 学校のチャイムみたいなの鳴らしてる
- 何時かな？とか考える時間が無駄
- スプリントレビュー
- チェックリスト
- レトロスペクティブ
- share
- バリューストリームマップ
- サイクル効率
所感
分刻みのスケジュールすごい。無駄の排除が徹底的。 モブプロやってたときは1日にAARで数回ふりかえりやってたけど比にならなかった。 守破離の守を徹底的にやったあと、最適化を徹底的にやってこの状態にしたんだろうなーと思った。でも本当やるときはこれくらいストイックにやらないと見えてこないからまたやらないと。
そういえばPOってエンジニアとは異なる知識もいるけどランダムロールってのはどういうチームだと成り立つのだろうか？
スクラムチームとして、妨害リスト（Impediments List ) を運用して見えてきた課題解決方法
Detail
Slide
Memo
- 妨害リスト
- ボード
- まずfactに注目したい
- 登録されたらfactを集めに行く
- そこから優先度が決まる
- 例
- 人やスキル
- 環境
- プロダクト
- 品質にかかわる姿勢
- パートナーとかも自由に登録できるようにする
- 何が妨げになるのかを俯瞰できる
- 振り返りで出てくる課題とどう違うのか
- 結果から直近の行動に対して振り返る
- 妨害は前提に潜んでいることが多い（チームの外とか）
- 前提に対しての課題解決となる
- 妨害リストの運用
- スクラムの中で透明性を保ってやるほうがいい
- 誰かが勝手に解決してしまわないように
- Trello結構使ってる → エウレカがTrelloボードを作成する時に、必ず行う設定
- チーム外にも見える化すると会話がしやすい
- 直接話しにくい話題でも妨害リストにすると話しやすくなる
- スクラムの中で透明性を保ってやるほうがいい
- 定着のために
- しばらくすると更新されないとか問題が起こる
- デイリーミーティングできく
- 定期的な棚卸しの場をつくる
- 妨害リストを運用する場をつくることが重要
所感
ふりかえりの課題とは別で課題を出せる場所を、ちゃんと意図があって分けるようにしているのがいいと思った。 まずfactを集めて、factをもとに優先度を決めるというのがよさそう。 運用は大変だけど、チームメンバーがサポートしてくれたらやれそうですね。
「ふりかえり」の始め方と続け方
Detail
Regional Scrum Gathering Tokyo 2018 - 「ふりかえり」の始め方と続け方 | ConfEngine - Conference Management Platform
Slide
Memo
- 前提
- 心理的安全性
- 真因にたどり着くようにする
- 場づくり大事
- 始め方
- 場づくり
- 状況にあったやり方
- 場づくり
- 参加者
- 発言しにくい空気を作る人は呼ばないとか
- 気持ちとか準備
- 障害起きてるときはできないよねとか
- どんなイベントがあったか確認とか
- 場の空間
- えらいひとの近くとかはちょっと・・
- 道具、ふせんとペンがいいよ
- 参加者
- 状況にあったやり方
- 続け方
- 点ではなく線でふりかえる
- 前回とまったく関係ないことにフォーカスしちゃうとよくわからなくなる
- 線でみていけるメトリクスをみたほうがいい
- 事実に向き合いやすくなる
- メトリクス
- トラブル数
- 追加削除のコード行数
- バックログアイテムの分類（機能追加なのかバグなのか）
- メトリクスのポイント
- 2点以上みる
- ベロシティあがっても残業時間あがったらNG
- 定性的なものでもいい
- 2点以上みる
- アクションを日々の活動に組み入れる
- リードする人を決める
- 責任はチームにある
- タスクをする時間を見積もる
- リードする人を決める
- 点ではなく線でふりかえる
- 参考
所感
形骸化しがちなとりあえずKPTからちゃんと課題や成長ポイントにたどり着くためのヒントがあった。 自分のチームはやっぱりとりあえずKPTにしてしまっていてなかなか課題出ないなーみたいな時期もあったので、メトリクスのネタはいろいろ考えてみたい。
Smug? Oyatsu Shrine ~ Improvement patterns seen through practicing "Oyatsu Shrine" ~ どや！？オヤツ神社 ～実践しているオヤツ神社を通して見る改善パターン～
Detail
Slide
Memo
- カイゼンの現実
- 銀の弾丸ない
- いいと言われているものをやっても自分のチームではうまくいかない
- 人の問題
- 組織パターン
- チームになりきれていない
- ぎこちない関係のまま
- 解決策
- 自然と人があつまる
- 質の高い会話ができる
- おやつ神社
- おやつ神社
- おやつ神社はパターン
- scrum PLoP
- こういうふうにやったらいいよっていうパターン
- パターンとは
- 形は決まっている
- パターンの適用
- おやつ神社 is 対話をする場
- 御神体
- copeのサイン
- プリンター横
- プリンター待ちのときに会話が生まれるといいのでは
- みんなの目につくところに置くときれいにしてくれる
- 市民権
- えらいひとに直訴
- 資金が尽きたら終わり
- 仕入れサイクル
- アンチパターン
- 蟻地獄
- 自分の近くに置いて進捗どうですかと聞くとだれもこなくなった
- 可視化→菓子化
所感
Scrum PLoP(Pattern Language of Program)自体知らなかった、色々参考になりそう。 オヤツ神社建立試してみようと思いました。
がんばれスクラムマスター（流しが見てきたスクラムマスターの理想と現実）
Detail
Slide
Memo
- 定義
- 失敗例
- 新人
- 自己組織化を阻害
- 解決策を提示
- 理由を説明できない
- 開発と兼任で忙しい
- やっぱり専任でやれるといい
- スクラムマスターはどこにいけばいいか
所感
チームの自己組織化を支援するというテーマは理解していたが、自己組織化したあとどうなるの？というのはよくわかっていなかったので参考になった。
実感駆動でものづくり ー 協調学習過程としてのスクラム。欲しいものを、どうやって知るか。
Detail
Slide
Regional Scrum Gathering Tokyo 2018
Memo
- 従来開発のあるある
- リリース後にユーザーが使う、フィードバックを反映できる体制や予算はないことが多い
- 要件で削られ、、
- 予算で削られ、、
- 実装できず、、
- 使われず、、
- 実装できず、、
- 予算で削られ、、
- 使われるのはごくすこし
- リーンスタートアップ
- 小さい仮説検証を高速にまわす
- テーマはカネと政治
- イノベーションのジレンマ
- 破壊的イノベーション
- 実際にやるのは大変
- 社内政治を攻略する
- 組織をハックする
- イノベーションのジレンマ
- カネとAgile
- カネといっても
- チームを維持する燃料（コスト）
- 儲けの話ではない
- カネの扱いをミスるとアジリティを下げる心理バイアスにつながる
- エンタープライズx新規ビジネスでおこりがちな話し
- 新規事業なのに計画駆動になる
- ベースとなるサイクルが年
- 1年後を予測して計画するので発見による軌道修正が困難になる
- いくら現場がアジャイルやスクラムでやっていても外枠を作っているお金のリズムが制約になる
- 資金調達する単位を細かくしたほうがいい
- アジャイルの軌道修正とお金の調達とあわせないといかん
- カネと説明責任のレイヤーからアジャイルにする必要がある
- 資金調達タイミング
- 指標が変化するタイミング
- 導入期に追うべき指標は継続率（リテンション）
- プロブレムに対してソリューションがあっている状態をつくる
- 顧客実証
- CAC（獲得コスト） < LTV
- 都度進捗報告に応じた資金調達ができるといい
- お金のリズムとしてもアジャイルにしやすい
- ステージゲート方式
- ビジネス目線でのアウトカムのでるスクラムチームになっていかないといけない
- カネといっても
- カネと政治とちょっといい話
所感
お金のリズムと開発のリズムから合わせにいかないとだめだよという話はたしかにそうだなと思った。 KPI周りの考え方も参考になった。 金と政治の話はなかなかおおっぴらに話しにくい内容な気がするけどめっちゃフランクに話されてて楽しんで聞くことができました。
Day3 基調講演 / クロージングキーノート あなたの中に世界がある / You are the World
Detail
Slide
なし
Memo
- RSGT2018に集まっている人
- ステージを変えたい人
- ステージが変わった人
- ステージを変えちゃった人
- リーダーとは
- 小さいときは親がリーダー
- そのうち親から離れて自分のことは自分で決めるようになる（自分がリーダー）
- さらにステージが進むと、
- 学校
- 地域
- 社会
- 等々でリーダーとなる場面がある
- なぜ自分がやらなくてはいけないのか
- （岩切さんの場合）パンドラの箱を開け続けてきた
- 世の中を変えることができるのは
- 政治家
- デザイナー
- デベロッパー
- 大義の元に世の中を変えていってほしい
所感
大きなプロジェクトの無茶振りに応えてきた話を聞かせてもらい、多くの大変なやるべきことの中からどういう観点で自分のやるべきことを選択してきたのかと言う観点で共感した。 組織パターン読む。 自分なりの大義をみつけて仕事をしていきたいなーと感じた。
全体通して
アジャイルやスクラムというとプラクティスの部分が注目されがちなイメージがあるけど、より根本にある考え方に色々触れられた気がしてとてもよかった。
色々な人と話してこれまでより全然自分の中での理解がすっきりしているし、今後もここを軸にプロダクト開発を考えていきたいなーと思った。
個人的に気になっていたこととして、認定資格を取るとどうなるの？という疑問があったんだけど、川口さんとお話しする機会があって、一番の理由は講師からパッションをもらえるということという話を聞いてとても納得感があった。
なぜならRSGTに参加するだけでも相当意識を引き上げられたから。
ちなみにこの内容は社内勉強会でも共有した。
エンジニアだけでなくPOやデザイナーも参加してくれて、これまでなんとなく進めていたものについてこんな体系的なものがあるよという提案にはなった気がする。
これがきっかけになったのかわからないけど、次の社内の読書会のネタはスクラムブートキャンプになった。昔チームでやったときはあんまり興味持つ人いないだろうから・・という理由でチーム内でやってたけど、今は関心が広がりつつあるかんじでとても良い。
そんな取り組みをやりつつ、来年は僕以外のメンバーも複数人参加できるとさらにいろんな動きが加速していくんじゃないかなと思った。
