部署別 / 情報政策課・DX推進

情報政策課・DX推進の職務経歴書｜書き方と、そのまま使える記述例

2026年9月時点の公開情報にもとづきます。制度や募集要項は変わることがあるため、手続きの前に各機関の公式情報をご確認ください。

情報政策課の職務経歴書で、いちばん多い1行目はこれです。

「基幹系システムの更改を担当。◯◯システムの導入に従事。」

事実です。ただ、読んだ側には何も残りません。システム名は自治体向けの製品で、民間の読み手は知りません。そして「導入に従事」という言葉には、自分が何を判断したかが現れていません。

この記事では、情報政策課・DX推進の仕事を職務経歴書にどう落とすかを、悪い例と良い例を並べて整理します。

言い換えの一覧は情報政策課・DX推進の経験は民間で何と呼ばれるかに、行き先の選び方は情報政策課・DX推進からの転職先に分けて書いています。この記事は、書類そのものの話です。

「オンライン化する法律」が、格差の是正まで書いています

書き方の前に、一つ押さえます。ここを取り違えると、書類の方向がずれます。

情報通信技術を活用した行政の推進等に関する法律（デジタル手続法）第1条は、この法律が、デジタル社会形成基本法第17条及び官民データ活用推進基本法第7条の規定に基づく法制上の措置として、あらゆる活動において情報通信技術の便益を享受できる社会が実現されるよう、情報通信技術を活用した行政の推進について、その基本原則及び情報システムの整備、情報通信技術の利用のための能力又は利用の機会における格差の是正その他、情報通信技術を利用する方法により手続等を行うために必要となる事項を定める、としています。

注目してほしいのは、「格差の是正」が同じ条文に入っていることです。

オンライン化を進める法律が、使えない人・使える環境にない人への手当てを、同じ目的のなかに置いています。

つまり、この仕事は「デジタルに置き換える」だけでは終わりません。置き換えられないものをどうするかまでが、範囲に入っています。

だから職務経歴書に書くべきなのは、導入した件数ではありません。何を置き換え、何を残し、残したものにどう手当てしたかです。

書類全体の形を決める

情報政策課の場合、応募先が変わっても共通する組み立てがあります。

1. 職務要約（5〜8行）
2. 担当業務（箇条書き。製品名ではなく機能で）
3. 実績（3〜4件。1件あたり5〜8行）
4. 活かせる経験・スキル（応募先に合わせて並べ替える）

読まれるのは職務要約と実績です。担当業務の箇条書きは確認のために目を通される程度なので、時間は実績に使ってください。

職務要約の書き方

悪い例

> ◯◯市役所に入庁後、市民課を経て情報政策課に配属。基幹系システムの運用保守、◯◯システムの更改、庁内ネットワークの管理等を担当。現在は情報政策課主査として、自治体DXの推進に従事している。

システム名と部署名しかありません。どこにでもある書類になります。

良い例

> 市役所に入庁後、市民課で窓口を4年、情報政策課で7年。情報政策課では住民記録・税・福祉の基幹系システムの更改を、要件定義から稼働後の安定までを通して担当した。契約規模はおよそ◯億円、対象業務は◯業務、関係する課は◯課。各課からの改修要望を年間◯件受け付け、費用と影響範囲で優先順位をつけて事業者に発注する運用を作っている。オンライン申請は◯手続を導入したが、本人確認と原本の提出が必要な◯手続は窓口を残し、代替の予約制を用意した。稼働直後の不具合については、事業者と切り分けの手順を決めて対応にあたっている。

違いは4つです。

1. どこからどこまでを通したかが書いてある（要件定義から稼働後の安定まで）2. 規模が書いてある（契約金額、業務数、課の数、要望の件数）3. 導入だけでなく、残した手続と手当てが書いてある4. 止まったときの話が入っている

3つ目と4つ目が、この経歴でいちばん差が付く部分です。

担当業務の書き方

箇条書きにします。製品名ではなく機能で書いてください。

悪い例

> ・◯◯システム（住民情報系）の運用保守> ・◯◯クラウドサービスの導入> ・◯◯ネットワークの管理

読み手は製品を知りません。

良い例

> ・基幹系システムの更改（住民記録・税・福祉の◯業務、契約規模◯億円、要件定義から稼働まで◯年）> ・データ移行の計画と検証（移行対象◯件、突合の方法の設計を含む）> ・各課からの改修要望の受付と優先順位づけ（年間◯件、◯課）> ・事業者の選定（仕様書の作成、◯社からの提案の評価、契約）> ・運用保守事業者との定例協議、障害発生時の切り分けと指示> ・庁内ネットワークと端末の管理（◯台規模、更新計画の策定）> ・情報セキュリティポリシーの改定と、全職員向け研修の実施（年◯回）> ・個人情報の目的外利用の可否の審査（年間◯件）> ・オンライン申請の導入（◯手続、窓口を残した◯手続の整理を含む）

製品は畳み、機能と規模だけを残します。この形なら、民間のどの職種に対応するかも分かります。

実績の書き方――ここに時間を使う

実績は3〜4件に絞ります。書く形は状況 → 論点 → 自分の判断 → 結果です。

悪い例

> 基幹系システムの更改を担当し、予定どおり稼働させた。

「予定どおり」しかありません。何を判断したのかが分かりません。

良い例

> 【オンライン化で、窓口を残す手続を先に決めた】> 申請手続のオンライン化を進めるにあたり、当初は対象を全手続とする方針だった。ただし各課に確認したところ、本人確認が法令で求められるもの、添付書類が原本でなければならないもの、聞き取りをしないと申請内容が確定しないものが一定数あることが分かった。> そこで、全◯手続を「そのままオンライン化できるもの」「様式を変えればできるもの」「窓口を残すもの」の3つに分類し、3つ目については理由を法令と運用の両面から整理して庁内で共有した。窓口を残す手続については、待ち時間を減らすための予約制を代わりに用意している。> 結果として、オンライン化したのは◯手続、窓口を残したのは◯手続となった。分類の基準は、その後の手続追加でもそのまま使われている。

長く見えますが、9行です。ここに書かれているのは導入件数ではありません。方針をそのまま実行しなかったという判断、3分類という手段、残す理由を整理して共有したこと、そして代替を用意したことです。

「できないものを見つけて、理由を説明し、代わりを用意した」という形は、企業の業務改革でもそのまま求められます。

実績に使える題材

情報政策課なら、次のような題材が使えます。

• オンライン化で、残す手続を決めた話（上の例）
• 事業者を選んだ話（何を基準にしたか、価格以外に何を見たか）
• データ移行の検証で、差異を見つけた話
• 稼働後に止まったときの対応（切り分けと、事業者への指示）
• 各課の要望に優先順位をつけた話（基準をどう決めたか）
• 個人情報の目的外利用を認めなかった話（何を根拠に判断したか）
• セキュリティの規程を現場が守れる形に直した話
• 標準化への移行で、業務側の例外を整理した話

数字の出し方

情報政策課の書類では、規模が伝わる数字を使います。

情報政策課は扱う規模が大きい部署です。規模を書かないのは損なので、必ず入れてください。

求人票の言葉に合わせて並べ替える

方向ごとの詳細は情報政策課・DX推進からの転職先に整理しています。

つまずきやすい点

1. 製品名を並べる

読み手は自治体向け製品を知りません。機能で書いてください。

2. 「導入した」で止める

残したものと、その理由を必ず添えてください。これがこの経歴の差別化点です。

3. 規模を書かない

情報政策課は扱う規模が大きい部署です。契約金額、業務数、課の数、データ件数。書かないのは損です。

4. 事業者との関係を書かない

何社から選び、何を基準にし、契約後にどう管理したか。ベンダーマネジメントは求人票に出てくる言葉です。

5. 主語が消える

「更改を実施した」では、課としてなのか自分なのかが分かりません。課の成果と自分の関与を分けてください。「課として更改し、自分は要件定義と移行の検証を担当した」で十分です。

6. 在職中の資料をそのまま使う

仕様書や設計書を持ち出して添付することはできません。自分で作り直した説明資料に置き換えてください。セキュリティの構成や、事業者名と契約の細部も書かないほうが安全です。

自分の経歴がどう言い換えられるかは、一度話しながら整理したほうが早いことが多いです。どの経験に値が付くのかから相談できます。

LINEで短く聞くこともできます

まとめ

• デジタル手続法第1条は、オンライン化を進める法律でありながら、「情報通信技術の利用のための能力又は利用の機会における格差の是正」を同じ条文に入れています
• 置き換えられないものをどうするかまでが、この仕事の範囲です
• だから書類に書くのは導入件数ではなく、何を置き換え、何を残し、残したものにどう手当てしたかです
• 担当業務は製品名ではなく機能で書き、契約金額・業務数・課の数・データ件数を必ず添えてください
• 実績は状況 → 論点 → 自分の判断 → 結果の順に、3〜4件だけ書きます
• 「うまくいかなかったときの記述」を1件入れてください。止まらなかった実績より、止まったときに何をしたかが読まれます

よくある質問

契約金額を書いてよいですか

公表されている入札・契約の情報の範囲であれば、概算で書いて差し支えありません。「およそ◯億円規模」で十分です。ただし、事業者名と契約の細かい条件は書かないほうが安全です。規模が伝わればよいので、金額だけで足ります。

開発をしていないのに「要件定義」と書いてよいですか

書いて構いません。要件定義は、何を作るかを決める工程であって、作る工程ではありません。各課の業務を聞き取り、何をシステムで処理し、何を人が処理するかを決め、仕様書に落とす。情報政策課がやっているのは、まさにこの工程です。ただし「要件定義を担当」とだけ書くと薄いので、何業務を、何課から聞き取り、どう仕様に落としたかを添えてください。

セキュリティの経験は、どこまで書けますか

規程を作った・改定した・研修をした・審査をした、という事実は書けます。一方で、実際の構成や、どういう対策を講じているかは書かないでください。在職中の団体の守りに関わります。書くなら「規程を現場が守れる形に直した」「年◯回の研修を設計した」「目的外利用の可否を年間◯件審査した」のように、取り組みの形と量で書いてください。