いまクラウドよりオンプレを学ぶべき理由

今日、ありとあらゆる企業がクラウド移行を果たし活用している。 こんな今だからこそ、オンプレ時代の知識が大事だという話をしていきたい。

問題

過去の経験から、一つ具体的な例を上げて話そうと思う。

以下のようなシステム構成において、System A から System B への通信が定期的にタイムアウトするという問題が発生していた。 この問題の分析は難航していて数々の担当者があたっていたが、ついに解決されないまま数年間放置されていた。

問題の規模がそれほど大きくなく、業務影響が大きくなかったことも放置されていた原因の一つであった。 しかし、サービスが成長するにつれて、いよいよ無視するわけにも行かなくなってきていた。

System A の担当エンジニアは言う。

「タイムアウトのためのパラメターは確認したし、思いつく限りのログを取ってみた。ログを確認したところ、System B からのレスポンスが全くかえってこないのだ。LB か System B が怪しいのではないか」

System B の担当エンジニアは言う。

「該当リクエストのうち、System A からのリクエストが届かないこともあるし、届いていることもある。届いている時には数ミリ秒で応答を返している。Managed Service C か System A でのレスポンスを受け取る処理が怪しいのではないか」

マネージド・サービス C に問い合わせた担当者は言う。

「タイムアウトのレポートがあった時間帯のログを見てみたが該当の通信はきちんと通っているし、ブロックされている形跡はない。本当に System A, B で問題はないのか」

三者ともに明確に問題を指摘することができずに暗礁に乗り上げていた。

問題解決

この問題を解決したのは、チームでは新参のエンジニアであった。彼はもともとネットワーク・エンジニアとしてのバックグラウンドを持っていた。彼は持ち前のネットワークの知識を活用しつつ、このクラウド・ベースのアプリケーションの問題を一つずつ紐解いていった。その結果、以下のような結論を導き出した。

• この問題は以下の複合的な要因によるものである
• NAT Gateway のポート枯渇: NAT とマネージド・サービス C は、それぞれ一つの Public IP しか持っていない。一分間に 65,000 以上の接続があると新たな通信ができなくなる
• タイムアウト設定の一貫性: 各コンポーネントのタイムアウトがばらばらで、途中の経路で予期せぬ応答結果を返す
• マネージド・サービス C 内部の問題: マネージド・サービス内部の通信問題もまれに発生している

先程あげた担当者は皆間違っていなかった。ただし、問題の一部分しか見ることができていなかったのである。あるときには NAT Gateway でタイムアウトが起き、あるときはタイムアウトの設定の不一致で、あるときはマネージド・サービスの問題が発生していたのである。

問題が複雑なときにむやみに仮説を棄却するのは危険だ。例えそれを反証する事実があったとしても、複合された他の要因のものである可能性があるからである。

問題を解決できるエンジニア

先のエンジニアのアプローチは以下のような単純なものであった。

通信が途絶える可能性のある経路をたどり、全ての仮説を上げて一つずつ潰していく。一つずつ被疑箇所を修正し、リリースし、変化を計測する。 一つの問題を解決するとタイムアウトの発生件数ががくっと下がり、複合問題がそれぞれの問題に分解され、より効果的に問題分析を進めることができた。 アプリケーション・ログや業者への問い合わせのみに頼ることなく、システムの下回りで何が起きているのかを、一つ一つ丁寧に掘り下げていった。

クラウドやマネージド・サービスは重要である。便利である。これらはあなたのシステムが扱いやすいように全てを抽象化してくれる。

一方、仕組みが抽象化された世界では、問題すら抽象化されてしまう。つまりそのままでは解決が難しいということだ。 だから、発生した問題をネットワークやオペレーティングシステムといった低次元のレベルまで掘り下げて分析をしていかなければいけない。

世界ではデジタル変革のニーズは高まる一方だ。それに伴ってエンジニアが必要とされ、より多くの「エンジニア」が市場にあふれることになる。 コードを書くことができるエンジニアは増えるだろう。だが問題を解決できるエンジニアはそれに伴って増えていくとは限らない。 世の中には、ますます多くのデジタル・プロダクトが生まれ、それと共に多くの問題が生まれるだろう。

こうしたトレンドの中、きちんと問題を解決できるエンジニアの希少価値はますます高まっていくと思う。だから、むやみやたらとバズワードを追いかけるよりも、基本を大切にするべきだ。今からブレード・サーバーを買ってきて自宅のラックに備えようと言うつもりはない。だが、かつてそうした時代に求められていた基本的な知識を学ぶことは大事だ。オペレーティング・システム、システム・プログラミング、ネットワーク、データ構造とアルゴリズム、データベースといった足腰を鍛えることが大事なのではないかと思う。

キャリアは作るな

キャリアと偶然の関係

もし若手エンジニア諸君の中に自分のキャリア・プランに悩んでいる人がいるとしたら、ぜひそんな悩みなど捨ててしまうことをオススメする。 なぜなら世の中のキャリアのほとんどは「偶然」で決まってしまうからである。

ハーバード大学のジョン・D・クランボルツ教授らは、キャリア形成において「偶然」がもたらす影響が大きく、これを考慮してカウンセリングすることが難しいと述べている。そのうえで「計画的偶発性理論」という理論を提唱している。この理論の説明は様々な解説が見つかるので、ここでは詳しく語らない。要するに「キャリア・プランニングを頑張るよりも偶然が起きやすい環境に身をおいて、チャンスをものにできるように準備したほうがいいよね」ということだ。

ディズニーの CEO と偶然

最近「The Ride of a Life Time (邦題: ディズニー CEO が実践する 10 の原則)」という本を読んだ。 ロバート・アイガーのキャリアは ABC テレビのスタジオ管理者 (要するに AD さん) から始まって、いろいろな経験を経て ABC テレビの社長に就任し、その会社が別の会社に買収され、さらにウォルト・ディズニーに買収され、最終的にウォルト・ディズニーの CEO として指名されるという物語だ。その機会の連鎖はとても目まぐるしい。

ディズニーＣＥＯが実践する１０の原則

無論、単なる運だけで出世できるわけではない。ロバート・アイガーの忍耐強さや、他人をいたわりながらもより良い仕事をひたむきに追求する姿勢は彼の成功の源泉だと思う。だが、上の偶然が重ならなければ、テレビ会社のスタジオ管理者が、世界中の子供達に夢を売る偉大な企業の CEO になるということは発生しなかったと思う。やはり偶然はキャリア形成の重要なファクターを占めていると思う。

自分のキャリアと偶然

自分のキャリアを振り返ってみると、随分と偶然に支えられてきたと思う。いまは、グローバルに活躍できるエンジニアリング組織づくりをするという非常にやりがいのある仕事に恵まれている。いまでこそこんな仕事をしているが、大学生のころはまともに英語を話すこともままならなかったし、エンジニアリング一本で勝負をかけていた自分がマネジメントの仕事につくなどとは思わなかった。

自分がグローバルな環境での仕事に興味を持ったのは、新卒で入った会社で立ち上がった新規プロジェクトに偶然飛び込むことができたからだ。プロジェクトはアメリカで立ち上がったので駐在員として仕事をすることになった。様々な経験を詰んできたエンジニアたちが腕を奮っていた。中には自分の父親よりもずっと年上なエンジニアもいた。とても聡明な知識を授けてくれるだけにとどまらず、その年齢にも関わらず、バリバリ現役として力強く働いていた。そうした雰囲気にとても触発され、将来もこうした環境で仕事がしたいと思った。

帰国してからも、いろいろな国のエンジニアに囲まれて仕事をすることができる機会に恵まれた。その中でリーダーシップを取る機会に恵まれた。組織が大きくなるにつれて、技術的なリーダーシップにとどまらず、マネージャーとして活躍する機会にも恵まれた。そうした日々の積み重ねがあって、いまの刺激的な仕事につながっている。

キャリアは波乗りに似ている

キャリアづくりは波乗りに似ていると思う。どんなに素敵な休日の計画を立て、海に出たところで、波が立たなければ何もできない。 波に乗りたければ、まず波の立つ海岸へ向かうことだ。そして沢山の波に呑まれながら、勇気を出してパドリングをし、何度も挑戦することである。

大学生のときに「恐れるぐらいなら失敗してみよう」を座右の銘として良く自分に言い聞かせていた。ビビリな自分を奮い立たせてとにかく挑戦させようとして思いついた言葉だ。もしかすると、この言葉が自分に様々なチャレンジを仕向け、結果としてこのような恵まれた機会に行き着いているのかもしれない。

エンジニアというのは専門家故に、キャリアプランに悩む人が多い人が多いと思う。以上の理由から、自分はキャリアプランを悩むことをやめることをオススメしたい。キャリアは作るものではない、機会に作ってもらうものなのだ。

なぜ OKR は O と KR なのか? 目標設定には光と闇がある！

OKR とMBO (目標による管理)

目標による管理は多くの知識産業において広く使われている手法である。とりわけ技術産業では、OKR と呼ばれるシンプルなフレームワークが現在のベストプラクティスとして広く使われている。

アンディーグローブは OKR を彼の著書「High Output Management」で世界に広めた。このフレームワークは極めて単純である。目標を以下の要素で定義するのだ。 - Objective — 定性的な最終ゴール。野心的な「ムーンショット」ゴールを設定する。 - Key Results — 定量的で具体的な達成項目を設定する。

ここでひとつ面白い疑問をしてみたい。なぜ OKR は Objective と Key Results という２つの要素を使うのだろうか。

目標管理の光と闇

多くの人が目標管理は人材を管理するにあたって有益だと考えているだろう。だが、多くはその副作用を知らない。

ハーバード・ビジネス・スクールのある論文がこの副作用について述べている。この論文は、目標設定の失敗事例をフォードやエンロンと言った有名な事例を含めて分析して議論している。

この論文の結論は目標設定は以下の警告ラベルと共に注意深く使われなければならないということだ。

from Goals Gone Wild: TheSystematic Side Effects of Over-Prescribing Goal Setting

この論文の著者らは、あまりに具体的な目標設定をすると視野が狭くなり誤ったゴールを達成してしまうと述べている。また、一方であまりに野心的なゴールを掲げると、倫理的によろしくない振る舞いをしたり、不適切に大きなリスクを取ったり、人々のモチベーションを下げると述べてもいる。目標は具体的すぎても、挑戦的過ぎてもいけないということだ。

OKR はなぜ O と KR なのか？

OKR はこのバランスを取るためのシンプルなフレームワークとなっている。Objective は我々に究極的に達成すべきゴールを与えてくれる。そのゴールは永遠に達成できないものかもしれないが、我々を常に正しい方向に導いてくれる。Key Results は一方で、具体的な達成すべきアクションを与えてくれる。我々は具体的な進捗を知ることができ、それゆえにモチベーションを高めることができる。

Objective は北極星のようなもので、Key Results は道標のようなものだ。どれだけ頑張っても北極星を掴むことはできないが、確実北へと向かうことができる。間違った道標を選んでしまったときも気がつくことができるし、次の道標を正しいものに修正できる。これこそが OKR の本質的な力なのである。

原文記事:

yuichi-murata.medium.com

参考文献: Goals Gone Wild: TheSystematic Side Effects of Over-Prescribing Goal Setting

言語の壁を突破する！ライブ議事録コミュニケーション - Organization i18n

コミュニケーションの手段はたくさんある

我々人類は様々なコミュニケーション手段を持っている。我々は話したり効くことができる。読んで書くことができる。感情を雰囲気で伝えることができる。これらの「マルチモーダル」なコミュニケーションのとり方は極めて効果的である。特に普段異なる言語を用いる人と話すときには。マルチモーダルコミュニケーションは、チームの共通言語を得意としていない場合 (我々日本人の場合英語でしゃべるのが苦手な場合) にもメッセージを伝えることを助けてくれる。

リモートネイティブの到来に伴い、コミュニケーションの手段が増えた。この記事ではその一つとしてライブ議事録コミュニケーションというものを紹介したい。

ライブ議事録コミュニケーション

ライブ議事録コミュニケーションは普段はことなる言語を使う人と話すときに効果的だ。ミーティングに先立って、議題を入念に準備しておき事前に参加者に周知しておく。参加者は事前に議論の準備ができる (知らない単語を調べておくことも含めて)。これらには Google Docs や Confluence などのライブドキュメンテーションツールを使うのがおすすめだ。会議が始まった後でも誰でもコンテンツを追加できる。このライブ議事録によって参加者は議論の行く末を見失わずに済むし、語学に達者である必要もなくなる。

議事録の存在はチームに声を上げる勇気を与える。何しろ必要なキーワードが全てスクリーンに並んでいるのである。これがあれば声を上げるのはずっと簡単になる。また、他の人の話す議論をリスニングする難易度も下がる。自動車が一番エネルギーを消費するのは発進するときだ。一度加速してしまえばそれほどのエネルギーは必要なくなる。同様に、議事録の助けを経てしゃべり始めてしまえば、意外と話が続くものである。

ライブ議事録は共有クリップボードとしても機能する。そこにはリンクでも写真でも、格言でも、現地の言葉でも貼り付けることができる。これは自分の昔の one-on-one ミーティングに使ったライブ議事録だ。当時中国出身のメンバーとチームの文化を変える方法について議論していた。自分が人海戦術について話をしているとき、英語で Human Wave Attack といっても全く伝わらなかった。そこで Google Translate で中国語にして貼り付けたところ、彼は一発で自分の意図を理解してくれた。

議事録を使ってコミュニケーションをするのって無駄じゃない？

もし全てのトピックをテキストに落とさないといけないのだとしたら、本当にミーティングをする必要あるのだろうか。これは良い質問だと思う。Slack とか Mail で済ませてしまえばいいだろうと、あなたは考えるかもしれない。しかし、自分の答えは「必要」である。もしその会議の参加者があなたが一緒に仕事をする主たるチームメンバーであるなら。

これはチームにとって加速のプロセスである。ミーティングをすること自体が彼らにとって学びの良い機会となる。チームはいずれ議事録のサポートが最小限でも自然にはなせるようになるだろう。また、たとえ加速中であってもミーティングをすること自体がチームワークを助ける。「単純接触効果」というキーワードを聞いたことがあるだろうか。普段から顔を合わせているメンバーには自然と助けて上げたくなるものである。

このようなアプローチをうまく活用して、ゆくゆくはチームの共通言語で自然に仕事ができる、そういうチームを作ろう。

意図的分散チーム: 英語話者のエンジニアと連携する最高のチームワーク - Organization i18n

言語の壁の問題をどうクリアするか？

国際化をすすめるエンジニア組織では、異なる言語を話すメンバーをチームに抱えることがある。典型的な「言語の壁」問題である。現地語 (つまり日本語) の話者と英語話者がいる。多くの組織はチームを英語化を促進しようと試みるがこれには時間がかかる。この変化をスムーズに、かつ現在機能しているチームの効率を下げずに実施するためにはどうしたら良いだろうか。

意図的分散チーム

Mike Cohn は Succeeding with Agile にて面白いアイディアを述べている。意図的分散チームだ。

意図的分散チームはチームメンバーを二つの異なる拠点から選んで混成するものだ。図でわかる通り、二人のメンバーがフランスから選ばれた、残りの二人が米国から選ばれている。Mike は意図的分散チームはそれぞれのチームに透明性をもたらすと述べている。例えばどちらのチームも、一方の拠点にしかいないスクラムマスター、プロダクトオーナー、ステークホルダーといった人物に平等にアプローチできる。シビアな時差があったとしても平気だ。

筆者はここで、全く同じコンセプトが地理だけではなくて、言語の場合にも適用できることに気がついた。

意図的・言語分散チームは日本語話者と英語話者を選んで一つのチームを作る。このアプローチの良いところは、オリジナル版と同じくそれぞれのチームに透明性をもたらすことである。スクラムマスター、プロダクトオーナー、そしてステークホルダーは片方の言語しか話せないかもしれない。大抵は日本語しか話せないケースだ。どちらのチームも、これらの関係者に言語の問題を最小化してアクセスできる。

もう一つ、ユニークな利点として国際化を促進する効果が期待できる。他の言語話者がチームに存在することは、お互いの学習経験となる。日本語話者は英語を勉強する機会を得られるし、英語話者は日本語の学びを通じて文化を知ることができる。

いつ導入すべきか？

欠点もある。異なる言語話者をチームに組み込むことは、少なくとも最初はチーム内部の能率を下げるだろう。これを避けるには、十分な関係値と最低限の語学力が事前に形成されていなければならない。

筆者の経験からアドバイスすると、まずはインキュベーションチームから始めた方がよい。インキュベーションチームを通じて基礎ができたら少しずつ意図的分散チームへとシフトしていくのだ。これはロケットのようなものだ。まず第一ブースターで十分に加速してから二段目に移る。一段目で十分に加速していれば、大気圏から離脱するための二段目の燃料はあまり要らない。注意深くまずはインキュベーションチームから初めで、ここぞというタイミングでロケットを切り替えるのである。

原文:

yuichi-murata.medium.com

関連記事:

www.amazon.co.jp

yuichi1004.hatenablog.com

インキュベーションチームで始める国際化 -- Organization i18n

国際化初日 (Day 1)

国際化を始め、初日はとても難しい。日本の様にその地域のビジネスがその国の言語に依存している場合、言語の壁があるがゆえにより大変だ。多くの従業員はビジネスやエンジニアリングのタスクを現地語でこなしている。しかし、より多くの才能ある従業員を世界から集めるには、英語を主軸とした国際化が必要になってくる。

今日のビジネスを回している現地組織のメンバーと以下に両立していくことができるだろうか。

インキュベーションチーム

自分の十年間の勤務経験から、これを達成するためには「インキュベーションチーム」が鍵になると確信している。

インキュベーションチームとは、ローカルな組織の中に独立したインターナショナルチームを作るというものである。インキュベーションチームは独自の仕事の領域とミッションを持ち、完全に国際化されたチームとして働く。人々は英語などの言語を話す。現地語を話す必要はない。こうすることで、ローカルな組織を無理に捻じ曲げず、世界中からより多くの才能ある従業員を集めることができる。

インキュベーションチームの存在は、ローカルチームのメンバーにもいい経験をもたらす。それぞれのチームが働く中で、ローカルチームのメンバーはインキュベーションチームのメンバーと話す必要が出てくる。プールに入るとに急に飛び込むよりも、ゆっくり準備を整えて入水したほうがショックが少なくて済む。インキュベーションチームとの会話はまさしくプールに入る前の準備体操となりうる。

外交官を配置する

インキュベーションチームの成功の鍵は良い「外交官」を配置することだ。外交官はたいていマルチリンガルな人材でローカル組織から選ばれる。

外交官の役割は 2 つの異なるチームをつなぐことだ。インキュベーションチームはしばしば、ローカル組織のメンバーの助けを必要とする。 外交官は２つのチームから人々をつなげ、一緒に仕事をするように促す。

もしあなたがインキュベーションチームを組織しているなら、あなた自身が外交官になれるのが一番望ましい。もしあなたがその役割をできないのであれば、外交官の選出は注意深く行う必要がある。外交官はお互いの言語だけではなく、文化も理解する必要がある。これらのチームは物事の文脈や異なる文化的背景によって衝突が起こりやすい。外交官の役割はこうした衝突を解決することだ。社交性のある人材を見つけることができれば、こうした問題をよりかんたんに解決することができるだろう。

外交官はどちらの方向に選出しても構わない。外国から来た人の中には現地語を理解して、ローカル組織側に入っていくことができる外交官となれるものもいるだろう。しかし、基本的にはローカルチームからインキュベーションチームに外交官を選出するほうが良い。ローカルチームから派遣される外交官はすでに様々な人との関係値や会社のカルチャーに対する理解、特定のビジネス知識といった「資産」を積み上げているからだ。

課題と解決策

インキュベーションチームの課題は組織の分裂にある。異なる言語を使っていると、同じ考え方を組織に浸透させることは難しくなる。 インキュベーションチームは情報や指示がなかなか下りてこないことに文句をいい、ローカルチームはインキュベーションチームがビジネスの背景や会社の文化を理解してくれないと嘆くだろう。その結果、この２つのチームは衝突を起こしがちになる。

この問題を和らげるためには、やはり外交官の存在が鍵となる。自分の過去の経験で、インキュベーションチームがローカルメンバーの支援を得られず進捗を作れないと不満をいだいている局面があった。ある日、英語が達者で各方面にコネのある同僚が入ってきて議論に参加すると、たちどころに衝突が解消してしまった。彼女はインキュベーションチームが持つアイディアを理解し、ローカルチームのメンバーに適切に翻訳した。彼女はまた、彼女の持つ関係値を活用して、ローカルチームのサポートを求めた。この話の様に外交官は２つのチームがより良く仕事をするに当たって決定的な役割をもつのである。

幼児がずっと保育器の中にはいっていられないように、インキュベーションチームの仕組みはチームが大きくになるにつれて変えていかなければならない。次回は、インキュベーションチームから次のステップへの移行について別の記事で語りたいと思う。

原文:

yuichi-murata.medium.com

効果的なリモートインタビュー -- 候補者を理解し惹きつける方法

日常としてのリモートインタビュー

リモートインタビューは日常的になった。実際のところ自分もほぼ一年近く候補者と対面したことはない。はじめのうちは、リモートインタビューに慣れる必要があった。コミュニケーションは初対面だと特に難しい。ホワイトボードを使った議論などいままで使えた方法も使えなくなってしまう。 しかしながらリモートインタビューに慣れるにつれ、いくつかの優れた方法を見つけた。

この記事では 3 つの効果的な方法について、自分の経験から語りたい。

方法1: 資料をつかってポジションを説明する

まずはじめに紹介する方法は、資料を使って候補者に該当ポジションを説明することである。

面接を通じて相手を見定めようとしているのはあなただけではない。候補者こそ、あなたとその組織を見定めようとしている。特に現状の採用市場を鑑みると、エンジニアにはたくさんの機会がある。自分が候補者を選ぼうとする前に、まず候補者に自分を選んでもらうことが大切だ。面接は候補者にポジションの魅力を伝える絶好の機会である。そのポジションの魅力を伝えるために、時間をさくべきだ。

リモート会議システムを使った場合、プレゼンテーションの共有は簡単だ。ボタンを押してシェア完了だ！候補者の視点から見れば、図や表などの資料を通じて説明を聞いたほうが、口頭でされるよりもずっとわかりやすい。面接官が自分のためにより準備をしてくれて、歓迎されていると感じることだろう。

方法 2: 資料を使って演習をする

あなたは面接中演習の資料を提示することもできる。

これは自分の同僚から学んだやり方だ。彼はソースコードを提示すると、候補者にコードレビューを求めた。ホワイトボードにコードを書き出す必要はない。彼は事前にソースコードをテキストファイルで用意しておいていつでも提示できるようにしていたのだ。

こうしたコードレビュー面接は、以前はホワイトボードに簡単なアルゴリズムを書いて実施したりした。しかし、画面の共有を用いたやり方は、より複雑で実践的なレビューを可能にする。この方法は候補者が以下に注意深く実装をレビューするか見定めるのにうってつけだろう。

Photo by Luca Bravo on Unsplash

方法3: コラボレーションをする

もし候補者を採用する前に一緒に仕事ができたらどうだろうか。実際にやってみると良い。

昨今のリモートドキュメントツールはリアルタイム・コラボレーションをサポートしている。プライベートリンクをシェアすれば、ユーザー登録をしなくてもコラボレーションに参加できる。

簡単なアーキテクチャ図を Draw.io や Google Slide に貼り付けてみよう。候補者と一緒に解決してみたい、いくつかの技術的な課題を図の中に入れておく。

あなたは候補者に質問をして、アーキテクチャ図を修正する。あるいは、候補者に設計をリードしてもらって、候補者に更新してもらっても良い。候補者とあなたの正確や仕事のスタイル次第でどの様に進めても良い。

このアプローチの良いところは、コラボレーションがどの様に実施されるのかお互いが理解できることだ。あなたは候補者があなたの同僚とどの様に議論をするか理解できる。候補者はその会社に入ったときにどの様に設計をするか想像できるだろう。

リモート環境を活用してインタビューをする

これらの方法はオンサイトで実施できないものではない。しかし、リモート環境ではずっと簡単である。共有ディスプレイを会議室に置く必要はない。PC をつなく必要もない。ただボタンを押してあなたの画面を共有するだけだ！候補者の方もコラボレーションをするための PC を前にしていることだろう。

リモート面接体験を活用して、候補者をより理解しよう。そして候補者にその機会をより良く理解してもらおう。

原文:

yuichi-murata.medium.com