M3 USA 出張記 #4: SaaSを比較する際の高速なプロトタイプ作成Tips

エンジニアの冨岡(@jooohn)です。先週からUSにて合流した笹川とルームメイトになりました。週末は一緒にグランドセントラル駅やMoMAなどに行き、二人でさらにニューヨーカー感を高めてきました。

f:id:jooohn:20181105080451j:plain — Jackson Pollock の絵の前で満面の笑みを浮かべる笹川

f:id:jooohn:20181105072403j:plain — ティファニー本店の前でサラダの入った紙袋を持つ冨岡

f:id:jooohn:20181105072628j:plain — そもそも量が多すぎるサラダ

さて、USに来てからは、大きくMDLinxで今後使用するCMSの選定を行ってきました。

www.m3tech.blog

この選定の際に、各候補ごとのプロトタイプを作ること、見せることが以下の点で重要な判断材料になったりします。

APIのケイパビリティ、開発者としての使用感を確かめる
CMSを使って記事を作成する際の一気通貫の体験を確かめる

特に、今回は以前の記事で紹介したように、HTMLの代わりにstructuredなデータを生成し、それをHTMLに整形する、ということも行われそうです。エンジニアであれば「これはフロントエンドの実装しだいでどうにでもなるな」とわかっても、記事を書くライターにそれを理解しろというのも酷な話なので、実際に動くプロトタイプを見せることが肝要です。

この際かなり開発工数を抑えて、かつそれなりに綺麗に各候補のプロトタイプを実現できたと思ったので、いくつかTipsを紹介します。

サービスごとの差分はインターフェースと実装の関係で表現

各CMSで作成した記事を表示するプロトタイプを作っていますが、アプリケーションにとっては、裏側で動いているのがContentfulだろうがContentStackだろうが、自前のバックエンドサーバーだろうが関係がないはずです。

アプリケーションは「記事をとってくる手段」がなんであれ行う仕事があり、「記事をとってくる手段」の実体がContentfulであり、ContentStackであるわけです。これはインターフェースと実装の関係のようです。

f:id:jooohn:20181104013412p:plain

Clean Architectureのエッセンスを拝借し、アプリケーションからは抽象に依存するようにし、具体的な実現方法を注入するようにします。たとえ実装がContentful/ContentStackのようないずれか一つに決まったとしても、抽象に依存するように層をわけることはメリットがあると思います。今回のように候補が複数ある場合はメリットがより顕著ですね。検討サービスが増えた際にもプロトタイプを簡単に増やせそうです。

TypeScriptでインターフェースを明示

今回、こういった依存関係をはっきりさせるためにTypeScriptを採用しました。

f:id:jooohn:20181104073939p:plain — 実装イメージ

記事の型（Article）と、それを取得するインターフェース（CmsService）を定義しています。各サービスではこの型に合うように実装するようにし、サービスごとの微妙なインターフェースの差異をここで調整します。Articleの本文であるRichTextは、各サービスによって表現方法が大きく異なると思いますが、これも中間の表現として共通の型を用意しました。

f:id:jooohn:20181104075333p:plain — ContentfulのCmsService実装イメージ

型に合わせてCmsServiceを実装することに集中すれば良いので、各サービスごとのプロトタイプ作成が容易で、しかも独立しています。例えば今回は私がContentfulを、矢崎がContentStackの実装を行いました。このようなケースでは静的型がとてもよくマッチしますね。

なおReactを用いてプロトタイプを実装したのですが、ちょうどタイミングよくcreate-react-appがTypeScriptサポートをしたので、Reactを使っている場合は導入ハードルが下がっています。

Create React App 2.1 (with TypeScript support) is now available! Read the release notes to get started: https://t.co/3TbHvDkNCc @typescriptlang
— Joe Haddad 🎃 👻 (@timer150) October 30, 2018

プロトタイプの共有にはホスティングサービスの無料枠が便利

作ったプロトタイプを見せるためにローカルのPCの画面を共有するということもできますが、web上に公開されていると誰でもどこでも閲覧できて便利です。

Web APIを提供している各サービスを比較する場合、フロントエンドからそれを利用すればいいことになるので、.jsといった静的ファイルをデプロイすれば他チームメンバーと簡単に共有することができます。

静的ファイルのホスティングは選択肢が柔軟で、以前の記事で紹介されたように、S3/CloudFrontといったAWSのサービスを利用することもできますし、プロトタイプが目的であれば各ホスティングサービスの無料枠でも十分でしょう。

これらはGithubとの連携も充実しているので、特に何も考えずにCDパイプラインが実現できてしまうのも魅力です。

プロトタイプの場合、confidentialな情報が含まれていることはほとんどないので、世の中の便利なサービスを雑に使えて便利ですね。

まとめ

いくつかのSaaSを用いたプロトタイプを作成する際に、実施してよかったことを紹介しました。動くものをサッと作って意思決定を強力にサポートできるのはエンジニアの強みですね。TypeScriptを用いたり適度に抽象化することで、サッと作る際にも作業を分割できるなどのメリットがあります。プロトタイプの実装がなんやかんやでそのまま本番で使われる・・・ということも往々にしてあるので、プロトタイプと言えども節度を持って実装することをおすすめします。