顧客満足度120%を目指すシステム開発(第1回)
〜開発内容が決まるまで〜

「顧客満足度100％を目指す」と書くと、 何十年もソフトウェア開発に携わってきた一流エンジニアのようで、何だか気恥ずかしい気がします。私自身は、システム開発という業種に入ってから未だ10年にも満たない、ベテランと呼ばれるのは何年後？というキャリアに過ぎません。そんな私ですが、幸いこれまで、多様な仕事の機会に触れ、多くの優秀な方々と出会いながら、ある時はシステム構築側企業の代表として、またある時は受注側企業の要員として、時には元請会社のマネジメント役として、システム開発の現場で働いてきました。私のコラムでは、そのような経験や、出会った方々（実際にお会いしてはいないが、書籍などを拝見しただけの一方的な出会いを含め）の言葉を借りながら、弊社の目指すシステム開発の方向性を、工程ごとに数回に分け、お話ししてみようと思います。

曖昧な要件内容、曖昧な契約内容

元通産省情報処理システム開発課長を務められた方が、「電子政府における情報システムの調達問題を解く」というタイトルの論文中で、「そもそも日本のビジネス慣行では、欧米に比べて契約書の比重が低い。政府のITサービスにおいては、調達仕様書(RFP：Request For Proposal)が明確に作成できず、発注のスペックもあやふやであったから契約書もあいまいに結ばざるをえない。その結果、不透明な価格設定や品質の信頼性低下をもたらしてきた。今後は官民の責任分担を明確化した契約書を締結するべきである。」と論じているのを拝見したことがあります。

こういった傾向は決して政府調達に限った話ではないように思います。
近頃は、官公庁でさえもCIO(Chief Information Officer：情報戦略統括役員)という言葉を目にするようになりましたし、幾多のセキュリティリスクの高まりや個人情報保護法を代表とする情報保護の必然性を感じ、発注者側も自身の大切なシステムをベンダに丸投げするのではなく、十分に理解・検討していこうという流れにあるように感じます。

弊社は、システム開発の受託開発を行っていますから、業務受託側となるのはもちろん、再委託する場合には業務委託側にもなります。弊社では、『要件の管理』や『契約』ということをCMMIプロセス上でも非常に重要な側面と捉えています。それは、後々問題が起きた時に交渉を有利にしようという自己防衛のためにそう考えているのではなく、開発するシステムがお客様である企業でどのような戦略・戦術の中で発生し、どういった目的を持ち、どのようなアクター（登場人物）があり、という基本的な前提条件を明確に理解できないままに、お客様と共通のゴール形成が出来るはずがないと考えるからなのです。

曖昧な要件から、明確な要件へ

弊社のシステム開発プロセスでは、要件定義も曖昧なままに設計・開発へとは進めないようになっています。しかしながら、実態としては必ず要件が確定した段階で引き合いがある訳ではありません。要件も不明確なままに見積もり費用が先行している場合、内容の詳細化はともかくサービスインの時期だけが決まっている場合等々、案件の発生は実に様々です。
システム開発では、開発する内容に応じて様々な開発ライフサイクルが存在しています。

• 上流工程から下流工程へ流れていくウォーターフォール型
• 試作版のリリースとそれに対する評価をもとにリリース版を開発するプロトタイプ型
• 機能ごとなど部分的なリリースを繰り返しながら完成に近づけていくスパイラル型

弊社では、基本的には上記の3つの型を混合させた下図ような形を、大規模システム開発時の標準工程として採用しています。

拡大する（GIF画像、24KB）

プロトタイプに対するコスト（費用・時間・要員）をどれだけかけられるかというバランス取りは必要かと思います。しかし、一昔前、アプリケーションが全てメインフレーム上で稼動していた頃と異なり、お客様も新しい技術や新しいインフラに追随していくことは容易ではないはずですから、やはり今回のシステムの感触を掴んで頂くためのプロトタイプの実施は、「百聞は一見にしかず」の言葉通り、お客様の期待する姿を確認するための何よりの機会です。

また、基本設計の時点でマニュアル作成を盛り込んでいるのはあまり例には無いかもしれません。私の思いとして、お客様に要件をご確認頂く書類は、お客様の視線で理解出来るものでなければならないと考えています。『機能設計書』も、単独で読んで頂いても十分に意味が伝わるようにという流れで作成しますが、一番分かり易いのはマニュアル類ではないかと思うのです。ただ、この時点でのマニュアルは、実装前のものですから、リリースまでに改修が必要になってしまうという手間は発生するのですけれど。

ヒアリングの時間は決して省きませんし、作成するドキュメントの分だけレビューも発生しますし、お客様のプロジェクトご担当者にもそれなりの時間を割いて頂くことにはなってしまいます。プロジェクトのご担当者が忙しい余りにプロジェクトの進捗が滞るようであれば、場合によっては専門要員の確保をお願いすることもあります。それ程に、要件定義という作業は、委託側・受託側双方でそれ程の労力をかける必要のある大切な工程と言えます。

要件が明確だから、見積もりも正確に

こうして要件が明確になって初めて正確な見積もり（費用・期間など）を算出できることになります。弊社の見積もり方法は、案件の規模やタイプにもよりますが、「システム開発」と呼ぶ規模の開発案件にはFP法を採用しています。名前をご存知の方も多いかと思いますが、大雑把にFP法を表現すると、入出力データとそれを操作するための機能数や難易度をもとにシステム規模を算出する方法で、数値ベースの見積もり手法としては、比較的メジャーなものです。

市販パッケージとは異なり、システム開発の費用の妥当性というのは、きちんと提示するのが難しく、またお客様にとっても、何を基準に高い、安い、妥当を判定するのか難しいというのが現実です。しかし、そこに甘んじず、費用を提示する側の責任として、提示費用の根拠を可能な限り明朗に伝えなければならないと思っています。ファーストフード店に行って何種類かの商品を注文した時に、もし明細がなく合計金額だけ請求されたらきっと納得しないでしょうし、もし明細を提示されても、ジュース類が一般に何円くらいで売られていて、似たようなものが他店では何円で売られていてという知識が全く無ければ費用の妥当性は分からないに違いありません。

システム開発についても「どうせ分からないから」ではなく、お客様にしっかり検証して頂きたいと思いますし、そのための一つの根拠がFP法によって算出する費用明細です。FP法を適用するには、ある程度まで要件が洗い出せていることが前提条件となります。ですから、要件も確実でないうちに「見積もりだけ下さい。」というリクエストには、時としてお応えできない状況も発生しています。しかし、自分たちでさえもカンでしか分からない見積もりをお客様に提示することは、何だかとても無責任な気がしてならないのです。

要件に関するお客様のとの合意

弊社が、CMMIというシステム開発のフレームワーク作りを行っていることを過去のコラムでご紹介させて頂きました。その中で、今回の要件が決まるまでの間に、どれだけの事をお客様と合意すべきと定義しているかを幾つか抜粋して書いてみます。ただ単に渡して捺印を取るだけでなく、『説明』も制度付けている点もよくご覧下さい。

• 受託条件明細書（業務内容や費用・スケジュールを記載したもの）を顧客に説明し、合意を得ること。
• 個別契約書を顧客に説明し、合意を得ること。
• 要件の発生や追加・変更についての会議を開催した場合は、要件管理シートを作成し顧客のレビューを受けること。
• システムの新規立ち上がり時には、要件が確定するまで顧客との会議を繰り返すこと。
• 要件定義書作成完了後は、顧客を含めたレビューを実施し、合意を確認すること。

どうでしょうか？これでも未だ不安は残るでしょうか？
もし、このような面倒くさいまでのやり取りを厭わず、システム開発の満足度を120％味わいたいお客様がいらっしゃいましたら、是非弊社へご一報頂ければと思います。