学び[PR]Linuxビジネスを成長させたエンジニア上がりのリーダーが語る、ビジネスがうまく行かないリーダーのための処方箋2014年2月19日ある日、日本ヒューレット・パッカード(日本HP)でLinux事業のリーダーを命ぜられた赤井誠氏(前回記事参照)。エンジニア上がりで、ビジネスの経験もリーダーの経験もほとんどない中から、なんとかリーダーとして事業を軌道に乗せていきます。ビジネスにはいいときもあれば悪いときもあります。リーダーとしてビジネスがつまづきそうなときにどうすればいいのでしょうか。本記事では書籍「リーダーにカリスマ性はいらない」から、リーダーシップに関する記事を2回に分けて許可を得て転載しています。前編に続き後編の今回は、お客様に怒られたり、ビジネスがうまくいかなかったときにどうするか、という話です。リーダーはクレームを「処理」するな1時間以上怒り続けられる人は、滅多にいないぼくはさまざまなトラブル処理を自分の仕事としていたが、トラブルというのは必ずしも社内だけにあるわけではない。「会社の外」とのもめごとのほうが厄介だし、直接的に売上げに響いてくる可能性があるという意味では重大だ。お客様とのトラブルがあるたびに、「担当営業と一緒にぼくが怒られに行くケース」がかなり増えていった。いや、ほぼ日課と言ってもいいくらいだった。以前納品したシステムに不具合が出て、お客様からクレームが入ったことがある。システムが止まるってことは、ビジネスが止まるってことですよ。してくれるんですか?」クライアント側の担当者がこんなふうに「怒りモード」に入っていると、若手の営業マンは音を上げてしまうこともあった。いうときは、ぼくがどうにかしないといけないのだが、何も経緯がわかっていないのが正直なところで、その時点ではお客様が何をそんなに怒っているのか理解できなかった(お客様には申し訳ないのだが......)。いま思えば、そのときある意味で開き直ったスタンスしかとれなかったのがよかったのだろう。状況を教えてください」というように、とにかく聞き役に徹したのである。すると、カンカンに怒っていたお客様も、せいぜい1時間もすると「......で、HPさん、どうしたらいいかな?」と相談モードに変わっていったのである。お客様も「リーダー」なのかもしれないなぜこうなるのか。僕の聞き方が特別うまかったとは思えない。話してみて気づくことがあった。このようなトラブルの際に訪問すると、対応してくれるのは先方のリーダークラスの人である。彼ら自身も、社内では上司や経営陣から対策を求められる立場にある。彼らがいくらぼくたちにクレームを伝えていたとしても、最終的にはk、自分たちでトラブルを解決し、上司に報告しなければならないことに変わりはないのだ。つまるところ、立場はぼくと同じだ。彼らも、ある時点で「はっ」と我に返って、解決策を求めるようになる。お客様が「怒りモード」から「相談モード」に切り替わったら、やっとそこからが本当の対話の開始だ。あとは、社内での問題解決と同じ。話を聞き、次回の訪問までに対策を検討、なるべく早く解決する。そのためにはやはり、お客様から十分に情報をいただける環境だけはつくっておかなければならない。それさえできれば、むしろトラブル解決を通じて、お客様からの信頼を積み重ねる機会にさえなる。お客様が怒っているときでも、必ずしもこちら側に問題があるケースばかりでもない。サポートされていない構成のシステムを導入したのは自分たちなのに、いざ動作不良が起こるとクレームを入れてくるようなクライアントもいる。どんな場合でも、まずリーダーとして同行したら、お客様の話をじっと聞く。焦ってクレームを処理しようとしてはいけない。なんとかしようと思って、反論や言い訳めいたことを言うなどもってのほかだ。こちらから火に油を注ぐようなことをしないかぎり、向こうもいつまでも怒っているわけにはいかないことに気づくはずである(1時間以上怒り続けている人に一度だけお会いしたこともあるが......)。リーダーは誰よりも「言い訳上手」になれ。「うちは特殊」症候群に陥っていませんか?ビジネスを継続していると、うまくいっている時期ばかりではなく、そうでない時期がどうしても出てくる。ビジネスが低調なときに、リーダーとしてビジネスレビューミーティングに出るのは本当につらかった。これはどこの国の人でも同じ。ぼくも、うまくいっていない時期を体験したし、そういうときの会議では「早く自分の番が終わってほしい」ということで頭の中がいっぱいだった。Linux事業が拡大していくと、ぼくは別領域のビジネスレビューミーティングにも参加する機会が出来た。うまくいっていない領域があれば、そういう会議で「なぜうまくいっていないのか?」についてマネジメントから質問が飛ぶ。リーダーにはそれに対する釈明が求められるわけだ。このとき、日本の担当者の弁明には一つのパターンがあった。日本ジェネラル・エレクトリックで長年にわたり人事リーダーを勤めた八木洋介氏(現・住生活グループ執行役副社長)の言葉を借りれば、「ジャパン・イズ・ユニーク・シンドリーム」(「日本は特殊」症候群)である。リーダーは「言い訳」できないといけないこうした言い訳を聞くと、外国人マネジメントのなかには、怒りをあらわにする人もいた。怒るのかといえば、それが「ちゃんとした言い訳になっていない」からである。人生訓などではよく、「何があろうと言い訳するな」といった趣旨のことが言われる。たしかにビジネスでも結果がすべてだから、言い訳は認められないだろう。したレビューミーティングの場でリーダーに期待されているのは、しっかりとしたビジネス状況を経営陣に説明することなのだ。ぼくは会議に参加するたび、マネジメントとうまくコミュニケーションが取れているリーダーとそうでないリーダーを比較観察するようにしていた。優秀だと見なされているリーダーでも、必ずしもつねにビジネスが好調だというわけではない。不調なときほど、ミーティングの準備に時間をかけて、うまくいかなかったことに対する「言い訳」をしっかり用意しているのである。マネジメント層にも納得感が生まれるし、「このリーダーはしっかりとビジネスを理解している」という認識が信頼につながる。逆に、言い訳をしっかりと用意せず、「ウチは状況が特殊なので」といったごまかし方をしていると、「このリーダーはやるべきことをやっていない」と評価されてしまうのだ。「言い訳」をつくり上げる作業は、次に実施すべきアクションを明確にしてくれる。いうリーダーのチームは、素早く着実に軌道修正を進められるのである。リーダーは結果に対しては言い訳できない。プロセスについては、「いかにロジカルに言い訳ができるか」がカギになるのである。無料ご招待3月2日に開催予定のセミナーに読者のみなさまをご招待いたします。ヴォイストレーニングで人に伝わる声と話し方を学ぶ詳しくはこちらの申し込みページをご覧ください。≫次の記事バニラJavaScriptを選択する≪前の記事エンタープライズ向けのアプリストアを次々に発表するヒューレット・パッカード。DWHのVertica向けアプリストアを発表。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。Feed最新記事10本ITエンジニアが投票した「ITエンジニア本大賞2020」ベスト10発表。Kubernetes」が正式版に。ElasticsearchやKibanaなどをKubernetes環境にデプロイ、Operatorにより運用も容易にKubernetesとコンテナの実行に最適化された統合システム「Diamanti」のアーキテクチャはどうなっているか[PR][速報]AWS、2021年初頭に大阪リージョンを開設すると発表。10へログイン可能に。10へ拡大Google、コーディング不要でアプリケーション開発ができる「AppSheet」買収。WebAssembly」正式版を5月にリリース。usPublickeyについて/運営者についてお問い合わせ広告についてプライバシーポリシ。