[セッションレポート]AWS-12 プロトタイピングのススメ ― 手早くサービスを作って検証するための実践的ノウハウ #AWSSummit

お疲れさまです。とーちです。 4/20〜4/21 に開催されている AWS Summit 2023 に参加しています。
AWS Summit 2023 のセッション「プロトタイピングのススメ ― 手早くサービスを作って検証するための実践的ノウハウ」に参加したのでレポートをお届けします。

セッション視聴

AWS Summit Tokyoの登録を行うことでオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です。）

登録済みの場合、以下から直接遷移できます。

• https://jpsummit.awsevents.com/public/session/view/531

セッション概要

【スピーカー】

アマゾン ウェブ サービス ジャパン合同会社 デジタルトランスフォーメーション本部 プロトタイピングエンジニア

友岡 雅志

【概要】

目まぐるしく新たなサービスが生まれては消え、ユーザーの需要自体が漠然としている昨今では、サービスの素案をいかに素早く実現し仮説検証するかが特に重要です。このために役立つのがプロトタイピングで、アイデアの検証に必要最小限の機能を最短の手数でサービスとして実装し、検証の高速なイテレーションに貢献します。このセッションでは、お客様のプロトタイピング活動を日々支援する AWS Japan のプロトタイピングエンジニアから、AWS を活用して効果的なプロトタイピングを実現するための様々なノウハウをお伝えします。内容はビジネス要件・アーキテクチャを検討する際の抽象的な段階から、プロトタイプを実装する際の具体的な話にも及びます。

セッション内容

概要

• 本日の内容
  • プロトタイピングを効率的に行うノウハウ
  • 業界によらない普遍的に役立つ知識
• プロトタイピングとは
  • プロトタイプを作る営み、開発活動のこと
  • プロトタイプとは？
    • プロダクトの段階は以下のとおり
      • Demo：ときにはコードすら伴わないサービス実用性を示す最低限のシステム
      • Prototype：最重要のスコープに絞って短期間で検証を行う　 ← コレのこと
      • パイロット及びプロダクション：リリースして実際にユーザがついたフェーズ
  • プロトタイピングは必ずしも新規開発フェーズに限ったものではない
• プロダクト作成の悩み
  • 満を持して実装したが全然期待通りに動かない
  • FailFast という考え方
    • 早い段階で問題を見出して失敗したほうが軽傷で済み、失敗を次に活かすことができるという考え方
• プロトタイピングが生む悩み
  • 思いの外、早く進まない
  • AWS サービスは抽象度が低いのはいいが、プロトタイプで雑に動かしたいというニーズには向いているのかという話
• 一般的なプロトタイピングのフェーズ
  • 要件定義
  • アーキテクティング（設計）
  • ビルディング（コーディング）
  • その後
  • 本日のアジェンダはこれに沿った形

要件定義

• プロトタイピングの目的は？
  • まずは目的を明確にしてチームで合意しよう
  • チームで共通認識をもつことが大事
  • なぜプロトタイピングを作るのか
    • なんらかの検証したい項目があるから
    • なにを検証したいのか
      • どういうユーザ体験になるのか
      • 実際に使えるのか
    • 項目ごとに優先度を決めておくとなおよし
  • なぜ明確にするか
    • 後の意思決定が明確になるから
• プロトタイプの形を明らかにする
  • 各人が思い描くプロトタイプは異なるので共通認識を作ろう
  • 方法はいくつかあるが大事なのは
    • お互いに質問を重ねること
    • それによってすり合わせて形を明らかにする
    • 明確にする余地がある部分をうやむやにしないことが大事
• 目的から開発スコープが決まる
  • 目的に対して最小限の開発スコープを定めるのが大事
    • スコープを広げるほど検証開始が遅くなる
      • 遅くなることがチームとしてのデメリットになってくる

アーキテクティング（設計）

• かっこいいアーキテクチャ禁止
• たくさんの意思決定が必要
  • 例えばコンピューティングリソースをどうするか（lambda or ecs or ec2）
  • 他にも色々な意思決定が必要
• プロトタイピングにおいては不要な複雑化をしないのがコツ
  • シンプルの定義
    • 一般的にはチームにとって認知負荷が低いもの
    • そのチームが考えるシンプルな状態に保つこと
• 作っていくと自然と複雑な方向に転がりがち
  • なので、阻止する力を加える
    • 要件の見直し（本当に強力な整合性が必要？結果整合性でよくないか？）
    • 目的の再確認（今その機能が本当に必要？）
    • 指向のバイアスの排除（実はもっとシンプルなものがあるかも？）
• アンチパターン
  • 先読みしすぎた技術選定
  • 早すぎる最適化（例えばプロトタイピングの段階なのに Lambda のコールドスタートを早くするのに頑張ってしまうとか）
  • かっこいいパターンをとりあえず導入（例えばマイクロサービスをとりあえず導入）
    • マイクロサービスが悪いと言っているわけではない。プロトタイピングの目的に沿うのであればやるべき。
    • 課題意識がないのにとりあえずかっこよさげなの導入するのが良くないということ
• まずはシンプルなところから
  • 必要性が見えたときに最低限の複雑化
  • それを繰り返す
  • 必要に応じて大域的な複雑化（リファクタリング）
  • 結果として必要十分に複雑な状態になるようにする

ビルディング（コーディング）

• AWS サービスの抽象度をあげる

• AWS の特徴

  • ビルディングブロック
  • 非常に細やかに設定できる＝抽象度が低いということ
• プロトタイピングでとりあえず動けばいいというフェーズでは、より便利にやる方法がある
  • その方法とは → 抽象度をあげるようにする
    • 学習、構築コストが下がる
  • 個々のリソースではなくパターンとして抽象化する
    • これを実現する方法＝ CDK
      • 色々機能があるがプロトタイピングにおいては抽象化機能が活きてくる
      • IAM とかバケットポリシーとか気にせずともコード数行でリソース作成できる
• CDK で抽象度の階段を自由にいききする
  • 抽象度が高いほど生産性があがる
  • 抽象度が低いほど柔軟性があがる
  • CDK には３層の抽象度がある
    • L1：CloudFormation リソースと１:１で対応
    • L2：一般ユースケースの抽象化
    • L3：特定ユースケースの抽象化
  • L2 コンストラクトの EC2 インスタンスを使った抽象度の階段登り降りの例
    • L2 コンストラクトでは一見変更できないようなプロパティがある
    • L2 では一見できないことも L1 層に降りることができる
      • ※筆者注：例えば以下のような方法
        • AWS CDK（TypeScript）の L2 Construct で設定できないプロパティを設定する方法 | DevelopersIO
  • CDK なら生産性と柔軟性の両取りが可能
• どこまでプロトタイピングのクオリティを高めるか？
  • カバレッジ１００％？CI/CD 完備？
    • プロトタイピングにおいては不要かも。プロトタイピングに決めた目的に沿うべき
    • プロトタイピングと完璧主義の相性はよくない
      • プロトタイピングでは実装そのものより検証結果に価値があるため
  • 完璧を目指すのではなく、より下げた場所を目標にする
    • ただしスピード最優先も悪手になりがちなので注意
    • スピードとクオリティのバランスのいいところでやるのが大事
  • トレードオフ、投資対効果を考える
    • 巷にはいろいろなベストプラクティスがある
    • ベストプラクティスを完璧にやろうとするとスピードは落ちる
    • それぞれのベストプラクティスについてトレードオフを考える
    • メリットを教授できないほど短命なプロトタイプもある
  • 技術的負債
    • （プロトタイピングでは）完璧を目指す、ベストプラクティス踏襲は常に最善ではない
    • しかし、ベストプラクティスに背いたゆえに将来それの是正をせまられることもある
    • プロトタイプの目的に沿えば、負債が理にかなうこともある
    • 今、現時点でみて、将来負債となるかは不確実
    • 上記のことから、技術的負債＝必ずしも悪と捉えないようにすること

その後（爪をとぐことの重要さ）

• プロトタイピングの成功は経験がものをいう
  • 意思決定を素早く行いつつも、自信をもって行う必要があるから
  • 説得性のある根拠＝根拠は知識によってもたらされる。知識は経験によってもたらされる。
  • 成功するプロトタイピングのためにはある程度経験が必要
    • どうやって経験をつむか
      • プレプロトタイプ活動
        • いままで使ったことのない技術で簡単なアプリを作ってみる
        • CloudFormation,Terraform,CDK で同じ構成を書いてみる
        • 上記によりやったことあるを積み重ねる
      • クロージングレビュー
        • 個々の案件で得られた知見を共有する会
          • 例えば新しい技術をためしてみた際の共有とか
          • 例えば新しいプロジェクトの進め方でやってみた際の共有とか
        • えられた教訓をチーム内で共有する
        • 一つのプロジェクトで閉じずにより大きなフィードバックループを作る
• 但し書き
  • 色々言ったが、とりあえずやってみるのが最強
    • 初期フェーズでの失敗は取り返しがききやすい
  • なのでまずとりあえずやってみる
  • まずはやってみて経験をつむ、これがスタート
• まとめ
  • プロトタイピングで早期に問題に気づく
    • FailFast の手段として活用
  • 抽象化が高速なプロトタイピングの鍵
    • 早く進めたいときは抽象化して実現＝ CDK
  • 経験こそ成功の礎
    • 「とりあえず試してみる」の心がけをもつ
• call to action
  • このあとなにするか
    • あなたの関わっているプロジェクトでより FailFast なアプローチを取り入れられないかチームで議論する
    • ベストプラクティスのトレードオフ表をチームの状況に沿って埋めてみる
      • トレードオフ表の列：ベストプラクティス名、導入コスト、運用コスト、導入しないリスク、導入によるリターン、リスク・リターンが顕出する状況・時期
      • ベストプラクティスの項目（行）：デプロイの自動化、Linter/Formatter,Infrastructure as Code
• 関連セッション
  • AWS-11 MVP から始める、ビジネスのスケールに連動したアーキテクチャの遷移について
• AWS JP Prototyping チームのブログ
  • Prototyping Blog | Prototyping Blog

感想

なんというかすごく前向きな気持ちになれるセッションで良かったです。
FailFast の考え方は、弊社の中でも繰り返し伝えられている概念ですし、「とりあえず試してみる」についても弊社のCLPの「やってみる」に通じるものがありますので、今回のセッションを聞いたことで、こういった考え方が大事なんだということをより実感することができました。

私自身も案件の中でプロトタイプのようなものを作ってお客様にご提示する機会はあるので、このセッションのやり方を取り入れていこうと思いました。

以上、とーちでした。