本コラムの前回で、システム開発における人月ベースの見積もり問題を取り上げたように、建設業界とIT業界との相似点は多い。今回は建築の話になるが、重要となるポイントはやはり共通である。
長く建設業で仕事をしていた筆者は、建築に関わる相談事を受けることが時々ある。かつての本業は港湾施設の設計など土木が中心だったので建築は専門外だが、構造物を作るのは似ているし、何より建築に興味があったから折に触れて知識を得ていた。相談事の多くは住宅についてである。新築工事や修繕工事、材料や価格、耐震性や工法など、内容は多種多様だ。
住宅にまつわる相談事を聞きながら気づかされるのは、「誰しも専門外のことについてはよく分からない」という現実である。関心や実体験のある人はそれなりの知識を持っているが、情報が溢れるインターネットでも求める答えは容易には見つからないし、確証は得られない。
最近、住宅の外壁防水塗装工事の相談を受けた。マンションでも戸建てでも、屋根や外壁は経年劣化する。建物の機能を維持するためには10年くらいの間隔で補修する必要があるのだが、何度も経験することではないので技術知識がない。するとどうなるか? 補修工事の業者チラシが郵便受けに投げ込まれていたりするが、その業者が信頼に足るのか、あるいは見積りを頼んだが内容が適正なのか、工法は妥当なのか、仕上がりの品質は期待できるのかなど不安になるのだ。
「知ると知らぬ」の差は大きい
材料、工法、工事プロセスの技術知識がないと、業者選択もままならないのは当然である。だから多くの場合、複数の業者から見積りを取る。それぞれの工事計画の話を聞くが、塗料材料や工法を説明されても単価が適正なのか、材料の機能品質レベルが適切なのかは、判断できない。見積りの根拠になる外壁の面積を自ら計算する人もいないから、業者の提出する書類を鵜呑みにするしかない。結局、予算を考えながら、いずれかの業者に丸投げすることになる。
技術知識があるとどうか。複数の業者から見積りを取って工事の説明を受けるところまでは変わりがない。違いが出るのは、見積りや工事内容がわかるので業者と交渉ができることだ。材料を耐久性のよいものに替えてもらったり、概ね数量は多めに見積もっていることが常だが、数量に齟齬があれば修正してもらったり、足場を簡易な工法に替えてもらうなど交渉ができるのである。
この交渉力は業者から見れば、ある意味脅威である。曖昧にしたり恣意的に工事を進めたりすることができない。厄介な顧客ではあるが、きちんと対応せざるをえない。その対応で業者のよしあしの見分けもつく。適度の緊張感があり、工事品質にも影響を及ぼす。
個人的な話になるが、筆者は昨年、自宅を5カ月かけてリノベーションした。リフォームというレベルではなく、鉄筋コンクリートの躯体だけを残し、間取りも含めて全面的な改装工事を行った。3社に見積り引き合いをし、具体的な話を始めた段階で1社が辞退した。2社目はある構造設計に対して「自信がない」と設計途中で降りてしまった。結局、見積りは高めだったが類似工事の実績があり、設計技術者もしっかりしていた3社目に依頼した。
その後も材料の変更や設計の変更、工法の変更などたくさんの交渉を重ね、工事経過の現場チェックも行い、工期どおりに予想以上の出来栄えで完成した。筆者に技術知識がなかったら、工事費用も工期も仕上がりも違っていたはずだ。完工時には、筆者のようなうるさい客に付き合ってくれた工事関係者全員を近所のレストランに招待し、感謝と敬意を伝えた。
建築もシステム開発も、発注者の技術知識が重要
システム開発でも同じことが言えるのではないだろうか? ハードウェアやネットワークを含めてシステム開発に関わる知識の有無で、開発のQ(品質)、C(費用)、D(工期)が変わってくると思う。知識がなければ丸投げせざるをえなくなり、力関係は一方的になる。仕様をきちんと伝えられなければ、成果物に目的との乖離が生じてしまう。手戻りが増えれば費用はかさみ、納期は遅れるし、品質の劣化も当然起こってくる。そうして失敗プロジェクトが累積することになる。
相手と交渉できる知識があれば関係は対等になり、役割分担ができ、適正な見積りで契約し、相互に適度の緊張感も生まれて開発プロジェクトが大きくぶれるようなことはなくなる。システム開発の失敗やトラブルの原因は建設と同様、発注者と受注者の技術知識の非対称性が大きい。その差を埋めていかないと適正な調達は適わない。
そのために建設業界では、発注者の立場になって調達を代行するCM(コンストラクションマネジメント)の仕組みがある。欧米では一般的だが、日本では一部にとどまっている。システム開発に至っては、CMという言葉さえない。であればなおのこと、発注者は技術知識を習得して交渉力を高めなければならない。
そのためには常に技術に関心を持ちリサーチを欠かさず見聞を広め、不明なことは専門家に訊き、テスト開発を実践するなどR&Dも積極的に行い、技術の成熟度や適応性を判断できるようにならねばならない。技術に貪欲になり、目利きになることだ。
- DXを推進するなら「情報システム部門」を根底から見直せ!(2024/10/30)
- 「建設DX」の実態と、厳しさを増す持続可能性(2024/10/02)
- 過剰なハラスメント意識が招く日本の萎縮(2024/08/27)
- 日本の死生観の変化がもたらす将来(2024/08/07)
- 銀行窓口業務の効率化、なぜ今もできない?(2024/06/24)