見出し画像

Living in ambiguity (不確実性の中で生きる)とは何か

So @lmanul quit Google and released a bunch of internal-only Google comics, and I have a favorite.

Ron Amadeo

Living in ambiguity とは何か

この画像は Internal Only だと思ってましたが、普通にツイートしてる人がいましたので掲載させてもらいます笑
これは社内では有名な Meme 画像でして、これまで存在したメインの道は Deprecated(廃棄された)で、では新しい道はどうかというと、Under Construction (今作ってる最中)という、にっちもさっちもいかないことを表した画像です。今でこそこういうことは減りましたが、昔はこんなんばっかりだったそうです笑

さて、今日は短編で「Living in ambiguity」について書こうと思います。これは 巨大 Tech 企業においては必須スキルですから、これから Tech 企業を志す人は是非理解しておくと良いでしょう。今年は Hult の後輩学生の皆さんからLinkedIn で多くの問い合わせを頂いているので、それも兼ねて、こういう記事がもっと書けるといいなと思っています。

僕が Google 入社前に漠然と思っていたことは、「Google ともなれば、全ての情報がまとまっていて、全てが自動化されているのだろう」ということです。で、いざ入社してみると3日でそれが幻だったことに気づきます。自動化について言えば、「Google ってなんてマニュアルなんだろう、これ明らかに人足りてないよな?」みたいな状況はたくさんあります。どうしてこういうことが起きるのかというと、「Google では常に新しいことにチャレンジすることが求められる」からです。もちろん、過去に作ったツールの継続的な改善なども行いますが、それらも新機能ですから、Under Construction の状況は常に存在するのです。

で表題の「Living in ambiguity」についてなのですが、思い返してみると、「Living in ambiguity」自体が Role Requirement になっているポジションをいくつか見たことがある気がします。これはどういうことかというと「ウチのチーム結構いろいろコロコロ変わるけど、ストレス感じずにやれる人募集!」ってことなんだろうと僕は理解しています。僕はいわゆる非エンジニアで、言っちゃえばオペコンのような仕事なので、Leadership の鶴の一声で、今日はこっち向いてるけど明日は真逆を向いてるみたいなことがよくあります。僕は性格的にカチッと決まったことが好きなタイプなので、確かに最初はストレスを感じることもありましたが、慣れました。いくつか例を挙げましょう。

例①
5/25
??「6月1日から新プロジェクトローンチします!マジインパクトでかいんでマネージャーはしっかり準備してください!」
僕「了解っす!もっと早く言ってほしかったです!でも頑張ります!」
5/27
??「6月1日予定だったプロジェクトですが、6月8日に延期になりました!それ以上の情報はありません!」
僕「了解っす!もっと早く言ってほしかったです!でも時間できて良かったです!」
6/8
??「新プロジェクトは無期限で延期されました!」
僕「了解っす!準備に使った時間返してください!」

例②
11/15
??「この案なんだけど、既存のヘルプセンターに例を加えたらいいんじゃないかな?ちょっとそれで作ってみてくれる?」
僕「(うーん、それはどうかと思うけど…)了解っす!来週新しいバージョン持っていきますね!」
11/22
??「この案なんだけど、どうしてこのヘルプセンターに例を入れたの?これってちょっと現実的じゃないし、前例もないから私的には承認しかねるわ。」
僕「(黙って立ち上がりパソコンを窓から投げる)」

例①の方は、大きなプロジェクトによくあることですね。規模とインパクトがデカすぎいて、なかなか上層部でも方針がまとまらない案件です。法的な Implication がでかいと尚更意思決定に時間がかかります。例②の方は、忙しい人にありがちなやつですね。あまりに忙しすぎて自分が言ったことを覚えていないやつです。これも結構な頻度であります。

「Living in ambiguity」とは何ではないか

で、Entry Level の読者のために書いておきたいのは、「Living in ambiguity」とは何ではないか、です。不確実性の中で仕事をするということはストレスですが、ただ闇雲に自分で道を切り開くものではありません。そこで、Manager や Stakeholders との Expectation Setting が大事になってきます。大事なことは:

  1. Living in ambiguity とは、一人で意思決定を行うことではない。また、戦略的意思決定とも違います。

  2. 不確実性が高ければ高いほど、自分が使うリソース(i.e. 時間)について Manager とすり合わせを行い、了承を得ること。

  3. わからないことをそのままにしていいということではない。Project Manager に進捗を聞いたり、コンスタントに Stakeholders にアップデートを求めるのはあなたの仕事の内です。

まとめ

というわけでツラツラと書きましたが、結局何が言いたいのかというと「Living in ambiguity」ってめっちゃ大事なスキルだよ!ということです。外資でこのスキル無しにやっていくのは不可能です。(全て僕に当てはまるのですが)せっかちな人、頭に血が登りやすい人、真面目な人、はストレスでメンタルを壊さないように、今からリラックスする訓練をしておきましょう。自分がコントロールすることができない、他人依存のプロジェクトではこういうことばっかりです。いちいち怒っていたらキリがない。他人のせいで自分のプロジェクトが頓挫すると流石に怒ってもいいですが、基本、他者依存のプロジェクトが頓挫したからと言って、あなたの評価に影響はありません、だってあなたのせいじゃないもんね。でも、「Living in ambiguity」は大事。僕たちの世代は常に新しいことをやっていくわけですから、常に不確実性に晒されます。ストレスでメンタルやらないように、一緒に不確実な世界で未来を創っていきましょう!


この記事が気に入ったらサポートをしてみませんか?