SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

初めての省庁系システム開発

初めての省庁系システム開発(第4回)~査読すべき資料を早急に収集せよ~

慣れないと査読だけで力尽きます

省庁系システム構築の根底にある考え方を知る

 第3回「受領資料の意味を熟考せよ」で紹介した、「業務・システム最適化指針(ガイドライン)」は業務・システム最適化の推進のサイトにあります。このガイドラインが省庁系システムを構築する上での哲学となる資料です。一見、調達仕様書を書く上で必要なだけの文書とも受け取れますが、このガイドラインを元に調達仕様書が記述されるわけですから、その背景を理解するには当文書を見逃すことはできません。

 業務・システム最適化の推進のサイトに、「第2業務・システム最適化企画指針(ガイドライン)(PDF)」があり、12ページ目に調達仕様書に含まれる情報が記述されています。また、18ページ目にはEA(Enterprise Architecture)の思想に沿った文書群が図として示されています。この図に示された文書は受領資料の中に含まれており、要件定義の出発点になると考えられます。業務流れ図や実体関連図も含まれており、新システムの概要を知るには非常に参考になる文書です。

四分類体系と標準記述様式の関係(第2業務・システム最適化企画指針(ガイドライン)P18図4より抜粋)
四分類体系と標準記述様式の関係(第2業務・システム最適化企画指針(ガイドライン)P18図4より抜粋)

 質が高い文書の場合、素直にこれらの文書から、自分たちで得た知識や新たな提案を追加することで、要件工程を進めてゆくことも可能です。注意すべきことは既存システムが存在し、それをもとに新システムを構築する場合です。これらの図は調達仕様書を作成したコンサルタント会社などが描いた将来像であるため、既存システムから乖離しすぎている場合、その乖離を埋めるべきか、それらの図をあくまで参考資料として扱い作業を進めるかの選択が必要となります。既存システムの文書も受領できるので早急な判断が重要となります(受領した業務流れ図や実体関連図を単なる参考資料として扱うためには、それなりの根拠を示し、省庁の方に納得してもらわなくてはなりません)。

 業務・システム最適化指針(ガイドライン)はあくまでも、省庁全般のためのガイドラインであり、省庁毎の詳細な部分は見えてきません。以下に経済産業省のガイドラインを紹介します。

 「EAポータル」からEAも元にした経済産業省のシステム構築に関する考えかたを理解できます。そこから「EAガイドライン」にたどり着くと詳細な情報が得られます。「EAポータル」には経済産業省のシステム構築に必要な多種の情報があります。大切な情報を見逃さないためにも、一通りサイトの資料を確認すべきでしょう。

省庁の仕事は手続きに沿って動く

 省庁は「手続き」と呼ばれる届出・申請から始まる一連の流れで仕事が行われています。「手続き」の理解の深浅により、後工程の苦労が決定すると言っても過言ではありません。経済産業省を例に取ると「電子経済産業省(e-METI)」というサイトがあり、そこに「手続検索」のリンクがあるので、たどり着くことができます。ただし、そこで得られる情報は、利用者から見た手続き情報に限られています。これは当然のことです。届出した後の省庁での仕事をサイトで紹介しても誰も見ないし、見せるべきでないものもあります。従って、利用者から見た手続きは理解しておく必要がありますが、その後の省庁内での手順は要件定義工程でしっかり把握すべき事項となります。

 以下は、要件定義時における手続理解の勘所です。

 受領資料の業務流れ図には届出や申請という大きな括りでの流れ図は存在しますが、個々の「手続」についての流れ図は存在しないことがあります。従って、大きな括りの業務流れ図を参考に、個々の「手続」についての理解が必要となります。

  1. 手続の目的・ゴールなどを明確にする
     
  2. 手続特有の業務の流れがないか辛抱強くヒアリングする

     省庁の方にとっては日常業務となっているため、個々の手続で業務の流れを意識していないことが多いです。最初に省庁系システムの要件定義で、このヒアリングを怠ったため、要件定義で行うべきことを基本設計で行うことになり、大きな進捗遅れを招いたという痛い経験がありますので、ここは「辛抱強く」ヒアリングするしかありません。

  3. 手続間に関連がないか確認する

     関連を明らかにすることも非常に肝要で、2と同様、「手続」には関連性が存在することを基本設計時になり気づき、2と同じ結果を招きました。「A手続をトリガーとし、B手続が起動する」「A手続が承認されない場合、B手続も無効となり、A手続からやり直す必要がある」など関連性を要件定義時にどれだけ洗い出せるかにより、その後の工程の工数が変化します。つまり、常識ですが、要件定義時にすべて洗い出せれば、後工程の工数は減るということです。

  4. 支障がない限り、現場の作業を見せてもらう

     なかなか実現しませんが、依頼してみる価値は大いにあります。全手続は無理にせよ一部でも見せてもらうと理解は深まります。

  5. 画面や帳票の実際のデータを見せてもらう

     4と同じですが、少ないヒアリングの中で理解していた帳票の要件が、実際の帳票を見て、一変したということを経験しています。今では、要件定義に入ると同時くらいに4と5は省庁の方に要望し、早急に実現できるよう動いています。

技術は何を基準に選択するのか

 以前からよく指摘されていたことですが、業務・システム最適化の推進のサイトの技術体系だけでは、省庁が目指している最適化は望めません。なぜなら、最適化を達成するために採用すべき技術が記載されていないからです。それを補うものとして、初めての省庁系システム開発(技術編第1回)~オープンソースで構築~で紹介した「情報システム調達のための技術参照モデル(TRM)」が公表されました。

 例としてBI(Business Intelligence)を挙げると、p37にBIの機能要件、非機能要件、標準的な技術が明確に示されています。標準的な技術では「ISO/IEC11179(メタデータレジストリの国際標準)」と「JIS X4181-3(ISO/IEC11179のJIS化作業結果)」が必須となっており、順守しなければならないことが分かるようになっております。他の文書も同様ですが、当文書に関しては今後頻繁に改定される可能性があり監視対象の文書とすべきでしょう。

 なお、政府機関のセキュリティ基準については、「技術編第3回~政府機関のセキュリティ~(仮)」で紹介します。

 次回は、第1回でも少し触れましたが、要件定義時に特に重要な「コンサルタントと省庁の関係」について紹介します。

修正履歴

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
初めての省庁系システム開発連載記事一覧

もっと読む

この記事の著者

チャーリー・佐藤(チャーリー・サトウ)

ここ10数年、プロジェクト・マネージャやソフトウェア・アーキテクトという一見相いれない仕事を繰り返してきました。プログラミングも大好きで、自宅ではいろんな言語を楽しんでいます。年齢も40過ぎ、徹夜の連続では耐えられないようになってきました。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/4041 2009/07/20 14:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー