開発・コーディングルールを公開します
- 奧村 哲次
- 1 日前
- 読了時間: 3分
― アジャイルでも要件定義を捨てないための実務設計 ―
アジャイル開発が当たり前になった今、
開発現場では次のような言葉をよく耳にします。
「要件定義はしない」
「まず作ってから考える」
「細かいことは後で直せばいい」
それらはすべて、「アジャイルだから」 という言葉で正当化されがちです。
しかし私は、
この認識こそが多くの開発プロジェクトを不安定にしている最大の原因だと考えています。
アジャイル開発は「判断を省略する」ことではない
アジャイル開発とは、
要件定義をしないこと
判断を後回しにすること
ではありません。
実際の現場では、必ずどこかで次のような判断が行われています。
何を実装するのか
何を変更するのか
何を削除するのか
どこに影響が出るのか
いつリリースするのか
問題は、
それらの判断が「どこに正として残っているのか」 が
構造として整理されていないことです。
判断が構造化されていない現場で起きていること
多くの現場では、判断が
会話の中で決まり
チャットに流れ
コードを書いた人の頭の中だけに残る
という状態になっています。
この構造では、
調査のたびに考え直す
修正のたびに背景を探す
引き継ぎのたびに混乱する
という状況が必ず発生します。
開発・コーディングルール Wiki を公開した理由
そこで今回、
私自身が実務で実際に使っている「開発・コーディングルール」をWikiとして整理し、公開しました。
このWikiで定義しているのは、
コーディング技法
フレームワークの使い方
開発効率化のノウハウ
ではありません。
定義しているのは、ただ一つ
一度決めた判断を、実装で変えさせないための実務ルール
です。
判断は正本に集約する
コードには判断結果だけを残す
調査や修正で「なぜこうなったか」を考え直さなくて済む
そんな構造を作ることを目的としています。
手法論よりも「構造」を重視する
アジャイル、ウォーターフォール、スクラム。
どの手法を使うかは本質ではありません。
重要なのは、
判断がどこで確定し
どこに正として残り
実装とどう結びついているか
という 構造 です。
Wiki 入口（Chapter 0）
この考え方と
全体構成をまとめた入口ページが以下の Chapter 0 です。
👉 開発・コーディングルール Wiki｜Chapter0
ここから先では、
ADD / CHG / DEL による判断区分
Backlogキーと日付をコードに残す理由
Gitを「履歴」ではなく「復元装置」として扱う設計
環境分離と責任範囲
デモ環境を本番と混ぜない理由
といった、
実務で破綻しないための具体ルールを
Chapter 1〜6 に分けて整理しています。
最後に
アジャイルであっても、要件定義は必要です。
ただしそれは、分厚いドキュメントを作ることではなく、
判断を構造化し、実装と結びつけることです。
その一つの答えとして、このWikiを公開しました。
コメント