モバイル案件に参画したあと、対応端末がじわじわ増えていく場面があります。最初はiOSとAndroidの主要な端末だけだった話が、途中からタブレットや古い端末の確認まで加わっていくケースです。範囲が動く理由は、稼働の前提が最初の要件に書かれていないところにあります。この記事では、対応端末とOSの前提をどう要件として書き、参画前に何を確かめておくと範囲を保てるかを整理します。

1. 対応端末が後から増えるのは、書いていないから

稼働環境の要件に、利用者側の環境も含まれている

モバイル案件に参画してしばらく経つと、「この端末でも動作を確認してほしい」という声が途中から入ってくることがあります。最初に聞いていた範囲より対応先が増え、どこまでが元々の依頼なのか見えにくくなる瞬間です。稼働の前提を誰も文字にしていなかったことが、範囲が後から動く理由になっています。

デジタル庁の標準ガイドラインは、情報システムの稼働環境に関する要件として、クラウドサービスの利用環境やサーバー環境だけでなく、クライアント環境（OS、ブラウザ等）の要件も記載することを求めています¹。稼働の前提は、クラウドや基盤の設計だけでなく、利用者が使う端末側の条件まで含めて書く範囲だと分かります。

つまり対応端末やOSの範囲は、参画してから決まっていく話ではなく、最初の要件定義に書いておく項目です。打診を受けた段階で、クライアント環境の記載が要件定義書のどこにあるかを確かめておくと、後から範囲が動いたときの拠り所になります。

利用者側の環境は「選べないもの」ではなく「書くもの」

端末やOSは利用者が持っているものなので、こちら側では選べないと感じる場面が多くあります。この感覚のまま案件を進めると、対応範囲は相手の言い分に合わせて広がっていく形になりがちです。

選べないことと、書かれていないことは別の話です。利用者側の環境そのものは選べなくても、「どの範囲まで確認するか」は要件として書ける対象です。範囲を相手任せにするより、最初の打ち合わせで確認する対象を書き出しておくほうが、後から話が食い違いにくくなります。

打診を受けた面談で「対応端末はどこまでか」と聞かれて即答できないと、後から相手側の想定に合わせて範囲が決まっていく展開になりやすくなります。要件定義書のクライアント環境の欄を先に確認しておくと、面談の場で自分から範囲を示せます。

参画前に確かめておきたいのは、対応端末やOSの範囲が要件定義書のどの項目に、どこまで書かれているかという点です。書かれている範囲がそのまま引き受ける範囲になり、書かれていない部分は打ち合わせで詰める対象になります。

図の作成：Remogu編集部。標準ガイドラインが示す要件の構成を整理したもので、統計データではありません

2. 広げすぎないことも要件整理

合理的な構成にする、という視点

対応端末を確かめる話をすると、「念のため全部の組み合わせを見ておきたい」という声が返ってくることがあります。範囲を広く取っておけば安心という気持ちは分かりますが、確認する組み合わせが増えるほど、稼働にかかる時間と手間も比例して増えていきます。

デジタル庁の標準ガイドラインは、稼働環境についてプロジェクトの特性を踏まえて合理的な構成となるよう要件整理を行い、不要な調達を行わないことを求めています²。対応範囲を広げることではなく、案件の特性に見合った構成に絞ることが、要件整理として位置づけられています。

つまり「広く構えておく」ことと「要件として整理されている」ことは、別の話です。対象をどこまで確認するかを決める作業自体が、稼働環境の要件整理の一部になっています。

全部に対応する、が正解ではない

対応端末を増やすほど丁寧に見えると感じる場面もありますが、確認する範囲が広がるほど、テストにかかる時間や、後から出てくる不具合への対応も広がっていきます。狭めることに気が引ける気持ちより、範囲を決めて書いておくことのほうが、稼働全体を軽くします。

対応する端末やOSを絞り込む判断は、要件整理の一部として行うものであり、都度その場で決める話ではありません。企画の早い段階で、確認する組み合わせの一覧を書き出し、対象に入れる理由と入れない理由を並べておくと、後から範囲を聞かれたときにも説明しやすくなります。

参画前に確かめておきたいのは、対応範囲が「案件の特性を踏まえて決められたものか」という点です。決め方の根拠があいまいな案件ほど、稼働後に対象が動きやすくなります。

対応範囲を確かめるときに見ておきたい観点を整理すると、次のようになります。対象とするOSや画面の大きさ、ブラウザやアプリの実行環境、想定する利用者数や利用場面、将来の追加余地まで、どこに書かれているかを一つずつ確認しておくと、話し合いの土台がそろいます。

観点	確認する内容	書いておく場所
対象とするOS	稼働を確認する範囲をどこまでとするか	要件定義書のクライアント環境の欄
対象とする画面の大きさ	タブレットなど大きな画面まで含めるか	同上
ブラウザやアプリの実行環境	アプリの配信形態や実行方式を含めるか	同上
想定する利用者数や利用場面	多数の利用者が使う前提かどうか	要件定義書の利用者像の欄
将来の追加余地	稼働後に対象を広げる可能性をどう扱うか	変更管理に関する取り決めの欄

3. 特定の端末に依存しない、という向き

ハードウェアやソフトウェアに依存しない、という要件

特定の端末やOSに合わせて作り込むほど、動作が安定して見える場面があります。ただしその作り込みが特定の環境に強く結びついていると、対象の端末が増えたときや、土台側の環境が変わったときに、同じ調整をやり直す負担が生まれます。

デジタル庁の標準ガイドラインは、中立性に関する事項として、情報システムを利用する端末についても、特定のハードウェア又はソフトウェアに依存しないよう留意することを挙げています³。特定の環境に寄せた作り込みを避ける向きが、要件の段階で明文にされている形です。

この向きは、特定のOSや機種を評価する話ではありません。どの端末やOSであっても、依存を減らした構成にしておくと、対応範囲が動いたときの影響を小さくできるという整理です。

端末側と土台側の両方が動く前提で考える

端末側の依存を避ける話をしていると、土台側（クラウドやサーバー）の前提は変わらないものとして進めてしまう場面があります。ただし土台側の前提が動くと、結局は端末側の対応にもしわ寄せが及びます。

標準ガイドラインの改定では、システム方式に関する事項として、クラウドサービスについて極力クラウドネイティブな構成となるよう留意する記載が追記されています⁸。端末側の依存を減らす話と、土台側の構成を見直す話は、同じ改定の中で並んで扱われています。

依存を減らした構成で参画する案件と、特定の環境に強く結びついた構成で参画する案件とでは、日々の稼働の中で確認する対象の増え方が変わります。前者は土台側の変化を一つの窓口で追えますが、後者は変化のたびに複数の実装を洗い直す作業が発生します。

参画前に確かめておきたいのは、依存を避ける対象が端末だけに限られていないか、という点です。土台側の前提が今後どう変わる想定かを合わせて聞いておくと、端末側の対応がどこまで安定するかも見えやすくなります。

図の作成：Remogu編集部。標準ガイドラインが示す中立性の考え方を整理したもので、統計データではありません

4. 試す環境も、要件として書く

テストの範囲は「気合」ではなく要件の話

実機を必要な分だけそろえられず、確認漏れが不安に残ったまま進める場面があります。手元にある端末で確認し、不足している分を気持ちで補おうとすると、どこまで確認できたかが個人の感覚に委ねられてしまいます。

デジタル庁の標準ガイドラインは、テストに関する事項として、設計から運用開始に至るまでの全てのテストについて、種類、目的、内容、実施者、合否判断基準、テスト実施環境等を記載することを求めています⁴。テストに使う環境そのものが、要件として書く対象に含まれています。

つまり実機をどこまでそろえるかは、現場の判断力に頼る話ではなく、要件定義の段階で決めておく項目です。参画前には、テスト実施環境の欄に対象端末がどこまで書かれているかを確かめておくと、確認の範囲があいまいなまま進むことを防げます。

止まったときの前提も、要件に含まれている

稼働中に障害が起きたとき、どこまで自分の対応範囲なのか分からず、不安だけが先に立つ場面もあります。何をどこまで直す想定なのかが共有されていないと、起きた出来事への向き合い方も定まりません。

標準ガイドラインは、継続性に関する事項として、障害や災害等による問題発生時に求められる機能、システム構成、目標復旧時点及び目標復旧時間等を記載することを求めています⁵。止まったときにどこまで復旧させるかという前提も、あらかじめ要件に書いておく対象です。

復旧の前提を都度その場で判断するより、要件定義の段階で目標復旧時点や時間を確認しておくほうが、稼働中に起きた出来事への向き合い方がはっきりします。参画前にこの欄を読んでおくと、実機の確認範囲と合わせて、対応の輪郭が見えてきます。

テストと継続性の要件に書く項目を一覧にすると、次のようになります。テストの種類や目的、実施者、合否判断基準、テスト実施環境に加えて、目標復旧時点や目標復旧時間まで、どこまで具体的に書かれているかを確かめておくと、稼働後の不安を事前に減らせます。

記載する項目	内容	確認しておく視点
テストの種類	単体・結合・利用者確認など、行うテストの区分	どの区分がどこまで実施予定か
テストの目的	何を確かめるためのテストか	対応端末の確認がどの目的に入っているか
テストの実施者	誰がテストを行うか	実機の確認を誰が担当する想定か
合否判断基準	合格と判断する基準	基準が端末ごとに定められているか
テスト実施環境	実機やエミュレーターなど、確認に使う環境	対象の端末がここに書かれているか
目標復旧時点・目標復旧時間	障害発生時にどこまで、どれだけの時間で復旧させるか	復旧の前提が案件の説明にあるか

図の作成：Remogu編集部。標準ガイドラインが示すテスト・継続性の記載項目を整理したもので、統計データではありません

5. 説明の届け方まで含めて成果物

使う人向けの手順書も、成果物に入っている

開発が一区切りついたところで、成果物は動くもので完成したと感じる場面があります。ただし実際に使うのは、開発に関わっていない利用者です。動くことと、使い方が伝わることは、別の課題として残ります。

デジタル庁の標準ガイドラインは、改定によって、利用者の視点を含めてシステム操作マニュアルを作成する記載を追記しています⁶。動作の確認だけでなく、使い方を説明する文書までが、成果物として位置づけられています。

つまり手順書やマニュアルの作成は、開発の後工程として軽く扱われる作業ではありません。参画前に、操作マニュアルの作成が対応範囲に含まれているかどうかを確かめておくと、成果物の全体像が見えやすくなります。

端末が違えば、届け方も変わる

マニュアルを一つ作れば足りると考えて進めると、実際に使う場面で「見つけにくい」「探しにくい」という声が返ってくることがあります。端末が変われば、画面の大きさも操作の流れも変わるためです。

標準ガイドラインの改定では、国民等の多数の利用者が参照するマニュアルについて、利用環境に応じて閲覧・検索しやすい形で提供するよう努める記載が追記されています⁷。端末の違いは操作の違いだけでなく、説明そのものの届け方にも及ぶという整理です。

参画前に確かめておきたいのは、マニュアルを一種類だけ用意すれば良い案件なのか、利用環境ごとに届け方を変える案件なのか、という点です。この違いが分かっていると、成果物として求められる作業量の見立てが変わります。

モバイル案件で積み重ねてきた経験は、層に分けて書き出すと伝わりやすくなります。実装、検証、運用、利用者向けの説明という4つの層のうち、どこに厚みがあるかを整理しておくと、参画前の話し合いでも自分の強みを説明しやすくなります。

層	内容	説明の届け方の工夫
実装層	端末ごとの挙動を作り込んできた経験	挙動の違いを整理して伝える
検証層	実機によるテストを重ねてきた経験	確認した範囲を具体的に示す
運用層	障害発生時の復旧対応に関わってきた経験	起きたことと対応を時系列で残す
利用者層	操作マニュアルや案内文を作成してきた経験	利用環境に応じて届け方を変える

図の作成：Remogu編集部。標準ガイドラインが示す成果物の考え方を整理したもので、統計データではありません

6. まとめ

対応端末が後から増えていく感覚は、要件が書かれていないことの表れです。デジタル庁の標準ガイドラインが示す稼働環境やテスト、マニュアルの要件は、端末やOSの前提を最初から言葉にしておくための手がかりになります。

参画前に要件定義書のクライアント環境の欄やテスト実施環境の欄を確かめておくことは、範囲を守るための準備です。書かれている範囲を引き受け、書かれていない部分は打ち合わせで詰めるという進め方に変えると、稼働中に範囲が動く場面は減っていきます。

Remoguが扱う案件は、90%以上がフルリモート可能です⁹。場所を選ばずに稼働できる環境で、こうした要件整理の経験を積み重ねたい向きには、まず登録して自分の経験に近い案件の条件を確かめてみることが、次の一歩になります。

7. よくある質問

対応OSの範囲は誰が決めるのか

対応するOSの範囲は、現場でその都度決める話ではなく、要件定義書のクライアント環境の欄に書く内容として位置づけられています¹。参画前にこの欄を確認し、書かれていない部分は打ち合わせで詰めておくと、後から範囲を聞かれる場面を減らせます。

実機がそろわない案件ではどうするか

実機の確保が難しい場合でも、まず確かめたいのはテスト実施環境の欄にどう書かれているかという点です⁴。書かれている範囲と手元の実機との差を早めに共有しておくと、確認方法を相談する材料になります。

古いOSの不具合まで引き受けることになるのか

対応する範囲は、プロジェクトの特性を踏まえた合理的な構成として整理する対象です²。古い環境を対象に含めるかどうかも、その整理の中で決める話であり、要件に書かれていない範囲まで自動的に引き受ける前提にはなりません。

政府向けのガイドラインは民間の案件でも参考になるのか

このガイドラインは政府の情報システムを対象にしたものですが、クライアント環境やテスト環境を要件として書くという整理の仕方そのものは、モバイル案件の要件を確認するときの視点として参考になります。案件ごとの要件定義書に同じ観点があるかを照らし合わせてみると、対応範囲を確かめる手がかりになります。

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

出典・参考情報

＊1 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（k 情報システム稼働環境に関する事項）（2026年6月12日）
＊2 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（k 情報システム稼働環境に関する事項）（2026年6月12日）
＊3 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（h 中立性に関する事項）（2026年6月12日）
＊4 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（m テストに関する事項）（2026年6月12日）
＊5 デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第5章 要件定義（i 継続性に関する事項）（2026年6月12日）
＊6 デジタル庁「デジタル・ガバメント推進標準ガイドライン」改定履歴（第3編第7章）（2026年6月12日）
＊7 デジタル庁「デジタル・ガバメント推進標準ガイドライン」改定履歴（第3編第7章）（2026年6月12日）
＊8 デジタル庁「デジタル・ガバメント推進標準ガイドライン」改定履歴（第3編第5章）（2026年6月12日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）