Tabelog Tech Blog

食べログの開発者による技術ブログです

チームに浸透する技術選定をするためには

この記事は 食べログアドベントカレンダー2022 の1日目の記事です🎅🎄

概要

食べログシステム本部 新規事業開発部 仕入チームの板谷です。
今回は、私が何度か行なった「技術選定」についてお話ししたいと思います。
なぜこのテーマにしたかと言いますと、自分は今まで業務において技術選定といったことはしたことがなく、さらにいうと今回例にあげるようなインフラ面についてはなんとなく「使ったことがある」くらいの素人だったからです。
そんな私が初めてインフラや運用を含めて技術の導入を進めたので、同じような人の何か教訓になることがあるのではないかと思い執筆に至りました。

対象

この記事は以下の人たちの参考になるかなと思います

  • これから初めて技術選定をする人
  • 新しい技術の導入に積極的なチームメンバーの方
  • チーム内で何か意思決定をしようとしている人

この記事のゴール

技術選定を行う際に気をつけることがわかる

今回扱う題材

今回は仕入チームで実際にあった「社内管理画面のフロントエンドデプロイ先にAWSのS3を使うのかGCPのCloud Storageを使うのか」という技術選定を例に挙げつつ技術選定をする上で大事なことをまとめていきます。

前提

  • 仕入チームではアーキテクチャ変更とパブリッククラウド化を進めている
  • アーキテクチャ変更する際フロントエンドとバックエンドを疎結合にしたい
  • アーキテクチャ変更やパブリッククラウド化を進める上でPoCの機会があるとよく、ちょうど社内管理画面を新設したいという案件的要望が発生していた

上記のことから、社内管理画面をPoCの機会として活用する運びとなりまして、まず第一歩として後戻り可能な部分としてフロントエンドをパブリッククラウドに置く構成にすることが決まりました。その上で、ではどのパブリッククラウドを利用するのかという部分が選定の対象となりました。

本題

自分が技術選定を行った中で大事だと思ったことは以下の2点です。

  • 納得感を得る
  • 導入後のワークショップを行う

それぞれについてなぜ大事なのかの理由と、どうしたら良いかについてこれから解説していこうと思います。

納得感を得る

なぜ納得感を得る必要があるかと言いますと、あまり納得していないものは使われなかったり、メンバーの気持ちの中に疑問や禍根を残したまま利用する事になってしまうからです。

十分な比較材料による比較をする

当たり前のことのように聞こえるかもしれませんがこれは外せません。
「なんとなく流行っているから」や「他のチームでも使っているので」と言った理由は導入後に「自分のチームにはあっていなかった」「使いにくい」と言った事態を招きかねません。技術によって色々比較すべき項目はあると思いますが下記の4点は最低限押さえておくと良いでしょう

トレンド

なんとなく流行っているという主観ではなく世の中的に何が流行っているのかきちんと見極めましょう。自分が使ったことがあったとしても今はもう他のものが流行っているなんてことはよくあります。(自分はありました...)
調べ方は色々ありますが1つの方法として「Google トレンド」を使うのが良いと思います。
実際にS3を使うのかCloudStorageを使うのが良いのかの選定を行う際には、個々のサービスのトレンドも大事ですがS3やCloudStorageといった1つのサービスだけ利用することはなく今後全体としてAWSを使うのかGCPを使うのかが大事になりそうということでGoogle トレンドを使った比較材料を用意しました。 また、もちろんこれだけではなくそのほかにもさまざまな記事を参考にしつつ普及率の調査も行ったりしました。
これはGoogle トレンドを使ってS3とCloudStorageの比較を行なった画像です。
これはGoogle トレンドを使ってS3とCloudStorageの比較を行なった画像です。
(引用: https://www.veritis.com/news/aws-vs-azure-vs-gcp-cloud-market-share-q1-2021/)

費用感

会社で導入する上でこちらの項目は欠かせません。
もちろん安ければいいというものでもありませんが、アクセス数や利用頻度を仮定してどの程度の費用感になるのかを示すことは必須です。
実際にS3を使うのかCloudStorageを使うのが良いのかの選定を行う際には、Vueで作ったフロントエンドをデプロイする想定だったのその場合どれくらい容量を使い、どれくらいアクセスが来るのかというのを仮定し見積もりを行い概算を出しました。 これはS3とCloudStorageの料金比較を行なった画像です。

導入難易度

導入する際の難易度はあらかじめ理解しておくと実際導入となった際に進めるのが楽になります。また、こちらを行っておくと自分の理解度もグッと上がります。ネットで調べてみると簡単そうだけど実際導入してみようと思ったら苦戦することなどよくあるのでこちらもやっておくと良いでしょう。
実際の検証では具体的に下記のようなことを確認しました。

導入難易度の検証で確認したこと
  • CircleCIからデプロイ可能か
  • ドキュメントは充実しているか
  • 簡易システムを構築し、各環境でPoC
    • 手順は簡単か
    • わかりやすいか
    • コンソール画面の操作感はどうか

チームに適しているか

これまでのは技術自体の良し悪しの判定ですが、忘れてはいけないのは実際チームに対して適しているかです。
具体的に下記のようなことが考えられていると良いでしょう。

  • 自分たちのチームで解決したい課題は何か
  • 自分たちのチームで既に利用している技術は何か

チームメンバーの意見を汲み取る

こちらも当たり前ではあるのですが、技術選定を行う際調べたりするのはメイン担当の一人で最後にチームメンバーで決議を取ると言った形を採用することが多いように感じます。
その際にちゃんとチームメンバーの意見を汲み取らないと「実際あまり賛成ではなかったという人」が可哀想ですし、浸透もしにくくなってしまいます。
チームメンバーの意見を聞く際に全て説明して「何か意見や質問ありますか?」と投げかけることがよくあると思うのですが、こちらはあまりよくないと思っています。
理由として、質問しようにもあまり説明がわからなかったと言った場合に言いにくいことや、色々調べてくれた人に向かって反対意見を言いにくいということが挙げられます。
そこで、自分は一人一票意思を表示できるようにしておくと良いと思っています。
自分はよくこちらの「Team poker」を使っています。 これはTeam pokerを使ってアンケートを取った際の画像です。 このように一人一票投じる体制を作ることで、みんなの意見がより汲み取れやすくなります。

最終的にどちらになったのか

AWS GCP
トレンド
費用感
導入難易度
チームに適しているか
チームメンバーの意向
  • トレンド
    AWSの方が大きく上回っておりました。
  • 費用感
    費用感に関しては想定される金額が少額であるため大きな差はありませんでした。
  • 導入難易度
    どちらも難しくはないのですが普及率の高さから問題解決の際に助かるであろうということ、今後慣れていない方も運用する上でコンソール画面が見やすい方が良さそうという点からAWSに軍配が上がりました。
  • チームに適しているか
    機能に多少差はあれど現時点の機能ではどちらが適しているといったことはなさそうでした。
  • チームメンバーの意向
    チームメンバー全体の意向としてはシェアが広いことや、個人的に慣れている方もいることがありAWSの方が多数派となりました。

以上のことから最終的にはAWSを使うことを見越してS3の利用となりました。 今回は意思決定のスピード重視で後戻り可能な範囲としてフロントエンドの技術選定を行いました。今後はより全体最適の検討も行いつつ、システム全体の移行を進めていきます!

導入後のワークショップを行う

忘れてはいけないのが、導入後のケアです。
技術選定は技術を導入することが目的ではなく導入してチームで運用するのがゴールです。
そのために導入後にその技術についてワークショップを開くと良いかと思います。選定段階でメリットやなんとなくの使い方は理解されてると思うのですが、頭で理解していても実際使うのは少しハードルがあります。また、わからないものは便利さより大変さの印象の方が勝ってしまったりします。それはとても勿体無いことですので少し時間はかかるかもしれませんが、導入した技術についてみんなが手元の環境で動かせるようにしてあげるとその後の運用の話などが進みやすいかと思います。
今回のケースだと実際にAWSのコンソールにみんなで入ってみたり、S3の設定を一部変更してみてどのような変化があるかをみんなで確かめたりすることが挙げられます。

以上のことに気をつけると選定したものがチームに浸透しやすいかなと思います。
ぜひ参考にしてみてください。

技術選定をしてみての学び

この会社に来るまで技術選定というものを行なったことがなかったのですが、何度か行うことでチーム内で意思決定をする際に大事なことを学べました。
何か意思決定をする際、今までは割と一人で抱えて最後に共有するという形をとっていたのですが、なんとなくチームメンバーに伝わってないなと思ったり、周りの人はどう思っているんだろうと思うことが多かったです。
原因は今回挙げたようなことがちゃんと行えていなかったからなのだと思います。比較材料が足りなかったり、相手の意見を聞いているようで聞けていなかったり、目的と手段を履き違えて導入することに注視してしまってその後のことをちゃんと考えられていなかったり...
つまり、相手の視点に立つということができていなかったのだと思います。
振り返ってみると当たり前のような感じもするのですが、できているつもりでできてないことがまだまだあるなと学びのある経験でした!
今後技術選定に関わらずチーム内での意思決定をする際は上記で学んだことを生かしていきたいと思います。

次回予告

明日は@kinoshita-yuさんで「大規模システムのリファクタリング」です。お楽しみに!