2008_05_19－ユーザー側から見た要件説明。

２００８年５月１９日発行

分割ラインです

　★　要件定義編　★

　　
　　ユーザー側から見た要件説明
　　
　　
　　要件定義の説明は、非常に疲れます。
　　以前、私も　　よくユーザーから言われました。
　　　　「何回言わせるの？この前説明したでしょ」
　　　　「推測すればわかる話じゃないの？」
　　　　「ちょっとは、自分で考えて。」
　　
　　ユーザーも忙しいのです。
　　ですから、自分なりに情報をかき集めて、調べたりして
　　自分なりに調べたところまで説明してから、聞くようにしてしました。
　　まぁ、今思えば当たり前なのですが。。。

　　
　　ユーザーも腹の中で思っているのです。
　　　　　「こいつ、本当にわかっているのか？」
　　
　　
　　
　　ユーザー側が、開発側の理解度を図る目安として
　　　　・開発側のノートをチラッと見てください。
　　　　　　言った内容が正しく書かれており理解できることです。中には
　　　　　　ノートに走り書きのみをしている人がいます。他人が見て
　　　　　　わからないものは、後から見直してもまず思い出せません。
　　　　・議事録は翌日・翌々日までに提出してもらいましょう。
　　　　　　なぜなら、記憶は時間とともに忘れていくからです。
　　　　　　遅かったら催促してみましょう。
　　　　・中間報告を設けて、説明内容がまとまっているか確認しましょう。
　　　　　　思い違いやモレは、お互い早く見つけることで、
　　　　　　損失は少なくなります。
　　　　・レビューは間違った内容よりも傾向を掴みましょう。
　　　　　　間違いは、特定の人や機能や期間に偏っていることが多いのです。
　　　　・日本語文章だけのまとめ方は、ＮＧです。
　　　　　　マトリックス表やスケッチ図やグラフなど、ビジュアルに
　　　　　　わかりやすくまとまっているかです。
　　　　　　日本語のみでは、捕らえる視点で理解の仕方が変わりやすい。
　　　　　　チェックにも時間がかかります。
　　　　・わかりやすいまとめ方は、開発側の理解度になります。
　　　　　　本当に理解していれば、自分なりのアレンジも可能なはずです。
　　　　　　わかっていない、ちゃんと考えていない　は将来に不安を
　　　　　　抱えます。ひどい場合は交替も考えましょう。
　　
　　
　　
　　ただ、
　　ユーザー側も、伝えモレは必ずある事を常に思ってください。
　　　　　　思っているだけで、かなりの確率で思い出します。
　　　　　　後から言った言わないでもめるのは、止めたいものです。
　　
　　
　　
　　知らない人に、説明するのって大変疲れます。
　　　　どのユーザーでも同じ苦言を聞きます。
　　　　　　そこにちょっと知ったかぶりをしている人を見かけると
　　　　　　　　余計に腹が立つのでしょう。
　　　　要件定義から険悪ムードになることは数多く経験してきました。
　　
　　
　　
　　
　　謙虚な姿勢になって聞くことは、
　　　　　開発側の大事な心構えではないでしょうか。
　　
　　開発側の意見はユーザー説明が終わってから、
　　苦労をねぎらいながら発言する気づかいも必要だと、つくづく思います。
　　
　　
　　
　　
　　ユーザー側も開発側の仕事内容について指摘しましょう。
　　　　・説明した内容がうまくまとまっていない。
　　　　　　　表や図などにまとめてほしい場合は、率直に言いましょう。
　　　　　　　思い違いは、後になってお互いに苦労します。
　　　　・業務経験の無い担当者のみの場合、遠慮しないで申し出ましょう。
　　　　　　　業務経験がなく、ユーザー側の思いがうまく伝わっていないと
　　　　　　　感じたら遠慮なく開発側営業・上司に言ってください。
　　　　　　　はやく騒いだ方が、解決も早くなります。
　　
　　
　　
　　今回は、ユーザー側の体制よりも開発側の体制が弱い場合について
　　書きました。
　　ユーザー側の体制が弱い場合が多いのですが、
　　　　ユーザー側も知恵を絞れば、結構楽できます。
　　　　　　それは、わかりやすいドキュメントを書かせることです。
　　
　　開発側がわかりにくいドキュメントを作成してくる事が
　　　　結構多いのです。
　　故にチェックにも時間がかかってしまうのです。
　　　　わかりにくいドキュメントは、書き直しさせるくらいの
　　　　　　度胸がほしいものです。
　　表や絵や図などで、わかりやすく記述させて下さい。
　　チェック時間は、大きく削減することが可能になります。
　　
　　ユーザー側は、未解決事項の解消に重点を置いてください。