「スプレッドシート、もう限界です」
2026年1月、以前スプレッドシートの改修を依頼いただいた方から、再度相談があった。
フリーランスのライターとして、月に6〜8万文字の執筆業務をこなしている方だった。
管理表は、以前外部委託でスプレッドシートを作ってもらっていた。過去のログを見て自己満足に浸ることもあるし、今月の受注状況を確認して、残りの文字数を計算することもある。
でも、GASと関数を組み合わせまくった複雑な構造で、本人も修正できない状態になっていた。
【Before】データベース構造になっていない管理表
初回の打ち合わせで、現状の管理フローを聞いた。
1. 執筆環境と文字数カウント
執筆は「VS Code」というコーディング用のソフトで行っている。小説も書けるという理由で使っているとのこと。
書いた文字数は、ファイルから文字数計算ソフトにコピペして、出た数字を手入力している。
2. 受注判断と文字数管理
月に6〜8万文字くらい受注していて、案件数ではなく文字数で管理している。
- 文字数がいっぱいになったら今月は打ち切って翌月分を受ける
- 今月分は何文字終えてるから残りは毎日これくらい書けば間に合う
活動量のアッパーが決まっていて、文字数ベースで受注判断が必要だった。
3. 手数料計算とクライアント管理
売上も管理したいが、仲介サイトによって手数料が引かれる。手数料率は金額によって違うため、手計算が必要だった。
請求書の送付先も管理したいが、請求書は1年ごとにフォルダーに入れてまとめている。再依頼があった時は、このシートで過去の履歴を見て、請求書フォルダーからコピーして作っている。
4. スプレッドシートの限界
元々Excelでごちゃごちゃにまとめていたものを参考に、外部委託でスプレッドシートを作ってもらった。見た目もどんどん足していっている感じだった。
でも、データベースの構造になっていなかった。
GASと関数を組み合わせまくって、なんとか表現している状態。本人も修正方法がわからず、困っていた。
【Notice】改修ではなく、Notion移行という選択
当初は「スプレッドシートの改修」という依頼だった。
でも、私はこう判断した。
「今後のメンテナンス性を考えると、Notionに移行した方がいい」
1. クライアントDBと案件DBを分ける
スプレッドシートでは、クライアント情報と案件情報が混在していた。
Notionなら、クライアントDBと案件DBを分けて、リレーション機能で紐付けられる。
- クライアントDB: 請求書の送付先、連絡先、過去の取引履歴
- 案件DB: 案件ごとの文字数、納期、進捗状況、報酬
この設計なら、再依頼があった時も、クライアント名で検索すれば過去の請求書情報がすぐ見つかる。
2. 文字数の自動集計
Notionのフォーミュラ機能を使えば、文字数の自動集計ができる。
- 今月の総文字数
- 完了した文字数
- 残りの文字数
- 残り日数で割った1日の目標文字数
これで、毎回手計算する必要がなくなる。
3. 時間計測とAI活用の可能性
Notionなら、執筆開始時にボタンを押して時間を測ることもできる。
また、週報をAIに作ってもらってモチベーションに繋げたり、執筆の相談をAIにすることも可能だ。
情報を一箇所にまとめることで、拡張性が生まれる。
【After】「情報を一箇所にまとめる」価値
提案を聞いた相談者からは、こんな言葉があった。
「情報を一箇所にまとめられるのはいいですね」
これが、Notion移行の最大の価値だ。
- GASと関数の組み合わせは、属人化する： 外部委託で作ったスプレッドシートは、作った本人しか理解できない。データベース構造にすることで、メンテナンス性が上がる
- DBを分けて、リレーションで紐付ける： クライアント情報と案件情報を分けることで、情報の重複を避け、管理を簡素化できる
- 文字数の自動集計で手作業を削減： フォーミュラ機能を使えば、残り文字数や1日の目標文字数を自動計算できる
- 改修よりも、移行を選ぶ判断： 複雑化したスプレッドシートを修正し続けるより、データベース構造に移行した方が、長期的なメンテナンスコストが下がる
「カツカツ」のスケジュール管理を、少しでも楽に
相談者は、子供がいて、最近はちょっとカツカツだと話していた。
だからこそ、毎日の文字数目標を自動計算できることが重要だった。
スプレッドシートからNotionへの移行は、単なるツールの変更ではない。
「手作業を減らして、本質的な仕事に集中する」ための設計だ。