OuDiary - OuDiaプログラム開発日誌

　これを書いている2007年12月現在、OuDiaの最新バージョンは0.04.08 となっています。

　このバージョンのベースとなる OuDia Ver.0.04 は、2006年3月7日 にリリースされました。このバージョンは、僕自身がOuDia本格着工時にやりたかった機能が一応満たされたものであり、ひとつのマイルストーンとなるものであると思っています。OuDiaを本格着工したのは2005年5月ですから、ここまで来るのに約8ヶ月が経っていました。

　作者自身はこのバージョンをリリースした後、再就職を行いました。その後はまたまた本業多忙になってしまっており、OuDiaの開発にはなかなか時間をかけられなくなってしまいました。結果、バージョン0.04以降のバージョンアップの間隔は開いてしまい、規模的にも小改造にとどまっています。

　こんな状況ではありますが、OuDia Ver.0.04.08 のダウンロード回数は 2000 以上となり、ユーザーの方は当初よりもずいぶん増えました。また、実験的に開設したブログやメールでも、OuDiaに対するご要望を頂戴しております。まあ、時には「過去をふりかえっているだけ」などという手厳しいお言葉を頂戴することもありますが・・・(^^; 。

　今のところ、 OuDia に対する次の大きな展開の予定を考えることは難しい状況ではあります。でも、これからもできる範囲で、ユーザーの皆様のご期待に応えられる方策を考えていきたいと思っています。

　Vector は、日本最大規模の、オンラインソフトウエアライブラリです。OuDiaも、この Vector に登録しています。

　当初はあまり深く考えず、お試しのつもりでの登録でした。が、Vector の宣伝効果たるや大変なもので、これをきっかけに OuDia のユーザーが大きく増加しました。同時に、このサイトへの来訪者も、Vectorの掲載を機に増加しました。

　OuDia Ver.0.03.01 は、このサイトで 1/17～2/25 の間公開していましたが、ほぼ同時期に並行してVectorでも公開していました。Vectorでの公開期間は1/27～3/14 でしたが、これはVectorの場合、申請から掲載までの間に１週間程度の時間がかかるためです。
　期間中のこのサイトからのダウンロード数は 150 。これに対して Vector からのダウンロード数は 386 と、何と倍以上でした。Vectorの露出度たるや大変なものです。しかも、Vectorにソフトウエアを登録すると、
 『gooダウンロード』（http://download.goo.ne.jp/）
 『Yahoo!コンピュータ - ソフトウエアダウンロード』
 『＠nifty:ダウンロード＠nifty』
といったサイトにも、Vectorのダウンロードページへのリンクが自動的に掲載されました。これらを含めたトータルの宣伝効果は、想像以上のものがありました。

　この経験から思ったことは、一個人のWebサイトを高アクセス数の人気サイトにするのは大変だ、ということです。特に、近年はブログの普及もあり、WWW上にはサイトが溢れすぎています。その中で多くの人に気づいてもらうのは並大抵なことではなくなっています。『OuDiaのホームページ』の場合は、『ソフトウエアの提供』という特性があったがために Vector という宣伝媒体を利用することができましたが、一般的な、情報提供のみの個人Webサイトを人気サイトに育てるのは、非常に困難な時代になっているように思います。

　OuDia公開後、動作チェックを兼ねて自分でも結構列車本数の多い大手私鉄の路線のデータを入力してみました。しかし、時刻表データの入力は結構な時間がかかりました。編集動作をかなり工夫したつもりだったのですが、自分で使って見て「まだ工夫の余地がある」と感じました。

　OuDiaは、完全なパターンダイヤの作成はかなり簡単にできるのですが、多くの大手私鉄の路線は、完全なパターンダイヤになっているのはデータイムだけで、朝ラッシュ時・夕ラッシュ時には完全なパターンダイヤになっていないケースがほとんどです。この朝夕ラッシュ時においては、同じ列車種別でも発着時刻・所要時分に１～２分のずれが多発し、これらを手作業で修正するのに時間がかかるのでした。こういう１～２分のずれの修正を容易にするにはどのようにすればよいか・・・を主体に考えることにしました。

　まず面倒だったのは、[駅時刻]ダイアログへの時刻入力です。
　当時の[駅時刻]ダイアログは、必ず時と分の入力をしなくてはならない仕様でした。これを、時を省略して分だけを入力できるようにしました。
　また、当時の[駅時刻]ダイアログは、着時刻を修正しても発時刻が変化しませんでした。このため、ある駅の着時刻・発時刻両方を繰上げ・繰下げするのが面倒でした。これも、着時刻を繰上げ・繰下げすれば発時刻も自動的に繰上げ・繰下げになるように変更しました。
【参照】2.3.1. [駅時刻]ダイアログの便利な使い方(http://homepage2.nifty.com/take-okm/oudia/oudia_manual/c02_usersguide/c03_ressyanyuuryoku/c01_ekijikokudlg/ekijikokudlg.html)

　これで少しは楽になったものの、まだ物足りません。[駅時刻]ダイアログを使って駅時刻を変更するには、キー操作が2～3回必要になります。

　「やはり1分の時刻変更はキー操作1回で実行できるべきではないか」ということで考えたのが、『2.3.11. 列車の駅時刻の連続１分修正』(http://homepage2.nifty.com/take-okm/oudia/oudia_manual/c02_usersguide/c03_ressyanyuuryoku/c11_renzoku1syuusei/renzoku1syuusei.html)機能でした。これにより、駅時刻の微調整はかなり素早くできるようになりました。

　しかしながら、これでもまだ時刻表データの入力が面倒なことには変わりないですね。でも、今のところ、これ以上の入力省力化の方法は思いつかないところに来ています（「駅時刻を入力しない」という解決方法は除きます）。

　極めつけは「駅時刻を入力しないこと」なのでしょう。その方法の一つとして「『駅から時刻表』のデータを読み込めるようにしてほしい」という要望を挙げる方も昔からいらっしゃいます。しかし、『駅から時刻表』はデータの加工を認めていないようですし、そもそもそんな機能を作ったところで、『駅から時刻表』のサイトが模様替えされてしまえば、『駅から時刻表』を読み込むプログラムは一瞬にして使い物にならないゴミになってしまいます。『駅から時刻表』の模様替えのたびにプログラムを作り直す作業は明らかに不毛です。このため、そのような機能を追加する予定はありません。

　当初は機能・動き共にいまいちだったOuDiaも、いろいろな方からの感想・ご意見を受けながら改良を重ねていき、４ヵ月後の11月にはバージョン Ver.0.02.03 となりました。
　この頃には、「OuDiaがダイヤに関心をお持ちの鉄道ファンの皆様に受け入れていただけるソフトになっている」との手ごたえを持てるようになってきました。
　そこで 2005年11月17日、このサイト『OuDiaのホームページ』の一般公開を開始しました。

　公開はしたものの、当初は来訪者がほとんどいない状態がでした。
　宣伝活動として、とりあえず Google などの検索サイトに登録してみたものの、訪問者は１日にほんの０～４人、という状態でした。OuDiaのホームページには当初からアクセスカウンタを表示していましたが、その数のあまりの少なさに恥ずかしくなり、一時はアクセスカウンタの表示をやめたこともありました。

　以前も記しましたが、初期のOuDiaは現在のものに比べてかなり動作が重いものでした。特に重かったのが [編集]－[元に戻す] の動作、いわゆるUndo(アンドゥ)機能でした。

　当時のUndo機能が遅い理由は明白でした。このころのOuDiaは、編集動作ごとに路線データ全部をメモリ上に保存し、Undo動作が行われた時には路線データ全部をUndoデータから読み出して上書きしていたからです。
　補足しますと、『路線データ全部』というのは、全部の駅・全列車種別のデータ・及び全ダイヤの全列車の全駅の発車時刻を含みます。また、『編集動作』とは駅の追加・削除・修正から列車の駅時刻の1分の変更までを含めた、『路線ファイル』に保存されるデータのあらゆる変更動作を指します。
　列車本数の多い路線のデータを入力していると、データ量は次第に多くなっていき、それに従って編集動作が遅くなっていくのでした。

　解決方法も明白です。編集動作ごとに保存するデータを、Undoに最低限必要なデータに減らせばいいのです。たとえばある列車のある駅の時刻を変更した場合、Undoに最低限必要なデータは、『どのダイヤのどの列車のどの駅の時刻を何分変更したか』ということだけです。これなら、『路線データ全部』に比べてデータ量は大幅に減らせます。
　しかし、OuDiaの『編集動作』は、小は列車の駅時刻の1分の変更から、大は駅の追加までいろんな種類があり、それによって『Undoに最低限必要なデータ』は変わります。特に駅の追加・削除は、その時点で存在する全ダイヤ・全列車の駅時刻の変更につながります。これらをうまく管理できるような設計を考える必要がありました。

　そんななか、大阪の某大型書店のコンピュータのフロアで、『デザインパターン』に関する書籍を目にしました。『デザインパターン』とは、ソフトウエアの設計ノウハウをまとめたものです。
　このうち、Undoの最適化に役立つものはないかと探した結果、OuDiaでは『 Memento パターン』と『Command パターン』を参考にしてUndoの再設計を行いました。これがうまく当たり、Undoを含めた編集動作全体を軽快にすることができたのでした。

　最初の OuDia は７月末に動作し始めましたが、その後自分でデータ入力を行って不具合を修正し、8月5日に OuDia Ver. 0.1.805.1 をネット上で公開しました。はじめての OuDia の公開です。

　このころの OuDia は今よりずっと完成度は低く、インターネットで不特定多数に公開するほどの自信は持てない状態でした。このため、『@nifty 鉄道フォーラム』という、会員制フォーラムのデータライブラリで公開しました。

※　『@nifty 鉄道フォーラム』は現在では運営形態が変わり、『有限会社鉄道フォーラム (http://www.railforum.jp/) 』 となっています。

　これとは別に、当『OuDiaのホームページ』の試作も始めており、そちらでの公開も行っていました。が、これはあくまで知り合いに OuDia を試してもらうためのものでした。このころの『OuDiaのホームページ』は、検索サイトに登録していなかったので、知らない人が訪れることは事実上不可能でした。

　このバージョンは結構多くの方にダウンロードしていただき、多くの方からフォーラムに、ご意見・ご感想をお寄せ頂きました。多数の好意的な感想をお寄せいただき、開発者として非常に嬉しく感じました。モノ作りの喜びを再認識させていただけたと思います。

　僕はプログラマを職業としていましたが、プログラムを作る仕事の現場の多くは、最終的にプログラムを使う人と接する機会がほとんどありません。多くの場合、プログラマはユーザーからはその存在を感じられない『裏方』なのです。特に、下請けとして開発を受注するような会社にいるプログラマは、エンドユーザーと直に接する機会はなく、苦情だけが特定の『担当者』から伝えられる、という状況になっています。

　そういう意味では、作ったものを使ってくれた人の生の声を聞けるというのは、とても新鮮な経験でした。

　その後、OuDiaは、皆さんからお寄せいただいた意見や、自分がデータを作成してみて不便だと感じた点をもとに、機能向上を重ねていきました。
　また、重い動作を軽快にするための設計の見直しも繰り返していきました。今のOuDiaはこのころに比べるとずいぶん軽快な動作になったと思いますが、この軽快さはある日突然実現したわけではなく、工夫を重ねて徐々に軽快になっていったのでした。

　　『10.ダイヤグラムビュー・まっすぐな列車線』で述べたような工夫を重ねて、ようやくダイヤグラムビューに、それなりに見栄えのするダイヤグラムが表示できるようになりました。
　が、この時点でのダイヤグラムビューの機能は、「ただ表示するだけ」でした。時刻表ビューにはそこそこ力を入れて編集機能を充実させてきたのに、ダイヤグラムが「ただ表示するだけ」では、何か物足りないものが感じられました。

　また、WinDIAのダイヤグラムウインドウも、機能は「ただ表示するだけ」であり、時刻表ウインドウに連携するような機能はありません。僕自身が以前WinDIAを利用した時には、「ダイヤグラムの表示結果をもとに発着時刻を修正するのが不便だなあ」と感じられました。このため、このような作業をサポートする機能が何か欲しいな、と思いました。

　まず思いつくのは、「ダイヤグラムビュー上でダイヤの編集」という機能です。具体的には、ドローソフト(Microsoft Word や Excel の『図形描画』みたいなもの)のように、ダイヤグラムビュー上のマウス操作で列車線を引いたり修正したりできるようなものです。
　しかし、これは作るのに相当手間がかかり、すぐにできるようなものではありませんでした。
　また、「どのような操作方法にすればいいのか？」というところを、仕様としてうまくまとめることができませんでした。一般のドローソフトで図形を作成する場合とは異なり、ダイヤグラムはウインドウ上を直線が高密度で交錯します。その高密度の列車線の中から、目的の列車線をマウスでクリックして選択するだけでも難しく、快適な編集作業とはいかないのではないか？と思われました。
　このような経緯で、このアイデアは没になりました。

　「ダイヤグラムを見ながらダイヤデータを修正」という作業をサポートでき、しかも比較的簡単に実現できる機能として考えついたのが、

 ダイヤグラムビューの列車線をダブルクリックすると、時刻表ビューが開き、ダブルクリックされた列車にフォーカスが設定される

という機能でした。
　当初は「本当に便利なのかなあ？」と半信半疑で作成した機能でしたが、動作してみると結構便利で、僕自身のお気に入りの機能になりました。

　OuDiaは一言でいうなら「ファイル編集ソフト」です。そもそも画面そのものが地味ですし、動画再生ソフトなどのような動きはありません。このため、それを使った作業も非常に地味で飽きやすいものです。そんな中で、「ダイヤグラムビューの列車線ダブルクリックによる時刻表ビューへのジャンプ」という機能は、OuDiaではほとんど唯一の、派手な動きを伴う機能であり、OuDiaのアクセントになっていると思うのですが、いかがでしょうか。

　話が前後して、これはダイヤグラムビューを作成していたころの話です。

　ダイヤグラムビューは、時刻表ビューで入力された全部の列車の駅時刻を線で結べばいいだけだ、と当初僕は思っていました。

　ところが、実際の鉄道時刻表を見ると、同じ各駅停車列車でも、列車によって駅間所要時分に±１分の差が散在しています。これは、実際の列車ダイヤは秒単位(10秒単位や5秒単位)であり、時刻表に表示される時刻は秒以下を切り捨てたものになるためです(着時刻については秒以下を切り上げている時刻表もあるようです)。

　問題は、ダイヤグラムビューにおいて、駅間所要時分に±１分の差が散在する駅時刻を正直に線で結ぶと、列車線は屈折が多くて見苦しいものになるということです。

　言葉ではうまく伝わっているかどうか自信がないので、例を挙げましょう。

　A駅～E駅の5駅があり、各駅の駅間所要時分が1分30秒の区間があったとします。
　この路線で、A駅発時刻が 0:00:00 と 0:07:30 の2本の列車がある場合、時刻表ビューは以下のようになります。

　この時刻表ビューの入力どおりに列車線を引くと、ダイヤグラムビューは以下のようになってしまいます。

　しかし、以下のダイヤグラムの方が、見た目に見やすいですし、本物に近いはずです。

このため、ダイヤグラムの列車線をより真っ直ぐにするにはどのようにすればよいのかについて、いろいろ考えました。その結果、

　発時刻しか入力されていない一般駅(主要駅以外の駅)の駅時刻は無視して、主要駅から主要駅までの駅時刻を直線で結ぶ方がよい

という結論に達しました。

　現在のOuDiaのダイヤグラムビューは、上記の結論を原則として列車線を結んでいます(実際には、もう少し複雑なルールになっています)。
　但し、主要駅間を結ぶ直線が、駅時刻ビューで入力されている時刻から1分以上離れている場合は、入力されている駅時刻に従って線を結ぶようになっています。

　時折ユーザーの方から「入力した駅時刻が、ダイヤグラムビューでは無視されて線が引かれてしまう」というご指摘を頂戴しますが、それはこの仕組みが原因です。
　ダイヤグラムビュー上の列車線が駅時刻上を正確に通り過ぎるようにしたい場合は、

• その駅の駅規模を主要駅にする
• その駅の駅時刻に着時刻・発時刻の両方を入力する

のいずれかを試して見てください。

　設計が終わると、いよいよプログラミングの作業になりました。

　前にも述べましたが、設計段階で「何を作るか」が明確になっていれば、プログラミングの作業は設計作業よりは単純作業に近くなります。
　もっとも、プログラムを作るためには知識が必要ですし、必要とされる動作の実現方法に関する知識を持っていない場合は、調べるという作業が発生します。が、どちらかというと、創意工夫よりは、仕事を効率よくこなすための経験がモノを言います。
　ソフトウエア開発はよく、建築に喩えられます。建築でも「何を作ればいいのか」を明確にする設計がきちんと行われれば、実際の大工仕事は比較的単純作業に近いものになる、そんな感じかもしれません。もちろん、大工仕事にも知識と経験が必要ですよね。

　開発メモによれば、プログラミングを開始したのは2005年5月23日、一通りのプログラムが終了して最初の OuDia が動作するようになったのは 7月20日ですから、ほぼ２ヶ月かかったことになります。
　OuDia のプログラムの行数は、約87000行です。ただし、これらすべてをこの2ヶ月で作ったわけではありません。『グリッド形式ビュー』の開発で述べましたが、OuDiaを本格的に作り始める以前から、かなりの構成要素の蓄積を行っています。このような部分を除いた、純粋にこの2ヶ月で作ったプログラムの行数は、大体57000行といったところです。

　このころの OuDia は、基本コンセプトや画面の見た目は現在とほぼ同じでしたが、動作が重いという大欠点を持っていました。現在のOuDiaに比べると、すべての動作が重く、使っていてストレスを感じるものでした。
　特に重かったのが [編集]－[元に戻す] の動作。いわゆるアンドゥ機能でした。ある程度の編集データになると、アンドゥ動作に３秒以上もかかることもありました。当時はアンドゥ動作中に砂時計カーソルの表示を行っていなかったので、作者ですら「フリーズか？」と思うこともありました。

　OuDia と同じ分野のソフトウエアに WinDIA があります。このため、あらゆる面において、どうしても OuDia と WinDIA を比較してしまいます。
　この頃の OuDia は、WinDIAと比較しても相当動作が重いものでした。というより、作ってみてはじめて WinDIA がいかに軽快なソフトウエアなのかがわかり、驚嘆してしまいました。パソコンの性能が今とは比較にならないほど低く、ソフトウエア開発環境も今とは比較にならないほど貧弱な時代において、 WinDIA ほどのソフトを開発なさった ふゆき 氏には只々脱帽という思いでした。

　『UI』は User Interface （ユーザーインターフェース）の略です。ユーザーインターフェースは、ソフトウエアがユーザーとの対話を行う機構・つまり画面設計のことです。
　画面設計は通常、ドメインモデリングの結果をもとに行います。画面の種類や機能は通常、ドメインモデリング上での『クラス』と対応関係を持ちます。例えば、

• 　『路線』クラスの属性を設定するための画面・・・『路線ファイルのプロパティ』ダイアログ
• 　『路線』クラスに含まれる『駅』を追加・削除する画面・・・『駅ビュー』
• 　『駅』の属性（プロパティ）を編集する画面・・・『駅のプロパティ』ダイアログ

という具合です。各画面に入力可能な項目も、ドメインモデリングの結果であるクラスの属性をもとにすれば、大筋は自然に決まります。
　こうして、全１２個の画面の仕様をある程度決定したところで、ようやくプログラミング言語でプログラムの動作を記述していく作業（プログラミング）に着手できるわけです。

　プログラミングという作業は、通常はそれほど創意工夫を必要とする作業ではありません。設計段階で「何を作るのか」が明確になっていれば、あとはそれにしたがってこつこつ進めていくような作業です。しかし、作業にはどうしてもパソコンが必要なため、屋内にこもっての作業にならざるを得ません。
　これに対して、モデリングや設計といった作業は、コーディングの何倍も頭をひねる作業になりますし、ひらめきも必要です。しかし、この作業は紙と鉛筆があればできるため、あまり場所を選びません。むしろ、デスクに向かいっぱなしよりも、環境が変わった方が、いい考えが浮かぶこともあります。

　僕は、電車やバスに乗っている間に設計を行うことが多かったと思います。家のデスクだと、ついついテレビを見てしまうことがあったりします（お昼の連続ドラマにハマってしまいます・・・）。が、昼間の空いている電車なら、テレビは見られないし、周りに知っている人もいない空間なので、結構集中できるんですね。幸い僕は京阪神在住なので、ＪＲでいわゆる『大回り乗車』をすれば、少ないお金で長時間、電車に座っていられます。また、ときどき流れる景色を見るのも気分転換になります。
　あと、OuDiaを作っている時期には愛知県で『愛・地球博』が開催されており、僕も何度か訪れました（平日に行けるのは失業者の強みでした）。人気パビリオンに入るために長時間並ぶことが何度かありましたが、そんなときは行列待ちをしながら、ノートパッド片手に設計を考えていました。このため、２時間程度の行列は、あまり苦にならなかったように思います。もっとも、こんなことができたのは６月まででして、７月以降は猛暑のため、屋外で行列しながらの考え事はとてもできなくなりましたが・・・。

　この章では、OuDiaのプログラム開発に関するお話をしたいと思います。OuDiaのユーザー様の大部分は、ソフトウエア開発とは関わりのない鉄道ファンの方だと思いますので、そういう方々にはこの章の記事は何のことやら・・・だと思います。そういう方は読み飛ばしてくださって結構です。この記事は僕自身の記録も兼ねていますので、こういう章もあることをお許しください。

　近年では、ソフトウエアを開発するにあたっては、プログラミングにさきがけて『ドメインモデリング』という作業が行われます。
　『ドメインモデリング』の『ドメイン』は、「ソフトウエアが取り扱う世界」のことです。日本語では、『問題領域』という訳語が定着しています。ネットワーク上でコンピュータを識別する『ドメイン名』（例："homepage2.nifty.com"）とは関係がありません。
　『ドメインモデリング』は、僕も勉強不足のためかうまく説明できないんですが、「ソフトウエアが取り扱う世界の構成要素・関係・構造を分析し、文書化・図面化すること」と言えばいいでしょうか。なお、ソフトウエア開発の世界では、『ドメインモデリング』の構成要素のことを『クラス』と呼んでいます。

　 OuDia では、『ドメイン』の中心になるクラスは『路線』です。そして、それを取り巻く以下のようなクラスがある、と分析しました。

• 『路線』には、複数の『駅』が存在する。
• 『路線』には、複数の『列車種別』が設定される。
• 『路線』には、複数の『ダイヤ』が設定されている。
• 『ダイヤ』には、『下り』『上り』それぞれの複数の『列車』が設定される。
• 『列車』には、各『駅』毎に『駅時刻』が設定される。
• 『駅時刻』には、着時刻・発時刻・駅扱{運行なし・停車・通過・経由なし　のいずれか}の３つが指定される。

　今日、ソフト開発の世界では、このような構成の図面の表記法として、『UML』が広く使われています。『UML』では、『ドメイン』の世界に存在するクラスの関係・構成を『クラス図』で表します。OuDia 開発時に作成した図面は、以下のようなものでした。

この図面には、『OuDia』を構成するウインドウ・ダイアログ・ファイルといったものは含まれていません。『OuDia』のウインドウ・ダイアログはあくまで『ドメイン』内の『路線』・『駅』・『ダイヤ』・『列車』・『駅時刻』を編集するための窓口であり、「OuDia が取り扱う世界の構成要素」とはいえないからです。また、路線ファイルは「『ドメイン』の構成要素をファイルに記録したもの」であり、これも「OuDia が取り扱う世界の構成要素」ではないからです。

　ここでの作業は、いわば「当たり前のことを文書化・図面化している」だけにすぎません。しかし、プログラムの作成は、とても細かい作業の積み重ねのため、しばしば作業の進行方向を見失いそうになるんですね。そうなるとプログラム作成中に考えが混乱し、「自分自身が作っているものが正しいかどうか分からない」・「自分自身が作ったものを後で見ると、何のためのものか分からない」・「無駄なものを作ってしまった」という状況が発生しだします。そんなときに、『ドメインモデル』が明確にされていれば、それが開発の進行方向決定のヒントになるわけです。

　2001年に仕事が忙しくなってから、開発作業がすっかり進まなくなっていた OuDia でしたが、ネックだった『グリッド形式ビュー』は、４年にわたる試行錯誤の末、ようやく実用可能な水準になっていました。これ以外にも、 OuDia を完成させる上での技術的な問題はいくつかありましたが、それらもこの４年間のうちに少しずつ解消できていました。これにより、僕自身が OuDia を「無理なく作れる」と思えるようになってきていました。

　2005年５月、それまで勤めていた会社を辞めて、再び自由な時間が増えました。この機会に、なかなか作れなかったダイヤグラム描画ソフトを一気に作ってしまおう、という気になりました。これまでは「いつかできればいいなあ・・・」という存在だった OuDia の製作は、このときを境に一気に具体化することになります。

　僕は大学を卒業してからずっとプログラムの開発を仕事にしてきましたが、この頃は仕事に自信を失くしていたころで、プログラムを作る仕事に対するやりがいも見失いかけていました。かといって、プログラム開発以外にやりたいことも見つけられないでいました。そんな中でしたが、「とりあえず、自由な時間のある今のうちにやっておいた方がいいことって何だろう？」と考えたときに、思いついたのが OuDia の開発だったわけです。また、 OuDia の開発を通して、プログラマとしての自分の能力を見つめなおしてみたいという気持ちもありました。僕にとって OuDia の開発は、「自分が使いたいソフトを作る」ということに加えて、「キャリアの棚卸し」の意味も持っていたわけです。

（OuDia 開発の経緯-5b 『グリッド形式ビュー』の開発 からの続き）

　実際に『グリッド形式ビュー』を自分で作ってみると、やはりプログラムはなかなか複雑なものになりました。これを、分かりやすい構造で、それなりに利用しやすく、なおかつ拡張性のある設計にまとめあげるまでには、設計の修正と試作を何度も繰り返すことになりました。

　また、試作品の頃の『グリッド形式ビュー』は、今よりもずっと動作が遅いものでした。OuDiaの『時刻表ビュー』に使うためには、横方向５００列・縦方向１００列程度で、しかも数字がぎっしり並んだ画面を実用的な速度で表示する必要がありましたが、この頃の『グリッド形式ビュー』は、行や列の数が多くなるのに従って動作速度はどんどん遅くなりました。横５００列の表となると、単に表示するだけで４秒程度の時間がかかるという始末で、とても実用に耐える代物ではありませんでした。
　これが限界のはずはありません。WinDIAは、同じくらいの数の表を迅速に表示できています。遅いのは明らかに設計がまずいからです。
　これも、高速化に向けて設計の修正を何度も繰り返して、ようやく実用化可能な速度になりました。

　※　なお、この試行錯誤の過程で、表示の速いフォントと遅いフォントがあることに気がつきました。例えば、文字の横幅が一定の『ＭＳ ゴシック』と、プロポーショナルフォント(横幅が文字によって異なるフォント)の『ＭＳ Ｐゴシック』とで表示速度を比較した場合、『ＭＳ ゴシック』の方が断然速いのです。このため、OuDiaではデフォルトのフォントを『ＭＳ ゴシック』にしています。

　OuDia開発のスタート（2000年後半）で、2000年後半ごろに自由な時間が多く取れるようになった・・・と述べましたが、2001年の年末頃からは再び仕事が忙しくなりました。それ以後は、土日の、それもたまに開発するだけという状態だったので（土日のうちの片一方は朝寝して終わりでしたし、連休は旅行がしたいですし・・・）、開発の進捗は非常に遅いものでした。特に、2001年8月から2003年11月までの２年余りは全く手をつけていません。こんな調子でしたから、『グリッド形式ビュー』の最初の試作品の設計を始めてから、現在のOuDiaに採用している『グリッド形式ビュー』の試作品が完成するまで、何と４年もかかってしまいました。

　OuDia で、ユーザーが最も長時間使用する画面は、おそらく『時刻表ビュー』だと思います。
　この『時刻表ビュー』をはじめとした表形式の画面のことを、OuDiaでは『グリッド形式ビュー』と呼んでいます。Microsoft Excel の画面でお馴染みの形式です。なお、『グリッド』(grid)には、「格子」・「網」・「碁盤目」といった意味があります。

　OuDiaを作成するにあたり、この『グリッド形式ビュー』をどうやって実現するかが問題になりました。この方針を決定しないと、作り始めることができません。

　まず、OuDia の『時刻表ビュー』に使う『グリッド形式ビュー』にはどんな機能が必要なのかを考えてみました。

1. 各セル（升目）に、任意の文字を表示できること。
2. それぞれのセルの文字のフォントや文字配置（右寄せ・左寄せ）は、個別に設定できること。また、文字の色や背景色も、セルごとに個別に設定できること。
3. 各行・列の幅が個別に設定可能であること。
4. 行・列の間の罫線の色や太さは、個別に設定できること。
5. 隣り合ったセルの結合が可能であること。
6. スクロールバーによるスクロールが可能であること。
7. 画面上のセルのうちの一つを、『フォーカスセル』とすること。『フォーカスセル』は、点線の枠線で表示する。『フォーカスセル』は、矢印キーやマウスによるクリックで、ユーザーが任意に移動できること。さらに、『フォーカスセル』の移動に合わせて、画面をスクロールさせること。
8. 表形式ビューを画面に表示するだけでなく、プリンタに印刷できなくてはならない。

　「Microsoft Excel の画面でお馴染みの形式です」などとサラッと書きましたが、実際にこれだけの機能を持った画面を自分で作るのには、かなり手間がかかることが予想できました。

　ところで、このようなグリッド形式の画面を実現する方法として、自分でグリッドの機能を作る以外に、コンポーネントを利用するという方法があります。コンポーネントとは、自分のアプリケーションにとりこんで使うことのできるプログラムの部品のことです。グリッドを実現するためのコンポーネントとして、 "MSFlexGrid" というものがあることは知っていました。

　しかし、 "MSFlexGrid" では、表示に関しての必要条件、つまり上の１．～７．までは実現できるものの、表を印刷することができません。また、 "MSFlexGrid" をはじめとするコンポーネントを利用する場合、コンポーネントの機能に不満があったとしても、コンポーネント自体を改造することは不可能です。OuDiaで最も重要な画面である『時刻表ビュー』を作るにあたり、画面の機能が自由に変更できないとすれば、それは大問題です。
　結局、コンポーネントの利用は断念し、『グリッド形式ビュー』を一から自作することにしました。

(つづく)

  『3：OuDia開発のスタート』で述べましたが、「どんなソフトを作るのか」のイメージを整理するため、仮のユーザーズマニュアルを作成してみることにしました。

　OuDiaのユーザーズマニュアルは、『HTML Help』という方式になっています。このときの僕は、HTML Help に関心を持っていましたが使ったことはありませんでした。「これを機会にHTML Helpを作ってみたい」というのも、マニュアルを作成しようとした理由です。

　HTML Helpを作るのは、このときが初めてでしたが、作ってみるとこれが意外に簡単でした。HTML Helpを作成する手順を簡単に書くと、以下のようなものになります。

1. HTML Helpの各ページを、HTMLファイルで作成する
2. HTML Helpの目次を作成する。
3. １．で作ったHTMLファイルと、２．で作った目次ファイルをコンパイルして、HTML Helpファイル(.chm ファイル)を作成する。

　このうちの１．は、普通のホームページ製作の作業と全く同じです。『FrontPage』や『ホームページビルダー』などの、一般的なホームページ作成ソフトで簡単に作成できます。また、作成したHTMLファイルはそのままWEBサイトで公開することもできます。現在のOuDiaではその特性を活かし、マニュアルをWEBサイト上で公開しています。

　２．と３．は、『HTML Help Workshop』というツールを使います。このソフトは英語版しかなく、決して使いやすくありませんが、使い方が分かってしまえば、手順は簡単です。

　HTML Help Workshop の入手方法は、こちらをごらんください。
 http://www.microsoft.com/japan/office/ork/2003/tools/BoxA02.htm

　HTML Help が導入される以前のWindowsのソフトのヘルプは、WinHelpという方式でした（WinDIAのヘルプも、この方式です）。しかし、これの作成は非常に時間と手間がかかりました。比較的簡単なソフトウエアの場合では、ソフト本体を作成するよりヘルプを作成する方が時間がかかるということすらありました。このため、ヘルプを搭載していないアプリケーションも多くありました。
　HTMLHelpによって楽にヘルプが作れるようになったのは、HTMLというファイル形式自体の表現力の高さ・使い勝手のよさによるところが大きいと思います。
　2000年当時は、一般の人々によるホームページが増えつつあった頃です。このころの僕自身は、ようやく個人のPCを所持してインターネットを利用し始めたころであり、HTMLファイルを書くのはこのときが初めてでしたが、「これだけ簡単に作れるんなら、流行るわけだ」と納得しました。

　2000年の後半ごろ、それまで仕事が忙しかった状況から、自由な時間が多くとれる状況になりました。このとき、「列車を自由自在に変更できるダイヤグラム描画ソフトを作ってみようかな・・・」と、何となく思い立ちました。僕は最初からOuDiaの作成に本腰を入れていたわけではなく、当時は片手間気分ではありましたが、一応この時点がOuDia開発のスタートだと言えます。

　もっとも、当時はOuDiaという名前はありませんでした。といっても、何かを作ろうというときに、製作対象が名無しではイメージも沸きませんし、何よりソフトウエアのファイル名も決められないので、とりあえず『DiagramEdit（仮称）』という名前をつけていました（今思い出しても、自分のネーミングセンスのなさには嫌気がさしてきます）。

　まず考えたのは、「どんなソフトを作るのか」ということです。具体的には、「どんな画面があるのか」・「その画面でどんな操作をすればいいのか」ということを考えていました。ソフトウエア開発の用語でいうところの『外部設計』ですね。

　最初のうちは、外部設計は手書きメモで作成していましたが、ある程度考えがまとまってきたところで、とりあえず簡単なユーザーズマニュアルを作成してみることにしました。この時点では実物のソフトウエアはないため、画面イメージについては、ドローツールやキャラ絵(文字の組み合わせで図形を構成したもの)で代用していました。

　OuDiaのユーザーズマニュアルは、『HTML Help』という方式になっています。僕自身がHTML Help を使ったのはこのときが初めてでしたが、これについては後述したいと思います。

　このときの構想は、現在のOuDiaとは少し違っていました。『駅』のデータには、駅名と駅規模のほか、駅間距離をkm単位で入力できるようにするつもりでいました。ダイヤグラム画面での縦軸の駅間の幅は、この駅間距離をもとに決定するつもりでいました（現在は、駅間最小所要時間で決定しています）。
　また、『列車種別』の指定の代わりに『列車パターン』を指定するようになっていました。『列車パターン』には、列車種別ごとの停車駅と、各駅間所要時分を設定するようになっており、時刻表の画面では始発駅で『発時刻』と『列車パターン』を設定するだけで、終点までの時刻が自動的に設定されるようなものを考えていました。

　現在のOuDiaには、これらの機能は採用していません。
　『列車パターン』の機能を採用しなかったのは、

• 複数列車のコピー・ペースト
• 列車の時刻の繰上げ・繰下げ

ができれば十分代替になるだろうと判断したからです。また、ほとんどの路線では、同じ停車駅でも所要時間は列車ごとにばらついており、『列車パターン』通りにはいかないというのも理由です。

　駅間距離の入力を採用しなかったのは、実物のダイヤグラムが距離ではなく運転時分をもとに縦軸の幅を決定していることが分かったからです。

参考：時刻表大研究（監修：鉄道友の会。廣済堂出版）

  僕がパソコンを購入したのは、2000年のことだったと思います。さっそくインターネットプロバイダ @nifty に入会し、@nifty内の『鉄道フォーラム』からWinDIAをダウンロード・インストールしました。会社のパソコンで試している状態では、時間のかかる時刻表データ入力はとてもできませんでしたが、自分のPCを自分の家で使うとなると、時間の制約も遠慮もありません。いくつかの路線のデータを入力して、ダイヤグラムを眺めたりしていました。

　ところで、ダイヤを眺めていると、「この列車はこの時間にも走っていればいいのに」「この路線にはこんな列車があればいいのに」などと思うことがたくさんあります。ちょうど、プロ野球ファンの人がテレビ観戦をしながら監督気分で「あいつを出せばいいのに」などと思うのと同じようなものかもしれません。

　ところが、「自分が思うような列車を、WinDIA上で試しに追加してみよう」と思った場合、これが簡単ではないんですね。WinDIAは、既存の時刻表のデータを入力してダイヤグラムを表示させるには十分なソフトなのですが、入力後のデータを変形・編集するようにはできていないのです。このとき、僕は「入力済みの時刻表データ上に、自分が思うような列車を自由自在に追加したり、既存列車の時刻を自由に変更できるようなソフトがあればなあ・・・」と思いました。これが、OuDia開発の原点です。

　現在のOuDiaには、

• 複数列車のコピー・ペースト
• 列車の時刻の繰上げ・繰下げ

という機能があります。この２つを組み合わせることにより、「入力済みの時刻表データ上に、自分が思うような列車を自由自在に追加」ということが、一応実現できるようになっています。
　例えば、始発駅であるＡ駅 10:00 発の列車がある場合に、Ａ駅10:30発の列車を増発してみたいと思ったら、

1. 10:00発の列車をコピー・ペーストして２本にする
2. ２本目の 10:00 発の列車の、Ａ駅の発時刻を 10:00 から 10:30 に繰下げる

という手順で、列車を追加することができます。
　僕自身は、この２つの機能こそが、OuDiaで最も重要な仕様だと思っています。この２つの機能による自由な列車の追加・変形ができないのなら、OuDiaを作りはしませんでした。

　みなさん、こんにちは。take-okmです。
　本業多忙で、しばらくOuDiaのバージョンアップからは遠ざかってしまっています。ユーザーの皆様、本当に申し訳ありません。
　僕自身もしばらく開発作業から離れてしまったため、OuDiaの実像を忘れかけつつあります。でも、開発者としては、こういったことはきちんと記録に残しておくべきです。
　そういったわけで、改めてOuDia開発の経緯を、この場を使って振り返ってみたいと思います。
　閲覧者の皆様に興味を持っていただけるとは思えませんが、これは僕自身の記録という面が大きいということで、ご容赦ください。

　僕がOuDiaの最初のバージョンを公開したのは2005年８月のことでしたが、そのずっと以前から、鉄道趣味人を対象にしたダイヤグラム描画ソフトウエアはいくつか開発され、ネットワークを介して配布されていました。その中でも最も広く使われているソフトは、今さら言うまでもなく、ふゆき氏作の "WinDIA" です。WinDIAの歴史は結構長く、ReadMeファイルによれば、最初のバージョンが完成したのは1994年7月です。

　僕が初めてWinDIAに触れたのは、1995年ごろだったと思います。もともと鉄道ダイヤに興味のあった僕は、10代のころには方眼紙に手書きでダイヤグラムを作ろうとしたりしてきました。が、これは大変手間のかかる作業なんですね。それだけに、画面上で時刻表を編集するだけでダイヤグラムを表示・印刷してくれるWinDIAを見たときの衝撃は大きかったです。

　ただし、その頃の僕は個人ではパソコンを保有していませんでした。WinDIAも、会社のパソコン上で試しに使ってみただけでした。当時はまだ新米プログラマだった僕には、WinDIAほどのプログラムを作る力は到底ありませんでしたから、「ああ、すごいソフトを作る人がいるんだなあ」と思うだけでした。