米国西海岸時間の 3 月 10 日（木）22 時（日本時間 3 月 11 日（金）15 時）前、シリコンバレーの自宅でくつろいでいた Google 社員、カ・ピン イー（Ka-Ping Yee）の携帯電話に、クライシスレスポンスチームから 1 本のメッセージが飛び込んできた。

　第 4 回「クライシスレスポンスの仕組み」で紹介したように、Google 社内には世界各地で起こる自然災害に対応するためのクライシスレスポンスチームが常設されており、カ・ピン イーもメンバーの 1 人だ。日本時間の 3 月 11 日（金）14:46 に発生した東日本大震災を受け、クライシスレスポンスチームはすぐさま活動を開始したのである。

　カ・ピン イーが自宅のパソコンからクライシスレスポンスチームの専用チャットルームに入ると、すでに同僚のプレム ラマスワミ（Prem Ramaswami）とライアン フェラー（Ryan Falor）がディスカッションを始めていた。クライシスレスポンスチームが取る対応は災害の内容によって異なってくるが、多くの人にとってまず必要なのは家族や友人の安否情報だ。カ・ピン イーが中心となって開発した安否情報確認サービス「パーソンファインダー」は、2010 年 1 月のハイチ地震を皮切りに、同年 2 月のチリ地震、4 月の青海地震（中国西部の青海省チベット族自治州）、7 月のパキスタン洪水において活躍し、東日本大震災でも提供することが決定された。

　パーソンファインダーは、「App Engine」（アップエンジン）上で動作するウェブアプリケーションである。App Engine とは Google が開発者向けに提供するサービスで、開発や維持管理の手間を減らせるのが特徴だ。一般的なサーバー（ネットワーク上に置かれたコンピュータ）上でサービスを提供する場合、サービス提供者がサーバーの維持管理を行う必要があり、アクセスするユーザーや扱うデータが増えると新たなサーバーを用意したり、アクセスが 1 つのサーバーに集中しないように工夫しなければならない。これに対して App Engine では、アプリケーションをサーバーにアップロード（サーバーにプログラムを読み込ませる）すれば、すぐにサービスが利用できるようになる。パーソンファインダーは 4 度の経験を元に改良が加えられており、URL（インターネット上のアドレス）を決めさえすれば、ほとんど手間を掛けずに開始できるようになっていた。

　ただし、パーソンファインダーのメニューなどはすべて英語で書かれており翻訳が必要だった。まずカ・ピン イーらは日本語の読み書きができる社員を募って最低限の翻訳作業を行い、パーソンファインダーを起動させた。

パーソンファインダーのトップ画面で「消息情報を提供する」を選ぶと上図の入力画面になる。別のユーザーが状況のデータを追加することも可能だ。

　プレムは、面識のあった東京オフィスのブラッド エリス（Brad Elis）に連絡を取り、パーソンファインダーの外部向け公開と周知を依頼する。

　震災からわずか 1 時間 46 分後の 16:32、パーソンファインダーが公開された。

　この頃 Google 東京オフィスのこたつエリアには大勢の社員が集まり始めており、エリスはここでマーケティング担当の根来香里らと連絡をとってパーソンファインダーが開始した旨を Twitter などを通じてネットに発信していった。17:52 には災害情報特設サイトが公開され、パーソンファインダーはページのトップに掲載された。

　公開当初のパーソンファインダーは最低限の翻訳が行われていたとはいえ、まだ随所に英語のままの箇所が残っており、日本語として不自然な表現も少なくなかった。エリスは、Google ドキュメントのスプレッドシートに翻訳が必要な箇所を書き出し、他の社員の協力も仰ぎながら翻訳作業を進めていった。

　メニュー等の翻訳作業は 2 時間ほどで概ね完了したが、パーソンファインダーを使っていくうちに、いくつかの問題があることがわかってきた。特に、非スマートフォンの携帯電話から使えず、また検索機能には日本語特有の問題があった。Google の製品は最低限の国際化がなされており、パーソンファインダーも最初から漢字の入力や検索はできたのだが、漢字で 5 文字以上の名前を検索できなかったのである。また、読みがなの入力や検索もサポートされていなかった。ユーザーインターフェイスを翻訳するだけでは、日本人ユーザーに使いづらいため、プログラム自体を改良する必要が出てきた。

　そこで、モバイル系製品のプロダクトマネージャーである牧田信弘が、パーソンファインダーのプロダクトマネージャーを担当することになる。牧田はモバイル系に強いエンジニアらと協力しながら、パーソンファインダーの改良を進めていった。日本国内の（非スマートフォンの）携帯電話は、機種によって搭載しているブラウザや扱える文字コード（文字と固有番号の対応関係を決めたるルールのこと）の仕様が異なるため、実に細かなノウハウが要求されるのである。携帯電話版パーソンファインダーは 11 日の 23:50 に公開され、13 日（日）午前 2 時頃には携帯電話番号での検索もできるようになった。

　読みがな検索の問題については、Google マップ担当ソフトウェアエンジニアの川口良が担当した。震災翌日の 12 日（日）、川口は結婚記念のお祝いを兼ねて、東京ミッドタウンのホテルで家族とのんびり過ごす予定だったが、社内メーリングリストで検索の改良ができるエンジニアが求められていることを知る。そこでホテルにパソコンを持ち込み、妻に謝りながら検索機能の改良を進めたという。異体字（例：「渡辺」と「渡邉」など）を含めたあいまい検索や、漢字の読みを推定する機能は要望も多かったが、これは開発に時間がかかると思われた。Google のウェブ検索では、強力なあいまい検索や読み方の連想機能が備わっているが、パーソンファインダーは Google 本来のサービスとは切り離されたオープンソースのソフトウェアであるため、これらの機能を追加するなら自分でプログラムコードを書く必要があったのである。そこで、あいまい検索は後回しにして、まずはパーソンファインダーに読みがなの項目を追加するところから始めた。App Engine はデータベースの構造が柔軟で、アプリケーションで使う項目は比較的簡単に追加できる。

　パーソンファインダーの改良には、複数のエンジニアが同時に参加しており、変更／追加されたプログラムコードは膨大な量に上る。エンジニアの書いたプログラムコードは開発者用のメーリングリストに投稿され、コードレビュアーが問題がないかを確認し、問題なければ更新処理を行う。ちなみに App Engine では、動作中のサービスを止めることなく、機能の更新が可能だ。

　震災からの 1 週間、パーソンファインダーのコードレビュアーを担当したのは、米国本社のカ・ピン イーだった。特に最初の 2、3 日はほとんど寝ることもなく、コードのレビューを続けていた。