【DXの罠】入門教材で作れたシステムを、そのまま会社で使ってはいけない
「Webアプリの作り方を一通り勉強した」
「生成AIに聞きながらCRUDもログインも実装できた」
「実際にブラウザから動いている」
ここまで来ると、
「これなら自社の業務システムも作れるのではないか」
と思いたくなります。
しかし、ここに生成AI時代の大きな落とし穴があります。
入門教材で作るシステムと、企業が本番運用する業務システムは、そもそも設計目的が違います。
入門教材の目的は、
フレームワークの仕組みを理解すること
です。
企業の業務システムの目的は、
異なる立場・権限・所属を持つ多数の人間が、重要な企業データを安全に扱い続けること
です。
この二つを同じ設計で作ってはいけません。
1．実際の「入門教材」を7つ見てみよう
ここで、実際に公開されているフレームワーク学習教材を見てみます。
重要なのは、これらの教材を批判することではありません。
むしろ、どれも入門教材としては非常によくできています。
問題は、
「教材で完成したサンプルアプリの構造＝業務システムの正しい構造」
だと思い込むことです。
① MDN ― Express「地域図書館」チュートリアル
MozillaのMDNには、Node.js＋Expressを使って「地域図書館」のWebサイトを作る非常に分かりやすいチュートリアルがあります。
MDN：Express チュートリアル「地域図書館のウェブサイト」
内容は、
- Expressアプリケーションの作成
- データベース
- ルーティング
- ビュー
- フォーム
- デプロイ
などです。
MDN自身が、このシリーズを終えると**「簡単なExpressアプリケーションを自分で開発するのに十分な知識」**が身につくと説明しています。
さらに興味深いことに、Express学習モジュールのページでは、今後追加できるテーマとして、
- セッション
- ユーザー認証
- ユーザーの認可と権限
- Webセキュリティ
などが別途挙げられています。
つまり教材自身が、
「まず簡単なWebアプリを作る」
ところに学習範囲を絞っているわけです。
それは入門教材として正しい判断です。
しかし、その構造をそのまま社員数百人の業務システムへ持っていくのは別問題です。
② paiza ― Flask入門
Pythonの軽量WebフレームワークFlaskにも、非常に分かりやすい日本語入門教材があります。
最初のFlask入門では、
- Webアプリの初歩
- Hello World
- ルーティング
- テンプレート
- 共通部分の分割
- ユーザー操作による表示変更
などを順番に学びます。
これはまさに、
「Webフレームワークとは何なのか」
を体験するための教材です。
ここで重要なのは、
この教材で習った作り方が間違っているわけではない
ことです。
ただし、
「本社」
「支店」
「店舗」
「部長」
「一般社員」
「取引先」
「顧客」
という複雑な関係を持つ業務システムは、最初から別の設計問題として考える必要があります。
③ FastAPI ― 公式チュートリアル
FastAPIには、日本語化された非常に充実した公式チュートリアルがあります。
最初は非常にシンプルです。
FastAPI()を作り、
パスを定義し、
リクエストを受け、
JSONを返す。
そこから、
- パスパラメータ
- クエリパラメータ
- リクエストボディ
- バリデーション
- レスポンスモデル
- エラー処理
などを段階的に学びます。
もちろんFastAPIにはSecurity Toolsもあり、認証・認可を実装できます。
つまり、
FastAPIが業務システムに使えないという話ではありません。
むしろ逆です。
自由度が高いからこそ、
「会社・組織・ユーザー・権限・データ境界をどうモデル化するか」
は、フレームワークの入門教材とは別に設計者が考えなければならないのです。
④ Next.js ― App Router入門
現在のNext.jsにはApp Routerを中心とした学習導線があります。
日本語で基本構造を確認できるドキュメントはこちらです。
Next.js 16 日本語ドキュメント：App Router
ここでは、
- インストール
- プロジェクト構造
- レイアウト
- ページ
- ナビゲーション
- Server Components
- Client Components
などを順番に学習できます。
公式のNext.js Learnには、さらに興味深い題材があります。
請求書を登録・編集・削除できるダッシュボード
を作ります。
ログインページもあり、認証で保護されたページもあります。
これは非常に良い教材です。
しかし、ここで経営者が注意すべきなのは、
「ログイン＋請求書CRUDができた」ことと、「企業の会計・販売管理システムとして設計できた」ことは同じではない
という点です。
本番の企業では、
営業担当者はどこまで見えるのか。
営業部長は何を承認できるのか。
経理担当者はどこまで変更できるのか。
支店Aから支店Bの請求情報が見えてよいのか。
退職者の権限をどこで停止するのか。
といった、教材とは別の問題が大量に発生します。
⑤ paiza ― Laravel入門
Laravelの入門教材も非常に分かりやすい例です。
paizaラーニング：Webアプリ開発入門 Laravel編
ここでは、
- ルーティング
- MVC
- Blade
- フォーム
- Eloquent ORM
- CRUD
- ログイン
- アクセス制御
まで順番に学ぶことができます。
しかもpaiza自身が、この講座について、
理解しやすくするため基本的な内容に留め、サンプルや演習課題も小規模にしている
と説明しています。
ここは非常に重要です。
教材が悪いのではありません。
教材側が「小規模な学習用です」と明示しているのです。
実際、後半ではログイン・ログアウト・サインアップを追加し、
自分の投稿だけ編集できるようにする
ところまで学習します。
これは認可を学ぶ最初の教材として優れています。
しかし企業システムでは、
「自分か他人か」
だけでは済みません。
会社、部署、役職、プロジェクト、店舗、担当顧客、承認経路などによって権限が変化します。
⑥ Railsチュートリアル ― Railsの教科書
Ruby on Railsにも、日本語で非常に分かりやすい初心者向け教材があります。
教材自身が目的を非常に明確に説明しています。
題材は、
写真や文章を投稿できるミニブログアプリ
です。
そして、
「できるだけ簡単なサンプルアプリ」
を使ってRailsとWebアプリの基礎を説明するとされています。
内容も、
- 小さなRailsアプリ
- CRUD
- モデル
- Gem
- 画像アップロード
という、非常に分かりやすい構成です。
これを読んでRailsを学ぶのは正しい。
しかし、
ミニブログの設計を、そのまま会社の販売・購買・会計・人事システムへ拡大するのは正しくありません。
⑦ Spring Boot ― 入門ガイド
最後は、企業システムでも広く利用されるSpring Bootです。
日本語で読めるSpringの入門ガイドがあります。
Spring：Spring Boot アプリケーションの構築
このガイド自身が、
Spring Bootを簡単に体験するためのもの
と説明しており、約15分で簡単なWebアプリケーションを構築します。
別のSpring MVC入門でも、
Webコントローラーを作り、ブラウザにページを表示させるところまでを段階的に学習します。
もちろんSpringには、その先に非常に強力なSecurityや企業向けの仕組みがあります。
しかし、
「15分でSpring Bootアプリが動いた」
ことと、
「企業の権限体系を設計できる」
ことは当然ながら別です。
2．7つを並べると、共通点が見えてくる
技術は全部違います。
JavaScript。
Python。
PHP。
Ruby。
Java。
しかし、入門教材には共通した構造があります。
まず、
画面を出す。
次に、
URLと処理を結びつける。
そして、
データベースへ保存する。
CRUDを作る。
さらに進んだ教材では、
ログインを付ける。
ここまで来ると、非常に「システムらしく」見えます。
だから危険なのです。
3．入門教材は「どう動かすか」を教える。業務設計は「誰に何を許すか」から始まる
初心者向け教材では、
「このボタンを押したらこの関数を呼ぶ」
「このURLならこのControllerを動かす」
「このフォームの値をデータベースへ保存する」
という順番で学ぶことが多くなります。
当然です。
動かなければ学習にならないからです。
しかし企業の業務システムでは、実装より前に、
誰が使うのか
を考えなければなりません。
例えば、
- 経営者
- 本部管理者
- 部長
- 店長
- 一般社員
- 経理担当者
- 外部税理士
- フランチャイズ加盟店
- 取引先
- 顧客
が同じシステムへアクセスするとします。
ここで最初に考えるべきなのは、
「画面をどう作るか」ではありません。
まず、
誰が、何を、どこまでできるのか
です。
4．「ログインを付けた」だけではマルチユーザー設計ではない
これは特に経営者に知っておいてほしい点です。
ログインとは基本的に、
「あなたは誰ですか？」
を確認する仕組みです。
しかし企業が必要としているのは、その次です。
「あなたは何をしてよいですか？」
さらに、
「どの会社・部署・店舗・顧客のデータを扱ってよいですか？」
まで決める必要があります。
したがって企業システムでは、
認証
↓
認可
↓
組織境界
↓
レコード境界
↓
業務上の承認関係
まで設計する必要があります。
ログイン画面は、その入口にすぎません。
5．生成AIが、この勘違いをさらに危険にした
以前なら、初心者が入門教材から大規模なシステムを作ろうとしても、途中でプログラムが動かなくなりました。
そこで、
「何か設計がおかしい」
と気づく機会がありました。
ところが生成AIは違います。
「この人だけ編集可能にして」
と言えばif文を書いてくれます。
「部長も編集可能にして」
と言えば、さらに条件を追加します。
「管理者も」
「この店舗だけ例外」
「このユーザーだけ特別」
と要求すると、
AIはかなりのところまで動くコードを作ってしまいます。
結果、
一つの業務ルールが、
画面Aのif。
画面Bのif。
APIのif。
バッチ処理のif。
帳票処理のif。
と分散していく。
それでも当面は動きます。
ここがAI時代の怖さです。
6．入門教材のコードを捨てる必要はない。「設計図」にしてはいけない
ここで誤解してほしくありません。
入門教材のコードを使うな、という話ではありません。
ルーティングの書き方。
ORMの使い方。
フォーム処理。
テンプレート。
API。
バリデーション。
これらはそのまま役立ちます。
しかし、
入門教材から学ぶべきなのは「部品の使い方」であって、「会社全体の設計図」ではありません。
ここを間違えると、
小さなTODOアプリを少しずつ継ぎ足して、
最後には基幹システムにしてしまうようなことが起きます。
それは、
二人乗りの原付きに荷台を足し、座席を足し、タイヤを太くし、最後には大型バスとして高速道路を走らせようとするようなものです。
途中からどれだけ部品を追加しても、
最初から多人数を乗せることを考えて作られた車両とは設計思想が違います。
7．経営者がSEに聞くべき質問は一つ
プログラムを読めなくても構いません。
担当者に、こう聞いてみてください。
「このシステムでは、誰が・どの組織に所属し・どのデータに・どんな操作をしてよいかを、どこで定義していますか？」
この質問に、
「この画面ではif文で……」
「このControllerでは……」
「ここだけ例外で……」
という説明が延々と続くのであれば注意が必要です。
逆に、
User。
Group。
Role。
Permission。
Policy。
Organization。
Tenant。
ACL。
名称は何でも構いません。
会社の権限体系と業務体系が、
一つの構造として説明できる
のであれば、少なくとも設計について考えられています。
結論――入門教材は正しい。だからこそ、その先が必要になる
今回紹介した7つの教材は、どれも悪い教材ではありません。
むしろ、
初心者にWebフレームワークを理解させるために、意図的に問題を小さくしている教材
です。
だからこそ重要なのです。
入門教材を最後まで終えたとき、
「業務システムが作れるようになった」
と考えるのではなく、
「業務システムを作るための道具を、一通り触れるようになった」
と考える。
ここには大きな違いがあります。
生成AIによって、この「道具を使う能力」は急速にコモディティ化しています。
その一方で、
誰が使うのか。
何を許すのか。
何を分離するのか。
どこを共通化するのか。
変更されたとき、どこまで影響するのか。
という設計の重要性はむしろ高くなっています。
入門教材を否定する必要はありません。
ただ一つ、
入門教材で作ったサンプルアプリを、そのまま会社の業務システムの設計図にしてはいけない。
これだけは、生成AI時代のDXにおいて経営者が知っておくべきことではないでしょうか。