私、キットＰＭはこの度の地震と津波に被災された方々に心からのお見舞いを申し上げます。また、亡くなられた多くの方々のご冥福をお祈りいたします。
少しでも被災された皆様のお役に立ちたい、それにはどうしたらよいかキットＰＭなりに考えましたが、やはり本職のノウハウのご提供が一番だと思い立ちました。被災された中小企業の皆様のために、緊急のプロジェクトの立上げやプロジェクトのリカバリを行う場合の計画立案のために、キットＰＭの方ハウを無償でご提供いたします。
ご提供可能なサービスの内容についてはこちらをご覧ください。
◆－－－－－－－－－－－－－－－－－－－－－◆
■今日、明日（4/5）は高松へ出張です。只今神戸三ノ宮から高速バスで移動中です。車窓から見る風景もすっかり春めいて来ました。眠くなるのを堪えてこのブログを書いています。
■前回、「火消し」の手順その１「現状把握」の難しさについて考えました。２週間をめどにこの作業を終わらせることが目標なんですが、そう簡単に本当の現状を把握できないとも言いました。
少し考えれば分かる話ですが、プロジェクトが障害にぶつかったとき、障害を乗り越えるために行動している期間が長くなれば長いほど、プロジェクト目的実現のための思考より、一体誰のせいでこうなったかと責任追及、裏を返すと責任逃れのための思考と行動に走りがちとなります。
そんな状況でプロジェクト外部（たとえ社内のＰＭであっても）から来た人に、易々と実情を教えるはずはありません。
しかし、幾ら表面的な事象やありきたりな原因を提示されるということは、あたかも燃え盛っている場所ではない所に一生懸命水をかけるように誘導されるようなものです。そりゃ、かけないよりましでしょうけど。
■したがって、どうやって真の原因に辿りつくのか、が「火消し」の次の山場となります。重要なのはプロジェクトメンバと信頼関係をいかに素早く築くかということです。でもその前に「真の原因」とは何かについて考えておきましょう。
■わかり易い説明としては、実例をまんま上げればいいんですが、それはちょっと流石にはばかれるので、多少のフェイクを交えつつイメージが浮かぶような話を作ってご説明します。
あるITシステム製品の企画・商品化プロジェクトのお話です。プロジェクト主幹部署は商品開発部です。そのプロジェクトでは基本となる機能については市販のアプリケーションソフトウェアを利用して、そこに自社技術による付加価値を付けて商品化しようと目論んでいました。
また、関係部署との調整も行い全社プロジェクトとして万全の体制で望んだつもりでした。
当然、事前にそのソフトウェアメーカーとも話をして機能の検証も行い、プロジェクトの総意として採用にOKが出ていました。しかも、そのメーカーの開発計画では次期バージョンで、重要ではないが必要と考えていたアドオン予定の機能が実装されるという情報もありました。こんないい話はありません。
さぁ、プロジェクトはキックオフを行いスタートしました。後は計画に従い、付加価値を付けるためのアドオン機能の仕様確定、設計と作業を進めれば良いわけです。
順調にスタートしたプロジェクトでしたが、その５ヶ月後キットＰＭがプロジェクトに呼ばれました。
「ＰＭが体調を崩して入院したが代わりのＰＭがアサインできないので、手伝って欲しい」ということです。もちろん、お仕事ですから喜んで引き受けました。このときキットＰＭはプロジェクトの危機はＰＭの不在であると思って、その穴埋めをすることをイメージしていたのです。
着任してまずやったのは当然現状把握です。
そうすると、まだ仕様が決まらない、直接関係のない仕事をなぜかやっている、選定したパッケージソフトの時期バーションの開発が遅れていて、アドオン開発に影響が出ている、仕事の優先順位が明確でないなど、問題が山積みだったのです。そうです、そのために前任者のＰＭが病気になってしまったのですね。
さぁ、それから状況を整理し真の問題点を見つけるべく走り出すことになりました。先ほど上げたまずい状況はあくまで表面に現れている現象です。いったいなぜこのようなことが起こっているのか本当の原因を見つけないと対策の立てようがありません。
火元を見つけて、そこに消化活動を集中する必要があります。時間にもお金にも余裕がありません。
まずやったのは、プロジェクトが危機的な状況にあるということをプロジェクトメンバがちゃんと認識できるように、メンバと意見交換を行うことでした。このとき、状況を悪くした犯人を探すのではなく、プロジェクトを立て直すためにどうするかを考えるということを、徹底して説明しました。
次に、「思考プロセス」を実施したわけです。
■さて、まだまだ続きそうな本シリーズですが、次回は「思考プロセス」がどういうものかご説明することにしましょう。乞うご期待。