GASで社内の業務を自動化する経験を重ねてきた人ほど、案件の打診を受けた直後に手が動きます。ただ、作った後になって「思っていたのと違う」と言われる場面は、腕の差ではなく、作り始める前に何をそろえたかの差から生まれています。デジタル庁の実践ガイドブックには、システムを作る前に業務を整理するための項目がすでに並んでおり、この記事ではその並びを、GASの案件を引き受ける場面に置き換えて追っていきます。「言われたものを作るだけの相手」に見られる不安も、作る前の順番を押さえることで小さくできます。

1. 自動化で揉めるのは、腕ではなく順番

口頭の依頼を、そのまま実装してしまう場面

現場で自動化を頼まれるとき、要件は口頭で降りてくることが多く、手が速い人ほどその場で仕様を思い浮かべ、すぐに書き始めたくなります。担当者の話を聞きながら頭の中でスクリプトの形が見えてしまうことは、積み上げてきた経験があるからこそ起きる自然な反応です。

ただ、担当者ごとに違う例外は、依頼を受けた時点では見えていません。動くものを見せた後になって「この場合はどうするのか」という声が続けて出てくると、作り直す範囲は思ったより広がり、最初に感じていた手応えは薄れていきます。

実際に出てくる例外は、担当者ごとに異なる入力の順番であったり、月末だけ締め方が変わる処理であったり、これまで担当者本人が気づかないうちに手作業で吸収していた確認であったりします。口頭で聞いた範囲にはこうした細部が含まれていないことが多く、動くものを見せて初めて表面化します。

この食い違いは、依頼した担当者だけでなく、その処理結果を受け取る別の部署の手間にもつながります。表面化した例外への対応をそのつど引き受けるたびに、作った側と使う側の双方に確認の往復が積み重なっていきます。

例外は、作った後ではなく作る前に見つけられる

例外が後から出てくる原因は、腕ではなく、依頼を受けた時点で確認する順番が決まっていなかったことにあります。同じ担当者から同じような案件を任される場面が続くほど、この順番の差は積み重なっていきます。

その場で仕様を決めて動かすことよりも、作る前に業務の流れを一度そろえておくことのほうが、後の手戻りを小さくします。これは慎重になるという話ではなく、確認する対象を先に決めておくという順番の話です。

作る前にやることは、すでに一覧になっている

何を確認すればよいか迷う場面では、行政のデジタル化を進める実践ガイドブックが企画の段階で並べている確認項目が手がかりになります。自治体や府省向けに書かれた文書ですが、業務を整理する観点そのものは業種を問わず読み替えられます。

次の項からは、その一覧のうち業務をそろえる部分を、GASの案件を引き受ける場面に置き換えて、順番に見ていきます。

図の作成：Remogu編集部。作る前にそろえる進め方を整理したもので、統計データではありません

2. 作る前に、業務をそろえる

「業務を標準化する」が、企画の項目として置かれている

実践ガイドブックのサービス・業務企画の章には、システムを作る前に、業務を標準化するという項目が置かれています¹。工夫や心構えとしてではなく、企画の段階で確認する明文の項目として並んでいる点に意味があります。

GASの案件に置き換えると、これはスクリプトを書き始める前に、担当者ごとの手順の違いを一度そろえる作業に当たります。手順がそろっていれば、動くものを見せた後の質問はぐっと減ります。

業務をそろえる作業は、参画が決まった直後、実際に手を動かし始める前の打ち合わせの場で行うと、後の手戻りを最も防げます。依頼した担当者本人に加えて、その処理結果を受け取る部署の窓口にも同席してもらえると、その場で認識を合わせられます。

チェックリストにも、同じ確認が並んでいる

予算要求前のチェックリストにも、システムを作る前に、業務を標準化したかという確認項目が並んでいます²。企画を通す段階で目を通す項目として位置づけられていることが分かります。

動くものを見せる前に確認する項目としてすでに用意されている以上、感覚に頼るよりも、この並びを先に通しておくことのほうが、後工程との整合を取りやすくなります。

業務を紙に落とすときに、書き出す3つの軸

企画の工程で行う活動として、業務の現状把握と分析、業務フロー等の可視化、実績データ分析が挙げられています⁷。GASでの自動化を引き受ける場面に置き換えると、これは担当者への聞き取り手順を新しく組み立てることではなく、今ある手順・分かれ道・処理の頻度を紙に落とす作業に当たります。

項目	書き出す内容	確認する相手
現状把握と分析	今の手順を誰がどの順番で行っているか	実際に手を動かしている担当者
業務フロー等の可視化	判断が分かれる分岐点と、例外の扱い方	担当者ごとに手順が変わる部署の窓口
実績データ分析	これまでの処理件数や発生頻度の傾向	依頼元の担当者、または上位の意思決定者

表にまとめた3つの軸を作る前に確認しておくと、動くものを見せた後の「この場合はどうするのか」という問いに、依頼を受けた時点で答えを持っておけます。

紙に落とすときは、今の手順と分かれ道、処理の頻度までを書き出す一方で、実装の方法や画面の細かな操作手順までは書き込みません。実装の細部を早い段階で固定すると、あとで変更が必要になったときの調整がかえって難しくなるためです。

3. 作りすぎない線を、先に引く

「シンプルな企画案になっているか」という確認

同じチェックリストには、自分で作りすぎず、シンプルな企画案になっているかという項目もあります³。積み上げてきたスキルがあるからこそ、頼まれた範囲より先まで手が届いてしまう場面は珍しくありません。

手が動く人ほど、頼まれた範囲の外側まで整えたくなりますが、その広げ方自体が確認の対象になっている点は押さえておきたいところです。作りすぎは善意から始まることが多く、気づきにくい落とし穴になります。

作りすぎた仕組みは、その分だけ内側が複雑になり、直せるのが実装した本人だけという状態を生みやすくなります。小さな変更のたびに呼び出される場面が増えると、次の依頼に振り向けられる時間はその分だけ目減りしていきます。

一度に全部を実現しない、という選び方

同じチェックリストには、一遍に全てを実現するのでなく、段階案を検討したかという項目も置かれています⁴。最初の依頼の裏側に、まだ言葉になっていない要望が眠っていることは少なくありません。

最初から全体を仕上げることよりも、段階に割って引き渡すことのほうが、依頼主が途中で確認できる区切りを残せます。区切りがあれば、方向がずれても手戻りは一段階分で収まります。

最初の段階に入れるのは、依頼された範囲の中でも繰り返し発生している処理だけに絞り、発生頻度の低い例外や、まだ言葉になっていない要望は外しておきます。外した部分は次の段階の候補として残しておけば、必要になった時点で足せます。

段階に割ると、引き継ぎも軽くなる

段階を区切ると、途中まで作った時点で「思っていたのと違う」という声を早い段階で受け取れるようになり、作り直す範囲も小さく収まります。次の担当者へ引き継ぐときも、区切りごとの説明で済みます。

図に示した3つの段階は、どこまで作ったら次に進んでよいかを決める目印としても使えます。段階の境目で一度立ち止まる時間を、あらかじめ見込んでおくとよいでしょう。

図の作成：Remogu編集部。段階を区切って進める考え方を整理したもので、統計データではありません

4. 端から端まで見てから、手を付ける

「エンドツーエンドの視野」という確認項目

同じチェックリストには、エンドツーエンドの視野での企画案になっているかという項目が置かれています⁵。頼まれた作業の内側だけを見ていると、この項目は見落としやすくなります。

頼まれた作業だけを速くしても、その前工程や後工程が詰まっていれば、業務全体の流れは変わりません。自動化する範囲を決める前に、その前後がどうつながっているかを確かめておきたいところです。

部分だけを速くした結果としてよく起きるのが、前工程の入力がそろわないまま自動化が動き出してしまう状態や、後工程の担当者が出力の形式を読み取れず、結局手作業で加工し直してしまう状態です。速くなったはずの工程の前後で、かえって確認の手間が増える場合もあります。

部署の境目に、やわらかく橋を架ける

サービス・業務企画の視点には、縦割り組織にやわらかく横串を刺すという項目も置かれています⁶。自分の担当範囲の外まで確かめることは、口を出すことではなく、確認の範囲を広げることだと捉えると動きやすくなります。

自分の担当範囲だけを見ることよりも、前後の部署がその出力を何に使っているかまで確かめることのほうが、後から「使えない」という声が届く場面を減らせます。

部署をまたいで聞くときは、担当範囲を超えて口を出すという構えではなく、依頼された処理の前後で困っていることがないかを尋ねる持ち出し方にすると、相手も答えやすくなります。「この処理の前後で、何か確認していることはありますか」という聞き方が入り口になります。

前後の工程で確かめておくこと

前後の工程を確認する対象は、自動化する作業そのものだけではありません。前工程で扱うデータがどんな形で作られているか、後工程でその出力を誰がどう使うか、例外が起きたときにどの窓口へ連絡が届くかまで含めて確認しておくと、部分だけを速くして終わる状態を避けられます。

工程	確認すること
前工程	自動化の対象になるデータが、どんな形式・頻度で作られているか
自動化する工程そのもの	例外が起きたときに、誰の判断を仰ぐか
後工程	出力を受け取る部署が、それを何に使っているか
連絡経路	例外や不具合が起きたときに、どこへ連絡が届くか

表に挙げた4つの確認先を先に押さえておくと、作った後になって別の部署から要望が届くという場面を、作る前の段階で減らせます。

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

5. 効果を業務の流れに紐づけて語る

「効果を紐づける」という視点

サービス・業務企画の視点には、将来の業務フローには、効果を紐づけるという項目が置かれています⁸。作った後の説明で終わらず、その先の業務にどうつながったかまでを語る視点です。

作ったものの効果を伝えようとするとき、かかっていた時間の数字を作りたくなりますが、その数字は出典のない数値と同じ扱いになってしまいます。手元に根拠がない数字は、語らないほうが信頼を保てます。

効果を語るときに並べるのは、どの手順がなくなったか、どこで確認の待ち時間が変わったか、誰が担っていた作業が減ったかという業務の流れの変化です。数字を測っていなくても、こうした変化は具体的に説明できます。

業務の流れが、どこでどう変わったかで語る

時間の数字を自分で作ることよりも、業務の流れのどこがどう変わったかを言葉にすることのほうが、依頼主にも次の依頼主にも伝わりやすくなります。数字がなくても、変化そのものは十分に説得力を持ちます。

例えば、確認のために別の担当者へ回していた工程が、自動化によってその場で完結するようになったという変化は、時間を測らなくても伝えられます。工程が減った、確認先が変わった、という事実だけで十分です。

こうして業務の流れの変化として語れる経験は、次の案件を引き受けるときの、最初の打ち合わせでそのまま使える言葉になります。同じ形で説明できる経験が積み重なるほど、依頼主に伝わる速さも増していきます。

GASの経験を、4つの層で書き出す

実績を言葉にするときは、GASの経験を実装した内容だけでなく、その先の業務フローまで含めて4つの層に分けて書き出しておくと、次の依頼主に説明するときにも使い回せます。

層	書き出す内容
実装した内容	GASでどんな処理を組んだか
効いた業務フロー	その処理が、どの工程の流れを変えたか
変化した判断や動き	担当者の確認や判断が、どう変わったか
次に活かせる経験	次の案件でも使える、業務をそろえる進め方

表に挙げた4つの層をそろえておくと、参画先が変わっても同じ形で自分の経験を説明でき、「言われたものを作るだけの相手」に見られる場面を減らす材料にもなります。

図の作成：Remogu編集部。実装した内容と業務フローの変化を経験として書き出す考え方を整理したもので、統計データではありません

6. まとめ

自動化の案件で「思っていたのと違う」と言われる場面は、腕の差ではなく、作る前に何を確認したかの差から生まれます。業務を標準化する¹という項目からエンドツーエンドの視野で確認する⁵という項目まで、実践ガイドブックの並びをそのまま引き受ける場面に置き換えて通すだけで、後から出てくる例外は作る前の段階で先に見つけられるようになります。

「言われたものを作るだけの相手」に見られる不安は、作る前の順番を押さえ、実績を4つの層で言葉にする⁸ことで、企画の段階から関われる相手として見てもらう材料に変わります。

場所に縛られず、積み上げてきた自動化の経験を活かせる働き方を探しているなら、Remogu（株式会社LASSIC運営）はリモートワーク案件に特化したエンジニアマッチングで、案件の90%以上がフルリモート可能です⁹。

まずは登録して、業務をそろえる進め方が活かせる案件の条件を、自分の目で確かめてみましょう。

7. よくある質問

「言われたものを作るだけの相手」に見られないためには、どうすればよいですか

作る前に業務をそろえる4つの軸を確認してから引き受けると、依頼された作業だけを進める相手ではなく、企画の段階から関われる相手として見てもらいやすくなります。

自分にしか直せないものを増やさないためには、どうすればよいですか

段階に区切って作ることや⁴、前後の工程を先に確かめておくこと⁵は、自分だけが仕組みを把握している状態を増やさない助けになります。

仕様書がない現場では、どこから始めればよいですか

現状把握と分析、業務フロー等の可視化、実績データ分析の3つを紙に落とすところから始めると⁷、口頭の依頼だけでは見えなかった分岐点を、作る前の段階で見つけられます。

政府向けの実践ガイドブックは、民間の案件でも参考になりますか

実践ガイドブックは行政のデジタル化における企画の考え方を示した参考文書であり、民間の案件がそれに従う義務があるものではありません。ただし、業務を標準化してから作り始めるという考え方自体は、依頼主が官公庁でも民間企業でも変わらず参考にできます。

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

出典・参考情報

＊1 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第4章 サービス・業務企画（心構えと視点）（2026年6月12日）
＊2 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第1章 チェックリスト（サービス・企画内容の検討）（2026年6月12日）
＊3 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第1章 チェックリスト（サービス・企画内容の検討）（2026年6月12日）
＊4 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第1章 チェックリスト（サービス・企画内容の検討）（2026年6月12日）
＊5 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第1章 チェックリスト（サービス・企画内容の検討）（2026年6月12日）
＊6 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第4章 心構えと視点（2026年6月12日）
＊7 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第2章 プロジェクトの管理（企画の活動の総括）（2026年6月12日）
＊8 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第4章 心構えと視点（2026年6月12日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）