京都大学特命教授 博士（工学） DBアジュディケータ 調停人 仲裁人
建設契約は非常に不確定要素の多い契約とならざるを得ない。建設プロジェクトでは、工事が一般的に大規模で複雑なため設計図書や仕様書を完ぺきに準備することが不可能であり、かつ工事が長期にわたり、その間に政治・経済の状況が大きく変わるといった状況変化も珍しくはない。また、気象・海象等の自然を相手にし、さまざまな予期せぬ出来事が起こるリスクをはらんでいる。こうした特異性が契約の不確定性となって現れ、工事が進むにしたがって実際の状況と契約時の想定が乖離してくる。
その乖離の責任を誰が取るか・・・。つまり「誰がコスト増の負担や工期延長の責任を持つか」などに関して発注者・エンジニア・コントラクター間に意見の相違が生まれやすいのである。そしてこのような意見・契約解釈の相違が紛争に発展することもまれではない。紛争がエンジニアの決定（Engineer's Decision」や再交渉による和解（amicable settlement）で解決されなければ仲裁や訴訟に発展する。これらの法的手続きは時間と費用を要するだけではなく、契約当事者の関係を悪化させ、これがさらに紛争をエスカレートさせるという悪循環に陥る。
契約上の紛争に対処する最善の方法は、紛争が大きくなる前に解決するか、あるいは最初に紛争を生じさせないことである。DBの目的のひとつは契約当事者間で解決できない紛争に対し勧告または裁定を下し、早い段階で現場レベルでの解決を可能にすることである。
しかし、DB経験者はDBの真の目的と価値は紛争の予防であると報告している。最も新しく出たFIDICの標準約款のひとつである、デザイン・ビルド・オペレート契約条件書1ではこれまでの「クレーム、紛争、仲裁条項(Clause20 Claim, Disputes and Arbitration)」に「紛争の予防(Sub-clause 20.5, Avoidance of Dispute)」がはっきり謳われている。
DBとは個別プロジェクトに設置する紛争委員会のことである。通常、中立・独立な3人の経験ある専門家（土木・建築・機械等の技術者あるいは建設プロジェクトの経験が豊富な法律家）によって構成され、プロジェクトの着工時から竣工後の瑕疵担保期間が終えるまで存続・機能する。経験ある専門家とは当該プロジェクトと同様の工事に精通しており、契約文書の解釈に長けており、紛争解決の経験が豊富である専門家のことである。DBはプロジェクト・チームの一部としてクレームの発生を防ぎもし紛争が起こっても当事者の合意によってDBに要請される非公式見解や助言の提供によって、友好的に解決することを手助けする。どうしても当事者同士で紛争が解決しないときには、DBに申し立て（付託）が行われDBが勧告や裁定を出す。仮に勧告(Recommendation)や裁定(Decision)が当事者によって受け入れられなくとも、その後の更なる交渉のベースとなりえるので、和解のチャンスは多い。このようにDBは当事者が敵対的な立場を取らないで、紛争の予防および和解による早期解決を促す。
1975年にアメリカ・コロラド州のアイゼンハワー・トンネルの第２坑道工事の過程において、初めて「紛争審査委員会（DRB：Dispute Review Board）」が用いられた。このDRBの試みは圧倒的な成功を収めた。DRBは3つの紛争の付託を受けたが、それらに対する勧告を基にした合意が成立し、その最終結果に関係者すべてが満足した。一方、1980年には世銀がホンジュラスのエル・カホン水力発電所プロジェクトでDRBを使用したが、これも成功裏に終わった2。
FIDICは1987年の第4版の「エンジニアの決定(Engineer's Decision)」という永年採用されてきた紛争解決手続きをFIDIC約款1999年版で大きく変更し,この権限を「紛争裁定委員会（DAB：Dispute Adjudication Board）」に与えた。世銀と開発銀行群（MDB：Multilateral Development Banks）および国際基金協会（IFIs：International Financing institutions）はFIDICの協力の下にFIDIC 1999年版に基づく"Harmonized Edition"（MDB版）を2004年に発行し、DABを導入した。これによって世銀や各開発銀行融資のプロジェクトでは、必ずDBを設置しなければならなくなった。前述のごとくJICAも2009年6月にODA融資プロジェクトの調達図書「Sample Bidding Documents」に採り入れた。しかもJICAはDBコストをプロジェクトに必須な費用として計上することを認め、融資額の見積もり時からコスト参入することを認めている3。
DBの価値はコスト・セービングを実現し、プロジェクト関係者の関係を敵対的（adversarial）関係からパートナーシップへと変える。
「問題も紛争もないときにDBを常設してどうして高額の出費をしなければならないのか」とよく言われる。そのような発注者やコントラクターはDBの設置を遅らせ、決まって「もし当事者の間で穏便に解決できない問題が出てきたときにDBを設置します。」と言う。また設置はしたものの現場訪問はコスト・セービングのために年に一回でよいという当事者もある。これらはすべてDBの経験が不足していたり、DBを適切に設置し運営することが結局はコスト・セーブになるということを理解していなかったりするためである。
もしDBを設置しなければどのようなプロジェクト運営になるか。典型的な姿はクレームが重大事になってきたとき、コントラクターとエンジニアが手紙のやり取りを始める。これらの手紙や書類はクレーム・コンサルタント、工程解析専門家、独立した地質学者、地球物理学者、国際および地元弁護士の助言や支援を受けて準備することが一般的である。このような外部専門家をコントラクター同様エンジニアも必要とするが、その費用は最終的には発注者が支払うことになる。
このような書類の準備はコストがかかるだけではない。多くの関係者の時間を奪う。書類は当然両当事者の上位管理職が目を通す必要がある。これらのクレーム関連書類を巡って両者が何度も何度も、何ヶ月も会議を持ち交渉を繰り返す。両者ともにそれ以上の出費と時間を伴う仲裁には何とか行かないですむようにと願いながらも、勝ちは譲れない。ますます和解は困難になる。このような戦いは竣工後にずれ込むことも稀ではない。その頃には当事者は現場から撤退しており、宿舎や事務所もなく、交渉のためにホテルに滞在し、会議室を借りる必要がある。意見を提出した専門家に交渉会議に出席してもらうためには航空運賃やホテルの宿泊代が発生する。最後には調停人を導入することになるかもしれない。これらのコストは容易に見積もることはできない。ただいえることは莫大なコストがかかるということだけである。これに引き換え、DBのコスは前述のごとく見積もることでき、予算に組み込むことができる。
それではDBを適切に設置し運営すればどのような利益が得られるのか。DBは最初から契約を熟知し、現場訪問時だけではなく自国にいるときに送ってこられる情報によって現場状況を把握している。同種のプロジェクトの経験のおかげでDBメンバーは常にリスクの存在する領域に注意し、起こりそうな問題に気をつけている。DBメンバーは当事者が紛争を未然に防ぐことを助ける経験が豊富であり、またもし紛争が起こってしまったらそれが契約上正式な紛争となる前に和解する手助けをする。最も成功したDBとは一度も正式な書面による付託やヒアリングがないことである。その中でも、DBプロセスに現場のスタッフだけが関与し、当事者の上位管理者の関与を一切必要としなかった場合が典型的な成功と呼べるのである。
もし何らかの理由で和解が成立せず、正式な付託があった場合には、DBは手続きを上手にコントロールし、提出書類を最小限に留めさせ、ヒアリングは両者にフェアーであるが、短くし、できるだけ全員一致の裁定を早く出す。この裁定が両者あるいは一方当事者にとって不服であっても、仲裁に行くことなしに再交渉によって和解するベースとなる。
以上のことから伝統的にクレーム解決を先送りにし、プロジェクトの終わり頃にあるいは竣工後までも長引く、膨大なクレーム・カウンタークレーム図書を巡る戦いに費やすコストを考えると、DBを適切に設置し運営することはまさしくコスト・セービングである。ましてやそのあとに仲裁や訴訟に行くときの費用を考えれば、DBにかかる費用がどんなに小さいかわかる。
旧Red Bookで定義されていたエンジニアの役割が新Red BookとMDB版で大きく変更された。副条項Sub-Clause 3.1 Engineer's Duties and Authority}で規定されているように、これまで中立公正であるべきとされてきたエンジニアが発注者のために業務をすることになったのである。
そして以下の業務を行うときには原則的に発注者の承認を前もって得なければならない。
Except as otherwise stated in these Conditions:
(a) whenever carrying out duties or exercising authority, specified in or
implied by the Contract, the Engineer shall be deemed to act for the Employer;
契約条件に特段の取り決めがない限り、契約に定められているか合理的にそのように解釈できるエンジニアの義務を遂行したり、職権を行使したりするときには、エンジニアは（発注者のエージェントとして）発注者のために行動しているとみなされる。
この条項によってエンジニアは発注者に偏った業務の仕方をすればよいのかというと、副条項Sub-Clause 3.5 [Determination]によって歯止めもかけられている。
（前略）the Engineer shall make a fair determination in accordance with the Contract, taking due regard of all relevant circumstances.（下線は筆者による）
（前略）エンジニアは関係するすべての状況を考慮しつつ、契約に基づいて公平な決定をしなければならない。（下線は筆者による）
ところでエンジニアの実質的な業務の内容と質に変化があったのであろうか。答えは「否」である。DBにはエンジニアやコントラクターに何かを指示したり命令したりする権限はなく、これまでのエンジニアの権威が損なわれることは決してない。そして実際にDBが設置されたプロジェクトでは、エンジニアは中立・公正な指示・承認・査定等を実行するようになる傾向がある。なぜなら、建設プロジェクトの経験が豊富で、絶対的中立公正を守ることができ、契約解釈の経験が豊かで能力が高いDBメンバーの前で、偏った考え方や行為をすることは自分自身のプロフェッショナルとしての面目が立たない、また、コントラクターからDBに付託を行われて結局は公正な判断が出るからである。したがって、特に筆者の経験した限りにおいては、エンジニアは旧Red Bookで求められていたような中立・公正な立場をとることを実現している。
DBがなく、当事者が敵対的（adversarial）関係にあるプロジェクトにおいては、生じてしまった余分なコストと工事の遅延を当事者がどのような比率で分担するかを交渉し、あるいは仲裁で争っているのである。DBの設置されたプロジェクトでDBがないときのことを想定したり、DBの設置されていないプロジェクトでDBがもしあったらと想定したりするのはすべて仮定の話であり、断言することは難しいが、DBプロセスの真の価値はこの余分なコストと工事の遅延そのものをなくす、あるいは最小限にとどめることが出来ることであると筆者は確信している4。したがって、一部の発注者が持っている、DBはコントラクターだけに有利なプロセスであるという考えは正しくはなく、最終的に発注者のためになる仕組みであることを理解することが肝要である。DBの発祥の地、米国において、各州の道路局などがDBを採用していることを見てもこのことが分かる。
Copyright © 2023 Toshihiko Omoto
Website by Designition
