開発計画・技術選定学習記事全11節Design
表計算・ノーコード・ローカルツール・Webアプリを同じ軸で比べる
この記事で身につくこと表計算の改善・ノーコード・ローカルツール・Webアプリという作り方の違いを説明し、機能一覧と制約から候補を絞る理由を書ける。
記事内目次（24項目）
この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。依頼・承認管理を「表計算の改善」「ノーコードツール」「ローカルツール」「Webアプリ」のどれで作るかを、同じ軸で比較する話です。
なぜ必要か。作り方を決めずに「とりあえずWebアプリで」と進めると、もっと簡単な方法で十分だった場合に手間をかけすぎたり、逆に簡単な方法では実現できない要件（役割ごとの閲覧制限など）を見落としたりします。
この記事を読むとできるようになること。
- 4つの作り方の違いを、構成の分け方と使われ方の観点で説明できる
- 機能一覧・制約をもとに、各方式の向く条件・向かない条件を書ける
- 複数の役割と状態管理が必要という条件から、候補を絞る理由を書ける
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「4つの作り方の違い」と「比較表の形」が分かり、ひな形を埋め始められます。
- 作って確かめる：上に加えて第6節（失敗例と直し方）→第7節。
- 設計判断を深める：上に加えて第8節（トレードオフ、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、02-02の機能一覧と03-01の制約一覧をもとに、依頼・承認管理を実現する4つの作り方（表計算の改善、ノーコードツール、ローカルツール、Webアプリ）を同じ軸で比較し、候補を絞ることです。
「何を作るか」（機能）と「何が制約か」が決まっても、「どう作るか」（方式）はまだ決まっていません。この記事では、作り方そのものを比較し、この業務に向く方式・向かない方式を整理します。
この記事を読み終えると、次のものが手元にできます。
- 4方式の比較表（向く条件、向かない条件、制約との適合、運用負担）
- 候補に残す方式と外す方式、それぞれの理由
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
方式（作り方の種類）
一言でいうと、システムをどのような形で実現するかの大まかな分類です。
たとえば、「表計算ソフトの一覧に手作業で状態を書き込む」のと、「専用の画面から操作するWebアプリ」は、同じ依頼・承認管理でも方式が違います。
これがないと、「とりあえず慣れているやり方」で作り始めてしまい、後から「この方式では権限の管理ができない」と気づいて作り直すことになります。
表計算の改善
一言でいうと、Excelのような表計算ソフトの使い方を工夫して業務を回す方式です。たとえば、依頼の一覧をシートにまとめ、状態の列を手作業で更新します。
ノーコードツール
一言でいうと、プログラムを書かずに、画面と処理の部品を組み合わせてアプリを作る方式です。
ローカルツール
一言でいうと、1台のパソコンの中だけで動く、ネットワークを介さないプログラムです。
Webアプリ
一言でいうと、複数の利用者がネットワーク越しに同じ画面・データにアクセスするアプリです。
読む順路：比較のもとになる機能一覧・制約一覧は02-02・03-01が該当します。候補方式を踏まえた技術選定は03-03が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。
3. 理解する：方式によって何が変わるか
3.1 構成の分け方と使われ方の違い
4つの方式は、「誰が」「どこから」「どう操作するか」が異なります。
| 方式 | 構成の分け方 | 使われ方 |
|---|---|---|
| 表計算の改善 | 1つのファイルに一覧・状態をまとめる | 各自がファイルを開いて手作業で更新する |
| ノーコードツール | 画面・データ・処理をツール内の部品で組み立てる | ツールが用意した画面からアクセスする |
| ローカルツール | 1台のパソコンの中でプログラムとデータが完結する | そのパソコンを使う人だけが操作できる |
| Webアプリ | 画面・処理・保存先が分かれ、ネットワーク経由でつながる | 複数の利用者が別々の端末からアクセスする |
02-02で決めた機能（依頼の作成・提出・承認・差戻し・一覧閲覧）は、依頼者・承認者という異なる役割の人が、別々のタイミングで操作します。この「複数の役割が別々に操作する」という条件が、方式を選ぶ際の重要な軸になります。
3.2 よくある誤解
「Webアプリが一番高機能だから常に正解」。機能が多いほど、開発と運用の負担も増えます。この業務の規模（社内の小規模な利用）に見合った方式を選びます。
「表計算は業務システムに使えない」。少人数で、権限の分離が厳密でなくてもよい業務なら、表計算の改善で十分なこともあります。この記事では、02-02の機能一覧（役割ごとの権限、REQ-002・REQ-003）と照らして向き不向きを判断します。
「ノーコードツールなら何でも作れる」。ノーコードツールは種類によって、複雑な権限ロジック（自己承認の禁止など）を組みにくいことがあります。実際に使えるかは、候補にしたうえで03-03で確認します。
「AIに方式を決めさせれば早い」。AIは方式の一般的な特徴を説明できますが、この業務の制約・機能に照らしてどれが向くかは、人が判断します（第4.3節）。
4. 判断すること
4.1 何を確認すればよいか
| 確認すること | この記事での扱い |
|---|---|
| 複数の役割（依頼者・承認者・運用管理者）が別々に操作する必要があるか | 02-02の機能一覧より必要（自分の依頼だけ、割当の依頼だけを見る、という役割ごとの範囲がある） |
| 状態（下書き・提出済み・差戻し・承認済み）を一元的に管理する必要があるか | 02-02の機能一覧より必要（誰が見ても同じ状態が分かる必要がある） |
| 03-01の制約（会社支給PC、社内ネットワーク、社内契約のAI。いずれも03-01が置いた教材上の仮定）にどの方式が合うか | 各方式ごとに第5.2節で確認する |
4.2 勝手に決めてはいけないこと
- 02-02で決めた機能（何をするか）を、方式を選ぶために変更しません。
- 方式の比較は、02-02・03-01の内容に基づいて行い、この記事で新しい機能や制約を作りません。
- 「候補に残す」「外す」の判断理由は、比較表の内容に基づいて書き、思い込みで決めません。
4.3 AIに任せる範囲
各方式の一般的な特徴（構成、使われ方、向く場面）の提示はAIに任せられます。しかし、この業務の機能・制約に照らしてどの方式が向くかの判断は人が行います。
5. 作って確かめる：方式比較表を作る
5.1 準備
02-02の機能一覧、03-01の制約一覧の記入例を用意します。03-01の端末・ネットワーク・利用可能なAIは教材上の仮定であるため、この比較は「その仮定を前提にした場合の比較例」として扱います。
5.2 方式比較表（03-01の教材上の仮定を前提にした比較例）
| 方式 | 向く条件 | 向かない条件 | 制約との適合 | 運用負担 | 候補判定 |
|---|---|---|---|---|---|
| 表計算の改善 | 少人数で、権限の分離が厳密でなくてもよい業務 | 役割ごとの閲覧制限、状態遷移の自動的な確認が必要な業務 | 会社支給PC（教材上の仮定）で開けるため制約には合う | 低い（ただし権限管理は手作業） | 外す（依頼者・承認者の権限分離をREQ-002・REQ-003として厳密に守れない） |
| ノーコードツール | 早く作りたい、複数人が同時に使う業務 | 自己承認禁止のような細かい権限ロジックが組みにくい場合がある | 利用可能なAI（教材上の仮定）・データ持出し（未確認）の制約との適合は未確認 | 中（ツールの契約・保守が必要） | 保留（03-01の未確認の制約が確認でき、権限ロジックが組めると分かれば候補に残す） |
| ローカルツール | 1人がパソコン内だけで完結させたい業務、社外にデータを一切出したくない業務 | 複数の利用者が別々の端末から同時に使う業務 | ネットワーク制約（社内限定、教材上の仮定）には合うが、複数人利用には向かない | 低い（ただし複数人利用に向かない） | 外す（依頼者と承認者が別々の端末から操作する必要があるため） |
| Webアプリ | 複数の役割が別々の端末から、共通の状態を見ながら操作する業務 | 開発・保守の負担を最小にしたい場合 | 会社支給PC・社内ネットワーク（いずれも教材上の仮定）からのアクセスに合う | 中〜高（開発・保守が必要） | 候補に残す（複数の役割と状態の一元管理という条件に最も合う） |
この比較結果は、03-01の教材上の仮定（会社支給PCのみ、社内ネットワークのみ、社内契約AIのみ）を前提にした一例です。仮定の内容が変われば、比較結果も変わります。
5.3 AIに比較表の下書きを頼む
各方式の一般的な特徴をAIに提示させ、比較表の下書きを作らせます。
依頼・承認管理アプリを、表計算の改善・ノーコードツール・ローカルツール・Webアプリのどれで作るか比較したいです。02-02の機能一覧（役割ごとに操作が分かれる）と03-01の制約一覧を渡します。
依頼：
1. 各方式の一般的な向く条件・向かない条件を挙げてください。
2. 制約一覧と照らして、適合しそうか・未確認かを示してください。
してはいけないこと：
- 特定の製品名を挙げないでください。方式の種類として説明してください。
- この業務にとって「どれが正解か」を断定しないでください。判断は人が行います。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。
- 「〇〇（特定の製品名）が最適です」と、製品名を挙げて断定的に記載
- ローカルツールについて「向かない条件」を書かず、良い点だけを記載
6.2 見つけ方と直し方
- 製品名の記載：設計書8.4「技術選定を先走らない」に反します。方式の種類としての説明に修正します。
- 向かない条件が無い：完了条件「各方式に向かない条件がある」を満たしません。ローカルツールの向かない条件（複数人利用に向かない）を追加します。
指摘：
1. 特定の製品名を挙げないでください。方式の種類として説明してください。
2. ローカルツールに向かない条件が抜けています。追加してください。
変えないこと：
- 02-02・03-01の内容そのものは変更しないでください。6.3 修正後の比較表
修正後の比較表は、第5.2節のとおりです。
7. 確認結果
第5.2節の比較表を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 4方式以上が同じ軸で比較されている | 4方式（表計算の改善、ノーコード、ローカルツール、Webアプリ）を同じ5列で比較 |
| 各方式に「向かない条件」がある | 4方式すべてに向かない条件あり |
| 候補に残す理由と外す理由が書かれている | Webアプリは候補に残す理由、表計算・ローカルツールは外す理由、ノーコードは保留の理由を明記 |
残る制限：この比較は架空の制約・機能に基づく一例です。会社支給PC・社内ネットワーク限定・社内契約AIという制約は03-01が置いた教材上の仮定であり、正本に根拠のある確認済みの事実ではありません。仮定が変われば比較結果も変わります。ノーコードツールの適合は、03-01の未確認の制約（データ持出し、予算）が確認できるまで判断を保留しています。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 トレードオフ
| 方式 | 得られる利点 | 生じる負担 |
|---|---|---|
| Webアプリ | 複数の役割が別々の端末から共通の状態を見られる | 開発・保守の負担が他方式より大きい |
| 表計算の改善 | 低い負担ですぐに始められる | 役割ごとの権限分離を厳密に守れない |
複数の役割と状態管理が必要という条件（02-02・記事Aの要件）を優先すると、開発・保守の負担が増えてもWebアプリを候補に残す、という判断になります。この判断は架空の設定であり、実際の業務では負担をどこまで許容できるかを踏まえて見直す必要があります。
8.2 適用限界
この記事の比較は、架空企業「みらい業務サービス」の小規模な社内利用を前提にしています。利用者数がさらに少ない、あるいは役割の区別が不要な業務であれば、表計算の改善やノーコードツールがより適することもあります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 方式比較表ひな形（方式、向く条件、向かない条件、制約との適合、運用負担、候補判定） | templates/03-02-approach-comparison_template.md | templates/03-02-approach-comparison_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（02-02、03-01）の機能一覧・制約一覧を用意する
- 検討する方式を4つ以上挙げる
- 各方式の向く条件・向かない条件を、機能一覧と照らして書く
- 制約一覧と照らして適合状況を書く
- 候補に残す方式・外す方式と、それぞれの理由を書く
10. 次工程への受渡し
次へ渡すもの：方式比較表、候補に残した方式（Webアプリ）とその理由。
次工程での使われ方：03-03（技術とサービスを選ぶ）では、候補方式（Webアプリ）を前提に、具体的な言語・保存先・配置先を選びます。
前工程へ戻る条件：候補方式が02-02の機能一覧を実現できないと分かったら、02-02に戻って機能一覧を見直します。
11. 根拠と更新情報
- この記事の会社・人物・比較結果はすべて架空の設定です。
- 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- 特定の製品名を挙げないという方針は、教材設計書
AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第8.4節「技術選定を先走らない」に基づきます。 - 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 未確認事項：ノーコードツールについて、03-01の未確認の制約（データ持出し、予算）が確認できていないため、判断を保留しています。
- 更新履歴：2026-09-20、ユーザーレビューにより、比較に用いた03-01の制約（会社支給PC、社内ネットワーク限定、社内契約AI）が教材上の仮定であることを明記しました（正本に根拠がないため）。