賃貸管理アプリKosProの開発事例：課題からリリースまで

このブログの記事の多くは、ソフトウェア開発会社とどう協業するかをテーマにしています。今回は趣向を変えて、私たち自身の「台所」をお見せします。KosProは、私たちが自社で開発し、Google Playでリリースした下宿・賃貸管理アプリです。本記事では、KosProがどのように生まれたのか、つまり解決した課題、バージョン1で意図的に見送った機能、FlutterとSupabaseを選んだ理由、そして開発を通じて学んだことをご紹介します。

インドネシアでは、学生や単身の社会人向けに部屋を貸す「コス（kos）」と呼ばれる下宿型の賃貸物件が広く普及しており、個人オーナーが運営しているケースがほとんどです。KosProはそうしたオーナーのためのアプリです。

この記事は宣伝のためではありません。私たちの仕事の進め方を最も具体的に示す事例だからこそ書いています。業務用のアプリを検討している経営者の方であれば、同じパターンがおそらく御社のビジネスにも当てはまるはずです。

課題：誰も気づかない家賃の滞納

KosProのアイデアは、下宿オーナーがどのように事業を運営しているかを観察したことから生まれました。ほぼすべてが手作業です。支払いはノートに記録し、入居者には一人ずつWhatsApp（インドネシアで最も普及しているチャットアプリで、日本でいうLINEのような存在です）で連絡し、空室の状況はオーナーの頭の中にしかなく、整った収支レポートもありません。オーナーが複数の物件を持つと、問題は何倍にも膨らみます。

興味深いことに、最大の課題は記録そのものではなく、誰も気づかないまま放置される家賃の滞納でした。

• 入居者ごとに支払期日が異なり、それぞれの入居日に連動しているため、統一された「請求日」がない。
• 銀行振込による支払いが、口座の他の取引と混ざってしまう。
• 誰も督促していないため、支払いが遅れている入居者に何週間も経ってから気づくことが多い。
• オーナーが管理人に業務を任せたり、担当者が替わったりすると、支払い履歴も一緒に失われる。

まだAIが必要ないビジネスとはの記事をお読みになった方なら、まさにその実例だとおわかりでしょう。問題は「賢さが足りない」ことではなく、「整理されていない」ことです。解決策はAIではなく、入居者と請求のデータを一元化すること、状況を明確にすること、そしてリマインダーを自動化することでした。

ディスカバリー：まずは紙の上で設計する

1行のコードを書く前に、画面ごとのアプリフローと、物件一覧、部屋、入居者、通知、設定、レポートに至るまで、全ページのシンプルなワイヤーフレーム（ローファイ）を作成しました。このドキュメントがスコープの契約書になりました。そこにない画面は、バージョン1には入れません。

バージョン1が必ず答えるべきだと考えたのは、次の3点です。

1. 今月まだ支払っていないのは誰か、まもなく期日を迎えるのは誰か。
2. どの部屋が空いていて、どの部屋が埋まっているか。
3. 入居者ごとの支払い履歴。トラブルが起きたときの拠りどころになるように。

正直に言うと： 当初の希望リストははるかに長いものでした。決済連携、入居者向けポータル、複数管理者対応、さらには空室を一般公開して募集するアイデアまで。どれも魅力的に聞こえ、どれもリリースを遅らせるものでした。私たちは、MVPとフル機能プロダクトの違いでお客様におすすめしているのと同じ規律でそれらを削りました。そのうちいくつかは今もまだ作っていませんが、不満を言うユーザーはいません。

バージョン1のスコープ：4つのオブジェクトと1つのフロー

設計の結果、v1のスコープは4つのデータオブジェクトと1つのメインフローに固定しました。

メインフローはこうです。オーナーが物件と部屋を登録し、入居者を入力すると、アプリが毎月の請求を自動で作成し、そのステータスを色分けします。緑は支払済み、黄色は期日間近、赤は滞納です。請求をいつ支払済みとみなすかはオーナーが決め、部屋のページにあるボタン1つで操作できます。

意外に重要だった小さな点が1つあります。「期日間近」のしきい値は、当初7日に固定していました。実際に使われ始めると、3日がいいというオーナーもいれば、2週間がいいというオーナーもいました。現在は3日、5日、7日、14日から設定できます。教訓：作り手にとって「当たり前」の数字が、使い手にとっても当たり前とは限りません。

技術選定：FlutterとSupabase

Flutterを選んだのは、1つのコードベースでAndroidとiOSに対応でき、私たちが使い慣れているからです。このような業務アプリでは、「100％ネイティブ」な見た目よりも、改善サイクルの速さの方がはるかに重要です。

Supabaseを選んだのは、バックエンドをゼロから作らずに3つのものを一度に提供してくれるからです。PostgreSQLデータベース、認証（メールとGoogleサインインに対応し、オーナーが新しいパスワードを覚えなくて済むように）、そしてサーバー上の定期実行関数です。この定期実行関数によって、オーナーがアプリを開かなくても、毎月の請求が自動で作成され、滞納ステータスが毎日チェックされます。

PremiumサブスクリプションにはRevenueCatを使っています。これは最初の選択肢ではありませんでした。その経緯はKosProから学んだマネタイズの教訓で紹介しています。

技術者ではない読者の方にお伝えしたいのは、これら3つはいずれも何週間分もの作業を省ける既製サービスだということです。中小企業の業務アプリであれば、自前でサーバーを構築するより、こうしたサービスを使う方がほぼ常に賢明です。費用感についてはインドネシアでのアプリ開発費用 2026年版で解説しています。

想定より複雑だったこと：日付

最も些細に見えた機能、「毎月請求を作成する」が、実は最も時間を要しました。1月31日に入居した人の2月の期日はいつか。月の途中で部屋を移った入居者にはどう請求するか。一部だけの支払いは何として記録するか。サーバーとスマートフォンのタイムゾーンが違うと、請求が誤った日に作成されないか。

これらの問いは、どれ一つとして機能リストにはありませんでした。すべて作業中に浮かび上がってきたものです。だからこそ私たちは、お客様向けの見積もりに必ず「業務ルール」のためのバッファを含めていますし、SDLCにおけるテスト工程を削ってはいけない理由もここにあります。

検証のため、極端な規模のダミーデータを作成しました。各100室を持つ100物件で、滞納中、期日間近、支払済みの入居者もそろえています。1万室でもアプリがスムーズに動くなら、30室のオーナーが困ることはありません。

Google Playへのリリース

2026年4月初旬の最初のコミットから、2026年7月末のGoogle Playでの公開まで、KosProは小規模なチームで、他の業務と並行しながら約4か月かかりました。似たプロジェクトを見積もる際には参考になる数字です。1つの業種に向けたシンプルな業務アプリで、決済連携はないものの、サブスクリプションと自動化を備えたものです。

コーディング以外で時間がかかり、どんなプロジェクトでもスケジュールに含めておくべきことがいくつかあります。

• デベロッパーアカウントと本人確認。 法人名義のアカウントの場合、Googleは組織の本人確認を求めます。これには独自の待ち時間があります。
• 掲載素材。 アイコン、フィーチャーグラフィック、スクリーンショット、2言語の説明文、自社ドメイン上のプライバシーポリシー。すべて審査の対象です。
• 審査とコンプライアンス。 ユーザーアカウントとアプリ内課金を備えたアプリは、ユーザーデータの扱いも含めて、より厳しく審査されます。

iOS版も同じコードベースから、アプリ内課金の設定も含めて準備を進めており、後に続く予定です。

リリース後：想定していなかったこと

実際に他の人が使い始めると、設計時には思いつかなかったことがいくつか見えてきました。

1. ジャンクなアカウント登録。 使い捨てメールアドレスによる登録がありました。使い捨てメールドメインのブロックと、ログイン試行の記録を追加しました。バージョン2.0.1では、これがむしろメインのアップデートになりました。
2. 更新されない古いアプリ。 ユーザーは自動的にアプリを更新してくれるとは限りません。サーバー側が変わっても古いバージョンが壊れないよう、強制アップデートと推奨アップデートの仕組みを追加しました。
3. オーナーだけでなく入居者へのリマインダー。 最も多かった要望は「アプリが督促してくれないか？」でした。その答えがPremium機能です。オーナーが自分のWhatsAppをアプリに接続すると、編集可能なメッセージテンプレートで、入居者に請求のリマインダーが自動送信されます。

御社のビジネスに持ち帰れること

• 機能からではなく、ステータスから始める。 「誰がまだ払っていないか」という問いは、他の10の機能よりも価値があります。御社のビジネスでそれに相当する問いを見つけてください。
• 日付とお金のルールは、必ず想像以上に複雑です。 そのための時間を確保してください。
• コアビジネスでない部分には既製サービスを使う。 認証、データベース、サブスクリプションなど。自社で作るのは、プロダクトを差別化する部分だけにしましょう。
• 無料と有料の境界は最初から設計する。 それは価格だけでなく、データ構造にも影響します。

これは私たちがお客様のプロジェクトに取り組む方法でもあります。Cuplikinを含め、自社で開発するプロダクトは、そのプロセスをお客様向けのサービスに適用する前に検証する場なのです。

次のステップ

データが散在している、請求状況を把握できていない、業務が特定の人の記憶に依存しているなど、御社のビジネスにも似た課題があれば、ちょうどよい規模のアプリの設計をお手伝いします。無料相談から始めるか、WhatsAppでご連絡ください。メール（hello@rancanginaja.com）でもお問い合わせいただけます。