はじめまして。2021年4月新卒入社の椎野良介（しいのりょうすけ）です。私は学生時代から競技プログラミング（略して競プロ）をしており、フューチャー入社のきっかけも競プロという、いわゆる純粋競技プログラマーです。私のようなバックグラウンドの方からフューチャーのキャリアプランを見ると、後述のSAIGやTIGといった最適化案件に特化した部門を真っ先に思い浮かべるかもしれませんが、私は基幹システム刷新などのフューチャーで多数を占めるようなプロジェクトに継続して携わっています。そんな私の入社のきっかけと、入社後に感じたありのままを書いていこうと思います。これからファースト/セカンドキャリアを考える方々に、フューチャーでは若手でも責任ある業務にチャレンジできることを知っていただければ幸いです。

入社のきっかけはHTTFで聞いた「難しいことが好き」という言葉

私は大学で高分子工学という、化学系の分野を専門にしていました。その中でもシミュレーションを行う研究室に入り、プログラミングの勉強がてら「AtCoder」で競技プログラミングを始めました。そこから、フューチャーが主催するコンテスト、HACK TO THE FUTUREの本戦に招待されたことがフューチャーとの初めての出会いです。コンテストなのでメインはプログラミングの問題を解くことですが、コンテスト前に聞いた会社紹介で「難しいことが好き」と言っていたことが印象的でした。

その後しばらくして就職活動をスタートさせます。当初は大学の専攻に沿って化学メーカーをメインにエントリーしていましたが、企業の情報収集をして自身がやりたいことは何かと改めて考え直すと、さまざまな領域で課題を探し、頭を使って解決していくことに取り組みたいのだと気付きました。そこで思い出したのがフューチャーでした。改めて話を伺ったところ、楽しみながら難題に取り組んでいるイメージが湧きあがり、入社を決めることとなりました。

入社後に競プロ経験が役立ったことと苦労したこと

競プロきっかけで入社した私ですが、SAIGやTIGなどの技術寄りの部門にアサイン希望を出しませんでした。私自身、入社した段階では技術スキルを磨くことよりも、多くの業界に関わり、自身が興味のある業界業種を探すことが優先であると考えたためです。異なる業界のプロジェクトを経験した今、この選択は間違っていなかったと思います。

研修を終えてから今までで、2つのプロジェクトにアサインされています。1つ目は人材業界、2つ目はアパレル業界です。

プロジェクト➀：人材業界

基本設計フェーズでのアサインでした。アサイン直後から、主要機能の設計とお客様への仕様説明を任され、参画して日が浅いながらもチームの1メンバーとして扱われているということを強く実感しました。このプロジェクトでは競プロの経験が役に立ちました。お客様とのセッション中に機能追加を検討する際、処理方針とだいたいの計算量をその場で想定しながら会話を進めることができました。例えばテーブルAとテーブルBを結合する、のような処理方針だけであれば誰でも話せることだと思います。私はそこからさらに合計の処理データ量まで見積もった上で、十分高速に動くことや若干時間がかかるなどの概算までお伝えし、意思決定をスムーズにしていただけました。また、説得力のある回答をすることでお客様からの信頼感を築くことにも繋がったと自負しています。

一方で、競プロと同じような考え方では通用しなかったという経験もしました。競プロではコーナーケースを常に意識する必要があるため、セッションの際にも一回で合意を取りきろうとするあまり、細かいパターンにまで踏み込んで話をしてしまいました。しかし、いきなり細かいパターンの話をしてもどうしてその話をしているのかお客様には伝わらず、結局何も決めることができませんでした。まずは大筋を決めて全体のイメージを共有し、細かいところは後で詰めていくというのがオーソドックスな進め方だと後でリーダーから教わりました。

プロジェクト②：アパレル業界

ここでは既存システムのアーキテクチャ刷新と新規機能追加の2つを行う案件に要件定義から携わり、現在は内部結合テストに取り掛かり始めたところです。このプロジェクトでは、設計のインプットとして既存システムを調査するということが何度もありました。その際、主に設計書を参照するのですが、設計書の記載では分からない部分もあり、ソースコードまで辿ることもしばしばあります。そして、得てして設計書では分からない部分はソースコードも複雑になりがちなのですが、競プロの再利用をするつもりのない状態で書かれたソースコードよりは読みやすいと自分に言い聞かせて乗り切ったという経験があります。

そのような過程を経て作成した成果物のレビューでは「この設計のインプットは何？」「検討の過程で考えたことを教えて」など、ゴールにたどり着くまでに調べたこと、検討したことを重視した上長からのコメントを受けました（もちろん成果物の正しさも見ていますが）。正しいゴールにたどり着いてさえいればその手段は問わない、とは言いますが、どのような経路を辿ってゴールにたどり着いたかを一つ一つ言語化していく必要があり、最初の頃は言語化のための準備に苦労しました。これがチームで仕事をするということなのだと頭では理解しつつも、元来考えたことをまとめるのが苦手であったこともあり、この作業がそれほど大事なのかと疑問に思う時期もありました。

ですが、要件定義や基本設計から時間が経ち、自身が設計したものをテストする今の段階になってみると、ゴールまでのプロセスも重要であると体感ができました。テストの際にデータのライフサイクルが記されたドキュメントを見たり、不具合があった際にその機能が参考にした既存システムの機能を見に行ったりなど、言語化のために過去の自分たちが作った資料が非常に役立っていることを実感しています。使い捨てのコードを書いている競プロとは違い、機能作成者の手から離れた場所で長く使っていく必要があるからこそドキュメント整備が大事なのだと理解できました。

スキルを磨きたい自分にピッタリの環境があった

競技プログラマーであった私が、入社して2年半ほどで経験した・感じたことをお伝えしました。もちろん知識や経験がそのまま役に立つというわけではないですが、これまで競プロを通じて培ってきた素養や、アルゴリズム的思考力は業務の節々に役に立っていると実感できています。

また、フューチャーでは若手でも責任のある（≒難易度の高い）ことを任せられることが多く、競技プログラマーのように自身のスキルを磨きたいという方にはピッタリの環境だと思います。早いうちからチームやプロジェクトに貢献しているという実感が得られるため、大きな業務に携わりたいという希望も叶えられます。

この記事を見て、必ずしもSAIGやTIGだけがアルゴリズム力を活かせる場所ではないと知ってもらい、フューチャー全体に競プロ出身の方が増えてくれることを願っています。