こういう記事は年末に出すのがいいのかもしれないが、だらだら書いてたら新年になってしまった。

2022年の活動として一番大きかったのは、個人の活動としてスタートアップの創業を手伝ったことだ。自分が手伝ったのはエンジニアリング周りとプロダクトマネジメント周りの大体全部。

オファーいただいた時点で事業規模からフルタイムでのコミットは不要とのことで、副業でこの仕事をしていた。

ざっくり出来たことと感想

一つのアプリを文字通り0から作り上げてリリース、ユーザーを集めることに成功した。またエンジニア組織を1人（自分だけ）の状態から立ち上げ、経営方針からフルタイムではない業務委託のエンジニアオンリーという限られたリソース下で、パズルのような配置をやって、二週に一度はアップデートのリリースを出せる運用をやっていた。

もともと可処分時間をプロダクトマネジメントのことを勉強したり考えたり、課題解決のためのアイデアを練ったりするのに使ってしまうくらい好きなことであるため、非常に楽しい仕事だった。経営側があまりエンジニアリングの事情に詳しくなかったため、エンジニアリングが絡むことをほぼ任されたり、エンジニアリングの事情を分かりやすく伝えたりし、エンジニアとしてのバックグランドも存分に活かせた仕事だった。

一方で、全員の勤務時間が不定なことによるコミュニケーションの難しさ＋スタートアップ特有の特大不確実性との立ち向かい＋経営側と開発チーム側の板挟みになる、といったことで苦悩する時も多かった。（がまあこれをなんとかするがPdMの仕事なのでやりがいは非常に感じてた）

この記事ではどんなことをしてたか、書いていきたい。

そのときの選択にはベストを尽くしたつもりで、うまくいったものもあれば、微妙だったのもある。ここでは一つひとつについては結果を考察しない。（別途振り返り記事は書くかも）

あと到底1年でやったことを書き切ることなど出来ないので、サマリ的な感じで書いてます。

事業

toCコミュニケーションアプリの制作と運営

加入タイミング

CEO, COOが競合分析やペルソナ作りを終えて作るサービスの方針が確定し、エンジニアとエンジニアを動かしてプロダクトを作れる人を探していたタイミング。エンジニアは業務委託で数名決まってる人がいた。

やったこと

組織作り

組織文化の醸成

組織文化の情勢は最初がだいじだと思ってたので、特に初期は頑張っていた。情報の透明性の高い組織づくりを目指し、当初LINEでやりとりしてた経営メンバーに対してもSlackでの情報交換やNotionの利用を呼びかけた。

エンジニアに対しては特にリリース前の初期はここどうしますか？系の話が非常に多く、決まらないと先に進めないことが多かったので、気軽にエンジニア同士、またPOに対し質問できる空気作りを心がけた。加えて質問しやすいようなコミュニケーション(MTG)設計も心がけた。

（MTG終わりに、何か1週間限りのこの場所で言っておきたいこと、聞いておきたいこと、あればお願いします（10秒待つ） + MTG終わって解散になった後MTG部屋に10分くらい残るので、なんでも話しかけてくださいなど...）

▲SSoTの原則に則ったドキュメンテーション文化を作っていった

エンジニアリング周り

技術選定

業務委託のメンバーと相談しつつ最終的な決定は自分がやった。

クライアント

CEO, COOが採用したエンジニアがFlutterエンジニアだったため(本来逆)、またAndroid, iOSアプリを同時に迅速に提供したいという理由から、Flutterを採用。Flutter, riverpodを使ったクリーンアーキテクチャでの実装、またmockitoを使ったテスト実装をやっていった。

バックエンド

業務委託のSREメンバーと相談しながら、Cloud SQL, Cloud Run, Cloud Storage, Cloud Functions, Firestoreなどを使った構成を決めていった。Firestoreはアプリ内のチャットサービスに使い、クライアントのSDKから直接APIを叩く方式で実装していった。

チーム運用

Slack, Notion, ClickUp, Google Workspaceを採用し使い方をチームに広めた。2022年後半はNotionの機能が拡充されていったのとスクラム運用を廃止したため、タスク管理をClickUpからNotionに移行した。

費用管理

資金が非常に限られていたため、特にGCPでは利用頻度やアクセス数を考慮した、Cloud Runでのminimum instance数の設定、開発環境のアーキテクチャ変更などのチューニングを行った。

エンジニア採用

応募者と面接して採否を決定。とはいえ業務委託の採用だったので、スキル面と条件面の確認が主だった。

エンジニア配置

エンジニア全員と技術スタックに加え思想的な部分（こうであってほしいこうしたいこういうのが気持ち悪い）などを定期的にヒアリングし、各々のエンジニアが最大バリューを発揮できる、かつエンジニアチームが円滑に回るようなアサインをした。

プロダクトマネージャー的なこと

エンジニアチーム運用（タスク運用、コミュニケーション設計など）

スクラム開発を導入。チームの特性にあったカスタマイズを加え、回していった。自分がPOをやってユーザーストーリーを作ってメンバーに説明をしていた。2022年後半はスクラム運用を廃止し、タスクには明確な期限設定＋アジャイルのための振り返りをやる運用にした。というのも、業務時間が不定（月の目安労働時間と成果目標だけ設定してあってあとは自由）の業務委託エンジニアに対し、スプリントを回す方式がタスクを遂行してもらうことに対し合わなかった。しかしスタートアップゆえ未熟の組織で定期的に開発チームで振り返りをすること、またエンジニア同士で同時に勤務時間を過ごすことがあまりないので振り返り会が貴重で興味深い雑談機会となること、それがエンジニア同士で課題を解決しなければならない時のコミュニケーションの壁を薄くすること、これらは重要視していたためスクラムをやめても定期的な振り返りMTGは残した。

コードオーナーの任命（デリゲーション）

物事を円滑に素早く進めていくことがスタートアップでは非常に大事である。初期、文法や記法、アーキテクチャ、諸々で議論が煮詰まり本質的なコーディングとそのデプロイが滞ることがあった。そこで、コードオーナーというロールを作り任命した。コードオーナーにはコミッター間での意見や知識を統合し、最終的にコーディング規約を規定してもらう役割、コードレビューで悩んだ時に最終的に判断する役割、コード品質を担保する役割をつけた。これによって、

エンジニアリングに親しくない経営メンバーとのコミュニケーション

他のサービスがやっている一見簡単そうに見えることも、エンジニアリング的観点から見ると非常に大変なことが多々ある。これを理解してもらえるまで説明する、現実世界のわかりやすい事象に例えて説明するなど、いろいろ心がけていた。

サービス設計

toCアプリのスタートアップで大切なのは、仮説検証を短いサイクルで行い資金を使い切る前に収益構造を生み出すことである。4月初頭のファーストリリースまでは、自分が加入する前からあって投資家のGoももらってるアイデアをそのまま実現するのが仕事だったが、それ以降はリリース後のユーザーの反応を見て新しい機能を考え仕様を決めエンジニアを動かす仕事に徹することになった。

アイデアの発散と収束を繰り返し、さまざまなユーザーに影響を与えるファクターを考慮、またユーザ数と収益をプラスのフィードバックに持っていくこと、現在会社が持ってるリソースで実現可能なこと、など諸々を考慮して、次につけるべき機能を割り出していった。

またPMF(Product Marketing Fit)するために、考案した新機能がついた後のアプリに対し、SWOT分析等の各種戦略的分析手法を適用していった。