公式サイト
https://www.agilejapan.org/index.html
🎉Agile Japan 2019🎉
— サテライト行脚中！アジャイルジャパンの中の人 (@agilejapan) April 11, 2019
今年は7/18(木)に開催します！
こちら詳細はこちらから💁♀️https://t.co/E9TpW1Yfeu#agilejapan pic.twitter.com/Dlae5LqPiV
会社でアジャイルなお仕事をやってるので、会社の経費で参加です。
以下、復習用の個人メモ。
[基調講演] マネージャー不在の洞窟型組織
セッション紹介： https://www.agilejapan.org/session.html#e-03
スライド： https://www.agilejapan.org/2019/session/keynote-03_GROOVE.pdf
【第１部】LOVOT概要および発表後の反響について
起業から発売あで、4年間売り上げゼロで、事業費100億。
LOVOTは３６０度の顔認識。
家に来ると地図を作る。
すべての声がオリジナルで、喉がある
服を着ないと動かない。着ている服を認識する。
赤ちゃんの見守りをする。
外出中の家の状況を送信する。動ける。
【第２部】LOVOT開発に、アジャイルが必須な理由
ピラミッド型はマネージャが必要。
GROOVEはフラット組織にしている。
LOVOT 開発は先が見通せないため、思考と学習を重視した。
初期が一番知識が無い。
見通せない領域はアジャイルが大事。
今は複雑で見通せない範囲が多い。
アジャイルでやるならフラットが相性がいい。
LOVOT開発は、生命の進化プロセスを４年の開発期間で再現
・早く試して、いかに早く学ぶか
・スコープがどんどん変わる
そのなかでどうやって組織を運営していくかの最適解がスクラム
①早く試して早く学ぶ
SpaceXの動画は、失敗をすることを誇っている。なぜなら、失敗させたほうが学びが大きいから。
ロケット打ち上げはNASAからSpaceXに移ってきた。
・NASAは税金を使うので失敗できない。それでどんどんコストが上がった
・SpaceXは失敗しても税金を使ってないので、失敗を許容しやすい
でも、「早く試して早く学ぶ」というのは、実際は大変。なぜなら、不安になるから。
アジャイルは【コロンブスの新大陸の発見」と同じだと思った。
コロンブスが戦ったのは、船員の不安。
なんとか船員を束ねながら新大陸を発見した。
不安のマネジメントが出来たのがコロンブスの勝因。
①早く試して、早く学ぶ → 不安との戦い → 見える化して不安解消
見せる化をして不安を解消するのが大事。
見通しの悪いところで遭難しない能力がアジャイル。
ぎりぎりを責めることが大事。
一歩間違えると失敗する。
ギリギリを攻めるにはどうすればいいのか。
それは、片足が落ちても踏みとどまれるかどうか。
失敗を盛大にするとリカバリにすごい時間がかかる。
アジャイルどころではなくなる。
どれだけ片足が落ちた時点で気づけるかが大事。
片足を落とし慣れるのがスクラム。
何かが起きたらすぐ方針転換する。
②スコープがよく変わる 〜オペレーションの完成度をあげる組織の弱み〜
スコープが変わると何がツライかというと、ピラミッド型は部門ごとに領域が分かれること。
仕様変更が少ない場合はこれが一番効率良い。
でも、領域を分けると、領域間の隙間ができる。
忙しくなると領域が狭くなってきて、領域間に隙間ができる。
３－６か月かかって隙間がでてきて、埋めるのにまた同じくらいかかる。
最後に帳尻合わせでガタガタなものになる。
スコープが変わることを前提として作らざるを得なかったので、フラット型の組織を採用した。
フラッと型組織だと、隙間があると気づく。
各自の不安で領域間の空白地帯があぶり出される。
経営者には不透明感が出るかもしれないけど、それでも他社は追随出来なくなるので納得する。
組織のタイプ 〜「自律性」と、「船頭の数」によって、性質とパフォーマンスが変わる〜
フラット組織を導入して失敗するのは、仲良し組織で船頭が多数の場合。
船頭が多くなりすぎるのは取るべき選択肢ではない。
完全フラットだと、１０人いると１０の意見が出る。
船頭多くして船山に上る。
自律性はあるけど、物事が纏まらない。
派閥のないピラミッド組織ピラミッドは上手くいく。
スクラム・ホラクラシー型フラット組織
スクラムは横連携のコストが安い。
スコープ変化のコストが安い。
でも各自が説明責任を持たないといけない。
なぜなら横連携でコミュニケーションできないとメリットが活かされないから。
イノベーションにおいて大切な能力は、“Learning agility” (学びの素早さ）
職場の活気① 〜スクラム＆フラット型組織の組み合わせは、活気がある〜
ピラミッド型組織は２：６：２の法則になる。
フラット型組織にすると下位の２割がほどんどいなくなる。
中間６割と上位２割の区別がなくなっていく。
それに対し、ピラミッド型組織の下位２割は生産性がマイナスで、それらが中間層の６割を食ってしまう。
するとピラミッド型の青の面積が減る。
フラット型組織は、青の総面積は大きい。
職場の活気② 〜「飽きる」をポジティブの捉える〜
イノベーションにおいて大切な能力 ＝ “Learning agility”
学びが素早い＝飽きっぽい
数年で飽きてもおかしくない。
飽きた人を縛り付けるとLearning agilityが下がるので輝きが失われる。
最大の敵は「飽き」
職場の活気② 〜「飽きる」をポジティブの捉える〜
７割は死亡保険の加入率は、アメリカは2割だけど日本は7割。
日本人は不安を減らす努力を怠らない。
でもリスクを取らないのでLearning agilityが上がらない。
積極的に「飽きる」ことを認め、覚悟を決めると、生産性はあげられる
飽きたら早めに手を挙げてもらう。
挑戦はLearning agilityの向上にもなる。
スクラムのメリット まとめ
船頭を一人に保ちながらチームの自律性を維持することが可能。
「服従の心理」という本がおすすめ。
フラット型でスクラム運営すると職場に活気が出る。
・スクラムできない、というヒエラルキーと戦うくらいならフラット組織にしてしまう
アジャイルコーチ、スクラムマスター、研修等にしっかりコストをかける
・研修にコストをかけて、ようやく動き始める。
実運用は、午後のセッションにて説明
Bazaar（バザール）をやってる。
フィーチャーチームへの移行には適切な時期がある。
なので、コンポーネントチームから始めている。
【残り時間】QA
Q.
会社だと人事評価とかある。どうされてるか？
A.
フィードバックと評価は分離しようとしている
フィードバックは振り返りをやっている。
年に１回、360度フィードバックをやっている。
スプリントごとのふりかえりは業務ふりかえりをやってる。
その人の成長以外に、自己認識と他己認識の乖離をどう理解するのかの課題がある。
自分はコミュニケーションできてると思ってるのに、他の人からは「できてない」と思われていることがある。
360度フィードバックは、最低７人からやっている。
自分と他者の乖離を見る。
トラブルとなるのは自己認識と他己認識が乖離している部分。
評価は、今はやっていない。
評価は一度やってしまうと、情報硬直性があるので難しい。
自分が手をあげて他の人が承認するプロセスを考えている。
チームで、どうやって給料を決めるかを考えてもらおうと思っている。
Q.
自律型組織に合わない人は、出ていってもらうことあるか？
A.
あまりない。
フィットする人ばかりではないが、合わないと自分から移っていく。
入社して１～２か月は、多くの人が戸惑う。
１～２か月経って、自分が合うか合わないかがわかる。
合わなければ離れていく。
でも離職率２～３％くらい。
Q.
出資者に対するリリースバーンダウンチャートの説明とか、スプリントレビューとか、どうやって出資者に説明しているか？
A.
出資者はフラット型組織とスクラムに慣れていない
フラット型組織で失敗するベンチャーが多すぎるのは、拡大する時に課題がでて、ヒエラルキーに転換することが多いから。
なので出資者にはウォーターフォール的に説明している。
POの責務として、ROIを最適化するというのがある。ROIのIは、イノベータからのIN。
外向きにはウォーターフォール、内向きにはアジャイルで。
日本のイノベーションを加速するScrum
セッション： https://www.agilejapan.org/session.html#l-03
ランチセッションです。無料配布のサンドイッチおいしかった。
戦闘機「グリペン」の開発で使ってるスクラムのプロセスは、Scrum@Scaleですね。
今年のデブサミで原田さんのScrum@Scaleのセッション聞いて、ブログ書いてます。
#agilejapan で講演の「日本のイノベーションを加速するScrum」を公開しました！たくさんのご来場ありがとうございました。今回は事例を多く含めました。また、「日本のやり方」の模索も考察しています。https://t.co/Oa4ZpGnNlZ
— Kenji Hiranabe (@hiranabe) July 22, 2019
アジャイルジャパン、ありがとう。ブログ書きました。 #agilejapan https://t.co/ndWXOAlZG3
— Kenji Hiranabe (@hiranabe) July 25, 2019
展示会場では、いろんなブースが出てました。こちらは「旅するAgile本箱」。
アジャイル関連の書籍がたくさんあって、何冊か手に取って目を通させていただきました。
なぜ始まらない？アジャイル開発 アジャイルコーチと考える組織改革
セッション： https://www.agilejapan.org/session.html#e-05
スライド： https://www.agilejapan.org/2019/session/west1-2_freee.pdf
3セッション分の時間枠だったので、前半の2セッション分の時間枠のみ参加しました。
前半は、実際にコーチから支援を受けたチームの体験談が複数あったあと、質疑応答になりました。
以下、メモ。
---
コーチの見つけ方
上司が知ってる方を連れてきて、やっとむさんがやってきた
コーチ呼んでよかったこと
第三者視点でアドバイスくれる。社内事情に左右されない。
コーチ来る前は、やってて自信が持てないのがツライ
アジャイルコーチを呼んで型を知り、型を守る。
まずは徹底する。
目的からずれ始めたらアジャイルコーチが指摘してくれた。
第三者的な視点で意見をくれるのがよい。
アジャイルの要素の概念が説明できるようになった。
ワークショップで考える会を開いてもらって、それで身についた。
コーチが不要になるようにコーチが動いてくれた。
圧倒的にホワイトボードや付箋を使うようになった。
コーチの見つけ方
コミュニティとか、知り合いからの紹介だった。
スクラムでずっといくわけじゃないので、そのあたりに中立な人が希望だった。
自分がいなくてもよいようにする、と表明してくれた。
コーチ呼ぶのに困ったところ
モノづくりしないのでどれだけコストかけていいか
コーチングやティーチングできる人は単価が高い
でも、コーチがSMやPOを育ててくれるのなら安いのでは。
まとめ
スクラムをはじめるのなら徹底する
徹底しないと良し悪しが分からない。
体験する場や考える場を設けてくれるの大事。
質疑応答（ディスカッション）
最初に、周りの人とこのセッションで質問したいことについて話し合う時間がとられました。
私のグループでは以下のような意見ができました。
・コーチが目指していること
・コーチがいなくなってもいいとは
・仮説検証のやりかた
・コーチとして入るときに、絶対外してはいけないこと
そのあと、各グループで出た質問内容をもとに、質疑応答ベースでセッションが進みました。
聴衆から出た質問はいかのようなものがありました。
・コーチ入る前に、どう始めたか？
・コーチのお値段
・やりはじめて最初もやもやしたのがどのタイミングで晴れてきたか
・freeで半年でよく半年で慣れたな
・1つのチームを社内に広げるときに何やれば広がるか
・コーチ導入する際にユーザ企業様と文化の相違あるときに衝突とかどうすりあわせるか
・コーチが週2日に入る時は、週のどんな日か。スクラムイベントがある日か？
・メンバーがコーチやスクラムに好意的じゃないときにどう進めていくか
・守破離の守で立ちいかなくて解散してしまった場合、どうやってマインドセットを育てていくのか
・コーチって、SMにやりかたを教えて、SMからチームに教えるのか
・アジャイルを上の縦に広げていくには？
Q.
コーチのお値段は？
A.
アトラクタさん25万円/日
今日のコーチのみなさんのお値段は↓
・15万円/日
・13万円/日
・15万円/日
まずは試してみませんか、で、最初だけ13万とか少し安くする。
コーチが合うかどうか大事なので、最初は安く設定とかして、長期的にいけそうなら価格を設定する。
Q.
コーチがくる日は？
A.
最初は週２で、今は週１
スクラムイベントがよく理解できていないときは、スクラムイベントを1日に全部入れるのはキツイので、それで2日にした
2日きてもらったほうがワークショップとかしてもらえるし。
意味が大丈夫とかなってきたら週１に
始める時はがっつり1か月フルでコーチに来てもらった。
スクラムの役割とかセレモニーとか、教えてもらう。
1週間、缶詰めになって議論する。POも入ってもらう。
だんだん歩けるようになってから、コーチに少しづつ離れてもらう。
Q.
コーチはどう入りたいか？
A.
月１はやめたほうがいい。
週１か２で、変化を見る。考える時間を作る。
チームにじっくり考えてもらう必要があるときは週３
スクラムイベントは出たいので、週１～２は必須。
スプリント０のときは週３か週４で入った。
最初は週３～４で半日を4回とか、間をあけないように。
コーチが抜けていくときは、イベントだけ参加とか。
そこでチームができるようになってきたら、開発中にチームがどうコミュニケーションしてるか、とかを見る。
それで、テスト書いてないね、ということが分かると、「一緒にテスト書こうか」と言う。
コーチが得意としていることは、スキルによる。
イベントある日に行くこともあれば、わざとイベントの日を外していくこともある。
スクラムイベントデーは、アジャイルコーチを確保できないことある。
他のプロジェクトにコーチを先通りされてしまう。
コーチの都合で丸1日フルで行けない日がでることがあるが、半日だけでも、行けない日よりはマシ。
午前は現場A、午後は現場Bとか。
コーチの掛け持ちは２～３件かな。
正しいものを正しくつくる ープロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
セッション： https://www.agilejapan.org/session.html#p-01
「正しいものを正しく作る」というタイトルだと、「正しいとはなんや？」となるので・・・
今日のテーマは「分からないものを分かるようにする」
文脈
・新規事業やサービスづくり
・はじめてアジャイルに取り組む
どちらも、どうなるかわからない、というのが共通
分からない状況でも進めていかなければいけない
どうやればいいか？
不確実性の高い状況にどう立ち向かうか？
→ 基本戦略：わからないものをわかるようにする
「不確実」な中に、「確実」をつくる
わかるところを作る
わからないものをわからないまま進める
→わかったことが役立つかは運任せ
わからないことが後でわかってきても後の祭り
ビジネスは、間に合わないとダメ
わかるようにするための活動とは
検証活動を重ねて空白地帯（分からないこと）を知識で埋めていく
わからないものをわかるようにする戦略
１．わからないから選択肢を広く持つ
決めうちして間違えると時間的損失が大きい
時間あたりで得られる学びが少ない
２．最も「わかる」のは想像ではなく現実に直面したとき
→いかに現実に近い状況をコスパよくつくるか
コスパがよくないと繰り返しできない
３．分かる、に使う距離（時間、予算）を段階的に
活かす次が無いと意味がない
次を活かす設計＝段階化
現実歪曲曲線
縦軸がリアリティ
横軸がリソース
傾きは一定でない
ランディングページは早いけど、リアリティない
デザイン入りプロトタイプは、飛躍的にリアリティが上がる
フロントエンドのみ実装プロトタイプは、より表側の動きできて体験が味わえる。でもリソースはあがる
インターネットで公開できるMVPが最後にあり、リアリティとリソースは高い
横軸： 最初の学びを得られるまでの時間差
縦軸： 得られる学びの量との差
最初は左下だけでもかなりわかる。早く。それで学びを得られる
お金をかけてリアリティかけるよりいいんじゃないかな
MVPの力学
リソースももったいないけど、時間がもっともったいない
なのでリソースを減らしてリアリティを上げたい
できるだけ左上を目指す。 ①→②
ノンコーディングプロトタイプイングツールとかも使える。
競合他社のありものの製品を使うなら、安く済む
それでわかったフィードバックから仮説を立てて検証していくとか。そういう作戦もある
リソースは利用料を払うだけでいきなり検証できるものを使えばよい。
大企業の戦略
予算を投下して、たくさんの選択肢を試す
→ 段階的にダメな案を省いていく
→ 残った選択肢でプロトタイプを作っていく
現実で多いのは・・・
・決め打ち
・想像だけで決め打ち
・想像だけで決め打ちでいきなり超リアリティのあるものを作ってしまう
→ 学びはあるが、かける予算と時間と、期待があってない
→ 頓挫
・大企業的戦略もだいたい取られない
決め打ちは間違っている、とわかってるけど、なぜ起きる？
環境最適化問題
俯瞰的視点に立てば誤りに気づくことでも、詳細に寄りすぎると誤りに気が付かない
そこで、「自分たちを立ち止まらせる問い」を
ほんとにこれでいいんか？
正しいものを正しく作れているか
自分たちの思考と行動に別の方向性を与える
気づけないことを気づけるようにするにはどうすればいいか？
人は制約を置かれたたとき、その制約の下で最適な解を見つけようとする
例えば、「重要なものを選べ」だと、全部重要ということで全部選ばれてしまう
「TOP3を選べ」とすると、並べて比較して決めるようになる
自分が気づけないところに行くには、
自分たちの意識にとらわれない問いで思考や行動に向き直る
不確実な高い状況ほど、わかっていることに答えてばかりいても発見が足りない
→ 回答不可能な問いをあえて置く
そのやりかたの１つが仮説検証型アジャイル開発
本当にできるの？
→ 経産省のシン・ミラサポプロジェクト
アジャイル開発だけで何をつくるべきかが見えるわけではない
・価値探索
・インセプションデッキ
・仮説キャンバス
・ユーザーインタビュー
やると見えてくる問題がある
LeSSでつなぐビジネスとIT
セッション： https://www.agilejapan.org/session.html#e-12
現在の組織の問題点１： 官僚型のマネジメント
・標準化で誰でもできる、わかりやすい
・ビジネスとITが分離され、開発現場が顧客視点を失う
・顧客に素早く価値を届けることよりも、組織内部の稼働に注目する
現在の組織の問題点２： サイロ化した組織
・機能別の部門
・部門の責務に閉じた目標
従来型の組織はチームになっていない
役割間で異なる目標、作業分担、やり方が共有されていない
組織をチームにしよう
・同じ目標を持つ
・フォローしあう関係
・やりかたを共有している
LeSSのコンセプト
組織をシンプルにし、アジャイルになるためにはどうすればいいか？
スクラムを大規模にするために、著者二人が実験をたくさんやってて、それが本になってる
大規模スクラムはスクラムである
スクラムの導入が爆発的に増えている理由
スクラムの成功は抽象的な原理原則と、具体的な手法の絶妙なバランスにある
LESSはスクラムと同様にバランスをとっている
抽象的な原理原則と具体的なプラクティス
LESS
フレームワークをルールで定義している。ルールは少ない。４－５枚くらい。
それだけだと動くの難しい。そのためにガイドが周りを覆っている
そのまわりに実験がある。みなさん実験してみましょう
フレームワークが薄くて、シンプルに初めて、実験してくださいね
原理・原則
LESSのコア
リーン思考とか顧客中心とか
少なくすることでもっと多く
フレームワークが軽い
フレームワーク
２つある
・LESS フレームワーク： ２～８チーム
・LESS HUGE フレームワーク： ９チーム以上
1人のPO、１つのプロダクトバックログ、１つのプロダクト
各チームは独自のプロダクトバックログを持っていない
完成の定義も１つ
すべてのチームが共通のスプリント
複数のチームが１つのスプリントで動いている
ラーマンの組織行動の原則
４つある
３の「カスタマイズ」と、４の「文化は構造に従う」について
クロールでしか泳いだことの内集落の話
１つの泳ぎ方しか知らない集落があった
クロールという名前も知らない
遠くの集落は違う泳ぎしている
平泳ぎというらしい
自分のはクロールと言うらしい
やってみようぜ
クロールしかしたことがない人が平泳ぎをすると
これまでより体力消耗するし、ぜんぜん進まない
これまでのやりかたを踏襲して、名前だけ変えて余計に重たくしているとか、あるある。
クロールをやったことない人が、やったことない平泳ぎを取り入れてもうまくいかない
ちゃんと学んでいかないといけない
自分たちが1点しか知らなくて、もう1個を知らないのに、その間の真ん中なんて取れるんですか？
カスタマイズする前に、振り切ってそれをやってみるのが大事。
文化は構造に従う
組織が変わらない限り、考え方は変わらない
顧客価値による組織化
・実際のチームを基本単位としてブロックを組んで組織をつくる
・自己管理、クロスファンクショナル、同一ロケーション、長期間存続
・チームの大半はフィーチャーチーム
フィーチャーチームとは
・エンドツーエンドで顧客中心のフィーチャーを実現する、安定した長期間存続するチーム
（フィーチャーチームの対称的な概念が、コンポーネントチーム）
・クロスファンクショナル
・クロスコンポーネント ・・・ すべてのコンポーネントはすべてのチームが面倒をみる
・すべてのスプリントで完成したフィーチャーを提供
フィーチャーチームの利点
・明確なフィーチャーの所有権
・遅延を引き起こす依存関係がない
・顧客の言葉で話す開発組織
LeSSでのマネジメント
・ 「Hackmanの権限マトリックス」は、縦軸が「権限」で、横軸が「チームの名称」
・2番目が「自己管理チーム」
アジャイルの文脈で求められているのは、最低限、自己管理チームであること
組織の強さを作る存在としてのマネージャ
２つの現場がある。
１．価値を消費する現場・・・ユーザ側
２．価値を創造する現場・・・チーム
「チーム」を組織図の一番上に置いて、マネージャは一番下にいる
・マネージャは、多くの権限をチームに移譲する
・マネージャは、チームとスクラムマスターが取り組んでいる障害排除と改善を手助けする
現地現物
１．問題解決力の向上 ・・・ マネージャの重要な役割は、問題解決の方法を教えること
２．より良い組織の意思決定 ・・・ マネージャはチームの仕事の状況を真に把握し、経営判断についてのフィードバックを得る
原著者からのメッセージ
階層型組織とマネジメント構造を同一を捉えている人が多いが、そうじゃない
階層型組織でも指示型のマネジメントスタイルでなければ自己管理チームを作ることは可能
大規模アジャイル方法論「SAFe」の実践 ～ペイメントサービスにおける組織デジタル化～
セッション： https://www.agilejapan.org/session.html#g-04
スライド： https://www.agilejapan.org/2019/session/east2-4_NTTdata.pdf
NTTデータのアジャイル
アジャイルプロフェッショナルセンタ
「Altemista」というブランドをやってる
方法論がProjectNow!
様々なメソドロジーを内包している
SAFe
・３つのレイヤ
１．システム開発
２．ビジネス
３．組織運営
・2017年頃からSAFeがデファクト
SAFeをどう始めればいいか
公式手順はImplementation Roadmapが提示されている
ガイドラインで汎用的
具体的にはイメージしにくい
NTTデータの事例： 国内最大のキャッシュレス決済総合プラットフォーム CAFIS
129名のSAFe体制で対応中
Large Solutionを意識したチーム構成
導入の課題
SAFeを開始するまでの導入部分の話をする。
SAFeの立ち上げ方
立ち上げプロセスが従来のウォーターフォールと全然違う
SAFeの前半プロセスは新しいので先入観なく取り組める
後半プロセスは従来プロセスを踏襲してやってしまいやすい
つまづかないように、後半プロセスを意識的に変えた。場所とか人とか組織とかシステムとか。
SAFeの５つのコンピテンシー：成功のための行動特性
SAFeの５つのコンピテンシーに４つ（場所、人、システム、組織）をマッピングした
１．場所
課題
・人が集まらない （高スキル技術者ほど市場価値が高いので）
・レイアウトの問題で会話が少ない
・大規模なので狭い、
・利便性とのトレードオフのセキュリティ
→ ラボを立ち上げて対応
場所の対策１： ラボ
人が集まる場所を目指す
１．働きやすい
２．ワクワクする職場
アクセスのよい都心
デザイン性の高いオフィスで、新しいものに取り組んでる感
多様なデバイス
場所の対策２： 対話重視のオフィス設計
・フリーアドレス ・・・ 同じチームとしか話さない、ようにしない
・どこでも会議可 ・・・ ホワイトボードをいっぱい設置して、移動式
・音楽が流れる ・・・ コミュニケーションしやすいように スピーカー置いたり
場所の対策３： 開放感のある十分なスペース
関係者全員が一堂に会せる
４フロアを確保
場所の対策４： 自由度を上げてもセキュリティは確保
社内LANと分離した独立NW環境
端末構成管理システムを用意
内部統制監視システムを導入し、コミュニケーションツールやファイル操作を監査
２．人（チーム）
人（チーム）の対応が一番の成功理由だった。
Scrumの定着率が低いのは、育成期間を確保し、アジャイルコーチ、チームのスクラップ＆ビルドで対応
人財評価
人の対策１：育成期間の確保
３～４スプリントはベロシティが上がらない
チーム立ち上げる際に、「見定め期間」を設ける
人の対策２：アジャイルコーチ
「見定め期間」にアジャイルコーチをつける
アジャイルコーチを入れるのが成功要因として大きかった
改善サイクルが不調の時とか、メンバ入れ替えがあったタイミングでもアジャイルコーチをつける
10チームのScrumチームを並行で立ち上げた
チームの立ち上げ期間をずらして、一人のアジャイルコーチが複数チームを見れるようにした
人の対策３： スクラップ＆ビルド
見定め期間をすぎぎてもうまくいかないチームがある。
→ 性格的な適正とか、一度出来上がった人間関係とかが原因
→ チームの解散、メンバ再配置も必要だと考えた。心を鬼に。
10チームが軌道に乗るまで、シビアに評価した
それがそのあとステップアップできた成功要因となった。
人の対策４：人財評価
人財評価は対応中。
スキルセットと育成プランを継続して作っていくのを取り組んでる
３．システム
アプリとインフラの維持コストが高いのが課題
→ オープンAPI化とかマイクロサービス化とかクラウドとか、対策をとった新環境を用意した
システムの対策１：オープンAPI化
これまでは新しいチャネル追加なるとIFを追加してたので工数が大きかった
新環境はオープンAPIに統合
対策２：マイクロサービス化
これまではサイロ化してて、他IFとの重複があった
新環境でマイクロサービス化して保守性とアジリティ向上を実現
対策３：パブリッククラウド活用
用途に合ったパブリッククラウドを用意
４．組織
課題は２点
・各レイヤーの情報の見える化
・WF準拠の社内ルール、意思決定が遅い
対策
・DevOpsの活用
・社内ルールを改定、新ビジネスマネジメントプロセス
組織の対策１： DevOpsの活用
進捗管理はJira
情報共有はconflueence
コミュニケーションはMattermost
ビジネス、組織運営との関連付けは付箋アナログ
組織対策２： 特区化
プロジェクトでなくプロダクトライフサイクルで管理
ここまでで下地作りできた
→ ２０１９年７月からSAFe本格始動
まとめ
100名超規模の大規模アジャイルをSAFeでやってる
SAFeの立ち上げには従来のやりかたを意識的に変える必要がある
人が一番大事。人の集め方、意識の変え方、働き方、チームビルディング、すべて人間中心
質疑応答
Q1.
SAFeをやるのに３アジャイルコーチに入ってもらったとあったが、コーチに何をやってもらったか？
A1.
スクラムマスター自身どうふるまえばいいのか定着してない。
スクラムマスターのそばで、イベントに観察者のように張り付いて見てもらい、改善の指示をする
最初の１スプリントはべったり入ってもらう
２～３スプリントは最初の計画会議か最後のレトロスペクティブだけ参加するようにする
---
Q2.
スクラムチームの見定め期間後の、「ダメだね」となる判断基準はあるか？
A2.
明文化したものはない
プロダクトオーナー的なトップの人が判断する形をとってる
アウトプットとかチームの雰囲気とかを勘案して全体最適化をしている
---
Q3.
大規模アジャイルの方法論はいくつかあるが、なぜSAFeを選んだか
A3.
LeSSとかScrum@Scaleとかでも大規模なものは作れる
でも、縦に組織として伸ばしてくのはSAFeしかなかった
組織を変えたいというのを目指していくのでSAFeを採用した
Fun! Done! Learn! 〜 チームの楽しさと学びを成果に結びつく新しい振り返りを体験しましょう！
セッション： https://www.agilejapan.org/session.html#e-14
スライド： https://docs.google.com/presentation/d/1PzKrGMIahCkeAqddv8g14oxQEzpI5HPd5zrTv0DLspw/edit#slide=id.p
(クリックするとスライドに飛びます)
１．説明
Fun! Done! Learn!がどうやって生まれたか？
沖縄のイベントで。
スクラムやりたくないチームにどうアジャイルコーチが関わるか？
どんな工夫すればチーム自らチームの状態を知って行動がおこせるのか？
成果重視でかんばってるけどこのままもつのか
うちのチームは成長してるのか
もっとたのしくやりたい
チームが自己診断できたらおもしろいかもね
→ fun/done/learnを生み出した
とにかく楽しい絵をかいてやってた
funの要素がないとやってられない
２．やる
10人～15人でチームを作って、今日のアジャイルジャパンに参加して思ったことに対してやってみる。
実際にやってみた。
やってみた感想：
スプリントレトロスペクティブはいつもKPTを使ってるけど、マンネリ化したら、Fun! Done! Learn!を一度試してみるのもありかもしれない。
KPTだと↓の要素が確かにあるなぁ、と思いました。
・課題の改善という意識がすりこまれているのか、”よくなかったこと”にフォーカスして話しがちな傾向があるのは確かに。
・振り返りをする時間をしても「できなかったこと」にばかり目が向いてネガティブな印象になりがち
ネットワーキング 併設：平鍋師匠のアジャイルあるある相談会
セッション： https://www.agilejapan.org/session.html#nw-1
参加者のみなさんと軽食をまじえての歓談タイムです。
軽食も十分な量があって、翌日は人間ドックなのに食べ過ぎてしまった・・・
感想
上質なセッションがとても多くて有意義でした。
こーゆうオープンな場で生の現場の事例などを知れるのは大変ありがたい。
自分の現場にも試せそうなヒントや気づきがありました。
有料だけど、また会社のお金で来年も参加したいと思うのでした。
- 関連記事
-
- 「エンジニアのためのコーチング体験型勉強会Vol.1」に参加しました
- 「Agile Japan 2019」に参加しました
- 「Developers Summit 2019 Summer」に行ってきました
