企業のデジタル化を支える仕事

この教材でたどる機能と役割

以下は読む順番です。すべての企業がこの順で直接取引することを示す図ではありません。

1. 1
   変える業務を決める

   目的、現場の課題、成果を整理

   コンサルティングを学ぶ →
2. 2
   仕組みをつくる

   業務とデータを設計し実装

   ITサービスを学ぶ →
3. 3
   計算・通信を使う

   基盤を調達して運用

   AI・クラウドを学ぶ →
4. 4
   現場で使い続ける

   利用者の行動と成果を確認

   小売・ECを学ぶ →

システムを入れることと、成果を出すこと

紙の申請を画面へ置き換える、在庫を一つの台帳で見る、問い合わせにAIを使う。いずれもデジタル技術の活用ですが、目的は同じではありません。作業時間を減らしたいのか、ミスを減らしたいのか、顧客へ新しいサービスを届けたいのかによって、必要な設計と評価が変わります。技術の名前より先に、変えたい結果を書きましょう。

IPAのデジタルスキル標準は、共通のリテラシーとDXを推進する人材の役割を整理しています。企業研究で役立つのは、「デジタル人材」という一つの職種を探すより、業務、データ、設計、実装、保護などの役割を分けることです。以下の例は特定の企業の成果を示すものではなく、役割と事業を調べるための架空事例です。

参照資料：デジタルスキル標準

在庫のずれを、データだけの問題にしない

ある小売企業で、画面に表示される在庫と倉庫の実数が合わないとします。新しいシステムを買う前に、入庫、出庫、返品、棚卸しで誰がいつ記録するかを確認します。同じ商品に複数のコードがある、更新のタイミングが違う、例外処理が紙に残るなど、業務とデータの境目に原因があるかもしれません。

この場面では、現場への聞き取り、商品データの定義、既存システムとの連携、画面の設計、テスト、運用教育が必要です。すべてを同じ会社が担う場合も、複数社と利用企業が分担する場合もあります。役割分担は契約や組織によるため、SIer、SaaS、コンサルティングという分類だけで担当範囲を決め付けないようにします。

クラウドに移しても責任は残る

AWSの責任共有モデルでは、クラウド事業者と利用者が担う範囲を区別し、利用するサービスによって利用者側の責任が変わるとしています。基盤の運用負担を減らせても、利用者権限やデータの扱いまで自動的に適切になるわけではありません。どの作業を任せ、どの判断を自社で持つかという設計が必要です。

企業研究では、導入支援と継続運用を分けて見ましょう。移行時に必要な作業、日々の監視、問い合わせ、更新、障害時の対応では、仕事のリズムも求められる成果も違います。顧客のシステムを扱う企業に関心があるなら、何をもって完了とする契約か、稼働後にどの範囲を支えるかを調べると、事業の理解が深まります。

参照資料：Shared Responsibility Model

AIを加えるときの問いを立てる

在庫や顧客対応へAIを組み込む場合も、導入自体を成果にしないことが大切です。何を入力し、誰が出力を使い、間違いが起きたらどこで気付くのかを整理します。人の確認を置く場合は、確認にかかる時間や、判断に必要な情報も設計の対象になります。技術の評価だけでなく、運用の手間まで含めて考える練習です。

同じ時間短縮でも、部署内の一作業だけが速くなり、別部署の確認が増えることも想定できます。そこで成果指標を、処理時間、やり直し、利用継続、顧客の体験など複数に分けておきます。これらは特定ツールの性能を断定するものではなく、導入事例を読むときに見落としを減らす編集部の分析枠組みです。

会社の業態より、担当する課題を比べる

就職先を比べるときは、「上流だから良い」「自社製品だから自由」といった短い言葉だけに頼らず、どの顧客と、何を決め、どこまで責任を持つ仕事かを調べてください。受託開発でも継続して改善する仕事があり、自社サービスでも顧客ごとの調整が必要な場合があります。募集されている部署と担当業務まで確認して初めて比較できます。

練習では、同じ業務領域に関わる二社を選び、一社はサービスを提供する立場、もう一社はそれを利用・導入する立場として読みます。収益を受け取る契約、成果を評価する人、利用後の改善を担う人を書き分けてください。自分が仕事で扱いたい問いを一つ残し、ITサービス教材の職種の章と企業探索を行き来すると、学習を具体的なキャリア研究につなげられます。

提案・開発・運用を同じ案件で比べる

一つの改善案件を通して職種を見ると、仕事内容を具体化できます。提案の段階では、誰が困っているか、費用をかける目的は何か、成果をどう判断するかを整理します。開発の段階では、仕様、既存システムとの接続、テスト、変更への対応が課題になります。運用の段階では、利用者の問い合わせや障害、改善要望を扱います。すべてを一人が担当するとは限りません。

比較では、各段階の成果物を一つずつ想像してください。業務の流れを示す図、動作を確認した機能、異常を検知する監視と対応手順などです。自分が作ってみたい成果物を選ぶと、単に「ITに興味がある」という状態から、具体的な学習や職種の調査へ進めます。募集情報では職種名だけでなく、担当顧客、チーム、働き方、評価される結果を確かめましょう。

会社を調べる際は、その会社自身の改善と、顧客向けに売るサービスも分けます。社内のAI利用事例があることと、顧客へAI導入支援を提供することは別です。また導入件数の発表と、利用が定着したことや利益への寄与も同じではありません。発表の対象と確認できる結果を短く書き出し、事実からどこまで解釈したかを残すと、企業比較を更新しやすくなります。

ノートには、導入前の課題、実施したこと、確認できた結果の三つの欄を作ると便利です。結果がまだ示されていない発表も、そのまま未確認として残せます。次に読む資料の目的がはっきりするため、事例の件数だけを集めるより、業務の変化を説明しやすくなります。