東京メトロ（正式な社名は東京地下鉄株式会社）のルーツを辿ると、大正時代の「東京地下鉄道」というベンチャー企業に行き当たります。東京に地下鉄を走らせることを目的に早川徳次（はやかわのりつぐ）という鉄道マンによって、1920年に作られた会社です。
地下鉄というビジネスの事業性、実現性を投資家や銀行に説いて回ってお金を集め、浅草-上野間に着工したのが、1925年（大正14年）9月27日。同区間が開業したは1927年（昭和2年）12月30日のことでした。
地下鉄が走り始める1920年代の東京では、人々の主な交通手段は路面電車で、それは「市電」と呼ばれていました。東京都はまだ存在せず、都心にあった15区（今の23区とは名前も区分けも異なる）の地域を東京市と呼んでいた時代です。
市電は山手線内のエリアをほぼ隙間なくカバーし、年々新規路線が増えていくような状況でした。当時の東京市電の路線状況はこちらから。それでも、伸び続ける交通需要に対して、路面電車ではすでに不足気味でした。
当時の流行歌で、東京節という歌があります。(1919年リリース) この中で、「東京名物の満員電車」という歌詞がでてきます。今でも名物ですが、東京の満員電車はこのあたりがルーツのようです。 この歌では「いくら待っても来やしない」ともあり、今の満員電車とは混雑度合いが全く違っていたようです。
実業家の福澤桃介（福澤諭吉の娘婿）という人で、早川徳次の東京地下鉄道を作る10年以上前に、こちらも東京地下鉄道という会社を立ち上げました。ですが、こちらは時代の先を行き過ぎていたようで、誰にも理解されずに建設が許可されませんでした。
早川徳次の計画もすんなりと進んだわけではありませんでした。東京の交通需要の不足から新しい公共交通が必要とされていた、と今から見れば時代の必然のように思えますが、当時の人にはなかなか理解されなかったようです。まずは鉄道省や東京市に地下鉄建設を働きかけるも理解されず。仕方がない、自分で作るぞと決意し、技術的な問題を一つずつ潰していき、事業性の調査をして周囲を説得して資金を集めて、免許取得、会社設立、着工。難工事を乗り越えて、実際に開業するところまでこぎつけました。
彼をそこまで動かしたものはなんだったのか、ただの金儲けではなかったように思えます。
ちなみにロンドンで世界初の地下鉄が走り出したのは、1863年のことです。そのころの日本といえば、14代将軍の徳川家茂が229年ぶりに京都に上洛し、 孝明天皇に攘夷を誓っていました。福澤桃介による地下鉄計画ですら、ロンドンの地下鉄から40年以上経っています。当時のイギリスと日本の国力の差がよく分かります。
1920年代の日本は、不況・恐慌の時代でした。第一次世界大戦後の不況(1920年3月〜)、関東大震災(1923年9月1日）、昭和金融恐慌（1927年3月〜）が続きます。
不況であるにも関わらず、物価がどんどん上がっていく（スタグフレーション）状況で、とどめを刺したのが世界恐慌(1929年10月〜)でした。
開業当時の上野駅の様子についての資料を見つけました。
実際には、スマートフォンから直接オープンデータを公開するサーバーにアクセスするようなアプリを開発することは、運営側は想定していなかったようで、利用規約にもやんわりと直接アクセスするアプリはお断りのようなことが書いてありました。書いてあったのですが、それを知らずに作り始めました。（今から思うと冷や汗モノです。せっかく作ったアプリがガイドライン違反で応募できない、なんて事態になっていたらと思うと。。。 こういう文書はしっかりと目を通すべきですね）
開発者サイトには、フォーラムがあって、いろいろな開発者の人たちがいろいろな意見を運営側の人たちとやりとりしていました。
あるとき、「ガイドラインには直接アクセスするアプリは作らないでほしいといったことが書いてあるが、サーバー立てるのもホネだし、これはちょっと何とかして欲しい」と誰かが言いはじめ、「そうだそうだ」と周りの人たちも言い始め、運営側もそんなにいうのなら、といったような感じで、直接アクセスするアプリが解禁になりました。（その裏で、わたしは「え、ダメだったの！？」とビックリしていました。）
それとほぼ同時に、オープンデータを公開するシステムにガードタイムが導入されました。ガードタイムとは、あるアクセスと次のアクセスの間に一定の時間を置かなければいけない制限のことで、同じ端末から連続してアクセスが集中して、他のユーザーに迷惑をかけるのを防ぐ意味があります。
実はこのガードタイムの導入が、わたしにとってはそれなりに痛手でした。この頃には、オープンデータにアクセスして、ココメトロの原型のようなアプリが出来上がっていたのですが、連続してアクセスするような動作をしていたため、まったく動かなくなってしまったのです。
これが9月の終わりの頃の話です。9月の半ばから作り始め、9月の終わりにはそこそこ動くモノが出来ていたというわけですが、この初めの頃というのは開発をしている期間で一番楽しい頃で、どんどんアプリが充実してくる時期なのです。少なくともわたしにとっては。
初めてサーバーにアクセスして駅名を取得できた、時刻表を取得できた、じゃぁ次はこうしてみよう、ああしてみようというのが続き、時間を忘れて没頭してしまう。自分が考えて作ったカラクリが思い通りに動く、ちょっとエラくなったみたい、という単純な喜びを忘れられない。
プログラマというのは、多かれ少なかれ、そういう単純な動機で動いている人種と思います。
この先は、ドロドロした苦悶の日々が始まります。まず、このガードタイム問題に限りませんが、コードをたくさん書いて動きが複雑になってくるとバグ取りも一苦労になってきます。あっちこっちのコードを行き来して読んだり、デバッグプリントを埋め込んだり、バグにフォーカスしたコードを書いてみたり、と手がかかるようになってきます。
また、いつまでも、ああ動いたというヨロコビに浸っていることはできません。作ってみた機能を取捨選択して、応募するに足るアプリにまとめていかないといけません。ある機能をつけてみた、イマイチだった、作り直し、といったようなことが続きます。前回までクダクダと書いたようなことは、この期間にああだこうだといろいろと試してみて、考えた結果でもあります。
ようやく、これならなんとか、という出来栄えのアプリになり、締め切りまで2週間を残して、Appleへの審査申請を済ませます。これが11月の頭のことでした。
(iPhoneのアプリは、Apple社の審査に合格しないと公開できないのです。審査にはだいたい1週間ほどかかります）
バグを直して申請し直すか。だが、申請し直した後、もし別の問題でリジェクトされたら間に合わない。このバグは、Appleの審査でリジェクト（審査の結果、問題を指摘され差し戻される）される可能性が高い。仕方なく、審査のやり直しを決意します。どうか、すんなり審査が通りますように。
この方式の良いところは、表示する文字を減らせることです。掲示物としては合理的な表示方法です。掲示板の限られた面積の中で、文字の数を減らし、一文字を大きくして、視認性を上げることができます。そして、それはスマホの狭い画面の中でも同じことが言えます。
ココメトロでは、出発時刻の他に到着予定時刻も表示する必要があります。例えば、18時30分発の列車があった場合、出発駅の横には”30”と表示されます。ずっと先の駅に、19時40分に到着する場合、その駅の横に”40”と表示してしまうと、18時40分と誤認する可能性があるのです。
それがどうした、という話なんですけど、普通はこの順番が逆なのです。路線名が先で、駅名は後。銀座線上野駅、丸ノ内線新宿駅、千代田線赤坂駅と、よく言うでしょう。この呼び方は、ある路線があって、その途中停車のポイントとして駅がある、「駅」は「路線」の一部であるという考えを反映していると言えます。路線に対して駅がぶら下がるという形。路線が一番、駅が二番。
これは、いわゆる列車を走らせる側の考え方です。
その一方で、こんな考え方もあります。誰かに電車の乗り換えを説明しようとするときを思い浮かべてください。例えば
「上野駅から銀座線で銀座駅に行って、そこで丸ノ内線に乗り換えて、新宿駅に向かう」
とっさに出てきたこの文から読み取れるのは、駅を基準に語っているということです。
乗客はある駅から別の駅に移動するために電車に乗る、路線（電車）は手段にすぎない。乗客はまず駅のほうを先に考え、その次にどの路線を使おうかと考えるものなのです。駅が一番、路線は二番。
こちらはいわば、列車に乗る側の考え方です。
路線を先に考えるか、駅を先に考えるか。どうでもいいような話のようですが、このことに気づいたとき、鉄道事業者と乗客という立場の違いを決定的に表しているなと思いました。このアプリは、「ホームにある掲示物を見る人のためのアプリ」であって、ここはやはり乗客の立場に立つべきだとも思いました。
いわば、「鳥の目」で路線全体についての情報を提供するのではなく、「虫の目」になって、ひとりひとりの乗客の立場で、今いる駅について、近くの列車についての情報「だけ」を提供する。これは、いつもホームの掲示物がしている情報提供と同じです。
例えば、下の図のような例。この区間は有楽町線と副都心線が並行して走っている区間です。普通の路線図では、右の図のように実際の線路を忠実に表現しようとして、縦線を2本描くところですが、「虫の目」という観点では、1人の乗客が同時に2つの路線に乗ることはできないので、縦線を2本描くことはありません。むしろ、左側の図のように各駅で並行する別の路線に乗り換えできると考えます。
まず、ホームに置く掲示物という性質上、あらゆる人が見て役に立つような情報を載せる必要があります。ホームにいる多くの人は、それぞれ目的とする駅が違います。それら各駅の到着予定時刻を示さなければなりません。
また、列車は次から次へとやってきます。当然ですが、同じ目的地であっても列車によって到着予定時刻は異なります。これらをすべて示さなければ到着予定時刻を知らせたことになりません。到着予定時刻は、表示すべきパターンが多すぎて、掲示物で伝えることが難しい情報なのです。
現実的な解として、ホームには「所要時間一覧表」というものがあります。今の駅から先の駅への所要時間が示されています。路線図と一緒になっている場合が多いです。ホームにいる人が目的地の到着予定時刻を知るには、まず自分が乗ろうとする列車の出発時刻を調べ、それにこの所要時間を足して計算する必要があります。
乗り換え検索ではもちろん到着予定時刻を知ることができます。ですが、そのためには再びヒトからサルに戻り、目的地となる駅を入力しなければなりません。私ならその段階で到着予定時刻を知ろうとすることを諦めてしまいます。
表示すべきパターンが多すぎて、掲示物で伝えるのが難しい情報。さらに既存のアプリであっても提供するのにひと手間がかかる情報。それをより簡単に簡便に伝える。
このコンテストに応募するアプリの形がやっと見えてきました。
到着予定時刻「だけ」を表示するのでは、なんだかよく分からないアプリになってしまう。行先表示板や路線図が遠くて見えない、ホーム内を探しに行くのが面倒、改札の外でも情報が欲しい、という場合に応えるため、これらの情報も合わせて表示し、わかるようにしました。
また、前々回に書いたように、目的駅を入力しないアプリにしようと決めたので、停まる可能性のあるすべての駅の到着予定時刻を表示するようにしました。結果として、より掲示物に近い感じになりました。
こうしてできたのが、ココメトロの路線図の画面です。
前回から続く
電車のスマホアプリで、乗り換え検索でないものを探していたわけですが、そもそも乗り換え検索が世に現れる前から、電車は走っていたわけです。わたしだって、電車に乗る前に毎回必ず乗り換え検索を使うわけではありません。
列車の種類と行先を見ることで、次に来る列車が目的の駅に停まるかが分かります。つまり、自分が乗るべき列車かどうかが分かります。さらに出発時刻を見ることで、あと何分ここで待てば列車に乗れるのか分かります。
従来：少し首を振って行先表示板を見て、さらに少し頭を使って路線図を思い出し、この列車に乗ろうと決める。
新しい：スマホの小さい画面をのぞき込み、サルのように苦心して文字を打ち込み、表示された結果に１から10まで従って、列車に乗る。
後者の方が、より間違いなく効率的に移動できるでしょうが、前者の方がヒトとして、ずっと高度で難しい情報処理・判断をしています。 また、ハタ目から見て、イライラしながら猫背でスマホに向き合っている姿は、とても「スマート」には見えないことでしょう。
・・・という結論では、困るのです。賞金が。無理矢理でもスマホを使わないといけないのです。いや、無理矢理使わなくちゃいけないようなアプリなら作りたくないなぁ。スマホありき、というところがなんだかスマートじゃない。使ってもいいし、使わなくてもいい、といったそんなアプリがいいな。
などと、こういった思考を経て、これから作ろうとするスマホアプリの目指すものが、既存の乗り換え検索ではない、ということは確かになりました。
むしろ、「スマートフォン」「乗り換え検索」出現よりも前からあった、「スマート」な情報提供手段、すなわちホームにある掲示物や看板の情報を追加、補足するようなアプローチのアプリにしよう、と思いました。こういうアプリならば、使う人はまず行先表示板を見て、もうちょっと情報が欲しいというときに初めてスマホが出てくる、といったことになります。
ココメトロというアプリが生まれるまでに、わたしがどういうことを考えていたのか、思い出して書き留めておこうと思います。
コンテストで賞を頂いてからというもの、このアプリに対して様々な感想を頂きました。そんなふうに受け止められたのか、と驚くこともあったので、ひょっとしたらこの雑文も誰かの役に立つことがあるかもしれません。
スマホアプリを作ったことはあったので、頑張れば入賞くらいならできるかもしれない、と最初は思いました。とりあえず、応募できるかどうかは分からないけれど、APIのユーザー登録をして、何ができるかを調べ始めました。
電車に乗る人が使うスマホアプリといえば、ひとつしか思い浮かびません。
乗換え検索のアプリです。
出発駅と到着駅を入力すれば、どの路線を使えばいいか教えてくれる、大変便利なものです。わたしもよく使います。