2024.12.01
こんにちは、システム部の五十嵐です。
今回はWebアプリケーションを開発する際の技術選定について、弊社でも取り入れている実践的な1つの考え方を紹介します。尚、ここで言う技術選定とは
- プログラミング言語
- フレームワーク
- ライブラリ
- XaaS
- 設計思想
などを取り決める作業を指します。またこの考え方はさまざまなジャンルのアプリケーションに適用できると思いますが、弊社では主にWebアプリケーション開発における技術選定で取り入れているものであり、今回のスコープとしても一応Webアプリケーションに絞っています。あらかじめご了承ください。
技術選定にベストプラクティスはない
まず最初にアプリケーション開発における技術選定にベストプラクティスは存在しない、という共通認識を持つところが今回のスタートです。敢えて言うほどのことでもなく「当たり前じゃん」と思う方も多いとは思いますが、何事にも前提というのは大切なので。
ではなぜベストプラクティスがないのか、少し掘り下げましょう。理由はいくつかありますが、一番大きいモノとしては諸々の事情でアプリケーションに求められる役割は変質するからです。アプリケーションというのはさまざまな理由で当初想定していたものとは異なる役割を担わされることがあります。例えば
- 社内でのみ利用していた在庫管理システムを、社外の商品納入企業も利用できるように改修する必要が生じた。
- イントラネット外との通信を行わなず、ユーザーも社内の少人数という前提があったので、各種脆弱性に対応するようなアーキテクチャ構成になっていない。
- 日に10,000件のアクセスを捌ければよい程度の小規模ECサイトで、某人気メーカーの商品を独占販売することになった。
- 大量のアクセスや注文データ保持といった性能要求を想定したアーキテクチャ構成になっていない。
などです。これに対して「最初からそういう拡張性を想定した技術選定こそがベストプラクティスである!(ドヤァ」とはもちろん言えませんね。今必要な規模に応じた適切なコスト、という観点も選定では必要となりますので。
他にもWebエンジニアの方であれば痛いほど理解しているとは思いますが、Webアプリケーション開発を取り巻く技術要素の進歩が目まぐるしいというのも理由の1つです。日々新しいツールや概念が登場し、ようやくキャッチアップできたと思っていたものも、知らぬ間にどんどんアップデートされていきます。
例えば私がエンジニアを始めた2012年当時、Webアプリケーション開発といえばApache StrutsやRuby on RailsなどのリッチなMVCフレームワーク上で、モノシリックなアプリケーションを構築するというスタイルが主流でした。しかしそれから10年近く経った2021年現在、この日進月歩の流れを受けてWebアプリケーションを取り巻く状況は一変しました。マイクロサービスアーキテクチャの普及によってサービス単位・モジュール単位で「小さいアプリケーション」を作る考え方が主流に。より細かい観点で見るとフロントサイドはフロントサイドに特化したJavaScriptフレームワーク(React、Vue.jsなど)で開発し、サーバーサイドはサーバーレスアーキテクチャの実行環境(AWS Lambda、Firebaseなど)上で動作するプログラムを開発するケースが増えました。SPA(Single Page Application)という単語もWebエンジニアの中では完全に一般的になりましたね。
他にもCD/CIをサポートするサービスやIaaS上での監視サービスが充実したことによって、従来は分業・専業という意識の強かった開発チームと運用チームの間にDevOpsという概念が生まれたり、仮想化コンテナ技術の高度化により、開発・運用コストの削減や開発ライフサイクルのスピードアップなどが図れるようになりました。
このようにWebアプリケーション開発を取り巻く技術要素というのは日々進化を続けているため、数年前までデファクトスタンダートのように扱われていたものが今ではサポートも危うかったり、当時最新の技術として取り入れたものが気づけばアンチパターンになってしまっている、というようなことは往々にして起こります。その時代・そのタイミングのベストプラクティスだと思った技術でがっつり固めてしまうのではなく、必要に応じて必要な部分を置換できるような柔軟性が大切です(かなり理想論ですが)。
選定における評価指標
技術選定にベストプラクティスがないということを踏まえて、では我々はどのようにアプリケーションの技術選定をすべきか。何かを判断するためには必ずその判断の基準となる指標や基準値といったものが必要ですね。「なんとなくコレにしてみました」が許されるのは休日の個人開発か神クラスのハイパーエンジニアだけです。そしてその指標ですが「技術選定 アプリケーション」みたいなキーワードでググると、有意義な情報がたくさん出てきます。いい時代ですね。例えば下記のようなもの。
この記事がとてもわかりやすく、かつ詳しく書かれているので、ぶっちゃけコレ読んであとはTry Try!!で終わってしまう気もするんですが、さすがにそれでは私の人事評価に影響が出そうなので、やはり弊社のナレッジを踏まえた、より実践的な話をすることにしましょう。
小さく軽く、必要最小限に
一部は前述でお薦めした記事にも書いてありますが、技術選定時には
- サービス要件を満たしているか
- 経営戦略上のスケジュールを守れるか
- イニシャルコストが抑えられるか
- ランニングコストが抑えられるか
- 開発生産性が高いか
- 採用実績は十分か
- 継続的なサポートが受けられるか
- 採用技術の追加・変更を柔軟に行えるか
- etc..
のように検討・判断の基準となる指標がいくつも存在します。で、これらを満たしやすくする実践的なポイントは、より小さく、より軽いものを採用することです。マイクロサービスアーキテクチャと同じ考え方ですね。
例えばこんな感じのゆるふわサービス要件があるとしましょう。
- アニメーションとかパララックス的な動きが多い、ちょっとリッチなLPを3ページ分作りたい。
- 3ページはそれぞれ表示する商品名が異なるだけで、それ以外は全く同じ。
- 各ページのヘッダーレイアウトは共通。
- 今後も同じようなLPを作成するかもしれないし、しないかもしれない。
このときエンジニア的な感覚だと「Vue.js導入して共通部分をコンポーネント化して、各ページコンポーネントから商品名を渡して…」とか「ウチはAWS使ってるからCloudFront + S3だな!GitHubにPushしたらCodePipelineが動くようにして、CloudFrontのキャッシュをクリアするLambdaも噛ませて…」とか考えますよね。わかります。でも私はこの程度ならこんな構成にします。
- ピュアなHTML・CSS・JavaScript + jQueryと関連プラグイン
- Webエンジニアなら誰でもキャッチアップ期間なしで触れる。
- jQueryの採用実績を今更機にする必要もない。最悪ピュアなJavaScriptに書き換えることに大した手間はかからない。
- CSSとJSだけ共通にしておいてHTMLだけコピーして3ファイル作ればいい。別に3つ書き換えることになっても大した手間はかからない。
- 何より開発コストが低い。
- CloudFront + S3だけど手動運用でいい
- 頻繁なリリースがあるわけでもないし手動運用で十分。
- 何より構築コストが低い。
- ミニファイとかでgulpくらいつかうかも
- 余裕があるときに後からやればいい。
- なくても開発は困らない。
- やったところで大したコストにならない。
「今後も同じようなLPをどんどん作ることが決まったらどうするんだ!」って意見が出そうですが、そしたらその時にVue.jsでもなんでも導入すればいいです。共通のCSSとJSはそのまま再利用できますしね。少なくとも現状で3ページしか必要となっていないにもかかわらず、フレームワークやら自動デプロイの仕組みは感覚的にオーバースペックですし、上記の判断指標と照らし合わせてもNGとなるものが多いでしょう。
ただこれだとアプリケーション開発の技術選定というには心許ないので、もう一つ例を上げます。こんなサービス要件です。
- 既存顧客にキャンペーンメールを送りたい。
- キャンペーンは任意のタイミングで任意のものを送りたい。
- 運用担当者が管理画面からキャンペーン内容の設定、及び送信したい。
- メールの開封率や、メールに記載したLPのアクセス数など、効果計測も実施したい。
これまたエンジニア的な感覚だと「管理画面と送信系のバッチは別モジュールにすべきか…」とか「さすがにLPのアクセス数はGAで取るとして、メールの開封率はWebビーコンか…?」とか考え始めてしまいがちです。しかしこれも、「より小さく、より軽く」と考えるのであれば
- 既存のキャンペーン配信SaaSを利用する
- 既存顧客のデータ連携部分だけシステム化する
- 単純な情報連携バッチだから社内で一番使ってるRubyのピュアなスクリプトでいいかな。
- 単純なスクリプトなら、やっぱりリリースも手作業で十分かな。
あたりが判断指標を最適に満たすのではないでしょうか。「SaaSを利用するのは技術選定なのか」というツッコミが上がりそうですが、それはIaaSにAWSを採用するのかGCPを採用するのか、はたまたIaaSじゃなくてオンプレでいくのかというような選定の延長だと考えています。また、もちろん細かく要件定義していくとSaaSでは対応できないことがいくつも出てくる可能性があるので、その時にはその要件を取るか、コストやスケジュールを取るかという判断が必要になります。
おわりに
これを書き始めた段階では、弊社での実例と共に「このケースではどのように技術選定を行ったか」を書くつもりだったんですが、よくよく考えたらあまりオープンにできないネタが多く、結構抽象的な投稿になってしまいました。次回はもう少し具体的な話ができたらいいですね(他人事)。