2026.03.31

ArchiFuture's Eye　　　　　　　　　　　　　　　　　竹中工務店　山崎裕昭

前回のコラムでは、担当したソフトウェア開発で経験した、建設業と似ていると感じた課題と
アジャイルソフトウェア開発の出会いまでを書きました。今回は、アジャイルソフトウェア開
発という考え方が、BIMモデルを活用したプロジェクトマネジメントにも応用できることに気
づいた、その経験について書きたいと思います。
 
「アジャイル」という言葉への誤解
みなさん、「アジャイル」、と聞くとどんなイメージを持ちますか？
 
一般的には「素早く作る」「失敗してもいいからやってみる」などではないでしょうか。そう
いうイメージを持たれている方が多いと思います。
 
しかし、アジャイルの本質は「スピード」や「無計画」ではありません。
 
次のセクションで、アジャイルソフトウェア開発の特徴をもう少し詳しく見ていきましょう。
 
アジャイルソフトウェア開発とは
アジャイルソフトウェア開発は、従来のウォーターフォール型開発の限界を感じたエンジニア
たちが2001年に集まり、新しい開発の在り方を議論して生まれました。その成果が「アジャ
イルソフトウェア開発宣言」です。最初に完璧な計画を立てるのではなく、小さく作って確認
し、フィードバックを受けながら改善を繰り返す―この反復的なアプローチを重視する開発手
法の総称です。

　　※上記の画像、キャプションをクリックすると画像の出典元のWebサイトへリンクします。

アジャイルソフトウェア開発にはいくつかの開発手法があるのですが、具体的な開発手法につ
いてはまた別の機会に考えることにして、今回は「アジャイルソフトウェア開発宣言」につい
て考えてみます。
 
アジャイルソフトウェア開発宣言
 『プロセスやツールよりも個人と対話を、
　包括的なドキュメントよりも動くソフトウェアを、
　契約交渉よりも顧客との協調を、
　計画に従うことよりも変化への対応を、
　価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記の
　ことがらにより価値をおく。』
 
ここで重要な前提条件を述べておきます。『左記のことがら』つまりプロセスやツール、要件
定義書といったドキュメントを軽視するという意味ではないということです。つまり、「要件
定義のドキュメントは一切作らなくて良い」ということではありません。建設プロジェクトと
同じで図面は必要です。
 
私はこのアジャイルソフトウェア開発宣言に出会った時、前回のコラムで書いたウォーター
フォール開発で経験したつまずき、「最新じゃなくなる問題」、「要望・要求の膨張」、「イ
メージとの違い」を改善できるのではないかと直感的に感じました。
変化への対応を受容することで、最新の技術への対応や将来的に対応できる仕組みづくりにも
つながりますし、不完全な状態でもいいので動くソフトウェアを見せてもらうことで、対話を
しながら要望や要求を整理することができ、イメージと違うことも伝えることができます。
 
そして、そのアプローチが「BIMモデルを活用したプロジェクトマネジメント」と共通点が多
いことに気づきました。
 
BIMモデルを活用したプロジェクトマネジメントとの共通点
なぜ私はBIMモデルを活用することとアジャイルソフトウェア開発が共通していると気づいた
のでしょうか？それは、自分自身が作業所でBIMモデルを活用している時に、不完全なBIMモ
デルであっても図面と共に関係者に共有し、認識をすり合わせていく手順を踏んでいたからで
す。BIMモデルを関係者と共有することで、対話が深まり、その結果として共通認識をさらに
深めることができる。その経験があったので、アジャイルソフトウェア開発を選択することに
戸惑いはありませんでした。
 
私は、ウォーターフォール開発で進んでいたものを一旦巻き戻し、アジャイルソフトウェア開
発で開発を進めることにしました。山あり谷ありではありますが、先述した課題を克服しなが
ら進めることができるようになっています。
 
アジャイルソフトウェア開発とBIMモデルを活用したプロジェクトマネジメント
ここで一旦、アジャイルソフトウェア開発宣言に戻ってみます。これを、BIMモデルを活用し
たプロジェクトマネジメントに置き換えてみると、下記のように考えられませんでしょうか？
 
「プロセスやツールよりも個人と対話を」→プロジェクトチーム内での対話を
「包括的なドキュメントよりも動くソフトウェアを」→静的な図面だけではなくより視覚的に
　理解しやすいBIMモデルを
「契約交渉よりも顧客との協調を」→IPDなどの協調型の契約方式を
「計画に従うことよりも変化への対応を」→社会の変化に合わせて、コスト・納期面で対応可
　能な変更への適応を
 
アジャイルソフトウェア開発宣言が示唆しているのは、BIMモデルを活用するだけでは不十分
で、「個人との対話」や「顧客との協調」、「変化への対応」が同時に求められるということ
です。それらを一緒に取り組まずに、社会に価値を届けることはできない、ということだと、
私は考えています。それは、「チームが持つ共通認識を継続的に更新しながら、価値あるもの
を作り上げていく」という、リーンコンストラクションの中でも一つの重要なポイントそのも
のです。
 
アジャイルソフトウェア開発は『動くソフトウェア』を見せるだけではなく、『素早く作る』
『失敗してもいいからやってみる』という単純なアプローチでもありません。
 
同じように、建設プロジェクトも、BIMやデジタルを導入するだけでは上手くいかないのです。
 
最後に
IT業界の人間でもない私が、公の場でアジャイルソフトウェア開発のことについて書くことは、
大変恐れ多いことなのですが、こうやって他業界と建設業の仕組みや文化を掛け合わせていく
ことも、イノベーションの一つではないかなと思います。
 
みなさんも、他産業との掛け合わせで気づいたことがあれば、ぜひご意見をお聞かせいただけ
ればと思います。

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
•