Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agile Japan 2019 開発側ビジネス側の先へ/Agile Japan 2019 Beyond the business people and developer

Ikuo Suyama
September 04, 2019

Agile Japan 2019 開発側ビジネス側の先へ/Agile Japan 2019 Beyond the business people and developer

※ AgileJapan2019再演
AgileJapan2019渋谷サテライトでお話させていただいた内容です。

Ikuo Suyama

September 04, 2019
Tweet

More Decks by Ikuo Suyama

Other Decks in Technology

Transcript

  1. ”開発側”
    ”ビジネス側”
    の先へ
    〜アジャイルで超えた3つの壁〜



    View Slide

  2. 陶⼭ 育男
    Ikuo Suyama
    @martin_lover_se
    ⾒習い “Agile Developer”
    @CyberAgent AI tech Studio
    New!

    View Slide

  3. Mob Mentality Show
    with Chris, Austin, 川⼝さん, 永⽥さん, 吉
    ⽥さん
    omoiyari.fm#48
    with 横道さん, 三浦さん, 川
    ⼝さん
    XP祭り2019
    Coming soon!!
    「全部⾒せますモブプロジャー
    ニー︕ 」
    ⾒てね︕

    View Slide

  4. 今⽇お話すること
    とあるB2Bプロダクトでのアジャイル実践
    • “開発側” “ビジネス側” が分断された状態から、ア
    ジャイルなチームになっていった過程
    • 変化の過程で現れた「3つの壁」
    • 壁に直⾯した時考えたこと、実践したこと

    View Slide

  5. 「ビジネス側の⼈と開発者は、
    プロジェクトを通して
    ⽇々⼀緒に働かなければなりません。」
    ーアジャイル宣⾔の背後にある原則

    View Slide

  6. 半年前のLODEOの開発
    「社内受託開発」
    • ”ビジネス側” からの要件通りにつくる
    • 進捗は 定例会議 で報告する
    • リリースした機能が使われないこともある

    View Slide

  7. • なぜ必要なのか︖
    • 価値はあるのか︖
    • いつできるのか︖
    • つくったものは正しいのか︖
    半年前のLODEOの開発
    「社内受託開発」
    何もわからない

    View Slide

  8. 0.「変化」と向き合う
    ”ビジネス側” との間に現れた
    「3つの壁」
    第⼀の壁︓<信頼の壁>
    コミュニケーションの分断
    第⼆の壁︓<透明性の壁>
    情報の分断
    第三の壁︓<ミッションの壁>
    KPIの分断

    View Slide

  9. 何を考え、どう⾏動して
    「開発側」「ビジネス側」の壁を
    乗り越えたのか

    View Slide

  10. 0.
    変化と向き合う

    View Slide

  11. ⼆年前…

    View Slide

  12. ぼく︓ 「スクラムやりましょう︕」

    View Slide

  13. ぼく︓「スプリントプランニングやって
    デイリースクラムやってスプリントレ
    ビューやってレトロスペクティブをやり
    ます。スクラムマスターはプロセスに責
    任持ってプロダクトオーナーがビジネス
    に責任持って開発チームはスプリントに
    コミットします。プロダクトバックログ
    は優先順位付けされていてスプリントプ
    ランニングでスプリントバックログにア
    イテムを積んでタスクボードで管理しま
    す。受け⼊れ条件がとても⼤事です。

    View Slide

  14. メンバー︓「割り込みが多くて計画なんてできない︕」
    ぼく︓「割り込みに対応できるだけのスラックをもたせ
    ましょう。“昨⽇の天気”というものがありまし
    て... なので⼤丈夫です(キリッ」
    メンバー︓「スプリント計画が⻑すぎて無駄︕」
    ぼく︓「プランニングポーカーを使いましょう。
    なれてくれば時間がかからなくなります。
    ... なので⼤丈夫です(キリッ」
    ぼく︓「そうそうスプリントレビューでは
    どーのこーの...」
    ぼく︓「POはどーのこーの...」
    ぼく︓「もう⼤丈夫です︕
    あとはよろしくおねがいします︕」

    View Slide

  15. それから
    約⼀年の⽉⽇が流れ...
    (育休をとってました)

    View Slide

  16. 復帰後…
    ぼく︓「あれスクラムやってないんですか︖」
    ボス︓「元のやり⽅でいこうってなった」
    ぼく︓「」

    View Slide

  17. なぜスクラムは
    受け⼊れられなかったのか︖

    View Slide

  18. ⼀度にもたらした 「変化」 が
    チームのキャパシティを超えていた

    View Slide

  19. Tips.
    「変化のキャパ」を⾒積もる

    View Slide

  20. 「変化のキャパシティ」
    単位期間あたりでやり⽅の変更を許容できる量
    チームのキャパ < 変化の⼤きさ
    を無理に実⾏しようとすると、望まない結果に..

    View Slide

  21. 変化のキャパシティを⾒積もる
    • チームで起こっていることを観察する
    • 否定的な意⾒があったか︖
    • 意⾒を⾔ってない⼈は誰か︖
    • 顔⾊はどうか︖
    • Fist to Five してみる
    • ⼀番低い数字を出す⼈は︖
    • ⼀番変化に敏感な⼈はだれか︖
    チームのキャパは平均では決まらない

    View Slide

  22. チームに変化をもたらすには
    • キャパを増やすのは時間がかかる
    • 起こす変化を分割して⼩さくする
    • 例︓
    • 今までのやり⽅と並⾏で始める
    • 例︓ガントチャート + カンバン
    • スクラムイベントを1つずつ実装する
    変化のバッチサイズ
    (⼀度に起こす変化の量)を下げる

    View Slide

  23. “⼤きな変化より、⼩さな
    変化のほうが抵抗が少ない。
    しかしたくさんの⼩さな変
    化が、最終的には⼤きな転
    換を⽣み出すのだ“
    ーFearless Change アジャイルに効く
    アイデアを組織に広めるための48のパターン

    View Slide

  24. 復帰から半年…
    「モブプロ︕」
    「カンバン︕」
    「ノーエスティメート︕︕」
    「変化のキャパ」の意識で
    ”開発側” のアジャイル導⼊が
    うまく回ってきた

    View Slide

  25. “ビジネス側” の⼈と⼀緒に働きたい

    View Slide

  26. 第⼀の壁︓
    <信頼の壁>

    View Slide

  27. 信頼の壁︓
    コミュニケーションの分断
    • 暗黙の了解
    • 「エンジニアに直接依頼しない」
    • 固定概念
    • 「ビジネスは開発プラクティスをやってくれない」
    コミュニケーションがない=信頼がない

    View Slide

  28. ”ビジネス側” との
    コミュニケーションを増やしたい

    View Slide

  29. 「⼩さな変化」を「継続的に」
    起こすしくみが必要

    View Slide

  30. Tips.
    「アクションアイテムつき」
    ふりかえり

    View Slide

  31. “1. 場を設定する
    2. データを収集する
    3. アイディアを出す
    4. 何をすべきかを決定する
    5. レトロスペクティブを終了する
    ...この構成は
    有⽤性が検証されたプロセスだ”
    ーアジャイルレトロスペクティブズ
    LODEOではとくに 1. と 4. を重視

    View Slide

  32. アナログゲームで ” 場を設定”
    発⾔の敷居を下げる
    参加を促す

    View Slide

  33. シビアな意⾒と
    カジュアルな意⾒が混在
    楽しかったこと/できたことにも向き合う

    View Slide

  34. 「次の週やること」を
    必ず⼀つ決める
    他はリストには積まない

    View Slide

  35. 「ふりかえり」=
    コミュニケーションの⼟台
    • プロダクトで起こっていることを定期的に話しあう
    • お互いに困っていること/興味があることを知る
    • ギャップを埋めるためにできることを少しずつ試す
    お互いのことを知り、少しずつ信頼が⽣まれる

    View Slide

  36. ふりかえりにより
    コミュニケーションが増え、
    どんどんチャレンジがしたくなる

    View Slide

  37. ... 時々、「失敗」もする

    View Slide

  38. 「失敗」に対する恐怖
    「失敗したくない」
    「会社が/上司が/チームが 失敗を許さない」
    「競合がいて、失敗している暇なんてない」
    ⾔葉のイメージが悪すぎる

    View Slide

  39. Tips.
    「失敗」をイメチェンする

    View Slide

  40. “成功や失敗ではなく、
    学んだことを祝おう。”
    なぜ失敗が必要なのか
    ーManaging for Happiness,
    「Celebration Grid 」

    View Slide

  41. 失敗がしたいわけじゃない
    「うまくいくかどうかわからないとき、
    最も学びの効率が⾼くなる」

    「やったことがないことは、
    そこそこ失敗する可能性がある」
    新しいことを始めると、
    「失敗」は避けられない

    View Slide

  42. 「失敗」の意味を揃える
    「失敗」から連想されるもの
    • リリース時の事故、本番バグ
    • 情報漏えい
    • 契約で決まっている納期遅延
    • etcetc...
    取り返しがつかないやつ

    View Slide

  43. 「失敗」の意味を揃える
    僕が思う「失敗」
    • CI環境でビルドがコケた
    • モブプロの交代時間を⻑くしたらすごい疲れた
    • タスクの粒度を1/2⽇以下で制限=>誰もやらなかった
    • etcetc...
    ごめんなさいテヘペロ

    View Slide

  44. 「失敗」の閾値を下げる
    • ⾃分から率先して「実験」する
    • 「チョット試してみましょう︕」
    • 「わからないんで実験してみましょう︕」
    • 期待値をコントロールする
    • 「いいアイディアだと思うんですけど、やったこ
    とないのでうまくいかないかも...」
    • 失敗した時素直に認め、すぐ謝る︕
    • 「ごめんなさい、うまくいきませんでした」
    • 「でも、これはうまくないことがわかりました」
    笑顔で︕︕

    View Slide

  45. 「失敗できる」

    「アクションアイテムつきふりかえり」
    = 機能するふりかえり
    「信頼の壁」を超えた︕

    View Slide

  46. 第⼆の壁︓
    <透明性の壁>

    View Slide

  47. 透明性の壁︓
    情報の分断
    • どんな案件が動いているのか
    • どんな営業活動をしているか
    • 開発は何を作っているのか
    • 頼んだ仕事はいつ終わるのか
    何もわからない︕

    View Slide

  48. 対策は知ってる。
    カンバンをやればよさそう。
    だけど...

    View Slide

  49. キャパが⾜りなそう...

    View Slide

  50. Tips.
    「信頼貯⾦」
    を使う

    View Slide

  51. “信頼貯⾦とは
    あなたの周囲の⼈が
    持っている
    あなたに対する信頼の蓄積”
    ーアジャイル開発者の習慣−acts_as_agile
    / 最終回 信頼貯⾦を増やす

    View Slide

  52. キャパが⾜りない
    それでも変化が必要な時
    境界を越境して⼈を巻き込みたい
    ⼤きな変化を伴う新しいプロセスを導⼊したい
    「信頼貯⾦」と相談して、⼀歩踏み出してみる

    View Slide

  53. 判断基準︓
    信頼残⾼はあるか︖
    • 話を聞くに値する成果を残したか︖
    • 正直か︖
    • 約束を守っているか︖
    • ⾃分もチームメンバを信頼しているか︖
    • 弱さや⾜りない能⼒を開⽰できるか︖
    • 失敗しても関係は壊れないか︖
    ⾜りないキャパを残⾼で補う

    View Slide

  54. みんながやってることが共通認識に︕
    踏み出した先で⾒つけたもの
    ビジネス/開発統⼀カンバン

    View Slide

  55. 信頼貯⾦で
    ⼀歩踏み出して、
    カンバンで
    「透明性の壁」を超えた︕

    View Slide

  56. …おや︖

    View Slide

  57. View Slide

  58. 開発って、これだけしかないんだ…

    View Slide

  59. これまでの⾃分の関⼼︓
    「開発チームのプロセスを
    いかに改善するか︖」

    View Slide

  60. 突きつけられた現実︓
    「開発チームのことだけ⾒ていても
    インパクトは殆ど無い」

    View Slide

  61. 第三の壁︓
    <ミッションの壁>

    View Slide

  62. ミッションの壁︓
    KPIの分断
    • ビジネス側のKPI
    • 受注件数、売上、粗利
    • 開発のKPI
    • スループット、リードタイム
    まるで関わりがない︕

    View Slide

  63. 流れていく案件…

    View Slide

  64. 関連のない開発…

    View Slide

  65. 使われない機能…

    View Slide

  66. 何も変わってない
    • なぜ必要なのか︖
    • 価値はあるのか︖
    • いつできるのか︖
    • 作ったものは正しいのか︖
    ー が、「⾒える化」された

    View Slide

  67. ⼤丈夫、超えられる。
    信頼があって、課題が明確

    View Slide

  68. 持てるアジャイルを総動員して
    壁を超えに⾏く︕

    View Slide

  69. なぜ必要なのか︖
    • 何が問題/課題なのか︖
    • いまはどうしているのか︖
    • どう解決すればよさそうか︖
    • どれから/どんな順番ですすめるべきか︖
    「なんにもわかってなかった…」
    ユーザーストーリーマッピング
    つくるものへの共通認識の醸成

    View Slide

  70. 価値はあるのか︖
    • そのPBIにどんな価値があるのか︖
    • なぜその順番でつくるのか︖
    • CD3(Cost of Delay Divided By Duration)による優先
    順位付け
    • バックログポートフォリオ
    • 機能開発 N%, 負債対応 M%, …
    バックログリファインメント
    価値の基準を合わせる

    View Slide

  71. いつできるのか︖
    機能する朝会(昼会)
    • 全員参加できるよう「昼会」
    • カンバンが情報ラジエーターに
    • 今何をしているのか︖
    • 困っていることはないか︖
    • 必要に応じて「分科会」
    • 納期駆動、案件毎などのコミュニケーション
    毎⽇活動を同期する

    View Slide

  72. いつできるのか︖
    プランニング
    • カンバンをタイムボックス化
    • 少し先の作戦を⽴てやすく
    • ⾜りない/新しい情報はあるか︖
    • 今週は何ができる/何をしてほしい︖
    • どうやって今週のゴールを達成する︖
    今週できることを決める

    View Slide

  73. つくったものは正しいのか︖
    レビュー
    • 作り終えたらすぐフィードバックをもらう
    • ビジネス、デザイナー、クライアント…
    • 作ったものは欲しかったものか︖
    • 課題を解決できそうか︖
    • ビジネスで使えるものか︖
    • もっとよくできるか︖
    つくったものを確かめる

    View Slide

  74. つくったものは正しいのか︖
    ユーザーテスト
    • 実際に使ってもらうと、何が起こるか︖
    • 数字だけではない、リアルなフィードバック
    • 作ったものの「リアルさ」を感じる
    • ⾃信と、プロダクトへの愛着
    つくったものを確かめる

    View Slide

  75. 出てくる課題をひとつひとつ、
    着実に対応してきた

    View Slide

  76. プロダクトの活動を通じて、
    僕たちはチームになった。
    「ミッションの壁」を超えた︕

    View Slide

  77. 「ミッションの壁」の先は…︖

    View Slide

  78. 社会から必要とされて
    ちゃんと「儲かる」...!!

    View Slide

  79. … に向かって、
    今⽇も挑戦中︕

    View Slide

  80. まとめ
    第⼀の壁︓<信頼の壁>
    「失敗できる」「ふりかえり」で超えた
    第⼆の壁︓<透明性の壁>
    「信頼貯⾦」で「カンバン」をやって超えた
    第三の壁︓<ミッションの壁>
    アジャイルで超えていく︕
    0.「変化」と向き合う
    「変化のキャパ」を⾒積もる

    View Slide

  81. まだまだ旅は始まったばかり。
    アジャイルの旅を続けましょう︕

    View Slide

  82. ご清聴
    ありがとうございました︕

    View Slide