※2012年12月1日より新ブログに移行しました。よろしければこちらもご覧ください。
free to write WHATEVER I like
Top > 仕事:駆け出しコンサル記 アーカイブ
次の3件>>
December 29, 2009

コンサルタントの領海侵犯問題

拍手してくれたら嬉しいな⇒
 会社に大阪の法律事務所から私宛でいきなり手紙が届いた。良質の紙に明朝体で綴られる文章。「げっ!何かやらかしたか!?」と恐る恐る読んでみたら、大学の同級生がその事務所に就職したことを知らせる手紙だった。もう、驚かせやがって…(本人は私を驚かす気なんてなかったんだろうけどね)。

 そんな余談はさておき、タイトルの「コンサルタントの領海侵犯問題」って何ぞや?ということだが、先日コンサルタントの勉強会に参加した時に話題になった事柄である。あるコンサルタントがクライアントから仕事を依頼されたところ、その企業には各部門に別々のコンサルタントがすでに数名関与していた。その方が悩んだのは、先に関わっていたコンサルタント達の実績がつかめず、彼らのこれまでの提言内容を覆すようなコンサルティングを実施してもいいのかどうか?ということだった。つまり、既存のコンサルタントの領海を侵犯するような行為が果たして許されるのか?という問題である。

 中小企業でも大企業でもそうだが、同じテーマや領域に複数の独立コンサルタントやコンサルティング会社が関わっていることは結構ある(私も直面したことがある)。この「領海侵犯問題」にはどのように対処したらいいのだろうか?ちょっと生意気な内容も入ってくるが、私なりの見解を述べてみたいと思う。

 クライアント側が複数のコンサルタントの手を借りる理由を考えてみると、2つに絞られると思う。1つは「前のコンサルタントが一定の成果を残してくれたが、続きのフェーズはそのコンサルタントの専門ではなかったため、別のコンサルタントに依頼した」というケースである。この場合、クライアントは前のコンサルタントを比較的ポジティブに評価しており、その内容を発展させることを期待している。もう1つは、「ある特定のコンサルタントだけに頼ると見方が偏る可能性があるから、多角的な視点から自社を分析してほしい」というケースである。この場合のクライアントはどちらかというと既存のコンサルタントを批判的、懐疑的に見ている可能性が高い。

 クライアントがどちらのニーズを持っているのかは、コンサルティングの最初の段階できちんと確認した方がよい。そして、既存のコンサルタントの成果物を必ず見せてもらうようにしなければならない。前者の場合であれば、既存のコンサルティング内容を踏襲しつつ、クライアントにとってより有益な提案へと膨らませていく。とはいえ、完全に既存の成果物に迎合すればいいかというとそういうわけではない。コンサルタントとして呼ばれている限りは、おかしいとか矛盾していると思う部分はきっぱりと指摘ししながら進めていく必要がある。

 後者の場合は堂々と領海侵犯していいと思う(もちろん、社内政治には気をつけなければならないが)。特に、クライアントが既存の成果物を見せてくれない場合は、ほぼ間違いなく後者のニーズを抱えていると言い切れる。前者であれば、成果物を隠す理由などないからだ。

 最初に紹介したコンサルタントの話では、クライアントの意図が読めず総花的な提案になってしまったが、実は後者のニーズを抱えていたことが最終報告会の時に社長の口から明らかにされたという。もしプロジェクトの開始時点でそれが解っていたら、もっと突っ込んだ提案ができたのかもしれない。

 話を聞いていると、どうやら営業部門、品質管理部門などにそれぞれ別のコンサルタントが張りついていたそうだ。にもかかわらず、営業は受注拡大ができていないし、欠品は多発するし、問題が山積だったという。コンサルタントが入っていながらそんな状況だったというなら、私なら間違いなく領海侵犯したと思うなぁ。だってそんなの許せないしね。
December 16, 2009

異なる立場の人が見ても理解できる資料を作ろう

拍手してくれたら嬉しいな⇒
 クライアント企業に自社製品を提案したり、社内で新しい企画を立ち上げたりする時には、(大抵はパワーポイントを使って)何らかの資料を作ることになる。読み手の立場に立って解りやすい資料を作れというのは当たり前のことだが、提案書や企画書は組織内の様々な立場の人が目にするから、異なる部署や役職の人が見ても意味が伝わるように注意しなければならない。これはかなり重要かつ難しいことである。

 例えばITベンダーがシステムソリューションを提案する際、その提案書は窓口となる情報システム部門、システムのユーザーとなる業務部門、そして最終的な決裁を下す経営陣の目に触れる。情報システム部門はシステム構成や開発期間、開発・保守の体制に関心があり、業務部門は新システムの使い勝手がいいかどうかや新システム導入後の業務プロセスがどう変わるのかを心配し、経営陣は新システムに対する投資がいつ回収できるのか、端的に言えばそのシステムで利益が増えるのかどうかを考えている。それぞれの疑問に全てもれなく答えられるような提案書を作る力量が、ITベンダーの営業担当者やSEには求められる。

 コンサルティングプロジェクトで事業計画や変革プランをまとめる場合にも、クライアント企業のプロジェクトメンバー向けにはこれまでの検討・分析内容や今後取り組むべき課題の詳細、実行計画と役割分担などをつぶさに記述し、役員向けにはA3で1枚程度のエグゼクティブサマリーをつけることが多い。このように、提案書や企画書は多様な人間が読むものだという前提に立って作成した方がよい。

 逆に、作成した資料が誰の目に触れるものなのかを事前に的確に把握しておかないと、後で痛い目に遭うことがある。かつて、あるクライアント企業の人材開発部で、社員育成のガイドラインを作成するという小規模のコンサルティングをした時のことである。この企業は、中長期的には抜本的な育成体系の見直しを必要としていたのだが、短期的には、上司と部下のコミュニケーション不足により上司が部下のスキルレベルを把握できず、従ってスキルアップの支援もできないという課題に直面していた。

 そこで、上司が部下のスキルレベルを簡易に把握し、定期的に部下の育成計画を立案する仕組みをまとめたガイドラインを人材開発部の担当者と一緒に作成した。小規模のコンサル案件だったということもあって、私はてっきり、この資料は人材開発部の上層部の人だけが見るものだと思っていた。しかし、いつの間にか人材開発部の上層部を飛び越えて、役員の目にも入ってしまったのだ。役員は当然、中長期的な育成体系の見直しに関心があるから、ガイドラインに書かれているような手続き的な話は眼中にない。そのため、「こんな細かいことを議論しろと言った覚えはない。もっと社員育成の全体像を描け」と言われてしまった。正確には私が直接言われたのではなく、役員にガイドラインを説明した人材開発部の担当者がそう言われてしまった。

 私も中長期的な人材育成体系づくりの必要性は知っていたのだから、もっと注意深く資料を作るべきだった。つまり、人材育成体系見直しのロードマップをきちんと描き、今回のガイドラインがそのロードマップの中でどういう位置づけになっているのかを示さなければならなかった。資料の読み手が誰であるかを読み違えたばかりに、クライアント企業の担当者に迷惑をかけてしまったという失敗談である。
November 23, 2009

データは定量/定性の両面から眺めよう

拍手してくれたら嬉しいな⇒
 組織の現状を把握して問題点を明らかにしようと思ったら、方法は2つしかない。つまり、定量データを入手するか、定性データを入手するかである。だが、どちらか一方で十分ということはまずない。両方のデータをバランスよく分析することが、現状の深い理解につながると思う。

 ある製造業のクライアントで、設計リードタイムの短縮をテーマとしたコンサルティングをした時のことである。設計部門の現状を把握するために、社員の方々にインタビューを行った。すると、「過去の設計情報を探し出すのが困難」、「受注設計の仕様書をチェックするのに時間がかかる」などといった設計業務そのものの非効率さを指摘する声以外に、「設計以外の仕事が多すぎる」という意見がかなり多く聞かれた。

 「顧客のクレーム対応、顧客先での運転指導などのサポートまですることがある」
 「設計図面を見れば解るようなことまで製造現場が電話で問合せてくる」
 「製造ラインで何か問題が起こると、製造現場に呼び出されて対応しなければならない」
 「部品の仕入れが遅れると、設計が製造ラインへの部品の配膳を行うこともある」

 設計部門といいながら、実態は営業も製造もアフターサポートも兼ねているようであった。本来、設計に費やすべき時間が設計以外の業務に奪われてしまい、製品設計のリードタイムに影響を与えているのだろう。だから、解決策としては、設計情報を設計部門⇔製造部門間で柔軟にやり取りするためのシステム改修、サポートセンターの組織体制再構築、部品調達基準・外注業者の見直しなども必要になってくるのかな?と思っていた。

 インタビューが一通り終ったところで、社員の方々がどの業務にどのくらいの時間をかけているのかを1週間調査することにした。インタビューで明らかになった現状業務を細かく分類し、各業務に毎日どれくらいの時間を費やしたのかをアンケート票に記入してもらうことにした。(※)

 インタビューで「設計以外の業務が多すぎる」とさんざん言われていたため、おそらく設計以外の業務がかなりの割合を占めているのだろうと予測していた。だが、アンケートを集計したところ、「設計業務の割合は約80%、設計以外の業務の割合は約20%」という結果だった。

 プロジェクトメンバーの予想よりも、設計以外の業務の割合は少なかったのだ。こうなると話が違ってくる。では、インタビューの時になぜ多くの社員が「設計以外の業務が多すぎる」と発言したのだろうか?ひょっとしたら、設計という創造的で神経を使う仕事に他部門から横槍を入れられると、必要以上に過敏に反応してしまうということなのかもしれない。あるいは、どんな部門でも他部門と依存関係にあるのだから、20%程度の他部門支援業務が発生するのは必然であって、それを必須のタスクと捉えていない設計部門の社員の意識にむしろ問題があるのかもしれない。この辺りは憶測なので、今となっては何とも言えない。

 ただ、業務量調査から言えることは、設計リードタイムを短縮するためには、設計業務そのものにダイレクトにメスを入れた方が効果が大きいということである。最終的にプロジェクト内では、インタビューで多くの指摘はあったものの、設計以外の業務に関しては優先度を下げ、設計そのものの生産性を上げる施策を重点的に検討するという結論に至った。インタビューの結果だけに頼っていたら、あまり重要でない問題にまで闇雲に議論を広げていたかもしれない。

 現状分析そのものが目的なのではなく、問題を解決するための施策を導き出すことが重要であるから、現状把握ばかりにいつまでも時間を費やすことはできない。しかし、時間がないからといって偏ったデータを使うのではなく、できるだけ定量と定性の両面から現状を観察できるように心がけるべきだと思ったエピソードであった。

(※)業務時間分析では、実際にストップウォッチを使って細かく時間を計測することもあるが、この時は厳密な分析というよりも傾向を知ることが目的であったため、アンケートという簡易的な手法を用いた。