初めての省庁系システム開発（第5回）～省庁の影にコンサルタントの気配あり～

はじめに

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

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

　第5回目の今回は、「省庁の影にコンサルタントの気配あり」について解説していきたいと思います。

これまでの連載

　本編

• 初めての省庁系システム開発（第1回）～誤字・脱字を侮るな～
• 初めての省庁系システム開発（第2回）～コミュニケーションルートを確保せよ～
• 初めての省庁系システム開発（第3回）～受領資料の意味を熟考せよ～
• 初めての省庁系システム開発（第4回）～査読すべき資料を早急に収集せよ～

　技術編

• 初めての省庁系システム開発（技術編第1回）～オープンソースで構築～

省庁の影にコンサルタントの気配あり

　省庁系システムの開発において、企画工程と設計・開発工程の両工程を同じ会社が受注することはできません。従って、シンクタンクなどのコンサルタントを行う事業者は企画工程を、ITベンダーが設計・開発工程を受注するような棲み分けが行われています。

コンサルタントとITベンダーの関係

コンサルタントの悩み

　コンサルタントの主たる成果物は「調達仕様書」です。短期間で現行調査と将来のあるべき姿を示さなくてはなりません。この作業の結果、「業務システム最適化指針（ガイドライン）」の中の現行体系、将来体系と呼ばれるものが明らかになります。ただし、これらの作業が非常に短期間ということもあり、ITベンダーが受け取る仮の要件定義書（調達仕様書）は完成度としては高くありません。従って、本当の要件定義工程時にはITベンダーから大量のQA票が送られ、その対応に追われることになります。

　さらに、コンサルタントはその後PMO（project management office：プロジェクトの支援を目的に設置される専門の部署）という形で省庁内に残ることが多いため、省庁としてITベンダーのその後の作業の指導・監督を行うことになります。省庁の方は政策絡みの仕事がしたくて入っている方が多いため、システム周りのことに関しては疎かったり、興味を示されなかったりします。このような事情のためPMOはシステムに関する提案作りを行ったりすることになります。

　現実問題として省庁には多くの文系出身、特に法学部出身者が多いことは事実です。省庁は文系出身者以外にも理系出身者も採用し、もっと積極的に「e-Gov」を推し進める必要があります。省庁系内のシステムに限らず、競争力がなくなりつつある日本のIT力を建てなおすには、日本全体のIT化のグランドデザインが行える人を養成しなければならないのではと感じています。そのような人物により、民間の力が最大限に発揮できる環境を整えることが必要です。