災害復興についてプログラマとして考えたこと-2

突然ですが、ボランティアといったらどんなイメージですか?

人それぞれイメージを持っていると思うのですが「100%の善意でなければ許されない」というような雰囲気、あるいは空気を感じることってありません?

僕はあるんです。

そこらへんの日本人的清潔主義、潔癖主義、不良品0% 主義が負の影響を与えてるな、って思うことがよくあります。
ボランティアといえば無償、無私、というイメージが強すぎて、私欲を目的に参加することがやましく感じてしまう人も多いんじゃないかと思うんです。少なくても僕はそうです。

僕がその手のプロジェクトに参加するとしたら、主にスキルアップ目的でしょう。私欲バリバリです。これがちょっとやましい。
でも、言い訳がましいですが、無理なくうまく労力をボランティアに取り込むには、私欲をうまいこと抱え込むこと、あるいは刺激、利用することが重要なんじゃないかと思うんです。

たとえば、僕の個人的な興味範囲は、アジャイルだとか、XP、Scrum、RUP (古 !!) のような開発プロセスやDomain-Driven Design、UML、MDA (古 !!) とかオブジェクト指向関係のモデリング技術とかです。オブジェクト指向関連の諸技術ですね。
実装系ももちろん好きです。いまならGAEとかスマホ系とか面白そうですよね。
ここらへんをうまく刺激してくれるようなプロジェクトだと、僕なんかは飛びついてしまいます。

SIer に近いところで仕事している人間なら、この周辺技術には多少なりとも興味があるのではないでしょうか?　SIerの中の人、あるいは近い人達も大部分の人たちは、様々な事情により思うようにアジャイル化できなかったり、モデリング技術を活かせなかったりして不満を抱えているように見受けられます。

僕もかつてはそんなところにいましたが、最近は一人または少人数のプログラミングばかりです。好きにデザイン、実装をできるので満足ではあるのですが、プロマネ系の経験を得ることがなくなったので、それはそれでどうなのか、と感じているのが現状です。

そんな状況のなか、大震災が起き対応の不手際、情報のやり取りのおそさを見るにつけ、一プログラマとしては「ちゃんとシステム化しておけ」とイライラする気持ちを抑えきれませんでした。

そんな風に災害復興とか災害対策とかの対象領域を考えていると、エンタープライズな感じや、モデリングしがいがあり、小さかったら必要無さそうなレイヤー化とか、書籍では勉強したことあるけど全然使う機会がなくて忘れてしまう系の知識を応用できそうな結構な大きさの領域であることに気が付きます。

勉強したけど適用場所を見つけられずに悶々としているような人は、適当な大きさの問題領域をみると、モデリングしたらどう、とかXPで計画を立てたらどう、とか考えたりするとおもうんです。少なくても僕はそうです。

しかし、モデリングしたとしてもこのモデルは正しいのか?　他によりよいモデリングがあるんじゃないか、といろいろ考えるのですが、まわりにOOな人が皆無なので検証する方法がなく、その為途中でやめてしまうことがほとんどでした。

ですから、要求定義から始めて、計画、モデリング、コーディングまでをこなすようなOO (オブジェクト指向) でのベストプラクティスプロセスをベースにした実践的な勉強会やセミナーがあったらぜひ参加したい、と常々思っているのですが、そんな長く行う勉強会はないだろうし、セミナーはあるだろうけど企業向けだろうから一般人が参加できる値段ではない場合がほとんどでしょう。もっとも知らないだけかもしれませんが。

その為、学習はもっぱら書籍になるのですが、ここらへんのエンタープライズ系やプロマネ系を扱う書籍類は基本抽象論なので全然頭に入ってこないんです。
俺がアホだということだけが原因ではないはず。ないよね?

　　ないと言って下さーーい　　　　ｳﾜｧｧ-----｡ﾟ(ﾟ´Д｀ﾟ)ﾟ｡-----ﾝ!!!!

アナリシスパターンとか全然わかりません。何度か確認しました。

　　「この本は日本語で書かれているはずだ」ってw

日本語で書かれているはずなのに、さっぱり意味が取れない。アナリシスパターンは割と特殊ですが、その他エンプラ系を扱う書籍やモデリング系も基本分かりにくいです。
具象論で論理展開してくれるともっとわかりやすくなるんだろうな、と思うのですがそこら辺は多分守秘義務とかでむずかしいんだろうし、基本的に成功例しか出せないだろうし。
また出せたとしても自分の問題領域をと違う業界の事例を出されたりすると、それはそれで…という困ったちゃんだったりします。

しかし、災害復興とか災害対策が問題領域なら、日本全国どこでも大地震が起こる可能性があるわけですから災害対策の仕組みを知っておいても損はないし、この一ヶ月TVとかを通じて共通体験や問題を共有していますから、要求が想像しやすいのでモデル化も手を付けやすい。

この問題領域を、あの人がモデリングしたらどうなるのだろう…　とか、
XPをベースにしてあの人が回すとしたら、どんな計画をたてるのだろう…
要求定義　プロジェクト・ファシリテーションをあの人がやったら…
DDDで分析した場合どうなる…　

Javaで実装をしたら…
Railsとか　…

　　あっそうだ。いまさらCOBOLでw
　　いやまて、ここはちょっとおしゃれに Object COBOL でどうだ !!

などなど…

そして、その過程を記録し、整理することでエンプラ系のアプリを作る上で具象論から抽象論を説明するような分かりやすい書籍を作ったり、ハンズオン型の書籍を作ったり、その本の売上を寄付したり…

などと考えていくといろいろ広げやすそうな感じがしてきます。そんなことつらつら考えていた時に、岩切さんのLTを聞き、Project　Ichigan　を立ち上げたとのことだったので、メンバーをみたら、OO系の有名な人がいっぱい集まっているではないですか、と。

Project　Ichigan　をググルと　一眼レフ系のサイトばっかりひっかかてくるのはご愛嬌としてw、それらしきページには近日の予定はないとなっているので、多分立ち上げたばかりなので企画を煮詰めている最中なのでしょう。

それならば、これら考えを企画としてまとめれば、岩切さんのこれからの活動において何かしらのヒントになるかもしれない、と思い5日位かけて企画をまとめてからtwitterとかで「こんな企画どうでしょうか?」と投げかけるつもりで書き始めました。

ただ、だれもこんな弱小ブログにこないだろう、と思っていたので何も考えず製作途中のものを公開していたんですが、今見たらコメントが付いているので結構ビビっています。
コメントをくださった方ありがとうございます。いまは企画に関する記事のまとめでいっぱいいっぱいなので、もうちょっと企画に関する記事を書いてからコメント返信させて下さい。

ということで、長くなったので企画の詳細は明日に続きます。