1. 開発プロジェクトの進め方 Preferred Infrastructure 西鳥羽二郎

2. 自己紹介 西鳥羽二郎 (Twitter ID: jnishi) Professional and Support Service部 検索エンジンSedueの導入支援 製品サポート Sedueを用いた開発案件のプロジェクト支援 プロジェクトマネジメント カスタマイズ開発

3. 今日のお話 開発プロジェクトの進み方 案件の始まりから終わりまで プロジェクトを進める際に気をつけていること 提案内容の精査 開発時の順番

4. 案件の流れ(ウォーターフォール) 見込み客の確保 ヒアリング 要件 必要な機能 制限 予算 スケジュール 開発 テスト 納品 検収 要件定義 製造 納品/検収 営業 設計

5. 営業 見込み客(リード)を集める イベントによる宣伝 ホームページからの問い合わせ 商品の説明 etc… 特に興味を持ったお客様には直接訪問 詳しい商品説明 現状の課題のヒアリング 例「社内にドキュメントがあるはずなのにみんなそれを活用してないんだよね」

6. 要件定義 顧客の要望をシステムで実現できる形にブレークダウンする ソフトウェアが実現できなければならない機能の洗い出し 「データベースからデータを取得し、全文検索を行えるようにしなければならない」 「検索窓を用意し、ユーザーが検索窓に任意の文字列を入力し、Enterキーを押した時、検索結果表示画面に遷移し、入力文字列を本文に含む文書の中から10件表示する」 「複数台構成にし、フェイルオーバー機能を有する」 下記のトレードオフ 顧客にとって必要な機能 自分たちで実現できること コスト スケジュール

7. 設計 要件定義で挙げられた機能を実現する方法を考えること 「それ、Sedueでできるよ」 「GETのq=のパラメータで検索文字列を受け取って、Sedueのクエリに変換して問い合わせて結果を取得してhtmlに変換して返せばできる」 「検索サーバーを2台構成にしておけば冗長性は確保されるね」 「キーワードでクラス作ってIDも持たせておこう」

8. 開発 要求 / 設計を元に実際に動くものを作る 他の導入作業も含める 環境構築 製品/ 開発物の導入 追加要望 / 修正などの対応も含まれます

9. 納品 / 検収 納品: 開発した成果物を顧客に渡す(DVDの形が多い) ソースコード ドキュメント 納品書 検収: 納品物の確認が顧客の方で終了したら開発は終了し、対価が支払われる ※ 開発でトラブルが起こると納品 / 検収が遅れて対価の請求が遅れる

10. 案件の流れ 提案!! 見込み客の確保 ヒアリング 要件 必要な機能 制限 予算 スケジュール 開発 テスト 納品 検収 要件定義 製造 納品/検収 営業 設計 契約(=拘束力)の発生 契約なし

11. 提案 要件定義を行なったあたりで提案を行う ここで重要な3要素が決まる 作るもの スケジュール 金額 デスマーチを回避するために開発者は以下のことに行う 実現可能性 コストの見積り 成果物の意識合わせ

12. 不確実性と修正コストの戦い 次の二つのせめぎあい 不確実性=リスクは工程が進むほど 減っていく 修正のコストは工程が進むほど掛かる http://www.pearsoned.co.uk/bookshop/article.asp?item=1370 http://www.atmarkit.co.jp/farc/rensai/bottleneck01/bottleneck01.html

13. プロジェクトマネジメントの肝 工程を進める方が不確実性は小さくなっていく なるべく早く工程を進めたほうがリスクの洗い出しが早くできる 修正のコストが小さい上流工程のうちに修正をする 要件定義や設計に時間をかけて修正や懸案事項の洗い出しを行うほうが良い 如何に上記のバランスをとるかが肝になってくる

14. 実際の進め方 提案!! 要件定義 製造 納品/検収 営業 設計 機能1 機能2 機能3 リリースを細かく分けて、一気に 設計->製造->リリースを行わずに 機能毎に設計->製造->リリースを 行う 提案前に設計も行う

15. 提案時 提案内容作成の材料 開発項目の列挙 開発工数 スケジュール デスマーチを回避できるかどうかは提案内容が肝(大事なこry 顧客と開発側で想定していたものが違っていた 作り始めてみたら後から後から必要なものが出てくる 提案終了->契約後に変更するのは大変な労力がかかる

16. 見積り 「優れた見積りは信頼性の高い設計と要求が揃って初めて得られる」(アートオブプロジェクトマネジメント) 見積もり時には必ず担当する開発者を巻き込む 可能な限り設計を行う 設計が変わりうる不明な点が出てきたら要求を確認する 前提条件として記載 顧客に問い合わせる 要求が実現できるかも精査 項目を細分化する 詳細まで踏み込んだほうが精度が上がる 作るものへの理解が進むほどよい見積りができる

17. 製造 機能毎に開発 リスクが大きいところから設計、実装 変更があった時に他への影響がでかい 実装コストがかかる 目に見えにくい / 想像しにくい -> 漏れや勘違いが多い 逆に実物を見なくても想像しやすく変更が起こりそうなところは後回し 実装前のほうが対処しやすい 機能毎にリリース 検証環境を用意し、順次リリースしてなるべく早く顧客に見せる

18. 仕様変更 仕様変更は避けられない 時間と共に状況が変わる 細部まで考えが行き届くまで時間がかかる 作ってみて初めて分かることもある

19. 仕様変更 変更や検討漏れがあった際 下記の要素を鑑みて対処法を検討 必要な機能かどうか 実現する為のコスト(規模, 設計時 < 実装時 < 検証時) 顧客と交渉 取り決めた仕様のままにする 修正して対応する 顧客/ユーザー/開発へのインパクトの理解が深いほど交渉が容易 (インパクトがでかいものは要件定義/設計で無くしていることが前提)

20. プロジェクト終了後 振り返り -> 次の提案時に反映 工数が大きかった変更 要件定義の段階で潰せなかったか 変更が多かった箇所 顧客の方で検討してもらうことで時間がかかる /変更が多かったもの-> 検討だけは先にやってもらい、着手を後回し 作ってみなければ分からない -> 作りなおすこと前提で工数をつむ、優先して開発を行う

21. 失敗例集 見積もりが大雑把すぎた 「うーん、全部で3ヶ月くらいあればできるんじゃない?」 作業量の見積りは悪くなかったが、時間を確保できなかった 「これは2週間あればできますね」-> 背後に締切の近いものを幾つか抱えていて時間がかけられなかった 無駄に要件を厳しくしていた 参照系 / 更新系に分けた構成で更新系まで冗長化を要件に入れてしまった-> 本当はそこまでの耐障害性は必要なかったはず

22. まとめ プロジェクトの進め方 営業->要件定義->設計->開発->納品->検収 提案内容が命 関係者をちゃんと巻き込みましょう 時間をかけて要件を詰める 後工程に進むほど不確実性が無くなる 要件定義/設計の段階で不明瞭なところを潰す 開発時はリスクの大きいところから着手する 開発規模は小さいほうがリスクは少なく変化に強いため可能ならアジャイルのほうがおすすめです

23. ご清聴ありがとうございました 参考文献は後日Preferred Research blogに掲載します