変えやすさを優先する
システムは、使われ始めてから要件が変わります。最初の設計で目指すのは、すべてを予測することではなく、変わったときに直しやすいことです。
01Architecture
アーキテクチャの考え方
小さく始め、必要になったら分ける
最初はモジュラーモノリスで作り、分ける必要が出た境界だけをサービスに切り出します。
移す道を残しておく
特定のサービスに依存する部分を小さくし、規模が変わったときに別の基盤へ移せるようにします。
決めた理由を残す
技術選定やアーキテクチャの判断は、なぜそう決めたか、ほかに何を比べたかを、設計の記録として残します。担当者が替わっても判断の経緯が分かります。
02AI-driven development
AI 駆動開発
AI で速く書き、判断と確認は人が持つ。分担をはっきり決めています。
AI に任せること // draft
- 実装の下書き
- テストコード
- ドキュメントの下書き
- 既存コードの調査
人が行うこと // decide
- 要件の整理
- 設計の判断
- コードレビュー
- リリースの判断
- 情報の扱い
- お客様のコードと情報は、学習に使われない設定のツールでのみ扱います。お客様の規程がある場合はそれに従い、AI ツールを使わない体制にも対応します
- 使うツール
- Cursor、GitHub Copilot、Claude Code など。案件ごとに、お客様の規程に合うものを選びます
03Quality & security
品質とセキュリティ
- コードレビュー
- すべての変更をレビューしてから取り込みます
- 自動テスト
- 重要な処理に自動テストを書き、CI で毎回実行します
- 静的解析・型チェック
- CI で毎回実行します
- 検証環境
- 本番と同じ構成の検証環境で確かめてからリリースします
- リリース
- CI/CD で自動化します。可能な構成ではブルーグリーンデプロイで、止めずに切り替えます
- 権限と秘密情報
- 権限は必要な最小限にし、パスワードや鍵は管理ツールで扱います
04Deliverables
納品物
要件定義書
作るもの・作らないもの、画面と機能の一覧
設計書
構成図、データの設計、技術選定の記録
ソースコード
お客様のリポジトリに納品します
テストの結果
テストの観点と結果
運用手順書
デプロイ、監視、障害時の対応の手順
環境の定義
IaC で管理している場合は、そのコード
05Contract
契約形態
作るものと範囲が決まっている開発
成果物を納品します。
要件が固まりきっていない開発、リリース後の改善や運用の継続
状況に合わせて進め方を調整しながら、継続して開発と改善を行います。
06Process
進め方
- 01
要件整理
作るもの・作らないものを分けます。既製の SaaS で足りるなら、そうお伝えします。
- 02
技術選定・設計
構成と技術を選び、選んだ理由を残します。費用の内訳（工数・単価）を示します。
- 03
実装
小さく動くものを早めにお見せし、確認しながら進めます。仕様を変える場合は、理由と影響を整理してからお伝えします。
- 04
テスト・リリース
検証環境で確かめ、CI/CD でリリースします。
- 05
運用・改善
監視とコストの見直しを続けます。保守の範囲と時間を決めてお受けします。
07Tech stack
技術スタック
実務か、自社で本番運用した経験がある技術だけを載せています。
- フロントエンド
- React / Next.js / TypeScript
- バックエンド
- Node.js / Hono / Prisma / Java・Spring
- モバイル
- iOS / Android (cross-platform)
- 生成 AI
- Gemini API (Google) / RAG
- クラウド
- AWS / Google Cloud / Azure
- PaaS・エッジ
- Supabase / Vercel / Render / Cloudflare
- DevOps
- CI/CD (GitHub Actions) / IaC / ブルーグリーンデプロイ
- ローコード・SaaS
- kintone / Salesforce / Power Apps / Power Automate / SharePoint Online
→Contact
お問い合わせ
進め方や納品物を、お客様の社内の基準に合わせることもできます。