1. Agile Japan 2010 事例セッション1
官公庁でも取り組み始めたアジャイル！
～山形県庁の事例～
ベンダー編
２０１０年４月
ＮＥＣソフトウェア東北
及川 洋靖

2. プロジェクトの概要
▐ プロジェクトの全体像
ＮＥＣおよびＮＥＣソフトウェア東北を含む６社によるシステム構
築・運用のプロジェクト
▐ 今日ご紹介するアジャイル開発の範囲
ＮＥＣソフトウェア東北が担当した共通認証基盤などの開発部分がメ
イン
山形県庁様および６社が何らかの形でアジャイルに関連
ＮＥＣソフトウェア東北
ＮＥＣ
および 他ベンダーなど
認証基盤など
グループ会社
アジャイル開発
山形県庁
2

3. 規模・体制など
▐ 期間
平成１７年１２月～平成１９年３月
（本格的にアジャイルに取り組んだのは平成１８年５月～）
▐ 規模
約５０人月
▐ 体制
５人体制、ほぼ１００％工数投入
名前 役割 経歴（当時）
Ｎさん リーダー 入社１３年目
及川 サブリーダー 入社１２年目
Ａさん 開発メンバー 入社７年目
Ｕさん 開発メンバー 入社７年目
Ｏさん 開発メンバー 入社２年目
3

4. お客様との距離
仙台から山形市まではバスで
約１時間
（ＪＲでも行けます）
山形県
山形市 仙台駅前バス停～山形県庁前
バス停は約５０分
１日７０往復以上あるので、
宮城県
県は違いますが、お客様との
仙台市 距離は非常に近いです
4

5. アジャイル開発までの経緯
▐ 「山形県情報システムフレームワーク」の策定に参画
アジャイル開発の必要性に言及
▐ 「山形県情報システムフレームワーク」を適用した最初の調
達案件を受注
アジャイル開発の必要性
5

6. プロセス
お客様から見たプロセス 社内のプロセス
要求
方向づけ 分析
設計
分析
設計 ２週間単位 小イテレーション
実装
推敲 分析
小イテレーション
設計
実装
小イテレーション
設計
実装 ２ヶ月単位
テスト
設計 大イテレーション 小イテレーション
作成 実装
テスト
設計
実装
テスト 小イテレーション
実装
テスト
移行 実装
テスト
6

7. プロジェクトでのフェーズの考え方
▐ 統一プロセスのフェーズの考え方を利用
各フェーズで行うそれぞれの作業の割合は異なる
7

8. 大イテレーション
▐ 開始
イテレーション計画書を作成して、次イテレーションの合意を
得る
▐ 終了
イテレーション結果報告書を作成し、今回のイテレーションの
成果物を確認（次イテレーションへの残作業も確認）
計画書と結果報告書で
Ａ４、３ページ程度
8

9. 小イテレーション
実装するストーリーを決める
計画ゲーム 必要なタスクを洗い出す
タスクカードを作成して貼る
小
イ
テ 朝会
レ
ー バーン
シ 日々の作業 ＴＤＤ
ダウン
ョ ペアプロ
チャート
ン
ＣＩ
ふりかえり KPTでふりかえり
9

10. 小イテレーション計画・タスク
小イテレーションは、「計画ゲーム」によって作成された1～3日人日
程度の作業の「タスク」の集合。
タスクは、ToDoボードに貼り出し、同時に進捗管理のためのバーンダ
ウンチャートも作成
カオスの海 未着手のタスク 作業中のタスク 作業済のタスク
「カオスの海」には、作業過
タスク1 タスク4 タスク6
程で顕在化したタスクを貼り タスクx ……… ……… ………
出す。 ……… 状況は、バーンダウ
⇒優先度高いものは次のイテ タスク2
………
タスク5 タスク7 ンチャートへ反映
……… ………
レーションに組み入れる
タスク3
………
タスクの作業による個人の課 作業の進捗状況に合わ
題は、朝会で報告し、メン せて、タスクカードを
バー間で共有する。 移動
＜ToDoボード＞
＜小イテレーションの計画＞ ＜バーンダウンチャート＞
10

11. 継続的にインテグレーション
▐ CruiseControlを利用した継続的インテグレーション
▐ Subversionにコミットしたら自動的にビルド＆テスト＆テ
ストカバレッジレポート作成
CruiseControl
テストカバレッジレポート
何か問題があれば開発
者メーリングリストに
jUnitテストレポート
通知 →すぐに修正！
11

12. プロジェクトルームの様子
目標を常に見える場所に張って、
一体感を高める工夫
朝会で今日やること・課題などを確認
別のプロジェクトでアジャイルに挑戦し
た際に貼っていたスローガンを再利用
ニコカレでメンバーの様子を見える化 12

13. ふりかえりの内容をご紹介
13

14. ドキュメントなど
▐ 詳細設計書などアプリケーションの細かい動きを設計した文書を実
装前には作成していません。
全体の実装の範囲や、ユースケース、機能の一覧など、プロジェクト
の遂行に必要なものは作成しています。
▐ 小イテレーション開始時に、実装する範囲の設計を実施。
実装に必要な情報を箇所をホワイトボードやＷｉｋｉに記述しました。
動作が複雑だったり、アーキテクチャをハッキリしておいた方がよい
部分にはＵＭＬを利用。
画面モックを作成した部分もあります。
▐ アプリケーションの設計書は、実装後に実装した内容に合わせて作
成（Ｗｉｋｉに書いておいた情報を、メンテナンス等のために必要
な文書としてまとめる）
実装後に作成するため、アプリケーションの変更があっても設計書を
直す必要がない（実装内容をメモしたｗｉｋｉだけ修正しておく）
14

15. 動作確認を目的としたリリース
▐ 山形県庁様向け
大イテレーション単位で動作するアプリケーションを公開
成果物の確認をしていただいた
▐ 他の開発チームへのリリース
大イテレーションよりも小さな単位でリリース
（小リリース１～数回分程度）
スクリプトを実行するだけで社内環境にリリース。他チーム
は自分たちのシステムと常に連携動作させながら開発。
15

16. その他
▐ 仕様変更やスコープの変化は？
今回のプロジェクトでは大きな仕様変更は発生しませんでした。
スコープは調達仕様書によりハッキリしていました。
▐ 品質はどのように確保？
作成フェーズまでは、Junitによる単体テストが中心。
テストが常にグリーンであること、カバレッジが目標を上回っ
ていること。
移行フェーズで実施した結合テスト・総合テストなどは、
ウォーターフォール型の場合と同様に、テスト仕様書を作成し
て、手動でテストを実施。
16

17. プロジェクト、その後
▐ 良かった点
アジャイル開発を体験
アジャイル開発に対応できるメンバーを育成できた
お客様にも満足していただけた
▐ 課題
当時のメンバーはその後バラバラになってしまった
その後のアジャイル開発事例があまり進んでいない
少しずつ事例は増えつつある
▐ 今後・・・
アジャイル開発事例を増やして、お客様によりご満足いただけ
るようなシステムを構築できるようになりたい
17

18. ご清聴ありがとうございました