[PR]Linuxビジネスを成長させたエンジニア上がりのリーダーの、リーダーシップ実践論とは?

2014年2月12日

日本でLinuxの商用利用が広まり始める前の2002年、日本ヒューレット・パッカードのエンジニアだった赤井誠氏は、ある日社長からLinux事業のリーダーを依頼されます。

「いますぐ社長室まで来てくれますか?」

 2002年秋、デスクで仕事をしていると、夕方頃に1通のメールが届いた。
 発信者は、ぼくが当時務めていた日本ヒューレット・パッカード(日本HP)の社長だった樋口泰行さん。言わずと知れた現・日本マイクロソフトの社長である。
 社長室で待っていた樋口さんは、突然こう言った。

「来期からスタートするLinux事業の全社プロジェクトなんですが、リーダーをやってもらえませんか?」

 僕はそのオファーを迷わず断った。
 この事業が大きな困難を伴うと予測できたからだ。

日本HPのLinuxビジネスは、ここから数百億円規模にまで成長するのですが、そのリーダーを勤めた赤井氏がどのようにビジネスを成長させてきたのか。書籍「リーダーにカリスマ性はいらない」では、エンジニア上がりだったためにビジネス開発の経験もリーダーシップの経験もほとんどなかった赤井氏の体験談と教訓が詰まっています。

本記事は、書籍からリーダーシップに関する記事を2回に分けて許可を得て転載し、さらに書籍では説明されなかったIT業界の背景や裏話などを加筆しています。前編の今回は、リーダーはオフィスをもっと歩こう、という話です。

リーダーはデスクで待つな、オフィスを歩け。

仕方がないので、社内をうろついてみた

 最終的にプロジェクトを任されることになったぼくは、調査会社の報告書を読んだり、ネットを検索したりと、ひとまず情報を集めてみた。
 しかし結局のところ、「どう進めていくか」については、まったくというほど「絵」が見えてこなかった。もちろん、社内にまとまった情報があるわけでもない。

 この時期、調査会社によるLinuxやオープンソースに関する調査レポートがそもそも少なかったということがある。さらに、ネットでLinux技術情報でないビジネスパーソン向けの情報は、「Linuxはボランティアが開発している」「Linuxがマイクロソフトを脅かす」といった傾向のものばかりで、それらの情報からビジネスを構築することは困難だった。

 途方に暮れたぼくは、営業マンたちがいるフロアを歩き回ることにした。自分の席でじっとしていてもらちが明かないので、とにかく顔見知りの営業マンに声をかけて、話を聞かせてもらおうと思ったのだ。
 正直なところ、そこまで何か目算があったわけでもない。とはいえ、こうやって社内をうろつくという「リーダーらしからぬ行動」がその後の突破口になったのは間違いなかった。

 その中で聞けた話は必ずしも「役に立つ話」ばかりではなかなったが、販売の現場で何が起こっているのかをつかむには十分だった。これを通じて、なぜ日本HPのLinux事業がうまくいってなかったのか、問題の根幹が見えてきたのである。

そもそも「何を売ればいいか」が分かってなかった

ぼくが最初に声をかけた営業マンは、昔から尊敬していた先輩の西島さんだった。

「西島さん、時間ありますか?」
「はい、あるけど、何?」
「来期、Linux事業を担当することになりそうです」
「お、ちょうど、いいときに来てくれた。実は、いまパートナーからLinux製品に関して引き合いがあったんだけど、よくわからなくてね……」

 このやりとりに象徴されているとおり、問題は非常にシンプルなことだった。つまり、営業の現場は、Linuxに関する引き合いがあっても、どの商品を提案すればいいかがわからず、混乱していたのである。

 こうなってしまっていたのには、さらに理由があった。当時、販売の現場では「Linuxはお客様に新しい選択肢を提供するものなのだから、こちらで勝手に商品を絞り込むべきではない。できるかぎり多くの選択肢を見せるようにしよう」という方針が取られていたのだ。

 当時は、まだ一部の大企業がLinuxを基幹システムに採用を開始したばかりで、どのような構成が最適であるかという知識がIT業界全体になかったのである。サーバにLinuxディストリビューションをインストールするということだけで大きな価値がある時代であったのだ。
 また、企業向け商用Linuxディストリビューションを提供するベンダーが国内、国外あわせて多数があり、どのベンダーが主導権を取れるかといことが不透明であった時期でもあった。このような状況でどういった製品を推奨して販売するという方針もないのだから、営業の現場は混乱する以外なかったのである。
 「たくさんの選択肢」というと聞こえはいいが、実体は「玉石混淆」。営業マンもなにをお客様に提案すればいいか、まったくわからなくなってしまっていたのだ。

 この混乱は営業を支援する技術部門にも影響していた。彼らも「どの製品に集中して支援体制を構築すればいいか」がわかっておらず、すべてが中途半端な状態に陥っていたというわけだ。

報告を待っていたら、絶対に気づけなかったこと

 問題がわかってしまえば、実行すべきことは、きわめてシンプルだ。
 多様な製品を満遍なく売るのではなく、核となる販売注力製品を決定したうえで、各種の保管製品、コンサルティング、サービスの体制を作り上げていくのである。

 当時メディアは、LinuxはIT予算の少ない中小企業が「無料」だから導入しているといった論調が多かったのだが、現実は大企業を中心にして、新しい基幹プラットフォームとして検討されていたのである。そのため、単にサーバーとOSの販売体制を作るだけでは不十分であり、コンサルティングや保守サービスを含めたトータルのエコシステムを構築する必要があったのだ。

 こうした一連のことは、ぼくがデスクに座って、調査会社の報告書やウェブサイトとにらめっこしていただけでは、決して起こりえなかっただろう。そもそも、現場から「こういう問題が起きています」という報告が上がってきたかどうかもわからない。

 営業メンバーのいるフロアに足を運び、そこを歩き回って話を聞いたからこそ、「営業部が何を売ればいいかすらわかっていない」という実に初歩的ながらも本質的な課題を発見することができたのだ。

リーダーは自席に部下を呼びつけるな

入社以来、上司からデスクに呼びつけられた経験がなかった

 まだ工場で開発エンジニアをしていたときのこと。滅多に鳴らないデスクの電話が鳴ったことがあった(当時は海外とのコミュニケーションが多かったので、電話よりもメールが中心だった)。当時、新たに赴任した本部長からである。

「赤井さん、ちょっと、私のデスクまで来てください」

 急いで新本部長のところまで行ったものの、とくに何か大きな問題があったわけではない。通常の仕事の依頼だったのだが、そのときのぼくは猛烈に違和感を覚えていた。当初はこの違和感がどこから来るかわからなかったが、よく考えてみると思い当たることがあった。
 入社以来、ぼくは「上司から席に呼ばれる」という経験がなかったのである。  テレビや映画などでは、デスクにいる上司が「赤井君、ちょっとこっち来て!」などと部下を呼びつけるシーンがよくある。
 日本企業ではよくある風景なのかもしれないが、エンジニアとして製品開発部門にいたころのぼくは、上司からそんなふうに呼びつけられたことも、呼びつけられている人を見たこともなかった。  部下に何か要件がある上司は、部下のデスクのところまでやってきて話すのが普通だと思っていたのである。

「歩き回るマネジメント」がベースにあった

 それ以来、「なぜぼくは上司から呼びつけられたことがなかったのか?」を不思議に思っていた。
 その疑問が氷解したのは、HP社史を扱ったビデオを見たときのことだった。その映像には、夜中まで残業して製品テストをしている社員のところを、共同創業者デビッド・パッカードがたまたま通りかかるシーンがあった。

 それを観ながら「なるほど」と思った。人手が足りないことに気付いたデビッドが、その場でいきなり製品テストを手伝いはじめたのである。

 よくよく考えてみると、上司に対する匿名フィードバックを以前求められたときにも、「仕事を依頼するときに、上司はあなたの席に来ますか?」といった趣旨の質問事項が含まれていた。
 つまり、上司がみずから部下のもとを訪ねて、状況を自分の目で確かめながら、ビジネスをリードしていくというスタイルは、創業者から受け継がれているHPの文化だったのだ。

 上司がぼくをデスクに呼びつけなかったのも、第1章で述べたようにぼくが社内を歩き回ったのも、HPのなかで脈々と受け継がれてきたマネジメントスタイルだったのだ。
 それが「歩き回るマネジメント」(MBWA ―― Management By Walking Around)と呼ばれていることを知ったのは後日のことである。

リーダーに個室はいらない

 MBWAは、上司と部下のあいだの上下関係を極力なくして、オープンで中立的なチームを実現する一つの手法だった。デビッド・パッカードとビル・ヒューレットはこれ以外にも、さまざまなチームワークの確立手法を導入している。
 たとえば、現在のシリコンバレーでは一般的になっている「オープンドア・ポリシー」もHP発の文化だ。

 これは、エグゼクティブの個室をなくしたり、あるいは、個室があったとしても、ドアを開けっ放しにしたりして、部屋をオープンにするという手法である。それまでの米国企業では、個室を持つことが一つのステータスだった。
 しかし2人の創業者は、個室を持つことで生まれる弊害のほうを問題視した。個室やドアをなくしてしまうことで、リーダーと部下が相互に信頼できる雰囲気を社内やチーム内につくりあげようと考えたのである。

 HPが買収した米東海岸の企業を訪問したときには、ある部署のマネージャーが「個室を取り上げられることになったんだ」と嘆いているのに遭遇したことがある。
 ぼくがリーダーになったときに、こうしたHPの伝統を理解していたのは、非常に大きなメリットだった。実際、ぼくはMBWAを通じて、チーム内にオープンで中立的な関係性を構築していくことができたからだ。

 だからこそ、ぼくは当時も(そしていまでも)、デスクから人を呼びつけるということを絶対にしないようにしている。それをした瞬間に、人間関係にある種の「上下」が生まれてしまうからだ。もちろん、そうした上下があった方がうまく回るチームもあるのかも知れない。
 しかし、ぼくのようにリーダーになったばかりの人間や、複数の部署を横断してマネジメントする立場になった人は、よりオープンな関係性を築いたほうが短期間で信頼を得ることができるはずだ。

読者プレゼント
「リーダーにカリスマ性はいらない」出版記念セミナー 無料ご招待
3月2日に開催予定のセミナーに読者のみなさまをご招待いたします。
- 明日から使えるプレゼンテーション力を身につける
- 人に伝わるプレゼンテーションを作る
- ヴォイストレーニングで人に伝わる声と話し方を学ぶ
詳しくはこちらの申し込みページをご覧ください。

リーダーにカリスマ性はいらない リーダーにカリスマ性はいらない
リーダーは仕事を「イシュー」から始めてはいけない! あのスティーブ・ジョブズが憧れたヒューレット・パッカード(HP)で、国内最下位だったLinux事業を世界ナンバー1の数百億円規模にまで拡大した「日本HP伝説の社員」が語る次世代リーダーシップの真髄!

(本記事は、赤井誠氏提供によるタイアップ記事です)

あわせて読みたい

Linux 働き方 PR




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本