Download to read offline
![エレベーターピッチテンプレート
• [潜在的なニーズを満たしたり、抱えている課題
を解決したり]をしたい
• [対象顧客]向けの
• [プロダクト名]というプロダクトは
• [プロダクトのカテゴリー]である。
• これは[重要な利点、購入への説得力ある理由]
があり、
• [競合サービス名]と違って
• 我々のプロジェクトは[差別化の決定的な特徴]
が備わっている。](https://image.slidesharecdn.com/random-141117231433-conversion-gate02/85/re-78-320.jpg)
![エレベーターピッチ例：Gunosyの場合
• [自分の知りたい情報を定期的に収集]したい
• [ビジネスパーソン]向けの
• [Gunosy]というプロダクトは
• [キュレーションサービス]である。
• これは[簡単な設定での使用や、アプリで手軽に
アクセス]することができ、
• [Yahooニュース]と違って
• 我々のプロジェクトは[常に自分の興味のある分
野の情報を受動的に手に入れられる気軽さ]が備
わっている。](https://image.slidesharecdn.com/random-141117231433-conversion-gate02/85/re-79-320.jpg)
More Related Content
![[RSGT2019]全部スクラム！～SIerで大切だったこと、サービサーで大切だったこと～](https://cdn.slidesharecdn.com/ss_thumbnails/rsgt20190110-190110041236-thumbnail.jpg?width=640&height=640&fit=bounds)
![【会社紹介資料】DXインキュベーション株式会社 [ 2026/01 公開 ].pdf](https://cdn.slidesharecdn.com/ss_thumbnails/dx-260109094457-99cdcb44-thumbnail.jpg?width=640&height=640&fit=bounds)
![【会社紹介資料】DXインキュベーション株式会社 [ 2026/01 公開 ].pdf](https://cdn.slidesharecdn.com/ss_thumbnails/dx-260111043954-4d99478e-thumbnail.jpg?width=640&height=640&fit=bounds)
![【会社紹介資料】DXインキュベーション株式会社 [ 2026/01 公開 ].pdf](https://cdn.slidesharecdn.com/ss_thumbnails/dx-260109090506-c3f9affd-thumbnail.jpg?width=640&height=640&fit=bounds)
![【会社紹介資料】DXインキュベーション株式会社 [ 2026/01 公開 ].pdf](https://cdn.slidesharecdn.com/ss_thumbnails/dx-260110091700-f9430e2d-thumbnail.jpg?width=640&height=640&fit=bounds)
![【会社紹介資料】 株式会社カンゲンエージェント [ 2026/01 公開 ].pdf](https://cdn.slidesharecdn.com/ss_thumbnails/202601-260109011218-57ff1508-thumbnail.jpg?width=640&height=640&fit=bounds)
![【会社紹介資料】DXインキュベーション株式会社 [ 2026/01 公開 ].pdf](https://cdn.slidesharecdn.com/ss_thumbnails/dx-260109084717-293d42bc-thumbnail.jpg?width=640&height=640&fit=bounds)
![【会社紹介資料】DXインキュベーション株式会社 [ 2026/01 公開 ].pdf](https://cdn.slidesharecdn.com/ss_thumbnails/dx-260109091120-2e61a704-thumbnail.jpg?width=640&height=640&fit=bounds)
![【会社紹介資料】DXインキュベーション株式会社 [ 2026/01 公開 ].pdf](https://cdn.slidesharecdn.com/ss_thumbnails/dx-260109085534-7362cbc2-thumbnail.jpg?width=640&height=640&fit=bounds)
re:日暮里アジャイル
- 1. re: Nippori Agile 株式会社CyberAgent 佐藤慎悟
- 2. WARNING 夜な夜な日暮里で遊び回っているという 社内のごく一部に広がる 私、個人に対するデマへの皮肉を込めて この名前にしただけであって 日暮里とアジャイルは一切関係ありません。 日暮里デマ歴 祝一周年
- 3. 本日のメニュー ・開発手法について ・アジャイルって何だろう ・スクラムについて ・インセプションデッキ
- 4. 本日のメニュー ・開発手法について ・アジャイルって何だろう ・スクラムについて ・インセプションデッキ
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14. ・何のために作っているの？ ・ユーザーにメリットはあるの？ ・それが、ちゃんとユーザーに届 けられているかをこまめに確認！
- 15.
- 16.
- 17. ・関係者は目的達成のためにお互いに協 力しながら進める ・利用者の反応や関係者からのフィード バックを継続的に得ながら、計画を調整 ・一度にまとめてではなく少しづつ作る ・出来上がった物が求めている物とあっ ているかを頻繁に確認する
- 18.
- 19.
- 20.
- 21.
- 22. アジャイルをやろう Doing Agile アジャイルにやろう Being Agile
- 23.
- 24. スクラムScrum ・アジャイル開発の手法の一つ ・全員が一枚岩となって行う、作業、会 議、成果物を定めたもの
- 25. スクラムScrum ・要求を常に順番に並び替えて、その順番にプロダク トを作る事で成果物を最大化する ・固定の短い期間に区切って作業を進める ・現在の状況や問題点を常に明らかにする（透明性） ・定期的に進捗状況や作っているプロダクトが正しい のか、仕事の進め方に問題がないかどうかを確認 ・やり方に問題があったり、もっとうまく出来る方法 があったりすれば、やり方そのものを変える。
- 26.
- 27.
- 28.
- 29. プロダクトオーナー ・プロダクトの結果責任を取る ・プロダクトバックログの管理者で優先順位の最終決定権を持つ ・プロジェクトに必ず一人必要 ・開発チームを活用してプロダクトの価値を最大化する ・開発チームに相談出来るが、干渉は出来ない
- 30. 開発チーム ・リリース判断可能なプロダクトを作る ・全員揃えばプロダクトを作れる ・上下関係はない ・開発チーム全員で作業を進める自己組織化されたチーム
- 31. スクラムマスター ・スクラムのプロセスがうまくまわるようにする ・妨害を排除する ・支援と奉仕をする ・教育、ファシリテート、コーチ、推進役
- 32.
- 33.
- 34. http://www.scrumprimer.org/ プロダクトバックログ ・実現したい要求をリストにして優先順位で並び変える ・一度作って完了ではなく、絶えず修正されるものなので、 常にメンテナンスして最新に保つ ・プロダクトバックログには作業量を表した値を使う
- 35. １番目に欲しい ２番目に欲しい ３番目に欲しい ４番目に欲しい ５番目に欲しい ６番目に欲しい
- 36.
- 37.
- 38. スプリント計画ミーティング http://www.scrumprimer.org/ ・スプリントで開発をするには計画が必要 ・ミーティングは二部制 ・プロダクトオーナーは何を欲しいのか（第一部） ・開発チームはどれくらいできそうか（第一部） ➡ストーリーポイントをつけていく ・開発チームはどうやってそれを実現するか（第二部）
- 39. １番目に欲しい ２番目に欲しい ３番目に欲しい ４番目に欲しい ５番目に欲しい ６番目に欲しい タスクタスク タスクタスク タスクタスク タスクタスク スプリント
- 40.
- 41.
- 42. http://www.scrumprimer.org/ デイリースクラム ・時間は15分以内 ・昨日やった事、今日やる事、問題点を共有 ・別途で話が必要な物は後で時間をとってやる ・全員が進捗や問題になっている事を把握できる ・デイリースクラムは開発チームのためのもの ➡特定の誰かへの報告会ではない
- 43.
- 44.
- 45.
- 46. http://www.scrumprimer.org/ スプリントレビュー ・開発チームの成果物をプロダクトオーナーが確認する ・確認するのは動作するプロダクト ・完了しなかった物はプロダクトバックログに戻される ・プロダクトバックログに追加する項目の有無について議論 ・現在の進捗を踏まえて、リリース日や完了日を予測する
- 47.
- 48.
- 49. スプリントレトロスペクティブ http://www.scrumprimer.org/ ・うまくいった事、今後改善すべき点を整理する ・振り返り（KPT法なんかが分かりやすい） ・次回スプリント以降のアクションプランを決める
- 50.
- 51.
- 52.
- 53.
- 54. Q.スプリントの期間って別にバラバラで もよくないですか？ A.スプリントの期間を固定する事でチー ムのベロシティを計れるようになって進 捗を把握しやすくなったり、見積もりの 誤差が少なくなるよ。
- 55.
- 56. Q.ストーリーポイントって時間とかで予 測したらダメなわけ？ A.時間で見積もると人によって見積もり が違う事がある。あと、チームの成長を 考慮していないのでチームが成長して いった時に見積もりをやり直さないとい けなくなるよ。
- 57.
- 58. Q.リリース判断可能なポイントってどう いうこと？ A.各ストーリーにおけるゴールを明確に しよう。何をもってリリースが可能かを 決めないといつまで起っても終わりませ ん。また、リリース判断ポイントの定義 は品質基準とも言えます。
- 59.
- 60.
- 61. いまいちな点① 何？このストーリー… とても、大きいです… タスクは細分化しよう。 冷静な判断も下しやすい。
- 62.
- 63. いまいちな点② ゴールどこ？ どこまで走ればいいの？ ゴールはちゃんと決めましょう。 スプリントって言ってんのにフルマラソン。
- 64.
- 65. いまいちな点③ アジャイルだから ドキュメントとかいらなくね？ どういう形でもいいから 全員が分かる、形となった物が必要
- 66.
- 67. いまいちな点④ だからこれは デザインなのよ！ デザインはデザイン。 仕様等は別のドキュメントで。
- 68.
- 69.
- 70. よかった点① 健やかなる時も 病める時も進捗を把握 なんだかんだで 状況を全員が把握出来る
- 71.
- 72. よかった点② あれちょうだい！ はい、これもちょうだい！ 随時テスト出来る状態にして とにかくテストテスト！
- 73.
- 74. よかった点⑤ 振り返ると楽しかった あの日々 辛く冷たい時間を過ごすのではなく 楽しく実りのある開発をしたい
- 75.
- 76. プロジェクトの全体像を 端的に伝えるための ドキュメント ※アジャイルサムライを読んでみてください
- 77. 10個の手強い質問 1.我々は何故ここにいるのか 2.エレベーターピッチを作る 3.パッケージデザインを作る 4.やらないことリストを作る 5.ご近所さんを探せ 6.解決案を描く 7.夜も眠れなくなる問題はなんだろう 8.期間を見極める 9.何を諦めるかをはっきりさせる 10.何がどれだけ必要なのか
- 78. エレベーターピッチテンプレート • [潜在的なニーズを満たしたり、抱えている課題 を解決したり]をしたい • [対象顧客]向けの • [プロダクト名]というプロダクトは • [プロダクトのカテゴリー]である。 • これは[重要な利点、購入への説得力ある理由] があり、 • [競合サービス名]と違って • 我々のプロジェクトは[差別化の決定的な特徴] が備わっている。
- 79. エレベーターピッチ例：Gunosyの場合 • [自分の知りたい情報を定期的に収集]したい • [ビジネスパーソン]向けの • [Gunosy]というプロダクトは • [キュレーションサービス]である。 • これは[簡単な設定での使用や、アプリで手軽に アクセス]することができ、 • [Yahooニュース]と違って • 我々のプロジェクトは[常に自分の興味のある分 野の情報を受動的に手に入れられる気軽さ]が備 わっている。
- 80.
- 81. Nippori Agile sprint0 参考書籍 アジャイルサムライ http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06856-0 SCRUM BOOT CAMP THE BOOK http://www.seshop.com/product/detail/15395/ リーン開発の現場 http://lean-trenches.com/
- 82.
- 84.
- 85.
- 86.
Editor's Notes
- #3 ネーミングについては一応ですね 完全に語感だけなので特に深い意味はないです。 キャッチーさ重視ということで
- #4 今日のメニューですが 割とベーシックな所のお話を出来ればと思います。 開発手法の思想の部分から、アジャイル手法の中のスクラムにクローズアップする内容になります。
- #5 お昼のすぐ後なのでちょっとでも眠くなってきたら手を挙げてください。 ストレッチします
- #6 で、まずは開発手法についてその思想やスタンスのお話から
- #7 まず、大きく今回お話する事で開発手法にはこの二つがあります。 どちらが良い、悪いという話ではなく、単純にどんな思想なのかというのを比較出来ればと思います。
- #8 ウォーターフォールの基本的な考え方は「区切られた全ての行程が正しい」という前提で進める方法です。 この前提を守りながら進めるため、当初に作成した要求仕様を忠実に実装し、その仕様を全て満たした時点で開発完了となります。 水は上から流れるため、ウォーターが落ちる（フォール）というとこからこの名前になっているとか。
- #9 対して、アジャイル型の場合は行程分けされて進むのではなく、プロジェクトは変化するものと考え、小さなサイクルを何度も回しプロジェクトが生み出すプロダクトを最大化する事を重要と考えます。 そのため、当初計画された機能が100%完成する事は困難です。 そのかわり、プロダクトがリリースされる時点で関係者全てが「最大の価値がある」と思えるようなプロダクトが完成します
- #10 プロデューサーやプランナーは開発について何も知らなくていいというわけではないです。 直接開発に手を出さないとしても、知っていると知っていないでは自分のチームを理解する深さが違ってきます。
- #11 僕はこういった事の理解は非エンジニアであるプロデューサーだからこそ大事だと思っています
- #12 で、今日はアジャイルの勉強会という事なので アジャイルについて掘り下げていきます
- #13 まずそもそもですが
- #14 サービスを作る上で本当に大事な事ってなんだろう
- #15 機能の一つ一つには意味があって、ちゃんとそれをユーザーに届けられているか それを常に確認していく事が必要だと思います
- #16 最初に予定していた物が色んな経緯を経て、変更になるというのは十分にあり得るのですが ユーザーに価値のある物を提供するという理由である限りは、常に変化する必要があります。 そのためには
- #17 柔軟な対応を出来るようにしておかないといけません
- #18 それを実現するためには何が必要になってくるかというと 関係者は目的のためにお互いが協力的であるべきで ユーザーのフィードバックをもとに計画を調整し さらに一度にまとめてつくって軌道修正をしにくくするのではなく 少しずつ作っていき 成果物が求めている物になっているかをこまめに確認する必要があります
- #19 アジャイルってなんだろう
- #20 アジャイルは目的を達成するための習慣である、と
- #21 開発手法としてアジャイルをやろう、みたいな話が出たりもしますが そもそもアジャイルのやり方にしたからと言って必ず好転するとは限りません。
- #22 アジャイルを目的とするのではなく
- #23 目的を達成するためにアジャイルな思想でやっていきましょう
- #24 次にスクラムなのですが
- #25 アジャイル開発の手法の一つとして 簡単に言うと全員が一枚岩となって行う、作業や会議、成果物を定めたものになります
- #26 スクラムの特徴としては ・常にやる事を並び替えて、その順番にプロダクトを作る事で成果物を最大化します ➡プロダクトバックログの順番がそれにあたります ・固定の短い期間に区切って作業を進める ➡リリースまでの期間をsprintとして区切ってます 現在の状況や問題点を常に明らかにする ➡かんばんでプロジェクトのメンバーが全員お互いの状況を把握します 定期的に進捗状況や作っているプロダクトが正しいのか、仕事の進め方に問題がないかどうかを確認 やり方に問題があったり、もっとうまく出来る方法があればやり方を変える ➡定期的な振り返りが必要な理由はここだったりします
- #27 で、細かい事はいいから実際のフローはどうなっているのかと言うと
- #28 こんな感じですね。 なんかこういうタッチだと和みますね。 これは開発からリリースまでの流れを絵にしているんですが このサイクルを短い期間で繰り返して行くのがスクラム開発の流れになります。 プロダクトバックログでやる事を整理し、 それをどういうボリュームでやっていくか、どんな風に実現するかを決めて その後、開発を進め 実際に出来上がったものを確認し、リリースをしていく この一連の流れを短い期間で繰り返す事で、 細かく、素早く、開発を進めていく事が出来ます。
- #29 それぞれの流れを説明する前にスクラムチームにはそれぞれ役割があります
- #30 まず、プロダクトオーナー。 プロダクトオーナーはその名の通り、プロダクトの責任者です。 開発チームを活用してプロダクトの価値を最大化するポジションです。 ウチで言うとプロデューサーがその立場にあたると思います。 また、プロダクトバックログの優先順位を最終的に決定するのもプロダクトオーナーの仕事です。
- #31 次に開発チーム。 実際にプロダクトを作っていく人たちがこれにあたります。 仕事の進め方を指示されるのではなく、開発チーム全体で責任を持って作業を進めます。 基本的には上下関係はないとされていますが、だからと言って先輩にタメ口をきいたりするのはやめましょう。 僕は責任持てません。
- #32 そしてスクラムマスター。 どちらかと言えば縁の下の力持ち的なポジションで スクラムのルールを守るようにファシリテートをしたり スクラムの外にいる人からの妨害などからプロダクトオーナーや開発チームを守ります。 、また、開発チームやプロダクトオーナーの求めに応じて作業を助けたりもします。 実際にはこの他にステークホルダーと言ってスクラムチームとの利害関係者という立ち位置もありますが 一旦ここのついては割愛します。
- #33 で、またスクラムの流れに戻ります。
- #34 左下から順に説明をしていくと
- #35 まずはプロダクトバックログから始まります。 これは要求を順番に並べ替えたリストになります。 これを用意して、プロダクトオーナーがその優先順位の最終決定を行います。 リストの項目をストーリーと言いますが、 そのストーリーの見積もりには絶対的な時間などではなく相対的なポイントを使ったりします。
- #36 プロダクトバックログの優先順位は常にメンテナンスしていきましょう
- #37 で、そのプロダクトバックログを元に今度は
- #38 スプリント計画ミーティングを行います。
- #39 プロダクトバックログからスプリントに落としこんで開発に突入します。 そのための計画をする必要があります。 一応スプリント計画に使える時間は決まっていて、一ヶ月スプリントであれば８時間。２週間スプリントであれば４時間となります。 ミーティングについては二部制で、 第一部ではそのスプリントで、どのプロダクトバックログの項目を開発するのかを検討し、内容を確認します。 開発する量は過去のスプリントの実績と今後の予測を参考にして決定します。 この過去の実績の事をベロシティと呼びます。 bk2の場合はこれまでベロシティを計ってきていなかったので今のメンバーでのベロシティというのは出ていないので 実際に1スプリントでどれくらいの作業をこなせるのかというのはこれから正確になってくると思います。（現在進行中） 第二部では、第一部で選択したプロダクトバックログの項目を完了させるために必要な全ての作業を開発チームによって洗い出します。 作業をタスクとして呼ぶ事が多くこのタスクは開発チームの作業計画となり、スプリント期間中も自由にタスクを追加したり削除したりできます。
- #40 Sprintでやるボリュームを決めて それをタスクに分解していきます。
- #41 スプリント計画ミーティングが終わるとその後は開発に突入していきます。
- #42 その中で毎日行うものがあります
- #43 朝会と言ったりもしますがデイリースクラムでは 15分の限られた時間の中で開発チーム全体に向けて 昨日やったこと、今日やること、困っている事を簡潔に報告します。 これによってスプリントがゴールに向かって進んでいるか、作業の進捗はどうなっているか、メンバー間の協力が必要な事がないかなどを確認します。 デイリースクラムは特定の誰かに向けての報告会議ではなく、問題解決の場でもありません。 問題を報告した場合はデイリースクラム終了後に改めて、問題解決に必要な人を集めた別の会議を設定してください。 これによって開発チームのメンバーの時間を会議によって削られる事を避けます。
- #44 時間は有限です。 大切にしましょう。
- #45 そして開発を繰り返し、出来上がった物をもって
- #46 プロダクトオーナーがプロダクトを確認する機会を設定します。 これをスプリントレビューと言います
- #47 作ったものを見ながらプロダクトオーナーが確認出来るようにします。 プロダクトオーナーはそれを受けて依頼した通りの物であれば作業完了と判断します。 依頼したものを異なる場合は、作業は完了していないものとし、プロダクトバックログに戻します。 毎スプリントごとにプロダクトが要求通りにつくられているかを検査することによって 最後にまとめて確認して多くの手戻りが出たりすることを避けられるように出来ています。
- #48 レビューが終わると最後にそのスプリントを全員で振り返ります
- #49 スプリントレトロスペクティブと言いますが
- #50 いわゆる、振り返りの時間です。 Bk2ではsprint締め会と言っています。 ここでは直近のスプリントでの開発で問題がなかったか、もっと成果を出すために出来る事がないか検査を行い 次のスプリント以降のアクションプランを決めます。 もっと成果を出せるように自分たちの仕事のやり方を変えて行きます。 仕事のやり方を常に改善していく事はアジャイル開発における大事な点の一つで スクラムではスプリント単位でそれが行われるように仕組み化されています。
- #51 振り返りを行いチームの力を高めていきましょう。 プロダクトバックログやスプリント計画と同じくらい大切な仕組みです。 よくこれを無駄な時間と捉える場合もありますが 開発を進めるにあたり、チームとしての成長を促す、大事な時間です。
- #52 こういった一連の流れを短いサイクルで繰り返す事で開発にメリハリやリズム感を生み 常に動くもので確認をしながらサービスを作り上げていきます。 スクラムに取り組む際には、今説明したスクラムの全体像を関係者全員が理解している事が必要になってきます。
- #53 で、この流れの中で僕も疑問に思っていた事とか あとよく聞かれたりする事をちょっとQ&Aでまとめてみました。
- #54 スプリントの期間って別にバラバラでもよくないですか？ 例えばスプリント１は１週間だけど スプリント２はやらなきゃいけない事が多いから２週間に延ばそうか、みたいな。 延ばしたい気持ちも分かりますがスプリントの期間がバラバラになると困ることもあります。
- #55 １スプリントで消化したストーリーの事をベロシティと言いますが 期間を固定しないとベロシティにばらつきが出てきてチームが１スプリントで消化できるストーリーの量が量れなくなってきます。 ベロシティを計れると何がいいかと言うと、最終的なゴールへの進捗が把握しやすくなったり、当初の見積もりの誤差が少なくなるので 原則的にはスプリントの期間は固定にした方がいい事が多いと思います。
- #56 次に ストーリーポイントって時間とかで予測したらダメなわけ？ スプリント計画ミーティングとかで工数を見積もる時に何日とか、何時間みたいな予測の仕方でもいいんじゃない？ っていう事なんですが、これ最初は僕も時間とかでいいんじゃないって思ってたんですが
- #57 時間で見積もると結局人によって見積もりの差が出てしまうという事と 絶対的な値はチームの成長を考慮していないのでチームが成長していった時に見積もりをやり直す必要が出てきます。 また、チームで相対的な値を出す事でストーリーの規模感が分かりやすくなると思います。 ストーリーポイントについては議論されているテーマでもありますが 難易度や規模感で表す事によって次のスプリントの予測を時間で出すよりもはるかにたてやすくなるメリットがあると僕は考えます。 ただし、あまりこれに拘りすぎると仕組み自体がうまく機能しない事もあるので これはチーム全員の対話をもとに決めていけばいいと思います
- #58 リリース判断の可能なポイントって何だろうという事ですが
- #59 各ストーリーはゴールをちゃんと明確にしましょう。 そのゴールを持ってリリースをしていきます。 それがリリース判断可能なポイントになります。 また、このポイントの定義はプロダクトの品質基準とイコールになります。
- #60 ただし、イマイチな事ももちろんあるので、いくつかアンチパターンを紹介していきますね
- #61 まずですね、細分化しにくかった大きめなストーリーをそのままやったりすると中々にしんどい場合があります
- #62 細分化しておくに超した事はないです。 困った時の対応とか、機能を削らざるをえない時とかの 判断がしにくい事もあるので、他の作業に影響が及ぶ事もあるので。 あと優先順位が分かりにくくなったりもします。
- #63 ストーリーのゴールが不明瞭だったもの。 そのせいで修正が延々と続き、次のスプリントに影響が及んだ事もありました。 中々進捗が良くない時もあったりしたので。
- #64 ゴールはちゃんと決めましょう。 もう、なんていうかストーリーを完結させるって事は本当に大事だな、と。 もし、追加で対応しないといけない物が出てきた事は別のストーリーを作って対応出来るような 環境にしておかないとそこで進みが止まってしまうのでゴールは明確にしましょう。 みんな疲れます。
- #65 アジャイルは短い間隔で計画から実行を繰り返す方法。 だからぶっちゃけドキュメントとかいらないよね、みたいな話。
- #66 甘えんなと言いたいです。 事実、プロデューサーって時間が中々取れないケースが多々あるので厳しい場面もあると思います。 だけど究極手書きでもいいから何か形にする事で開発は進みやすくなります。これは経験則です。 アジャイルの本質を理解していれば、アジャイルだからドキュメントなんていらねーなんて発想にはならないと思います。
- #67 デザインをまとめて管理していた物があったんですが どうもデザインが仕様みたいになっちゃった時があって デザイナーに負荷がかかりすぎてしまいました。
- #68 デザインはデザイン。仕様は仕様でちゃんと管理した方が最終的に情報もスッキリすると思います。 ここらへんはある程度の棲み分けをしておいた方がいいかなと個人的には思います。
- #69 ただ、もちろん悪い事だけではなくてですね いいこともありました
- #70 まぁどんな時でも状況を全員が把握しやすい感じになっていたかな、と。 開発後半はやはりみんな疲れはありましたけど、あとこれくらい残ってるよ！っていう認識は全員持ててかなと
- #71 はい、なんだかんだで。 でもやっぱりチームの状況は全員把握出来るような状況はベストだと思います。
- #72 何をちょうだいという話なんですが
- #73 不明瞭なゴールで修正が増えてしまった時にゴールの制定もそうなんですが とにかく動作テストをすぐ出来るような状況にもっていったのは良い結果になった事があります
- #74 あとは単純に大変な事もあったけど楽しいかなという。
- #75 楽しく仕事をするって事は本当に重要で ふざけたり遊べというわけではなく、お互いが前向きな仕事を出来るように心がけるべきです。 例えば、sprint締める度に乾杯するとか KPTを潤滑にまわすためにお茶しながらやるとか そういう小さい事でもいいから仕組みを導入するのも一つの手段としてアリだと思います。 スクラムって結局プロセス重視のフレームワークではなく 人を重視した物なので、コミュニケーションからお互いに学べる事もやっぱり多くて 僕自身も知識として持っていた物が体験を通して身につけられたりと 結構こういう経験は大きかったように思います。
- #76 インセプションデッキについて軽く触れたいと思います
- #77 すごくざっくり言うとインセプションデッキというのは プロジェクトの全体像を端的に伝えるためのドキュメントです。 言語化しないとわからない事って結構あると思います。 そうだったの？って思う事って意外と多くて 特に立ち上げからいない人間なんかはこういう物があるだけでも すんなり入りやすくなると思います。 詳細についてはアジャイルサムライを読んでみてください。 この本の著者によって広く認知されるようになったものです。
- #78 インセプションデッキは10個の質問から成り立ちます。 これは認識をすり合わせる強力な項目になっています。 プロジェクトメンバー間でも共通の認識を持っていると持っていないのとでは 開発プロセスにおいての認識に違いが出てくる場合があります。 で、先日Candyで合宿があった際に少しこの話をしたのですが まずはエレベーターピッチを作ってみようか、という話になったので 今日はエレベーターピッチにフォーカスします。 その他に関しては今日は割愛します。
- #79 エレベーターピッチの由来は アメリカのシリコンバレーが発祥です。 「エレベーターの中で投資家と居合わせたら自分のビジネスプランを30秒で伝えられないようであれば未来はない」と言われてきました。（ピッチは説明するという意味） 何のためにやるのかという所ですが ・サービスにおいての共通認識をロジカルに明快な言葉として形にする。 ・言語化する事で、一つの機能の開発においてもブレを生まれにくくする ・Candyの場合は今回のダカイの方向性の認識の相違を無くし、よりクオリティの高いものにする という目的があります。 ここに写っているテンプレートに沿って括弧の中を埋めていく事でそれぞれの認識をすり合わせます。 これは出来ればプロジェクトメンバー全員で作りましょう。
- #80 これは例で別のサービスでテンプレートに沿って入れてみたものですが 端的にサービスの事を表しています。 どういうターゲットに向けてどういうカテゴリーのサービスで どんな目玉機能があってどういう差別化ポイントがあるのか。 エレベーターピッチは作って終わりではなく 作ったら見える場所に貼っておくといいと思います。 共有フォルダの中にしまい込んでも多分誰も見ません。僕はまず見ません。 プロジェクトの方向性を正確に共有出来るツールとして活用していけると思います。
- #81 で、スクラムやアジャイルに関する本はたくさん出てると思います。 僕もまだ全然読めていない方なので勉強中な所はあるのですが
- #82 ちなみにこちら今回の勉強会やるにあたっての参考書籍となっております。 スクラムブートキャンプなんかは漫画を入れながら事例を元に一連の流れを説明してるので 最初のとっかかりとしては入りやすいかと思います。 アジャイルサムライは僕は何か困った時なんかはたまに読み返してますが 普通に読み物としても面白いかなと。 入門としてもオススメします。 リーン開発の現場なんかは翻訳の方がSUFとかで ウチでやってたりしたので知ってる方もいるかもしれませんが これも事例を元に書かれているので具体的で分かりやすいです。 他にもおすすめの本とかあったら教えてほしいです。
- #83 最後に ここまで話を進めてきましたが 結論から言えば、開発がうまく回れば何でもいいと思っています。 ただ、そのための方法論は引き出しが多ければ多いほど絶対的に役に立つというのと プロデューサーは特にこういった事に対してエンジニアと同じ言語で話せた方が武器になると思っています。 「知らない」からいいですませてしまうのではなく、直接手を動かさないからこそ「知っておくべき」だと。 あとコレは私見ですが、この考え方というのは 開発に限った話ではなく、プロデューサーのタスクにも活用出来ると思っています。 変更という言葉から無関係ではいられない立場だからこそ 柔軟な対応するためのハックとして噛み砕いていければと思います。
- #84 スクラムは銀の弾丸ではありません。 何にでも効く特効薬でもありません。 それをどんな風に活用するかは結局人によってくるのですが 正しい方法を知る事でプロジェクトの幅が広がってくるのではないかと思いました。
- #85 変化を恐れずに柔軟な対応が出来るように、 アジャイルな思想でやっていきましょう
- #86 ご清聴ありがとうございました。
- #87 はい、で 何か質問などあればお願いします。 なんでもいいです。 何か質問などある方いらっしゃいますか？ 【いない場合】 さっき出てきたよくある質問の中には入っていなかったんですが 見積もったポイントがやってみたら結構大きかったとか、意外と小さかった、みたいな時もあると思うんですが そういう時は次のスプリント計画ミーティングでちゃんとポイントを修正すると より今後の見通しが立てやすくなるかな、と思います。