開発段階で本当に管理されるもの

一言でいうと

SIの開発段階で実際に管理されるのは、コードの品質ではなく、標準・構成・進捗の3つであり、その理由は、このシステムを作った人が、2年後にはいないからです。

なぜ標準が先なのか

開発者が20人なら、スタイルが20通り出てきます。それぞれ、それなりに合理的ですが、3年後に保守する人は、その20通りをすべて読まなければなりません。SIシステムの寿命は普通7–10年で、作った人はたいてい2年以内にいなくなるので、読む人の時間が、書く人の好みよりはるかに高くつきます。

そのため、標準は、良いコードを作るためのものではなく、予測可能なコードを作るためのものです。どのファイルを開いても同じ場所に同じものがあれば、初めて見るモジュールでも30分で直せます。

開発標準が最初に来る

SIプロジェクトの開発の最初の週は、コーディングではなく、開発標準定義書を読むことから始まります。パッケージ構造、クラスの命名規則、ログレベルの使用基準、例外処理の方式、共通コードの使い方、クエリの作成ルール(動的クエリの許容範囲、ヒントの使用可否)が、そこに書かれています。

理由は単純です。開発者が20人なら20通りのスタイルが出てきて、3年後に保守する人は、その20通りをすべて読まなければなりません。SIシステムの寿命は普通7–10年で、作った人はたいてい2年以内にいなくなります。

公共事業なら、ここに電子政府標準フレームワークが加わります。Springベースで、共通コンポーネント(ログイン、ファイルアップロード、掲示板、コード管理)を提供します。バージョンとJDKの組み合わせが事業の公告に明記されているので、「もっと新しいバージョンのほうがいいのですが」は通用しません。

構成管理: ブランチよりも「タグとリリースノート」

最近は、SIでもGitを使います。しかし、オープンソースプロジェクト式のブランチ戦略をそのまま使うと、うまく合いません。理由は、デプロイの単位が「機能」ではなく、「次」(1次、2次)だからです。

1次サービスイン: 会員/注文
2次サービスイン: 精算/統計
安定化パッチ: 毎週木曜日の夜間

そのため、実際に重要なのは3つです。

デプロイされたものとソースが一致しているか: タグなしでデプロイすると、3か月後にロールバックする対象が見つかりません。
誰がいつ何をなぜ変えたか: コミットメッセージに要件IDや欠陥IDを入れる理由です。fix bugというコミットメッセージは、保守担当者に何の情報も与えません。
本番反映の履歴: ソースの履歴とは別に、「いつどのバージョンを本番に上げたか」の台帳が必要です。

エアギャップ環境のプロジェクトなら、外部のGitHubが使えないので、社内のGitLabか、ひどい場合は、ファイルサーバーとzipが構成管理です。そのような環境でも、タグ=デプロイアーティファクトのスナップショットという原則だけ守れば、最悪は避けられます。

単体テスト: SIでこの言葉が実際に意味するもの

用語を正確に知っておく必要があります。学校で習った単体テスト(JUnit)と、SIの成果物としての「単体テスト」は、重なりますが、同じではありません。

区分	対象	成果物	誰が
単体テスト(UT)	プログラム/画面1つ	単体テストシナリオ・結果書	開発者本人
統合テスト(IT)	業務フロー、システム間連携	統合テストシナリオ・欠陥管理台帳	QA/PL、両システム
受入テスト(UAT)	顧客の業務シナリオ	受入テスト結果書、検収確認書	顧客の業務部門

SIの単体テスト結果書は、普通こんな表です。

TC-207 | 주문 조회 - 정상 | 조건: 고객ID=C001, 기간=2026-01~2026-06
       | 기대: 12건 조회, 응답 3초 이내
       | 결과: 12건, 1.8초 | 판정: Pass | 시험일: 2026-08-11 | 시험자: 김영주

このコードブロックの韓国語は、注文照会の正常ケース、条件(顧客IDと期間)、期待(12件照会、応答3秒以内)、結果(12件、1.8秒)、判定、試験日、試験者(人名)を表しています。

重要なのは「例外ケースがいくつあるか」です。正常ケースだけの単体テスト結果書は、レビューで差し戻すのが正しいです。最低でも、次のものは必要です。

必須値の欠落
長さ超過 / 型の不一致
権限のないユーザー
照会結果が0件
同時更新(楽観ロックの競合)

コードレビューと静的解析

大規模な事業には、普通、品質項目が契約に入っています。静的解析ツール(SonarQubeなど)で、致命的な欠陥0件、セキュリティ脆弱性0件のような目標値が設定されます。

ここで、新人がよく経験することがあります。締め切り直前に静的解析を初めて実行したら、2,000件出てくるのです。序盤から毎日実行する必要があります。ルールはプロジェクトの開始時にチームが合意してロックし、それ以降に新しく生じた違反だけを防ぐ方式(新規コード基準)が現実的です。

進捗率の正直さ

週次報告に使う進捗率は、たいてい「完了プログラム数 / 全プログラム数」です。そのため、プログラム一覧が正確であって初めて、進捗率が意味を持ちます。

そして、1つのルールがあります。単体テスト結果書がなければ、完了ではありません。「コーディングはすべて終わっていて、テストだけが残っています」が積み重なると、最後の2週間に、全員がテスト結果書を遡って作成することになります。その文書にどんな価値があるかは、誰もが知っていますが、誰も口にしません。

現場での姿

進捗率の報告は、この段階で最もよく歪みます。「80%完了」という報告が、何週間も80%にとどまるのが、典型的なサインです。

原因は、たいてい数える単位がないことです。プログラム一覧があれば、進捗は「全体118個のうち92個の単体テストが合格」のような、数えられる数字になりますが、一覧がなければ、各自の体感を平均することになります。そして、体感はいつも90%付近で止まります。

構成管理も、同じ理由でずれます。ブランチ戦略をどれだけうまく組んでも、デプロイの単位が「次」であるプロジェクトでは、何がいつ出たかのほうが重要です。タグとリリースノートがなければ、障害のとき、「今本番に上がっているのは、どの時点のコードなのか」を、誰も断言できません。