住宅建築とソフトウェア開発における問題点の考察
私ごとですが、実は戸建てを購入しました。
建売ではなく、間取りや外装は自分で決められる、いわゆる半注文住宅というやつです。とても楽しみにしていたのですが、実は引っ越した今も補修工事が続いています。
その原因が、私が日々携わっているソフトウェア開発で起きがちな問題とあまりに似ていたので、考察を書きたいと思います。
※特定のハウスメーカーや大工さんを責める記事ではありません。プロセスや関係性に着目して問題提起する記事です。
長いですがぜひ多くの人に読んでもらえると嬉しいです。
事実の振り返り
まずは起こった事柄を時系列に並べます。
・11月5日 設計図FIX＆請負契約締結
・11月30日 施工着手
↑
この間、現場監督と大工さんとはコミュニケーション取らず
↓
・3月3日 中間確認
▼確認観点・窓の取り付け
・間取りの確認
▼実際
・壁や階段がまだついておらず、間取りは確認できず
・とりあえず窓の取り付けだけ確認する
・現場監督の方にスケジュールを確認。問題ないと言われる。
・4月12日 内覧会
▼確認観点
・清掃済みの状態。これでもう引き渡して問題ないかどうか
▼実際・床には木屑、工事の道具が転がっている
・階段やフローリングには傷や隙間がある
・窓台と巾木の色が設計と違うことが発覚。再度工事をすることに
・天井にシーリングファンを取り付けたいと設計士さんに話していたことが現場に伝わっておらず、天井の補強工事がされていない。
・実は最終の補修工事が終わっていない。異例だが引き渡し後の4月23日に再度確認をしてほしいと言われる
・現場監督の方にスケジュールを確認。引っ越し業者を4/26に依頼しているので難しければ言ってほしいと言う。問題ないと言われる
・4月22日 物件の引き渡し（実際には引き渡せないが形式上鍵だけ受け取る。）
・4月23日 最終工事の確認
▼確認観点
・補修工事＆清掃済みの状態。これで引き渡して問題ないかどうか
▼実際
・床には依然として木屑がある
・以前指摘した階段やフローリングの傷は修正されていない
・窓台と巾木の色に変更が入ったため、壁紙を二重で貼られており、仕上がりもまちまち
・あまりの修正できてなさに現場監督の方に「あなたは確認していたんですか？」と聞くと「確認できてないです」と返答
・窓台と巾木の壁紙の施工の雑さを確認すると、「5人の業者を入れて1日で修正した。施工手法などについては特に指定してない」
・設計図通りに外のポストが設置されていなかった。木を植えようとしたため、あえて右にずらして設計してもらっていたが、大工さんが気を利かせて真ん中に設置していた。
・人生で初めて「上司を呼んでください」と言う。後日改めて話すことに。
・4月26日 引っ越し（ダンボールはほぼ開けられず）
・5月1日 現場監督の方と上司が説明に来る
▼説明内容
・今後の補修工事の方針・原因の説明
▼判明した事実
・現場監督の方は他にも数件現場を抱えていた
・週2〜3日は現場には顔を出していた
・上司も週次で進捗は聞いていた
問題点1 職能ごとに組織を分け、職能を超えたコミュニケーションが不足している
本来であれば「顧客の要望を叶える家を建てて、住環境を改善する」が大きな目的としてある訳ですが、今回問題のハウスメーカーでは組織また工程を職能ごとに分けたことで下記のような限定合理性が発生しました。
⑴営業: 一番高いプランで契約する
⑵設計士: 一番高いプランで設計する。設計書を早くFIXさせ現場監督に渡す
⑶現場監督: 納期までに設計書通りの建築を終わらせる
⑷大工・職人: 現場監督の言われた通りのことをやる
皆が自分の仕事を全うしているはずなのに、誰も幸せにならないこの惨劇。
このような組織や工程ではコミュニケーションや中間成果物で、情報の非対称性が発生しないようにしなければいけません。そうしなければ、視界の統一ができず、目的からずれて手戻りが大きくなってしまうからです。
今回、情報の非対称性が生まれていたのは、設計士に伝えた要件が漏れていたことでも明らかでした。目的からずれたしわ寄せは当然のように最終工程に回ってきます。前工程の中間成果物やコミュニケーションの不足が原因なのに。
問題点2 実現工程でコミュニケーションを取る仕組みがない
設計士の方とは対面で約10回の打ち合わせをしてきましたが、現場監督と直接話したのは3回しかありませんでした。
家の様子を週に1度は見に行っていたのですが、大工さんに差し入れなどはしないでくださいとハウスメーカーから言われていたので、実際は遠目からチラチラと見るだけでした。
実際に建築すると設計書では分からなかった表現が難しい場所や、設計意図がわからない場所は当然出てきます。そのときコミュニケーション取る仕組みがなければ、設計書通りに受け入れるしかありません。
例えるならデザインファイルを見ながら、プロダクトオーナーと話さずソフトウェア開発をしている状態と言ったら伝わりやすいでしょうか？
ソフトウェア開発の失敗事例としては、先日こちらにも書きました。
「チームではなくなった」半年開発しているリニューアルで失敗したこと
上記の記事から一部抜粋します。
外部のデザイナーの方にワイヤーとデザインを起こしてデザインファイルを納品してもらい、それを元にエンジニアが開発するというフローでした。実際開発する段階になって、実現が難しい表現や工数がかかる機能が出てきました。しかし、外部のデザイナーさんはすでにおらず、要件を詰めたメンバーも中途半端な状態で別のプロジェクトに移動してしまいました。〜 中略 〜要件や表現を考えるときは、いわば制約のない理想論を語ることができます。ただエンジニアが対峙するのは現実です。私はどちらも大切で、両方を行き来しながら一つの価値を作るのがコストパフォーマンスが良い機能を作れると考えています。その行き来する仕組みがなかったため、エンジニアはデザインファイルを受け入れるしかなく、結果論としてコストパフォーマンスの悪い機能を作ってしまいました。
気を利かせてくれてポストを真ん中に立ててくれた大工さんも「今後木を植える」という要件を伝えていたら、お互い苦い思いをしないで済んだはずです。
問題点3 設計書頼みに建築する
建築の契約を交わすときに、「設計書の内容を期日通りに建築する」というような契約書にサインしますが、果たして一番目的を達成するためにいいのでしょうか？
漏れていた「窓枠と巾木の色を変える」要件ですが、分厚い設計書の中のあるページの右下の方に一文で書かれていただけでした。また設計書にはそこに至るまでに話された議論や経緯は全く書かれていません。
果たしてこの分厚い設計書を見ながら正確にかつ納期通りに建築が終わらせられる確率ってどれくらいなのでしょうか？
「要件漏れや認識違いは出る（人間だもの）」の前提で、いかにそれを小さくするか？早く見つけるか？にフォーカスした方が生産的だと思います。
例えば
・要件を設計書と一緒に渡す（目的不確実性を減らして手戻りを小さくする）
・設計段階で現場監督を立ち会わせる（実現可能性の確認）
・設計士を現場に立ち会わせる（現場に設計意図を伝える）
・発注者に進捗や成果物を共有する会議を週次で設定する（認識違いを早く見つける）
などです。
工数をかけてFIXした設計書（デザインファイル）はどれだけ不確実性を下げるのに役立っているのでしょうか？
問題点4 上司の責務が不明瞭
今回は現場監督の過剰な稼働を認識していたのに、何も対応策を打たなかった上司に問題があると思います。上司ってなんのためにいるのでしょうか？
「頭を下げるために高い給料をもらっている人」なのでしょうか？であれば私はそんな人にお金を払いたくありません。
であれば徹夜させてでも納期に間に合わせるよう指示するのが上司なのでしょうか？それではせっかく投資して育てた部下が潰れてしまうかもしれません。
最近は上司という概念は不要で、顧客と事業の成功だけを考え行動する役割が必要なのではないかと思うようになりました。いわゆるリーダーです。でリーダーは役割であって役職ではないので、誰がやってもいい。そんな組織だと素敵です。
上司というよく分からない仕事をしている人に対して責務を明文化するところから始めたいと思います。
以上です。最後まで読んでいただき、ありがとうございました！