2008_07_17－曖昧さの排除。

２００８年７月１７日発行

分割ラインです

　《　品質管理編　》

　　
　曖昧さの排除。
　　
　　
　　要件定義や設計工程において曖昧さはいろいろな所に隠れています。
　　
　　　　　・文書表現における曖昧表現
　　　　　・システム機能における曖昧
　　　　　　　（わかったつもりだが詳細まで考えられていない）
　　　　　・数字で表現できるところが、日本語表現のみとなっている。
　　　　　・問題という意識がない。
　　　　　・担当者が明確になっていない。
　　　　　・期限がない。
　　　　　・成果物が他人に説明できない。
　　　　　・他人の質問に答えられない。
　　
　　これらは、すべて曖昧さが潜んでいるのでのす。
　　決まっていないものは、
　　　　課題や懸案事項として明確になっていればいいのですが。
　　
　　「気づいていない。」ことが曖昧さなのです。
　　
　　
　　
　　しかし経験上から、いくら課題や懸案事項として明確になっていても、
　　課題や懸案事項が簡略化された内容で、括られてしまっていることは
　　時間の無駄を生むのです。
　　
　　課題や懸案事項でも、もっと深く掘り下げると全く別の課題や懸案事項が
　　でてきます。
　　つまり表面上の課題が解決されても、
　　　　　新たな課題や懸案事項は出てきて、また時間がかかるのです。
　　　　　　　結果として深く掘り下げていないだけ、時間が無駄になるのです。
　　　　時間が有限なのは理解できますが、無策が目立つのも問題です。
　　
　　
　　
　　またユーザー側の重要担当者の出席率を上げることも必要です。
　　重要担当者は、忙しい人が多く出席率が低い傾向にあります。
　　もしくは、検討項目やＱ＆Ａを作成して
　　別途個別打ち合わせ時間を作っていただき、集中して行うなどの対策も
　　必要です。
　　
　　
　　
　　
　　曖昧さの排除で工夫点
　　
　　　(1).原点となるプロジェクト目標から外れていないか。
　　　　　プロジェクト目標は網羅しているか？
　　　(2).完成時点における利用イメージはコンセプトが明確に表れているか？
　　　(3).文書表現において、数値表現になっているか？
　　　　　数値表現できない箇所は、なぜできないか明確か？
　　　(4).日本語のあいまいな単語は含まれていないか？
　　　　　「など」「だいたい」「およそ」「くらい」「たぶん」
　　　　　「すぐに」「少し」「多いめ」「ずっと」
　　　　　直ぐに理解できない長い文章や二重否定文が含まれていないか？
　　　(5).課題や懸案事項は、掘り下げて討議して
　　　　　課題の解決ストーリーを組み立て新たな課題の発掘まで行っているか？
　　　(6).ステークホルダー（役員・システム部上司・運用責任者・
　　　　　　　　　　　　　　　　　利用する事業部担当や上司・エンドユーザー）
　　　　　を交えて、検討やレビューを実施しているか？
　　　(7).表や絵を用いて表現のわかりやすさを工夫しているか？
　　　(8).要件定義書や設計書は標準化して統一フォーマットになっているか？
　　　(9).要件定義は、技術的や論理的裏づけとなる証明が取れているか？
　　　　　または証明するのに何が必要か検討されているか？
　　
　　
　　
　　あいまい表現を排除するにも困難を極めます。
　　　　　しかしここで徹底して排除していれば、
　　　　　　　後工程において手戻りや思い違いによる故障の作りこみを
　　　　　　　　　排除することができます。