Loading Park Labs...
Loading Park Labs...
ケアキロの開発中に、大事な気づきがあった。訪問看護師向けのアプリを作っていたけど、ステーション管理者の機能も欠かせないと気づいたのだ。だから2月初めの今、ケアキロを看護師個人のアプリから、看護師とステーション管理者をつなぐプラットフォームに変えている。今のユーザーは10人で、看護師向けのPWAとランディングページは1月末に作った。

看護師が「このアプリ使いたい!」と言っても、ステーション(事業所)が対応していなければ100%は活用できない。たとえばこうだ。
Table 1
| 看護師がすること | ステーション側で必要なこと |
|---|---|
| 勤務日誌 | ステーション管理者の確認・承認 |
| 経費精算 | 管理者の決裁フロー |
| スケジュール管理 | ステーション全体のスケジュールとの連動 |
| 患者情報 | ステーション単位での管理 |
個人アプリには限界がある。
もともとは看護師個人用の業務管理アプリだった。最初はシンプルだったけど、プラットフォームへ方向を変えたことで、今は5つのシステムが連携する構造になった。
Table 2
| システム | 説明 | 状態 |
|---|---|---|
| ランディングページ | サービス紹介・会員登録への誘導 | 運用中 |
| 看護師向けWebアプリ | PWAベースの業務管理 | 運用中 |
| 看護師向けモバイルアプリ | Flutterのネイティブアプリ | 準備中 |
| ステーション管理者ページ | 管理者用ダッシュボード | 開発中 |
| 運用者コンソール | システム全体の管理 | 開発中 |
ひとり開発だから、自動化なしではやっていけない。システムがここまで大きくなると、手動デプロイは無理だ。そこでGitHub ActionsでCI/CDパイプラインを作った。push 1回で全部デプロイされる仕組みだ。
%% git pushのあとに動くGitHub Actionsのジョブ・2月5日時点
flowchart TD
A["git push"] --> B["detect-changes・変更ファイルを検知"]
B --> C["deploy-landing・ランディングページ"]
B --> D["deploy-web・Webアプリ"]
B --> E["deploy-station・ステーション管理者ページ"]
B --> F["deploy-console・運用者コンソール"]ステーション管理者ページを集中して作っている。主な機能はこれだ。
B2B SaaSは、関わる人すべてを考えなければならない。個人ユーザーだけを見ていてはだめで、組織の中でどう使われるかを先に描く必要がある。
今回の気づきで、方向が少しはっきりした気がする。看護師もステーションも使えるサービスになれるかどうかは、やってみないとわからない。