1

公共システム開発を アジャイルで挑戦

～山形県庁の事例～

山形県総務部総合政策局情報企画課主事

渡邊

貴之

平成22年4月9日

2

アジェンダ

山形県情報企画課の役割

山形県情報システムフレームワーク

アジャイル開発を採用した理由

初めてのアジャイル開発に取り組んで

アジャイル開発における課題

今後の取組み

3

はじめに山形県は、大きく四つの地域（村山地域、 上地域、置賜地域、庄内地

域）に分かれており、それぞれ特有の文化、自然が展開されています。

人口：約120万人

市町村数：35団体

特産品：さくらんぼ、つや姫（お米）ラ・フランス（西洋梨）

話題：おくりびと（庄内地方）天地人（置賜地方）

山形県HPhttp://www.pref.yamagata.jp

山形県の特徴山形県の特徴

4

山形県情報企画課の役割

・情報化に関する施策の総合企画及び調整に関すること。・地域情報化の推進に関すること。

・電子申請システムに関すること。

・行政の情報化の推進に関すること。・情報処理システムの開発及びその支援に関すること。

・県基幹高速通信ネットワークの管理及び運営に関すること。・大型汎用コンピュータの管理及び運営に関すること。

山形県情報企画課の組織体制山形県情報企画課の組織体制

情報企画担当

電子県庁企画担当

基幹ネットワーク調整担当

具体的には・・・

・庁内情報システムの全体 適化

・情報システムフレームワークの運用

・情報システム開発予算の査定

・情報セキュリティポリシーの管理

・各部局へのシステム開発支援

等

ITマネージメント

機能を担う

5

以前の県の情報システム従来のシステム開発・運用の状況従来のシステム開発・運用の状況

HWHW

ｾｷｭﾘﾃｨ

OS

ｽﾄﾚｰｼﾞ

ﾐﾄﾞﾙｳｪｱ

業務業務アプリアプリAA

HW

ｾｷｭﾘﾃｨ

OS

ｽﾄﾚｰｼﾞ

ﾐﾄﾞﾙｳｪｱ

業務業務アプリアプリBB

ｾｷｭﾘﾃｨ

ｽﾄﾚｰｼﾞ

ﾐﾄﾞﾙｳｪｱ

業務業務アプリアプリCC

OS

＋＋

×流用不可

ﾌｧｼﾘﾃｨ（場所、電源

etc） ｲﾝﾀｰﾈｯﾄ回線

[給与] [人事] [総務事務]

（例）・H/WからS/Wまでが密結合状態。どこか一部でも修正が必要となると、ほとんど全ての結合部分（インターフェー

ス）の改修が必要。・各情報システム間のデータ連携不備に

よる事務の非効率化。

・制度改正時等、プログラム改修を行うと、

プログラム以外の部分にも改修が必要。・H/W、S/Wの保守切れによる更新対応に

も、S/Wの設定変更費等、膨大な改修経

費がかかる。

この状況を解消しなければならない・・・

6

情報システムフレームワークの制定

全庁的なシステム開発・運用指針、ＳＩ憲章

（平成17年11月制定）

本県の情報システムについて、特定のＩＴ企業への依存をなくし、適正なコスト及び

適切な技術による開発・運用を図るため、次の３つのルール「依存しないこと」、「公開す

ること」、「共通部品、共通サービスを利用および追加すること」を強く意識してシステム

開発することを定めたもの。

３つのルール

・依存しないこと

：

特定の技術や製品に依存しないこと

・公開すること

：

プログラムソースは全て公開すること

・共通部品、共通サービスを利用、追加すること

山形県情報システムフレームワーク山形県情報システムフレームワーク

7

山形県情報システムフレームワークの概念山形県情報システムフレームワークの概念

全体最適かつ適正なシステム開発、運用を実現するためのＩＴスタンダード

・Webサービス連携を中心としたサービス連携志向（ＳＯＡ）。

・各レイアの分離（差し替え可能）と共通的に使用できるものを共通化し開発、

運用コストを削減。

・オープンソースソフトウェアの採用、ドキュメント管理の一元化、発注区分を小さく

することなどで地元企業への発注拡大（地域ＩＴ産業振興）。

8

情報システムフレームワークにおける アジャイル開発

9.4

アジャイル開発プロセス（P180抜粋）アジャイル開発プロセスの概要「アジャイル」は、「迅速な」「俊敏な」という意味であり、よいソフトウェアを無駄なく、

すばやく作るための開発方法を「アジャイル開発プロセス」と呼ぶ。・・・

・・・また、開発を反復型で行うという点も、アジャイル開発プロセスに共通した点で

あり、本書でも反復型開発を基本原則として取り扱う。

情報システムフレームワークでは、反復型開発プロセスの一種であるUP(Unified

Process, 統一プロセス)を標準の開発プロセスとして利用する。

情報システムフレームワークでは、アジャイル開発をせよ！

と規定している

9

・データ交換・共通機能の

相互利用

HWHW

ｾｷｭﾘﾃｨ

OS

ｽﾄﾚｰｼﾞ

ﾐﾄﾞﾙｳｪｱ

業務業務アプリアプリAA

HW

ｾｷｭﾘﾃｨ

OS

ｽﾄﾚｰｼﾞ

ﾐﾄﾞﾙｳｪｱ

業務業務アプリアプリBB

ｾｷｭﾘﾃｨ

ｽﾄﾚｰｼﾞ

ﾐﾄﾞﾙｳｪｱ

業務業務アプリアプリCC

OS

＋＋

×流用不可

ﾌｧｼﾘﾃｨ（場所、電源

etc） ｲﾝﾀｰﾈｯﾄ回線

[給与] [人事]

ﾌｧｼﾘﾃｨ（場所、電源

etc） ｲﾝﾀｰﾈｯﾄ回線

HW

セキュリティ

OS

ストレージ

ミドルウェア（WAS,DB,ESB)

業務業務アプリアプリCC

業務業務アプリアプリBB

業務業務アプリＡアプリＡ

[総務事務]

[給与] [人事] [総務事務]

従来のシステム開発・運用の場合従来のシステム開発・運用の場合

情報システムフレームワークを遵守した場合情報システムフレームワークを遵守した場合

情報システムフレームワークが目指す姿

キーワードは「シェア」、インフラ構成に限った話ではなく、システム全般について

・・・

アプリ以下は

県は所有し

たくない。

他のアプリ、

製品と自由

に交換可能、

交換しても他

へ影響を与

えない関係。

他システム

情報システム

フレームワーク

・オープンな技術の採用・共通部品構築と活用・システムとデータ連携の構築・マスターデーターの統合・ハードウェアの統合

コスト削減

10

何故アジャイルだったのか？

この思想に合致する手段として、システム開発のアーキテクチャにはSOAを奨励。

・業務の視点から、欲しい機能（サービス）を部品化。

・部品同士は疎結合し、自由に取替可能。

・共通的に利用可能な部品は、今後共通部品化して利用していく。

SOAによるサービスを疎結合させるメリットは他に、

・機能を単純化できる可能性がある。

・機能が小さければ、地元企業でも参入できる。調達に競争喚起できる。

・言語など何をつかっても連携できる柔軟性がある等。

まさに情報システムフレームワークのコンセプトに合致

変更に強いシステムをつくる

情報システムフレームワークのコンセプト

11

何故アジャイルだったのか？

SOAを採用すれば開発は自然にアジャイルになる・SOAによる開発設計を進めると、サービス単位での開発が可能。

・サービスの開発はユーザーとのコミュニケーションが重視され、合意しながら開発。・SOAが変更に強いなら、開発も変更に強い方法がよい。・SOAとアジャイルは相性が良い。

発注者（職員）にとって一番わかり易い開発手法（ユーザー視点）・実物を見ながらシステム開発ができる。・発注者（職員）が積極的に関わることで、開発後の不具合やそれに伴う改修追加費用を削減できる。・これまでの「紙（仕様書）で発注、後は業者丸投げ」のシステム開発を防げる。

変更を前提としている、そして変化に強い変更を前提としている、そして変化に強い

ユーザーが実物を確認しながら開発ユーザーが実物を確認しながら開発

12

最初の取組み～電子申請システム～

◆概要・2003年7月

電子申請システムの開発開始（NECを代表企業とする企業体が受託）

・電子申請システムの共通サービス部分について、アジャイル開発を条件とした仕様（共通サービス部分：職員認証、文書管理機能、ＰＤＦ作成機能）

◆取組み

・受託会社の進捗管理もアジャイルに変更してもらった

・受託会社内にWARルームを設置

→

県の担当者も訪問

・Wikiを導入して県とのコミュニケーションを充実

・ペアプログラミングもやったそうです

詳細はこの後の

ＮＥＣの発表で

◆効果

・発注者としてプロジェクトに積極的に関与したことで、無駄な開発を削減できた。

・自然と適切な進捗管理がなされ、納期内に開発が完了した。

13

その後の課題

◆電子申請システムの開発以降、約30システムの再構築を進めたが、アジャイル開

発を前提とした発注仕様にも関わらず、実際にアジャイル開発に沿った開発は行わ

れなかった。

◆ベンダーは受託時はアジャイルで開発すると言っても、結果的にはウォーターフォー

ルで開発してしまう。

電子申請システム以降、アジャイル開発は普及していない・・・

14

その後の課題

（１）大手はアジャイル開発しない？・大手ほどアジャイル開発体制がとりにくいのかもしれない。大手の内部進捗管理がウォーターフォール管理。電子申請開発受託会社の進捗報告を変えなければならなかった事例がこれを証明。

・大手はbaseシステムと名を変えたパッケージを持ってきた。それは全庁を俯瞰しない業務 適化のパッケージであり、自分の開発工数を減らすため。

・県の考える全庁を俯瞰した機能部品やサービスなどではなく、その業務だけで流通、再利用を考えたもの。（業者を選んだ県が悪いのか？）

・分析設計は現行のシステムとbaseシステムのフィットアンドギャップが中心で、打ち合わせ結果を議事録に起こし、それを承認する方式を要求する。

・制度改正や機能的な漏れが発覚しても確認印を盾に、スケジュールが遅れる、追加費用を払って欲しいと、変更に応じない。

・パッケージカスタマイズビジネスとアジャイルは相性が悪い？

考えられる原因考えられる原因

15

その後の課題

（２）県側の問題・原課担当者はその業務の部分 適だけを望み、全庁的な 適化を考えない。

・ウォーターフォール型の開発に馴染みがあり、完成後の検収まで職員は開発過程には関わらず、業者に丸投げすればよいと考えてしまう。

“良きに計らえ”

・パッケージの方が手間がかからず、担当者の負担も無いと考え、ベンダーが提案する個別 適化されたパッケージをそのまま受け入れてしまう。

・自治体という性格上、基本的に設計と実装のズレは認められない。

・情報企画課のガバナンス不足（体制問題）。情報企画課に強い権限があれば、開発に介入をしていくが・・・

考えられる原因考えられる原因

16

今後の取組み

各課業務フローの可視化

業務を可視化し、業者任せを防止する

職員研修の実施

開発業者とのコミュニケーションを重視し、

丸投げを防止

SOAの推進

自然にアジャイル開発の推進へ

17

古くなった機能

機能

新機能

機能

機能

機能

新財務システム新財務システム

機能

機能

機能

共通Webサービス群（機能部品）共通に再利用する

機能

Webサービス群（機能部品）

単独でまだ共通再利用さ

れていない

機能 機能

新給与システム新給与システム 新建設システムなど新建設システムなど

次期全体最適化（共通Webサービス拡充によるシステム構築イメージ）

ESBESBによるによるWebWebサービスとデータ連携サービスとデータ連携

BPEL（ビジネスプロセスエグゼキューションランゲージ）

Webサービスを組み合わせて、システムを構築する

小さな粒度で地

域企業も参入。

開発後再利用す

る。

取替えや修正

統合データベースと

共通データ

統合DB

共通ﾃﾞｰﾀ

情報システムフレームワークに従ったミドルソフトウェア情報システムフレームワークに従ったミドルソフトウェア

インフラストラクチャー稼動基盤の統一インフラストラクチャー稼動基盤の統一

今後、機能部品は

アジャイル

で開発していく！

今後、機能部品は

アジャイル

で開発していく！

18

以上で終わります。

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