目的：
新国立競技場建設費の見積りが揺れ動く本質を解明します。
見積りの問題点を認識していただきます。
情報システムにおける
見積り精度向上の課題を認識していただきます。
ねらい：
もっと見積りに関心を持っていただきます。
ーーーーーーーーーーーーーーーーーーーーーーーーーーー
新国立競技場の見積りや計画が大幅に揺れ動いています。
８月２８日政府は、
新国立競技場の建設費を１５５０億円と決定したと発表しました。
この直前の見積りから冷房設備をなしにして１００億円を下げた、
ということです。
これで２５２０億円から１０００億円下げたと安倍総理は自慢げでした。
夏の大会で冷房がない？
まあ甲子園の夏の大会でも冷房がないのだから
やってやれないことはないでしょうが。
それはともかく、
分からないのはなぜこんなに見積り額が変わるのかです。
意味や見積り範囲は別として、
以下のように見積り額が動いています。
２０１２／１１ １３００億円 計画
２０１３／１０ ３０００億円 以下見積り
２０１３／１１ １８５２億円
２０１３／１２ １６９９億円
２０１４／０５ １６２５億円
～ ３０００億円
２０１５／０７ ２５２０億円
２０１５／０８ １５５０億円
２０１５／０７の見積りでは、開閉式の屋根をやめたとか、
引き算での説明はされていますが、
そもそもどうなのか、は説明されていません。
見積りをするためには、設計が前提となります。
どういうものを作るかが決まって初めて
その図面を分解して見積りになるのです。
本件の見積りは
ずーっと設計はできていなかった段階のです。
今もできていません。
詳細の設計ができていない段階での見積りは
かなり推定が入ることになります。
その推定の根拠は、類似案件です。
日産スタジアムが６００億円でできたのだから、
それに対して規模がどのくらい違う、
あるいは開閉式天井がつくとかで
足し算・掛け算をして算出します。
その際、まったくの新規技術だと、
あるいはどういうものになるか分からないときは、
リスクを見ます。
安全を見て多めに見積もるのです。
今回の当初の３０００億円の見積りは、
リスクを見た部分が多かったと思われます。
こんな大型案件で工事費が何割も増えたら
会社に重大な損害を与えることになります。
誰だってリスクを多く見ます。
それにしても、こんなに振れ幅が大きいのは
もう一つ理由があります。
それは施工技術が分からない人が
見積りに関わっていることです。
設計をする人でも
施工技術が分からない人が多いといいます。
いくらになるか考えずに設計案を作っているのです。
ザハ・ハディドさんもその類でしょう。
予算は１３００億円と言っているのに
あんな壮大な案を作って出すのですからね。
審査する方だって
コストのことが分からずに
デザインの斬新性だけで決めているのだから無責任です。
設計者でもその程度です。
ましてそれを依頼するお役人・文官は
もっと評価力がないのです。
そんな人たちがこねくり回すのですから
わけも分からず揺れ動くのです。
若干脇道です。
技術的な評価力がなくても、
類似案件のコストくらい知らなければダメでしょう！
見積りについて追求した当時の国会の委員会で
議員からの他の案件のコストはどうなっているのか
との質問に対してＪＳＣの担当役員が、
「把握していません」という回答をしていました。
論外ですね。
以上のことは見積りには付いて回る「常識」です。
分からない人たちがこねくり回すから
こんなことになってしまうのです。
この不首尾の経緯を私なりに以下の表にまとめてみました。
見積りが振れる要因
要因
|
今回の場合
|
対応法
|
１． 要件が変わる
・ この施設を何に使うのか、どのくらいの規模にするのか、定性的ねらいをどうするのか、によって当然ながら実現コストは変わる。
|
・ Ｎ万人収容
・ 用途（陸上競技、サッカー大会、音楽会、等々）
・ 敷地面積
・ 災害時避難場所
・ 日本の技術力を世界にアピールする。
|
・ これが基本要件で、これが決まらなければ、何も決められない。
・ 当初これは最大限の希望的可能性を盛り込んでいた。
・ 何でもかんでもの施設など実現した試しはない。
|
２．設計ができていない
・ 要件が決まって設計になる。
・ 設計ができていなくてまともな見積りができるわけはない。
|
・ 今回のザハ氏の入選はデザインコンペでデザインを決めただけで設計は行われていない。
・ ２０１４年１月に基本設計が開始されているが、５月にこの基本設計を基にしたとされる見積りが１６２５億円である。
・ この期間の「見積り」では到底積上げ型の見積りができるレベルにはなっていない。
|
・ この段階での見積りは超概算見積りである。
・ 類似案件からの類推となる。
・ 前例となる類似案件がない場合は、リスクを見て膨らませた見積りとする（そうせざるを得ない）。
|
３．建設工事に理解がない人間が見積りに関わる
・ 前提とか見積り方法を捨象して結果の数字だけを使う。
・ 数字の独り歩きが行われてしまう。
・ 見積り内容の精査ができず、見積り値を丸呑みしてしまい、前向きの施設・機能の改善検討ができない。
・ 施工技術に精通していない設計者の設計は、最適機能・最小費用を考慮していない設計となっている可能性がある。
|
・ 最初の段階の３０００億円とか上記１６２５億円は、この数値で計画とするレベルでは到底ない。
・ 文科省や日本スポーツ振興センター（ＪＳＣ）の担当官は到底技術評価はできない「文官」であったろう。
・ 今後の問題になるが、設計技術者と施工技術者の密な連携が納期短縮の面からも必要となる。
|
・ 見積りの前提条件を確認し、見積り値の限界を認識して検討を進めるべきである。
・ 超概算見積りを前提に予算化措置などをしてはいけない。
|
ーーーーーーーーーーーーーーーーーーーーーーーーーー
情報システム開発での見積りでも、
まったく同じことが毎日のように起きているのです。
「こんなことをやりたい、見積りをしてほしい」
と開発業者がお客様に言われます。
「どんなものを作るのですか」
「まだ詳細は決まっていない、
だから概算でいいから見積ってほしい」
そう言われると仕方ないので
開発業者は想定・仮定をして見積ります。
積み上げの見積りができませんから、
類似案件からの類推しかありません。
分からない部分はリスクを見て上乗せします。
そうするとお客様はその概算で予算措置を講じます。
そうなると、仮の概算数値は既成事実になります。
「予算がこれだけだからこれで開発してくれ」
そうして開発に入ると、
追加の仕様がどんどん出てきます。
リスクを見た枠もどんどん超えます。
「えーっ、それは困ります」とクレームしても
「とにかく予算がそれしかないのでそれでやってくれ」
となるのです。
新国立競技場の見積りと同じことでしょう？
これからも続きますよ。きっと！
ーーーーーーーーーーーーーーーーーーーーーーーー
もう一つは、
企画または設計ができたあとの見積りの問題です。
開発業者はその企画案または設計案に基づき、
それなりの方法で開発規模の見積りをします。
発注者は
一般的にその見積り値を評価する力がありません。
発注者に開発実務の経験があれば、
「何でその部分がそんなにかかるのか」と追及ができますが、
そうでないと鵜呑みにせざるを得ません。
多くの発注側企業では、
もう長い間開発実務から遠ざかっていますので
開発業務の「当たり」がつけられないのです。
「とにかく高いから少し安くしてくれ」
とか言って値切るしか能がありません。
従来の見積りは、
開発側では積み上げて見積っていますが
発注側から見ると、
工事費一式でいくらですという見積り方法だったのです。
もし「何でその部分がそんなにかかるのか」の質問への回答
に対する理解力があれば、
「だったらこういう仕様に変更してコストを下げよう」
という検討も可能となるのです。
「見積りの内訳が見えるようにしよう」ということで
ファンクションポイント法（開発する機能をベースに見積る方法）
が開発され一部企業で実用されています。
ファンクションポイント法は、
水洗トイレを３つ作ってくれ。
そのトイレには男女共用のウォッシュレットを付けてくれ。
という要求に対して、水洗トイレ分でいくらです、
という見積りです。
当たり前でしょう？
これだと「ウォッシュレットは止めようか」
という検討ができるということです。
それでもなぜそんなにウォッシュレットにかかるのか、
という疑問は残ります。
ウォッシュレットの作り方・設置方法が分からないと
それ以上の突っ込みはできません。
現在、発注者に開発実務の経験をさせよう、
という動きも出てきています。
ところでファンクションポイント法は
新規開発には適用できるのですが
システムの変更（保守・エンハンス）、つまり以下のような
和式便所を洋式に変更する
洋式便器にウォッシュレットを設置する
に適用できるようなファンクションポイント法的な見積りは
一般化していません。
これをシステム企画研修社では開発し提供しています。
今までこの方法がなぜなかったのが不思議です。
以上、情報システムにおける見積りの問題点を整理すると
以下のようになります。
情報システムにおける見積りの問題点と対策
問題点
|
原因
|
対策
|
・
開発内容が決まっていない段階で見積りを要求される。
・
仕方なしに「適当に」[
「超概算」という前提で見積りを出す。
・
そうするとそれが独り歩きで確定見積りになってしまう。
・
機能が膨らんでも、提示した見積りの中で開発せざるを得ない。
|
・
開発内容が決まる前に予算措置を講じる必要がある。
・
開発内容が決まっていない段階で的確な見積りをする方法はない。
・
開発内容が決まってからでも、短時間に正確な見積もりをする手法や能力がない。
・
受注側の交渉力が弱い。
|
・
見積りを出す際には見積りの前提条件を明示する。
・
前提条件は何らかの方法で定量化か具体化を行い、事後の折衝時に、具体化された要件が範囲内か否かの判断ができるようにする。
・
その上で、追加要件は次回回しにするとかの結論に到達するようにする。
・
それには、そのつもりで臨む覚悟と交渉力が必要である。
|
・
変更処理（エンハンスまたは保守業務）に対する機能ベースの見積り法が確立していない。
・
そのため、発注側は、見積りの妥当性を検証する方法がない。
|
・
見積り方法の研究が十分されていない。
・
あるいは、良い方法が共有されていない。
|
・
システム企画研修株式会社ではその方法（ＳＷ式工数見積り手法）を開発しているので、それを研究する。
|
ＳＷ式見積り手法に関心ある方はお以下にお尋ねください。
mind-pc@newspt.co.jp
0 件のコメント:
コメントを投稿