Sudo インターンの旅(1)

本稿の内容は実話であり、もし類似点があっても偶然である。

2015–7 から 2016–10 までの1年以上のあいだ、僕は大学2年の下半期から最初のインターン — Sudo を始めた。その頃ちょうど Sudo はできてまだ間もなく（とはいえ公式サイトもほぼ整っていて、まだ絶えずイテレーションを重ねている段階だった）、参加時の人数もおおよそ 13、14 人ほどだった。

すべてはまだ不確定なまま進んでいたし、エンジニアに向き合う会社に身を置いていたこともあって、数多くのオフラインコミュニティや Conference に参加する機会に恵まれ、その途中で多くの優秀な開発者とも知り合った。

最高のインターンとまでは言えないが、確かにかなり刺激的な1年だった。当時はいろいろな出来事があったものの、課業と仕事で忙しく、断片的なメモしか残せていなかった。ちょうど最近、新しい仕事を探そうとしていたので、昔の断片的なメモを整理し、この期間の歩みを記録に残したいと思った。

このインターンは熙哲の紹介から始まった。当時、以前のプログラミングの進捗を取り戻すため、バイトがないときは図書館で Java を書いたり、Web を作ったりしていた。長時間の集中が必要だったうえ、スマホにはネットもなく、当時の同級生たちは僕を見つけるのがとても難しかった。

ちょうど熙哲が僕の Web への興味を知っていたので、新創公司を一つ紹介してくれて、話を聞きに行った。まさかそのまま入ることになるとは思わなかった。

それを幸運と呼ぶべきかどうかは分からないが、一つの会社の興隆からサービス終了までを経験できたのは、もしかするとかなり貴重な体験だったのかもしれない。（でも二度目はもう体験したくない……）

Sudo とは何か？

今ではサービスは終了しているが、Google でキーワード検索すればまだかなりの結果が見つかる。大まかに以下のように分けられる。

• エンジニアの転職を支援するマッチングプラットフォーム
• 学生のインターン探しを支援するマッチングプラットフォーム
• ヘッドハンターサービスに申し込んで転職先を探せるマッチングプラットフォーム
• エンジニア求人とインターン求人を検索できる大型プラットフォーム

フロントエンド戦国時代

最初に入ったときは JavaScript にまだ十分慣れていなかったので、まずは tutplus の講座（会社持ち）で JavaScript の基礎を補い、家では犀牛書を読みながらよく分からない概念をかじったり、built-in function の実装をいくつか試したりしていた。

当時のフロントエンドはちょうど戦国時代に突入しており、Angular のブームは徐々に去り、React が勢いを増し、もともとの flux は次第に Redux に置き換えられ、babel、es6 の構文、webpack などが、ほぼ同時期に一斉に台頭してきた。幸運にも、チームがちょうど React を使って複雑なページを開発していたので、関連技術を学び始めることになった。

元のフロントエンド担当が退職したあと、主サイトの開発を引き継ぐことになり、チームと密に協力するのはこれが初めてだった。いっしょに scrum を回し、チケットをさばき、PR を出し、style guideline を書き、linter を導入するなど、いろいろ経験した。のちになって、ここまで一連の流れが整っている新創公司は多くないのだと気づいた。大半は、上司が何か機能を思いつくとそのまま開発を求められ、開発プロセスも人それぞれの認識の違いでズレが生じがちだった。

開発チーム

まだ開発チームの紹介をしていなかったが、僕が Sudo に入ったばかりの頃の開発チームは、顆顆、Peter、Denny、Henry だった。

最初はただ単に、この人たちと一緒に仕事をするのがとても楽しいと感じていただけだったが、のちになって、こんなに充実したチームを見つけるのは本当に簡単ではないのだと気づいた。

インターン期間中は Denny と顆顆が Web 開発に注力していたので、僕も少しずつ babel、es6（当時ちょうど急速に広まりつつあった）、react、redux を学んでいった。さらに、RxJS が台湾でまだ始まったばかりの頃、Denny はすでに僕のところへ来てこう言っていた。「空いたときに RxJS を見てみて。functional reactive programming だよ」と。

Denny

こんな言葉がある。「体重と起床時間をコントロールできる人は、何でもできる」。彼はかつて、コードを書くために XXX を XXX した。

音楽界で、誰かの実績や技術が非凡なら、「魂を悪魔に売った」と形容されることがある。ならば Denny は「魂をコードに売った」と言ってもいいのかもしれない。

こう言うと、Denny がプログラミングに取り憑かれた偏執狂みたいで少し不公平かもしれないが、コードを書く以外にも、彼は「世界大代誌」と「求職天眼通」を立ち上げた。

僕の記憶でいちばん印象的だったのは、ある日早起きして（4:00 AM）コードを書こうとしたとき、Denny がまだオンラインで、Slack を叩いたら本当に返事が返ってきたこと、そして会社の社員旅行で、みんながゲームをしているあいだに Denny だけがノートPCを取り出し、funfun function というチャンネル（functional programming の話）を見て、見ながら居眠りしていたことだ。

大半の人の努力は、才能を上回るほどには至っていない。

これが、たぶん Denny から僕が受け取った最大の気づきだ。インターン後半の半年で彼は退職したが、その姿勢と学び続ける精神は、今でも僕が非常に敬服しているものだ。

本科出身でもない人があれほど真剣なのに、君はまだ何をふざけているんだ？

だいたいそんな感じだ。

Peter

まずはスキル面から。HTML, CSS が書けるデザイナーだけでもかなり少ないのに、彼は bootstrap や Ruby on Rails の文法も使って開発を手伝えたし、github で PR を出してフロントエンドのいくつかの問題も解決できた。

彼のデザインするページは、そこまで理想化されていなかった。

普通のデザイナー、特にグラフィック系から UI デザイナーへ転向した人は、非常に完璧なページを設計しがちだ。文字はぴったり収まり、画像はきれいで、カードの高さはそろっていて、幅も固定されている、といった具合だ。

しかし実際の Web では状態は一つではないし、入力も思い描いたほど完璧にはならない。長すぎる文字をどう処理するか、改行はどうするか、省略記号はどう扱うか。

さらに考えるべき状態もある。空状態、エラー状態、極端な状態、ローディング状態などだ。これらはデザイナーが見落としがちなポイントでもある。

もう一つは、Peter がエンジニアと積極的にコミュニケーションを取り、理不尽な要求には応答しようとしつつ、問題の切り分けもしてくれたことだ。チームに入ったばかりの頃は、立場の関係で（年齢がいちばん下、学生でもあり、開発経験もいちばん少ない）、自分の意見をあまり言えなかったが、彼はずっと「もっと意見を言って、自分の考えを出したほうがいい」と勧めてくれた。なぜなら、コミュニケーションしないと結局ひどい目に遭うからだ。この点は Sudo に入ってから僕も痛感した。

Henry

Henry はかなり経験豊富なエンジニアだ。Web 開発、アプリ開発、バックエンド、devops、Linux 操作まで非常に詳しく、技術情報もよく投げてくれて、僕は彼から多くを得た。

開発上の問題だけでなく、彼はあるゲームの疑問、Steam のセール、美ドラマの見方まで答えてくれる。

顆顆

僕は顆顆を、3 great virtues of a programmer の実物版みたいだと思っている。これらの特性は一見ネガティブに見えるが、ソフトウェア開発では一種の美徳でもある。そして顆顆の性格は、その後の僕に大きな影響を与えた。まずはあるものを作り、あとでよくしていく、という考え方だ。

怠惰 — Laziness

Sudo では多くのことが自動化されていた。自動デプロイ、CI、Slack bot による運営まわりの連携、hubot を使って他部門が統計データを取得できる仕組み、rollbar などは、いずれも顆顆（それから henry）によって一手に作られたもので、開発上かなりの手間を省いてくれた。僕はそこに直接参加していたわけではないが、その過程で devops に関する知識や、よく使われるサードパーティサービスについて少しずつ理解が進み、その後の開発にかなり役立った。

James

上司はとても重要だ。仕事への満足度の大部分を左右すると言ってもいい。議論の際に話題を正しい方向へ絞り、開発スケジュールを管理する。

こうした一見当たり前のことが、僕が他の会社で働いたあとにとても深く実感された。会議時間を決める人がいない、会議に明確な目的がない、スケジュール管理やフォローアップをする人がいない。結果として開発全体がめちゃくちゃになり、ようやく、気持ちよく協力できる PM を見つけることがどれほど貴重かを知った。

他チームについては実際に密接な協業経験がないため、ここでは詳しく紹介しない

Sudo 週刊

Sudo 週刊は、開発チームが互いに見つけた技術情報を共有するために、顆顆を中心として立ち上げたものだ。みんながそれぞれ別の道を歩んだ今では長らく放置されているが、過去の各号を参照してみるのもいいだろう。

続く。