Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a アジャイル事例紹介
Semelhante a アジャイル事例紹介 (20)
Último
Último (12)
アジャイル事例紹介
- 1. Copyright © 2016 NTT DATA CCS Corporation アジャイル開発 事例紹介 安心・安全な開発を目指して 2016年11月19日（土） 株式会社NTTデータCCS コンシューマシステム事業部 第3システム開発部 森 達彦
- 2. 2Copyright © 2016 NTT DATA CCS Corporation 安心・安全とは 安心とは 「心配・不安がなくて、心が安らぐこと」 安全とは 「安らかで危険がないこと」 お客様 開発側 プロジェクト期間を通し、お客様に安心いただき、安全に開発を進める。 安心 安全 アジャイル開発プロセスで実現 Copyright © いらすとや （広辞苑）
- 3. 3Copyright © 2016 NTT DATA CCS Corporation 簡単に会社紹介と自己紹介 森 達彦 業務系システム開発に従事 ・ ウォータフォール型開発を約20年 ・ Unified Processで社内開発標準作り、開発を約3年 ・ アジャイル開発を試行錯誤しながら約５年 株式会社NTTデータCCS 株主：株式会社NTTデータ（60%）、JXアイティソリューション株式会社（40%） ・NTTデータグループの総合力を活かした、様々な業界のシステム提案/開発/保守/運用 ・総合エネルギー・資源・素材企業グループであるJXグループのシステム提案/開発/保守/運用 JXグループ向け事業ビジネスシステム事業X アジャイル推進部隊 http://www.nttdata-ccs.co.jp/
- 4. Copyright © 2016 NTT DATA CCS Corporation 4 当社のアジャイルまでの道のり（これも簡単に）
- 5. 5Copyright © 2016 NTT DATA CCS Corporation 開発プロセスへの悩み（～ 2001年） 全てのプロジェクトがウォーターフォール（滝）型プロセスを採用 プロジェクト失敗 / 敗因分析 仕様変更に伴う手戻り作業の増加（下流工程ほど深刻） 顧客（ユーザ）とSIer（開発者）の仕様（イメージ）認識齟齬による作り直し 実装不可能な設計の発覚、要求された性能が出ない 誰も必要としていないドキュメントの作成 計画への不信感の増大 道のり ～ウォーターフォール適用期～
- 6. 6Copyright © 2016 NTT DATA CCS Corporation 開発標準（2002年～2005年） プロセスのリファレンスモデルとしてUPを採用 Coup［ku:] 反復開発 要求駆動開発（ユースケース駆動開発） コンポーネントベース開発 視覚的モデリング ドキュメント：スケッチと設計書 DOAとOOの融合 ※ ※事例 - 「DOAとUMLを“いいとこ取り”：IT Pro」 http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040128/1/ 道のり ～開発標準適用期～ Unified Process（UP）、Coup［ku:］
- 7. 7Copyright © 2016 NTT DATA CCS Corporation アジャイル開発への挑戦（2005年～） QCDSの目標達成より価値の獲得 変化を受け入れる プロセスからプラクティスへ ⇒ 軽量なプロセスと多様なプラクティスの採用 重量な規約からシンプルで軽量な約束ごと プロジェクト・ポータルサイトによるコミュニケーション 道のり ～アジャイル開発適用期～ ウォーターフォール アジャイル 価値
- 8. Copyright © 2016 NTT DATA CCS Corporation 8 事例紹介
- 9. 9Copyright © 2016 NTT DATA CCS Corporation 本日お話する内容 1. プロジェクト紹介 2. アジャイル開発プロセスの提案 3. 安心・安全を目指して実践した内容 4. 不安にさせてしまった 5. プロジェクトをふりかえって 全71ページ
- 10. 10Copyright © 2016 NTT DATA CCS Corporation 安心・安全な開発を目指して １．プロジェクト紹介
- 11. 11Copyright © 2016 NTT DATA CCS Corporation プロジェクト紹介 システム特性 業種：サービス業における会員管理業務 言語：Ｃ＃ 規模：約６００ＦＰ、４０機能、４０テーブル 期間：８ヶ月（イテレーション期間は３．５ヶ月） システム構成：Ｗｅｂシステム プロジェクト特性 開発形態：新規（再構築） 体制：お客様側 - 3名（エンドユーザー除く） 開発側 - 4名 ～ 10名（うち協力会社3名） アジャイル開発経験者：4名 プロジェクト体制と契約形態 お客様 NTTDCCS 協力会社 SES、請負※ SES 開発側 ※ 要件定義はSES契約で実施
- 12. 12Copyright © 2016 NTT DATA CCS Corporation プロジェクト紹介 １．現行のドキュメントが陳腐化している 仕様は運用担当の頭の中にあり、仕様が開発側に伝わらない可能性がある 運用担当も部分的にうろ覚えがある ２．新規要件の確定までに時間が掛かる 一部の新規要件は時間を掛けて決めたい 全ての新規要件が決まるまで作業が止まってしまうのは不安 メンテナンスされず放置 プログラムだけがメンテされ続けている 複数の部門が絡むので調整に 時間が掛かりそうです。 お客様の不安（４点）
- 13. 13Copyright © 2016 NTT DATA CCS Corporation ３．厳しい性能要件がある 本番環境はオンプレミスのため、容易にスケールアウトなどの対応ができない 要求した性能が実現できるのか不安 ４．開発プロジェクトで失敗している ウォータフォール型で大失敗した経験があり、システム開発が不安 （終盤で重大な問題が発生し、C/O延長など手を尽くしたが断念） 早く！でもハードが心配・・ あと一歩のところでつまずき、大きな怪我をしてしまった プロジェクト紹介
- 14. 14Copyright © 2016 NTT DATA CCS Corporation ２．アジャイル開発プロセスの提案 安心・安全な開発を目指して
- 15. 15Copyright © 2016 NTT DATA CCS Corporation アジャイル開発プロセスの提案 お客様の不安 ウォーターフォール アジャイル 現行のドキュメントが 陳腐化している ・上流工程で全ての仕様が明確にでき、 確定後ぶれることが無ければ○ ・仕様が曖昧な状態で開発が進むと下流工 程からの手戻りが多くなり× ・ドキュメントではなく実際に動くソフトウェアで 動作確認できるので仕様の認識違いや漏れ に気づきやすく○ ・お客様が頻繁に動作確認するため、負担が 大きくなり× 新規要求の確定までに 時間が掛かる 要求仕様が確定するまで待つことで、全体的 な整合が取りやすく、品質は良くなり○ 要求内容が確定するまで次のフェーズに進めず、 待ちの状態になり× 確定している要件から順に開発を進めるため、 待ちがほとんど無く○ 新規要求が全体に関わる内容であれば大き な手戻りとなり× 厳しい性能要件がある 性能確認が遅くなるため、チューニングなどリカ バリ時間が少なくなり× 優先順位を上げて早く実装することで、プロ ジェクト中盤には性能確認ができる。そのため、 リカバリする時間に余裕ができ○ お客様は開発プロジェク トで失敗している 最終的に構築されたシステムが、ユーザーの要 求通りに動けば○ 受け入れ確認では認識違いなど問題が発生し やすく、リカバリする時間が短く× 動くソフトウェアを定期的に確認したり、性能の 早期確認を行うため、受け入れ確認で大きな 問題は発生しにくく○ ウォーターフォールとアジャイルの比較検討 リスク高
- 16. 16Copyright © 2016 NTT DATA CCS Corporation 安心・安全にプロジェクトを遂行するため、当社で開発実績が豊富な「アジャイル開発プロセス」を ご提案いたします。 アジャイル開発プロセスとは・・ 仕様書など紙面上でのレビューを徹底しても、抜け漏れや認識齟齬、非機能要件の未実現 などが発生します。最悪の場合、これらが発覚するのは、お客様の受け入れ試験時であり、残 り時間が殆ど無い状況です。 アジャイル開発は、仕様書のレビュー後、早々に動くものを作成し、お客様に動作確認して いただきます。このサイクルを繰り返すことで、抜け漏れなどのリスクを早く検知し、軌道修正 を行う開発プロセスです。 今回の再構築がアジャイル開発プロセスに向いている点は以下の通りです。 ① 現行踏襲する機能の設計書が最新化されておらず仕様は担当者の頭の中にある。 ② 新規要件の仕様確定に時間を要する可能性がある。 ③ パフォーマンスに厳しい条件がある。 アジャイル開発プロセスのご提案 アジャイル開発プロセスの提案
- 17. 17Copyright © 2016 NTT DATA CCS Corporation 要件定義 基 本 設 計 詳 細 設 計 実 装 単 体 テ ス ト 結合 テスト システム テスト 受入れ テスト 非機能要件の一部検証非機能要件定義 アーキテクチャ設計、AP基盤拡張 基 本 設 計 詳 細 設 計 実 装 単 体 テ ス ト 基 本 設 計 詳 細 設 計 実 装 単 体 テ ス ト ① 現行踏襲する機能の設計書が最新化されておらず仕様は担当者の頭の中にある。 開発の流れ 動作確認 動作確認 お客様 開発側 複雑な機能は仕様の伝え漏れや誤り、認識齟齬が発生しやすいと考えています。 そのため、必要最小限の設計書を作成した後、早々に動く機能を確認いただき、フィードバッ ク（FB）をいただくことで、このリスク顕在化を最小限に抑えます。 設計～単体テストの一連のフェーズを一定期間（2週間を想定）繰り返し行い、実現します。 ＦＢ ＦＢ 動く機能 動く機能 反復型開発 反復#1 反復#2 反復#1x アジャイル開発プロセスの提案 お客様へのお願い ・開発期間を通し、設計書レビュー、動作確認、フィードバックを実施いただくことになります。 ・仕様追加、変更が発生した場合、優先順位の低い同規模の機能との出し入れをご相談させていただきます。
- 18. 18Copyright © 2016 NTT DATA CCS Corporation ② 新規要件の仕様確定に時間を要する可能性がある。 確定を遅らせる 要件定義フェーズ期間中に新規要件の仕様が確定しない場合が考えられます。 一部のために開発全体が進められないとリソース（人、時間、コスト）に無駄が生じ、お互いに 不幸な状況となります。 そのため、要件の仕様確定タイミングを遅らせ、確定している要件から開発を進めます。 未確定 確定 確定 確定 開発 確定 今回の開発規模 機能の出し入れ検討 開発対象外 お客様 開発側 要件定義 基 本 設 計 詳 細 設 計 実 装 単 体 テ ス ト 結合 テスト システム テスト 受入れ テスト 非機能要件の一部検証非機能要件定義 アーキテクチャ設計、AP基盤拡張 基 本 設 計 詳 細 設 計 実 装 単 体 テ ス ト 基 本 設 計 詳 細 設 計 実 装 単 体 テ ス ト 開発の流れ 反復#1 反復#2 反復#1x アジャイル開発プロセスの提案 お客様へのお願い ・要件定義終了時に再度お見積りをさせていただきますが、その時の未確定分は想定見積りとします。 後々確定した仕様のお見積りと想定見積りに差が生じた場合は、その差を相殺するため、優先順位の低い 機能との出し入れや、一部仕様の簡略化など、ご相談させていただきます。
- 19. 19Copyright © 2016 NTT DATA CCS Corporation 要件定義 基 本 設 計 詳 細 設 計 実 装 単 体 テ ス ト 結合 テスト システム テスト 受入れ テスト 非機能要件の一部検証 基 本 設 計 詳 細 設 計 実 装 単 体 テ ス ト 基 本 設 計 詳 細 設 計 実 装 単 体 テ ス ト ③ パフォーマンスに厳しい条件がある。 開発の流れ 高負荷時でも照会系機能は1秒という厳しい性能目標があります。 システムテスト時に負荷テストを実施しては残り時間が少なく、取り返しがつかない可能性があります。 そのため、照会系機能を作成した後は、開発と並行して負荷テストを実施し、性能目標をクリアす るための調整を行います。 負荷テスト実施 各種調整 非機能要件定義 アーキテクチャ設計、AP基盤拡張 反復#1 反復#2 反復#1x アジャイル開発プロセスの提案 お客様へのお願い ・負荷テストは本番稼働環境をお借りして実施することを考えております。
- 20. 20Copyright © 2016 NTT DATA CCS Corporation アジャイル開発を提案してきたのは御社だけ。 前回の失敗があるので、このアジャイル開発に チャレンジしてみようと思いました。 プロジェクト期間を通し、動作確認など私達の負担 も大きいことは覚悟しています。 一緒に良いものを作っていきましょう！ お客様 契約成立！ お客様の評価 アジャイル開発プロセスの提案
- 21. 21Copyright © 2016 NTT DATA CCS Corporation お客様側 開発側 責任者 ＰＭ ＰＬ アーキテクト ＤＢＡ 設計・製造 テスト 営業 責任者 ＰＬ システム運用 エンドユーザー エンドユーザー部門（3部門） システム部門 開発部隊 仕様調整 動作確認会 エンドユーザー アウトソーシング先（3箇所） アジャイル開発プロセスの提案 体制図 フィードバック
- 22. 22Copyright © 2016 NTT DATA CCS Corporation タスク名 １ヶ月目 ２ヶ月目 ３ヶ月目 ４ヶ月目 ５ヶ月目 ６ヶ月目 ７ヶ月目 ８ヶ月目 要件定義 設計～製造 結合テスト システム テスト お客様確認 受け入れ データ移行 リリース 要件定義 お客様様動作確認 準備 準備 準備 実施 実施 実施 実施 準備 エンドユーザ操作習得 開発スケジュール アジャイル開発プロセスの提案 反復3 反復4 反復5 反復6 予備反復2反復1 データベース設計 アーキテクチャ検討、設計、開発 非機能要件の検証、チューニング 設計/製造/単体テスト 実行環境構築 ：開発側 ：お客様側
- 23. 23Copyright © 2016 NTT DATA CCS Corporation ３．安心・安全を目指して実践した内容 安心・安全な開発を目指して
- 24. 24Copyright © 2016 NTT DATA CCS Corporation 安心・安全を目指して実践した内容 実践した以下の内容についてご紹介します。 １）反復計画と仮リリース ２）開発範囲の調整 ３）反復毎の品質確認 ４）見える化
- 25. 25Copyright © 2016 NTT DATA CCS Corporation １）反復計画と仮リリース 認識のズレの早期確認と新たな要求の掘り起こし 安心・安全を目指して実践した内容 １）反復計画と仮リリース ２）開発範囲の調整 ３）反復毎の品質確認 ４）見える化
- 26. 26Copyright © 2016 NTT DATA CCS Corporation タスク名 １ヶ月目 ２ヶ月目 ３ヶ月目 ４ヶ月目 ５ヶ月目 ６ヶ月目 ７ヶ月目 ８ヶ月目 要件定義 設計～製造 結合テスト システム テスト お客様確認 受け入れ データ移行 リリース 実施タイミング 要件定義 お客様様動作確認 準備 準備 準備 実施 実施 実施 実施 準備 エンドユーザ操作習得 仮リリースとお客様への動作確認会 反復3 反復4 反復5 反復6 予備反復2反復1 データベース設計 アーキテクチャ検討、設計、開発 非機能要件の検証、チューニング 設計/製造/単体テスト 実行環境構築 機能の優先順位付けと反復計画 安心・安全を目指して実践した内容 反復計画と仮リリース
- 27. 27Copyright © 2016 NTT DATA CCS Corporation 分類 機能名 優先順位 仕様確度 早く確認 顧客管理 顧客情報登録 高 高 高 顧客情報検索 高 高 高 顧客情報更新 高 高 顧客情報削除 中 高 顧客情報ＤＬ 低 低 履歴管理 変更履歴検索 中 低 システム管理 ユーザー管理 中 高 マスタ管理 低 高 ① 機能の優先順位付け お客様に動作確認いただく順番を決めるため、機能に優先順位を付けます。 本プロジェクトでは要件定義後、お客様と以下の３段階で優先順位付けを行いました。 ・高（影響大、お客様に直接影響する、社外のアクターが使用する） ・中（高低以外） ・低（あると便利、無くても何とかなる） 安心・安全を目指して実践した内容 反復計画と仮リリース
- 28. 28Copyright © 2016 NTT DATA CCS Corporation 優先順位表（機能一覧） 安心・安全を目指して実践した内容 反復計画と仮リリース
- 29. 29Copyright © 2016 NTT DATA CCS Corporation 分類 機能名 重要度 ＃１ ＃２ ＃３ ＃４ ＃５ 顧客管理 顧客情報登録 高 ○ 顧客情報検索 高 ○ 顧客情報更新 高 ○ 顧客情報削除 中 ○ 顧客情報ＤＬ 低 ○ 履歴管理 変更履歴検索 中 ○ システム管理 ユーザー登録 中 ○ マスタ管理 低 ○ ② 反復計画の作成 機能の優先順位表を基に反復計画を作ります。 各機能の対応工数と要員計画を照らし合わせ、機能を割り振りました。 ただし、開発中での変化を受け入れるため、反復計画は随時見直しを行っていきました。 この時、優先順位の低い機能は、なるべく後半の反復に計画しました。 安心・安全を目指して実践した内容 反復計画と仮リリース
- 30. 30Copyright © 2016 NTT DATA CCS Corporation 反復計画表 安心・安全を目指して実践した内容 反復計画と仮リリース
- 31. 31Copyright © 2016 NTT DATA CCS Corporation 次の反復では、これらの機能の動作確認ができるのですね。 関係するエンドユーザー部門に動作確認するよう伝えておきます。 ① 反復計画に沿って 仮リリース ② 動作確認 システム部門 エンドユーザー エンドユーザー お客様 もう動かせるんだ 入力チェックを追加 してもらおう 開発側 繰り返し 仮リリースと動作確認 反復 計画表 安心・安全を目指して実践した内容 反復計画と仮リリース
- 32. 32Copyright © 2016 NTT DATA CCS Corporation お客様へ安心をお届け ・ お客様は反復計画を基にどの機能が動かせるのかを知ることができ安心 ・ 動くソフトウェアという最終的な成果物を定期的に操作でき、開発の進捗状況を実感 ウォータフォール型開発の場合では、開発中は進捗報告を信じるしかなく、動くソフトウェアに 触れるまでは、本当に期待通りのシステムができているのか不安に感じています。 システムが出来上がっていくのが分かって安心 お客様からは とのお言葉をいただいております。 安心・安全を目指して実践した内容 反復計画と仮リリース
- 33. 33Copyright © 2016 NTT DATA CCS Corporation プロセス １ヶ月目 ２ヶ月目 ３ヶ月目 ４ヶ月目 ５ヶ月目 ６ヶ月目 ７ヶ月目 ８ヶ月目 ウォーター フォール （想定） システムテスト 要件定義 基本設計 詳細設計 実装・単体 結合テスト 初めての動作確認 ウォーターフォールとアジャイルの動作確認タイミングの比較 基本的にお客様は関与しない アジャイル 要件定義 反復3 反復4 反復5 反復6 予備 結合テスト 反復2反復1 システムテスト 設計/製造/単体テスト 確認 確認 確認確認 初めての動作確認 約３ヶ月の差がある！ 残り時間が短い 残り時間に余裕がある 安心・安全を目指して実践した内容 反復計画と仮リリース
- 34. 34Copyright © 2016 NTT DATA CCS Corporation 仮リリースはここが大事！ 動作確認会は必ず開催すること エンドユーザーに確認してもらうこと フィードバックは必ずいただくこと 安心・安全を目指して実践した内容 反復計画と仮リリース
- 35. 35Copyright © 2016 NTT DATA CCS Corporation 動作確認会は必ず開催すること 「動作確認をお願いします」 と動作環境に配備するだけでは、お客様は確認してくれません。 今回のプロジェクトでは、業務の流れに沿ったシナリオを作成し、動作確認を行いました。 この説明で、業務での利用シーンがイメージできるため、その場でお客様から認識の相違や 違和感、納得感などを得ることができました。 動作確認会は、一緒にシステムを作っているという一体感をお客様に感じていただくことも目的です。 これを切っ掛けに、お客様内部での動作確認も円滑に進んだように感じています。 1. xxxxxxxx 2. aaaaaaa 3. ------- シナリオ 安心・安全を目指して実践した内容 反復計画と仮リリース
- 36. 36Copyright © 2016 NTT DATA CCS Corporation エンドユーザーに確認してもらうこと エンドユーザーに動作確認していただけないと、プロジェクト終盤で大きな問題が発生します。 今回のプロジェクトでは、あらかじめエンドユーザーに動作確認の実施をお願いしました。 「まずはシステム担当者が動作確認する」 は危険です。 きちんとエンドユーザーが操作し、画面の見やすさや、使い勝手を感じていただくことが重要です。 別のプロジェクトで、エンドユーザーの動作確認が後回しとなったため、得られたフィードバックや、 その対応が無駄になり、プロジェクト終盤で対応に追われ、問題となるケースがありました。 お手数ですが、動作確認をお願いします。 分かりました。 安心・安全を目指して実践した内容 反復計画と仮リリース エンドユーザー
- 37. 37Copyright © 2016 NTT DATA CCS Corporation フィードバックは必ずいただくこと フィードバックが無いと仮リリースする意味がなく、ウォータフォールのようにプロジェクト終盤で 問題が発生します。 今回のプロジェクトでは、各反復で動作確認いただき、フィードバックを必ずいただくようにしました。 エンドユーザーから得られたフィードバックは、お客様のシステム部門で取りまとめ、取捨選択した上で 開発側にフィードバックするようお願いしました。 フィードバックを対応することで、お客様との認識の乖離を減らすことができるため、終盤で大きな 問題の発生を抑えることができます。 過去のプロジェクトで、フィードバックをいただけず、プロジェクト終盤で多くの問題が発生したケースが ありました。 これが今回のフィードバックです。 ありがとうございます。 対応を検討します。 安心・安全を目指して実践した内容 反復計画と仮リリース
- 38. 38Copyright © 2016 NTT DATA CCS Corporation ２）開発範囲の調整 予算内で最大の価値を提供 安心・安全を目指して実践した内容 １）反復計画と仮リリース ２）開発範囲の調整 ３）反復毎の品質確認 ４）見える化
- 39. 39Copyright © 2016 NTT DATA CCS Corporation タスク名 １ヶ月目 ２ヶ月目 ３ヶ月目 ４ヶ月目 ５ヶ月目 ６ヶ月目 ７ヶ月目 ８ヶ月目 要件定義 設計～製造 結合テスト システム テスト お客様確認 受け入れ データ移行 リリース 実施タイミング 要件定義 お客様様動作確認 準備 準備 準備 実施 実施 実施 実施 準備 エンドユーザ操作習得 反復3 反復4 反復5 反復6 予備反復2反復1 データベース設計 アーキテクチャ検討、設計、開発 非機能要件の検証、チューニング 設計/製造/単体テスト 実行環境構築 開発範囲の調整 安心・安全を目指して実践した内容 開発範囲の調整
- 40. 40Copyright © 2016 NTT DATA CCS Corporation 請負契約では、開発範囲や費用を決め、お客様と合意した上で開発を進めます。 アジャイル開発は、仕様の変更を受け入れ、より価値あるシステムの提供を重視します。 開発範囲や費用が決まっているのに、 どうやって仕様追加や変更を受け入れ ればいいの？ 安心・安全を目指して実践した内容 開発範囲の調整 開発範囲 開発範囲 変化を受け入れ 請負契約 アジャイル開発
- 41. 41Copyright © 2016 NTT DATA CCS Corporation Ａ Ｂ Ｃ Ｄ Ａ Ｂ Ｅ Ｆ 開発範囲 重さ：開発規模 契約時 開発中 仕様追加 開発規模を維持して開発範囲を調整 安心・安全を目指して実践した内容 開発範囲の調整
- 42. 42Copyright © 2016 NTT DATA CCS Corporation 本プロジェクトでは開発規模にファンクションポイントを使用 要件定義フェーズ 業務フロー図 機能一覧 論理 データモデル ビジネスルール ファンクションポイント 既存画面 安心・安全を目指して実践した内容 開発範囲の調整
- 43. 43Copyright © 2016 NTT DATA CCS Corporation 分類 機能名 優先順 ＦＰ 顧客管理 顧客情報登録 高 15 顧客情報検索 高 10 顧客情報更新 高 12 顧客情報削除 中 7 顧客情報ＤＬ 低 8 履歴管理 変更履歴検索 中 8 システム管理 ユーザー管理 中 11 マスタ管理 低 10 分類 機能名 優先順 顧客管理 顧客情報一括取り込み 高 契約時 追加したい機能 （例） 顧客情報を一括で取り込む機能があると 作業時間が短縮できるので、是非実現を お願いします。 エンドユーザー フィードバック 各機能のＦＰはデータファンクションや機能の複雑度を考慮し再計算したもの。 安心・安全を目指して実践した内容 開発範囲の調整
- 44. 44Copyright © 2016 NTT DATA CCS Corporation 分類 機能名 優先順 ＦＰ 顧客管理 顧客情報登録 高 15 顧客情報検索 高 10 顧客情報更新 高 12 顧客情報削除 中 7 顧客情報ＤＬ 低 8 履歴管理 変更履歴検索 中 8 システム管理 ユーザー管理 中 11 マスタ管理 低 10 分類 機能名 ＦＰ 顧客管理 顧客情報一括取り込み 12 契約時 追加したい機能 重要度が低の機能を開発範囲から外す。 お客様と相談し、開発範囲から追加分の工数と相殺できる機能を選択。 今回は、優先順「低」の機能は全て開発範囲外としました。 安心・安全を目指して実践した内容 開発範囲の調整
- 45. 45Copyright © 2016 NTT DATA CCS Corporation 分類 機能名 ＦＰ 顧客管理 顧客情報登録 15 顧客情報検索 10 顧客情報更新 12 顧客情報削除 7 顧客情報一括取り込み 12 履歴管理 変更履歴検索 8 システム管理 ユーザー管理 11 開発範囲（追加分の取り込み後） 分類 機能名 ＦＰ 顧客管理 顧客情報ＤＬ 8 システム管理 マスタ管理 10 開発範囲から外した機能 開発範囲から外した機能 １８ＦＰ 開発範囲に取り込んだ機能 １２ＦＰ ６ＦＰ あと６ＦＰ分の追加・ 変更ができるのですね。 お客様 安心・安全を目指して実践した内容 開発範囲の調整
- 46. 46Copyright © 2016 NTT DATA CCS Corporation 本プロジェクトでは、約６０ＦＰの出し入れを行い、開発規模や費用を維持しました。 開発規模（６００ＦＰ） 開発規模（６６０ＦＰ） 追加（６０ＦＰ） 開発規模（６００ＦＰ） 追加（６０ＦＰ） ① 契約時 ② 開発途中での追加 ③ 開発規模の維持（調整） 開発期間 契約時に合意したファンクションポイント数となるようお客様と調整しました。 開発コスト 優先順位 高 低 コストも期間もオーバーしてしまう！ ・費用追加の協議 ・対応タイミングの調整 ・要員調達の手配 等々 安心・安全を目指して実践した内容 開発範囲の調整
- 47. 47Copyright © 2016 NTT DATA CCS Corporation 機能出し入れ時の悩み ・ 細かい仕様の追加や変更はＦＰ計測ができず、工数で出し入れを行いました。 そのため、工数からＦＰを逆算してＦＰを管理することになりました。 工数で出し入れをせざるを得ないのか？ ← 他のプロジェクトでも同様の悩みが・・ （例） ・ 画面の項目を入れ替えてほしい ・ データ登録時のチェックを追加してほしい ・ CSV出力の項目を追加してほしい 等々 安心・安全を目指して実践した内容 開発範囲の調整
- 48. 48Copyright © 2016 NTT DATA CCS Corporation 開発範囲の調整はここが大事！ 契約時にお客様と合意しておくこと 調整対象は取捨選択していただくこと 安心・安全を目指して実践した内容 開発範囲の調整
- 49. 49Copyright © 2016 NTT DATA CCS Corporation 契約時にお客様と合意しておくこと お客様との合意が無ければ、開発範囲の調整ができず、様々な調整事項が発生します。 本プロジェクトでは、きちんとお客様にご説明し、納得いただいた上で契約しました。 そのため、開発範囲の調整においては、特にトラブルは無く、機能の出し入れを行えました。 これにより、優先順位の高いフィードバックを、期間や費用の変更なく取り込むことができました。 安心・安全を目指して実践した内容 開発範囲の調整
- 50. 50Copyright © 2016 NTT DATA CCS Corporation 調整対象は取捨選択していただくこと 複数の部門が絡むシステムのフィードバックは権限のある方が取捨選択しないと、各部門との 調整に時間が掛かってしまい、プロジェクトの進捗が滞ります。 本プロジェクトでは、システム部門のPLがエンドユーザ部門と話し合い、現行踏襲が基本という 強い意思を持って取捨選択いただきました。そのため、仕様追加、変更が溢れかえることは ありませんでした。 取捨選択されたフィードバックは開発範囲の調整（出し入れ）の対象となります。 しかし優先順位により、どうしても開発範囲から溢れてしまうものは、次のフェーズ （カットオーバー後）での対応とさせていただきました。 安心・安全を目指して実践した内容 開発範囲の調整
- 51. 51Copyright © 2016 NTT DATA CCS Corporation ３）反復毎の品質確認 第１反復 第２反復 復 第４反 保守性を高める 安心・安全を目指して実践した内容 １）反復計画と仮リリース ２）開発範囲の調整 ３）反復毎の品質確認 ４）見える化
- 52. 52Copyright © 2016 NTT DATA CCS Corporation タスク名 １ヶ月目 ２ヶ月目 ３ヶ月目 ４ヶ月目 ５ヶ月目 ６ヶ月目 ７ヶ月目 ８ヶ月目 要件定義 設計～製造 結合テスト システム テスト お客様確認 受け入れ データ移行 リリース 実施タイミング 要件定義 お客様様動作確認 準備 準備 準備 実施 実施 実施 実施 準備 エンドユーザ操作習得 反復3 反復4 反復5 反復6 予備反復2反復1 データベース設計 アーキテクチャ検討、設計、開発 非機能要件の検証、チューニング 設計/製造/単体テスト 実行環境構築 反復毎の品質確認 安心・安全を目指して実践した内容 反復毎の品質確認
- 53. 53Copyright © 2016 NTT DATA CCS Corporation ソースコードの静的解析の実施 反復毎に品質を確認する手段として、ソースコードのメトリクスを収集しました。 目標値を逸脱したり、増加傾向にある場合は、メンバーに改善を促すと共に リファクタリングし、目標値を下回るよう継続的に対応を行いました。 静的解析ツール ：SonarQube チェックしたメトリクス ：コード重複率、クラス平均複雑度 ＜目標値＞ コード重複率：10%未満 クラス平均複雑度：10未満 安心・安全を目指して実践した内容 反復毎の品質確認
- 54. 54Copyright © 2016 NTT DATA CCS Corporation コード重複率（目標10%未満） クラス平均複雑度（目標10未満） 最初の反復で増加傾向にあったので改善 以降は4%～5%で推移 継続的なリファクタリングで5～６を推移 安心・安全を目指して実践した内容 反復毎の品質確認 アーキテクトの負荷が高く・・
- 55. 55Copyright © 2016 NTT DATA CCS Corporation ４）見える化 みんなで同じ情報を共有 安心・安全を目指して実践した内容 １）反復計画と仮リリース ２）開発範囲の調整 ３）反復毎の品質確認 ４）見える化
- 56. 56Copyright © 2016 NTT DATA CCS Corporation タスク名 １ヶ月目 ２ヶ月目 ３ヶ月目 ４ヶ月目 ５ヶ月目 ６ヶ月目 ７ヶ月目 ８ヶ月目 要件定義 設計～製造 結合テスト システム テスト お客様確認 受け入れ データ移行 リリース 実施タイミング お客様様動作確認 準備 準備 準備 実施 実施 実施 実施 準備 エンドユーザ操作習得 反復3 反復4 反復5 反復6 予備反復2反復1 データベース設計 アーキテクチャ検討、設計、開発 非機能要件の検証、チューニング 設計/製造/単体テスト 実行環境構築 安心・安全を目指して実践した内容 見える化 見える化 要件定義
- 57. 57Copyright © 2016 NTT DATA CCS Corporation ツールの利用 ツールを使い、関係者全員が課題や状態を把握できるようにしました。 これによりお客様や開発内部でのコミュニケーションが円滑になりました。 ・ストーリーボード：付箋に機能を書き、貼り付けて状態を管理（開発内部で利用） ・チケット管理：課題管理ツール（ITS）で課題の状態を管理（お客様とのやりとりで利用） ストーリーボード ToDo 設計中 実装中 試験中 Done 担当者は状態に 応じて貼りかえる 実装が滞っているものがあるな。 早速確認してみよう。 開発側 安心・安全を目指して実践した内容 見える化 第２反復
- 58. 58Copyright © 2016 NTT DATA CCS Corporation 課題管理ツールを利用してお客様とコミュニケーション ■メリット ・誰がボールを持っているか明確なので、対応が早くなる（なるべく持ちたくない） ・何が終わって、何が終わっていないのか一目瞭然 ・ボールのやり取りしている内容が証跡として残る（経緯が分かる） ・最新の内容や状態がすぐに共有できる お客様 開発側 安心・安全を目指して実践した内容 見える化
- 59. 59Copyright © 2016 NTT DATA CCS Corporation フェーズ 成果物 説明 要件定義 業務フロー図 業務理解とお客様との認識合わせが目的 ユースケース図 アクターとユースケースとの関係を明確にする ビジネスルール定義書 システムに関係するビジネス上のルールをまとめた定義書 画面モックアップ 既存と異なる画面のみ作成。表示項目やイベントを明確にすることが目的 画面遷移図 画面の遷移を定義した設計書 ロバストネス図 ユースケース記述ではなく、アクターとシステムのやり取りを明確にする 論理データモデル 本システムが保有するデータの論理的な構造をまとめたモデル ＣＲＵＤ （Create,Read,Update,Delete） ユースケースとテーブルの関係を明確にし、機能不足やテーブル不足を検出する 非機能要件定義書 AP基盤の拡張やインフラ設計に必要とする情報を記述する 設計 画面設計書 各画面の外観とその振る舞いを定義した設計書 テーブル定義書 各テーブルの定義書（論理名、物理名、ドメイン、制約、説明等） バッチ設計書 各バッチの振る舞いを定義した設計書 アーキテクチャ説明書 ソフトウェア・アーキテクチャの説明書 物理データモデル 論理データモデルをＲＤＢＭＳにマッピングしたモデル 実装ガイドライン ＡＰ基盤を利用する際のルールを取り決めた実装のガイドライン お客様との認識の乖離を埋める新たな取り組み 安心・安全を目指して実践した内容 見える化
- 60. 60Copyright © 2016 NTT DATA CCS Corporation ロバストネス図（例） 安心・安全を目指して実践した内容 見える化 ：画面、帳票 （boundary） ：処理 （control） ：データ （entity）
- 61. 61Copyright © 2016 NTT DATA CCS Corporation ロバストネス図の採用 ・ お客様にも分かりやすい（本プロジェクトではシステム部門の方） ・ 内部構造を大まかに見える化できる ・ 既存機能の実現であれば、お客様との認識合わせに大変有効 今回はユースケース記述は作成せず、ロバストネス図を使い、システムの内部まで 踏み込んで認識合わせを行いました。 「この処理が抜けている」や「この処理はこのタイミングではない」など、認識のずれが 上流工程で発見できたことで、手戻りが減り、安心、安全につながりました。 安心・安全を目指して実践した内容 見える化
- 62. 62Copyright © 2016 NTT DATA CCS Corporation ロバストネス図 この処理を伝え忘れて いました。 お客様 安心・安全を目指して実践した内容 見える化 ：画面、帳票 （boundary） ：処理 （control） ：データ （entity）
- 63. 63Copyright © 2016 NTT DATA CCS Corporation 安心・安全を目指して実践した内容 見える化 ロバストネス図を作成する時に参考にしている書籍 おすすめです！
- 64. 64Copyright © 2016 NTT DATA CCS Corporation ４．不安にさせてしまった 安心・安全な開発を目指して
- 65. 65Copyright © 2016 NTT DATA CCS Corporation 不安にさせてしまった お客様の不安 安心・安全な開発を心がけていましたが、お客様を不安にさせてしまいました。 反復毎にリリースする機能の品質問題
- 66. 66Copyright © 2016 NTT DATA CCS Corporation 反復毎にリリースする機能の品質 お客様は仮リリースに期待に対し、胸を膨らませています。 そのため、仮リリースしたものに不具合があると不安に感じてしまいます。 初回の仮リリースでこれをやってしまいました。 原因 本プロジェクトは、現行システムの再構築であり、基本的に現行踏襲でした。 お客様の動作確認の目的は、主に現行通りに動くかでした。 新しいサービスを作る場合、お客様自身がイメージが掴めていない場合があります。 そのため、早く確認していただき、まずイメージを掴むことが動作確認の目的となります。 しかし、今回はイメージよりも現行仕様が満たされていることが重要でした。 お客様と開発側で、この認識がずれていたことで一時的に不安にさせてしまいました。 不安にさせてしまった お客様の不安
- 67. 67Copyright © 2016 NTT DATA CCS Corporation 今回の対策 ２回目以降の仮リリースでは、動作確認を２段階に分けて実施させていただきました。 ① システム部門に確認いただき、不具合を棚卸し（並行して不具合対応） ② 優先度の高い不具合を解消した状態で、ユーザ部門が動作確認 お客様全体の 動作確認 この不具合はいつ 解決するんだろう システム部門 動作確認 ユーザ部門 動作確認 システム部門 ユーザ部門 この不具合は事前に 確認できたなぁ システム部門 ユーザ部門 この画面のココは使い勝手 を変えて欲しい！ 不具合対応 この不具合は重要なので、 ユーザ確認前に優先して 対応して欲しい ２回目以降の仮リリース時の 動作確認 改善 初回の仮リリース時の 動作確認 フィードバックが不具合に 集中してしまった・・ お客様の価値をより高める フィードバックをいただけた！ 不安にさせてしまった お客様の不安 動作確認の目的を把握し、反復計画や仮リリースを計画することが重要！ これが納品されるの？
- 68. 68Copyright © 2016 NTT DATA CCS Corporation ５．プロジェクトをふりかえって 安心・安全な開発を目指して
- 69. 69Copyright © 2016 NTT DATA CCS Corporation プロジェクトをふりかえって プロジェクトをふりかえり、改めて良かった点は以下の通りです。 ・定期的に動くソフトウェアの提供 ・途中、品質に対する問題はあったものの、繰り返し動作確認いただくことで、 プロジェクト期間を通し、安心していただけたと感じています。 ・エンドユーザーが動作確認やフィードバックに関わったことで、開発終盤や カットオーバー後に認識の相違や大きな問題は発生しませんでした。 ・期間を通してお客様とコミュニケーション ・プロジェクト期間を通し、設計レビュー、動作確認、フィードバック、開発範囲の 調整とお客様に負担を掛けましたが、一緒に開発を進めているという一体感が あり、お客様自身も楽しまれていたように感じました。 一緒にカットオーバーを無事に迎えた時、「システム開発って上手くいくんですね。 ありがとうございました」と笑顔で言われたことは忘れません。 お客様と開発側が協力して開発できたことが最大の成功要因と考えています。
- 70. 70Copyright © 2016 NTT DATA CCS Corporation ●仮リリースでの教訓 ●開発範囲の調整での教訓 本日のおさらい 動作確認会は必ず開催すること エンドユーザーに確認してもらうこと フィードバックは必ずいただくこと 契約時にお客様と合意しておくこと 調整対象は取捨選択していただくこと
- 71. 71Copyright © 2016 NTT DATA CCS Corporation 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 さいごに Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas © 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 これからも安心・安全な開発に取り組んで参ります。 アジャイルソフトウェア開発宣言
- 72. Copyright © 2011 NTT DATA Corporation 6 Copyright © 2016 NTT DATA CCS Corporation