今回お届けするのは、バックエンドエンジニア 萩原のインタビューです。「その時代に合わせて適応していく」と語る彼が今考えるAIとの向き合い方について、COO山口が読者の視点に立って深堀りしました。

<h2 id="h5c4d85c8fd">PROFILE</h2>萩原登 バックエンドエンジニア 1984年愛知県生まれ。ECサイト開発、WEBメディア、フリーランス、法務系スタートアップでの経験を積む。現在はAzitのバックエンドエンジニアとして、ビジネス要件の技術的実装から運用までを担当。AI活用による開発プロセスの効率化に関心を持ち、時代の変化に「適応」することを重視。

<h2 id="he8c51a2c75">世の中に適応していくために「まずは触ってみる」</h2> ー 最初にプログラミングに触れたのはいつのことでしょうか。 小学生の頃です。当時、家にPC-98という古い国産マシンがあったんです。あと、当時を経験した人なら分かると思うのですが「マイコンBASICマガジン」という雑誌がありまして…そこに書かれたプログラムを打ち込むと、何かしら動くものが作れるんです。そうやっておもちゃとして遊んでいたのが、プログラミングに触れたきっかけです。 ー 当時、普及率としては珍しかったのではないでしょうか？ 1990年代前半なので、パソコンは普通に売ってはいたけど、家にあるかっていうとちょっと人による所ではあったと思います。学校ではコンピュータールームやコンピューターの授業もありました。まだ始まったばかりくらいの時代ですが。インターネットよりは少し前の時代ですね。 その後、中学に入ってからもパソコン部はありましたが、当時は何かゲームを作ったりするよりも、ゲームで遊んでいることばかりでした。 なので、そこからいきなりエンジニアを目指したり「将来これをしよう」と決めていたということはなかったというのが正直な所です。当時から触れていたことで、自然と馴染んでいった感じです。 ー 社会人になり、ファーストキャリアからエンジニアなんですか？ そうですね。大学を中退したあと、25歳ぐらいまでは公認会計士試験の勉強をしたりしていました。結局それは諦めて、その後就職したのがファーストキャリアです。当時ネットゲームの知り合いが募集していた求人で、ECの会社に入り6年ほど過ごしました。 ー 公認会計士からエンジニアというのは、結構振れ幅の大きな決断だったと思います。 そうですね。何かしら仕事をしなきゃと思った時に、一番できそうだったっていうのがプログラミングだったんですよね。今と環境が違って、当時はプログラミングができれば仕事はあったというのが正直な所です。そんな始まりでしたが、だんだんプログラマーの立場が分かってきて、なんだかんだそのまま居座ってしまいました。 ー そこから割と様々な業界を経験されていますよね。 そうですね、ECから始まり、ライフスタイルのWEBメディアだったり、フリーランスを経験したり、法務系スタートアップにいたり、その後現職のAzitにきて。そんな感じなので「この業界をやりたい」っていう強いこだわりがないというのは、確かにあるとは思います。 もともと公認会計士を勉強していて、若干抽象的にビジネスを見るというか、仕組みを見たり、お金の流れを見たりっていうのが好きなので、様々な業界にいるというのはあるかもしれません。 ー なるほど。ご自身では自分のことをどういうエンジニアだと思ってますか？ エンジニアとしてというよりは仕事全般ですけど、「適応」を重視していますね。特に最近のAIも「これは触って適応していかなきゃいけない」と感じる気持ちは強くて。 何にしろ、自分で触ってみるのは結構大切だと思っています。ブロックチェーンにしろAIにしろそうなんですけど、意外と皆触ってなかったりするんですよね。そこで触って感覚を掴むだけでも、アドバンテージになり残るものが手に入ると思っているので、そういう意味で触っていこうと決めています。

<h2 id="hbca82ca24e">AIと共に進化する開発体制</h2> ー 現在の業務について教えてください。 &nbsp;バックエンドエンジニアとして、ビジネスの要件を技術的に実現することを主な業務としています。ビジネス側からの要望を受け、それを要件に落とし込み、実装から運用までを担当しています。 ー いま挑戦していることはなんですか？ &nbsp;AIをどうやって使っていくか、ということに尽きます。理由は明確で、私たちのようなスタートアップでは、小規模で大きなプロジェクトにチャレンジする。ということが多いからです。複数の企業で経験がしてきましたが、特に小さな企業ではチームビルディングは常に苦労してきました。採用活動を強化するのも1つのアプローチですが、AIをうまく活用することで、課題解決の一助になると感じています。 ー AIを使った開発体制の変化についてどう考えていますか？ 本質的にはそんなに変わらないと思ってますが、小さなプロダクトを作って、使って、作り捨てるみたいなことは簡単にできるようになると思います。&nbsp; 小さいチームで高速にプロダクトを作るというのは流行っていきますよね。本当にコストが10分の1、あるいは100分の1になる可能性がありますし。ただ、やはり大規模にサービス展開しようとなると、まだまだAIだけではできないのことも多いので、人の力が必要だと感じています。 ー Azitの場合だと、スモールなチームでのプロダクト開発が増えて当たり前になっていきそうですね。 そうですね。機能ベースで生まれて付け足していった時に、サービス全体として統合するとなったら、やはり人間が入らなくてはいけないシーンもあると思います。フィードバックを持って手元で開発するってなったら、やっぱりまだ人間が必要で。なので、教育とかそういうところを除けば、そういった分かれ方をするのかなと思っています。新規の案件ベースで作って、ある意味スモールに使い捨てになるようなサービスを作っていくチームと、統合してサービスとして作るチームに分かれるかもしれませんね。 ー Azitのプロダクトチームは主にリモート体制ですが、今後どうなっていくと思いますか？ 私自身今愛知に住んでいますが、AIを活用していけばいくほど、結局残るのは人間同士のコミュニケーションになるので、リモートで完結できない仕事の重要性が相対的に上がると思います。それこそ、もし全国各地にいるなら小さいリモートチームが日本全国あるっていうスタイルが増えるかもしれないですね。2、3人になれば、名古屋チーム、大阪チーム、九州チームみたいなのもあるかもしれないですし。 ー 萩原さん自身が本社のある東京に住む日も近いということでしょうか…？ 適応という形で必要なら出社、引っ越しもあるかなという感じですね。今の大学生は、一番AIネイティブ世代になると思っていて。その5年後ぐらいになると、もう体の芯までAIに浸かった大学生になるはずです。今でもAIはありますけど。でも大学4年間、今のAIやそれ以上のレベルのAIに触れてきた人たちが社会に出てきて、例えばベンチャーを起業するぐらいになると、また違う世界が見えるかなとは思ってます。ちょっとどうなるかはわからないですが。

<h2 id="h3fffc9597c">自然と取り入れるマインドセット</h2> ー どんな方にAzitに入社していただきたいと考えていますか。 直近で私個人の希望で言うと、一緒にAIを使った開発フローの掘り下げをやりたい、と言ってくれる方が一番嬉しいのですが。 全体的な視点で言うと、まだAzitやDeliveryXは運用フェイズではなく試行錯誤してサービス改善を推し進める段階です。それを受け入れて一緒に成長・完成させたいと思ってくれる方がいいなと思っています。もしかしたら、半年後には別のことをやっているかもしれないんです。そういった部分も含め、柔軟に受け入れてくれるタイプの方だといいですね。そういう開発フローを作ること自体が財産というか、価値に感じて楽しんでいただける方だと嬉しいです。 ー 少し広い話ですが、AIの台頭をエンジニアとしてどう見ていますか？ 「AIでエンジニアいらなくなる」なんて言われますけど、そんなことはしばらくなさそうです。今はパソコンがあれば何でもできるじゃないですか。でも、実際に手を動かし価値を届けることのできるエンジニアはまだまだ多くはありません。例えば今後10年ほどで、本当にエンジニアがいらなくなる時が来るかもしれません。その時は社会の仕組みも変わっていると思うので、その時に合わせて適応していきたいと思っています。 ー そのときこそ「感性」など人間的なものが大事になってきますよね。 そうですね。仕事の密度はAIによってどうしても上がっちゃうので、難易度が上がっていくと思うんです。ちょっと言い方に迷いますが、何も考えずに作業をして、資料を作ったりする時間ってあるじゃないですか。そういうのがAIで全部なくなっていくので、その分仕事の密度は上がっていくと思います。それはいいことばかりではないかなって思うこともなくはないんですよね。 人間、本当に集中して創造的な時間を1日8時間週5日で過ごせるかと言ったら、ほとんどの人が無理なんじゃないかと思っているので。 ー わかります。AIを使い始めて、自分で情報を頭で考えて整理して出力するよりも、レビューする数が異様に増えてレビュー疲れが発生している気がします… そうですね。同時並行ができすぎるので、同時にやり過ぎちゃって、実はパフォーマンスが悪いとかもあり得るので、タスク管理はもうAIに全部任せちゃうっていうのが、割と今後行く道かなと思ってます。 AIのアウトプットを読み込んで決断する仕事しか残らないって、それで1日8時間働けますかって言われたら、めちゃくちゃタフですね。 ー 最後に、これからの人生の目標はありますか？ しばらくはAIの発展を見守りながら、エンジニアとしてその進化を追いかけていきたいと思っています。実際に、今動いている技術や、これから来るものを見据えながら、どこまでAIが進化するのかを追いかけることに個人的な興味があります。せっかくエンジニアをしているので、その進化を実感しながら仕事をしていきたいですね。 インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2> Azitではバックエンドエンジニアを募集しています。詳細は、以下の募集ページをご覧ください。 <a style="color:#1155cc" href="https://herp.careers/v1/azitinc/mFCv7shzKFSa" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/mFCv7shzKFSa</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

「その時代に合わせて適応していく」エンジニア萩原の、AIとの向き合い方

Love from Azit 編集部

<a style="color:#000000" href="https://love-from.azit.co.jp/article/0t8w_v3zh" target="_blank" rel="noopener noreferrer">前編</a>に続き、CTO十亀のインタビューをお届けします。後編では、直近を振り返りながらこれからの組織などについてお話しました。

<h2 id="h5c4d85c8fd">PROFILE</h2>株式会社Azit CTO 十亀眞怜 <a style="color:#000000" href="https://x.com/pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a> 慶應義塾大学理工学部在学中に、吉兼・須藤と出会い、株式会社Azitを共同創業。2021年以降、CTOとしてサーバサイドの開発・技術戦略の立案ならびに実行、エンジニアの採用等を中心に担当。

<h2 id="hb418d49441">ときには「現場」で課題解決も</h2>ー CREW時代から、結構現場に行ってバグフィックスをするシーンなどを見てきました。人と会うために外に出るんじゃなくて、課題解決のために外に出るんだな、と。ここには何か理由はありますか？ 現場で対応するのが一番解決法として良ければ、それがやっぱり早いですし、理想的かなとは思っています。そんなに外に出たいわけじゃないですけど（笑）それがベストだから、やろうかなっていうのはありますね。 当時の技術環境を考えると、生のエラーログみたいなものをリアルタイムでネット越しに見られるようなものはなかったので、現場に行って繋がないと何が起きてるか分からなかったというのもあります。特にライドシェアはそうで、Webサービスならサーバーのログとかがあると思うんですけど、アプリになると、やっぱり現場に行って端末で何が起きてるか、見ないといけないことも。CREWドライバーの方の横に行って、操作してもらい、ケーブルを刺して、吐き出してるアプリケーションレイヤーのログを見ないと判断できないこともあったりして。それが、Azitがまだ3〜4人ぐらいのときなので、自分でやっていましたね。 ー 事業をピボットして、物流・サプライチェーンの世界へやってきたわけですが、どのような技術的チャレンジが存在する領域なのでしょうか。 特にマーケットプレイスでは、物流システムのそれぞれのモデルや条件をどうやって上手く抽象化してまとめていくか、という所が、システム設計として一つ大きなチャレンジだと思います。 その中で、ライドシェアでもそうでしたがやっぱり物流も、リアルの世界で起きていることをデジタルで表現して拾っていくプロダクトになるので、現場で起きていることと、デジタルでどう表現してるかっていう所の繋ぎ目をシステムでうまく表現できているかっていうのが大事な所です。 物流やサプライチェーン領域って、既存の領域として複雑なオペレーションや、特例のオペレーションみたいなのがよくあるので、ある意味エンジニアが思い込みで勝手に仕様を狭めちゃったりとかしてはいけないんですよね。 そういうバランス感覚、例えばどこまでがシステムで許すべき部分なのか、ここは柔軟にあえて汎用的に使える形にしておくことで、現場で工夫してもらえる部分として残すか、みたいなところは、実際いろんな企業の話を聞いていく中で、プロダクトの仕組みと面白い部分だと考えています。 ー プロダクトとしてのチャレンジや技術的なチャレンジは、どういう領域になると考えていますか。 特定の要素技術に特化しているというよりは、情報のワークフローをAzitのプロダクトの中で統一する部分と、自由に組み合わせられる部分を組み合わせたシステム設計みたいなところが面白いんじゃないかなと思います。 このプロダクトは、業務フローを、決めてその通り使ってもらうわけではなく、もう一段上のレイヤーでの設計が必要になります。たとえば、ユーザーがどういうタイミングで何をするのかっていうのを決めることができるシステムを作るってなると、抽象度が上がるので、ここをどう破綻せずに作れるようなソフトウェアにするのかっていうのが、設計が難しいところの一つだと思います。その工程を作る仕組み作りの部分をも、うまくデジタル化するところがまた面白いかなと。 そういう部分って、今まではデータをどう表現するかを考えなければいけなかったと思うんですけど、今はAIがもっと柔軟にデータを差配したりとか判断できるようなコンポーネントとして間に入ってくる可能性はかなりあるなと思っているので。

<h2 id="h6c4f69cb4d">現場のニーズに共感し、取り組み続ける</h2>ー 一個人として、エンジニアとしての興味はどこに向かっていますか？ そうですね。一個人としては、量子コンピュータの分野は長期で見て何らかの面白みがある技術が繋がっていくと思ってるので、そこは引き続きウォッチしていきたいと思っています。 あとはやっぱり、今、汎用AIと直接対話するというところが世の中に全部出てきてますけど、そこをソフトウェアの中に隠したり、ユーザーにとっての直接インターフェースじゃなくて、補助する形でパワーアップする形でAIをどう使っていくかっていうのは、プロダクトのデザインとして重要になっていくと思うので、Azitのプロダクトでもそうですし、世の中的にどうなっていくのかっていうのは興味はありますね。 ー やはりAIは、今までDXされきってなかった物流やSCM業界にも大きなインパクトを与えるんですね。 そうだと思います。現場で起きてることって、もちろん改善できる部分もあると思うんですけど、そういうオペレーションって何かしらの理由で行われていると思うので。それをシステムにするときに、今までだと論理で表現しづらいからこぼれちゃってた部分が、ようやく直接取り扱いすることができるかもしれないような、技術が追いついたのかなと思っています。 現場で起きてることを、人間が聞けば理解して判断したり、柔軟に対応できる部分っていうところに、今までシステムがそれを表現する方法がなかったら追いつけてなかったというのがあって。そこにAIが入って、別の処理を打つことができるようになると、より現場の良い部分、現場の工夫によって成り立ってきたオペレーションを、そのままシステムに組み込めるかもしれないですよね。 ー そのために、Azitとしてはどういう組織になると考えていますか。 プロダクトマネージャーやエンジニアのチームは大きくなっていくと思いますし、設計の部分全体は人間が引き続き見ていくんじゃないかなと思っています。AIがほとんど全てを作ってしまうというよりは、差配してもらいたいロジックやコンポーネントは人間が丁寧に作っていき、AIエージェントにどのタイミングでどういう形に入ってもらうか、どっちのコンポーネントにどういう情報フローを移行するかとかを決めてもらうみたいなワークフローを組むところも、やっぱり人間がやるところになるかな。と考えています。 具体的なコーディングはAIが支援してくれる部分が多くなってくると思います。シンプルなコードだけ書き続けたい、みたいな志向は減ってくるのだろうな、と思っていて。どうやってAzitのプロダクトが使われるのか、どういう価値があるのかという所を考える時間が長い人が、増えていくんじゃないかなとは思います。 ー そんな中で、Azitは、どんな人が向いてると思いますか？ そうですね。会社の社風っていうのもありますけど、結構コミュニケーション好きな人が多いと思って。このコミュニケーションというのは、決して何か楽しい冗談を喋ってほしいとか、なにかのテレビ見ましたみたいな話をしてほしいという話ではなくて。 プロダクトを良いものにするために、きちんと取るべきコミュニケーションを取れることなんですよね、そのためにはやっぱりその人間関係が円滑に回ってないといけないので。当たり前ですが、いつも嫌な感じの人とは、なかなか話しづらいじゃないですか。それでビジネスに支障が出る可能性もあるので、仕事をする上で必要な情報をお互い気楽にやり取りして、より良いものにするためのチーム作りができる人や、価値が作れる人っていうのは、重要だと考えています。 DeliveryXは、仕組み作りのプロジェクトなんですよね。なので、やっぱりクライアントの現場ではいろんなことやってるので、それに共感することも大切だと思っています。 実際に現場に行ったときも、例えば薬剤師の方が袋に詰める傍らで、Azitに発注してくれたりとかしてるので、そういうのを間近で見ると、やっぱりその中でどれだけ効率的に皆様に使っていただけるかっていうのは考えないといけない。 自宅でキーボードとマウスで作業してるだけっていうのは、ちょっと違うのかもしれないと思ってしまうんですよね。技術に特化するみたいな話だと、その人がもっと集中して、まとまった時間を1人で取りたいともちろんあるかと思って。ただ、Azitが目指すことを実現するために、ユーザーが現場でどういうニーズを抱えてるのかみたいなことに対してきちんと傾聴して、取り組んでいける人とご一緒できるといいなと思っています。 インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>AzitでバックエンドのTech Leadポジションを募集しています。 詳細は、以下の募集ページをご覧ください。 <a style="color:#0b57d0" href="https://herp.careers/v1/azitinc/mFCv7shzKFSa" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/mFCv7shzKFSa</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

【後編】現場のニーズに共感し課題解決を続ける。CTO十亀の履歴書

今回は、CTO十亀のインタビューです。2回に分けてお届けし、前編ではこれまでの経歴から現在に至るまでを振り返っています。

<h2 id="h7422936a6c">きっかけは「難しい」という面白さ</h2> ー 幼い頃からパソコンを触っていたと聞いていますが、エンジニアになった経緯を伺えますか。 親の仕事の関係で、小さな頃から家にパソコンがあり触っていたんですよね。とはいえ、当時はまだインタラクティブアートみたいなもので遊んでいる程度でした。プログラムを書いてグラフィックを作ったり、カメラの映像をもとに動いたら画面のコンテンツも反応するグラフィックを作ったりして遊んでたのが最初の頃、小学校高学年くらいのときだったと思います。 遊び程度でも、コンピュータというものを使った物作りが好きでした。プログラムって入り組んでいるので、複雑なものを書いて思った通り動いた時の楽しさとか、逆に思ってもみないような動きをすることの面白さみたいなのもあって。コンピュータの画面の上とかコンピュータの中で動く何かを作るというのが、純粋に楽しいと感じていました。 ー その原体験があった上で、いつ頃から本格的にコーディングにのめり込んでいったのでしょうか？ 本格的にやり始めたのは中学1年生ぐらいのときですね。うちはiMacだったんですけど、Javaのプログラミング環境を使って、JavaでGUIのアプリケーションを作ったりしていました。後は、当時も今もありますけど、XcodeっていうMacでiOSアプリやMac用のアプリを作るツールで、開発して初めて何か作ったりとかをしていました。 ー 当時Macのアプリケーションを開発して、どういうフィードバックを世の中から得られたんですか？ たしかに、フィードバックはあんまりなかったというのが、正直なところです。中学1年生ぐらいのときに、Lispのコミュニティによく遊びにイベントに行っていて。そのときはLispってマイナー言語というかあんまり使用者が多くなかったので、その中でいろんな人と「僕はこういうの作ってみています」みたいに交流したりしていました。 当時周りには、プログラミングを知っていたり、HTMLを使ってる友達とかはいたんですけど、プログラミングしてる人ってあんまりいなかったんですよね。プログラミングができるということ自体に面白さを感じるようになっていました。 ー 聞いた話ですが、大学時代は「サービス開発しようとしたら十亀だ」みたいなのが大学で知られていたとか。それって、どういう感じだったんですか？ エスカレーター式の学校だったので、高校時代の同級生が大学内にも結構いたんですよね。僕、高校のときから学校にThinkPadを持っていって、廊下の端に座ってコード書いたりとかしてる時間もあったんで「そういう奴がいるぞ」という意味では、元々知名度があったと思います。そういう背景もあり、大学1年のときに1つ目のベンチャーに声をかけてもらいました。 ー そこが初めての学生起業になるわけですか？ そうですね。当時Railsで開発するのがちょうど日本で流行ってた時期で、僕は結構Railsを個人的にいろいろ触っていたこともあって、ニーズにもはまったので参加することにしました。 そこで、他のメンバーにコーディングを教える機会があって。それを知ってもらって、学内で「ベンチャーやってて、バリバリコード書いてサービス作ってる」って周りに伝えてもらったりして。誰かがうまく話を回してくれたっていうのがあり、起業したい人達の間で話題に上がりやすかったんじゃないかと思います。

<h2 id="hb6e258c86f">より面白く、困難な課題を解決するために。</h2>ー 当時からもう、将来的にも起業しようと考えていたのでしょうか？ 自分で事業をやりたい、会社をやりたいっていうモチベーションがあったわけではないんですよね。ただ、当時から一般的な大学生よりも実用的なプログラミングの知識を蓄えることができていて。だから、もっと面白い課題があって、もっと自分の能力を伸ばせる環境にいたいとは考えていました。 授業で出てくるものとかだと、物足りなさを感じることも多かったんですよね。そんな中で、ベンチャーでやっていると、もっと実践的な課題や、効率よく作ることを求められたりすることも多く、それを作って自分の能力が上がることに楽しさも感じていました。 なので、漠然とした作業をするようなところに就職するよりは、面白い課題が得られるような会社にいきたいと思っていました。それが起業なのか、もっと何か有名な企業に入るのかとかは、当時は決めていませんでしたが。 ー そんな中、卒業後の進路はどうやって決めていったんですか？ 大学時代からAzitをやっていましたが、当時はこのままAzitをやっていくか、Azitを手伝いつつ大学院に行くかどうかで迷っていて。なので、その時点で就職の選択肢はあまり考えてなかったんですよね。 当時、いろんな大学院も気になっていて、話を聞いてたんですよ。他大学の情報系や、数学系の研究室を実際に見学させてもらったりも。また、もう少しロジックとか、哲学みたいなことをやりたいとも思ったので、文学部の哲学科の研究室の先生にも1回面談に行かせてもらいました。そこの先生にも言われたんですけど、やっぱり僕は、ものすごく細かい世界で1人しか知らないことを、1人で知りたいというよりは、広い世界のいろんなことに挑戦したり知りたいというタイプなんですよね。 研究室の中で論文を読んで一生研究するよりは、実際のユーザーの声を聞きながら誰かに触ってもらえるような開発をした方がいいんじゃないか、と。先生からもアドバイスをもらいましたし、自分もそうだなと感じるようになりました。 勉強ももちろん好きなんですけど、1個のことをずっと一生ピンポイントで研究して、そのことについて世界で一番詳しくなるよりは、僕はもしかしたらいろんな問題を解いて、また新しい問題に向かっていくことをずっと繰り返してる人生の方が、楽しくなるんじゃないかということを改めて思ったんですよね。そうなるとやっぱり就職か、そのままAzitかっていうのを迷ってたら、目の前に今ちょうど様々な課題を持ったAzitがあったので、これを続けることに決めたという感じです。 後編につづく インタビュアー：COO 山口 恭平、編集：坂井 華子

<h2 id="hda492ffe51">採用情報</h2>AzitでバックエンドのTech Leadポジションを募集しています。 詳細は、以下の募集ページをご覧ください。 <a style="color:#0b57d0" href="https://herp.careers/v1/azitinc/mFCv7shzKFSa" target="_blank" rel="noopener noreferrer">https://herp.careers/v1/azitinc/mFCv7shzKFSa</a> また、Azitではpodcastも配信しております！ぜひ聞いてください！

【前編】技術的チャレンジをし続けるために取った「起業」の選択。CTO十亀の履歴書

株式会社 Azit CTOの <a href="https://twitter.com/Pocket7878" target="_blank" rel="noopener noreferrer">@Pocket7878</a> です. 今回は、CREW Expressプロダクトの各領域で採用している技術スタックをご紹介します。 <h2 id="hebc0f8471a">APIサーバー</h2><ul><li>Rails 6.1.x</li><li>Ruby 3.1.x</li></ul>を利用しています。 サービスの開発当初は、WebフロントエンドもReactのコンポーネントをERBに乗せる形で提供していましたがフロントエンドの開発の生産性等を鑑みて、フロントエンドを切り話してAPIサーバーとしての機能提供に集中しています。 APIのスキーマはOpenAPIで定義しており、<a href="https://github.com/interagent/committee" target="_blank" rel="noopener noreferrer">commitee</a>で実装と定義の一致の検証をすると共に、Webフロントエンド側でAPIクライアントの自動生成に利用しています。 開発のプラクティスとしてTDDとDDDを採用しており、<a href="https://love-from.azit.co.jp/article/ddd" target="_blank" rel="noopener noreferrer">事業ドメインの整理の段階から戦略DDDに取りくんでいます</a> また、Rails上でドメイン構造を整理しつつ、静的型付けのある言語でより開発の信頼性や安定性を向上させるためにコアドメインを段階的にGoに移行することを計画しています。<h2 id="h3d909c6d1f">Webフロントエンド</h2>クライアントさんから利用していただく管理画面、弊社内のオペレータがカスタマーサポートの業務として利用する社内管理画面の開発では、ビジネスの変化に追従しつつ柔軟なUXを提供しやすいように<ul><li>Next.js</li><li>TypeScript</li></ul>を採用しています。 状態管理等にはRecoilとContextを利用しており、APIとの通信はOpenAPIからクライアントを自動生成し、SWRでラップしています。 CSSは、CSS ModuleとCSS in JSを併用していましたが、CSS in JSに寄せていく方針に決定して、新規コンポーネントはCSS in JSで書くと共に既存のコンポーネントの移行も進めています。<h2 id="h054fab72d6">モバイル</h2>配達パートナーから利用されるモバイルアプリケーションはAndroid, iOS両プラットフォームともにネイティブアプリで、Kotlin, Swift 100%でそれぞれ開発しています。 Android向けアプリはマルチモジュールのMVVMになっており、新規機能開発の際には既存の画面等もJetpack Composeでリライトを進めています。 iOS向けアプリはクリーンアーキテクチャ型のマルチバンドル構成で、UIのレイヤーではVIPERアーキテクチャを採用しており、新規機能開発の際には既存の画面をSwiftUIにリライトして開発しています。 VIPERアーキテクチャの採用判断はSwiftUIの登場する以前に判断したため、SwiftUIを前提に考えるとMVVMの方が適合しやすいため移行も検討しています。 Flutter等のクロスプラットフォームフレームワークの導入も開発初期に検討しましたが、サービス開発の時点でネイティブの専門性の高いメンバーが揃っていたこと、当時のフレームワークの知見の量や安定性とアプリケーションに求められる非機能要件などをふまえてネイティブで開発をする判断をしました。<h2 id="hb3c83ebaaa">最適化エンジン</h2>

CREW Expressでは、クライアントさんの配達リクエストをより少ない人数や稼動時間で効率よく配送するための各種最適化を提供する事で、クライアントさんのオペレーションや金銭的なコストを低下させる事を価値として提供しています。 そのような最適化を実施するエンジンはRustで記述しており、インフラはAWS Lambdaに乗せて最適化したい配送の問題定義をPOSTしてやると、最適化をした結果を返すようなプライベートAPIを公開しています。 APIのスキーマはOpenAPIで定義し、仕様の変更があると自動生成したクライアントコードがAPIサーバー側のリポジトリにPRとして発行されるようにしています。<h2 id="h1fc02ea273">インフラ</h2>インフラは全てAWS上に構築しており、スケールしやすい技術選定をすることで運用コストを下げるために、ECS Fargate, ElastiCache, Amazon Aurora, Amazon Lambda等を積極的に利用しています。<h3 id="hdc2da36b1a">位置情報管理</h3>AWS Automotive@Loft 第一回 モビリティサービスで登壇させていただいた時の資料:

配達パートナーの位置情報を記録する事でディスパッチの最適化に利用していますが、位置情報を稼動中の多くの配達パートナーの端末から受信して記録していくことが必要になります。 このシステムは、多くのトラフィックを受ける事になるためWriteに対してスケールする必要があり、またクライアントからの配達リクエストの量が増えた時にReadに対してもスケールが求められます。 そのような要件の位置情報の管理基盤を構築するにあたって、なるべく金銭的にも運用コスト的にも低コストで実現できる事を期待し、 Writeのスケールのために配達パートナーアプリからの書き込みの窓口にAmazon Kinesis Data Streamsを使用し、 位置情報の保存にはAmazon Location Serviceを利用しUberの<a href="https://h3geo.org/" target="_blank" rel="noopener noreferrer">H3</a>を利用してハッシュキーをつくってDynamoDBに索引をつくる事で高速な絞り込みを実現しています。<h3 id="hda9ca5f26d">構成管理</h3>構成管理にはTerraformを利用しています。 CI/CDにはGitHub Actionsを利用しており、PRを送るとfmtのチェックやvalidate、tflintの実行等の各チェックと共に、<a href="https://github.com/suzuki-shunsuke/tfcmt" target="_blank" rel="noopener noreferrer">tfcmt</a>でplanの結果がコメントされたり、マージされたら自動的にapplyされ結果がそのPRに投稿されるようにしており、GitHub上で構成の管理やレビューが完了するようにしています。<h2 id="h5e24d1c553">ログ分析・サーバー監視</h2>アプリケーションでエラーが発生してしまっている時の予兆にすばやく気がつき、その要因特定や解決をすばやく実施する事ができるよう、ログの集積・分析やAPMにはDataDogを利用しており、エラー発生時の要因分析、5xx系エラーの量の監視や外形監視等を実施しています。 また、アプリケーションレベルでのエラーの管理にはSentryを利用していて、新規のエラーが発生した場合にSlackに流れるようにして開発中やリリース後に即座に気がついて対応が可能なようにしています。<h2 id="ha214098e44">まとめ</h2>今回はCREW Expressプロダクトの各領域で採用している技術を紹介いたしました。 CREW Expressでは各領域毎に独立して最適な技術選定が可能となるように分離しながら日々改善を進めており、CREW Expressの技術的な改善を推進してくださる方を募集しています。 少しでも御興味をもってくださったら、是非お気軽に話を聞きにきてください!

CREW Expressプロダクトの各領域で採用している技術スタックをご紹介します。