スプレッドシートは十分に役立つ業務ツールです。細かな権限、判断の履歴、確実な引き継ぎが必要になり、今の運用では対応しにくくなったときに置き換えを検討しましょう。行数の多さだけでは、アプリを開発する理由になりません。まず、シートの整理や既存製品で解決できないか確認します。
一つの業務フローから始める
架空の保守チームを例に、依頼の登録から完了までを追います。誰が登録し、誰が技術者を割り当て、誰が完了を確認するのでしょうか。必要な項目は、その判断を支える依頼ID、設備、日付、担当者、状態です。
すべてのタブをそのまま画面にする必要はありません。最初は一覧、依頼の詳細、担当者の割り当て操作だけで足りるかもしれません。
テストできるルールを書く
デザインより先に、具体的な動作を決めます。
- 技術者は担当する依頼を更新できるが、他人の担当割り当ては変更できない。
- 調整担当者は割り当てと完了処理を行い、完了前に必須情報がそろっていることを確認する。
- 取り込み時に依頼IDの重複や不明な設備参照があれば、確認対象として示す。
- 同じ依頼を同時に編集した場合は競合を表示し、変更を黙って上書きしない。
ボタンを隠すだけでは不十分で、サーバー側でも権限確認が必要です。OWASPの認可ガイドがその境界を説明しています。これらは受け入れテストにする項目であり、安全性の保証ではありません。
説明から初期計画をつくる
無料ツールには、匿名化した列と役割を入力してください。データモデル、権限、画面、移行手順の案が得られますが、アカウントへの接続やデータ移行は行いません。仕様として使う前に、前提を確認し、修正しましょう。
全面移行の前に試す
空欄、重複、例外的な状態を含む、小さな代表サンプルで試します。試行中の正本となるシステム、取り込みエラーの担当者、検証済みバックアップからの復元方法を決めてください。二つのデータを別々に編集し続ける運用は避けます。データベースの制約はルールを支える手段です。PostgreSQLの文書に例がありますが、技術の指定ではありません。
業務に不要なら、請求、高度なダッシュボード、AIは初版の対象外にします。役割、ルール、画面、テストを短い資料にまとめることが次の一歩です。個別開発が適切なら、TurboV1に見積もりの目安を依頼し、開発前に範囲と前提を確認できます。