ケアキロ進化 - 看護師アプリからプラットフォームへ

ケアキロ開発中に重要な気づきがあった。

現在、care-kiroは初期ユーザー10人ほどに使ってもらいながら改善している。まだ小さな数字だけど、訪問看護のような業務領域では、10人の実ユーザーから得られる学びはかなり大きい。公開ページでは看護師向けの利用を前面に出していて、管理者向けは準備中という位置づけだ。だから今は、看護師個人の使いやすさを大事にしながら、将来的にステーション利用へ広げる道筋も見ている。

💡 重要な発見

訪問看護師向けのアプリを作っていたけど、

ステーション向けの導線も考える必要があると気づいた。

なぜステーション向けの視点が必要か？

看護師が「このアプリ使いたい！」と言っても、

ステーション（事業所）の運用と相性が悪いと、継続利用が難しくなる。

例えば：

個人アプリとしての使いやすさと、業務サービスとしての広がりは分けて考える必要がある。

最初は、看護師さん個人の作業を楽にすることだけを考えていた。日誌を簡単に書ける。スケジュールを見られる。必要な情報を整理できる。それだけでも価値はあると思っていた。

でも実際の業務は、個人だけで閉じていない。訪問看護はステーション単位で動く場面も多い。記録、経費、月次レポートのような情報は、個人が入力した後に別の人が確認したり、組織のルールに沿って扱ったりする可能性がある。

つまり、看護師さんにとって便利であることが最初の価値で、そこからステーション側の負担を増やさずに広げられるかが次の課題になる。ここを分けて考える必要があった。

🔄 ピボット：アプリからプラットフォームへ

だから今、方向を変えている。

- 以前: 看護師個人用の業務管理アプリ

- 変更後: 看護師個人の利用を起点に、ステーション利用にも広げられる業務サービス

これは単なる機能追加ではなく、プロダクトの見方そのものの変更だ。個人向けアプリなら、UIの使いやすさと個人の便利さが中心になる。ステーション利用まで考えると、共有、権限、組織設定、データの扱い方まで考える必要がある。

正直、開発範囲はかなり広がる。でも、care-kiroはB2CとB2Bの両方の性格を持つサービスだ。現場で使われ続けるには、個人の便利さを削らずに、組織としても扱いやすい形へ少しずつ近づける必要がある。

📈 システムが大きくなった

最初はシンプルなアプリだったけど、

今は複数の入口を見据える構造になってきた。

この構成にしたことで、care-kiroはただの記録アプリではなく、業務サービスとしての性格が強くなってきた。逆に言うと、運用コストも増える。ログイン、権限管理、データの整合性、通知、デプロイ、障害対応。ひとりで見るには少し大きい。

だからこそ、最初から全部を完璧に作るのではなく、ユーザー10人の現場で本当に必要な部分から作る。今はその段階だ。ステーション向けの機能も、理想の管理画面を全部作るのではなく、まず「共有されるべき情報は何か」「誰がどのタイミングで見るのか」を整理したい。

⚙️ CI/CD自動化

1人開発だから、自動化なしではやっていけない。

GitHub ActionsでCI/CDパイプラインを作った：

git push → 自動検知 → 必要なシステムをデプロイ

- detect-changes: 変更されたファイルを検知

- deploy-landing: ランディングページをデプロイ

- deploy-web: Webアプリをデプロイ

- deploy-station: ステーション向け機能を追加した場合にデプロイ

- deploy-console: 運用者コンソールを追加した場合にデプロイ

push 1回で必要な部分だけデプロイされる構造にしていきたい。

この自動化はかなり重要だった。手動デプロイだと、複数の入口を毎回確認して反映するだけで疲れる。ひとり開発では、デプロイ作業に集中力を奪われると、肝心のプロダクト改善が進まない。

自動化しておけば、修正を小さく出せる。初期ユーザーからフィードバックが来たら、すぐ直して出す。この速度が、今のcare-kiroには必要だ。

🚀 開発状況

ステーション向けに必要な導線を整理している。

ステーション向けで検討している主な機能：

特に優先しているのは、看護師側で入力された情報が、必要な相手に自然に届く流れだ。ここがつながると、care-kiroは「個人の記録アプリ」から「ステーションでも使える業務ツール」に近づく。

ステーション向けにやりたいことは多いが、最初のMVPでは次の3つに絞る。

経費精算や統計は重要だけど、最初から全部入れると複雑になる。ユーザー10人の運用を見ながら、どこから広げるか決めたい。

🧪 ユーザー10人からの学び

ユーザー10人まで増えたことで、開発の優先順位が少し変わった。作りたい機能ではなく、使われるために必要な機能を先に見るようになった。

例えば、入力フォームの項目を増やせば情報量は増える。でも現場では、入力が長くなるほど使われなくなる可能性がある。ステーション向けの機能も同じで、ダッシュボードを豪華にするより、確認すべきものが迷わず見える方が大事だ。

小さなユーザー数でも、実際に使ってくれる人がいると、仮説の質が変わる。「こうしたら便利そう」から「これがないと運用に乗らない」に変わる。この違いは大きい。

🎯 今回の教訓

B2CとB2Bの両方を持つサービスは、入口を分けて考えるべき。

看護師さんがすぐ使えること。

ステーションでも無理なく扱えること。

この2つは似ているようで、設計の焦点が少し違う。

そして1人開発で自動化は選択ではなく必須。

システムが大きくなるほど手動デプロイは不可能になる。

この気づきで方向がもう少し明確になった気がする。

看護師もステーションも使えるサービスになれるかどうかは、やってみないとわからない。

次にやることははっきりしている。

care-kiroは、Park Labsの中でも一番「実運用」に近い実験になっている。だから急ぎすぎず、でも止まらずに進めたい。