あなたは今の建設プロセスに満足できているだろうか？
決まらない要件や何度も繰り返される修正。
クリエイティブな仕事だと思っていたのに、いつしか作業に追われる日々…そんな経験をしていないだろうか？
適切な作業や検討期間、客先・プロジェクトメンバーの一体感、明確な分業、確立されたノウハウ。このような条件が揃っている建設プロジェクトは少ないはず。
もし、揃わない条件の中でもパフォーマンスを発揮できる建設プロセスがあったら…
そんな希望を抱きながら、現代だからこそできる新たな建設プロセスについて検討してみようと思う。
目的
成長産業かつ新しいIT分野の開発プロセスを建設プロジェクトに応用し、効率化や新たな手法の模索を行うことで、下記の効果を期待する。
【生産性の向上】
アジャイル開発のプロセスを整理・導入し、建設プロジェクトの効率化を目指す。
【柔軟性の確保】
計画段階での変更や予期せぬ事態に対し、より柔軟に対応できるプロセスを構築する。
【継続的改善の導入】
プロジェクト終了後も得られた知見やノウハウを組織内に蓄積し、次のプロジェクトに活かす基盤を形成する。
背景・課題
建設業界は古くからの建設プロセスが主流でDX化が遅れており、以下のような課題が見られる。
【情報の断片化と共有不足】
企画、設計、施工の各段階における情報やノウハウが十分に連携されておらず、部門間・担当者間で共有されないまま業務が進められる。
【プロセスの硬直化】
建設プロセスはウォーターフォール型の側面が強く、手戻りや変更に対する対応が遅れがちになる。
【品質とノウハウの属人化】
人材不足や後継者不在が進行する中、個人の知識や経験に業務品質が依存し、業界全体の品質低下やミス、知識不足が顕著に現れる。
整理手法
下記の内容で検討を行う。
【開発プロセスの調査】
ウォーターフォール開発とアジャイル開発の基本原則、メリット・デメリットを整理する。
【建設プロセスと開発プロセスの比較】
建設プロセスにおけるステージ（企画、設計（基本設計・実施設計）、施工、維持管理）の各段階を明確にした上で開発プロセスと比較する。
【建設プロジェクト×アジャイル開発の可能性整理】
両者のプロセスを比較し、建設プロジェクトのどの段階にどの手法を適用できるか、また両者を組み合わせたハイブリッド型の可能性について検討する。
整理結果
開発プロセスの調査
まずは、簡単にアジャイル開発とウォーターフォール開発の手法について整理する。
アジャイル開発とは？
アジャイル開発は１回の開発期間（イテレーションやスプリントと呼ぶ）を短く設定した、繰り返し型の開発手法で、優先順位に基づいて動くソフトウェアを徐々に成長させていくという特徴がある。
• 変化への柔軟な対応: 短いサイクルで開発とテストを繰り返すため、途中で仕様変更や顧客からのフィードバックに柔軟に対応できる。
• リスクの早期発見: 小さな単位でテストを行うため、問題点を早期に発見し、修正することができる。
• 顧客との密な連携: 開発の各段階で顧客とコミュニケーションを取り、要求とのズレを最小限に抑えられる。
• 全体像の把握が困難: 全体の計画を厳密に立てないため、プロジェクトの進捗やゴールが見えにくくなる場合がある。
• ドキュメントが不足しがち: 開発を重視するため、詳細な設計書やドキュメントの作成が後回しになるリスクが高い。
• チームの成熟度が必要: チームメンバーが自律的に動くことが求められるため、経験やコミュニケーション能力が重要になる。
ウォーターフォール開発とは？
ウォーターフォールでは最初にすべての要求を定義し、設計、実装、テストと順に開発する。そのため、動くものが確認できるのは開発の最後である特徴がある。
• 全体像の把握が容易: 事前に綿密な計画を立てるため、プロジェクト全体のスケジュール、コスト、ゴールが明確になる。
• 進捗管理がしやすい: 各フェーズの完了が明確なため、プロジェクトの進捗状況を管理しやすくなる。
• ドキュメントが充実: 各フェーズで詳細なドキュメントを作成するため、引き継ぎや保守が容易になる。
• 変化への対応が難しい: 途中で仕様変更が発生した場合、前のフェーズに戻る必要があり、コストやスケジュールに大きな影響が出る。
• リスクの発見が遅れる: 最後のテストフェーズで問題が発覚すると、手戻りが非常に大きくなる。
• 開発期間が長期化しやすい: 全体計画を終えてからでないと次の工程に進めないため、開発期間が長くなる傾向がある。
建設プロセスと開発プロセスの比較
建設プロセスはどちらかと言えば、ウォーターフォール型のプロセスに近いと思われる。アジャイル型のソフトウェア開発プロセスと並べて比較できるよう、各ステージの結びつけを行う。
全体プロセスは結びつけができそうだが、ソフトウェアと建築物（構造物）では、現存するか・しないか大きな違いが存在する。
ソフトウェアのバージョンアップや複製に比べて、建築物は改修工事時の条件（利用や工事の時間）が厳しいと考えられる。
どちらにおいても多くのコストがかかることやメンテナンスで利用できない期間が存在するが、特に建設プロセスにおいては、工事期間中の対応や確認申請への対応の観点から建築物の増改築を頻繁に行うのは現実的ではないだろう。そこで、BIMモデルによる仮想の建築物をソフトウェア開発における第一リリースとして定義してみる。
アジャイル開発の特徴と建設プロセスでの定義
アジャイル開発の特徴（「アジャイルプロジェクト実践ガイドブック」 【IPA 独立行政法人 情報処理推進機構】）を建設プロセスに定義してみると下記のように考えることができる。
◼️成果物を素早くリリースする
成果物＝建築物→BIMモデルに置き換える
各ステージでの成果物は設計図書やパース等に置き換えることはできるが、今回は建設プロセス全体の成果物である「仮想建築物（BIMモデル）」を定義する。
建築士の標準業務については、①「建築士標準業務」の整理を参照。
◼️ニーズに合わせて変更を加えやすい
ニーズの確認→適正な対象者
ニーズに合わせた変更を行うためにまずは、対象者の特定が必要だ。ここでは、建物の用途をベースにニーズの定義づけと意見の集約しやすさを整理しておく。
◼️予測不可能な問題に対処し続ける
予測不可能な問題→実際の建築物≒BIMモデル
ソフトウェア開発のリリースが開発対象そのものを実際に運用するのに対して、BIMモデルは実際の建築物と全てを同一条件にすることは困難である。存在することで周辺に与える影響、雨・風・気温の環境変化、材料の劣化等、シュミレーションにより高度化はしていくだろうが、完全にはならないだろう。
一方、設計が進んで発覚する不整合や意思の相違、利用の際に感じる使用感等、BIMモデルでも事前に把握できるものも多く存在する。予測不可能な問題への対処は、モデル空間という限られた条件下での対応となることが前提となるだろう。
建設プロジェクト×アジャイル開発の可能性整理
実際の建築物の代わりにBIMモデルを活用することで、設計上の問題点や利用上の課題を把握することができると考えられる。下記の手順を循環させることでアジャイル型の開発の利点を取り込めるようになるだろう。
BIMモデルの作成
スプリントを重ねてブラッシュアップ
BIMモデルを作成し、次ステージである②③の内容を踏まえてブラッシュアップを重ねる。全体工程を踏まえて意思決定や並行作業に必要なモデル作成のフローやブラッシュアップ要素はさらに詳細な検討をしていくことで効果が大きくなるだろう。
特に確認申請の前後で変更可能な範囲が決まっているとスムーズだろう。（ただし、計画変更の手続きを前提とするれば柔軟性の向上は可能。）
ニーズを捉える（トライアル）
トライアル方法や期間
ニーズを捉えるには、対象者の選定も不可欠である。実際の建築物が利用される条件とより近い環境を仮想空間で再現する必要がある。見た目のイメージのみにとらわれず、動線や作業を明確化し、時間軸の概念も入れる必要があるだろう。③を見据えた観点での実施方法や期間の検討が必要だ。
フィードバック
意見の収集や分析手法
フィードバックについても実際の建築物ができてから発生するものと仮想空間における課題や予想を区分する必要があるだろう。意見の収集の手法においては、今までの建設プロセスとは異なり、BIMモデルであることを強みにデータ上での集約や整理をすることで強みを活かす手法が構築できると考える。ここの段階の情報を①に反映することでより洗練された設計・モデルができるだろう。
各々のフェーズでさらに深掘りや検討が必要だ。
まとめ
アジャイル開発は「短いサイクルで改善を繰り返す」という点が最大の特徴だ。
建設業界にそのまま当てはめるのは難しい部分もあるが、BIMモデルを活用して仮想的に試行錯誤を繰り返すことで、アジャイル開発の良さを取り込むことは十分可能だと考えられる。
これにより、
・設計段階での課題を早めに発見できる
・利用者の声を反映しやすくなる
・プロジェクト全体の柔軟性が増す
といった効果が期待できる。
建設プロセスにアジャイル開発の視点を取り入れるには、更なる深掘りや検討が必要だが、より効率的で利用者に寄り添った新しい建築物づくりの可能性として視野にいれることができるだろう。
ひとりごと
私は今回の検討をするにあたりアジャイル開発について調査をしていく中で、アジャイル開発の本質的な部分は分野問わず、さまざまな場面で有効だと知った。
ウォーターフォール開発の後に生まれたアジャイル開発だが、どちらにも長所短所があり単純比較できるものではないようだ。
また、アジャイル開発はただ単に短いサイクルで開発して、変化に合わせる手法という認識だったが、チームの自発性や対話を重要視する姿勢等の思想が込められているようだ。まだまだ奥は深い。
コメント