アジャイル開発事例紹介～適応と計画のバランス～株式会社オージス総研ＥＳ４部第３チーム入江茂喜 2010/7/25 1 発表内容  １．プロジェクトの概要（５分）１．１システム化の背景および目的１．２プロジェクトの特徴１．３システム全体概要  ２．プロジェクト管理（1０分）２．１２．２２．３２．４  反復型開発～戦略と計画～品質管理進捗管理メトリクス３．まとめ（15分）３．１３．２３．３３．４３．５ 2010/7/25 プロジェクト実績まとめ反復開発の効用今回の気付き今後の課題と展開あれから2年・・・ 2 １．１システム化の背景および目的  旧システムの老朽化  1997年に構築し、H/W、S/W共に老朽化  改造に次ぐ改造で、メンテナンスが大変  ビジネスニーズとのアンマッチ  業務に合わなくなってきた  連携先他システム再構築に伴い、I/F変更 2010/7/25 3 １．１．１旧システムの概要    PowerBuilder + COBOLで27万6千ステップのC/S 独特な画面で使いづらい（使い方がよくわからない）ドキュメントはCOBOL部分の詳細設計書だけラベル？ソートバー？いえ、ボタンです暗号のようなチェックボックス担当者Mさんのコメント「ボタンを押すと何が起こるか分からないので怖い…」 2010/7/25 4 １．３プロジェクトの特徴       旧システムと同等機能を備え、業務が滞りなく遂行可能なこと連携他システムとの親和性を向上言語を統一、ＯＳＳを活用しＷｅｂシステムに使い勝手を向上させ、スリム化したい連携他システム開始に絶対間に合うこと一括請負が希望（要件ほとんど固まってないけど…）・旧システムは、規模から算出すると200人月以上・スリム化するとは言え、工期は8ヶ月しかない・さらに機能を向上させる要件を盛り込めるのか？ 2010/7/25 5 １．４システム全体概要     全面的にOSSを採用したJ2EE 3層WebシステムフレームワークにOJF(Seasar2) DBMSはPostgreSQL バーコードリーダに接続する専用GUIアプリクライアント APサーバﾌﾞﾗｳｻﾞ：アプリケーション F/W： OJF, JasperReport Web/AP： Apache, Tomcat GUI： Swing 2010/7/25 OS：Red Hat Enterprise Linux DB: PostgreSQL IE6~7 FireFox DBサーバプリンタサーバ他システム 6 ２．１反復型開発～戦略と計画～  使い勝手を向上させ、スリム化したい  タイムボックスの反復型開発で、何度もリリースする  変更要望を積極的に受け入れ、改良する  連携他システム開始に絶対間に合うこと  ドキュメンテーションは出来る限り減らす  OJFを活用し、アーキテクチャだけは早期安定させる  一括請負が希望（要件ほとんど固まってないけど…）  外部設計完了時に再見積り  見積もったファンクションポイントは固定し、死守する  反復型でリスクを徐々に討ち取る 2010/7/25 7 ２．１．１開発手法=UP+アジャイル？実際の「プロジェクト計画書」に書いた今回の開発手法の説明   開発手法は端的に言えば、「UP(統一プロセス)＋アジャイル」である UPからは、プロジェクトの安定性に関する概念を引き継ぐ    アジャイル開発から、プロジェクトの適応性に関する概念を引き継ぐ      アーキテクチャ中心リスク駆動プロセスやツールよりも、個人との対話を優先包括的なドキュメントよりも、動作する製品を優先契約の交渉よりも、顧客との協調を優先計画に従うよりも、変化への対応を優先そして、中核となる反復型開発は両者の概念を引き継ぐ   2010/7/25 UPからは、「インクリメンタルな反復型プロセス」 ⇒ユーザビリティが重要で、複雑な機能を洗練する反復アジャイルからは、「反復型でフィーチャ（機能）ベースの提供」 ⇒反復ごとに実際に稼動する機能セットを提供する 8 ２．１．２反復計画時の悩み  要件定義開始から2ヶ月強でリリースしないと…  いきなり実装？いくらアジャイルでも設計が足りなすぎる  ユースケース駆動は採用してない。何から開発しよう？  UPのような作業分配の概念を適用できるか？  どうやって？始めにWBSで全てのタスクを決める？  そんなお堅い計画駆動をやってる時間はない有名なUPの図。でも…どうやったらこんな作業分配を計画できるの？ 2010/7/25 ？全反復のWBS を最初に計画するの？それはアジャイルじゃないはず。 9 ２．１．３実際の反復計画    反復毎に完了すべきトランザクションファンクションポイント(TFP)だけを最初に決めた反復毎に“ストーリー“を計画し、意味ある機能のまとまりを反復毎にリリース（機能毎の重要度も意識）計画した反復毎TFPに収まるのであれば、反復間で、開発対象機能を入れ変えることも可とした 300TFP 292 200TFP 100TFP 設計作業の割合 258 テスト作業の割合 70 30 2010/7/25 反復１反復２反復３反復４ 10 ２．２品質管理  単体テストは自動テストコードと機能テストを併用  OJF TestTool(S2Test)による回帰テストコードを作成  単体と言いつつ、反復毎リリースに向けて結合的なケースも含む  結合テストは単体テストで出来ないものだけを実施  機能間連携、他システムI/F、シナリオ、性能テスト単体テストケース数 UTカバレッジ(C0基準) 結合テストケース数不具合件数(※1) 障害件数(※2) 530 90％以上 320 (予測せず) 実績 1,600 80％ 400 63 5 6 前倒しされた？計画 ※1 結合テスト中の不具合、 ※2 ST、リリース後の顧客起票障害 2010/7/25 11 ２．３進捗管理    全体の進捗管理はWBS（途中で放置したが…）結局、リリースが完了した機能数(TPF)だけを管理テスト時はテストケース消化数で管理 GDBプロジェクト反復進捗 700 【反復１完了(12/10)】 70ﾄﾗﾝｻﾞｸｼｮﾝFP消化 600 トランザクションFP 500 【反復２完了(1/11)】 292ﾄﾗﾝｻﾞｸｼｮﾝFP消化 (累計362、残288) 残FP 反復毎計画FP 400 【反復３予定(2/9)】 258ﾄﾗﾝｻﾞｸｼｮﾝFP消化 300 【反復４予定(2/29)】 30ﾄﾗﾝｻﾞｸｼｮﾝFP消化 200 100 20 07 /1 1/ 20 5 07 /1 1/ 12 20 07 /1 1/ 19 20 07 /1 1/ 26 20 07 /1 2/ 20 3 07 /1 2/ 10 20 07 /1 2/ 17 20 07 /1 2/ 24 20 07 /1 2/ 31 20 08 /1 /7 20 08 /1 /1 4 20 08 /1 /2 1 20 08 /1 /2 8 20 08 /2 /4 20 08 /2 /1 1 20 08 /2 /1 8 20 08 /2 /2 5 0 2010/7/25 日付 12 ２．３．１各反復中の進捗管理   バーンダウンチャートで時間単位の予実管理毎朝スクラムミーティング、毎昼全体ミーティングチームリソース残作業時間 500 450 迅速なリカバリ 400 工数（人時） 350 300 250 200 150 100 50 2010/7/25 1/10 1/11 7 1/9 12/20 6 1/8 12/19 5 1/7 12/18 4 12/27 12/17 3 12/26 12/14 2 8 9 10 日付／日数 11 12 13 14 15 16 12/25 12/13 1 12/21 12/12 0 13 ２．４メトリクス（１）  OJFの活用で、コードは反復１で一番成長  EntityGenによってDaoやEntityを一気に自動生成  後半、完了FPは増えても、コード生産量は伸びない  リファクタリングでコードが“減る“コンポーネントも出る 800 700 600 500 400 300 200 100 0 SLOC 150,000 100,000 50,000 0 11/1 12/7 1/8 2/13 3/4 コード量完了FP FP 200,000 4/18 コード生産量とリリース完了TFPの成長 2010/7/25 14 ２．４メトリクス（２）   反復１で設計に注力している影響でテストは少ない後半、本体コードよりテストコードが成長する最終的にテストコードは本体コードの２／３の規模  少ないかも？OJF TestTool(S2Test)の生産性が良いのは確実  SLOC 300,000 250,000 全てのコード 200,000 テストコード抜き 150,000 テストコード 100,000 50,000 0 11/1 12/7 1/8 2/13 テストコードの成長 2010/7/25 3/4 4/18 15 ３．１プロジェクト実績まとめ    途中で再見積りし、追加費用を頂く生産性は計画をかなり上回る JUAS標準開発工期より30％短縮 ※JUAS: 日本情報システム・ユーザー協会 ※標準工期：投入人月の立方根の2.4倍計画 - 実績計画比110% 利益率(％) 納期(リリース日) 2008年6月計画比130% 2008年6月投入要員(人月) 78.5 4 12.8 95.8 4 15 16万7千売上(百万) ＣＳ満足度生産性(FP/人月) 規模(有効ｽﾃｯﾌﾟ数) 2010/7/25 - 16 ３．２反復開発の効用（１）   反復毎に小さな要望を取り込み、機能を洗練する最終的には外部設計時から大幅に機能が変更  ウォーターフォール型だったら、この大変更を一気に取り込むのは困難だっただろうし、そもそも変更を受け入れなかっただろう ◎小さくホップステップジャンプ 2010/7/25 ×命がけの大ジャンプ 17 ３．２反復開発の効用（２）  開発作業自体が改善されるある作業のやり方がまずければ、次の反復で大胆に見直す  顧客へリリースするため、ビルド＆配置、データ移行も改善   設計が最適化される最初はシンプルに。必要に応じて再設計やリファクタリング  前回の反復で捨てた設計上のアイデアを再度採用することも   モチベーションが向上する  1ヶ月ごとに訪れる、ほど良い緊張感と終わったあとの達成感  事実が成功を裏付けているという安心感 2010/7/25 18 ３．３今回の気付き  成功要因を一つ選ぶとしたら“何度もリリース“ 要件・設計・実装・テスト・移行の全ての開発作業を繰り返す  ただし、最低４回は繰り返さないと効果は薄い   変化（適応）と安定（規律）は両立できる今回のブレンド手法が理論的に正しいか否かは分からないが…  QMS外部審査にもパス。従来の品質ﾏﾈｼﾞﾒﾝﾄにも適合は可能   反復型では保守性が生産性を左右する開発者が保守性を切実な問題と受け止めた  保守容易性は未来への投資ではなく、今の推進力に必須になる  2010/7/25 19 ３．４今後の課題と展開  お客様の理解を得るためは？  反復やアジャイル手法への抵抗感はまだ強い  効果的にメリットを説明する提案へ（保守性向上など）  CCPMの適用  通常とは逆にメンバーはギリギリの工数見積りをしがち  プロジェクト全体での効果的なバッファ管理が必要  さらに大規模、さらに短納期に応える手法へ  どれだけ独立化したチームが作れるかが鍵？  横断的に仕様を調整する専任チームが必要か？ 2010/7/25 20 ３．５あれから２年・・・  ウォーターフォール型開発再び  ウォーターフォールは怖い    アジャイルからの気付き    統合テストまで見つからない仕様ミス、解決されないリスク運用しないと気付かないムダな機能、真のユーザ要求計画に柔軟性を取り込むことの重要性（CCPM）密なコミュニケーションの重要性（暗黙知の活用、見える化）アジャイルの今  大規模開発への適用、契約のあり方は、未だ模索中   アジャイルへの誤解（過小or過大評価、）は少なくなりつつある    “計画駆動とアジャイルは対立軸でない”、“PJごとにカスタマイズが必要”など検索→「アジャイルは単に廃れつつある流行語なのか？」適用事例は増えつつあり、徐々に市場からの要請も増えている   2010/7/25 検索→「キーパーソンに聞くエンタープライズ・アジャイルの現在」検索→「非ウォーターフォール型開発に関する調査結果公開」 “RFPにアジャイル適用を盛り込むユーザ企業も多い”日経BP池上氏談 21 補足- マスタスケジュール 2007 9 10 推敲作成 11 12 3 4 5 要件外部定義設計ｱｰｷﾃｸﾁｬ設計・構築反復反復反復反復追加１２３４開発移行結合テスト一括契約 2010/7/25 2008 1 2 ｼｽﾃﾑﾃｽﾄ・移行・ﾘﾘｰｽ SES契約 22