既存アプリを「設計図」にして、AIで別スタックへ移植する ── SwiftUIアプリをFlutterに作り直した話
日程調整アプリ soroe は、ゼロから設計したのではなく、既存の SwiftUI アプリ wari-ios を「設計図」として Claude で Flutter / Riverpod へ移植して作った。鍵になったのは、レイヤーの構造対応表を先に用意すること。AIに移植させるときの渡し方を書く。
続きを読む →シフト制の職場で、希望をどうやって集めているか。 おそらく多くの現場は、この形に落ち着いています。
このやり方は、人数が少ないうちは一番早い。新しく何かを覚える必要がなく、 全員がすでに LINE を使っているからです。
問題は、どこで限界が来るかです。
シフトを組む作業を分解すると、実際に時間を食っているのは 「組む」ところではありません。
| 手間 | 内容 | 人数が増えるとどうなるか |
|---|---|---|
| ① 転記 | LINE の文面を表に写す | 人数に比例して増える |
| ② 催促 | 出していない人を探して声をかける | 人数に比例して増える |
| ③ 変更の反映 | 「やっぱりこの日は無理」への対応 | 人数 × 変更回数で増える |
「組む」こと自体は、希望が揃ってさえいれば案外すぐ終わります。 つらいのは、揃うまでと揃ったあとです。
LINE で集めると、書き方が人によって違います。
「5、6、12、13以外なら入れます」 「平日の夕方だけ大丈夫です」 「来週は無理ですが再来週から」
これを表に写すとき、解釈が入ります。「平日の夕方」は何時から何時か。 「来週」はどこまでか。ここで取り違えると、確定後に「そんなつもりじゃなかった」になります。
転記ミスは、起きた時点では気づけません。確定して初めて発覚するのが厄介なところです。
締切を過ぎて出していない人に、個別に声をかける。 これが、実は一番の負担だという話をよく聞きます。
グループに「まだの人はお願いします」と流しても、 自分のことだと思わない人には届きません。個別に送ると角が立つ気がして、 送るまでに時間がかかります。
必要なのは 「誰が出していないか」が一覧で見えること、それだけです。 一覧で見えれば、催促は事務作業になります。見えないから、記憶と気遣いの作業になる。
確定後に「この日どうしても外せない用事が入った」と言われる。 これ自体は仕方のないことです。
問題は、確定シフトが画像で配られていること。 画像は直せないので、作り直して流し直すことになります。 そして、古い画像がグループの上のほうに残り続けます。
「どれが最新か分からない」が起きるのは、だいたいここです。
経験的には、5〜6人が分かれ目のように思います。
人数だけでなく、シフトの複雑さでも変わります。 時間帯が1種類(例: 9-17時だけ)なら人数が多くても回りますが、 早番・遅番・中番があると、途端に表が読めなくなります。
いきなり全部を変えると、現場が止まります。効く順に一つずつ。
3 まで来ると、そもそも LINE で集める必要がなくなっている、ということが多いです。
soroe は、この3つをそのまま形にしたアプリです。
スタッフ側は招待リンクからブラウザで参加できるので、 「全員にアプリを入れてもらう」ところで止まりません。 iOS / Android のアプリ版もあります。
操作は使い方ガイドに画面図つきでまとめています。
大事なのは、いまの運用が悪いわけではないということです。 LINE とエクセルは、人数が少ないうちは最適解です。 限界が来たときに、どこが重くなっているのかが分かっていれば、 直す場所を間違えずに済みます。
日程調整アプリ soroe は、ゼロから設計したのではなく、既存の SwiftUI アプリ wari-ios を「設計図」として Claude で Flutter / Riverpod へ移植して作った。鍵になったのは、レイヤーの構造対応表を先に用意すること。AIに移植させるときの渡し方を書く。
続きを読む →予定を「揃える」日程調整アプリ soroe の iOS 版・Android 版を公開しました。これまで Web 版で提供してきた機能を、App Store / Google Play からアプリとしてご利用いただけるようになりました。
続きを読む →