怒濤のような 3 月 11 日が終わって翌日の土曜日、エリスは社員全員に届くメーリングリストが大量のメールであふれていることに気づく。「何かできることがあれば手伝いたい」というメールが多かったことに気がついたエリスは、重要なメーリングリストから、その話題を分離させるべく「Japan quake volunteer（日本向けの震災ボランティア）」という新規メーリングリストを用意した。これを使って、誰がどんなことをやっていてどんな助けが必要かの情報を交換しようとしたのだ。
その後、エリスは収集した情報を元に Google Docs というサービス（現在は Google Drive に統合）でスプレッドシート（表）を作成し、誰がどんなことをやっているかを表にまとめて整理し始め、それを 14 日の月曜日、ミーティングで皆に紹介した。
ミーティングでは、思いついたアイディアも表に書き込みたいという意見が出た。営業チームの荒木温（のどか）は、Twitter などを通して社外から Google にリクエストされているアイディアをまとめていた。ただ、一度にたくさんの情報が集まり過ぎたため、エリスは 1 人で整理できなくなり助けを求めたところ、以前東京オフィスで勤務していたプロダクトマネージャーの井上陸が名乗りをあげ、整理を手伝ってくれた。
こうして Google 東京オフィスでの全災害対応を管理する表ができあがった。この表には 1 件 1 件の災害対応に対して、優先度や手伝いたい人の連絡先ともなる責任者の名前、進捗の度合いが書き込まれていた。また別表には、個々のプロジェクトを誰が手伝っているかも書き込まれた。その後、数百件のプロジェクトが書き込まれる表に成長するが、エリスはこれをいかにして管理したのか。
「私がやったのは型をつくっただけ」とエリスは謙遜する。「とりあえず表にこういった項目を書き込むということを決め、ある程度、わかっているプロジェクト、わかっている人の情報だけ書き込んで共有しました。すると、後は抜けているところに、それぞれの担当者が自分で情報を書き込んで埋めてくれたんです」
もっとも、情報に抜けがある項目は、Google Docs の条件設定機能を使って自動的に色がつくように工夫をしていたようだ。
簡単そうに語るエリスだが、表のとりまとめ以外にも多くの作業をこなしていた。毎日、他の社員たちが寝たりプログラミングに集中して、他の人とのやりとりがなくなる深夜帯に、メーリングリストのすべてのメールに目を通していたのだ（震災発生から 1 ヶ月で 569 の話題が立ち上がった）。まだ表に書き込まれていないプロジェクトや進捗の情報を補い、さらには、翌日のメーリングリストには、今誰がどんなプロジェクトを進めているか、流し読みしただけで全体像をつかめるように簡単な「まとめ」の文章を投稿していた。
その上で、個々のプロジェクトに優先度を付けるようにしていた。必要であれば、各プロジェクトの担当者から、プロジェクトの詳細を聞き出して仮の優先度を付けておき、その後の会議で優先度をどうすべきかという議論を行っていた。
「あのような状況下では、何を良しとして何を悪しとするのか、何をやるのかやらないのかという判断をする人が必要でした。判断が 100% 正しいか正しくないかではなく、統一した見解を誰かが出すということが重要でしたが、彼が一瞬にして管制塔になったことが（Google）東京で大きなスピードをあげられた理由の 1 つだと思います」と徳生は振り返る。
Crisis
Response
