WinActor（画面の操作を自動で行う道具)の案件は、募集内容によって求められる作業の重さがまるで違います。画面の操作を並べるだけで完了する案件もあれば、例外の処理や判断の分かれ道まで組み込む案件もあります。この差が生まれる理由は、案件情報に「設定」と「開発」の境目がほとんど書かれていないためです。本記事では、この境目がどこで分かれるのか、契約を受ける前に何を確かめればよいのかを整理します。

1. 食い違うのは設定と開発の境目が書かれていないから

何が設定で、何が開発なのか

WinActorの案件でまず戸惑うのは、募集内容に書かれている作業の粒度がそろっていないことです。画面の操作を順番に並べて自動化するだけの作業を指す案件もあれば、判断の分かれ道や、例外が起きたときの処理まで組み込む作業を含む案件もあります。

書かずに作れる仕組み（ノーコード・ローコード）は、一部利用を含めると全体の約4割の企業が取り入れています¹。導入自体は広く進んでいるものの、そこで担う作業の重さは委託元によってかなり違います。

画面の操作を並べるだけの作業と、例外の処理まで組み込む作業とでは、必要な時間も求められる経験もまったく異なります。この違いが案件情報の文面には表れにくいという点が、食い違いの出発点になります。

境目を決めるのは受ける側ではなく相手の体制

境目がどこに引かれるかは、受ける側の希望だけでは決まりません。約半数の企業が開発の内製化を進めており⁴、社内に一定の対応力を持つ委託元ほど、例外の処理まで自社で抱えようとする傾向があります。

反対に、内製化がまだ進んでいない委託元では、判断の分かれ道になる部分ごと外部に委ねる案件になりやすくなります。境目は案件ごと、委託元の体制ごとに変わるものだと捉えておくと、募集内容の読み方が変わります。

つまり、境目を決めているのは案件情報の書き方ではなく、委託元がどこまでを自社で担おうとしているかという体制です。次の章から、その体制の違いを具体的に見ていきます。

図の作成：Remogu編集部。設定と開発の役割の違いを整理したもので、統計データではありません

2. 社内で設定はできるという前提

画面の操作を並べる範囲は社内でも担える

書かずに作れる仕組みを一部でも取り入れている企業は全体の約4割にのぼります¹。画面の操作を順番に並べるだけの作業であれば、専門の開発担当を置かなくても社内で担える委託元が一定数あるということです。

この前提を持つ委託元は、WinActorの案件を「操作の並びを整える作業」として募集します。求める範囲は狭く、期間も短めになりやすい傾向があります。

ただし、この前提はあくまで画面の操作を並べる範囲に限られます。判断が分かれる場面や、想定していなかった状況への対応までは含んでいません。

開発に近い作業は社内で担いにくい

一方で、DevOpsやモデルベース開発のような開発に近い手法は、開発を請け負う企業を除くと導入している委託元は多くありません²。仕組みを組み立てる力を社内に持つ委託元は限られているということです。

つまり、社内で担える範囲は「操作を並べる」段階までで、例外を見越して仕組みを組み立てる段階になると、外部の力を借りる委託元が増えます。

この二つの前提を並べると、案件情報に書かれていない境目が見えてきます。次の見出しで、範囲ごとの傾向を表に整理します。

画面の操作を並べる範囲と、開発に近い範囲の違い

ここまでの内容を整理すると、案件の範囲は大きく二つに分かれます。ひとつは画面の操作を順番に並べる範囲で、書かずに作れる仕組みの広がりとともに社内で担う委託元が増えている範囲です。もうひとつは、判断の分かれ道や例外への対応まで含む範囲で、開発に近い手法の導入が進んでいない委託元ほど外部に委ねやすくなります。次の表に、この二つの範囲の違いをまとめます。

範囲	内容の例	社内で担える度合い
画面の操作を並べる範囲	決まった手順どおりに操作を自動化する作業	一部利用を含め全体の約4割の企業が取り入れています1
開発に近い範囲	例外の分岐や仕組みそのものを組み立てる作業	開発を請け負う企業を除くと、導入している委託元は多くありません2

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）をもとに作成

3. 例外の処理が外に出る

段階を区切って進める開発は一部にとどまる

例外への対応を計画的に進める開発の手法として、段階を区切って確認しながら進める開発（アジャイル開発）があります。一部の利用を含めても、全体の2〜4割程度の委託元が取り入れている段階です³。

つまり、例外が起きたときにどう対応するかをあらかじめ計画に組み込む進め方は、まだ委託元の一部にしか広がっていません。残りの委託元では、例外が起きるたびに対応を検討する形になりやすいのです。

この差が、WinActorの案件で「例外の処理まで含むかどうか」の分かれ目になります。計画的に進める体制を持つ委託元ほど、例外への対応も含めて案件の範囲に組み込みます。

内製化を進めても、人と技術の課題は残る

開発の内製化を進める委託元でも、課題がないわけではありません。内製化の課題として人材の確保や新しい技術への対応を挙げる企業が多くあります⁵。

人材や技術への対応が追いついていない委託元では、例外の処理を担える人が社内にいないため、その部分だけを外部に委ねる案件になりやすくなります。逆に言えば、この部分こそが受ける側の経験が生きる場面です。

画面の操作を並べる範囲は社内に残り、例外の処理は外に出る。この分かれ方を知っておくと、案件情報の行間を読みやすくなります。

例外への向き合い方で見る、案件の傾向の違い

ここまでの内容を、例外への向き合い方という軸で整理します。段階を区切って進める開発を取り入れている委託元と、まだ取り入れていない委託元とでは、例外が起きたときの対応の組み込み方が異なります。次の表に、その傾向をまとめます。

委託元の傾向	例外への向き合い方	案件に出やすい範囲
段階を区切って進める開発を取り入れている	全体の2〜4割程度が該当します3	例外への対応も計画に組み込まれやすい
人材や新しい技術への対応が課題になっている	内製化を進めていても課題に挙げる企業が多くあります5	例外の処理だけを外部に委ねやすい

図の作成：Remogu編集部。例外処理の決め方による進み方の違いを整理したもので、統計データではありません

Remoguは、案件の90%以上がフルリモート可能です。設定と開発の境目を確かめながら案件を探すときは、まず自分の経験に近い案件がどれくらいあるかを見てみると、次の判断がしやすくなります。

4. 決める人がいない場合

意思決定を担う責任者がいないと、判断が止まる

例外が起きたときに「誰が決めるか」という点も、案件の範囲に影響します。意思決定を担う責任者を設置していない委託元は約半数に上ります⁶。

決める人が明確でない委託元では、例外への対応方針がその場で決まらず、確認や持ち帰りが増えます。結果として、WinActorの案件でも「まず判断を仰ぐ相手を探す」作業が発生しやすくなります。

決める人が明確な委託元とそうでない委託元とでは、同じ「例外処理」という言葉でも、実際にかかる時間がまったく違います。

資料の有無が、判断の速さを左右する

要件定義や設計は、いまも文書を中心に行われています⁷。文書が整っている委託元では、例外が起きたときにも「本来どう動くはずだったか」を照らし合わせやすくなります。

文書が整っていない委託元では、判断の材料が担当者の記憶に頼ることになり、例外への対応がその都度変わりやすくなります。決める人がいるかどうかと、資料が残っているかどうかは、セットで見ておきたい点です。

次の章では、この「資料が残っているか」という観点を、もう少し具体的に見ていきます。

5. 資料が残っているか

文書が中心の進め方は今も続いている

要件定義や設計がいまも文書を中心に行われているという傾向は⁷、WinActorの案件にもそのまま当てはまります。操作の手順や例外の扱いが文書として残っている委託元ほど、後から確認できる範囲が広くなります。

文書が残っていれば、担当者が変わっても対応の経緯をたどれます。反対に、文書が残っていない委託元では、例外への対応が担当者の頭の中にしかない状態になりやすくなります。

受ける側にとっては、この文書の有無が、案件の始めやすさと、途中での問い合わせのしやすさを分ける材料になります。

品質を重視する委託元ほど、資料を確かめたくなる

システムを利用する委託元は、品質を最も重視する事項として捉えています¹⁰。品質を重視する委託元ほど、手順や判断の根拠が資料として残っているかどうかを気にする傾向があります。

資料の有無を尋ねることは、委託元の姿勢を確かめることでもあります。資料が整っている委託元は、例外への対応も含めて範囲を明確に伝えてくれる可能性が高くなります。

資料の有無で見る、確認しやすさの違い

ここまでの内容を、資料の有無という軸で整理します。文書が整っているかどうかは、品質への向き合い方ともつながっています。次の表に、確認しておきたい点をまとめます。

観点	実態	確かめておきたいこと
要件や手順の記録	いまも文書を中心に行われています7	操作の手順や例外の扱いが文書に残っているか
委託元が重視する事項	品質を最も重視する事項として捉えています10	品質を重視する委託元ほど資料を確かめやすい

6. 契約の形から範囲を確かめる

取引のたびに手間がかかる点が課題になっている

契約の場面でも、範囲の食い違いは起きやすいところです。契約では取引のたびに手間や工数がかかる点を課題に挙げる委託元が多くあります⁸。

毎回条件を一から確認する形になると、設定なのか開発なのかという範囲の話も、そのつど個別に決めることになります。案件ごとに範囲の書き方がばらつく背景には、この手間の問題があります。

受ける側からすると、契約のたびに範囲の説明を求められるのは負担に感じられるかもしれませんが、範囲を確かめる機会でもあります。

契約の見本となる型を知らない委託元もある

契約の見本となる型（モデル契約）そのものを知らないとする委託元も多くあります⁹。見本となる型を持たない委託元では、契約書の文言が案件ごとに大きく変わることがあります。

こうした委託元と話すときは、契約書の文言だけに頼らず、設定の範囲と例外の処理の範囲を、あらかじめ言葉にして確認しておくと、後からの食い違いを防ぎやすくなります。

契約の形は委託元によってさまざまですが、範囲を確かめる姿勢はどの契約でも変わりません。次の章で、受ける前に確かめる順番を整理します。

契約の形や工数の扱いは案件ごとに異なります。登録して自分の経験に合う条件を確かめておくと、話を受けるかどうかの判断がしやすくなります。

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

四つの観点を、この順番で確かめる

ここまでの内容を、受ける前に確かめる順番として整理します。まず確かめたいのは、募集内容が画面の操作を並べる範囲なのか、例外の処理まで含む範囲なのかという点です。

次に、例外が起きたときに意思決定を担う責任者がいるかどうかです。責任者を設置していない委託元は約半数に上るため⁶、この点は特に確かめておきたいところです。

三つ目は、要件や手順の資料が残っているかどうかです。文書を中心に進める委託元かどうかで⁷、対応のしやすさが変わります。四つ目は、契約の形と工数の扱いです。

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

この四つを、契約を受ける前の会話の中で確かめておくと、始まってから範囲が食い違う場面を減らせます。

設定だけの案件と開発を含む案件は、募集内容でどう見分ければよいですか

募集内容だけで見分けるのは難しいことが多く、例外の処理が案件に含まれるかどうかを直接尋ねるのが分かりやすい方法です。意思決定を担う責任者がいるか、要件や手順の資料が残っているかを合わせて確かめると、範囲がより具体的に見えてきます。

画面の操作を並べる作業だけを担当したい場合、何を伝えればよいですか

設定の範囲に絞りたいという希望は、契約前の面談ではっきり伝えておくとよいでしょう。委託先と協議し、例外が起きた場合の対応をどちらが担うのかを、あらかじめ言葉にしておくと、始まってからの行き違いを防ぎやすくなります。

経験がまだ少ない場合でも、例外の処理を含む案件を受けられますか

経験がまだ少ない場合は、まず資料が整っている委託元かどうかを確かめると始めやすくなります。文書を中心に進める委託元であれば⁷、本来どう動くはずだったかを照らし合わせながら対応できます。自分の経験に近い案件がどれくらいあるかは、登録して確かめてみると判断の材料になります。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」書かない選択（2025年4月・2026年8月確認）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」確認の自動化（2025年4月・2026年8月確認）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」混在する現実（2025年4月・2026年8月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」内製化の広がり（2025年4月・2026年8月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」入る余地（2025年4月・2026年8月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」決める人（2025年4月・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」契約の負担（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」相手の前提（2025年4月・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月・2026年8月確認）