Future Tech Blog
フューチャー開発者ブログ

アルバイト生から見たフューチャーのTIG DXユニット


導入

はじめまして。

2019/7/1にFutureへ新卒入社した棚井龍之介と申します。

現在は会社の新人研修に誠意取り組んでおります。

大学を卒業してから入社するまでの期間、私は Future の TIG DXユニットにアルバイトとして参加しました。

TIG: Technology Innovation Groupの略で、フューチャーの中でも特にIT技術に特化した部隊です。
DXユニット: TIGの中にありデジタルトランスフォーメーションに関わる仕事を推進していくチームです。

アルバイトの視点から見た「Future ってこんな会社なんだ」について紹介いたします。

筆者スキルセット

  • TCP/IP の授業を受けて、IT 分野に興味を持ちました
  • 大学時代の4年から、 AI 系ベンチャー企業で5か月ほど長期アルバイトに参加しました
  • 長期アルバイト中に触った技術
    • 言語
      • Python
    • インフラ寄り
      • Docker
      • AWS
    • OS
      • MacOS

Future 入って分かったこと

開発に使う技術

  • Go や Terraform など、イケイケのweb系企業が使いそうな技術をFutureでも使います

Future といえども ITコンサル業界の一角を占めるお堅い会社であり、開発言語は「Java」がメインになると思っていました。しかしながら、初めに受けたタスクは「Node.js で記述されたアプリケーションを Go に書き換えて欲しい」というものでした。「ある案件で利用する言語をなるべくGoで統一したい」という方針から生じたタスクだったので、私のみならず、他のアルバイト生もGoで開発していました。

私はサーバサイト側のタスクとして Go と Terraform を使いましたが、フロントサイド側のアルバイト生は Vue.js を使い画面コンポーネントを作成していました。

サーバ、フロントへのアサインは完全に「案件ベース」であり、自分の希望する技術とアサイン先で必要な技術がマッチすれば、タイミング次第ですぐに新しい技術へスイッチできます。私の場合、初めはアプリケーション開発がメインでしたが、インフラにも興味があることを上司に伝えたところ、担当タスクが済んだらすぐに Terraform を利用したタスクへと移動できました。

アルバイト中の経験から、Future-TIGでは、案件とタイミング次第で未経験の分野への挑戦権を得られると実感しました。経験の少ない段階では「どの分野に適性があるか」は予測できないので、「やりたい技術を意思表明すれば挑戦させてくれる文化」は「手を動かすエンジニアになりたい」私にはピッタリでした。

評価基準について

  • Future-TIG では、技術力が高い人が評価されると思います

Future には、アルバイトとして参加している大学生から40歳手前で転職された方まで、多様なバックグラウンドを持つ技術者がいます。それを反映して、Futureでは「○○さん」と、さん付けで名前を呼ぶ文化があります。年齢を問わずにチームが結成されるので、年下の上司や年上の部下などいくらでもいました。しかしながら、それを気にする社員はいませんでした。

評価軸となるのは「どんなアウトプットを出したか」という点に絞られるので、「何歳か」「男性か女性か」「出勤しているか1」という技術力とは関係しない部分は、評価項目に上がりません。成果物で評価してもらいたい技術者には最適な環境です。その代償として、未経験の分野ではなく、ある程度知見が貯まった技術を使い続けたいという人には、かなりつらい環境になると思います。

開発の進め方は「ブラウザで検索し、公式ドキュメントを理解して、実装する」の繰り返しであり、このサイクルをいかに早く回せるかにより、本人の技術力が評価されます。この評価方法は、AI系ベンチャー企業と Future のどちらでも全く同じでした。

キャリア入社について

Futureでは、自分の観測範囲で半数近くがキャリア入社された方でした。キャリア入社された方々にお話を伺うと、

  • ユーザー企業の情シスでITに触り、もっと開発側に近づきたいと思った
  • 前の企業ではスキルアップに限界を感じ、レベルの高い技術者のいる会社へ入りたいと思った

という旨の転職理由を話されていました。

キャリアで入社される方の場合「より高いレベルの環境を目指した結果、その選択肢の1つとして Future があった」というケースの人が、私の周りには多めでした。技術への関心が高い人が自然に集まるという Future の文化は、最先端の技術を次々と実装する社風ともリンクしています。「できる人、もっとできるようになりたい人」がキャリアとして Future にジョインされるので、基本的に意識高めの人が多いと感じました。

私が担当したタスク

  • Go で GCP の Billing 情報を通知するアプリケーションを2タイプ作成(近日 OSS として公開予定)
  • 設計思想の異なる2つの Terraform スクリプトを1つに統合

Go でのアプリケーション開発 ×2

Web界隈で大人気の Go を使い、GCP の Billing 情報を通知するアプリケーションを作成しました。アルバイトとしてアサインされた段階では Go 言語の経験は一切ありませんでした。しかしながら、公式ドキュメントと試行錯誤をつづけることにより、実際の案件で利用するアプリケーションの完成まで漕ぎつけました。

アルバイト生である私の書いたコードでもしっかりとレビューして頂き、そのために時間を割いて頂いた社員の方々には感謝の気持ちでいっぱいです。本当にありがとうございました。

アルバイト生が開発するコードであっても、全て実案件に関わっている(コードを納品するお客様がいる)ので、先輩方は本気でコードレビューしてくれます。したがって、「実案件で通用するレベルまでコード力を向上させたい」という大学生には、Future でのアルバイトを是非ともお勧めしたいです。

Terraform スクリプトの統合

2つの Terraform スクリプトを1つに統合するタスクを担当しました。

現実にある1つのインフラは動いているが、それを構成管理する Terraform スクリプトは2つ存在する2という恐ろしい状況から、インフラ実態を一切操作せずにスクリプトのみを統合するというタスクを進めました。

設計の異なる Terraform スクリプトを統合するには、片方のインフラ定義を、現状と矛盾しない形で、もう一方へと「移植する」必要があります。また、同時に移植が問題なく成功したことを「証明する」必要もあります。この「移植」と「成功の証明」を何とか達成したことが、私のアルバイト期間における最大の実績だと思っています。

Terraform スクリプトの書き方が異なれば、terraform apply コマンドで生成される tfstateファイルの定義も異なった記述になります。したがって、移植を達成するには

  1. Terraform スクリプトの記述を、片方に矛盾なく移植する
  2. tfstateファイルの内容を、移植した Terraform スクリプトに完全に沿う形で書き換える

という2つの壁を同時に乗り越える必要があり、私はこれを突破しました。

現在の私ならば、Terraformスクリプトの統合と tfstateファイルの書き換え程度ならそれほど難しいタスクではありません。この具体的な方法については技術的な需要があると認識しているので、別な場面でご紹介したいと考えています。

「未経験でもインフラを希望したら、最先端の技術を利用し、かつ、とても難しいタスクを経験できた」

技術力を向上させるには「技術的に困難な壁を突破する」経験が必要です。しかし、その分野に対して未経験な人では、なかなか難しいタスクを任せていただけません。しかし、Future でならば、「最先端技術の難しいところ」をアルバイト生であっても担当させて頂けます。むしろ、社員の方々はそれ以上に難しいタスクを次々に解決しています。

「手を動かすエンジニアとして活躍したい」と考えるエンジニアであれば、Future で働くことはプラス面が多いと感じました。

まとめる

アルバイトを通してFuture では…

  1. イケイケなWeb系企業が使うような最先端の技術を使っている
    • 市場価値を高く保てるので、将来的な転職に有利になる
    • 最先端の難しいタスクを担当することで、技術力が急上昇する
  2. 「技術力が高いこと」が評価される
    • 自主的に勉強する習慣や、ブログや講演で一般公開することが歓迎される
    • 仕事と並行して、エンジニア界隈で知名度を上げられる
  3. 技術を向上させたい人が社外からも集まってくる
    • 「勉強するのが基本」という人が集まってくるので、互いに教えあう文化がある
    • 社員のバックグラウンドが多様で面白い

という3点の特徴があるのだなと理解できました。

現在の私は研修中の身ですが、1日も早く現場に復帰できるよう、誠意努力してまいります。

Future の先輩社員の皆様方、これからもよろしくお願い致します。


  1. 1.社員補足: 現時点ではリモートフレンドリーではありますが、リモートファーストでは無いので、慣れるまでは出社を推奨しています。
  2. 2.社員補足: 別のチーム(他社)が管理していたインフラ構築作業を弊社で巻き取ったために発生したイレギュラーな状態でした。