SHOEISHA iD

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

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

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

初めての省庁系システム開発(第3回)~受領資料の意味を熟考せよ~

受領資料の中で1番大切な「調達仕様書」の注意点

  • X ポスト
  • このエントリーをはてなブックマークに追加

 この連載では、省庁系システム開発において、著者が経験したプロジェクトを例として、どのような技術を使用したかだけでなく、省庁系システム特有の掟などを書き綴っていきます。本記事では、省庁から受領する多くの資料の中で一番重要で、その後の要件定義工程を進めてゆく上で欠かせない「調達仕様書」について、説明していきます。

  • X ポスト
  • このエントリーをはてなブックマークに追加

はじめに

 一次請けであれ二次請けであれ、または準委任であれ、省庁系システムの開発は、初めて経験するものには戸惑いを与えます。金融系システムや流通系システムなどを経験した技術者にとって、知っておかないとうまく事が運ばないことがあるので注意が必要となってきます。技術面は後ほど紹介することとして、著者が4回の省庁系システム開発で学んだことは次の点です。

  1. 誤字・脱字を侮るな
  2. コミュニケーションルートを確保せよ
  3. 受領資料の意味を熟考せよ
  4. 査読すべき資料を早急に収集せよ
  5. 省庁の影にコンサルタントの気配あり
  6. 自社に馴染んだ開発手法に持ち込め

 第3回目の今回は、「受領資料の意味を熟考せよ」について解説していきたいと思います。

これまでの連載

受領資料の言葉の挑発に乗るな

調達仕様書の存在

 開発がフルスクラッチなのか、あるいは大規模な改修なのかにも左右されますが、受領資料の中で1番大切なのが「調達仕様書」です。ただ、これが非常に曲者なのです。

受領資料の中で1番大切な「調達仕様書」
受領資料の中で1番大切な「調達仕様書」

 後の回で述べますが、省庁でのシステム開発は基本的に「業務・システム最適化指針(ガイドライン)」に従って進められます。このガイドラインを1つの文章に無理に訳すとするなら、「各省庁バラバラな基準・手法で開発していると、非常に効率が悪いし、省庁間で整合性を取りにくいので、基準や手法を統一して開発しませんか」と言った非常に当たり前のことが記述されています。これは非常に評価すべきところです。

 ただ、このガイドラインの根底に流れる思想はEA(Enterprise Architecture)なのです。お気づきかと思いますが、一時期流行していた言葉です。これはバカにしているわけではなく、この事実を知って初めて、ガイドラインを包括的に理解できるようになると言いたいだけなのです。流行に乗るのは一般企業だけではないのです。従って、2009年時点の省庁系のシステム開発はEAの理解が不可欠であるということです。「EAって何?」と思った方は症状が悪化する前にお勉強を始めてください。

誰のためのガイドライン?

 では、このガイドラインは果たして誰のためのものなのでしょう? 答えは調達仕様書を書くためのものです。つまり、コンサルタント会社向けのガイドラインということです。他にも目的はありますが、要件定義時ではこの程度のものであるという理解で十分かと思われます。ガイドラインの第2章(PDF)に次のような記述があります。

 個別管理組織は、最適化計画に基づきシステム設計・開発の調達を行うに当たって、将来体系の標準記述様式と整合的に、次期システムの設計・開発に必要な各要件を定義した仕様書(要件定義書)を作成する。

 ただし、ガイドラインが作成されることにより、特定のITベンダーが独占していた省庁系システム開発に、他のベンダーが参画できる機会が開かれたことは大きなことです。自由な競争により、国民の血税で作られるシステムがよりよい方向に向かうことを願っています。

 また、当ガイドラインにはITベンダーも理解しておくべき点が多く記述されているという意味では、明記はされていませんがITベンダーのためのものでもあると解釈できます。

実情は?

 気になるのは、調達仕様書がガイドラインにどれくらい準拠しているかということです。残念なことですが、まだまだ準拠と言えるほどのレベルには達していません。筆者が係ったシステムでの調達仕様書では記載レベルが異なったり、章立てがそろっていなかったりしていました。調達仕様書も入札により、コンサルタント会社などが落札後、短期間で作成しますので、矛盾点などが存在するのも事実です。

 調達仕様書はあくまでも仮の要件定義書であるので、要件定義の工数は、他のシステムと同様の工数比率で計算しておくのが無難です。要件定義工程から受注するのであれば、あくまでも要件定義工程の責任は受注したものにあるわけであり、調達仕様書を記述した会社にあるわけではないことは非常に重要です。

落とし穴

 省庁の仕事は省令や関連の法律と強く結びついています。調達仕様書の中に「○○法○○条参照」と何気なく記述されているのですが、○○条だけ見ても理解できません。つまり、その法そのものを査読しなければならず、またその法から他の法への参照があったりすると、芋づる式に法を読んでいかなければなりません。法律に通じていればいいのですが、何せ技術屋。日本語で書いてあるのだけは理解できるというものも少なくありません。これらを理解できて初めて省庁の方と会話ができる状態になります。法律に強い要員を1名くらいはアサインしておいた方が安心です。

法律に強い要員を1名くらいはアサインしておいた方がよい
法律に強い要員を1名くらいはアサインしておいた方がよい

教訓

 契約時に「要件定義は、調達仕様書を元に両者で協議して行います」と記述されていても簡単に信じてはいけません。上でも述べたとおり、調達仕様書も完全というにはほど遠く、矛盾するところが散見されます。調達仕様書=要件定義書とは限らないのです。ガイドラインに記載レベルなどが明確に示されることにより今後改善されることが1番いいのですが・・・。見守りたいところです。

調達仕様書=要件定義書とは限らない
調達仕様書=要件定義書とは限らない

 

 次回は、技術編第1回として、省庁系システムを実装する上で役立つ情報を紹介します。

修正履歴

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

  • X ポスト
  • このエントリーをはてなブックマークに追加
初めての省庁系システム開発連載記事一覧

もっと読む

この記事の著者

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

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

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

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

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/4027 2009/07/06 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

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

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

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

メールバックナンバー

アクセスランキング

アクセスランキング