事業コックピット — 今やらない欄は、畳んでおくことにしました

副業の準備を進めると、判断材料が少しずつ散らばります。使える時間、予算、事業の候補、登録したサービス。次に何をするかを考えるたびに、それぞれを見に行く必要がありました。

その材料を1画面に置いたのが、事業コックピットです。最初はメールアプリを作るつもりでしたが、用途を整理して作るものを変えました。

9月5日の見直し：すでにある記録を入口にする

初版を点検すると、事業の方針や運用は別のメモで進んでいるのに、この画面の判断欄や台帳は空のままでした。すでに書いてあることを、ここにも入力する前提の設計でした。

そこで、入口を変えました。事業の方針、媒体の運用、問い合わせメールの準備状況を、元のメモから読めるようにしています。更新日時と、どの記録を読んでいるかも表示します。この時点では、メモの本文をアプリ側に複製せず、元の記録をそのまま読む形にしました。

以前の判断欄、候補、メール、台帳は「補助の記録」にまとめ、最初は畳んでいます。まず今の記録を読み、必要なときだけ補助の欄を開く形です。

同日の追加：事業の軸とサービスを結ぶ

さらに、副業ごとの目的・今の段階・次の一手と、使うサービスを結び付ける画面を追加しました。構想や保留の軸は畳み、進めている軸から開けます。複数の軸で使うサービスは、共通の基盤として並べます。

サービスごとに、プラン・費用・更新予定・最後に確認した日を記録できます。金額が分からなければ未確認のまま残し、無料とは区別します。元の記録の本文は引き続き参照し、一覧に必要な項目を手元の台帳で管理する形にしました。

画面を開いている間は、保存済みの運用記録を1分ごとに読み直します。このサイトの応答とGitHubの公開処理も、10分間隔で確認する仕組みを加えました。パソコンとアプリの裏側の処理が動いていることは必要です。この時点では、契約プランや請求額を自動で取り込む連携はありませんでした。

9月7日の追加：配信予定をカレンダーで見る

記事やSNSの配信予定と、自動処理の説明も文章で並べていました。日付と作業の流れを見比べられるよう、配信カレンダーと運用の流れを示す図を追加しました。事業で絞り込み、予定を開くと、何をいつ配信するかと、どの記録から表示しているかを確認できます。

原稿に日付があること、投稿サービスが予約を受け付けたこと、実際に配信されたことは、それぞれ別の状態で表示します。日付しか記録していない予定に、公開した時刻を補うこともしません。元の原稿や配信記録を読み直すので、カレンダーをもう一つ手で更新する必要はありません。

運用の図では、原稿の準備、公開、予約配信、確認、改善をつなぎ、パソコンで動く工程とクラウドで動く工程を分けました。パソコンを閉じた後も受付済みの予約は配信できますが、次の原稿を作って補充する処理にはパソコンの稼働が必要です。この区別も画面で確認できるようにしています。

9月13日の追加：契約費用と、支払った金額を分ける

使うサービスが増えると、毎月の負担が見えにくくなります。利益を考えるためにも、サービスをAI・開発、ASP（広告の仲介サービス）、メールなどにまとめ、契約費用を月額で見られるようにしました。年払いは12か月に分け、その月に実際に払った金額は別に表示します。

Gmailの請求・契約・解約メールを確認し、根拠を付けて台帳へ取り込む仕組みも加えました。請求書と支払完了の通知が両方届いても、同じ取引を二度数えないようにしています。別のアカウントで契約したサービスは手動でも登録でき、概算にはその印を付けます。

メールの確認はCodexの定期実行で行います。パソコンとCodexの起動が必要で、メールが届いた瞬間に反映される方式ではありません。最後に確認できた時刻と、更新の失敗も画面に残します。初回の取り込みと、同じメールを読み直しても支払額が増えないことを確認しました。日々の更新が続くかは、これから確かめます。

ここから先は、8月31日に作った初版の構成です。掲載している画面も初版の説明用サンプルです。

今いる段階と、次へ進む条件

画面を準備・検証・収益の3段階に分けました。

準備では使える時間や予算を決めます。検証では「いつまでに、何が分かれば進めるか」を候補ごとに書き、お金が動き始めたら必要な手続きも扱います。段階名だけでなく、何が揃えば次へ進めるかを表示します。

空のテーブルを並べない

事業一覧、アカウント台帳、お金の手続き。全部の欄を最初から出せば、完成した管理アプリらしく見えます。でも、準備中の僕に必要なのは、その全部ではありません。

そこで、今の段階で使わない欄は畳みました。

欄を隠すだけでは、あとで理由を忘れます。だから、時間や予算が決まらないまま候補の作り込みを始めないためだと、その場に書きました。

判断材料が揃うと、候補を扱う欄が開きます。

合格基準は結果が出る前に書きます。あとから「まあ手応えはあった」と済ませないためです。

メールは受信専用にしました

このアプリで扱うのは、サービス登録や請求に使う管理者用IDです。そこから外へ送る用途はないので、送信の仕組みは作っていません。

メールは、件名などで分かるものを先に仕分け、迷うものだけAIに見てもらいます。AIを呼べないときは「その他」に残すようにしました。

登録通知から、使っているサービスの一覧を作る機能も付けました。この初版の受信機能は未接続のまま残しています。9月13日に追加した費用管理では、CodexのGmail連携を使って請求などの必要なメールを確認する形にしました。

何で作ったか

保存したデータから、人が読むためのメモも自動で作ります。アプリとメモの両方を手で書き直すと食い違いそうなので、直す場所は1つにしました。

使い続けられるかは、これから

初版を作ったのは8月31日です。9月5日に事業の軸とサービスを結ぶ画面を追加し、7日には配信予定と自動処理の流れも見渡せる形にしました。13日にはメールを根拠に費用を更新する仕組みも加えました。この作りで何か月も使い続けられるかは、まだ分かりません。

ポイ活マネージャーでは、集めた数字を見る用事がありました。このアプリでも、判断材料をまとめたことで、次にすることを決めやすくなるかを見ていきます。

似た画面を作るなら、最初に今日使う欄と、まだ使わない欄を分けてみるとよさそうです。僕には、全部埋めるよう迫られない画面のほうが合っています。