防災
ITDART
IT DARTDay 23

エンジニアのみんな、防災やろうぜ! - エンジニアが防災に関わるべき10の理由

More than 3 years have passed since last update.


序章

みなさん、はじめまして。Fujita Shuと申します。

Qiitaは見るばかりで記事を投稿したことはありませんでしたが、この度、ひょんなご縁からこのアドベントカレンダーに参加させて頂くことになりました。よろしくお願いします。


簡単な自己紹介

仕事ではRuby on Railsを使ったWeb制作、移動中の電車内でもプログラミング、趣味(個人的研究)では東京メトロのオープンデータを扱うRubyのGem1を開発しているという、いろいろな意味でRuby on Railsな人間です。

田舎は岩手の海沿い。サンマは買うものではなく貰うものだと思っています。

震災以後、社会工学の観点から防災に関わろうと、防災系ITエンジニアを目指して修行中です。

現在東京在住、来年から愛知県と岩手県の2拠点で活動する予定です。


TL;DR

「死傷者を減らす」「経済的な被害を抑える」「社会的な混乱を防ぐ」といった防災の根本的な目標を達成するためには、現状の社会全体の防災意識や防災に関する情報提供のプラットフォームは不十分です。

この現状を打開するためにはエンジニアの技術力と思考力、WebマーケティングやUI,UX設計の技法が必要です。

また、優秀な先人が生み出したソフトウェア工学の手法もヒントになる可能性があります。


結論


  • エンジニアは防災に向いている、だからみんな一緒にやろうぜ!

技術的というより、思想的な話が中心になります。


1. 防災をぶっ壊す!

(2016/01/02:加筆修正)

防災の新しいアーキテクチャ、新しいフレームワークを作ろう


結論

エンジニアは、生産性を高めるための物事のアーキテクチャ、フレームワークに慣れ親しんでおり、試行錯誤を繰り返しながら更に洗練されたものや自分の必要性に応じたものを作ってしまう能力と情熱も持ち合わせている人です。

そういう人が、いまの防災に必要です。


なにをやるのか

新しい防災の形を作り、「よりよい防災」や「よりよい社会」を実現する、っていうことです。


なぜやるのか

いまの防災の制度やその背景にある思想は欠陥を抱えていて、それを発展的に解消させないと、今までと同じような悲劇が別の場所で繰り返されてしまうからです。


なんでそう思ったか

MVC とそれに類似する概念、欠点を補うために登場した新しい概念などを見ていたら、


  • 'Model', 'View', 'Controller'

  • 自助 」「 共助 」「 公助 」(防災の用語)

が似ているんじゃないか?と思ったからです。(この記事は、そんなふとした気付きから始まった考察のまとめです。まとまっていないような気もしますが… 汗)


MVC

エンジニアの皆さん、特にWebアプリケーション開発者にはおなじみの MVC という言葉。アプリケーションの機能を Model, View, Controller の3つに分割して、それぞれの責務を明確にしておくと、ソフトウェア開発の生産性や保守性が上がるよね、という話は入門書やQiitaの記事など至るところで目にしますよね。


特に、大規模なアプリケーションになればなるほど、「責務の明確化」は重要です。私もRailsを始めたばかりの頃は機能を詰め込み過ぎたFat Controllerを作ってしまったり、Modelに書くべき処理をViewに書いたりと、いろいろやらかしたものです。そのときのコードは見るだけで恥ずかしくなりますし、そのまま辛うじて動き続けているアプリケーションをリファクタリングしたり機能拡張したりするのも大変です。


3つに分けてみる

ところで、物事を「3つの機能に分ける」という例は、MVCに限らず、世の中のいろいろなところで見ることができます。

例えば、中学や高校の社会科の教科書には「立法」「行政」「司法」の 三権分立 が出てきますし、どこぞのアイドルグループではメンバーを Aチーム、 Kチーム、 Bチームの3つに分けてそれぞれの特色を出す(そしてファン心理を掴む)ということが行われています。 ダチョウ倶楽部ネプチューン もまた然りでしょうか。

どうやら、「3つに分けてみる」というのは役割分担の典型的な方法のようです。

ちょっと脱線気味になりましたが、本題に入ります。


自助、共助、公助 - 防災の「アーキテクチャ」

防災の話をしていると、頻繁に「 自助 」「 共助 」「 公助 」という3つの言葉がセットで登場します2

自助・共助・公助

ご存知ない方向けに説明すると、この3つの言葉は、



  • 自助 - 個人、家庭レベルの災害対策


  • 共助 - コミュニティレベルの災害対策


  • 公助 - 市区町村・国レベルの災害対策

という意味で、具体的には



  • 自助(規模 小)


    • 災害発生前 - 家具の固定、防災グッズの用意

    • 災害発生時 - 頭を覆う、火を消す




  • 共助(規模 中)


    • 災害発生前 - 自治会の防災訓練

    • 災害発生後 - 隣近所での救助・支援




  • 公助(規模 大)


    • 災害発生前 - 防災を推進するための施設や制度の整備など

    • 災害発生後 - 警察・消防・自衛隊などによる人命救助・応急的な復旧活動、復興に必要な制度構築、財政支援



などが当てはまります。

そして、3つの言葉の背景には、

災害って、社会全体に影響があることだから、

みんなそれぞれの役割を明確にして、やるべきことをちゃんとやろうよ

という考え方があります。

お、MVCの思想

アプリケーションの機能を Model, View, Controller の3つに分割して、

それぞれの責務を明確にしておくと、ソフトウェア開発の生産性や保守性が上がる

に似ていますね。


3つに分けてはみたけれど - MVCという幻想

話は再び、MVCに戻ります。ここで勘のいいエンジニア、経験豊富なエンジニアの皆さんはお気づきでしょう。

MVCって、気付いたらViewやControllerが肥大化して保守性悪くなったりするよね。

PresenterとかDecoratorって言われる、ModelとViewを繋ぐ概念もあるよね。

ややこしい処理はServiceクラスとかに切り分ける手もあるよね。

MVCじゃなくて、MVVMっていうのもあるよ。


エンジニアE(Knockout.jsユーザー)

MVCじゃなくて、MVVMっていうのもあるよ。


GemはDraperかActiveDecoratorが便利だよ。

ちなみに俺はDraper派。
あとValidatorクラスとかCallbackクラスも上手に使いたいね。
例外処理も、StandardErrorを継承してうまいことやりたいよね。

MVVM? 何それ。VVVFとかPMSMじゃなくて?

(最後は私です。失礼しました…)

それはさておき、


  • 「MVCは基本・定番だけどすべてではない」

  • 「基本的な作法に従ったつもりでアプリケーション開発をしていても、注意しないと汚いコードの山が出来上がる」

  • 「気をつけていないと適切でない箇所に処理を加えてしまう」

という点は皆さん経験的にご納得頂けるかと思います。

Qiitaの記事を検索してみても、


「ビジネスロジックはModelに置くべき」と言うが、開発者によって理解や意見がバラバラで統一的な実装ができない

引用元:まだMVC,MVP,MVVMで消耗してるの? iOS Clean Architectureについて

(iOS開発がテーマの記事ですが、開発現場で一般的に生じる問題であろうと考え引用しました)


とか、


このモデルは現在に至るまで長いこと支持されている。もしかしたら金科玉条のように宗教的な信仰を受けているといっても言い過ぎじゃないかもしれない。

引用元:MVCの流れを簡単にまとめてみる


という指摘があるほか、

など、MVC以外のアーキテクチャに関する解説も見られます。


補足1

も参考になるでしょう。


補足2

Webアプリケーション開発者から見た、MVCとMVP、そしてMVVMの違いとその参照先のサバクラ両方で動く JavaScript の大規模開発を行うために - GitHubにあるように、Railsにおける「MVC」は本来のMVCの派生型であるMVC2というアーキテクチャに近いようです。

同様に、MVCというワードが意味するところは文脈に応じて変わる場合があると思われます。

本記事では、MVCの厳密な定義や構造を特に気にせず、「Model, View, Controllerを分割するデザインパターン」程度の意味で使っていますので、本文中に曖昧な箇所があってもご容赦頂きたいと思います。

もっとも、私の理解が足りないせいで文章中に不正確な表現があるかもしれませんので、その点はご指摘頂ければ幸いです。


ということは…

さあ、ここまで来たら、皆さんの中には、次のような疑念が生じているのではないかと思われます。

MVCこと「ソフトウェア・アーキテクチャの3分割構造」と同様に、

「自助」「共助」「公助」の「防災アーキテクチャの3分割構造」も必ずしも万能ではないんじゃないの?

というか、実は大きな落とし穴があったり、みんなが誤解していたりしない?
もうちょっと懐疑的に考えながら、もっといいものを作ったほうがよくない?


発展的にぶっ壊せ!

「自助」「共助」「公助」は死んでいる!


自助・共助・公助の落とし穴

自助・共助・公助

世の中の災害対策が「自助」「共助」「公助」を念頭に行われている以上、上のような疑念をもつ私は考え過ぎなのかもしれません。

そして、そもそも「自助」「共助」「公助」を真っ向から否定するつもりはありません。

自分の身は自分の身で守るのは当然ですし、共助の力によって災害発生直後からその後数年を耐え抜いた人々も数多くいます。大災害への対策や復興は、公助なくしてはとても実現できません。

実際、岩手県沿岸部での東日本大震災の例をみると、



  • 自助 - 各地(釜石市鵜住居地区が有名4) - 「津波てんでんこ」の精神(「いざというときは、自分の安全だけ考えてとにかく逃げろ」という考え方。これを徹底しながらも助け合いながら避難したことで、被害の軽減に大きな効果があったとされる)


  • 共助 - 各地 - 避難所生活での助け合い5


  • 公助 - 各地(特に普代村) - 防潮堤の整備(普代村は家屋の浸水被害ゼロを達成。釜石港や宮古市田老のように津波によって破壊されたものも、人的被害の軽減に一定の効果があったことが示されている)

という形で、「自助」「共助」「公助」が成果をあげていますし、



  • 公助 による 共助 のデザイン - 宮古市 - 仮設住宅入居の際の制度設計(同じ地域の人は同じ場所の仮設住宅に入れるように市が配慮した。その結果、震災後のコミュニティ衰退が抑えられ、被災者の心理的負担も軽減された)


  • 自助共助 による 公助 のバックアップ - 各地(特に大槌町) - 行政職員が犠牲になったり公用車が流されたりした状況で、避難所の運営や救援物資の提供を住民が行なった。

という事例があるように、それぞれの責務を完全に分離するのではなく(MVCがそうであるように、そもそも分離できない)、相互補完的で、かつ他に依存し過ぎない制度設計や文化の構築が必要です。


でも、自助・共助・公助は万能ではない

一方、「自助」「共助」「公助」の限界と現実として、次のようなものが知られています。


  • 「自助」をやるべき個人・家庭が、自助を疎かにした結果、被害に遭い、そのしわ寄せが行政に行く(例:各家庭の自助がしっかりしていれば公の防災対策や災害後の支援、財政負担を削減できる)

  • 「自助」をやるべき個人が、公からの情報を信じ込んだために想定外の災害で被害を受けてしまう(例:<陸前高田・津波訴訟>気象庁予報の責任主張 津波の高さが、気象庁した予測を上回った→訴訟に)

  • 東京のような大都市圏ではコミュニティの力が弱い(隣の人の顔や名前を知らなかったりする)ので、「共助」の力が弱い

  • 逆に、コミュニティの力が強い地域では、逃げ遅れた人を助けようとして自分も犠牲になってしまうという惨事が起こりうる(実際に東日本大震災のとき各地で起きた)

ね、「自助」「共助」「公助」って問題あるでしょう?


追記 (2016/01/07)

実は法的には「自助」「共助」の根拠や役割、責任は不明確なのだそうです。(参考

うーん、ヤバいぞ。

「自助」「共助」「公助」それぞれが大切なのは当然ですが、(概してわかりづらい)公的機関のWebサイトや文書で堂々と紹介されているのに、人の命に関わることのに不明確というのはいただけませんね。様々な利害関係者の立場を総合して明確化するのは大変な作業ですが、議論を整理するなら整理して欲しいところです。

個人的には、「自助」「共助」「公助」という言葉は「語呂がよくて、単純なモデルでわかりやすいから」というだけの理由で盲目的に使われているに過ぎず、上位互換の概念を作ってしまった方が防災の根本的な目的が達成しやすくなる(ので作りたい)と思っています。


じゃあ、どうするの?

結論から言うと、民間の力を使うことで個人の「自助」の力を強くすることが必要です。

もう少し具体的に言うと、一般の事業者がその従業員に対して、公共性や生活密着度の強い事業者(交通、電気、ガスや大手小売)がその利用者に対して自助の強化を促す仕組みが必要です。


現状認識

…と言われてもピンと来ないでしょうから、さらに掘り下げて説明していきます。

世の中の仕組みを分析するためには、まず「どんな人がいて、どんな組織があるのか」を整理する必要があるでしょう。

そこで、皆さんおなじみのリレーショナル・データベースの構造図をヒントにモデル化を試みました。まずはこちらをご覧ください。

人間関係が豊かな社会構造

三陸海岸の集落にあるような、昔ながらの「家庭」や「コミュニティ」(赤枠で囲った部分。従来モデルの「自助」「共助」で力を発揮する)が機能している例です。ところが、都市部(例:東京)では、

人間関係が希薄な社会構造(極端な例)

赤枠で囲った部分の力が弱いのです。

すなわち、「自助」「共助」「公助」の前提がそもそも崩れているんですよね。

岩手の海沿いと東京を両方知っている立場からすると、同じ仕組で防災をやろうとする必然性はまったくないと思うのです。

現状、都市部でコミュニティを強化して共助の底上げを図ろうとする活動もあります。うまくいけばいいですが、災害はコミュニティに参加しない人のところにも等しくやってきます。っていうか、面倒くさいコミュニティの人間関係に気を遣わなくて済むのが都会のいいところですからねぇ(正直、私も東京に住んでいてそう思います 笑)。

こうなれば、別のやり方で防災力を高めることを考える方が建設的です。

ね、新しい防災アーキテクチャが必要でしょう?


いいものは取り入れて、次を作ろう


2. 防災はもっとアジャイルに


3. DDD (Disaster Driven Development)


4. TDD (Tohoku Driven Development)


5. BDD (Bosai Driven Development)


6. 防災とWebマーケティング


7. 防災の心理学とUI・UX設計


8. Disaster3.js


9. 社会のデザインパターンとアンチパターン


10. 災害、AI、フィルターバブル - 不都合かつ必要な情報との付き合い方


お詫び

2 - 10を要約すると、


「死傷者を減らす」「経済的な被害を抑える」「社会的な混乱を防ぐ」といった防災の根本的な目標を達成するためには、現状の社会全体の防災意識や防災に関する情報提供のプラットフォームは不十分です。

この現状を打開するためにはエンジニアの技術力と思考力、WebマーケティングやUI,UX設計の技法が必要です。

また、優秀な先人が生み出したソフトウェア工学の手法もヒントになる可能性があります。


(大事なことなので二度言いました)

ということになりますが、全然筆が進まなかったので、1の終わりの部分の加筆修正も含め、年末年始に書きます。(ごめんなさい and 乞うご期待!)


おわりに


震災からのプログラマー

実は、私がプログラマーになったきっかけは、あの東日本大震災でした。自分は東京の下町育ちですが、ルーツは岩手県の沿岸部、本州最東端の宮古市。見知った海と町の変わり果てた様子に愕然とし、「これからの日本はどうなってしまうのだ」という言い知れぬ不安に襲われました。

その後、何もできない無力感に打ちのめされて1年近く気の抜けた状態に陥っていた私は、論理的思考と高い技術力と情熱を兼ね備えたエンジニアたちが情報発信のプラットフォームを次々と立ち上げ、救援活動にも貢献していたということを知りました。

ああ、この人たちみたいになりたいな…

そう思って、ちょっとずつ、HTMLをいじり、CSSをいじり、Rubyで簡単なファイルや文字列の処理にチャレンジ…と階段を登ってきました。

「オブジェクト指向とか理解できねーよ」と言いながら理解し、RailsとJavaScriptで面白い表現ができると知り、オープンソースの思想に触れてからは、こんなに面白いものはないぞと、狂ったように勉強し、気付いたらバリバリのRubyistになり、仕事にするようになっていました。


まとめ


「死傷者を減らす」「経済的な被害を抑える」「社会的な混乱を防ぐ」といった防災の根本的な目標を達成するためには、現状の社会全体の防災意識や防災に関する情報提供のプラットフォームは不十分です。

この現状を打開するためにはエンジニアの技術力と思考力、WebマーケティングやUI,UX設計の技法が必要です。

また、優秀な先人が生み出したソフトウェア工学の手法もヒントになる可能性があります。

(大事なことなので三度言いました)


…という考えを具現化するために独立をします。(ちょいと宣伝 and 決意表明)


お知らせ

2016年2月11日から3月11日までの30日間、「3.11 アドベントカレンダー」やります。


決まっていること


  • テーマの縛りはなし。防災や災害に少しでも関連することならなんでもOK。

  • 東日本大震災、地震・津波に限らず、火山の話題もOK。


  • 例:


    • 南海トラフ巨大地震の予測と統計学

    • GWにおすすめ 三陸海岸イベント情報

    • 【実際にやってみた】いざというときの救急救命法

    • 牡蠣を使ったレシピ

    • 岩手の地酒

    • 一度は行ってみたい日本の温泉ベスト30



  • 参加自由。誰でも書ける。


  • 私が年明けから爆速でRuby on Railsで開発する。(DB設計のメモ以外、まだ何もやっていないw)



お願い


  • 執筆にご協力して頂ける方、執筆して頂ける方を紹介してくれる方、開発への参加・助言を頂ける方、その他ご興味がある方は、お気軽にご連絡ください。宜しくお願いいたします。

  • 私のFacebookはこちら

元々、アドベントカレンダーとはキリスト教圏でクリスマス前に使われるカレンダーで6、そこから派生してプログラマーたちのイベントが生まれたそうですが、「3.11 アドベントカレンダー」は「建国記念の日から東日本大震災が発生した日まで、テーマは(基本的に)防災」という日本的なコンテンツを目指したいと思っています。

また、Qiitaのアドベントカレンダーと同様、わかりやすく有益な情報が集まるプラットフォームを作ることで、「東日本大震災の教訓を伝える」「復興の現状を正しく発信する」「東北地方の面白さを伝えて足を運んでもらう」「未来の災害に向けた課題を整理し、防災を推進する」等々を実現し、防災文化の発展と被災地の復興、将来の減災に貢献したいと思っています。(どこまでいけるかな?)


謝辞

最後になりましたが、突然のお願いにも関わらず参加をお許しいただいた@takorattaさん、ありがとうございました。

この記事をきっかけに、ITの知識を防災に役立ててみようとする方、防災への興味からITを勉強してみようという方が増えてくれれば幸いです。





  1. これを開発しながらRuby(とRails)を独学で習得しました。最近忙しくて(という理由をつけて)放置気味な上、独学中に書いた汚く無駄の多いコードが散乱していて恥ずかしいので、GitHubを漁ったりgit cloneしたりするのはやめて下さい…^^; 



  2. 「自」「共」「公」と略すと政党一覧みたいになってちょっと嫌なので、略さずしつこく「自助」「共助」「公助」と書くことにします 



  3. もとはLightning Talk用のスライドだったようで、作成者ご本人が「荒削りですしネタ的要素も多分に含んでいます。」とコメントされていますが、私自身はこのスライドで「間違っている」とされているものをMVCと思い込んでいた上に、実際にやっている(and やってきた)ことは「これが本当のMVC」とされているものにほかならないということを知りました。そして、そこから「そもそもMVCって何だ?」と考えるようになりました。 



  4. マスコミでは「釜石の奇跡」と言われることがありますね。この記事では、地元の人々の「今まで訓練してきたんだし、このくらいできて当然だ」「当たり前のことをやっただけ」という意見を尊重し、そのような言い方はしないことにします。 



  5. 宮古市における被災者住宅確保等の取り組みでは、「避難所生活でのプライバシーの保護に配慮し間仕切りを用意したが、あまり需要がなかった」という話も紹介されています。 



  6. キリスト教の本家アドベントカレンダーのことは知ったのは、独学でプログラミングを始め、調べ物をしているときにQiitaのアドベントカレンダーに出会ってからでした…