1. 公共システム開発を
アジャイルで挑戦
～山形県庁の事例～
平成22年4月9日
山形県総務部総合政策局情報企画課
主事 渡邊 貴之
1

2. アジェンダ
山形県情報企画課の役割
山形県情報システムフレームワーク
アジャイル開発を採用した理由
初めてのアジャイル開発に取り組んで
アジャイル開発における課題
今後の取組み
2

3. はじめに
山形県は、大きく四つの地域（村山地域、最上地域、置賜地域、庄内地
域）に分かれており、それぞれ特有の文化、自然が展開されています。
山形県の特徴
山形県の特徴
人口：約120万人
市町村数：35団体
特産品：さくらんぼ、つや姫（お米）
ラ・フランス（西洋梨）
話題：おくりびと（庄内地方）
天地人（置賜地方）
山形県HP
http://www.pref.yamagata.jp
3

4. 山形県情報企画課の役割
山形県情報企画課の組織体制
情報企画担当
・情報化に関する施策の総合企画及び調整に関すること。
・地域情報化の推進に関すること。
具体的には・・・
・庁内情報システムの全体最適化
電子県庁企画担当
・情報システムフレームワークの運用
・電子申請システムに関すること。 ・情報システム開発予算の査定
・行政の情報化の推進に関すること。 ・情報セキュリティポリシーの管理
・情報処理システムの開発及びその支援に関すること。・各部局へのシステム開発支援 等
基幹ネットワーク調整担当
ITマネージメント
・県基幹高速通信ネットワークの管理及び運営に関すること。 機能を担う
・大型汎用コンピュータの管理及び運営に関すること。
4

5. 以前の県の情報システム
従来のシステム開発・運用の状況
（例）
[給与] [人事] [総務事務] ・H/WからS/Wまでが密結合状態。
業務 業務 業務 どこか一部でも修正が必要となると、
アプリA
アプリA アプリB
アプリB アプリC
アプリC ほとんど全ての結合部分（インターフェー
ﾐﾄﾞﾙｳｪｱ ﾐﾄﾞﾙｳｪｱ ﾐﾄﾞﾙｳｪｱ ス）の改修が必要。
＋＋ ・各情報システム間のデータ連携不備に
よる事務の非効率化。
ｽﾄﾚｰｼﾞ ｽﾄﾚｰｼﾞ ｽﾄﾚｰｼﾞ
OS OS OS
ｾｷｭﾘﾃｨ ｾｷｭﾘﾃｨ ｾｷｭﾘﾃｨ
×
流用
不可
・制度改正時等、プログラム改修を行うと、
HW HW HW プログラム以外の部分にも改修が必要。
・H/W、S/Wの保守切れによる更新対応に
ﾌｧｼﾘﾃｨ（場所、電源 etc） ｲﾝﾀｰﾈｯﾄ回線 も、S/Wの設定変更費等、膨大な改修経
費がかかる。
この状況を解消しなければならない・・・5

6. 情報システムフレームワークの制定
山形県情報システムフレームワーク
全庁的なシステム開発・運用指針、ＳＩ憲章 （平成17年11月制定）
本県の情報システムについて、特定のＩＴ企業への依存をなくし、適正なコスト及び
適切な技術による開発・運用を図るため、次の３つのルール「依存しないこと」、「公開す
ること」、「共通部品、共通サービスを利用および追加すること」を強く意識してシステム
開発することを定めたもの。
３つのルール
・依存しないこと ： 特定の技術や製品に依存しないこと
・公開すること ： プログラムソースは全て公開すること
・共通部品、共通サービスを利用、追加すること
6

7. 山形県情報システムフレームワークの概念
全体最適かつ適正なシステム開発、運用を実現するためのＩＴスタンダード
・Webサービス連携を中心としたサービス連携志向（ＳＯＡ）。
・各レイアの分離（差し替え可能）と共通的に使用できるものを共通化し開発、
運用コストを削減。
・オープンソースソフトウェアの採用、ドキュメント管理の一元化、発注区分を小さく
7
することなどで地元企業への発注拡大（地域ＩＴ産業振興）。

8. 情報システムフレームワークにおける
アジャイル開発
情報システムフレームワークでは、アジャイル開発をせよ！
と規定している
9.4 アジャイル開発プロセス（P180抜粋）
アジャイル開発プロセスの概要
「アジャイル」は、「迅速な」「俊敏な」という意味であり、よいソフトウェアを無駄なく、
すばやく作るための開発方法を「アジャイル開発プロセス」と呼ぶ。・・・
・・・また、開発を反復型で行うという点も、アジャイル開発プロセスに共通した点で
あり、本書でも反復型開発を基本原則として取り扱う。
情報システムフレームワークでは、反復型開発プロセスの一種であるUP(Unified
Process, 統一プロセス)を標準の開発プロセスとして利用する。
8

9. 情報システムフレームワークが目指す姿
情報システムフレームワークを遵守した場合
・オープンな技術の採用
従来のシステム開発・運用の場合 ・共通部品構築と活用
・システムとデータ連携の構築
[給与] [人事] [総務事務] ・マスターデーターの統合
・ハードウェアの統合 他システム
業務 業務 業務
アプリA
アプリA アプリB
アプリB アプリC
アプリC ・データ交換
・共通機能の
コスト削減 相互利用
ﾐﾄﾞﾙｳｪｱ ﾐﾄﾞﾙｳｪｱ ﾐﾄﾞﾙｳｪｱ
＋＋
フ
[給与] [人事] [総務事務]
レ 情 業務 業務 業務
ー 報 アプリＡ アプリB
アプリB
・・・
アプリC
アプリC
ｽﾄﾚｰｼﾞ ｽﾄﾚｰｼﾞ ｽﾄﾚｰｼﾞ
ム シ アプリ以下は
ワ ス ミドルウェア（WAS,DB,ESB) 県は所有し
OS OS OS ー テ たくない。
ク ストレージ
ｾｷｭﾘﾃｨ ｾｷｭﾘﾃｨ ｾｷｭﾘﾃｨ ム 他のアプリ、
流用
× OS 製品と自由
セキュリティ に交換可能、
不可
交換しても他
HW HW HW HW へ影響を与
えない関係。
ﾌｧｼﾘﾃｨ（場所、電源 etc） ｲﾝﾀｰﾈｯﾄ回線 ﾌｧｼﾘﾃｨ（場所、電源 etc） ｲﾝﾀｰﾈｯﾄ回線
キーワードは「シェア」、インフラ構成に限った話ではなく、システム全般について 9

10. 何故アジャイルだったのか？
情報システムフレームワークのコンセプト
変更に強いシステムをつくる
この思想に合致する手段として、システム開発のアーキテクチャにはSOAを奨励。
・業務の視点から、欲しい機能（サービス）を部品化。
・部品同士は疎結合し、自由に取替可能。
・共通的に利用可能な部品は、今後共通部品化して利用していく。
SOAによるサービスを疎結合させるメリットは他に、
・機能を単純化できる可能性がある。
・機能が小さければ、地元企業でも参入できる。調達に競争喚起できる。
・言語など何をつかっても連携できる柔軟性がある等。
まさに情報システムフレームワークのコンセプトに合致
10

11. 何故アジャイルだったのか？
変更を前提としている、そして変化に強い
SOAを採用すれば開発は自然にアジャイルになる
・SOAによる開発設計を進めると、サービス単位での開発が可能。
・サービスの開発はユーザーとのコミュニケーションが重視され、合意しながら開発。
・SOAが変更に強いなら、開発も変更に強い方法がよい。
・SOAとアジャイルは相性が良い。
ユーザーが実物を確認しながら開発
発注者（職員）にとって一番わかり易い開発手法（ユーザー視点）
・実物を見ながらシステム開発ができる。
・発注者（職員）が積極的に関わることで、開発後の不具合やそれに伴う改修追
加費用を削減できる。
・これまでの「紙（仕様書）で発注、後は業者丸投げ」のシステム開発を防げる。
11

12. 最初の取組み～電子申請システム～
◆概要
・2003年7月 電子申請システムの開発開始（NECを代表企業とする企業体が受託）
・電子申請システムの共通サービス部分について、アジャイル開発を条件とした仕様
（共通サービス部分：職員認証、文書管理機能、ＰＤＦ作成機能）
Ｎ
◆取組み Ｅ 詳
・受託会社の進捗管理もアジャイルに変更してもらった Ｃ 細
・受託会社内にWARルームを設置 → 県の担当者も訪問 の は
発 こ
・Wikiを導入して県とのコミュニケーションを充実
表 の
・ペアプログラミングもやったそうです で 後
の
◆効果
・発注者としてプロジェクトに積極的に関与したことで、無駄な開発を削減できた。
・自然と適切な進捗管理がなされ、納期内に開発が完了した。
12

13. その後の課題
電子申請システム以降、
アジャイル開発は普及
していない・・・
◆電子申請システムの開発以降、約30システムの再構築を進めたが、アジャイル開
発を前提とした発注仕様にも関わらず、実際にアジャイル開発に沿った開発は行わ
れなかった。
◆ベンダーは受託時はアジャイルで開発すると言っても、結果的にはウォーターフォー
ルで開発してしまう。
13

14. その後の課題
考えられる原因
考えられる原因
（１）大手はアジャイル開発しない？
・大手ほどアジャイル開発体制がとりにくいのかもしれない。大手の内部進捗管理が
ウォーターフォール管理。電子申請開発受託会社の進捗報告を変えなければなら
なかった事例がこれを証明。
・大手はbaseシステムと名を変えたパッケージを持ってきた。それは全庁を俯瞰しない
業務最適化のパッケージであり、自分の開発工数を減らすため。
・県の考える全庁を俯瞰した機能部品やサービスなどではなく、その業務だけで流通、
再利用を考えたもの。（業者を選んだ県が悪いのか？）
・分析設計は現行のシステムとbaseシステムのフィットアンドギャップが中心で、打ち合
わせ結果を議事録に起こし、それを承認する方式を要求する。
・制度改正や機能的な漏れが発覚しても確認印を盾に、スケジュールが遅れる、追
加費用を払って欲しいと、変更に応じない。
・パッケージカスタマイズビジネスとアジャイルは相性が悪い？ 14

15. その後の課題
考えられる原因
考えられる原因
（２）県側の問題
・原課担当者はその業務の部分最適だけを望み、全庁的な最適化を考えない。
・ウォーターフォール型の開発に馴染みがあり、完成後の検収まで職員は開発
過程には関わらず、業者に丸投げすればよいと考えてしまう。 “良きに計らえ”
・パッケージの方が手間がかからず、担当者の負担も無いと考え、ベンダーが提案す
る個別最適化されたパッケージをそのまま受け入れてしまう。
・自治体という性格上、基本的に設計と実装のズレは認められない。
・情報企画課のガバナンス不足（体制問題）。情報企画課に強い権限があれば、
開発に介入をしていくが・・・
15

16. 今後の取組み
各課業務フローの可視化
業務を可視化し、業者任せを防止する
職員研修の実施
開発業者とのコミュニケーションを重視し、
丸投げを防止
SOAの推進
自然にアジャイル開発の推進へ
16

17. 次期全体最適化（共通Webサービス拡充によるシステム構築イメージ）
Webサービス群（機能部品） 統合データベース
共通Webサービス群（機能部品）
る 共通に再利用する
と
単独でまだ共通再利用さ 共通データ
。 開 域 小 れていない
古くなった
発 企 さ 機能 機能
機能
後 業 な 新機能
共通
再 も 粒 機能
機能 取替えや 機能 機能 機能
統合
DB ﾃﾞｰﾀ
利 参 度 修正
用 入 で 機能
機能
す 。 地 機能
BPEL（ビジネスプロセスエグゼキューションランゲージ）
Webサービスを組み合わせて、システムを構築する
で で アア 今今
開 開 ジジ 後後
発 発 ャャ 、、 ESBによるWebサービスとデータ連携
し し イイ 機機
て て ルル 能能
い い 部部 新財務システム 新給与システム 新建設システムなど
く く 品品
！ ！ はは 情報システムフレームワークに従ったミドルソフトウェア
インフラストラクチャー稼動基盤の統一 17

18. 以上で終わります。
ご清聴ありがとうございました。
18