【技術特集】選ばれた技術、その理由と裏側～②～

こちらは【技術特集】選ばれた技術、その理由と裏側～①～の続きです。

佐藤さん

では、続いてGoogle Cloudの構成について話していきたいと思います。
今回、注文一元管理サービスからデータ連携されてきて業務システムから取りに来てもらう構成で行くので、注文一元管理サービスから連携された注文情報を保持しておくためのDBが必要になってくるのですが、そこのDBをどうするかを検討したいと思います。興野さん何かいい案ありますか？

興野さん

うちで良く使われているDBがCloud SQLになってくるかなって思いまして、最初にCloud SQLで試算を出してみました。今回はアクセス数が何万件も入ってくるといったところから、1件当たりのデータ量とかも試算ができたので、数値としては大体186~190ドルくらいはかかるといった想定となっております。高可用にした場合で320ドルくらいかかってくるかといった想定です。
今回は店舗数自体も、導入店舗数自体もそこまで大きなものではなく、1日当たりの書き込み数の部分も想定していくと、そこまでの量ではないので、Firestoreのネイティブモードを採用するのもどうかと思っております。こちらの方も試算を出してみましたが、大体50ドル前後で収まって、3分の1くらいのメリットが出てきたといったところになります。しかし、FirestoreはNoSQL形式になっているので、データがあまりにも複雑であればCloud SQLの方も検討するべきかと思っております。

佐藤さん

今のところ要件を見る限りでは、何かリレーションを張らないといけない訳ではなさそうですし、Pull型になる前提ではあるのですが、注文情報の保持と、注文情報を送ったか送ってないかといったステータスの管理と、その店舗を識別するための識別子があれば、要件としてはクリアすると思うので、NoSQLでも問題ないかと思います。

興野さん

ありがとうございます。という事でしたら、1店舗につき月2000件のオーダーといったところで、1日で割っていくと、66件程度、50店舗でも1万件オーダーぐらいなので頻繁ではない部分もあり、Firestoreにするのが良いかと思うのですが、いかがでしょうか？

佐藤さん

良いと思いますね。Cloud SQLとFirestoreで開発工数に影響はありますか？

興野さん

今回のような単純な構造であれば、特に開発工数に影響はないと思います。

佐藤さん

なるほど。そうでしたら、今回はFirestoreで進めましょうか。インフラ構成的にはAPIはCloud Functionsを使って構築して、DBはFirestoreということで進めていきたいと思いますが、他にこの場で決めておきたいことはありますか？

興野さん

今のところは大丈夫です。

佐藤さん

では、引き続きよろしくお願いいたします。

藤森

打ち合わせに同席させていただき、ありがとうございました！

話を聞いてみて思ったのは、業務システムに搭載させたい機能・特徴をきちんと把握・明確化したうえでそれに合った技術選定を行う、といったことが重要なのが伝わってきました。初めに佐藤さんが店舗数・アクセス数の計算などを発表して、条件を整理してから興野さんがそれに合った選択肢を提示しているような形ですね。業務システムの特長を生かせるように技術選定をされているのが印象的でした。
また、選択肢の多さ・引き出しの多さというのも、技術選定の上で大事になってくるのではと思いました。話の中で興野さんから勉強会に参加されていたとのことでしたが、そういった勉強会には頻繁に行かれてるんですか？

興野さん

私の場合は「connpass」といったエンジニアのイベントが募集されているサイトがあるのですが、それに応募したり、何回か登壇して発表を行ったこともあります。

藤森

実際に発表を行ったことがあるのはすごいですね。常に勉強もしながら、選択肢を増やしていって、製品に合った適切な技術選定を行えるよう日々努力しているのが伝わってきました。ありがとうございます。
ではここからは、打ち合わせの進め方についての質問をいくつかしていきたいと思います。

みんなで意見を出し合って決めるときに気を付けていることはありますか？

佐藤さん

特定の人だけが発言しないように、皆に話を振っていくというところに気を付けていますね。

興野さん

最近は自分の意見、例えばインフラ構成だとこういった感じにするべきじゃないですかと提案すると同時に、まわりの意見を広く求めるといったことも意識しています。結果として、自分だったら想定していない盲点だった部分が見えてきたりすることもあるので、注意するようにしています。

意見を出し合った後、最終的な判断は誰が下していますか？

興野さん

我々の中で意見をまとめて結論が出たとして、その結論で良いかを決めることを最終的な判断とするなら、リーダーやグループ長になってくるかと思います。

藤森

リーダーの立場になる佐藤さんはどうでしょうか？

佐藤さん

そうですね。まずバックエンド内でリーダーの人が決定して、その後にプロジェクト全体のレビューなどもあるので、結局のところ最終的な決定というのはDR(判定会)で行われる感じかもしれないです。

1度決めたことの判断がプロジェクトの途中で変わったことはありますか？その時、どのような対応を取りましたか？

佐藤さん

これはしょっちゅうあります。むしろない方が珍しいくらい。なのでその都度メンバーを集めて、問題点を話して、どう対応していこうかを決め直すことが多いと思います。

藤森

そうなんですね。しょっちゅうあるということで、1度決まったとしても、変わる場合に備えて対応できる柔軟性も必要、ということですね。

意見を発言する時に迷ったり躊躇したりすることはありましたか？

興野さん

今回のプロジェクトでFirestoreのネイティブモードというものを採用しているのですが、バックエンド内では前例としてはないものを取り入れていて、当時は入社2年目でしたが新しい技術の提案もしやすいし、実際にそれが採用されて製品として出される、といったことがあり、躊躇することはなかったです。

最後の質問となりますが、お互いに尊敬するところや、すごいなと思うところを教えてください。

佐藤さん

興野さんは、すごく勉強家で、新しい技術に対するピックアップのスピードがとても速いので、とりあえず興野君に新しい技術のことを聞いたらなんでも答えてくれる、素晴らしい人だと思ってます。

興野さん

佐藤さんは、これまでのエンジニア経歴が非常に長い方でして、そこの経験から出てくる、何かしら懸念される問題点の把握とその問題のピックアップや、あとはバックエンド開発グループの中だとリーダー層が正直少ないといった部分があるのですが、その中でも会議などスムーズに行えていて、マネジメント能力が高い方だと思っています。

ーーーーー

バックエンド開発グループの佐藤さん、興野さん、貴重なお話をありがとうございました。

この取材を通して、お２人がお互いの長所を理解しながら業務に当たっていることが伝わってきました。今回は2人での技術選定でしたが、人数が増えても、開発の場面になっても意見を出し合いながら進めていく様子が容易に浮かんできます。佐藤さんからも「バックエンド開発グループは、チームワークを活かしてプロジェクトに取り組んでいます」とのことでした。

さらに、「バックエンド開発グループはリモート勤務が多いのですが、常にMeetをつないでいて業務のことだけでなく、雑談もしてるんですよ」と普段のコミュニケーション方法を教えてくださいました。リモートでも常にオンラインで繋がっていて、まるでオフィスで並んで仕事しているのと同じような感覚で仕事できているからこそ、いい関係性が保てるんですね。良いチームワークの秘訣も聞くことができて、とても充実した取材になりました。

今後も開発現場の取材レポートを順次公開していく予定ですので、楽しみにしていてください！