はじめに
一次請けであれ二次請けであれ、または準委任であれ、省庁系システムの開発は、初めて経験するものには戸惑いを与えます。金融系システムや流通系システムなどを経験した技術者にとって、知っておかないとうまく事が運ばないことがあるので注意が必要となってきます。技術面は後ほど紹介することとして、著者が4回の省庁系システム開発で学んだことは次の点です。
- 誤字・脱字を侮るな
- コミュニケーションルートを確保せよ
- 受領資料の意味を熟考せよ
- 査読すべき資料を早急に収集せよ
- 省庁の影にコンサルタントの気配あり
- 自社に馴染んだ開発手法に持ち込め
第2回目の今回は、「コミュニケーションルートを確保せよ」について解説していきたいと思います。
これまでの連載
コミュニケーションルートを確保せよ
誤字・脱字の失敗でめげている場合ではない
第1回「誤字・脱字を侮るな」でも記述したとおり、最初にこの失敗を犯してしまうと、その後のコミュニケーションが楽ではありません。だからと言ってコミュニケーションを諦めていたらプロジェクトの失敗は必至です。精神論に近いものになりますが、プロジェクト計画書に従って、会議体の設定、課題表、QA表の運用ルールを早急に決定しないと、要件定義工程がストップしてしまいます。
この問題の解決に特別なノウハウはありません。正攻法が1番です。まずは今後、誤字・脱字を無くすための具体的な対策を示し（場合によっては、誤字・脱字があったら一定のペナルティを自ら提案するなど）、粘り強く交渉あるのみです。
過去の教訓
2次請けで仕事をしていたときの話ですが、QA票を大量に作り、1次請けの会社に提出したのはいいのですが、回答期限が来ても音沙汰なしでした。単に確認を取るだけのQAでも回答がなかったために、1次請けの会社に問いただしたところ、QA票は一切省庁に投げていないとのこと。理由がなんと「誤字・脱字を精査しないと提出できない」というものでした。精査なんて少し時間をかければできるはずです。
結局、本当の理由は1次請けの会社の課題担当者が誤字・脱字で省庁からお叱りを受け、すっかり怖気づいて提出できなかったためなのです。その省庁の担当の方は、筆者らが2次請けであることはご存知であったため、筆者の会社が要件定義をストップさせているように見えてしまい、きついお叱りを受けた記憶があります。これは課題担当者だけでなく、1次請けのPM・PMOさえ提出するのをためらっていたためでもあります。しかし、叱られるからといってコミュニケーションルートを確保しないのは、さらに状況を悪化させるのみです。
肝心なのは、失敗に対する対策を立て、それ以降に信頼を回復することなのは言うまでもありません。
忙しいというだけでは・・・、5W1Hを徹底調査することで乗り越えよ
省庁の方が忙しいのは、タクシーを使って帰宅していたのを終電に変えたりしたニュースがテレビで流されているので状況は理解できます。ただ、それで会議体やレビューを「忙しいから」と言われて「了解しました」と返事するのでは困るのです。直接の利用者である省庁の方の協力無くして要件定義の成功はありえない。要件定義の成功無くしてプロジェクトの成功はありえない、という至極当たり前のことを説得するしかないのです。
ただし、省庁には繁忙期というものがあることは調べておいた方がいいでしょう。省庁には大量の届出が提出されますが、その期限前後は確かに「忙しい」のです。ちなみに今のプロジェクトでは繁忙期を事前に把握していたので、うまく会議やレビューを行うことができました。5W1Hで忙しさを整理し、その対策を打つべきなのです。繁忙期の例はWhenで、担当者がWhoで、・・・と整理することで、適切なタイミングでのコミュニケーションが可能となるのです。
省庁のシステムは手続き（届出）ベースです。つまり、紙の時代のカラーが抜け切っていないのです。また、オンラインでの届出が義務化されているところは（筆者の知る限りでは）ないのではと思います。つまり、紙ベースでの届出とオンラインでの届出の平行運用を行っていると思われます（総合的な行政ポータルサイト「e-Gov」の利用は数パーセントにとどまっているという調査もあります）。従って、現行業務を調査すると、どの時期にどういう役割の人が何の仕事をやっているかは思ったよりも情報としては入手しやすいのです。また、このような情報を入手できないのは、業務理解を得るための方法論に問題があるということでしょう。
切るタイミングが難しいカード
実は、次回に紹介する「業務・システム最適化実施指針（ガイドライン）」（PDF）のp25に次のような記載があります。
企画段階で作成した仕様書（要件定義書）においては、不確実、不足又は過剰な要件が存在する可能性があるため、個別管理組織は、必要に応じ、設計・開発事業者等の関係者と調整し、必要かつ十分な要件定義を確定させ、仕様書（確定版）を作成する。
難しいと言ったのは、第5回「省庁の影にコンサルタントの気配あり」でも触れますが、仮の要件定義書を作成するのは省庁ではなく、コンサルタントであるからです。
省庁から時間がないと言われた場合、「ご存じのように業務・システム最適化実施指針（ガイドライン）にもありますように、基本設計のインプットとするためにヒアリングして確認しておきたいことがあります。基本設計以降スムーズなシステム開発を行う上で非常に重要となりますので、忙しい中、重々承知しておりますが、お時間を頂ければと思います」と言えるところですが、コンサルタントから見たら心中穏やかではないことは察しがつきます。自分たちが作った要件定義書のどこに不確実さ、不足などが存在すると言うのか、とクレームが来るのはもっともな反応です。一番望ましいのは、契約時に要件定義書を完成させるために、コンサルタントの十分な協力が必要と謳っておくことです。それでも難しい場合、コンサルタントの協力を得られるよう、省庁と直接交渉するしかありません。
次回は、省庁系システム開発に関わるうえで受領する資料のそれぞれの意味や、その中でも一番大切な「調達仕様書」の注意点について紹介します。
