AgileAgile

Japan 2010 Japan 2010 事例セッション事例セッション11

官公庁でも取り組み始めたアジャイル！官公庁でも取り組み始めたアジャイル！

～山形県庁の事例～～山形県庁の事例～

ベンダー編ベンダー編

２０１０年４月

ＮＥＣソフトウェア東北

及川

洋靖

2

プロジェクトの概要プロジェクトの概要

▐

プロジェクトの全体像ＮＥＣおよびＮＥＣソフトウェア東北を含む６社によるシステム構築・運用のプロジェクト

▐

今日ご紹介するアジャイル開発の範囲ＮＥＣソフトウェア東北が担当した共通認証基盤などの開発部分がメイン

山形県庁様および６社が何らかの形でアジャイルに関連

ＮＥＣソフトウェア東北

認証基盤などアジャイル開発

ＮＥＣおよび

グループ会社他ベンダーなど

山形県庁

3

規模・体制など規模・体制など

▐

期間平成１７年１２月～平成１９年３月（本格的にアジャイルに取り組んだのは平成１８年５月～）

▐

規模約５０人月

▐

体制５人体制、ほぼ１００％工数投入

名前 役割 経歴（当時）

Ｎさん リーダー 入社１３年目

及川 サブリーダー 入社１２年目

Ａさん 開発メンバー 入社７年目

Ｕさん 開発メンバー 入社７年目

Ｏさん 開発メンバー 入社２年目

4

お客様との距離お客様との距離

山形県

山形市

宮城県

仙台市

仙台から山形市まではバスで

約１時間

（ＪＲでも行けます）

仙台駅前バス停～山形県庁前

バス停は約５０分

１日７０往復以上あるので、

県は違いますが、お客様との

距離は非常に近いです

5

アジャイル開発までの経緯アジャイル開発までの経緯

▐

「山形県情報システムフレームワーク」の策定に参画

アジャイル開発の必要性に言及

▐

「山形県情報システムフレームワーク」を適用した最初の調

達案件を受注

アジャイル開発の必要性

6

プロセスプロセス

お客様から見たプロセス 社内のプロセス

方向づけ

推敲

作成

移行

要求分析設計

分析設計実装

分析設計実装

設計実装

テスト

設計実装

テスト

設計実装

テスト

実装テスト

実装テスト

小イテレーション

小イテレーション

小イテレーション

小イテレーション

２ヶ月単位２ヶ月単位

２週間単位２週間単位

大イテレーション大イテレーション

小イテレーション小イテレーション

7

プロジェクトでのフェーズの考え方プロジェクトでのフェーズの考え方

▐

統一プロセスのフェーズの考え方を利用

各フェーズで行うそれぞれの作業の割合は異なる

8

大イテレーション大イテレーション

▐

開始

イテレーション計画書を作成して、次イテレーションの合意を得る

▐

終了

イテレーション結果報告書を作成し、今回のイテレーションの成果物を確認（次イテレーションへの残作業も確認）

計画書と結果報告書で

Ａ４、３ページ程度

9

小イテレーション小イテレーション

小イテレーション

計画ゲーム

日々の作業

ふりかえり

実装するストーリーを決める

必要なタスクを洗い出す

タスクカードを作成して貼る

朝会

ＴＤＤペアプロ

ＣＩ

バーン

ダウン

チャート

KPTでふりかえり

10

タスクの作業による個人の課

題は、朝会で報告し、メン

バー間で共有する。

タスク1

………

タスク2

………

タスク3

………

タスク4

………

タスク5

………

タスク6

………

タスク7

………

タスクx

………

カオスの海 未着手のタスク 作業中のタスク 作業済のタスク

作業の進捗状況に合わ

せて、タスクカードを

移動

状況は、バーンダウ

ンチャートへ反映

小イテレーションは、「計画ゲーム」によって作成された1～3日人日

程度の作業の「タスク」の集合。

タスクは、ToDoボードに貼り出し、同時に進捗管理のためのバーンダ

ウンチャートも作成

「カオスの海」には、作業過

程で顕在化したタスクを貼り

出す。

⇒優先度高いものは次のイテ

レーションに組み入れる

小イテレーション計画・タスク小イテレーション計画・タスク

＜ToDoボード＞

＜小イテレーションの計画＞ ＜バーンダウンチャート＞

11

継続的にインテグレーション継続的にインテグレーション

▐

CruiseControlを利用した継続的インテグレーション

▐

Subversionにコミットしたら自動的にビルド＆テスト＆テ

ストカバレッジレポート作成

CruiseControl

jUnitテストレポート

テストカバレッジレポート

何か問題があれば開発何か問題があれば開発

者メーリングリストに者メーリングリストに

通知通知

→すぐに修正！→すぐに修正！

12

プロジェクトルームの様子プロジェクトルームの様子

朝会で今日やること・課題などを確認

ニコカレでメンバーの様子を見える化

目標を常に見える場所に張って、

一体感を高める工夫

別のプロジェクトでアジャイルに挑戦し

た際に貼っていたスローガンを再利用

13

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

14

ドキュメントなどドキュメントなど

▐

詳細設計書などアプリケーションの細かい動きを設計した文書を実

装前には作成していません。

全体の実装の範囲や、ユースケース、機能の一覧など、プロジェクトの遂行に必要なものは作成しています。

▐

小イテレーション開始時に、実装する範囲の設計を実施。

実装に必要な情報を箇所をホワイトボードやＷｉｋｉに記述しました。動作が複雑だったり、アーキテクチャをハッキリしておいた方がよい部分にはＵＭＬを利用。

画面モックを作成した部分もあります。

▐

アプリケーションの設計書は、実装後に実装した内容に合わせて作

成（Ｗｉｋｉに書いておいた情報を、メンテナンス等のために必要

な文書としてまとめる）

実装後に作成するため、アプリケーションの変更があっても設計書を直す必要がない（実装内容をメモしたｗｉｋｉだけ修正しておく）

15

動作確認を目的としたリリース動作確認を目的としたリリース

▐

山形県庁様向け

大イテレーション単位で動作するアプリケーションを公開

成果物の確認をしていただいた

▐

他の開発チームへのリリース

大イテレーションよりも小さな単位でリリース（小リリース１～数回分程度）

スクリプトを実行するだけで社内環境にリリース。他チームは自分たちのシステムと常に連携動作させながら開発。

16

その他その他

▐

仕様変更やスコープの変化は？

今回のプロジェクトでは大きな仕様変更は発生しませんでした。

スコープは調達仕様書によりハッキリしていました。

▐

品質はどのように確保？

作成フェーズまでは、Junitによる単体テストが中心。

テストが常にグリーンであること、カバレッジが目標を上回っていること。

移行フェーズで実施した結合テスト・総合テストなどは、ウォーターフォール型の場合と同様に、テスト仕様書を作成して、手動でテストを実施。

17

プロジェクト、その後プロジェクト、その後

▐

良かった点

アジャイル開発を体験

アジャイル開発に対応できるメンバーを育成できた

お客様にも満足していただけた

▐

課題

当時のメンバーはその後バラバラになってしまった

その後のアジャイル開発事例があまり進んでいない

少しずつ事例は増えつつある

▐

今後・・・

アジャイル開発事例を増やして、お客様によりご満足いただけるようなシステムを構築できるようになりたい

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