アトラエで働くエンジニアとは
株式会社アトラエでエンジニアをしている青野 ( @ysk_aono )です。こちらは、Atrae Advent Calendar 2019 1日目の記事になります。
初日ということで敢えて具体的な技術には触れず、アトラエのエンジニアチームの概要について軽く触れるのと、そこに新卒入社し7年以上働いてきた自分が普段エンジニアとして意識していることを書きたいと思います。後者はあくまで個人レベルの話にはなりますが、それなりに長くいる人間として会社の雰囲気が伝わるかなと。
※2019/12/1現在の情報なので、1ヶ月後には変わっている内容もあるかもしれません。
そもそもアトラエって？
ここから書き出すと際限がないので、直近 (FY2019) の決算資料を貼っておきます。
すごくざっくりまとめると、以下のような会社です。
・「世界中の人々を魅了する会社を創る」をビジョンに掲げています
・テクノロジーによって人々の可能性を広げる事業を創り出すという思いを込めて、自分たちを "People Tech" カンパニーと定義しています
・「意欲ある従業員が無駄なストレスなく働ける組織」を志向し、無駄なルールや階層のない、性善説に基づいた組織運営をしています
・東証一部上場企業です
・FY2019は売上32億、営業利益7億でした
・社員数は50半ば、現在の社員一人当たりの売上は6,500万くらいです
・求人メディア「Green」、組織改善ツール「wevox」、ビジネスマッチングアプリ「yenta」の3つの事業を自社で運営しています
エンジニアチームについて
技術スタック/ツール
こちらは、これから他のメンバーが色々書いてくれるかと思います。一例ですが、下図のような技術やツールを開発チームで利用しています。
チーム構成
アトラエでは現在3つのサービスを運営していますが、それぞれのプロジェクト (弊社では事業部もプロジェクトと呼称したりします) 毎にエンジニアやデザイナーが所属し、基本的にはどれか1つのプロダクトに集中してコミットする形態を取っています。その中でエンジニアやデザイナー, その他ビジネスサイドのメンバーがユニットを組み、企画・機能開発・検証etc.を行うことが一般的には多いです。いわゆる職能別組織というよりは、事業別/目的別の編成に近い形かと思います。
事業レイヤーより下の細かいPJは端折りますが、現在エンジニアは大別すると「Green / プロダクト開発チーム」「yenta / プロダクト開発チーム」「wevox / プロダクト開発チーム 」「wevox / Data Scienceチーム」の4つのどれかに所属して日々働いています。メンバーは基本的には、エンジニア + デザイナー + (PdMやPjMの役割を果たす他メンバー) という感じです。筆者の私はyentaの開発チームで働いています。少し毛色が異なるのは、データサイエンティストとエンジニアでチームを構成しているwevoxのDSチームでしょうか。ちなみに、座席もそれらの職種が混ざった状態になっており、取り組んでいるプロジェクトに応じてちょこちょこ席替えしたりしています。
※ちょうどDSチームのインタビューブログがあったので貼っておきます↓
一方で、会社全体の技術ポートフォリオの強化/拡大・知見の属人化解消・技術者としてのキャリア形成etc.の観点から、職能別の情報共有や雑談もとても重要です。こちらはまだまだ改善の余地はありそうですが、エンジニア全員でのweekly定例ミーティング、技術毎のSlackチャンネルでの雑談や情報共有、有志による勉強会や輪読会の実施などが行われています。
個人的には、社内で比較的キャリアが長いエンジニアでお茶・ランチをして会社全体の技術/開発組織について雑談をしたり、iOS開発に携わるエンジニア同士で机を並べて開発したり (普段は席が離れているので) というのをやってみたりしています。
↑先日は神田のらくスパにiOSエンジニアで行って、Work from SPAしました
人数規模
現在のところ、エンジニアは正社員で15名程度 (全従業員の3割くらい)、業務委託などでお手伝いいただいている方々も含めると20名強というところです。これで3つのプロダクトを作っているわけなので、とても人が多いとは言えない状況です。楽ではない...です。一方で、デザイナーやビジネスサイドのメンバーと一丸になってプロダクトを作り上げていく楽しさは非常にあります。
このように事業全体を見据えて議論しながらプロダクトを作り上げていくところ、技術スキルで事業や会社をリードするところ、開発チームを作り上げていくところ、色々なポジションがまだまだ空いています。技術スキル研鑚に加えてこれらも貪欲にやってみたい方は、ぜひご連絡ください！（突然の求人広告）
会社の求人情報 : https://www.green-japan.com/company/172
私のTwitterアカウント : https://twitter.com/ysk_aono
働くエンジニアとして意識していること
さて、こういった環境で7年以上自分は働いてきたわけですが、そんな中意識していることを書いてみます。 (ちなみに、自分が入社したときはエンジニアの数は3人程度でした)
1/ エンジニアの強みを理解し、技術へのオーナーシップを持つ
2/ 技術を通して事業を作っていることを忘れない
3/ 将来を想像しながら作る
4/ 領域を広げる
5/ プロダクト作りに関わる全てのメンバーと信頼関係を築くこと
個人的な内容にはなりますが、同僚たちも似たような考えは持っているような気がします。違ったら違ったで、きっと別途アウトプットしてくれるでしょう
1/ エンジニアの強みを理解し、技術へのオーナーシップを持つ
エンジニアの強みの一つは、テクノロジーの力で事業成果や様々なプロセスにレバレッジを利かせられることだと思っています。もちろんこれはエンジニアという職能単体だけで実現できることではなく、他の分野のプロフェッショナルと協働することで生み出せる価値です。しかし、実際にそれを自分の手で扱う主体はエンジニアです。成し遂げたい目標のために技術を理解し使いこなせるようになること、この部分に対してオーナーシップを持たなければならないと考えています。
また、自分の書いたコードが、サービスに関わる人 (ユーザや同僚) ・事業に対して価値や影響を生み出したりしていると自覚し、それに対して責任感やワクワク感, 愛着を持つこと、それもサービス開発の文脈では大事だと信じています。
雑にまとめると、エンジニアであることにプライドを持つという話に帰着するのかもしれません。
2/ 技術を通して事業を作っていることを忘れない
なぜ会社に集まってチームでプロダクトを作っているかといえば、会社のビジョンに近づくため・価値ある事業を生み出すことでファンを増やしその対価をいただくためです。このあたりは趣味の個人開発とは違うところかなと感じます。
会社で事業をやっている以上は時間は有限なので、まず開発者としてはアウトプットのスピードが求められます。これは実装スピードを早めましょうという話に留まらず、開発に関わる意思決定を早くすること、仕様が固まっていないなら前進できるように落とし所をつくりにいくこと、なども含まれるかと思います。手を動かすだけが仕事ではないというのは忘れないようにしています。
事業目線では、アウトプットのクオリティの高さも非常に重要です。サービスを利用する方が実際に見るI/Fや体験の質のレベルを上げる、バグや障害が出る確率をできるだけ下げる、他の同僚が理解しやすいコードを書くetc. 、当たり前ですがクオリティが高い方が良いに決まっています。まだまだ私も未熟ですが、上記のスピードとクオリティの両方を高いレベルで兼ね備えるために研鑚を怠らない技術者になりたいです。
また先述した内容にも通じますが、事業開発において、技術に関わる最後の砦になるのがエンジニアです。エンジニアがNoと言ってしまうとプロダクトの前進は止まってしまいます。「全てYesと言わなければいけない」とは全く考えていませんが、例えば「プロダクトの価値を上げるためにこの機能は必要か」「本当に開発して検証すべきなのか」の問い/議論の答がyesなのであれば、技術を使った問題解決を簡単に諦めてはいけないなと思います。
※本記事の趣旨とは関係ないのですがｗ、弊社の優秀なデザイナーチームが会社のロゴリニューアルをした際の振り返り記事です。プロダクトの「Why」「What」の議論を一緒にするのは非常に楽しいです
3/ 将来を想像しながら作る
事業もそれが属するマーケットも不確実ですし、この先何が起こるのかを完全に予想するのは神でもないので難しいでしょう。しかし、この先事業の方向性でシステムがどう変わっていきうるのかを念頭において開発することは、それでも大事だと考えます。難しいですけど...
「将来」という文脈だと、システムの技術的な負債というのが分かりやすいトピックかと思います。いわゆる取り返しのつかない技術的負債というのは、未来の開発スピードや効率を大きく落としうる意思決定と行動が積み重なっていくことで未来の選択肢が大きく減少し、生まれるものです。このあたりは、書き出すと長くなるかもしれないので控えますが、できるだけシンプルであることを是とし、良い設計をする・良いコードを書くことで、システムの複雑度の上昇ペース (= プロダクトをユーザに届けられるスピードの下降ペース) を抑えることが重要だなと、自身の経験や周囲からの知見で思い知らされました。
一方で、「借金をしたという自覚をする」「返済することを計画にいれる」というのがセットなのであれば、一時的な借金は私はありだと考えています。
4/ 領域を広げる
仕事の範囲を広げる、というところです。
プロダクトの開発リソースが常に十全とはいえない状況にも助けられ？、自身も役割を少しずつ変えてきました。入社した当初はRailsやJavaScriptを中心に書いていましたが、そのうちにAWSも触ることになりました。その後ガラッと変わって、社内で初めてのiOSエンジニアやAndroidエンジニアになったりもしています。最近は優秀なデザイナー陣がいるのでやる機会も減りましたが、ペーパープロトタイピングをしたり、Sketchでお粗末なデザインを作っていた時期もありました。
一つの分野を深掘りするのも非常に大切で、自分にはそちらが不足しているという自覚もあるのですが、異なる技術を触ったことで見える世界が広がり良いことも多かったです。大したレベルではないのですが、これからどんな新技術が必要になっても怯まずに向き合えそうな自信はあります。
5/ プロダクト作りに関わる全てのメンバーと信頼関係を築くこと
有限な時間の中で一人で遠い目標にたどり着くのは非常に困難で、大したことはできないことが多いです。そのためにチームがあります。そういった中で気持ちよく仕事する / 自身の影響力を広げていくには、信頼の醸成が欠かせません。
書いてみると当然のことなのですが、チームメンバーの期待に応える (期待を超える) 、エンジニアに限らず全てのメンバーと誠実にコミュニケーションをする、しっかり議論して決まったことは前向きに取り組む、これらは意識するようにしています。
fishという書籍に「自分で態度を選ぶ」という、仕事を楽しむ原理が書いてあります。いくつか失敗をするなかで、この重要性がとても理解できました。ちなみに、弊社社員の必読書になっていますw
最後に
企業アドカレ初日ということで、どういう会社の人がこれから書いていくんだろう？ というのが少しでも伝われば良いなと思い、つらつらと書いてみました。
技術を通した事業のさらなる成長へのコミット、採用を含めた技術力の全体的な向上、各プロダクトや社内セキュリティルールの策定・構築、事業チーム間を跨いだ知見のさらなる共有・属人化の解消などなど、様々な部分で伸び代がたくさんある状態です。解くべきイシューを見つけそれを解決する、シンプルですがこれをエンジニアとして続けていかなくてはいけません。これから記事を書いていくメンバーとこれからジョインしてくれる将来の仲間で、楽しく乗り越えていきたいなと思っています。
というわけで以上です。明日は 1年目の mutsumi くんの記事です、楽しみ。Atraeアドカレ、よろしくお願いします。