情報処理にかかわる実際の問題

• プロジェクト (ひとまとまりの仕事) を始める前に考えること (Star and Estes, 1990, 第11章「現実の問題」)
  • 解決したい問題を明確にしないと始まらない。
  • 結果が得られるまでの時間がどれだけかかってよいのか?
  • プロジェクト管理は複雑な業務である。
    • 「人月の神話」(Brooks ... IBMのプロジェクトリーダー経験者): 1人で365日と365人で1日とは同じでない。
  • データの容量とそれを保存する場所、コスト、(特に磁気媒体の場合)劣化対策としての書きかえの必要性
• プログラムを書くことと、ソフトウェア製品を作ること
  • 手間の違い (Brooks)

    プログラム: 1	プログラムシステム: 3
    プログラム製品: 3	プログラムシステム製品: 9

  • ヒントに富む本
    • プログラムシステム製品を作るプロジェクト運営に重点 ... Brooks, Yourdon
    • プログラムを書くことに重点 ... Plauger, Bentley
    • どちらかといえば人間の心理に重点 ... Weinberg, Landauer
  • 原型を速く作る(rapid prototyping)のと、他人の手にゆだねる製品を作るのとは、道具を使いわけたほうがよさそうだ。 (プログラム言語に関しては、コンピュータ利用の教材 「しっかりした言語と手軽な言語」参照。)
  • 大学で教員や学生が作るプログラムの多くは、利用者が自分だけか、顔を合わせられる範囲に限られるので、「原型」と同じ扱いがふつうである。実務では(売るソフトウェアはもちろん、フリーや自家用でも)もっと構造設計や検査に重点をおく。
• データの流れの設計が基本
  • プロジェクト全体のスケールと、個々のプログラムのスケールのいずれでも使う。
  • データフローを図で示す方法の案
    • データが蓄積されている状態(データセット、データベース)を、箱のようにかく
    • データの移動を、箱を結ぶ矢印としてかく
    • データの加工処理は、箱を結ぶ矢印への注記として、箱とは区別した囲みでかく
  • 他人との間は、「箱」でデータを引き渡し、そのデータの形式の記述をしっかりさせることで、加工処理プログラムの作成を分担できる。
  • リアルタイム処理(通信がらみ)では別の考え方が必要かもしれない。
  • プログラムの制御の流れを示す「フローチャート」は、プログラムをわかりやすく書けば不要。ただし副プログラムを呼び出す関係の図はほしい。
• プログラムのまちがいの検出と修正(デバッグ debug =虫取り)
  • 大型計算機(Unix普及以前のOS)上のFortran言語による事例が、東京大学大型計算機センター「Fortranプログラムデバッグの手引」にまとめられている。増田もプログラム相談員としてこれの編集に参加した。
  • Kernighan and Plauger (1978) も参考になる。例文の言語が古いFortranとPL/Iだが、今のFortranで書きなおしてみた[別ページ(アクセス制限あり)]。
  • C言語の場合はわたしの知識は乏しいが、藤原(1994)、同じ著者の「Cプログラミング診断室」、Koenig (1989)などがある。
  • 機械語のプログラムの変数の範囲を越えて記憶領域を書きかえている(「プログラムをこわしている」)と、プログラムの流れがおかしくなったり、突然止まることもある。また、結果が微妙におかしいこともある。これの原因としてよくあるのは
    • 記憶領域(おもに配列変数)の確保を忘れている、あるいはその寸法が小さすぎる。
    • 副プログラム(C言語では「関数」)とそれを呼び出す側の変数の対応がまちがっている。
  • 変数に値を与えるのを忘れてその値を使ってしまうと、結果には意味がない(見かけ上うまくいくことも多いが)。自動的に初期値0が与えられる言語(例、awk)を使う場合も、それでプログラムの趣旨に合うか要注意。
  • 変数の値をある範囲で変えて実行するとき、ちょうど端の値に一致する場合の扱いをまちがえやすいので要注意。また、区間の数と区間をくぎる値の数のちがい(いわゆる植木算の問題)にも要注意。
  • プログラムを、制御構造を明確にして書くこと (コンピュータ利用の教材「プログラミング言語のはなし: 制御構造を中心に」参照)で、まちがいが起こりにくく、デバッグがしやすくなる。
• データを扱うとき注意すること
  • (別教材「データ解析にはいる前の仕事--気象データの場合を例に」も参照。)
  • 自分にとって初めてのデータを使う前には、正しく読めているかどうか、および、データの品質の見当をつけるため、データの内容の、なんらかの意味での全数検査が必要。(データのまちがいや、意図的に欠損を示す印として、とんでもない値がはいっていることがある。)
    • 計算機の単純処理能力と人間のパタン認識能力を利用。グラフ化、多次元データのいろいろな断面での図化。(Chambersほか, 1983; Cleveland, 1985; 廣田, 1999)
    • 地理データでは、位置をとりちがえる失敗をしやすいので、まず海陸分布などと対比できる変数を選んで、作図して確認する。
      • 全球ラスターデータの場合:
        • 座標系は緯度経度か?
        • xが経度、yが緯度か?
        • 経度は0度からか、-180度からか?
        • 緯度は北からか、南からか?
        • 値の位置は格子線の交点か、マス目の中央か?
        • 「のりしろ」はあるか?)
    • 大量データの場合は、図を見る方法ほど検出力は強くないが、自動チェック(バッチ処理)も必要。
    • 平均値や標準偏差より先に、はずれ値に強い(robust)統計量(中央値などの順位統計量)を見る。 (Tukey流の探索型データ解析、渡部ほか, 1985)
    • 統計処理には、データ欠損があっても使えるくふうが必要。
  • 精度と正確さ
    • (この用語の意味は「世界をサンプリングする」参照)。
    • 形式的な有効数字は簡単に示せるが、複合した処理を経た結果の精度を示すことはむずかしい。しかし、なんらかの信頼度の表示はすべきである (Star and Estes 11章)。
• 標準化 (互換性)
  • データの交換のために、データ形式を標準のものにそろえると便利。
  • 現在、空間情報(地理情報)の表現のISO(国際標準化機構)やJISの標準化が進められている(村上, 2000)。SDTS (spatial data transfer standard)という略語で言われることが多い。データを説明する情報(メタデータともいう)の書きかたの標準化も含まれている。
  • 標準は広く使われて初めて価値がある。煩雑すぎては逆効果。
  • 実際に使われている業界標準には、体系として整っていない点があることが多い。一方、初めから標準として合理的に構成したものは、実際に普及するとは限らない。多くの標準は両者の間の妥協となる。ISOやJISの標準にはなったが、けっきょくあまり広くは使われなかったものも多い(例、コンピュータグラフィックスのGKS[グラフィックスの教材中の「GKSについて」参照]やCGM)。
  • プログラム言語(C, Fortranなど)の標準化は非常に役にたっている。ただし、Fortran 90/95のように、機能を多くしたために、それに適合したコンパイラを作る組織(会社)が少なく、利用者も大型数値計算ユーザーだけに限られてしまった(その限りでは有用)という事例もある。わたしの個人的標準言語は、Fortran 77に、Fortran 90の機能のうち今では業界標準的になっている項目を加えたもの(フリーのコンパイラg77や、Cへの翻訳ソフトウェアf2cの機能の範囲)である。
  • 文字コード(文字をどのようなビット列で表わすか)の標準化もいろいろ妥協を含んでおり不満を述べる人も多いが、ともかく必要なことである。
• 著作権 (copyright) (名和, 1996)
  • 知的財産権には、特許、意匠(デザイン)、商標もあるが、わたしはよく知らない。(研究成果を特許にしろと言われても困る。)
  • Copyrightは本来「複製する権利」をさし、文化的に意味のある著作物の流通を促進すること(出版業を成り立たせることを含む)をねらって法律が作られている。
  • 文書、図画、映画、ソフトウェア、データベースなどに分類して規定が決められている。
  • 財産権としての著作権(譲れる)と、著作者人格権(譲れない)がある。
  • 学者の論文のpriorityの尊重は、著作者人格権の尊重とほぼ一致する。
  • 論文の著作財産権は出版者に移転することが多い。その場合、論文をコピーするには、出版者の許可が必要であるとか、出版者が指定した組織に料金を払う必要があるとかのようなとりきめがあることが多い。
  • 著作権の適用外を、public domainという。アメリカ合衆国では、連邦政府の著作物や、 著作権表示をしないソフトウェアがこれに該当する。日本に、著作権の年限が終了したもの以外に、これに該当するものがあるかどうかは、意見が分かれる。
  • 商品のソフトウェアの多くは、著作者が、著作権を根拠として、再配布の禁止あるいは制限をしている。
  • フリーソフトウェアの多くは、著作者が著作権を主張したうえで、自由な再配布を許可することを明記している。ソフトウェアはフリーにし、それに関するサービス(注文に応じて作ることを含む)は有料にするのがよいという主張(Stallmanなど)もある。
  • 地理データには、
    • 著作権がない(public domainの)もの、
    • 著作権があるが再配布自由な(freeの)もの、
    • 著作権によって再配布が制限されているもの
    がある。
  • 国土地理院の「数値地図」の著作権は測量法を根拠としている。
  • 今の社会には、商品とフリー(public domainを含む)のものの両方の存在意義があると(わたしは)思う。

参考文献

• Bentley, J.L., 1988; 野下 浩平, 古郡 廷治 訳, 1991: プログラマのうちあけ話--続・プログラム設計の着想。近代科学社, 256 pp.
• Brooks, F.P.Jr., 1995; 滝沢徹, 牧野祐子, 富沢昇 訳, 1996: 人月の神話 (原著発行20周年記念増訂版), アジソン・ウェスレイ, 321 pp. (日本語版発売元はピアソンを経て丸善出版に変わった.)
• Chambers, J.M., Cleveland, W.S., Kleiner, B. and Tukey, P.A., 1983: Graphical Methods for Data Analysis. Wadsworth. (版元がChapman and Hallに変わったらしい.)
• Cleveland, W.S., 1985: Elements of Graphing Data. Wadsworth, 323 pp. (版元がChapman and Hallに変わったあと品切れになり, 改訂版がHobart Pressから出ているが, 内容がかなり変わってしまった.)
  [同 日本語版] 渡部 宏邦 訳, 1987, 科学技術者のためのグラフ処理技法。日刊工業新聞社。(版元品切れらしい) [読書ノート]
• 藤原博文, 1994: Cプログラミング専門課程。技術評論社、 367 pp.
• 廣田 勇, 1999: 気象解析学 -- 観測データの表現論。東京大学出版会, 175 pp. [読書ノート]
• Kernighan, B.W. and Plauger, P.J., 1978; 木村 泉 訳, 1982: プログラム書法。共立出版、236 pp.
• Koenig, A., 1989; 中村 明 訳, 1990: Cプログラミングの落とし穴。トッパン, 158 pp. (この出版社はなくなった. 現在出版されているかどうか未確認.)
• Landauer, T.K., 1995; 山形 浩生 訳, 1997: そのコンピュータシステムが使えない理由。 アスキー, 422 pp.
• 村上 広史, 2000: 地理情報標準の最新動向。 第29回 国土地理院技術研究発表会 (国土地理院技術資料A.1-No. 224), 59 -- 66.
• 名和 小太郎, 1996: サイバースペースの著作権。 中公新書 1320, 194 pp.
• Plauger, P.J., 1993-94; 安藤 進 訳, 1995-96: プログラミングの壷。共立出版、3冊, 254+234+254 pp.
• Stallman, R.M., 1985; 野崎 昭弘 訳, 1988: GNU宣言。 Computer Today, No. 23 (1988.1), 9 -- 16. (この文自体もフリーなのでいろいろなところに収録されている。この雑誌は一例)
• Star, J. and Estes, J., 1990; 岡部篤行, 貞広幸雄, 今井 修 訳, 1992: 入門・地理情報システム。共立出版, 235 pp.
• 渡部 洋, 鈴木 規夫, 山田 文康, 大塚 雄作, 1985: 探索的データ解析入門。朝倉書店, 188 pp.
• Weinberg, G.M., 1988; 木村 泉 ほか訳, 1994: プログラミングの心理学。技術評論社, 367 pp. (この著者の本はたくさんあって、どれもおもしろいが、書ききれない。)
• Yourdon, E., 1997; 松原 友夫, 山浦 恒央 訳, 1998: デスマーチ--なぜソフトウェア・プロジェクトは混乱するのか。 トッパン, 215 pp. (現在は別の出版社から出版されているようだが未確認.)

[地理情報学の授業の目次へ]