Sudoインターン記(1)

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

2015年7月から2016年10月までの1年余り、僕は大学2年の後期に最初のインターンを始めた。それがSudoだ。その頃はちょうどSudoが立ち上がって間もない時期だった（とはいえ公式サイトは大体出来上がっていて、継続的にイテレーションを回している最中だった）。加入した時はだいたい13、14人程度しかいなかった。

すべてがまだ不透明な中で進んでいて、エンジニア向けサービスを提供する会社に身を置いていたこともあり、オフラインのコミュニティやカンファレンスに数多く参加する機会に恵まれ、その過程で多くの優秀な開発者と出会うことができた。

最高のインターンとまでは言えないかもしれないが、間違いなく非常に刺激的で充実した1年だった。当時はたくさんの出来事があり、学業と仕事の両立に追われて途切れ途切れにノートを取るくらいしかできていなかった。ちょうど最近新しい仕事を探すタイミングになり、過去に書き留めた断片的なメモを整理して、この道のりを記録に残しておきたいと思った。

このインターンは熙哲（シーザー）の紹介から始まった。当時、それまでのプログラミングの遅れを取り戻すため、アルバイトがない時は図書館にこもってJavaを書いたり、Webページを作ったりしていた。長時間集中する必要があったし、スマホのネットも繋がっていなかったため、当時の同級生からすれば僕はなかなか連絡のつかない人間だった。

ちょうど熙哲が僕がWebに興味を持っていることを知っていて、あるスタートアップに行って話してみないかと紹介してくれた。まさかそのまま入社することになるとは思ってもみなかった。

幸運と言っていいのかは分からないが、1つの会社の立ち上がりからサービス終了までを経験できたのは、とても貴重な経験だったのかもしれない（もう二度と体験したくはないけれど……）。

Sudoとは？

サービスは既に終了してしまったが、Googleでキーワード検索をすると今でもかなりの検索結果が出てくる。大まかに分けると以下のようなものだ：

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

フロントエンド戦国時代

入社した当初はJavaScriptにまだあまり慣れていなかったため、まずはtuts+のチュートリアル講座から始めて（会社持ち）JavaScriptの基礎を固め、家に帰ってはサイ本（JavaScript: The Definitive Guide）を齧りながらよく分からない概念を理解したり、いくつかの組み込み関数（built-in function）を自作してみたりしていた。

当時のフロントエンドはまさに戦国時代に突入したばかりだった。Angularのブームが落ち着き始め、Reactが徐々に人気を集め、従来のFluxがReduxに取って代わられつつあり、Babel、ES6構文、Webpackなどがほぼ同時期に一気に台頭してきた。幸運なことに、チームがちょうど複雑なページの開発にReactを採用していたため、関連する技術を学び始めることができた。

もともといたフロントエンドエンジニアが退職した後、僕がメインサイトの開発を引き継ぐことになり、初めてチームと密に連携して仕事を進めることになった。スクラムを回し、チケットを消化し、PRを出し、スタイルガイドラインを書き、linterを導入するなど……これほど整った開発プロセスを持つスタートアップは多くないことに後から気づいた。大半のスタートアップでは、上司が思いついた機能をそのまま開発しろと指示し、開発プロセスもメンバーそれぞれの認識の違いによってばらつきが生じてしまうものだ。

開発チーム

まだ開発チームの紹介をしていなかった。僕がSudoに入った当時の開発チームには、顆顆（コーコー）、Peter、Denny、Henryがいた。

最初は単純にこの人たちと一緒に働くのがすごく楽しいと思っていただけだったが、後になってこれほど揃ったチームに出会えるのは本当に滅多にないことだと気づいた。

インターン期間中はDennyと顆顆がWeb開発に専念していたため、Babel、ES6（当時は急速に普及している最中だった）、React、Reduxを徐々に学んでいった。さらにはRxJSが台湾でまだ話題になる前から、Dennyはいち早く僕のところに来て「暇なときにRxJSを見てみなよ。Functional Reactive Programming（関数型リアクティブプログラミング）だから」と言ってくれた。

Denny

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

音楽の世界では並外れた業績や技術を持つ人を「悪魔に魂を売った」と形容することがあるが、Dennyを表すなら「コードに魂を売った」と言えるかもしれない。

こう言うとDennyがただのプログラミング偏執狂のようでフェアではないかもしれないが、コードを書く以外にも、彼は「世界大代誌」や「求職天眼通」を立ち上げた。

僕が最も印象に残っているのは、ある日早起きして（午前4時）コードを書こうとしたとき、まだDennyがオンラインになっていて、Slackでメンションしたらなんと返事が返ってきたことだ。また、ある時の社員旅行でみんながゲームをして遊んでいる最中、Dennyは一人ノートPCを開き、「funfun function」というチャンネル（関数型プログラミングを扱うチャンネル）を見ながら居眠りしていたことだ。

大半の人の努力のレベルは、まだ才能を競い合う段階にすら達していない。

これが、Dennyから得た最も大きな気づきかもしれない。インターンの後半で彼は退職してしまったが、彼の姿勢や学習に対する熱意は、僕がずっと尊敬し続けているものだ。

情報系専攻でもない人間がここまで本気でやってるのに、お前は何をもたもたやってんだ？

だいたいこんな感じだ。

Peter

まずはスキル面から。HTMLやCSSが書けるデザイナーというだけでもすでに希少なのに、彼はBootstrapやRuby on Railsの構文を使って開発をサポートし、GitHubでPRを出してフロントエンドの画面上の問題を解決することもできた。

彼がデザインする画面は、決して理想主義的なものではなかった。

一般的なデザイナー（特にグラフィックからUIデザイナーに転向した人）は、往々にして極めて完璧な画面をデザインしがちだ。テキストの長さがぴったりで、画像が綺麗で、カードの高さが揃っていて、固定幅になっている、といったような。

しかし実際のWebページにおいては、状態は1つだけではないし、入力も想定通り完璧なものばかりではない。テキストが長すぎる場合の処理や、改行、三点リーダー（省略記号）はどうするのか？

他にも考慮すべき状態がある。空状態（Empty State）、エラー状態、極限状態（境界値）、ローディング状態など、これらはデザイナーが陥りがちな盲点だ。

もう1つの点は、Peterがエンジニアと積極的にコミュニケーションを取り、不合理な要望にはしっかり対応し、問題をクリアにしようとしてくれたことだ。チームに入ったばかりの頃の僕は、立場上（最年少で、まだ学生で、開発経験も一番浅い）、自分の意見を述べるのをずっと躊躇していた。しかし彼は、もっと意見を言って自分の考えを出すようにと勧めてくれた。なぜならコミュニケーションを取らない結果は悲惨なことになるからだ。このことは、Sudoに参加した後に痛いほど実感した。

Henry

Henryは経験が非常に豊富なエンジニアだ。Web開発、アプリ開発、バックエンド、DevOps、Linuxの操作に至るまで精通しており、技術に関する情報も頻繁に共有してくれたため、彼からは多くのことを学んだ。

開発に関する質問だけでなく、Henryはゲームの疑問、Steamのセール情報、海外ドラマの鑑賞ガイドに至るまで何でも答えてくれた。

顆顆

顆顆はまさにプログラマーの三大美徳（3 great virtues of a programmer）の体現者のような人だった。これらの特性は一見ネガティブに見えるが、ソフトウェア開発においては美徳となる。そして顆顆の性格は、その後の僕に大きな影響を与えた。まずは動くものを作り、それから良くしていく（先求有再求好）。

怠慢 — Laziness

Sudoでは多くの作業が自動化されていた。自動デプロイ、CI、運用上のあれこれを連携するSlack bot、他部署が統計データを取得するためのHubot、Rollbarなど、これらはすべて顆顆（とHenry）が一から構築したもので、開発の手間を大幅に削減してくれた。僕自身がその構築に関わったわけではないが、その過程でDevOpsの知識や代表的なサードパーティサービスについて徐々に理解を深めることができ、その後の開発にとても役立っている。

James

上司の存在は重要だ。仕事に対する満足度のほとんどを左右すると言ってもいい。議論の論点を正しい方向に絞り込み、開発スケジュールをコントロールする。

こうした一見当たり前のように思えることは、他の会社で働いた後になって痛烈に実感した。誰もミーティングの時間を設定せず、会議に明確な目標もなく、スケジュール管理もフォローアップも誰もやらない。その結果、開発スケジュール全体が崩壊して初めて、気持ちよく一緒に仕事ができるPMに出会えることがどれほど貴重なことかを思い知った。

他のチームに関しては、実際に密な共同作業をした経験がないため、ここでは割愛する。

Sudo週刊

Sudo週刊は、開発チームがお互いに見つけた技術を共有するために顆顆が中心となって立ち上げたものだ。メンバーが散り散りになるにつれてすっかり更新されなくなってしまったが、過去のアーカイブを参考として見ることができる。

つづく。