突然の話で恐縮だが、本日6月30日をもって、会社を退職した。

　入社が2006年3月だったので、5年半近く在籍したわけだが、振り返るといろいろあった。コンサルティングや研修でお世話になったお客様や、マーケティング関連で一緒に仕事をした取引先の方々からは、本当にたくさんのことを勉強させてもらった。この場を借りて厚く御礼申し上げたい。

　翻って社内の方を思い返してみると、やっぱりベンチャーというのは難しいとしみじみ感じる。私は前職もベンチャーだったが（アビームコンサルティングの元子会社。現在はアビームコンサルティング本体に吸収されている）、親会社がしっかりしていたこともあって、創業時から事業内容や社内制度がある程度確立されていた。それに対して、今回の会社は本当に何もないところからスタートした純粋なベンチャーであった。

　社内の人たちから何かプラスの意味で学んだことがあるかと問われれば、正直なところ「ほとんどない」と答えざるを得ない。逆に、反面教師的に学んだことならば、最低でも50個は挙げられる自信がある。今はそれらの教訓について詳しく書けないけれども、いつか書ける日が来ることだろう。

　1つだけ重要な教訓を挙げると、「ベンチャーでは、適切な人材の採用が最重要だ」ということである。『ビジョナリー・カンパニー』の著者であるジェームズ・コリンズは、事業の方向性を決めてから人材を採用するのではなく、「まずバスに適切な人材を乗せてから、方向性を決めることが大切だ」と力説していたが、この言葉の意味がもう本当に痛いほどよく解った。

　ベンチャー企業にとって、人材の採用は、製品開発や営業活動と同じくらい、あるいはそれ以上の重みがある。大企業であれば、数百人〜数千人単位で採用した中に数人から数十人ぐらい変な人材が混じっていても、リスク分散が可能である。これに対し、ベンチャーは人数が少ない分、1人の採用の失敗が命取りになりかねない。

　こう考える読者もいるだろう。「経営の常識ではないか、適切な人材を集めるというのは。どこが新しいというのか」と。ある意味ではたしかにそうだ。昔から説かれている経営の鉄則のひとつだ。しかし、良好から偉大に飛躍した企業には2つの際立った特徴があり、常識とは異なっている。（中略）

　まずはじめに適切な人をバスに乗せ、不適切な人をバスから降ろし、その後にどこに行くかを決めること、これが要点である。もうひとつ、第二の要点として、偉大な企業への飛躍には、人事の決定に極端なまでの厳格さが必要なことがあげられる。

　売上高の伸び率がつねに適切な人材の伸び率より高ければ、偉大な企業を築くことはできない。偉大な企業を築いてきた人たちは皆、企業が成長していくときに最大のボトルネックになるのが、市場でも技術でも競争でも製品でもないことを理解している。どの要因よりも重要な点がある。それは適切な人びとを採用し維持する能力である。

　個人的には、事業の方向性が本当に全くの白紙状態というのはあまり望ましくないと考える。コリンズがこの鉄則を導いたのは、ヒューレット・パッカードの創業者が、操業当初は売れるものなら何でもなりふり構わず売っていた、という事実があったからだと思われる。

　現実的な話をすれば、「向こう3年ぐらい、最低でも直近の1年間は、何を武器に市場で戦うのか？」を大まかに構想した上で人材を採用するのが普通だろう。しかし、採用自体はコリンズの言う通り、慎重に行わなければならない。ベンチャーは慢性的に人手不足であり、対外的な知名度もないに等しい。したがって、求人への応募があったらすぐにでも採用したいという誘惑にかられる。だが、そこをぐっと我慢して、目の前にいる応募者が本当に自社にフィットする人材かどうかを見極める必要がある。

　では、何を基準に採用の可否を決めるのか？それは、

（1）自社（あるいは創業者）の仕事に対する価値観に合致しているかどうか？
（2）（多少弱みがあるとしても、それを補って余りあるほどの）傑出したスキルがあるかどうか？

という2つに尽きる。逆に、「ビジョンに共感しているかどうか？」や「やる気があるかどうか？」は基準にならない。まして、「面接でたまたま意気投合したから」とか、「自分と馬が合いそうだから」という理由は論外だ。ベンチャーが欲しい人材は、「明日からすぐにでも仕事を任せられる人材」である。ビジョンに共感しているかどうかは、応募者本人の主観的な問題であり、人材の質を見極める材料にならない。また、「やる気」は本人を取り巻く環境や時期によって変動するし、会社側もやる気を（いい意味で）操作できるから、これもまた決定打にはならないのである。

　菅総理が自民党の浜田和幸参院議員を総務政務官に起用した「一本釣り」が物議を醸しているが、総理が「浜田議員の復興に対する強い意気込みを買った」と発言していたのをTVで見た。要するに、総理は浜田議員の「やる気」を起用の基準にしたわけだ。しかし、ベンチャーではこの手の採用はたいてい失敗する。そして、今回の一本釣りも、浜田議員が与野党の期待に十分に応えられずに終わる可能性が高いだろう。

　価値観と能力が判断基準になるのは、この2つは変動しにくいからである。さらに、能力の高さよりも価値観の合致の方が大切だと言える。能力の高さが採用の基準になる理由は自明であるにしても、価値観の合致の方が優先されるのはなぜか？それは、価値観は社内の様々な意思決定に対してダイレクトに影響を及ぼすからだ。

　例えば、「商談で敗れたら、敗因をきちんと分析して反省する必要がある」という価値観を持った人と、「ベンチャーのうちは結果オーライで成果が出ればOK」という価値観を持った人が一緒に仕事をすれば、営業会議は破綻するに違いない。価値観が違いすぎると、2人の能力がどれだけ高くても、2人の人間関係はギクシャクしてしまうのである。

　ベンチャーは、社内の制度やルールの整備がどうしても後回しになりがちだ。しかしながら、採用については前述の2つの基準に沿って人材を見極めるプロセスを早い段階で作るべきである。そのプロセスの構築には、製品開発や営業活動と同じくらいの時間を費やすだけの価値があると断言できる。

　まだまだ書きたいことはたくさんあるのだが、それは「書ける時期が来たら」ということにしておこう。なお、7月からの私の活動については、明日このブログで発表する予定である。

	ビジョナリー・カンパニー ― 時代を超える生存の原則 ジェームズ・C. コリンズ 日経BP社 1995-09
	ビジョナリー・カンパニー 2 - 飛躍の法則 ジェームズ・C. コリンズ 日経BP社 2001-12-18

RFP&提案書完全マニュアル 永井 昭弘 日経BP社 2005-07 おすすめ平均： 永久保存版RFP本 とてもわかりやすいRFP指南書 RFP入門者向け

　（前回からの続き）

　本書で紹介されているITのRFP（提案依頼書）を参考に、研修のRFPの雛形を考えてみた。まだまだブラッシュアップする余地があるけれども、ひとまずたたき台として載せておく。

（1）背景
　「何のために研修をやるのか？」という研修の目的を記述する。ここはITのRFPと同様、ビジネス上の目的でなくてはならない。逆に言うと、単に「営業担当者の提案力を強化する」とか、「新任管理職にマネジメントスキルを習得してもらう」といったスキルレベルの目的を書くだけでは不十分である。なぜなら、これだけではあまりに抽象的であり、読む人によってはいかようにも解釈できてしまうからだ。

　スキルの具体的な中身は、そのスキルが自社の目指している経営・事業の文脈の中で語られて初めて明らかになるものである。経営・事業の方向性と習得すべきスキルの関係性が明確でなく、漫然と「○○スキルを強化する」といった目的しか掲げられないのであれば、ベンダーに研修を依頼しない方がいい。そういう場合は、書店で売っている一般書籍を会社で購入して、社員に配布した方がはるかに安上がりだよ。

《例》
　（a）（BtoB企業を想定）当社がビジネスを展開している市場は成長期にあるため、新規の顧客企業をスピーディーに獲得していかなければならない。そのためには、顧客企業のキーパーソンを商談の初期段階で握り、キーパーソンの潜在ニーズを先取りした提案内容を素早くまとめることが重要である。ただし、営業担当者が1人で提案書を書き上げるのは現実的ではない。そこで、社内の営業スタッフや技術支援部隊などを活用して、”チームで営業を行う”というスタイルを営業部門全体に浸透させることが必要と考える。

　（b）（BtoC企業を想定）当社の強みは、店舗における顧客へのきめ細かいサービスである。ただ、事業の拡大によって多様な顧客が店舗を訪れるようになっており、しかも顧客のニーズは変化しやすい。顧客が再び来店してくれるかどうかは、「顧客が店舗を訪れるたびに『あっ！』と驚くようなサービスを販売スタッフが提供できるかどうか」にかかっている。販売スタッフの上に立つ管理職は、自らの成功体験や従来のやり方をスタッフに押しつけるのではなく、スタッフから新たなアイデアがどんどんと出てくるような風土を醸成しなければならない。

（2）育成対象者
　研修対象者の人数、所属事業、職種、職位、年次、これまでの業務経験などを記載する。

（3）研修のゴール
　ITのRFPで言うところの「業務要求」に該当する部分。（2）の育成対象者に、研修を通じて習得してもらいたい知識やスキルを記述する。ここでも「○○力の習得」といった抽象的な表現で終わらせず、「研修を通じて、社員に何ができるようになってほしいのか？」という具体的な業務・行動レベルで書くのが望ましい。

《例》上記の（a）、（b）を例に取ると、

　（a）・商談の初期段階で、ビジネスポテンシャルの大小を見極め、商談の優先順位をつける。
　・顧客企業内のパワーポリティクスを把握し、キーパーソンを特定する。
　・窓口担当者の情報や顧客企業のHP、その他公知情報などを活用して、キーパーソンの潜在ニーズについての仮説を立てる。
　・インタビューでキーパーソンの潜在ニーズを聞き出す。
　・社内関係者との打合せ（社内関係者に顧客企業の潜在ニーズを伝える、自社製品・サービスと顧客ニーズの適合性に関する意見をもらう、提案シナリオを検討する、提案に向けた作業分担を行う、など）におけるファシリテーションを行う。
　・社内関係者が作成した提案書のレビューを実施し、アドバイスを提供する。
　・プレゼン時に、キーパーソンに対して提案書の内容を短時間で伝える。
　・プレゼンの結果や商談の結果を社内関係者と共有し、今後に向けた課題を整理する。

　（b）・販売スタッフと密にコミュニケーションをとる時間を確保し、現場で得られた気づきを聞き出す（今までにないタイプの顧客がいたか、その顧客にどういうサービスを提供したか、など）。
　・販売スタッフの意見の善し悪しをいきなり評価せず、まずはスタッフが自らアイデアを生み出したという姿勢を肯定する。
　・その上で、管理職自身がよいと感じた点をスタッフに素直にフィードバックする。
　・自社の価値観や行動規範に照らし合わせると、「もっとこうした方がいいのではないか？」と思う点については、販売スタッフに対して問題提起をする（決して、管理職自身の見解を押しつけてはいけない）。
　・スタッフのアイデアのうち、他のスタッフにもぜひ学んでほしいアイデア（横展開するアイデア）を選定する。
　・勉強会などの形式で、定期的にアイデアの横展開を行い、他のスタッフからも意見を引き出す。

（4）研修に対する要求
　ITのRFPで言うところの「技術要求」に該当する部分。ここは、研修の「内容」と「運営」に関する要求の2つに分けられる。内容面の要求には、研修の中で是非取り上げてほしいトピックスや、逆に絶対に教えないでほしい事柄（実際、こういうリクエストを受けることもたまにあるよ）などを入れる。また、「演習を多く取り入れてほしい」、「個人ワークではなく、グループワークを中心にしてほしい」という要望も内容面の要求に入る。

　運営面の要求とは、研修期間（何日間の研修なのか、あるいは第1・3土曜日に1日ずつ実施してトータルで2日研修とするのか、など）や、研修開催場所（自社の研修センターなのか、合宿形式でどこかのホテルに宿泊するのか、研修ベンダーの施設を使いたいのか、など）のことである。

（5）講師に対する要求
　これは「技術要求」の一部とも言えるが、講師の人柄やスキル、経験、経歴が研修導入の可否を握ることも少なくないので、別項目として切り出した。

　・自社と同様の業界における業務経験がある講師にしてほしい。
　・社員のモチベーションが下がり気味なので、『褒めて伸ばす』タイプの講師にしてほしい。
　・社内の人間があれこれ言ってもさほど効果がないので、外部の目線から厳しくアドバイスができる講師にしてほしい（こういうのも実際にあるリクエスト）。

など、講師そのものに対するニーズをまとめる。

（6）事前準備・事前課題に対する要求
　ITのRFPで言うところの「運用要求」に該当する部分。ただし、研修終了後だけでなく、研修の前から継続的なフォローを必要とすることがあるため、「事前」と「事後」で分けた。小演習や診断、テストなどの事前課題を実施したい場合は、その旨を記載する。

　なお、新しい研修を導入する際に、「現場の協力や理解をどのようにして得るか？」をめぐって、人事担当者が頭を抱えるケースがある。特に管理職の人たちは、部下を研修に出席させることで現場の業務に支障が出ることを恐れて、ネガティブな態度を取りやすい。現場へスムーズに研修を導入する方法について、ベンダー側から何かしらの提案を受けたい場合も、その旨を書いておく。

　手前味噌で申し訳ないけれど、私の会社では、部下が受講する研修を半日程度にまとめたダイジェスト版を管理職向けに実施したり、上司と一緒でなければできないような事前課題を企画したりすることがある。

（7）事後フォロー・事後課題に対する要求
　これは、学習効果の検証に関わる要求である。まず、短期的な検証としては、研修からそれほど日が経たないうちに小テストや事後課題、診断をやってもらい、研修前のスコアとの比較をする、という方法がある。

　中長期的な検証としては、短期的な検証と同じような方法でスコアを算出して、得点の推移を見るという手もあるが、これ以外にも「フォローアップ研修」を開催することもある。例えば、研修から半年後に同じメンバーに集まってもらい、

　・研修での学習内容をどのくらい現場で実践したか？
　・実践にあたってどんな課題があったか？
　・その課題をどのようにクリアしたか？
　・未解決の課題は何か？

などを議論して研修内容の定着度合いを把握し、さらなる継続的な取り組みを促すことを狙いとしている。フォローアップ研修は手間がかかるが、スコアだけでは解らない成果や課題を発見するのには適している。こうした事後フォロー・事後課題に関する要望があれば、ここに記述する。

（8）予算
　研修1回あたりのおおよその予算を記述する。なお、事前／事後課題やフォローアップ研修、診断などの付加的要素を検討している場合は、その分の予算を別途確保しておく必要がある。

（9）スケジュール
　研修ベンダー決定から研修開催まで（事後課題・事後フォローがある場合は、その分のスケジュールも含む）の大まかなスケジュールを記述する。ベンダーが持っている研修コンテンツのカスタマイズに要する期間や、受講者の募集期間などを考慮しておく。

（10）特記事項
　ITのRFPと同様、提案書に盛り込んでほしい内容、提案書の提出〆切、提案書提出以降のスケジュール、RFPに関する問合せ窓口などを記述する。

RFP&提案書完全マニュアル 永井 昭弘 日経BP社 2005-07 おすすめ平均： 永久保存版RFP本 とてもわかりやすいRFP指南書 RFP入門者向け

　IT業界は自らを建設業界と比較して、業界の未熟さを嘆くことがある。IT業界の方々からは、「建築だと工数の見積がかなり正確にできるのに、ITではスケジュールの見積が甘い」とか、「プラントや工場の建設では投資対効果を算出するロジックが確立されているのに、ITの投資対効果をちゃんと算出しているベンダーは少ない」といった話をよく聞く。本書も、「建設業界ではRFP（提案依頼書）の決まった形式が存在するが、IT業界にはそういうものがない」という問題提起から始まっている。

　私は、研修業界はIT業界とよく似た業界であると思っており、さらにIT業界よりも深刻な問題を多数抱えていると感じる。研修のRFPをちゃんと出して、研修ベンダー向けに説明会をやってくれる企業は、本当に一部の大企業に限られる。たいていのケースではRFPなんて見たことがないし、まして業界全体で標準的に使われている雛形なんぞあるはずもない。

　研修とITでは投資規模が違うし、最初にしっかりと仕様を決めておかないと後になってプロジェクトが炎上しやすいITに比べれば、研修なんて実施の直前まで中身の修正がきくから、RFPなど必要ないという意見もあるだろう。だが、金額に関して言えば、本書の中で「数百万円程度の小規模なIT導入でも、RFPは作成すべきだ」と述べられている。研修業界でも数百万円の案件ならざらにあるし、研修対象者が多くて同じ研修を何十回もやるケースでは数千万単位になる。個人的に、金額の多寡がRFPの要不要を決めるとは思わない。

　また、確かに研修の直前まで中身を修正することは可能ではあるが、とはいえやはり、早い段階で中身がきちんと決まるに越したことはない。それをせずに、研修ベンダーと顧客企業の間で会議を重ねながら、徐々に中身を擦り合わせていこうとすると、途中で「言った、言わない」の押し問答になりやすい。そういう意味でも、最初に「どういう研修をやりたいのか？」をRFPという形で文書化しておくことは重要だと思うのである。そして、研修ベンダーはRFPに書かれている要求を十分に理解し、さらに行間を読んで最適な提案を行う、というのが理想的な姿ではないだろうか？？

　ちなみに、本書で提案されているRFPの雛形はこんな感じ（太字は本書の用語、補足説明は私がつけた）。

（1）趣旨
　システム導入の「目的」を明示する。「業務効率化をしたい」、「システムの操作性を高めたい」という業務・ITレベルの話ではなく、「新しいシステムの導入を通じて、どういう事業・ビジネスを目指したいのか？」という経営レベルの方向性を述べる。

（2）業務要求
　システム導入によって実現させる業務の内容を記述する。これは、（1）の「将来的な事業・ビジネスの方向性」を実現するために、「自社の社員は具体的にどのような仕事・動き方をしなければならないのか？」という問いに答える形で記述するとよい。例えば、「顧客囲い込み型のビジネス」という方向性を掲げたならば、

　・ロイヤルティの高い顧客を識別するターゲティングの実施
　・顧客の優先順位に基づく営業担当者のきめ細かいフォロー
　・メールを活用した自社HPへの効果的な誘導
　・購買履歴を活用したおすすめ製品・サービスの紹介
　・定期的な顧客満足度の実施（定量・定性の両方）

などが業務要求となるだろう。

（3）技術要求
　ここはシステム的な要件を書くところ。例えば、「当社が指定するハードウェア、ソフトウェア、OSを使ってほしい」とか、「Webの検索レスポンスは○○秒以内にしてほしい」とか、「パート、アルバイトの方でもすぐに使えるように、画面インターフェースは簡単なものにしてほしい」といった技術面の要望が入る。

（4）運用要求
　システム稼動後の運用・保守に関する要求。「24時間365日のサポートを希望するのか、ビジネスアワーだけのサポートだけで十分なのか？」、「自社で運用・保守できるように保守要員のトレーニングまでお願いしたいのか、運用・保守はベンダーに全てアウトソーシングしたいのか？」など。

（5）予算
　想定している予算。システム導入時にかかるイニシャルコスト（ソフトウェア、ハードウェア、SE、コンサルタントの費用など）と、導入後のランニングコスト（ソフトウェア、ハードウェアのライセンス更新料、運用・保守コストなど）に分けて、大まかな金額を載せる（予算を載せるかどうかは意見が分かれるところだが、本書では駆け引きなしに予算を素直に載せた方がトラブルが少なくて済む、とされている）。

（6）プロジェクト期間
　プロジェクトのキックオフから要求定義、設計、開発、テスト、リリースに至るまでのスケジュールを記載する。

（7）特記事項
　提案書に盛り込んでほしい内容、提案書の提出〆切、提案書提出以降のスケジュール、RFPに関する問合せ窓口などを記述する。

　上記の雛形を参考に研修版のRFPの雛形を考えてみたので、次回はそれについて書くとしよう（今日の記事は前置きだけで終わってしまった、汗）

　（続く）