今回は、わたしたちの開発チームが“何をやっているか”というより、“どういう考え方で開発しているか”を中心にお話ししたいと思います。

おたくの開発チームって、結局どういう特徴なの？

一言で言うと、「業務起点で、長期運用前提の基幹システムを、内製で再構築しているチーム」です。

① 前提：扱っているシステムの特性

まず、わたしたちのチームの前提です。

• 教育領域の基幹システム（学生・講師・学納金など）
• 年間3万人以上の個人情報を扱う
• 複数システムに分断された既存ERPを段階的に再構築中
• 業務依存度が高く「止められないシステム」

つまり、

💡 「壊れてはいけない」領域

です。

この前提が、すべての設計・技術判断に影響しています。

② 設計思想：長期運用前提（10年スパン）

設計の基本方針は明確です。

• 一時的な開発効率よりも、長期保守性を優先
• 属人化を排除し、誰が見ても理解できる構造にする
• 「あとで直す」を前提にしない

具体的には：

• 責務分離を徹底（Controller / Service / Domain / Repository）
• ビジネスロジックはドメイン層に集約
• トランザクション境界を明示的に設計
• 例外設計（握り潰す / 伝播させる）を意図的に統一

💡 “動くこと”ではなく、“壊れない構造”を作る設計

です。

③ 技術スタック：保守性・標準化を最優先

技術は堅実なものが多いです。

言語

• Java / C#
  → 型安全・コンパイルチェックによる品質担保

フレームワーク

• Spring / .NET
  → 標準化された構成・長期サポート

データベース

• RDB（トランザクション前提設計）
  → ACID特性を前提に整合性重視

フロント

• SSR（Server-Side Rendering）
  → フロント/バックの責務分離・構造の単純化

バージョン管理

• Git
  → レビュー・履歴・設計意図のトレーサビリティ確保

💡「再現性と寿命」で選定

しています。

④ 開発プロセス：全員設計・全員実装

一般的な分業とは違います。

• 設計担当 / 実装担当を分けない
• 全員が設計レビュー・コードレビューに参加
• 実装中の気づきを設計へ即時フィードバック

これにより：

• 設計と実装の乖離が起きない
• 実装不能な設計が生まれない
• 現場にフィットする仕様になる

💡設計はドキュメントではなく、チームで更新され続けるもの

という考え方です。

⑤ レビュー文化：業務ロジックまで踏み込む

レビューは品質チェックではありません。

観点は主に3つです：

技術観点

• N+1問題の有無
• トランザクション境界の妥当性
• パフォーマンス

設計観点

• 責務分離が守られているか
• 変更に強い構造か

業務観点

• このロジックは業務的に正しいか
• 想定外ケースで破綻しないか

実際の会話例：

• 「この制約、DB制約で持つべきでは？」
• 「この処理、業務上あり得るパターン漏れてない？」
• 「この例外、ユーザーにどう影響する？」

💡 コードレビュー＝業務理解の深化プロセス

です。

⑥ ドキュメント運用：設計の一部として扱う

ドキュメントは必須です。

対象：

• 要件定義書（業務要件）
• 設計書（アーキテクチャ / データフロー）
• システムにかかわる仕様書全般
• README / コードコメント

運用ルール：

• Gitでコードと同時管理
• リリース前に必ず更新
• 変更履歴を明確化

目的：

💡 「知らない人でも理解できる状態」を維持すること

属人化を防ぐためのコア資産です。

⑦ 業務理解：評価軸の中心

わたしたちのチームで評価されるのは以下です。

• 業務フローを正しく理解できる
• データの流れを設計できる
• ビジネス要件とシステム要件を接続できる

具体的な問い：

• 「この業務、どのタイミングでデータが発生する？」
• 「この処理、リアルタイムである必要ある？」
• 「この例外、業務上どう扱うべき？」

です。

⑧ AI活用：補助として限定的に利用

利用方針は明確です。

• GPT：設計初期の矛盾検出・思考補助
• Copilot：実装補助
• IDE：VSCode / Visual Studio

制約：

• 上流（要件定義・設計）は人間主導
• 意思決定をAIに委ねない

💡 AIは“加速装置”であって、“設計者”ではない

という位置づけです。

まとめ

わたしたちのチームの特徴を整理すると：

• 業務起点で設計する
• 長期運用（10年）前提で構造を作る
• 技術は標準・堅実志向
• 全員設計・全員実装
• レビューで業務ロジックまで踏み込む
• ドキュメントで属人化を排除
• 業務理解が評価の中心

いまのフェーズでしかできないこと

• 内製化の初期メンバーとして関われる
• 技術選定・設計思想に意見を出せる
• システム全体を理解できる

完成された環境では得られない経験です😊