Ponpoco WorksPonpoco Works

Ponpoco Works — Portfolio

手を動かして、
本番まで運用してきました。

地域おこし協力隊としての活動をきっかけに、非エンジニアから独学でアプリ開発を始めました。 設計から実装・運用まで一人で担ってきた経験と、そこから生まれた制作物をまとめています。

01

経歴・スキル

地域おこし協力隊としての活動以降の経歴です。

経歴

2023〜地域おこし協力隊として一関市に着任。地場の困りごとをITで解決する活動を開始
2026〜一般社団法人デジタルラボ一関で外部IT担当として活動。紙・手作業の業務改善やアプリ開発を支援
並行して屋号 Ponpoco Works として、L-Pocco(予約・現場管理SaaS)を個人開発・本番運用

使える技術

バックエンドPython・FastAPI
データベースSQLite
フロントエンドJavaScript・Jinja2(ノービルド構成を基本とする)
その他Google Apps Script・GitHub Actions
02

設計の判断軸

技術選定で何を優先し、何を捨てているか。実際の判断の軸です。

01

枯れた技術を選ぶ(Choose Boring Technology)

新規サービスは原則ビルド工程なしの素のHTML/CSS/JS、バックエンドはPython FastAPIモノリス、DBはSQLite単一ファイル。流行より、AI時代でも保守できる構成を優先する。

02

ルールはサーバー側で強制する

フロントだけの制御はIDOR(権限の迂回)の温床になる。UIは補助であり、業務ルールの強制は必ずサーバー側で行う。L-Poccoの本人確認・予約容量制御はこの原則で設計している。

03

新設定は「0=従来挙動」で足す

既存機能への新しいフラグや列は、未設定なら今までどおり動く形で追加する。段階的に安全にリリースし、切り戻しの道を残す。

04

ライブラリより先に標準機能を疑う

依存を増やす前に、プラットフォームやブラウザが標準で持つ機能で解決できないかを検討する。依存が少ないほど、長期的な保守コストは下がる。

05

限界と出口を先に文書化してから選ぶ

巧妙な最適化より、確実に動く単純さを優先する。ただし「単純さで済む範囲」には限界があるため、その構成が通用しなくなる境界(例: リアルタイム同時編集が本体になる、チーム開発化する)をあらかじめ言語化しておき、境界に達したときだけ構成を見直す。

03

制作物

依頼を受けてつくったものではなく、自分や身近な困りごとから生まれたツール群です。

04

個人開発を続ける理由

非エンジニアから始めて、必要に迫られて手を動かすうちに、自分で作って運用するところまで来ました。 頭で考えるより先に、まず小さく動くものを作って試す。困りごとを見つけたら、自分や身近な人のために作ってみる。 そうやって作ったものが、結果として次の仕事や関係につながっています。

経歴や制作物について、
ご質問があればお気軽にご連絡ください。