mocriの振り返り

By kkoudev

今年も去年の振り返りを書いてみようかと思います。
ただ今年は今開発しているmocriというプロダクトの開発で採用した技術やサービス開発についての４年間の振り返りを書こうと思います。
これをこのタイミングで記述する理由としては、１つの節目を迎えたと感じたためです。

mocriというプロダクトについて

このプロダクトの開発に着手したのは2018年秋頃だったのでもう4年も前のことになります。
その後、2019年3月にベータ版をリリースし、その年の夏頃には正式版をリリースという形で進行してきました。

当時私は別プロダクトのサービスが終了し、その後何をやろうか考えているときに
当時のPOに声をかけていただいたために参画することになったという経緯です。
プロダクトの最初の印象では音声通話のコミュニケーションサービスの作業通話特化型という感じで、
エンジニアの私からみた時に実現難易度が高そうなことと、高額となるであろうランニングコストをどう解決するのか…というのが真っ先に思い浮かびました。
この当初の懸念はのちに自分を苦しめることになるのですが、それはまた後述します。

最初の技術選定

当初は本当に音声通話と画像送信だけができるサービスだったのですが、
チャットと同じく送信は部屋に入室しているユーザーに即反映される必要がある要件でした。
となると、双方向通信ができる必要があるという点が真っ先に思い浮かびます。
世間的にもgRPCの事例がいくつかで始めたときで、gRPCは双方向通信をサポートしています。
しかもProtocol Buffersを使えばスキーマファーストな開発もできます。
そうなると、これを使わない手はないと考えて、APIとしてgRPCを採用することに決めました。
クライアントについては、ギリギリまでネイティブで実装するかReact Nativeで実装するかを悩んだのですが、
エンジニアが最初は私一人であったことと、タイミングよく日本語入力の不具合が当時リリースされた v0.57 で修正されたというCHANGELOGが目に入ったため、これは問題なく使えそうだと考え、思い切って採用することに決めました。

そんな感じで、当初のアーキテクチャとしては以下のようになってました。

・React Native
・gRPC (grpc-go)
・Kubernetes (kOps。のちにEKSへ移行)
・MariaDB (のちにMySQLへ変更)

その後、ブラウザ版をリリースした際は

・Next.js
・grpc-web

を採用しています。

k8sを採用した理由については、

・設定ファイルベースで必要なコンテナの定義や細かいルールが記述できる
・ローカルでも使える (重要)

当時はECSでインフラ構築をしている事例が社内では大半だったのですが、
ローカルではdocker-composeで環境構築をするような例が多く、
それでは環境差異が出てあまり良くないな…と考えていたためでもあります。
もちろんk8sにしたところでローカルとステージング以降では全然ネットワーク構成もロードバランサーの数も異なるのですが、 あくまでできる限り環境差異を近づけることを目的としました。

尚、kOpsを採用した理由としては、当時はまだEKSが東京リージョンで使えなかったのと、 EKSにManaged Nodegroupのような便利な機能がなかったためです。

また、肝心の音声通話については、Clubhouseで一躍有名となった(といってもまだこの頃Clubhouseはありませんでしたが) agora.io を採用しました。
個人的にこの選択がある時点までは成功だったと思いつつも、後に大きな失敗でもあったなと今になって思います。

クラウドサービスについては色々揃っているAWSを採用しました。
当初、Firebaseで認可・DB諸々全部構築して早く作ってリリースする！みたいな風潮が社内で流行っていたのですが、 自分はその考え方に非常に懐疑的だったのと、Firebaseを中心にサービスを作ってしまうとのちにサービスとしてスケールしづらくなるという危機感の方を抱いていたため、MessagingやDynamic Linksのような一部のみを採用するに留めました。
そしてこの選択は結果的には成功だったなと思います。

技術選定のその後

４年も前に選択した技術が果たしてどうだったのか、という点は気になることかと思います。
ただこれはあくまで個人の感想なので、必ずしも全ての事例に当てはまるものではないと思ってください。

React Nativeについて

ある程度新しいバージョンに追従していく限りでは、非常に上手く機能していました。
UIはOSバージョン差異を意識しなくて良いのでネイティブよりも圧倒的に確実で作りやすいです。 ただいつまでも直らない不具合にパッチを当てたり、PRを送ったりといった努力をある程度は重ねる必要はあります。
Flutterは使ったことがないのでわかりませんが、React Nativeについてはそのような運用スキルが必要です。
また、環境差異を考慮したビルドについては基本的にネイティブの知識(CocoaPods、Carthage、SPM、Gradleなど)が必須になります。
iOSもAndroidもネイティブで開発していた経験がある自分にとってはそれほど苦ではありませんでしたが、
この辺の経験がなくて単にReactだけ触ったことがあるという人には全くおすすめはできません。
とはいえ、それも慣れなのでやっていれば覚えていくことかと思いますが、ある程度の根気は必要です。

React Nativeを採用して失敗している世の中の事例は最新バージョンに追従していなかったり、
パッチを当てまくった挙句にバージョンアップできなくなった、みたいな例が見ている限り多いと考えています。
なので自分としては

・できる限り最新版に追従する (とはいえ最新はバグもあるので、マイナーバージョンがある程度上がってからバージョンアップする)
・RN本体やライブラリにパッチを当てるのは最終手段。小規模な機能なら最悪自前実装した方がマシかどうかも含めて考える

この２つが大きく重要なポイントであったと考えています。

gRPCについて

gRPCについては正直可もなく不可もなく、という感想です。
ただRESTよりは高速であることと、OpenAPIよりは自動生成コードが比較的マシであるというくらいが良いところかなと思います。
とはいえ、grpc-webについては完全に微妙でした。これは今でも変わっていません。

grpc-webの微妙なところ

grpc-webはgRPCの機能を全て満たしていません。登場から３年以上経過してもこの状態なので、公式も完全にやる気がないとしか言えません…。
双方向通信(Bidirectional Streaming)はもちろんできないのと、公式版はSSRでの利用すらできないため、Next.jsでの採用には難があります。
そのため、grpc-webを利用する場合は公式版は利用せず、 improbable-eng/grpc-web を利用するのがデファクトスタンダードとなりつつありました。
こちらは双方向通信をWebSocketで実現するようになっており、クライアントストリーミングは利用できないものの、それ以外のgRPCの通信方式は全て利用ができます。
双方向通信が利用できればクライアントストリーミングは代替可能なので、大きな問題ではありませんでした。
また、SSRでの利用も可能なため、Next.jsでの利用も問題ないのと、React Nativeでも利用が可能です。

しかし、以下の問題があります。

・自動生成されるコードが微妙で、gRPCのTrailerデータがエラー時しか取得できない (自動生成コードを使わなければ一応可能)
・React Nativeでは単方向通信(Unary)しか使えない
・詳細エラーが正常に受け取れないことがある

とはいえ、これらの問題は別の方法での対処が可能だったのでそこまで大きな問題ではなかったのですが、
とうとうこの improbable-eng/grpc-web も更新が1年以上止まってしまいました。

ただ最近Bufの開発する connect-web が登場したこともあり、これが improbable-eng/grpc-web 同等の機能を満たしつつ、問題を解決しているならまだまだ可能性はあるかもしれませんので今後には期待ができそうです。

とはいえ、フロントエンド(Web/iOS/Android)では今は圧倒的にGraphQLを採用した方が開発しやすいのと、事例も多く登場しているため、
今後私が新しくプロダクトを作る際に grpc-web を採用することはないかな…と現時点では思います。
gRPCは、あくまでフロントエンドではなくバックエンドのサービス間通信で利用するに止めるのが最も適しているのではないかと考えています。

Protocol BuffersとgRPCのコード自動生成のオプションが微妙に噛み合っていない

これは具体的に言うとObjCのことなのですが、
gRPCをiOSネイティブで利用する際は、公式のObjC版かSwift版を利用する必要があります。
当初grpc-swiftはまだ正式版ではなく、一度採用したもののDeadlineを無効化しても10分ごとに接続が切れる謎の不具合があったりしたので、ObjC版に置き換えました。 ObjCというと抵抗があるかもしれませんが、Swiftから呼び出して使うので別にObjCでネイティブコードを全て記述するわけではありません。

さて問題というのは、ObjC/Swiftという言語が同一プロジェクト内に同じ名前のクラス名を作れない、というところにあります。
JavaやGoといった言語とは違い、パッケージのような概念が同一プロジェクト内にはないわけです。
そのため、これを考えずにProtocol Buffersの設計をしているとある日突然ハマることになります。
これに対処するために、protocの方ではディレクトリパスをクラス名に付与できるオプションが比較的最近追加されたのですが、
肝心のgRPC側のプラグインにはそのようなオプションがないため、結果的にこのオプションは役に立っていない状態になっています。
私の方で issue を挙げたものの、誰も開発する気がないのか issue をたらい回しにした挙句にbotに閉じられてしまったという経緯もあります。

このように、言語によってサポートがまちまちな状態なので、gRPCをObjC/Swiftで利用するのは微妙なところです。
最初から名前が被らないようにスキーマ設計を行うか、objc_class_prefix というオプションを利用して
被った場合は接頭語に別の名前をつけてあげるといった付け焼き刃な対応をするしか現状はない感じになっています。
(grpc-swiftではディレクトリパスをクラス名に付与するオプションが自動生成時にあるので、ObjC版を使わなければこの問題には当たらないことでしょう)

MariaDBについて

これは一昨年くらいの振り返りでも記述したのですが、MariaDBを利用していたことが原因で大障害を引き起こしました。
MariaDB(10.3系でした)の不具合で、プライマリキーに文字列(UUID含む)を利用するとカラム追加起因でデータが壊れるケースがあるという不具合です。
この不具合は時間差で発動するところがまた大きな問題でした。
とにかくこの一件からMariaDBは２度と採用しないと自分の中では決めています。
この不具合でサービスを１週間止めることになってしまい、サービス復帰時にTwitterトレンドに入ってしまったのも今では懐かしい思い出になっています…。
なので自分はこの経験もあって、MariaDBを使うならMySQLを使おうとどうしても言わざるを得ない感じになっています。

kOpsについて

kOpsについての問題は以前EKS移行の記事を書いた時にも書いたので簡潔に記述しますが、
クラスタアップデートがある時点からできなくなったために新しくクラスタを作らざるを得ない→それならEKS移行するか、となったため移行しました。
今ならEKSで最初から構築するのが間違いなくおすすめになります。

agora.ioについて

agoraを採用したことで最も高難易度であった音声通話の実装を簡略化することができましたが、 このagoraは非常に不具合が多く、バージョンアップをすることで簡単に音声が聞こえなくなる、途切れるなどの問題を引き起こしていました。
また、全てのアプリで利用しているSDKのバージョンが一致していないと問題を解決できない、なんてことも多々ありました。
(特にAndroidでの不具合が多く見られました)
ソースコードも公開されていないため解析もしようがなく、ログをサポートに送るだけにとどまるケースが殆どです。
サポートも本社に直ではなく、日本代理店を通すところがまた大きな時間的なロスを生む要因にもなっていたと思います。
その結果、不具合と認識されてもその修正版がリリースされるのはいつになるかわからず・・・という何もできずにただ謝ることしかできないような状態が続いたこともありました。

また、このagora.ioは利用ユーザー数と時間ベースで料金が決まるため、ユーザー数が少ないうちは安く感じるのですが、 ユーザーが一定数に増加すると一気に料金が跳ね上がります。
これが自分が当初懸念したランニングコスト問題です。
サービスをいち早くリリースしたいという目的で agora.io を使うことは必ずしも悪いことではないのですが、 ランニングコストの回収目処が立っていない中で利用を決めてしまったのは完全に失敗だったと考えています。

最初からTwitter Spaceでも利用しているというJanusあたりを導入し、運用していくのが良かったのではないかと結果論としては思っています。
もちろんその分運用がより大変だった可能性は十分にあるのですが、
結果的にランニングコスト以外の面でもこの選択はのちのサービス拡大の足枷となってしまいましたので、選択としては失敗だったなと考えています。

技術選定のまとめ

そんな感じで、技術選定についてはgRPCを初め、色々と問題はあったものの
スキーマファーストで開発していくことについての体験は非常に良かったと感じているので
今後もスキーマファーストで開発する方法を中心に採用していきたいなとは考えています。
MariaDBについては完全に事故のようなものでしたが、実績のあるRDBMSでもこのようなデータを簡単に破壊してしまうような不具合があるものなんだなと知れたのは前向きに考えると良い経験でした。

プロダクト開発の振り返り

プロダクト開発をする上で非常に有効だった施策や失敗談として、以下が印象に残っています。

漫画を元にプロダクトの説明をしたツイートがバズりやすい

最初は200RTくらいいけば…と思ってツイートしたら、まだリリースしてもいないのに6000RTくらいになってました。
リリース前にツイートしたこの内容から結構プロダクトとしていけるかもしれない、という期待が膨らみました。
その後、リリース時も同様に漫画を元にツイートしたものがバズり、またあるインフルエンサーが引用RTで紹介してくれたら当時利用していたTestFlightのユーザー最大数(1万が最大)にまでダウンロードされたみたいなことがありました。

創作界隈と相性が良かったというのもあるのかもしれませんが、漫画を元にしたツイートは内容がわかりやすく、(読まれやすく)
他のプロダクトでもRTやいいねがされる傾向にあることがわかりました。
これは当時としては新しい発見だったかなと思います。

バズったと思っても毎回同じくらいのRTやいいね数で止まるということは拡散していない

これは要するに、フォロワーもしくはそれに近い人が毎回いいねやRTをしてくれるというだけであって、
新しいユーザーへリーチできているかでいうと微妙なポイントとなります。
これも判断を見誤ったポイントの１つで、今回も6000RTくらいされているから人気がでるだろうと思われた機能も
いざ出してみればそれほどKPIに寄与するものではなかった、ということがありました。
なので、過去にバズったツイートのRT数やいいね数はメモしておいた方がいいでしょう。
既に利用していただいている人に良いと思われることも重要ですが、リーチが目的であるならそれだけでは意味をなさないこともあります。
強いて言うなら、既に使っていただいている人が他の人に勧めるくらいの良いものになっていれば、また話は違ったのかもしれません…。

初期のペルソナから変化するケースは少ない

mocriは友達同士で通話するアプリのため、クローズドな通話アプリです。
ただ、マネタイズをしていく上ではオープン志向での拡大路線を狙う方が認知させやすいため都合がよかったりします。
そこで、オープン志向な人を取り入れていく施策をいくつか打ちましたが、どれも上手くはいきませんでした。

これが意味するところは、初期に設定したペルソナと現在のユーザーが大きく変化していないことに尽きます。
仮に変化をしたとしても、少ない割合であるか、まだその規模には達していないということです。
あくまで初期のペルソナに対してPMFしたわけですから、そこから外れてしまえば当然割合が少ない以上、中途半端な規模では上手くいくことがないわけです。

もしオープン志向へ寄せるなら、完全に別サービスとして１からペルソナを設定し直して作るべきだったか、早々に今のペルソナを含んだより広いターゲット層へ向けたプロダクトへピボットするべきだったなと今にしては思います。

マネタイズ機能はユーザー体験によりマッチしていなければ課金されない

マネタイズ機能は通常機能よりも使われる率がずっと少ないです。
これは当たり前のことではあるのですが、この「ずっと少ない」というのは 自分達が想像している何千倍も少ないということです。
普段サービスを作っている側からすれば、同じ労力で作った機能を単に無料か有料かを決めるだけで良いので この辺の判断を見誤ることが多々あります。

例え金額が安くても、お金を出すということはそれだけペインとなっていた何かを解決できるからか、 もしくはお金を出すことでより一層楽しかったり嬉しかったり、また便利と思える体験ができるからこそ払うものです。

つまり、「普段よく使う機能では解決できない何か」であるペインポイントに対してマネタイズしなければ課金する気はユーザーは起きないし、
代替手段があるならそっちを使うことに注力することが殆どです。
Twitter Blueが良い例なのですが、どれも「あれば便利だけどなくても困らない」機能ばかりであり、 そのような便利機能に対して課金されることは実はあまり多くはないということになります。

この辺り、言葉だととてもニュアンスが伝わりづらいのと、これ以上うまく自分も説明はできないのですが、
それだけユーザーの気持ちになってどのような体験が一番嬉しいのか、どれならお金を出しても良いとなるのか というのを大きく意識する必要がある、ということを感じました。

過大なランニングコストはサービスのスケールを止める

冒頭で話したランニングコストの問題は、当然ながら運用費の大半を占めるため、 そうなると広告を打つこともできなくなります。
それくらいに、agora.ioの費用は莫大な費用であり、他のマーケティング施策を打てなくするレベルのものです。
もちろん、広告は一例です。
他にも、画面共有のような非常に需要の高い機能を何故実装できていないのかというのもこのランニングコストが起因しています。

もし自前でJanusなどで構築をしている限りは、データの伝送手段を制限するような仕様なりチューニングをいくつかできたと思いますが、(もちろんそれでもコストは課題とはなるでしょうが) agora.ioを使う限りは、ミュートにしていても部屋に参加している限りは課金がされるため全くもってデータ伝送観点におけるチューニングが意味をなしません。
そうなると、通話上限時間の設定や、もしくは通話自体に課金をするといった方法でないとサービスで黒字化を達成することは叶わないことでしょう。

そのため、コスト感は非常に大事です。
よくスタートアップで言われている「マネタイズより先にユーザー数を伸ばすこと」という原則は間違ってはいないものの、一方で無い袖は振れないので何事にも物には限度があるということを心がける必要があります。
そのため、初期にある程度会社やVCが投資してくれるからとか、そういうのを前提に考えてサービスを伸ばし続けるとこのランニングコスト問題にぶつかってて動けなくなってしまうことがあります。
まさにmocriではこのランニングコスト問題にぶつかってしまったため、最初からランニングコストを考慮したサービス拡大設計と技術選定が大事になってくるというのが身に染みて感じました。

ユーザーの意見を何でもかんでもそのまま聞き入れてしまうとプロダクトとしての複雑化を招きやすい

これはよく言われることなので自分も意識はしていたのですが、
知らず知らずのうちにユーザーの意見を鵜呑みにしてしまうことが結果としてありました。
その結果、機能過多になったり、表示・非表示機能が毎回登場したりと、
わかりづらさが増えていく結果になってしまったと考えています。

もちろん、ユーザーの意見は大事な感想の１つです。
問題は、それを実現する自分達の手段にあったと思っています。

最近イーロン・マスクがTwitterでユーザーからのアンケートで閲覧数の表示位置を決めようとしてたことがありましたが、 結果的に自分達が普段やってることもあのようなことだったのかも知れない…と思うと、反省しても仕切れない感じでした。
結局大事なことは、「ユーザー体験がそれによってどれだけ変わるのか、どれだけ改善できるのか、結果どのように感じるのか」でしかないなと今では感じています。

例えば表示・非表示機能をつける必要があったのはそのようにせざるを得ない場所に表示されていたのが問題だった、というのが問題の本質だったと考えていますし、もっと突き詰めればそもそも必要な機能だったかどうか、という話もありました。
最初からその判断を誤らなければ、複雑化も防ぐことができたであろうと今では思います。

マネタイズから逆算して作った機能はユーザー体験よりマネタイズが目的となってしまいがちである

これも当然といえば当然のことなのですが、自分達の目的がマネタイズを成功させることになってしまっており、肝心のユーザー体験に基づいた機能を提供できていなかったという話になります。
もちろん途中で本当にこれでいいのか、と思うポイントはいくつもあったものの、時間的制約もある中で今更引き返すことも難しく、早く機能をリリースしてそれを証明するしかないという形で動いていました。
ただ、思ったよりも機能が複雑化してしまい、開発にも時間がかかって結局あとから改善する時間的余裕がない中でリリースしてその結果を目の当たりするだけになってしまった、という事態になります。

では、何故ユーザー体験に基づいたマネタイズ手段を最初から考慮できなかったのかというと、
きょうび大金を稼ぐためのマネタイズ手段で成功事例があるものは少ないです。
そのため、手段ありきで逆算してそこに当てはめるしかないというように考えてしまっていました。
これはこれで仕方がなかったと思う反面、自分たちがもっと強くユーザー体験の重要性を認識して、現在のデータに基づいてこのプロダクトには当てはまらないことを最初から提示できていればよかったのでは、と思います。
とはいえ、これも結果論でしかなく、当時の自分たちがこれ以外に手段がないと最初から思ってしまったことが一番良くなかったのかもしれません。

こうしてマネタイズを考慮して逆算して作ったような機能は、結果的には「代替手段があるのに何が違うの？」とユーザーに言われる始末だったりします。
これも何故みんな気づかなかったのか、というと結局のところユーザー体験を優先したものになっていなかったからではないかと自分は考えています。
シンプルが売りだったプロダクトの機能は複雑化の一途を辿っただけでなく、代替手段のあるものを別名称で提供しただけというなんともお粗末な結果に終わったという話になります。

マネタイズ手段から逆算して作ることそのものが悪いとは思いません。
あくまで優先すべきはユーザー体験であり、かつ「ペインポイントに対してマネタイズができてるかどうか」です。
先述したとおり、お金を払うハードルは開発者目線と使用者目線では全く違います。その差は何千倍以上もあると考えても良いと思います。
それだけに、しつこいようですがユーザー体験を優先することがいかに重要になってくるか、と私は考えています。

ユーザーインタビューやアンケートの結果で需要があっても実際に利用してもらえるかどうかは別問題である

これは元々６割ほど需要があったものを「需要がある」と解釈してリリースしたものの、結果的に「あまり使っていない」「いつか使いたい」に止まってしまっているユーザーが多かったというものです。
ちなみにこれは逆パターンもあり、アンケートでは２割ほどしか需要がなかったもののリリースしてみると多く使われる機能になった、ということもありました。

これらの差もしつこいようですがユーザー体験に基づいたものになっていたかどうか、でしかないと考えています。
例え需要がなくても、ユーザーのペインポイントを解決できる機能や、想像していなかった楽しさを提供できる機能であればその良さをユーザーは体験するために自然と利用するようになる、という話です。
また、ユーザーから「欲しい」と言われている機能でも、実現手段に問題があればそれはユーザーの想像する欲しい機能ではなくなってしまうケースがあるのと、また「欲しい」というのはなんとなくふわっとそう思っているケースも多々あるため、リリースされてみると「実は必要なかった」ことに気づくケースもあります。

ユーザーインタビューは毎回５名前後の方から意見をいただいて、それをもとに機能開発をすることがあったのですが、
ユーザー1人の意見が大多数の意見ではないのに、実際にインタビューしてみると多くのユーザーからの意見だと錯覚するケースもあります。

これは私もクライアントワークなシステム開発をしていた時代に経験があるのですが、どう考えても実現が工数的に難しい機能であっても、いざお客さんの前で話をしてみると「確かに欲しい機能だよな…」と思ってしまい、否定しづらくなるということです。
つまり、相手に共感してしまうために、自分の考えを第三者視点で判断できなくなってしまうという罠があります。
直接話をした人の意見というのは、単にアンケートでいただいた意見よりも重く受け止めがち、とも言えるかも知れません。

なので結局のところ、ユーザーの意見を参考にするだけでよいのに、それを重く受け止めすぎてそのまま実現してしまい、体験に基づいた課題解決ができていなかった、という話が主な失敗ポイントだったのではないかと考えています。

プロダクト開発におけるまとめ

そんな感じで、色々と失敗談を羅列しましたが、まとめると

・ユーザー体験をいかにユーザー視点で捉えられるかどうかを実際のユーザー以上にもっと強く意識する方法を考えるべきだった
・いつのまにかユーザーの課題ベースではなく欲しい機能ベースでの開発にシフトしてしまっていた

というところなのではないかなと自分は考えています。

今後について

今後は今までの失敗を可能な限り繰り返さないという点はもちろんそうなのですが、
また機会があれば新規プロダクト開発を続けていきたいという考えもあります。
やはり0→1の開発は学ぶことが多く、一度成功したサービスを開発し続けるだけでは得られない経験や発見がいくつもあります。
一方で、自分はどのような立場になってもコードを書くことを辞めないことに拘ってきた技術者でもあって、
プロダクトマネジメントとエンジニアリングの両方をもっと突き詰めて新しい挑戦をしてみたいと考えております。

昨今では新規サービスの成功難易度は格段に上がっており、
企業としてはスタートアップ界隈で成功したサービスを買収して育てる、みたいな方針を取ってる企業が多いです。(弊社もその1つです)
とはいえ、大企業がスタートアップ同様に柔軟な動きができるかというと様々な制約のために難しいケースが殆どであり、
お金と社名以外で優位に立てるポイントがほぼありません。
そのため、成功しているサービスを買収したところでそのまま上手くいかないケースも多々あるのと、
買収した企業と企業文化がマッチしないためにかえって悪い方向に転がるケースも無きにしも非ずです。

ではスタートアップならどうなのかというところなのですが、
スタートアップ界隈でもロシア・ウクライナの抗争以降は
投資家がお金の投資に対してより慎重になってきている、という話もあるため、
とあるスタートアップ企業では投資制限されたため採用の制限をしているところもあったりします。
そのため大企業であれスタートアップであれ、問題の種類は違えど何かしらの制約を乗り越えない限りはプロダクト開発をうまく進めることは出来ないとも考えています。

何がより今の自分に適しているか、また今後の業界の方向性も踏まえた上でどうなのか、
それぞれを加味した上で今一度プロダクト開発を単なるエンジニアリングによる改善目線ではなく、いちから作り出していく方向で動き続ける機会と巡り会えたら良いなと考えています。

というわけで、一通りマネタイズ機能の開発とリリースまでを行ったことを一つの節目と感じたため、
プロダクトの振り返りとさせていただきました。

2023年にやりたいこと

そんな感じで、去年はプロダクト開発中心であまり趣味でやりたいことも出来ていないような状況だったため、 今年はもう少し余裕を持つことを目標としたいです。
ひとまず、いつまでもNetlifyに置いているこのブログをVercelへ移したいなと思うので、まずはそこからやってみようかと思います。