大森氏の自己紹介
大森亮氏（以下、大森）：それでは始めます。タイトルは「失敗と成功から学ぶ技術選定」ということで、主に個々の技術の話になってしまいますが、お話しします。株式会社YoiiのCTOの大森亮と申します。「Not confidential」ということで、スクショやシェアもOKです。
まず簡単に自己紹介からします。（スライドを示して）ここに書いてあるとおりではありますが、1個前にブロックチェーンの会社にいて、そこがエンジニアとしてのファーストキャリアとなっています。
そこでエンジニアとしてスタートして2年ほどいて、OSSの開発とかもやっていたんですが、（その後に）そのブロックチェーンの会社にいたCTOと一緒に株式会社Yoiiを立ち上げた状況です。
株式会社Yoiiの事業と組織概要の紹介
ではまず、スライドの理解度が深まるので、弊社の事業概要について説明します。
設立は、ちょうど2年ほど前です。事業内容は、SaaS、D2C、サブスク企業の経営者とかが対象ですが、（企業の）資金調達をサポートするところを（実施しています）。融資でも投資でもない、売上予測を基にした新しい資金調達を提供しています。法律用語で言うと「将来債権の譲渡」になります。
あとは審査申請。資金調達の申請をオンラインで完結できるところと、銀行とかだと1ヶ月はかかってしまう結果を6営業日以内（に返すことで）ですぐに返ってくることを価値として置いて開発を進めています。（スライドを示して）画面の右下にある、このようなものを作っています。
組織概要ですね。今は正社員が13名で、そのプロダクト開発に関わっているチームが8名という状態です。（スライドを示して）このスライドではあまり関係ないんですが、この8名は全員海外出身なので、社内の公用語として英語で開発を行っています。
人数構成はソフトウェアエンジニアが3名、データサイエンティスト、データアナリストが1名ずつ、プロダクトマネージャーが2名。こちらは顧客側 の画面と、データサイエンスプロジェクト（の画面）という感じに分かれていて、デザイナーが1名。ほかに業務委託のエンジニアが4名。このような構成で、比較的少人数となっています。
会社の歴史はいろいろと書いてあるのですが、この中で言いたいのは、まずスライドの緑になっているところですね。今は正社員が13人ですが、正社員が初めて入ったのはちょうど1年前の2022年3月頃。ここから1年で13人に増えたので、それまではほぼ1人プラス業務委託何名かの、かなり少人数で開発をしていた状況でした。
また、2021年4月。（スライドの）左のほうに書いてありますが、Closed βのリリースを創業直後ぐらいに行いました。
プロダクトのWho・When
もう1個背景として説明したほうがいいものが、弊社のプロダクトの性質です。技術選定の仕方とか開発マネジメントの仕方って、そのチームの性質やプロダクトの性質によって大きく変わってくると思うので、弊社の場合はどうかをまず共有します。 性質が違うと使うべき技術選定の考え方も変わってくるので、「ここは私たちと違うな」と思ったら、あまり参考にしないでもらいたいです。
「Who」というところですが、弊社のお客さまはスタートアップ、SaaS、D2Cなどの経営者、財務担当者です。
「When」がけっこう限定されていて、「資金調達したいな」と思った時、あるいは「今調達するとしたらいくらできるんだろう」というような見積もりが欲しい時です。なので、毎日張り付きで使うようなプロダクトではない状態です。
どのようにプロダクトを使うのかですが、会社の財務情報や本人確認情報などを提出したり、あとは「freee」「Stripe」などの会計ソフトや決済ソフトをAPI連携したりという使い方をします。
こういう性質を踏まえた時に、弊社のプロダクトにとって重要なことと重要じゃないことが出てきました。重要なことは、まずお客さまの情報管理をしっかりするというところです。会社の財務情報はセンシティブな情報がけっこうあるので、情報漏洩をしないことが一番大事です。
あと、審査のためのUI/UXのわかりやすさと、柔軟な機能追加。追加で「やはりこれを審査で聞きたい」となったら、柔軟にその項目を追加できたりですね。
あまり重要ではないことなんですが、システムのスケーラビリティですね。そもそもアクティブユーザーが多くなくて、事業を拡大しても増えにくいというところで、そこをあまり強くする、意識する必要がないようなプロダクトです。
また、ダウンタイムもかなり許容できるようなプロダクトです。例えば深夜や夜、土日とかに（サービスが）落ちていても、そこまで影響は大きくないようなプロダクトとなっています。
初期の技術選定をどのように行ったか
という経緯を踏まえて、まず初期の技術選定をどのように行ったかという具体的な話をします。開発フレームワークとして、AWS Amplifyを使用しました。
最初にMVPを作るという意味では、かなりスピード感を持って作れたなと思っています。AWS Amplify内での構成としては、GraphQLサーバーを使い、Cognitoでユーザー認証をするような状況でした。（スライドを示して）緑で書いているんですが、言語としてはGoを採用して、Domain-Driven Design構成で書いていました。
マイクロサービスとかが流行っていると思いますが、弊社はフロントエンド、バックエンドをモノリス、1つのレポジトリでやっています。
売上データをアップロードしてグラフを表示するUIを開発して提供しました。やはりスピード感が大事なので、審査の申し込みフォームとかはサイトを作り込まずにGoogleフォームで代用していました。
技術的負債の解消のために実施したこと
ただ、Amplifyを使用したものの、結局は技術（的）負債が起きてしまって。それを解消したというところで、まずは失敗談に近いことからお話しいたします。
まず、AmplifyのバックエンドからTerraformへの移行を行いました。なぜ行ったかですが、Amplifyについては、最初にプロダクトを作る、MVPレベルを作るという意味では良かったんですが、まだ新しめのフレームワークで後方互換性のないアップデートがけっこう発生して、それに対応しないといけなかったり。
あと、Amplifyって、DynamoDBとかLambdaとかは1コマンドで追加できるんですが、それ以外のものを追加するには、「結局CloudFormationをベタ書きするほうが楽なんじゃないか」というぐらい複雑な設定が必要で、それに対するドキュメントも少なかったというところがあります。
単純にTerraformを使ってみたかったというのも重なってはいたんですが、そういう経緯があって、カスタムリソースが増えていくにつれて移行する必要性を感じてきました。
どのようにして行ったかなんですが、いったんTerraformで管理するところだけにリソースを置いて、リソースの処理を変えたりせず、Terraformで管理するようにしました。
Amplifyにはフロントエンドのホスティング機能がついているんですが、そちらは移行しませんでした。それでもやはり3人月ほどかかってしまったというところですね。
ちょっと時間もアレなので、簡単にですが（説明します）。ユーザー基盤の移行に意外と時間がかかりました。
どういうことかというと、1ユーザー1組織だったところを、1つの組織の中に複数のユーザーという構造に変更したことによって、オブジェクトの所有がユーザー単位から組織単位になってしまって。ここはかなり時間がかかってしまったところです。
2度目の移行は、（もともと）DynamoDBを使っていたところを、やはりJoinが複雑だからRDS（Relational Database Service）に移行したというものです。これ（の実施期間）が1週間程度で、けっこう楽にできたのは良かったと思います。
なんで良かったのかは、Domain-Driven Designを採用していたことが功を奏したのかなと思っています。ユーザー基盤の責務がコード上でかなり切り出されていて、そこだけを変えれば良くて。ユニットテストとかも容易に行えたので、移行コストが低かったです。
あとはAPIデータダウンロード処理。、LambdaをFargateに移行したり、あとはできるだけ「Fivetran」などの便利なSaaSを用いようと（したと）いう話ですね。ちょっと軽く飛ばします。
まだ取り組んでいないこと
逆に、取り組んでいないこともいくつもあります。その中でピックアップすると、マイクロサービス化は現在のところまだ取り組んでいません。
まだ正社員が入ってから1年というのもあるし、現状のサービスの数やメンバーの数を踏まえると、今マイクロサービス化してしまうと、逆に開発スピードが遅くなってしまうよなという判断をしています。
例えば、フロントエンドとバックエンドの両方にまたがるようなプルリクエストなどがやりづらかったり。今はまだ柔軟な開発がやはり重要な時期なので（そのままにしていますが）、そのようなプルリクが（現状）多数発生していて、これからやりにくくなってしまうなと感じています。 一方で、ソースコードレベルではDDD（Domain-Driven Design）で責務が分離してできていて、将来的な分離とかリファクタはしやすいような状況にはなっているかなと思います。
Cognitoを移行ですね。これはやはり弊社のセキュリティレベルや運用のルールとかがかなりかっちりしないとできないと思っています。
あと、パスワード管理はかなりセンシティブなところなので。もちろんCognito独自の詰まりどころはあるんですが、それよりもパスワード管理をAWSへ移譲できるメリットは大きいなと感じていました。
技術的負債解消をする時の考え方
技術的負債の解消の考え方で、「取り返しがつきやすいか？ 難しいことか？」みたいな話があると思います。
取り返しがつくことというのは最初はそんなに気にしなくてよくて、ソースコードのリファクタリングや自動化ツールの導入。CIなんて後からいくらでも導入できます。
逆に取り返しが難しいのはデータの不足ですね。取っていなかったデータを後から見ることはできないし、消えてしまったデータも戻らないので、バックアップをちゃんと取るということです。
あとはユニットテストの導入。これはやはり後から書くのが面倒だからです。Test-Driven開発というか、その時に書くのが一番いいです。ユーザー基盤周りの実装はやはりやってみると意外と大変だったというところですね。
ほかには、（Chat）GPT先生に聞いてみたというところで。一般的な質問をしてみたら「（ChatGPTの回答が）抽象的でよくわからない」となって、Amplifyに絞った質問をしてみたら、もうちょっと具体的（な回答）が出てきました。これはGPT-3.5を使いました。
GPT-4に「マイクロサービスを導入すべきか」を聞いてみました。（Chat）GPTを使う時に重要なのは、背景をちゃんと説明することかなと思います。
（スライドを示して）このように聞いてみたら「マイクロサービスの管理に必要な技術力や人員が十分にそろっているか検討が必要です」と言われたので、もしかしたらまだちょっと早いのかなという気はしています。 DevOpsやコンテナ技術などのスキルも、ちょっとまだ不十分な気がしていて。ここは採用とともに進めていく感じかなと考えています。
使ってよかった技術・使って後悔した技術
技術選定の振り返りとして、使って良かった技術はAmplifyですね。CI/CDを簡単に構築できてスピード感を持って開発できたし、開発者ごとの環境構築が楽にできました。
AppSyncとCognitoは、GraphQL APIの認証処理を丸投げできたので良かったです。DDDはユニットテストの導入もスムーズだったし、ユーザー基盤の移行とかもスムーズにできたのが良かったです。
あと、これはあまり紹介していないんですが、弊社はデータエンジニアも採用・募集していて。（必要スキルは）「Snowflake＋DBT（Data Build Tool）」となっていますが、こちらも非常に使い勝手が良いです。
使って後悔した技術です。これはAmplify。使って良かった（もの）と被っているんですが、Amplifyが対応していないインフラを扱うあたりから苦しくなってきました。でも不便でも使い続けてしまって、後からの改修がより大変になってしまったという話です。
あとDynamoDBですね。DynamoDBはAmplifyから作成しやすいという、フレームワークロックインに近い理由で使い始めたんですが、やはりJoinが多数発生するようなデータ構造では不向きですね。
それを解決するようなプラクティスなどはAWSが提示しているんですが、やはりバックエンド側のスキーマ管理や実装が複雑になるので、採用すべきではなかったなと思っています。
こちらもRDSへ移行できるものは移行していったり、新しくストアするデータはRDSにしたいとなって、段階的に移行している状況です。
取り返しがつくならどんな技術を採用してもいいと思う
まとめです。やはりスタートアップや新規事業はスピードが命なので、これは当たり前のレベルですが、早く作ることは必須となっています。その上で、その後に柔軟にアップデートできるような技術選定が重要になっています。まずは早く作ることができるのであれば、取り返しがつくならどんな技術を採用してもいいんじゃないかなと思っています。
ただ、言語を後から変えるのはメチャクチャ難しいですし、後回しにすると変更範囲が大きくなるような不便さは、（そう）感じた時点で手を打つほうがいいですね。後になればなるほど変更が大変になってくる。 弊社の場合、Amplifyによる開発やユニットテストの導入は、早くやっておいて良かったところです。
あと、取り返しがつかないようなことに関しては、予防的に対応すべきです。（例えば）ユーザー基盤とかセキュリティとか、データバックアップ（について）です。
この（開発PM勉強会登壇の）お話を受けてからけっこうChatGPTの進歩が目覚ましいので、ジェネラルな話をするぐらいなら、今は全部（Chat）GPTに聞けばいいんじゃないかなと思ってしまうような状況ですが、（Chat）GPTを使う場合には、やはり質問力が大事です。
自分のチームやプロダクトの背景を伝えたり、いろいろな判断をする上でも、そこを考えることが大切かなと思っています。
以上、ご清聴ありがとうございました。
