全社ミーティングに見るグローバル企業CEOの言葉力

Howard_Schultz

シリコンバレーにある会社でよくある光景として、4半期に一度全社員を揃えてのカンパニーミーティングがある。(スタートアップなんかだと週一、月一)ここでCEOやCFO達が4半期ごとの業績、うまく行っていること行っていないことを「包み隠さず」プレゼン。これから先何にフォーカスして、何をスコープから外すのか、クリアなメッセージと事実とともに語られる。また従業員は直接CEOに質問する機会もある。当然彼らは会社のトップである以上、いかなる質問にも答えることが求められる。そこではぐらかそうものなら「何か隠してる」、「CEOなのに把握してない」と思われ、従業員とトップの信頼関係に水を差すことになるのだ。

この部分だけでも日本企業とは様相がだいぶ異なると思うが、もしグローバル化を志向するのなら、こうした場でトップが「はっきりした」メッセージを「迷いなく」発することはものすごく重要。グローバルカンパニーは働いている人が千差万別。それぞれ異なる文化的背景を持つ。なので、クリアで短いメッセージでないと、メッセージを発する側の意図したとおりに解釈してくれないことがよく起こる。こちらでいう “Less is more” という考え方だ。

ならば、「文脈を読む」ことを前提とする日本語と近い考え方かというと、そうでもない。むしろ広告やマーケで使われるような”Punch line”の考え方に近いものだ。例えば”Build the best”という言葉。本日CEOが繰り返し使っていた言葉の1つだ。宣伝広告のマーケの人たちが一言で印象づけるために作るキメのワンフレーズ。そういうキレのある言葉を語りのなかで頻繁に使う。メッセージを極限までシンプルにしながら相手に行動を促す考え尽くされた言葉だ。中学生の英語力でもわかる単語(=誰でも分かる)に、様々な事実とストーリーを重ねて従業員に訴えかける。こちらのCEOは経営の透明性(=事実を社員と共有する)という感覚が徹底しており、その姿勢が社員に「では、自分達はこの事実の前に何をすべきか」を考えるきっかけを与える。そしてそうした行動を奨励する仕組み(責任の所在、役割分担、ゴールの明確化)や評価制度をトップは用意する。

会長、社長、専務取締役達が現場から遠いところにあり、現場への権限移譲やゴールをはっきり決めない中でいくらトップがグローバル化を叫んでも何も変わらない。一方トップが会社の現実についてクリアに語らないようでは、社員は本来何をすべきかわかるはずもない。すると「本当にこのままでいいのか?」と一抹の不安を抱えながら働くことになる。そんな会社で社員は持てる能力を発揮できるはずがないのだ。

グローバルという言葉が最近日本のビジネス系記事で見ない日はないくらい使われているが、海の向こうに行ったら日本のスタンダードを一度捨てるくらいの覚悟がないと、正直まともに戦えない。グローバルでの競争するとなると自己否定と進化をセットで回さなければ置いていかれる。そして、戦いに慣れてきたら日本のスタンダードの良いところを融合すればいい。それが自分にとっての差別化になるのであれば大いにそうするべき。この点を理解している経営者が日本には少なすぎる気がしてならない。

 

さて、今日の全社ミーティングでは、なんとスターバックスの現CEO、Howard Schultz (ハワード・シュルツ)氏がゲストスピーカーとして登壇した(上の写真)。彼の話が非常に示唆に富んでいたので、次回はその内容について書いてみる。

 

文系人間がWebサーバー立ち上げでよくつまづく4つのポイント

linux_not_windows

WindowsとLinuxの使いやすさはまだイコールではない(特に文系にとって)

ITの世界にいるにも関わらず、文系かつネットワーク系だと自分から求めない限りサーバーやその上で動くアプリケーションに触る機会がほとんどない。コテコテ文系人間だった自分にとって、新卒で入社したころはサーバーの知識と経験を獲得するのはものすごく骨の折れるプロセスだった。何しろ自分の周りにも理解している人が少ない。そしてとにかくわからないことだらけ。そもそもサーバーはなんで「サーバー」という名前なのかとか。当時Windowsしか知らなかった自分にとって無機質なコマンドラインは不便でしかなく、何かをインストールしようものなら、依存関係にある他のパッケージがないというエラーメッセージにさんざん泣かされた。

そのうち、CiscoのIOSやJuniperのJunosでネットワーク機器の振る舞いを理解し、設定はできるようになっても、その先につながるサーバーやストレージがどんな仕組みでどう動くかというのは、よくわからない世界だった。

だが、いつしか飛び込んだWAN最適化のテクノロジーの世界でアプリケーションパフォーマンス向上について日夜悪戦苦闘し、Qfabricでデータセンター周りのテクノロジーを担当した結果、サーバーやストレージを扱う機会が増え知識と経験曲線がググッと上がる。

最近では仕事でWebアプリのモックアップを作る必要が出てきたので、自分でいろいろこねくり回せる環境がほしいなあと思い、開発環境を立ち上げた。ド素人のころはサーバーの立ち上げだけで1週間!もかかっていたものが、最近は1時間もあれば基本的な準備はできるようになった。(アマゾンのAWSではなくスタンドアロンのサーバーの話)

そうした経験を踏まえ、文系人間がLinuxサーバーを扱う際にかなり高い確率でつまづくポイントについて書いてみる。逆説的にこれらについてわかっておけば自分みたいに苦労しないと思うからだ。(あくまで文系視点で)

インストールの流れとかはググればいくらでもでてくるのでそこは書きません。

– Linux OSとWindows/Mac OSの違い(インストール時)

まずサーバーを扱うためにOSをインストールしないといけないが、Windows/Macのように自動でほぼ全部のインストールを勝手にやってくれることはない。インストール途中でいろいろあれを決めろ、これを割り当てろ、これに入力しろと質問される。しかもその説明が簡素すぎて、用語を理解していないと何をするためのものかさっぱりわからないという事態に陥る。インストール時には軽く予習をして、何について聞かれるのか、それは自分にとって必要な物かを知った上で望むことをおすすめする。

(最近のRedhat/Centos, UbuntuあたりはだいぶわかりやすくなったがそれでもWindows・Macしか知らない文系人間にはつらい)

– ファイルと構造

Windowsのように「写真はMy Pictureフォルダーで、文書はMy Document」と決め打ちでクリックのようにはいかない。Linuxはrootのディレクトリーから始まって、各々の機能のディレクトリーが木の枝のように広がっていく。操作はそのディレクトリーを行きつ戻りつ、ファイルの読み書きをしないといけない。GNOMEでGUI操作ができるならまだしも、CLIしかないとなれば、自分が今どの階層にいるのかを常に意識しないといけない。

Directory_structure

– ユーザーとユーザーグループ

Linuxでは「ユーザー」とその「ユーザーが所属するグループ」というのが露骨に影響する。普段Windowsを使っている時にはあまり意識することはないが、Linuxを扱うときにはディレクトリーとファイルが正しいユーザーとグループに所属していないと、まともにアプリを使えない。例えばWebサーバーをたちあげてアクセスしたと思ったらこんなエラーが。

Permission_error

まずはどのアプリがどのユーザー/グループを使うのかを把握。あとはchmod, chownで揃えること。

– パッケージと依存関係

Windows/Macでアプリケーションのインストールに失敗することは普通ない。しかしLinuxでアプリやパッケージのインストールは失敗することがよくある。まずはそこに驚かないこと。なぜ失敗するかといえば、たいていはそのパッケージに必要な他のパッケージがなかったり、バージョンが古かったり。ただ、そういった苦労を助けてくれるコマンドというのは存在する。例えばRedhat Enterprise Linuxで使うyumというコマンドはそれ。インストールしたいパッケージを指定すると、自動で依存するパッケージもインストールもしくはアップデートしてくれる。

以下はMySQLのパッケージのアップデートをかけるときの顛末。

続きを読む

SDNへの新たなアプローチ – Network Function Virtualization

DC in Barcelona

礼拝堂のなかにあるデータセンター  in バルセロナ

2013年の世界のIT市場の中で間違いなくHot WordのSDN。そんなSDNに対して自分が働くJuniper Networksがどんなスタンスで挑もうとしているのか、最近ニュースが流れた。

Light Reading – Juniper’s SDN Will Build Service Chains
http://www.lightreading.com/software-defined-networking/junipers-sdn-will-build-service-chains/240146332

この記事だけだとわかりづらいところがあるので自分なりに解説してみます。
(あくまで個人的見解としてのものです。会社としての公式見解ではありません。)
まずはSDNって結局何を実現するためのものか?の理解からおさらいしてみよう。

Increase flexibility of network  (ネットワークの「自由度」をあげる)
ハードウェアやチップ、ベンダーによる機能や振る舞いの差異を超えて、ユーザーが使うアプリケーションの要件に応じたネットワークリソース(帯域、QoS、遅延要件等々)が動的にアサインされる

 

Reduce time to market for new services  (新規サービス展開までのスピードをあげる)
アマゾンでは11秒ごとに新しいコードが、1時間に最大1000回もデプロイされている。こうした「常時更新」があたりまえのクラウドサービスの世界において、これまでネットワークの世界はあまりに切り離された状態だった。しかしSDNはアプリケーションでの変化をネットワークの世界へと伝播させることで、リソース最適化を速やかに行うことを狙う。

 

Reduce capex and opex  (設備投資と運用に関わる費用の削減)
そして、上記2点はここに収斂。例えばDCの規模(物理・仮想サーバーの台数、電源・熱効率、ストレージ容量等々)は今後も増え続ける=コストがかかる。維持・拡張のための定期的な投資は避けられないにしても、今ある機材の投資効率がSDNによって上がり、また管理の負担も減るならその経済的メリットは大きい。

 

で、この3点を達成するためにSDNがやってくれることは、

 

ネットワーク上の司令塔(Control Plane)とその命令に従ってデータを転送する役者達(Dataplane)をわける。そうすると個別のネットワーク機器を設定管理する必要がなくなり、司令塔役の装置だけで全てを集中管理できるようになる。逆に上記の「自由度」や「展開スピード」にあたる細かい設定は司令塔で一括で行い、例えばDC内にある数百台のネットワークデバイスに自動展開などなど。

 

一方Juniperがやろうとしているのは、

 

(Juniper Networksの)ネットワーク機器が持つFunctionを外にも広げる。ここでいう「外」にあるデバイスはx86商用プラットフォームならなんでも。これがNetwork Function Virtualizationのコンセプト。

 

もともとJuniperの機器で動くOS、JUNOSはControl PlaneとData Planeが別れた作りをしている。なのでわざわざSDNで説くような「全く別の」Control Planeを用意するのはそもそも2度手間。むしろ、今すでに商用レベルの機能を水平展開していくほうがいい。そして要件に応じて各Control Planeが「次々に」必要な機能をOnにしたりOffにしたり、リソースを割り当てたり、これがLight Readingの記事にある”Service Chain”のコンセプト。ただ、全く司令塔役の集中管理デバイスがいらないかというと、そういうわけではない。ネットワークマネジメント部分は集中すべきだし、全体としての整合を取るのにSDN Controllerにあたるもの必要と考える。しかし、おそらくOpenFlow Controllerのようにガチガチになんでも集中的に管理というレベルではない。分散したものを自律的に束ねる仕組みはQfabricでも経験済み。そしてContrailを買収したあたりをみても分散したControl Planeを互いに同期しあうアプローチを想定している模様。

 

「自由度」や「展開スピード」を実現するのにOpenFlow型アプローチが全てではない。Juniperのように Loose-Centralize なアプローチのほうが実はscale out しやすいしここがおそらくJuniperとしての違いを出すところなんでしょう。

 

その決断、本当に大丈夫?スタンフォード大学が考えるDecision Quality

Pyramid

クルーグマンもうなる、13.1兆円の安倍政権肝いりの、緊急経済対策を盛り込んだ補正予算案。USで夜が開けるころには閣議決定も通るだろうし、その思い切りの良さはいいと思う。ただその使い方に関する意思決定についてはものすごく気を使ってほしい。なぜなら意思決定の良し悪しは予算の使い方、そして日本の向こう5年10年のプレゼンスにかなりインパクトが大きい。

なぜ、こんなことを言っているかというとスタンフォード大では意思決定クオリティーの良し悪しの根源はトップの意思決定に対する考え方で決まってしまうと説くから。例えばこんなニュースがあった。

理科好きの子ども育成を…教材費の大幅増額検討
http://www.yomiuri.co.jp/politics/news/20130107-OYT1T00598.htm

ん?ちょっとまって。「科学技術創造立国を目指す」のはわかるが、顕微鏡や人体模型の「数」が増えることがそもそも目標に対してとるべき本当の方法か?ここで問題になっているのは、「日本の中学2年生で『理科を使う職業に就きたい』と答えた割合は20%で、国際平均の56%を大幅に下回った」のが今見えている問題なのであって、それが「~の数」が足らないというのが原因とはならないはず。

なぜ、こんな意思決定をしてしまっているのか?

そこを考える前に意思決定には大きく3つ種類がある。Policy Decision, Strategic Decision, Tactics Decision。それらの関係性は下のピラミッド図のとおり。

Decision_Hierarchy

下の層の意思決定は上の層の意思決定の枠内でしか決められないというのがミソ。従ってTacticsはStrategic Decisionに当然依存する。ではPolicy Decisionとは何か?

Policy Decision -> 意思決定に含めない範囲

である。”Take it as given”という言葉で表現されたり、経済ドラマなんかででてくる、「ソコは今回触らないでおこう・・」という類のものだ。Policy Decisionをどこに設定するかで何が戦略的なのか意味合いがかなり変わってくる。

話を先の例に戻すと、今回大幅に減った理科系科目(ITの世界も含めて)の興味を上げたいのであれば、もっとそもそもなんで理科って大事だし面白い?に答えていくアプローチをとるって興味を育てるのが最初にあったっていい。そして、そうした仕事に就いている、これから就いていく人々がもっと称賛される仕組みを作るべきだし(高学歴プアなんてゆくゆく云われるような努力は誰もしたがらない)、またそうしたリアルなプロフェッショナル達が子どもたちにその世界がどんなものかを見せてあげるようなことに予算をつけるべき。(考えれば他にもいろいろあるが)

しかし、政府からすれば上記で論じるような部分は、意思決定に含めないか、含めたくないので、堂々と人体模型の数のための予算が盛り込まれる。

こうした政府の意思決定の裏側が見えてしまうと、13.1兆円も予算つけてるけどその政策立案と実行の部分で本当に大丈夫か?と疑問に感じてしまうのだ。これでは何かを決めているようで、本当の意味での経済対策のための意思決定になってない。

_________________________________________________________________________

本稿で紹介したDecision Qualityという考え方、スタンフォード大学で提供しているStrategic Decision & Risk Management という講座で学べます。意思決定のクオリティーを上げるための考え方やツール、また人間なら必ずあるバイアスの影響をどこまで小さくするかとか。クラスはすべてオンラインで受講できるので興味のある人はぜひ。