Yuibun（結文）

課題

LINE は連絡のための場所で、Instagram は発信のための場所です。そのどちらでもない「感謝を伝える」「価値観をすり合わせる」ための場所がありませんでした。

日常の連絡に混ざってしまうと、感謝は流れて消えます。パートナーとの間で本当に残しておきたいやりとりだけを、別の場所に積み上げたい——それが出発点でした。

やったこと

2種類のカード体験を設計・実装しました。

サンクスカードは、ホーム画面のウィジェットから即座に感謝を送れます。受け取り側にはリッチ通知が届き、開封の演出が入ります。モットーカードは、ふたりが同時に了承したときだけ開きます（コード発行＋生体認証による MFA）。片方だけでは開けない仕組みにすることで、価値観のすり合わせを「一緒に開く」という体験に落としました。

設計上の意思決定

ADR と内部設計書を実装より先に書いた

• 判断：アーキテクチャ・DDD・TDD・IaC・CI/E2E までを含む内部設計書を、コードを書く前に整備した。
• 選択肢：個人開発なので設計は頭の中に置いて、まず動くものを作る。
• 理由：個人開発は中断が入る。2週間空けたときに、判断の理由が残っていないと同じ検討をやり直すことになる。
• 結果：判断の履歴が残ったことで、方針変更のときに「何を前提にその判断をしたか」から議論を始められるようになった。

React Native ＋ ネイティブウィジェット併用

• 判断：アプリ本体は React Native、ウィジェットはネイティブで実装する構成にした。
• 選択肢：フルネイティブ、あるいはウィジェットを諦める。
• 理由：サンクスカードの価値は「アプリを開かずに送れる」ことにあり、ウィジェットは体験の中心であって付属物ではない。一方で本体の画面数は多く、クロスプラットフォームの恩恵が大きい。
• 結果：体験の中心だけをネイティブに寄せ、残りを共通化するという線引きになった。

詰まったところ・失敗

Pulumi で IaC を運用している最中に、S3 の課金が想定外に膨らみました。インフラをコード化しただけでは、コストは自動的に管理されません。

学び

• 個人開発でも ADR と内部設計書は先に書いた方が速い。中断からの復帰コストが違う。
• IaC は構築を自動化するが、コストの監視は別に用意しないといけない。実際に払って学んだ。