セットリストは「順序のあるプログラム」を共有する問題
セットリストの管理は、一見すると単なるメモの共有に見えます。しかし実際に扱う対象は「順序があり、時間の合計に意味があり、複数人が同じものを見ながら本番で参照するデータ」です。この 3 つの性質が揃うと、汎用のメモアプリや表計算では扱いにくくなります。
この記事では、こうしたツールを設計するときに判断が必要になる論点を 6 つ挙げ、Setlii がそれぞれどの選択をしているかを書きます。他のツールを検討する際の比較軸としても使えます。
論点 1：曲以外の要素をどう扱うか
ライブの進行には、曲だけでなく MC や演出、転換が含まれます。これらを「曲のリストに付随する備考」として扱うか、「曲と同格のアイテム」として扱うかで、設計は大きく変わります。
| 方式 | 利点 | 欠点 |
|---|---|---|
| 曲だけを並べる | 構造が単純で入力が速い | MC の時間が合計に入らず、実際の尺とずれる |
| MC・演出も同格に並べる | 合計時間が実態に近くなる | アイテム種別の管理が必要になる |
Setlii は後者を採っており、曲・MC・演出を同じリストに並べられます。持ち時間の管理を重視するなら、この方式でないと計算が合いません。
論点 2：共有相手にアカウントを要求するか
セットリストを見る人は、バンドメンバーだけではありません。PA、照明、対バン相手、会場スタッフ、そして観客が含まれます。これらの相手全員にアカウント登録を求めるのは現実的ではありません。
Setlii は、ログインが必要な共有と、URL を知っていれば誰でも閲覧できる公開共有の両方を持たせています。渡す相手によって切り替えられることが前提だと考えているためです。
論点 3：通信が不安定な場所で使えるか
ライブハウスやスタジオは地下にあることが多く、電波が届きにくい環境です。本番直前に開けないツールは、どれだけ機能が豊富でも使われません。
この制約は、データの取得方法とキャッシュの持ち方に直接影響します。オンラインでの取得だけを前提にした設計にすると、いちばん必要な場面で開けないことがあります。なお Setlii は現時点でオフライン編集には対応しておらず、閲覧・編集とも通信が必要です。ここは今後の検討事項として残っている論点です。
論点 4：入力コストをどこまで下げられるか
曲ごとにキー、テンポ、演奏時間、メモ、参考音源を入力できるようにすると、機能としては充実します。一方で、入力必須の項目が増えるほど最初の 1 件を作るハードルは上がります。
- 曲名だけで登録できること
- 詳細は後から埋められること
- 一度入れた曲を別のセットリストへ流用できること
Setlii ではライブラリ機能がこの 3 つ目にあたります。同じ曲を毎回入力し直す運用になると、続かないためです。
論点 5：ステージ上での操作性
本番中は、暗い場所で、片手で、数秒以内に目的の情報へたどり着く必要があります。画面が明るすぎない、文字が大きい、タップ回数が少ない——このあたりは機能一覧には現れませんが、実用性を左右します。
逆に、本番中に編集する機能はほとんど使われません。編集は準備段階の操作であり、本番中は閲覧に最適化されているほうが実態に合います。
論点 6：誰のものとしてデータを持つか
バンドで使うツールでは、データの所有者をどう定義するかが後々効いてきます。個人アカウントにすべてがぶら下がる設計だと、その人が抜けたときにセットリストごと失われます。
| 持ち方 | 利点 | 問題になる場面 |
|---|---|---|
| 個人アカウント単位 | 実装が単純。1 人での利用に向く | 脱退・アカウント削除でデータが消える |
| グループ（バンド）単位 | メンバーの出入りに耐える | 権限管理の設計が必要になる |
Setlii はバンドを 1 つの単位として扱い、その配下にセットリスト・ライブラリ・メンバーがまとまる構造にしています。掛け持ちしている場合は、バンドごとに作成して切り替えます。
Setlii が備えている機能
| 機能 | 内容 |
|---|---|
| セットリスト | 曲・MC・演出を順序付きで管理。キー、テンポ、メモ、参考音源を付与できる |
| ライブラリ | よく使う曲をテンプレートとして保管し、複数のセットリストへ流用する |
| バンド | バンド単位でセットリスト・ライブラリ・メンバーをまとめ、編集権限を分ける |
| 共有 | URL による公開共有と、ログインが必要な限定共有を切り替える |
| リハーサル録音 | 録音を保存し、時間範囲を指定してコメントを残す |
| マルチプラットフォーム | iPhone アプリと Web ブラウザの両方に対応 |
技術構成
クライアントは Flutter で実装し、iOS 版と Web 版を同じコードベースから提供しています。バックエンドはノーコード型の BaaS である Xano を利用し、認証は Apple / Google / LINE 連携とメールアドレスに対応しています。
Web 版を用意しているのは、共有相手がアプリを入れていない場合でも開ける必要があるためです。論点 2 の判断が、そのまま構成の選択に反映されています。
クロスプラットフォームで作る場合の一般的なトレードオフ
| 観点 | 単一コードベース | プラットフォーム別実装 |
|---|---|---|
| 開発工数 | 少ない | 2 倍近くかかる |
| UI の作り込み | 各 OS の作法から離れやすい | OS ごとに最適化できる |
| Web 対応 | 同じコードで出せる | 別途実装が必要 |
| ネイティブ機能 | プラグイン頼りになる場面がある | 直接扱える |
個人〜少人数で開発し、かつ Web 版が必須という条件であれば、単一コードベースを選ぶ合理性は高くなります。逆に、OS 固有の体験を突き詰めたい場合は判断が変わります。
今後の検討事項
- バンド単位の有料プラン：共有先での広告非表示、録音容量の拡張、PDF 出力などを検討しています
- 共有 URL の OG 画像生成：SNS で共有したときにセットリスト名とバンド名が入ったプレビューを出す
- 予定とセットリストの統合：ライブの日程管理をセットリストと同じ場所で扱えるようにする
- セットリストの構成提案：過去のデータをもとに構成案を提示する。優先度は上記の後
いずれも検討段階であり、実装時期や仕様は確定していません。順序は利用状況を見ながら判断する予定です。
ご意見をお寄せください
「こういう使い方をしたい」「この操作が面倒」といったご指摘は、仕様を判断するうえで大きな手がかりになります。アプリ内のサポート、もしくは サポートページ からお送りください。