1
/
5

技術選定の極意を教えます! OKANのシステム開発で使用している技術スタックと選定基準

こんにちは。OKANでCTOを担当している川口です。採用の面談をしていると必ずといっていいほど質問される、OKANのシステム開発で使用している技術スタックと技術の選定基準について説明したいと思います。

フロントエンド開発

フロントエンドの開発には React を使用しており、言語は TypeScript で開発しています。

Reduxのような大掛かりなState Managerは入れておらず、シンプルに React Hooks のみで実装する方針で進めています。コンポーネント化に関しては強力に推し進めており、OKANで定義したデザインシステムをもとに部品化・標準化を行っています。

OKANではライブラリやフレームワークは最小限にしていくという方針 (これについては機会があれば別途説明したいと思います) があるので、自分たちで低コストで開発できるレベルであればライブラリ的なものも自作しています。

例えば、HTTP Requestライブラリで有名なところではAxiosなどがありますが、HTTP Request程度の処理であれば自分達でもそれほどコストをかけずにライブラリ化できるので、必要最低限の機能に絞って自作したものを使っています。

コンポーネントの開発に関しては、前述した通りデザインシステムを適用して開発しています。エンジニアとデザイナが一緒に Storybook を使用してUIのデザインや振る舞いについて調整をしながら効率的に開発を進めています。

ここまで説明した内容は、新規開発する部分での話。既に開発済みのシステムには Ruby on Rails を使用したところが多く存在しています。順次新しい技術スタックへの置き換えを進めていますが、既存システムを直接修正していくケースもまだまだ多くあるため、そのような場合は Ruby で開発を行っています。

バックエンド開発

バックエンドの開発には Node.js を使用しています。こちらも言語は TypeScript です。フレームワークは Express を採用しています。

フロントエンド開発のところで説明したとおり、バックエンド開発においてもライブラリやフレームワークは最小限にするという方針に則り、ライブラリなどは最小限にして進めています。

例としては、ORマッパーのライブラリなども使用していません。流石にDBコネクタライブラリは使っていますが、そもそも TypeScript は JavaScript なのでデータは Object で返ってくる。データモデルにおけるアーキテクチャは CQRS を採用しているので、一般的なORマッパーだとしっくりこないし、不要な部分が多すぎる、ということで自作してしまっています。

その他のポイントとしては、設計は基本的にマイクロサービスを前提としているために、各サービスの分割レベルや役割の定義についてはチームで十分に議論をしながら進めています。

インフラ開発

インフラ関連はAWSをメインに使用しています。新しく開発する部分に関しては特段の理由が無い限り、はじめからマイクロサービスとして設計するようにしています。

アプリケーションの実行環境はコンテナ環境を前提としているため、 ECS(Fargate)になります。Localマシンでの開発環境も同様にDockerで開発できるような構成で進めています。

CI/CDは、CodePipeline上のCode BuildとCode Deployを使用しています。AWSの標準形を採用しているので、サードパーティ製のツールなどはあまり使用していません。サードパーティ製の便利なツールがたくさんあるとは思いますが、ツール選定の手間や、そのツールのアップデートやアップグレードに付き合っていかなければならないというオーバーヘッドがあります。このオーバーヘッドはAWSのツールを使っていても存在してしまいますが、謹製のものを使用した方がより安心できると言う観点から特段の事情が無い限りはAWSの標準の仕組み進めていき、もし何か手を加えたけれは自分たちでScript等を作成して対応していく、必要があればサードパーテイ製ツールを導入するという優先順位で進めていくこととしています。

DeployはBlue/Green Deploymentを採用しています。これはDeploy前の本番環境の検証を実行しやすい点、切り戻しが容易である点を考慮したためです。Rolling Updateの方がDeploy Processの実装自体は簡単なのですが、Deploy前後のプログラムの互換性を考慮しなければならない点と、問題が発生したときの切り戻しが難しいため Blue/Green Deploymentを選択しています。問題があってもあっという間に修正して、次のバージョンで対応するという常に前に進むことに対応できればRolling Updateも選べるかもしれません。

既存の Rails アプリケーションは、まだEC2で稼働しているものもあります。順次リファクタリングを行って、コンテナベースの環境へと移行していく予定です。

技術選定の基準はどうしているのか

一般論とそれほど違いはないと思いますが、OKANのシステム開発における選定基準として気にしている点を挙げておきます。

  1. 開発する目的に適しているか
  2. 中長期の開発に耐えられるか
  3. エンジニアが対応可能か
  4. 開発するために必要な情報が得られるか
  5. アップデートが適切に提供されるか
  6. 開発効率は良いか

1. 開発する目的に適しているか

モノリシックアーキテクチャで使えていた技術がそのままマイクロサービスで適用できるわけではありません。Node.jsはWeb APIを提供するには優れているとは思いますが、統計情報の計算やバッチ処理に適したものとは言えません。それぞれ実現したいことに適した技術や方法があります。技術の特性などに注意を払って適切に選択をする必要があります。

やりたい技術で選ぶこともモチベーションにつながるのはわかりますが、趣味でやっているわけではありません。プロとしてきちんと目的を達成できるようにするために、我慢が必要な場合もあります。

2. 中長期の開発に耐えられるか

最初に構築した技術のまま変更せず、最低限のパッチだけ適用して使い続けるという時代は終わりました。耐用年数が5年だから、5年間は何もせずに耐えるということはありえません。システムは生き物です。常に適切な状態に進化させ続けていく必要があります。そこで使う技術も中長期の使用に耐えうる技術を選択する必要があります。

その観点で考えた時、提供元が継続してその技術を提供し続けられる体制になっているかという点は重要です。とあるモジュールのコントリビュータが開発を継続していくことが困難でオーナーを別の人に託したら、知らないうちにそのモジュールがマルウエアに変わっていた、という話もよくあるようです。提供元の組織体制や身元などもできるだけ把握しておく方が安心です。

極端な破壊的変更を頻繁に行わない、あるいは行ったとしても後方互換性に対してできるだけ配慮しているかどうか、ということも考慮すべき要素です。その技術を提供している提供元のスタンスによりますが、破壊的な変更を厭わず積極的に前に進むポリシーを持っているようなところの技術を採用する場合は、それについていく覚悟が必要になります。

もう一つは、リリース計画などが明らかになっているという点です。いつLTSになるのか、いつサポートが終了するのか等の計画が事前に公開されているかどうかは、計画的に開発を進めていくにあたって考慮しておかなければならない要素となります。

3. エンジニアが対応可能か

PHPをメインにやっていたエンジニアに、コンパイルってなんですか? みたいなことを言われたことがありました。そのエンジニアはWebアプリの開発は普通にできていたし、サーバー関連の作業も十分こなしていましたので、Web開発という意味でのスキルは十分あったといえるでしょう。

とはいえ、そのようなエンジニアにとってGoやRustは特性が違いすぎるため、技術転換の難易度は高いと思われます。言語の設計が近しいものであれば、比較的に容易に移行できるでしょうが、エンジニアのスキル状況に配慮せずに技術を選定してしまうと、エンジニアが対応できるようになるまでに多大な時間を必要としてしまいます。

4. 開発するために必要な情報が得られるか

良さそうな技術があった場合でも、情報が無ければ利用するためのコストが跳ね上がってしまいます。APIの定義は書いてあるのだけどどのように動作するのかよくわからない、個別のAPIはわかるのだけど、どれをつなぎ合わせるとやりたいことができるのかわからない、といったレベルのドキュメントを良く見かけます。利用者は試行錯誤しながらコードを書くことになるため、開発コストが上がる原因となります。

また、原典に適切な解説がないために、なぜそうなっているのか、そのように動作するのか、ということがわからないこともよくあります。これは開発した成果物の品質に影響を与えます。提供元からの正しい情報提供ができているかどうかというポイントは品質確保という観点からも重要です。

5. アップデートが適切に提供されるか

アップデートという意味では、セキュリティ的な観点が最も重要です。問題が発見されたらタイムリーに新しいバージョンが提供されるかどうかは最も重要な要素の一つとなります。

機能的な観点での進化に関しては、提供元がどのようなポリシーで開発を進めていくかがわかっていれば良いでしょう。通常はより良い方向へ進化させていく方へベクトルが向いていくので、長い間放置されているようなものでなければ良いと思います。メインストリームの技術を選んでいる限りは、どれを選んでも同じような方向へ向かっていくのでそれほど大きな差異は生まれないはずです。

6. 開発効率は良いか

この項目は一番最後に挙げました。開発効率という観点でいうと、便利なライブラリや機能が揃っていることが効果的だと思われますが、それ以外の要素もあります。例えばGoなどでは言語体系自体が一種の開発ルールを定義しているとも言えます。このような言語を利用すれば、不要な議論をせずに開発に着手できるようになります。

とはいえ、開発効率で最も重要な要素は、その技術への慣れです。C言語であっても、それに慣れているエンジニアであれば、どんな言語よりも速く書けるでしょう。ここで大事なことは、極端に開発効率が悪いものではないことを適切に評価・判断できていれば良いと思います。

技術スタックは移り変わるが本質は変わらない

ここまで、OKANで使用している技術スタックとその選定基準について説明してきました。Web開発では、複数の領域において様々な技術スキルが必要になるので昨今のエンジニアの皆さんは技術習得が大変なことかと思います。ただ、技術スタックは変わっていっても開発の本質的なところは変わりません。表面的な言語やツールの使い方だけ覚えて満足せずに、何が本質的で変わらないものなのか、表面的なものは何なのかなどを意識してエンジニアリング活動をしていけると良いと思います。

株式会社OKANでは一緒にはたらくメンバーを募集しています!

フルスタックエンジニア
自社プロダクトで働き続けられる社会を作る!Webアプリ開発エンジニア
人材不足が叫ばれる中 果たして「出会い」だけに情熱を傾けて 出会ったあとの「働き続けられる組織づくり」を なおざりにしていいのでしょうか? 株式会社OKANは「働く毎日を豊かに」 をフィロソフィーに働き続けられる環境をつくります。 中でも職場で日常的に起こる問題に着目しソリューションを提供しています。 例えば、ぷち社食サービス「オフィスおかん」。 からだにいいお惣菜を安価に提供することで健康的で働き続けやすく。 お惣菜を持ち帰れるので家庭と仕事の両立を助けて働き続けやすく。 ぷち社食のまわりでコミュニケーションが生まれ働き続けやすく。 様々な問題を解決することで多くの会社さまに導入していただいております。 今後は社食以外のアプローチでも 働く毎日に起こる問題を解決し 働き続けられる環境をつくります。 働くの「つづく」を「つくる」、日本のおかんのような企業に
株式会社OKAN
プロジェクトマネージャー
あのオフィスおかんをデジタル化する!? プロジェクトマネージャーを募集
人材不足が叫ばれる中 果たして「出会い」だけに情熱を傾けて 出会ったあとの「働き続けられる組織づくり」を なおざりにしていいのでしょうか? 株式会社OKANは「働く毎日を豊かに」 をフィロソフィーに働き続けられる環境をつくります。 中でも職場で日常的に起こる問題に着目しソリューションを提供しています。 例えば、ぷち社食サービス「オフィスおかん」。 からだにいいお惣菜を安価に提供することで健康的で働き続けやすく。 お惣菜を持ち帰れるので家庭と仕事の両立を助けて働き続けやすく。 ぷち社食のまわりでコミュニケーションが生まれ働き続けやすく。 様々な問題を解決することで多くの会社さまに導入していただいております。 今後は社食以外のアプローチでも 働く毎日に起こる問題を解決し 働き続けられる環境をつくります。 働くの「つづく」を「つくる」、日本のおかんのような企業に
株式会社OKAN
株式会社OKANでは一緒に働く仲間を募集しています
22 いいね!
22 いいね!
同じタグの記事
今週のランキング
株式会社OKANからお誘い
この話題に共感したら、メンバーと話してみませんか?