エアークローゼットの技術やエンジニアについての考え方など
こんにちは！エアークローゼットCTOの辻（Twitter）です。
この記事はエアークローゼットアドベントカレンダーの1日目の記事です！エアークローゼットに所属しているエンジニア・デザイナー・エンジニアマネージャーが様々な内容の発信をしていきますのでよろしくおねがいします！
はじめに
簡単に自己紹介させてもらうと、新卒からSierエンジニアで3年ほど、その後楽天でフロントエンド3年弱経験したのちに、2014年から創業期のエアークローゼットにまずはボランティアでジョイン。その後正式にCTOとしてジョインし、現在7年目のCTOとなります。最近は着物にハマっていて侍CTOとしてやっていきたいと思いますのでよろしくおねがいします！
今日書くこと
1日目の記事ということで個別の技術の話ではなく、エアークローゼットの技術に対しての考え方や、私が思うエアークローゼットエンジニアとしての矜持・こだわりなどを書くポエムです。そのため個別の技術のことが知りたいという方は2日目以降の記事を見ていただけたら幸いです。
IT技術って面白いよね
IT技術の世界は本当に日進月歩。昨日まで当たり前だったことが今日はもうレガシーになることが日常茶飯事。逆に今日できないことが明日できるようになることもざらにある。
伝わる人ほぼいないと思いますが、最近あった具体的な話でいうと、AWSのAPI GatewayからVPC内のリソースにアクセスしたいことがあって、VPC LinkとNetwork Load Balancerを使ってまずはそれを実現。しかしNetwork Load BalancerのターゲットにはIPアドレスしか指定できず、リリースのたびに付け替える仕組みをつくる必要があるなーと思っていたら、なんとNetwork Load BalancerのターゲットにApplication Load Balancerを指定できる機能がちょうどそのタイミングでリリースされ悩みが解決！なんてことがありました！（伝わる人がいたら嬉しい！）
Network Load BalancerのターゲットグループにApplication Load Balancerを設定する
なんてことが当たり前のようにあるとちゃんと情報のインプットしなきゃな！って意識にもなるし、それを使って課題解決した瞬間のやったった感はたまらんものがあります。うん。
もちろんもうちょっとマクロな視点で見てもたとえばAI技術の発展も楽しみですよね！とくにイーロン・マスクの脳直結型デバイスとかめっちゃ夢があって期待してます。
エアークローゼットもそういうIT技術がめっちゃ好きな人が集まって作っていて、それは”発想とITで人々の日常に新しいワクワクを創造する”というミッションにも現れています。
技術はツール
一方で技術はあくまでツール、目的を達成するための手段。
あくまで一番大事なことは自分たちが何を為したいのか、どんな世界をつくりたいのか、そのために何をつくるのかであって、それを実現するためのツールが技術です。そしてそこに矜持を持って常に今ある技術で最高のプロダクトを開発できるエンジニア集団でありたいと思ってます。
エンジニアの仕事はシステム開発ではなくプロダクト開発である
エアークローゼットではエンジニアの仕事はシステム開発ではなくプロダクト開発ととらえています。なにが違うのか。システムと呼ばれるものはITシステムに限らず、須く仕組みでしかありません。これに対してプロダクトはサービスそのものであり、それ自体が価値を持っているもの、もしくは生み出すものです。
システムであれば作りたい要件をまとめてそれを実現するシステムが開発することがアウトプットとなりますが、プロダクトの場合本当にそれがお客様にとって体験価値が上がるものなのか、もっと良くする方法はないのかなど、多角的に考えその価値を高めることがアウトプットとなります。
エアークローゼットでは、そのようなプロダクト開発に主軸を置いて開発を行っています。
フロントエンド・バックエンドでエンジニアを分けない
エアークローゼットでは、エンジニアをフロントエンドエンジニアとかバックエンドエンジニアとかって括りでは全く分けていません。
それはなぜか。ある機能を実現するときにフロントエンドの責務は何で、バックエンドの責務は何なのか、をまず設計する必要がありますよね。
そのときにフロントエンドしか知らない、もしくはバックエンドしか知らない状況だと必ずどちらかに偏った設計になってしまって、最も効果的な設計にならないこともしばしば。そのためエアークローゼットでは技術領域でエンジニアを分けることは一切せずに、実現したい機能ごとにエンジニアをアサインし、必要なことはすべてやってもらう体制をとっています。
また、エアークローゼットではバックエンドの開発環境にNode.jsを採用しているのですが、言語を統一することで可能な限りシームレスにフロントエンドとバックエンドの開発を行うことができるようにしたかったことも採用理由のひとつだったりします。
ないものはつくる
今でこそNode.jsはだいぶ開発も進んできて、かつライブラリも充実してきましたが、サービスを開始した2015年当時はまだまだ他の言語に比べると言語仕様自体も貧弱だし、便利なライブラリもそんなに多くない状況でした。まさにちょうどNode.jsとiojsに分かれてしまっていた頃です。
そうすると当然自分たちでないものはつくるという発想で開発していくことが求められます。なので例えばrailsのdeviseのcurrent_userが便利だからそれと近い感覚でログインユーザにアクセスできるミドルウェアを作ってみたり、サードパーティーライブラリでかゆいところに手が届かない場合はforkして機能追加したり、ときにはプルリクを送ったりと、"ないものはつくる"姿勢で開発を行っています。
システムの動きと現実の動きは統一すべし
具体的な設計手法でいえば、エアークローゼットでもここ数年はDDDを取り入れて設計を行っているのですが、そもそもの思想としてシステムの動きは必ず現実の動きと統一させるべきだと考えています。
なぜかというと、そうしないと現実の動きが変わった場合にシステムがそれに追従できなくなることがよくあるからです。一度作ったシステムが絶対に仕様が変わらない保証があるなら、そんなにこだわる必要ないのかもしれませんが、そんな状況はほぼないでしょう。
なのでもちろんモデル図つくって、責務分離して、ディレクトリ構成つくってとかの方法論も重要なのですが、まず現実の動き、お客様側の話であればUXを、運営側の話であれば業務フローをエンジニアが理解し、それをシステムに落とし込むことが最も重要だと考えています。
さいごに
思いつくままに大事にしてることをつらつらと書いてみましたが、これが正解というよりはあくまで私が現時点で大事にしている考え方です。
もしかしたら今後また変わるかもしれませんし変わらないかもしれません。
また、自分はこう思う、ここは賛成だけどここは違うと思うといった意見があったらぜひ議論してアウフヘーベンしていけたらなって思ってます。
というわけで、エアークローゼットに興味がある方はぜひ気合い入れてつくった採用特設サイト"エアクロクエスト"があるので、こちらもみていただけたら嬉しいです！
また、2021年の新卒が作成した、新卒エンジニア密着ムービーもありますので、こちらも見ていただけたら内部の雰囲気が伝わるのではないかなと思います！
ではここまでお読みいただいてありがとうございました！まだまだ続くエアークローゼットアドベントカレンダーをお楽しみください。