実装2週間・要件定義4ヶ月。AI時代の開発で痛感した「上流工程の価値」
はじめに
この記事では、AWS × dbt × Snowflake を用いたデータ基盤構築プロジェクトで、
要件定義〜設計に4ヶ月、実装はわずか2週間 という、
「いやバランスおかしくない？」という経験から得た学びをまとめています。
技術的なTipsよりも、
上流工程の価値・設計の大切さ・AI時代のエンジニアとして必要な力
といった“働き方”にフォーカスした内容です。
実装フェーズはAI（ChatGPT / Codex）が爆速で進めてくれた一方で、
上流工程はというと……
「ちょっと会話しませんか？」と言っていたはずが、気づけば4ヶ月経っていました。
その経験を通して、
「プロジェクトって、コードを書く前にほぼ決まってるんだな」
という当たり前だけど重要な事実を痛感しました。
1. プロジェクトの概要
今回のプロジェクトでは、AWS・dbt・Snowflake をベースにしたデータ基盤の設計・実装を担当しました。
役割としては、
- 要件定義
- 基本設計
- 詳細設計
- 実装（コード生成はAIを併用）
- UT作成
- ジョブ実行・構成管理
まで一気通貫で関わりました。
ここでは技術の細部よりも、
「なぜ実装よりも上流工程に時間がかかったのか」
という気づきを中心にお話しします。
2. 上流工程が想像以上に難しかった理由
今回のプロジェクトでは、要件定義〜設計に4ヶ月以上を費やし、
実装は2週間で終了しました。
数字だけ見ると、
「実装サボってた？」と言われそうですが、
むしろ逆で、上流がハードモードすぎた のが正直なところでした。
● 認識のズレ：一度決まった方針が覆ることがある
週次の会議ごとに前提が変わったり、
関係者によって解釈が違ったりする。
象徴的だったのは、
スケジュールの都合で見送りになっていた OTF採用の方針が再度ひっくり返った瞬間。
「え、また戻るの？ さっき諦めたばかりでは？」
とPCの前で静かにツッコミましたが、
上流工程ではこういう“前提の揺れ”は日常茶飯事です。
● 情報のズレ：資料はあるのに“真実”がない
資料はあるけれど、どれが最新かわからない。
むしろ、古い資料の方が正しい という逆転現象まで起きていました。
まさに
「地図はあるのに、どれも現在地を指していない」
という状態。
参画後はまず資料の構造化・最新化を行い、
「とりあえずここを見れば正しい」という場所を作るところから始めました。
上流工程では 「正しい情報がどこにあるか？」 を整えるだけでも、プロジェクトは前に進みます。
● 距離のズレ：複数チーム間の心理的・物理的距離
業務・アーキ・インフラ・運用など複数チームが関われば、
意思決定のラグや認識ズレが発生するのは避けられません。
必要な時期には最密チームと毎日ショートミーティングを実施し、
“距離を縮める工夫” をして乗り越えました。
● 気づいたこと
要件定義・設計フェーズの難しさは、コード以上に
認識・情報・距離を整える「コミュニケーションの量」で決まる。
その重要性を改めて痛感しました。
3. 設計書で最も意識したのは「誰のためのドキュメントか？」
● 基本設計：顧客の認識を揃えることが目的
基本設計では、抽象度を上げつつ、顧客が本当に知りたい
- なにができるのか
- どんなメリットがあるのか
- 運用はどう変わるのか
を重視しました。
技術の細部まで踏み込むより、
「これで進めて問題ないですか？」
を確認するフェーズという意識でした。
● 詳細設計：「この情報だけで実装できるか？」
開発者が迷わないように、
- 前提条件
- 例外ケース
- 処理の流れ（図＋文章）
- 具体的な入出力例
を徹底的に明確化しました。
常に
「自分が実装者なら、これで作れるか？」
と問いかけながら書き進めました。
これは後述の “AI実装” にも非常に効きました。
4. ChatGPTが最も活躍したのは“実装フェーズ”
今回のプロジェクトで一番感動したのは、
UT（単体テスト）実装の効率化 でした。
従来の感覚では、
- 実装：1
- UT：3
くらいの工数でしたが、今回は
体感1/10くらい になりました。
● コメントで意図を伝える → AIが爆速でテストを書く
AIに渡す前に関数を1責務に分割し、
コメントブロックで「この関数で何をしたいか」だけ明確にしておく。
こうするとChatGPTはまるで
「わかってますよ、こういうのが欲しいんですよね？」
と言わんばかりにUTを生成してくれます。
逆に曖昧な要件を渡すと、
「全部盛りにしておきました！！」
みたいな巨大 main 関数が爆誕するので注意です。
● テストコードの改修がほぼゼロに
仕様変更やリファクタが入っても、
差分だけ伝えればAIがUTも一緒に直してくれました。
実装 → AIがUT修正 → 次へ進む
この流れは、純粋に「未来だな」と感じました。
5. 自分の強みは「曖昧さを整理して、前に進めること」
今回のプロジェクトで強く感じたのは、
自分は “カオスを整理して前へ進める” 役割が得意だということ。
- 要件の整理
- 不明点の言語化
- チーム間の橋渡し
- 議論がループしている部分の構造化
こうした地味だけど重要な部分で、
プロジェクトを確実に前へ動かせる瞬間が何度もありました。
技術力とは別の価値があることを、改めて実感しました。
6. おわりに：上流工程には、間違いなく“価値”がある
今回の経験で強く思ったのは、
上流工程はエンジニアの市場価値を押し上げるフェーズ だということ。
要件を整理し、認識を揃え、曖昧さをなくし、
実装可能な形にまで落とし込む。
実装はAIが加速してくれる。
だからこそ、
「実装の前の考える時間」こそが、人間の価値になる。
もちろん上流工程は難しいです。
「これ本当に終わるの？」と思った日もあります。
でも、その難しさの向こう側に、
実装では味わえない面白さがありました。
この記事が、
誰かが上流に挑戦するきっかけになれば嬉しいです。