お役所のためのシステム開発のヒント

「こんなはずでは・・・」をなくすために

ここでは、情報システム開発を発注した際に最も重要となる仕様書作成にポイントを絞って説明しています。なぜ仕様書が重要かということですが、意外にこの仕様書というものがシステム開発の発注時に重視されていない気がします。システム開発者の業界では「発注者の言ったとおり（書いたとおり）のシステムを作っても発注者が思ったとおりのシステムは完成しない」といわれており、システム開発においては、この発注のための仕様書次第でシステムの良し悪しが決まるほど仕様書が重要な位置を占めています。

そもそも「仕様書とは」

国語辞典（大辞林）で「仕様書」を検索すると「やり方や、その順序を記した文書。」と記されています。システム開発には様々な段階・場面（フェーズ）が存在します。実は、仕様書といってもその場面ごとに仕様書が存在しますので、自分が行っているのはどの場面のどのような内容かをしっかり理解していないと、「こんなはずでは・・・」ということになってしまい、開発は失敗に終わります。

発注を行うときに、一般的に「仕様書」と呼ばれているのは、システム化のための要件定義が終わった段階を文書化した「システム化要求仕様書」のことを指していると思いますので、ここではそれを前提に話を進めます。

システム開発の手順（用語の統一が必須！）

私がかつて所属していた組織では、システム開発において「概要設計」「基本設計」「詳細設計」という用語が一般的に使われていましたが、それぞれの段階で何をするのかということは正確に定義されていない、もしくは理解されていないと思います。

また、受注業者がたまたま同じ用語を使った場合、その対象とする範囲が違っていると、委託内容に錯誤が発生しかねないという事態も生じます。そこで、システム化構想が出来た段階からこれらの用語を、受託業者も含めて統一するべきだと思います（もしくは、統一された用語・発注手引書を作るべき。）。

独立行政法人 情報処理推進機構（IPA）では、「情報処理技術者スキル標準（ソフトウェア開発技術者）」の中で、システム開発業務プロセスを次のように定義しています。

（図）システム開発作業プロセス（出典：IPAソフトウェア開発技術者スキル標準から）
※これらの詳細は、IPA「ソフトウェア開発技術者スキル標準」を参照ください。

システム化のための前提として検討すべきこと

システム開発をする際にはコンピューター的な視点に陥りがちですが、実際のシステム化では現行業務を正確に分析しビジネスプロセスを洗い出すということが一番重要であり、かつ、時間をかける必要があります。

このように書くと大げさですが、要するに、今どのようなやり方で仕事をしていて、そこにどのような問題点があり、それを解決するためにどのように仕事を変えるか。そして、その改善されたプロセスのどの部分を情報システムが担うかということが正確に定義されていないと、せっかく開発したのに「こんなはずでは・・・」とか「全く役に立たない・・・」ということになります。

誰が（主体）、何のために（目的・結果・効果）、何を（対象・範囲）、どうするのか（処理）ということを明確にした上で、システム化の範囲（対象）を決定しないと（システム化構想を描かないと）システム化の方向性さえも誤る危険性を持っています（特に、事業に対して経営感覚や危機感のないお役所の場合、この部分が非常に軽視される傾向にあります。）。

以上を踏まえた上で、発注の仕様書を書くための要件（システムであんなことをしてほしい！こんなことを実現してほしい！というリスト）が絞り込めることになります。

システム化要求仕様書 作成時の注意点

「こんなはずでは・・・」という最悪のシナリオがどうして起こり、どうすれば改善できるのかを具体的な例で解説したいと思います。下記には発注者と受注者の間でよく取り交わされるトラブル時の一言とその解説を記載しましてみました。（注：この箇所は、もともとは本文と連動して記載されていましたので、内容が一部わかりにくくなっている箇所があります。ご了承ください。）

「御社が意図している内容は、仕様書に明確に記載されていない」

システム化要求仕様書が曖昧、もしくは、仕様自体に不備があり、詳細が記載されていないためシステム化の範囲が明確になっていない。

例えば、普段、卓上で使っている電卓の仕様を考えてみてください。

• 四則演算が可能なこと
• メモリー機能があること
• １２桁まで表示できること

以上のような仕様を考えがちですが、このメモリー機能とは何を指しているのでしょうか。メモリー機能というのは、値を一時的に保存して後で使うというのは一般的ですが、これをどのような場合にどのように使うかまでは明記されていません。また、メモリー保持のサイズや回数（履歴？）なども同様に明確になっていません。四則演算としか書かれていないので、普通に考えれば「加減乗除」なのでしょうが、マイナスの計算は？とか、小数点への対応は？とか数え上げるとキリがないくらいです。

このように、一見単純な電卓ですが、機能要件を丁寧に拾い上げるとかなりの量になります。最悪なのが、「四則演算が可能で適切に機能する電卓であること」などという表記です。「適切に」というマジックワードは社内では便利な言葉として重宝するかもしれませんが、システム開発の要求仕様書ではトラブルを招く以外の何物でもありません。

以上のように、「一定の水準で」とか「適当・適切」といった定性的な記述は仕様書に使うべきではないでしょう。どの程度の水準、どの程度適切といった具体的事例もしくは数値を明記すべきです。

また、システム開発は「業務」ということが主体ですので、仕様書には現行業務がどのようになっているのか、という現行業務の詳細な解説書をつけておく必要もあります。

ＩＴ関連の発注になれた方々の中には、「仕様書はなるべく幅を持たせてぼかして書くのが契約後に柔軟に対応できていい」などということをおっしゃる方もいます。「なぁなぁ」でシステム開発ができた時代は確かに、「決まった予算でうまいことやっといて」くれたかも知れませんが、こうすることでトラブルも増えます。

さらに、内容をよくわかっている業者だけが正確に見積もれる（つまり安く落札できる）という不公平感も生み出しています。それ以前に、先ほどまでの内容から「あいまい」さがもたらす不利益の方が大きいことがわかってもらえると思います。

「仕様変更は口頭ではなく書面で依頼して欲しい」

お役所に限らず、なにか書面を発行する場合には、通常決裁権者の「決裁」が必要となるため、担当者は文書作成を避ける傾向にあります。「うまくしといてよ」とお願いし、営業が「いいですよ・・・」と安請け合い。これが後から「言った、言わない」のもめ事になり、さらには訴訟になった場合、書面がなければ負ける可能性が高くなります。

仕様書は契約書の一部。つまり仕様の変更は契約書の変更です。契約内容を変更するには決裁が必要。また、自分たちを守る意味でも必ず書面で仕様変更依頼をしてください。

「パッケージソフトのやり方にできる限り合せて欲しい」「既存システムからのデータ抽出やデータ登録作業などは、御社の役割なので御社でやってもらいたい。」

これも、仕様が詳細に固まっていないことが原因でおこるトラブルです。このようなものを作って欲しいと詳細に書かれた要求仕様書での見積もりであれば、それで提案した業者の責任になります。これも、仕様が曖昧なことが原因です。

「データ登録作業やデータ抽出なんて当然受注した業者の仕事でしょ？」と思いがちですが、システム化要求仕様書にかかれていなければ業者の仕事ではありません。このあたりの条件もしっかり検討しておく必要があります。

「手作業でやっていることはすべてシステムで自動的」

最近のシステム開発の根本的な間違いの一つが上記です。業務をシステム化すればボタン一つで業務が終了するかのような錯覚をしている人が多いです。ご飯を炊く場合でも炊飯器でボタン一つ！といいながら、米の量を決め、研いでから、必要な分量の水を調整した上でスイッチポンです。

システム化は現行業務をスピードアップしたり軽量化したり付加価値をつけるために行っているのです。完全機械化するためではありません（最初の「システム化の前提として検討すべきこと」でも書いています。）。使うのは人間、考えるのも人間です。機械が行って効率的な部分は機械に、人間がすべき部分は人間が、というのが原則です。

「開発中なら、関連する業務もシステム化して欲しい。」

システム化に際して、非常にリスクの高い発言です（お役所でシステム発注に慣れた方々がよく口にする内容でもありますが・・・）。

ついでに関連する業務もシステム化して欲しい、というのは一見仕様書の変更にも見えますが、中心は「業務もシステム化してほしい」です。つまり、「タダで作って！」ということです。本当に業者に要求するのであれば仕様変更の手順を踏むか、別途契約書を作って書面で管理すべきです。

もし、対応してくれたとしても、今後のメンテナンスやシステムが機能しなかった場合の補償問題が起きる可能性があり、どこまでがシステム化した業者の責任となるかが曖昧になりますので、正式に依頼するのであれば正式な契約書を交わすべきです。

以上のように、情報システム開発を発注する際には、できるだけ詳細なシステム化要求仕様書を作成し、いったん決めた仕様書は安易に変更しないということが重要となります。

多少の不具合やミスは改善へのステップとして前向きに捉える

システム開発において欠陥や不具合はつき物です。これらを最初から見込んでスケジュールや予算を立てる必要があります。これらを次の改善等に向けて蓄積していくことで、上手なシステムライフサイクルを築くことが可能となります（お役所の事業では「絶対にミスはない、正しい」という一種の思い込みがあります。）。

一方、根本的に土台から作り直さなければならないほどシステムがおかしいという場合は要求仕様書に問題があります。これは発注者側のミスということになります。

良い業者のみつけ方（参考までに）

システム開発では、エラー（プログラムのミス）が発生して当然というスタンスで開発を進めることが最も重要だといわれています。システムテストや稼働の段階でエラーが発生して、「こんなはずではないんだけどな、、、」とか「ちゃんと動くはずですが、、、」と、エラーに驚くような技術者（ＳＥ）は良い業者とは言えないといわれています。

一方、「やっぱり、ここでエラーが発生したが、、、」と冷静にエラーを見つめることが出来る技術者（ＳＥ）は質の高いシステム開発ができるといわれています。システム開発におけるシステムテストの目的が「エラー（ミス）の発見」ということからも理解できると思いますので、逆に、何の不都合も起きないシステムテストは失敗だと評価されます（一般的感覚と逆になります。）。

このあたりは、一般の感覚と反対に映るかもしれませんが、システム開発で業者を見分ける重要なポイントとなりますので参考にしてください。

発注後のプロジェクト管理を怠らない

一般に、お役所では、予算を獲得し発注したら仕事が終わりと考えられていますが（もしくは、その後のプロジェクト管理が重要な仕事だという認識に欠けている。）、このプロジェクト管理をしっかり行わないと、出来上がった情報システムの質を大きく左右することとなります。

要求仕様とは「できることリスト」なので、そのリストを実現するための外部設計、内部設計、最終的なプログラミングおよび成果（ソースコードやプログラム設計書を含む）の過程において、決定事項や成果品が文書化されているか、また、それらが要求事項を満たしているかどうかを確認していく必要があります。

画面の遷移やデータ保存の考え方等要求仕様には書かれておらず、かつ、発注者の責任が大きい部分（特に運用に影響を与えるような内容の部分）については、開発の節目ごと成果を確認していく必要があります（一般に「レビュー」と呼ばれます）。

また、発注時のスケジュールも適宜（出来れば２週間に１度程度）確認し、スケジュールどおりに開発が進んでいるかも管理します。スケジュールどおり進んでいないということは、最初の業者の提案や見積もりが甘いか、仕様書に根本的なミスがあるかのどちらかです（スケジュール（納期）も契約の一部！）。

最終的に、ソフトウェア（システム）の納品となった場合、その外部設計書、内部設計書、プログラム設計書、ソースコード等の詳細な仕様書（この仕様書は「システム化要求仕様」ではなく、システムやプログラムの製品仕様書です。）を文書化したものも併せて納品してもらいます。これら全てがそろって情報システムです。また、これらがないと、システム改修や再開発等における費用積算にも大きな影響を与えます。

大抵の場合、これらの文書が存在しないため、当初に開発した業者しか変更ができないという事態に陥り、一般競争によるシステム改修の発注を妨げています。これら納品物（完成図書）は家を建てるときの設計書に相当し、これがあれば、基本的には作業員が変わっても作業が可能です。

最後に、素人がわかる仕様書であること

情報システム開発の発注で「仕様書」を作るというと、専門的な知識や技術が必要と思われる方も多いですが、基本的には利用者の視点からの「こんなことがしてほしい・・・」という内容の文書を詳細に書いたものに過ぎません。

結局、発注する側と受注する側とのコミュニケーションは仕様書を通してしか理解されませんので、「わかりやすい（つまり、曖昧な点がない）」ということが大原則となります。良いシステム化要求仕様書が書ければシステム化の半分は成功といっても過言ではありませんので、これらの点に注意して最高の仕様書を作りましょう！

関連するリンク

• 仕様書