要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

PDCAサイクルではなく、PDCサイクルを回そう

職場ではPDCAを回しましょうという言葉が良く出てくるのだが、個人的には、Aという部分に引っかかっている。Aというのは、Act(改善)の頭文字なのだが、ActしたらまたCheck(評価)が必要なんじゃないのか?と思ったりする。今回は、PDCAについて整理をする。

PDCAとは?

PDCAサイクルという名称は、サイクルを構成する次の4段階の頭文字をつなげたものである[3]。

Plan(計画)  :従来の実績や将来の予測などをもとにして業務計画を作成する。
Do(実行)  :計画に沿って業務を行う。
Check(評価):業務の実施が計画に沿っているかどうかを評価する。
Act(改善)    :実施が計画に沿っていない部分を調べて改善をする。
この4段階を順次行って1周したら、最後のActを次のPDCAサイクルにつなげ、螺旋を描くように1周ごとに各段階のレベルを向上(スパイラルアップ、spiral up)させて、継続的に業務を改善する。

PDCAサイクル - Wikipedia

PDCAの説明についてはWikipediaを引用した。PDCAというのは、計画(Plan)、実行(Do)、評価(Check)、改善(Act)の一連の活動のことを指す。それぞれの英単語の頭文字をとって、PDCAと呼んでいる。製品の品質を作りこむために、このような技法が使われている。この手の類の用語はいろいろあり、OODAというようなものもある。色々な用語が出てきても現場は混乱するだけなので、日本では長らくPDCAが使われている。

PDCAの問題点:Actの部分の定義があいまい

個人的には、PDCまでの活動は納得できている。計画し、実行し、評価をするのは、当たり前のことだ。腑に落ちないのが改善の部分だ。改善というのに終わりはあるのだろうか。改善をするためにも、計画し、実行し、評価をするのではないだろうか。であれば、PDCPDCPDC・・・とすべきだ。

結局、Actという活動のスコープがあいまいなのだ。現場では、改善をするためにPDCAを回しましょうというのだが、「計画して、実行して、評価して、改善する」となると、改善をするために改善をしましょうということで、何を言っているのかわからない状態になる。改善もDoなのではなかろうか。仮に「改善」でPDCAの活動が終了であるとするならば、それはパッチあてのような気がする。本来であれば、PDCまで実施した後に、また、Pからやり直し(真因を分析し、対策を検討する)が必要ではないかと考える。

継続的改善を目指すならば、PDCAのAは不要

そういうわけで、私なりに腑に落ちるPDCAサイクルを下記図に示した。Checkまで終わったら、またPからやり直そうということだ。大事なのは、目標を決めて、進んで、現在位置を確認する、その行為を繰り返すということだ。Aが何なのかを考え出すと、次のPに進めなくなってしまうので、いったんAはなくしてしまうこととする。別にAをなくしてPDCのサイクルとしても、改善活動はできるはずだ。

f:id:req-definer:20220130084232j:plain

PDCサイクル

結論:PDCAサイクルではなく、PDCサイクルを回そう