HEC ソフトウェアの開発及び維持管理体制に関する講演録

44.1 講演開催の経緯
本講演録は、平成 17 年 3 月 16 日(木)午前 10 時から午後 5 時まで、財団法人河川情報センター
にて開催された元米国陸軍工兵隊水文工学センター（HEC）アーレン・フェルドマン氏による「HEC開発及び維持管理体制に関する講演会」の同時通訳の速記録を基に、吉谷・清水（元土木研究所交流研究員）が編纂したものである。編纂に当たっては、重複した通訳を削除し、誤訳や意味不明部
分を講演者の意図を汲んで修正したため、編纂者の主観が含まれている部分があることを断っておく。
アーレン・フェルドマン氏は、20 年以上に亘り HEC の水理水文技術部長として、水理計算モデ
ルHEC-1(洪水予測ソフトウェア)やHEC-HME(流域水文解析ソフトウェア)の開発責任者を務めてきた。フェルドマン氏と日本の交流は、旧土木研究所が行っていたカルフォルニア大学デーヴィス
校 Kavvas 教授との共同研究を通して始まった。土木研究所職員が共同研究のためにデーヴィス市を訪問した際に、Kavvas 教授の紹介により HEC を訪問しフェルドマン氏と個人的な意見交換を行っていた。また、フェルドマン氏は、平成 15 年 3 月 26 日に水文水資源学会・国土交通省国土政
策技術総合研究所が主体となって開催した「Hydro Modeling and Interface 2003～Software for
Hydraulics, Hydrology and Water Quality～」に招聘されている（1.1 参照）。このような経緯から、
フェルドマン氏は日本の政府組織や水理・水文・水質ソフトウェアに関する現状についての認識を持つようになったため、最適の講師となったと考えている。
今回の招聘は、世界各地にユーザーを持つ HEC ソフトウェアの維持管理体制と HEC の組織運営を詳しく調べるため、土木研究所ユネスコセンター設立推進本部（当時）が事務局となって行なった。招聘準備段階で、水理・水文・水質シミュレーションモデルの標準化を検討している国土技術政策総合研究所と財団法人河川情報センターに相談し、この関係者向けの講演会も企画することになった。本講演会はこのような経緯で実現した。当講演会の準備として HEC ソフトウェアの開発と維持管理に関する質問を関係者から事前に集約し、それをフェルドマン氏に事前に伝え、その回答に加えて、フェルドマン氏が日本の技術者に有用と判断した内容も解説するレポートを来日前に作成していただいた。講演会での「手元の資料」とある発言は、このレポートのことである。その日本語訳は巻末の CD-R に収録している。
講演会は、日本側が事前に送付した質問をできるだけ網羅するように、しかし、個々の質問に一つ一つ答えるのではなく、できるだけ体系的に日本側に HEC の実情が伝わるよう、フェルドマン
氏の判断で講演全体の構成を決めていただいた。これらの交渉は、招聘手続きを行った土木研究所
ユネスコセンター設立推進本部（当時）の吉谷が行った。

4-1

4.2 講演録
4.2.1 Corps HEC introduction（1） Water Resources Software Development - HEC's Experience, Observations

HEC は１階建ての建物。
＜U.S. Army Corps of Engineers(USACE)-Civil Works＞
米国陸軍工兵隊（USACE）は、軍関係と、民間の土木、特に水資源に関しての機関の２つの使命を帯びている連邦機関です。
当初 USACE は、舟運（ナビゲーション）の技術開発からスタートしました。次第に洪水防御等のいろいろな工学の研究の要望が出てきて今日に至っています。現在 700 以上のダムを管理し、アメリカ全土にわたる閘門、水門も USACE が管理しています。広大なる貯水池から小さな閘門までが対象となっています。他に、洪水の被害軽減、ナビゲーション、水の供給など、活動は多岐にわ
たっています。
（2） USACE Civil Works
アメリカにおいて、USACE は水資源の管理に関しては非常に特異な機関です。陸軍ですが、実際は従業員の 98％が民間人で、軍人は２％です。ただ２％の人が与える影響は非常に大きなものがあります。
貯水池の運用、さらに維持、さらに生態系の復旧ということもミッションに入っています。川の流れについていろいろなことをしようと思うと工兵隊から許認可が必要となります。
組織の構成は、本部（ワシントン D.C.）の下に地域ごとの局があり「division」と呼んでいます。
河川流域の水資源は、このディビジョンが担当します。南太平洋地域のディビジョンは更に幾つかの地域からなり、例えばロサンゼルスであったり、サンフランシスコであったり、サクラメントであったり、ディビジョンがそれぞれのディストリクトごとに分かれています。
ロサンゼルスで洪水の問題があったとすると、ロサンゼルスの政府関係、あるいは市関係、あるいは一般の人が工兵隊に、この洪水の被害があるので何とか助けてほしいというふうに支援を求めてきます。工兵隊はそれぞれの地域の担当が、それぞれの地域で問題があるといろいろな問題解決を図ります。
軍隊ですから、命令指揮系統があります。ディストリクト・オフィスにはカーネルという大佐が4-2

います。将軍がディビジョン・オフィスを管轄しています。さらにその上の位のジェネラルが本部を管轄しているという組織体系です。
（3） Hydrologic Engineering Center, HEC
HEC は、先ほど述べたそれぞれの地域、ディストリクトにあるオフィスのサポートをするために 1964 年に設立されました。HEC はこの組織を側方からサポートしています。ですから、ヘッドクォーターと一緒にサポートしています。

図 4-1 陸軍工兵隊組織における HEC の位置付け＜組織＞
HEC は組織として小さい方で、30 人ぐらいの専門のエンジニアが働いています。ほとんどのス
タッフが大学の修士号を取っていて、５～６人の博士号取得者もいます。
＜学生の活用＞
HEC はカルフォルニア州のデーヴィス市にオフィスを構えています。そして、カルフォルニア
大学デーヴィス校から常に何人かの在校生、あるいは卒業生を受け入れて仕事を一緒にしてもらっています。ですから、我々が教授のように学生を指導するというケースもあります。その学生は、テンポラリー・スチューデント・エンジニアというポジションであり、中には１、２年かけてそれから修士へ進む人もいるし、数年かけて PhD を取る人もいるし、いずれにしても、テンポラリー
ベースです。正職員として採用するとなるといろいろな査定があります。ただ、テンポラリーの場
合はそんなに厳しい査定がないので簡単に採用することが出来るメリットがあります。今も何人かの学生に一緒にやってもらっています。
＜HEC の活動＞
HEC の活動は、Hydrologic and Hydraulic（水理・水文）を基礎として、洪水の被害軽減の計画を立てて、分析をしています。水をどのように管理するかということが大切です。
どのようなツールを使ってその問題解決を図るかというと、一般的に使えるようなソフトウェア
開発し、それを使って問題解決に当たっています。実際に研究をしたものをどのようにして使っていくかということで、エンジニア用のマニュアル（EM）、ユーザー用のマニュアルというものを作
4-3

って、ガイダンスをしています。
技術支援とかトレーニングを行ったりとか、調査研究を行っています。これについてはまた後で詳しく述べていきます。
水文学においてアメリカの地域のディストリクト・オフィスをサポートしていくことが、我々が焦点を置いている一番大きなミッションです。

陸軍工兵隊水文工学センターの使命

技術支援

研修・教育
および
ソフトウェアサポート

研究開発

水文工学、計画分析の専門技術センター
研究、トレーニング、技術支援
をバランス良く実施
研究、トレーニング、技術支援をバランス良く実施
カリフォルニア州、デイビス

図 4-2 HEC の使命（4） HEC Philosophy
こういった個々のディストリクト・オフィスの問題解決の支援をしていますけれども、一般に適用できるようなやり方で問題解決に当たっていくのが我々HEC の大きな理念となっています。
トレーニングも大きな活動目的の１つでありまして、収入はわずかですが時間をかけてトレーニ
ングを提供しています。
（5） Technology Development & Transfer
HEC の活動がそれぞれどのように相互に関連しているか例を挙げて説明します。
例えば、ロサンゼルス地域で水路の流速が非常に速くなってしまったという問題がありました。
どうしたらいいか調査してくださいというふうに HEC に要望が来ます。
River Analysis System（RAS）というソフトウェアを使って、流速が速くなったその水路に対して、それを修正する方法を提案しました。ロサンゼルスのディストリクト・オフィスから多少お金を出してもらって研究をして、問題解決に当てるという例です。
また、USACE には研究開発に当たる R&D オフィスがあります。この R&D オフィスから HECに資金を出してもらうこともあります。いろいろなディストリクト・オフィスから出てきたニーズに基づいて R&D から要望が出てきます。ですから、このディストリクト・オフィスは R&D を通して「こんなニーズがあるのだけれども」と HEC に言うこともできるし、直接それぞれの現場の4-4

オフィスから HEC に、「こんなニーズがあるのだけれども」というような話が来る場合と両方あります。
R&D から調査依頼があるとき、HEC と競合する団体（同じような研究機関）での調査も検討されるので、実行までに時間がかかります。ディストリクト・オフィスから直接 HEC に上がってきた場合はダイレクトに来ますので、短期間で処理できます。
R&D から水理・水文、あるいは洪水軽減、水資源管理について資金を出してもらっていますので、ディストリクト・オフィスからの資金を多少 R&D の資金で補っているという形になっています。
問題解決できた後、そのソフトウェアの使い方、分析のパフォーマンスを、このディストリクト・
オフィスの職員の方たちにトレーニングをしていきます。
問題が何か突き止めて、問題を解決して、トレーニングをするという循環で仕事が流れていきます。それが済むとまた新しい問題に取り組むという作業に入っていきます。
＜Q： ディストリクト・オフィスの仕事の内容と HEC の関係＞
Q： ディストリクト・オフィスの仕事の内容と HEC の関係をお聞きしたいのですけれども、まずディストリクト・オフィスである問題を抱える、そんなに大きな問題ではなくて通常の水理解析をやるテーマがあるとします。そうすると、ディストリクト・エンジニアリング・オフィスのエン
ジニア自体がみずから解析計算するパターン、あるいは民間コンサルタントに契約関係を結んで解析をするパターン、それと HEC にサポートをお願いするパターン、の３種類のパターンを仕事の難しさによって使い分けていると考えてよろしいでしょうか？

Data
Manag
Queue

Web
ServerDD
ManagerDD

SHEF
decoder

Transformer

Verifi er

DA

Current Data

C

A
V
S
E I
R
V
E

DB
Inter faceDB
Extract/ Post

FSF

R

GIS Controller

Model Working Files
HMS

C

A
V
C
I
L
I
E
N
T

Arc/
View

RAS

Model Results

Process/Alarm
Status
DA
FSP
DD
CAVI

Arc/
Info

A： ディストリクト・オフィスは、自分たちで独立しているので、問題解決が自分たちでできるならばディストリクト・オフィス内で問題解決をしていきます。もしディストリクト・オフィス内
で問題解決ができなければ、大学に助けを求めてもいいし、HEC に助けを求めてもいいし、ある4-5

いはコンサルタントに何とかしてくれと言ってもいいし、それは問題の性質によって自由に選択していくことです。HEC のソフトウェアを使わなければいけないということではないのです。ですから、我々は使ってもらうように常に良いものをつくらなければいけないわけです。
例えば、ロスアンゼルスの場合、普通は流速の速い水路の分析は大学の教授がやっていたのです。
そして、その大学教授が研究したことを今度は HEC に持ってきて、その研究成果を RAS というソ
フトウェアに盛り込んだという経緯があります。
＜Q：工兵隊は何を管理しているか？＞
Q： それぞれのディストリクト・オフィスの管理の範囲はどうなっているのか。例えばロサンゼ
ルスオフィスは何々川と何々ダムを州政府ではなくて、連邦政府が自から管理しているのかを教えて欲しい。
A： 工兵隊が所有しているダムもありますし、開拓局が管理運営しているところもありますし、
州がやっているプロジェクトもありますし……。
Q： そのオフィスは工兵隊の管轄内にある施設を自から管理しているという意味ですか。
A： ええ、ちょっと御説明申し上げます。例えば、多目的貯水池の場合、カルフォルニアの州がこの貯水池を管理して水の供給とかに使うわけです。洪水調節のためにこの貯水池の設計に工兵隊が関与してくるという図式です。洪水が起きたときには工兵隊が優先して関与している。洪水がないときには州だけがこの貯水池の運用に関わる。だから、何か問題があると工兵隊が出ていくという図式です。
○司会 これは非常に興味深いお話で、説明に恐らく丸一日必要になるぐらいの問題なので、私の理解している範囲でごく簡単に答えます。日本のような河川管理区域という明確な区域を管理しているという概念ではなくて、その都度にいろいろな組織がプロジェクトを行っています。そのプロジェクトの施設や計画などを担当部局が計画・管理しているという図式になっています。なぜ陸軍
工兵隊かというと、議会がかなりコントロールしていまして、最初は舟運のミッションを陸軍工兵隊に与えたことから始まりました。その後、航行可能な区域の構造物建築許可は全部陸軍工兵隊が出すというふうになっています。それは議会が制定した「Clean Water Act」の中で明確に定義されています。そういう関係で、陸軍工兵隊が航行可能な水域に関することは全部所管するという構図になっています。
その辺の趣意は、昔、カルフォルニア大学デーヴィス校の浅野孝先生と一緒にいろいろ報告書を書いてありますので、後で皆さんにお配りしたいと思います。
＜Q： コンサルタントとの関係＞
Q： ディストリクトからコンサルタントへの委託業務の中で、コンサルタントが問題を抱えたときに、それをサポートする形で HEC が入る仕組みはあるのでしょうか。
A： そういうケースも結構あります。ディストリクト・オフィスが使っているコンサルタントともいろいろやりとりがあります。ディストリクト・オフィスからソフトウェアのアプリケーション
をコンサルタントに提供してくれという要望が HEC に来るというケースもあります。サポートしてくださいよという依頼が HEC に来ることもあります。
そこで重要なのは、プログラムがどんなものであるかはディストリクト・オフィスのニーズに基づいているということです。だから、ディストリクト・オフィスから直接要望が来ようが、コンサ
4-6

ルタント経由であろうが、ニーズを満たすということがプログラム開発の根底となっています。それが重要な点です。基礎的な研究というよりも応用研究です。実際に実用にするための研究と言えます。
＜Q： HEC と同じような組織＞
Q： お話の中で、R&D 経由でニーズが来る場合と直に来る場合とあって、R&D 経由で来ると割り振りとがあるので時間がかかるということなのですが、ということは、HEC と同じような機能を持つ組織がアメリカ国内にあるのでしょうか？
A： 水理実験を行なう、WES という Water Environment System が、これは旧称ですが、ありまして、ＷＥＳも HEC と同じような、数字的なモデリングも行っています。基礎的な研究に視点を置き、現場に即した活動ではなくて、研究自体に重きを置いています。
4.2.2 HEC products（1） HEC Products
HEC の主な製品は、まずソフトウェアで、次に技術的な方法やガイダンスである「Corps ofEngineers Manual」についてのレポートです。インターネットに接続していただいて、工兵隊のウェブサイトに行って「Engineering Manual」を見ていただくことも可能です。
このガイダンスには水理・水文の管理、あるいは洪水の軽減といったことに HEC が責任を持っていますよということが書かれています。
国のダムの安全に関する研究といった特殊な研究も行っています。Federal Emergency
Management Agency というアメリカの機関に対しての研究も行っています。
技術移転も大きなウエートを占めています。ウェブサイトを見ていただきますと、ニューズレタ
ーとかトレーニングについて書いてあります。
ソフトウェアのダウンロードをするセクションもあります。ウェブサイトにアクセスしていただ
ければ、ここに網羅してある情報は入手可能です。
１ヵ月に１回、ショートコースを実施しています。３月のショートコースは洪水防御のためのリスク分析でした。来月は川の不定流解析がショートコースとして紹介されています。
このコースは主に工兵隊職員を対象としているのですけれども、工兵隊外部の方でも受けることは可能です。
（2） Major Software Packages
ソフトウェアパッケージについて、幾つか見ていきます。
河川の水理解析、流域の水文、洪水被害、さらに貯水池の分析が、４つの大きな主なパッケージとなっています。
（3） Systems Integration, Other
あとはシステム統合を扱っているソフトとしまして、リアルタイムでの水・マネジメント・シス
テムがあります。そして、データ・マネジメント・システムが非常に重要です。時間をずっと追ってデータを見ていくという、データ・マネジメント・システムを開発しました。最近では生態系の4-7

分析についても行っています。
川の水理を考えていく上で、HEC は別に生態学者ではないのですけれども、水理・水文を考えていく上でやはり生態系についても考えないといけないということです。
（4） HEC-RAS, River Analysis Version 1.0 Release 1995, Now V 3.1

もう少しそれぞれのパッケージを詳しく見ていきます。
「RAS」と言っている河川の水理解析システムです。
河川の水理に関して、非常に実際的な面を見ていきます。流れが安定しているとき、安定していないとき、いろいろな橋の影響、あるいは排水溝、実際は一次元的なソフトウェアなのですけれども、擬似的に二次元的にシミュレーションしていくということが可能なソフトです。
例えばこのアニメーションはネバダ州の Tahoe 湖の近くにある川なのですけれども、本流がこういうふ
うに流れ、水がオーバーフローしたときに貯留しておく氾濫原がこの川の流域にあります。そして、この流れがどういうふうに流れていくか、それぞれの貯留氾濫原との結びつきがどうなっていくかということをこの RAS でシミュレーションしていくことができります。
川の水位が上がると、氾濫原へ流れていきます。水位が下がれば、今度は氾濫原から逆に川へ戻ります。それをこの RAS のソフトウェアがシミュレーションして、視覚的に見せてくれます。
ダムが決壊した場合の分析、これは最初のスライドで見ましたね。閘門とかダムというのはある程度水をためておかなければいけないわけです。いろいろなエンジニアの会社がこのような解析ソ
フトを競合して開発しているのです。DHI が開発しているものもあります。DHI のソフトでもこういう形で見せることができります。これを何とか RAS のソフトウェアに取り込むことができな
いかというような問い合わせが来たこともありました。
例えば閘門の「hinge pool operation」においてディストリクト・オフィスがどんなニーズを持っているのかということを探ってくわけです。RAS のソフトウェアパッケージにそのニーズも盛り込
まれています。ちょっと特殊過ぎるので RAS に入っていないケースもあるかもしれません。パッ
ケージに入れてほしいという要望が工兵隊のそれぞれのディストリクト・オフィスからあれば、当4-8

然それは盛り込んでいく努力はしていきます。
RAS は水理解析においてはかなり完成されたソフトとなっていると言えますが、ただ例外として土砂の移動については扱えるようにはなっていません。RAS パッケージで土砂について取り扱えるようにしようと、今、開発中です。HEC-6 パッケージというのをお耳にされたことがあると思うのですが、この土砂の移動について扱っていた昔のパッケージが HEC-6 というものです。RAS に取り込むだけではなしに、最新鋭のものとしてどういうことを考えなければいけないか、例えば土砂についてどういうふうに考えなければいけないかということを鋭意検討しています。
（5） GIS についてシステムにはいろいろな地理学的な要素が入っていますので、GIS については ESRI にサポートをお願いしています。HEC が独自で GIS を開発しているわけではない１つの例が、ESRI に頼んでいるというケースです。Arc GIS を使って HEC-RAS にインプットするデータをつくるようなユーティリティを作っています。
＜Q： HEC の業務範囲＞
Q： HEC とディストリクトやディビジョンの役割分担について質問します。例えば、氾濫解析のプログラムをつくって提供するまでが HEC なのか、それとも解析してアニメーションまでが HECの役割なのか。実際に研修プログラムを開発してトレーニングをして使えるようにという話がありましたけれども、どの辺まで HEC がやって、どの辺までが現場の話になるのか。
A： HEC は単に、アドバイスとかコンサルティング業務だけという場合もあるし、細かく開発してディストリクト・オフィスに、どういうふうにしたら分析ができるかということをトレーニング
するところまで踏み込んで HEC がやっている場合もあります。
例えば、ミシシッピ川のどういった管理上の細かいニーズがあるかということをディストリク
ト・オフィスから吸い上げます。そして、ディストリクト・オフィスの河川管理計画をシミュレー
ションするようなソフトウェアを開発し、ディストリクト・オフィスにそのソフトウェアの使い方をトレーニングして技術移転し、その後、実際に使ってみたら、これはうまくいったよというようなフィードバックをオフィスから返してもらいます。
ディストリクト・オフィスがグラフを使って、例えば地域住民、あるいはほかの機関に河川管理計画を説明をするためにグラフを使うケースもあります。フィールド・オフィスからフィードバックをしてもらうのがニーズを吸い上げる上で非常に重要です。
（6） HEC-HMS, Surface Hydrology Version 1.0 Release 1997,
Now V 2.2
このソフトの対象は降雨です。雨、あるいは雪が降ってきた場合に、その降ってきた雨水がどういうふうに流れるかというお話をします。
RAS はマイクロソフトの FORTRAN で開発されましたが、Java
言語に基づいてこの Hydrologic Modeling System、HMS は開発されています。HEC-1 をさらに発展させたものが HMS です。このソフトウェアは降雨、雪解け、あるいは、降った雨がどういうふうに流れるかといったもろもろの水理・水文現象を解析します。HEC-1 からの大きな変更は、空4-9

間的にグリッドでこの分布を解析する点です。雨水がどういうふうに流れるかというのは空間的に見ていかなければいけないプロセスですから、降雨はレーダからマッピングして解析する必要があります。これは GIS システムを使ってこのモデルシステムをサポートしています。使っているのはArc GIS システムです。
このユーティリティを開発する場合には ESRI とかなり緊密に連絡をとって進めていきました。
ESRI とどのようにして協力的な研究開発協定を結んできたかというのは、後でソフトウェアの開発の話をするときに触れていきます。
＜Q： レーダ雨量のメッシュの大きさ＞
Q： レーダ雨量の下の図のメッシュの大きさ、１km×１km なのか。それと降雨量としての精度
管理、降雨量としての精度についてはどう考えているか。
A： ４km です、周辺が。もっと進んだものだと１km というのもあります。
＜Q： レーダ雨量のキャリブレーション＞
Q： 日本では、地上雨量計が一応正しいものとして、レーダ雨量計をそれに合わせて、降雨分布が得られます。米国ではどうしているのか？
A： 地上とレーダと合わせてやるし、気象モデルも加味して予測するという場合もあります。いろいろな手に入る情報を統合してやるのが一番いい評価法です。
（7） HEC-FDA, Flood Damage Analysis Version 1.0 Release 1977, Now V 1.2

図 4-3 洪水被害/影響解析 HEC-FDA

FDA は浸水した地域のいろいろな建築物、建物を細かく分析して見ていきます。それぞれの浸水した建物はどれぐらいの程度の被害を受けたか、あるいはどのぐらいの浸水深になったかというよ4-10うな情報があります。FDA 水理パッケージによれば、水の深さがわかります。そして、水の深さと関連した被害の程度を洪水被害分析ソフトが計算してくれます。そして、どれぐらいの水の深さからどれぐらいの被害があるか、あるいはどれぐらいの深さになりうるのか、そしてどれぐらいの頻度で浸水するかをコンピュータで計算し、１年間当たりの被害を予測計算することができます。
ディストレクト・オフィスはこの被害を軽減することによってどれぐらいのベネフィットがあるかということと、そのためにどれぐらいコストをかけなければいけないかという、そのコストとベネフィットとの相関関係を天秤にはかるということをしています。
当然、そのプロジェクトごとに、
これはこれぐらい役に立つものだ、ただその分、これぐらいのコストがかかるということをプロジ
ェクトごとに査定していかなければいけないわけです。
そして、GIS からもサポートをしてもらっています。そして、洪水被害を受けた地域の１つ１つの建物の情報をこの GIS によって得ることができます。
（8） HEC-ResSim, Reservoir Analysis Version 1.0 Release Spring 2003

図 4-4

貯水池シミュレーションシステム HEC-ResSim

貯水池をうまく運用すれば、洪水被害を削減することも可能になります。そこで、多目的貯水池
パッケージ（HEC-ResSim）をつくりました。いろいろな目的を持った貯水池の運用のシミュレー
ションをしていきます。水力発電、水の供給、あるいは洪水制御、環境的な目的、あるいは灌漑用に下流で水の供給のコントロールもしていくというようなことをやります。
水力発電システムへのこんなことが必要だということの中にこれを加えていくことができります。
この貯水池はある水力発電の目的に合致している、こっちの貯水池はまた別の水力発電の目的に合致しているなというふうにシミュレーションすることによりわかります。以前の HEC-5 というプログラムでは特殊な、例えばチャネル（水路）のキャパシティだけに特定したものだったり、あるいは貯水池放流に特化した情報しか扱わないというものが HEC-5 でした。
新しいこのパッケージは、下流からのいろいろな要望に基づき、どれぐらいの流量が必要かというようなことも計算できます。この貯水池満水状態であり、別の貯水池は貯水率が低い状況になっ4-11

ている。そして下流で、ある一定のルールがあります。これらの条件全てに基づいてシミュレーシ
ョンしています。
貯水池、貯水池運用のシステムをかなり包括的に、幅広く取り込んだ最新鋭のソフトウェアパッ
ケージになっています。
工兵隊の水マネジメント・システムについては、非常に重要なので後ほどお話をします。
＜Q： HEC システムの対象国＞
Q： こういうパッケージは構成上、アメリカ国内のみを対象としているのか、または海外に対して使うような作り方をしているのでしょうか？
A： 工兵隊向けにつくっているのですけれども、一般でも使っていただけるようには考えていますから、外国でも使えるはずです。
＜Q： 海外支援での実績＞
Q： 例えば、アメリカがどこか海外支援に行ったときにそこでこういうシステムを使うとかいうような具体的な実績はありますか？
A： 例えば、スマトラ沖のああいう大規模災害があって、アメリカから支援に行くというようなときにも、もちろん使えます。ローカルデータで記述していますけれども、カルフォルニアの川の状況の分析もできるし、例の津波の被害の分析もできます。
＜Q： 精度管理・品質保証＞
Q： ソフトウェアの品質保証、ステータスは、あるいは適用条件の明示みたいなものはオープンにしているのでしょうか。
A： それは後でちょっとお話をしますけれども、答えはイエスです。クオリティ・コントロール
をどういうふうにやっているかというのは、後でお話をいたします。その点は非常に重要です。世
界中で HEC のソフトウェアは使われています。HEC にしてみれば、多くの人が HEC のソフトをテストしてくれているということになります。エラーがあったらどんどん連絡してくださいというようにお願いしています。
＜Q： HEC の人員配置＞
Q： HEC の組織としては 30 人ぐらいで、小さなオフィスでやっているとのことですが、ディストリクトの問題解決の支援ソフトの開発と同時にサポートもしている、トレーニングもしている、
更に、海外にも目を向けているというのは、物理的に、人数的に足りているのでしょうか？
A： やはりかなり汲々してやっていますというのが現実です。これまでの技術を継続していくと同時に、新しい技術にどれぐらいの HEC の人員を配置していくかというような問題がありますの
で、HEC のスタッフの能力を広げていく上でも、コンサルタントと契約しています。ソフト開発
で、どういうふうに請負契約でやっているかというようなお話も後でさせていただきます。
Q： そうすると、平均的に 30 人がコアで、学生さんとかいろいろ入ってきて、客員教授みたいな人もいて、大体平均的に何人ぐらいでやっているのですか。
A： 60～70 人というところですかね、まあ、予算にもよりますけれども。
（笑声）
Q： その 60 人から 70 人の内訳ですけれども、今、メジャーのソフトが例えば４つあって、それ4-12

ぞれのチームを構成するというのは大体等分に配分されているのでしょうか？
A： パッケージによっては、大体３～４人が大体永久的にそれをずっとやるという人です。チームについては後でまた申し上げますけれども、ESRI とかいったコンサルタントに頼むときもあります。
＜Q： HEC の雇用形態＞
Q： その 30 人のコアメンバーというのは、結構長く勤務されるのでしょうか。日本の場合だと転勤という制度があって、３年ぐらいで入れ替わるのですが。
A： 離職というのは少なくて、非常に定着してずっと長くやっているケースが多いです、喜んで仕事をしてもらっているみたいなので。
（笑声）このディストリクト・オフィスの現場から来ている方もいらっしゃいますし、これはという人を現場のフィールド・オフィスから引っ張ってくるというケースもあります。委託先のコンサルタント会社から引っ張ってくるという場合もあります。大学からとか、あるいは政府関係の機関から採用してくるという場合もあります。
例えば今の HEC 代表者は、前はコンサルタント会社で働いていた方です。Development andResources Corporation というコンサルタント会社から HEC に来られました。いろいろな経歴を持ったスタッフが HEC で働いているというのも１つの利点かと思いますね。大学の教授を招いて仕事をしてもらうというようなプログラムもあります。あと、ディストリクト・オフィスから HECに来て、担当するプロジェクトに取り組んでもらうというケースもあります。
＜Q： ソフトウェアの拡張はその少ないメンバーで進めるのか？＞
Q： 例えば今、一次元のモデリングシステムを HEC-RAS という形でつくっていると思うのです
けれども、将来的にそれを二次元あるいは三次元のモデルに拡張していくという動きはあるのでしょうか。
A： 徐々にではありますが、動きがあります。川の水理では準二次元というのを今使っています
けれども、土砂の移動については多次元のものを考えています。
将来必要となってくると思います。
4.2.3 Software development（1） Early Software Development
それでは、ソフトウェアの開発についてお話をしていきます。
ソフトウェア開発の歴史、これまでどういう経緯でやってきたかお話しします。どんなリソースが必要か、今はそれがちょっと変わってきているので、そのリソースの変化についてもお話をします。
コンピュータは、昔はハードウェア上にいろいろな制約があって、スピードも遅かったし、計算速度も遅かったというようないろいろな制約がありました。シミュレーションをするときに、私は最初にやっていたのはカードです、メインフレームの大型コンピュータにインプットするというのがコンピュータ・テクノロジー・テクニシャンとしての最初の仕事でした。
どうしてもサイズが限られていましたから、プロセスそれぞれに別個のプログラムが必要だったわけです。HEC-1 ではまず、降雨の解析があって、雨水が地面にどういうふうに流れるかというのはまた別のプログラムがあったわけです。川の流れはどういうふうなルートをたどるかという解析
4-13

には別のプログラムが必要でした。
ハードウェアの進歩によって、HEC-1 をパッケージとしてまとめることが可能になりました。
（2） PC Software Development
現在ではグラフィック・ユーザー・インターフェースが使えるようになりましたから、昔はやっていた“Look andfeel”、見て、触るというようなやり方はちょっとばかげた
やり方のように、もう昔の話になってしまいましたね。
昔のプログラムは全て大型メイン・フレーム・コンピュータの処理用でした。昔はソースコードというのを配布して、それぞれのユーザーの別個のコンピ
ュータで編集してもらっていたのです。ソフトウェアの維持管理においてはパソコンが出てきてから飛躍的に変わりました。コードをメインフレームから PC に変えていくというのがまず我々がやらなければいけない最初の仕事でした。
同じ OS でどの PC にも使える実行可能なコードをまず配布していきました。
日本はパソコン開発の上で先導的役割を果たしてきましたから、パソコンの能力がいかに早く拡大していったかというのは皆さんよくおわかりのことだと思います。
データをインプットする上で、ユーザーをアシストしていくためにメニュー・プログラムというものをまずつくっていきました。今使っているグラフィック・ユーザー・インターフェースの前準備の段階としての作業でした。
（3） Modern software development
1990 年ぐらいでメインフレームからパソコンへの転換というのは行われたわけですが、さらにコンピュータ科学の能力というのはどんどん進歩しました。1990 年に HEC では次世代ソフトウェアの開発に取りかかりました。RAS とか HMS だとか、Reservoir System の開発のソフトウェア等
がそのさきがけとなってきたのです。
次世代ソフトウェアについてちょっとお話をしてから、1996 年から始まった統合システム（インテグレーテッド・システム）についてお話をしていきます。
新しいコンピュータの能力が進歩してきた中で、HEC の内部ではチームをつくってその進歩への取り組みを進めてきました。コンピュータ・プログラミングを行っていく上で文化的に変わってきたと言ってもいいと思いますが、HEC 所長のデーヴィスさんがそれについて触れていました。
昔は１つのプログラムに１人のエンジニアというソフトウェアの開発をしていました。HEC-2
はビルさんという人が全部一人でやっていたので、HEC-2 についてのいろいろな専門的な情報というのは、そのビルさん一人の頭の中に入っていたわけです。これは FORTRAN を使ってプログラミングをしていました。次世代ソフトウェアの開発では新しいコンピュータの進歩に対応しています。
HEC の部署を再編して、いくつかのチームを作りました。工学上のアルゴリズム、十進法の計算法、ハードウェア環境、コード構成と言語、ユーザー・インターフェース、データ管理とソフト
ウェアの統合をそれぞれ見ていくチームです。チームがそれぞれのアイテムを見ていくという体制で取り組んできました。
4-14

技術的な仕事ということもあるのですけれども、HEC のいろいろな部署からの人が集まっているということで、いろいろな新しい考え方が融合して新しい考え方をつくり出してきたということが重要だったのです。そして、いろいろなところの部署から集めてきて混合チームをつくって、「う～ん」というような状況をつくり出してしまったわけです。昔からやっていた人が昔からのやり方を踏襲するということはもうできなくなったわけです。だから、「う～ん」という状態になってしまったわけです。
（4） Software Development Goals
次世代ソフトを開発する上でどういうことを目標、ゴールとしているかというと、我々は水文工学のエンジニアですから、最新鋭の水文工学、あるいは計画の分析を特徴づけていくということがまず注目してやってきたことでした。古いソフトウェアをそのまま新しいものに転換するということではなくて、古いソフトウェアがどういう能力があったのかということを吟味、査定して次につなげていく、新しいものにつなげていくということです。
ソフトウェアを開発していく上で、構成要素としてはコーディング、さらに言語を見ていったわ
けです。さらに、ユーザー・プラットフォームを見ていきました。ソフトウェアを構成するものがどんどん変わっていってしまうので、コーディングとかランゲージを見ていくのは非常に大変な仕事でした。
FORTRAN、C++、あるいは Java というように移っていきましたが、やはりコンピュータの科
学的な技術が進んでいくのに、それに歩調を合わせていくというのは非常に努力の要ることでした。
ソフトウェアを開発する上で先導的な立場をとっているというよりも、もう産みの苦しみを味わう
ような、そういう大変な作業で取り組んできました。行き止まりに突き当たってしまって、もう一回研究をやり直したというようなことも多々ありました。
新しいソフトウェアの大きな能力の１つがグラフィカル・ユーザー・インターフェースというものですが、広範にわたってディスプレイができる、あるいはグラフができるというものが大きな特徴です。ソフトウェアが非常に柔軟性を持って、ほかのケーパビリティをも取り込めるように、このソフトウェアのケーパビリティを効果的にどんどん拡大していくというのが大きな努力の目標でした。
１つ以上のプログラムをサポートできるライブラリもつくっていきました。あと、ソフトウェアのメインテナンスにかかるお金をできるだけ削減していくということにも注力しました。そしてもう一つ注力したことは、ソフトウェアを常にパブリックドメインにおくのだということを念頭に置いてやってきました。
アメリカ以外の国は、なぜそのソフトウェアをいわゆるパブリックドメインに置いておかなければいけないのだというのを不思議だなと思われる方がいらっしゃられるかと思います。HEC のソ
フトウェアの開発の資金というのはアメリカの税金で賄われているのです。やはり税金で賄われているからには、当社が開発した製品というのは公共の用に資するべきだというのが基本的な考え方にあるのです。そして、広く使っていただければ、それだけ我々にとっても利点があるというふうに考えています。

4-15

（5） Software Development - continued
これまで、ちょっと前には随分トレーニングを行ってきました。
マイクソフトのWindows とUnixと両方で開発を開始しました。マルチ・プラットフォーム・ケーパビリティというのがありまして、
マイクロソフトのパソコンでも Unix でも両方とも使えるという非常に使い勝手のいいものです。
それをやるのは非常に大変でした。
最初の River Analysis System はマイクロソフトの環境でしか使えませんでした。マルチ・プラ
ットフォームにするよりも、MS に限ってしまった方が早く、そしてよいソフトウェアが開発できるのでそういう形になったわけです。HMS はマルチ・プラットフォームを Unix でギャラクシー
と呼ばれる言語でスタートしました。
ギャラクシーはJava の前のバージョンと言えると思います。
（6） プログラミング言語：Java オブジェクト指向
HMS はギャラクシーから始まって Java を用いるようになりましたが、Java が発展してきたので、ギャラクシーは余り使い勝手がよくなくなってしまいました。当時はギャラクシーは最新鋭の技術でしたが、コンピュータ技術が進むにつれて、ギャラクシーは Java にとってかわられてしまったわけです。もうすぐ出る HMS Ver.3 は、すべて Java で作成しました。
グラフィック・ユーザー・インターフェースの開発は非常に難しく、大変でした。ブッシュ大統
領もよく言う、“It's hard”、（笑声）難しい、難しいと言っていたわけです。
FORTRAN から新しいシステムに転換していくというのはなかなか大変だったのです。特に、Unix は扱いが大変でした。大学の人に来てもらって、C++についてまず講義をしてもらったわけです。新しいソフトウェアの開発環境において、いわゆるオブジェクト指向の流儀に慣れる必要がありました。カルチャーショックでした。
オブジェクト指向のデザインとコーディングというのは、FORTRAN から転換していく上で非常に難しかったのです。
「改宗する」ぐらいの大変さがあったわけです。このオブジェクト指向ということを理解して、そして「これだ！」というふうにスタッフがわかったときに、もうこれしかないというように、宗教を広めるみたいな感じでオブジェクト指向（オブジェクト・オリエンテッド）
を説いて回るようになったほどです。
（7） Guiding Principles
HEC では、実証された最新の技術やコンセプトを水文エンジニアリングに適応しています。それは常に連携をとってディストリクト・オフィスからのニーズの解決に役立っています。そのために、ソフトウェアのデザインをしていく上でディストリクト・オフィスのエンジニアに HEC に来てもらって、取り組んでもらうというような活動もしてきました。
Windows と Unix 両方ということはさっき申し上げました。
オブジェクト指向のプログラミングのメリットの例は、再利用可能なライブラリです。
よい例が、グラフィックスです。HEC のグラフィックス・ライブラリを使って下のグラフ等をつくってきた
わけです。

4-16

（8） DHI へのグラフィック・ライブラリーの外注
資金的にも余裕がなかったので、このグラフィック・ライブラリーを開発していく上で、デンマークの会社と契約・ベースで取り組んだことがあります。そして、その契約の中には、HEC が自
由にソフトウェアを、実行ファイルで配布できるという条項を盛り込んでおきました。ですから、
HEC がそのソフトの使用権を取得すると、ディストリクト・オフィスはその使用権を別個に取得する必要がなかったのです。しかし我々のグラフィック・パッケージを変更するときには、またデンマークに頼まなくてはならないわけです。
デンマークの会社は我々以外にもほかに取引先がありますから、我々がこれと言うパッケージをそこのデンマークの会社に頼んでも、すぐに変更してもらうということはなかなか難しかったのです。当然、いい会社でしたから、我々よりもより優先順位の高いお客さんもいたわけです。まあ、
それはしょうがないことだと思います。
「OK、もう新しいソフトウェアについてはもう十分わかったので、自分たち独自でパッケージを開発していこう」ということを決めたわけです。
HEC のグラフィック・パッケージは HEC の RAS とか HMS とか ResSim とか Flood Damage
Analysis とかのすべてのソフトウェアに使われています。
グラフィック・ユーザー・インターフェースのデザインも大きな仕事でした。コンピュータ・イ
ンターフェースを水文のエンジニアとしてどういうふうに設計したらいいのかということを、随分たくさんのエンジニア間で、会議で討議してきました。
水文エンジニアとコンピュータ技師を協調しながらやっていくためにどうしたらいいかということを述べた文献を文書で出したりということもしてきました。そして、その文献を新しいグラフィック・ユーザー・インターフェースを開発していく上で活用しました。基本的なソフトウェアを開発して、それを正しく適用し、それを使ってもらう。そのいい例としてグラフィック・パッケージと GIS というソフトウェアの開発があります。

4-17

（9） GIS システムの開発
1970 年に HEC で GIS システムを開発しました。地図データを入れて、分析できる最初のシステムでした。
当時としては時代をリードするような非常に新しいものでした。
80 年代になって ESRIの協力があって、やっと GIS も一般的に使われるようになってきたわけです。
HEC で GIS とか Arc GIS とか ARC/INFO を活用したソフトウェアを開発しました。それらを発展させて利用するためにユーティリティをきちんとつくっておくのが重要です。
（10） HEC-HMS Graphic User Interface

グラフィック・ユーザー・インターフェース（GUI）について、具体的に見ていただきます。
これは水文モデリングシステムです。ウィンドウズのエクスプローラとこのインターフェースとはちょっと似たところがあるとお気づきの方もいらっしゃると思います。GUI には４つコンポーネントがありまして、ネットワークがここに描写、表現されています。ウィンドウズのエクスプロー
ラでもファイルが出ているように、ここに表示されています。これも水文に関しての表示です。シ
ステムの絵が出ていまして、河川のサブ流域ナンバー１が書いてあって、この流域の一部、サブ流
域ナンバー１が示されています。データ編集をする場合には幾つか方法があるのですけれども、デ
4-18

ータのアクセス法は幾つかありまして、ここにウィンドウがあって、ハイライトされたデータのエ
レメントはこの下に出てきています。最後のところですが、どういう活動が行われるかということについての情報がこの右下のところに出てきています。
これは HMS の新しいバージョンです。ほかのソフトウェアはまた別の考え方を持った人がやっていますから、これとはまたちょっと違ったものになっています。１つの方法だけで、これでやろうというように、全員が納得して合意したというようなものはありません。それぞれ開発チームが検討しながらやっていくということが可能なわけです。HMS の担当の人はこれが一番いいと考えていますし、Reservoir System の担当者は、うん、これはまた Reservoir にも使えるなというように考えるかもしれません。
データを関数を含めて標準化することは、それを編集する上では非常に強力な武器になるものだと思います。流域の状況を記述するだけではなしに、いろいろな水の流れとか、あるいは雨水の動きをつかむこともできます。
雨量と流量は、データが対になっています。ストリーム・システムは、中で流れがどういうふうに流れていくかの、ルートを見ていくシステムです。さらに、アウトプットを見ていく上でも使うことができます。
このツリーの中に結果が組み込まれています。このシミュレーションを見たいというときにはそれをハイライトして、クリックしてグラフの上で再現することができります。それぞれのグラフィック・デザインを見たいときにはそこにアクセスしてクリックすれば、その結果が一目瞭然に出てきます。非常に強力なインターフェースだというふうに我々は確信しています。
（11） Sources of Funding
では、資金源についてお話しします。
主に３つあります。①研究開発（R&D：研究開発に応用するためにこの工兵隊の Research &Development Division）から出ている場合と、②工兵隊内の Automated Information Systems、（「AIS」と呼ばれる）、③ディストリクト・オフィスのそれぞれの要望に基づいて資金が出される
場合、の３つです。
HEC がそれぞれの現場のオフィスといろいろ相談して、年間のそれぞれの事業ユニットをつくっています。そしてこのフィールド・オフィスの代表が集まっていろいろな年間の事業のうち、どれに優先順位をつけて実行していくかということを投票形式で決めています。主に RAS とか HMSとかいったソフトウェアはこの R&D からの資金で賄われたわけですが、一部、「Specific Offices」と呼ばれるディストリクト・オフィスの資金で賄われた部分もありました。
Corps Water Management System はAutomated Information Systemにサポートされていますが、それについては後ほど説明します。
かなり大きなソフトウェアの開発は、AIS が関与しています。工兵隊すべてにわたって使えるよ
うな大きなプロジェクトがこの Automated Information System によって行われています。このAIS というのはそれを十分賄うだけの規模があります。
「Life Cycle Management of Information System」という非常に詳細にわたったシステムがあるのですが、AIS システム開発の上でやっている軍としての取り組みのシステムとなっています。
まず、非常に圧倒されるようなプロセスなのです。開発工程の全体において、ユーザーのニーズを
4-19

インプットしています。それぞれ特定のオフィスについてはさっきお話ししました。
Life Cycle Management System については私のこの文献に詳しく述べてありますのでソフトウ
ェア開発の担当者の役割についてお話をしていこうと思います。
（12） Participants and Roles
開発に当たってメンバーは、HEC からも学会からもユーザーであるディストリクト・オフィス
からも、さらに私企業、連邦機関からも参加してもらっています。HEC の責任範囲としては、デザインして、開発して、配布して、それを管轄していく役割を担っています。
開発チームはまず主導的な立場のエンジニア、これは HEC の人間ですけれども、チームには１人か２人の HEC のアシスタントが入ります。さらには、私企業の請負業者が契約ベースで入ります。ユーザーが広くテストをしてもらう、そういう社会ができ上がっています。請負契約については後ほど詳しく申し上げます。
学会、大学からはソフトウェアの活力、あるいは信憑性についての最新鋭のアドバイスをしてもらっています。そして、学会に頼んで我々が提案するものをそれぞれ独自の立場でレビューを行ってもらっています。
やはり大学となると現場に即した実際的な考え方よりも、将来志向で考えてしまうという傾向があります。ですから、大学と実際的な現場のオフィスとのギャップについて、その橋渡しをする役
割を HEC が担っています。ですから、大学では HEC は余りにも実際的、実務的過ぎるのではな
いか、一方、現場のオフィスでは、HEC というのは余りにも理論的過ぎるのではないかというよ
うなことを言われますが、そういう批判があることもいいことだと思います。
ユーザーは主には工兵隊内の担当者なのですけれども、そういう人に HEC に来てもらってチームに参加してもらいます。結果をいろいろ査定してもらって、フィードバックしてもらって、そしてソフトウェアの考え方、そしてクオリティ・コントロールの観点においてもこういうフィードバ
ックを外部からしてもらうというのは非常にいいことだと思います。
知的所有権を持った、ソフトウェアの所有権を持ったベンダーについてはまた後で詳しく述べて
いきます。
私企業、
さらには連邦機関のそれはどれぐらいのことができるかということにも関連してきます。
技術的に違う見方、あるいは当社の製品の代替物となる製品も出してくれて、いろいろな見方、考え方を交換できます。GIS ソフトウェアの場合はこの知的所有権を使っています。HEC の中で不足する部分があれば、その製品で埋めていくようにしています。
（13） Software Development Processes Continued
ソフトウェア開発プロセスで Waterfall 方式を採用しているのか、Spiral 方式を採用しているのかという質問がありました。
Waterfall 方式の場合は一気に開発してそれをテストして、テストされて実証されたら、また新たに開発してということを一本道に行っていくのが Waterfall 方式です。
もっと自由にできるのが Spiral 方式で、プロトタイプを作成し、結果をチェックして変更を加える、またテストして変更をする（フィードバックする）ということを自由にできるのが Spiral のや
り方です。
4-20

理論的には Waterfall 方式でも Spiral 方式でもいいのですけれども、実際は Waterfall 方式とSpiral 方式、これを併用して作業しています。修正する場合、Waterfall だと１回完結して次に行くのですが、Spiral だと開発順序を遡ってもう一度作り直すということができります。
（14） 外注比率
HEC が直営でどれぐらいやって、外部にどれぐらい請負契約ベースでやっているかというお話です。業務範囲がいろいろ広範囲にわたっていますので、HEC の職員だけでは全部網羅し切れないので、外注が必要となっています。HEC のスタッフの能力を広めていく上でも外注（契約）は有効です。
別添のレポートの中には、どういう契約書を使っているかというのが、その実例が入っています。
具体的には、競争入札をおこなっています。だれでも自由にプロポーザルを提出してもらうことが可能です。
まず、一般的な能力とそのコストがどのぐらいかかるかということだけを考えてます。特殊な、特にこのソフトウェアを開発するのだということについては、最初の契約では触れていません。それぞれの業者はどういうことができるか、それに対するコストがどれぐらいかということを最初に提案します。
その業者の能力とコストに基づいて、どの業者を使うかということを HEC が決めています。コ
ストが低いからといってそれで選ばれるとは限らないわけです。技術的な高さとコストとの兼ね合
いで契約者を決めていきます。安ければいいというわけではありません。
（15） タスクオーダー
次に、契約者が決まったら、どういう仕事をしてもらうかというタスクオーダーを発行します。
ソフトウェアのデザインをするのにどれぐらいのケーパビリティがあるかとか、実際どういう開発
やメインテナンスをするのか、そういうことが契約のタスクオーダーに入っています。100 にも上るタスクオーダーがあり、通常、契約期間というのは５年ぐらいです。
協力的研究開発契約（Cooperative R&D Agreement）を結び、HEC がその契約者にお金を払います。HEC の資金です。
（16） ESRI との協定
工兵隊と ESRI との間では、正式な協定が結ばれています。ESRI は実用プログラムを作成する
上で、HEC を支援しています。必要な機能を HEC で書面化し、ESRI で作成して貰い、HEC のパッケージにそれを盛り込んでいます。
実際に両者の間でアグリーメントを結ぶ上では、これはいいぞという利点が双方にないと上手くいきません。当社のソフトウェアについて、GIS を開発・利用できるということが HEC にとっては利点です。水理エンジニアリングについて、また新しい使い道があるので、そういう点で ESRI
にとっては利点なわけです。また、HEC は広い範囲にわたるユーザーがいますので、こういった
ESRI のユーザーの情報も使えるということは、HEC にとっては非常に有利な点です。

4-21

（17） ライブラリの標準化
開発していく上ではコードとかライブラリとかデータをできるだけ標準化していこうという努力をしました。開発者にとってもユーザーにとっても、この標準化は非常に利点がありました。
とはいえ、開発言語については FORTRAN、Java、（今ちょっと Java に傾いていますけれども、）などを完全に標準化してしまったわけではありません。HMS では FORTRAN のライブラリがあって、水文のプロセスごとにそれぞれ独立したプログラムになっています。グラフィック・ユーザー・イン
ターフェースのプログラムはすべて Java を使用しています。Java から FORTRAN ライブラリに呼び出して、そして詳細な水文の計算をするようにという指令を出しています。
グラフィックについてのライブラリ、これはもうさっきお話ししました。
インプット、アウトプットのプロシージャについてのライブラリもさっきお話ししました。
データの管理、データの保存のついてのライブラリ、これも１つの大きなライブラリです。
（18） 外国語インターフェース
HMS の最新の開発の中では外国語とのインターフェースというのがあります。ここでは、外国語とのインターフェースについてお話をしていきます。
Java システムは外国語を扱う上で大きな利点があります。HEC では「Java ソフトウェア開発者キット（SDK）」を使っています。誰でも容易に手に入れることができます。Java の開発者は、「ただ開発するだけではなく、ユーザーがどの外国語でも使えるということが大事だ」ということを理解していました。
Unicode というものを Java で使いまして、（90 万の文字を使っているというふうに私は聞いているのですけれども、）どの言葉でも、サンスクリット語でも日本語の漢字でもどれでも使える、と聞いています。実際に今世界で使われているどの言語もこれに入っています。この機能は「Resource
Bundle」（リソースの束）と呼ばれています。テーブルを作成し、左には英語で記述し、イコールの右側は他の国の言語で記述します。ソースを直接書き換えなくてもこのテーブルを書き換えることで翻訳が可能なのです。要素名をここに書きなさいというふうにプログラミングして、スクリー
ンにどういうものが出てくるかというと、リストの右側に出てくるものがそこの指定した場所に出てきます。まだテスト済みではないのですけれども、理論的にはロシア語でも日本語でもこれは対応可能です。イタリアなど数カ国から翻訳してほしいというような要望も HEC に来ています。
ここで、Tool Tip（
「TT」と呼んでいます）を紹介します。カーソルを使うと、アイテムのとこ
ろにカーソルを置くと、風船（バルーン）みたいなものが出て説明がポッと出ます。これを利用す
れば、翻訳や注釈を入れることが可能です。スクリーン上のアイテムだけではなくて、TT のとこ
ろにカーソルを置くとバルーンの記述が出てきます。
HMS ではこの Resource Bundle が３つか４つ使われています。ユーザーは右側を翻訳して、自分の好きな言語に翻訳することができります。HEC が使っているベンダーも非常にこれに興味を持っています。世界でこれを評価してもらえるといいなと私は思っています。ソースコードを配布する必要がないというのがこれで非常に重要な点です。
HMS プログラムは、Java の Resource Bundle という形でエクスキュータブル・コードがまとめられています。ユーザーは HomePage にアクセスして、すぐにプログラムを使うことができり
4-22

ます。
（19） EXE ファイルのみの配布・ソースファイルを配布しない理由
HEC ではエクスキュータブル・コードだけで、なかなかソースコードを配布しないのはなぜかというような質問があります。HEC のウェブサイトにもそれは書いてありますが、２つの方法をとっています。
古いソフトウェアですでに成熟して（バグ取りが大方終わっている）、もう変更がない（バージョンアップの予定もない）分についてはソースコードを配布するというのが１つの考え方です。
新しいプログラムで常に新しい変更が行われているプログラムについては、エクスキュータブ
ル・コードしか配布したくないというのが基本的な考え方です。なぜなら、自分たちの問題でもう手いっぱいなのに、ユーザーさんがソフト・コードを手に入れて、「あ、こんな問題が起こってしまった」と言われても、なかなかそこまで手が回らないというのが現実だからです。
（20） Quality Control パブリックドメイン βテスト
最後に、ソフトウェア開発工程の中で述べたいことは、クオリティ・コントロール、QC の問題です。さっき御質問でもありましたが、ソフトウェアがこれで大丈夫だということをユーザーに確信してもらうことが重要です。HEC の中でも広範囲にわたるテストは行います。標準テストと呼ばれる一連のテストがあって、開発されたソフトウェアについては全てそのテストを行います。それぞれの計算法、アルゴリズムのテストであったり、マスキンガムのテストをしたりもします。ア
プリケーション全体のテストを行う場合もあります。
最後のプログラムはいろいろな細かい、微に入り細をうがったたくさんのテストを経ています。
プログラムを配布していく前に HEC 内部で行っていくテストとして BETA テストというのがあります。実際にユーザーがソフトウェアをテストする BETA テスティングをおこないます。β版はいろいろな入手方法があるのですけれども、RAS についてはウェブサイトにアクセスしてもらえばだ
れでもそれをテストすることが可能です。工兵隊のオフィスだけではなくて、世界中のエンジニアの方にアクセスしてもらってテストしてもらうことが可能です。これは HEC にとって非常に重要なテストです。
プログラムのテストは、これという特定の人に頼みたい場合があります。こんな時でも、頻繁に使ってくれるいいユーザーはだれかということがわかっていれば、いざというときにそのユーザーに頼むということもでき、重宝します。
ダム決壊に興味のある人には RAS とか HMS のプログラムを出して、ダム決壊の結果を査定してもらうということも可能です。
プログラムをパブリックドメインにおくということによって、ユーザーに幅広くテストしてもらって、そのテストの結果をまた教えてもらうという形での公開は、開発側として非常に有用なのです。HEC ではこのような理由でパブリックドメインに公開をしています。
最終版としてリリースしていく前にチェック・リストがありまして、いろいろな項目がこのチェ
ック・リストには盛り込まれています。チェック・リストにはテストとかコードがどういうところで使われたかとか、どこにあるかとかいういろいろな情報が網羅されています。
ユーザーからのフィードバックというのは非常に重要です。ソフトウェア・サポートのところで4-23

もお話をしますが、ソフトウェアは無償配布ですが、エラーがあったらどんどん HEC に直接言ってくださいというアナウンスをしています。もしプログラム・エラーを発見したら、制限なしに
HEC にコンタクトしてもらえるようにしています。
ただ、工兵隊以外の方がプログラムを使う上で支援をしてほしいと言われても、それには応じられません。この点については後でソフトウェア・サポートの中で触れます。
ISO9001 では、実際にコンサルティング・カンパニーでソフトウェアが使われる前に QC 的なところをチェックして、実証していかなければいけないということになっています。取得には非常に広範囲にわたる手続が必要です。ですから、ソフトウェアのこういうテストをしたからきちんとしたものだということを、きちんとした証拠によって実証していく必要があります。
HEC では、この ISO を実際に適用しているというよりも、ISO の考え方を HEC で使っていると言えます。最終的には ISO のプロセスを実際には踏襲するというようにはなると思いますが、今は考え方を踏襲しているという段階です。
HMS の場合ですと、それぞれの計算法にテストのやり方があります。例えば、浸透を考える場
合には、SES Infiltration Technique の基礎式を、MATHCAD というソフトウェアに入れて、アウ
トプットを得ています。HMS の結果と MATHCAD よって計算された結果を比較して検証しています。QC の中でそれも非常に重要な要素を占めています。かなりの作業になりますけれども、降雨の計算とか Infiltration のメソッドとか、Unit Hydrograph、Kinematic Wave という方法があるのですけれども、どの計算法を使うにしてもよいのですが、検証は必要と考えています。
川の流れを追跡するプロシージャは、MATHCAD 計算結果と比較検討することで検証できます。
ISO のプロシージャの中にもそれらの検証は含まれています。
＜Q： RAS の開発費用＞
Q：HEC の開発に関する予算、経費について、HEC-RAS にまとめるときにどれぐらいかかったか。
A：HMS は R&D から 20 万ドルぐらい出してもらって使いましたが、この資金源とは別のところ
からもお金が出ています。GIS サポートなどの場合は年間 10 万ドルぐらい。そのうちの 30％、３万ドルを HMS が使う。ほかの水管理システムの場合、また別のところから５万ドルとか 10 万ドル、HMS がもらってくる。年予算というのは変わるのですけれども、年間、大体 30 万から 40 万ドルぐらい、それぞれ HMS と RAS に予算が使われています。予算が少ないときには 20 万ドルぐ
らいしかもらえない。
Q： 別の言葉にしますと、96 年からということを考えると、８年間ですから、それ掛ける８ぐら
いの経費が今までにかかったと考えていいのですか。
A：当然、開発というのはずっと続くものですから、その時々のものではないのだけれども、大体100 万ドルぐらいそれにかかっています。３～４年にわたって年 20 万ドルから 30 万ドルぐらい使
われて 100 万ドルぐらいになった計算です。HEC-1 との代替、取ってかわるということだけが目的ではなかったのですけれども……。
＜Q： 予算の内訳＞
Q：予算の内訳、外注費、人件費等について、100 万ドルの内訳は？
A：３人ぐらいが担当していました、リード・エンジニアというのはビル・グルーナーという人で、ニーズによってそれに１人とか２人加わったりした。
4-24

人的経費は１人 12 万ドルぐらいです。ただ、直接の給料だけではなくて、管理費、一切合切含
めて１人 12 万ドルぐらい、間接経費を含めてかかっている。直接人件費は年間５万ドルから７万ドルぐらい、もともと HEC にいた人が外へ出てコンサルタントをやっているのですけれども、それぐらいの補助として支払ったということです。
＜Q： 今後の開発予算＞
Q：ネクストジェネレーションについて今、つくられているようなものがどれぐらい予算を組まれているか。
１００万ドル

HEC
全体：５００万ドル

R&D

７つのプログラム
各２０万ドル
１００万ドルフィールドアシスタント
ディストリクト・オフィス

１４０万ドルA：トータルで、R&D からのバジェットが 100 万ドルぐらい、それぞれの主なプログラムに 20 万ドルぐらいというのが１つの予算の見当で、年間で 20 万ドルぐらい１つのプログラムに考えています。水理・水文と貯水池と洪水被害軽減で、それぞれが 20 万ドルぐらい。いつもそれだけ予算がもらえるとは限らないのですけれども、R&D からなかなかお金をもらえないときはもっとフィールド・オフィスに行って、何とか資金援助をしてくださいというふうに頼みに行くこともあります。
HEC の中で R&D が占めている比率というのは 30％～40％ぐらいです。HEC トータルとしては年間 500 万ドルぐらいの予算です。それはトレーニング・プログラムとかソフトウェアのサポー
トとか、研究開発も含めてです。かなり予算のうちの大きな部分がフィールド・アシスタンス、いわゆるディストリクト・オフィスから出してもらっています。ということは、HEC はコンサルテ
ィング会社みたいな感じです。
予算のうちの 30～40％ぐらいが年度の最初にまず割り当てられます。残りの 60～70％は実際にそのプロジェクトが進んでいく中で、ディストリクト・オフィスからその予算年度の中でその都度お金を出してもらっています。30％ぐらいが会計年度の前に来て、その会計年度期間中はディスト
リクト・オフィスからそれぞれ徐々にもらうという形になっています。
＜Q： メインテナンス費用＞
Q：メインテナンスでどれぐらいかかるか
A：５年から 10 年ぐらい前にソフトウェアのメインテナンス業務というのがありました。これは、ヘッドクォーターからそれぞれのディストリクト・オフィスに税金が課されるみたいな形で、上納金みたいな形で割り振ったわけです。
「嫌だ、税金などは払いたくない」と現場のオフィスは言うの4-25

ですけれども、（笑声）やはり政府関係のユーザーというのはサービスを受けた人が払うべきだというように言うわけです。実際にサービスを受けたら、受けた人が払いなさいよ（受益者負担）というのが政府関係のユーザーの考え方です。
現在では、サポートしてもらったら、毎年、毎年のディストリクト・オフィスから寄附みたいな形で資金を拠出してもらっているのです。
HMS や RAS の７つのプログラムについて１つの地方オフィスについて年間 3000 ドルぐらいがサポートの予算です。
４０のフィールド・オフィスがあるので、3000×40 ＝ ＄120,000 ／１本
７本のソフトですから 120,000×7＝ ＄840,000 ／年 となります。
＜Q： サポートの内容＞
Q：サポートの内容は？
A：電話のホットラインのサポートとか、ある程度限られてはいるのですけれども、コンサルティ
ング業務とかそういった支援的な業務です。
＜Q： GUI の比率＞
Q：GUI のグラフィカル・ユーザー・インターフェースの開発というのは非常に困難だったという
ふうに言われていたのですけれども、今の割合として、それに注力するマンパワーは、プログラム
本体と比べるとどのぐらいの割合を占めているのでしょうか？
A： RAS の場合はマイクロソフトを使っていたので比較的少なかった。HMS は C++とか Javaを使って開発したので大変でした。HMS については１人がもうほとんど専任、張り付きで GUI の開発について取り組み、担当しています。
＜Q： インターフェースの共通化＞
Q： インターフェースを共有化するという意味合いで同一のコンセプトのもとで開発しているのか、それとも RAS は RAS、HMS は HMS で、別個、別個でインターフェースをつくっているのかという質問ですが。
A： Data Storage System（DSS）を扱っているチームが１つあります。データ保存システムです。この DSS というのは HEC のプログラムがそれぞれお互いにコミュニケーションするためにつくられたものです。時間と対になるデータ、時系列データのためにこのチームはつくられました。
標準的なデータベースはこの時系列データには余り使い勝手がよくなかったので、DSS がつくられました。例えば DSS が雨水の流量データを受取り、川、あるいは貯水池の水理にこの流量の情報を使うというように使っています。
Q： もう一つ、流量を Data Storage に渡して、そこから別に計算に行くというお話が今ありました。その流量は Data Storage に渡すということだけを考えて渡しているのか、それとも次に何をしてほしいということも含めて渡しているのか、要は全体のコントロールをどうしているのかを聞きたいのですけれども。Data Storage System を使ったデータのやりとりのコントロールをどうしているのか。
A： DSS のデータは、HEC のソフトですべて読み込めます。それがスタンダードになっている
のです。
4-26

アプリケーション間は DSS のフォーマットのファイル渡しでおこなっています。
また、付加データとして XML が使えないかというのは今検討中です。
GIS のデータ・フォーマットを決めたときは、RAS とか GIS インターフェース、いろいろなチーム、フィールド・オフィスやら政府機関やら ESRI、ベントリー、大学関係者、コンサルタント
から HEC に来てもらって、GIS のデータを RAS と GIS とどういうふうに共有するか、そのフォーマットについて、検討しています。フォーマットができますと、今度は ESRI とかベントリーが自社で GIS のフォーマットをつくるという形をとっています。このフォーマットというのはもう公に出していますから、ユーザーでどんなプロシージャを使われているかというのはすぐわかると思います。
具体的な作業は、GIS の水理・水文についての専門家、ディビット・メイドメント教授にヒアリ
ングを行ないました。この教授の博士号研究の２人の学生が HEC に来て仕事をしています。
逆に、Arc Hydro の開発については HEC のスタッフもいろいろ関与しています。
GIS については大学とのコネクションで技術を吸収しています。
（21） XML について2000 年の話ですけれども、アメリカのいろいろな機関で、これについて盛んな議論が行われていました。そしてアウトプット・レポートをつくるときに、この HMS の中で XML を使っています。
テンプレートを当初、HEC から出して、そしてユーザーが自分のアウトプット・レポートをそのテンプレートに基づいて修正していくことができります。サブ・スタンダードのアウトプット・レ
ポートというのはもちろん我々から提供しますけれども、そうすればユーザーで非常に柔軟性を持って使ってもらえます。連邦の機関ではデータというのは共有したいのですけれども、なかなか予算が取りにくいのが現状です。ですから、プロジェクトのひも付きにして、そういうことを進めていく、そして予算を取るという形で進めています。
Q： 今、XML が外部に出すときに使われていると言っていましたけれども、Data Storage System
でやりとりをするときにはそれが使われているのか、使われていないとすれば何でやっているのか。
A： アウトプット・レポートを構成するときにだけ使っています。DSS でのやりとりは使っていません。DSS ではファイルで渡しています。
＜Q： Data Storage System について＞
Q： その DSS の中にもちろん時系列データもあるし、あるいは GIS データというのもあると思うのですが、その GIS データについてはもう Arc Hydro そのものになっているのでしょうか。
A： 空間的なデータ、空間的な配置というものを DSS の中でやっています。
＜Q： 学会との関係＞
Q： 先ほど開発したソフトの精度の管理の件でいろいろなテストのランドマーク等をお聞きしたのですけれども、アメリカの土木学会（ASCE）とプログラム自体の精度をチェックする等、そういう関係は持たれているかどうか。
A： 精度管理は直接はやっていません。アメリカの土木学会は HEC が出したガイダンス・ドキュメントそういった書類やガイダンスをレビューする形で関係しています。確かにソフトウェアの4-27

レビュー自体はもう本当に業界の人、あるいはユーザーがやります。
直接は関与していません。ドキュメントのレビューだけです。
（補足）「Hydraulic Engineering Manual」というのがありますね。あれを ASCE に頼んでレビューしてもらっている。今の話では、ソフトウェアの精度管理は頼んでいないけれども、一般ユーザーがいろいろ言ってくれるから直せるということだと思いますね。
＜Q： 著作権について＞
Q： 日本では実際にプログラム・コードを書いた人は著作者人格権を持ち、その人の許可なしにコードを書き換えることはできないということになります。そうすると、アメリカでもそういう同
じような著作権があるのか。
もしあったらそれはソフトウェアを後で違う人が書き換えるときには、書き換えていいというような契約をしているのかどうか。
A： 著作権の使用についてはいろいろ調べました。法的ないろいろな難しい点があります。まず
ソフトウェアを仕上げてしまって、コピーライトを確立して、一たん完成してしまったものはコピーライトが確立します。何かまた変更したときはまた別の著作権が必要になってきます。開発途上でいろいろ変更があるとコピーライトについても非常にややこしい点があります。
ソースコードなりエクスキュータブル・コードを変更しようと思ったら、これは工兵隊からの変
更ですよというように証明しないと問題になります。
ユーザーがソースコードをいろいろ変更したときに対応した経験がありますが、どれだけ大変な思いをして対応したかというのは、本当にもう口では言えないぐらいのものでした。メイン・フレーム・コンピュータを使っていた時代にソースコードを一般に出していたのですけれども、プログ
ラムの中身についてのサポートをしていたことになり、予想以上に大変でした。
4.2.4 Software support（1） Software support
ソフトウェアがちゃんと生命を持って生き生きと活動しているための２つの重要な点があります。
これといったメインテナンス法が確立しているわけではなく、常に変化していますから非常に取り扱いが大変です。
まず制度上のサポートが必要です。工兵隊、さらには HEC からの制度上のサポートが重要です。
これは大事な製品ですから、ちゃんと人や資金などを確保して、継続的なサポートをしていかなけ
ればいけないというふうに制度的に決めてサポートしていかなければいけません。
資金は常に変わりますけれども、サポート自体は常に継続的に行っていかなければいけないのです。
制度的なサポートが継続的に得られた次は、技術的な能力の高さが必要になってきます。ソフト
ウェア開発におけるあらゆる領域で、高い技術力を保持していかなければいけないということがHEC の理念です。やはり DHI とか USGS といったどんなソフトウェアの開発者に聞いても、この２つの問題がお金を投資していく上で、ソフトウェアのサポート上非常に重要なことと、同じことをほかの開発者も言っています。
4-28

ソフトウェアの配布と、さらにドキュメントを出していくということもまた別の意味で重要な点です。Executables source code の話は先ほどしましたが、書類、文献を出していくことも重要です。
昔、緑色をしたマニュアルが HEC にあったのですけれども、ユーザーズ・マニュアルとして非常に有名でした。あとはウェブサイトからダウンロードもしていただけます。
RAS の新しいプログラムが出ますと、１ヵ月に 6,000～7,000 ぐらいのダウンロードのアクセスがあります、非常に人気のあるソフトウェアなので。工兵隊から、アメリカのコンサルタント会社、あるいは世界中からたくさんのウェブサイトへのアクセスがあります。これも１つのすばらしいソ
フトの配布の方法ではあると思います。当然、このウェブサイトを運営していく上では資金がかかります。
このウェブサイトではウェブマスターとか、あるいは HEC の RAS とか HMS を扱っているチー
ムのリーダーにコンタクトしてもらえることができます。名前は公表できませんが、技術的な、指導的な立場にいる人たちともアクセスは可能です。
ユーザーサポートについては、工兵隊と工兵隊外部に対してはこのサポートの仕方について非常に大きな違いがあります。
この点についてはウェブサイトでも説明を載せています。
ソフトウェアを講入してもらっている工兵隊のオフィスには、直接的にサポートしています。工
兵隊外部へのサポートは我々ベンダーという呼び方をしているのですけれども、そういった業者を通じてサポートを行っています。
例えば、エラーがあったよという報告があれば、それはもう制限なく受け付けています。エラーがあったら、もうどんどん HEC に言ってきてくださいというようにしています。これは、世界中
で HEC のソフトウェアがテストされているということになるのです。
いつアップデートするのですか、ニューバージョンはいつ出るのですかという質問があったかと思うのですが、ディストリクト・オフィスからこれというニーズがあった場合にアップデートを行っています。そして、アップデートがディストリクト・オフィスからいろいろ一定数出てきて、さらにそれに対するバグを解決した場合に新しいバージョンが出されます。
（2） Vendors of HEC Software
業界とのいろいろな双方向のやりとりをする中で、ベンダーの働きというのは非常に重要な働きをしています。HEC が一般の人との交流を持つ上での大きな役割を果たすのがベンダーです。HEC
から一般にサポートがされなくなってしまうと、小さなソフト会社とかそういったところがサポートをするようになると思います。そして、工兵隊以外の方から HEC に例えば電話で問い合わせが来ると、我々はベンダーにそれをつなぎます。
土木研究所もベンダーの１つになることは可能です。
ベンダーになるのに、特にこれという制限とか規制とかはありません。いろいろなサービスをベンダーが提供しているのですが、ソフトウェアとかドキュメンテーションを配布するだけだったり、あるいは電話でのホットライン・サポートをベンダーがする場合もあります。エンジニアリング的なサービスをしてもらえるというのも非常にいい点です。
また、このベンダーが新しい顧客を開拓してくれているのです。トレーニングコースのビデオテープなども配布していますし、トレーニングをしてくれるベンダーもいます。よいベンダーというのはソフトウェアを配布するだけではなくて、エンジニアに関する支援をしたり、あるいはトレー
4-29

ニングをしてくれるというのが本当の意味でいいベンダーだと思います。
さっきショートコースについてお話をしましたけれども、ASCE といった大学関係者・政府関係、あるいは民間企業もそういうショートコースを担当してくれています。
１プログラムのベンダーになるには、200 ドル払ってもらっています。
お金を払うことによって、安易にベンダーになりたいということを防いでいます。200 ドル払うからには、やはり真剣にベンダーになってもらうことを考えてもらうというようにしています。
ベンダーを使うことによって、HEC は工兵隊以外の人たちとも交流を幅広く持てるようになっています。ベンダーは HEC から直接サポートを受けることが出来ます。優秀なベンダーだったら
質問のほとんどをベンダー自体でその答えを見つけることができます。どういうふうにソフトウェアを使ったらいいのかということがわからない場合は、ベンダーは HEC に問い合わせてきます。
ベンダーは 10、あるいは時に 100 ぐらいのユーザーがいて、その手助けをしています。皆さんからの御質問もあるのですけれども、HEC 内部でも、どうやってそのベンダーをコントロールしていくのだという問題が１つあります。ベンダーがどういうことをしているか、ベンダーの活動についてのクオリティ・コントロールというのができたらいいのですけれども、いろいろな難しい法
律的な問題も絡んできていますので、公的な意味でのベンダーのクオリティ・コントロールは、実際はできていません。
ソフトウェアのサポート、あるいはベンダーを使うことについて何か御質問はありますでしょうか。
＜Q： ベンダーのクライアント＞
Q： ベンダーのクライアントというのはどういう人なのでしょうか。
A： コンサルティング会社であることもあるし、個人の場合もあるし、別のエンジニアリング会社であることもあります。例えば、州政府がベンダーになるというころもあります。HEC のソフ
トウェアをイリノイの水資源局ではよく使ってくれていますから、イリノイ州の水資源局が手助けする部分もあります。連邦政府でもベンダーとは言えないのですけれども、同じような役割を果たしています。
National Resource Conservation Service（自然保護局）、Soil Conservation Service（土壌保全局）と同じようなやり方で、こういった組織が HEC に直接資金を出してくれています。ディスト
リクト・オフィスが出しているように。
その政府機関に５人から 10 人ぐらいのエンジニアがいて、彼らがその管轄のオフィスをサポートしている。１つのグループに HEC のサポートを集中すれば、このグループからまたそれぞれの管轄のオフィスをサポートするというやり方をしています。
＜Q： ユーザーのニーズを把握する際のベンダーの役割＞
Q： ユーザーのニーズを把握するときに、ベンダーというのは有効に機能していますか、それはディストリクト・オフィスにテクニカル・サポートをするのと比べて有効に機能していると思いますか。
A： いいエンジニアリング会社はすばらしいサービスをし、中には最低限のサービスしかしないところもあるし、やはりいいところからはちゃんとニーズをつかめるし、ベンダーの質にもよるということです。HEC の職員よりも優秀なベンダーもいるそうです。
4-30

ベンダーはサポートしている相手に様々なエンジニアリング・サービスを提供することで、コストをもらっています。ユーザーとベンダー間での契約については、HEC はタッチしません。サービスの善し悪しによってどのぐらいお金をもらえるかが決まってきます。
4.2.5 Anatomy（1） Anatomy of a Software Development Project
次のセクションは、ソフトウェア開発プロジェクトの実例についてです。
これは新しい Reservoir System のプロジェクトの開発です。ソフトウェアが完了した４～５年前にこのニーズをつかんでソフトウェアの開発に取りかかりました。新しい技術やデータが出てきていますから、昔のソフトウェアはどんどん古い、時代遅れになってしまいます。このようなニーズ応えるためには、５年ぐらい前に開発が始まっていないといけない。実際のソフトウェアが世に出されるのは５年後ということです。
HEC の内部に「チャンピオン」と言われるような人がいて、工兵隊内部でのソフトウェアの開発の推進力となっています。一つのソフトを開発するのに大体４年ぐらいの期間が要ります。技術がどういうものかを見極めるだけではなしに、実際にかかる資金を確保することもこのチャンピオ
ンの大きな役割です。
資金が集まった、そうしたら今度開発に取りかかっていくと、次はどういうニーズがあるかを突き止めていかなければいけないわけです。この Reservoir System の場合は、現場のフィールド・
オフィスの人にどういうことが要求されるかという Requirement Document、要求事項というものをつくってもらいました。
ある程度 R&D からもお金が出ますけれども、実際はフィールド・オフィスからかなりお金が出ています。開発の実作業は、３年ぐらいかかります。その内訳は、デザインが１年でコードデベロ
ップが１年です。さらに、リリースの前に、いろいろとテストしたり、書類化したり、あるいは BETA
テストというのを積極的に行います。
次はメインテナンスで、これは限りがありません。大がかりなソフトになりますと、開発して、さらに改良、さらに新しいバージョンを出すとなると 10 年以上の年月を要していると予想しています。
その 10 年の間にまた新しいコンピュータ・サイエンスが出てきて、またさらに改善しなければいけないというケースも有ります。
（2） HEC Res Sim, Reservoir Analysis Version 1.0 Release Fall 2002
「Res Sim パッケージ」と呼んでいますが、開発に当たって、いろいろなニーズをフィールド・
オフィスの人と相談して確認していきました。
前のソフトウェアではこういったことはできませんでした。Corps Water Management System、
工兵隊水管理システムの中で作動することだけを考えていましたから。CWMS については後でちょっとお話をしますが、どういうことが必要かをこうやって長々とリストにしてあります。
これは今、一番新しい HEC のモデルです。最新の機能（GUI であり、コードであり、グラフィクス）を備えています。

4-31

（3） Anatomy of HEC-Res Sim Development
まず、HEC-5 に取って代わるものが必要でした。新しい運営ルール、オペレーション・ルールというものも出てきましたし、新しいインターフェースとか、マルチ・プラットフォーム、ケーパビ
リティに対応していかなければいけないというニーズがあったのです。
それが1996年あたりです。
1997 年にサポートを始めて、大体資金も 97 年ぐらいに調達しました。97 年、98 年に細かいニーズを見ていって、要求事項を文書化していきました。
コードが 1998 年から 2001 年にかけて開発されました。2001 年から 2002 年にかけてソフトウ
ェアのテスト、文書化、さらには BETA テストといったことが行われました。
まず、工兵隊のオフィスに 2002 年に配布を始めました。工兵隊からのフィードバックに基づいていろいろ改定してから、実際に一般用に公開していきました。プロジェクト・エンジニアとか
HEC の人とか、さらには IT の専門家更に、２、３人いつも学生も開発に参加しました。開発の多くの部分は外注を使いました。このソフトはマルチ・プラットフォームだけではなくて、クライア
ント・サーバー・テクノロジーも応用されています。その意味では、非常にハイテクな技術を持った外注が必要だったわけです。
コストは 100 万ドルほどかかりました。作業分担は HEC と外注で半々ぐらいです。
Res Sim の開発について、どういうタイムラインで行われたかを今ざっと見ていただきました。
（4） The Real World Today
次に、どういう問題が今あるかというのを見ていきます。
Waterfall のように直線的に工程がつながっていく手法で開発をすることは、理想ではあるのです。しかし技術がどんどん変化していきますから、なかなか実際はそうはいかないようです。開発
の上でそのような技術の変化が一番大きな問題でした。オペレーティングシステムとか、言語が変わっています。ソフトウェア開発の環境自体が変わってしまうわけです。直線的に行けばいいのですが、周期的にグルグル、開発した、試してみた、だめだったらまた再開発した、試してみた、まただめだったというふうにグルグル回る、スパイラル方式での開発になっています。
開発の中でどうしても問題が出てくるのはつきものですので、やはりバグというのもあります。
もうこれで開発は終わり、そして今ソフトウェアを世に出していくという決断をするのは、マネ
ジメントの責任です。
資金が尽きてしまったからもうストップという場合もあるでしょうし、（笑声）時間が随分開発にかかってしまって、ユーザーから早く出してくれということで、もうここで開発終了という場合も考えられます。
２、３年前の中央大学での講演で、DHI ともお話をしたのですけれども、昔はソフトウェアの開発というのは８割方がテクニカルなもので、20％ぐらいがアウトプットとかディスプレイの問題でした。ところが、この比率が今ではもう逆転しています。いろいろなグラフィックスとかデータベースの技術が要求されてきていますから。
水文のテクニカルな部分の要求されるものは 15～20％ぐ
らい、コンピュータ・サイエンスに関する部分がもう 80～58％を占めています。
コンピュータ能力が上がっていますけれども、それに伴ってソフトウェアへ要求されるものもどんどん大きくなってきています。

4-32

4.2.6 Integrated system（1） Issue of the Day/Near Future:‘System Integration’
水文ソフトウェアを開発していく上で、次に考えていかなければいけないのはシステム統合です。
継ぎ目のない環境の中でプログラムとデータが相互にコミュニケーションをできるようにしていかなければいけないわけです。
パズルみたいですけれども、１つの例としてここに挙げました。データ収集があって、データベ
ースのところへ行って、データベースに入れて、データを視覚画面で見られるようにして、モデリ
ング、あるいは意思決定を行って、そして出てきた結果としての情報を一般に公開するということです。
HEC の最初のころの開発については、Corps Water Management System でした。ウェブサイ
トをごらんいただければ、CWMS についてはいろいろなことが記載されています。
（2） Integration System Example : CWMS

Integration System Example: CWMS
Data
Manag
Queue

SHEF
data
file(s)Web
ServerDD
Manager
DD

Transformer

SHEF
decoder

VerifierDA

Current Data

C
A
S V
E I
R
V
E
R

DB
InterfaceOracleDB

Extract/Post

GIS Controller

Model Working Files
HMS

FSF

RSS

RAS

GIS

C

A
V
C I
L
I
E
N
T

Arc/
View

FIA

Model Results

Process/Alarm
Status
DA
FSP
DD
CAVI

Arc/
Info

Hydrologic Engineering Center

Corps Water Management System は１つの例です。CWMS の目的は、貯水池を運用していく、あるいは洪水の際のコントロール、堤防の保全、貯水池の管理が目的です。
CWMS はまずデータ収集から始まっています。衛星通信によってデータを集めてきます。
Telephone landlines Communication、データをいろいろな方法でこのシステムに集めてきます。
ナショナル・ウェザー・サービスと協力して SHEF（Standard Hydrologic Engineering Data
4-33

Format）、水文工学データ・フォーマットの協定が連邦機関の中でむすばれています。
降雨の観測、あるいは天気予報、USGS の水位観測というのも来ているかもしれませんし、流量観測もあるかもしれません。
工兵隊では独自のゲージをいろいろ使っている場合もあると思います。
データの格納の際は Data Verification、クオリティ・コントロールをかけます。データは自動的に入ってきて、それが一定、安定しているかどうかをチェックしてデータベースに格納します。
データベースは、Oracle によって管理されています。ここから HEC の Data Storage System へと運ばれてきます。DSS からそれぞれのモデルにデータを渡していきます。
コントロールセンターは、頭脳に当たるのですが、ここでプロセスを管理しています。入ってくるデータをオペレーターが見て、データベースの中のデータも見て、どのプログラムに入力するかをオペレーターが決めて、入力データをそれぞれ割り振りしています。
「Control and Visualization
Interface」と呼んでいます。
こういう情報がインプットされると、今度は意思決定が行われます。これが継続的にバックグラ
ウンドの中で行われるのが理想ですけれども、水理水文、あるいは Reservoir のシミュレーションは継続的に行われていきます。
問題がなければエンジニアは、ただモニターしていればいいのです。例えば洪水が起こると、オ
ペレーターはそれぞれのプロセスの細かい点をやりくりして調整していかなければいけません。
今、例えば嵐が来ている場合、あるいは洪水になった場合の情報をはっきりと正確に出すためにいろいろシミュレーションしたり、キャリブレーションしたりということがオペレーターとしては必要になってきます。
この集まった情報に基づいてどういうふうにプロジェクトを運営していくか、あるいはその資金、リソースを使っていくかということに対する意思決定が行われます。
あとはデータを一般に広めていく、データの公開です。ウェブサーバーを利用しています。
これは工兵隊内部で行われていますが、実際には一般にも公開することも可能ではあります。
これが 1996 年以後の HEC の主なプロジェクトです。大きなプロジェクトの１つです。これによって新しい水文・水理のテクニックが開発されたというわけではありません。この分析をする中では、先ほどからお話ししている HMS とか RSS とか、RAS とか、GIS とかいったソフトウェアを使っているだけなのです。
理想を言いますと、貯水池を管理している人は水路の通水能力ではなくて、実際にこれから起こりそうな洪水の状況に応じて意思決定をできるということが理想ではあります。
「Flood Impact」と呼んでいますけれども、洪水がその地域に与える影響です。環境的なものとか、そういうことを突き止めるということです。
新しいプロジェクトとしてはこのアイデアを取り上げて、プロジェクトを計画する上でその考えを使っていくということが新しい動きとしてあります。
「Watershed Analysis Package」と呼んでいます。
（3） CWMS Decision - support Modeling
これは、マネジメントの側からデータを見たもので、「Model Working Files」と呼んでいます。
これは Data Storage System の活用方法の一つです。このシステムは、ナショナル・ウェザー・サ
ービスの天気予報のプロセッサにデータを出していきます。さらに、水文予測前処理にデータを出
4-34

していきます。また、Hydrologic Modeling System でシミュレーションをするための気象的ある
いは水文的なデータ情報を含みます。また、貯水池予測システムへの情報として活用しています。
（4） CWMS, Water Management Version 1.0 Deployed 2002,Now 1.1
これは軍のオートメーティド・インフォメーション・システムとして考えていただけるといいと思います。これはリアルタイムで、年中無休でやっています。
水資源のネットワーク上で意思決定をしていく上で、手助けとなるようなシミュレーションをしてくれるシステムです。
ネットワーク・ベースのクライアント・サーバー・システムです。非常にお金がかかっています。
コンピュータ・サイエンスとしても、サーバー・システムはかなり複雑なシステムかと思います。
97 年に始まったこの開発されたシステムは、今いろいろな工兵隊の事務所で使われています。
＜Q： CWMS について＞
Q： CWMS は、事務所ごとに動いているのですか。そうだとすると、どのぐらいの事務所でこれを使っているのか、
全国でもう共通して工兵隊の中では使っているということでしょうか。
例えば、フィールド・オフィスが 40 数ヵ所とありましたけれども、すべてでもう使っているのでしょうか。
A： イエス。すべての Reservoir について実施されているわけではないのですけれども、それぞれのフィールド・オフィスで、少なくとも１つのプロジェクトについて実施されています。５年で総計 700 万ドルぐらい使われています。データの収集管理、さらに処理にほとんどその予算が使われました。
＜Q： 外注とのコミュニケーション＞
Q： 私も外注を使って非常に簡単なソフトウェアをつくったことがありますが、大失敗しました。
それは、こちらの要望が全然理解されないからです。契約者はコンピュータ・プログラマーでして、
例えばいろいろな色を選べるようにするとか、字の大きさを自在に変えられるとか、我々がそんな重視していないところにたくさん時間をかけてそこを充実して、肝心な、例えば早く計算してほしいとか、そういうのが全然できませんでした。そういうコミュニケーションが全然うまくいかなかったのですが、そういうような経験はありますでしょうか。
A： それはよく起こることです。それに近い経験はあって、そこまでひどくはなかったみたいです。契約書の要求文言の中に HEC と緊密に連絡をとってやってくれということが入っていますので、必要ならば毎日 HEC のスタッフとコンストラクターとが協働できるようにということを契約に明記しています。チェックポイントが規定されていまして、ある１つが完了するとその時点でレビューして、これでいいから次へ行っていいよ、あるいはこれはだめだからもう一回元へ戻せということをチェックする規定が契約書の中に明記されています。HEC に契約としてはこういう能力がありますよということを出してもらって、そしてHECでは10日かけてその契約者のできること、能力を査定します。
製品が完成したらチェックをおこない、上手くできていない場合、10 日から 15 日かけてきちんと HEC からの要求に基づいたものにするために修正する、要するに、要求どおりに上がっていな
かったら 10 日から 15 日以内に HEC の要求どおり修正してくださいよということが契約の中に規4-35

定されています。すべての契約の中にはチェックポイントが明記されていますから、契約者との作業はきちんとチェックされるようになっています。
Q： ソフトウェアの開発のやり方で、スパイラルで開発した場合、契約者にじゃあプログラムをつくってもらったが、ちゃんと契約書どおりにはつくったのだけれども、実際は使えるソフトではないというようなことがあったら、その契約は全くむだになるということがあると思うのですけれ
ども、そういうようなことも承知で契約に出すということはあるのでしょうか。
A： ちゃんとソフトウェア、RAS であれ、何かのソフトウェアの中できちんと作動するということを実証することを契約者への要求項目の中できちんと明記することにしています。それで結果をレビューして、必要ならば追加事項を入れます。やはり要求項目の中にきちんとそういうものを入れておけばそういうケースは起こらないということです。
（5） Public Domain
Public Domain についてはいろいろ先ほどからお話をしましたが、連邦政府のお金が出ています
ので、当然、それは一般に公開されるべきだというのが基本的な考え方です。例えば、知的所有権などという問題に突き当たった場合、大学を巻き込んでやっていかなければいけない、大学が知的所有権を所有している場合は、工兵隊にはこれは出してほしくないというようなケースもあります。
ソフトウェアの権利がきちんと確立されないと、その開発には HEC でも随分時間がかかってしまいます。非常に難しい問題、質問ではあるのですけれども、ソフトウェアが広く一般に使われれば、その開発においてもより改善点が出てくる、避けられないということを HEC は確信しているのです。
（6） Challenges
我々にはいろいろな課題がありますが、一つはパブリックドメインでの開発です。これはいろいろ逼迫した状態になっています。例えば DHI のソフトウェア開発などで、民間でソフトウェアは開発するようにと推奨する動きがあるのです。ちょっと変な言葉かもしれないのですけれども欧州化ですね。デンマーク政府などでも、民間機関で開発することを奨励しています。実際にお願いしたときには、非常にいい作業をしてくれます。
議会からのサポートも減っているので余り予算もとれない、それだけソフトウェアをいいものにしていく上での資金が足りなくなっているという課題があります。
これはさっき言っていた制度上のサポート、あるいは制度の能力ということに関連しています。
ですから、知的所有権ということに対して人々の認識が高まっているので、なかなかソフトウェア
をただで配布するということが難しくなってきています。
政府が補助金を出して、ヨーロッパのいろいろな機関が、どんどん攻勢をしかけてきています。
フロリダの「Everglades」と呼ばれる生態系復旧プログラムなどは非常に大きな予算を使っているので、ほかのプログラムに対する予算面での圧迫となっています。
やはり資金源の確保ということが非常に大きな課題となっています。
だれもがそのソフトは使いたいと考えるのですけれども、なかなかそれをサポートしてくれる資金が得にくいのが現状です。

4-36

4.2.7 Summary（1） Conclusions
次に、こういう課題に対して結論としてはどういうものかと言いますと、水文工学は当然引き続き進めていかなければいけないわけです。新しいニーズがいつも水文工学においては生まれています。ですから、HEC としてはそれぞれのプログラム、RAS であるとか、HMS だとか、Reservoir
System だとかいったそれぞれのプログラムのリソースを常に確保しておかなければいけないということです。コンピュータ・サイエンスがどんどん進化していますから、それに歩調を合わせていくということが非常に大変になっています。
どんなコンピュータ能力が必要かということを頭の中で描くことは簡単なのですけれども、実際にそれを構築していくのは非常に難しいことです。制度的なサポートを得るためには、何か新しいことをまた見つけていかなければいけないと思います。
工兵隊内部では内部的なサポートシステム、工兵隊外部にはベンダーのサポートシステムも存在しています。これらが引き続き行われていけば、こういった課題に対する解決策となると期待しています。
ただ、ベンダーのシステムが余りにも大きくなり過ぎて、負担が大き過ぎるという危険性もある
かと思います。
ソフトウェアを開発していく工程の中で、強い統括力を発揮するマネージャーが必要になってきます。コンピュータ・サイエンスということがその作業の中でかなり大きな位置を占めるようになってきました。
（2） HEC Contacts/Information
HEC にコンタクトしたい場合の情報をここに書いてあります。HEC のウェブサイトもあります
し、「software and report」という欄があって、そこにもアクセスしていただけます。今、どんな活動がされているか、あるいはニューズレターにもアクセスいただけます。トレーニングについての情報も得られます。工兵隊外部の方たちにもアシストが得られるようにベンダー紹介の欄もあります。
あとウェブマスター、つまりソフトウェアに関与しているグループにもコンタクトしていただけます。それぞれ RAS とか HMS、Reservoir System、それぞれのソフトウェアごとにグループにコンタクトしていただけます。
HEC が水文工学においてどういう役割を果たしているか、そしてソフト開発がどのように行われているか、どういう問題があって、それに対してどういう対処をしているかということについて、
これでいろいろとおわかりいただけたかと思います。
ソフトウェアに対するニーズというのがありまして、できたら皆さんにベンダーになっていただ
いて、日本におけるそういうニーズを汲み上げていただいて、我々とコンタクトしていただけると非常にありがたいと思っています。
直接 HEC と関係をもつころは、陸軍ですのでなかなか難しいかと思いますが、個人的に活動している HEC の職員もいますし、コンサルタント会社などもありますので、接触はしていただけると思います。

4-37

＜Q： 国費を投入したソフトを海外に配布することの問題＞
Q： 資金源はアメリカのタックスペイヤーで、アメリカの国民に対してフリーということだと思うのですけれども、そういうものを海外に配ることというのは制限・問題はないのですか。
A： 業界で技術の必要性は増大しているので、「ノー」と言う人はいないと思います。ソフトというのは単なるツールであって、それを使い続けるためにはエンジニアリングのアシストが必要です
から、DHI の有償のソフトを買ったはいいけれども、後でメインテナンスとか、サポートとか、ト
レーニングを受けようと思ったら、またお金を出してそういうものを受けなければいけないですよね。ですから、ソフトだけがあっても実用にならないので、そのような問題は起こらないと思います。
＜Q： ソースは公開しない理由＞
Q： ソースは公開しないで、エグゼファイルしか出さないという話がありましたが、ベンダーに対してもソースファイルは公開していないのですか。
A： 当然、ソフトの開発中ではいろいろな変更がある可能性がありますから、どこに対してもソースコードは一切出さないことになっています。コンピュータ・サイエンスが発達してくると、ソースコード自体もどんどん、どんどん複雑化してきているので、ベンダーに対してもソースコード
は出しません。
ベンダーとして修正してソフトウェアの付加価値を高めたい場合はあります。
Java ではソース無しでも、ユーザーが水文のアルゴリズム、計算法を開発して、日本のInfiltration Technique を使って、それを HMS に使う。HMS にほかのライブラリにコンタクトして、そしてその計算法を見つけなさいというふうなインプットをすることもできる。ベンダー独自の方法を開発して、HMS がプロセッサ、データ処理のプロセッサとして機能できるようにするという方法もある。まあ、そういうやり方は問題を起こしているかもしれないけれども、そういうやり方もあるということです。
＜Q： Java＞
Q： Java を使っておられますが、それはもうずっと Java を使い続けられるということで間違いないのでしょうか。
A： そうです。将来的にも、新しい Java が間違いなくまたアップして……。
Q： Java がアップデートし、新しいバージョンが出たら、新しいバージョンの Java を使っていかれるのですか。
A： 使うつもりです。古いものとの互換性があればですが。
（笑声）古いシステムが変わるとちょっと問題が起きるものなのですが、でも将来的にも使い続ける意向です。Java の場合、非常にいい
開発環境を持っていると思うので。
＜Q： リバー・マネジメント＞
Q： ちょっと観点の違う質問をさせていただきます。予算がだんだん厳しくなってきているという話がありましたが、それは例えば、Everglades のようなところに持っていかれたり、民間に開発を委ねたというところがあるのはわかるのですけれども、リバー・マネジメントの重要性だとか、
それからそれのためのこういうプログラム開発そのものの必要性というものの評価が落ちてきてい4-38

るというようなことはないのでしょうか。
A： 公がどういうプロジェクトを重要視するかどうかは、これは時によって変わってしまうものです。環境面に余り注力しないときもありましたが、今は環境的な側面は非常に重要視されています。例えば環境分析をする場合、水理・水文のエンジニアリングの知識も要るし、あと RAMS とかデータ・マネジメントなども必要になっていますから、それなりに水理水文、あるいはソフトウ
ェアを使った解析、分析というものが要求されてきます。
Q： 一般的に、例えば政府内でリバー・マネジメントに対する重要性の認識が下がってくる可能性がないかということについては。
A： 有ると思います。やはりああいうスマトラ沖地震とか津波とかがあると、どうしても関心は
地震予知の分析に行ってしまいます。水文・水理、貯水池システム、それぞれに対して核となるマ
ネジメントの意識をずっと高い領域に留めておくのはなかなか難しい。新しいニーズが出てくる、
例えばティートンダムが決壊したという場合には、やはり新しいダム管理の手法が要求されてきます。ニーズが出てくると、それに対する新しいものも要求されてきます。
ただ、基本的な川に関する水文工学がきちんと運用されていなかったら、
例えばダムが決壊して、それに対するシミュレーションが必要になったときも、迅速に対応するということはできません。
だから基礎的な部分を今からしっかりやっておかないと、何か起きたときにすぐ対応できないという問題はあると思います。
＜Q：ベンダー契約費＞
Q： ベンダーがいろいろ外部のユーザーサポートをやってくれる、そのときに 200 ドル払えばベンダーになれるというお話ですが、HEC の予算が非常に苦しいということでしたら、ベンダーのエンジニアリング・コンサルティングの売り上げに比例する料金を徴収するとか、そういう仕組みは考えなかったのでしょうか。
A： やはり連邦機関だから、普通のプロセスの中でなかなか外部からお金をいただくということに制限があるのです。その 200 ドルはアメリカの国庫に入ってしまうのです。HEC としては、お金はもらっていないそうです。なかなか生かさず、殺さずでやられているみたいです、連邦政府から。
（笑声）＜Q： 他の類似ソフトとの関係＞
Q： 例えば Bureau of Reclamation のように、アメリカの中のほかの組織でも同じようなソフト
ウェアを開発していますけれども、それに対して何か意識をしているのでしょうか。例えば、競争相手と思っているのか、あるいはいつか重複しているのだからどっちかの予算を削れと言われるのではないかとか、そういうような意識は何かあるのでしょうか。
A： Bureau of Reclamation だけではなくて、Soil Conservation Services、USGS とか、ほかのアメリカ政府機関にとってもやはり問題になることです。NASA などもそうなのですけれども、水文モデルとかそういうもの……、やはりその１つ１つのものをまとめるようにして、リソース自体を浪費しないようにという動きがありますね。それぞれの開発に正当化された意図がありますが、
水文学自体は同じですから、もっと共同して一緒になってやっていくということは可能だとは思います。水資源のワークショップを開いて議論している例がありますけれども……。
政府機関の中で Bureau of Reclamation のように、同じような水文モデルの開発をやっていると4-39

ころもあります。政府機関内でのいろいろなデータ管理とか、ほかの政府機関にもそれを使えるよ
うにというように HEC はしているし、政府機関ごとのもっと交流というものを活発にしなければいけないと思います。Rio Grande の工兵隊のオフィスも Bureau of Reclamation のシステムを使っています。CWMS に Bureau of Reclamation のソフトウェアを統合しているのです。インター
フェースにしておいて、CWMS から Bureau of Reclamation に行けるようにしています。天然資源のことについていろいろな政治家が討議しているらしいのですけれども、工兵隊とか Bureau of
Reclamation とか EPA からのいろいろな機関がいろいろな水文を統合して１つにまとめてしまっ
たらどうだという議会での論議があるそうです。それは政治的には難しいことだけれども。
＜Q： HEM HM の実習用に HEC のモデルは使っているのか？＞
Q： 工兵隊では「Hydraulic Engineering Manual」とか「Hydrology Manual」とか、非常に程度の高いすぐれたマニュアルを出版されていますね。それで、そういうマニュアルの内容を末端のエンジニアも理解し、使っていくというためには、実際の応用問題を解いて練習する必要もあると思いますが、そのときに HEC のこういうシミュレーションモデルとか、そういうものが役に立つのではないか、あるいは役立てるためにつくっているのかどうか、その辺のところをお尋ねしたいと思いますが。
A： 水理・水文分析の非常に基本的な考え方、原則がこのマニュアルには書いてあります。工兵隊のその担当のテクニカル・エキスパートがそのマニュアルを読むわけです。洪水防御とか洪水予
測とか、その Reservoir System について HEC もそのマニュアルの中に記載しています。いろいろな問題の実際的な例とか、アプリケーションの例などについてもその書類の中では触れています。
エンジニアリング規制についても書いてある書類もありまして、どのようにしてそのプロジェクトを始めていくかというようなことについても書いてあります。エンジニアリング・マニュアルには技術的な明細が書いてあるし、次はユーザーズ・マニュアル、あるいはアプリケーション・マニュ
アルがあります。アプリケーション・マニュアルと HEC マニュアルの間には関連性があります。
直接的な結びつきはないにしても、それぞれ参照できる部分があります。
Q： それで、こういう HEC-RAS とか、そういうようなものがそういうエンジニアリング・マニ
ュアルの考え方や知識を職員が、エンジニアが理解する、そういうツールになるのではないか、するつもりはないのか、そういうつもりであるのかということなのですけれども。
A： アプリケーション・マニュアルからエンジニアリング・マニュアルに参照してもらって、研究するためにどういうことが必要かということはアプリケーション・マニュアルを見てもらえばわかります。そういう必要なことを満たしていくためにはどういうふうにして HMS が役に立つかというようなことを参照していただけるようになっています。
ですから、御指摘のことを、普通の公的なエンジニアリング・マニュアルに対しても HEC のモ
デルでつなげていけるようにできないかなというようなことを考えています。
Q：

私も個人的に考えているのですけれども、日本でも非常に多くの事業をやっておりますので、マニュアルは相当いろいろなものをつくっております。ただ、それを伝える手法としてこういうソ
フトウェアをつくって練習するということによってトレーニングするのがいいのではないかなと思ったものですから、そういう質問をしたわけです。
A： 昔のアプリケーション・マニュアルは工兵隊のプロシージャ、一般的なアプリケーションではなくて、実際に工兵隊のテクニカルな観点からの問題があって、工兵隊の実際の例とは結びつけ
4-40

られないものだったのです。新しいアプリケーション・マニュアルではプログラムを、どうやってエンジニアリング・マニュアルと参照しながらこのプログラムを使っていったらいいかということを新しいアプリケーション・マニュアルには書いてあります。いろいろなテクニカルな調査をしていく上では、やはりソフトウェアは非常に有用なツールになっていくと考えています。
○司会 では、もう時間になりましたので、これで今日の講演会を終わりたいと思います。
大変長い時間、講演をしていただきまして、ありがとうございます。拍手をもってお礼をしたいと思います。
（拍手）
どうもありがとうございました。

4-41