Comments
Description
Transcript
第3部 - 経済産業省
第３部 IT プロフェッショナルに対する ヒアリング調査 第 3 部では、高いレベルのスキルを有する IT 技術者 30 名に対するヒアリング調査の 結果を分析し、次の３点を明らかにすることを目的としている。 高いレベルの IT 技術者は ①どのようなスキル・知識を有しているのか ②どのような経験を通して、それらのスキル・知識を獲得したのか ③どのように人材育成をおこなっているのか 上記の点を明らかにすることにより、日本企業の IT スキルおよび技術をよりレベル アップする施策についての手がかりを得ることができると考えられる。 1. 目的 1.1 調査目的 本調査の目的は、冒頭で述べたように、日本を代表する IT 企業における技術者が、どの ようなスキル・知識を持ち（目的 1）、どのような経験を通してそれらを獲得し（目的 2） 、 どのように人材育成をおこなっているのか（目的 3）を明らかにすることにある。 本調査での目的の意義および調査における焦点について述べる。 第 1 に、IT 技術者に対するインタビューを通すことで、現実に即した形で、スキルや知 識を抽出することができる。インタビュー調査の結果と従来の理論的知見を比較すること で、IT スキル・スタンダードの基準を見直す際に役立つ。 第 2 に、IT 技術者の持つスキルや知識が、どのような経験を通して獲得されたのかとい う「How」の部分を聞き出すことで、優秀な IT 技術者を育てる際のポイントが明らかにな る。これらのポイントは、IT 企業における若手・中堅技術者の人材育成の指針として重要 な意味を持つ。 第 3 に、高いレベルにある IT 技術者（IT プロフェッショナル）が、若手や中堅技術者を どのように育成しているのかを知ることで、人材育成の問題点や重要ポイントを明らかに することができる。上記の経験データとあわせて活用することで、知識マネジメントや人 的資源管理システムといった人材育成の制度的側面を考える際に役立つ。 また、これらの目的は、本報告書全体の基本目的と照らし合わせると、「C）プロフェッ ショナルになるまでに何が必要か」に対応する。 141 1.2 調査モデル インタビューデータを分析するにあたり、IT 技術者を①プロジェクトマネジメント、② コンサルタント、③セールスの 3 つの職種に分類する。このとき、IT アーキテクトの調査 人数が少なかったこと、そしてヒアリングにおいてはスキルの面でプロジェクトマネジメ ントと重複する部分が多くみられたことから、プロジェクトマネジメントに含める形で分 析した。また、コンサルタントのうち、IT（業務）コンサルタントとビジネス（BT もしく はマネジメント、アプリケーション）コンサルタントは特に区別せず、一括してコンサル タントとして扱った。セールスは調査人数が少ないが、他の職種とスキルが異なるため、 独立して分析をおこなった。 図 3.1.1 の調査モデルは、IT 技術者が、職務経験を通して様々なスキルや知識を獲得す ることをしめしている。その際、獲得されるスキルや知識は、「熟達段階（初級レベル期・ 中級レベル期・上級レベル期） 」や「職種（プロジェクトマネジメント・コンサルタント・ セールス） 」 、 「各社における人材育成の方法」に影響を受けると予想される。 熟達段階 ・初級レベル期（入社∼5 年目） ・中級レベル期（6 年目∼35 歳） ・上級レベル期（ここ最近 5 年） 職務経験 スキル・知識 職種 ・プロジェクトマネジメント ・コンサルタント ・セールス 図 3.1.1 調査モデル 142 各社における 人材育成の方法 2. 方法 2.1 調査手続 わが国において、プロフェッショナル制度もしくはプロフェッショナルの育成に力を入 れている IT 企業 6 社を選定し、経済産業省商務情報政策局を通してヒアリング調査の依頼 をした。各社人事・教育担当が 4 名から 8 名の IT 技術者を選定し、最終的に 6 社 30 名の 技術者に対してヒアリング調査を実施した。調査対象者の選定にあたっては、各社におい てプロフェッショナルと認められ、IT スキル・スタンダードにおいてレベル 5 以上で、可 能な限りレベル 6 か 7 に相当する技術者を選定してもらうように依頼した。 ヒアリング調査は、9 月から 11 月上旬の間に行われ、調査者 2 名が各社を訪問した。ヒ アリングは、半構造化された形で行われた。すなわち、調査者が提示した質問に答えても らうが、質問の順序にこだわらず、話の流れを重視し自由に話してもらう形をとった。ヒ アリングの所要時間は 1 時間から 2 時間であり、内容はフィールド・ノートに記録され、 テープレコーダーに録音された。録音された内容は、全て文字に変換し、電子データにし た。 2.2 調査対象者の属性 ヒアリング調査対象者の職種および所属企業は、表 3.2.1 に示すとおりである。30 名の 対象者のうち、男性 29 名、女性 1 名、年齢は、38∼57 才であり、役職は全員、部長以上 であった。職種としては、プロジェクトマネジメントが 15 名（IT アーキテクト含む）、コ ンサルタントが 11 名、セールスが 4 名であった。セールスの人数が少ないため、以下では、 参考程度に分析結果を報告する。 表 3.2.1 調査対象者の職種・所属企業 職種 プロジェクトマネジメント コンサルタント セールス 計 A社 3 1 1 5 B社 3 1 0 4 C社 3 3 2 8 143 企業 D社 0 3 1 4 E社 3 1 0 4 F社 3 2 0 5 計 15 11 4 30 2.3 質問項目 ヒアリング調査では、以下の質問をおこなった。 質問 1：入社から現在までを、初級レベル期（入社∼5 年目） 、中級レベル期（6 年目∼35 歳） 、上級レベル期（ここ最近 5 年）に区分した上で「自身のスキルや能力が向上 したと思われる経験（プロジェクト・出来事・職務）」について説明してください。 質問 2：各経験を通して、どのようなスキル・知識・能力が身についたと思うか、説明して ください。 質問 3：現在、社内や部内において、どのような形で知識や情報を共有し、人材育成をおこ なっているか、説明してください。 2.4 分析方法 調査者は、記録されたヒアリングの内容を、以下の手順で分析した。 第 1 ステップ ヒアリング・ノートの中から、①IT 技術者が持つスキル・知識・能力、② スキル・知識・能力を獲得するきっかけとなった経験、③社内における人 材育成方法、に関する情報をピックアップした。 第 2 ステップ ピックアップされた情報のうち、 類似性に基づいて情報をカテゴリー化し、 名前をつけた（職種別） 。 以下の分析では、カテゴリーレベルの分析に加えて、代表的なインタビューデータの一 部を提示する。カテゴリーに関する詳しい内容については資料（1）を参照のこと。 144 3. 結果 3.1 IT 技術者のスキル・知識・能力 ヒアリング調査で提示されたスキル・知識・能力は、次のようなカテゴリーに大きく分 類することができた。 ①顧客管理 顧客に対する活動 ②集団管理 部内やプロジェクト内のメンバーに対する活動 ③仕事上の知識 職務を遂行する上で必要な知識 ④分析能力 職務を遂行する上で必要な分析能力 ⑤姿勢・態度 職務を遂行する上で必要な姿勢や態度 以下の分析では、これらの分類基準に沿って、獲得されたスキル・知識・能力を整理す る。なお、表中の（ ）の数字は、一連のインタビューにおいて、当該カテゴリーに含まれ るスキル・知識・能力が出現した回数である。また、表にまとめる前の詳細な情報を付録 ４の付属資料３にしめす。 145 3.1.1 顧客管理に関するスキル・知識・能力 表 3.3.1 顧客管理に関するスキル・知識・能力（職種別） プロジェクトマネジメント コンサルタント セールス 顧客とのコミュニケーション(7) 顧客とのコミュニケーション(5) 顧客の視点で考える(3) 顧客のプライオリティを明確化 顧客ニーズ・問題の把握(10) 顧客を理解する(5) (5) 期待より少し上のサービス(1) 顧客に密着する(1) エンドユーザー志向(1) 顧客との関係づくり(5) キーマンの把握(3) 顧客の視点でとらえる(1) 顧客の説得・交渉(5) お客様を導く力(1) 顧客から学ぶ(1) 一貫して自分のやり方を通す(1) トラブルからの信頼(2) 適切なトラブル処理(3) クイックな立ち回り(1) レスポンスの速さ(1) 期待より少し上のサービス(1) できないことを明確に伝える(3) 職種にかかわらず、顧客に対する活動において最も強調されたのは、 「顧客とのコミュニ ケーション」であった。職種による違いも見られ、プロジェクトマネジメントでは「顧客 のプライオリティを明確化する」「できないことを明確に伝える」といった顧客の要求水準 や期待を明確にするスキルを重視していたのに対し、コンサルタントやセールスは顧客に より深く入り込むことを強調していた。 例えば、あるプロジェクトマネジメント（P1）は次のようにコメントしている。 「一言で言うと、コミュニケーションスキルだと思うのですよ。我々にとって、まず 何が一番大事なのかというと、お客様の真の要求を正確に捉えることなのです。例え ばお客様の予算を知らないで進めていてもうまくいきませんし、どういうレベルのシ ステムを作りたいかというポイントを外しても、うまくいきません。つまり何を基準 にプライオリティをつけるのか。例えば、とことん性能追求型でいくのか、または絶 大なる信頼性を求めるのか等、要求ポイントを明確にすることが大事です。 」（P1） 別のプロジェクトマネジメント（P9）の声も聞いてみよう。 「 （失敗するプロジェクトの原因は）大規模ということに限らず、出発点の、お客様と の間の整理ですよね。契約を含めて。要件範囲、役割といった、そこがあいまいだと いう場合が、まずありますよね。プロジェクトマネジメントなり、プロジェクトリー ダーが、最終的に、システム、インフラ、アプリケーション、どんなものを作るんだ ということのイメージをちゃんと持っているかどうか。持っていない場合、失敗しま 146 すね。 （中略）当社も、結構失敗しているプロジェクトもあるんですけどもね。仕様が なかなか決まらないということがあって、お客様にレビューをお願いして。それをし ても、なかなか決まらない、うやむやになって、ずるずるといってしまうということ があって、大問題になったことがあるんですけども。そのときに、お客さんが、時間 が取れないからちゃんとレビューしてもらえないとか、お客さんに対応していただけ ないということをいう人もいるんですよ。そういうことは、現象的には事実ですが、 お客様と話してみると、当社が出してる検討資料なり、仕様書の観点がずれていたり するんですよね。だから、相手にしてくれないということがあるんですよ。お客様と よく話してみると、本当はそういう問題だったりもする。そういうことをつかまえて、 ではどういう手を打たなくちゃいけないとか。」（P9） しかし、顧客のニーズを把握し、プライオリティを明確にすることは容易なことではな い。顧客の求めているものを様々な角度から検証することが重要となる。次のプロジェク トマネジメント（P5）のコメントを見てみよう。 「お客さんが色々言ってくるが、何を求めているかを正確につかむか。外すととんで もない方向にいってしまう。そうなると門前払いになる。なんとなくこんなもんだと 思ってアプローチするとうまくいかないんです。いかにお客さんが求めているものを 正確に把握するか。言ってることを言葉どおりにやってもしようがないわけで、言っ ていることがらを色んな角度から検証して、確かにここを求めているというのを押さ えて対応する必要があるんです。」 （P5） コンサルタントは、プロジェクトマネジメントに比べ、一歩踏み込んだ形で顧客とコミ ュニケーションすることが求められている。つまり、顧客があいまいな形で抱えている問 題点を明確に整理しなければならない。あるコンサルタント（C5）は次のようにコメント している。 「コンサルタントとしての役割みたいなものに、いくつかあるんですけど。大きいの は、その相手の立場に代わって、社内で発言してあげる、もう 1 つはまとめてあげる ということだと思うんですよね。よく誤解を受けるのが、自分たちが考えられなかっ たことを、何か出してくれるという。そうではないですと、最初に申し上げるんです けど。ビジネスをしているのは、お客様自身ですから、ビジネスをしてない人たちに かなうわけないですよね。違う観点で見るとか、まとめるという行為は、我々の仕事 だと思ってますし。社内で、あなたに代わって発言しますというのが、1 つのキーです ね。 」（C5） 147 次のコンサルタント（C9）は、顧客企業の実態をつかむために、独自のやり方を工夫し ている。 「話していって、相手が『しまった！内部的なことまで言うじゃなかった』というよ うなことまで、できるだけ聞かなきゃいけないんですよね。というのが、コンサルタ ントの実際に業務分析、現状把握というのが、そういうことだと思うんですよね。私 がやるときは、必ず 2 ラウンドやるんです。必ず、同じ部門を 2 ラウンドやります。 というのは、まず監督者階層、係長くらいのレベルですね。係長というのは、業務を 自分でやりながら、ある程度監督的なことをやってるわけですね。その人たちにまず、 お話を聞きます。同じ資材の人とか、生産管理の人とかに聞くんですね。その次に、 管理者階層、課長とか、部長とかに同じことを聞くんですね。そしたら、答えはおの ずと違うんですね。 （中略）別々の時間に、全然隔離して、聞きますからね。どれが真 実かってわかりますね。そこをつかまないと、フィードバックしても、ベースが真実 でないと全く意味がないんですね。」 （C9） セールスの場合には、次のコメントに見られるように、顧客の組織に入り込んだ上でキ ーマンを把握することが重視されていた。 「誰かまず、プロジェクトの旗を振ってくれる人を、見つけなければいけないので。 お客様の中で。あるいは、これをもって男になるというですか、そういう人を見つけ て、スポンサーを見つけて、プロジェクトの形を作っていって、お客様に、プロジェ クト稟議を出していただきますというか、そこが、私の一番重要な仕事だと思ってい ます。 」 （S2） 顧客の現状を把握した後に重要となるのは、「顧客との交渉スキル」 「顧客を説得するス キル」である。次のコンサルタント（C9）は、最も重要な能力として「説得力」を挙げて いる。 「やはり、納得感のある説得ができるということが、非常に重要なことで。そのため には、こちらをのんで、いくら押し倒しても、ロジカルに抗議するというのはダメな んです。相手がやはり、ここくらいは我慢しなくちゃな、っていう納得感がある説得 ができる、不安が残らない説得ができる能力が、コンサルタントには、一番要求され ると思いますね。そうじゃないとね、作った仕組みを使わないんですよね。 」 （C9） 148 3.1.2 集団管理に関するスキル・知識・能力 表 3.3.2 集団管理に関するスキル・知識・能力（職種別） プロジェクトマネジメント コンサルタント セールス プロジェクトの目的を明確化(2) 局面局面での準備事項(1) 率先垂範(1) スケジュール管理(7) リスク管理(2) 社内の人脈(1) 品質管理(3) プロジェクト状況の見極め(1) 事前予測と準備（リスク管理）(4) 顧客と開発の調整(1) 優先事項の明確化と決断力(6) チームメンバーとの情報共有(7) サブリーダーのマネジメント(3) やる気を出す仕組みづくり(1) メンバーの方向づけ(6) 能力が見えている人材をコント 率先垂範（やってみせる）(3) ロール(1) 集団管理に関するスキルは、圧倒的にプロジェクトマネジメントにおいて重視されてい た。特に、「スケジュール管理」「リスク管理」「優先事項の明確化と決断力」 「チームメン バーとの情報共有」 「メンバーの方向づけ」に関するスキルが重視されていた。なお、コン サルタントの多くは、プロジェクトマネジメント職種の経験を持っていた。表中に示され たスキルは、プロジェクトマネジメントとして必要なスキルである。 スケジュール管理や事前の準備に関して、あるプロジェクトマネジメント（P10）は次の ように述べている。 「どういうマネージをしていこうかという計画を立てるというのは非常に重要ですよ ね。その時点で、いろんなリスクを考えて、それに対するスケジュールでのバッファ とか、要員計画でのバッファとか、後は設計面での考慮とかですね。そういったとこ ろを、やはり埋め込むんですよね。それをどこに埋め込むかと、どこがこのプロジェ クトのポイントなんだっていうことを見極めるのが大事だと思います。たとえば、1 個 前のプロジェクトというのが、非常に規模がでかくなってきて、たぶん、進捗も遅れ てきて、品質も後ろの方で悪いだろうと。すごく長い期間、開発するからですね。そ うすると、必ず、後ろの方で、いろんな対応をしなきゃいけないということで、なる べく上流の方は人を抑えて、後ろの方に要員計画を積んどいてあげるんですよね。」 （P10） 149 プロジェクトの全体スケジュールを把握した上で、重要ポイントを事前に見極めること の重要性は、別のプロジェクトマネジメント（P6）も指摘していた。 「まず、マイルストーンを明確にして、作業間の関連をちゃんと作って、どこがクリ ティカルパスだということを押さえられる、全体スケジュールを書きます。例えば、 問題のプロジェクトにいって、スケジュールを見せてくれと言ったら、実はそういう 関連の、絵などないガントチャートというか、棒グラフみたいな絵だけ書いていくプ ロジェクトもあって、ここの作業とここの作業は、どんな関連があって、何がクリテ ィカルパスなのかということ、を全部話し合って、最悪私が、全部書いて、これでい こうと。まず、そういう大きなところはちゃんと作った上で、それをブレイクダウン するということなんですよ。全体をまず、きっちりと。大体、まずいプロジェクトは そういうのがないんですよ。」 （P6） プロジェクトが大規模になるほど、少数（4, 5 人）のサブリーダーを通して間接的にプロ ジェクトをマネジメントすることが重要になる。次に挙げる 2 人のプロジェクトマネジメ ント（P9, P6）のコメントを見てみよう。 「自分で見れるというのは、4∼5 人くらいですから、キーマンをちゃんとつかまえる。 見分けて、技術的な面だったらこの人、マネジメントの面だったら、この人というよ うに、ある程度、4∼5 人に絞って。直接コントロール、指示を与える人を絞ってやり ました。その配下は、その人に見てもらうという形で。」 （P9） 「その人のスキルと、性格というのを、ちゃんと（見極める）。こいつは、誰かがいな かったらダメなやつとか、あんまりきつく言ったら、反抗的になるとか。何かがあっ たときに、プロジェクトが忙しくなって残業が増えて、コンビニ食が多くなって、い らいらし始めて、そういう状況になって、人間がどういう風に出てくるかという。全 然変わらないやつもいるし、切れるやつもいる。全員を見るわけじゃなくて、4∼5 人 ですよ。大きなプロジェクトであっても。キーマンは 4∼5 人。この人間があまり、変 な風にならなければ、他のヤツも見れると。ずっと監視してるわけじゃなくて、こい つらがまともな方向に動き出せば、こっちから目を遠ざけて、こっち側の人間を見て いったらいいと。これがうまく作用しなければ、このプロジェクトはぼろぼろになる と。 」 （P6） プロジェクトマネジメントは、サブリーダーに仕事を任せるだけでなく、問題が生じた ときには、問題の性質を吟味した上で、速やかに解決しなければならない。あるプロジェ 150 クトマネジメント（P7）の次のコメントを見てみよう。 「サブグループのなかで閉じていてすむような問題と、全体に行き渡る問題というの を見極める。グループに閉じた問題がそのグループのリーダーとその範囲内で解決能 力があって、おさまりそうな問題かどうかを判断する。おさまりそうならいいが、一 方、グループ間にまたがるような、アーキテクチャーにかかわるような問題について は、基本的には解決できないだろうということで、自分が入る。自分が入って、かか わるメンバーの主だったメンバーを集めて、タスクフォースでも問題の所在とか、ど ういう対策をうつかということでも、そのときに誰がいつまでにということを徹底す る。 」（P7） プロジェクト内に問題が生じているかどうかを見極めるためには、普段からの情報収集 が鍵となる。次のプロジェクトマネジメント（P1）は、サブリーダーが上げてくる情報の 正確度を把握し、多面的な情報収集をおこなっている。 「その人の上げてくる情報の精度というのを、自分として持っているんです。つまり、 ある分野の見解に関してはその人は正しいけど、違う分野での見解は、自分が辛いだ けで言っていることが多い、という事を個人別にマッピングしています。又１つの情 報だけだと精度がおちるので、対面情報をどう取るかということが大事です。対面情 報の取り方は 2 つあります。1 つは、プロジェクトの中で SE 組織以外に、プログラム の開発部署・他事業部などの関連部署が、密接に関連し、仕事を横の立場で見ている わけです。その部署の人から、どう見えるかという事を日頃から聞いておいて、自分 の中で考えている事の精度を上げていくのです。もう１つは、最近はなかなか難しく なってきているのですが、若い人の情報が直接上がってくるルートを作っておく事で す。 」 （P1） トラブルが生じる危険性のある重要な場面において、プロジェクトマネジメントは、自 ら手本を見せることでサブリーダーを教育しつつ、プロジェクトを進める必要がある。あ るプロジェクトマネジメント（P1）は次のようにコメントしている。 「もめそうなときだけですよ。自分で、こうやりますということで、こういう風にし たいということをやって、彼が見て、どういうスタイルでやると。あるところまで、 それをやりまして、あるところから切り替えて、全部やってもらうんですよ。私は、 横にいるんですけど、見てるんです。それでやり方についてのディスカッションみた いな形で、これは合ってると思うけど、これは外してると思うとか。考え方はいいけ 151 ど、アプローチの仕方がまずいから、誤解を招くとか。」 （P1） 3.1.3 仕事上の知識 表 3.3.3 仕事上の知識（職種別） プロジェクトマネジメント コンサルタント セールス 技術的知識(9) SE としての能力(3) アプリケーションのノウハウ(1) モノの作り方(2) 経営全般を見る目(5) 技術検証力(1) 世の中のしくみの知識(1) 業務知識(4) お客様との仕事の進め方(1) ビジネス全体のしくみ(1) メソドロジー(3) 法律的知識(1) 業務知識(2) 自己の得意領域(1) 人脈(1) 仕事上の知識に関して、プロジェクトマネジメントが最も強調していたのは、コンピュ ータに関する「技術的知識」であった。プロジェクトマネジメントに必要な技術的知識と して挙げられたのは、「コンピュータの基本」「プログラミングのスキル」「ハードウェア の知識」 「データベースの知識」「システム全体の知識」であった。ただし、インタビュー の中では、技術的知識は重要であるが、あくまでも前提条件であり、優れたプロジェクト マネジメントの決定要因とはならないというコメントが多くみられた。 技術的知識とマネジメントスキルの重要性の割合について質問したところ、あるプロジ ェクトマネジメント（P7）は次のように答えている。 「私はやはり幹部社員になるときから、半々くらいかと思っている。私のときは 37 か らなったから、そのときから、エンジニアリングが 5 割で、5 割がマネジメント。部長 になったら少し上がって、事業部長になったら、7∼8 割がマネジメントで 2 割くらい がエンジニアリング。ただその 2 割のエンジニアリングというのは、エンジニアリン グの割合が少なくなればなるほどエッセンスは貯まっているというものじゃないかと 思う。」 （P7） また、業務知識に関しては、むしろ業務を理解する力が重要であるという意見があった。 あるプロジェクトマネジメント（P2）の次のコメントを見てみよう。 「たとえば組み立て加工なら何でもいいけど、生産管理にしても販売管理にしても、 お客さんとやれば、お客さんの方が業務やその理解のしかたにしても詳しい。自分で 業務の仕事をしているのだから、詳しいし、理解が及ばないのは当然だと思っている。 我々が業務知識をつけたにしても、違うお客さんを相手にシステムを作るのだから、 152 同じ業界でも相手が違うから、いくら業務知識を知っていても、我々の言っているよ うにやってくれることはまずないので、業務知識は必要がないとは言わないが、それ よりも理解力だと思う。基本的にお客さんの言っていることが理解できて、聞いてい るなかで、お客さんのやりたいことを理解して、矛盾を見つけたり、それを整理して、 システム化することのほうがよっぽど大事だと思う。」 （P2） コンサルタントに必要な知識として挙げられたのは、自己の領域における「業務知識」 、 「経営全般を見る目」 、「メソドロジー」であった。特定業務を得意分野とする業務（IT） コンサルタントの場合には、業務知識が重要となる。小売分野を専門とするコンサルタン ト（C5）は、次のように述べている。 「その当時は、小売、流通関係というのは、お客様自身とまさに一緒にやれるという 環境の中でやりましたね。技術的な世界はそうなんですけど。お客様によって、技術 だけやってという場合もあれば、アプリケーション開発一緒にという場合も。アプリ ケーション的には、百貨店さんなんかで、「友の会」というようなシステムをやりまし たね。あれをリアルな仕組みで立ち上げたときに、リアルオンラインで立ち上げたと きに、まさに 1 からやったという感じですね。それから、ずっと百貨店さんで、いわ ゆる POS のシステムをやって。当時まさに出始めた頃で。その POS に、いわゆる店 舗上システムというものを中心に手がけてきましたね。百貨店さんですので、ある意 味で全ての業種を扱える。衣料から、食品、大型の家具とか。今、出ている業種業態 みたいな、大きい枠組みの部分をそのときに身につけられたという感じですね。」 （C5） このように特定領域を得意分野とする業務コンサルタントの場合には、業務知識が非常 に重要になる。これに対し、経営一般に対するコンサルティングを行うビジネスコンサル タントは、企業経営、会社、ビジネスの全体像を理解しているかどうかという「経営全般 を見る目」を重視していた。 コンサルティングをする際の方法論・手法をメソドロジーと呼ぶが、 「コンサルタントの グレード別に、このメソドロジーをどのように扱うべきか」について、あるコンサルタン ト（C2）は次のように述べている。 「メソドロジー活用というのは当然の話ですが、コンサルタントグレードによって行 動の水準が異なります。既存のメソドロジーに従ったコンサルティングを遂行できる というレベルの上位は、コンサルプロジェクトの目的やクライアントの体制・力に合 わせて部分的に省略したり、複数のメソドロジーを組み合わせてアレンジできるとい うレベルであり、更にその上のレベルだとメソドロジー自体を自ら開発しています。 153 （中略）コンサルティンググレードという話をしましたが、真中くらいのグレードは メソドロジーを使ってコンサルプロマネができること。その一歩手前はプロジェクト 全体のリーダーはできないけど、プロジェクトの中での各ワークショップを切り盛り できること。そのもう一歩手前はコンサルリーダーから指示された調査、分析、仮説 立案ができること。そういう順番でグレード付けを行い、ジョブアサインをしていま す。 」（C2） セールスも、IT の技術動向を把握するスキルが必要となるという。あるセールス（S3） は次のようにコメントしている。 「私が常に言っているのは技術検証能力、これは営業でも兼ね備えないとだめ。今技 術の進展が早い。例えばデータベースなどいろいろあるが、マニュアルを見れば何も 考えずにできるとなるが、原理原則がわからない人は使い方だけ勉強してしまうので、 新しいものがでたときできない。お客さんと話すときも原理原則を知りながら、セー ルスの技術検証能力がないといけない。」 （S3） 3.1.4 分析能力 表 3.3.4 分析能力（職種別） プロジェクトマネジメント コンサルタント 問題の分析能力(5) 問題解決能力(8) ゼロから新しいものを作る能力 柔軟な対応力(2) (1) 論理的思考力(3) 世の中とコンピューターをつな 提案力・企画力(1) ぐ能力(1) 現場と理論のバランス(1) 要件が不明なときの類推能力(1) 各種分析スキル(4) セールス 環境の変化を理解する(1) プロジェクトマネジメントに必要なのは、 「問題の分析能力」であった。クライアントか ら業務の話を聞き、業務のポイントや問題の所在をつかむことが重要となる。次のコメン トは、銀行をクライアントに持つプロジェクトマネジメント（P3）のものである。 「自分でポイントだと探すわけではなくて、いわゆるヒントは教えてもらえる。具体 的にここがポイントなんだよと。何でこういうものができるのかわかればいいんだと。 ただ『それは 10 年かけて覚えるんだ』と言われたときに、それはそれでサラッと聞き 流しておいて、ココがポイントだと思って、あとは自然に仕事の中でどこかで色んな 154 ヒントが出てきて、なるほどと思うことが出てきたりとか。」 （中略） 「1 つ覚えてくる と銀行員ではないので全て覚える必要はなくて、あるポイントだけ覚えて、認められ るとあとは普通の会話ができる。そこまでもっていけば、どこかのプログラムが作れ るけど業務がわからないヤツと思われずに、ある程度この業務なら会話ができるぞと いうところまで持っていけば。」 （P3） 個人の分析能力を最も重視する職種はコンサルタントであった。特に、顧客の抱える問 題を把握し解決策を提示するための「問題解決能力」「論理的思考力」「各種分析スキル」 が重要となる。問題解決能力とは、「問題をはっきりさせる」「変化が何かをあぶりだす」 「本質を理解する」 「問題解決技法を活用する」といったスキルを含んでいる。あるコンサ ルタント（C2）は、会社のメソドロジーの一種である「真因訴求法」について次のように 述べている。 「メソドロジーの中には各種の要素技法が含まれていますが、入り口は KJ 法なんです よね。まずは具体的な問題を極力定量的に 3 行で書いたポストイットカードを大量に 集めて、それをグルーピングしていって、全体の構図が俯瞰できるような形に整理し ていきます。そこで問題の構造ができて、因果関係とか、どれが親だとか子だとかが 出てきますよね。それを見て、どうもこの辺がヘソっぽいですねというポイントを抽 出し、次にそれに対してこれはなぜ起きているのかということを逆に展開して、これ 以上いくと政治の問題になってしまうという手前のところで、どれが真因かというこ とを決める。そして、これが真因だというところを整理して、これだけ解決できたら、 そもそもの目的のこれは解決しますね、ということで合意を取ります。ここまではボ トムアップ型ですが、その後はこの真因を解決するために何をしないといけないとい う課題展開を、トップダウンで進めていきます。」 （C2） 「各種分析スキル」としては、 「マーケティング・リサーチ」 「財務分析」「ドキュメンテ ーション・スキル」 「企業の定量分析」といった分析方法が挙げられていた。 なお、セールスに対するインタビューにおいては、分析能力を重視しているというコメ ントは得られなかった。 155 3.1.5 態度・姿勢 表 3.3.5 態度・姿勢（職種別） プロジェクトマネジメント コンサルタント セールス 強い意思(2) 顧客志向(2) 責任感(1) 責任感(1) プロだと思うこと(1) 情熱(1) 自信の核があること(1) スキルよりも態度(1) 現地、現物主義(1) グローバルな視野(1) 常に新しいものをやる(1) ビジネスゲームの感覚(1) いずれの職種においても、個人の態度や姿勢は特に強調されてはいなかったものの、 「強 い意思」 「責任感」「情熱」等、プロとして自身に自身を持つことの重要性が指摘された。 あるプロジェクトマネジメント（P10）は、次のように述べている。 「悪い PM さん、私から見て『何だこいつは』と思う PM さんは、その問題に対して、 真正面から真剣に取り組まないとか、それに対する判断も適切でない、と。ちゃんと 中身がわかってないから、問題のですね。判断も適切じゃない、と。 （中略）本当の修 羅場になってくると、その人の本質がわかってくる、というのがあるんですよね。人 間って、結構人のせいにしたりとか、完全に誰かに任せて「お前やっとけよ」と、た だ指示だけしてですね、中はきちっと見ないで、人にやらせるとか・・・。というと ころが、見えてくると、やはり PM としてはダメだなと。本当に、最後の一番苦しい ときに、皆から信頼されて、自分が率先して、その辺を解決していくようじゃないと、 なかなかついてこないですよ。」 （P10） あるコンサルタント（C5）は、後輩の育成に関して、「プロ意識」を持つことが必要だと している。次のコメントを見てみよう。 「プロだと思え、という一言なんですけど。 （中略）やはり、給料とっているというこ との自覚が、基本的についてないと思うんです。特に、大組織の中では。ある意味で は、何も（仕事を）しなくても給料はもらえるみたいな話で、それですんじゃう世界 もあるんですよ。それは、許せないと。単純に言うと、私の持論ですけど。 」（C5） 次のセールス（S1）は、仕事をする上で「情熱（パッション）」を持つことの大切さを指 摘している。 「たとえば、私は昔からそうなんですけど、お客様とは徹底的に付き合うと。付き合 156 うというのは、酒が飲めるということなしに、たとえば、お客様の旅行があるとね、 自分も、スキーやテニス、山登りが好きだと、もう必ずいくと。うちの電話番号も全 員に教えました。何かあったら、うちに電話してきてくれ、と。それから、このお客 様のために、何が何でもやるんだという気持ちでやらないとダメですね。だから、こ れは、営業とか、どんな仕事でも、何が何でもやるんだ、というパッションをですね、 こういうのがないと・・・。」（S1） 157 3.2 スキル・知識・能力を促進する経験 次に、どのような経験を通して、スキル・知識・能力を獲得したかについて分析する。 職種毎、キャリア段階毎（初級レベル期・中級レベル期・上級レベル期）に、「経験の内容」 と「獲得したスキル・知識・能力」を整理した。 3.2.1 プロジェクトマネジメント 表 3.3.7 プロジェクトマネジメントが経験を通して獲得したスキル・知識・能力（熟達段階別） 初級レベル期 中級レベル期 上級レベル期 SE として部分的な仕事 小・中規模プロジェクトの 大規模プロジェクトのリーダー リーダー 厳しい顧客 ↓ ↓ ↓ コンピューターの基本、技術的 コミュニケーション、トラブル処 サブリーダーを通しての間接的 理、ものづくりの全体像を把握 マネジメント、即断即決、顧客 プロジェクトマネジメント ５∼６人のサブリーダー 知識・スキルの習得 の理解 プロジェクトマネジメントは、初級レベル期段階（入社から 5 年目まで）に、 「SE とし て、プロジェクトの部分的な仕事を担当」したり、 「プロジェクトのサブリーダーとして、 ５∼６名のメンバーを指揮するという経験」を通して、IT に関する基本的な技術や知識を 身につけていた。初級レベル期段階における仕事について、あるプロジェクトマネジメン ト（P9）は次のように述べている。 「このときは、プログラムの担当者でしたから、お客様が厳しいと感じることはなか ったですね。直接交渉することもなかったですしね。システムの仕組みも、この時期 に勉強したり、調べたりしました。 （中略）こういうプログラム担当で、結構いいもの ができたという後に、人が配下にくるようになって、もう少しまとまったものを見る ようになったときに、人にちゃんと任せるなり、指導するというようなことを、やれ ばよかったんですけども。自分自身でやらないと納得しないというところがあって、 あまりうまくいかなかったんですよ。その時期は。それが、後で、ヒューマンスキル の重要性というんですか、そういうことに気がつきました。」 （P9） このプロジェクトマネジメントは、プログラムという限定的な仕事の中で、システムの 仕組みに関する能力を磨いていたことがわかる。別のプロジェクトマネジメント（A3）の コメントを見てみよう。 158 「私自身は、大規模、何年もかかるプロジェクトを経験してますので。そんなに変わ ってないんですけど、入社 1 年目から 5 年目で見ますと、最初に入ったところが、信 用金庫の共同センター、金融機関ですね。仕事としては、アプリケーション、OS だと か、ミドルだとか、システム SE という仕事を 5 年くらいやってました。アプリケーシ ョン開発というより、システム構築ですね。性能計算、容量計算とか。信頼性も当然 ありますね。その中では、最近はあまり使わないですけど、待ち行列を使ったモデル を作って。最初の 5 年間というのは、システム SE のしくみだとか、スキルとして身に つけて。1970 年代後半というのは、SE がまだ、ハードウェアだとか、OS を直接見れ るという感じですかね。例えば、ディスクですと、回っているのが見えるというよう な時代ですから、そういう意味では、システムの基本となるのは、この時期に身につ けたんですね。生で OS だとか、ネットワークだとか、自分自身で実体験が積める環境 にありました。 （中略）3 人から 5 人のグループの一員ですから、大きなグループでは ないですね。」 （A3） 中級レベル期（6 年目から 35 歳）になると、小・中規模のプロジェクト（数十名のメン バー）のリーダーとして、 「コミュニケーション」スキルを獲得し、「ものづくりの全体像」 を理解する傾向にある。あるプロジェクトマネジメント（P1）の次のコメントを見てみよ う。 「中堅期は、SE が 30∼40 人程度いて、主任クラスとして参画しました。その中でお 客様の要求はどこに重点をおくか、例えば性能に重点を置く、信頼性に重点を置く、 運用性に重点を置くなどです。お客様、特に金融機関さんは、皆どれも大事だとおっ しゃるので、その中でもプライオリティをどうつけるかということが必要です。（中 略）社内の立場が上がってきたときに、課長相当のマネジメントを行うようになり、 プロジェクト全般を見てどのようになっているか。プロジェクトで、工程的に何が遅 れているのか、トラブルが起きて解決が遅れて問題になっている事はないか。お客様 の思いと我々の考えがマッチしているか。などのことを、プロジェクトの途中から担 当し始めて、今に至っています。」 （P1） 徐々に、部分的な仕事から、プロジェクト全般をマネジメントする仕事へとシフトして いることがわかる。次のプロジェクトマネジメント（P8）も、プロジェクト全般を管理す る仕事を経験することで、コミュニケーション能力の重要性に気づいたという。 「7∼8 年目に、100 名の大きさのプロジェクトを経験しました。海外で 20 名、国内で 159 80 名というオーダーです。その前は、OS 全体のあるコンポーネントのリーダーでし たので 10 数名ですね。 （中略）見なきゃならない技術領域がかなり広くなりますから、 視野の広さが必要になります。トラブルも、お客様から出てきたトラブルと、自分が プロジェクトを進めていく問題と、あと、例えば人が辞めたくなったとか、プロダク ト品質の問題、お金の問題もありますね。あまり IT のスキルと関係ないんですけど。 （中略）なぜそれが問題となったかという背景をよく知るということで、問題となっ ているということは何者かが期待していることに対してそのとおりになっていない、 ということだと思うんですよ。もともと期待されていることは何だったんだろうと、 それが乖離していることは何ですかと。表面的な問題ではなく、本質的な問題を把握 することが、問題で困っていることに対して嬉しい解決になるんじゃないかな、と思 うんです。 」 （P8） 上級レベル期（12 年目以降）では、大規模プロジェクト（100 名以上のメンバー）、ある いは品質基準等が厳しい顧客とのプロジェクトをこなすことで、サブリーダーを通した間 接的なマネジメントや即断即決の重要性を学んでいる。次のプロジェクトマネジメント （P5）のコメントを見てみよう。 「マルチベンダーのプロジェクトなんですが、非常に厳しいお客さんで、ここはシス テムの能力の限界ギリギリまで使おうという。だから、システムとして余裕がない。 運用上何かあると大きな問題に発展してしまいます。だけどお客さんはそんなものは 許さない。こういうパターンのお客さんだから、品質だとか、作業品質だとかそうい うものが厳しいんです。 （中略）120 人、150 人になると隅々まで目は届かない。そう すると、間接的にやらざるを得ない。間接的にやるサブリーダーをどこまで信頼する か、サブリーダーがどこまで信頼できないかを押さえておかないと。それぞれのサブ リーダーの特性をよくみておかないとうまくいかないし、動かし方も違う。ガンと言 えばやる人とおだてないと動かない人もいるし、難しいです。まず末端までいくこと はないけど、サブリーダー、その下にいるくらい、先２段階くらいまで、いかに浸透 させるかが難しい、それをやらないとうまくいきません。」（P5） 一連のインタビューでは、30∼40 人の中規模プロジェクトと 100 人以上の大規模プロジ ェクトでは、管理の仕方が異なるというコメントが多く見られた。上記のプロジェクトマ ネジメントは、品質に厳しい大規模プロジェクトを経験することで、サブリーダーを通し た間接的な管理のスキルを習得している。 一方、失敗の経験から大規模プロジェクトの運営に必要なスキルを身につけたマネジャ ーもいる。あるプロジェクトマネジメント（P4）は次のように過去の経験を語っている。 160 「私が一番悩んだのは、ちょうど 40 歳ごろのことなんですけど。1 つのプロジェクト で大赤字を出しました。プロジェクトを管理することと、アーキテクチャどうのこう のということは全く違うなあと思いました。プロジェクトはどっちかというと軍隊で すよね。極端なことを申し上げますと、軍隊というのは、100 人殺すかわりに 1000 人 を救うだとか、ここの拠点を取るんだとか、そういう生死与奪権が将校に与えられて いると思うんですよね。プロジェクトマネジメントというのは、まさにこれだと思う んです。ここを躊躇したら全員死んでしまう、というんですか。お客様との間のやり 取りもですね、お客様の言い分だけを聞いたら、味方を殺してしまうことになります よね。そこをどうやるのかがプロジェクトマネジメントだと思います。で、そこの思 いっきりというんですか、これはアーキテクチャだとか理路整然とした世界ではない。 一種の戦争とはいいませんけども、そういう強い意志であったり、全体を組織として 統率するといううんですか、それは今までの話とは違うなあと。これで猛烈に苦労し てですね。2 年半かかったんですけど。ボロボロになってフラフラになって、正直あの とき、窓が開いていたら窓から飛び降りたかもしれないくらい精神的にも追い詰めら れましたし、つらかったというのもあってですね。そういう指示する指揮系統のヘッ ドに立つということは、いろんな人の思惑があるんですが、下にいる人に対しても相 当厳しい気持ちを持っていないといけないと、つくづく思いましたね。」（P4） このプロジェクトマネジメントは、大赤字となった大規模プロジェクトを経験したこと で、 「優先順位を明確にした上で、決断する力」が必要となることを学習している。必ずし も全てのプロジェクトマネジメントが失敗の経験をしているわけではないが、運営が難し い大規模プロジェクトを経験することで、各マネジャーは、プロジェクトマネジメントに ついての中核的なノウハウや知識を習得していると考えられる。 3.2.2 コンサルタント 表 3.3.8 コンサルタントが経験を通して獲得したスキル・知識・能力（熟達段階別） 初級レベル期 中級レベル期 上級レベル期 SE として部分的な仕事 小・中規模プロジェクトリーダー 大規模プロジェクトのリーダー 専門的職務（多様性あり） ゼロからの経験 困難な仕事 ↓ 一人で成し遂げた経験 ↓ 全体像の把握 ↓ 顧客コミュニケーション 現場感覚 業務知識、各種ノウハウ 論理思考、分析能力 161 コンサルタントは、初級レベル期段階において、SE としての部分的な仕事、あるいは特 殊で専門的な職務に従事した経験を持つ場合が多かった。サブリーダーとしてプロジェク トの一部を担当するという意味ではプロジェクトマネジメントと同じキャリアを踏んでい るといえる。これに対して、何人かのコンサルタントは、「CAD、CAM のマーケティング・ リサーチ」「大量データ解析」「海外の大学との共同研究」「外資系の会計事務所でのシス テム監査業務」 「販売物流システムの提案」といった専門的な業務を経験している点に特徴 がある。これらの職務を通して、コンサルタントとしての専門能力の基礎を習得すると同 時に、会社やビジネスの全体像を把握し、現場感覚を身につけている。 IT を使った業務提案をする業務コンサルタントの場合、SE の経験が重要になる。あるコ ンサルタント（C1）は次のように述べている。 「コンサルタントというと一人一人が自分のスタイルをだすので、私の今のコンサル ティングの仕事は SE の経験がなければありえない。落としどころは、経営改革という よりは戦略的情報システムをこういうふうに導入しなさいというほうだから。」（C1） 業務改革を専門とするあるコンサルタント（C5）も次のようにコメントしている。 「大学で多少、統計をやっていましたので。言語は実際にやっていました。自分でプ ログラムを組んだりやっていましたので、コンピュータということに対する違和感は なかったですね。当然、業務系だったので、昔でいうと、COBOL という言語だったで すね。人が作ったプログラムのメンテナンスをずっとやっていたんですけども。100 本くらいやったんで。そこで、そういう意味では、プログラムの構造の世界、改めて、 業務に関する知識みたいなものを身につけられたという感じはありましたね。もう半 年くらい、1 年以内の世界の話で。ユーザーの開発中のプロジェクトに入って、それの 最後の部分をずっとやっていたという感じで。」 （C5） 一方、初級レベル期段階から専門的な業務に従事するコンサルタントも多い。業務コン サルタントを経て、現在、経営コンサルタント（C6）をしている人のコメントを見てみよ う。 「フィールドのエンジニアでなく、ディシジョンサポートシステム（DSS）という特 殊なシステムエンジニアをしていました。DSS という MIT（マサチューセッツ工科大 学）から理論を導入して、アプリケーションを作って、自分でディシジョンサポート システムのソフトウェアを、クライアントの先へいって、どう導入するかというサポ ートを当社の中でやっておりました。15 年間、私がお手伝いしたクライアントは、ほ 162 とんどは経営企画部か、経理部の方であって、コンピュータ部門の人とは、あまりお 会いしていない。これは、大変、コンサルをする上で、役立っていること。もう 1 つ は、何でもやるわけではなくて、DSS という理論を、入社してからすぐ共同研究して こしらえたものですから、1 つの理論と実践を持ってると、自身が沸くわけですね。そ れは私にとって、大変良かったと。」 （C6） 次のコンサルタント（C8）は、大学院在学中に公認会計士の資格を取得し、外資系の会 計事務所で監査をおこなった経験を持っている。 「5 年間、公認会計士として大手企業の監査をしました。監査は全体が見えますから、 売上から費用まで。全体を見て、色々な企業を回ったという経験が 5 年あります。そ の経験をベースに、『会社とは何なのか』ということが分かって、 『何でこういうやり 方なのか』ということが疑問も含めてわかるわけですね。」 （C8） 中級レベル期では、多くのコンサルタントが、小・中規模のプロジェクトリーダーとし て、未知の課題を自分の力で乗り切るという経験を通して、業務知識や各種ノウハウを習 得している。ただし、この時期にコンサルティング業務を経験している人は少なかった。 小売分野の業務改革を専門とするコンサルタント（C5）は次のようにコメントしている。 「その当時は、小売、流通関係というのは、お客様自身とまさに一緒にやれるという 環境の中でやりましたね。技術的な世界はそうなんですけど。お客様によって、技術 だけやってという場合もあれば、アプリケーション開発一緒にという場合も。アプリ ケーション的には、百貨店さんなんかで、「友の会」というようなシステムをやりまし たね。あれをリアルな仕組みで立ち上げたときに、リアルオンラインで立ち上げたと きに、まさに 1 からやったという感じですね。」（C5） 現在の職につく前に小さなソフトハウスに勤務していたコンサルタント（C7）は、次の ような経験をしている。 「顧客の要求が厳しかったというよりも、今まで誰もやったことがないことをしなけ ればならないというのが大変でした。今だったら、ネットワークでパソコンをつない で色々な業務をやるというのは当り前ですが、当時は、メインフレームでやっている ことを UNIX マシンを LAN でつないでやるなど、プログラムの作り方からして全然分 からなかったのです。本を読んで理解できても実際にやるのは難しいですから、皆手 探りでした。結果として、机上で『こういう風にやればいい』と色々考えたことを、 163 このような形で実践できたということが技術的面での自信になりました。それから、 プロジェクトをまとめるということ、お客様と話をするということが身につきまし た。 」（C7） 上級レベル期においては、大規模プロジェクトあるいは困難な仕事を経験することで、 顧客と深くコミュニケートする能力、論理的思考能力、分析能力を学習している。あるコ ンサルタント（C2）は次のようにコメントしている。 「SE の数だと当社よりも多いかもしれないという大手情報サービス企業の人材開発コ ンサルティングを行いました。基本的にはコンピテンシー・モデリングですね。 （中略） 人材開発の仕組みや推進組織だとか、そういったものをどうやって設計するのか、具 体化するのか、それをどう定着化させるのか、そういうところの新たな経験をしまし た。しかも、広い範囲の動きにしようとするトップの思い入れをどう無理なく実現し ていくか、ライン部門のハイパフォーマーをどう巻き込むかとかを、前面に出て色々 やらないといけない。役員層を含むステークホルダー・マネジメントだとかですね。 また、より目に見えない世界に踏み込んでいきますので、論理的思考力というのが非 常に大切でした。それとコミュニケーション力の組合せの重要性も痛感しました。単 なる意思疎通力ではなく、ビジネスマンとして筋の通った、腹に落ちる話として合意 できるかというコミュニケーション力です。どうすればそういう論理的思考力が発揮 された合意形成や成果物になるんだということが描けたかなと思います。」 （C2） このコンサルタントは、大規模なコンサルティング業務を経たことで、顧客に深く入り 込み、役員層を巻き込んだ説得スキルを習得している。次のコンサルタント（C7）は、失 敗の経験を通して、コンサルティング提案のあり方について学習している。 「情報システム基盤を作るのに、コンサルが必要だというんで、何人かまとめて入っ たんですよね。私一人で入ったんではなくて、チームで入ったんですけどね。ところ が、政治的なことが、いろいろごたごたあって、何か、当社が入るということは、ト ップの方で決まってしまってて。 （中略）現場がやはり納得してなかったんですよね。 で、当社の方法論というよりも、自分たちが今まで○○社から学んできたほうのがい いというのがあったらしくて、あれこれとケチをつけるというか。そういうやり方で はおかしいとか。やはり、コンサルというのは信じてもらわないと困るので。（中略） それから先のとりまとめを、こういうようにしようかな、と思ったときに『あなた外 れてください。人を変えないと、お客様が納得しないから』ということで、私が抜け て、違う若い人を入れて、向こうのやり方に、はいはい、そのとおりにいたしますと 164 いう形にしちゃったんです。こっちのやり方というのを一切出さないで。お客様にあ わせて、カスタマイズして進めますという形にして。これは私にとって非常に勉強に なりましたね。技術だけではない色々なお客様との関係の案件が増えてくるとコンサ ルはますます必要になってきます。最初の売り込みのときに、いかにしていいアピー ルをするかを考えるのは当然ですが、入ってから先にどうやってそれをうまくやって いって信じて頂けるか、これが大切ですよね。」（C7） こうした経験は、コンサルタントとしての姿勢やあり方を考え直すきっかけとなったよ うである。同じコンサルタント（C7）の次のコメントを見てみよう。 「だからコンサルティングをするというときにも、一貫して、『こういうのをやる』と いうのを貫き通さなければいけないと思いました。お客様が、違う人を連れて来い、 と言ったからといって、 『ハイハイ』とやっていると、やっていることの一貫性が全然 なくなるし、そうすると、当社は何をやっているのか、と結局は言われてしまうとい うことですよね。（中略）やはり、コンサルティングの手法なり、技法、私の場合は生 産技術の技法ですが、こう言ったものは、こだわってやる、フラフラさせてしまって はいけない、ということですね。それから、チームでコンサルを行う場合、例えば生 産技術をコンサルするグループの場合であれば、個人が仕切っていくやり方よりも、 むしろ、生産技術のツールのようなものを作って、それをベースにお客様にコンサル ティングしていく、そういうやり方の方が、バラつきがなく、品質のよいものになる ということが分かりました。方法論、ツールといったものを固めて、 『これプラスコン サルティングをご提供します』という形に変えたんですね。それで失敗が大分なくな りましたね。」 （C7） 上述した 2 つの事例は、コンサルタントにとって、顧客企業内の関係者をとりまとめて 合意を作っていくスキルが重要になることを示している。 165 3.2.3 セールス 表 3.3.9 セールスが経験を通して獲得したスキル・知識・能力（熟達段階別） 初級レベル期 中・上級レベル期 SE としての仕事 厳しい顧客 プロダクトアウト型の営業 海外経験 ↓ 殻を破る経験 営業の基本を習得 ↓ 会社全体の把握、ソリューションノウハウ、顧客との関係 セールスは、初級レベル期において、2∼3 年の SE 経験、あるいはプロダクトアウト型 の営業活動に従事することで、IT に関する基礎知識あるいは営業の基本を習得していた。 次のセールス（S3）は、SE としての経験が現在の提案型営業に活かされていると述べてい る。 「入社当時はホスト全盛期だったから、配属されたのがプログラムを設計する部門に 3 年くらいいた。SE とシステムエンジニアの 1 つ手前をプログラムエンジニアと言っ ていた。業務は知らなくていいということで、仕様書ができてきたら、それに従って IN と OUT があって、プログラムを作るという仕事。お客さんと接点をもって落とし 込むという仕事がシステムエンジニア、SE ということで 2 年くらいやった。（中略） 現在は、提案の前にレビュー会というのをやるが、そこでわからないというわけには いかない。営業という立場でも。そうでないと営業の提案に開発もついていくが、聞 かれたときにわからないということではお客さんも不安になるだろうし。」 （S3） 現在、グローバルに活躍しているセールスは（S4） 、初級レベル期段階の業務とそこから 得たスキルについて次のようにコメントしている。 「実は、私はずっと営業をしてまして。当初配属されたのは、国内関係の営業で、東 京で、そこに 8 年おりまして。 （中略）8 年間での仕事の進め方ですとか、いろんな契 約に関する行為だとか、法律だとか、そういうのはいろいろと勉強してきましたんで、 非常に役に立ってるし、いまだにその方たちとは、お付き合いも続いてるから、人脈 的に、非常に財産になってると思います。」 （S4） 中・上級レベル期では、厳しい顧客と付き合ったり、海外における経験によって、会社 全体の仕組み、ソリューションノウハウ、顧客との関係作りについて学んでいる。次のセ 166 ールス（S1）のコメントを見てみよう。 「○○社というところがありましてね、あちらを 12 年間担当してました。あちらは、 日本の製造業の中でですね、デミング賞とか、品質管理賞とかを、ばんばんに受賞さ れるお客様で。 （中略）お客様は、日本品質管理賞を受賞するための活動をやってまし たけど、情報システムのほうは、3 月から 9 月まで、お客様の部長様のほうも時間がな いわけで、土日をフルに使いまして、一日も休むことなくずっとやりまして。私はそ のときに、8 社か 9 社くらい、お客様を担当してまして。他の部品メーカーさんもね。 結構苦しい局面もあったんですけど。このときに、このプロジェクトをやることによ って、会社の中の、業務文書までみんな書き直したわけですからね、それからプロセ スをみんな整理清算しました。（中略）本当にここで、会社の仕組みと会社の機能と、 問題点と、いろんな関係性みたいなものを勉強させていただいて、私の今のほとんど のものが、○○社で教えていただいたものだと思っています。○○社で教えられたこ とが、本当に今のセールスマン、IT に携わっている人間としての、ほとんどのものを 作ってもらったと思っています。（S1） このセールスは、日本品質管理賞をめざす顧客企業とともに仕事をすることを通して、 「会社の仕組みや機能」について学んでいる。次のセールス（S4）は、経営層との関係づ くりがきっかけになって、営業に対する意識が変化したと述べている。 「1 つは、国内にいて主任前の私は、○○商事さんのトップの方々と名刺交換は、なか なかできませんでしたね。その殻を破いたのは、当時の副社長がお見えになったとき に、名刺交換をさっとしてしまった。当時、向こうは副社長でしたから、私は主任レ ベルで・・・そこで、さっとできたことが、私の転機になりました。それから後は、 その副社長と名刺交換できたんだから、たいていの企業のトップとの名刺交換もでき るだろうと。そういう風に思って自分の役職が上がっていけば、上の方とお会いする なんて、非常に楽になりました。（中略）今まで仕事をやっているというよりは、私は 毎回高度なビジネスゲームをやっている感覚が大切だと思っています。失敗をその次 のビジネスの糧として、それを取り返せればいいんじゃないか、と思っています。」 （S4） こうした「殻を破る」体験を通して、このセールスは、顧客企業の経営陣から情報を収 集し、提案することができるようになったという。次のコメントも見てみよう。 「トップの方の方針を知るには、その方と面談するのが一番早いんだと思うんですね。 167 下にその案件を落とされるまでには、もやもや悩まれることが多いですね。自分でク リアにするまでは、あまり下に落とさない方が多いので。方針や悩みを先に聞いてし まうということは、先に自分たちの作戦が練れるということで、次じゃぁこうしまし ょうとか、こんな風にしたらいいんじゃないですか、とか、先に言うようにしていま す。 」（S4） 3.3 各社における人材育成 これまで、高いレベルのスキルを持つ IT 技術者のインタビューを通して、各職種におい て「どのような知識・スキルが必要となるのか」 「その知識・スキルはどのような経験を通 して獲得されたのか」について分析してきた。これに対して、本項では、 「各社において、 若手・中堅の技術者がどのように育成されているのか」を検討する。 分析にあたっては、インタビューデータを「人材教育の方法」「コミュニティ活動」 「ナ レッジデータベース」 「仕事の進め方」 「評価制度」 「組織体制」 「人材育成の問題点」に分 けて整理した。 3.3.1 人材育成の方法 表 3.3.10 人材育成の方法（職種別） プロジェクトマネジメント コンサルタント セールス やらせてみる(5) 同行(2) 実践の中での育成(2) 絞り込んで育成(2) 環境作り(2) ケースメソッド(1) 熱心な上司につける(3) やらせてみる(2) ケースメソッド(2) 小規模案件の経験(1) 定量分析の教育(1) ケースメソッド(1) 書籍・論文の執筆(2) 人材育成方法の中心は、 「やらせてみる」に代表されるような実践の中での育成である。 ただし、ハイレベルな IT 技術者は、若手技術者を放任しているのではなく、「熱心な上司 につける」 「同行」 「環境づくり」といったように、様々な点に配慮しながら育成していた。 「ケースメソッド」は、実践教育を補足し、短期育成のために使われていた。書籍や論文 を執筆することがコンセプトを整理し、論理的な思考を磨くことは、コンサルティング能 力を高める上で有効である。以下では、具体的なコメントを紹介する。 「早い時期にプロジェクトリーダーを経験させるべきか」という問いに対して、あるプ 168 ロジェクトマネジメント（A2）は次のように述べている。 「できれば、早いほうがいいと思いますが、ケースバイケースですね。プロジェクト リーダーというのは、責任も重いじゃないですか。また、プロジェクトの規模にもよ ります。早いうちから、経験すればいいんですけども、あまり無理にやらせると、ひ ずみがくると思います。できれば、20 代のうちに、10 数人くらいのプロジェクトを回 して、30 代くらいになってきてから、もう少し大きなプロジェクトにしていったほう がいいと思います。 （無理にやらせると）ある意味、自信を失ってしまうとか。だけれ ども、マネジメントだけに徹すると、あまりにも技術がない。実際に大きくなると、 協力会社さんにお願いをするじゃないですか。そこに対してのつっこみもできないし、 お客様に対しての説得もできなくなってくる。協力会社さんを動かすのは得意なんだ けど･･･というマネジャーさんも、結構いたりしますから。私は、それはまずい現象だ なぁと思いますので。技術をつっこみながらマネジメントしていかないと、真の意味 でプロジェクトマネジメントができない局面もある。」（A2） このコメントにあるように、無理な形で仕事を任せると「ひずみ」がくるという。小さ いプロジェクトから大きなプロジェクトへ徐々に難易度の高い仕事を経験することにより、 技術とマネジメントのバランスをとることができるようになるのである。次のコンサルタ ント（C9）も、段階的に職務の難易度を高めることの重要性を指摘している。 「今できる仕事の、難しいところですが、10%∼20%くらいの無理があって、仕事をさ せる。もちろんフォローはしてですけど。（中略）優秀な有能なプロジェクトリーダー は、本当に少し上の仕事を与えられるんですよね。プロジェクトリーダーがしっかり してないと、その人のスキルを把握できていなかったら、ミスマッチになりますから ね。 （中略）非常に申し訳ないんですけども、たまたまついた、プロジェクトリーダー によって、成長に差は出ますね。反面教師という教師もあるという・・・。まず、自 分が疑問を抱け。あのようにならないためには、どうしたらいいか。 （中略）もちろん、 OJT は、アビリティをあげるための大きな機会だと思いますけども。さっき言ったよ うに、できる仕事をやらせていても、全然あがらないんで、ちょっと背伸びさせるよ うな仕事を与えなきゃいけないんですけど。それは、置かれた環境によって、非常に 難しいんですが。」 （C9） 技術者の能力より 10∼20%上の難易度の仕事を与えることが人材育成にとって重要とな るが、そうした仕事を与えることができるかどうかは上司の資質にも依存している。次の プロジェクトマネジメント（P7）は、新入社員を、意図的に教育熱心な上司につけるよう 169 にしている。 「当社の場合。新人は全部モノづくりから始める。 （中略）見てますと、その人たちが、 2 年経ち、4 年経ち、5 年経つと差が出てくる。この差は何かというと、上司の問題。 その配属された上司が育成とかに熱心な上司と、そうでない上司の下についた人は、 同じ会社に入社しても差が出てくる。入ったのは同じくらいだったから入ったのだろ うけど、差が出てくる。そこで私が思ったのは、皆一律に配属をばらまかない。そう いう熱心そうな部長がいるので、そこにまとめて、例えば 16 人入ってきたらここに 8 人、ここは 4 人、3 人くらいとか。そういう優秀なというのではなく、育成に熱心なと ころに入れるというのが 1 つの方針。もう 1 つは、私は自分の経験がそうだったから しないけど、一部そういうのがあったのは、いきなり当社の本体に入ったんだから、 マネジメントをやらせるんだということで、モノも作らないで報告書を書かせたり、 そういうことをやらせていた。私は全部そういうのはやめて、先ほど言った本体とか、 ＳＥ会社とかありますよね。そこに入れる。顧客のところに入って、そこで 2 年でも モノづくりとかそういうことをやらせる。新人はそういうふうに考えている。」 （P7） 中堅以降も、どのような職務を経験するかがコンサルタントとしての能力開発に大きく かかわっている。次のコンサルタント（C8）のコメントを見てみよう。 「経営コンサルタントで大、中、小と分けるのは私は持論で間違っていると思ってい る。大企業ノウハウは中小企業でも使えるし、中小企業のノウハウは、大企業でも使 える。どこが違うかというと規模が違うから、情報の共有の仕方とか情報システムの 大きさとか、データベースの大きさとか、そういうものは違うけど、経営の本質は同 じですので、使えるはずなんです。それを使えるようにしてあげるのが、経営コンサ ルタントです。 （中略）コンサルティングは、相手に同じことやっても、相手は 1 銭も 払いませんから。いつも新しいことをやらなければならない。とういうことは、コン サルタント自身が、いつも革新しなくてはならない。情報をいっぱいとって一生勉強 しなくてはならない。そのため、今、大中小の話をしましたが、大のノウハウを持っ ているコンサルタントは、小に対して別のノウハウを使えるわけでしょ。小でも大で 使えるものもあるから。そうすると、小としては驚くわけ、 「あ、こうやるといいんだ」 って。小しかやっていないコンサルタントは、それがわからないから使えないわけで すよ。大しかやっていないと大しかわからないでしょ。小のなかでも素晴らしいやり 方があるから。そうやって、『こういうやり方があるんでしょ』『あぁそうか』ってな るわけですよ。」 （C8） 170 こうしたコメントに見られるように、経営コンサルタントの場合、たとえ高いレベルに 達した後であっても、小規模な案件から得られる情報は貴重である。 次に、若手や中堅技術者の短期育成が重要なポイントになっている現状を考えると、「や らせてみる」教育だけでは不十分である。この点を補うために、3 つの職種すべてにおいて、 ケースメソッドを応用した教育が行われていた。あるプロジェクトマネジメント（P5）の 次のコメントを見てみよう。 「昔は失敗した。その中から色々経験して、学習できるひとは学習してブラッシュア ップしてくると。そういうプロセスはたどれた。最近はそうはいかないところもある。 プロジェクトマネジメント、確かにピンボック（PMBOK）だとか本も、指針もあるが、 それだけではうまくいかない。やはり実際の場面でどういうふうに判断して行動する かというところが重要。そうすると OJT しかないのかという話にいってしまうが、そ れぞれ個人が携われるプロジェクトの数というのが限られているところがあり、そこ をいかに補うかという話になる。ケーススタディを豊富に用意して、経験できないと ころはそれで補っています。実際のプロジェクトが 1 年、2 年、5 年になっていく。そ の中で色々経験できるのはそうだが、非常に偏った、限られたものになってしまうの で、事例を中心にした疑似体験をさせて、そこでどういう判断、行動をするかという ことを体験することが重要だと思う。それを短期間に実施し、促成栽培をしていかな ければならない。」 （P5） あるコンサルタント（C9）も、現場における人材育成を補うために次のようなケースメ ソッドを導入している。 「私の方で、IT コーディネーターのプログラムで使われるトレーニング用のマニュア ルというのを作ったんですよ。それは、どういう組み立てになっているかというと、 課題集というのがあって。ある A というバーチャルな会社があって、それがどういう 組織があって、どういう人間がいて、組織のダイナミクスはどうなっている、誰と誰 が仲がいいとか悪いとか、そういうことをいっぱい書いた資料集があって、それに課 題がついてるんですね。プロジェクトを起こしなさいとか、こういう悩みを抱えてる から、起こしなさいとかやって、課題に対して、解答を書かせて、その解答例を示し てやって、進めていくという。あるシナリオを分析しながら、ソリューションを提供 していくというような、そういうプログラムなんですね。（中略）セミナーで、バーッ と黒板に向かってしゃべってというのは、ダメなんですね。やはり、ケーススタディ で、自分が作業をして、後で何か代表的な解答が示されてですね、えらい違ってると、 こっちのがいい場合もあるんですね。そういう風にして、次のステップに進んでいく 171 と。大体、20 課題ぐらい出ていて、1 課題を、5∼6 時間ずつかけてやっていくという。 特にその中でには、財務分析とかいうのもあるんですけどね。誰と誰が非常に仲が悪 いとかですね、その人の語りとして、不平不満を言っている人とか、断片的にわざと 書いてあるんですよ。体系化されずに。そこをしっかり読みきって、プロジェクトの 構成は、これを入れとかないとまずいね、とかそういうものなんですけどね。（中略） 本当は、コンサルタントは、それじゃダメなんですよね。だから、今作ろうとしてる のは、開示レベルを分けようとしてるんですよ。非常に上級な、レベル 5 くらいの人 になると、もう会社名しか見せない。必要なことがあったら、聞けと。聞ける能力が なかったら、ダメなんですよね。全部資料集を見せてしまったら、1、2 年生はそれで いいんだけど。だから、資料集にするところまで、自分がヒアリングできるかどうか っていうところが、ものすごく重要なところじゃないですか。」（C9） 3.3.2 コミュニティ活動 表 3.3.11 コミュニティ活動（職種別） プロジェクトマネジメント コンサルタント 認定者中心のコミュニティ(3) 共有の恥ずかしさ(1) スペシャルインタレストグルー 同一化の障害(1) セールス プ(1) 共通技術ワークグループ(1) いくつかの企業では、同様な技術を持つ仲間からなる「コミュニティ」活動を実施する ことで、プロジェクトマネジメント間の情報・知識の共有や、人材の育成を促進させてい た。ただし、会社によっては、情報や知識を共有することを恥ずかしがるケースや、情報・ 知識の共有によってメンバーの行動が同一化してしまうという危険性も指摘された。 社内のコミュニティ活動について、あるプロジェクトマネジメント（P9）は、次のよう に語っている。 「プロフェッショナル認定された人は、コミュニティ活動に参加できるというコミッ トメントを持つことになってます。それ以外の人も、自主参加できる。会社が長いも ので、システム関係でも、いろいろ事業部がありますね。金融関係とか。事業部の中 で、コミュニティ活動を、結構やってます。それは、プロフェッショナル認定とかあ まり関係なくて。どういう分野に興味があるか。プロマネなのか、IT アーキテクチャ なのか。いくつか分野を設けて。そういうのの、横断的、全体的なコミュニティを、 プロフェッショナルメンバー中心にやってる形です。仕事が終わった後に、車座ミー 172 ティングというのをやったんですけど、コミュニティの中でもそういうことを始めま した。我々が 2 人くらい、プロマネさんが 5、6 人の 10 人弱くらいのメンバー。自分 のプロジェクトで、どういう問題があるとか、会社の仕組みのこととか、何でもいい から、思うことを話してもらって。そういうことに対して、アドバイスしたり、とい うことを始めてるんですね。それは、結構、いいですね。それは、事業部をまたがっ た全体のコミュニティでやってますので。いろんな業種の人が入ってきます。会議室 で、座って、議題があってやるのとは、違うんでしょうね。話しやすい・・・皆も、 自分が思っている問題というのを、言える場というのが欲しいんでしょうね。一方的 に聞くだけじゃなくてね。 （中略）視野が広がるというのもありますし、上の人からア ドバイスをもらうということも喜んでるし、問題を上の人にあげたいという気持ちも あるでしょうし。両面、効果があるというか。」（P9） 同じ会社に所属するプロジェクトマネジメント（P7）のコメントでは、 「情報化されたナレッジ、Web だとかナレッジマネジメントシステムでプロジェクト ウエブとか仕組みがありますが、本当にナレッジが伝わるかというと難しい。それは 専門別に、プロマネをめざしたいとか、アーキテクトをめざしたいとかそれぞれの人 たちに、最終的には Face to Face じゃないかという面がある。人間が直に伝えないと ナレッジというか、思いは伝わらない。それを部門毎にやっている。部門サイトで、 事業部だとか、部門毎に自分の部門で経験したことは完璧ではないにしろ伝える。当 社全体的に見ればそれを伝える場というのは色んな場を使ってコミュニティをつくる とか。コミュニティという言い方はしなくても、経験者がじかにその内容やプロセス やバックにある思いを伝えるということはやらないとなかなか伝わらない。データベ ースに入っている情報を使えばいいというだけだと、それは形式化された事例である とか、提案書とかそういうことが出てくる。だから、○○さんのプロマネの思いとか をコミュニティでしゃべると。他の人もしゃべると。話が全然違ってもかまわない。 その人たちが本当に思っていることを、自分の肉声で伝えるということが重要だと思 う。 」 （P7） このコメントにあるように、生の経験や価値観は、形式化された情報を蓄積したデータ ベースを通しては伝えることができない。こうしたノウハウについては、コミュニティを 通して、Face to Face で共有することが重要となる。先ほどのプロジェクトマネジメント （P9）は、Web 等による情報共有との関係について次のように述べている。 「Face to Face じゃないと、今みたいなコミュニケーションの場が、難しいんじゃな 173 いですかね。コミュニティでも Web を立ち上げてやってます。いろんな情報を得る。 コミュニティ活動でも、PM の技術を整備するために、いろいろアウトプットの資料だ とかあるんですね。そういうのも登録してあるわけで。情報を得るというのには、有 効です。コミュニケーションして、問題をぶつけ合う、共有するというのは、Face to Face じゃないと難しいのかなという気がします。 （中略）Web でやるのと、Face to Face でやるのとは、若干目的が違うような気がしますね。情報を共有するためには、有効 なツールですし、一方は、問題を共有するとか。両方使うのが、相乗効果があってい いと思います。」 （P9） ある会社では、コミュニティ活動を制度化し、グローバルに展開している。あるプロジ ェクトマネジメント（A1）の次のコメントを見てみよう。 「コミュニティ活動っていうことで、○○というのが運営されてるんですけど。そこ の中で、SIG というのを立ち上げまして、これはボランティアなんで、ボランティア で何でもやっていいかというわけではなくて、業務に関係あるものを取り上げて、い ろんなことをやるグループがあります。そこのリーダーとか。発案者とか。そういう のもやってます。B to B の SIG というのを、リードしてるんですけど。それも月 1 回 くらい。Face to Face というのもできますから。できれば、リコメンデーションを社 内に発信したいというのが目的ですよね。最新の SIG なんかでは、グリッドとかフロ ーみたいなところでやっていたときもあったし。スペシャリストだけでなくて、開発 部門もですね、ハードウェア開発するところ、ソフトウェア開発するところ、という のが一緒に集まって SIG というものを形成してますので。そういう意味では、部門を 越えて活動している、世界中に認められている、そういうのに参加・・・これは必須 に近いですね。後、当社の中でですけど、ワールドワイドのさらにコミュニティとい うものが、いろいろなものが出てきてまして。」（A1） 3.3.3 ナレッジデータベース 表 3.3.12 ナレッジデータベース（職種別） プロジェクトマネジメント コンサルタント データベースを活用(3) データベースの活用少ない(2) データベースの問題・課題(3) 考えなくなる(1) セールス データベース活用少ない(2) KM の専門チームあり(1) すべての職種において、ナレッジデータベースは存在していたが、積極的に活用されて 174 いたとはいえない。 「体系化が必要」 「忙しくて活用しにくい」 「知識を伝達することが難し い」 「自分で考えなくなる」といった問題点・課題が指摘された。 あるプロジェクトマネジメント（A2）は、知識を整理・体系化することの重要性につい て次のように述べている。 「ノウハウの源泉は、うちのファイルサーバーなんですよね。いろんなノウハウがあ りますが。なかなか、若い人が、体系化することがない。自分なりには、体系化する んですけど、組織として体系化することがない。体系化のほうは、私がやっているよ うなことがあります。皆のノウハウを集めて、自分の過去の経験もありますから、そ れでベースを作って、いろいろ吸収させて、大体のものを作って、逆に落としてとい う、やり方をしてます。 （中略）体系化しなくても、やることはやるんですが。どうし ても漏れが出るじゃないですか。私は、プロジェクトリーダーで、頭から面倒を見た こともあって。ある意味では、アプリケーション構築の中で、どうすべきかというで も観点がありますよね。当社でも、そういう方法論を持っているんですが、皆さん、 意外とそういうことを整理しないので、そこを私が作っているという感じですか。本 来なら、体系化したものを、教育しなくてはならないんですが、まだ作ったばかりな ので、下にも落としきれてないということがあります。」 （A2） このコメントにあるように、技術的ノウハウをサーバーに集めるだけでなく、それらを 使いやすいように体系化することが重要になる。 ある会社では、プロジェクト終了後の報告書のデータベース、およびプロジェクトマネ ジメントのためのホームページを構築している。あるプロジェクトマネジメント（P11）の 次のコメントを見てみよう。 「１つは、プロジェクトアーカイブを充実させようと思ってまして。プロジェクトが 終わるとプロジェクト完了報告書というのを書いてもらうことにしてます。それは、 かなりのものが今蓄積されているんですけど、これは我々の課題なんですけど。プロ ジェクトアーカイブを検索する仕掛けですね。いろいろキーワードをつけたりなんか してるんですけど。もう少し充実すると、自分が参考にしたいプロジェクトに行き当 たると。そういったものの充実を図っていきたいなと思っています。大きなものでは なくて、小さな検索、ちょっと聞きたいみたいなものは、我々が作っているホームペ ージがありまして、そこにプロジェクトマネジャーフォーラムという広場みたいなも のを持ってまして。そこに自由に書き込みができるというのを持ってまして。そこに、 知りたいことを書き込んでもらって、それに対して先輩が答えると。そういうような 仕掛けを作っています。そうはいっても、非常に忙しい人に書き込んでも前向きに回 175 答してくれるかというと、必ずしもそうではないので、我々がそこを 2 日 1 回とか覗 いてまして、我々がやったことは当然答える。後、答えるよりも、あの人がいいなと いう人がいれば、その人に答えをお願いするとか。そういう取り組みをしてまして。 」 （P11） この会社では、プロジェクト報告書を検索するしくみが課題となっている。また、マネ ジャー間の質疑応答のフォーラムを機能させるためには、必要に応じてナレッジオフィサ ーが介入し、調整することがポイントとなる。 ある会社では、情報・知識を提供しやすくするために、情報提供に対してインセンティ ブをつけている。しかし、日常的な忙しさのために、ノウハウの蓄積が思うように進まな いという。 「ナレッジベース、ナレッジデータベースで、その中で中身を、入っているコンテン ツを大きく 2 つに分けてですね、メソッドとノウハウっていう風に分けてるんですね。 メソッドというのは、普遍的で、ある程度正規化された、そういったようなもので。 ノウハウというのは、非常に混沌としていて、流動的な。しかしどっちも、上げてこ ない。どっちも上げてきて、メソッドをメンテするのは、それなりのマスターが、ち ゃんとアドミニストレーター的な人がですね、メソッドというのはメンテして。で、 ノウハウっていうのは、どんどんどんどん入れてきて、フリーに。で、使えるノウハ ウは、皆が参照してきますね。参照していったアカウントとかを、誰のが一番参照さ れてるかということを出すことによって、またインセンティブが上がって、またポイ ント入れてくるんですよ。 （中略）ただ、プロジェクトがものすごく忙しくて、葛藤の ある日が迫ってるんで、ノウハウを入れてくれ、といってもなかなか入れないんです よ。いちおう、○○研究部では、業績評価の中に、ノウハウの蓄積というのを義務付 けていて。それは紙で書いたといっても、全く点数化されなくて、シンキストに、ア プローチしましたといったら、評価してやる、という風になっていて。上期の締めと、 下期の締めのときには、どんどんどーんと入るんですね。継続的に入れるというのは、 忙しいんでね。顧客で作業してるでしょ？皆さん。で、疲れた体で帰ってきてね、入 れるか、って言ったら、入れないですよ。」（C9） この会社では、情報を上げやすくするために、次のような工夫もしている。 「基本的に、あげやすくするために、どういうその・・・例えば Word で入れてもいい し、Power Point で入れてもいいし、そういうもので入れて、添付で入れるような、そ ういう形にしてあります。そうじゃないと、こういうような形でやれ！というと、も 176 うあげないんですよ。今、自分が何かのために作って、たまたまある、これをポッと 入れるんだったら、入れましょう、という感じです。改めて、このような形に、と指 定するといやみたいですね。」（C9） ナレッジマネジメントを浸透させるために、ある会社のコンサルティング部門では、若 手中心のボトムアップ方式を採用し、成果をあげている。 「ナレッジマネジャーという人と、ナレッジ伝道師という人を作っているんです。マ ネジャーは、部長なんですけどね。だから、見てるだけというか、いちおう、変なの が入っていたら、チェックするということはしますが。伝道師というのが、割と若手 の人なんで、その伝道師がいろいろ文句を言ってもいいし、それからいろんな人の文 句を聞いて、マネジメントシステムに反映させるという役目なんで。そういう人が、 だんだん盛り上がってきて、どんどん入れようということで、入る数も多くなってき てますよね。（中略）どうもトップダウンで、最初の頃は、入れなきゃいけないという ようなときには、そっぽを向いていて。伝道師という若手の人が入ってきて、皆の意 見を入れたりすることによって、だんだん盛り上がってきたという感じ。ボトムアッ プというのが成功したのかなと思いますけどね。」 （C5） このコンサルタント（C5）はまた、ナレッジデータベースの弊害として「自分で考えな くなる」という点を指摘している。 「当社は、比較的最初から手がけていたんですけど。ソリューションパックとか、お 客様の事例集のデータベース化、基本的には知識、データベースみたいなものを作る、 それからプロジェクトの進み方の世界のプロジェクト Web という、プロジェクトマネ ジメント用の共通して見れる環境を作る。それを実践で、登録して作っているという 感じですね。似たようなプロジェクトがあれば、それを見れる環境にしているという。 私の持論からすると、さっきの考えなくなる世界なので、効率化というキーと、考え なくなるということを、どうやって折り合いをつけるというのが非常に難しい。難し いという表現をしてはいけないのかもしれませんが、自分でそういう風に思っていれ ば、見るのは全然かまわないと思うんです。見て、鵜呑みにするなというような話だ けを、同じようなプロジェクトでもお客様は違うわけですから。」 （C5） 177 3.3.4 仕事の進め方 表 3.3.13 仕事の進め方（職種別） プロジェクトマネジメント コンサルタント 開発手法を標準化(1) メソドロジーの開発(4) チェックリスト(1) 標準化づくり(1) セールス ナビゲーションシステム(1) プロジェクトマネジメントやコンサルタントの間では、仕事の進め方を標準化するとい う試みが行われていた。あるプロジェクトマネジメント（P4）のコメントを見てみよう。 「開発の手法だとか、改めて、標準化しようという動きがあります。まだ、去年くら いから、全体のプロセスとは本来どうあるべきなのか、ということをデザインしてる んですけども。手法、技法をまず 1 つにしてみようと。良い悪いは別ですけど、1 つし かなかったら、他との比較というのはなかなかできないと思うんですけども。いくら でも情報は取れるわけですよね。今、何か 1 つ覚えたら、応用がきくと。私は、物事 を判断したり、まとめるというときに、やりやすいんじゃないかと思うんですね。自 信を持っている独自の方法があるんだったら別ですけど。それは、思いつきベースの やり方だと思いますから。まずは、物の考え方の原点というものを覚えて、それを使 いながら議論するというんですか。 （中略）技法といいますと、画一化されてしまうの かと思いましたが、そうではなくて、原理原則みたいな本質的なところでの技法とい うことですよね。そこへ、導きやすくしてやるために、ツールというのを利用すべき だと思うんですよね。」（P4） この会社では、これまで個人に任されていた開発の手法を標準化する試みが行われてい る。注目すべき点は、標準化された開発手法を「本質を見るためのツール」と考えている 点である。 別の会社では、開発に関して独自のナビゲーションシステムを整備している。 「ナビゲーションを行うシステムを持ってまして。そういう中で、お客様の要件を整 理するためのフォーマットでありますとか、そういうときにどういう点に注意してい けばいいかとか、そういうナビゲーションのシステムになってます。パソコンに向か って入れるとですね。ナビゲーションですから、非常に標準的なものなんですけど。 こういう段階では、こういう帳票を使ったらどうですかとか。こういうときにはこう いうことをやったら、どうですかとか。そういう suggestion＋ワークシート＋流れ、 178 プロセスというものを中に入れておきまして、支援するような仕掛けになっています。 なかなか問題に追われてしまうと、そこを開けてみようという気持ちにもなれないと きもあるので、そこは繰り返し繰り返し、これを使ったらどうですか？ということを 紹介したり。中を我々がブラッシュアップしてますので。ブラッシュアップしつつも、 PR してですね。こういうところが良くなってますよとか。（中略）経験している人で も、新しい問題にぶつかったら、ちょっと見てみようかと。」 （P11） コンサルタントの場合には、コンサルティングのノウハウを「メソドロジー」という形 に落とし込むことで業務を効率化するとともに、ナレッジマネジメントをおこなっていた。 あるコンサルタントは次のように述べている。 「現時点では我々は、市場から見たコンサルティングのブランドイメージがあまり強 くありませんので、何ができるんだということを全部メソドロジーにして明示してい ます。メソドロジー、実績、命題に対する進め方、どういうアウトプットを出すとい うことを具体的に示すというやり口です。（中略）ただ、プロフェッショナルは必ずし もメソドロジーのみには依存していません。漠然とした命題であれば、まずはコンサ ルコアスキルのみで進んでから命題を整理する。あるいはメソドロジーを組み合わせ る、あるいはメソドロジーを開発する。上位グレードの人間はそういうことをやって います。 」 （C2） このコメントにあるように、メソドロジーの開発は上位レベルのコンサルタントが持つ ノウハウを標準化し、組織としてのスタイルをアピールしていく狙いがある。次のコンサ ルタント（C7）が属する会社でも、同様なスタンスで、既存のノウハウをメソドロジーに 変換する作業をおこなっている。 「もっと早くから手をつけるべきだったのですが、昨年の夏ぐらいから、コンサルを 担当している若手が集まって１０名くらいのチームを作って、コンサルティングの現 状の分析と、方法論の改善を行っています。今まで塩漬けになっていた考え方、古く なった技法を見なおして、もう一度基盤になる技術を再確認しましょう、新しい技法 にリニューアルしましょう、ということです。（中略）ビジネスコンサル系の人、ＩＴ コンサル系の人、生産技術の人が集まって新しい考え方で方法論を整備して、その枠 組の中に今までのノウハウを当てはめて蓄積することも始めています。それを、私達 のナレッジマネジメントシステムに乗せて、ナレッジベースを作って、それを持って お客様のところに行けるようにしようという取組みです。（中略）ナレッジマネジメン トとしては、色々な知識を集めて利用する、というのはやっていたのですが、もっと 179 根本的にコンサルを行うノウハウを整理して、フォーマットもきちんとして蓄積して、 それをお客様に持っていけるようにしようというものです。今までやっていたような、 何か色々集めておいて参考にして下さい、というのではなくて、工数はかかりますが、 再利用できる形まで抽象化して蓄積しています。こうしておけば、コンサルが人に依 存することも減りますし、人との関係で方向性が揺らぐことも防げます。自信のない 若い人でも何とかお客様のところに出ていけます。(中略)コンサルでは、若い人が一人 で出ていくことはなくて、ベテランの人について、見ながら覚えていくという形をと っているんですが、それでは沢山の人を育てることが難しいんですよね。コンサルを 大きなビジネスにするためには、もちろん、人を育てることもしますが、ナレッジベ ースをきちんと作って、ノウハウにプラスαのコンサルティングをお客様に提供する ビジネスモデルを考えています。」 （C7） 次の会社では、ナレッジマネジメントの一環としてメソドロジーの開発をおこなってい る。その際、あるコンサルタント（C6）は、メソドロジーとしてのノウハウをそのまま活 用するのではなく自分なりにメソッドをカスタマイズすることが重要である、と指摘する。 「ナレッジマネジメントの専門チーム、ナレッジブローカーが 6 人いますが。我々が コンサルティングの経験で作り上げた、それを抽象化してメソッドを作りましょうと。 それが現在のわが社のやり方です。コンサルを始めたときに、その当時に、○○とい うメソッドを当社で作ったんですよ。それは、私が初めてやったコンサルプロジェク トを裸にして、メソッドを作ったんですよ。当社オリジナルだし、かなりいいもの。 それをいまだ、10 数年間、継承して使い続けているんですよ。使い続けるということ は、メソッドがかなり賢くなっている。業務改革、システムの構想立案だとか、プロ シージアルに物事を進めていくコンサルティングテーマのメソッドなんです。新しい 事業創造のメソッドに合わないんですよ。クライアントと整理していくパターンでな くて、クライアントから悩みを聞いて、シナリオをうちで作って、ある日突然アイデ アを提案するという、やり方が全然違う。そのメソッドを、当社が独自で作り上げて。 たぶん、ライセンスどおりにしても使えないと思うんですね。メソッドというのは。 当社でも、一番長いんですが。○○というメソッドは、オール当社で使えているかと いうと、なかなかそうでもない。○○というメソッド作りにかかわった人、もしくは 1 回使ってみて、自分なりのカスタマイズをした人は、非常にうまく使っているんです よ。与えられた手法だから、従って、手順どおりにやっていけば、コンサルができる んだと思っている人は、メソッドは全く使えない。これが、ソフト作りのメソッドと の大きな違いだと思います。」（C6） 180 3.3.5 評価制度 表 3.3.14 評価制度（職種別） プロジェクトマネジメント コンサルタント 年齢により評価基準を変える(1) スキルアセスメント(1) 認定制度(1) 認定制度(1) セールス 年齢により評価基準を変える(1) 知識共有を評価(1) プロジェクトマネジメントおよびコンサルタントに関しては、認定制度を導入したり、 年齢別に、評価基準を変えるという工夫がなされていた。 認定制度を導入した会社のプロジェクトマネジメント（P9）は、次のようにコメントし ている。 「プロフェッショナルとして認定して、それを上げていくときに。または、認定する とき。そのときは、売上損益も見ますが、プロセスです。この人がプロジェクトマネ ジャーとして、どのくらいのレベルで、さらに上にあがれそうだとか。そういう評価 ですね。それはむしろ、プロセスなり、その人が培ったノウハウだとか、プロジェク トマネジメントに対する、その人の見識というのかな、どう捉えているかとか。そう いった場合には、プロセスのほうを見ます。評価といったときには、2 通りあると思う。 成績評価みたいなものと、その人のプロフェッショナルとしての評価というのがある。 厳密ではないですけど、プロフェッショナル制度には、インセンティブをつけてます から。そこが上がっていくと、反映されますよね。少しリンクしてて。リンクがもう 少し強くなると思うんですけど。第 1 回の認定が、今年の 3 月。そこで 100 名程度で。 今、2 回目の認定をしてて、200 名くらい認定されると思います。」（P9） この会社では、売上・利益といったアウトプットではなく、プロセスを基にプロフェッ ショナル認定をおこなっている。 成果主義の人事評価に関して、次のプロジェクトマネジメント（P7）のコメントを見て みよう。 「成果主義は成果主義でやるが、ウエイトというのがある。ウエイトを変えた。新入 社員で何年までの人には何をウエイトにおくか、幹部社員になったときに、例えば半 分損益の責任、ウエイトを置くようにした。だけど新入社員で 2、3 年と 5、6 年と、 幹部社員になるまでのあと 4、5 年の間のそれがみんな幹部社員と同じかというと、違 181 うはずで、若い人にはさっき言ったような考え方でやってもらわないといけないので、 何にウエイトを置くかというと当然技術をいかに蓄積するか、といったところを評価 の尺度としてウエイトを高める。まず、ウエイトを変えたということ。」 （P7） このコメントからわかるように、評価の際に、若手技術者はプロセスを、中堅以上の技 術者はアウトプットを重視している。あるコンサルタント（C6）も次のように述べている。 「目標管理というのを当社がやってるんです。その中で、『あなたが今年、得意領域を 深耕しました。どの領域を深耕しますか？』という項目を目標設定して、年に何件く らい、プロジェクトを推進したいですかという目標設定をします。日ごろ活動してい るプロセスを目標値にしているんです。結果としての売上とか、受注ということだけ ではなく。若い人、5 年未満の人は、7 割くらいは、プロセスにかかわるキーパフォー マンスインディケーターを目標設定、3 割くらいが、売上高とか。幹部社員になります と、6 割くらいが、売り上げだとか、利益。4 割くらいがプロセス。」 （C6） コンサルタントでは、スキルアセスメントを導入したり、知識を提供した者にインセン ティブを与える企業もあった。プロジェクト毎にコンサルタントのスキルを評価している 会社の例を見てみよう。 「半年に 1 回スキルアセスメントをやってもまるっきり意味がないと思っていまして、 プロジェクト単位でスキルアセスメントをやるわけですね。プロジェクトが始まる前 に自分はどのスキルセットが何レベルなので、このプロジェクトでこれをこれだけ上 げたいとコンサルプロマネに申告します。プロマネは、このスキルはこのプロジェク ト背景で上がるわけがないからこっちを上げろ、というような調整をし、それで合意 したらプロマネはどんなに怖くてもそのスキルを上げるような場を与えないといけな い。ワークショップコーディネーションなんてやらしたら怖くてしかたがない。自分 でやった方が早い。でもそこで合意したら、前の日に徹夜で練習してでもそれをやら せないといけない。プロジェクト単位にそういう目標設定とジョブアサインをやると、 育成サイクルが短くなる。半期 1 回やるより。しかも特定の物件でやっているので場 を与えやすいのと評価もしやすい。 （中略）スキルアセスメントはプロジェクトリーダ ーが行いますので、必ずしも自分の上司とは限らない。そういう複数のアセスメント 結果を直属上司が見ながら、業績評価等へつなげています。」 （C2） この例にあるように、通常の業務とスキル評価を連動することで、より短いスパンで、 多面的な評価をすることが可能になる。 182 次の会社では、ナレッジを評価の対象にしている。 「ナレッジの共有は難しい。だから、ナレッジマネジメントをうちでやっています。 ナレッジマネジメントを商売としても売っているのですが、難しいですよ。難しいか らどういうことをやるかといえば、ナレッジを出したら、お金をあげるということ。 普通、自分が勉強したんだから黙っていて得してやろうと思うじゃないですか。そう ではなくて、ナレッジを出したらあげるってことですよ。ナレッジマネジメントをや っていくと、ナレッジを共有しないと、その人にナレッジが集まらないわけですよ。 「あいつ何も教えてくれない、隠している。 」って。だから、ナレッジを共有して出す ことが、自分の勉強になるんですよ。人の経験を買うんですよ。M&A と同じ。個人の 経験は買えるじゃないですか。 （中略）3 月の期末まであと 15 日とかで 300 万円、500 万円あげなくてはいけないような場合、普通売上なんてあげられるわけないじゃない ですか。そういう時に、過去に一所懸命情報公開しているやつが、金額査定をしてす ぐに入れてくれる。そうすると、ノルマ達成できるじゃないですか。そうすれば、ボ ーナス下がらないですむじゃないですか。いっぱいやってればボーナスは上がるし。 そういう風に、皆さんが疑問に思うように、「情報出さないんじゃないの」「情報共有 しないんじゃないの」って思ったら、それをひっくり返すように「何したらそれが出 るの」っていうことを、教科書どおりにそれをやっていく。」 （C8） 3.3.6 組織体制 表 3.3.15 組織体制（職種別） プロジェクトマネジメント コンサルタント 流動的なチーム制(3) セールス ジョブローテーション(1) コンサルタントについては、個人の意向や関心を重視する流動的なチーム制がとられて いる企業が多かった。あるコンサルタント（C6）の次のコメントを見てみよう。 「3 年間は、やりたいようにやりなさいと。コンサルというのは、自分がやりたいテー マというのがある。マーケティングコンサル、ヒューマンリソース系とか。業務分野 でジャンルを決める人もいるし。ファシリテーションのコンサルをしたいんだとか。 知恵をもってクライアントに提案するコンサルをやりたいんだとか。現場改善型がや りたいんだとか。領域とタイプの組み合わせ。それを、私から与えることは不可能で あって、3 年間は、自分のやりたいことを。自分がつきたいリーダーにつきたいと言え ば、自由につける。40 人がどういうアサインをされているのか、棒グラフを開示して 183 いる。全て、オープンマネジメントで。それで、3 年後に決めなさいと。どんなタイプ のコンサルをやりたいかを。やりたいということが最大の価値であって。無理にやら せてもダメで。 （中略）基本的に若い人も、マルチプロジェクトをしなさいと。2 プロ ジェクトは同時にやりなさいと。課長、MC ですと、同時に 3 プロジェクトくらいは平 行してますね。マルチプロジェクトもおりますから、ある期間は、このリーダーとや りたいと。同時に、このリーダーにもついているというパターンです。」（C6） 次の会社も、同様に、コンサルタントの意志や主体性を尊重した組織体制を採っている。 「うちは、社内マーケット・システムをつくってあるんですよ。それはどういうこと かといえば、自分の部署でこれ自分に合わないなと思えば、即自分の意志で止められ る。上司に相談しなくていいんですよ。 （中略）ある人は「戦略情報システムだけやり ます」とか、「顧客管理が得意だから CS やる」とか、「ERP パッケージやる」とか。 それをクラスターでやっているんですよ。今クラスターは 40、50 あるかな。数はいく らでも増えたり減ったりしているわけ。去年あたりうまくいかなかったクラスターは、 今年はなくなるわけ。私ももう、これを 7、8 年やっているんだけど、なくならないで すんでいるんですけど。でも、人数はバーっと減ったりゼロになったり、1 人でもいい んです。1 人クラスターと呼んでいるの。だって、その人がその業界で No.1 の人だっ たら、1 人だっていいんですよ。」 （C8） 3.3.7 人材育成の課題と問題点 表 3.3.16 人材育成の課題と問題点（職種別） プロジェクトマネジメント 早期育成の重要性(1) コンサルタント セールス ゼロからの経験が不足(2) 他者に頼る傾向(1) 管理志向(1) 人材育成の課題として挙げられたのは、「早期育成」である。あるプロジェクトマネジメ ント（P7）は次のように述べている。 「感心するのはここ 4∼5 年以内に入ってきた当社の社員というのは、どこも同じかも しれないが、すごく優秀です。たぶん、私が 10 年かかって、そこの域に達したのが、 4∼5 年で達するのじゃないか。そのためにはそういうような、モノをちゃんと作った り、技術を訓練するという歴史、ヒストリーをつくってやらないといけなくて、優秀 184 だからといって、スタッフみたいなことをやらせては、かえってダメになる可能性の スピードが速いんじゃないか。モノをつくって、サブリーダーになって、サブリーダ ーで 4∼5 人を引っ張って、こういう経験を積ましてこうだというものを 15 年かけた ものを、同じことを 5 年から 6、7 年のなかで詰め込んで、それに答えられるくらいの レベルの人がここ 4∼5 年で入ってきていることを感じる。だから、上の人がそういう ことを計画的にシナリオをつくって、育成するプランを持っているかということにか かっているんじゃないか。 」 （P7） このコメントにあるように、早期育成のためには、優秀な人材を獲得した上で、段階的 に濃い経験を積ませ、計画的に育成していく必要がある。また、変化の早い環境に適応す るためには、知識や情報の共有によって、短期間で能力の高い人材を育成する必要がある。 しかし、知識や情報の共有が行き過ぎると、 「自分で考えなくなる」「ゼロから何かを生み 出すという経験ができない」というデメリットが生じることも指摘された。 次のプロジェクトマネジメント（P4）は、自分で考えて実行することの重要性を強調し ている。 「知られるということと、実装するということ、実証するとか、これがなかったら、 ダメだと思います。勉強するだけだったら、本やインターネット、いくらでも情報を 取り出せますから。私たちのときでも、アメリカの本でも買ってきて、読めば、新し いことというのは、理解できるわけですよ。ただ、それを使わないと、何もわからな いんですよ。本には、便利だと書いてありますけど。実証すると、それで経験をして、 良い悪いを理解して、その次に、普及させるために教えるということ。これはこうな んだけど、こういう悪さがある。だから、こうやれということを、スパイラルにやら ないと、だめなんだろうと。新しいことというのは、とっぴなとこから、生まれてく るのではなくて、何かがあって、改善、改良してということで進んできてますよね。 （中 略）今の若い人は、探そうとする。インターネットで探せば、いい答えがいくらでも 出てくる。サンプルコードが出たり、大学でもそうだと思いますが、卒論を書こうと 思えば、迷わずインターネットで探してきて、カット&ペーストですんでしまうと。自 分で考えないと。カット&ペーストと検索エンジンに優れたやつなら、良いレポートが 作れると。こういうのは、いけないんだろうなぁと。」（P4） このコメントにあるように、「安易に情報を収集するだけで、自分の頭で考えようとしな い若手技術者が多い」という意見が多かった。次のコンサルタント（C5）は、即戦力化が 重要となっているが、それだけの時間や機会が少なくなってきた点を指摘している。 185 「どういう風に育てるかという話ですが、経験させると、それだけの時間を要すると。 そこのジレンマみたいなものが非常に、皆さんがもっているんじゃないかと思うんで すけど。即戦力化という言葉と、最終的に、どちらが本当に有効なのかみたいな。ア メリカのように長い目で見なくていいという発想が、日本的なカルチャーの話から変 わってないような気がするんですよ。（中略）表面的な知識は、皆さんあるというんで すけど、それを実際に適用して、まさに何事もなければ、スムーズに流れるんですけ ど。必ず何か起こる。そのときの、対応の時間が、昔に比べると 2 倍、3 倍かかってい るというのが今の現状じゃないかと思います。（中略）どちらかというと、任せるとい う環境が少なくなっちゃったような気がするんです。責任の取り方というような議論 が非常に重要なのかもしれないんですけど。基本的にやらせてみるという世界が、減 っていると思うんです。それは、プロジェクト的に大きくなってきている、縦割りに なってきている、そこだけ見ていれば、常に報告していればみたいな、というような ことが強すぎてると思うんです。それで、考えなくなってというような部分もあるか もしれないです。下手に考えて怒られるよりは、考えないで丸投げしたほうがいいや というような。」 （C5） 186 3.4 顧客満足経営の現状と課題 インタビュー調査を実施する中で幾度となく強調された言葉は「顧客」であった。IT 技 術者にとって、顧客のニーズやプライオリティを把握し、スピーディに品質の良いサービ スを提供することで顧客を満足させ、再受注することが重要になる。職種にかかわらず、 「顧客管理」スキルが重視されていたことからも、顧客満足（Customer Satisfaction）を 高めることが競争優位を確立する鍵となることがわかる。 以下では、各社が顧客満足度を高めるためにどのような試みをしているかを、「顧客満足 度の測定」「顧客満足度と業績評価のリンク」「顧客満足度の規定要因」「過剰サービスの 危険性」という側面から検討する。 3.4.1 顧客満足度の測定 顧客満足度の測定の方法としては、「顧客アンケート」が最も多かったが、「直接聞きに いく」という意見も見られた。顧客アンケートを実施する際には、担当者が持っていく場 合と別部門から送付するやり方に分かれる。顧客アンケートの限界としては、測定の妥当 性に問題があるという意見が多かった。あるプロジェクトマネジメント（A2）の次のコメ ントを見てみよう。 「プロジェクトを長い間やると、お客様も単純には評価できないですよね。やはり、 よくやってくれれば、評価を悪くできないというところもあるし、たまたま付き合い が少ないところにいくと、ひどい評価になったりということも、たぶんあると思うん ですよね。お客様評価を、客観的に捉えるというのは、結構難しいと思いますよ。ベ ンダーの立場ではね。一般調査だったら、まだいいと思いますけど。そこら辺の測定 というのは、結構難しいと思います。」 （A2） このコメントは、顧客との関係性の強さによって満足度の結果が左右される点を指摘す るものである。次のコンサルタント（C5）も、付き合いの長い顧客がアンケートをつけに くくなる、と述べている。 「現在、お客様にアンケートをとって、回収して、成績管理、目標管理の中の 1 項目 の中に、そういう意味では入っています。コンサルだけでなく、フィールド SE という キーで、全体にやってます。なかなかお客様からも、難しいというか、『勘弁してよ』 というお客様もいらっしゃる。顔が見えちゃうだけに、どう答えていいかということ が。アンケートを自分で投げて、取ってきてというのもありますし。コンサル認定す るときには、評価を、自分のやったプロジェクトの評価をつけとくというのがありま 187 すから。本当は知らない中でやってくれるのだったら、それはそれでいいような気が するんですけど。実は、本人がわかっているので、今は。そういう仕組みは、ちょっ と考えなきゃいけないような気もしますけど。」（C5） あるセールス（S2）も、顧客がアンケートに回答することに消極的であるとコメントし ている。 「お客様満足度については、会社で持っているお客様満足度の調査を、私たちが十分 に活用できていないと言っていいと思うんですけど。昔、面倒くさいといって、一箇 所にしかやってないんですね。それは、情報システム部門です。ご不満に対して、ど ういう対応をしていったら、買ってもらえるかということで、一番買ってもらえる情 報システム部門に、調査をするというのは、正解だと思うんですけど。お客様にとっ ても、面倒くさくて、その調査を下に投げられるケースが多いので、あまり正確な調 査は得られていないと思っています。それよりは、ストレートに、お客様が怒ってい るときは、怒って言ってきますし、クレームがあるときは、言いますし、もって回っ た言い方というのは、されませんから。そういう観点では、満足度は毎日いただいて いるという認識でいます。あまり、ほめてはくれませんけど。」（S2） 次のコンサルタント（C6）は、アンケートよりも顧客に直接聞きにいくことやリピート が重要であるとしている。 「コンサルティングが終了したら、お客様が満足したかというデータを出して、アン ケートをもらうという制度がありますが、あまり運用しきれてないですね。私が、今 それを聞く役割を果たしてますが、 「満足をしてますか？」ということを聞くというこ とが大事なんです。聞いた時点で、お客様の満足が上がるんです。ホテルの支配人か らのレターというのがありますよね。書いたことはないと思いますが、ないと不安で しょう？あれは、安心感をとるためのマーケティングツールなんですよ。ないホテル にいくと、不満が出るんですよ。同じように、コンサルというサービス、終わったら お客様に、そのサービスについてお声をいただくという。これをやると、サービスも 上がるんですよね。もう 1 つは、定量的に私のところで見ているというのは、リピー トなんですよ。お客様に聞くまでもないと。不満があれば来ないと。個人として、同 じお客様のリピート率がどうなのか。私の組織としてリピート率がどうなのか。高い ときは、リピート率が 8 割ありました。今でも 5 割を下ったことはないです。リピー トがあるということは、不満が少ないということ。アンケートをとろうというところ が、大企業ですよ。クライアントで不満が出たら、議論するというよりも、すぐクラ 188 イアント先へ行こう。行動力のないことが不満なんですよ。直接話せば、言いたいこ とが言えるし、聞けるし。リアクションのスピードが見えないんですよね。 」 （C6） ある会社では、プロジェクトが進行している期間中、定期的に顧客と面談し、顧客の期 待と現状サービスが適合しているかどうかをチェックしている。次のセールス・マネジャ ー（S4）のコメントを見てみよう。 「当社には、まず、お客様と「実際どのようなことをやっていったらいいのでしょう か」 、ということをセットして、その後で、ちゃんとミートしたかどうかということを、 検証しながらお客様のご要望に対して、応えていっているのかを確認するメカニズム があります。」 （S4） 3.4.2 顧客満足度と業績評価のリンク 顧客満足アンケートの結果を評価に結びつけるかどうかに関しては、結びつけている会 社とそうでない会社に分かれた。まずは肯定的な意見から見てみよう。 「 （満足度を評価にリンクして）いいと思います。満足度というのは、いろいろ尺度が あると思いますが、少なくともお客様がいいとおっしゃってるのでいいと思います。 ただし、どこがいいかを知りたいんですよね？人間性、振る舞いを言っているのか、 技術的なサポートを言ってるのか、ということは多面的に聞く必要があると思います。 それでも要素がばらつきがありますよね。アンケートをいろんな角度でやったほうが いいと思います。私も、顧客満足度は、本人じゃ聞きにくいだろうから、上司が行っ てこいとしてました。実は、お客様の満足度でお聞きしたいんですけど、いいところ と、逆に改善しなくちゃいけないところを教えてくださいと。現場の課長とかに、お 客様に聞いてもらうんです。付き合いも長いですし、趣旨をお話すれば、別に紙でく ださいというのではなくて。素直に評価にします。人間付き合いが長くなると、甘く なるが、それはそれで、1 つの満足度だろうと。」 （A3） 次のコンサルタントが属する会社も、顧客満足度と評価を結びつけている。 うちの部は、評価の中に、顧客評価というものを義務付けてます。顧客に対して質問 表を一定のフォーマットで書いてまして、それをプロジェクトの節目節目に、担当者 自らが、書いてもらって、はんこをもらって回収するというのをやってます。評価の 結果は、業績評価に点数化します。顧客評価という項目がありますので、顧客に十二 分に評価されていたら 10 点とかですね、ごく普通だったら 6 点ですとか、そういう風 189 に反映してます。業績評価に反映してます。ただ、具体的に書くときに、その顧客と なぁなぁだったら、ちょっと上目に書くということがあるかもしれませんけどね。い ちおう、制度として、そういうものを盛り込んでいます。（C9） 次のコンサルタント（C8）は、顧客満足度調査を査定（人事評価）にリンクすることは システムを機能させる上で必要不可欠であると主張している。 「普通の顧客満足度のアンケートから、従業員に対するアンケートまでやります。従 業員に対するアンケートは、「将来こういうことをやりたい」というものから、従業員 の満足度調査もやる。また、100 万円以上の仕事に関しては、アプレイザル・シートで 調査をしている。アプレイザル調査とは、お客さんのところへ、担当者を介さずに直 接「○○さんの仕事はどうでしたか」と送るというものです。また、大きい仕事は、 常務や専務が、直接聞きにいくんですよ。顧客満足は、やらないと生き残っていけな い、そういう仕組みになっています。評価に直接かかわるから。給料にも響く。だか ら、ただ評価だと駄目なの。評価は、実際の査定に影響して給料に響かないと。もし も、2,000 万円もらっている人が、満足度なんて知りませんっていって給料に響かない と駄目でしょ。査定にすぐに響くように。自分の給料なりボーナスに。一般企業でや っているところは少ないですが、○○はやっています。日本経営品質賞とってるし。 BSC（Balanced Scorecard）入れてやっています。営業部長さんが「あなたはプロセ スを変革しましたか」って聞かれるんですよ。その結果、同じ部長クラスでボーナス で 300 万円差が出たそうです。これは○○の話だけど、うちも同じようにやっていま す。 」 （C8） 次に、顧客満足度を業績評価とリンクしていない会社の例を見てみよう。 「いちおう統計とって絶対点がつくんですよ。100 点満点で何点かという。どこが弱い という傾向が見えてきますんで。ごくあたりまえの使い方なんですけど。査定に、あ まりつなげちゃうとね、難しい。加点主義だったらいいんだけど、減点主義になるじ ゃないですか。加点の方で使えればいいんだけど、そんないい点数がついてこないで すからお客様から。厳しいお言葉ばっかりついてきますから、アンケートは改善につ なげていくというふうに活用しないと、加点側に倒れないんですよ。」 （P8） このプロジェクトマネジメントは、満足度を評価につなげると減点主義につながる恐を 指摘している。これに対して、次のコンサルタント（C7）は、顧客によって、評価の厳し さに違いが見られるため、査定につなげることは難しいと述べている。 190 「お客様によって、評価のしかたが違いますよね。全く同じ人が、全く同じやり方で 評価しているわけではありませんから、Ａというお客様は非常に甘い評価をするけれ ども、Ｂというお客様は辛い評価をする、ということはありうるわけです。また、同 じようにスキルがあって、同じような成果物を出していても、お客様の状況によって 評価は変わってきます。お客様が非常に厳しい状況にあって、コンサルに対してかな りの期待を持っているお客様は、評価が厳しくなります。わりにゆとりがあって全体 額がそれほど大きくなければ、まぁまぁ少々のことはいいか、この次がんばってくれ よ、ということで、評価はそれほど下がらないのです。大体相関が見えています。全 体の額が大きかったり、長期だったり、かなりお客様自身が困っておられるときは、 同じようなことをやっても評価が良くないのです。これでは、顧客満足度は個人の評 価には使えません。満足度の評価は、色々なことを考えているお客様の本当の気持ち を知って、どの辺のところを改善するかを考えるのに使うということが重要だと思い ます。 」 （C7） 以上のコメントから、顧客満足度を査定に結びつける上で、プロジェクトの規模、期間、 顧客が抱える問題等、様々な要因を考慮する必要があるといえる。 3.4.3 顧客満足度の規定要因 顧客満足度は何によって決定されるのであろうか。インタビューでは、IT に関するスキ ルや品質だけでなく、態度やレスポンスの速さが重要であるという指摘がなされた。次に 挙げる、プロジェクトマネジメント（P7）とコンサルタント（C7）のコメントを見てみよ う。 「お客さんの顧客満足度はまず品質だと思う。品質がベースになっている。人間どう しでやっているものだから、不思議なことに品質が全く同じレベルだったこともある が、品質が少しくらい悪い、少し悪いほうが満足する、ほめられることがあると思っ ている。それはレスポンスの速さである。（中略）僕が大事なのは品質が大事で、品質 にかかわらず、お客さんの要望に対するレスポンスをいかに速くするか。それと今流 行りの言葉でいうと、ソリューションというのは他社と違った、さすが当社だという のが必要じゃないかと思う。大体顧客満足度に関してはその 3 つくらいが重要で、当 社が今そういう評価をされているということは、客観的にそこが劣っていると思う。 」 （P7） 「今、その育成という面では、私、色々データを取っています。顧客満足度に関係す 191 るのがスキルなのか、態度なのか、成果物をきちんと出すことなのか、その辺の関係 をみているんです。もしも、成果物、たとえば報告書さえあれば満足してくれる、と いうのであれば、方法論で『これだけのものを揃えておく』と規定して、ドキュメン トの書き方などを教育すればよいと思うのですが、どうもそうではないんですね。コ ンサルタントのスキルよりも態度、それも、丁寧であるとか、言葉遣いが良いという よりも、積極性、つまり、 『あなたのためにこんなことをやりたいんだ』という思いが 一番効いているんじゃないかと思われるんです。これは、まだデータが集まっていな いんで、もうちょっと集まったら、色々と相関を分析してみようと思っています。そ うなってくると、もちろんコンサルティングのノウハウや生産技術について身につけ る勉強も大切ですが、コンサルティングのときの話し方とか対応とか姿勢とかをきち んと学ぶというのも必要なのかな、と思っているんですよね。」（C7） 3.4.4 過剰サービスの危険性 顧客満足度を高める上で気をつけるべきことは、過剰サービスの危険性である。あるコ ンサルタント（C1）は次のように述べている。 「一番気をつけているのはお客さんの期待よりもオーバーサービスしてやろうと思う 気持ちですね。別な観点で調べ直してあげようとか、参考資料を添付しようかとか。2 社以上の仕事が並行しているときに、質、量が足りなくて悪いと思ってしまうんです。 人が良いといわれる。頭にくるのはサービス精神を丸呑みしてくるお客さんがいるこ とです。これに対して、好意が義務になる、勘違いすることがある。そういう場合は 1 ∼2 週間遠ざかる。コンサルティングには検収がないので、どこまでやったら満足して くれるかということは文章に書けない。」 （C1） 次のセールス（S4）も、顧客の期待に対して満足度が高すぎた場合の危険性を指摘して いる。 「ユーザー数が十数社くらいしかないんですね。ほとんど毎日顧客にいっているメン バーばかりなんですよ。だから、顧客満足度のアンケート結果は、いい結果が出ます。 本当にこんないいのか・・・とも思いますけど。本当に、べったりついた営業の特性 となってますから。都内にあるユーザーばかりだったんで、非常に訪問頻度は高いで す。ほとんど、毎日のようにいってまして、何か情報があったら、すぐ上がってきま す。そういう意味じゃ対応も早いですから、顧客満足度も高いという形になってます ね。不満があるといえば、品質の不満だとか、価格が高いだとか。営業行為はそんな に低くない数字が出てて、期待値と実際の値のギャップ値が 1 くらいがちょうどいい 192 んだという話ですが、１を下回っています。１を下回っていると言うことは、オーバ ーセールスになっていると思います。（中略）日本のお客様は、いいものを求めすぎる 傾向がありまして、例えば、24 時間 365 日、夜中に来いといいましても、2 時間以内 に着けとか言われますよね。本来、それはオーバーだよなぁと思うんですけど。それ を当たり前にしてしまうと、それをちょっと崩すと不満がくるんですよね。最初に SLA （Service Level Agreement）をきちっとしておかないと、いいものを与えすぎると際 限なくなります。これからは、SLA を明確にするというのは我々の課題かもしれない。 過剰は、過剰が当たり前になってしまってて。皆感覚を忘れているんですよね。あの 時、やってあげたはずなのに・・・。「あれ、この間やったじゃないか！」って、「そ れやってあげたんですよ」と言っても、あれが正のはずだと思ってますから。SLA を 明確にしていくことは非常に、難しくて。今後は SLA を明確にした対応を十二分に考 えた活動をする必要があります。」 （S4） 193 4. 第３部まとめ 本調査の目的は、日本の代表的 IT 企業における技術者が、どのようなスキル・知識を持 ち（目的 1） 、どのような経験を通してそれらを獲得し（目的 2）、どのように人材育成を行 っているのか（目的 3）を明らかにすることにある。以下では、これら 3 点について、これ までの分析をまとめる。 1）IT 技術者のスキル・知識 IT 技術者のスキル・知識は、「顧客管理」 「集団管理」「仕事の知識」「分析能力」「姿勢・ 態度」に分類された。以下では、それぞれのカテゴリーについて、職種間の共通点と相違 点について説明する。 表 3-2（再掲） IT 技術者に必要なスキル・知識・能力（職種別） 職種 顧客管理 集団管理 仕事の知識 分析能力 姿勢・態度 ﾌﾟﾛｼﾞｪｸﾄ･ﾏﾈｼﾞｬｰ ◎ ◎ ○ ○ △ ｺﾝｻﾙﾀﾝﾄ ◎ △ ○ ◎ △ ｾｰﾙｽ ◎ △ ○ △ △ 注： ◎特に強調された ○強調された △それほど言及されなかった すべての職種において重視されていたのは「顧客管理」に関するスキルであった。具体 的には、どの職種においても、顧客のニーズや問題点を把握し、自分たちの主張を明確に 伝えるコミュニケーションスキルが不可欠となる。ただし、同じ顧客コミュニケーション でも、コンサルタントやセールスは、プロジェクトマネジメントに比べて、より顧客と密 接な関係を作った上で、顧客を交渉・説得するスキルが要求されていた。 プロジェクトマネジメントは、他の職種に比べて、 「集団管理」のスキルを必要としてい た。多数のメンバーから構成されるプロジェクトを円滑に進めるためには、 「スケジュール 管理能力」 「優先事項の明確化と決断力」等によってプロジェクトの流れを管理しつつ、サ ブリーダーを通して間接的にプロジェクトをマネジメントしなければならない。 「仕事上の知識」に関して、プロジェクトマネジメントにとって重要なのは「技術的知 識」であったのに対して、コンサルタントでは「経営全般を見る目」 「業務知識」「メソド ロジー」といった、問題を把握し解決するための知識が重視されていた。 「分析能力」を最も強調していたのは、コンサルタントであった。コンサルタントは、 「論 理的思考能力」 「各種分析スキル」に基づいて、顧客の問題を把握し、適切な提案・企画を 提示する能力を持たなければならない。 「姿勢・態度」に関しては、「自信」「強い意志」 「責任感」 「情熱」といった要因の重要 性が指摘された。 194 2）経験の特性とスキル・知識の獲得 IT 技術者はどのような経験を通して、上述したスキル・知識を獲得したのであろうか。 職種別、キャリア段階別（初級レベル期・中級レベル期・上級レベル期）に整理すると以 下のようになる。 プロジェクトマネジメントは、初級レベル期（入社から 5 年目まで）において「SE とし ての部分的な仕事」や「５∼6 人の小規模グループのリーダー」を経験することで、IT 技 術に関する知識やスキルを習得していた。中級レベル期（6 年目から 35 歳まで）では、数 十名のメンバーで構成される「小・中規模プロジェクトのリーダー」を経験することで、 ものづくりの全体像を把握するとともに、顧客やメンバーとのコミュニケーションやトラ ブル処理についてのスキルを身につけていた。上級レベル期（ここ最近 5 年）では、100 名以上のメンバーから成る「大規模プロジェクトのリーダー」として、品質要求が厳しい 顧客や時間的な余裕がないプロジェクトを経験し、サブリーダーを介した間接的マネジメ ント能力やスピーディな意思決定能力を獲得していた。こうした点から、高いレベルのプ ロジェクトマネジメントは、小規模から大規模なプロジェクトと、徐々に難易度の高いプ ロジェクトを段階的に経験していることがわかる。 コンサルタントは、プロジェクトマネジメントと同様に、初級レベル期において、SE と しての部分的な仕事に従事している傾向にあった。しかし、「大量データ解析」「海外の大 学との共同研究」といった通常の SE とは異なる専門的な仕事を経験していることが多かっ た点に特徴があり、こうした仕事を通して、ビジネスの全体像を把握し現場感覚を身につ けていた。中級レベル期では、小・中規模のプロジェクト・リーダーとして、これまで経 験したことのない仕事を任されることで、コンサルティングに必要な業務知識や各種スキ ルやノウハウを身につけていた。上級レベル期には、大規模プロジェクトのリーダーを経 験したり、難易度の高い仕事をこなすことによって、顧客とのコミュニケーション能力や 論理的思考能力、分析能力を高めていた。このように、コンサルタントは、徐々に難易度 の高い仕事を経験しているという点ではプロジェクトマネジメントと共通しているが、よ り専門性が高い仕事、従来の経験が役に立たない新規性の高い仕事を個人ベースで経験し ている点に特徴がある。 セールスは、初級レベル期において、SE としての仕事を通じて技術検証力を身につけた り、プロダクトアウト型（従来型）の営業活動によって、営業の基本を習得していた。中 級・上級レベル期では、厳しい要求を持つ顧客を担当したり、心理的に自らの限界を破る ような経験をすることで、顧客との関係づくりのスキルやソリューション・ノウハウ、会 社全体を把握する力を身につけていた。中級レベル・上級レベル期に、難易度の高い仕事 を経験しているという意味では、プロジェクトマネジメントやコンサルタントと共通して いた。 195 3）人材育成 各社において若手や中堅技術者をいかに育成しているかについては、以下のようにまと めることができる。 人材教育の方法として最も強調されたことは、 「やらせてみる」に代表されるような実践 を通しての教育であった。ある職務を任せることで経験を積ませる際には、 「熱心な上司に つける」 「同行する」「環境づくり」といった点が配慮されていると同時に、小さなプロジ ェクトから大きなプロジェクトへと徐々に難易度の高い仕事を経験させる工夫がなされて いた。また、短期間に育成するために、 「ケースメソッド」によって実践教育を補足してい るケースが多くみられた。 あるレベルに達した IT 技術者が、半公式的な「コミュニティ活動」を通して、様々な情 報を共有している企業もあった。このコミュニティ活動は、形式化された情報が蓄積され ているデータベースでは扱うことの難しい「生の経験や価値観」を Face to Face のコミュ ニケーションによって共有する場であり、若手や中堅技術者の育成にも役立っている。 「ナレッジ・データベース」は、ほとんどの企業、職種において採用されていたものの、 日常的な忙しさのために、積極的に活用されているとはいえなかった。データベースを機 能させるためには、 「ナレッジを体系化」する「ナレッジ･オフィサー」が不可欠であり、 「検 索しやすさ」を向上させ、ナレッジを提供したメンバーに「インセンティブ」を提供する といった工夫が必要となる。また、ナレッジ・データベースには、「知識を伝達することが 難しい」 「自分の頭で考えなくなる」といった問題点が存在することが指摘された。 「仕事の進め方」に関しては、従来まで個人に任されていた開発手法を標準化する試み がなされており、独自のナビゲーションシステムを整備している企業もあった。コンサル タントの場合には、コンサルティングのノウハウを「メソドロジー」に変換することが業 務を効率化する上で有効となる。ただし、そうしたメソッドを活用する場合には、各自が カスタマイズしなくてはならないという。 「評価制度」については、「プロフェッショナル認定制度」を導入している企業が存在し た。評価をする際には、若手はプロセス重視、中堅以上はアウトプット重視というように、 「キャリア段階別に評価基準を変えている」ケースが多かった。また、一部のコンサルテ ィング部門では、プロジェクトごとにスキルを評価したり、ナレッジを評価対象にしてい た。 「組織体制」に関しては、個人の意向や関心を重視する「流動的なチーム制」をとって いるコンサルティング部門が多く見られた。 人材育成の問題点としては、 「人材を早期育成」するために知識や情報の共有を進めると、 技術者が「安易に情報を収集するだけ」で「自分で考えなくなる」という点が指摘された。 また、これまでのように、 「ゼロから何かを生み出す経験」をさせる機会が減ったことも問 題となっている。 196 4）顧客満足経営 最後に、本調査を通して強調された「顧客管理」のあり方についてまとめる。この点は、 冒頭で示したヒアリング調査の目的のうち、人材育成と深い関係がある。 「顧客満足度の測定」については、「顧客アンケート」や「直接聞きに行く」という方法 がとられていた。ただし、 「顧客との関係の強さ」によって評価結果が左右されたり、同じ サービスを提供した場合でも、 「顧客によって評価の厳しさが異なる」という問題点も指摘 された。また、顧客側がアンケートへの回答に消極的であるケースも多く、アンケート結 果よりもリピート注文の有無の方が重要であるという意見もあった。プロジェクト期間中 に、顧客の期待と現状サービスの適合度をチェックしている企業も存在した。 「顧客満足度と業績評価のリンク」については、実施している企業と実施していない企 業に分かれた。実施していない理由としては、「減点主義につながる恐れ」があり、 「顧客 によって評価の厳しさに違いが見られる」という意見が挙げられた。顧客満足度と業績評 価を結びつける際には、プロジェクトの規模、期間、顧客が抱える問題等を考慮する必要 がある。 「顧客満足度の規定因」として、IT に関するスキルや品質に加えて、「態度やレスポンス の速さ」が重要であるという点が指摘された。 顧客満足度を高める上で留意すべきことは、「過剰サービスを避ける」という点である。 長期的に顧客満足度を高めるためには、顧客の期待に対して満足度が高すぎないように注 意しなければならないという。 197