長崎県「戦略的な情報システム調達でIT化を目指すe県ながさき」：第2回

4.　調達のプロセス

日立：
前回（第1回）のご説明で、長崎県では業務システムを構築する際に普遍的なデータというものに着目して、共通のデータベースで管理される情報を基本とする考え方をされていました。そして、共通のデータベースをもとに業務間の相互連携を意識したシステムを業務ごとに開発していくということでした。
では、調達に向けてのプロセスは、最初にデータベースを作り、次に各課の職員さんがデータベースを確認して、最後に発注するための企画書を作るという流れでしょうか。

島村氏：
そうしてしまうと、職員は「自分にはとてもできない」として仕事を投げ出してしまいます。むしろ、次のようにしてはどうでしょう。
業務として毎日携わっているわけですから、どのような改善をしたいかは職員が一番知っていると思います。なら、ポンチ絵（システムとして実現したい画面や帳票の想像図）は絶対書けるはずです。次に、そのポンチ絵を書いた職員にさらに詳しく書けと言わずに、プロのデザイナーに注文してラフなポンチ絵をきれいな絵に仕上げてもらいます。さらに絵が仕上がるのにあわせて、別のプロにお願いしてデータベースのフォーマットを設計してもらいます。最後に絵とデータベースフォーマットが揃ったところで、もう一人のプロに詳しいシステムの設計書(仕様書)を書いてもらいます。
今までのシステム開発では、担当者がITに弱いと感じると経験豊富なSE、それも超がつくようなSEを求めることが多いようです。しかし、3人のプロにお願いして、それぞれが強い分野で仕事ができるよう段取ると、課題は解決できます。

日立：
きれいな絵というのは具体的にはどのようなものなのでしょう。

島村氏：
では詳しくご説明しましょう。
最終的な仕様書は次のようなものになります。具体的にシステムがどう動くか、データベースとのバランスを含めて、画面遷移、業務画面、データベースに格納する項目などがきちんと詳しく書かれたもので、これが最終的な仕様書になります。
仕事を任された担当者というのは、システム開発においてポンチ絵レベルの資料しか作れませんが、発注のときに必要なのは最終的な仕様書です。ポンチ絵とはあまりにも乖離しているので、任された担当者はきちっと仕事をしてくれる超経験豊富なSEが必要と勘違いしてしまいます。

日立：
最終的な仕様書自身も発注するのですか。

島村氏：
発注します。
この例では、最終的な仕様書を作る前に、二人のプロを使って、「画面とフローの要求仕様」と「データベースの要求仕様」の作成を終わらせています。最終的な仕様書を作る人にとっては、あやふやな部分が少ないので手戻りの心配がありません。
担当の職員一人に対して、プロを三人使いましたが、それぞれの専門分野に集中してもらっているのと業務範囲が明確なのでリスクも少ないですし、受注した側でもあれこれと悩む必要がありません。

日立：
確かに、今までの開発工程と、今島村さんのところでやられている工程は明らかに違いますね。普通は、調達で受注したところが、初期段階の設計から関わっていき、先ほどご説明いただいたポンチ絵と簡単な文言で書かれた仕様書が出てきて、それを受注してスタートするとなりますが、これはもう発注前に設計が進んだ状態のものを最終的に調達にかけているという違いがありますね。
行政機関の発注においては、職員がリスクを負うのが嫌で要求定義から開発・運用まですべてができることを条件に大手の1社にやらせようとすることが多いように感じますが、島村さんの進める調達形式は随分と違いますね。また、実現できているところがすごいですね。

島村氏：
このやり方では、行政職員にシステムのプロになれといっていません。全体の5%くらいをお願いしているだけです。残りの95%はプロにまかせています。

日立：
お話を伺う前までは職員の方がいきなり高度な調達スキルをどうやって持てたのだろうと不思議でした。ちょっとした工夫だけで、リーズナブルでいい形になっていくのですね。単純なアプローチの仕方を変えただけで、別にマジックでもなんでもないですね。

島村氏：
そうです、マジックでもなんでもないです。

日立：
ただ、当初にプロが行う設計部分をどのように調達するのかが気になります。普通、行政の調達は入札にあたって審査など調達そのものに対する事務負担も大きいはずで、数を多くすると行政側もつらいと思いますが。

島村氏：
でも、このように分割すると、作業範囲が限定されるので高額な見積もりをする人はいないですよ。結果的に、ほぼ合見積もりで発注できる金額の範囲になります。ですので、職員はちょっと事務負担が増えるだけです。

日立：
時間制約の問題はいかがでしょうか。お話をお聞きしますと、最終的な仕様書に至るまでに期間をかなりかけているように思われますが。

島村氏：
実際、設計段階ではかかります。しかし、その分、開発時の仕様調整やトラブルが減るので、全体の行程としては安心しながらかつ早くできます。

日立：
発注の回数が多いので、長期になるように見えるけれど、トータルでみると短くなるということですね。

島村氏：
さらに、リスク分散もきちんとできるようになります。仕事量として多くないからリスクも最小限になります。もしミスがあっても、どこで発生しているのかわかりやすくなります。

日立：
それぞれ切り出される作業というのは、毎回違うところにお願いするのですか。それとも、この部分はお付き合いのあるところなど固定化したりするのですか。

島村氏：
複数社に発注しています。このような人材は育てていくべきと思っています。「デザインできる人材」も「システム設計をきちんとできる人材」も地域には必要です。

日立：
ベンダに頼らないようにするために、設計資料としてのフォーマットなり、形式を統一していくことは大変ではないですか。

島村氏：
フォーマットの考え方も少し違います。私も大手ベンダにいたのでフォーマットが大事だというのは知っています。ですが、わざと守っていません。大事なことを忘れられては困るからです。仕様書を読んだ相手がすぐ理解し納得してもらうのが大事なのであって、フォーマットが大事なわけではないからです。
理解してもらうには“絵”や“図”が大変効果的です。この仕様書を見ていただいてわかるように、ほとんど“絵”で構成されています。

日立：
フォーマットを統一していこうということはないんですね。

島村氏：
データベースにある情報をどこにどう表示させたいか、そのときの注意事項は何なのかが正しく伝われば、プログラムは組めます。相手はプロなのですから。
フォーマットに意識が行き過ぎてフォーマットを守ることには熱心だけど、相手が理解できないものになっては困ります。ですからフォーマットを決めるのは、誰もが相手に伝えることの重要性を理解してからでいいと考えます。

日立：
要求仕様が曖昧だから手戻りが起こる可能性があるのであって、要求仕様を絶対押さえるという話でそこに注力しているということですね。

島村氏：
そうです。
最終的な仕様書にどうつくるか細かく書いてありますので、これを受け取る開発者も楽だと思います。データベースも明確ですし、そのデータを画面のどこに表示するかも全部書かれているわけですから。

• ページの先頭へ