Webサービス・スマホアプリ開発前に社内で確認すべきこと

Webサービスやスマホアプリの開発を外部に相談したいとき、最初に整理すべきなのは「どんなものを作るか」よりも「何を解決したいか」「誰が使うか」「本当に新規開発が必要か」です。ここが曖昧なまま相談を始めると、見積もりの前提がそろわず、社内説明もしづらくなります。

この記事では、開発会社に相談する前に社内で確認したい内容を、実務で進めやすい順番で整理します。読後には、新規開発で進める妥当性、Web/PWAとスマホアプリの優先判断、初回相談に必要な最小準備物、予算・工程・関係者・運用/セキュリティの確認範囲を、自社案件に当てはめて判断できる状態を目指せます。必要なのは完成した仕様書ではなく、初回相談が前に進む最低限の材料です。

課題整理から運用・セキュリティ確認まで、社内確認の流れを1枚で整理した図です。最初に全体像をつかむと、どこまで固めれば初回相談に進めるか判断しやすくなります。

01Section最初に確認するのは「作る理由」があるか

開発の相談を前に進めるには、「アプリを作りたい」「Web化したい」ではなく、先に課題と目的をそろえる必要があります。デジタル庁の標準ガイドラインやIPAの要求策定ガイドでも、詳細な要件より前に、企画や要求の整理を行う考え方が示されています。

以下では、この7ステップに沿って、相談前に確認したいポイントを順番に見ていきます。

課題→対象ユーザー→期待効果の順で整理する

最初にそろえたいのは、次の3点です。

• 何が問題か
• 誰が困っているか
• 何が改善されれば成功か

たとえば「現場報告をアプリ化したい」ではなく、「現場報告が紙とメールに分散し、入力遅れと転記ミスが出ている。外出先からスマホで入力できるようにしたい」と置くほうが、相談先にも社内にも伝わります。

期待効果は厳密なKPIでなくても構いません。利用率、作業時間削減、入力ミス削減、問い合わせ件数の減少など、比較しやすい指標を2〜3個置けば十分です。

既存SaaS・業務変更・新規開発を並べて比較する

新規開発に進む前に、既存SaaS導入や業務変更も並べて比較するための整理図です。判断軸を先にそろえると、社内説明や外部相談の前提がぶれにくくなります。

新規開発の妥当性は、少なくとも次の3択で比較しておくと判断しやすくなります。

1. 1既存SaaSやパッケージ導入で足りるか
2. 2業務変更や手運用改善で解消できるか
3. 3それでも新規開発が必要か

新規開発を優先しやすいのは、独自業務が競争優位に直結する場合、既存製品では必須要件を満たしにくい場合、将来の連携や拡張を自社要件に合わせて設計したい場合です。逆に、既存SaaSや運用変更で短期に解決できるなら、まずはそちらを比較してからでも遅くありません。

この段階で決めることと後で詰めることを分ける

この段階で決めたいのは、完成した仕様ではありません。まず必要なのは、次を1枚で説明できる状態です。

• 背景となる課題
• 対象ユーザーと利用シーン
• 比較した代替案
• 成功指標の仮置き
• 今回やらないこと

一方で、画面遷移の細かさやデータ項目の詳細、実装方式までは後で相談しながら詰めれば大丈夫です。 最初から全部を固めようとすると、相談開始が遅れます。

02SectionWeb/PWAとスマホアプリ、どちらを優先検討するか

方式判断でよくある誤解は、スマホで使うならアプリ一択だと考えてしまうことです。スマホで使うからアプリ、ではありません。 管理画面中心の業務や価値検証の初期段階では、Web/PWAで十分なこともあります。

PWAに関するweb.devの解説では、インストール、オフライン対応、一部の端末機能活用などが可能とされています。ただし、インストールやオフラインデータの扱い、通知の可否はOSやブラウザで差があります。AppleもWeb Pushの技術情報を公開していますが、必須要件がある場合は対象端末を先に固定して確認するのが安全です。

方式判断で見る軸

スマホで使うからアプリ、とは限りません。通知・オフライン・配布方法・更新運用など、記事内の判断軸を横並びで見比べるための図です。

迷う場合は、まずWeb/PWAで価値検証し、必要性が固まってからアプリへ広げる進め方も現実的です。

Web/PWAを先に検討しやすいケース

Web/PWAを先に検討しやすいのは、管理画面や社内業務が中心である場合、URLで素早く展開したい場合、初期段階では端末機能やオフライン利用が限定的である場合です。更新を細かく回したい案件にも向いています。

スマホアプリを先に検討しやすいケース

ネイティブアプリを優先しやすいのは、通知やモバイル体験そのものが価値になる場合、ストア配布が前提の場合、端末機能やオフライン動作の重要度が高い場合です。なお、アプリ公開では審査・申告・公開運用も前提に考える必要があります。 AppleのApp Review GuidelinesやGoogle Playの審査準備ガイドに沿った対応も見ておきましょう。

03Section相談前にそろえる要件は「最低限の相談材料」でよい

相談前に必要なのは、要件定義書の完成ではありません。相談先が見積もりや提案を始められるだけの材料があるかどうかが基準です。ここで重要なのは、機能を増やすことではなく、初期範囲を絞ることです。

相談可能な最低ラインを決める

要件定義書の完成がなくても、初回相談に必要な材料は整理できます。最低限そろえたい項目と、あると比較しやすくなる追加情報を分けて示す図です。

初回相談前に、最低限そろえたいのは次の情報です。

• 目的
• 対象ユーザーと利用シーン
• 必須機能候補
• 既存システム連携の有無
• 希望時期
• 予算条件
• 未確定事項

この段階で、想定利用者数、利用頻度、ピーク時利用規模、認証前提まで分かると比較精度は上がります。ただし未確定なら、空欄にするのではなく「未確定」と書いておくほうが、相談先から必要な確認が返ってきやすくなります。

必須・希望・後回しを4軸で分ける

機能の優先順位は、各候補を次の4軸で見ると整理しやすくなります。

• 目的達成への直結度
• 法務・運用上の必須性
• 代替運用の可否
• 後回し時の影響

テンプレートとしては、下の形を使えます。

要件優先順位付けテンプレート

• 機能名：
• 目的達成への直結度：高 / 中 / 低
• 法務・運用上の必須性：高 / 中 / 低
• 代替運用の可否：高 / 中 / 低
• 後回し時の影響：高 / 中 / 低
• 判定：必須 / 希望 / 後回し
• 後回し・対象外の理由：

「目的達成への直結度」または「法務・運用上の必須性」が高いものは、初期範囲の候補になりやすくなります。反対に、代替運用ができ、後回し時の影響が小さい機能は、初期リリースから外しやすい項目です。

初期リリース範囲と対象外を明示する

初期リリースは、必須機能3〜5件を目安に絞るのが実務では扱いやすい幅です。必須が多すぎる場合は、対象ユーザーを絞る、手作業で補う、段階導入に分ける、の3つで切り分けると現実的です。

同時に、「今回はやらないこと」も必ず残してください。 対象外があると、見積もり範囲のぶれが減り、複数社比較もしやすくなります。

04Section予算とスケジュールは「相場」ではなく「前提条件」で見る

金額や期間は、機能数だけでなく、連携の有無、扱う情報、公開方法、保守範囲で大きく変わります。だからこそ、相場を探すより先に、何が費用と工程を動かすのかを社内で分けておくことが重要です。

デジタル庁の標準ガイドライン解説書でも、企画から要件整理に進む前段工程が示されています。開発工程だけでは、社内の実行可能性は判断しにくいからです。

費用を5つの層に分ける

特に見落としやすいのが、保守運用と社内対応コストです。 外部見積もりだけを見ていると、公開後に社内の負担が増えてから気づくことがあります。

予算条件ごとに先に決めることを変える

予算が未確定でも相談は始められます。ただし、何を優先するのかだけは決めておかないと、提案の比較軸がばらけやすくなります。

工程は社内整理から公開準備まで見る

全体工程は、社内整理、相談先選定、要件たたき台、見積もり・提案、比較・稟議、契約、設計・開発、受入テスト、公開準備、運用開始の順で見ると整理しやすくなります。

短納期でも削りにくいのは、要件たたき台、受入テスト、公開準備です。 個人情報やアプリ審査が絡む案件では、この確認を後ろ倒しにすると差し戻しが増えます。アプリ案件では、Google Playのアプリ作成・設定ガイドのように、公開前の設定や申告が必要になるため、Webよりも公開準備の論点が増えやすくなります。

05Section誰に何を確認するかを先に決める

開発相談が止まりやすい理由のひとつは、誰が決める人で、誰が確認する人かが曖昧なことです。最初から全員を巻き込む必要はありませんが、初期に必須の人と、条件次第で早めに確認すべき人は分けておくと進めやすくなります。

初期に必須で巻き込む関係者

条件次第で早めに確認したい関係者

決める・確認する・実行するを分ける

肩書きよりも大事なのは、タスクごとに役割を分けることです。

• 決める：目的、初期範囲、予算条件、相談開始可否を決める
• 確認する：連携可否、セキュリティ条件、契約上の論点を確認する
• 実行する：資料作成、比較、問い合わせ、運用準備を進める

背景、目的、対象ユーザー、方式仮説、初期範囲、予算条件、スケジュール条件、主なリスク、未確定事項、承認してほしいことを1枚にまとめれば、初期相談の承認材料としては十分です。

06Section運用・セキュリティは最低限だけ先に決める

運用やセキュリティは、詳細設計まで社内で決め切る必要はありません。ただし、何を扱い、誰が責任を持ち、最低限どこまで管理するかは、相談前に大枠を置いておくほうが進めやすくなります。

開発前に決める運用項目

開発前に押さえたいのは、次のような項目です。

• 扱う情報の種類
• 運用責任者
• アカウント方針
• 権限の大枠
• 障害や問い合わせの一次対応窓口

ここで決めたいのは「どこまで社内で責任を持つか」の線引きです。 監視閾値や暗号方式のような細かい実装は、相談先と設計段階で詰めれば構いません。

個人情報・権限・ログの基本方針

個人情報を扱う場合は、個人情報保護委員会のガイドライン（通則編）で示される安全管理措置の考え方を踏まえ、誰がアクセスできるか、どの情報を守るか、事故時にどう動くかを確認しておきたいところです。

また、IPAの情報セキュリティ対策ガイドラインや5分でできる情報セキュリティ自社診断でも、バックアップや運用ルール、事故対応の基本が整理されています。権限については、必要最小限のアクセスに絞るleast privilegeの考え方が参考になります。

開発前に最低限確認しておきたいのは、次の4点です。

• 権限区分は何段階必要か
• ログを残す必要があるか
• バックアップと復旧の考え方はあるか
• 障害時の一次窓口はどこか

アプリ公開で増える確認事項

アプリ案件では、これに加えてストア申告、プライバシー情報、権限利用の説明、審査時の確認情報も論点になります。Appleの審査ガイドラインやGoogle Playの審査準備ガイドを見ても、公開時にはアプリ内容やアクセス方法、申告情報の整備が求められます。

そのため、アプリを検討するなら、公開直前ではなく、相談段階から「どの権限を使う可能性があるか」「ログイン方法はどうするか」までは仮置きしておくほうが安全です。

07Sectionこの状態なら外部相談に進める

ここまで整理できていれば、発注準備が完了していなくても、比較可能な初回相談には進めます。大切なのは、未確定事項をなくすことではなく、未確定のまま見える化することです。

初回相談の最小準備物

複数社比較で条件をそろえるコツ

複数社に相談する場合は、同じ前提条件を渡すことが最優先です。 提案の差を見たいのに、前提条件まで会社ごとに変わってしまうと、価格も工程も比較しにくくなります。

未確定事項がある場合は、「未確定なので提案時に前提を置いてください」と伝えるほうが、差分の理由を読み取りやすくなります。比較の精度は、情報を完璧にそろえることより、前提差を見える化することで上がります。

読後すぐにやる3つのアクション

1. 1課題、対象ユーザー、成功指標、代替案を1枚にまとめる
2. 2Web/PWA先行か、アプリ先行か、両方検討かを仮決めする
3. 3最低ラインの情報を同じ条件でそろえて、初回相談を始める