仕事の正しいススメ方
昨今、色々サイトを見て回っていると、
「ＰＤＣＡはもう古い！」
なんて記事も見かけますが、本当にそうでしょうか。
すくなくとも、『会社』の経営は原則としてＰＤＣＡで回っています。これは法律によるところが大きいのですが、企業経営は原則１年周期で
予算計画（事業計画）し、
実行し、
計画との差異を評価して、
最後に問題点を是正する
というサイクルで動いています。これを「年度」と言う単位で１サイクルとしているわけです。また、計画差異が大きいまま進めても、計画そのものが形骸化してしまい投資家への情報としては不適切になるため、上場企業は四半期に１度、ＩＲ情報として途中経過の決算を公開していますよね。あわせて通期の計画見直しなどもしているはずです。
たしか、確か証券取引所からの指示だったかな？金融商品取引法とかのからみかもしれません。詳しくは知りません。
これらは、すべてＰＤＣＡで動いています。企業経営がＰＤＣＡとなっていると、少なくともその所属にある部署・部門も当たり前ですけど、足並みをそろえる関係上、ＰＤＣＡになります。企業の立てた年間計画に沿う形で業績や事業を運営しなければならないからです。もちろん、部署がそうである以上、そこで働く従業員にも何らかの形でＰＤＣＡによる運用と結果を求めることになるでしょう。
ですので、「ＰＤＣＡ」が古くからあるフレームワークなのは確かですが、それが現代と合わないか？というとそれは違います。当然ながら、他の方法が向いているケースもあると思いますが、だからと言ってＰＤＣＡが淘汰されるようなものでもありません。
そして、少なくとも『プロジェクト』の継続運用にあたっては、ＰＤＣＡの方が相性がいいと言えるでしょう。
ＰＤＣＡが導入されない理由
ＰＤＣＡのほか、ＰＤＣあるいはＯＯＤＡなど、様々なプロセス改善手法が提起されてはいますが、そもそもＰＤＣＡすらまともに利活用できないようでは、他の方法も大して活用することは難しいのではないでしょうか。
ＯＯＤＡなんかは、ここ数年で聞くようになりましたが、どちらかと言うと「デキる人向け」と言うか、「エリート向け」と言うか、過去の経験を活かせず、これから新規に何かを始めようと言う人に向けたフレームワークな気がします（あと、チーム活動には不向きな気がします）。
また、日本人はこのＰＤＣＡをベースとしたプロセスアプローチを非常に苦手とする人種と言われていますが、なぜ苦手なのでしょう？
実際に観察してみると、厳密にはＰＤＣＡサイクルを実施すること自体が苦手なのではなく、多くの企業において
・最初から導入しようとしない
・ライフサイクルと言う考え方がない
風土や文化の方が色濃いようにも見えます。その証拠に、
・「Check」を実施する企業風土自体が存在しない。
・データを蓄積しないから、「Plan」時に過去実績を活かしきれない。
という企業は数え切れないほど見てきました。今在籍している会社でもそうです。いつも、過去の実績を人の記憶に頼っていて、新しく台頭してくるリーダーやマネージャーに引き継がれないから、いつまで経っても、組織のレベルが上がっていかないのです。
これは、ＰＤＣＡの本質を理解していないからと言う側面もあるのでしょう。事実、ＰＤＣＡに関する書籍群は非常に数多く出版されていますが、その中でＰＤＣＡが本当の意味での『目的』が記載されていないか、記載内容がごく一部であるものが殆どです。
これでは理解できるはずもありません。
極意は「反復改善」
また、理解できない以上、当然のことながら"イテレーション(反復)"も理想通りに進めることはできません。なぜなら、イテレーションの根底にはＰＤＣＡの思想があるからです。
では、ＰＤＣＡの本質的な『目的』はどこにあるのか？と言うと、第一に浮かんでくるのは
変化/改善の継続的な吸収
でしょう。
まず最初に理想（ゴール、目標）をイメージし、理想通りの結果にたどり着くための行動計画（アクションプラン）を実施する。計画通りに実行しながら、微調整を行い、最後に計画と現実の乖離した部分を分析し、乖離したその差異から、変化すべき部分を洗い出し、受け入れ、取り込み、次回以降の計画精度向上／成功率向上／生産性向上に役立てる。
これがＰＤＣＡの最も重要な『目的』であることは疑いようもありません。
しかし、これがただの旅行や夏休みの計画といった一過性のものであればよかったのですが、常に類似の行動、活動を反復する通常の業務やシステム開発では、さらに深掘りして目的を見定めなければなりません。
だからこそ、イテレーションという考え方が生まれたのです。
タイムボックスを小さくする
タイムボックスとは、"時間をある程度の塊にまとめたもの"です。
１年の開発プロジェクトを、まとめて１年分計画するとあまりに長期過ぎてどうしても精度が落ちます。ですから、工程単位や成果物単位といった小さい単位で、さらに詳細な計画に落とし込むのです。
小さくすればするほど、計画精度は向上します。アジャイル開発手法のほとんどが、小さい単位の開発＋イテレーションで進むことを前提とするのはそのためです。
また、小さな単位にし、時間的制約を設けることで、
・短期間となるため集中力を高めやすい
・リズムを生み出しやすい
などの効果も期待できます。
具体的には…そうですね、たとえば子供の頃（大人になってからでもいいですけど）、帰宅途中にトイレにいきたくなったことはありませんか？まだ学校を出たばかり、あるいは駅から歩き始めたばかり。まだ家までは半分以上の距離があります。住宅街の中なので、近くにコンビニもみあたりません。
そんなとき、「あの電信柱まで」とか「あの角を曲がるまで」と言ってガマンしたことってありませんか？
あえて「家まで」ではなく、短距離、短時間に区切って集中し、それを複数回繰り返すことで、集中を持続させる方法です。
意外と、子供の頃からやってたりするものなんです。
（たしか昔、ちびまる子ちゃんの話でもそんな話があったような？）
ＰＤＣＡは、その１サイクルだけで１つのタイムボックスが作れます。そのため、ＰＤＣＡを念頭に置いた場合、どれだけタイムボックスを小さく区切ってサイクルさせることができるかが、成功のカギを握ることになります。
計画しない、計画書（スケジュール）を作らないと言うのは、ＰＤＣＡそのものを否定します。
そのため、タイムボックスが明確にならず、「いつまでに」「なにを」「どのような状態に」しなければならないのかが誰にもわからなくなってしまうため、計画破綻を起こしてしまう確率が大幅に上昇します。
小さな単位で成果物を作成する
目に見えるものを用いて、確認が行えるというメリットがあります。
たとえば、仕事上において１つのドキュメントを作るとしても、全部作ってから確認するのではなく、１章、１ページが作成できた時点で確認する計画としてしまえば、最小単位のＰＤＣＡで、不良や指摘部分が明確になり、変化を受け入れ、残りの作業精度が向上することになります。
ドキュメント作成なんかはわかりやすいですね。
特に、同じような様式を数ページ、数十ページ作成しなければならないのだとすれば、最初の１ページをモデルケースとすることで、残りのページの品質の大半が確認できてしまいます。「設計書」や「試験仕様書」と言ったモノであれば、効果は絶大でしょう。
目に見えない（何もできあっていない）状態で、打合せ等を開いて意識確認をしたところで、口頭で話した内容が互いにとってすべて共通のイメージとなっている可能性は低く、ＰＤＣＡによって可視化した成果物を利用した確認の方が、より高い品質となるのは自明の理です。
リスクの高いものほど優先的に
リスクが高いということは、色々と手間がかかるということです。しかも、手間がかかるような事態に陥る確率が高いし、陥った時の影響がとても大きいということです。
ですから、『リスクの高いもの＝緊急度の高いもの』と位置づけ、優先的に処理するようにすると良いでしょう。後回しにしておくと、残りの時間で対応できなくなってしまっている…と言うことはよくあることです。
こうして対策しておくことによって、残った作業のリスクを包括的に低減させることが可能になります。
たとえば、チーム作業であれば、最初に確認した１人目の時点でリスクが明らかになれば、チーム全体でリスクが顕在化する前に、その解決方法を共有することで、あらかじめ未然に摘み取ることも可能になるわけです。
ＰＤＣＡサイクルによる計画的な運営は、元来、業務の現場にとても馴染みやすいモデルのはずです。しかし、個々人のレベルになると、どうしても実施することが億劫になってしまうために、このサイクルの組織的な浸透を妨げてしまうのです（特に計画を嫌がる）。
正しく理解し、「やってもやらなくてもいいもの」ではなく、「やることが当たり前のもの」になるよう組織的に改善すると、このフレームワークは多くの業務で役に立ってくれるはずです（本質さえ誤っていなければ、具体的なやり方はどのような方法でもいいのですが）。
ちなみに、ＰＤＣＡを難しいと感じるとしたら、それはひょっとすると完全に新規の事業かなにかで、周囲に頼ることができる人もなく、類似した体験もしたことがなく、100%未知の取組みをしているのかもしれません。
そのような場合、ＰＤＣＡサイクルは、回し始めた当初は計画精度が低く、行き当たりばったりとなっていることも多いと思います。「実績」を積みながら、幾度か改善を加えていかなくては、「計画」がまともに機能しないかもしれません。それまでは、試行錯誤の繰り返しとなるでしょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。