SQLを使う案件は数が多く、相手先によって任される範囲が大きく違います。同じ「SQL」という言葉でも、決まった条件でデータを取り出す文を書くだけの案件もあれば、データの持ち方そのものを設計する案件もあります。担当範囲を確かめないまま参画すると、想定していた作業と実際の作業がずれて、途中で持ち帰る仕事が増えることになります。この記事では、案件情報のどこを見れば担当範囲が読めるかを、公的な資料の手がかりとあわせて整理します。

1. SQLの案件は2つに分かれる

データを取り出す文を書く仕事

SQLを使う案件の中でいちばん数が多いのは、すでに用意されているデータの置き場所から、必要な条件で取り出す文を書く仕事です。集計表を作る、条件に合う一覧を出す、既存の画面やレポートに数値を渡す。こうした作業は、置き場所の形がすでに決まっているため、書く内容自体に迷う場面は少なくなります。

この種類の案件は、担当範囲が比較的狭く区切られています。取り出す文の書き方に工夫の余地はあっても、データをどう分けて置くか、どんな名前で管理するかといった判断は、すでにクライアント側で終わっているためです。参画してすぐに着手できる案件が多いのも、この範囲の仕事の特徴です。

一方で、同じ案件情報の文面からは、この範囲で終わるのか、もう一段広い範囲まで踏み込むのかが読み取りにくいことがあります。次に見るのは、その境目がどこに現れるかという点です。

データの持ち方そのものを決める仕事

もう一つの種類は、データの持ち方そのものを決める仕事です。どの情報をひとまとまりにするか、どの単位で分けて置くか、後から条件を足しやすい形にしておくかといった判断が含まれます。取り出す文を書く前段階の設計にあたる部分で、決めた形が後の作業のしやすさを左右します。

IPAの調査では、モジュール性やデータモデルを意識した設計に取り組む企業は、利用する側を中心に依然として少ない状況です⁹。設計まで担う人が社内に育っていない状態で、外部の案件として持ち出されるケースがあるということです。

同じ調査では、データ利活用に関する方針を明確にしている企業は少なく、対応の遅れが目立ちます⁸。方針が固まっていない段階で声がかかる案件ほど、取り出す文を書くだけでは収まらない可能性があります。取り出す仕事かどうかよりも、決める仕事が含まれるかどうかのほうが、担当範囲を大きく左右します。案件情報を読むときの最初の分かれ目は、ここになります。

図の作成：Remogu編集部。案件で任される範囲の傾向を整理したもので、統計データではありません

2. 計測の話が出る案件は設計まで含む

定量的な計測とダッシュボードの話が出たら設計まで踏み込む合図

案件情報の中に、状況を定量的に計測してダッシュボードで可視化するという言葉が入っていたら、それは取り出す文を書くだけでは終わらない合図です。政府情報システムの利用方針では、定量的な計測とダッシュボードによる状況の可視化が挙げられています¹。数値を集めて画面に映すところまでを一つの仕組みとして作る話だからです。

集計する対象が増えるほど、どの単位でデータをまとめて置くかという判断が先に必要になります。取り出す文を書く前に、何を軸にして数値を並べるかを決めなければ、後から条件を足すたびに書き直しが発生します。計測の話が出る案件は、この設計にあたる部分まで担当範囲に含まれると考えたほうが実態に近くなります。

大きなリソースを通常時に使わない考え方がデータの持ち方に跳ね返る

もう一つの手がかりは、リソースの使い方に関する言葉です。ピーク時を想定した大きなリソースを、普段の状態でも使い続けないようにする考え方が挙げられています²。普段は小さく、必要なときだけ大きくするという発想は、データの取り出し方にも影響します。

普段の処理を軽くしようとすると、まとめて計算しておく部分と、その都度計算する部分を分ける判断が必要になります。この分け方を決めるのは、取り出す文を書く仕事よりも、データの持ち方を決める仕事の側です。計測とリソースの話が同じ案件情報に並んでいたら、担当範囲は広めに見ておくほうが安全です。

計測の話があるかないかで担当範囲を比べる

同じSQLの案件でも、計測やダッシュボードの話が含まれるかどうかで、任される範囲は大きく変わります。含まれない案件は取り出す文を書く作業が中心になり、含まれる案件はデータの持ち方を決める設計まで踏み込みます。実際にどう違うのか、比較表で整理します。

項目	計測・可視化の話がない案件	計測・可視化の話がある案件
中心になる作業	決まった置き場所から取り出す文を書く	数値をまとめる単位や持ち方を設計する
着手のしやすさ	比較的早く着手できる	設計の打ち合わせから始まることが多い
後からの変更	条件を足すたびに文を書き直す程度	持ち方を見直す必要が出ることがある
確認しておきたい点	取り出す条件の詳細	数値を集める単位と更新の頻度

図の作成：Remogu編集部。案件で任される範囲の広がりを整理したもので、統計データではありません

3. 夜間のまとめ処理という手がかり

夜間バッチの見直しが挙がる案件は仕組みそのものに触れる

案件情報の中に、夜間にまとめて処理する仕組みを見直すという言葉が出てきたら、それも設計側の作業が含まれる手がかりです。夜間バッチの必要性を見直すことが挙げられています³。まとめて処理する時間帯を減らす、あるいはなくすという話は、データの持ち方を変える判断とつながっています。

夜間にまとめて処理する仕組みは、日中の処理を軽くするために作られていることが多く、この仕組みを見直すとなると、日中の処理の仕方まで含めて考え直す必要が出てきます。取り出す文を書き換えるだけでは済まず、どの単位でデータを更新するかという設計に踏み込みます。

更新の確認テストを最適化する話も設計側の仕事

もう一つの手がかりは、事業者側が提供する仕組みが更新されるときの確認テストを最適化するという話です。マネージドサービスの更新時における確認テストの最適化が挙げられています⁷。更新のたびに確認する作業を減らせるように、テストの仕組みを整えるという内容です。

確認テストを最適化するには、どこを重点的に確認すればよいかをあらかじめ決めておく必要があります。これも、取り出す文を書く仕事というより、仕組み全体をどう設計するかという判断に近い作業です。夜間のまとめ処理と更新時の確認テスト、この2つの言葉が案件情報に出てきたら、担当範囲は設計側まで広がっていると見たほうが実態に合います。

夜間のまとめ処理を見直す前と後を比べる

夜間にまとめて処理する仕組みを見直すと、日中の作業の仕方や確認する項目がどう変わるのか、見直す前と後で比較します。

項目	見直す前	見直した後
まとめ処理の位置づけ	夜間に一括で処理する	処理の頻度や単位を見直す
日中の作業	まとめ処理の結果を前提に進める	更新の反映のされ方を確認しながら進める
更新時の確認	都度手作業で確認する	確認テストの仕組みで最適化する
担当範囲	取り出す文の調整が中心	仕組み全体の設計まで含む

図の作成：Remogu編集部。担当範囲の変化を整理したもので、統計データではありません

4. 費用の話から範囲を読む

利用料を定期的に確認する話は運用まで見る合図

案件情報にクラウドの利用料を定期的に確認するという言葉が入っていることがあります。利用料を定期的に確認することが挙げられています⁴。費用の確認は、取り出す文を書くだけの作業ではなく、運用を続けながら見ていく仕事です。

利用料を確認する担当になると、どの処理がどれくらいの費用を生んでいるかを、データの持ち方と結びつけて説明する場面が出てきます。費用の話が案件情報に含まれているかどうかは、担当範囲が運用まで続くかどうかを見分ける材料になります。

稼働していないリソースへの課金を抑える話とオートスケールの話

稼働していないリソースへの課金を抑えることが挙げられています⁵。使っていない状態のものにも費用がかかる仕組みなので、使われているかどうかを判断できる形でデータを持つ必要があります。この判断材料を用意するのも、設計側の仕事に入ります。

当初からピーク時を想定して大きく作る構成から、必要な分だけ自動で増減する構成へ変わります⁶。自動で増減する構成に合わせるには、処理を細かい単位に分けておく必要があり、取り出す文の書き方そのものも変わってきます。

利用料・稼働していないリソース・自動で増減する構成。この3つの言葉が並んでいる案件情報は、費用の話を入り口にして、データの持ち方まで踏み込む案件だと読めます。

費用に関する言葉は、担当範囲の広さを直接語ってはくれません。それでも、どの言葉が並んでいるかを見れば、取り出す文を書く範囲で終わるのか、設計まで含むのかの見当がつきます。

5. 決まっていない前提で入る

方針が明確でない企業が少なくない

データ利活用に関する方針を明確にしている企業は少なく、対応の遅れが目立ちます⁸。つまり、案件として声がかかる時点で、方針そのものが固まっていない状態から始まることがあります。取り出す文を書く前提が揺れやすいのは、このためです。

方針が固まっていない状態で参画すると、途中で条件が変わる場面に出会うことがあります。最初に決めた取り出し方が、後になって別の単位に組み替えられることも珍しくありません。決まっていない前提で入るという心づもりが、この種の案件では役に立ちます。

設計に取り組む体制がまだ整っていない

モジュール性やデータモデルを意識した設計に取り組む企業は、利用する側を中心に依然として少ない状況です⁹。設計を担う体制が社内に整っていないからこそ、外部に案件として出されるとも読めます。

体制が整っていない状態から入る案件は、進め方を決める打ち合わせの回数が増えたり、最初に立てた計画を途中で見直したりする場面が出やすくなります。取り出す文を書く仕事のつもりで参画すると、範囲の広がりに戸惑うことがあります。

決まっていない前提のときとすでに決まっているときを比べる

同じSQLの案件でも、方針や設計がすでに決まっているかどうかで、進め方や確認する項目は変わります。比較表で整理します。

項目	方針・設計が決まっている案件	決まっていない前提で入る案件
最初の打ち合わせ	取り出す条件のすり合わせが中心	方針そのものの整理から始まる
進め方	計画どおりに進みやすい	途中で条件が組み替わることがある
求められる関わり方	指定された範囲で取り出す	持ち方の設計まで意見を求められる
担当範囲の広がり方	比較的一定	進めながら広がることがある

6. 着手している企業が半数という現状

半数という数字が意味すること

データの利活用に着手している企業は約半数です¹⁰。つまり、残りの半数は、これから着手する段階にあるということです。SQLの案件として声がかかる相手が、どちら側にいるかによって、任される作業の性質は変わります。

着手している側の企業では、すでにある仕組みを引き継いで、取り出す文を書く作業が中心になりやすくなります。これから着手する側の企業では、定量的な計測とダッシュボードによる状況の可視化といった話から始まり¹、仕組みそのものを一緒に作る場面が出てきます。

半数という数字は、どちらの案件が多いかを決めるものではありません。ただ、案件情報の中に計測や可視化の言葉が出てくる頻度は、これから着手する企業が一定数いることの表れとも読めます。

計測の仕組みがまだ整っていない案件もある

着手している企業か、これから着手する企業か。案件情報だけで見分けるのは難しい場面もありますが、計測・夜間のまとめ処理・費用という3つの手がかりを重ねて見ると、どちら寄りの案件かの見当がつきやすくなります。

これから着手する側の案件では、決めるべき事項が案件の途中で明らかになっていくことがあります。取り出す文を書く仕事だと思って参画しても、途中で持ち方の相談を受ける場面が出てくるのは、この段階にある企業と組むときの特徴です。

半数という現状を踏まえると、案件情報の文面だけで担当範囲を決めつけず、最初の打ち合わせで確かめる姿勢が役に立ちます。次の章では、その確かめ方を順番に整理します。

7. 受ける前に確かめる順番

案件情報に出てくる言葉を順番に確かめる

ここまで見てきた手がかりを、受ける前に確かめる順番として整理します。まず、案件情報の中に定量的な計測とダッシュボードの話が出ているかを確かめます¹。出ていれば、取り出す文を書く仕事だけでは収まらない可能性があります。

次に、夜間にまとめて処理する仕組みを見直すという言葉があるかを確かめます³。見直しの話があれば、日中の処理や更新の確認テストまで担当範囲に含まれることを想定しておきます。

最後に、費用に関する言葉の有無を確かめます。利用料の確認や、稼働していないリソースへの課金といった言葉が並んでいれば、運用まで続く案件だと見当がつきます。この3つの手がかりを順番に確かめることで、案件情報の文面からある程度の担当範囲が読めるようになります。

図の作成：Remogu編集部。確かめる順番を整理したもので、統計データではありません

打ち合わせで確かめておきたいこと

文面だけで判断がつかないときは、最初の打ち合わせで直接確かめます。取り出す文を書く範囲で終わるのか、データの持ち方を決める設計まで含むのか。この境目を打ち合わせの段階で言葉にしておくと、後から範囲がずれることを防げます。

方針や設計がまだ決まっていない前提で入る案件かどうかも、打ち合わせで確かめておきたい点です。決まっていない前提だと分かっていれば、途中で条件が組み替わっても、想定の範囲内として受け止められます。

SQLを使う案件は、取り出す文を書く範囲から設計まで含む範囲まで幅がありますが、いずれも場所を問わず進めやすい領域です。案件の90%以上がフルリモート可能です。担当範囲を確かめながら、無理のない形で参画先を選べます。

取り出す文を書く案件と設計まで含む案件、どちらを選べばよいですか

どちらが良いというものではなく、今の経験や志向に合わせて選ぶ判断です。取り出す文を書く範囲は着手しやすく、設計まで含む範囲は担当する内容が広がります。案件情報に出てくる言葉を手がかりに、自分に合う範囲かどうかを確かめてから打診への返答を決める進め方が現実的です。

経験がまだ少ない場合でも、設計まで含む案件を受けられますか

経験がまだ少ない段階で、設計全体をひとりで任される場面は限られています。まずは取り出す文を書く範囲の案件で、案件情報にどんな言葉が出てくるかを見る経験を積み、次第に計測や夜間のまとめ処理といった言葉が出てくる案件へ進むという流れが無理のない進め方です。案件情報の言葉を手がかりに、担当範囲を確かめてから打診への返答を決めることが、遠回りに見えて一番早い進め方です。

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

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見えるようにする（2026年・2026年8月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」常時の余裕（2026年・2026年8月確認）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」時間帯の前提（2026年・2026年8月確認）
＊4 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見ることから（2026年・2026年8月確認）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」止まっているもの（2026年・2026年8月確認）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見積りの前提（2026年・2026年8月確認）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」テストの費用（2026年・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」方針の遅れ（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」着手の広さ（2025年4月・2026年8月確認）