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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

by Agile Japan on Apr 18, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 26

Statistics