役に立たないシステム・動かないコンピュータが生まれる理由は何か？ 中小企業の情報システムの開発・導入を応援する「ＩＴ１１９番」 ＲＦＰ 【提案依頼書】 制作
|
 HOME> 使えるシステムを開発するための４つの考え方 > 依頼者の「明示されない」要求を読む |
 依頼者の「明示されない」要求を読む
 |
依頼者の「明示されない」要求を読む
依頼者との打ち合わせで、発現されることは要求の断片です。
それを、そのまま議事録として作成し、要求定義としても．．
使えないものとなります。
発せられた言葉から「真意・要求」を読み取る必要があります。
これを「与件」と考えています。
この与件は、バラバラな情報パーツでしかありません。
この材料をもとに、予見（プレビュー）します。
すると．．不備や整合不良が見えてきます。
その不備・整合不良を解消するために２つの視点で
設計（デザイン）を考えます。
１．構成要素（アイテム）
２．仕組み・構造（プロセス）
そして、要件の補強をします。
すると、前提条件が変わり制約条件を考えます。
この無理返しで、依頼者の要求をまとめ上げます。
これで「要件定義」を作りこみます。
 与件を整理し、予見と設計で要求を完成させる！ |
|
|
 「言ってるコト」と「望んでいるコト」が違う
ＳＥとして、だんだん経験を積んでくると、
導入後、どの部分に変更を要求されるか予測できるようになります。
その場合は、ここは、こう言っているけど違うって言うだろうなと．．．
システムを設計していて、どちらにも対処できるように準備して進めます。
そして、いざ運用となって『違う』と言われたら．．．
言葉では、『大変です、大きな変更です』と言いますが、
（事実何の対処もしていなければ大きな変更になります）
実は、すぐに切り替えられるというような設計で開発をしていた経験があります。
仕事の流れを「仕事の仕組み」と考えると、事前に想定できるようになります。
そのＳＥ経験から学んだことは
 顧客は 「言ってるコト」と「望んでいるコト」が違う ．．ということです
|
