クラウドの導入はもう一巡した、という受け止めが広がっています。一部の部門で使い始める段階を終えた企業は増え、話題は全社でどう使いこなすかに移りつつあります。数字を並べてみると、その移行にはまだ大きな差が残っていることが分かります。この差の中に、これから人の手が必要になる仕事が具体的な形で詰まっています。この記事では、その差が生む仕事の中身と、エンジニアとして関われる範囲を整理します。

1. 一部利用は8割超、全社利用は60.0％です

クラウドサービスを一部でも利用している企業の割合は、8割を上回る水準まで達しています¹。この数字を目にすると、クラウドの導入はすでに一巡し、検討する余地はもう残っていないように感じられます。

ところが同じ調査で、全社的に利用している企業の割合を確認すると、60.0％にとどまっています²。一部の部門で使い始めた状態と、組織全体で使いこなしている状態の間には、まだ埋まっていない開きが残っています。

「一部で使っている」と「全社で使える」は、同じ言葉のようで到達点が違います。前者は入口を通った状態を指し、後者は仕組みとして根づき、日々の判断の中に組み込まれた状態を指します。この違いを取り違えると、既に落ち着いた領域に見えてしまい、実際に動いている仕事を見過ごすことになります。

この差は誤差ではありません。むしろ、これから人の手が入る仕事がどれだけ残っているかを示す量です。数字の大きさよりも、そこにどんな作業が詰まっているかを見ていく視点が要ります。この視点を持てるかどうかで、同じ案件情報を読んでも見える仕事の量が変わってきます。

同じ調査の中にある、二つの物差し

8割超のほうは一部でも利用している企業の割合を測ったものです¹。60.0％のほうは、全社的な利用という別の設問を測ったものです²。測っているものが違うと分かれば、この二つの数字を対立させて読む必要はなくなります。

この二段階を意識せずに「クラウドはもう普及した」とひとまとめにしてしまうと、実際に動いている仕事の輪郭を見誤ります。全社的な利用の水準がまだ道半ばであることは、部門をまたいで関わる余地がそのまま残っていることを意味します。

むしろ、普及の進み方を二つの段階として捉える手がかりになります。導入したかどうかを見る段階と、組織全体で使いこなせているかどうかを見る段階です。次の章では、この間にある差の中身を具体的に見ていきます。

出典：総務省「令和7年通信利用動向調査の結果」（2026年5月）をもとに作成

案件情報を読むときも、この二段階を意識しておくと判断のぶれが減ります。「導入済み」と書かれていても、全社に行き渡っているかどうかまでは、その一文だけでは分かりません。中身を確認する視点を持っておくと、案件を選ぶときに役立ちます。

2. 差の分が、これから広げる仕事です

一部利用が8割を超えている一方で¹、全社的な利用は60.0％にとどまっており²、その間には部門ごとの利用を全社に広げる仕事がそのまま残っています。

部門ごとに導入したクラウドは、その部門の担当者だけが使い方や設定の勘所を把握している状態にとどまりやすい面があります。ほかの部門から見ると、同じ仕組みのはずなのに扱い方が分からない、という状況が起きやすくなります。担当者が変わった途端に運用が止まる、という事態も起こりえます。

全社で使える状態にするには、権限の設計や運用のルールを部門をまたいで揃える工程が要ります。導入の速さより、揃える設計の丁寧さのほうが、全社展開の成否を分けます。

この工程を軽く見て導入だけを急ぐと、部門ごとに違うルールが積み重なり、あとから揃え直す手間がかえって増えます。急がば回れという言葉が、そのまま当てはまる場面です。目先の速さを優先した判断のしわ寄せは、たいてい後の工程に回ってきます。

部門利用と全社利用の間にある工程

この工程は、クラウドを初めて触るという扱いにはなりません。既に動いているものを、部門をまたいで誰もが同じ手順で使える形に整え直す仕事です。ゼロから作る仕事より地味に見えますが、影響する範囲は組織全体に及び、関わる工程の数も増えていきます。

作り込む力よりも、既にあるものを整え直す視点のほうが求められる場面です。地道に見える調整の積み重ねが、結果として全社展開の速度を左右します。次の章では、企業がクラウドを使う理由の中で何が伸びているのかを見ることで、この仕事に何が求められているのかを読み解きます。

図の作成：Remogu編集部。全社展開までの流れを整理したもので、統計データではありません

この整え直しに関わる人には、部門ごとの事情を丁寧に聞き取りながら、共通のルールに落とし込む調整力が求められます。技術だけでなく、部門間の橋渡しをする姿勢も同じくらい重要です。

3. 使う理由で伸びているのは拡張性です

クラウドを使う理由を尋ねた設問では、「システムの拡張性が高いから(スケーラビリティ)」の回答が前年より最も大きく増えており、その伸びは6.8ポイントに達しています³。理由の中で最も動いた項目が、拡張性だったということです。

拡張性という理由が伸びている裏には、使う量や範囲をあらかじめ決めきれない、という組織側の事情があります。事業の計画自体が変わりやすくなっている中で、容量を先に固定してしまう設計は選びにくくなっています。先の見通しが立てにくい時期ほど、この理由の重みは増していきます。

容量を固定する設計より、状況に応じて伸び縮みさせる設計のほうが選ばれやすくなっています。この伸びは、費用を抑えるためだけの選択ではないことを示しています。

事業の変化に合わせて仕組み自体を動かせるかどうかが、選ばれる基準に新しく加わっています。ここで問われているのは、決められた容量を運用する力ではなく、変化を受け止める設計を組む力です。

この理由の伸びを、アンケートの一項目として読み飛ばしてしまうと、案件の中身を見誤ります。拡張性を理由に挙げる企業が増えているということは、伸縮を前提にした設計を任せられる人を探している企業も増えている、という読み方ができます。数字の裏側にある発注側の事情まで読み取ると、案件情報の見え方も変わります。

理由の並びと設計への影響

拡張性を含め、クラウドを使う理由として挙げられている項目を並べると、それぞれが対応する設計の重点が見えてきます。数値の大小ではなく、理由の種類として捉えてください。

理由	具体的な内容	設計で確認したいこと
拡張性	システムの拡張性が高いこと3	需要の変動に応じて伸縮させる仕組み
資産・保守体制	資産、保守体制を社内に持つ必要がないこと4	保守や更新の作業をどこまで引き受けるか
災害時の備え	災害時のバックアップとして利用できること5	復旧の手順と切り替えの確認方法
信頼性	サービスの信頼性が高いこと（情報漏えいなど対策）6	アクセス権限と記録の残し方
容量変更への対応	システムの容量の変更などに迅速に対応できること7	変更を受け止める仕組みの設計

拡張性を軸にした設計の経験は、特定の技術に限らず幅広い案件で評価されやすい経験です。積み上げてきた経験を言葉にするときは、扱った技術名よりも、伸縮の設計にどう関わったかを中心に語ると伝わりやすくなります。

拡張性以外の理由についても、次の章でそれぞれが指す設計の重点を見ていきます。理由が示す方向性を押さえておくと、案件で求められる経験を言葉にしやすくなります。

4. 理由の並びから、求められる設計が読めます

四つの理由が指す設計の重点

資産や保守体制を社内に持たずに済むこと⁴、災害時にバックアップとして使えること⁵、信頼性が高く情報漏えいなどへの対策になること⁶、容量の変更に迅速に対応できること⁷。この四つは、いずれも「持たない」か「変えられる」かのどちらかに関わる理由です。

持たない、という理由からは、保守や監視の一部を外側に預ける設計が求められます。すべてを自分たちで抱え込む前提を崩し、どこまでを預けてよいかを線引きする作業が必要になります。預ける範囲を誤ると、かえって確認の手間が増えることもあるため、線引きの精度がそのまま設計の質になります。

変えられる、という理由からは、需要に応じて伸縮する仕組みが求められます。あらかじめ決めた容量を守る設計ではなく、変化を前提にした設計へと考え方を移す必要があります。

機能を作り込む力よりも、預ける範囲と自分で持つ範囲を線引きする力のほうが、この場面では重宝されます。この線引きは一度決めて終わるものではなく、事業の状況に合わせて見直しが続きます。過去に決めた基準をそのまま使い続けるより、状況が変わるたびに問い直す姿勢のほうが求められます。

この線引きを誰か一人の判断に委ねてしまうと、担当が変わるたびに基準が揺れ、同じ議論を何度も繰り返すことになります。判断の根拠を言葉にして残しておくことが、全社展開の場面ではそのまま評価される仕事になります。

この線引きを丁寧に行っている企業ほど、参画するエンジニアに求める役割も明確になっている傾向があります。曖昧なまま任される案件より、線引きが済んでいる案件のほうが、自分の経験を発揮しやすくなります。

全社に広げる段階では、部門ごとに引いていた線を、組織全体で揃え直す作業が発生します。部門の数だけ判断の基準がばらついていると、揃え直す手間はそのまま増えていきます。次の章では、この線引きを組織全体で揃え直すときに、実際にどんな論点が出てくるのかを整理します。

出典：総務省「令和7年通信利用動向調査の結果」（2026年5月）に挙げられている理由をもとに作成

5. 全社展開で出てくる論点を整理します

部門ごとの使い方を全社の仕組みに揃えるとき、最初に出てくるのは権限の設計です。誰がどこまで操作できるかを、部門の垣根を越えて決め直す必要があります。部門ごとにばらばらだった基準を一つに揃える作業は、思っている以上に時間がかかります。

次に出てくるのが費用の見え方です。部門ごとに払っていた費用を、全社でどう配分して捉えるかという論点です。部門単位の感覚のままでは、全社で見たときの費用の姿がつかめません。

三つ目は、障害が起きたときの切り分けです。全社で共有する基盤になるほど、影響が及ぶ範囲も広くなり、どこで止まったのかを素早く特定する仕組みが要ります。

四つ目は、既存のシステムとの接続です。全社に広げるほど、これまで別々に動いていた仕組みをつなぐ場面が増え、接続の数だけ確認する箇所も増えていきます。

この四つの論点は、どれか一つだけを整えても解決しません。権限を整えても費用の見え方が曖昧なままでは、投資の判断が遅れます。四つを並行して見ていく視点が、全社展開を任される人には求められます。

全社展開で確認したい四つの論点

この四つの論点を、内容と確認したいことに分けて次の表にまとめました。

論点	内容	確認したいこと
権限の設計	誰がどこまで操作できるかを部門をまたいで決め直すこと	権限の粒度と、変更時の承認の流れ
費用の見え方	部門ごとの費用を全社でどう捉え直すかということ	どの単位で費用を切り分けて示すか
障害時の切り分け	共有する基盤が広がるほど影響の範囲も広がること	どこで止まったかを特定する手順と記録
既存システムとの接続	別々に動いていた仕組みをつなぐ場面が増えること	接続点の仕様と、変更時の影響範囲

図の作成：Remogu編集部。全社展開で確認したい論点を整理したもので、統計データではありません

四つの論点はいずれも、部門ごとの前例をそのまま全社に広げるだけでは片づきません。全社という単位で最初から設計し直す姿勢が、全社展開のプロジェクトでは特に重宝されます。

この論点は、どれも一度決めれば終わるものではありません。事業の状況が変わるたびに、揃え直す作業がまた発生します。次の章では、この数字がどんな企業を対象にしたものかという前提を確認します。

6. 数字を読むときの前提を押さえます

ここまで見てきた数字は、どんな企業を対象にした調査なのかを確認しておく必要があります。調査の対象は、100人以上の企業6,040社です⁸。

対象が100人以上の企業である以上、この数字をそのまま小規模な組織に当てはめることはできません。規模が変われば、部門の数も、揃えるべき仕組みの数も変わり、全社展開にかかる調整の量も変わります。

規模の大きな組織ほど、部門間で仕組みを揃える調整の量そのものが大きくなります。数字が示す60.0％という水準は、その調整をすでに経た企業の到達点であり、これから経る企業にとっては目安になります。逆に言えば、規模が大きい組織であるほど、まだ調整の途中にある案件に出会いやすいということでもあります。

案件情報を見るときも、この前提を意識しておくと読み方が変わります。対象となる企業の規模が分かれば、そこで求められる調整の量や、関わる工程の広さもおおよそ見当がつくようになります。

自分が関わろうとする企業がどの規模で、どの段階にあるのかを見極めることが、案件を選ぶときの手がかりになります。数字の前提を確かめる習慣は、この記事に限った話ではありません。どんな調査データを目にしたときも、対象の範囲を確認してから読み解くと、案件選びの判断がぶれにくくなります。

7. エンジニアが関われる範囲と、案件の探し方

関われる技術層

全社展開に関わる仕事は、一つの技術層だけでは完結しません。インフラやネットワークの層、権限やセキュリティの設計の層、監視や運用を仕組み化する層、そして既存システムからの移行を支える層に分かれます。

自分の経験がどの層に強いかを言葉にできると、案件を選ぶときの軸がはっきりします。複数の層をまたいで見てきた経験があるなら、それ自体が強みになります。一つの層に絞り込むより、橋渡しできる経験のほうが重宝される場面も増えています。

技術層	主な仕事内容	リモート適性
インフラ・ネットワーク層	権限設計を含む基盤の構成、部門をまたいだ設定の統一	高い
セキュリティ・権限設計	アクセス権限の設計、記録の残し方の整備	高い
監視・運用の仕組み化	障害の切り分け手順の整備、監視の仕組みづくり	高い
移行・接続支援	既存システムとの接続、移行時の確認	中〜高い

技術層をまたいで経験してきた人ほど、全社展開のような複数の部署が関わるプロジェクトでは重宝されます。得意な層を軸にしながら、隣接する層の知識も少しずつ広げておくと、選べる案件の幅も広がります。一つの案件で複数の層に触れておくこと自体が、次の案件を選ぶときの材料になります。

こうした仕事は、常駐して顔を合わせ続けることを前提にしていない場合が中心です。Remoguが扱う案件は、90%以上がフルリモート可能です⁹。場所を移さずに、全社展開という仕事の中身に関われる余地は十分にあります。

リモートで進める場合でも、権限の設計や障害対応の手順は文書として残すことが前提になります。顔を合わせる時間が減る分、判断の根拠を言葉にして共有する力が、これまで以上に問われます。

全社展開のプロジェクトに、経験がまだ少なくても関われますか

全社展開の仕事は、権限設計や運用ルールの調整など複数の役割に分かれています。特定の層で積み上げてきた経験があれば、そこから関わり始めることができます。まず自分の経験に近い層を、案件情報と照らし合わせて確認することをおすすめします。経験の幅よりも、一つの層で積み上げてきた深さのほうが評価される場面もあります。

常駐が前提の案件が中心なのでしょうか

常駐が前提かどうかは案件によって異なりますが、リモートで進めやすい案件が中心です。条件は掲載時点の案件情報で確認できます。全社展開に関わる仕事であっても、場所を理由に対象から外れる案件は限られています。

参画するには、まず何を確認すればよいですか

自分がこれまで担当してきた技術層と、その中で工夫してきた点を言葉にしておくことです。次に、登録して自分の経験に合う案件の条件を確認することが、具体的な一歩になります。数字や設計の話を積み重ねてきましたが、最後に動くのは案件情報と、自分の経験を照らし合わせる一手間です。

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

出典・参考情報

＊1 総務省「令和7年通信利用動向調査の結果」情報流通行政局（令和8年5月29日公表）（2026年5月）
＊2 総務省「令和7年通信利用動向調査の結果」情報流通行政局（令和8年5月29日公表）（2026年5月）
＊3 総務省「令和7年通信利用動向調査の結果」情報流通行政局（令和8年5月29日公表）（2026年5月）
＊4 総務省「令和7年通信利用動向調査の結果」情報流通行政局（令和8年5月29日公表）（2026年5月）
＊5 総務省「令和7年通信利用動向調査の結果」情報流通行政局（令和8年5月29日公表）（2026年5月）
＊6 総務省「令和7年通信利用動向調査の結果」情報流通行政局（令和8年5月29日公表）（2026年5月）
＊7 総務省「令和7年通信利用動向調査の結果」情報流通行政局（令和8年5月29日公表）（2026年5月）
＊8 総務省「令和7年通信利用動向調査の結果」情報流通行政局（令和8年5月29日公表）（2026年5月）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）