IT業界から学ぶ、建設プロジェクトの共通認識（1）
2026.01.20
ArchiFuture's Eye 竹中工務店 山崎裕昭
前回のコラムでは、リーンコンストラクションについてお話ししました。実は、私がその可能
性に気づけたのは、全く別の業界での経験があったからです。今回は、その経験についてお話
しします。その業界とはIT業界です。これまでに書いてきた『プロジェクトの共通認識を築く』
という考え方に至った背景には、実はシステム開発での経験が大きく影響していたからです。
私は、５年半前に本社に来てから、BIM関連のシステム開発に、発注側の人間として携わり始
めました。当時の私は、作業所で長く仕事をしてきたので、専門工事会社への発注業務はして
いましたが、それらは自分の専門領域でもありますし、お客さんからいただいた仕事として専
門工事会社へ発注をしていました。しかし、今回は、自分自身がリーダーとなってシステム開
発を発注することになったのです。いわば、何も建設プロジェクトのことを知らない人間が、
突然建設プロジェクトでの発注者側の立場になった状態でした。
実際の開発プロセス
開発を始めた当初、私は全く知識がなかったので、周りで行われていた方法と同様のウォー
ターフォール開発という方法で開発を進めていきました。ウォーターフォール（Waterfall）が
日本語で「滝」を意味するように、川上から川下へ逆流せずに流れていく開発手法で、この開
発方法は、建設プロジェクトの流れと非常に似ています。
1. 要件定義：どんなシステムが欲しいか決める（建設：どんな建物にするか決める）
2. 設計：画面デザインやデータ構造を決める（建設：設計図や製作図の作成）
3. 開発：実際にプログラムを書く（建設：実際の建設作業）
4. テスト：きちんと動くか確認する（建設：検査）
5. 納品・運用保守：ローンチ、維持管理（建設：竣工・維持管理）
一般的には、メリットとして、計画が立てやすいことや大人数での作業に向いていること、
また、デメリットとしては、後戻りができないこと、変更に弱いことなどが言われています。
私が携わった開発の一つでは、おおよそ8ヶ月の期間をかけました。
体験したつまずき
そして、その開発プロセスの中でいくつかのつまずきを体験しました。開発プロセスの時系列
に沿って紹介します。
つまずき①：最新じゃなくなる問題
要件定義が終わって、開発を始める時に新しい技術やフレームワークが登場し、「今作ってい
るものが完成する頃には古くなっているのでは？」という不安を感じました。これは建設プロ
ジェクトでいえば、「最近、新しい設備機器が出たので、部分的にでも導入したい」という状
況に似ていると思います。
つまずき②：要望・要求の膨張
そして、開発が進むにつれ、「こういう機能も追加したい」「ここはこう変更したい」という
要望が次々と出てきました。建設プロジェクトでは、総合定例の後に現地を巡回する際に「現
地で壁の下地が建ったら、思ったより狭いので広くしたい」と言われる状況と似ています。
つまずき③：イメージとの違い
8ヶ月後にプロダクトが納品された時、「しっかり要件定義もして、定期的に打合せでも確認し
たはずなのに、『表示速度』や『操作感』は求めていたものとは少し違うな」と感じたのです。
画面が表示されるまでに数秒かかることは確認していましたが、実際に業務で使ってみると、
その『待ち時間』が作業の流れを止めてしまうことに初めて気づきました。
建設プロジェクトに関わる方なら、下記のような似た経験があるのではないでしょうか？
「発注者の要件も聞いて、設計図書もしっかり作って承認をもらっていたはずなのに、竣工検
査時に、エントランスの壁がイメージと違う、と言われた」
建設業界とIT業界の類似性
これらの経験を通じて、私はある仮説を持ち始めました。建設業とIT業は、抱えている課題の
構造が非常に似ているのではないか。そして、IT業界から学べることがあるのではないか、と。
発注者、元請け、下請け構造、現場作業者の要素で比較したものが下記の図になります。
この表から分かりますように、IT業界と建設業界は社会構造だけでなく、それぞれが抱える問
題も共通しています。
この類似性は、時に深刻な問題を引き起こします。近年、システム開発を委託した企業が、完
成したシステムが要件を満たしていないとして、開発ベンダーとトラブルになっている事例が
複数報じられています。しかし、「しっかり要件定義したはずなのに」「定期的に確認してい
たはずなのに」—これは建設プロジェクトでもよく耳にする言葉ではないでしょうか。
この類似性に気づいたことは、私にとって大きな転機でした。なぜなら、IT業界が直面してい
る課題と、その解決策を学ぶことが、建設業界にも応用できる可能性があると感じたからです。
特に、「どうすれば関係者全員が同じイメージを持ち続けられるのか」「変化にどう対応する
か」という点は、これまでのリーンコンストラクションに関するコラムで触れた「プロジェク
トの共通認識」の問題そのものでした。
アジャイルソフトウェア開発との出会い
そんな時に私が出会ったのが、アジャイルソフトウェア開発です。これは、まさに私が北欧で
感じた「共通認識を深める」プロセスと通じるものでした。「実は時系列でいうと、アジャイ
ルソフトウェア開発との出会いは、リーンコンストラクションに触れる前でした。BIMモデル
の活用に悩んでいた私は、偶然出会ったアジャイルソフトウェア開発の考え方に可能性を感じ、
勉強と実践を始めました。
次回のコラムでは、アジャイルソフトウェア開発の特徴などに触れながら、建設プロジェクト
で共通認識を深めることについて考えてみたいと思います。
