#6 スタフェスのエンジニアはどのように開発しているのか ahiru にその裏側を聞いてみた【STAFESおくのほそ道】
「STAFESおくのほそ道」と題しまして、「スタフェスで働く人たちってどんな人なの？」をテーマにお届けしていきます！
これはソフトウェアエンジニアの吉藤がホストするPodcast、Radio STAFESのシリーズ「STAFESおくのほそ道」の公開と合わせて、一部内容を記事化しています。
第6回目のお相手は、ahiruさんです。
話し手
吉田祐平（ソフトウェアエンジニア）
経歴
Twitterでは 吉田あひる として活動。社内でも ahiru と呼ばれる。
2021年1月にスターフェスティバルに入社。
ごちクル運営のバックエンドをメインに、インフラやフロントエンドにも携わっていたが、ここ1年は社内の管理基盤をリプレイスする KAGUYA チームにて要件定義や設計・実装に関わっている。
現在は TypeScript をメインにバックエンドエンジニアとして従事。
どういうものを開発しているか
吉藤：
ahiru さん、入社してもう2年ぐらい経ちますが、大車輪の活躍ですね。設計が大好き！ということで、設計伝道師だと思っています。
今、商品登録の開発をしているかと思いますが、具体的にどういうものを開発しているのでしょうか。
吉田：
社内の既存の管理基盤をリプレースする KAGUYA というチームにジョインしてから、まずやり始めたのが商品を登録できるようにしていくというものでした。
製造パートナー（弊社と契約を結んでいる製造側の総称）と呼ばれる方々がいらっしゃいまして、弊社が運用しているプラットフォームに商品を登録することで、製造パートナーさんが作った商品を、 ごちクル とか ごちクルNow というサービスに展開ができるようになるんですけど、今まで、その商品を弊社のプラットフォームに登録するためには、ノーコードツール（ソースコードの記述なしにアプリやWebサービスが開発できる方法）みたいなものを経由したフォームで登録したり、あるいは弊社の営業にExcel等で共有してそれをもとに弊社のオペレーションチームが管理基盤にポチポチ登録していくフローだったんですよね。
それだと運用工数がかかるとか、製造パートナーさん自身が好きなタイミングで商品登録できないとか、そういった課題感があったので、製造パートナーさん向けの管理画面を用意して、そこから直接商品登録をしていただけるような機能を開発しておりました。
吉藤：
今まで弊社が商品情報を電話だったりメールだったり、あるいはフォームだったりでヒアリングしていたものを、自らの手で登録してもらえるようにしていこうっていうものですね。
人間がインターフェースになっていたところに新しく管理画面を作るということで、何から手をつけていいかわからない途方もない開発だなと思うんですけど、最初どういうことから始めていきましたか？
吉田：
大変だという話はチームに移動したタイミングで聞いていたのですが、具体的にどこを改善しなきゃいけないのかは全く知らなかったので、まずは情報収集を行いました。
弊社ではドキュメント管理を Confluence というツールを使って行っていて、基本的にはそこに様々な情報が載っているので、オペレーターの方々の作業フローが記載されているドキュメントを探しにいって、片っ端から全部読みましたね。
ただやっぱりドキュメントを読むだけだと、実際のところどうなのかな？と思う部分があったり、スムーズにできたパターンしか書いてなかったりするので、例外パターンについてとかは、直接オペレーターの方との mtg でヒアリングしました。
現状どういう状態になっていて、商品を実際その管理基盤に登録するためには本来どういうフローになっていたら楽なんだっけ？というのを考えるところからのスタートでした。
吉藤：
ドキュメントっていうのが、今どういう情報を製造パートナーさんから受け取っていて、それをどういう観点でチェックしていくか、みたいな内容ですよね。どこと調整して、いつ登録する、というフローなんかの情報が分散していたと。まず情報収集が結構大変だったって感じですよね。
吉田：
そうですね。商品登録までのフローとか、関わる人物がどのくらいいるのかとか、ドキュメントを読んだだけだとよくわからないんですよね。ヒアリングしていったら、製造パートナーさんが「商品登録したい！」って言ってから実際登録するまでの流れで想定と違う箇所があったり。最初から最後までのフローを同一人物がやっているのかと思ったら、社内でも何人かのコミュニケーションが発生していたり。
吉藤：
そういうフローを発見するのは結構大変でしたよね。
商品を自身で直接登録するっていうことを製造パートナーさんにしてもらいたかったわけですが、商品にも色々あって、お弁当だけでなくて、他にもサイドメニューとか色々ある中で、最初丸ごとやろうとしたんですよね。
吉田：
今考えると、とてつもないことをしようとしていましたね。
吉藤：
あの時思っていたものの一部を実現して、リリースまでいけたって感じですよね。
ahiru さんが各所へヒアリングされた後、最初に設計したのってどういうところだったのでしょうか。
吉田：
一番最初は、商品を登録するにあたって、製造パートナーさん自身が入力しないといけないものの中で、弊社で補完する必要があるかどうかの区別から始めました。
現状のフローが、製造パートナーさんから聞いた内容を弊社が少し手直しして改めて登録する流れだったので、製造パートナーさん自身に入力していただかないといけないものと、その中で弊社が補完しないといけないものがあるかを再確認する必要があったんです。
具体的には登録申請っていうオブジェクトを、コード上と言うかデータベース上にも登場させないといけないんですけども、そこのデータ構造をどうするかというところからまず考え始めましたね。
実際に手を動かしてみて大変だったこと
吉藤：
例えば製造パートナーさんが使う管理画面からスタフェスの管理画面上にデータを申請データを持ってくるみたいな登録申請を、イベント駆動でやったわけなんですけれども、その辺の辛さとかもありました？
吉田：
そうですね。新しい管理基盤と言うか、 KAGUYA って言われるものを開発していて、その製造パートナーさん向けの管理画面と、社内向けの管理画面のやり取りもイベント駆動を採用しているんですよね。
そもそもの話。イベント駆動でやっている理由から説明すると、 API ベースで各種アプリケーションがやり取りするっていう世界観で、当然機能自体は実現できると思うんですけど、それをしてしまうと、 KAGUYA って管理基盤なので、KAGUYA が落ちると、周辺のアプリケーションが全部落ちてしまうんですね。そのような耐障害性みたいなところの懸念がありました。
あとは KAGUYA にしか情報がない状態になってしまうと、例えばそのデータ基盤と言われる、マーケティングに使うデータだったり機械学習に使うデータだったりを蓄積していくものがあるんですけど、そこにデータを連携するのもバッチなのか、 API ベースでやるのかという話なんですが、バッチからだとデータを同期するところにリアルタイム性がなくなってくるし、API ベースだとそれはそれでちょっと重いわけですよね。
そのあたりを解決するにはどうするかっていうので、イベント駆動っていうものが候補として上がってきました。イベント駆動っていうだけあって、イベントを起因に様々な処理が動くっていうような世界観のものなんですけど、例えば KAGUYA 上に商品が登録された場合、普通の開発だとその商品登録 API を叩いたら、そのリクエストの中でデータベースに書き込みにいくのに対して、イベント駆動だと、API が叩かれたら、まずその商品が登録されたよ！ってイベントを発火して、そのイベントを監視している周辺のアプリケーションがそのイベントの中身を見にいって、自分たちのデータベースに取り込む処理の流れになります。
イベント駆動でやることによって、データ基盤へのデータの連携っていうのもリアルタイムで行うことができるし、耐障害性に関しても、 KAGUYA っていう管理基盤が落ちていても動くようにしたいっていうニーズがある場合は、そのイベントを元に自分たちのアプリケーションでデータベースにイベントの中身を保存してもらえれば、わざわざ KAGUYA の API を叩かなくても、自分たちでそのデータを表示することができるので、そういったメリットを得るためにもイベント駆動にしています。
製造パートナーさん向けの管理画面と、社内の管理基盤の連携も、イベント駆動をもとにやっています。
イベント駆動を導入して何が大変だったかというと、僕自身、イベント駆動に対する知識が全然ない状態から始めたので、アンチパターンをほぼ知らないし、イベント駆動ならではの設計というか、イベント駆動にしたことによるアプリケーションコードへの影響も知見がない状態だったので、かなり手探りだったし、様々なアンチパターンっぽいものを踏んだなっていうところですね。
吉藤：
今の時点でもうすでに、イベントの設計をして、「あ、失敗したな」と思って変えたものもありますし、まだ発見できていない失敗も沢山ありそうですよね。
吉田：
そうですね。あと、発見しているけどまだ変えられてないやつとか。
吉藤：
どうすんだこれ・・ってやつね。
単純にその商品を登録するっていう機能だけを聞いたときに想像する開発の量よりも、工程めちゃくちゃ多い気がするんですけど、その辺りどうでした？
吉田：
API で受け付けて、その場でデータベースに反映させるっていうフローじゃない以上、その一つの機能を実現するために必要なコンポーネントっていうか、要素がどうしても増えちゃうので、開発量自体は増えてるなーっていう実感はありますね。加えて、デプロイの手数もどうしても増えちゃうので、そこら辺の工数はかかるなぁとは思いますね。
吉藤：
個々のコンポーネントの実装をデプロイしたとしても、結果繋げて見せることができるのが、一通り開発し終わってからになっちゃいますよね。それで、デモを見せるのに結構時間かかっちゃったりして、なかなか思うように進まなかったり。
吉田：
そうですね、もっと早く見せたかったなと思います。やっぱり実際に見せると、「ここはこうして欲しかったんですけど」という意見をいただくこともあって。でもリリース時期も近いから、「リリース後の対応でいいですか？」という会話になってしまったことも、反省点でしたね。
吉藤：
そうですね。我々が見つけられていないもので、運用してくださってる方々が知ってることを引き出すのって難しいというか、お互いに何を知っていて何を知らないのかを完全に把握していない以上、 ”もの” を見ないと出てこない意見・わからないことってありますよね。
そういうイベント駆動の事情もあってか、新しい商品を登録するっていうことだけを念頭において開発されていたかと思うんですけど、その登録した商品を変更する機能の開発も苦労されたところがあったと思うんですよね。
「変更するだけだったらボタン押したら終わりじゃん」って思われがちですが、製造パートナーさんから変更の申請を上げてもらうっていうフローだと、ただ変更するのとは訳が違うと思います。
吉田：
そうですね。イベント駆動だからというのも多少あると思うんですけど、一番工数を上げる要因になってるのは、相互運用だからなんですよね。
僕が所属している KAGUYA っていうチームは、社内の既存の管理基盤をリプレースしていこうということをやっているわけですけど、なぜそれをやっているのかと言うと、背景として、既存のデータモデルが複雑化してしまっているのがあります。本当はこういうことがしたいんだけど、そのデータモデルだとできないとか、あとは欲しいデータ取ってくるのにデータモデルが複雑なせいで何回もクエリを投げ直さなきゃいけないとか、様々な現状があって。
商品登録申請の機能を実装するにあたって、データモデルの改善も一緒にやろうというのがミッションとしてあるんですけど、とはいえその既存の管理基盤のデータ構造を一気にドンって変えると、影響範囲が凄まじいことになってしまうので、気軽に変えることができない。そこも開発のスコープに入れてしまうと、登録申請とか変更申請とかの開発がそもそも進まなくなってしまうんです。
新しいデータモデルを提案しつつ、既存の管理基盤のデータモデルも活かすということを考えると、KAGUYA 上にデータが登録されたら、それを既存の管理基盤に同期させなければいけない。
ただ、その二つのデータベースがある状態でお互いがその相互運用可能な状態に納めなきゃいけないとか、変更申請に関しても、 KAGUYA の方で変更されたものをを既存の管理基盤に同期させるのは問題ないんですけど、 KAGUYA ですべての変更がまかなえているわけではないので、既存の管理基盤でしかできない操作があるんですよね。なので、既存の管理基盤で操作されたら、その変更も KAGUYA に持っていくみたいなことをしないといけないっていう。これが開発工数を上げる要因になっているかなと思いますね。
吉藤：
既存の開発基盤で加えた変更も反映させるし、新しい開発基盤からの変更の申請をスタフェスの方で承認したらそれも反映させるし、双方向のデータのやり取りみたいなのが単純に反映させるだけじゃなくて、どっちを勝たせるのかみたいな、そういう複雑なことも考えなきゃいけないですもんね。
吉田：
製造パートナーさんが変更申請をしてくれたら、それをすぐさま社内の管理基盤に反映させてしまうと、またいろいろ問題が発生するので、その申請を審査する期間みたいなのが必要になったりするんですけど、その間に既存の管理基盤の方で商品変更されちゃったら、その場合どういう状態になってなきゃいけないの？という調整は結構大変でしたね。
吉藤：
そうですね。既存の運用を止めずに、新しいものに移行していくっていうのが、ファーストリリース後の開発からは難しいなって改めて思います。
例えるなら、坂道で転がり始めてしまったらもう止まるわけにはいかなくて、呼吸するタイミングがないと言うか。
吉田：
まさにそんな感じですね。
設計の中で得た学び
吉藤：
商品を登録したり変更したりの設計を考える中で、学びみたいなものってありますか？
吉田：
学びというか、未だに難しいなと思って考え続けてるところではあるんですけど、既存のデータモデルが現状、いただいている要求全てに応えられる状態になってないっていうのがあるんですね。既存の管理基盤をつぶさに調べていって、それをそのまま綺麗に直したものを KAGUYA 上に新しいデータモデルとして定義するだけだと、おそらく不十分なんですよね。
というのも、恐らくもう諦められてる要求がいっぱいあって、現実的に既存のデータ基盤で実現できない要求もいっぱいあって、まだまだ言語化されてないものも多分いっぱいあるので、ただ綺麗にするだけだと、おそらく不十分なんだろうなと。
とはいえ、じゃあどういう要求が今後が発生するのかっていうところまでは全部は見えてないので、新しい商品のデータモデルはどういう形に落ちつければいいのかなとか、そういう見えてない要求に対して今後どういう構造であれば今後の追加改修が行いやすいかとか、どこで着地させるかとか、そのあたりがとにかく難しいし、悩み続けているところです。
あとはモジュラリティに対する感度は良くなってきたなと思います。
実は、今回の商品登録申請の機能開発時に、個人的にめちゃめちゃ反省したミスがあったんです。
商品を登録する申請だから、パッと見、その申請の内容と商品の内容が一致してるように見えるんですよ。なので、商品のデータ構造と登録申請の中身を、データベース上で同じような扱いにしてしまったんですよね。
後から問題に気づけば、何でそんなことしたんだって感じではあるんですけど、同じところにリレーションを張るようなことをしてしまったせいで、商品申請と商品っていう2つのドメインの結合度が高くなってしまいまして。
何が具体的に問題だったかを説明すると長くなってしまうので割愛するんですけど、こことここはもう扱う問題が異なるから、一見同じように見えても分離させなきゃいけないんだ、というような勘所みたいなところが、今の開発をしていてよくわかってきたというのが学びとしてありますね。
吉藤：
商品と申請っていうのはライフサイクルも違うし、それを一緒に扱ってるから色々難しくなってるのではないか？っていうことに気づくタイミングがあったわけですよね。僕はミスでなく成功だと思っています。
吉田：
幸いにも弊社はリファクタリングに理解があるというか、複雑性を押さえていいプロダクトを作っていこうというところにすごい理解がある環境なので、そこの技術的負債の解消はすごく大変だったんですけど、先日無事にそこの解消も終わって、ようやく許容範囲の構造になってきたかな、というのはありますね。
吉藤：
どうしてもこういう刷新するっていう仕事だと、リモデリング・リアーキテクチャにどこまで時間をかけるかっていうのは、なかなかバランスが難しいところですよね。
外から見ると「アウトプットしろ」という風に見えてしまうし、なんかそれを優先しすぎると本来の目的を見失うというか、このバランスに常に苦しんでるところですけど、答えは見つかってませんね。
吉田：
今、僕が所属しているチームでは一つ新しい試みとして、リファクタリングデーを毎週月曜日に開催しています。
その名の通りなんですけど、リファクタリングを月曜日にがーっとやって、アプリケーションコードの複雑性みたいなのを定期的に下げる活動をしていこうというものですね。
なんで週1でやっているのかというと、この前社内で、『A Philosophy of Software Design』 っていう本の輪読会をしたんですけど、その本の中で「開発時間の10%から20%をリファクタリングに当てると、数か月でリファクタリングをしない開発に比べて、開発速度が上回っていく」というようなことが書かれていたので、やってみようと。
5日のうち1日を丸々リファクタリングに充てれば、だいたい10～20%ぐらいに該当するということで、週1リファクタリングデーをやって、より開発速度を上げていこうという試みです。
吉藤：
たしかに月曜日って mtg もたくさんあるので、そもそもフルで開発できないことが多いですよね。そこを逆手にとっての月曜リファクタリング。
吉田：
そうですね。そのおかげでさっき言った技術負債も解消する時間が取れたし、開発速度っていうのは、こういう試みがあることで健全になってくんじゃないかなと思いますね。
吉藤：
日々の開発で、「やっぱりこれどうしようかな？」と悩むことも多い開発をされていると思うので、リファクタリングがそういうスパンでできるとなると、決断の速さという面でも、良い効果が出そうな気がしますよね。
最後に今後の開発の話を伺いたいんですが、 ahiru さん今どういう開発をしてますか？話せる範囲で構わないので、ざっくり教えてください。
吉田：
もう結構ずっと頭を抱えているんですが、スターフェスティバルって、一言で商品と言っても、いろいろな種類の商品がありまして、先ほど話した登録申請・変更申請で扱ってる商品っていうのは、お弁当って言われるものだけなんですね。
でも実際には、スターフェスティバルではドリンクとかサイドメニューとか、付属品と呼ばれるようなものとか、様々な商品の種別があって、担保しなきゃいけないデータの整合性がそれぞれ異なるんですけど、それらを新しい管理基盤の方でも扱えるようにしようっていうところを今取り組んでおります。
吉藤：
なるほど。そのあたりもたくさん聞きたいことがあるので、リリースが終わったらまたお話聞かせていただければと思います。
今日は ahiru さんに来ていただきました。ありがとうございました！
吉田：
またお話させてください。ありがとうございました！
📻配信リスト
Spotify ApplePodcast GooglePodcast
編集者から
最後までお読みいただきありがとうございました！
おくのほそ道始まって以来の、がっつり開発のお話でしたね。
ahiruさんとは採用チームとして一緒に採用もやらせていただいていますが、こういったお話は聞いたことがなかったので、これをやりながら採用チームにも所属しているってすごい・・・と思いながら聞いておりました。いつも採用周りでもありがとうございます。
一言でエンジニアと言っても様々な職種・幅広い業務がありますが、正直、そこにどのような苦労があって、悩みがあって、という想像できていなかった部分を、このインタビューで垣間見ることができた気がします。
この回に限らずですが、ぜひクルー全員に読んでほしいと思いました！（スターフェスティバルでは社員のことをクルーと呼びます）
会社のバリューの一つに、「WOW!」があります。
驚くほどのスピード・クオリティでお客さまの期待を大きく超えていこう！最速で最高を目指そう！というものです。
代表のYusukeさん（スターフェスティバルでは社長のことをYusukeさんを呼びます）がいつもされているのが、
「相手からの期待値があって、自分の仕事の結果がそこを下回った時に相手が感じるのが【不満】。だいたい期待値通りだと【満足】。満足をさらに上回ったら【WOW!】になる。さらにそれを上回ったら【感動】を与えられる。どんな仕事においても【WOW!】を目指そう」という話。
ahiruさんのお話は、まさにこれだなと思います。
出来上がったものでも改善を続けるし、どんなに手がかかっても、より良いリプレースのために基盤の相互運用をする。
結果としてシステムに不具合がない状態というのが前提になってくるのが、シビアだなと思うところの一つなんですけど。
全員が【WOW!】を意識して日々を過ごしたら、とんでもないプロ集団になれると改めて確信したお話でした。
スタフェスおくのほそ道、今回はKAGUYAについての回でした。
次回もお楽しみに！！
この記事が気に入ったらサポートをしてみませんか？