【連載】BIMコンサルへ提案依頼するための必須項目 |（第1回）発注時の5原則・前編

ゼネコンや建材メーカーなどのBIM推進やデジタル推進の担当者は、BIMや関連システムを導入するにあたり、BIMコンサルに何を伝えればよいか分からなくてお悩みの方がいるでしょう。

こうしたお悩みに対し、BIMコンサルの藤井 章弘氏が連載企画「BIMコンサルへ提案依頼するための必須項目」でお答えします。

連載第1回目は「発注時の5原則」です。BIM導入や社内に蓄積されたBIMデータの有効活用する方法などをBIMコンサルに相談したい方は、ぜひ参考にしてみてください。

他の連載記事はこちら

▼連載2回目：【連載】発注時の5原則・後編（第2回）

▼連載3回目：【連載】プロジェクトが止まる依頼事例（第3回）

▼連載4回目：【連載】プロジェクトに必要なチームビルディングのポイント（第4回）

▼連載5回目：【連載】RFPに記載すべき17の内容とポイント（第5回）

【原則1】最優先すべきは「課題の明確化」

BIMコンサルに依頼するときに最も重要なことは、「課題が何であるか」を明確にすることです。

当社にはゼネコンのBIM推進室、デジタル推進室や建築資材メーカー、建築事務所などの設計者といった立場の方々から、BIM設計やBIM周辺技術の開発、設計者が作成したBIMデータの活用方法など様々な依頼が来ます。

短期間で技術が進化する昨今の背景から、WebアプリケーションやRevit用プラグインの開発など、先端技術ありきの依頼も少なくありません。

しかし、先端技術の活用を検討するより先に「現状の課題が何か」を明確にすることが重要だと思います。

もちろん当社からもお客様が抱える課題解決に最適な技術を提案することができます。けど、当社からの提案が果たしてお客様企業が抱える課題の根本的な解決になるのか、わからない領域があります。

根本的な課題解決のためにも、BIMコンサルに依頼する前に「解決したい課題」や依頼するシステムが「誰が」「何のために使うか」、もしくは「開発したシステムの位置付け」を明確化することが不可欠だと考えています。

【原則2】課題に飛び込む「マインド」

依頼前に課題を明確化できていることが理想です。しかし、課題の種さえあれば、解像度が低くても我々にアプローチしていただく段階では問題ありません。課題が議論の中で見つかるケースもあるからです。

大事なことは、「課題が何であるか」「どうすれば課題を解決できるか」と、課題に取り組む姿勢を共に持てるかどうかです。

お客様の中には、依頼後は我々にシステムに実装する機能や仕様、運用方法の決定を完全に丸投げしてしまう方もいます。

それでも、ある一定はお客様の要望を満たすシステムを納品できます。しかし、実装する機能や運用方法などを一緒に議論したうえで、システム開発をした方がより良いものが納品できたのではないか感じることもあります。

当社に来る依頼は、先端技術を活用した挑戦的な取り組みや大企業の案件も少なくありません。特に大企業は有効活用できるデータを豊富に持っていて、これらを基にソリューションの提供やデータ整理、開発ロジックを考えたりします。

私の経験から、お客様の中に、社内で蓄積されたデータの活用方法を我々と一緒に考えてくださる方が1人でもいると、良いシステムが作れる可能性が高くなります。

より良いシステムを作るためにも、発注者側もBIMコンサルと一緒に「課題に飛び込むマインド」を持つことが大切だと思います。

【原則3】開発プロセスの基礎知識を取得

発注者側が、開発プロセスの基礎知識を取得しておくことも重要です。

一般的にシステム開発ではRFP（※1）の内容に基づき、契約を締結しスコープ（※2）を定義します。

我々はこれらに基づき、事前にお客様に具体的な開発プロセスを説明しますが、発注者側も理解しておくとプロジェクトの進行がスムーズに進むと思うことがあります。

RFPありきで要件定義、設計、実装、テスト、リリース、運用保守という流れが一般的な開発プロセスではあるものの、実際にリリース後の運用保守を考えて依頼する発注者は少ないです。

我々がシステム納品後の運用保守まで担当するケースもありますが、本稼働後の運用保守は発注者側が担当しなければならないこともあります。

我々は納品後の運用保守を視野に入れて技術スタック（※3）を選択します。
発注者側が幅広い視野で各フェーズにおいて具体的に何をするか理解しておくと話がスムーズに進むでしょう。

RFPに基づき基本契約を締結しスコープを定義したうえで、要件定義をいったん決めて、そこから各フェーズで詳細を詰めていくやり方が理想です。

しかし、実際に要件定義なしで開発が丸投げしてくる方や、手続きが煩雑であるがゆえに1回の打ち合わせで決まった大まかな概算で人月単価を見積もりせざるを得ない大企業もいます。

要件定義や人的単価の概算が曖昧なままプロジェクトが進むと、我々もしくは発注者側に人的リソースや予算などの面で負荷がかかります。

こうしたトラブルを防ぐためにも、依頼する際にプログラムなどの成果物に対して費用を払う請負契約か、作業に対して支払う委任（準委任）契約なのかを発注者側で知っておくことも重要だと考えます。

開発フェーズや契約形態などのシステム開発の基礎知識を抑えておくと、開発期間が短縮によるコスト削減が実現でき、発注者と開発者の認識のズレも減るので品質の高いシステムを担保できます。

注釈

※1：RFP（提案依頼書）

システム開発やWebサイト制作を専門業者に依頼する際に発注側の開発意図を適切に伝える提案依頼書。開発の目的、ゴール、予算、希望納期などを記載。

※2：スコープ

プロジェクトで作るシステムやサービス、文章などの成果物と成果物を作るための品質、費用、納期、人員などを定義したもの。

※3：技術スタック

1つのアプリケーションを構築・実行するのに使用されるプログラム言語、フレームワーク、ライブラリ、ツールを組み合わせたもの。

まとめ

前編では発注時の5原則のうち「課題の明確化」「マインド」「基礎知識」の3つが必要な理由をお伝えしました。
後編では「チーム体制」「スケジュール」が重要な理由を解説します。