コンサルタントの力
省庁系の仕事に限らないのですが、コンサルタントの「対象化する業務を把握する力」には驚かされることがあります。こんな短期間に、よくここまで調べ上げたなと感心させられることが多々あります。また、将来どうあるべきかもよく検討されており、ITベンダーに属する筆者から見て、敬服すべき存在です。
コンサルタントの限界
上記のように、現状と将来のあるべき姿の分析能力では秀でているコンサルタントですが、泥臭いシステム開発の経験が少ないのは否めません。確かに、開発経験のあるSE出身のコンサルタントの方もいますが、少数派です。
逆に、将来像を省庁に対してよりアピールできるという点で、SE出身ではないコンサルタントの提案の方が有利だと思われます。当然、現状から将来あるべき姿へのフィージビリティ・スタディは行われていると思いますが、技術的な面での判断を除いた提案の方がより魅力的に映ってしまうのは想像がつきます。その提案が技術的に可能かという検討は、落札するベンダーに任せたらいいという流れが感じられるからです。
実は、コンサルタントがITベンダーに技術的判断をすべて任せてしまう現状を、責めるわけにはいかないという面もあるのです。「業務・システム最適化指針（ガイドライン）」の技術体系には具体性が乏しいという弱点が存在することが挙げられます。ガイドラインに示された技術体系を見て、果たして、業務・システムを最適化できるとは考え難いというのが筆者自身の考えです。まだ、完全とは言えない「業務・システム最適化指針（ガイドライン）」をまさに指針とするのであれば、技術的な検討は、ベンダーに任せた方がいいのではという発想に傾きがちなのも無理ありません。
ただし、このような問題点も、技術編第1回「オープンソースで構築」で紹介した「情報システム調達のための技術参照モデル（TRM）（PDF）」の公表により解消する方向に向かうでしょう。とはいえ、コンサルタントだけでは採用すべき技術が決定できない可能性は大いにあります。コンサルタント会社の中でもSE出身のコンサルタントが技術面を受け持つようになってくると考えられます。
ITベンダーとコンサルタントの関係は？
ITベンダーは、コンサルタントから受領する仮の要件定義書を、省庁と「調整し、必要かつ十分な要件定義を確定させ、仕様書（確定版）を作成する」必要があります（※注1）。コンサルタントが仮の要件定義書を作成するうえで、省庁と直接要件を定義できない箇所もありうるという観点から考えると、要件定義では省庁とコンサルタントを交えた、綿密な調整が必要になります。
コツとしては、最初にコンサルタントと良好な関係を構築し、省庁と直接調整する前に、事前にコンサルタントと調整することです。機能要件や関連法令については省庁が詳しいこともあり、直接調整してもよいかもしれませんが、単なる打ち合わせの場であっても、PMOとしての立場から出席するはずで、省庁とベンダーのみで調整を行うことはコンサルタントとの関係構築上望ましいとは言えません。とはいえ、コンサルタントと調整すればそれですべて解決するかというとそれは間違いです。上記のとおり、短期間で作成された仮の要件定義書には不十分な点も多く、コンサルタントと合意できない事項が発生した場合、コンサルタント立会いのもと、省庁との調整が必要となります。コンサルタントとの関係が悪化することのみに捉われてしまうと満足のいく要件定義はできません。要件定義工程に入る前に省庁を交え十分な調整手順を確立することが要件定義の成否を決定する要因になります。第2回「コミュニケーションルートを確保せよ」でも触れているので参照ください。
「第3 業務・システム最適化実施報告書（ガイドライン）（PDF）」の「5 設計・開発 （1）要件定義の確定」（p25）を参照ください。
次回は、技術編の第2回として、「省庁系システムの認証方式」について説明したいと思います。
