QAの案件で「自動化」という言葉を聞くと、任される範囲がどこまでかは分かりにくいものです。現場によって、仕組みそのものを作る作業なのか、既にある仕組みを回す作業なのかが変わります。この記事では、公的な調査の数値をもとに、自動化という言葉が現場ごとにどう変わるかを整理します。品質への期待の高さと現場の仕組みの整い方を分けて捉えたうえで、線引きの示し方まで、順を追って見ていきます。

1. 自動化の意味は現場で変わる

自動化という言葉がどの範囲を指すかは、依頼する現場によって幅があります。同じ「自動化してほしい」という一言でも、実際に求められる作業は現場ごとに大きく違います。

作る側と使う側で導入の状況が違います

DevOpsやモデルベース開発については、作る側の企業を除くと、導入している企業は少ない状況です¹。案件で「自動化」と言われても、その言葉が指す作業の幅は、依頼元がどの段階にいるかで変わります。

依頼する側が自動化の仕組みそのものを持たない場合、任される範囲は「仕組みを作る作業」に近づきます。逆に仕組みが既にある現場では、「その仕組みを回す作業」が中心になります。

最初の打ち合わせで「自動化と言うとき、具体的に何を指しているか」を尋ねておくと、任される作業の実像が早い段階でつかみやすくなります。言葉だけで判断せず、現場の状態とあわせて確認する姿勢が役立ちます。

品質への期待は高いままです

一方で、利用する側の企業は、品質を最も優先する事項として捉えています²。仕組みが整っていなくても、品質そのものへの関心が下がっているわけではありません。

この落差が、「自動化してほしい」という言葉の中に、いくつもの意味を詰め込む形で表れます。任される範囲を早い段階ですり合わせておく必要があります。品質への意識が高い現場ほど、確認してほしい範囲を広めに考えている場合があります。

図の作成:Remogu編集部。作る作業と回す作業の比重が現場の成熟度で入れ替わる関係を整理したもので、統計データではありません。

次の節では、仕組みを回す土台がどれくらい現場に整っているかを、具体的な数値とともに見ていきます。

2. 回す土台が無い現場が多い

自動化の仕組みを「回す」には、その前提となる開発の進め方や管理の仕組みが要ります。まずはその土台がどこまで整っているかを見ていきます。

アジャイル開発はまだ一部です

アジャイル開発は、一部を含めても全体の2〜4割程度の企業が導入している状況です³。依頼元がウォーターフォール中心か、アジャイルの要素を持つかで、確認の頻度や単位は変わります。

段階を区切って確認する進め方に慣れている現場と、まとまった単位でしか区切らない現場とでは、任される仕事の粒度が違って見えます。案件の初期に、どちらの進め方に近いかを尋ねておくと、確認の頻度を見積もりやすくなります。

アジャイルの要素を持つ現場では、短い周期で区切って確認する分、1回あたりの範囲は狭くなりがちです。逆にまとまった単位で進む現場では、確認する範囲が広がる分、優先順位の付け方が問われます。

構成管理ツールの導入も限られています

構成管理ツールを導入している企業は、利用する側で約3割、作る側で約4割にとどまっています⁴。バージョンの管理が仕組み化されていないと、何をもって確認できたとするかの基準も揺れやすくなります。

確認の基準が固まっていない案件では、稼働の最初の期間に基準そのものをすり合わせる時間を見込んでおくと、後々の手戻りを減らせます。基準づくりも、確認作業と同じくらい重い仕事になり得ます。

版の管理が個人のフォルダに閉じている現場では、どのファイルが最新かを確かめるところから作業が始まります。この確認自体は地味ですが、後の手戻りを防ぐ土台になります。

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

この段階では、確認の手順を自動で回す前に、まず手順そのものを固める作業が発生します。次の比較表に、その違いを整理します。

現場の状態	開発の進め方	管理の仕組み	任される作業の中心
土台が整っている現場	アジャイルの要素を持つ	ツールで一元管理している	確認を回す作業
土台がまだ整っていない現場	まとまった単位で進む	手順が個人に依存している	手順を固める作業

この差を踏まえたうえで、次は現場が抱く「期待」の面に目を向けます。

3. 期待だけが高い状態

品質への期待が高いことと、その期待に見合う手応えを得られていることは、別の話です。ここでは期待と実態のずれを見ていきます。

品質は最優先事項として扱われています

利用する側の企業は、品質を最も優先する事項として捉えています²。この位置づけ自体は、案件に取り組むうえで支えになる面があります。

ただし、優先度が高いことと、確認の仕組みが整っていることは別の話です。優先度の高さは、むしろ確認してほしい範囲を広げる方向に働きます。「品質を優先している」という言葉だけでは、任される作業の量は見えてきません。

優先度の高さと仕組みの有無を分けて捉えると、依頼元が何を求めているのかが整理しやすくなります。両方が揃っている案件ばかりではない、という前提を持っておくことが役立ちます。

効果を得られていないという回答が目立ちます

「期待する効果を得られていない」という回答は、4か国の中で最も多くなっています⁹。仕組みを取り入れても、その手応えが伴っていない現場が一定数あることになります。

効果が出ていない理由は、案件を受ける側から見えるとは限りません。導入した仕組みそのものの問題なのか、使い方が定着していないだけなのか、切り分けて考える視点が求められます。

この落差を、確認の範囲だけで埋めるのか、原因を探る役割まで担うのかは、案件ごとに扱いが変わります。契約の前に、どこまでを引き受けるかを協議しておくと、稼働後の認識違いを避けやすくなります。

期待の高さを否定的に捉える必要はありません。品質を優先する姿勢がある現場は、確認の結果を丁寧に受け止めてくれる場面も多く、伝え方次第で協議が進めやすくなります。

案件を受ける側からすると、この落差をどこまで埋める役割を担うかが、任される範囲を左右します。次の比較表に、期待と実態のずれを整理します。

項目	現場の期待	実態として見えているもの
品質への位置づけ	最も優先する事項として扱う2	仕組みが伴っていない現場もある
導入の手応え	効果を見込んで仕組みを取り入れる	「効果を得られていない」という回答が最多9

期待と実態の差を踏まえて、次は確認の中身をどこから起こすかを見ていきます。

4. 何を確かめるかは文書から起こす

確認する項目をどこから起こすかは、案件によって手掛かりが違います。ここでは、いま残っている手掛かりの中身を見ていきます。

要件定義と設計は文書が中心です

要件定義と設計は、いまもドキュメントを中心に進められています⁵。確認する項目は、この文書を読み解くところから起こせます。

文書に書かれた仕様や条件を、確認できる形に言い換える作業が、最初の土台になります。ここを丁寧に進めるほど、後の確認がぶれにくくなります。文書の読み方そのものが、案件ごとの経験として積み上がっていきます。

要件定義の文書が分厚い案件ほど、最初に全体の構成を把握する時間を取ることが、後の効率につながります。読む順番を決めておくと、確認項目の抜け漏れを防ぎやすくなります。

複数の文書に情報が分かれている場合は、どの文書が最新の条件を示しているかを先に確かめておくと、途中で前提が食い違う事態を避けられます。

文書の記載が薄い箇所を見つけたら、確認の前提をどう補うかをクライアントと協議しておくと、後になって手戻りが発生する事態を防ぎやすくなります。

設計の粒度は荒いままです

モジュール性やデータモデルを意識した設計に取り組む企業は、特に利用する側を中心に、依然として少ない状況です⁷。設計の単位が大きいままだと、確認する範囲も大きな塊になりがちです。

文書はあっても、確認しやすい粒度に割られていないことが多く、その割り方自体が任される作業の一部になります。次の図に、文書から確認項目を起こす流れを整理します。

図の作成:Remogu編集部。文書から確認項目を起こす一般的な流れを整理したもので、特定の手順を示すものではありません。

この流れを踏まえて、次は確認の単位そのものが繰り返しやすい形になっているかを見ていきます。

5. 自動化しやすい形になっていない

確認項目を整理できても、それを繰り返し回せる形になっているかは別の問題です。ここでは、その手前にある設計の状態を見ていきます。

設計の単位が大きいと繰り返しにくくなります

モジュール性やデータモデルを意識した設計に取り組む企業は、依然として少ない状況です⁷。単位が大きいままだと、同じ確認を繰り返す仕組みを組みにくくなります。

繰り返し回すには、確認の単位を切り分ける作業が先に要ります。この切り分けそのものが、案件で任される仕事の中心になる場合があります。大きな塊のままでは、何度も同じ確認をやり直す羽目になりかねません。

切り分けの粒度をどこまで細かくするかは、案件ごとの判断が求められる場面です。細かすぎれば管理の手間が増え、粗すぎれば確認の抜けが残ります。

最初から完璧な粒度を狙うより、いったん区切ってみて、運用しながら調整していく進め方のほうが現実的です。小さく試して直す前提を、依頼元と共有しておくと進めやすくなります。

単位を切り分ける作業には、思った以上に時間がかかることがあります。着手前にその見立てを共有しておくと、稼働後のスケジュールが立てやすくなります。

リスク管理は一定の水準で整っています

ITのリスク管理や業務継続計画は、全体の5〜6割程度の企業が整備しています⁶。この領域は、設計の単位の粗さとは別に、一定の水準で仕組みが整っています。

リスク管理の仕組みがある現場では、確認する優先順位の考え方そのものが既に用意されている場合が多く、そこに沿って進める形になります。ゼロから優先順位を組み立てる場面は減ります。

整っている領域と整っていない領域が現場ごとに違うため、次の比較表で、任される作業の重さがどちらに寄りやすいかを整理します。

領域	整っている度合い	任される作業の重さ
ITリスク管理・業務継続計画	全体の5〜6割程度が整備6	確認を回す作業が中心になりやすい
モジュール性・データモデルの設計	取り組みが依然として少ない7	単位を切り分ける作業が先に要る

この違いを踏まえて、次は情報がどこに留まっているかという点に目を向けます。

6. 情報が個人に留まっている

仕組みだけでなく、情報の扱われ方も、任される範囲に関わります。ここでは情報の残り方を見ていきます。

技術情報の収集は個人に委ねられがちです

技術情報の収集は体系的な仕組みを持たず、個人に委ねられている企業が多くを占めます⁸。確認の手順や理由を残す作業も、同じように個人に依存しがちです。

引き継ぎの資料が薄いと、確認の背景をたどり直す作業から始めることになります。これも案件で任される範囲の一部です。担当していた人が抜けた途端に、確認の理由が分からなくなる場面も起こり得ます。

情報が個人に留まっている現場ほど、最初に「これまで何を確認してきたか」を聞き取る作業に時間をかける価値があります。土台を知ることが、その先の作業をやりやすくします。

聞き取った内容を自分なりに整理して残しておけば、途中で担当が変わる場面でも、確認の経緯が伝わりやすくなります。属人化を少しずつ解いていく動き方です。

自分が確認した内容とその理由を言語化して残す習慣は、この案件だけでなく、次の案件でも積み上げられる経験になります。

人材不足が最大の課題です

デジタル化の課題として人材不足を挙げる企業の割合は48.7%で、他の項目より高くなっています¹⁰。確認を担う人手そのものが不足している状況が背景にあります。

人手が限られている現場ほど、一人が担う確認の範囲は広がりやすくなります。その分、優先順位を自分で判断する場面も増えるため、判断の理由を残しておくことが後の説明を助けます。

この状況では、確認作業を一人で抱え込まず、区切って引き継げる形にしておくことが、案件を受ける側にとっても進めやすさにつながります。

情報を個人に留めない工夫が、次に見る「線引き」の土台になります。

7. 線引きを示す順番

ここまで見てきた現場の状態を踏まえると、自動化の範囲を示す順番が見えてきます。最後に、その順番を整理します。

土台の有無を最初に確かめます

DevOpsやモデルベース開発は、作る側の企業を除くと導入している企業は少ない状況です¹。この事実を踏まえると、最初に確かめたいのは「仕組みがあるかどうか」そのものです。

仕組みがまだ無い現場では、確認を回す前に、確認できる形を作る作業から始まります。この順番を早い段階ですり合わせておくと、後の行き違いを減らせます。

この順番をあらかじめ示せると、初めて組む相手であっても、どこまでを引き受けているかが伝わりやすくなります。伝え方を整えておくこと自体が、案件を進めるうえでの備えになります。

土台がまだ無いと分かった時点で、仕組みを作る作業に費やす期間を先に見積もっておくと、依頼元との間で無理のない進め方を組み立てやすくなります。

文書を起点に確認項目を示します

要件定義と設計は、いまもドキュメントを中心に進められています⁵。文書があるなら、そこから確認項目を起こし、優先順位を付けて示す、という順番が組み立てやすくなります。

この順番は、依頼元に説明するときにも使えます。「まず土台を確かめ、次に文書から項目を起こし、最後に単位を区切る」と伝えると、任される作業がどの段階にあるかを共有しやすくなります。

順番を示すこと自体が、確認する側と依頼する側の間で共通の言葉を作ります。感覚のずれを減らし、後から「聞いていない」という行き違いを防ぐ役に立ちます。

土台の有無を確かめ、文書から項目を起こし、繰り返せる単位に区切る。この3段階を示す順番として意識しておくと、任される範囲の説明がしやすくなります。次の図に、その順番を整理します。

図の作成: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 総務省「令和7年版 情報通信白書（デジタル活用の動向）」効果の実感（2025年7月・2026年8月確認）
＊10 総務省「令和7年版 情報通信白書（デジタル活用の動向）」最大の課題（2025年7月・2026年8月確認）