care-kiroに対して、実際に触って意見をもらえる人が少しずつ増えてきた。しばらく開発がゆっくりになっていたけれど、ベータ品質を上げて正式リリースに向かう時間にしたい。
care-kiroをもう一度しっかり進めるタイミングが来た気がしている。しばらくは他の実験やPark Labs本体の改善に時間を使っていたけれど、実際に触ってフィードバックをくれる人が少しずつ増えてきた。
🔬 なぜ今care-kiroなのか
care-kiroは、訪問看護師向けの記録管理と経費精算を出発点にしたサービスだ。最初の問題意識は、訪問の合間に発生する細かい記録や確認作業を少しでも楽にしたい、というものだった。
ただ、実際の業務フローを見ていくと、これは個人向けツールだけでは終わらないことが分かってきた。看護師が記録しても、ステーション側で確認する必要がある。経費は承認が必要になる。予定は組織全体のスケジュールとつながっている。
つまりcare-kiroは、B2CとB2Bの間にあるサービスだ。看護師個人にとって使いやすい入口が必要でありながら、ステーション側の管理フローにも自然につながらないといけない。
最近は、このサービスに対して具体的なフィードバックをもらえる機会が増えてきた。まだ大きな数字ではない。でもこの段階で大事なのは規模よりも密度だ。「現場では実際こう動いている」という話は、どんな仮説よりも強い。
📊 ベータで見えてきたこと
これまでのベータは、完成した製品を大きく広げる段階というより、方向性を確認するための段階だった。
業務フローはつながっている
記録、予定、経費精算は別々の機能ではなく、1日の仕事の中で連続している。
看護師とステーションでは見たいものが違う
看護師は素早く入力したい。ステーションは確認、承認、全体把握が必要。同じデータでも、役割によって見せ方を変える必要がある。
モバイルは後回しにできない
訪問看護は机の前だけで完結しない。移動中、訪問直後、短い空き時間に入力できることが大事だ。PWAとFlutterアプリの両方を考える理由はここにある。
機能数より信頼感
医療やケアに近い領域では、機能が多く見えることよりも、データが安全で、動きが予測できて、不安なく使えることの方が重要だ。
🔄 開発が少し止まっていた理由
正直に言うと、care-kiroの開発はずっと同じ速度では進められなかった。Park Labs本体の改善、AdSense再申請の準備、他の実験、ラボノートの整理などに時間を使っていた。
これは言い訳というより、ひとり開発の現実だと思う。ひとつを深く進めると、別のものは遅くなる。全部を同時に触ると、どれも浅くなる。care-kiroは特に現場理解とフィードバックが重要なサービスなので、浅く触り続けるより、集中できるタイミングでしっかり戻る方がいいと考えていた。
そして今、そのタイミングが来ている。フィードバックをもらえる人が増え、方向性も前よりはっきりしてきた。「いつか戻る」ではなく、「今戻るべき」に近い。
🛠️ アルファを見直し、ベータを磨く
正確に言うと、ベータからアルファに戻るという意味ではない。すでにあるベータを土台にして、内部的にはアルファのチェックリストをもう一度確認し、外部的にはより安心して使えるベータ品質まで上げていくという意味だ。
アルファチェック
データ構造、権限、記録フロー、経費精算フロー、役割ごとの境界を見直す。
ベータ改善
実際のユーザーが詰まる場所、モバイルで使いにくい場所、説明が足りない場所を優先して直す。
正式リリース準備
料金、オンボーディング、問い合わせ対応、利用規約、プライバシー、運用手順など、製品の外側も整える。
この段階で大事なのは、大きな新機能を足すことではない。「これは業務で使っても大丈夫そう」と感じられるかどうかだ。
💡 これから重視すること
次の開発では、実際のフィードバックを中心に置きたい。
ここは勝手に想像しすぎない方がいい。訪問看護の現場はすでに複雑だ。care-kiroがその複雑さを増やしてしまったら意味がない。
だからしばらくは、たくさん作るよりも、正しいものを作る時間にしたい。
🎯 次にやること
care-kiroは、Park Labsの中でも大事な実験だ。広告収益を試すサービスもあれば、ハッカソンで検証したサービスもある。その中でcare-kiroは、実際の仕事の不便を減らすことにかなり近い。
フィードバックをもらえる人が増えてきた今、このタイミングをちゃんと使いたい。アルファのチェックリストを見直し、ベータ品質を上げ、正式リリースに向けた準備をひとつずつ進めていく。
まだやることは多い。でも、もう一度手を動かす理由は十分にある。