日経BP社の人材開発支援サイト ヒューマンキャピタル Online

中沢さん

営業部門の議論も、商品開発部門の議論も、中沢さんが参加した研修でのITアーキテクトの議論も、同じような結論に収斂していく。どうやら、研修コンテンツの効果的な整備についても、われわれ独自の方法ができ上がりつつあるようだ。いつもの3人で議論してみよう。中沢さんは、島さんと大町さんに対して、次のように問題提起を行った。

そもそも今回のプロジェクトでは、単に週次ミーティングを中心に能力開発のサイクルを確立させるだけでなく、そこで必要性が明らかになった教育研修や学習コンテンツを効果的に現場に供給できるようにすることも想定していた。例えば、

• マーケティング基礎知識などの標準的知識：コストパフォーマンス高く供給できるように、外部の優れたコンテンツをeラーニングで配信する、など
• 技術資料、提案書事例などの社内ナレッジ：良質な資料が共有されるように、共有を前提としたコンテンツ作成のテンプレートを提供するとともに、資料が役立った度合いがランキングされるようにする、など

しかし、営業部門におけるプレゼンテーション研修や、商品開発部門におけるロードマップ研修など、「アイデアや情報を共通のフレームワークで集約・整理して、ロードマップとしてストーリー立てしてプレゼンする」というアルファ社オリジナルの研修のパターンが現れてきている。その要素を整理してみると、次のようなものだ。

• 第一に、ロードマップを初めとして、未来起点で考えてみること。つまり、チームメンバー間や顧客との間に共通の目的を設定すること。
• 第二に、その目的達成方法をチームで議論するために、情報を集約するための共通のフレームワークを持つこと。つまりコミュニケーション方法を設定すること。
• 第三に、目的達成に向けて一人ひとりのやり方が改善されることが目に見えること。つまり、意欲がわくようにすること。

これは一つの仮説であるが、ロードマップを作成し、プレゼンし、議論する研修こそが最も効率的・効果的な研修であり、必要な研修はそれに尽きているのではないだろうか。教育研修やコンテンツの整備について検討してきた経験を持つ大町さんに、企業内教育の最新の理論や動向に照らして、仮説の妥当性を吟味してもらうことにした。

大町さん

大町さんに検討結果を発表してもらう。大町さんは言う。
ロードマップ作成とそのプレゼンは、効果的な研修であると評価できそうです。なぜならば、効果的な教育研修コンテンツ作成の原則にかなっているからです。いくつか着眼点があるのですが、まず、教育研修として効果的なものであるためには、「インストラクショナル・デザイン」の原則にかなっている必要があります。「Analyze、Design、Develop、 Implement、Evaluate」の手順を踏んだものである必要があり、とりわけ「学習目標の設定」がきちんとなされているかどうか、およびそれが達成できたかどうかの「評価」がきちんとできるかどうかが効果的な研修設計の鍵になると言われています。

その点、ロードマップ作成研修は、ロードマップを作成し、合意を形成し、そしてプレゼンテーションできるようになる、という学習目標となる成果物／成果行動が極めて明確ですので、十分に条件を満たしています。

次に、教育研修コンテンツの効果を高めるための重要な視点として「論理モード」と「物語モード」の融合という視点があります。米国の教育心理学者で、日本の教育界にも大きな影響を与えたジェローム・ブルーナーが提唱するものとして知られています。

ブルーナーは、人間の認識には教科書のような「論理-科学的モード」とストーリーのような「物語モード」があり、人間が「わかる」「腑に落ちる」ときにはこれら2つの思考形式が補いあうことが重要だとしています。そして、前者と比較して後者の「物語」的思考様式がともすれば軽視されがちであることを指摘し、教育の場面における「物語」的思考様式の復権を主張しています。企業教育においてはケーススタディを使った教育研修を重視すべしということになるでしょうか。

そのような視点で考えてみると、私たちが試みている「未来へのロードマップを描き、説明する」というコンテンツでは「論理モード」と「物語モード」がちょうどうまく統合されていると言えるのです。というのは、未来起点で現状を振り返り、現状から未来へのロードマップを描くというのは「物語モード」です。それも、単に時間軸で語るから物語だというだけではなく、「本来こうあるべき→しかし現状はこう→ギャップはこれだ→こんなふうに埋めていこう」という葛藤を解決する流れは、まさにブルーナーの言う「物語」としての特徴を備えているものです。

一方、ロードマップを描くために、対象を要素に分解してフレームワークの中に情報を整理するというのは「論理モード」です。対象が要素にうまく分解され、情報がすっきりと整理されていればいるほど未来もよく見えるようになり、そこでは「論理」と「物語」は理想的に融合すると言えます。

これは仮説ですが、未来起点で考えるということにおいて「論理」と「物語」は融合すると言えるのかもしれません。例えば、翌週一週間の計画を立ててみるということだけを考えてみても、それは翌週のゴール達成に向けてのロードマップを描くようなものです。効果的に計画を立てるためには、活動の対象が頭の中ですっきりと分類、整理されている必要があります。対顧客、対社内部門、対ベンダー、製品情報、技術情報…というように。

未来を描いてお互いに突き合わせてみる…これが効率的な学習コンテンツの基本型になるのではないでしょうか。この仮説が今回のアルファ社のパイロットプロジェクトにおけるコンテンツ整備に関する結論であるように思います。

もう一つ評価の視点があります。それはアクションラーニングの視点です。今回のプロジェクトの最初の段階で問題になったように、伝統的にOJTとOff-JTは分野として以下のように分かれてきました。

• OJTを設計する「学習環境デザイン」：　学習のための空間や、学習のためのツール、学びあう仲間や活動といった、学習に関わる環境全体のデザイン
• Off-JTを設計する「インストラクショナルデザイン」：　学習環境を構成するリソースである教材や教授法のデザイン

しかし、近年、両者を統合するアクションラーニングという手法も有力なものになってきているわけです。

• OJTとOff-JTを統合する「アクションラーニング」：　実務上の問題解決や課題達成のなかでリフレクション(内省)しながら個人やグループ・組織が学習するプロセス。個人や組織の学習能力を高めるために、現実の問題・課題を題材に質問を中心とした小グループによるディスカッションで策を考え、実施する。

アクションラーニングを平たく言ってしまうと、部門横断的な問題解決や新規事業開発などのプロジェクト活動をそのまま教育研修にすることです。こう言うと、仕事そのものとどこが違うのか、ということになりますが、現実の課題に対して試行錯誤の経験をし、そのプロセスについて反省・検証を意識的に行うことで、立派な教育方法になります。

アクションラーニングは、次世代リーダー候補を選抜してリーダーシップ育成のために用いられることが多い半面、全社的、恒常的な教育研修プログラムとして運営するというのは簡単なことではありません。適切なテーマ選定、そしてプロセスの確立や指導者の育成が重要だと言われています。教育のためにプロジェクトを起こすというのでは本末転倒になってしまいます。

その点、自分たちの未来に向けてのロードマップを描き、関係者間で合意を形成し、それについてプレゼンするという研修は、どの部門においても必ず存在する重要テーマを扱い、目的とゴールとプロセスは明確、しかもそのプロセスには試行錯誤のプロセスも含まれ、また他人や他部門の視点を取り込んで反省や検証をするプロセスも含まれます。

アクションラーニングで取り扱うテーマの「8つの選定基準」を満たしているのです(マイケル・マーコード著、『実践アクションラーニング入門』、ダイヤモンド社より)。

1. 重要度が高いこと
2. ある程度の緊急性があること
3. 自分たちが抱えている問題であること
4. 能力の範囲内のものであること
5. 少数のメンバーが問題に通じていること
6. 有意性があること
7. 重要な学習の機会があること
8. グループに権限が与えられていること

すなわち、アクションラーニングの方法論としても誇れるものなのではないでしょうか。

中沢さん

中沢さんは言う。
われわれには、能力開発の「場」の整備と「コンテンツ」の整備の両方が求められている。場は「週次ミーティング」、コンテンツは「未来起点の企画提案」というように両方について中核になる部分が見えてきたようだ。しかも、場の実践の中からコンテンツが生まれてきたのであり、場とコンテンツが遊離していない。

今後の発展も描くことができる。「週次ミーティング」という場を起点にして、他の職場のミーティング、タスクフォースミーティング、能力開発委員会、あるいは客先等の実際の現場といった、様々な場を連携できる。同様に、「未来起点の企画提案」というコンテンツを起点にして、市場情報、製品情報、技術情報といった社内外のコンテンツの連携が可能になる。


図1：場とコンテンツの中核を整備する

あとは、これ以上は広げようとせずに、内容を深化させていくことが得策なようだ。すなわち、これらの「場」と「コンテンツ」をいかに効果的に運営していくか、ということに今後の検討は絞った方がよいだろう。

そのような中、あるトレーナーから「組織横断的なナレッジ共有のために、社内ブログやSNS(ソーシャル・ネットワーキング・サービス)のような、オンライン・コミュニティツールが効果的だから、今回のプロジェクトでもぜひ導入してほしい」と要望があった。能力開発委員会でこれを報告すると、社長は「他社に先駆けてノウハウを確立した方がいいものはぜひ検討しろ。そのためのパイロットプロジェクトだ」と言う。そして、パイロット部門以外の部門の委員も今回のパイロットプロジェクトの成果物への期待が高まっており、情報や成果物を共有できる仕組みはぜひ整備してほしいという。

しかし一方では、ブログやSNSという媒体自体に不信感を持つ委員もいた。というのも、これまでもアルファ社において、イントラネットの中で社内掲示板といったものは試みられてきたりはした。しかしあまり活用されないまま、一部の固定メンバーだけが活用して、後は見向きもしない状態になり、かえって社内に閉鎖的な空間を作ってしまった感もあったからだ。同じことを繰り返してはならない。今回のプロジェクトにおいてはどうしたらよいだろうか。この件については島さんに検討してもらうことにした。


(本稿について突っ込んだ意見交換が出来る場として「ヒューマンキャピタルSNS」(無料、要登録)にて、本トピックのコミュニティ「能力は現場で開発できる」を設けております。ログイン後ページ上部の[コミュニティ]からどうぞ。みなさまのご参加をお待ちしております。)


著者紹介

中沢さんは、IT業界の友人に声をかけられ、IT人材育成の勉強会に参加することになった。会合のテーマは「ITアーキテクトをいかに育成するか」である。IT業界では、ITコンサルタントと並んで「ITアーキテクト」の育成が現在喫緊の課題であるとのこと。どうやらアルファ社の状況と似ている。

会合は参加企業ごとに、自社におけるITアーキテクトとは何か、そしてどのように育成するか、ということについてプレゼンテーションを行い、それに基づいて、ディスカッションをするという方式である。アルファ社は必ずしもIT企業とは言えないが大いに関係しているからぜひ発表してくれとのことで、中沢さんも、「製品アーキテクトの育成に関するアルファ社の取組み」というテーマでプレゼンすることになった。

各社のプレゼンを聞いていると、会社によってITアーキテクトのとらえ方がかなり異なっている。

• A社：システムイメージを、「ビジネス」「アプリケーション」「インフラ」の各アーキテクチャ設計に落とし込む人
• B社：システムの一貫性を保つための「モデル」の策定・維持の中心になる人
• C社：ハードウェアやネットワーク、ソフトウェアなど様々な要素を組み合わせる専門家
• D社：システム構築プロジェクトにあたって技術面での意思決定を行う人
• E社：業務機能要件のみならず、性能/可用性/拡張性/運用性/連携性/機密性等の「非機能要件」を満足させる責任者
• F社：システムの基盤グループのリーダーとしてシステム全体設計を行い、さらに製造、試験からサービス開始、その後の安定稼働まで見届ける人

お互い全然違うではないか。そこで、IT技術者の人材像定義のデファクト・スタンダードになっている「ITスキル標準」におけるITアーキテクトの定義を取り出してみる。これでコンセンサスが得られると考えたが、まだかなり違う。どうやら「ITスキル標準」は各社各様に解釈されているらしいことがわかってきた。

そのような中で中沢さんがプレゼンする。アルファ社において、製品アーキテクトの重要性が認識されつつあるということ、そしてロードマップと情報整理のフレームワークを武器にして業界でのリーダーシップを発揮しようとしていることを強調し、大変に関心を持たれた。というのは、IT業界のこれまでのビジネスモデルでは、プロダクトを提案するというよりも、特定の顧客の特定のプロジェクトのニーズに合わせて、その都度システムを開発するのが通常であり、市場や技術が将来どのように変わっていくか、というまで目を配る余裕がないのが普通だったからである。

その点アルファ社では、流通セキュリティという分野に絞ることで今後の動向を予測し、絵を描き、リーダーシップをとろうとしている。それがIT業界にとっては新鮮な「攻め」の視点であり、本来あるべき姿を示しているように感じられたようであった。「ロードマップを先んじて描いてリーダーシップをとっていく攻めの姿勢こそは、世界的なOSベンダー、ERPベンダー、SaaS(Software as a Service)ベンダーなど、成功しているIT企業がとっている方法だ」という指摘もなされた。

各社のアーキテクト像はお互いにどこが異なるのだろうか？中沢さんがプレゼンに使った「対象×プロセス」のマトリクスはわかりやすいとの声があり、それを用いて整理してみることにした。各社それぞれ自社のアーキテクトがカバーする領域に色を塗り、それを突き合せてみる。そうしてみると案の定、塗られる位置が全然違う。

それにもかかわらず、「ITアーキテクト」と一言で言われるのはなぜだろうか？今度は、これらの共通項となるキーワードをカードに書いて、それを出し合ってみることにした。そうすると、「モデル化」「統合」「全体最適」「基盤」「非機能要件」といったキーワードが並んだ。


図1：各社のITアーキテクトの位置づけの違い

つまり、次のようなことなのだ。インターネットを介して、例えばマイクロソフトは全世界のパソコンのOSを一括アップデートし、グーグルは我々のデータそのものまで「あちら側」にまとめて置こうとしていることが象徴するように、ITの世界は現在、大統合に向かっている。NTTデータの浜口友一前社長は、10年後にはITおよび企業競争環境全般において「激変」が起きている可能性が高いことを指摘し、次の4つのシナリオを提示している(浜口友一著、『社員力』、ダイヤモンド社より)。

• 第1のシナリオ：大規模なコンソリデーション(統合)
• 第2のシナリオ：さらに進行する淘汰
• 第3のシナリオ：ITメーカーとITサービス会社間の競争の激化
• 第4のシナリオ：オフショアに向かうアウトソーシングの流れ

このような状況の中で、今後のITのシステムは堅固な設計の上でないと作れないし、発展させることができない。そのためには、システムの諸要素を接合する「骨格」に責任を持つアーキテクトが必要になるのである。


図2：ITアーキテクトは骨格に責任を持つ

こうすると、アーキテクトの技術は、品質管理やコスト管理と同じように、全体を支える「メタ技術」として独立させる方がよい。それにあたって、あくまでもコンピュータシステムのメタ技術とするか、それとも、ビジネスシステム全体のメタ技術にするかで、大きくアーキテクトのあり方も異なってくる。後者にすると、ビジネスをどこまでシステム化するのが得策か、そしてそれを自社開発するのか、他社と共同開発するのか、パッケージを使って開発するのか、あるいはそもそも自社では開発せずに、ASPやSaaSといったサービスをフル活用するのか、といった「ITを経営にどのように使うのが得策か」ということ自体の全体像判断が求められることになる。

そうするとアーキテクトの役割とは、結局、今後のグローバルなビジネス大統合時代において、自社のビジネス、業務プロセス、そしてそれを支えるシステムを、どこまでどうやって統合するか、見通しを与えることにほかならないではないか。

IBMでは90年代、世界のIBMを一つの組織として運営できるようにするために、次のような統合プロジェクトを推し進めたという。それを可能にするのはアーキテクトの役割ということになる(甲賀憲二、外村俊之、林口英治著、『ITガバナンス』、NTT出版より)。

• 155のデータセンター　→　16のデータセンター
• 31の個別ネットワーク　→　1つの統合グローバルネットワーク
• 何百個のクライアント構成　→　4つの標準構成
• 1万6000の社内アプリケーション　→　7500の社内アプリケーション

どうやらいずれにしても、統合への「ロードマップ」が鍵になってくるようだ。この、「ロードマップによるリーダーシップ」ということはアルファ社の場合と同じである。それが、参加者の皆さんがアルファ社のプレゼンテーションに惹きつけられた理由であった。

さて、ではなぜこのような、「攻めのロードマップ」を先導する技術者が育っていかないのか。そこで、アルファ社の例がヒントになる。アルファ社では製品毎にプロダクトマネージャーが数年単位で張り付くため、将来に向けて製品をいかに楽に育てていくか、ということがマネージャーの重要なテーマになる。

しかし、プロジェクト毎にプロジェクトマネージャーを割り当てるITシステム構築の場合には、インセンティブもプロジェクト毎に最適化されてしまい、ビジネスの全体、企業グループ全体、そしてシステムのライフサイクル全体の「全体最適」に真剣に取り組む者が現れにくい。だから、アーキテクトを育成するためには、プロジェクトマネージャーとは異なる業績評価基準を用意する必要がある。というような結論に落ち着いた。

そうすると、ITアーキテクトの育成方法とは何か？統合に向けてロードマップを描いた上で、実現に向けての課題解決案を持ち寄り、たたき合うこと以外にない。参加者の一人が「ただし、持ち寄るためにはフォーマットを決めておく必要があるだろうな。結局エンタープライズ・アーキテクチャの実践に行き着くのかなあ」と発言する。

エンタープライズ・アーキテクチャとは何か？それは、ITを中心として、企業経営の構造の全体像の、現状とあるべき姿を描くことであるという。 IBMのジョン・ザックマン氏が1987年に提唱したザックマン・フレームワークが元祖であると言われる。ザックマン・フレームワークは図のように一覧できるもので、それはITの世界において元素の周期律表くらい重要だと言われることもあるという。


図3：エンタープライズ・アーキテクチャのフレームワーク

このフレームワークの中に、システムにかかわるすべての要素を持ち寄り、共通の表記法で整理することで、様々な立場、様々な専門分野の人たちの物の見方を比較検討し、一貫性を保ちながら統合の検討ができるようになるという。共通の表記法をとることで、「アウトプットを見ればお互いのレベルがすぐにわかる」、「成果物を通じてノウハウを承継できる」ともいう。

このようなフレームワークを準備して議論をコーディネートすることがITアーキテクトの役割であるとすれば、出身がビジネス寄りであっても、ソフトウェア寄りであっても、あるいはインフラ寄りであっても、本質的な違いではないことになる。だからITアーキテクトと一言でくくれるのだ。

参加者の一人が「つまり、エンタープライズ・アーキテクチャのフレームワークとは、そこに組織中から人が集まり、切磋琢磨し、新しい知恵を生み出す、道場のようなものだな」と発言し、まさにそうだと盛り上がる。

中沢さんは、アルファ社の事例が意外な形で役立つことに驚くとともに、うれしく思った。また、本日の会合の結論となった、「フレームワークは道場！」という考え方は、今後の人材能力開発室のあり方を考える上で、極めて重要な考え方になりそうだと感じるのだった。

人材能力開発室に求められているのも、アーキテクトの役割にほかならないのではないだろうか。つまり、「人と知識の融合のアーキテクト」である。ビジネスの方向性から、教育研修から、人事制度から、コミュニケーションインフラに至るまで、常に全体像を把握し、能力開発のボトルネックが生じないように配慮しながら、能力開発が円滑に進んでいくようにする。まさにITアーキテクトと同じだと思うのだった。


図4：能力開発システムのアーキテクチャ

それにしても、営業部門も、商品開発部門も、今日のITアーキテクトの議論も、同じような結論に収斂していくとつくづく思う。すなわち、

• 将来像をロードマップで共有し、
• 情報を共通のフレームワークで整理し、
• お互いの認識を付き合わせることで、
• お互いに気づきが生まれ、
• 組織の中のムダが除去され、
• 新しいナレッジができあがっていく、

という結論だ。どうやら、研修コンテンツの効果的な整備についても、我々独自の方法ができ上がりつつあるようだ。いつもの3人で議論してみよう。


（本稿について突っ込んだ意見交換が出来る場として「ヒューマンキャピタルSNS」(無料、要登録)にて、本トピックのコミュニティ「能力は現場で開発できる」を設けております。ログイン後ページ上部の[コミュニティ]からどうぞ。みなさまのご参加をお待ちしております。）


著者紹介

今回パイロットプロジェクトを行う商品開発部門のグループでは3つの商品開発チームが走っており、その3チームがパイロットの対象である。営業部門と同じく、まずは時間の使い方と成果を週次ミーティングで確認することから始めていた。

もちろんこれまでもチーム毎に週次の進捗レビューは行っていた。だが、内輪の技術的な問題解決の話題が多く、進んでいるのか遅れているのか、問題がどれくらい大きいのか、会社としてサポートすべきなのか、経営者が聞いても分かるようになっているとは言えなかった。そこでまずは、週次ミーティングの前提として、商品開発のスケジュール管理フォーマットを共通化することで日々の進ちょくが見えるようにした。そうしてみるとやはり、高業績商品開発チームの特徴が見えてきた。

高業績チームは、この数年来ほとんど問題なく計画どおり商品を投入できている。製造段階になってからの仕様変更も少なく、市場投入後の施工フォローやクレーム対応に走り回ることも少ない。毎年のバージョンアップも想定された範囲内で収まることが多く、比較的苦労がない。一方、他の2チームは、機器や部品メーカーの開発の遅れや品質問題などトラブル解決に忙殺されがちであり、また既に市場に出した商品の施工サポートやクレーム対応に手間がかかっている。

一言で言えば、高業績チームは万事にわたって先手を打てていて、他チームはすべてが後手に回っている印象である。なぜそうなるのだろうか？具体的に活動の内容はどう違うのだろうか？

もう少し踏み込んで見てみたい。しかし顧客名や案件名という形で活動内容が分かりやすい営業と違って、商品開発者のスケジュールはそのまま見ても分かりにくい。そこで、活動の内容を見えやすくするために、最初の1カ月の活動時間を図のような枠組みで分類・集計することで各チームのメンバーの時間の使い方を比較することにした。そうすると以下のことがわかった。


図1：商品開発者がどこに時間を費やしているか

まず横軸の「プロセス」の軸で見ると、営業の高業績者と同様、商品開発の高業績チームもプロセスの上流に投入している時間の比重が高い。その内容として何をやっているのか話してもらうと次の通りだった。

• 文献に目を通し、技術動向をつかんでいる。
• 技術オタクなメンバーを専任として徹底的に情報収集させ、機器をつないでテストさせている
• 競合他社の商品についても展示会や顧客訪問を通じてウォッチしている。
• 商品の施工性や運用上の使い勝手などについてもサービス部門や顧客を訪問してよく情報を集めている。
• 試作・検証に非常に力を入れ、ショールームのデモシステムの活用度も高く、常にメンバーを張り付けている。
• 機器ベンダーをうまく使っている。開発の早い段階から機器ベンダーに提案をさせ、筋の良いベンダーを発見している。ベンダー側から見てもアルファ社とのつきあいは単に「もっと納期を早く」「もっとコストを安く」という話ばかりではないので熱が入るらしい。

次に、縦軸の「検討・活動対象」の軸で見ると、機器をつなぐシステムのインフラにあたる部分の検討に力を入れている。

• 通信方式の変化やICタグの出現など、大きな技術的な変化の中でシステムの基盤がどうなっていくのか、そこにどのような機器がぶらさがっていくのか、そのような議論、そして今後の見極めに力を入れている。

しかも、技術の調査や検証を闇雲に行っているのではない。今後の市場の変化や、技術の進化の方向性が、ロードマップとしてチームリーダーの頭に入っており、それに基づいて今後のアルファ社製品についての仮説を立て、その仮説が、情報収集、整理、試作、評価を導いている。つまり、仮説を検証する形で調査を行っているのだ。高業績チームのリーダーは「今後リリースする製品について3年後、5年後までのイメージを持てていれば大丈夫だと感じますね」と言う。

ロードマップとはどのようなものかと聞いてみると、図のようなものであるらしい。そして、チームリーダーは、IBMや村田製作所が用いているロードマップ手法、そして、松下電器が用いているテクノストーリー手法などを参考にしているという。また、経済産業省がとりまとめている『技術戦略マップ2007』も尽きない情報の源泉で、それを読むのが趣味だという。


図2：ロードマップのイメージ

高業績チームのやり方について他のチームのメンバーは皆大いに関心を持った。ほとんど全員ロードマップという言葉は知っているものの、実際に手を動かして作ったことはない。これはすぐに試してみる価値がある。まず、チーム毎に今後の「市場のロードマップ」「製品のロードマップ」「技術のロードマップ」の3枚のチャートを描き、それを持ち寄ってみる。そして3枚の対応関係をストーリーとしてプレゼンし合ってみる。単にそれだけのことなのだが、メンバーは口々に日頃いかに頭を使っていなかったかよく分かったと言う。そして、できあがったものは今後の思考の前提としていつも参照したいと言う。

また、メンバーは皆、これに時間を使うのは余計なこととは全く感じないと言う。というのは、そのまま商談ツールになるからだ。先進的な顧客と今後のセキュリティの課題とソリューションについてプレゼンテーションをして意見交換をすることで、顧客のニーズを検証できるし、機器ベンダーに見せることで、機器ベンダーから情報を得る目的も精度も高まる。

どうやら商品開発部門にとっては、このロードマップのプレゼンが、営業部門で始めたプレゼン研修に相当するものになりそうだ。そして、チーム間での突っ込んだ質疑応答は訓練の場になるとともに、関係部門を円滑に巻き込んで商品開発を進めていく上での問題を未然に洗い出すシミュレーションの場となる。

企業間の垣根がなくなる中でアルファ社が業界各社をリードしてアルファ・ブランドの中にとりまとめていくのが社長の言う企業運営の姿だ。実はこれは、ロードマップを率先して描くことで「情報リーダーシップ」をとっていくことに他ならない、ということが見えてきたともいえる。

「ロードマップを描くことが鍵というのは製品開発だけでなく、個人のキャリア開発においても言えるかもしれないな」と島さんは思った。キャリア開発ということを言いながら、自分が今後どのようにキャリアを形成していきたいのかロードマップとして具体的に描くということはしていないものだ。しかも、一度描いておけば、その後は常にそれを参照しながら能力開発ができる。

高業績チームは、ロードマップで仮説を立てているために情報収集が早い。チームリーダーは、情報収集・整理のポイントが頭に入っている。だから、技術オタクな部下に対して「何々を試してみて」と的確に指示を出せる。とは言え、技術の動向を把握し、将来予測を行う上では日々の体系だった情報収集と整理、蓄積が重要になる。しかも、商品開発では文献情報もまた重要であり、営業の案件情報と比べてその数が非常に多い。

そこで、技術情報を共有、蓄積するためのフォーマットを共通化しておくことにした。もっとも技術情報は件数が多い。他社で文献データベースを作ろうとしたら入力する項目数が多すぎて動きがとれなくなったという話も聞こえてくる。そこでフォーマットはできるだけシンプルに文章入力を主体とし、ただし何についての技術情報なのか分かるように、キーワード分類だけはシステムの全体像の共通理解に従ってプルダウン入力できるようにした。例えば「機能要件」であれば「1：ブロック」「2：アクセス」「3：鍵」などプルダウン入力できるようにしておく。


図3：情報整理のフォーマットイメージ

これを共有の技術情報データベースとし、読んだ文献や評価した製品などを登録していく。過去の重要文献についてもその重要性に照らして、過去の経緯を良く知るベテラン技術者にそれらを整理するミッションを課してデータベース入力を行ってしまった。

情報をとらえる網の目が整備されたことで情報の吸着力が増し、技術者一人ひとりがセキュリティ技術情報への感性を高め、組織として競合の動向や技術の進歩に対するアラートができるようになる。かつ、共有することで技術調査の無駄がなくなり、会社の知識資産の基盤になる。

もちろん従来も製品企画にあたっては競合他社製品の比較調査がなされており、そこではフォーマットも使われていたのである。しかし、担当者ごとにこれまで使われていたフォーマットを使いまわしていただけで標準化されてはいなかった。そしてフォーマットがばらばらであるのと同じだけ技術者の物の見方もばらばら、つまり統一されていなかったのである。フォーマットが統一されていなかったからデータベース化もされていなかった。

これまで一番広く使われていたフォーマットでは、顧客の視点から重要と考えられる項目が並んではいた。例えば「運用管理機能の充実」等々である。とは言え、今後重要になる製品のシステム化は十分意識されておらず、したがって「将来の拡張や新しい技術の接合を容易にするアーキテクチャ」といった今後重要となる視点が不足していた。

製品企画フォーマットとは、ある意味では力のある顧客がいわゆるRFI（Request For Information）を提示して各社の製品情報を収集、比較する時の表を、メーカー側から先回りして作成しているに等しい。そうなると、顧客に先回りしてこれから重要になるポイント、そしてアルファ社が重視する視点を啓蒙していかなければならない。これは、営業が顧客にセミナーを行い啓蒙する時の視点と同じである。そのようなわけで前回、商品開発側から営業に対して「非機能要件」の収集をもお願いしたい、という要望が出てきたのだった。

この検討を通して商品開発者のあるべき人材像も変わってきた。すなわち、ロードマップを描き、技術情報を収集し、試作・検証し、自社製品に取りまとめていくことこそが今後のアルファ社の商品開発者の中心的な役割である。ある意味では、技術や製品の開発者というよりも調査・評価を行うリサーチャーであるといっても良いかもしれない。

このような商品開発者像は、自社での機器開発が中心だったアルファ社の伝統的な技術者像とは異なるものであった。商品開発者のジョブデスクリプションの見直しにもつながる。そして情報を収集、整理することこそは商品開発部門のメンバーのコアスキルであると位置づけ、技術情報データベース充実への貢献を評価項目にする必要がある。そしてこれらは、今後の採用、人材育成やキャリア開発の方向性に大きな影響を及ぼすことになる。

あるとき、中沢さんは大学のクラス会で自社の取り組みについてIT業界にいる友人に話した。そうすると友人は大いに関心を持ち、それはIT業界でも大変に参考になる話だという。そして、「近々丁度、IT人材育成の勉強会があるのでそれに出てみないか」と誘われた。会合のテーマは「ITアーキテクトをいかに育成するか」であるという。中沢さんは参加してみることにした。


（本稿について突っ込んだ意見交換が出来る場として「ヒューマンキャピタルSNS」(無料、要登録)にて、本トピックのコミュニティ「能力は現場で開発できる」を設けております。ログイン後ページ上部の[コミュニティ]からどうぞ。みなさまのご参加をお待ちしております。）


著者紹介

営業部門の高業績者と島さんとで協力し合って出来上がったノウハウとは、これまでの導入事例、そして新しい営業先のニーズと提案内容を次のようなフォーマットの中に整理するというものである。さらに、当面の営業先のみならず、今後ターゲットとする業界についても、このツールを用いながら仮説を作成できる。


図1：顧客のニーズと提案内容を整理するツールのイメージ

このフォーマットと思考プロセスを共通言語として共有することにより、様々なメリットが得られることが明らかになってきた。

• このフォーマットで案件の特徴を整理しておけば、案件情報を共有化して、類似案件を参照することもやりやすくなる。
• 一つの案件について、チームで提案の可能性を話し合ってみることで、一人ひとりのニーズの引き出し方の得意・不得意分野が見えてきて、お互いに学びができる。
• 案件の全体像が見えるため、提案を組み立てるためにパズルのように埋めなければならない情報や知識は何かということがわかり、営業担当者が自分で商品開発部門に聞きに行ったりするなど、自律的に動けるようになってきた。

また、フォーマットを共有することで、当然、他部門とのコミュニケーションもうまくいくようになってきた。

• 経営管理部門からは受注予測が正確になったと評価されている。案件の正確な把握に基づいて受注確率を入力するようになったためである。
• 施工・サービス部門からは、早い段階で正確な情報が伝わるので、施工のための要員確保や機器発注がやりやすくなったと評価されている。機器によっては調達リードタイムが長いものがあるので、早く案件の内容を把握することは大切なのである。
• 商品開発部門からも、営業が整理したフォーマットを通じて、マーケット動向や顧客ニーズを把握できると評価されている。商品開発部門でもこれまで、独自に市場動向を分析してきたのだが、営業と商品開発とで情報の整理の仕方を共通化することで、協働がしやすくなってきた。商品開発部門が営業同行する場合も多くなってきたし、営業担当者の商品開発への提案も出てくるようになった。

また、商談の骨組みを、このフォーマットをベースに標準化できることが明らかになってきた。すなわち、次のような起承転結のストーリーで、それぞれのパートごとに2〜3枚の資料にまとめたプレゼンテーションを想定することで、商談の骨組みを標準化できるのである。

　【起】　顧客業界の特徴と商談の背景の整理
　【承】　安全性要件と利便性要件の整理
　【転】　安全性を確保しながら利便性を確保するためのポイント
　【結】　コストも考慮に入れた３種類のオプションと推奨案の提示



図2：ツールを使って商談の内容を組み立てる

商談の骨組みを標準化できることがわかったので、これまで外部の講師を招いて行っていた一般的な営業研修は廃止して、この骨組みに沿ったプレゼンテーション研修に一本化することにした。講師は営業部内のベテラン社員が持ちまわりで行うことにした。商談の組み立てのフォーマットがしっかりしているから、内部の講師でも研修を行える。アルファ社のビジネスと商品に特化したコンテンツだから社内講師の方が適している。最近の事例をケーススタディにして、受講者は提案を考え、プレゼンをし、講師が顧客の立場に立って様々な質問を出す。受講者はそれに対して応答することで、商談の場数を踏むことをシミュレーションできるのである。

さて、営業担当者がツールを活用することで、安全性と利便性のトレードオフについて、わかりやすく顧客に説明を行えるようになった。商品開発部門のメンバーを連れていく機会も多くなってからというもの、顧客から「社内向けに啓蒙のためのセミナーをしてほしい」という依頼がくるようになった。「そういう依頼があるならば、他社でもそのようなセミナーのニーズはある筈」。そこで、営業担当者で手分けして次のようなセミナーを提案してみることにした。

• 導入を実際に検討する前に、顧客内の関係者を集めてまずはセミナーを行う提案
• あるいは顧客の中で調査を行い、その報告会を行う提案
• 代理店と効果的に情報連携するための代理店向けセミナー

こうしてみると、徐々にアルファ社の営業プロセス自体が能動的なものになり、コンサルティングとも言えるものになっていることに気づく。中沢さんと島さんは当初、週次ミーティングを通じて営業担当者のスキルの弱点が見えてきた時、それを補強するために、おそらくは、コンサルティングスキル研修であるとか、ネゴシエーション研修であるとか、そういった教育研修をあらためて導入する必要が出てくるのではないかと予測していた。しかしどうやら、新たな教育研修の導入は必要ないようだ。

つまり、こういうことである。世界では今、情報を整理して方向性を指し示す「情報のリーダーシップ」が求められている。アルファ社のセキュリティ分野などは特にそうである。様々な情報が錯綜しているため、顧客企業も何が本当の課題で何から取り組んだらいいのか整理できないでいる。そこへアルファ社がきれいに情報を整理できるフレームワークを持って顧客に接することで、アルファ社しか提供できないユニークな価値に顧客も喜び、アルファ社自身にもさらに情報が蓄積され、好循環が生まれ始めている。

そのようなアルファ社のユニークな価値の根幹となるノウハウを営業担当者全員で自家薬籠中のものにすることこそがアルファ社の営業担当者の能力構築の近道なのだ。そして、その過程でおのずからコンサルティングスキルも、ネゴシエーションスキルもついてくる。自社のロジックが自家薬籠中のものになっていないのに、コンサルティングもネゴシエーションもあったものではない。

これでアルファ社の営業担当者がコンサルティング職にシフトしていく道筋も見えてきたと言えそうである。「コンサルティングビジネスへのシフト」ということで構えて一般的なコンサルティングスキル研修を広く導入する必要などはなかったし、コンサルティング業務の経験者をチームとして引っ張ってくる必要もどうやらなかったのである。

以上のような取り組み状況を能力開発委員会にて報告したところ、社長から「それはウェブマーケティングにもつながるのではないか」という指摘が出た。

つまり、顧客ニーズの明確化とソリューションへの落とし込みがそこまでフォーマット化できてきているのであれば、それは顧客接点を劇的に改革することにもつながる。例えば、ウェブを通じて顧客自らが課題を明らかにし、解決策を探すことができるようなセキュリティポータルを実現できるのではないか。しかも、新規顧客開拓だけではなく既存顧客へのサービスとしても有効ではないかという指摘である。

情報を整理するフォーマットをオペレーションの中心に据えることで、顧客と営業部門、商品開発部門、サービス部門とが情報を共有し、顧客のセキュリティ施策の妥当性を常にチェックし、最新のものにアップデートしていく仕組みができるのではないか…この検討はまさに、サービス・カンパニーに変身するという中長期ビジョンの具体化の検討そのものである。

その可能性の検証と具体化に向けて、マーケティング室中心に検討していくことになった。

さて、商品開発部門から営業部門の情報整理フォーマットに対して要望が出てきた。「セキュリティ要件」および「利便性要件」という「機能要件」に加えて、「非機能要件」も整理できるようにしてほしいというのである。非機能要件とは、「運用容易性」「将来の拡張性」「他の機器との連携性」など、セキュリティ機器をシステムとして維持管理したり、今後の拡張を行ったりする上で重要になってくる要件である。

確かにそれらの視点は、導入後の維持管理、そして将来のアップグレード提案を考えた時に重要になってくる。それは、アルファ社の視点から重要なだけでなく、顧客にとっても今後重要になることであり、今後大きな差別化のテーマになりうる。

実は、商品開発部門の側でもパイロットプロジェクトを行いながら同じことが話題になっていた。今後のアルファ社の商品開発においては「非機能要件」へのセンスが重要になるであろうということ、そして、このセンスこそが単なる製品開発者ではない「製品アーキテクト」に求められるものであろうということだった。

ここで、商品開発部門におけるパイロットプロジェクトの様子を見てみよう。


（本稿について突っ込んだ意見交換が出来る場として「ヒューマンキャピタルSNS」(無料、要登録)にて、本トピックのコミュニティ「能力は現場で開発できる」を設けております。ログイン後ページ上部の[コミュニティ]からどうぞ。みなさまのご参加をお待ちしております。）


著者紹介

いよいよ営業部門のパイロットプロジェクトからスタートする。能力開発室の3人は、まず、対象職場グループのグループ長とトレーナーを交えて、作戦会議を行った。グループ長は、週次ミーティングで使うフォーマットのイメージを見て言う。(【第6回】「こうすれば職場に週次学習を導入できる」を参照)

「これは大変ですね。確かに、営業ステップを標準化し、それぞれのステップにおける実施事項のチェックリストを作って営業能力の底上げをする、というのは数年前から懸案事項でした。しかし、島さんもついこの前まで営業企画にいたのでご存知の通り、多様な顧客に対する多様な営業ステップを標準化するというのは簡単なことではなく、頓挫しているわけですよ。この機会にそれを完成させるというのは良いことだと思いますが、時間がかかりますよ。もっと簡潔にできないでしょうかねえ。」
島さん

島さんは言う。

「そうですね、シンプルに始めましょう。まずは、仮説、検証のPDCAサイクルを回し始めるのが肝心なのです。そのためには差異が見えればいいのです。思惑と実績の差異や営業担当者による差異を目の当たりにすることができて、その原因を考えることができれば、そこから学びが始まります。」

そこで、まず、次の内容の週次ミーティングをスタートすることにした。

• 営業のインプットにあたる一週間の時間の使い方のレビュー。時間の使い方が望ましく計画されているかどうか、そして計画された通りに実行できているか、という見地から週次レビューを行う。

理想を言えば、どのように時間を使うべきか定量的に標準を設定したい。例えば、週に何件訪問し、何件提案書を提出していなければ受注目標を達成できない筈か、など。そして標準との差異に基づいて議論をしたい。しかし、そのためには営業のモデルを作り、データをとって検討しなければならない。

そこまでやらなくても、スケジュールをお互いに見えるようにしておくだけで、高業績者Aさんの時間の使い方と平凡な業績のBさんの時間の使い方とを比較して、なぜどう違うか、という議論はできるし、そこから大きな学びができる。例えば次のような着眼点から違いを議論できる。

• 既存顧客と新規顧客に使う時間の比率はどうか
• 営業先の「数」と「質」とのバランスはどうか
• どの段階で、継続訪問する／しないというのを見極めているか
• どのような場合に上司や他部門を連れていっているか
• 提案書作成などのペーパーワークはいつ行っているか

営業担当者によっては、スケジュールの公開を大変に嫌がりそうである。しかし、現実の姿をチームで直視しないことには学びは始まらない。そもそも勤務時間中の時間の使い方というのは会社にとっての最重要リソースであって、それを公開するのが嫌だという理屈は通らない…と言うことにする。次のことをルールにすることにした。

• 壁際にかけられていた行き先掲示板を廃止する。
• スケジュール管理用のソフトを一本化する。
• その上でスケジュールは上から下まで全員公開し、閲覧・更新可能にする。
• 外出中でも携帯電話などのモバイル機器で常に最新の状態にしておく。
• 機密情報についてはパスワードで保護する。

以上のようなスケジュールのレビューのほか、もう一つは営業活動のアウトプットのレビューである。そのためには「案件管理表」を用いることにする。それは営業案件が発生する都度、「ニーズの種類」、「予定商品構成」、「受注予定金額」、「施工時期」、そして「受注確率」などを登録するものである。従来から使われていたものだが、月一度の業績予測用の事務作業と見なされており、更新は月一度まとめてやるだけで、受注確率などもかなりいい加減に入力されていた。それを今回、日々のマネジメントツールとして用いることにしたのである。

案件管理表をチームメンバー間でお互いに見えるようにするとともに、これについても情報を最新の状態に保つことを義務づけることにした。また、受注確率についても、各人の判断力を駆使してできる限り精度高く入力するものとした。なぜ受注確率を○％と判断したのかということ自体がお互いの学びの材料になるからである。

以上のように、営業活動のインプットであるスケジュールと、アウトプットである案件管理表とで週次ミーティングができる。毎週全員分のレビューをしなくても、その場で指名して一つの案件についてレビュー、アドバイスしあうだけでも大きな学びができる。そして、必要とあれば、翌週のスケジュールにすぐ、営業同行でも何でも組み入れることができる。

2、3度週次ミーティングを行ったところ、早くも高業績者の特徴が誰の目にも明確に見えてきた。高業績者は受注確率の判断の仕方が実に適確で、しかもその判断を早い段階で行っているのである。その結果、抱えている案件のポートフォリオがうまく組まれているのである。最終的な成約件数を1とした場合の、成約に至る前までの手持ちの案件数を高業績者と平均者で比較すると、次の図のような具合である。


図1：高業績者と平均者の案件ポートフォリオの比較

提案書を出す先をうまく絞り込めているから案件の金額も大きく、商談の効率も良い。したがって、活動に余裕が生まれ、案件開拓のための活動にも時間を割くことができる。さらに案件の母数を多く持つことができ、そこから好循環が生まれている。

なぜうまく絞り込めているのだろうか。次のことが鍵になっていることがわかってきた。

• 早い段階で顧客の意思決定のポイントを見極め、導入のオプション（選択肢）を提示して、顧客の反応を見ながら、顧客の要望の背景、切迫の度合い、予算の度合い、競合の存在などを判断している。

なぜそのように効果的に導入のオプションを提示できるのだろうか。週次ミーティングを延長して、高業績者に最近の提案事例をあらためてチームメンバーのためにプレゼンしてもらい、皆で検討してみた。そうするとアルファ社のセキュリティソリューションを「安全性と利便性のトレードオフをいかに解消するか」というストーリーで提案をしているから顧客にとって大変分かりやすいのだということがわかってきた。


図2：安全性と利便性のトレードオフを踏まえた効果的な提案法

セキュリティ施策の問題とはつまるところ、「安全性」と「利便性」をいかに調和させるかということである。例えば、鍵を多くすればするほど安全にはなるが、一方では管理が煩雑になり不便になる。しかし、鍵を一つに統合すれば煩雑さは解消され、利便性も以前よりもかえって高まるかもしれない。それが提案のしどころである。このような思考の枠組みが顧客の利害にも沿っているから、顧客と一緒になって落としどころを探ることができるのである。

また、高業績者は日々業界雑誌などを読んだりしながら、このトレードオフのフレームワークを頭の中に置いて、読んだ事例のポイントを抜き出し、格納してしまうようだ。あるいは日々街を歩いていても、プロらしく目を配り、新しい動向があるとそれを頭の中に格納してしまう。問題意識があるからそれができる。そして、顧客を訪問すると、頭の中に格納してある事例を参照することで、説得力を持って提案できるらしい。

そのような情報整理の仕方を高業績者に公開してもらうことにした。もちろん高業績者としては、自分のノウハウを同僚に説明しようと思って日々の仕事を行っているわけではない。また、できればそのようなことに時間を使いたくないというのが本音である。

そこで、それを島さんがサポートすることにした。というのも、島さんは以前、営業企画部門で営業ツールをとりまとめていた時に「ニーズ抽出チェックリスト」を作成したことがあった。高業績者も島さんがとりまとめたチェックリストを大いに活用しており、それが彼のノウハウの一部分ともなっていたのである。その意味で島さんに対して借りがあったのだ。

「以前に営業企画で作成したチェックリストと、高い業績を上げているAさんの頭の中のチェックリストを組み合わせればさらによいものができあがります。ぜひそれを能力開発委員会でも発表してください。そして今後、アルファ社の標準ノウハウとして全国営業拠点に広げましょう。」

島さんの呼びかけで高業績者も忙しい中協力してくれることになった。インセンティブが大切である。そしてその結果、さらにいろいろなことが見えてきたのである。


（本稿について突っ込んだ意見交換が出来る場として「ヒューマンキャピタルSNS」(無料、要登録)にて、本トピックのコミュニティ「能力は現場で開発できる」を設けております。ログイン後ページ上部の[コミュニティ]からどうぞ。みなさまのご参加をお待ちしております。）


著者紹介