ＮＥＣにおける非ウォータフォール
開発に対する取組み
２０１２年１０月２４日日本電気株式会社
ソフトウェア生産革新部長 岩崎 新一 2012年度 SECセミナー資料 適用が進み始めたアジャイル開発目次
１．はじめに ２．アジャイル開発への取り組みについて ３．大規模・分散・ミッションクリティカルシステムにおける 非ウォーターフォール型開発について ４．おわりに非ウォーターフォール型開発方式への対応必要性
▌ 事業環境激変による『フレキシブル＆スピード開発』への対応 ▌ グローバルにおけるアジャイル開発隆盛への対応 開発型 開発手法 計画駆動開発 ウォーターフォール型開発 スパイラル開発 インクリメンタル開発・イテラティブ開発 Rational Unified Process （RUP） Enterprise Unified Process （EUP） SWAT2.0 プロトタイピング開発 RapidApplication Development（RAD） Operational Prototyping（OP） アジャイル型開発Scrum、Crystal Clear 、Extreme Programming （XP） Lean Development、Feature Driven Development （FDD） Dynamic Systems Development Method （DSDM）
Adaptive Software Development （ASD） Evolutionary Project Management（Evo） セル生産、ユニケージ パッケージ利用開発 フィットアンドギャップ分析 非ウ ォ ー タ フ ォ ー ル 開発
国内外のアジャイル開発トレンド
海外に お け る ア ジ ャ イ ル 開発の 状況 会社別導入状況 適用済み 80％ 未適用 15％ 不明 5％ PJ導入率別 半数未満 60％ 半数以上 40％ ウォーターフォール型 92％ 反復型 5％ その他 3％ （アジャイル含む） 国内の 開発方法論の 状況【出典】2011年11月 VERSION ONEによる調査 http://www.versionone.com/state_of_agile_development_survey/11/
アジャイル開発と対象領域
▐ 「ソフトウェア（以降、ＳＷと略記する場合あり）」の多様化・多面性 ▐ アジャイル開発の適用が容易な領域、極めて難しい領域も存在 アプリケーションソフトウェア （アプリケーションフレームワーク） システムソフトウェア ミドルウェア・ＤＢ 基本ソフトウェア エンタープライズ系 アプリケーションソフトウェア （アプリケーションフレームワーク） システムソフトウェア ミドルウェア・ＤＢ 基本ソフトウェア 組込みソフトウェア系 ミッションクリティカル性 超大 規模 小規模 低い 極めて重要 低い 極めて重要 アプリケーションソフトウェア （アプリケーションフレームワーク） システムソフトウェア ミドルウェア・ＤＢ 基本ソフトウェア Ｎｅｔビジネス型ＳＷ系 極めて重要 低い開発プロセスを考える上での考慮事項
▌
マネジメント系とエンジニアリング系に大別
▌
本項ではエンジニアリング系施策のみについて言及
人間マネジメント系施策 プロジェクト管理 管理プロセス 就業管理 など エンジニアリング系施策 開発環境 開発プロセス 開発規則 など バランスが重要従来施策とアジャイル開発プラクティスの整合
▐ ＮＥＣが従来推進してきた施策との整合を検討し、実施中 エンジニアリング 観点 開発場所 個別最適 全体最適 分散 （グローバル分散） 一カ所 アジャイル 開発 ＳＷ生産革新活動 • グローバル標準化 • 全体最適化施策 • ＳＷファクトリ • ＣＭＭＩ推進 など統合的な「フレキシブル＆スピード開発」方式へ
▐ 全ての領域で『フレキシブル＆スピード開発』追求が必要 ⇒ ピュアなアジャイル開発も包含 アジャイル 開発向き領域 規模 大 小 大 ミッションクリティカル性 小 ＮＥＣビジネス の重点領域 ※ＩＴサービス キャリアネットワーク 社会インフラ系システム 組込みソフト領域 など ＮＥＣビジネス の重要領域 ※社会インフラ系デバイス エネルギー系デバイス など Ｂ ｉ ｇ ｌ ｏ ｂ ｅ の サ ー ビ ス Ａ Ｐ の 一 部、 情報系Ｗ ｅ ｂ Ａ Ｐ の 一部 な ど 全体として 『ＮＥＣの非ウォータフォール開発手法』 として強化を進めている本日のご説明領域
▐ アジャイル開発向け領域での取り組み ▐ 大規模・ミッションクリティカル領域における施策 規模・分散 大 大 ミッションクリティカル性 小 アジャイル開発向け 領域での取り組み 大規模・ミッションクリティカル 領域における施策２．アジャイル開発への取り組み
について
アジャイル開発への対応状況
▌
変化に強く、俊敏な開発を実現すると言われるア
ジャイル開発に対して、ＮＥＣでは以前より注目
▌
グローバル開発、アジリティ向上のため対応を推進
各組織ごとで様々な取り組みが進んでいることが判明
全社横串のタスクフォースを設置し本格的活動を開始
先行事例を元に、アジャイル開発ガイドを開発
⇒ パイロットプロジェクト適用を通して内容拡充
開発ガイドで採用したアジャイル開発手法
▌ 最も普及しているスクラムをベースに開発 スクラム スクラム＋XP カスタムプロセス 不明 その他５２％
１４％
９％ ８％ １７％ 「スクラム」と「スクラム＋XP」を 合わせると全体の６６％出典： State of Agile Survey 2011
開発方法論開発の方針
スクラム
XP
要件管理（プロダクトバックログ） イテレーション管理（スプリント） プロセス改善の仕組み（ふりかえり） 役割定義（P.O./S.M./チーム） 継続的インテグレーション テスト駆動開発 リファクタリング ソースコードの共同所有 ペアプログラミング ソフトウェア品質会計 上工程品質会計 テスト工程品質会計 バグ収束判定 バグ分析 バグ傾向分析 １＋ｎ施策 ＊ ソフトウェア品質会計：NEC独自のソフトウェア品質管理手法 エ ッ セ ン ス を 抽出 ▐ 現在もっとも普及している手法であるスクラムを中核に策定（XPの一部も採用） ▐ 弊社が長年培ってきた ソフトウェア品質会計＊のエッセンスを追加 アジャイル開発の俊敏性に品質視点を追加品質会計＜ソフトウェア品質管理手法＞
▌ 設計・製造工程で作り込んだバグを負債とみなし、レビュー・テストに よるバグ摘出によりこの負債を返済し、負債が0となった時点で出荷 設計・製造過程 レビュー・テスト 製品 バグ 作り込み 製品 バグ 摘出 バグ 品質会計は、ＮＥＣ全体に適用されているＮＥＣ独自の品質管理手法 出荷直前に実施すべき項目が残っていないかを考える指標としてバ グ件数を使用 品質会計のなかでも、上工程品質会計が品質向上の鍵アジャイル開発ガイドの全体構成
▌
アジャイル開発概要
▌
６つのプロセスの説明
▌
リリース計画の変更
▌
アジャイル開発プラクティス
Ｎ回繰り返し（あまり多くしない；3回程度を推奨）チーム構成
スクラムマスター 品質保証担当 実現したい要件の管理を行い、要件の内容や優先度の最終 決定権を持つ。 プロダクトオーナー 開発チーム 要件に従って設計・製造・テストを行う。 ３～９人で構成するのが望ましい。 プロダクトオーナーと開発チームが正しくスクラムを実践する ための支援を行う。 品質が作りこまれている状況を確認する。 ビジネスとしては第三者的な立場から品質評価が必要。３種類のスプリント
スプリントの種類 説明 主な実施内容 準備スプリント 開発を始めるための 準備を行う アーキテクチャの設計 開発環境の準備 各種規約準備 開発スプリント ストーリー毎の開発を 行い、正常動作するよ うに品質を作りこむ 要件の詳細定義 設計 実装と単体テスト 機能テスト リリーススプリント 製品をリリースするた めに必要な作業を行 う リグレッションテスト システムテスト ドキュメントの作成と更新 リリース物の配布準備アジャイル開発特化型の人材育成について
▌ 開発を行う要員と普及を行う要員の2階層に分けて育成 ▌ 育成のための教育メニューを整備中 ▌ 従来社内人材育成制度と連携しキャリアパスの設定 人材タイプ 役割 育成するスキル アジャイル エバンジェリスト 外部折衝、社内普及推進 アジャイル開発への理解 担当組織のビジネス理解 アジャイルコーチ アジャイル開発PJの初期の 立ち上げ支援 下の3つの人材タイプの包括的なスキル スクラムマスター スクラムのプロセスの実践 スクラム、ファシリテーションスキル プロダクトオーナー 責任やシステムのビジネス価 値を高める 要求開発 プロジェクト管理 開発者 スクラムや開発プラクティス を用いた開発の実践 スクラム、開発プラクティス、品質、分散 開発、ツール適用、ユーザ中心設計、 【 普 及 】 【 開 発 】３．大規模・分散・ミッションクリティカル
システムにおける非ウォーターフォール
アジャイル開発の課題
▌ 国内ＳＩにおいて、アジャイル開発は極めて限定的
⇒ アジャイル開発に適する条件を満たすことが困難であることが阻害要因
（参考） 海外におけるアジャイル開発の普及要因
▌ アジャイルは米国発：ＩＴ技術者がユーザ企業に多いため、主体的にコントロールできる ▌ ブラジルは米国からの受託が多くタイムゾーンが同じであるためコミュニケーションが活発 ▌ 米国、中国、ブラジルではIT関連職の人気や給与が高いため流動性が高く技術が普及し やすい 【出典】 IPA/SEC 「非ウォーターフォール型開発の 普及要因と適用領域の拡大に関する調査」 （元データはIPA「グローバル化を支えるIT人材確保・育成施策に関する調査」）大規模・分散・ミッションクリティカル領域における施策 ▐ アジャイル開発のプラクティス、他の非ウォータフォール開発プラクティスに おいて大規模・分散・ミッションクリティカル領域に適しているというデータ はない ▐ できればアジャイル開発 プラクティスで統合できる ことが望ましい 規模・分散 大 大 ミッションクリティカル性 小 アジャイル開発向け 領域での取り組み 大規模・ミッションクリティカル 領域における施策
大規模・分散開発にアジャイル開発を適用するための考え方
▌
大規模システムのアジリティ向上にはアーキテクチャを
管理することが重要
⇒その上でユーザニーズの反映を考慮した小規模案件化戦 略が必要▌
プランＡ．ＵＩ系・画面系中心アプローチ
⇒ エンドユーザがディシジョンできる、変更が多いなどの理由 により、アジャイルがうまく機能する代表格▌
プランＢ．フィーチャー・ストリーによる小規模化
▌
プランＣ．アーキテクチャ見直しによる小規模化
アジャイル開発のチーム分割
▌ コンポーネントチームとフィーチャーチーム コンポーネントチームでは1つのストーリー実現に複数チーム同時作業が必要 フィーチャーチームではストーリー実現においてチーム間の依存関係が少ない プロダクト バックログ コンポー ネントA コンポー ネントB コンポー ントC Aコンポーネント チーム Bコンポーネント チーム Cコンポーネント プロダクトオーナー コンポーネントチームによる構成 ストーリー① ストーリー② ストーリー③ ストーリー④ ストーリー⑤ プロダクト バックログ コンポー ネントA コンポー ネントB コンポー ントC フィーチャー チーム フィーチャー チーム フィーチャー プロダクトオーナー フィーチャーチームによる構成 ストーリー① ストーリー② ストーリー③ ストーリー④ ストーリー⑤ システム システムプランＣ．アーキテクチャ見直しによる小規模化 （１） システムをアジャイル開発ができるレベルまで分解 アジャイル開発が機能する１０名前後で開発できるところまで分割 ※ サブシステム⇒サブサブシステム⇒モジュールレベルまで分解 サブシステム、モジュールの独立性が重要 （２） 対象システムのモジュール独立性のアセスメント 現状のモジュールの状況を構造メトリクス＊にて数値化 ⇒改善目標を策定 （３） 特定領域のアジャイル化方針策定 変化が大きいサブシステム、モジュールを特定 サブシステム、モジュールの独立性を極限まで追求してアーキテクチャ見直し 構造メトリクスにて再度評価 * ソースコードの状況を様々な角度から分析
