ブログ「ガ島通信」などで知られる藤代裕之さんは現在、内閣官房震災ボランティア連携室と連携している民間プロジェクト「助けあいジャパン」に関わっている。ネットを使った被災地支援の「現場」では何が起き、何に直面しているのか。ネットという手段を持つるわたしたちには何が求められているのだろうか。震災とネット、情報を考える、マスメディアには掲載されにくい「現場」からの現在進行形のルポとして、藤代さんに随時報告していただきます。（編集部）

▼その1：「情報の真空状態」が続いている

▼その2：できる範囲でやる──ボランティア情報サイトの立ち上げ

▼その3：「ありがとうと言われたいだけのボランティアは必要としていない」

▼その4：ターニングポイントになった夜

▼その5：チームを作る　誰がDBを作るか、プロデューサーは誰か

　3連休明けの火曜日（3月22日）。データベース開発を実現するために、とにかく動くことにした。チームがビルドされたとはいえ絵に描いた餅。なにせデータベースの開発担当者も決まっていなかった。上司に事情を説明して会社を出て、昼には絶望的な状況に直面し、夜には関係者のキックオフが行われるというめまぐるしい1日。何がなんだか分からないカオス（混沌）の中から動きが始まった。

霞ヶ関の評判

　助けあいジャパンを統括する佐藤尚之氏とチーム構成について打ち合わせるため、会社を出て汐留に移動する合間にもさまざまなところに電話をかけ続けていた。Webサービス開発者、研究機関の研究者、大阪に勤める知人に「明日から東京に来れないか」という依頼すらした。ほとんどの人が突然の電話にも関わらず、できる範囲での協力を約束してくれた。震災に対して「何か取り組みたい」という気持ちに後押しされていた。

　佐藤氏とは、データベースに関しては藤代に権限を集約することを依頼し、夕方に会うことを約束した。非常時の意思決定プロセスに合議制はなじまない。調整して落としどころを探ったり、なんとなく合意形成が行われたりという「日本的プロセス」は時間がかかりすぎ、議論をしている間に状況が変化してしまう。それに丁重に調整を行っても、関係者が納得して進んでいるかは別問題だ。助けあいジャパンという全体の中で、どの部分にどれくらいの権限があるかを押さえておく必要があった。

　次に霞ヶ関に向かった。助けあいジャパンはボランティア連携室という「公（政と官）」と連携している。スムーズに進めるためには官の反応も知っておきたかった。記者経験があるとはいえ、社会部が長く政治部の経験はないし、地方紙だけに中央のことは分からなかった。進める際の注意点を聞き、あわよくば協力者を得たいと考えた。

　助けあいジャパンの霞ヶ関の評判は悪かった。電話やメール、対面で次々と「やめたほうがいい」と忠告され、「バッドニュース」「筋が悪い」とすら言われた。理由はいくつかあったが、必要性は理解しているがネットのことが分かっていないのではないか、何をしているかわからない、という不信感が広がっているようだった。

　予想以上の反応の悪さに「ここまでか」と霞ヶ関を後にしようと地下鉄の入口に向かおうとした時だった。ある官僚から携帯電話に「打ち合わせたい」と連絡が入った。

もう動いているDBが見つかったが……

　指定された打ち合わせ場所に行き、話を聞くと、助けあいジャパン側にネット関連で検討を持ちかけていることがあるが、話を理解してもらえず困っているという。

　案件の1つに、物資マッチングのサービスがあった。モックアップレベルだったが既に動いており、ボランティア情報のデータベースにも使えそうだった。詳細を聞いたところ、自分の所属する会社が作っているという。まったく知らないことで驚いたが、これは渡りに船というよりは、厄介なことでもあった。事情を知らない人からは不透明な取り組みに見える可能性がある。

　しかし、大切なことはいかに早くデータベースを実現するかだ。一直線に進むためにリスクを取ることにした。「とにかく進めましょう」と話し、他省の震災対策担当者に連絡を取ってもらい、即席の打ち合わせが始まった。

　佐藤氏との打ち合わせは30分後に迫っていた。省庁関係者にも参加を依頼すると、その場にいた全員が打ち合わせに行くことで合意してくれた。

現地の負担を極力減らすことと、素早い実装の両立を目指して

会議の際のホワイトボード

　助けあいジャパンのボランティアスタッフ、官僚、自分の所属する会社の担当者という不思議な顔ぶれの会議が始まった。

　予想されていたこととはいえ、今後の体制とデータベースについて激しい議論が交わされた。時に細かな用件定義に入り込んでいった。データ登録はいつから始まるか、誰が、どこでどのような情報を入力するのか、マッチングサイトにするなら物資が届いたことをどう扱うか──。

　通常、Webサービスを作る際にはサービスイメージを考え、用件定義を行い、開発の規模や予算、スケジュールも用件定義次第となる。「よろしく頼む」のようなあいまいな用件定義を行うとプロジェクトが破綻したり、泥沼化したりする。恐ろしさは分かってはいたので、細かく聞きたい気持ちは理解できた。

　ボランティア側は、「現地が人や物であふれたらどうするのか」という懸念を表明した。マッチングシステムであれば要望に対しての充足率も分かるようにはできるが、それでは設計に時間がかかりすぎるし、構想ではいいアイデアとして使えそうでも、その通りに運用されることは少ない。現地の状況は変化する。大切なことは現地への負担を極力減らすことと、素早い実装を両立させること。物資の場合は送り届けられれば現地に山と詰まれてしまう可能性もあるが、人の場合は帰ってもらうことができる。

　データベースはシンプルにボランティア情報（人）の提供から始め、利用が進むにつれて機能を追加していく冗長性の高い設計にする──と決めていて、細かな議論をするつもりはなかった。「方向性だけ決めてくれればいい。とにかくこれでやらせてくれ」と貫き通した。