はじめに

プラットフォーム事業本部、Customer Decision Support Teamの岡見です。

所属部署の名前からは何をやっているチームなのか想像がつきにくいと思いますが、簡単に言うと、ユーザーレビューなどを通してお客さまの購買行動を促す施策とそのシステム開発をしています。昨年の7月にできたばかりのチームで、現在は、旧システムのリプレイスが主な業務です。

「ユーザーレビュー基盤の変革」シリーズとしては過去にも記事を書いておりますので、よろしければそちらもご覧ください！

新しい基盤を構築するリプレイスでは、どのような技術を採用するかをまずきちんと考える必要があります。新しい技術はどんどん出てきますし、ともすると興味本位で技術を選定したくもなりますが、大切なことは、要件に最適かどうかを考えることだと思います。考えることはたくさんありますが、例えばこんなポイントでしょうか。

数年先も動作するか
きちんと保守をしていける環境を整えられるか
スケールし、規模が大きくなっても大丈夫か etc.

今回、Customer Decision Support Teamでは、システムのリプレイスに際して新システムの構成を検討しました。この選定にあたって考えたこと、また今までの経験からどんな点に気を配って技術選定しているかを自分なりの観点で以下に紹介したいと思います。

人材確保ができるか

その技術を扱える人が少ないと当然、人を確保するのが難しくなります。求人や日本語の書籍の数が十分にあるかどうかが業界にいかに浸透しているかの目安になるので、考慮すると良いでしょう。

ランニングコストは高くないか

パフォーマンスが良ければサーバーリソースを節約できるので、ランニングコストが下がります。弊社の元CTOが言っていましたが、費用を抑えてよいものを作るのはエンジニアの腕の見せ所ですよ。

開発スピードはどうか

コンパイル時間、テスト時間、起動時間と、時間はかからないほうがいいです。ユニットテストに5分かかったらフラストレーションも溜まるでしょう？

資料は充実しているか

公式ドキュメントのサンプルが充実していることや、qiitaやblogでサンプルプログラムがある状況が望ましいです。日本語の書籍が多数出版されているなら業界にすでに浸透している、あるいは浸透し始めてきた技術と言えそうです。

運用しやすいか

あれも使いたい、これも使いたいで、いろんな技術を取り込んだら運用が辛くなります。よりシンプルにできないか、本当に必要なものかどうかを考えてみましょう。

引き継げるか

これは考えていない人が多いように感じています。引き継ぎが発生したときに、丸投げすることなく、きちんと引き継げるものかを考えてみましょう。スキルや向上心が足りないからと同僚を非難せず、技術的負債とならないように、習得可能か考えましょう。日本語書籍がオライリー本しかない技術で構築した場合、問題なく引き継げますか？

私欲で導入しようとしていないか

新しもの好きなエンジニアさんは多いです。新しいものを使いたいと意欲的なのは素晴らしいことですが、仕事で使う必要が本当にありますか？趣味とはしっかり切り離して、これじゃないとダメな理由を考えてみましょう。使いたいからという理由では、引き継がれる側は納得できません。

資料は充実しているか

リリースされたばかりの技術を使おうとしていませんか？初期リリースやメジャーバージョンアップの時はバグが発生するものです。必要なのは人柱になる覚悟ではなく、一呼吸を置く冷静さです。少し時間をとって、俯瞰してみましょう。

シンプルな構成で構築できるか

実は導入する必要ないとか、実はもっと簡単にできるとかありませんか？言語を例にあげれば、１つの案件で複数個を使用することはよくありますが、まとめられないものでしょうか？インフラ設計で言えば、集約できるところはありませんか？複雑な構成は運用が辛くなります。シンプルにしましょう。

今後の展望はどうか

メンテナのいない技術を採用したら悲劇です。脆弱性は修正されないし、不具合も修正されません。長くメンテナンスされているもの、適度にバージョンアップしているものを選びましょう。

普及するか

人の確保は容易になりますし、機能は充実します。普及するかどうかはとても大事なことです。普及せず、廃れてしまっては、さらなるリプレイスが必要となり、技術的負債と呼ばれてしまいます。新しいものを導入する時は、業界に浸透しそうなものかどうかをしっかり考えてみましょう。

学習コストは低いか

なるべく楽なものを選びましょう。先端技術を導入したとして、技術力がすごいと周りがほめてくれるかもしれませんが、そのシステムはあなたに依存していること忘れてはいけません。チームメンバーや社内のレベル、業界での普及具合を考えて選定しましょう。ハードルの高いものを採用する場合は、引き継ぎまで考えて、導入しましょう。

目標達成できますか

スケジュールや品質、運用コスト、SLAなどの数値目標はクリアできますか？

まとめ

こうした観点で、Customer Decision Support Teamでは、リプレイスの際の言語にGo言語を採用しました。下記にいくつか理由を挙げます。

高スループットのためランニングコストを低く抑えられる
dockerと相性が良く、開発環境を完全にコンテナ化できる
ライブリードが早い
書籍や資料が充実
既存チームから引き継ぐプロダクトがGo、Node.jsを利用している
社内で実績がある

学習コストを低く抑えたい場合、Node.jsの選択肢もありますが、Node.jsを利用するとスループットがGo言語と比較して低いので、ランニングコストが高くなります。

チームのメンバーみんなGo言語未経験でしたが、幸い、社内で優秀なGo経験者を採用できたので、炎上する心配もなく、順調に開発を進められています。

Customer Decision Support Teamでは、一緒に働く仲間を募集しています。私たちのチームは、コストを抑えて、品質の良いものを作りたい気持ちでシステム開発をしています。ワークライフバランスが整った環境で働きたい人、Golangでシステム開発したい人を募集しています！

秒間7000リクエストが必要な高トラフィックシステムを一緒に開発していきましょう！

dmm-corp.com

DMMにおけるユーザーレビュー基盤の変革（技術選定で気をつける13のこと）

シェア