スプレッドシートで足りる範囲｜人事の副業で自分の管理（稼働ログ・請求と入金・アカウントの一覧・判断のメモ・改善の記録）は、表計算の一枚ずつで足りる。足りなくなるのは案件が増えたときではなく、依頼側の情報を置き始めたとき

副業の管理に、専用のツールを入れるべきか迷う。稼働の記録のアプリ、請求の作成のサービス、案件の管理のツール。便利そうだが、副業の枠で使いこなせるか分からず、費用もかかる。結論を先に書くと、人事の副業で自分が管理するもの（稼働ログ、請求と入金の記録、アカウントの一覧、判断のメモ、改善の記録）は、表計算の一枚ずつで足ります。案件が三件や四件になっても、列で案件を分ければ、一組のまま回ります。足りなくなるのは、案件が増えたときではなく、依頼側の候補者の情報を自分の表に置き始めたときです。それは表計算の限界ではなく、置く場所の間違いで、専用のツールに移っても解決しません。表計算で足りる範囲を知っておけば、ツールに投資する前に、自分の管理は整います。自分のツールの一組はよく使うツールに、稼働ログの付け方は稼働ログの付け方に、入金の記録は決済・振込先の準備にまとめています。

表計算で足りる五つの用途

自分の管理の五つの用途は、それぞれ表計算の一枚で足ります。列の設計だけ決めておきます。

五つの要点は、「どれも一枚で、案件の列かタグで分ける」ことです。案件ごとに表を作ると、案件が増えるたびに管理する場所が増えます。一枚の中で案件を列で分ければ、案件が増えても表は増えず、絞れば案件ごとに見られ、絞らなければ全体が見られます。表計算の絞り込みと集計の機能で、月末の集計も済みます。

足りなくなる合図と、その正体

表計算で足りなくなったと感じる場面と、その正体を見ます。多くは、表計算の限界ではありません。

合図の要点は、「候補者の情報を置き始めたときが、足りなくなる最初の合図で、それは表の問題ではない」ことです。候補者の情報は、依頼側のATSや共有の中で扱うもので、自分の表に置くことが情報の線を越えています。専用のツールに移しても、置く場所が自分の側であることは変わらず、線は越えたままです。置く場所を依頼側の側に戻せば、自分の表は軽いままです。情報の置き場は案件ごとの情報の分け方に書いています。

エラベルの見解

相談で最も多い思い込みは、「案件が増えたら、専用のツールが無いと管理できない」というものです。実際には、複数の依頼側を長く持っている担当者の多くは、自分の管理を表計算の一組で回しています。稼働ログ、請求、アカウント、判断、改善の五つの表を、案件の列で分けて持ち、月末に集計する。専用のツールを使っている人と、管理の精度に差はありません。

見ていて差がつくのは、表に何を置いているかです。自分の管理の情報だけを置いている人の表は、案件が増えても一組で軽いままです。候補者の情報や依頼側の資料を置き始めた人の表は、重くなり、案件の終了時に消す作業が要り、置き忘れると守秘の問題になります。エラベルでは、担当者の自分の管理は担当者のツールで、依頼側と候補者の情報は依頼側の仕組みで、と分けることを前提にしています。表計算で足りるかどうかは、表計算の性能ではなく、置くものを分けているかで決まります。

依頼側の候補者の管理に表を使う場合の線

依頼側にATSが無く、候補者の管理を表で行う案件があります。その場合、表は使いますが、自分の表ではありません。

線の要点は、「候補者の管理の表は、依頼側の共有の中に作り、依頼側のものにする」ことです。自分のクラウドに作ると、候補者の情報が依頼側の外に出て、終了時に消す作業が要ります。依頼側の共有の中に作れば、情報は依頼側の管理下に留まり、終了時はアクセスの停止だけで済み、依頼側には資産が残ります。依頼側に仕組みが無い場合の作り方はツールを統一するか合わせるかの「統一を依頼側に頼んでよい場面」に整理しています。

表を一組に保つ設計

案件が増えても表を一組に保つ設計の要点です。最初に決めておけば、増やさずに済みます。

設計の要点は、「工程の名前を揃える」ことです。稼働ログの工程と、稼働報告の工程と、改善の記録の工程が同じ名前なら、ログを集計すればそのまま報告になり、報告の数字がそのまま改善の記録になります。名前が違うと、表と表の間で写し直すことになり、時間がかかります。報告の型は稼働報告のフォーマットに書いています。

表計算で起きやすい失敗

表計算を使う中で、副業の担当者が起こしやすい失敗です。

失敗の要点は、「候補者の情報とパスワードを置かない」の二つが、最も重いことです。他の失敗は、手間や精度の問題ですが、この二つは情報の線の問題で、表が漏れたときの損が大きくなります。置かなければ、表が漏れても、稼働と請求と判断のメモで、依頼側の情報は含まれません。

専用のツールに移る判断

表計算から専用のツールに移す判断は、案件の数ではなく、用途ごとに見ます。移す必要が無いことも多いです。

判断の要点は、「移す必要があるのは稼働ログと請求だけで、それも独立や規模の拡大の段階」だということです。副業の範囲で、案件が数件なら、五つの用途は表計算で足ります。専用のツールは、便利に見えますが、覚える時間と費用がかかり、副業の枠を圧迫します。表計算で回っているなら、移す理由はありません。費用が経費になるかは経費にできるものを見たうえで、専門家にご確認ください。

エラベルの見解

担当する側から見ると、管理に時間を取られていない人は、専用のツールを使いこなしている人ではなく、表計算の一組を、案件の列で分けて、月末に集計の機能で回している人です。稼働ログを付けた日に集計が出て、稼働報告に写すだけで済み、請求の入金予定日の列を見れば遅れが分かり、アカウントの一覧の確認の列を見れば放置が分かる。全部が表計算の一組の中で済んでいます。専用のツールを入れた人が、それより速いわけではありません。

順番として、副業を始める前に五つの表を一組で作り、案件の列と揃えた工程の名前を持ち、候補者の情報とパスワードは置かないと決め、副業用のクラウドの一か所に置き、月末に集計の機能で出す。案件が増えたら、列で分けるだけで表は増やさない。依頼側の候補者の管理に表が要るなら、依頼側の共有の中に作る。この順番で、表計算は副業の管理に足り続けます。エラベルでは、担当者の自分の管理は担当者のツールで、依頼側の情報は依頼側の仕組みで、と分けることを前提にしています。表計算で足りるかどうかは、置くものを分けているかで決まります。

まとめ

• 自分の管理（稼働ログ・請求と入金・アカウントの一覧・判断のメモ・改善の記録）は、表計算の一枚ずつで足りる
• 足りなくなる合図は候補者の情報を自分の表に置き始めたとき。表の限界ではなく、置く場所の間違い
• 依頼側の候補者の管理に表を使うなら、依頼側の共有の中に作り、依頼側のものにする
• 一組に保つ設計は案件の列・揃えた工程の名前・月のシートを分けない・集計は自動・パスワードと候補者の情報は置かない・一か所・列を変えない
• 失敗で重いのは候補者の情報とパスワードを置くこと
• 専用のツールに移すのは稼働ログと請求だけ、しかも独立や規模の拡大の段階。副業の範囲では表計算で足りる

よくある質問

表計算の関数や集計の機能が苦手です。それでも足りますか

五つの表で使う機能は、絞り込みと、合計と、日付での並べ替え程度で、複雑な関数は要りません。集計の機能（表の範囲を選んで、案件ごと・月ごとに合計を出す機能）を一度覚えれば、月末の集計は数分で済みます。覚える時間は、最初の一回だけです。苦手なら、最初は手で合計しても構いませんが、月末の時間が増えるので、早めに集計の機能を一度試してみることを勧めます。

依頼側から「候補者の一覧を表で管理してほしい」と言われました。自分の表計算で作ってよいですか

自分のクラウドではなく、依頼側の共有の中に作ります。「御社の共有フォルダの中に表を作り、そこで管理する形でよいですか」と提案し、依頼側の共有に置きます。列は、状態、工程の日付、記録、連絡の履歴のように、ATSの骨格に合わせます。依頼側の共有に置けば、情報は依頼側の管理下に留まり、終了時はアクセスの停止だけで済みます。依頼側が「自分の側で」と言う場合は、置く情報の範囲と終了時の扱いを文面で確認し、副業用の端末とアカウントで、他の案件と混ぜずに扱います。線は守秘の線を越えるに整理しています。

稼働ログと請求の記録を、一枚の表にまとめてよいですか

分けたほうが管理しやすいですが、一枚のシートに複数の表を置く形でも構いません。大切なのは、稼働ログは日ごとの行、請求は案件×月の行、という粒度の違いを混ぜないことです。粒度が違うものを一つの表にすると、集計が難しくなります。同じファイルの中で、シートを用途ごとに分けるのが、一組に保ちつつ管理しやすい形です。表の設計は稼働ログの付け方と決済・振込先の準備に書いています。