俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
•
11 recomendaciones•6,621 vistas
XP祭り 2015 (http://xpjug.com/xp2015/)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a 俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
Similar a 俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜 (20)
Más de Koichi ITO
Más de Koichi ITO (20)
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
- 1. 早稲田大学理工学部キャンパス (株) 永和システムマネジメント アジャイル事業部 Ruby x Agile グループ 伊藤 浩一 (@koic) 2015.09.12 (Sat) XP祭り 2015 over contact negotiation Customer collaboration 準委任契約によるふつうのソフトウェア開発 俺も受託開発
- 3. Computer programmer, guitarist. Leader of 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 ここ一年の活動範囲
- 8. TO MAKE THE END OF DECADE 2015.09.12
- 14. 今日の話
- 17. •開発者 •受注側 私の立ち位置
- 18. 所属事業部の昨年度の契約比率
- 21. 俺も!!
- 25. 一括請負 ハイブリッド 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 準委任で継続
- 26. 私は疑問 今回の世界線 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 私のオススメ
- 27. 私は疑問 今回の世界線 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 話のネタとして包括的 私のオススメ
- 28. 契約と現場
- 29. Copyright (c) 2011 Eiwa System Management, Inc. イテレーション (1週間) の流れ 要求 リリース可能な ソフトウェア Ship It! 次の イテレーションへ 内部リリース ふりかえり ! KPT !ベロシティ バックログ タスク プログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを 書く 受入テストを する " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイク ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。
- 30. Copyright (c) 2011 Eiwa System Management, Inc. イテレーション (1週間) の流れ 要求 リリース可能な ソフトウェア Ship It! 次の イテレーションへ 内部リリース ふりかえり ! KPT !ベロシティ バックログ タスク プログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを 書く 受入テストを する " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイク ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。 これはプロジェクトが まわったあとのはなし
- 34. •リリースできそう感あるか •どういったフォーメーショ ンならまわせそうか • Go or No go くみたて
- 41. 引き合い 第1節
- 48. @afukui degree n
- 53. 誰と重要 @beakmark
- 54. ヒアリング 第2節
- 56. • 予算感、体制、期間 … 長期もの？短期もの？自社メンバー のみでの開発チームか？内製支援か？ • 技術要素 … 得意な技術か？挑戦しがいのある内容か？ • どんなサービスを作るのか？ … ドメイン知識、共感 • レバー … リリース日やスコープの調整などが可能か？ • 仕舞い方 … リリース後も我々が継続して開発するのか？ 発注元で巻き取られるのか？ 事前確認リスト など
- 58. • インセプションデッキを作成する • インセプションデッキくみたての経験者はいた方が良い • ステークホルダー間の認識齟齬を明確にする • お客さま間でも立場によって欲しいものが違っているこ ともある • お客さまの中に熱意のある方がおられれば、作って頂く 事例もある 要件定義開始時の理想 http://www.amazon.co.jp/dp/B00J1XKB6K
- 65. • 概算見積り (E和スラング『お見積り』) • 予算を取るための見積り • 最初の問い合せで求められる事が多い • 見積り • 計画を立てるための視点 • 追加機能のエンハンスごとに行う ふたつの見積り
- 66. • お見積りと見積りは繋がっている • どう作るか、実現手段の話 • 確度が狭まったときにどう振る舞うかの 話から • イテレーションごとの見積りができずに、 お見積りだけできるのか疑問派の視点より まずは お の付かない見積りの話から
- 68. Copyright (c) 2011 Eiwa 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 Steve McConnel著 安井力／角谷信太郎 (翻訳)具体的な技法 フレームワーク実装 見積りとは、何であり、 何でないのか
- 71. 3秒見積り依頼への回答 「後ほど御持ちします」です。 (達人プログラマー p69より) 即興の見積りは止めよう。たっ た15分の見積りでさえ、もっ と正確だ。 (ソフトウェア見積り p57より)
- 74. • 誰がユーザーストーリーを作るの？ • 理想は要求者となる顧客だと考えているが、私が 関わったプロジェクトでは、顧客が書いたExcel やITSなどを元にヒアリングして、開発者が作る ことが多い • 出ている要件を見積れる粒度で練り直しすことは ままある • ストーリーの見積り 交換できるためにも見積る
- 75. • ストーリーを書くのは要件定義、見積りは設計行為 • 見積りする人と実装する人を分けない • どう作るかの実現を背景にするのが見積り • 掛かる工数の説明責任を果たせるようにする • 竹内予言「プログラムを書いたことがないシステム エンジニアが威張っているような会社は早晩滅びる」 見積りは開発者の仕事
- 80. • 基本的にすべてが はじめて やること • 同じものを3回作れればうまいことやれそう感 • 現実は1回勝負 • リスクのないプロジェクトはない • リスクを受け入れよう • そのうえで見積りを行って計画づくりをする ソフトウェア開発の難しさ http://upload.wikimedia.org/wikipedia/commons/c/c7/Explosions.jpg
- 83. 私は疑問 今回の世界線 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 私のオススメ
- 84. 一括請負 ハイブリッド 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 機能ロックを遅らす イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 準委任で継続
- 85. 今回の世界線 準委任 一括請負 リスクヘッジ 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! 0.25x 4x 2x 0.5x 1.0x 1.25x 0.8x 情報を集めて、やること、やらないことの 意思決定を進めて行く中でコーンを狭めて 行ける 見通しを立てるために やることを整理するターン
- 86. • ユーザーストーリー出し • スコーピング … やること/やらないこと • アーキテクチャの検証 • 技術的リスク 準委任の間にどこまでやるの？ プロジェクト後半で炎上しそうな ことを、選択肢の多いプロジェクト の頭に検証しておく
- 89. • 要員 x 期間 = 一括請け負い金額 • リーダー単価 x千円、エンジニア単価 y千円 • 一括請け負い金額を、epicベースのポイント比率で割って機能ご との金額を算出する • 管理工数、デザイン工数、インフラ工数、テスト工数、文書量 や管理画面の要件整理を忘れずに • 全体で3,000千円、全150ポイント、うち機能Aは30ポイント、 機能Bは20ポイント、それぞれの機能はおいくらでしょう？ • 機能Aは600千円、機能Bは400千円 一括請け負いの公式
- 90. • 人月単価をストーリーポイントで割ってお値段 を出す手法への疑問 • 0ポイントはおいくら？ • 0はいくつ足しても0にしかならない? • ソフトウェアの工数はそんなに単純ではない • 見積りとコミットメント同視への危険さ 計算できることは明瞭に繋がらない
- 93. • 基本は最小のユーザーストーリーのみ 見積りたいが、そうはいかないときも ある • 予算確保のために、ぜんぶ見積って • ぜんぶの要求が出るということはない 大きいままでは食べられないけど…
- 94. • 期日までに全部見積れない場合 • 見積りは常にリスクとコストの天 をとる • 30のストーリーがある、10のストーリーの合計が 15pt。残りがだいたい同じくらい難しいようであれば ざっくり3倍して 45ptくらいにはなりそう • もちろん単純に3倍したらそうなるわけでないことは伝 える • でもだいたい大きくはズレない ぜんぶ見積れないよ
- 98. 契約 第4節
- 101. ビジネス (お金) と開発 (現場) を繋ぐ架け橋 契約
- 102. • 契約上、納品が定まっている機能スコープは必 ず押さえておかなければならない • フィードバックを優先して行っていて円満に進 んでいるようでしたが、契約書に書かれている 機能ができていません！ (炎上、信頼関係の決 壊、どちらがお金を持ち出す？) • 大なり小なりフィードバックを受けるには、機 能スコープとのバーターを握っておく 契約が現場に与える影響
- 103. 2005.12.16
- 106. 欲しい物の優先順位は変わる ある時点で欲しかったものが手に入る時期に欲しいと限らない expected actual 変わるといっても この程度でしょ？ 使われるまでの期間が 長いほど変わる
- 107. EMBRACE CHANGE
- 108. うーん >< 今回の世界線 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 私のオススメ
- 109. 私のオススメ うーん >< 今回の世界線 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 決定を遅らせよ イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock!
- 110. • 必要なものを必要な段階になってか ら作ることに決めた方が良い • リリースサイクルと契約を分けて考え た方が高いアジリティを実現できる • 一括請負時でもこまめなリリースを 拒否された事はない 決定を遅らせよ
- 111. •契約と関係のないタイミングで順次リリース できる •契約単位とは別に必要なタイミングでリリー スを行っていきたいという提案で NG が出 たことはない •契約更新の度に、n人mヶ月後に向けた す べて 行う必要があるか分からないお見積り に時間を割かなくても良い 契約とリリース
- 115. リリース 第5節
- 119. トヨタ式 5W1H
- 121. • 間違ったものを正しく作ってしまう怖さ • ユーザー自身が本当に欲しいものが分からないことも • ないものは評価できませんね • 複雑な仕様はシンプルな仕様にできないか考える • 複雑な仕様はだいたい拡張しづらい、使いづらい • 実はExcelでよかったり、既存機能でまかなえたり • コミットメッセージへのWhyも大事ですね Whyは必ず確認する
- 125. Whole Team 受託顧客
- 126. Whole Team 受託顧客
- 132. おわりに
- 136. 誰と重要 @beakmark
- 137. XPE2ndと読書会がついてきます
- 141. 一括請負 ハイブリッド 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 あなたの好む契約形態は？ イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 準委任で継続