TECH NOWシステム開発
こんにちは、システム部の五十嵐です。
今回はWebアプリケーションを開発する際の技術選定について、弊社でも取り入れている実践的な1つの考え方を紹介します。尚、ここで言う技術選定とは
などを取り決める作業を指します。またこの考え方はさまざまなジャンルのアプリケーションに適用できると思いますが、弊社では主にWebアプリケーション開発における技術選定で取り入れているものであり、今回のスコープとしても一応Webアプリケーションに絞っています。あらかじめご了承ください。
まず最初にアプリケーション開発における技術選定にベストプラクティスは存在しない、という共通認識を持つところが今回のスタートです。敢えて言うほどのことでもなく「当たり前じゃん」と思う方も多いとは思いますが、何事にも前提というのは大切なので。
ではなぜベストプラクティスがないのか、少し掘り下げましょう。理由はいくつかありますが、一番大きいモノとしては諸々の事情でアプリケーションに求められる役割は変質するからです。アプリケーションというのはさまざまな理由で当初想定していたものとは異なる役割を担わされることがあります。例えば
などです。これに対して「最初からそういう拡張性を想定した技術選定こそがベストプラクティスである!(ドヤァ」とはもちろん言えませんね。今必要な規模に応じた適切なコスト、という観点も選定では必要となりますので。
他にも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!!で終わってしまう気もするんですが、さすがにそれでは私の人事評価に影響が出そうなので、やはり弊社のナレッジを踏まえた、より実践的な話をすることにしましょう。
一部は前述でお薦めした記事にも書いてありますが、技術選定時には
のように検討・判断の基準となる指標がいくつも存在します。で、これらを満たしやすくする実践的なポイントは、より小さく、より軽いものを採用することです。マイクロサービスアーキテクチャと同じ考え方ですね。
例えばこんな感じのゆるふわサービス要件があるとしましょう。
このときエンジニア的な感覚だと「Vue.js導入して共通部分をコンポーネント化して、各ページコンポーネントから商品名を渡して…」とか「ウチはAWS使ってるからCloudFront + S3だな!GitHubにPushしたらCodePipelineが動くようにして、CloudFrontのキャッシュをクリアするLambdaも噛ませて…」とか考えますよね。わかります。でも私はこの程度ならこんな構成にします。
「今後も同じようなLPをどんどん作ることが決まったらどうするんだ!」って意見が出そうですが、そしたらその時にVue.jsでもなんでも導入すればいいです。共通のCSSとJSはそのまま再利用できますしね。少なくとも現状で3ページしか必要となっていないにもかかわらず、フレームワークやら自動デプロイの仕組みは感覚的にオーバースペックですし、上記の判断指標と照らし合わせてもNGとなるものが多いでしょう。
ただこれだとアプリケーション開発の技術選定というには心許ないので、もう一つ例を上げます。こんなサービス要件です。
これまたエンジニア的な感覚だと「管理画面と送信系のバッチは別モジュールにすべきか…」とか「さすがにLPのアクセス数はGAで取るとして、メールの開封率はWebビーコンか…?」とか考え始めてしまいがちです。しかしこれも、「より小さく、より軽く」と考えるのであれば
あたりが判断指標を最適に満たすのではないでしょうか。「SaaSを利用するのは技術選定なのか」というツッコミが上がりそうですが、それはIaaSにAWSを採用するのかGCPを採用するのか、はたまたIaaSじゃなくてオンプレでいくのかというような選定の延長だと考えています。また、もちろん細かく要件定義していくとSaaSでは対応できないことがいくつも出てくる可能性があるので、その時にはその要件を取るか、コストやスケジュールを取るかという判断が必要になります。
これを書き始めた段階では、弊社での実例と共に「このケースではどのように技術選定を行ったか」を書くつもりだったんですが、よくよく考えたらあまりオープンにできないネタが多く、結構抽象的な投稿になってしまいました。次回はもう少し具体的な話ができたらいいですね(他人事)。