先日、id:wkzkさんと共謀した第0回BPMオフ会が無事終了しました。人生初めてのOFF会でしたが、「ちょｗｗｗ みんなキャラ立ちすぎｗｗｗｗ」って感じですげー楽しかった。皆様、御忙しいところご参加ありがとうございました。wkzkさん、幹事役ありがとうございました。次回は私めが頑張りますｗ
みなさん色々な思いがおありの上でご参加頂いており、今後は空手では参加できねぇなと猛省した次第です。そんな中、2次会でid:habuakihiroさんがお話してくれたことが勉強になったので、メモっておきます。記憶を呼び覚まして書いているため、微妙に細部が違うかも。
スイムレーンは悪
何が悪かと言えば、組織ありきでフローを記述しなければならないというのが悪だと。AS-ISの可視化には有益だろうが、ではToBeを設計するにあたってどうして組織ありきのフローにならねばならないのだ、と。本来必要のない仕事が、役職というフィルターを通すとあたかもそれが意味があるかのように見えてしまったりするのだ、と。
そういえば弊社で業務可視化をやっているけれど、スイムレーンってほとんど見たことが無いな・・・。
汚いものを汚く見せるのは死ぬほど難しい
羽生さんと言えば、マジカなのですが、マジカで書かれたカードをご覧になったお客さんが「自社の業務プロセスが例外系だらけで終わっている・・・」というのを視覚的に気づけるというのが大きい、というお話。
これはホントに大きい。ツールで可視化した業務プロセスの「どこがまずいのか」というのは人間依存。カバレッジの応用で「ここのフロー分岐大杉」とかはできるかもしれないけど、Visioなどのツールではそれを書き表すことが出来ないわけで・・・ 。汚いものを取り繕うのはお化粧すればいくらでも出来ちゃうけど、汚いものをそのまま汚く見せるってホントに難しい。クラス図やシーケンス図やER図やその他もろもろ・・・、を見て一発で「むっはー、これヤバいｗｗｗ」って言える人なんてよっぽどのプロだもんなぁ。
カチャカチャ感
S2が受け入れたられたのは、レゴのようなカチャカチャ感があったからではないか、という話。
これだけだと何のことかさっぱり分からないんだけど、インスタンス(クラスか？)レベルでひとつのソフトウェアを作っていける、自分自身でUnitを１つ１つ組み合わせることが出来る感覚がウケたのではないか、という話だった。この発想は無かった。
これを展開すると、SOAで言っている所謂サービスというのは、「カチャカチャ」するには粒度が荒いだろうと思う。DIコンテナはクラスという単一Unitだけど、SOAで言うサービスはa unit of work、複数のUnitを１つにまとめたものになる。この感覚の違い、なんつーかもう国民感情みたいなものが、どこまでSOAの普及に影響あるのだろうか。effectなのかaffectなのか。
まぁ個人的にはDIが好きなんだけど、new書かなくて良くなって複雑な多段構造のJ2EEWebアプリがPOJOベースでどんどんできるよーん、ってのが好き。JavaはPOJOから逸脱すると死ぬほどめんどくさくなるにも書いたけど、Javaってミドルウェア介すような仕組みになるとサーブレットとかJDBCとかうっとおしいんだよねｗ
関数をつなげたいんだよ！
一番のハッカーはExcelの関数をチェーンのようにつなげられるOLではないか、という話。でも時々Excelのシートに超長い関数をぶちこんでる神がいる。LOOKUPしたのをROUNDしつつCOUNTIFぶっこいてループまわして集計みたいな。Excelhack！って本書いてくださいとか思うぐらいのｗ
本来やりたいことがいくつもあって、それが関数という形で提供されていて、それをカチャカチャやって開発するっていう形こそ、自然なソフトウェア開発なんじゃないか、と。Javaが悪いとは言わないけれど、静的言語はクラスありきのプログラミングスタイルになるから、関数カチャカチャのプログラミングスタイルとは結婚できん。後者のHack感ってやっぱり重要なんだろうなぁ、こればっかりはオレ自身がRubyやってみないとわかんないだろうなぁ・・・。
ってことで、ちょっとRubyをぐぐってみたら、Rubyのチュートリアルの記事を発見した。ここにあるサンプルソースがJavaと全然空気が違うんでビックリした。
puts 1+2
なんかJavaとは流れている空気が違う。System.out.println(1+2)とは違う。
某大手外資系ソフトベンダーにお勤めのM氏曰く、なんかの調査で「ﾓﾏｴﾗが使ってるプログラミング言語は？」的な調査資料で、JavaやC#って7位前後で1位〜6位まで全部動的言語だったそうです。まずプロセスありき、表現したいことありき。LLに興味わいて来た。
熱き血が流れる30代
ここからは某大手外資系ソフトベンダーにお勤めのM氏のお話。技術講師的なお仕事をされておられる方です。
端的に覚えているのは、M氏の仕事上様々な年齢層の方にプログラミング等のレクチャーをすることがあるそうなのですが、一番食いつきといいのは実は30代半ばなんだそうです。ちょうどこの時代ってインターネットが出てきた黎明期のころから業界にいて、オープン化の波に食いついてきた世代のため、実装レベルの話をすると楽しくついて来るそうなんです。逆に、私のようにいきなりとってつけたようにJavaJavaしてる20代の若手の方が冷めていることが多いという話。
うーむ、確かに温度差がある。仙石さんのプログラマを目指すのに適した時代、適していない時代に通ずるものがある。
つまり、誰でもプログラマーになれた時代ではなかったというよりは、誰もプログラマーになろうとは思いもしなかった時代だった。しかし、逆説的ではあるが、苦労に見合うリターンが全く得られないからこそ、自分がプログラミングが好きだということを確認できたという点で、当時は「プログラマを目指すのに適した時代」だったと思う。
それに比べ、現在のように少しでもプログラミングができれば給料までもらえてしまう、ある意味プログラマが必要以上に優遇されている世の中では、好きだからプログラミングをするのか、それとも単に食うために(仕方無しに)プログラミングするのか、曖昧になってしまうわけで、「プログラマを目指すのには適していない時代」なのだと思う。
アメリカは引継ぎもカスタマイズもしないんですよ
これもは某大手外資系ソフトベンダーにお勤めのM氏のお話。
アメリカは「引継ぎ」なんてしないんです、とおっしゃってた。おそらく実作業レベルの粒度が、日本に比べて相当粗いんだろう。「引継ぎをしない＝業務オペレーションが洗練されている」とは限らないだろうが、システム化できるぐらい業務の標準化が出来ている、という側面は無視できない。カスタマイズもしないそうです。カスタマイズでしかカバーできない業務はやらないのだろうか。それとも日本のように会社毎に帳票出したり、っていう「それシステム化したら死ぬんじゃね？」的なワガママ要求が出てこないのだろうか。社会的背景も踏まえて。このあたりは興味深い。
欧米の顧客は日本ほどワガママではない、というのがあるのかもしれない。これは羽生さんがおっしゃってた。日本の品質要求って世界随一らしいじゃないですか。メリケン共とはワケが違うぜ、と。セブンの鈴木敏文御大が「ウォルマートなんて怖くありません」と言っていたのは、日本の顧客について来れやしないだろうという読みがあったからこそ、だと。
まとめ
はじめの２項目しかBPMとは関係ないというオチがあるんですが、BPMオフ会ではこのような有益で濃ゆいな話が盛りだくさんですので、特にユーザー企業にお勤めの方、是非とも参戦表明をお願いいたします！
