X-over Development Conference (XDev) 2011 私的不完全議事録 【xdev】

IT


目黒雅叙園

9 月 16 日(金)に、目黒雅叙園にて「X-over Development Conference 2011 (XDev 2011)」が開かれました。自分が参加したセッションについて議事録を取ったので、公開します。

内容や表記に正しくないところがあれば、コメント欄やブックマークコメント、ツイッターなどで教えていただければありがたいです。



目次

大規模サイトの性能問題をゼロに リクルートの成功事例を公開 (リクルート 米谷 修氏)

1. はじめに

リクルートの目指す世界観

  • 一人ひとりのさまざまな生き方や価値観を尊重しあえる豊かな社会

事業概要

MIT United (システム部門)について

  • MIT = Marketing and IT
  • プロジェクト推進部: 大規模サイト開発、PMO 機能提供など
  • システム基盤推進室: インフラ環境構築運用、性能検証など


2. 背景と課題

  • アクセス数の増加(99 年に 15 億 PV、2013 年は 2,127 億 PV)、インフラの負荷も右肩上がり
  • サービス(PGM)の複雑化により、改修難易度も高まる
  • 高いレスポンスの実現が困難になってきている
  • Google によると、ページの読み込みが 0.5 秒遅くなると、検索数が 20% 減少する
  • Amazon によると、ページの読み込みが 0.1 秒遅くなると、売上が 1% 減少する
  • アプリ性能向上のスピードアップが競争優位性向上の重要政策の一つに

ありがちな「性能問題」発生シーン

  • Oracle が遅いと主ったら原因は Java のようだった→Java ソースを追ったら根本原因は検索エンジンだった
    • 障碍箇所の特定に時間が掛かり、サービスへの影響が拡大
  • 検索エンジンの性能テストは十分だったか?→検証部隊に検索エンジンの知見者が不足していた
    • ハイスキルな要員がタイムリーにアサインできなかったために検証が不十分
    • こういうハイスキル要員は常時必要なわけではない
  • 性能テストで問題が発覚したが、カットオーバーまでにすべてのアプリ改修が間に合わない
    • 性能問題が発覚するタイミングが遅いために、アプリ改修が間に合わない

大きく3つの課題に集約される

  1. ボトルネックの特定
  2. 高いスキルを持った要員の安定的な確保
  3. 性能問題が発覚するタイミング

3. 課題の詳細と 3 つの打ち手

  1. ボトルネック可視化ツール(Perform VIew)の独自開発
  2. プロジェクト横断の性能対策専門チームを設立
  3. 標準開発工程への性能検証フェーズ組み込み

一般的な性能問題対応のステップに展開すると……

  1. 性能検証
  2. ボトルネック特定 (打ち手 1)
  3. 改修 (打ち手 2)
  4. 解決

1. ボトルネックの特定

Perform View を導入後

  • URL に紐づくメソッドや SQL の処理時間を計測
  • パターン 1: SQL がボトルネックの場合
    • URL を平均レスポンスタイムが遅い順に表示
    • リクエストに紐づく Java メソッド、SQL、検索クエリを一覧表示
    • 処理に時間が掛かる SQL をクリック
    • SQL 詳細情報を表示
      • SQLID から Oracle Enterprise Manager での詳細調査が容易に
      • SQL 実行計画を参照
      • 実行統計も確認可能
  • パターン 2: Java がボトルネックの場合
    • URL を平均レスポンスタイムが遅い順に表示
    • リクエストに紐づく Java メソッド、SQL、検索クエリを一覧表示
    • 処理に時間が掛かる Java メソッドを特定
  • 「遅いリクエスト発見→ボトルネック箇所の迅速な特定」の特定の仕組み
    • リクエスト ID ごとにユニークな ID を発行(フレームワーク内の機能として実装)
    • この ID を SQL ロギングやリクエストロギング、Solr (検索エンジン)ロギングなどに埋め込む
    • ログファイルを分析用データベースに取り込み、集計・分析処理
    • 結果を Perform View の分析用画面に表示

2. 高いスキルを持った要員の安定的な確保

  • 従来……プロジェクトごとに性能検証担当を置かざるを得なかった
  • 問題点
    • 要員確保……採用何度が高く、高いスキルの要員がすぐにアサインできるとは限らない
    • 採用コスト……常時必要な人材ではないため、継続的に確保する場合はコスト効率が悪化
    • ナレッジ蓄積……異なるプロジェクトで同様の問題に個別で対応するムダが発生している
      • この程度のプロジェクトなら性能担当は要らないね→こういう時に限って性能問題が発生
  • 現在……性能検証担当を共通プールに置き、高スキルの要員を定常的に確保しつつコストを下げる
    • 性能チームの中で積極的に自分の担当したプロジェクトで発生したナレッジを共有している
    • 障害時に一から調べることが徐々に減ってきた

3. 性能問題が発覚するタイミング

4. まとめと成果

  • 2010 年度累計で 10 案件の性能検証を実施・サポート→サービスイン段階での問題発生は 0 件

5. 今後に向けて

  1. 性能解析ツールのさらなるブラッシュアップ
  2. 保守案件への摘要
  3. ナレッジの展開 (スキルの平準化
    • Wiki ベースのナレッジポータル「ナレッジベース」を構築した
    • 障害事例集で問題とその解決策をプロジェクト横断で共有
    • 基礎ナレッジで性能問題に関する基本知識を担保
    • メルマガを発行することで、関係者の意識付けを強化

さらなるコスト効率化、課題解決のスピードアップ

今後はリクルート社内でのナレッジ共有に留まることなく、会社を超えた情報共有も深めていければと考えている。お気軽にご連絡ください!

宣伝

  • 「日経 Linux」2011/11 号から、リクルートのエンジニアによる性能チューニングの取り組みの連載開始
  • 9/26 に Hadoop カンファレンス、残席若干あり


ソーシャル時代のコンピュータサイエンス入門 〜統計的手法と機械学習の重要性〜 (ディー・エヌ・エー 水野 貴明氏)

自己紹介

本日のお題: エンジニアがコンピュータサイエンスを学ぶ意義とは

前提

  • 大学でコンピュータサイエンスを学んできた IT エンジニアは意外と少ない
  • いろいろな業種からエンジニアになっている
  • 自分が就職したのは 1998 年。2000 年問題真っ盛りの頃で、いろいろな方面からこの業界にやって来た
  • 日経キャリアカレッジ
    • 文系は不利?→「文系の強みを生かしましょう」「採用の際は狭き門ですが、業務については文理で有利不利は特にありません」
  • 自分も違う
  • エンジニアをやるのにコンピュータサイエンスを勉強する必要ってある?→なくても大丈夫。でもあるとお得
  • なぜ?→お金になるから。お金は幸せになるために要素の一つ
  • 例えば、ウェブの広告は様々なコンピュータサイエンスの上に立脚した技術で構築されている

本日私が主張したいこと

  • コンピュータサイエンスをこれまで勉強したことがないのなら、ちょっと勉強すると自分の強みを補強できるし、企業にとっても有利

私の経歴

バイドゥでの経験

本日紹介するのは、統計的手法や機械学習

  • 大量のデータを賢く自動的に処理するのに必須
    • スパムメールの処理
    • パーソナライズ
    • 検索
    • レコメンデーションエンジン
    • 広告
  • 例えば、ページの内容に合わせた広告を表示させたい!
    • 単語で検索するだけでは不十分
    • 例: 「偽装派遣」で派遣会社の広告が……
    • 「広告を出すべきではない内容」の判定が必要
      • 政治、宗教など
    • ルールベースでの適用は限界がある
  • ソーシャルネットワーク
    • 人との繋がりという膨大なデータが使えるようになった
    • それらのデータを利用した「味付け」は、人の行動を助ける力になれる可能性がある
      • 例: Twitter や Facebook のタイムラインは膨大だが、見たい情報だけ見る方法はないのか?
  • ウェブには膨大なデータがある
    • ウェブページ
    • Twitter
      • 口語体の短文がウェブに溢れる
      • 言語処理学会では Twitter のセッションが半日もあるほど注目されている
      • 位置情報も含まれているし
    • etc...
  • 宝の山!
  • しかし、人間はそんなに大量のデータをさばけない
  • そこで、統計的手法で一歩先へ

機械学習

  • 人間が自然に行っている学習能力と同様の機能をコンピュータで実現させるための技術・手法のことである。 ある程度の数のサンプルデータ集合を対象に解析を行い、そのデータから有用な規則、ルール、知識表現、判断基準などを抽出する (Wikipedia からの引用)

単純ベイズ分類器

  • ベイズの定理(1763 年、ベイズ発見)に基づいてデータを分類するもの
  • 各素性の条件付き確率の掛け算で、与えられたデータが A であるかどうかを判定する
  • メールを、それぞれの単語が含まれた際の「スパムである確率」の掛け算によって、スパムかどうか判定する
  • ページに広告を貼るべきかどうかを同様に判定する
  • あるユーザーにこれまでの行動から、メールを送るべきか判定する
    • EC サイトの新商品メールなど
  • ある情報に対して特定のユーザーが興味を持つかを判定する

決定木

  • 独立変数から従属変数を決定
  • 例: 天気、気温、湿度、風が強いかという独立変数から、ゴルフをするかどうかという従属変数を決定する

協調フィルタリング

  • 多くのユーザーの嗜好情報を蓄積し、あるユーザーと嗜好の類似した他のユーザーの情報を用いて、自動的に推論を行う方法論
  • 口コミの原理に喩えられることが多い

検索におけるログの利用

  • 最近は Lucene など高性能なフリーの検索エンジンが出てきた
  • でもキーワードが含まれる検索結果を出せばいいというものでもない
  • ランキングの調整、関連検索、クエリ補完、スペラー(例: グーグルの「もしかして」機能)など→ログの統計的分析

まとめ

  • 膨大のデータが存在している現状では、統計的手法や機械学習で一歩先へ進むことができる
  • ビジネスにも結びつくもので、お金にもなる
  • 興味がある人は、『入門 自然言語処理』を読んでください


HTML5 で変わる Web 制作の未来 (バスタイムフィッシュ 村岡 正和氏)

自己紹介

3 年後の Web サイトは今とどう違う?

見た目よりも中身が変わる

  • 画像リソース、Flash が CSS3、Video、Canvas、SVG に置き換わる
    • 会社のロゴはベクターグラフィックの SVG で作ったほうがいい。ロゴデータをウェブサイトからダウンロードすればキレイに印刷でき、イラストレーターのファイルをやりとりする必要がない
  • float レイアウトから CSS3 frexbox、grid、region、multi-column へ
  • マルチデバイスワンソースなサイトの実現 (MediaQueries etc...)
  • 今まで技術的に大変だったことが HTML5 でラクになる

「HTML5 的なデザイン」は登場する?

  • 自分は Yes だと思う
    • 新しいグラフィック系の API の登場によって、新しいメディアが生まれる可能性
    • 例: FItText プラグイン
      • 画面の拡大・縮小に応じて文字サイズも変わる
    • Web Font (村岡氏の作品)
    • Popcorn.js
      • ビデオの内容に応じて関連するウェブサイトや自分で作ったコンテンツを他のペインに表示できる
      • 単位時間当たりの情報密度が濃くなる
      • EC サイトで、商品の説明ビデオに合わせて価格や関連商品を他のペインに表示するなど
      • e-ラーニングなどにも応用できると思う

HTML5 制作の タノシイ シンドイ

楽しいこと

  • 今までできなかったことが手軽にできる
    • Geoloc、AppCache、Video、Canvas...
  • WebApp API が世界標準、安心
    • 一人で商売をやっているので特に強くそう思う
    • Flash はアドビの、Silverlight はマイクロソフトの製品。例えば明日アドビが倒産したとか、CEO の気が変わって Flash のリリースが有償になったら……
    • 一方、HTML5 はフリーで、どの企業にも依存しない技術。どの会社が潰れても、HTML5 は残る
  • ワクワク感、未来への期待
    • 数ヶ月ごとに新しいことが出てくる
    • 商売人の視点では「ちまちまやらずにとっととやれ」と言いたいが、オタク的観点からはこのじれったさがたまらない(会場笑い)

しんどいこと

  • Cross Browser
    • 実装の差、レンダリング結果の差、モバイル……
    • PC で 5 つ、モバイルで 5 つくらいか
    • 「Android ウェブブラウザー問題」と私が呼んでいる問題あり。機種によって動作が異なる。CSS アニメーションが動かない、Canvas が正常に働かないなど
    • 営業の方へ: Android の案件を取る時は、端末を絞らないとエラい目に遭う
    • Firefox や Opera はいいが、Android のウェブブラウザーは端末に依存する。リソースの有無が主要因か
    • 最初に対応機種を限定しておき、それ以外の端末は別料金対応にする
  • なんでもかんでも JavaScript
    • 大規模開発に向かない
    • セキュアプログラミングに気をつける
  • お客さまの説得
    • 「こういうことを HTML5 でやりたい!」「それ、Flash でやったほうがよくね?」
    • でも iPhone 対応を言われると弱い
    • 実話。Chrome で動かすアプリを HTML5 で開発、リリース 3 日前に「それ、HTML5 でやってるから Firefox でも動くよね? あと、キャッシュが効くって聞いたので、オフラインでも使えるようにできますか?」
    • 技術者はもちろん営業も、技術的な要点は押さえておくべき
    • Android は端末によって画面サイズが違うので、見え方が異なる。最初から同意を得ておいたほうがラク

みんな HTML5 を誤解している?

制作現場から見た「HTML5 の誤解」

  • <strong>HTML5 はお手軽に<em>みえる</em></strong>
  • Flash、Silverlight より HTML5 がいいんです!→No
  • Web アプリは全部 HTML5 ですよ!!→ケースに応じた判断が必要
  • スマフォサイトはやっぱり HTML5 だよね!!!→Yes, but...
  • 品質の観点から HTML5 は先駆的、実験的なアプリケーションに限定するのがよいと思う
  • 「iPhone がために HTML5」ではなく、そういうのを Web アプリとして実装すべきかまで考える。ネイティブアプリケーションのほうがいいことも

HTML5 だと安く上がるんだよね?

  • クロスブラウザー対応、技術者の単価が高い
  • html5test.com ですら必ずしも正しい結果を返さない
  • 検証にものすごいコストがかかる
    • で、「やっぱりダメでした」だと大損

HTML5 制作の判断ポイント

  • 判断ポイントは、「Web パワー > Local パワー」かどうか
    • ネイティブアプリケーションでよければ、Web にする意味がない
    • ネイティブアプリケーションでも Web のパワーを使える
    • Web の強みをフルに発揮できるものなら Web アプリケーション
  • HTML5 という言葉にみんなが飽きたら、HTML5 という言葉の流行が収束する可能性がある
  • 数年後に「これ、ローカルでもよかったよね」「HTML5 って何だったんだろうね」というアプリケーションが氾濫すると、Web 業界のビジネスチャンスを逃してしまうことにもなる。これは業界の課題だと思う
  • HTML5 は Web 制作における選択肢のひとつ
  • 皆さんにもぜひ HTML5 を使って、いい情報、悪い情報も共有してほしい
  • そして家電業界に乗り込んでいこう
  • HTML5 の制作を通じて、Web の未来を作っていこう

Windows、Mac、モバイル… クロスプラットフォーム時代のネイティブ開発の勘所 (エンバカデロ・テクノロジーズ 高橋 智宏氏)

Win32/Win64、MacOS X、iOS 向けの GUI アプリのポイント

  • WIn32 と Win64 の切り替えは用意か?
  • 共通の GUI フレームワークを持っているか?
  • Look & Feel は統一できるか?
    • 自前のスタイルを適用できるか?
  • 2D だけでなく、3D 描画も可能か?
    • 設計時のビジュアルなサポートはあるか?
    • アニメーション効果も可能か?
  • データベース接続機能は?
    • RDBMS の違いを吸収するドライバやレイヤは用意されているか?

次世代ビジネスアプリケーションプラットフォーム FireMonkey

WIn32 と Win64 の切り替えは用意か?

GUI コンポーネントや Look & Feel は?

2D、3D のフォームデザイナはあるか?

  • 3D グラフィックのデモ

データベース接続機能は?

  • 3D データベースアプリのデモ
  • 3D グラフィックアプリのデモ
    • デザイン時に光源を変えると、即座に見え方が変わる
    • 3 つのグリッドがあり、[Slide] ボタンでアニメーションして場所が入れ替わるデモ。ボタンのイベントハンドラは 9 行のみ

iOS アプリの開発は用意か?

  • iOS 用アプリケーションのデモ
    • 「ツール」→「Delphi to XCode 変換」で XCode 上のアプリケーションに変換できる

ネイティブドライバ dbExpress によるデータベースアクセス

  • dbExpress が直接対応していない RDBMS であっても、ODBC データソースさえあれば、コードを書き換えることなくあらゆるデータベースに対応
  • LiveData テクノロジーにより、設計時にデータを確認可能
  • 0 行コーディングでデータベースクライアントが完成
  • 基本的に RDBMS に依存しないクライアントコード

DataSnap──HTTP(S)/RESTful/JSON によるサーバー & クライアント通信

  • C++ または Delphi で、クラスのメソッドをクライアントに公開
    • 単一の .exe ファイルで、HTTP サーバー機能も内蔵
  • クライアント用プロキシコードは自動生成!!

PHP で Web アプリをビジュアル開発?

  • RadPHP XE2
  • GUI アプリを開発する要領で、Pure PHP + JavaScript で Web アプリを開発

PhoneGap

  • Objective-C や Java や iOS、Android の API を知らなくても、ネイティブアプリを作成可能
  • HTML、CSS、JavaScript を利用
  • 「ツール」→「Wizard for PhoneGap」を呼び出すだけ


開発者のアイデアを形に 〜Windows Azure に見るクラウド開発環境とは〜 (日本マイクロソフト株式会社 関田 文雄氏)

Windows Azure 発表

  • 2008/10 Azure Service Platform 発表
  • 2010/2 にリリース
  • 機能増強中
    • Marketplace (自分で作った Web サービスを販売できる)が日本からも来月以降利用可能

Windows Azure 開発環境の今

相互運用性──言語共通環境

相互運用性──Java

相互運用性──PHP

相互運用性──Ruby on Rails

デバイス──スマートフォン

  • 何ができる?

革新──LightSwitch

  • 業務アプリケーションを簡単開発
  • ステップ 1: データ定義
  • ステップ 2: 画面を追加
  • ステップ 3: 展開
  • デモ
    • Visual Studio から LightSwitch アプリケーション新規作成
    • データベースのスキーマを定義する画面が現れる
    • 画面テンプレートの選択画面が出るので選ぶ
    • デバッグ実行すると、アプリケーションが動く
    • 「Excel にエクスポート」ボタンを押すと、画面で追加したデータが Excel で開く
    • ソリューションエクスプローラーで開けば、C# のコードが見えるので、書き換えれば独自の挙動をカスタマイズできる
    • ソリューションエクスプローラーから「発行」を実行すると、発行ウィザードが起動
      • デスクトップか Web か
      • Web なら、IIS サーバーなのか Windows Azure なのか
      • Azure を選ぶと、各種パラメーターを入力するだけでデプロイされる

革新──HPC on Azure

開発者のアイデアを形に


復興のために技術者がやって来たこと、これからできること 私にも出来るボランティアのカタチ(sinsai.info 嶋坂 紀隆氏、Hack for Japan 山崎 富美氏)

自己紹介

sinsai.info とは

  • http:/www.sinsai.info/
  • 震災後わずか 4 時間で立ち上がった
  • 「どこで何が起こっているのか」を地図上に可視化する、被災者と支援者のための情報共有サイト
  • ハイチ震災、NZ 震災、リビアクライシスマップでの実績がある Ushahidi を採用、震災後 4 時間という速やかなサービス提供が可能に
  • Twitter、Web 投稿、メール投稿などの情報源から情報を取り入れ、人力で情報を精査した上でレポートとして情報公開
  • 登録情報 12,000 件
  • 200 万PV超、80 万ユーザー超、世界 169 ヶ国からアクセス
  • sinsai.info 上の情報を元に救助活動が行われた事例も
  • 仙台からのアクセスが最多

メディアでの露出

  • Web 媒体
  • 日経 BP
  • 9/4 NHK 総合テレビ「IT ホワイトボックス」

オープンコミュニティ

Android アプリ

関連プロジェクト

  • hack4jp 関連
    • Kizuna レポートプロジェクト
    • 情報再利用推進プロジェクト
  • FaxOCR プロジェクト

sinsai.info の裏側

  • 立ち上げ時は OpenStreetMap Foundation Japan のメンバーが中心
  • その後、Twitter や参加者の知り合いというカタチで参加
  • 助けあいジャパン経由での参加者増加
  • 現時点での総参加者数:

私と sinsai.info の関わり

  • 3/16: Twitter 経由で参加
  • 3/18: 最初のオフラインミーティング
    • この時点でネットワークエンジニアとしての作業はなし?
  • 3/19: CDN 導入検討からインフラ担当へ、後にインフラ班結成へ
  • 3/21: sinsai.info 法務班立ち上げ
  • 現在に至る

sinsai.info での作業内容

インフラ班での作業

  • インフラリソース管理、ドキュメント整備
  • インフラ費用検討
  • インフラ関連調整・打ち合わせ

割といつもやっている仕事内容と同じ

法務班での作業

  • 法務関連書類作成・確認
    • 契約内容などの確認も含む
  • ドキュメント権限管理
  • ユーザ管理
  • ボランティア応募者対応

事務作業いっぱい

いろいろなカタチ

参加しての感想

  • プログラムやデータベースに詳しい技術者でなくてもできることはある
  • 復興はまだまだ続くので、それに合わせて必要とされるものも変わっていく
  • 技術者視点ではない視点も必要

あなたにもできること

  • まだまだ協力者募集
    • sinsai.info でお待ちしています
  • 開発フェーズから維持フェーズへとシフトしているが、sinsai.info はまだまだ続く
  • データ班としての作業もまだまだ必要
  • 我こそはと言う人はぜひ!
  • sinsai.info API もあります→http://tinyrul.com/sinsai-api
  • 連絡はメールや Twitter にて

復興のために技術者がやって来たこと、これからできること (ここから山崎氏)

  • 技術者として何ができるだろう?
  • Google Person Finder
  • 岩手県ミラーサーバー
  • 被災地は紙で情報共有しているので、IT は役に立たないと言われていた→紙を写メに取って Picasa に上げるなどのコラボレーション
  • Hack for Japan「コードでつなぐ。想いと想い」
  • アイディア出しをしたり、オンラインでブレインストーミングしたり
  • プロジェクトの可視化

Hack for Japan のサイクル

  • 「アイデア立案→開発→リリース・PR」という流れをサポート
  • 震災復興支援アプリが数多く生み出される土壌を育むコミュニティへ

3/19〜21 hackathon #1

  • 京都・福岡・岡山・徳島
  • 余震を考慮して西日本で開催
  • 「継続すること。風化させないこと。」→少なくとも 1 年間続けよう
  • 5/21・22 hackathon #2
  • 7/23・24・30 hackathon #3
  • 「被災地と共に。」
  • 4/24 Hack For Fukushima (@会津)
    • 福島第一原発から避難してきた人がいた
    • 郡山・福島からも
    • 「正しい数値を知りたい」「自分の目で確かめたい」
    • 当初、政府は「20km 以内は避難してください。30km 以内は警戒区域」と言っていたが、その数字は信頼できる?
    • 実際には風の状態で変わる
    • 「風@福島原発」 (iPhone、Android)
      • 「風@福島原発を見てから外出しています」というユーザーの声
      • 開発者が展示ブースにいます
      • 「なるべく早くこのアプリが安易ストールされる日が来るのを願っている」(開発者)
  • ガイガーカウンターも、なければ作ろう→会津工業高校の学生が手作りのガイガーカウンターを作成
  • AR ガイガーカウンター (展示ブースにて! 福島の土もあります)

7/23・24 遠野 Hackathon

  • 遠野まごころネット
  • 海岸から少し離れた所を拠点にして活動
  • ご家族を亡くされた方、ボランティアで 2 ヶ月滞在されている方など、いろいろな境遇の人が

Ideathon

  • ホワイトボードが埋め尽くされるほどの要望
  • IT を使って解決してほしいことはたくさんある。遠い所でも貢献できることはある

仮説ネットカフェプロジェクト

  • 仮設住宅にはラウンジもネットもない
  • 体育館にいた頃は、iPad をみんなで見るなどの情報共有、コミュニティがあったが、仮設住宅に入るとそれらが分断された
  • 集まる場所を作って、ネットで発信・情報収集

Photrack.jp

  • 被災地、特に沿岸部は、火事で全部燃えてしまった
  • 思い出や形見がなくなってしまった
  • 写真が見つかったら、きれいにして持ち主や遺族に届ける
  • 汚れた写真の洗浄・スキャン
  • 「フォトサルベージの輪」などのプロジェクトも

復興まではまだまだかかる

  • 垣根を越える
  • 復旧から、復興へ
  • 被災地と共に。役立つ物を
  • 皆さんのスキルを生かしてください
  • 「IT で何か役に立てることはありますか?」と聞くと、「ない」と言われる
  • 「困っていることは何ですか?」と聞けば、いろいろ出てくる
  • IT でできることはまだまだたくさんある
  • 東京で当たり前のことも、現地では当たり前ではない
  • 例: 被災証明を出そうにも、原発付近は立ち入ることができない→東京でグーグルアースの画面をプリントアウトして持って行く
  • while (Japan.recovering) { we.hack(); }
  • http://www.hack4.jp/

質疑応答

「コミュニティで参加している人が減ってきている」という話があったが、ご自身がずっと残られている理由というか、考えというか、そういったものは。
母方の田舎が盛岡で、近い親戚には被害はなかったが、親戚の家族に陸前高田の人がいて亡くなっている。そういう意味で、自分の生活に身近な震災だったので、自分のできる範囲でやっていきたいと思って今でも続けている(嶋坂氏)
Hack for Japan に関しては、新陳代謝が起こっている。このような講演で活動を知り、入ってくる人もいる。人数は増えているか、同じくらい。人集めに一番苦労したのは最初の時だと思う。遠野はエンジニアがたくさんいる場所ではなかったので、人を集めるのが大変だった。新しい荘を発掘していくのも大切か。当初のコミュニケーションは ML だったが、人数が増えると喋りづらいので、Twitter や Facebook も取り入れた。ツールも変わってゆき、人も入ってくる。自分については、行って沿岸部の状態を見てしまうと、何かしなくてはという気持ちになる。(山崎氏)
私はボランティアに行ったが、ボランティアの作業はすべて紙で管理していて、管理が大変そうだった。あと、現地に車で行ってくださいと言われるが、地図が適当で移動に時間が掛かった。作業の継続性に難があった。こういう点についてもこの活動は役に立つのかと思った
状況が刻々と変わるので、マニュアルを作っても役に立たないこともあった。阪神淡路大震災の時のマニュアルはどうなったのかと思ったが、東北の人には届かなかった。今、次に使えるマニュアルを作成している。(山崎氏)
FaxOCR というのもやっている。文字を取り込んで DB に入れるという活動。インフルエンザのパンデミックが起きた時、ワクチンがどこにいくつあるかを整理するために始めた。(嶋坂氏)
自治体やライフラインの会社から出てくる情報が扱いづらかったが、「こういう形で欲しい」という要望は。
まさにそのもののプロジェクトを Hack for Japan でやっている「情報再利用推進」。中の人がとある経済産業省のメンバーで、情報の再利用をしやすい形式(CSV、JSON)で提供してもらうか、コンバーターを用意して統一的なデータを提供してもらう仕組みを作っている。台風 12 号の尼崎市の避難勧告が Word 形式だったという笑えない話もあるので、本気で取り組んでいきたい。(嶋坂氏)