「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより（発行日順）のページへ
 ソフテックだより技術レポート（技術分野別）のページへ
 ソフテックだより現場の声（シーン別）のページへ

ソフテックだより第３５号（2007年2月7日発行）
現場の声編

「顧客要求を読み取ることの難しさ」

1.はじめに

ソフテックではソフトウェアの受託開発を行っていますが、1本のソフトウェアを作り上げるのには様々な難しさがあります。
ソフテックでは顧客によって様々な開発スタイルをとります。
ウォーターフォール型、スパイラルモデル、プロトタイピングなどその時によって様々ですが、ウォーターフォール型の開発モデルでソフトウェア受託開発を行っている場合、最初のソフトウェア開発計画立案の段階は特に重要です。
この段階で、「顧客が行いたいことを正確に掴み、さらにできるだけ具体化したソフトウェアのイメージを準備し、正確な作業ボリュームを算定する」ことができれば、プロジェクト成功の確率は高くなります。
実際これは大変難しく、自分も大変苦心しております。
今回は、私がプロジェクトリーダーとして担当したプロジェクトにおいてどのように顧客要求を読み取ったかを御紹介させて頂きたいと思います。

2.担当プロジェクトについて

担当したプロジェクトについて簡単に概要を説明します。

(1) 開発ソフトウェアについて

ソフトウェアはWindowsアプリケーションであり、画面数、帳票数それぞれ20枚弱のボリュームを持ちます。約2MByteのバイナリファイル形式設定データを作成するソフトウェアで、この設定データはターゲットとなる装置で物件毎の固有設定データとして使用します。
CANやシリアルでの通信機能を備えており、装置へデータのダウンロードやアップロードが出来ます。

(2) 仕様検討期間

引き合いの話があってから製作仕様書をまとめあげるまで、3ヶ月ほどかかっておりますが、仕様検討は自分が一人で行いました。要した時間は2ヶ月間です。
顧客より開発要求仕様書の提示があり、それをもとに仕様検討をすすめました。

3.基礎知識・用語の理解

顧客の業種に関する事項、製品、システムについて基本知識を勉強します。
当たり前のことですが、顧客はその業種におけるプロフェッショナルですから、打ち合わせの際には専門用語や業界用語が飛び交います。
これらについて可能な限りの知識を習得しておくことが、重要です。
最低限の知識がなくては顧客の話が理解できませんし、顧客も不安を感じてしまいます。

自分が担当したプロジェクトでは幸いなことに社内で、関連システムのソフトを開発している担当者がおりました。
知識のない自分はその知識を得る為に次のようなことを行って数日間準備しました。

レクチャーを数日受ける。
システムに関する顧客の紹介ビデオ、パンフレットを熟読し、概要を掴む。
関連システムのソフト動作確認を行う。

4.顧客との打ち合わせについて

打ち合わせは効率を重視するようにしました。
単純に回数を重ねればよいという考えもありますが、それよりも事前検討をソフテックと顧客で十分に行う方が、成果があるという考えからです。

開発計画を作るまでに計3回、打ち合わせを実施しました。
一度目は、顧客担当者との顔合わせも兼ねつつ、ターゲットとなるソフトウェアの概要・納期・背景を伺いました。特に開発の背景（バックグラウンド）確認に重点を置きます。顧客が本当に必要としているものを掴む為、背景の確認は一番重要だからです。
二度目は、ソフテックが作成したソフトウェアイメージ資料に基づいたプレゼンを実施しました。
普段ならば、この時点でプレゼンを行うことは行いません。
しかしながらこれをあえて行った理由は、顧客とソフテックが考えているソフトウェアに大きな隔たりがあることを感じた為です。
もしこのまま進めば、仕様が確定するまでに膨大な時間を費やし、しかも認識違いもたくさん発生することを予感しました。
早期にビジュアルなソフトイメージが存在し、それを元に具体的に質疑を進めることができればこの問題を解決することができます。
作成した資料は、ソフトで作成する画面のビジュアルイメージと画面遷移についてまとめたものですが、ソフト開発早期の段階で顧客と内容のある検討ができたことは本開発のポイントだったと思っています。
三度目は、画面機能について改善提案、要望のヒアリングやスケジュール調整などを行いました。

本プロジェクトにおいては、顧客と二回目の打ち合わせを実施した際には、すでに具体的はソフトイメージ案を、ソフテックから顧客にプレゼンするようにしました。
これは、早期から顧客との認識合わせをしておくことを自分が重要視していた為です。
また、次の5.でもお伝えしますが、ソフテックでは開発の際に顧客とNotes DBを共有するということをします。
本プロジェクトでもNotes DBを顧客と共有しておりましたが、それにより打ち合わせの効率化や連絡の迅速化ができました。

5.顧客が提示する要求仕様書の検討と確認

本プロジェクトのように顧客が要求仕様書を提示している場合は、顧客の真の要求仕様をその中から正確に読み取る必要があります。

(1) 不明点・曖昧点を少しでも残さないように顧客へ確認

要求仕様書の検討を進めていくと不明点や曖昧な点がたくさん出てきます。
これらは、すべて顧客に確認するようにします。
不明点を解消する為には質問は多ければ多いほどいいと自分は考えていますが、顧客の立場では質問を迷惑がることもあります。
質問するにも、顧客に答えてもらいやすいように次のような工夫をします。

図、表などを駆使し、ビジュアルに質問の要点が分かるようにする。
1問1答を基本とする。
正確な日本語で、的確な表現にする。

確認手段には電話・メールなどがありますが、ソフテックでユニークなのはNotes DBを顧客と共有し、質疑を行うことがある点です。
本プロジェクトでは、Notes DBを顧客と共有する方法を採りました。

この方法は、電話やメールに比べて次のような利点を持ちます。

質問ができた場合にすぐに質問ができる。
顧客担当者に急な割り込みを強いらない。
図、絵、ファイルなどの貼り付けを容易にし、ビジュアルに相手に伝えることができる。
記録が残る。
多人数で情報共有ができる。
一覧性がある。やり取りの経過を容易に確認できる。

(2) 反復して読み取る

単純な方法ですが何度でも要求仕様書を読みます。
質問事項に対して顧客より回答があり、新しい情報が入ってきたりした場合に読み返すといろいろな事柄がつながって、全体が見えてくる場合があります。

(3) 一行、一行の重みを考えながら読む

非常に複雑な仕様内容を簡潔にまとめた文章が、要求仕様書の中に紛れていることがあります。
業界のプロフェッショナルである顧客は当然そのレベルで要求仕様を書きますので、説明内容が複雑である場合や、顧客にとって常識である事項は説明を省略しています。
省略箇所がどこか気づくことが非常に重要です。
もしそれを見逃したまま作業が進み、後工程になってから問題が起きた場合は、たった一言の何気ない記載事項が膨大な後戻りや、追加を発生することがあり、自分も過去に経験しています。

（4）要求仕様をよりよくできないか考えながら読む

顧客の要望する方法の他によりよい提案ができないか可能性を探りながら読み返します。
顧客の要求する仕様には何らかの理由や背景があります。
これを意識して読むことで、真の要求が見えることがあります。

6.顧客との打ち合わせについて

顧客の要求仕様を正確に読み取るという作業は、ソフトウェアを作る作業のうちのほんの一部分でしかありません。
しかし、この工程であっても失敗すればプロジェクト全体の命運を左右します。
とても重要な作業工程であることが分かって頂けたかと思います。
いずれ機会がありましたら、別工程についての話も御紹介したいと思います。

(T．S．)