要件定義の局面ではユーザーとの打合せが頻繁に行われ、ドラフト段階の要件定義書にユーザーからダメ出しをされることが多々あります。
ダメ出しの要因は、ヒアリング不足であったり、ユーザー自身の認識不足であったりといろいろありますが、多くはSTPD(See-Think-Plan-Do)サイクルを実施することにより解決できます。
要件定義においてSTPDサイクルを当てはめると下記のようになります。
【See】
何が(What)起きているか、起きるかを洗い出します。
いわゆるAs-Is分析の前半です。
注意しなければならないのは、思い込みを排してありのままの現実だけを見ることです。
人はどうしても一方向から見がちですので、思い込みを排するためにも視点や立場を変えて見ることが必要です。
また、何が困っているのか、どのような問題点があるのを併せて洗い出します。
【Think】
Seeフェーズで明らかになった現状や問題点について、なぜ(Why)そうなっているのかを分析します。
As-Is分析の後半になります。
【Plan】
SeeフェーズとThinkフェーズの結果から、どうすれば良いのかを考えます。
To-Be分析に該当します。
【Do】
Planの結果を要件定義書に反映します。
この段階でTo-BeとAs-Isのギャップを埋めるのですが、その結果Plan(To-Be)通りにいかないことがでてきます。
それについては、何が(What)起きるかを分析するSeeフェーズが次のサイクルですので、迷うことなくSeeフェーズへ移行して、Plan(To-Be)通りにいかないことによって何が(What)起きるかを分析するといった回し方ができます。
このようにSTPDサイクルを回すことにより、ヒアリング不足だとかユーザー自身の認識不足だった点が整理されながら顕在化して、より品質の良い要件定義書が出来上がっていきます。
PDCA(Plan-Do-Check-Action)サイクルでは、最初のPlanフェーズでAs-IsからTo-Beまでを行うことになり、PlanフェーズからDoフェーズに移るまでの時間がかかり過ぎます。
場合によっては、Planフェーズだけで要件定義工数のほとんどを使っていまい、サイクルでまわすどころかDoフェーズ以降のCheck、Actionフェーズの時間すらなくなってしまうことがあります。
要件定義書フェーズで品質を担保するためにはサイクルを回さなければならないと考えれば、PDCAサイクルよりもSTPDサイクルの方が適していることがお分かりいただけると思います。
