Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜

3,769 views

Published on

XP祭り 2015 (http://xpjug.com/xp2015/)

Published in: Engineering

俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜

  1. 1. 早稲田大学理工学部キャンパス (株) 永和システムマネジメント アジャイル事業部 Ruby x Agile グループ 伊藤 浩一 (@koic) 2015.09.12 (Sat) XP祭り 2015 over contact negotiation Customer collaboration 準委任契約によるふつうのソフトウェア開発 俺も受託開発
  2. 2. この発表は個人の見 解であり、所属する 企業・事業部の総意 見解ではありません
  3. 3. Computer programmer, guitarist. Leader of an Agile software development team at Eiwa System Management, Inc. Lives in Shinjuku. @koic photo token by @NaCl
  4. 4. • 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 ここ一年の活動範囲
  5. 5. 表参道.rb ! ! 毎月 第一木曜日 開催https://twitter.com/joker1007/status/639480386192408576
  6. 6. TO MAKE THE END OF DECADE 2015.09.12
  7. 7. http://www.amazon.co.jp/dp/4274217620
  8. 8. XPE2ndと読書会がついてきます
  9. 9. XPに詳しい上司もついてきます https://pbs.twimg.com/media/CIZYfj6W8AAqyAU.jpg
  10. 10. 今日の話
  11. 11. 今年のテーマは「俺も!!」ということで、去年のXP祭り 2014で同僚の木下史彦さんによる『俺の価値創造契約』の講 演に刺激を受けたものです。 私がこれまで従事したプロジェクトでは『価値創造契約』を " もちいない" 契約形態での受託開発を行っております。スター トアップによるサービス開発が隆盛の一方、何十年と日本の土 壌で培ってきた『人月』と『人情』をベースに『準委任契約』 で如何にアジャイルな受託開発にしていけるか挑戦し続けてい るお話をします。 多くの受託開発でのプロジェクトが採用している契約形態の中 での創意工夫と現場で過ごす方々への勇気を、XPから学び大 切にしていることと共に伝えられれば幸いです。 2015年5月11日提出のCFPより
  12. 12. •私の経験からの話 •受託開発での開発者 •4∼8人程度の規模 背景
  13. 13. •開発者 •受注側 私の立ち位置
  14. 14. 所属事業部の昨年度の契約比率
  15. 15. 私が過去10年で従事したプロジェクト
  16. 16. 本日お話ししないこと 商談 新しい契約形態での受託開発サービス 価値創造契約 @fkinoまでどうぞ
  17. 17. 俺も!!
  18. 18. 本日お話しすること 商談 伝統の契約形態での受託開発サービス 準委任契約 一括請負契約 @fkinoまでどうぞ
  19. 19. ユーザーストーリーを交 換可能とする、アジャイ ルソフトウェア開発には 準委任契約が向いている 私の結論
  20. 20. 一括請負 ハイブリッド 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 準委任で継続
  21. 21. 私は疑問 今回の世界線 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 私のオススメ
  22. 22. 私は疑問 今回の世界線 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 話のネタとして包括的 私のオススメ
  23. 23. 契約と現場
  24. 24. Copyright (c) 2011 Eiwa System Management, Inc. イテレーション (1週間) の流れ 要求 リリース可能な ソフトウェア Ship It! 次の イテレーションへ 内部リリース ふりかえり ! KPT !ベロシティ バックログ タスク プログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを 書く 受入テストを する " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイク ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。
  25. 25. Copyright (c) 2011 Eiwa System Management, Inc. イテレーション (1週間) の流れ 要求 リリース可能な ソフトウェア Ship It! 次の イテレーションへ 内部リリース ふりかえり ! KPT !ベロシティ バックログ タスク プログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを 書く 受入テストを する " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイク ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。 これはプロジェクトが まわったあとのはなし
  26. 26. 要求 リリース可能な ソフトウェア
  27. 27. 要求 リリース可能な ソフトウェア 今日はプロジェクトが まわる前と後の話中心
  28. 28. https://www.flickr.com/photos/library_of_congress/2179221438/in/photolist-4jz5Bq-4jyCmM-4jyiUr-4jCmGy-4jyist-8UDTGq-4jv49F-4jyjbp-jYZGfu-4jyiS6-4jv2NT-4jyiHr-ipaFQK-nZB5W9-nZBbBN-eavxhQ-4jyjFT-4jz9tq-87G2rd-4jz7Mm-4jyiP2-4jyiLr-4jCmKf-9saiMG-4jz8df-buYYJ6-fpYfKW-of2iyd-owvTqB-wXBhQ2-oeSewq-ouyVuG-ouLYBR-ouKkN9-4jv3vD-qQXejT-vGg49h-fqmDCP-afobYE-osK4Zb-ouu3E5-owvSZB-of2SoF-osK5ry-owwNYB-odhpwi-ouQqQ2-ovEveB-odDKss-odDxby
  29. 29. •リリースできそう感あるか •どういったフォーメーショ ンならまわせそうか • Go or No go くみたて
  30. 30. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り くみたて(立ち上げ周辺)の流れ
  31. 31. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り 1. 引き合い
  32. 32. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り 2. ヒアリング
  33. 33. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り 3. お見積り
  34. 34. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り 4. 契約
  35. 35. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り 5. リリース
  36. 36. 引き合い 第1節
  37. 37. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り くみたて(立ち上げ周辺)の流れ
  38. 38. http://agile.esm.co.jp/docs/business_plan_esm_agile_div_36th.pdf オレ達の受託 生態系
  39. 39. ? なぜそんなにも (ソフトウェア開発ビジネス にとって) コミュニティは重要なのか
  40. 40. ここで質問です 初めてお付き合いする 企業Aさんと企業Bさ んどちらとお仕事をす ると成功するでしょう?
  41. 41. 発注側も受注側も 博打https://en.wikipedia.org/wiki/Dice#/media/File:6sided_dice.jpg
  42. 42. •リピータ •コミュニティ繋がりの紹介 •既存顧客からの横展開 博打のリスクヘッジ
  43. 43. @afukui degree n
  44. 44. •信頼できる人からの距離 •できる人ができると言って いる人 •サービスか受託かではない ある人と何ホップで繋がっている?
  45. 45. http://agile.esm.co.jp/docs/business_plan_esm_agile_div_36th.pdf オレ達の受託 生態系
  46. 46. http://mugiwara.jp/ki2/wifky.pl?p=ExtremeExperience
  47. 47. A なぜそんなにも (ソフトウェア開発ビジネス にとって) コミュニティは重要なのか
  48. 48. 誰と重要 @beakmark
  49. 49. ヒアリング 第2節
  50. 50. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り くみたて(立ち上げ周辺)の流れ
  51. 51. • 予算感、体制、期間 … 長期もの?短期もの?自社メンバー のみでの開発チームか?内製支援か? • 技術要素 … 得意な技術か?挑戦しがいのある内容か? • どんなサービスを作るのか? … ドメイン知識、共感 • レバー … リリース日やスコープの調整などが可能か? • 仕舞い方 … リリース後も我々が継続して開発するのか? 発注元で巻き取られるのか? 事前確認リスト など
  52. 52. https://ja.wikipedia.org/wiki/%E6%B0%B8%E5%B9%B3%E5%AF%BA#/media/File:Eiheiji37nt3200.jpg
  53. 53. • インセプションデッキを作成する • インセプションデッキくみたての経験者はいた方が良い • ステークホルダー間の認識齟齬を明確にする • お客さま間でも立場によって欲しいものが違っているこ ともある • お客さまの中に熱意のある方がおられれば、作って頂く 事例もある 要件定義開始時の理想 http://www.amazon.co.jp/dp/B00J1XKB6K
  54. 54. https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck
  55. 55. インセプションデッキ作りで初 期の不確実性のコーンを狭める
  56. 56. 0 インセプション デッキ作りへの マイナス評価の お客様数はゼロ
  57. 57. https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck
  58. 58. お見積り (前編) 第3節 この章はちょっと長いですよ
  59. 59. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り くみたて(立ち上げ周辺)の流れ
  60. 60. • 概算見積り (E和スラング『お見積り』) • 予算を取るための見積り • 最初の問い合せで求められる事が多い • 見積り • 計画を立てるための視点 • 追加機能のエンハンスごとに行う ふたつの見積り
  61. 61. • お見積りと見積りは繋がっている • どう作るか、実現手段の話 • 確度が狭まったときにどう振る舞うかの 話から • イテレーションごとの見積りができずに、 お見積りだけできるのか疑問派の視点より まずは お の付かない見積りの話から
  62. 62. 現場でのソフトウェア見積り現場でのソフトウェア見積り INTERLUDE お見積りを支える技術
  63. 63. Copyright (c) 2011 Eiwa System Management, Inc. イテレーション (1週間) の流れ 要求 リリース可能な ソフトウェア Ship It! 次の イテレーションへ 内部リリース ふりかえり ! KPT !ベロシティ バックログ タスク プログラミング "機能 "バグ "データ移行 "ドキュメント "環境構築 "性能 "ジョーカー 受入テストを 書く 受入テストを する " 完了基準 ! TDD ! CI ! 仕様の確認 ! 見積り ! スパイク ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた だきながら進めていきます。 ここでは現場の見積りの話
  64. 64. ソフトウェア見積りの理論と実装 https://www.pivotaltracker.com ソフトウェア見積り 人月の暗黙知を解き明かす http://www.amazon.co.jp/dp/489100522X アジャイルな 見積りと計画づくり ∼価値あるソフトウェアを育てる概念と技法∼ http://www.amazon.co.jp/dp/4839924023 Mike Corn著 Pivotal Tracker Steve McConnel著 安井力/角谷信太郎 (翻訳)具体的な技法 フレームワーク実装 見積りとは、何であり、 何でないのか
  65. 65. 見積りは技術 なので身につけられる
  66. 66. 3秒見積り依頼への回答 「後ほど御持ちします」です。 (達人プログラマー p69より) 即興の見積りは止めよう。たっ た15分の見積りでさえ、もっ と正確だ。 (ソフトウェア見積り p57より)
  67. 67. 要件が整理さ れていなけれ ば見積れない
  68. 68. 要件整理はチームの仕事 軽いものは口頭ベースだったり、 重いものはExcelで表されたり 要件次第で 幾度かのやりとり システムの制約を確認したポイント をまとめて、どう作るかを整理した 結果をユーザーストーリーに書く 開発者 顧客 (や企画)
  69. 69. • 誰がユーザーストーリーを作るの? • 理想は要求者となる顧客だと考えているが、私が 関わったプロジェクトでは、顧客が書いたExcel やITSなどを元にヒアリングして、開発者が作る ことが多い • 出ている要件を見積れる粒度で練り直しすことは ままある • ストーリーの見積り 交換できるためにも見積る
  70. 70. • ストーリーを書くのは要件定義、見積りは設計行為 • 見積りする人と実装する人を分けない • どう作るかの実現を背景にするのが見積り • 掛かる工数の説明責任を果たせるようにする • 竹内予言「プログラムを書いたことがないシステム エンジニアが威張っているような会社は早晩滅びる」 見積りは開発者の仕事
  71. 71. エクストリームプログラミング実行計画15ページ 何かをプログラムす る時、どの位かかるか を見積るということは 完全に技術的な決定で ある
  72. 72. http://www.amazon.co.jp/dp/4274217620
  73. 73. お見積り (後編) 第3節 契約に向けたお見積りのお話
  74. 74. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り くみたて(立ち上げ周辺)の流れ
  75. 75. • 基本的にすべてが はじめて やること • 同じものを3回作れればうまいことやれそう感 • 現実は1回勝負 • リスクのないプロジェクトはない • リスクを受け入れよう • そのうえで見積りを行って計画づくりをする ソフトウェア開発の難しさ http://upload.wikimedia.org/wikipedia/commons/c/c7/Explosions.jpg
  76. 76. 1.将来起こりうる出来 事で、望まない結果を 生むもの。2.望まない 結果そのもの。 リスクの定義 『熊とワルツを』17ページより抜粋
  77. 77. 『エクストリームプログラミング』67ページより抜粋 長期的なひとつの契約 ではなく、短期的な契 約をいくつも結ぶよう にしてリスクを減らす こと
  78. 78. 私は疑問 今回の世界線 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 私のオススメ
  79. 79. 一括請負 ハイブリッド 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 機能ロックを遅らす イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 準委任で継続
  80. 80. 今回の世界線 準委任 一括請負 リスクヘッジ 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! 0.25x 4x 2x 0.5x 1.0x 1.25x 0.8x 情報を集めて、やること、やらないことの 意思決定を進めて行く中でコーンを狭めて 行ける 見通しを立てるために やることを整理するターン
  81. 81. • ユーザーストーリー出し • スコーピング … やること/やらないこと • アーキテクチャの検証 • 技術的リスク 準委任の間にどこまでやるの? プロジェクト後半で炎上しそうな ことを、選択肢の多いプロジェクト の頭に検証しておく
  82. 82. • 初期段階での見積り • どうやって金額を決めるの? ソフトウェア開発は繋がっている
  83. 83. お金の話 http://01.gatag.net/img/201507/29l/gatag-00012479.jpg
  84. 84. • 要員 x 期間 = 一括請け負い金額 • リーダー単価 x千円、エンジニア単価 y千円 • 一括請け負い金額を、epicベースのポイント比率で割って機能ご との金額を算出する • 管理工数、デザイン工数、インフラ工数、テスト工数、文書量 や管理画面の要件整理を忘れずに • 全体で3,000千円、全150ポイント、うち機能Aは30ポイント、 機能Bは20ポイント、それぞれの機能はおいくらでしょう? • 機能Aは600千円、機能Bは400千円 一括請け負いの公式
  85. 85. • 人月単価をストーリーポイントで割ってお値段 を出す手法への疑問 • 0ポイントはおいくら? • 0はいくつ足しても0にしかならない? • ソフトウェアの工数はそんなに単純ではない • 見積りとコミットメント同視への危険さ 計算できることは明瞭に繋がらない
  86. 86. 要求エラーか?インシデントか? そんな話はお互い 二の次にしたい 本当にやりたいことを順番をつけて やろう
  87. 87. 準委任契約は浪花節 機能とコストの 間に人情がある
  88. 88. • 基本は最小のユーザーストーリーのみ 見積りたいが、そうはいかないときも ある • 予算確保のために、ぜんぶ見積って • ぜんぶの要求が出るということはない 大きいままでは食べられないけど…
  89. 89. • 期日までに全部見積れない場合 • 見積りは常にリスクとコストの天 をとる • 30のストーリーがある、10のストーリーの合計が 15pt。残りがだいたい同じくらい難しいようであれば ざっくり3倍して 45ptくらいにはなりそう • もちろん単純に3倍したらそうなるわけでないことは伝 える • でもだいたい大きくはズレない ぜんぶ見積れないよ
  90. 90. http://bliki-ja.github.io/YesterdaysWeather/
  91. 91. http://twada.herokuapp.com/presentations/wewlc/twada_savannah_lion.png
  92. 92. 量は質に 転化する @t_wada
  93. 93. 契約 第4節
  94. 94. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り くみたて(立ち上げ周辺)の流れ
  95. 95. ? 成果物を事前に決め ることがアジャイル ソフトウェア開発に 向かないと思う理由
  96. 96. ビジネス (お金) と開発 (現場) を繋ぐ架け橋 契約
  97. 97. • 契約上、納品が定まっている機能スコープは必 ず押さえておかなければならない • フィードバックを優先して行っていて円満に進 んでいるようでしたが、契約書に書かれている 機能ができていません! (炎上、信頼関係の決 壊、どちらがお金を持ち出す?) • 大なり小なりフィードバックを受けるには、機 能スコープとのバーターを握っておく 契約が現場に与える影響
  98. 98. 2005.12.16
  99. 99. http://www.rubyist.net/ matz/slides/oc2005/
  100. 100. http://www.rubyist.net/ matz/slides/oc2005/
  101. 101. 欲しい物の優先順位は変わる ある時点で欲しかったものが手に入る時期に欲しいと限らない expected actual 変わるといっても この程度でしょ? 使われるまでの期間が 長いほど変わる
  102. 102. EMBRACE CHANGE
  103. 103. うーん >< 今回の世界線 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 契約パターン イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 私のオススメ
  104. 104. 私のオススメ うーん >< 今回の世界線 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 決定を遅らせよ イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock!
  105. 105. • 必要なものを必要な段階になってか ら作ることに決めた方が良い • リリースサイクルと契約を分けて考え た方が高いアジリティを実現できる • 一括請負時でもこまめなリリースを 拒否された事はない 決定を遅らせよ
  106. 106. •契約と関係のないタイミングで順次リリース できる •契約単位とは別に必要なタイミングでリリー スを行っていきたいという提案で NG が出 たことはない •契約更新の度に、n人mヶ月後に向けた す べて 行う必要があるか分からないお見積り に時間を割かなくても良い 契約とリリース
  107. 107. 4. 割れた窓を放置し ておかないこと 32. 早めにクラッシュ させること 『達人プログラマー』より抜粋
  108. 108. 契約終了後に対する 瑕疵担保よりも頻繁 にフィードバック得 られる仕組みが大事
  109. 109. リリース 第5節
  110. 110. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り くみたて(立ち上げ周辺)の流れ
  111. 111. ? 作った機能の 「お蔵入り」 ありませんか?
  112. 112. リリース後の運用 イメージをユーザー と合わせる
  113. 113. トヨタ式 5W1H
  114. 114. •Why? •Why? •Why? •Why? •Why? •How? WHAT HOW Why Whyは大方針
  115. 115. • 間違ったものを正しく作ってしまう怖さ • ユーザー自身が本当に欲しいものが分からないことも • ないものは評価できませんね • 複雑な仕様はシンプルな仕様にできないか考える • 複雑な仕様はだいたい拡張しづらい、使いづらい • 実はExcelでよかったり、既存機能でまかなえたり • コミットメッセージへのWhyも大事ですね Whyは必ず確認する
  116. 116. 受入テストと 運用の設計は コインの裏表http://www.public-domain-image.com/free-images/objects/money-bills/money-coins-pictures/penny-cents-copper-lincoln-coin-macro
  117. 117. point リリース後の運用 イメージはユーザー と合っているか?
  118. 118. 運用が最上流 @amapyon http://objectclub.jp/ml-arch/magazine/98.html
  119. 119. Whole Team 受託顧客
  120. 120. Whole Team 受託顧客
  121. 121. 長く続けてこその アジャイルチーム 阿吽の呼吸 リピータのお客様の言葉
  122. 122. http://www.agilemanifesto.org/
  123. 123. http://bliki-ja.github.io/PleasingTheCustomer/
  124. 124. 開発マネージャーたちは、どうすれば開発チーム を動機付け、励ますことが出来るのか、一生懸命 考えなさい、と。 ! それには、開発者たちと顧客を結びつければよい のです。 私が知っている開発者はみんな、自分た ちの仕事が実際に使用され、価値をもつことを楽 しんでいます。 顧客から「あなたのソフトウェア のおかげで仕事が楽しくなったわ」と言われたり、 そのソフトウェアがビジネスに利益をもたらした りする以上の喜びはありません。 http://bliki-ja.github.io/PleasingTheCustomer/
  125. 125. 要求 リリース可能な ソフトウェア引き合い リリース ヒアリング 契約 お見積り リリースを続ける中で チームは熟達していく
  126. 126. おわりに
  127. 127. https://twitter.com/koic/status/638710919992864768
  128. 128. ソフトウェアは 人が人のために 作るもの ―Kenji Hiranabe
  129. 129. http://agile.esm.co.jp/docs/business_plan_esm_agile_div_36th.pdf オレ達の受託 生態系
  130. 130. 誰と重要 @beakmark
  131. 131. XPE2ndと読書会がついてきます
  132. 132. XPに詳しい上司もついてきます https://pbs.twimg.com/media/CIZYfj6W8AAqyAU.jpg
  133. 133. 本日お話ししたこと 商談 伝統の契約形態での受託開発サービス 準委任契約 一括請負契約 @fkinoまでどうぞ
  134. 134. 一括請負 ハイブリッド 準委任 一括請負 準委任 準委任 準委任 準委任 準委任 一括請負 あなたの好む契約形態は? イテレーションごとに必要なものから必要なぶん見積る 実装が始まるより前の初期に一括で見積る というよりは、確度の低い見積りの段階で お品書きがロックされる 不確実性のコーンをある程度狭めた状態で 始めることで 確度の低い見積り と 仕様 未凍結 へのリスクヘッジする Lock! Lock! 準委任で継続

×