株式会社ラフティ | Time Craft Consulting
なぜ、判断は実装で変わってしまうのか
― 判断を実装で変えさせないための開発・コーディングルール ―
Chapter 0
開発ルール総論― このWikiが存在する理由 ―
このWikiは、
コーディングのやり方を教えるものではない。
また、
開発効率を上げるためのテクニック集でもない。
ただし、最初に一つだけ明確にしておく。
このルールを守った結果として、
調査・修正・判断は圧倒的に速くなる。
なぜなら、
一度決めた判断が、実装で勝手に変わらないためだ。
0-1. このWikiが前提としている現実
本Wikiは、
**「正しく作ればバグは出ない」**という前提を取らない。
むしろ逆である。
-
開発したものには必ずバグが出る
-
想定外の使われ方は必ず起きる
-
仕様変更・追加判断は必ず発生する
これは能力の問題ではなく、
ソフトウェアという対象の性質である。
したがって重要なのは、
-
バグをなくすこと
ではなく -
バグが出たときに、どれだけ早く正確に対処できるか
である。
0-2. 修正作業の正体は「調査」である
修正作業は、
コードを書くことから始まらない。
必ず次の工程から始まる。
-
何が起きているかを把握する
-
どこに影響しているかを特定する
-
どの判断に基づく実装かを確認する
この「調査」が遅いプロジェクトほど、
-
対応が遅れ
-
暫定対応が増え
-
副作用が連鎖する
つまり、
修正速度を決めているのは調査速度である。
0-3. 調査が遅くなる本当の原因
多くの現場で調査が遅くなる理由は、
技術力不足ではない。
原因は次のどれかである。
-
どの判断に基づく実装か分からない
-
判断の理由がコード・コメント・人の記憶に分散している
-
「当時はこうだったはず」という推測が入る
この状態では、
調査は必ず人依存・記憶依存になる。
0-4. 本Wikiが解決しようとしている一点
本Wikiでは、
判断の正本を Backlog に一本化する。
これは、Backlogというツール自体を
特別視しているわけではない。
Backlogを採用している理由は、
判断を「ID単位」で管理できる構造を持っているからである。
-
タスク＝要件単位で判断を切り出せる
-
IDによって判断を集約・参照できる
-
アジャイル開発においても
判断の追加・変更を自然に積み重ねられる
この「判断をサマリできる構造」が、
調査・修正を高速化する。
Slackなどのチャットツールは会話には適しているが、
判断の集約や再参照には向かない。
本Wikiが重視するのはツール名ではなく、
判断を一意に識別・一覧化し、
実装と即座に結びつけられる構造である。
0-5. なぜアジャイル開発と相性が良いのか
本Wikiは、
アジャイル・ウォーターフォール・スクラムを含む
どの開発手法でも成立する構造を前提としている。
重要なのは手法ではなく、
判断がどこで確定し、どこに正として残り、実装とどう結びついているかである。
近年は変更が頻発し、
優先度の高い判断から実装・検証を進める必要があるため、
要件や判断を小さく切って進めるアジャイル的な運用が現実的になっている。
本Wikiは、
変更をすべて「新しい判断」として積み重ねられる構造を持つため、
修正判断を速め、スプリントを止めずに対応できる。
一方で、
最終ゴールや全体像といった大枠は、
ウォーターフォール的に定義されている方が安定する。
本Wikiは、
全体像はウォーターフォールで定義し、
機能や要件を小さく切った単位で判断と実装を回す構造を前提としたルールである。
0-6. 効率化は「目的」ではなく「結果」である
本Wikiは、
効率化や生産性向上を目的として定義していない。
目的はただ一つ、
調査時に迷わない構造を作ることである。
判断の正本が一意であり、
判断と実装の対応関係が明確であれば、
-
調査は速くなり
-
修正判断は迷わず
-
実装の手戻りは減る
その結果として、
効率は自然に向上する。
これはテクニックによる効率化ではなく、
構造が正しく設計されたことの副作用である。
まとめ
本来、ウォーターフォールで定義すべき内容は、
工程ではなく 判断と責任を固定するための観点である。
具体的には、次が最低限そろっていなければならない。
-
要件・課題は何か（何を満たせば成功か）
-
原因・ボトルネックは何か（なぜ今それが起きているか）
-
解決方針は何か（どの手段で、何を変えるか）
-
影響範囲はどこか（システム／運用／業務／顧客体験／契約・規約）
-
非機能要件は何か（性能・可用性・セキュリティ・監査・保守性）
-
制約条件は何か（期限・予算・法規・既存仕様・外部依存・リソース）
-
完了条件は何か（受入条件／テスト観点／“OK”を誰が出すか）
-
移行・リリース手順はどうするか（切替方式・ロールバック・周知・教育）
-
リスクと対応は何か（起きうる事故と判断ルート）
-
責任分界はどこか（顧客／開発／運用／ベンダー間）
これらは、
Backlogであれば タスク起票時に穴埋め形式のテンプレートとして定義できる。
このテンプレートを一つずつ埋めていくことで、
-
要件定義書が自然に完成し
-
実装判断が明確になり
-
テスト観点が自動的に揃う
詳細設計書を別途作らなくても、
実装できるレベルまで判断を構造化できる。
これが、
Backlogを前提としたアジャイル開発が成立する理由である。
アジャイルとは、
考えずに早く作ることではない。
考える単位を小さくし、確実に回すことである。
本Wikiは、
この前提が崩れないための構造ルールを定義している。