Download as PDF, PPTX
More Related Content
![[Java Day Tokyo 2018]50分で最新技術学習の基礎を身につける(SOMPO Systems Daisuke Nishino)](https://cdn.slidesharecdn.com/ss_thumbnails/javadaytokyo2018bn3somposystemsdaisukenishino-180518144822-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to 俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
![デブサミ関西2012[A-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方](https://cdn.slidesharecdn.com/ss_thumbnails/devsumi2012kansaia2share-120914110840-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![夏サミ 2012 [B-2]エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方](https://cdn.slidesharecdn.com/ss_thumbnails/dvsumi12natsumib2share-120727064447-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
- 1. 早稲田大学理工学部キャンパス (株) 永和システムマネジメント アジャイル事業部 Ruby xAgile グループ 伊藤 浩一 (@koic) 2015.09.12 (Sat) XP祭り 2015 over contact negotiation Customer collaboration 準委任契約によるふつうのソフトウェア開発 俺も受託開発
- 2.
- 3. Computer programmer, guitarist. Leaderof an Agile software development team at Eiwa System Management, Inc. Lives in Shinjuku. @koic photo token by @NaCl
- 6. • 2014.09.06(Sat) XP祭り2014 •2014.11.08(Sat) Yokohama.rb Meetup#50 • 2014.11.29(Sat) TokyuRuby会議08 • 2015.01.16(Fri) ありがたい話 公開版 • 2015.02.25(Wed) Ruby Business Users Conference 2015 • 2015.03.28(Sat) 浜松Ruby会議01 • 2015.04.06(Mon) マイナビTV【永和システムマネジメント】のアジャイルな受託開発 • 2015.05.15(Fri) Ruby合同勉強会＠Sansan • 2015.06.04(Thu) 表参道.rb#1 • 2015.06.29(Mon) 西日暮里.rb 1周年記念会 • 2015.07.11(Sat) 関西Ruby会議06 • 2015.07.22(Wed) pixiv x ESM技術交流会 • 2015.07.27(Mon) 第14回 西日暮里.rb • 2015.08.29(Sat) TokyuRuby会議09 • 2015.09.12(Sat) XP祭り 2015 ここ一年の活動範囲
- 7.
- 8. TO MAKE THE ENDOF DECADE 2015.09.12
- 9.
- 11.
- 12.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 25. 一括請負 ハイブリッド 準委任 一括請負 準委任 準委任 準委任準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 準委任で継続
- 26. 私は疑問 今回の世界線 準委任 一括請負 準委任 準委任 準委任準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 私のオススメ
- 27. 私は疑問 今回の世界線 準委任 一括請負 準委任 準委任 準委任準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 話のネタとして包括的 私のオススメ
- 28.
- 29. Copyright (c) 2011Eiwa System Management, Inc. イテレーション (1週間) の流れ 要求 リリース可能な ソフトウェア Ship It! 次の イテレーションへ 内部リリース ふりかえり ! KPT !ベロシティ バックログ タスク プログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを 書く 受入テストを する " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイク ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。
- 30. Copyright (c) 2011Eiwa System Management, Inc. イテレーション (1週間) の流れ 要求 リリース可能な ソフトウェア Ship It! 次の イテレーションへ 内部リリース ふりかえり ! KPT !ベロシティ バックログ タスク プログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを 書く 受入テストを する " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイク ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。 これはプロジェクトが まわったあとのはなし
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56. • 予算感、体制、期間 …長期もの？短期もの？自社メンバー のみでの開発チームか？内製支援か？ • 技術要素 … 得意な技術か？挑戦しがいのある内容か？ • どんなサービスを作るのか？ … ドメイン知識、共感 • レバー … リリース日やスコープの調整などが可能か？ • 仕舞い方 … リリース後も我々が継続して開発するのか？ 発注元で巻き取られるのか？ 事前確認リスト など
- 57.
- 58. • インセプションデッキを作成する • インセプションデッキくみたての経験者はいた方が良い •ステークホルダー間の認識齟齬を明確にする • お客さま間でも立場によって欲しいものが違っているこ ともある • お客さまの中に熱意のある方がおられれば、作って頂く 事例もある 要件定義開始時の理想 http://www.amazon.co.jp/dp/B00J1XKB6K
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65. • 概算見積り (E和スラング『お見積り』) •予算を取るための見積り • 最初の問い合せで求められる事が多い • 見積り • 計画を立てるための視点 • 追加機能のエンハンスごとに行う ふたつの見積り
- 66. • お見積りと見積りは繋がっている • どう作るか、実現手段の話 •確度が狭まったときにどう振る舞うかの 話から • イテレーションごとの見積りができずに、 お見積りだけできるのか疑問派の視点より まずは お の付かない見積りの話から
- 67.
- 68. Copyright (c) 2011Eiwa System Management, Inc. イテレーション (1週間) の流れ 要求 リリース可能な ソフトウェア Ship It! 次の イテレーションへ 内部リリース ふりかえり ! KPT !ベロシティ バックログ タスク プログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを 書く 受入テストを する " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイク ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。 ここでは現場の見積りの話
- 69. ソフトウェア見積りの理論と実装 https://www.pivotaltracker.com ソフトウェア見積り 人月の暗黙知を解き明かす http://www.amazon.co.jp/dp/489100522X アジャイルな 見積りと計画づくり ∼価値あるソフトウェアを育てる概念と技法∼ http://www.amazon.co.jp/dp/4839924023 Mike Corn著 Pivotal Tracker SteveMcConnel著 安井力／角谷信太郎 (翻訳)具体的な技法 フレームワーク実装 見積りとは、何であり、 何でないのか
- 70.
- 71.
- 72.
- 73.
- 74. • 誰がユーザーストーリーを作るの？ • 理想は要求者となる顧客だと考えているが、私が 関わったプロジェクトでは、顧客が書いたExcel やITSなどを元にヒアリングして、開発者が作る ことが多い •出ている要件を見積れる粒度で練り直しすことは ままある • ストーリーの見積り 交換できるためにも見積る
- 75. • ストーリーを書くのは要件定義、見積りは設計行為 • 見積りする人と実装する人を分けない •どう作るかの実現を背景にするのが見積り • 掛かる工数の説明責任を果たせるようにする • 竹内予言「プログラムを書いたことがないシステム エンジニアが威張っているような会社は早晩滅びる」 見積りは開発者の仕事
- 76.
- 77.
- 78.
- 79.
- 80. • 基本的にすべてが はじめてやること • 同じものを3回作れればうまいことやれそう感 • 現実は1回勝負 • リスクのないプロジェクトはない • リスクを受け入れよう • そのうえで見積りを行って計画づくりをする ソフトウェア開発の難しさ http://upload.wikimedia.org/wikipedia/commons/c/c7/Explosions.jpg
- 81.
- 82.
- 83. 私は疑問 今回の世界線 準委任 一括請負 準委任 準委任 準委任準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 私のオススメ
- 84. 一括請負 ハイブリッド 準委任 一括請負 準委任 準委任 準委任準委任 準委任 一括請負 機能ロックを遅らす イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 準委任で継続
- 85. 今回の世界線 準委任 一括請負 リスクヘッジ 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積りと 仕様 未凍結 へのリスクヘッジする Lock! 0.25x 4x 2x 0.5x 1.0x 1.25x 0.8x 情報を集めて、やること、やらないことの 意思決定を進めて行く中でコーンを狭めて 行ける 見通しを立てるために やることを整理するターン
- 86. • ユーザーストーリー出し • スコーピング… やること/やらないこと • アーキテクチャの検証 • 技術的リスク 準委任の間にどこまでやるの？ プロジェクト後半で炎上しそうな ことを、選択肢の多いプロジェクト の頭に検証しておく
- 87.
- 88.
- 89. • 要員 x期間 = 一括請け負い金額 • リーダー単価 x千円、エンジニア単価 y千円 • 一括請け負い金額を、epicベースのポイント比率で割って機能ご との金額を算出する • 管理工数、デザイン工数、インフラ工数、テスト工数、文書量 や管理画面の要件整理を忘れずに • 全体で3,000千円、全150ポイント、うち機能Aは30ポイント、 機能Bは20ポイント、それぞれの機能はおいくらでしょう？ • 機能Aは600千円、機能Bは400千円 一括請け負いの公式
- 90. • 人月単価をストーリーポイントで割ってお値段 を出す手法への疑問 • 0ポイントはおいくら？ •0はいくつ足しても0にしかならない? • ソフトウェアの工数はそんなに単純ではない • 見積りとコミットメント同視への危険さ 計算できることは明瞭に繋がらない
- 91.
- 92.
- 93. • 基本は最小のユーザーストーリーのみ 見積りたいが、そうはいかないときも ある • 予算確保のために、ぜんぶ見積って •ぜんぶの要求が出るということはない 大きいままでは食べられないけど…
- 94. • 期日までに全部見積れない場合 • 見積りは常にリスクとコストの天をとる • 30のストーリーがある、10のストーリーの合計が 15pt。残りがだいたい同じくらい難しいようであれば ざっくり3倍して 45ptくらいにはなりそう • もちろん単純に3倍したらそうなるわけでないことは伝 える • でもだいたい大きくはズレない ぜんぶ見積れないよ
- 95.
- 96.
- 97.
- 98.
- 99.
- 100.
- 101. ビジネス (お金) と開発(現場) を繋ぐ架け橋 契約
- 102. • 契約上、納品が定まっている機能スコープは必 ず押さえておかなければならない • フィードバックを優先して行っていて円満に進 んでいるようでしたが、契約書に書かれている 機能ができていません！(炎上、信頼関係の決 壊、どちらがお金を持ち出す？) • 大なり小なりフィードバックを受けるには、機 能スコープとのバーターを握っておく 契約が現場に与える影響
- 103.
- 104.
- 105.
- 106.
- 107.
- 108. うーん >< 今回の世界線 準委任 一括請負 準委任 準委任準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 私のオススメ
- 109. 私のオススメ うーん >< 今回の世界線 準委任 一括請負 準委任 準委任準委任 準委任 準委任 一括請負 決定を遅らせよ イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock!
- 110. • 必要なものを必要な段階になってか ら作ることに決めた方が良い • リリースサイクルと契約を分けて考え た方が高いアジリティを実現できる •一括請負時でもこまめなリリースを 拒否された事はない 決定を遅らせよ
- 111. •契約と関係のないタイミングで順次リリース できる •契約単位とは別に必要なタイミングでリリー スを行っていきたいという提案で NG が出 たことはない •契約更新の度に、n人mヶ月後に向けたす べて 行う必要があるか分からないお見積り に時間を割かなくても良い 契約とリリース
- 113.
- 114.
- 115.
- 116.
- 117.
- 118.
- 119.
- 120.
- 121. • 間違ったものを正しく作ってしまう怖さ • ユーザー自身が本当に欲しいものが分からないことも •ないものは評価できませんね • 複雑な仕様はシンプルな仕様にできないか考える • 複雑な仕様はだいたい拡張しづらい、使いづらい • 実はExcelでよかったり、既存機能でまかなえたり • コミットメッセージへのWhyも大事ですね Whyは必ず確認する
- 122.
- 123.
- 124.
- 125.
- 126.
- 127.
- 128.
- 129.
- 130.
- 131.
- 132.
- 133.
- 134.
- 135.
- 136.
- 137.
- 138.
- 139.
- 141. 一括請負 ハイブリッド 準委任 一括請負 準委任 準委任 準委任準委任 準委任 一括請負 あなたの好む契約形態は？ イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 準委任で継続