• 会員限定
  • 2016/04/27 掲載

できるプロジェクトマネージャーほど「ファクトなしに報告を信じるな」と言う

事例に学ぶプロジェクト立ち上げ7つの勘所(第8回)

  • icon-mail
  • icon-print
  • icon-hatena
  • icon-line
  • icon-close-snsbtns
会員になると、いいね!でマイページに保存できます。
プロジェクト立上げ=システム化計画完了の達成水準を満たすためには、ファクトに基づいたレビューが求められる。ファクトに基づいたレビューが、承認後のプロジェクトを計画通りに遂行できること、計画通りの業務改革を達成しリターンが得られることを確実なものにするからだ。これを、設備メーカーのPMの実践事例・大手流通業のPMの実践事例と併せて紹介する。さらにこの勘所の実行に必要な行動規範・知識として、ファクトがないことに妥協しない行動規範、躊躇せずどこへでもファクト獲得に行動できる行動規範、必要なファクトを特定する仮説構築のための知識・検証方法の知識が必要であることを解説する。
バックナンバー

photo

今回の勘所 ファクトでレビューする

「ファクトを得ずに前に進むな」と言った有能PM

 プロジェクトでは、目論見通りに進まないことがいろいろある。

 例えば、業務改革目標について関係部門が合意しても、その後一部の利用部門推進者が執着心をもって推進しないと、できるはずのことも目論見通りの成果は得られない。また例えば、業務革新策(IL)を達成する上での関係調整課題や技術課題を想定して、それが当たっていても、その解決策が的を射ていない場合、想定した課題の悪影響は現実のものとなり、解決が図れない。

 関係部門を業務改革の目標に向けて本気にさせるには、彼・彼女らが執着心をもつようなファクトを示さなければならない。また解決策が妥当であることをファクトで実証していなければ危なくてそのような解決策に運命を委ねる訳にはいかない。

 勘所の4勘所の5で紹介した設備メーカーの開発設計業務革新プロジェクトでは、プロジェクトの利用部門メンバー数名が社外セミナーに参加し、先行他社事例を聞いてきた。その利用部門メンバーたちは、その事例の内容に感銘し、セミナーの帰路では「当社でも品質機能マップを導入しよう」と話し合い、帰社後には、張り切って業務設計にそれを反映するつもりだとセミナー報告を行った。

 その後、利用部門メンバーたちは業務設計に取り組み、熱心に議論を繰り返していたが、1週間が経過しても利用部門メンバーの中で確たる方向性は定まらず、議論を繰り返すほど各自の思いの違いがあることが判ってきた。そこでPMはこの状況を見かねて、利用部門メンバーたちの輪の中に入り、改めてセミナー内容から確認を始めた。

 PMが確認したところ、確かに事例企業の成果は素晴らしいものであった。この事例企業は、“品質機能マップ”と呼ぶ管理帳票を軸とした検討方法で設計開発を推進していた。品質+機能+マップと、一般名詞を組合せた言葉であるが、事例企業では、関連する設計者が一貫して共有する管理帳票にその名を与えて、それを大事にし、成果の上がる活動につなげていた。ここまでは事実である。

 ところが参加した利用部門メンバーが考えた業務設計の内容とセミナー内容がかみ合わないと感じたので、PMは掘り下げて聞いてみた。するとセミナーでは詳細な情報を得ることができなかったので、“品質機能マップ”というキーワードを基に、後は想像を膨らませて業務設計しようとしていた。しかしその膨らませ方が各自違い、方向性が定まらなかったのだ。

 PMは、利用部門メンバーたちが想像を膨らませただけの業務設計に、業務改革の行く末を委ねる訳にはいかないと判断し、ファクトを獲得して考え直させることを決めた。具体的には、事例企業に対して直接の訪問を申込み、教えを乞うのである。利用部門メンバーが参加したセミナーは、幸い小規模だったので、事例企業の講師と名刺交換できていた。そこでそれを頼りに訪問を申込み、相手である事例企業の技術担当役員から快諾を得ることができた。

 ちなみに、ユーザー企業同士で、礼を尽くしてギブアンドテイクのスタンスで、相手の取り組み事例の紹介を依頼した場合、断られることはほとんどない。同じ業界の競争合相手に対してであっても、激烈な競争領域でもない限り、好意的に情報交換できる例は多くある。頼まれた側が好意的に応じるのは、他社がどのような取り組みをしているか知ることができる価値、問われた自社の取り組みを見つめ直す機会が得られる価値、いつか自社の新たな取り組みで聞きに行くことができる可能性などがあるからだ。このように、ちゃんと頼めば受け入れられる可能性が高いのに、他社に対して教えを乞うことをためらうことは非常に多い。このプロジェクトの利用部門メンバーたちも、そもそも「訪ねていってもっと知りたいことを直接聞く」という発想からなかった。しかしPMは、教えてもらうことの重要さを知っていたので調査をアレンジしたのだ。

 PMは、訪問の準備として、調査の仮説を構築した。利用部門メンバーをファシリテートし、セミナー資料及びメンバーがセミナーで聞いてきた情報から、想定できる限りの業務改革策(IL)を想定し、そのILを論理的に展開して業務の目指す姿を描き、確認ポイントを明確にさせたのだ。調査仮説シートの例を図1に示す。

図1■先行企業の業務改革の調査仮説シート例
FW 仮説確認事項
IL 製品の設計構想段階から、品質・機能・コストについて目標設定し、その目標を開発レベルの構成に展開し,構成ごとに目標達成のための基本の考え方の仮説を立て,レビューで知恵を集め、以降の工程で一貫フォローすることで…
仮説は正しいか?

他にないか?
組織技術の横串組織を設置している。
役割は、①分野を超えたコスト低減策・品質向上策の横展開、②DR(デザインレビュー)の主催・進行、③目標の番人、…
体制は,設計技術者の**%
仮説は正しいか?
他の役割はないか?
仕組み立ち上げ時は?
制度構成ごと・DRごとの目標を厳守させる…
厳格なDR運営
仮ほかにDRごとの目標達成の判定基準はないか?
制度が崩れない仕掛けは何か?
人財 想定以外の特別な教育や育成策は何か?

 PMが、このように周到な準備をさせたことで、訪問調査は濃密なものとなった。いくつかの業務改革策(IL)は仮説どおりであった。一つのILは仮説の違っている点を明らかにでき、別の一つのILは調査先企業もまだ構想中で未実現であることが分かった。十分に仮説を検証できたので、有意義な訪問になったことに礼を言い、いずれ当社の業務改革が進んだところでその成果を再度報告に来ることを約束して先方を辞してきた。

【次ページ】 「ファクトなしに報告を信じるな」と言った有能PM
関連タグ タグをフォローすると最新情報が表示されます
あなたの投稿

    PR

    PR

    PR

処理に失敗しました

人気のタグ

投稿したコメントを
削除しますか?

あなたの投稿コメント編集

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

通報

このコメントについて、
問題の詳細をお知らせください。

ビジネス+ITルール違反についてはこちらをご覧ください。

通報

報告が完了しました

コメントを投稿することにより自身の基本情報
本メディアサイトに公開されます

必要な会員情報が不足しています。

必要な会員情報をすべてご登録いただくまでは、以下のサービスがご利用いただけません。

  • 記事閲覧数の制限なし

  • [お気に入り]ボタンでの記事取り置き

  • タグフォロー

  • おすすめコンテンツの表示

詳細情報を入力して
会員限定機能を使いこなしましょう!

詳細はこちら 詳細情報の入力へ進む
報告が完了しました

」さんのブロックを解除しますか?

ブロックを解除するとお互いにフォローすることができるようになります。

ブロック

さんはあなたをフォローしたりあなたのコメントにいいねできなくなります。また、さんからの通知は表示されなくなります。

さんをブロックしますか?

ブロック

ブロックが完了しました

ブロック解除

ブロック解除が完了しました

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

ユーザーをフォローすることにより自身の基本情報
お相手に公開されます