【IT現場の生態系】 「仕様確定」と「手戻り」、日本語が通じない異文化コミュニケーション

　金曜日の夕方、新しく導入される業務管理システムの試作画面を見つめて、ビジネスマンが軽やかに呟きます。
　　「ねえ、この社員検索の画面に、ついでに『過去の所属部署履歴』も表示できるようにしてよ。ボタン一個増やすだけでしょ？ 簡単、簡単」。

　その言葉を聞いたエンジニアの顔から、すうっと血の気が引いていく。
　　「えっと、今からそれを追加するとなると、仕様確定の後ですし、データ構造から見直す必要が……」

　　「そんなのプロなんだから、いい感じにやっといてよ！」

　これが、ITの現場で日常的に繰り返される、悲劇の幕開けの瞬間です。

　なぜ、このような悲しいすれ違いが絶えないのでしょうか。同じ日本語を話し、同じ会議室で頷き合っているはずの私たちが、実はまったく違う景色を見ている構造を、少し紐解いてみましょう。

物理法則のロックと、とりあえずの判子

　ITの世界において「仕様確定」という言葉は、プロジェクトの生存線そのものです。しかし、この言葉の解釈が、ビジネス側とエンジニア側とで致命的なほどズレているのです。

　発注側のビジネスマンにとって、仕様確定とは「とりあえずのスタートライン」に近い感覚ではないでしょうか。服を買いに行って「ひとまずこのサイズで試着してみよう」とするような、走りながら変えればいいという気軽さです。後から気が変わったら、微調整すればいいじゃないか、と。

　一方で、受注側のエンジニアにとっての仕様確定は、建築で言えば「コンクリートを流し込んで基礎を固める瞬間」です。これ以降の変更は、物理法則をひっくり返すほどのエネルギーを必要とするのです。
　データが複雑に絡み合う基幹システムであればなおさらです。画面に項目を一つ増やすということは、裏側のデータベースの形を変え、関係する過去のデータとの整合性を保ち、セキュリティの穴がないかを検証する、果てしないパズルを引き起こすことを意味するのです。

　それなのに現場では、「よくわからないけれど、期日だからとりあえず判子を押した」という合意なき確定が、今日もどこかで執行されています。

ジェンガの最下層を抜く絶望

　そうして生み出されるのが、現場における最大の環境破壊、すなわち「手戻り」という魔物です。
　ビジネスの現場からすれば、手戻りは「ちょっとした修正」に見えるかもしれません。Excelのセルを一行付け足すような感覚です。「なぜ、あんなに簡単な変更に何週間もかかるんだ？」「まだ完成していないのに、なぜ追加費用が発生するんだ？」と、不信感を募らせることもあるでしょう。

　ですが、エンジニアの視点に立つと、その「ちょっとした修正」は、完成間近のジェンガの最下層を「やっぱりここ、別のパーツに変えて」と引き抜かれるような絶望を伴います。

　地味で複雑な業務システムほど、一つの変更がドミノ倒しのように全体のバランスを崩します。良かれと思って直した一箇所が原因で、全く関係のない別の機能が動かなくなる「デグレード」という連鎖バグ。これが、エンジニアの精神をガリガリと削りとっていきます。苦労して積み上げた成果物が一瞬でゴミになる。「手戻り」とは、ただの作業のやり直しではなく、現場のモチベーションを根こそぎ破壊する災害なのです。

丸投げと営業スマイルの共犯関係

　この終わらない戦いを引き起こしている主犯は、実は双方の陣営に潜んでいます。

　一人は、自分の業務を言語化することをサボり、「プロなんだから言わなくてもいい感じにしてよ」と丸投げする発注者です。自分がどんなシステムを欲しているのか、自社の業務がどう回っているのかを、エンジニアに翻訳して伝える努力を放棄したとき、時限爆弾のタイマーが回ります。

　そしてもう一人の主犯は、心の中で「無理に決まっているだろう！」と叫びながら、営業スマイルで「持ち帰って前向きに検討します」と言ってしまう、ノーと言えないSIerやベンダーの上司です。できないことを「できない」と言えず、持ち帰った結果として現場のエンジニアにデスマーチを強いる。

　この「丸投げする発注者」と「ノーと言えないベンダー」との不幸な掛け算が、現場に未確定の手戻り爆弾を降らせ続ける構造を作っています。どちらか片方だけが悪者なのではありません。この二者の共犯関係こそが、生態系を歪めている真因なのです。

同じ子供を育てる共同親権者のように

　この泥沼から抜け出すために、私たちは普段から何を心がければよいのでしょうか。

　まず発注側のビジネスマンに必要なのは、「仕様確定」の判子の重さを知ることです。
　画面のイメージが湧かないなら、わからないまま進めてはいけません。エンジニアに「これ、実際に使うとどういう画面遷移になるの？」と、絵やプロトタイプを見せてもらうまで、しつこく食い下がる執着心が必要です。言葉の丸投げをやめ、自分の業務に向き合うことが、巡り巡って自分たちの未来を救います。

　一方で、受注側のエンジニアも、ただ「できません」と壁を作るのをやめるべきでしょう。
　ビジネスの言語でトレードオフを提示するのです。「その項目を追加するなら、全体の納期が2週間伸びます。あるいは、こちらの別の機能を諦めるなら今からでも入りますが、どちらが事業にとって優先度が高いですか？」と。

　システム開発とは、発注元と下請けの上下関係ではありません。一つのシステムという子供を、知恵を出し合って育てる「共同親権者」のような関係であるはずです。

　仕様確定を慎重に行うことは、決して相手を突き放す冷たさではありません。むしろ、限られた時間と予算の中で、最高のプロダクトを無事に世に送り出すための、お互いに対する「最大の優しさ」なのです。

【徒然メモ】「仕様確定」と「手戻り」の本質

1. 「仕様確定」とは何か

　IT現場における「仕様確定」は、単なる「書類へのサイン」ではなく、プロジェクトの生存線（ライフライン）です。

(1) 発注側のビジネスマンから見た「仕様確定」

　・「とりあえずのスタートライン」
　　「走りながら変えればいい」と思われがち。

　・「予算と納期のロック」
　　これ以上お金と時間をかけないための「約束」という認識。

　・「欲しいものが言語化された状態」
　　業務要件が画面イメージや機能一覧に落とし込まれた状態。

(2) 受注側のエンジニアから見た「仕様確定」

　・「設計・実装へのGOサイン」
　　建築で言えば「基礎工事を始めて良い」という絶対的な境界線。

　・「変更管理の基準点」
　　これ以降の変更は「追加料金・納期延長の対象（変更リクエスト）」になるという防衛線。

　・「予測可能性の担保」
　　データ構造やアーキテクチャを決定するための、不確実性の排除。

(3)「仕様確定」の理想と現実

　・理想
　　全員が同じ完成形をイメージし、合意できている状態。

　・現実
　　発注側は「よくわからないけど判子を押した」、受注側は「判子をもらったからこれで進める」という、「合意なき確定」が多発する場所。

2. 「手戻り」とは何か

　「手戻り」は、IT現場における最大の環境破壊（デスマーチの引き金）です。

(1) 発注側のビジネスマンから見た「手戻り」

　・「ちょっとした修正・変更」
　　「ボタンの位置を変えるだけ」「項目を1つ増やすだけ」という軽い認識。

　・「スケジュールの遅延」
　　なぜそんなに時間がかかるのか直感的に理解しにくい「ブラックボックスな時間」。

　・「追加費用の発生」
　　「まだ完成していないのに、なぜ追加でお金がかかるのか」という疑問の種。

(2) 受注側のエンジニアから見た「手戻り」

　・「ジェンガの最下層の抜き差し」
　　完成間近のビルを「やっぱり地下室を作って」と言われて基礎から壊すような絶望感。

　・「モチベーションの破壊」
　　苦労して書いたコード、テストした成果物が一瞬でゴミになる精神的ダメージ。

　・「ドミノ倒し的なバグの誘発」
　　急な修正により、関係ない別の場所に未知のバグ（デグレード）が埋め込まれるリスク。

(3)「手戻り」の発生メカニズム

　・要件定義の甘さ
　　「言った・言わない」のコミュニケーションギャップ。

　・見切り発車
　　仕様が確定していないのに、納期に間に合わせるために開発をスタートしてしまう構造的欠陥。

　・認知のズレ
　　発注側が「動くもの（プロトタイプ）」を見て初めて「思っていたのと違う」と気づくタイムラグ。

【関連記事】

☆IT現場の生態系

☆プロマネの生きる道

☆プロジェクトマネジメントの小径

書籍の紹介

・プロジェクトマネジメント知識体系ガイド
　（PMBOKガイド）第7版 Kindle版
　＋プロジェクトマネジメント標準: PMI日本支部 監訳
　プロジェクトマネジメント協会（PMI） (著)
　一般社団法人 PMI日本支部 (2023/1/6)
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・図解即戦力　PMBOK第7版の知識と手法がこれ1冊でしっかりわかる教科書 Kindle版
　前⽥ 和哉 (著)
　 技術評論社 (2024/9/20)
　プロジェクトマネジメントの世界標準として知られるPMBOK Guide 第7版の解説書です。「プロジェクトの基本」「価値実現システム」「12の原理・原則」などプロジェクトマネジメントの基礎となる知識のほか、PMBOK第7版のメインテーマともいえる「8つのパフォーマンス領域」について、要点をくわしく解説します。プロジェクトマネジメントの勉強のほか、PMP試験対策の第一歩としてもおすすめできる1冊です。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・図解入門よくわかる 最新PMBOK第6版の基本 Kindle版
　鈴木安而 (著)
　‎ 秀和システム (2018/3/23)
　PMBOKガイドは、米国プロジェクトマネジメント協会により、日本語を含め世界11ヶ国語に翻訳・出版されています。翻訳されても、専門用語が多い、カタカナ用語が多いなどの理由からなかなか理解が困難です。本書は、『PIMBOKガイド第6版』の翻訳・監訳チーム・リーダーでもある著者が、本来の意味をなるべくかみ砕いて解説します。イメージしやすいよう図版を豊富に使っているので、初心者からベテランまでわかりやすくなっています。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・プロジェクトマネジメントの基本がこれ1冊でしっかり身につく本 Kindle版
　前田和哉【著】
　技術評論社（2022/06）
　本書は、プロジェクトマネジメントについて基本から学ぶことのできる入門書です。プロジェクトマネジメントの基礎知識について解説した後、プロジェクトを「立ち上げ」「計画」「実行」「監視・コントロール」「完了」という5つの段階に分け、各段階において実施すべきこと、注意すべきポイントについて丁寧に解説しています。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-