平日の日中は1つの案件で運用保守にあたり、合間の時間に別の案件の設計判断にも関わる。複数の案件を並行させる働き方に関心はあっても、実際にどこまで抱えられるのか、踏み出せずにいるエンジニアは少なくありません。

この記事では、データベース・データ基盤の案件を軸に、2つの案件を並行させる週の組み方と、そこで壊れやすい箇所を先に整理します。掛け持ちを前提にした報酬の考え方にも触れながら、公的データとRemoguの調査データをもとに見ていきます。

1. DB・データ基盤の案件が掛け持ちと相性が良い理由

データベースやデータ基盤の運用は、常時張り付く仕事ではなく、定常監視と計画的な作業の組み合わせで成り立つ場面が多くあります。この波の読みやすさが、複数の案件を並行させる働き方と相性が良い理由です。まずは、その背景にある需要側の事情から確認してみましょう。

常勤で1人分の稼働を確保できない企業が増えている

IPAの調査によると、日本企業の85.1%でDXを推進する人材が不足していると報告されており、米国やドイツと比べても著しく高い水準です¹。常勤で1人分の稼働を丸ごと確保することが難しい企業が、業務の一部を外部の力に委ねる構図は、この不足感の裏返しとして生まれています。

データベース・データ基盤の領域は、常時監視が必要な場面と、計画的に時間を確保できる場面が分かれているため、複数の企業が同じエンジニアの稼働を部分的に必要とする状況と噛み合いやすくなります。1社に週5日を固定してもらうよりも、必要な時間帯だけを切り出して依頼するほうが、企業側にとっても現実的な選択になりやすいためです。

Remoguが扱う案件は90%以上がフルリモート可能であり⁵、移動にかかる時間を作業時間へ振り向けられることも、2つの案件を同じ週の中に収めやすくしている要因のひとつです。ただし、リモートで進めやすいかどうかは案件によって異なるため、契約前の確認は必要になります。

データベースの運用では、アラートへの一次対応さえ整えておけば、その他の時間を別の判断に充てられる場面が多くあります。四六時中画面を見ている必要がある仕事ではなく、決まったタイミングで確認し、判断が必要なときに集中して関わる、という働き方がもともと成立しやすい領域です。

問い合わせの改善やスキーマ設計の判断は人に残る

IPAはAI-Enabled ICT Workforce Consortiumの予測として、9割以上のICT職種で主要スキルの過半がAIによって変化すると示しています²。定型的な作業の一部は道具に置き換わっていく方向にありますが、問い合わせの原因を切り分ける判断や、スキーマ設計の妥当性を見極める判断は、依然として人の手に残ります。

「データベースの仕事だから安心」という単純な話ではありません。変化の中でも判断が人に残り続ける領域だからこそ、複数の案件から声がかかりやすい、という見方のほうが実態に近いといえます。判断が求められる場面が分散して存在していることが、掛け持ちという働き方を成立させる土台になっています。

スキーマ設計や問い合わせ改善の判断力は、1つの案件だけに留まらず、案件をまたいでも積み上がっていく経験です。性質の異なる複数の案件に触れるほうが、判断の引き出しが増えていく側面もあり、掛け持ちは単なる稼働時間の分割にとどまらない意味を持ちます。

図の作成：Remogu編集部。時間配分の一例を整理したもので、統計データではありません

時間の波を読みやすいことは分かっても、どの案件でもこの組み方が通用するわけではありません。次は、掛け持ちに向く案件とそうでない案件を見分ける観点を整理します。

2. 掛け持ちできる案件と、できない案件の見分け方

同じデータベース関連の案件でも、担う業務の性質によって掛け持ちのしやすさには差があります。まずは案件の性質を軸に整理してみましょう。

【表1】並行させやすい案件の性質

以下は、案件で担う業務の性質を5つに分け、複数の案件と並行させやすいかどうかを整理したものです。定常運用が中心の案件は時間を区切りやすく、障害の一次対応やリリース直前の伴走を持つ案件は、突発的な対応が発生しやすいため並行がしにくくなります。担当している業務がどれに近いか、確認しながら読み進めてみてください。

案件の性質	掛け持ちしやすさ	理由
定常運用が中心	高い	対応する時間をあらかじめ区切りやすい
計画的な移行作業	高い	作業日をカレンダーで先に確保できる
障害の一次対応を持つ	低い	発生のタイミングを選べない
リリース直前の伴走	低い	稼働が特定の期間に集中する
本番データに触る範囲が広い	中程度	情報を分離する設計をすれば両立しやすい

表1で「低い」にあたる業務を主に担っている場合、もう一方の案件との掛け持ちは慎重に考えたほうがよい場面です。反対に、定常運用や計画的な移行作業が中心であれば、あらかじめ時間を区切って複数の案件に対応しやすくなります。

1つの案件の中でも、担う業務が複数の性質にまたがっていることは珍しくありません。案件全体で判断するのではなく、自分が実際に担っている業務単位で表1に当てはめてみると、掛け持ちの可否がより具体的に見えてきます。

案件の性質は、途中で変わることがある

契約の当初は定常運用が中心だった案件が、追加の移行プロジェクトをきっかけに、性質が変わることもあります。表1への当てはめは一度きりの判断ではなく、案件の状況が変わったタイミングで見直す前提で運用すると、掛け持ちの安定度を保ちやすくなります。もう一方の案件への影響が出そうだと感じた時点で、早めに確認しておくと安心です。

案件の性質を見分けられたら、次は実際に週の中でどう時間を配分するかを考えていきましょう。

3. 2件を並行させる週の組み方

ここからが本題です。2つの案件を並行させるとき、週の中の時間の切り方には主に3つの型があります。

【表2】週の組み方の3つの型

以下は、2つの案件を1週間の中でどう組み合わせるかを3つの型に整理したものです。曜日で分ける型、午前と午後で分ける型、作業日をまとめて確保する型では、それぞれ向く作業と注意点が異なります。担当する業務の性質と照らし合わせながら選んでみてください。

時間帯の型	向く作業	注意点
曜日固定型（月水金と火木のように分ける）	定常運用や定例の打ち合わせが中心の業務	曜日をまたぐ突発対応には弱くなる
午前午後型（午前と午後で分ける）	短時間の判断や設計レビューが中心の業務	切り替えの回数が多く、頭の切り替えにコストがかかる
作業日集約型（週の前半と後半でまとめる）	計画的な移行作業やまとまった検証が必要な業務	集約した側で障害が起きると、もう一方への影響が大きい

どの型が向くかは、案件の性質によって変わります。表1で整理した性質と、図2のマトリクスを重ねて見てみましょう。

図の作成：Remogu編集部。案件の性質を波の読みやすさと即応性で整理したもので、統計データではありません

図2で左上に近い性質を持つ案件同士であれば、表2のどの型を選んでも比較的組みやすくなります。右下に近い性質を持つ案件が1つでも含まれる場合は、作業日集約型のように、まとまった時間を先に確保できる型のほうが安定します。

型は途中で見直してよい

最初に選んだ型を、そのまま固定し続ける必要はありません。曜日固定型で始めてみて、切り替えの回数が想定より多いと感じたら、作業日集約型に寄せていくといった調整は自然な流れです。大切なのは、型を決める前に案件の性質を確認しておくことであり、型そのものに正解があるわけではありません。

型を切り替える際は、変更のタイミングを事前にクライアントへ共有しておくと、受け入れ側の調整もしやすくなります。急に変えるのではなく、次の週から、と一区切りをつけて伝えるほうが、双方にとって負担が小さくなります。

週の型を決めても、実際に動かしてみると想定どおりにいかない場面が出てきます。次は、掛け持ちの中で特に壊れやすい箇所を先に確認しておきましょう。

4. 掛け持ちで壊れるのはどこか

週の型を組んでも、実際に2つの案件を動かしていくと壊れやすい箇所がいくつかあります。先に見えているものは、先に決めておくことができます。

【表3】壊れる箇所と先に決めておくこと

以下は、掛け持ちの中で実際に壊れやすい箇所を5つ挙げ、そこで何が起きるか、そして先に決めておくとよいことを整理したものです。切り替えのコストや情報の分離など、事前に取り決めておけば防げる項目が多く含まれています。心当たりのある箇所から確認してみてください。

壊れる箇所	起きること	先に決めておくこと
切り替えのコスト（頭の切り替え）	直前の案件の文脈を引きずり、判断が遅れる	案件を切り替える前に数分の区切りの時間を置く
障害が重なる日	両方の対応が同時に発生し、優先順位を即断できない	連絡が来た順ではなく、影響範囲の大きさで優先順位を決めておく
情報の分離	異なる案件の情報が混ざり、誤って共有してしまう	案件ごとに保管場所とアカウントを分ける
連絡の遅延	片方への返信が遅れ、信頼を損なう	対応できる時間帯をあらかじめ双方に伝えておく
稼働記録の混在	どちらの案件にどれだけ時間を使ったか分からなくなる	案件ごとに稼働時間を記録する習慣を先に作る

特に情報の分離は、掛け持ちを考えるうえで最初に決めておきたい項目です。IPAの「情報セキュリティ10大脅威2026」では、内部不正による情報漏えい等が組織向けの脅威の第7位に挙げられています³。これは掛け持ちそのものが危険だという意味ではありません。本番データに触れる立場を複数持つときには、情報を分離する設計をあらかじめ用意しておく必要がある、ということです。

保管場所とアカウントを案件ごとに分け、稼働記録も混ぜないようにしておけば、この項目はほとんど事前の準備だけで防げます。特別な仕組みを新しく用意するというより、案件を始める前の取り決めの中に、この観点を1つ足しておくという発想に近いものです。

表3の項目は、案件が始まってから1つずつ気づいて対応するより、始める前の顔合わせの場でまとめて共有しておくほうが効率的です。後から個別に伝えると、伝え忘れが起こりやすくなります。切り替えのコストについても、案件を切り替える前にその日の作業内容を短くメモに残しておくと、次に開くときに文脈を思い出す時間を短縮できます。

図の作成：Remogu編集部。2つの案件の稼働が重なる関係を整理したもので、統計データではありません

図3のように、2つの案件の稼働が重なる時間帯をあらかじめ把握しておけば、障害が重なる日にどちらを優先するかを、当日ではなく事前に決めておくことができます。壊れやすい箇所を先に決めておけば、掛け持ちそのものは無理なく回せる働き方になります。ここまでの型を踏まえたうえで、次は報酬の考え方を整理します。

5. 掛け持ちと報酬の考え方

働き方の型が決まったら、報酬をどう考えるかも整理しておきましょう。

月額報酬の基準線

Remoguが実案件2,450件(2023年1月〜2024年2月・支払上限金額から算出)を分析した調査では、フリーランスエンジニア全体の平均月額報酬は約76.5万円で⁴、職種別ではCTO・VPoE・テックリードが約98.9万円で1位です⁴。設計と判断を担う職種ほど、上位に並ぶ傾向がうかがえます。

ただし、この調査はフルタイムで1つの案件に稼働する前提の月額です。2つの案件を並行させているからといって、この数字がそのまま2倍になるわけではありません。あくまで1件あたりの基準線として捉えておく必要があります。

出典：Remogu「職種別・言語別の月額報酬ランキング」調査（2024年／実案件2,450件・支払上限金額から算出）をもとに作成

按分の考え方と、単価そのものは分けて考える

2つの案件を持つ場合、多くは稼働の割合に応じて報酬が按分される契約になります。たとえば週の稼働時間を6割・4割に分けるなら、報酬もおおむねその比率で組まれる、という考え方です。ここで避けたいのは、稼働率が下がったことを理由に、単価そのものを下げてしまうことです。

担ってきた判断の水準は、稼働時間の長さだけで測れるものではありません。稼働の割合を調整する交渉と、単価そのものを見直す交渉は、分けて考えたほうが、この先の案件でも判断の対価を保ちやすくなります。稼働を減らす相談をするときも、単価はそのままに時間だけを調整したい旨を、クライアントと事前にすり合わせておきましょう。

実際に伝える際は、「来月から稼働の割合を6割に調整したいのですが、単価はこれまでと同じでお願いします」のように、割合の変更と単価を分けて言葉にすると、意図がクライアントに伝わりやすくなります。稼働の割合は案件の状況に応じて途中で見直されることもあるため、見直しのたびに割合と単価を別の議題として扱う習慣をつけておくと、交渉が混ざらずに進めやすくなります。

報酬の考え方まで整理できれば、掛け持ちという働き方を、思いつきではなく設計として組み立てられるようになります。最後に、ここまでの内容を振り返っておきます。

6. まとめ

2つの案件を同じ週の中に収められるかどうかは、性質を見分け、壊れやすい箇所を先に決めておけば、無理なく判断できるようになります。いまの案件は、表1のどの性質に近いでしょうか。

7. よくある質問

Q1．PostgreSQLの経験だけで、掛け持ちを前提に参画できますか。

PostgreSQLの実務経験があること自体は、参画の材料になります。ただし掛け持ちを前提にするなら、それだけで判断せず、担当する業務が表1のどの性質に近いかも合わせて確認しておくと、無理のない組み合わせを選びやすくなります。定常運用が中心の業務であれば、掛け持ちとの相性は比較的良好です。逆に障害の一次対応やリリース直前の伴走が中心の場合は、まず1件に集中し、業務の性質が変わったタイミングで掛け持ちを検討するほうが安全です。

Q2．複数の案件を並行させることは、契約上問題ありませんか。

契約に競業避止や専念義務の条項が含まれているかによって扱いは変わります。複数の案件を並行させる前に、それぞれの契約条件を確認し、必要であればクライアントと事前に相談しておくと安心です。相談せずに進めてしまうと、あとから認識のずれが生まれやすくなります。新しい案件と契約を結ぶ前に、いまの契約書の該当箇所を見直しておく習慣をつけておくと、判断に迷う場面が減ります。

Q3．両方の案件で障害が重なったら、どうすればよいですか。

表3で整理したとおり、連絡が来た順ではなく、影響範囲の大きさで優先順位を決めておくことが基本です。あらかじめ両方のクライアントに、障害対応時の優先順位の考え方を伝えておくと、実際に重なったときにも落ち着いて動けます。図3で示したように、稼働が重なりやすい時間帯を把握しておくと、優先順位の判断そのものも事前に整理しやすくなります。

Q4．稼働率が下がると、単価も下がってしまいますか。

下げる必然性はありません。稼働の割合が下がるのは、その案件にかけられる時間が変わるからであり、これまで担ってきた判断の水準が下がるわけではないためです。按分で調整するのは稼働時間であって、単価そのものは分けて考えたほうが、この先の交渉でも一貫性を保てます。割合の見直しと単価の見直しを同じ議題で持ち出すと話が混ざりやすいため、別々に伝えることを意識してみてください。

Q5．案件は何件まで持てますか。

件数の上限を一律に決められるものではなく、案件の性質と、確保できる時間、情報を分離できる体制によって変わります。表1で「低い」にあたる性質の案件が含まれる場合は、増やす前に慎重な判断が必要です。定常運用が中心の案件が中心であれば、無理なく持てる範囲も変わってきます。件数を増やす前に、いま抱えている案件の稼働記録を1週間分見返し、想定より時間を使っている箇所がないかを確認しておくと、判断の材料が具体的になります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「DX動向2025（AI時代のデジタル人材育成）」ディスカッション・ペーパー（2025年10月9日）
＊2 IPA「DX動向2025（AI時代のデジタル人材育成）」ディスカッション・ペーパー（2025年10月9日）
＊3 IPA「情報セキュリティ10大脅威 2026」組織向け脅威（2026年1月29日）
＊4 Remogu「職種別・言語別の月額報酬ランキング」調査（実案件2,450件・2023年1月〜2024年2月・支払上限金額から算出）（2024年）
＊5 Remoguサイト公開情報（フルリモート可能案件の割合）