ここでは プロジェクト企画の提案書の承認を得る前に、情報を仕入れたり、社内の雰囲気や温度を知っておくことです。
そのために行うことについてお話しします。これらの努力をしておくことで、プロジェクトがスムーズに承認されスタートすることができるのです。
■ 日本型合意形成は全会一致
時間をかけて、問題点や具体的な課題の抽出ができて、さらにそれらの優先順位付けもでき、ある程度、ドキュメントも揃ってきたとしても、それを社内で承認を取るためには別な努力が必要です。
いわゆる「日本型合意形成」をよく理解しておくことです。日本型合意形成とは、会議で常に全会一致で決定され、一度決定した内容は、会議参加者が全員賛成ですので、必ずその計画通り進められるといったものです。
一方、西欧では会議ではディスカッションが行われ、反対意見もあります。会議でも、日本のように全員が一致して「Yes」と言うわけではありません。そして、一度決まっても、その後にも変更があればまた変更が追加されますし、期日通りに日本のようには終わらないこともあります。
私も、イタリア本社と日本のチームでプロジェクトを進めているときに、イタリア本社のあるメンバーが退職してしまい、プロジェクトが中断してしまったことを経験しています。新しい担当者が採用されるまで、そのタスクは一旦ストップすると連絡を受けたこともありました。
日本では、もしプロジェクトの誰かが辞めると、きちんと業務の引き継ぎをして、その仕事がストップしないようにマネジメントするものです。それは、全会一致で会社で決まったプロジェクトですから、必ず期日通りに終わらせなければならないと言う使命感が働くからだと私は思っています。
全会一致とは言いながらも、表面上は「Yes」と言っておいても、心の中ではあまり賛成していないという人もいます。しかし、表面上「Yes」と会議で賛成を示した以上、プロジェクトには協力せざるを得ないのです。ですから、こうした全会一致の状況になるまでには、個別でのコミュニケーションと根回しが必要になるのです。ここは政治と同じかもしれません。
企業は、日々運営されていますし、その都度その都度に根回しをしたり、個別のコミュニケーションをすることには労力もかかります。そこで、私が勧めている方法は、社内経営陣に対して、まずはサプライズを起こさないようするために、月例会議やシステム関連の全社会議の中で、近い将来に提案するであろうシステムプロジェクトについては、予告編として、少しずつで良いので情報を出して反応をあらかじめ見ておくことです。
例えば、突然、提案を出すと、「私は聞いていない」とか「自分だけ疎外されているのでは」と受け止め感情を害する方々もいます。また、そもそも、社長や経営陣も、会議で今さっき説明を受けたばかりで、本当にそうなのかどうかという実態もよくわからないまま、提案を受け入れることもなかなかできないのです。
したがって、月例経営会議や予算編成会議などで、システムプロジェクト化する問題点や課題については、概要を少しずつ出しておくことです。その出し方は、具体的に出す必要がありません。「こういった問題点があるので今検討中である」といったコメント程度で良いのです。そして、その次の会議では、その続報として短い報告をするのです。
つまり何かイベントの予告のようなもので、こうした予告を、数度にわたって何かの機会ごとにやることです。こうして、時間をかけて組織内のムードを盛り上げていくことです。 そうすることによって、プロジェクト企画案を出したときに、「あぁ、あれね」といった感じで受け入れてもらえやすくなります。
そして、特にキーパーソンとなるような方については、まめに情報交換して、自分たちが困っていることについてよく説明をすることです。そして、自分たちの仲間に引き込み、プロジェクト企画を承認してもらうための下準備をしておくのです。
■ 旧知のベンダーに他社事例を聞く
普段からお付き合いのあるベンダーさんや、セミナーなどで、広くシステム導入や技術の情報を事前に集めておくことです。特に、競合他社の状況については、経営陣はとても敏感です。自分が提案するプロジェクト企画が、競合他社では一体どうなっているのか、と言うことも調べておくことです。
ただし、自分で調べるには限界がありますので、いちばん早いのはベンダーさんにいろいろな情報提供していただくと言うことです。例えば、ロイヤリティープログラムについては、どの会社がポイントをどのように付与して、どういったサービスと交換しているか、あるいは、ディスカウントにしているか、といったことを会社別にきちんと調べておきます。
もちろん、社内の営業担当や責任者は、他社がどういったサービスを提供しているかわかっているのですが、きれいにまとまったものはなかなか持っていません。ITの視点から、CRMについて、どの会社がどの仕組みを使ってお客様とのコミュニケーションをとっているのかということを一覧表にまとめるのです。そして、それを経営会議などで報告すると、期待以上に喜ばれます。
具体的な事例の情報は、ベンダーさんが多く持っています。特に、ベンダーさんの営業マンは売り込むことがまず念頭にあるので、冷静な客観的な意見が得られない場合があります。どうしても自社製品を売り込むために、色々と情報を調整をするからです。
一方、ベンダーさんのSEやエンジニアの方々は、非常に客観性を持った冷静な意見をおっしゃってくださる方が多く、担当営業マンよりも、テクニカルなバックグラウンドを持つエンジニアと親しくするようにしていました。
このように、普段からベンダーさんとは持ちつ持たれつという関係も必要かもしれません。困ったときに相談したり、わからないことがあった時に他社事例を引き出して参考にするという関係です。
プロジェクトが節目を迎えたときの食事会や忘年会などには積極的に招待して関係性を保つことです。関係性が極端に深くなるのは問題ですが、ある程度は、ベンダーさんとの協力関係を維持しておく努力も必要で、その後、強力な武器になります。
■ドローンを飛ばす
プロジェクト企画書をいよいよ出す前段階で、必ずやっておかなければいけないのは、社内にドローンを飛ばして、本当に今がタイミングかどうか、多くのユーザーが望んでいるかどうか、その温度を測ることです。
例えば、ユーザーが望んでいないのに、会社の決定権一つで主要なシステムを入れ替えるとなると、かなりの抵抗勢力が出てきます。つまり、自分たちがさほど困っていなければ、わざわざ現場の業務フローを変えたくないからです。長年継続してきた業務フローを変えるにはとてもエネルギーが必要だからです。
しかし、現場のオペレーションで非常に困っており、早くなんとか解決したいというムードが漂っているのであれば、プロジェクト企画を出すタイミングとしては非常に良いと思います。システム導入は、全社的なものになります。たとえ経営陣や情報システム部門がそれを推進しても、ユーザー側であまり乗り気でないとプロジェクトは成功にはたどり着けないからです。
こうして社内にドローンを飛ばすような感覚で社内全体の温度をはかり、プロジェクトを始めるタイミングを見ることです。そのためには、雰囲気作りは絶対条件で、ユーザーはもちろん、経営陣に対しても、サプライズは絶対に起こさず、少しずつムードを高めて雰囲気を盛り上げていくことが非常に大切です。そのために、ドローンを飛ばしてプロジェクトに対する温度を計ることです。
