英会話アプリ「TerraTalk」を開発・運営しているジョイズ株式会社の柿原です。今回はWantedlyの「社会人１年目を振り返って」のテーマに乗っかって、１０年ほど前の自分のキャリアの原点を振り返ってみることにしました。

１年間のフルタイムインターン

私が物理学と経営学を勉強していたイギリスのバース大学では、１年間の休学を前提にフルタイムでのインターン経験が制度化されていました。学部や学科によってスタイルはまちまちで、例えば経済学では２年目に半年、３年目に半年の計１年。分子生物学ではフルタイムで働きながら課題を提出することで単位を認めるなど、イギリスの中でも、生徒の経験本位で柔軟にプログラムを組む大学でした。

そんな中で、多くの学生と同じように私も１年間のインターンを選び、プチ就活ののち縁のあったMet Office（気象庁）でお世話になることになりました。

異国の官公庁の、組織内スタートアップ

配属されたところは、社内IT部門の中のAdvanced Visualisation & Dataというチーム。当時私と上司を入れて４人の新しい組織でした。出来たばかりで、既存のオペレーションにも含まれず、成功を約束されているとも言えませんでした。組織内スタートアップという表現がしっくりきます。ミッションは、化石化しつつある庁内のソフトウェア基盤を現代化すること。ちょうど庁全体が半民営化・独立採算となり、オフィスも移転、外部からビジネス経験豊富なCEOを招聘するなど変革のさなかにありました。

紙の上では半民営化したとはいえ気象庁は研究開発機関ですので、ソフトウェア基盤投資の中の大きな部分をデータ解析や集計系が占めていました。そんな中で、組織に与えられたミッションは大きく分けて３つありました。

1. 新しいツール群を使うユーザー（研究者）のサポート

2. 古いツール群から新しいツール群にシームレスに移行するためのツールづくり

3. 組織的な移行に必要な熱量を醸成するためのキラーアプリの開発

私に与えられた役割は３、キラーアプリの開発。平たく言えば、新しい技術を使って未来を先取りして具現化し、組織、特に意思決定者にわくわくしてもらい、コトを動かす、という仕事です。

素人仕事→技術的負債

仕事を始めて5ヶ月ほどたったころでしょうか。アプリの原型がかなり出来上がってきました。コーディングにもかなり慣れてきて、一見順調に見えます。ところが。

「デバッグが、どんどんしにくくなっている・・・」

素人が何も考えずに書き始めたプログラムはなんと1ファイル8000行というとんでもない構成になっていました。ほぼグローバル変数とベタ書きの関数のみで構成されたそのアプリは、不具合をひとつ直すとすぐ他に影響が出てしまう。新機能追加なんてもっての他です。

そうやって困っているところに上司が新機能のアイディアと共にやってきました。

「これさ、２ヶ月ぐらいでできるかな？」

話を聞いてみると、規模の大きい機能が複数個。予算を取る上で必要な人物を動かすために必要な機能のようです。実装自体は２ヶ月で出来てもおかしくありませんが、なにせ前述の状態です。デモが確実に出来る水準まで到達するかは未知数でした。

「２ヶ月ですか・・うーん・・・」

「無理そうかな？」

出来るだけ早くデモをしてコトを前に運びたい上司の気持ちもわかる。一方で、このまま開発を進めてしまうと行き詰まることも目に見えている。何より、きちんと設計してこなかった自分の非を認めるのは少し怖い。

「１ヶ月、新機能の開発を止めてもいいですか？」

「え、どういうこと？」

「リファクタリングしたいんです」

リファクタリングとは、プログラムの見た目や機能を変えずに内部構造を整理することです。リファクタリングといっても、この場合はほぼ全面的な書き換え、大手術です。失敗して努力が無駄に終わる可能性もある。最終的な成果物の品質、後々の生産性を上げるための一種の賭けでした。

最終的には、この提案は受け入れられ、リファクタリングも結果的に２週間程度で終わり、オブジェクト指向を適用した新しい設計により新機能の追加も楽に出来るようになりました。

失敗からの学びこそが、本当の学び

上記の話は、結果だけ見れば成功にみえますが、不要なリスクをプロジェクトに持ち込んでるという点では大失敗と言えます。この件での最大の学びは何でしょうか。オブジェクト指向を用いた再利用性の高い設計手法でしょうか。はたまた、予め日程の余裕を入れ込む開発マネジメントの必要性でしょうか。

答えは「上司の要求は絶対ではないし、本当に達成すべきゴールが別にある可能性がある。真のゴールを見つけてそこにたどり着くプロセスを共有することこそが大事」ということです。

「新機能ABCを２ヶ月以内に」という要求は、真のゴール「意思決定者のニーズに沿ったデモをし、予算を獲得する」を満たすために、諸々の条件を上司が勘案して導き出した私個人の作業目標だったわけです。ここでポイントになるのは、常に現場に張り付いているわけではない上司は、細かな状況やリソースについて担当者ほど深く把握していないことが多いということ。必要に応じて事実関係を補完することで、上司の判断の質をより高くすることが出来るのです。

この経験は、日本に帰ってきてからソニーで働く中でも、独立・起業して多種多様なメンバーを統括するようになってからも、同じように生きています。

ソフトウェアの作り方、作業計画の立て方、メールやアポ取り、プレゼンなどのビジネススキル。１年間のフルタイムインターンで学んだことは数知れませんが、自分の仕事の進め方の根幹を作ったのは、履歴書やレジュメには表れない思考法の部分でした。