中堅IT会社の事業企画、経営企画、マーケ、営業、コンサル・・・雑多な経験とマルチタスクに翻弄される日々の徒然と気概をお届けします。

トラブルを分析し評価するより手を動かせ 例えば デイトレーダーの判断と行動

»

PDCAサイクル。「Plan→Do→Check→Action」これ当然大切なことであって、それを否定するつもりは毛頭ございません、ハイ。

理念があって、戦略があって目標を定めて、戦術に落とし込む。これ当然。そして、実践されたオペレーションは、評価され見直すものであることを僕は否定しない。

けれど実務、すなわちDOのフェーズにおいて、例えば何らかの業務システム開発PJを進めていたとする。顧客の仕様が確定しない、見積に想定したした仕様との規模にGAPが生じている、PJ進捗が思わしくない、コーディングのスキルが未熟である、など様々なシュチュエーションに出くわすわけだけれど、そんな時にしたり顔で「分析と評価」するのは不毛なことだと思うのだ。

先の実務のフェーズで「分析や評価」を行うと、置かれた状況から色んな理由を探すだろう。

  • 複数の部門内での利害対立が生じていて仕様の決定が遅延している
  • 営業フェーズでの見積が甘かった
  • PJ管理手法、進め方に問題がある
  • 自社のサービス・レベルやリソースに不足がある
  • 適正なメンバーがアサインされていない

など。

けれど、そんな理由探しをしても何も物事は進捗しない。実務においてはただ「PJ進捗に遅延を生じている」という事実にのみに向き合うことのみが必要だ。希望する仕様のGAPを予算に合わせた形にするの努力をして、キーマンを見極めて、仕様を早々に確定する。メンバーのサポート体制を構成する、など。

確かに先に挙げたものが、トラブルの理由かもしれない。けれどそれは、飲み屋でトラブルの愚痴言っているのとそう変わらない。トラブルの最中、その時に求められるのはトラブルシューティングという結果だ。理由を解析するのための状況の「分析と評価」は実務に入る前後にすべきことだ。

だから優先されるべきは、トラブルシューティングのための的確な「判断と行動」。「判断と行動」を決定するために必要な情報の「収集とその処理」は必要だが、走り出したプロジェクトであれば「分析と評価」は全て終わった後でよい。

けれど、この分析と評価の多くは正論であることが多い。それゆえに反駁は難しく、分析の無限ループに陥って、何も生産的行為が発生しないことすらある。

「判断と行動」と「分析と評価」の違いは何か。

僕が考えるところ、「判断と行動」は状況や現実を踏まえ、それらを抽象化した思考に基づいて導き出した「実行するための動作」のこと

そして、「分析と評価」はビジネスの方針や戦略と現実との相対的な比較によって積みかねられる「知識あるいは経験」なんだと思う。

話を転じて、例えばあなたが、株などのデイトレーダーだとすると分かり易いのではないか。

そのときに業績が良い企業、或いは市況が上がり基調であるである業界の株を買ったとする。けれど、それでも株価は下がることがある。その時に必要なのは、今現実に「損をしているという事実」を最優先にして、早めに損切りするのか、という判断と行動だ。業績が良いとか、上げ基調なのに、とか考えても株価は上がらない。

その時に必要なのは、迅速な判断と決定なはずだ。

「分析と評価」は取引が終わった後に、「知識、経験」として蓄積して、次の判断の正確性を高めれば良い。

「下手な考え休むに似たり」なのだ。

<了>

正林俊介

 

Comment(0)

コメント

コメントを投稿する