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

User Story Mapping - Scrum Niigata

User Story Mapping - Scrum Niigata

スクラムフェス新潟2023

アジャイルテスター視点で、ユーザーストーリーマッピングを活用した効果的なプロダクト開発
https://confengine.com/conferences/scrum-fest-niigata-2023/proposal/18346

Yasunobu Kawaguchi

May 20, 2023
Tweet

More Decks by Yasunobu Kawaguchi

Other Decks in Technology

Transcript

  1. ユーザーストーリー
    マッピング
    脱・利用者不在のアジャイル開発

    View full-size slide

  2. 川口 恭伸
    かわぐち やすのぶ
    Twitter: @kawaguti
    アギレルゴコンサルティング株式会社 シニアアジャイルコーチ
    株式会社ホロラボ シニアアジャイルコーチ
    一般社団法人スクラムギャザリング東京実行委員会 代表理事
    一般社団法人 DevOpsDays Tokyo 代表理事

    View full-size slide

  3. なぜアジャイルなのか?

    View full-size slide

  4. https://www.youtube.com/watch?v=nHIlMlpDWz
    g

    View full-size slide

  5. VUCAという略語を聞いたことがあると思います。
    私たちの世界が、
    変動性(Volatile)、
    不確実性(Uncertain)、
    複雑性(Complex)、
    曖昧性(Ambiguous)
    を持つようになってきている、ということです。

    View full-size slide

  6. いまVUCAだけでなく、変化の性質そのものが変
    化しています。私はこのことを2020年に初めて
    知りました。そして、なぜ物事がこれほどまでに難
    解なのか、その理解を深める上で、驚くべき発見
    となりました。以前は、大きな変化を経ても、その
    後しばらくは安定した状態が続くというものでし
    た。

    View full-size slide

  7. 私たちの人生、私たちの世界
    のますます多くの部分が、
    この3つの変化、すなわち
    永続的、
    遍在的、
    そして最も困難な
    指数関数的
    な変化にさらされています。

    View full-size slide

  8. 変化は休むことなくずっと続く
    永続的

    View full-size slide

  9. 変化はあらゆる場所で起こる
    偏在的

    View full-size slide

  10. 変化は拡大していく
    指数関数的

    View full-size slide

  11. 変革期 変革期 変化 変化 変化
    安定期
    拡大期
    安定期
    拡大期
    安定期
    拡大期
    ソフトウェアは変化した
    数年ごとのメジャーバージョンアップ
    大規模な先行マーケティング
    ライセンス販売モデル
    継続的な変更とリリース
    事前告知なし・発表日に提供開始
    従量制・サブスクリプション

    View full-size slide

  12. 変革期 変革期 変化 変化 変化
    安定期
    拡大期
    安定期
    拡大期
    安定期
    拡大期
    https://gazoo.com/feature/gazoo-museum/car-history/15/01/16_1/
    https://www.honda.co.jp/50years-history/
    challenge/1981city/page02.html
    https://www.youtube.com/watch?v=Hl1zEzVUV7w
    https://logmi.jp/tech/articles/327160
    ハードウェアも変化していく

    View full-size slide

  13. 1986
    変革期から学び、継続的な変化に備える
    変革期 変革期 変化 変化 変化
    安定期
    拡大期 拡大期
    安定期
    拡大期
    安定期
    2005
    https://logmi.jp/tech/articles/327160
    2022
    https://speakerdeck.com/kawaguti/roots-of-scrum-2005
    https://hbr.org/1986/01/the-new-
    new-product-development-game

    View full-size slide

  14. 変化を代謝する (取り入れて自らも変化する)
    https://www.youtube.com/watch?v=nHIlMlpDWzg

    View full-size slide

  15. https://www.youtube.com/watch?v=nHIlMlpDWzg
    変化は外から、障害の形で現れる。

    View full-size slide

  16. 要件定義でありがちな問題

    View full-size slide

  17. 27
    By Henrik Kniberg

    View full-size slide

  18. アジャイルとはなにか?

    View full-size slide

  19. 時は2001年
    真冬のスキーリゾートに集まった17人。
    軽量で迅速なソフトウェア開発を行っていた
    彼らは、共通の価値観を語り合い、
    マニフェストにまとめるに至った。
    4つの価値(バリュー)と
    12の原則(プラクティス)。
    そして、それを表現する言葉を採択した。
    それが「アジャイル」。

    View full-size slide

  20. 背後にある12の原則
    1. 顧客満足を最優先し、価値のあるソフトウェアを
    早く継続的に提供します。
    2. 要求の変更はたとえ開発の後期であっても歓迎し
    ます。変化を味方につけることによって、お客様
    の競争力を引き上げます。
    3. 動くソフトウェアを、2-3週間から2-3ヶ月とい
    うできるだけ短い時間間隔でリリースします。
    4. ビジネス側の人と開発者は、プロジェクトを通し
    て日々一緒に働かなければなりません。

    View full-size slide

  21. 背後にある12の原則
    5. 意欲に満ちた人々を集めてプロジェクトを構成し
    ます。環境と支援を与え仕事が無事終わるまで彼
    らを信頼します。
    6. 情報を伝えるもっとも効率的で効果的な方法は
    フェイス・トゥ・フェイスで話をすることです。
    7. 動くソフトウェアこそが進捗の最も重要な尺度で
    す。
    8. アジャイル・プロセスは持続可能な開発を促進しま
    す。一定のペースを継続的に維持できるようにし
    なければなりません。

    View full-size slide

  22. 背後にある12の原則
    9. 技術的卓越性と優れた設計に対する不断の注意が
    機敏さを高めます。
    10.シンプルさ(ムダなく作れる量を最大限にするこ
    と)が本質です。
    11.最良のアーキテクチャ・要求・設計は、自己組織
    的なチームから生み出されます。
    12.チームがもっと効率を高めることができるかを定
    期的に振り返り、それに基づいて自分たちのやり
    方を最適に調整します。

    View full-size slide

  23. 自己組織的な
    チーム

    View full-size slide

  24. 動く
    ソフトウェア
    できるだけ
    短い時間間隔で
    リリース

    View full-size slide

  25. 持続可能な
    開発
    自分たちの
    やり方を
    最適に調整
    意欲に満ちた
    人々
    優れた設計
    フェイストゥ
    フェイスで
    話をする

    View full-size slide

  26. 価値のある
    ソフトウェア
    競争力を
    引き上げ
    変化を味方
    につける

    View full-size slide

  27. ビジネス側の人と
    開発者は日々一緒に…
    シンプルさ…

    View full-size slide

  28. ビジネス側の人と
    開発者は日々一緒に…
    シンプルさ…

    View full-size slide

  29. できるようになるには?

    View full-size slide

  30. 教育心理学概論 新訂 (放送大学教材) [全集叢書]
    三宅 芳雄(著)、三宅 なほみ(著)
    経験から固めた「経験則」
    (素朴理論)
    学校で教える原理原則
    科学的概念
    自分で考えて言葉にすると
    はじめてつながる
    より適用範囲の広い、
    抽象度の高い知識

    View full-size slide

  31. 教育心理学概論 新訂 (放送大学教材) [全集叢書]
    三宅 芳雄(著)、三宅 なほみ(著)
    経験から固めた「経験則」
    (素朴理論)
    学校で教える原理原則
    科学的概念
    自分で考えて言葉にすると
    はじめてつながる
    より適用範囲の広い、
    抽象度の高い知識
    わかりやすい説明が生む
    バブル型理解

    View full-size slide

  32. 理解にはレベルがある
    https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1002_2
    Constructive Interaction and the Iterative Process of Understanding
    (建設的相互作用と
    理解の反復プロセス)
    三宅なほみ 1986
    0. ミシンは縫うものだ
    1. 上糸と下糸が結びつく
    2. 下糸は上糸の輪をまたぐ
    3. 輪がボビンの周りを回る
    4. ボビンの構造は空間を与える
    5. ホルダはカラーに固定される

    View full-size slide

  33. 下向きの批判は、評価的な批判とい
    うよりは、「不満」と考えたほうが
    いいかもしれません。批判する側が
    提案されたメカニズムを理解できな
    いということなのでしょう。しかし、
    重要なのは、これらの批判によって、
    より理解力のある相手が、メカニズ
    ムを探し続けなければならなくなっ
    たということです。
    「わからない」というフィードバックが重要
    https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1002_2
    Constructive Interaction and the Iterative Process of Understanding
    (建設的相互作用と
    理解の反復プロセス)
    三宅なほみ 1986

    View full-size slide

  34. 教育心理学概論 新訂 (放送大学教材) [全集叢書]
    三宅 芳雄(著)、三宅 なほみ(著)
    経験から固めた「経験則」
    (素朴理論)
    学校で教える原理原則
    科学的概念
    自分で考えて言葉にすると
    はじめてつながる
    より適用範囲の広い、
    抽象度の高い知識
    わかりやすい説明が生む
    バブル型理解
    ポプテピピック
    (C) 大川ぶくぶ, 竹書房

    View full-size slide

  35. ところで、私たちが欲しい理解とは
    どういうものだろうか?
    0. アジャイルとは?
    1. チームで行う
    2. イベントがある
    3. 繰り返して改善する
    4. …
    5. …

    View full-size slide

  36. 「アジャイルにおける要件定義とは
    こうだ」という情報をもらっても
    たぶん、ぜんぜんできるように
    ならない気がします。

    View full-size slide

  37. 自分勝手ではない本物のチームを作
    り上げる。それこそバルセロナのよ
    うに5、6人の選手が一度に連動し
    て、まるでひとりの選手のように機
    能するチームだ。それには多くのこ
    とが必要だった。
    イビチャ・オシム

    View full-size slide

  38. 開発プロセスとアジャイル

    View full-size slide

  39. 従来の「プロジェクト管理」
    よい企画をたて、
    適切な人を
    アサインして、
    進捗を管理し、
    不具合が少ない
    ものを作って納品

    View full-size slide

  40. 企画フェーズ
    予算取り
    人繰り
    要件定義
    詳細設計
    コーディング
    移行フェーズ
    リリース
    受入・検収
    システムテスト
    結合テスト
    単体テスト

    View full-size slide

  41. 作る人
    決める人

    View full-size slide

  42. 資料を作る人 会議する人 ものを作る人

    View full-size slide

  43. デジタル革命

    View full-size slide

  44. 動かしながら
    直していける
    柔軟で堅牢な
    ソフトウェア
    アーキテクチャ

    View full-size slide

  45. 自己組織的な
    チーム
    考えながら
    作れる

    View full-size slide

  46. 企画フェーズ
    予算取り
    人繰り
    要件定義
    詳細設計
    コーディング
    移行フェーズ
    リリース
    受入・検収
    システムテスト
    結合テスト
    単体テスト

    View full-size slide

  47. 企画フェーズ
    予算取り
    人繰り
    要件定義
    詳細設計
    コーディング
    移行フェーズ
    リリース
    受入・検収
    システムテスト
    結合テスト
    単体テスト
    固定

    View full-size slide

  48. 企画フェーズ
    予算取り
    人繰り
    要件定義
    詳細設計
    コーディング
    移行フェーズ
    リリース
    受入・検収
    システムテスト
    結合テスト
    単体テスト

    View full-size slide

  49. 企画フェーズ
    予算取り
    人繰り
    要件定義
    詳細設計
    コーディング
    移行フェーズ
    リリース
    受入・検収
    システムテスト
    結合テスト
    単体テスト
    常時

    View full-size slide

  50. 企画フェーズ
    予算取り
    人繰り
    要件定義
    詳細設計
    コーディング
    移行フェーズ
    リリース
    受入・検収
    システムテスト
    結合テスト
    単体テスト

    View full-size slide

  51. 企画フェーズ
    予算取り
    人繰り
    要件定義
    詳細設計
    コーディング
    移行フェーズ
    リリース
    受入・検収
    システムテスト
    結合テスト
    単体テスト
    「考えて、作って、確認する」
    …だけの実にシンプルなプロセス

    View full-size slide

  52. そして要件を細かくすれば…

    View full-size slide

  53. そして要件を細かくすれば…
    短く何度も繰り返せる

    View full-size slide

  54. そして要件を細かくすれば…
    短く何度も繰り返せる
    すばやく作って、
    利用者に使ってもらえれば、
    間違いに気づくチャンスが増える

    View full-size slide

  55. アジャイルな要件定義の例

    View full-size slide

  56. ある日の入社面接にて。
    面接官「システム開発に
    重要なことは
    何だと思いますか?」
    わたし「作る前にちゃんと
    要件を定義すること
    だと思います。」

    View full-size slide

  57. 後日の立ち話
    あのとき面接官だった部長
    「あれは100点回答だったね」
    わたし「てへへ」
    しかし、要件定義のなんたるかは
    全然わかっていなかったのでした。

    View full-size slide

  58. また別のある日。
    わたし「要件定義って、
    どうやるんですか?」
    優しい先輩
    「俺もちゃんと教わったこと
    ないんだよね。
    すでにある要件定義書を読んで、
    どういうものかを学んだんだよ。」

    View full-size slide

  59. 作る人
    決める人
    要件定義(書)が求められがちな状況

    View full-size slide

  60. 作る人の都合
    どうして(Why)、
    なにを(What)、
    どうやって(How)
    作るのか?
    決めてくれないと
    仕事にならないな。

    View full-size slide

  61. 作る人を
    雇っているのだから
    ちゃんと
    要件を渡して、
    稼働してもらわない
    といけないよ。
    決める人の都合

    View full-size slide

  62. 作る人
    決める人
    要件を定義して
    仕様にまとめて
    渡す。
    出来上がったら
    検収する。

    View full-size slide

  63. • どういうときに要件定義がうまくでき
    たといえるのだろうか?
    • 利用者の行動を理解するにはどのよう
    な手段があるだろうか?
    • 作る都合を考えた進め方はどうやった
    らできるだろう?
    • 長期的にROIが高いモノづくりを続け
    たい。どうやったらできるだろう?

    View full-size slide

  64. 2005年に登場したRuby on Railsは、デー
    タベースのテーブル作成、マイグレーション、
    ビューの足場作りなどの革新的な機能により、
    アプリケーションの迅速な開発を可能にし、
    Webアプリケーション開発に大きな影響を
    与えた。Ruby on Rails の他の Web フ
    レームワークへの影響は今日でも明らかで、
    Python の Django、Perl の Catalyst、
    PHP の Laravel、CakePHP、Yii、
    Groovy の Grails、Elixir の Phoenix、
    Scala の Play、および Node.js の
    Sails.js など、他の言語の多くのフレーム
    ワークがそのアイデアを借りている。
    Ruby on Railsとは…

    View full-size slide

  65. Ruby on Railsの
    内容に深入りする必要は
    ありませんが、
    本書に書かれている
    アジャイル開発の
    進め方の例が
    参考になりますので、
    紹介させていただきます。

    View full-size slide

  66. Incremental Development
    We’ll be developing this application incrementally.
    We won’t attempt to specify everything before we
    start coding. Instead, we’ll work out enough of a
    specification to let us start and then immediately
    create some functionality. We’ll try ideas, gather
    feedback, and continue with another cycle of
    minidesign and development.
    インクリメンタル開発
    このアプリケーションは、段階的に開発していきま
    す。コーディングを開始する前にすべてを指定
    (Specify)しようとはしません。そのかわり、いく
    つかの機能をすぐに作り始められるように、十分な
    仕様を決めておきます。アイデアを試し、フィード
    バックを集め、ミニ設計と開発のサイクルを繰り返
    します。

    View full-size slide

  67. このスタイルのコーディングは、常に適用できるわけ
    ではありません。アプリケーションのユーザーと密接
    な協力関係を築く必要があり、フィードバックを得な
    がら進めていきたいからです。間違うこともあるかも
    しれませんし、クライアントが最初はあるものを要求
    していたのに、後になって違うものを要求してくるこ
    ともあるかもしれません。理由は何でもいいんです。
    間違いに早く気付けば、その分修正費用も安く済む。
    このように、開発スタイルには変化がつきものです。
    This style of coding isn’t always applicable. It requires close
    cooperation with the application’s users, because we want to
    gather feedback as we go along. We might make mistakes, or the
    client might ask for one thing at first and later want something
    different. It doesn’t matter what the reason is. The earlier we
    discover we’ve made a mistake, the less expensive it’ll be to fix that
    mistake. All in all, with this style of development, there’s a lot of
    change as we go along.

    View full-size slide

  68. そのため、私たちが考えを変えたときにペナルティを
    受けないようなツールセットを使う必要があります。
    データベースのテーブルに新しいカラムを追加したり、
    ページ間のナビゲーションを変更したりする必要があ
    ると判断したら、コーディングや設定の手間をかけず
    にそれを実行できるようにする必要があります。この
    ように、Ruby on Railsは変化への対応に優れていま
    す。理想的なアジャイル・プログラミング環境なので
    す。
    Because of this, we need to use a toolset that doesn’t penalize us
    for changing our minds. If we decide we need to add a new column
    to a database table or change the navigation among pages, we need
    to be able to get in there and do it without a bunch of coding or
    configuration hassle. As you’ll see, Ruby on Rails shines when it
    comes to dealing with change. It’s an ideal agile programming
    environment.

    View full-size slide

  69. Along the way, we’ll be building and maintaining a corpus of tests.
    These tests will ensure that the application is always doing what
    we intend to do. Not only does Rails enable the creation of such
    tests, but it even provides you with an initial set of tests each time
    you define a new controller.
    その過程で、私たちはテストのコーパス(訳注:例文
    の集合)を構築し、維持することになります。これ
    らのテストは、アプリケーションが常に私たちの
    意図したとおりに動作することを保証するもので
    す。Railsはこのようなテストを作成できるだけで
    なく、新しいコントローラを定義するたびに、初
    期テストのセットを提供してくれます。

    View full-size slide

  70. Page Flow
    We always like to have an idea of the main pages in our
    applications and to understand roughly how users navigate among
    them. This early in the development, these page flows are likely to
    be incomplete, but they still help us focus on what needs doing and
    know how actions are sequenced.
    ページフロー
    私たちは常に、アプリケーションの主要なページ
    についてのアイデアを持ち、ユーザーがその間を
    どのように移動するのかをおおまかに理解したい
    と考えています。開発の初期段階では、これらの
    ページフローは不完全である可能性が高いですが、
    それでも、何をする必要があるかに焦点を当て、
    アクションがどのように連続するかを知るのに役
    立ちます。

    View full-size slide

  71. Some folks like to use Photoshop, Word, or (shudder) HTML to
    mock up web application page flows. We like using a pencil and
    paper. It’s quicker, and the customer gets to play too, grabbing the
    pencil and scribbling alterations right on the paper.
    The first sketch of the buyer flow is shown in the following figure.
    PhotoshopやWord、あるいはHTMLを使って、
    Webアプリケーションのページフローをモック
    アップするのが好きな人もいます。私たちは、鉛
    筆と紙を使うのが好きです。そのほうが手っ取り
    早いですし、お客さまも鉛筆を手に取って紙に書
    き込むことができます。買い手のフローの最初の
    スケッチを次の図に示します。

    View full-size slide

  72. 買い物かごのサマリーを
    表示する必要がある?
    (1個ずつが
    いいなあ)
    再計算
    お会計
    買い物を続ける
    製品を選択
    支払い
    カタログページ 買い物かごページ

    View full-size slide

  73. It’s pretty traditional. The buyer sees a catalog page, from which he
    selects one product at a time. Each product selected gets added to
    the cart, and the cart is displayed after each selection. The buyer
    can continue shopping using the catalog pages or check out and
    buy the contents of the cart. During checkout, we capture contact
    and payment details and then display a receipt page. We don’t yet
    know how we’re going to handle payment, so those details are
    fairly vague in the flow.
    極めて伝統的な方法です。買い手はカタログのページを
    見て、そこから一度に1つの製品を選びます。選択され
    た各製品はカートに追加され、選択のたびにカートが表
    示される。購入者はカタログページで買い物を続けるか、
    チェックアウトしてカートの中身を購入することができ
    ます。チェックアウトの際には、連絡先や支払いに関す
    る情報を取得し、レシートページを表示します。決済を
    どのように行うかはまだ決まっていないので、これらの
    詳細はかなり曖昧なフローになっています。

    View full-size slide

  74. The seller flow, shown in the next figure, is also fairly basic. After
    logging in, the seller sees a menu letting her create or view a
    product or ship existing orders. When viewing a product, the seller
    can optionally edit the product information or delete the product
    entirely.
    The shipping option is simplistic. It displays each order that hasn’t
    yet been shipped, one order per page. The seller can choose to skip
    to the next or can ship the order, using the information from the
    page as appropriate.
    次の図に示すように、売り手のフローもかなり基本的
    なものです。ログインすると、商品の作成・閲覧や既
    存の注文の発送を行うメニューが表示される。商品を
    閲覧する際には、商品情報の編集や商品の削除が可能
    です。
    出荷オプションはシンプルです。まだ出荷されていな
    い注文が、1ページにつき1件ずつ表示されます。販売
    者は、次のページに進むか、そのページの情報を使っ
    て注文を発送するかを選択することができます。

    View full-size slide

  75. The shipping function is clearly not going to survive long in the
    real world, but shipping is also one of those areas where reality is
    often stranger than you might think. Overspecify it up front, and
    we’re likely to get it wrong. For now, let’s leave it as it is, confident
    that we can change it as the user gains experience using our
    application.
    出荷機能は明らかに現実世界では長くは生きられ
    ませんが、出荷もまた、現実が想像以上におかし
    いことが多い分野のひとつです。今のところはこ
    のままにしておいて、ユーザーがアプリケーショ
    ンを使う経験を積んだら、変更できることに自信
    を持っておきましょう。

    View full-size slide

  76. Data
    Finally, we need to think about the data we’re going to be working
    with.
    Notice that we’re not using words such as schema or classes here.
    We’re also not talking about databases, tables, keys, and the like.
    We’re talking about data. At this stage in the development, we
    don’t know if we’ll even be using a database.
    データ
    最後に、これから扱うデータについて考える必要があり
    ます。ここでは、スキーマやクラスといった言葉は使っ
    ていないことに注意してください。また、データベース、
    テーブル、キーなどの話もしません。データについて話
    しているのです。この開発段階では、データベースを使
    うかどうかさえわかりません。

    View full-size slide

  77. Working on the data diagram raised a couple of questions. As the user buys
    items, we’ll need somewhere to keep the list of products they bought, so we
    added a cart. But apart from its use as a transient place to keep this product
    list, the cart seems to be something of a ghost—we couldn’t find anything
    meaningful to store in it. To reflect this uncertainty, we put a question mark
    inside the cart’s box in the diagram. We’re assuming this uncertainty will
    get resolved as we implement Depot.
    データ図の作成作業をしていると、いくつかの疑問が
    湧いてきました。ユーザーが商品を購入すると、購入
    した商品のリストを保存する場所が必要になるため、
    カートを追加しました。しかし、この商品リストを一
    時的に保存する以外に、カートは何か幽霊のようなも
    ので、保存する意味のあるものが見つかりませんでし
    た。この不確実性を反映させるために、図中のカート
    のボックスの中にクエスチョンマークを入れました。
    これは、Depotを実装していくうちに解決されるもの
    と考えています。

    View full-size slide

  78. Finally, you might have noticed that we’ve duplicated the product’s price in
    the line item data. Here we’re breaking the “initially, keep it simple” rule
    slightly, but it’s a transgression based on experience. If the price of a
    product changes, that price change shouldn’t be reflected in the line item
    price of currently open orders, so each line item needs to reflect the price of
    the product at the time the order was made.
    最後に、商品の価格を項目データで重複させているこ
    とにお気づきでしょうか。これは、「最初はシンプル
    に」というルールを少し破っているのですが、経験則
    に基づいた違反行為です。商品の価格が変更された場
    合、その価格変更は現在開かれている注文の項目価格
    に反映されるべきではないので、各項目は注文された
    時点の商品価格を反映する必要があるのです。

    View full-size slide

  79. Again, at this point we’ll double-check with the customer that we’re still on
    the right track. (The customer was most likely sitting in the room with us
    while we drew these three diagrams.)
    ここでもう一度、お客様に正しい道
    を歩んでいるかどうか、再確認しま
    す。(この3枚の図を描いている間、
    お客さまはおそらく同席していたは
    ずです)。

    View full-size slide

  80. Let’s Code
    So, after sitting down with the customer and doing some preliminary
    analysis, we’re ready to start using a computer for development!
    We’ll be working from our original three diagrams, but the chances
    are pretty good that we’ll be throwing them away fairly quickly—
    they’ll become outdated as we gather feedback. Interestingly, that’s
    why we didn’t spend too long on them; it’s easier to throw something
    away if you didn’t spend a long time creating it.
    さあコードを書こう
    さて、お客様との打ち合わせと事前分析が終わり、
    いよいよコンピュータを使った開発です。最初に
    作成した3つの図を元に作業を進めますが、フィー
    ドバックを得るうちに古くなり、すぐに捨ててし
    まう可能性が高いです。面白いことに、あまり時
    間をかけずに作ったものほど捨てやすいのです。

    View full-size slide

  81. We like to work with the customer so we can jointly agree on
    priorities. In this case, we’d point out to her that it’s hard to
    develop anything else until we have some basic products defined
    in the system, so we suggest spending a couple of hours getting the
    initial version of the product maintenance functionality up and
    running. And, of course, the client would agree.
    私たちは、お客様と一緒になって、優先順位を決
    めていきたいと考えています。今回のケースでは、
    システムで基本的な部分をある程度定義しないと
    他の開発が難しいため、まずはメンテナンス機能
    の初期バージョンを稼働させるために数時間かけ
    ることを提案します。もちろん、クライアントも
    納得してくれるはずです。

    View full-size slide

  82. プロダクトオーナーと
    開発者たちが同席した
    数時間のミーティングの間に
    作れる仕様までもっていく。
    これがアジャイル。

    View full-size slide

  83. プロダクトバックログ
    と開発者(たち)

    View full-size slide

  84. 資料を作る人 会議する人 ものを作る人

    View full-size slide

  85. エクストリームプログラミングの原動力のひとつ
    は、ビジネスとテクノロジーの間の溝を癒すこと
    でした。私は、一般的に言われている2つのグ
    ループが激しく対立し、協力する方法を見つけて
    も必要なものが得られないという状況を目の当た
    りにしてきました。つまり、自分には納期を決定
    する力があると思っている人が、その力の幻想を
    手放そうとしなかったのです。そこにエクスト
    リーム・プログラミングが登場し、一連の人間関
    係とそれを支える儀式、そしてそれらの儀式や人
    間関係を支える技術的な慣習を提示しました。そ
    して、その代償として、締め切りを指示すること
    ができなくなりました。
    (Kent Beck 2021年7月のAgile 2021でのトークより)
    https://ja.wikipedia.org/wiki/
    ケント・ベック

    View full-size slide

  86. それを良しとする人もいました。そして、そのよ
    うなチームはとてもうまくいきました。しかし、
    一般的には、力関係は変わっていません。つまり、
    インセンティブが変わっていないのです。だから、
    行動は変わらない。だから結果も変わっていない。
    私は、これはペアプログラムをするかしないかと
    いう問題ではなく、意思決定をスキル・情報・結
    果に向けて動かす意思があるかどうかという問題
    だと思っています。
    (Kent Beck 2021年7月のAgile 2021でのトークより)
    https://ja.wikipedia.org/wiki/
    ケント・ベック

    View full-size slide

  87. プロダクトバックログ
    開発者(たち)

    View full-size slide

  88. プロダクトバックログ
    優先順位付けされた
    機能リスト。
    開発者たちが見積もる。
    納期は決められない。

    View full-size slide

  89. 自己組織的に働く人々。
    優先順位に合わせて
    出荷判断可能な
    プロダクトの増分を
    生み出していく。
    開発者(たち)

    View full-size slide

  90. プロダクトバックログ
    動作する
    プロダクト
    (の増分)
    上から順に
    生み出していく

    View full-size slide

  91. 動作する
    プロダクト
    (の増分)
    上から順に
    生み出していく
    価値があるか
    どうかがわかる
    プロダクトバックログ

    View full-size slide

  92. 安定したチーム
    決まった期間
    仕掛を作らない
    継続的にリリース

    View full-size slide

  93. これはいつ
    できますか?

    View full-size slide

  94. これはいつ
    できますか?
    たぶん3スプリント目

    View full-size slide

  95. 動作する
    プロダクト
    (の増分)
    上から順に
    生み出していく
    価値があるか
    どうかがわかる
    プロダクトバックログ

    View full-size slide

  96. https://www.1101.com/iwata/2007-09-03.html

    View full-size slide

  97. その時代から、宮本さんは
    なんにも知らない人をつかまえてきて、
    ポンとコントローラー渡すんですよ。
    で、「さあ、やってみ」って言ってね、
    なんにも言わないで後ろから見てるんですよ。
    わたしは、それを
    「宮本さんの肩越しの視線」と呼んでたんですけど。
    その重要性というのは、
    いっしょに仕事するまでわからなかったんです。
    https://www.1101.com/iwata/2007-09-03.html

    View full-size slide

  98. いっしょに仕事してはじめて、
    「あ、これだ」って思うんです。
    つまり、ゲームをつくった人は、
    ゲームを買ってくれる
    ひとりひとりのお客さんに対して
    「このようにして作りました。
    こう楽しんでください」
    とは、説明に行けないんですね。当然ですけど。
    https://www.1101.com/iwata/2007-09-03.html

    View full-size slide

  99. 簡単にいえば、お客さん目線なんですけど、
    それをどうやって見つけるかという方法を
    宮本さんはすごく早くから確立していて、
    一方、わたしは、自分のプログラムが
    イケてるかどうかには興味はあっても、
    お客さんがどう感じるかみたいなところは
    考えが及んでいなかったんです。
    https://www.1101.com/iwata/2007-09-03.html

    View full-size slide

  100. https://www.1101.com/iwata/2007-09-04.html

    View full-size slide

  101. 「オレは、これをいいと思う」って
    すべてのお客さんを代表するかのように、
    思い込みで語るつくり手が多いんですよ。
    https://www.1101.com/iwata/2007-09-04.html

    View full-size slide

  102. 本当は「お客さんがこう反応する」
    っていう事実があって、
    「それはなぜだろう?」
    という仮説があって、そこではじめて
    「じゃあ、どうすれば、
    根っこの問題が解決できるだろう?」
    って考えなきゃいけないのに、
    「オレはこう思う!」という、
    事実と仮説をぐちゃぐちゃに混ぜた意見を
    押し通してしまうことが多いんですね。
    https://www.1101.com/iwata/2007-09-04.html

    View full-size slide

  103. つまり、宮本さんというのは
    視点を動かすことに長けているんですね。
    そのとおりですね。
    いままで近くで見てたのを、
    突然ものすごく遠くから見てやり直すというか
    虫メガネで見ていたかと思うと
    地上一万メートルからもう一回見直してみたり
    https://www.1101.com/iwata/2007-09-04.html

    View full-size slide

  104. まず注意:
    目的をブレークダウンしても
    詳細は描けません。
    まず対象を十分に知っていないと、
    解決策は出てきません。情報が不足し
    ていると気づいたらまず調べること。
    観察したり話を聞くことに時間を振り
    向けるときかもしれません。

    View full-size slide

  105. ユーザーストーリー
    マッピング

    View full-size slide

  106. ジェフ・パットン
    Jeff Patton
    両者の協調ワークショップ
    を通じて共通理解を作る。

    View full-size slide

  107. 124
    前書き

    View full-size slide

  108. 125
    前書き

    View full-size slide

  109. 126
    前書き

    View full-size slide

  110. 127
    “どのようなソフトウェアを作るかについての議論に何度も参加して、
    その議論を説明するためのドキュメントを書いた場合、そこにいたほか
    の誰かと理解を共有することができるかもしれない。2人ともそれでい
    いと思うということだ。
    しかし、あなたたちの共通理解は、ドキュメントに含まれていない細部
    をたくさん含んでいる。議論の場にいなかったほかの読み手は、あなた
    たちと同じだけの理解に達することができない。彼女がわかったと言っ
    たとしても信じてはいけない。
    私がバケーションの写真を使って自分のストーリーを話したのと同じよ
    うに、場を共有して、ドキュメントを使ってストーリーを伝えるの
    だ。”
    前書き

    View full-size slide

  111. 128
    “ポストイットやインデックスカードを使いな
    がら、話したり、スケッチを作成したり、書き
    出したりする必要がある。会話の場に持ち込ん
    で、それを指差しながら話したり、蛍光ペンで
    マークしたり、注釈を書き込んだりする。イン
    タラクティブでエネルギーにあふれたものだ。
    もし、全員が会議室テーブルを囲んで座り、担
    当者ひとりが全員の発言をストーリー管理シス
    テムに入力しているようなら、おそらくやり方
    を間違えている。”
    前書き

    View full-size slide

  112. 1. ストーリーを使う目的は、
    もっといいストーリーを書くことではない。
    2. 製品開発の目標は、
    製品を作ることではない。
    “実際、この本を読んでたった2つのことが読者のなかに残
    りさえすれば、私は満足だ。そして、その2つはこの章のこ
    こに書いてある。”
    第0章 まず最初に読んでください

    View full-size slide

  113. 1. ストーリーを使う目的は、
    もっといいストーリーを書くことではない。

    View full-size slide

  114. 139
    Rachel Davies Connextra Format
    第7章 よりよいストーリーテリングのために

    View full-size slide

  115. 140
    “1990年代の終わり頃、彼女はConnextraという会社で働
    いていた。Connextraは、ストーリーを生んだアジャイル
    プロセスであるエクストリームプログラミングをいち早く導
    入した会社の1つである。Connextraの人々は、ストーリー
    を使い始めてすぐ、ある共通する問題にぶつかった。
    Connextraでストーリーを書いたのは、ほとんどが営業や
    販売促進の人々だった。彼らは、自分にとって必要な機能を
    書き出す傾向があった。しかし、開発者たちが会話をすると
    きには、本来のステークホルダーを見つけ出し、「誰」と
    「なぜ」を含んだ、いい会話をはじめなければならない。機
    能の名前だけが書いてあっても、チームが話をすべき適切な
    人々を見つけ出し、適切な議論を始めるためには役に立たな
    い。”
    第7章 よりよいストーリーテリングのために

    View full-size slide

  116. “あなたがアジャイル開発プロセスを使っているなら、
    バックログにユーザーストーリーが含まれているだろう。
    ストーリーはそれだけ広く使われているのだから、この
    本でストーリーについて書いても時間の無駄なのではな
    いか。しかし、それは間違っている。Kent Beckが初
    めてストーリーについて書いてから15年の間に、ス
    トーリーは人気を集めるようになったが以前よりも誤解
    され、濫用されるようにもなった。” 、
    前書き

    View full-size slide

  117. 動作する
    プロダクト
    (の増分)
    上から順に
    生み出していく
    価値があるか
    どうかがわかる
    プロダクトバックログ

    View full-size slide

  118. • 全体像を見失いやすい
    • いつになったら完成するのか、そもそも何が作
    られているのかわからなくなってしまう
    • ストーリーを使っている人々が何も書き出さな
    くなる。
    • チームが予定された期限内に予定した仕事を終
    わらせることができない。
    • うちの製品にはユーザーがいないので、ユー
    ザーストーリーは役に立たないと言い出す
    前書き より抜粋
    プロダクトバックログ

    View full-size slide

  119. 2. 製品開発の目標は、
    製品を作ることではない。

    View full-size slide

  120. “私たちとしては、不満があって怒り、当惑していた人々が、ソ
    フトウェアが出荷されることによって幸せになるようにしたい。
    しかし、彼らはソフトウェアが入った箱を見ても幸せにはならな
    い(最近はソフトウェアが箱に入ってくることはあまりないが)。
    彼らはリリースノートを読んでも、モバイルデバイスにアプリを
    ダウンロードしても、幸せにはならない。
    彼らはソフトウェア、ウェブサイト、モバイルアプリ、その他あ
    なたが作ったものを使うことで、今までとは違う、幸せなやり方
    ができるから、幸せになるのだ。”
    前書き

    View full-size slide

  121. “その機能について会話するときには、
    それが誰のためのものなのか、
    その人たちは(その機能がない)現状ではどうやっているの
    か、
    (その機能を提供したら)今後はその人たちを取り巻く物事
    がどう変わっていくのか、
    そういったことを話題にする。
    そうした将来のポジティブな変化があるからこそ、
    それを欲しいと思うようになるのだ。”
    前書き

    View full-size slide

  122. プロセス全体の流れ

    View full-size slide