第33回 朝令暮改は悪いこと？
トライアンツコンサルティング
野村隆
2008/1/23
| 将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 |
この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けしています。
今回の内容は、リーダーシップトライアングルのManagementに関係します。Managementについては、連載第9回「ソフトウェアは目に見えない」を参照いただければと思います。
 |
| 図1 リーダーシップトライアングル。今回は「Management」に関連する内容を紹介 |
■PDCAサイクル全体が短いことの効果は？
前回「欲しいのは、PDCAサイクルが短い人」で、PDCAサイクルをちゃんと回すこと、PDCAサイクルが短いことが、仕事をしていくうえでは重要だと解説しました。
しかし前回は、P（Plan）が短ければスピード感を持ってD（Do）に進むことができるという効果については解説しましたが、PDCAサイクル全体が短くなることによる効果については言及しませんでした。そこで今回は補足として、PDCAサイクル全体が短くなることの効果について解説したいと思います。
■早めの軌道修正
PDCAサイクルが短いことの効果とは何でしょうか。それは自分の作業が間違った方向に進んでいるとき、軌道修正が早く利くということです。
具体的に見てみましょう。PDCAサイクルが1日の人と、1カ月の人とを比較してみると分かりやすいでしょう。作業が間違った方向に進んでいた場合、前者は1日で軌道修正できますが、後者は1カ月後にならないと軌道修正できません。
つまりPDCAサイクルが短ければ、C（Check）してA（Action）を取ることが素早くできるというメリットがあるのです。
PDCAサイクルを短くするという行為をもう少し具体的にいうと、ちょっと考えて（P）、まずは行動し（D）、間違いがあるかどうか確認し（C）、間違いがあれば即座に是正措置を取る（A）ということになるでしょう。
このような行動様式を取ることによるもう1つのメリットは、「少しずつ間違いを是正しながら進むことができるので、大きくは踏み外さない」ということです。不確実性の高いシステム開発のプロジェクトでは、このような考え方が適しているのではと思います。
■コロコロ変わる方向性
ここまでの説明で、気になることがありませんか？ PDCAサイクルが短いとすぐに方向転換をする可能性があるので、結果としてコロコロ方向性が変わる「朝令暮改」となってしまうのではと思うのではないでしょうか。
朝に計画（P）したことが昼の行動（D）を確認（C）した結果間違いと判明し、夕方に是正措置（A）を取れば、ちょうど朝礼暮改となってしまいます。
PDCAサイクルを短くすることが、不確実性をはらむシステム開発のプロジェクトには適していると先ほど説明しました。一方で私の経験からいえば、特に大規模かつ長期のシステム開発プロジェクトで方向性がコロコロ変わってしまうと、運営が困難になることがあります。大規模ゆえにメンバーが多く、多様な価値観を持つ人材が集まるためです。
では、朝礼暮改を避けるために、PDCAサイクルは長めにした方がいいのでしょうか。私の答えはNoです。やはり、PDCAサイクルは短い方がいいのです。
PDCAサイクルを短くし、かつ、朝礼暮改のそしりを受けないようにするにはどうしたらいいのでしょうか。
 |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
