@kyanny's blog

Write down what I learnt. Opinions are my own.

Quipper に入社して丸4年が経った

f:id:a666666:20170601211711p:plain

blog.kyanny.me

一年経ってしまった。いろいろあった。一年前はオフィスのことしか書かなかったので、今年は自分のことだけ書く。

Engineering Manager

今年の1月に会社の組織変更があり、 Engineering Manager というポジションができた。国単位・技術分野単位などで開発者をいくつかのチームに分け、それぞれに Engineering Manager がいるという、いわゆるふつうのピラミッド型の組織になった。で、俺が東京オフィスの Web Developer チームの Engineering Manager になった。

上司(CTO)から話があったのは去年の11月頃だった。プロダクト開発チームがグローバル全体で50名くらいになってきて、そろそろ CTO 一人で見るのは無理がでてきた、そこでローカルに Manager をつくり各種の業務や権限を委譲していきたいのだがどう思うか(やってくれるか)、という感じだった。

個人的には Zach Holman がいた頃の GitHub のような、マネージャー不在でもうまくいく超フラットな組織が理想だと思っているが、いろいろ、いろいろな事情を鑑みると、伝統的な組織の形にする必要性も十分に感じていた。マネージャーになりたいなどとは思っていなかったけど、チーム全体のことを考えると、誰かがそういう役割を担ったほうが良いのは明らかだった。できれば俺ではない、誰かが。

チームの一員として、立場とか肩書とか関係なくプロジェクトの成功のためにすべきと思うことはやってきたつもりだ。その中には、会議をファシリテートしたり、議論のイニシアチブをとったり、開発者以外のステークホルダーと対話したり、何かを決断したり、という行動も含まれていた。そういうことを専らやるのだ、単にそういう役割なのだと思えば、やってやれないこともないと思い、話を受けた。

実際やってみると、いろいろ想定外のこともでてきた。

最大の誤算は People Management の仕事の重さだった。人事関連の業務も権限委譲されたので、人事評価をする上で必要な目標設定なども Engineering Manager が行うことになった。これは大仕事だ、ということを、マネージャー側の仕事をやってみて思い知った。

各メンバーの強み・弱み・適性・志向などを踏まえて「ちょうどいい」目標を考え、「なぜその目標に挑戦して欲しいのか」「その目標に挑戦する過程でどんな成長を期待しているのか」「目標を達成することでどんな成果をだして欲しいのか」などを本人とじっくり話し合い、認識を合わせる。そういう目標を、一人につき最低三つ設定する。

目標は四半期ごとに設定し振り返りをするのだが、プロジェクトの状況・やるべきタスクなどは日々変化していくので、三ヶ月に一回の話し合いでは少なすぎる。「1 on 1 は最低でも隔週で実施すべき」ともいうし、自分でやってみても月一ではまだ少なすぎると感じたので隔週で会話する。状況の確認・困っていることのヒアリング・問題の見極めと解決のための動き・結果のフィードバック、などなど、会話そのもの以外にもやることはある。

それを全員分やる(今数えてみたら17名だった)。皮肉なことに、自分自身の目標設定は、四半期の終わりが見えてきた今も空のままだ。

今年の4月に人事制度が大きく変わり、 People Management の仕事が大幅に増えたのも想定外だった。昨年話を受けた時点では、 People Management でやることといったらせいぜい休暇申請の承認くらいで、それなら構わないだろうと思ったものだった。正直、こうなることを予め知らされていたら、話を受けなかったかもしれない。

マネージャーの仕事やることになるからプロダクトコードを書く時間は減ってしまうだろう、と覚悟はしていたが、読みが甘かった。 People Management 以外にも、会議がずいぶん増えた。どの会議も必要性は理解できるし、「とりあえず誰かご相談」みたいなぼやっとした話を聞くのも(場合によっては聞いたその場で斬り捨てるのも)マネージャーの仕事だと思って参加しているが、日によっては自席に全く座っていられないこともある。

まとまった、どころか細切れでもプロダクトコードを書く時間を捻出できなくなり、自分が開発タスクを担当してもスケジュールに間に合わせられる自信が無いので、プロダクション環境で動く「一軍」のコードを書く仕事からは手を引くようになった。社内向けの運用業務などで使う「二軍」のコードはかろうじて書いているが、そう遠くないうちに「一軍」のコードにキャッチアップできなくなり、「二軍」のコードすら書けなくなってしまうのだろう。こうして「コードの書けないマネージャー」の出来上がり、だ。

開発リソースの配分も気が進まない仕事だ。そもそも「開発リソース」ってなんだよ、って話だし、「この人は○○担当、この人は○○チーム配属」とか、誰かがそんなことを決めたりしなくても各々が自律的に動いて物事を成し遂げる、そういうものに憧れていたんじゃなかったのか、なのになんで真逆のことをやっているのだ、という矛盾を感じずにはいられない。これ一番嫌な仕事かもしれない。

悪いことばかりでもなかった。「マネージャー」がでてくることで物事の進みを速くできることもあった。いろいろな会議に参加することで多くの情報を得られ、メンバーにシェアされているべきだったのにシェアされていなかった情報をシェアできるようになった。疑問や質問に、より的確に回答できるようにもなった。メンバー・チーム・プロジェクトの強み・弱み・特性などを踏まえて、メンバーの成長・チームの成果・プロジェクトの成功のそれぞれを最大化するという観点から物事を考えるようになった。

でもやっぱり、「まさかこうなるとはなぁ」と思わずにはいられない。少なくとも、自分の予想よりもだいぶ早く物事が進んだ。一年以上早送りした感じ。

たまに「マネージャーをやるモチベーションは何なの?」と聞かれるが、個人としてそこにモチベーションは無い。じゃあ何故やってるのか。プロジェクトがうまくいかなくてメンバーが疲弊したり、良いプロダクトが作れなかったり、そういうのをこれ以上見たくないからだ。曲りなりにもソフトウェアエンジニアという仕事を15年くらいやってきて、会社でもかなり古株のほうで、物事がうまくいかない理由や原因もある程度はわかっているつもりで。

だったら黙ってやればいい、だけどそれ俺がやるんだっけ?と躊躇してしまい、目の前の火種を見過ごして、後になって火事騒ぎを起こしてしまったこともある。一歩踏み出せない原因の一つに、「みんな対等なチームメイトなのに、俺がでしゃばって仕切ったりするのは良くないんじゃないか」という心理的な抵抗感もあった。でも「マネージャー」の仕事としてそれをやるなら、違和感は緩和される。人の目には「権力を行使している」ように写るであろう振る舞いに別の違和感を覚えたりもするが、それでプロジェクトが成功し、メンバーが疲弊せず、良いプロダクトが届けられるなら、悪くない取引だ。

ずいぶん昔から、「マネージャーの最後の仕事は、自分より優秀な後任者を見つけて自分をクビにすることだ。そのような新陳代謝が行われるのが健全な組織だ」と考えてきた。今もその考えは変わっていないが、後任者が自分と同じように苦労し、同じように悩むのかと思うと、気の毒すぎて押し付けるのが憚られる。「そうやって耳障りの良い言い訳を口にしながら、保身が本音ではないのか?」と自問することで、どうにかダークサイドに堕ちないようにと気をつけている。そう考えること自体が excuse なのかもしれない。わからない。

Non-Japanese members

今年に入ってから、東京の Web Developer チームに外国人のメンバーが増えた。

「仕事で英語を使わざるを得ない環境であること」が Quipper に転職した大きな理由の一つだった。英語力の向上は数年来の課題で、しかしいろいろな勉強法に挑戦してもことごとく挫折し、ものにならないままだった。こうなったら英語を使わざるを得ない環境に飛び込んで、毎日ふつうに仕事してるだけで勝手に英語が上達する、という「仕組み」を作らないとダメだと思い、実際飛び込んでみて、英文読解と英作文については思惑通りにある程度のレベルまで上達した。

が、英会話の機会は正直ほとんど無かった。

採用活動をあまり活発にやっていなかった時期もあったし、興味を持ってくれる人も、その中で採用に至る人も、チームメンバーと似た経験とスキルセットを持つ日本人に偏りがちになる。たまに外国人のスタッフが滞在することもあるが、やはり仕事で直接絡むわけではないので「英会話せざるを得ない」という状況からは程遠い。

海外オフィスは外国人スタッフだらけなんだから話しかければ英会話し放題じゃないか、と言われればその通りなのだが、なにぶん自分から話しかけて雑談するのが大の苦手で、英会話への強烈な苦手意識も相まって、自ら話しかけることなど到底できなかった。

やはり英会話せざるを得ない環境を作るよりないのではないか…と思いながら採用活動をしていく中で、ぽつぽつと外国人の開発者が候補に挙がるようになってきた。彼らは大抵スキルが高く、しかし日本語コミュニケーションが難しい(英語コミュニケーションが必須)というあたりがおそらく就職する上でネックになっていて、だからこそ転職市場でまだ「売約済み」になっていないのだと思われた。

スキルが高い開発者は採用したい。言葉の問題は、ふつうの日本企業だったら超えられない壁かもしれないが、 Quipper はグローバル企業だし、開発者は日常的に英文の読み書きでコミュニケーションしている。英会話だって、抵抗感よりもむしろ興味がある人のほうが多いだろう。大変だとは思うけど、挑戦する価値はあるのではないか。いろいろな意見があったが、最後は俺が強く希望して採用することにした。

入社したタイミングがちょうど年度末・年度頭に向けた開発の佳境の時期で、非常にややこしい背景やら仕様やらのレクチャーをしている余裕が無く、グローバルの開発のほうを専らやってもらったりしていた。その後、立て続けに外国人の開発者が入社し、いよいよ全員日本のプロジェクトに参加しはじめた。日本語コミュニケーションの流暢さにも個人差があり、従って周囲のメンバーが英語でフォローする度合いにも個人差があるが、ようやく「東京ローカルですらインターナショナルな開発チーム」になってきた。

あとは仕事を通じて英会話の頻度を高めていければ…という筋書きだったのだが、ここでも物事は早送りになった。彼ら彼女らは東京の Web Developer チーム所属なので、俺がマネージャーということになる。当然他のメンバーと同様に 1 on 1 もするし目標設定もする。日本語はまだまだ勉強中、という人もいるので、英語で会話することになる。正真正銘の「英会話せざるを得ない環境」だ。

やってみて気づいたのは、リスニングよりもスピーキングのほうが「慣れ」が早い、ということだった。スタート地点が低すぎたのもあるかもしれないが、スピーキングは誤魔化すことができない。なんでもいいから喋らないと、絶対にコミュニケーションできない。なので、どれほど拙かろうが、どれほど発音が悪かろうが、英語らしきものを発話するしかない。通じるかどうか不安でビクビクするし、通じてないとヒヤヒヤするし、そもそも「英語を喋っている自分」が恥ずかしくて顔が熱くなる。でも、そういうしんどい経験も、何度かするうちに慣れてくる。

とりあえず意思の疎通がとれる程度には通じているかな、と思う。たまに通じないときもあるけど、焦りつつもなんとか言い直したりしてその場を乗り越えられるようになってきた。少なくとも、「英語を喋っている自分が恥ずかしい」という段階は無事に卒業できた。今ではオフィスで周囲の目がある状況でも躊躇なく英語で話すことができるようになった。度胸がついた、というのが正しいかもしれない。

一方で、リスニングは度胸の問題ではない。従って、聞く機会が少々増えたからといって、そう簡単に聞き取りが上達することはない。少しはマシになってきているものの、スピーキングと比べると上達速度は遅い。聞き取れてなくても曖昧に笑ったりすることで誤魔化せてしまうので、かえってトレーニング負荷が減ってしまう。その場で聞き返したりすべきなのだが、それはそれで恥ずかしかったり面倒くさかったりして、なかなかできていない。特にアメリカ英語が苦手で、英語ですらない何か不思議な音にしか聞こえないこともざらだ。

まぁでも総じて、思惑通りといっていい。チーム内でも英語コミュニケーションの比率が上がってきているし、外国人の開発者たちも活躍していて、徐々に馴染んできた。一緒に仕事をしている Product Manager なども「我々も英語を勉強しないといけませんね」と言ってくれた。「Quipper の開発チームが国際化されることで、一緒に仕事をするリクルートの人たちにも国際化を促す」という個人的な野望があり、その実現に少し近づけたかな、と思う。

一年後に向けて

なんか全体的に愚痴っぽく暗い内容になってしまった。悩みと内省、ということにしておこう。そもそも俺がブログに書く内容は昔からずっとこんなのばかりだったので、平常運転ともいえる。

社会人生活をはじめて15年くらい経ち、フリーター時代のアルバイトを除くとこれまで4社に勤めてきたが、三年から四年で転職を繰り返してきた。ある意味、一番「ここに長く勤めよう」という気がないまま入った Quipper が、人生で最も長く勤めた会社になったのだから不思議なものだと思う。

CEO と約束したプロジェクトはどうにか終わった。約束した当時は、そのタイミングで一区切りつけてもいいかな、と思っていた。けど、もうしばらくここでやることがありそうだ。