今日は71年目の敗戦記念日です。多くの戦没者と全ての戦争の犠牲になられた方に謹んで哀悼の意を捧げます。
最近の隣国の動きを見ているとちょっと落ち着かない気持ちになってしまいますが、71年前の今日のことを思い浮かべて、なんとか争いを無くして、お互いを信頼できるような国際関係が築けないかと思います。
また今日は、お盆ということもありお休みの方も多いのではないでしょうか。休日のひと時にキットＰＭの拙いブログをお楽しみいただければ、感謝感謝です。
前回は、住居の建築プロジェクトで、クライアントの望みを実現した未来の姿を正しく想像してもらえるためにやっていることを考えました。
大きな投資をするわけですから、クライアントも慎重になる一方その分期待も大きくなります。期待を形にすることこそがわれわれのサービスの本質ということになります。
プロジェクトの最初の段階で、クライアントの期待つまり要求を聞き出し、それを基に未来の姿を描くことになります。
ＩＴプロジェクトの場合だと、このアウトプットを ”要件定義書” と呼びます。要件定義の手法や要件定義書の内容については、とても気になりますが後で考えることにして、まずはどうやって未来の姿をクライアントに理解、承知してもらうのかを考えていきましょう。
なぜ理解、承知してもらう努力をするのかというと、クライアントの期待とプロジェクト結果のギャップを極力小さくすることが必要だからです。ギャップが大きいとトラブルに直結することになります。
ところが、プロジェクトの正式なアウトプットである ”要件定義書” は建築の世界だと平面図や立面図などの意匠設計書です。
図面になじみのないクライアントは、それを見て説明されても、上手くイメージを持つことは難しいものです。
ＩＴプロジェクトの場合も同様で、要件定義書を持って説明するだけでは、クライアントがそこから未来の姿を想像することは簡単ではありません。
要件定義活動には２つの側面があります。
一つは、クライアントの要求を正確に引き出し、論理的にまとめるという側面。これは、次の工程である設計フェーズのインプットとなるものです。そのため、正確さと網羅性がとても重要になります。
もう一つは、要件定義の内容を正確にクライアントに伝えるという面です。これは先ほども言ったように、施主であるクライアントに開発しようとするシステムの全貌を理解してもらうためです。
通常は前者に比重を置いて作業することが多いのですが、キットＰＭとしては、両方同じ程度の重要性を持っていると考えています。何事もスポンサーに伝わらなければ、意味はないのです。
ただ言うは易しということで、これをクリアするために以前から様々な工夫がされてきました。
次回は先人はどのようなやり方を考え出してきたかを考えて行くことにします。