0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

個人開発【現場OS開発編】【プロローグ】素人エンジニアが自分でアプリ開発できると甘く見てた 全16弾 無邪気な実装 vs 架空エンジニア2人の容赦なきツッコミ ~便利かなと思ってどんどん追加しちゃうんだよね~

0
Last updated at Posted at 2026-09-02

0F8B3937-EBD8-4F93-AA08-F42B89FD01B7.png

構想編はこちら

▶ note「現場OS 構想編」を読む

IMG_2160.jpeg

開発編シリーズ目次|全16弾+エピローグ

#1「在庫が見たいだけ」だったのに、引き算ひとつから在庫引当と多目的最適化まで始まった
総在庫・予約在庫・有効在庫を分けた瞬間、ただの在庫表示が別物になった

#2「予約機能もこのアプリ1個にまとめれば便利じゃん」で、“時間”が一気に牙をむいた
時間重複・境界条件・時間粒度・スマホ操作まで、空いてる時間を選ぶだけでは終わらなかった

#3「機能増えたら毎回探すの面倒じゃん」で、お気に入りから共通UI設計まで広がった
機能を増やした結果、「何を作るか」より「どう辿り着くか」が問題になった

#4「普通の組織図でいいじゃん」で一人を複数部署に入れたら、“多対多”が始まった
兼務・複数所属・部署別役職・過去履歴が一気に絡み始めた

#5「どこの現場で使うかも持てばいいじゃん」で、物件マスタが在庫・予約・人を全部つないだ
機能ごとにバラバラだった情報が、共通マスタを境に一つのシステムへ変わり始めた

#6「会社ごとにちょっと変えたい」で、設定駆動とバリデーションが殴り合いを始めた
柔軟にしたら、「自由に設定させすぎない仕組み」の方が難しくなった

#7「ログインできたからって何でも触れたらまずいじゃん」で、認証より面倒な認可の沼に入った
管理者か一般かでは足りず、「誰が・誰に・何をできるか」まで判定することになった

#8「二人とも空いてる画面を見てたら、どっちが勝つの?」でRace Conditionが牙をむいた
在庫も予約も、画面に表示された「空き」を信用しただけでは守れなかった

#9「自分の在庫も持てた方が楽じゃん」で、“場所・所有・利用範囲”が全部別問題だった
マイ在庫・現場在庫・共有在庫を分けたら、在庫数よりスコープ管理が難しくなった

#10「申請もこの中でできた方が楽じゃん」で、CRUDの裏に状態遷移が増殖した
申請・承認・差し戻しを入れた瞬間、「保存できる」だけでは何も足りなくなった

#11「資格もQRで見られたら早いじゃん」で、“全部見せる”より“必要な答えだけ返す”方が難しかった
資格・個人QR・権限をつないだら、識別より情報開示の方が本題になった

#12「一輪車を“ネコ”で探せないの不便じゃん」で、Canonical IDと人間の曖昧さを両立させることになった
人間には優しく、内部は厳密に――別名検索から正式IDへ収束させるまで

#13「機能増えすぎて説明する方が面倒」で、“どれが今の正解?”問題がコードの外まで広がった
ヘルプ・仕様・会話・引き継ぎがズレ始め、Single Source of Truthが必要になった

#14「Codexなら全部見てくれるじゃん」で、AIの作業速度が人間のレビュー限界を超えた
コードベース横断調査が便利すぎて、変更範囲・Git・差分・安全コミットが主役になった

#15「テストこんなに通るじゃん」で安心しかけたら、“全部緑なのに間違ってる”が普通に出てきた
横断テストで見えた、Interaction Bug・境界値・期待結果そのものの罠

#16「人間+AI+Codex、ここまで来たら完成でしょ?」で、開発体制そのものをプロにダメ出しされた
完全な、ど素人から辿り着いた現在地――でも最後まで人間が働きすぎだった

♯エピローグ「作れた」で終わりじゃなかった。むしろ、そこからが本番だった

やっぱりプロのエンジニアは凄いですね。

➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖

2026年。

現場OSの構想を、

実際に動くものへ変えるため、

本格的に開発へ着手しました。

使っていたのは、

中古の安価なノートパソコン1台のみ。

増設モニターなし。

開発環境らしい立派な設備もなし。

できることといえば、Excelを少し触れるくらい。

プログラミングの技術は、なし。

作っている本人が、完全な【ど素人】でした。

ここで、この開発記を読むうえでの前提だけ少し。

現場OSは、Node.js/JavaScriptを中心に作っています。画面側はHTML・CSS・JavaScript、サーバー側もNode.jsです。

そして、この開発記は、

「ど素人がAIを使って、どこまでアプリを作れるのか」

という記録でもあります。

ちなみに、本格的なDB(データベース)は使っていません。

データの保存には、JSONという形式のファイルを使っています。

開発環境はWindowsのローカル環境。

ただし、私は最初からこれらを理解して、自分でコードを書いていたわけではありません。

むしろ逆です。

コードも分からない。DBも分からない。APIも分からない。Gitもよく分からない。

私が分かっていたのは、

「現場で、こうなったら便利じゃん。」

という部分でした。

そこから私がやりたいことをAIへ伝え、AIにコードを書いてもらい、PowerShellで動かして確認する。

この開発編は、そんな状態から始まっています。

そして途中からCodexも加わり、作り方そのものまで少しずつ変わっていきます。

この前提を書いておくことで、この先に出てくるAPI、Git、PowerShell、競合制御、テストといった技術の話も、「最初から知っていた技術」ではなく、現場の疑問から必要になって、一つずつ出会っていったものとして読んでもらえると思います。

そこも含めて、ど素人がAIと一緒に作ってきた現場OSの開発記です。

こうなっていれば便利なんじゃないか?

コードからではなく、

技術用語からでもなく、

現場で感じていた、

そんな小さな疑問から始まりました。

今回は、開発内容を順番に説明するだけではなく、

二人のエンジニアに登場してもらいます。

エンジニアAは、

「エンジニアなら、そこ気になるでしょ」

というところを遠慮なく突っ込む役。

エンジニアBは、

そこで起きていることに、

技術用語を付けて短く解説する役。
642DCF57-8470-4B05-B11B-DD8C5AB2D48A.png

そして私は、

当時何を考え、

実際にどう作り、

どこで失敗し、

どう変えていったのかを答えます。

開発内容は実話。

A・Bとの会話はフィクションです。

このシリーズでは、

こんなふうに、

私の「これ便利じゃん」という素人発想。

Aの「エンジニアならそこが気になる」というツッコミ。

Bの「それにはこの技術が関係する」という短い解説。

で進めていきます。

そして最終回では、

作ったアプリだけではなく、

私自身のAIとの開発方法までツッコまれます。

完全な、ど素人が、

知らないまま問題にぶつかり、

後から、

「これ、ちゃんと技術の名前あったんだ。」

と知っていった記録です。

それでは、第1弾、

「在庫が見たいだけ」だったのに、引き算ひとつから在庫引当と多目的最適化まで始まった

総在庫・予約在庫・有効在庫を分けた瞬間、ただの在庫表示が別物になった。

始まりは、本当にただの引き算でした。

「10個あって、3個予約されてるなら、7個って出せばいいじゃん。」

――この「7個」をちゃんと出そうとしたところから、全部が始まります。

連載公開分(クリックで開く)
0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?