PDCAサイクルも起承転結もフレームワークの1つなのに信奉しすぎ感が漂う

万能でないからこそフレームワークなのだが．．．
何か文章を書くのに「起承転結」の特に「転」って何だろう．．．
「PDCAサイクルを回す」と呪文のように唱えても．．．
という私はまったくの素人で専門家ではない。ただの主観。

PDCAサイクルで難解なのは「A」で、さらに「A」から「P」へのつながり。

「PDCAサイクルを回す」＝「計画を立てて、それを実行して、振り返って、次に活かす」のような説明だが、これでは「A」がないし、「A」から「P」のつながりもわからない。

たぶん、こう説明する人は、作業工程を頭に思い浮かべているのかな？作業をするのに、計画して実行するだけではなく、ちゃんとチェックしないとダメだ、と言いたいのかな?と思ってしまう。

PDCAサイクルは工程管理ではなく、改善のスパイラルだということを忘れると「A」が抜け落ちてしまう。あと、「C」が「D」の生産物に対するチェック（レビューとか）と思っていたり。

わかりやすくなるかも、と思ってPDCAの日本語訳を考えてみた。

PDCA	一般訳	自己流訳
Plan	計画	特化	具体化のアプローチ
Do	実行	実装
Check(Study)	評価(学習)	分解(解析)	抽象化のアプローチ
Action	活動	汎化

何かを作るときには、目的を満たすための「特化」したものを考え、それを「実装」する。よりよくするには、実装したものをいったん「分解」し、共通項を抽出して「汎化」する。汎化されたものは技術/部品/規約/知見などであり、次の特化したものを作るときに適用することで、よりよいものができるようになる。

一度書いたプログラムをリファクタリングして汎用性を高めたり、同じ轍を踏まない工夫をして、次に作るときに役立てることが「A」から「P」の流れとなる。

改善のスパイラルも同じで、計画／実行のプロセスを例えばKPT(Keep/Problem/Try)に分解して、よいものをよりよく汎用的にして、次の計画に取り入れる。

※個人的には問題のあるものを無理によくする改善策にとらわれず、障壁を人為的淘汰によって排除するだけにした方が実りあると思う。