今日の一言：MVPを「計測」するなら、持てる力は全部使う 💪

昨日はロードマップ作成がメインでしたが、今日は一段ギアを上げています。 フルスタックエンジニアを含め、日本・インド・ブラジルのグローバル3拠点のエンジニアチームが 今年初めて同時間に集まりました 🌍ブラジルチーム全員集合は久しぶりだったので、みんなよくしゃべっていましたね！

少し無理を言って、3チームを一つのバーチャルミーティングで囲んで議論しました。ブラジルは夜中だったね(笑)！ありがとね

最初にやったのは「要件定義」の話 📐

まず最初に議論したのは、要件定義、DDD、その他のソフトウェアアーキテクチャや開発手法を どうするか、という点です。

一般的に、MVP開発やPoC開発では「とにかく早く作る」が優先されがちです。 ただ、Tenjin Techでは少し違う捉え方をしています。

• スピードは当然大事
• でも、そのままスケールできないMVPは、あとで必ず詰む

この2つはトレードオフではなく、同時に成立させなければならない。 だからこそ、最初のハイレベルアーキテクチャ設計が重要になります。

なお、ここで言う要件定義は「全部を細かく決め切る」ことではありません。
👉 MVPとして“決め切るべきところだけを決める”要件定義——ここを強く意識しています。ここは多様性有りのチームだと色々な意見がポンポンとでてくるのでイイですね！結構、皆ハッキリと言ってます。遠慮なしです(笑)アジャイルは全てをまず机の上にあげるのが基本です。隠してしまってはいけません。

ハイレベルアーキテクチャは最初に決め切る 🧠

今回のMVPについては、CEOであるジャックが、ハイレベルアーキテクチャを先に設計しました。 どの技術を使うのか、どのインフラを使うのか、どのデータベースを使うのか。一番個性がでるとこです(笑) これらはミーティング前にあらかじめ決めています。

たとえば、

• 今回は DynamoDB は不要だよね
• 基本は PostgreSQL でいこう
• じゃあ PostgreSQL をどのマネージドサービスで使うのが一番筋がいいか

「MVPだから後で変えればいい」という判断は、今回はしません。
👉 後戻りしない前提で決める。ここはTenjin Techのはっきりしたスタンスです。

1日20時間稼働のスプリント体制を試す ⏱️

今回、初めて1日20時間稼働体制を試します。構成はこうです。

1. 日本チーム 🇯🇵：一番早く1日をスタート
2. 約3時間後にインドチーム 🇮🇳 が合流
3. 日本とインドが寝ている夜間は、ブラジルチーム 🇧🇷 が稼働

結果として、1日あたり約20時間、開発が止まらない体制になります。

コミュニケーションは感覚ではなく「ルール」で決める 💬

コミュニケーションツールは Slack に統一しました。あわせて、明確なルールを設定しています。

• 通常の連絡：5時間以内に返信
• アージェント（緊急）：30分以内に返信

日本の開発現場では「よしなに」「いい感じで」といった指示が出がちですが、 グローバルチームでは、それが一番危ない ⚠️ だから、レスポンス時間まで含めて設計する。ここは徹底します。

三段構えのレビューサイクル 🔁

開発とレビューは、三段構えです。

1. 日本側が設計と方向性を定義
2. インド側が実装を進める（時差は約3時間。PRやPushをほぼ同じ目線で確認）
3. ブラジル側が夜間稼働（PR／Pushを上げ、翌朝に日本→インドの順でレビュー）

このサイクルを前提に回していきます。PRやPushはGitHub内でのアクションのことです。

1スプリント＝1週間。目的は「速度の実測」📊

今回のスプリントは、1週間＝1スプリントと仮定しました。 目的はとてもシンプルです。

👉 この体制・この設計で、どのくらいの速度でMVPが作れるのか
それを、誰かの理論ではなく、自分たち自身の手で実測する。 これが今回のゼロスタートMVPスプリントの本質です。