« 2008年4月 | メイン | 2008年6月 »

2008年5月 アーカイブ

2008年5月 1日

フリーダウンロードキャンペーン

今月の21日からSavvionのフリーダウンロードキャンペーンが始まった。7月21日までの3ヶ月間限定であるが、無料でモデラーが使えるのでぜひ試してみてはいかがでしょうか。日経ITProにも記事が出ていますので参考にしてください。

この無料のダウンロードは既に米国では行なっていて、日本でも大学向けにはやっていたのがやっと一般にも提供されるようになった。こうして、実際にツールに慣れてもらうのがBPMSの理解に役立つので、多くの人に使ってもらいたいと思っている。

まずは、BPMNに準拠したプロセス図の書き方を学ぶことから始まるが、大事なのはシンプルで一貫化したプロセスが描けるかである。

モデラーでは基本的にはアクティビティというコンポーネントを並べていき、分岐を発生させたり、管理アダプターをつないだりすることになるが、このアクティビティに何を持ってくるかがキーになる。

まあ、何はともあれ使ってみてください。


2008年5月 2日

理由

大林宣彦監督の作品というとまず浮かんでくるのが、「HOUSEハウス」である。1977年公開のホラー映画なのだが、いわゆるホラー映画というよりホラーファンタジーみたいな作品で、7人の少女が一人ずつ妖怪に食べられてしまうというもの。

何と言ってもこの映画の少女役が池上季実子、大場久美子、松原愛、神保美喜といった面々であることがすごい。ここからぼくは大場久美子のファンになり、大場久美子はコメットさんになっていった。すいません、横道にそれてしまった。

さて、映画「理由」である。宮部みゆきの原作は読んでいないのだが、どうも原作に忠実に撮ったらしい。だから映画も登場人物にインタビューしているように語らせることで成り立っていて、何と登場人物が107人にのぼる。

これだけの人が出てくるのでわけがわからなくなると思ってしまうが、最初はわからないなりにも一体どうなるのかという思いを持たせぼくには面白く感じた。ほんとよくこんな個性的な人たちを集められたと感心してしまう。

人間ってどうしても客観的にものは見えなくて自分の主観によってしまうところがある。思い込みやそうあるべきだとかそうに違いないと思ってしまう。そうした証言を積み上げながら映画は進行する。

いったい何が真実で何がウソなのかがもやっとした形で提示され、それをすこしづつ解きほぐしていく。でも結局何が起こったのかもわからないままで終わる。

いやー、大場久美子は出てきませんでしたが、なかなか面白いですね。

理由 特別版
posted with yusukebe.com::AmazonSearch on 2008.5.2
  • DVD / 角川エンタテインメント (2005-04-28)
  • Amazon 売り上げランキング: 30157
  • Amazon おすすめ度の平均: 3.5
    • 3 原作感を裏切らずに面白いと思った。
    • 5 幾重にも重なる箱を1つ1つ明けていくかのような展開
    • 5 最高に素晴らしいサスペンス映画
    • 5 パズルのような映画
    • 3 ディテールに神は宿る、が・・
Amazon.co.jpで詳細を見る


 

ITmediaに記事が

今日のITmediaのニュースにぼくら親子の記事がでた。

題して「ITは、いま :鎌倉の自宅ではたらく、父子2人のIT企業」で岡田有花さんが書いている。先月半ばにうちに取材に来ていろいろ聞いていったことが載っている。さすが記者の人は違う。こちらが勝手なことをぺらぺらしゃべったので、これをどうやって捌くのか興味があったがよく整理してある。

ちょっと照れくさいが読んでみてください。これで仕事が増えるといいのだが。そうはいかないか。
 

2008年5月 3日

びっくりした

昨日のITmediaの記事に対して、はてなブックマークがすごい勢いで付けられた。今日で500ユーザー数に届きそうだ。

そのコメントで親父のしゃべったことがかなり評価されていてびっくりした。ちょっと恥ずかしいくらいだ。正直そんな偉そうなことを言っている意識はなく、普段から思っていることを言っただけだったので、そうした持ち上げられ方にとまどっている。

単純におもしろいこと、楽しいことをやろうよ、そのためにはどうしたらいいかということだと思う。こういうことは年齢に関係ないことであって、いくつになっても持ち続けるべき心根だと思う。おもしろいことや楽しいことって自分でやりたいことであって、周りからやらさせることではないですよね。

ただし、それをやるにはいろいろなしがらみがあって、生活であったり、世間であったり、意気地であったり、自分自身を含めた抵抗勢力がいっぱい出てくる。それとどう折り合いをつけるか、あるいはそれをちょっとがんばってどけるかである。お金がないからできないという話でもない。

大上段にふりかぶって、これから好きなことをやりますなんて宣言しなくてもいい。潮時とかはずみというのがあるから、そのとき抜け出せばいい。

そのためには普段から自分のやりたいことを磨くことを忘れないようにするということではないだろうか。

皆さんにお褒めの言葉をいただいたのは、おそらく一丁あがりと思うことなくいつも前を向いていることに対してであろう。それは、ぼくが生来の楽天家で極楽トンボだからかもしれない。でもぼくはそんな自分が好きなナルシストでもある(笑)。

ぼくが好きな言葉を書いておく。ルイ・パスツールの言葉である。
「Chance Favors the prepared mind」
 

2008年5月 4日

PC-8001

ITmediaの記事に物置がサーバールームになっているという写真がでていたが、正確に言うと物置ではなく納戸に(まあ同じようなものか)、段ボールに入ったがらくたと一緒にマシンが置いてある。前々からこれらがらくたを整理してもう少しスペースを持たせないといけないと社長と話していた。

そこで昨日ぼくの担当のところを片付けていたら、突然ぼくの携帯が鳴った。社長から実印どこにあるという電話ではなく(笑)、サーバーが止まっているけど見てくれるという。社長は土曜日はいつも横浜で作業をしているので止まったのがわかったらしい。

それで言われるとおりディスプレーをつなぎ直して、回線を調べたりしたら、何と電源が外れていた。ぼくが蹴飛ばしたらしい。それくらい入り乱れていたのだ。

そんなわけで気を付けながら段ボール箱の整理をした。そうしたら、中から出てきたのがアルバムやらレコードやらで、しばし懐かしみながらの作業となりぜんぜんはかどらなかった。なかでも驚いたのはだいぶ昔に使っていたNECのPC-8001というPCがでてきたことで、とっくに捨てていたと思っていたのが出てきたのである。

ということで少しこのPC-8001にまつわる昔話を。確かこのPCを買ったのはうちの社長がまだ生まれたばかりの頃で、あやしながらこのPCを使っていた。PC-8001というのはぼくらのような年寄りはよく知っているのだが、その頃のベストセラー機でもうNECが独占的だってですね。

CPUが4MHzメモリーが16Kだったかな、そんなものでした。キーボートと本体が一体となっていて、カセットテープのデータレコーダがついている。それで価格が20万円近くしたはずで、そのときの給料からいうとかなり高価であった。この値段は今も変わってないのですが、容量、能力は格段に違う。

でなぜこんな高いものを買ったのか、これを使って何をしたのか。当時ぼくは化学プラントのエンジニアだったのですが、プラントの管理というのは、生成された製品構成の最適化と使用エネルギー原単位のミニマム化になるわけです。そのためには投入された原料の組成に合わせて運転条件を変えていくわけですが、その条件を設定するためにシミュレーションモデルが必要になる。そのモデルを作るのに使ったのです。

膨大な運転実績を多変量解析で分析し、モデル式のパラメータを決めていくのです。これはコンピュータがないと大変な作業となるのでコンピュータが使えてこそできたことなのだ。ただ、まだソフトウエアが少ないときだったので重回帰分析のプログラムなんかは本から写して動かした。

そうなんです、ぼくらはPCというのはあくまで計算機なのだ。それが今日のようにコミュニケーションの道具になるとは思ってもみなかった。

PCはAT互換機そしてWindowsが登場し、インターネットが普及していまのようになっていくが、NECのPCは8800、9800シリーズと続きやがて消えていった。

まあ、そんなわけでアルバムといい古いPCといい、片付けるどころかはるか遠い過去の情景に浸ってしまったのである。
 
PC8001.JPG
 

2008年5月 5日

また負けた

ほんとは書きたくなかったのだけど、わが横浜ベイスターズが勝てない。昨日も8回まで4点リードしていながらあの広島に(失礼!)負けた。新守護神寺原も打たれた。

勝率2割5分だから4回に1回しか勝てない。ああ、なんということだ。

いいですか、去年のちょうど今頃は首位だったのだ。中日に3連勝かしてすごい勢いだったのが、今年はダントツの最下位である。

打つのはそこそこ打つのだが、何といても投手陣がひどい。こういうときこそ若手の孝行息子がでてもいいのだが、この間の小林がそうだったのかもしれないが、昨日はその小林で逆転負けだ。

もう開き直るしかない。はちゃめちゃにやりゃーいいじゃん。誰か起爆剤になってくれ!
 

2008年5月 6日

誰も知らない

2004年度キネマ旬報ベストワンに輝いた是枝裕和監督の「誰も知らない」を観る。

うーん、微妙だな。主演の柳楽優弥君がカンヌ国際映画祭主演男優賞を受賞して話題になった作品だが、確かに柳楽君の眼力はすごいが、ぼくにはこの作品がいい作品なのかよくわからないと言ったほうがいい。ダメだといっているわけでもないのだが、評価に困る映画である。

映画は前半から中盤に淡々とストーリーが進む。もちろんその中では、こどもたちの演技とも呼べないような自然の振る舞いを切り取り、小物をなめるように撮ったり(実際に足元のシカットが多い)、少々冗長的でさえあるシーンが続く。

実際に巣鴨でおきた事件を題材に作られたというが、単に事件のアウトラインだけをもってきているだけで中味はぜんぜん違うと思う。あんな母親ではないはずだ。

結局、最後のシーンでタイトルの「誰も知らない」に納得するわけだが、“だからどうだっていうのよ”と叫んでしまった。それにあの終わり方は恐ろしいよね。

だから、繰り返すが事件の実相と全く違った創作だからリアリティを出すのが難しいのだ。

そこでリアリティがないからよくわかんねえと感じてしまうような気がする。映画自体はドキュメンタリータッチで雰囲気はもろリアルって感じなのだが、それ以外に強く伝わってくるものがない。

でもこれだけの評判でベストテンのトップなんだからいい映画なのだろう。ぼくの映画を観る眼が狂ってきたのかな?ぼくは全く予備知識なしで観たが、皆さんはおそらく実際にあった事件を下敷きに作られたことを知って観ているのではないでしょうか。

ぼくの勝手な推量だが、悲惨な事件だからきっと映画もそうなんだとかといった予断があると思う。そんな眼で観た場合とそうでない場合とでぜんぜん違って見えるように思うのだがいかがでしょうか?

誰も知らない
posted with yusukebe.com::AmazonSearch on 2008.5.6
  • DVD / バンダイビジュアル (2005-03-11)
  • Amazon 売り上げランキング: 4045
  • Amazon おすすめ度の平均: 4.5
    • 5 子が親の犠牲になる時代。
    • 5 明日に向って
    • 4 誰も知らない
    • 4 真実と虚構の間に生まれたリアル
    • 5 淡々と・・・凄い作品
Amazon.co.jpで詳細を見る


 

2008年5月 7日

テレビの衰退

以前、テレビの劣化というタイトルで記事を書いたことがあるが、そのときは、週刊誌の見出しに見つけた、一発芸人使い回しとかドラマの原作は漫画ばかり、「ワイドショー」の新聞棒読みをやめろとかを指摘した。そして、ぼくは今年から一部の番組を除いて極力テレビを見ないことにしている。

そうしたら、どうも最近は若者のテレビ離れも顕著になってきたらしい。そのため、スポンサーが集まらなくなってきたという。確かに高い視聴率の番組が減っているようだ。

これは、ひとえに番組の質の低下に尽きるのだろうが、そのへんのことがちょっと前の痛いニュースに出ていた。普段はこの手の記事は読まないのだが、ぼくが前から言っていたことと同じことを皆さんコメントしていたのでつい書きたくなった。

もちろんネットを普段使っているひとたちのコメントだから、テレビに否定的なのはわかるが、でも言っていることをよくみるとけっこう冷静に見ていることがわかる。

結局、彼らが言っていることを整理すると

・番組自体が面白くない。芸能人がクイズに答えたり、飯食ったり、カラオケ歌ってんのを見てどこが面白いんだ。NHKとテレビ東京ぐらいしか見るものはない。(ぼくも同じことを言ったことがある)
・テレビは一方的に電波流すだけで、それに見るほうでなぜ合わせなくてはいけないんだ。勝手にCMは流すしじゃまでしょうがない。
・どうせ時間を使うのだったら能動的に見たいよね。
・最新の情報は2ちゃんが最速だしドラマやアニメはようつべとニコ動で事足りる。

てな具合で若者はどんどんテレビから離れていってしまうのだ。ここでの問題は、一方通行の情報をプッシュしているだけのテレビの存在価値が縮小していくことなのだが、ある意味当然である。だって、双方向のコミュニケーションとオンデマンドになっているネットのよさをみんなが知ってしまったからである。

だから、テレビもそうした要求に答えることをしていかないと本当に衰退していくだろう。

2008年5月 8日

介護・家事手伝い付きSOHO型親子丼的起業

先日(5月2日)のITMediaの「鎌倉の自宅ではたらく、父子2人のIT企業」という記事が思いのほか反響があって、まだITMediaのアクセスランキングで29位にいる。あの記事の中では、主に仕事関係の話だったが、それ以外のことを少し。

ぼくが会社を辞めて家で仕事をするということになったら、3人が喜んだのである。まあ、息子のことは記事に出ているけれど、その他の2人はぼくの嫁さんとぼくの母親である。

嫁さんの方は、最初は「ええー、お父さん毎日家にいるのおー」と露骨にいやな顔をされた。だから、自分の家ではなく、向かいのばあちゃんの家で仕事をすると言ったら、顔がほころんだ。

一方、ばあちゃんはもうすぐ87歳になるんだけど、介護がいるというわけではなく元気でぴんぴんしている。しかし、最近はさすがにからだのことが心配なようでひとり暮らしが不安になっていた。だから、ぼくがばあちゃんの家の応接間をきれいにしてそこを事務所として使うと言ったら、そりゃあ良かったと言って喜んでいた。

まあ、いつも息子が同じ屋根の下にいてくれるということで安心だし、ときどき話し相手にもなってくれるということで暇つぶしにもなる。いつも、お風呂に入るとき、風呂の中で倒れるかもしれないからと言って「今から風呂に入るから」とぼくに言ってから入る。たまに、仕事に集中しているときに邪魔されることはあっても、機嫌のいい顔がみられるのでしかたがない。

ぼくの家は山の中にあるので、買い物やら病院、郵便局に行くのもけっこう大変なのだ。坂道なので行きはいのだが、帰りの登りはきつい。嫁さんも若い頃は自転車で出かけたりしたが、歳とともに元気がなくなり、ぼくが車で送り迎えをしたりすることが増えた。嫁さんは助かると言ってくれる。

それと、山の中ということは庭に葉っぱが舞い降り、雑草が激しく生えてくる。その掃除や草取りもぼくの仕事になっていった。まあ、家の中にずっといるより天気のいい日にする庭仕事もいいものだ。

仕事の場所が鎌倉というのもなかなかいい。いいというのは東京にほどよい距離感にいるということである。自然に囲まれているということである。いつもは緑に囲まれたところで静かに仕事をして、たまに東京にでかけていくというのはメリハリがあって快適なのだ。呑んで遅く帰っても次の日は家にいられる。

ただ、こんな生活が誰でもできるというわけではない。だいいち家がどこにあるのか、ばあちゃんの家が目の前にあるのか、周りに緑があるのかなど条件がそろうのは難しいかもしれない。たまたま、ぼくにはそうした条件がそろったのだろうが、みなさんもちょっと無理すればこうした生活に近いことはできないことはないと思う。

こんなことを言っているぼくにしても、若い頃は考えもしなかったし、できなかった。やっとこの歳になって、そうだこんな生活もあったのだと気がついたのだ。だから、皆さんも、いつでもいいから一度、肩の力を抜いて自分の今の生活スタイルをみつめてみたらいかがでしょうか。
 


2008年5月 9日

腑抜けども、悲しみの愛を見せろ

本谷有希子の戯曲および小説を映画化したもの。吉田大八監督、佐藤江梨子主演のブラックコメディ?だそうだ。

まず、このタイトルに驚かさされる。腑抜けはいったい誰なんだ。まあ勝手に解釈すると腑抜けは永瀬正敏演じる連れ子の男のことじゃないかと思ってしまう。それだけ他の女性陣のしたたかさや強さが際立つのだ。

いくつかこの映画で特筆すべきところがあって、まずは今言った永瀬正敏が演じる男が大まじめに生きる姿が滑稽にさえ映ることである。結局、何かに耐え切れず命を絶ってしまう。

それに較べて、3人の女性陣がすごい。佐藤江梨子、佐津川 愛美、永作博美の演じる女性たちである。この3人のしたたかさは感動さえおぼえる。

次いで、妹が叫ぶ「おねえちゃんって、やっぱおもしろいや」というセリフ。これにはのけぞった。さんざんいじめられておきながらこの返しにはまいった。

それからちょっと考えてみたら、ううっと思ったのは、“演技が下手で女優になれない女優のたまご”を演じる女優のことである。この役は佐藤江梨子なのだが、彼女はうまく演じたのかどうなのか、ああ混乱してくる。

最後は、永作博美のたまらなくかわいい女の演技だ。能天気な上房の打たれ強さみたいな、しかしほんの少し影があるといった雰囲気がすばらしい。あとで、調べたらブルーリボン賞の助演女優賞をもらっていた。それだけの演技であったと思う。

こういうストーリーは昔だったらドロドロの世界でそういう描き方をするんだが、今だとこんな形の映画になるんだなあと少しとまどい気味である。
 

腑抜けども、悲しみの愛を見せろ
posted with yusukebe.com::AmazonSearch on 2008.5.9
  • DVD / アミューズソフトエンタテインメント (2008-02-22)
  • Amazon 売り上げランキング: 1401
  • Amazon おすすめ度の平均: 4.5
    • 4 感想
    • 3 中途半端
    • 5 本気で邦画が凄い!
    • 5 う〜む、解説困難なこの妙〜なカタルシスはなに?
    • 4 俳優入門
Amazon.co.jpで詳細を見る


 

2008年5月10日

小飼弾の「アルファギークに逢ってきた」

弾さんが書いた「アルファギークに逢ってきた」(技術評論社)を読む。これは「Web+DB PRESS」に連載された記事をベースに一冊の本にしたものである。もう一気に読めた。弾さんGJです。

ただ、ITいやウエブいやプログラム言語を知っている人でないと何を言っているのか全く分からないのではないだろうか。ぼくは、プログラムを書いたことがない(正確にいうと若いころN88-BASICは少し書いたことはある)が、ここ1,2年で少し聞きかじったおかげで多少はわかるが、そうでない人は聞いたこともない言葉がでてきて、さっぱり理解できないと思う。

ということは逆にそういうことをよく知っている、あるいは今使っているような人たちにとっては面白くてしょうがない話なのだろう。

それでもここに出てくるアルファギークたちの技術ではないところでの言葉に感動するのである。もう書きたいことはやまほどあるんだけどネタばれになるし、書き切れないので登場するギークたちの言ったことの中から印象に残る一言ずつをあげてみることにする。

・Daivid Heinemeier Hansson :Ruby on Railsの開発者

生物はConfiguration(設定)をいじりまくるのではなく、Convention(規約)をそのまま援用している。いろいろ設定を変えてうまくいくものだけを拾い出すより、きちんと動く設定を少しずつ変えるほうがうまくいくんだ。

・伊藤直也:「はてな」のCTO

経済的に幸せになること「だけ」を考えてコードを書くっていうのは、あんまりよくないかなって思うんですけど、本当にコードを書いて世の中がよくなるんだったらって感じがします。

・Larry Wall:Perlの開発者

どれだけ優れたソフトウエアでも、文化を持たないものは普及しません。

・Evan Williams:Twitterの生みの親

失敗すれば落ち込むけど、失敗というより、過程なんだよね、うまくいくための。失敗しなきゃ、何もわからない。

・Dave Thomas:「達人プログラマー」の作者

ソフトウエアエンジニアリングというものはありません。少なくともまだないです。どういうことかというと、これ以上削れないところまで削るのがエンジニアリング。これ以上削れないところまで削るということは、どこまで削るとそれが壊れてしまうかがわかっていることです。まだ、ソフト上に関しては我々はそのレベルまで達していないんです。

・奥一穂:サイボウズラボ、Japanize、Pathtraq開発者

自分が前の会社で何が嫌だった、向いていないと思ったかって、請求書書くの嫌だった。

・John Resig:jQuery(JavaScriptライブラリー)作者

あえて機能を追加しないことができる人がすごいエンジニアだと思います。すなわち具体的に何が重要であり、何が重要でないかということを理解したうえで、その理解のもとで最適化できる人。

・Ingy .Net、Dave Rolsky、Jesse Vincent、C.L.Kao:Perl Mongers
「優れたエンジニア」、「ハッカーとの違い」はとたずねられて

Vincent: ひと言でまとめちゃうと「ハックへの愛」かな。
Kao: 単にエンジニアというのであれば「情熱」というのは必ずしも必要ではないと思います。
Rolsky: すごい大きな視点とすごく細かい視点を同時にもっている必要がある。
Ingy: プログラマー以外の視点を持つっていうのもすごい重要。

・天野仁史、はまちゃ2:JavaScriptの達人
優れたエンジニアとして重要なことはとたずねられて

天野: 俺は自分一人でどこまで作れるかっていうことだろ思います。上から下までどのくらい作れるか。アイディアもその人が持っているっていうのが、やっぱり俺は優れたエンジニアだと思う。行動力とスピード感と、あとはまんべんなく知っていて作りきるだけの技術力みたいな。
はまち: ぼくが思うには、やっぱり視点かな。すごく大きな視点と、顕微鏡みたいな視点、両方を持ち合わせている人!

・近藤淳也:「はてな」代表取締役社長
「はてブ」ってdelicio.usの真似かよ見たいに言われたらという問いに対して

思いついた瞬間で比べるとそうかもしれないですけれど、行動を起こしたほうにどんどん情報はついてくるじゃないですか。だから最初はもっといろんな素晴らしいことを考えている人がいたとしても、行動をちゃんと起こしておけばいいのかなと思います。

ね、すごいでしょ。みなさん言うことに説得力がありますよね。それに、かなり共通点があります。例えば、Dave RolskyやIngyが言っていることとはまちちゃんの言っていることが全く同じで、大きな視点と小さな視点を併せ持たなくていけないと言っている。これなんかぼくはものすごく共感する。前から言っているんだけどぼく流にいうと、“空を飛ぶ鳥の眼と地を這う虫の眼がいる”ということなのだ。

いずれにしろ、アルファギークたちの頭や心のなかの一端を知ることができて大変おもしろかった。ただ、欲を言えば、この続編としてもう少しテクニカルな話じゃなく、仕事スタイルみたいなものに絞って書いてくれるとエンジニアではない人にももっと読んでもらえるのではないかと思ってしまうのである。
 

小飼弾のアルファギークに逢ってきた [WEB+DB PRESS plus] (WEB+DB PRESSプラスシリーズ)
posted with yusukebe.com::AmazonSearch on 2008.5.10
  • 小飼 弾
  • 単行本(ソフトカバー) / 技術評論社
  • Amazon 売り上げランキング: 188
  • Amazon おすすめ度の平均: 3.5
    • 3 Web系最先端プログラマー
    • 4 ギークがギークに会いに行く
    • 4 ギークがギークに会いに行く
Amazon.co.jpで詳細を見る


 

2008年5月11日

アルファギークのアルファとは

昨日、「小飼弾のアルファギークに逢ってきた」の書評を書いたが、このアルファギークとは一体何のことなのかについてである。本の裏表紙には次のように書いてある。

「アルファ」は動物行動学ではリーダーとなる個体のこと。 「ギーク」は、ひたすら「好き」を貫いて信じる道を往き、世界を少しずつ、しかし確実によい方向に変えていくエンジニアのこと。 アルファギークとは、そういう特性を併せ持つ人たちです。

もう少しぼくなりに考えてみる。どうもみんなの言っていることを整理してみると、簡単に言うとスキルと情熱の4象限にあるように思える。スキルと情熱高い位置にいるのがアルファギークである。

すなわち、秀でた技術力をもって好きなこと、やりたいことを貫きとおすことがアルファギークの最小限の要件であるように思える。

それと、なんとなく技術オタク的なイメージを抱きかねないが、実はそうではなくて、幅広い視野、あるいはほどよいバランスといった感覚が備わっていないといけないのだろう。だから、狭い範囲の技術には優れたものを持っているが、それをやり通す熱情が感じられないのは単なるギークであるということになる。

もうひとつ言えることは、いろいろな視点でものを見るということとつながる話なのだが、一人でなんでもやってしまうということだ。

ひとつの領域だけで優秀ということはなく、できるやつは広い範囲でできるのだ。ここのところも特徴的な点で、想像力と創造力の豊かさをもって“自ら新しいものを作ってしまう”というところにアルファギークの存在感があると思う。模倣ではない独創、あきらめないこだわり、くじけない精神力、こうした要素こそこの世界で突っ走るために必要なものである。

ところで、アルファギークになれるヤツはいいけどなれない俺たちはどうなるのだ。最初にスキルと情熱の4象限と言ったが、情熱があってもスキルのないヤツ、スキルがあっても情熱のないヤツである。

前者のほうは、二つの方向があって、ひとつはスキルのあるヤツを使いこなすことを考えることで、これをプロジェクトマネジメントスキルという。もうひとつは職人に徹することだと思う。

後者は、これはなかなか難しくて、お前燃えろよと言ったところで本人がやる気がなかったらどうしようもない。まあ、ぼくのお薦めは自分ひとりになる環境を無理やりでもいいから作っちゃうということだ。個人事業主になってもいい、起業してもいいから独立することだね。

もちろん、スキルもなくて情熱もないヤツは問題外。

そういう意味でウエブの世界はずいぶんと技術者像のイメージを変えている。従来のようなステレオタイプのエリートエンジニアではついていけないような気がする。このムーブメントは早晩非ネット世界にも波及していくと思われる。

そのとき、このギークにアルファがなぜついたのか、どうしたらアルファを付けられるのか、アルファになれないギークがどうしたらいいのかを考えると面白いと思うのである。
 



2008年5月12日

アヒルと鴨のコインロッカー

このあいだ伊坂幸太郎の原作を読んで映画が見たくなったので借りてきた。小説を読んだとき、時間を交錯させたカットバックで書かれているので、これを映画にするのはどうするのだろうか、こりゃ難しそうだなと思った。

そうしたら、うまくさばいてあってびっくりした。中村義洋監督の手腕はたいしたものだ。ほんとはそのさばきかたを書きたいのだが、そこがこの映画の肝なのでまずいのでやめておく。まあ、原作に忠実に撮ってあるといえるのだが、原作どおりではないという作り方なのだ。とまあここまでで、中味はあまり語れない。

おそらく、なぜボブ・ディランなのだとか、ブータン人がどうしてあんなに日本語がうまくなるのだとか、人がいっぱい死にすぎだよとか批判する人がいるが、映画って日常的なことを拡大したり、誇張的な表現をするものだから、細かなところでありそうもないとか、おおげさだとかという批判はあまりしない方がいいように思う。

全体の雰囲気とか気分といったものがどうかというふうに観た方がいい。そういう点では、仙台という設定がいいし、若者特有の不安定さが出ていてよかったと思う。主演した若手俳優陣も生き生きとしていた。そうなんだ伊坂の小説は映画的なのだ。
 

アヒルと鴨のコインロッカー
posted with yusukebe.com::AmazonSearch on 2008.5.12
  • DVD / アミューズソフトエンタテインメント (2008-01-25)
  • Amazon 売り上げランキング: 801
  • Amazon おすすめ度の平均: 4.5
    • 4 原作ファンとして気持ちの良い映画化。
    • 5 完璧な映像化、見事です
    • 5 気紛れで見たけど最高の映画でした!
    • 5 思わず共感してしまう
    • 4 役者陣が映画の質感を上げた珍しい作品
Amazon.co.jpで詳細を見る


 

2008年5月13日

業務プロセス設計作法 ~ はじめに ~ 

これから何回かに分けて、上流設計にあたる業務プロセス設計について書いてみようと思います。

以前にも「ユーザ目線のBPM」で触れていますが、より具体的な方法を提示していきたいと思っています。これまでは、どちらかというと業務フローができたら、基本的にはノンコーディングでシステム構築ができることを説明してきていますが、その上流のところの話になります。実はここが非常に重要であると同時に難しい領域なのです。

ですから、今までも再三言ってきていますように「シンプルで一貫化されたきれいなプロセス」が書けたらそれでおおかたのシステム構築が終わってしまうということになりますので、そのきれいなプロセスをどう書くかがますます大事になるのです。

そこで、この業務プロセスを書くための作法についてひとつずつエントリーしていくことにします。本技法ではつぎに示すような16の作法からなっています。この作法に従って業務プロセスを作っていけば容易に実装までもっていけることを示せたらと思っています。

1.プロセスの特定
2.プロセスの始点のアクティビティと書類化
3、受付タスク管理
4.プロセスの終点のアクティビティと書類化
5.コンテ(業務・仕事のあらすじ)の作成
6.最終書類の必須データ項目
7.中間アクティビティの書類化と確定データ
8.中間書類の内容
9.分岐のタイプ
10.サポートシートの記述
11.きれいなプロセスにするための7つのチェックポイント
12.スイムレーン
13.データベースとデータディクショナリ
14.ビジネスルール
15.帳票
16.実作業の扱い
 

2008年5月14日

業務プロセス設計作法 ~なぜ“作法”なのか~

設計というと手順とかメソッドとかいった言い方の方が一般的であると思いますが、それだと何となく論理的なにおいがしないでもなく、ソフトウエア工学ですねみたいになります。しかし、よく考えてみると業務システム開発って工学的でしょうか?

少なくも、業務モデルは工学的モデルではないように思います。なぜでしょうか。それは人間が介在するものだからです。すなわち、恣意的であり、揺れたり、属人的であったりするのです。

とはいえ、全くカオスにできているわけでもない。厳密ではないにしても何らかの約束事はあるように思えます。別な言い方をすると、約束事ができるようなところとそうはできないところを分離して考えられそうだということです。

この考えが生まれた背景を少しお話しますが、ぼくは元々ケミカルエンジニアで化学プラントのオペレーションやプロセスエンジニアリングをやっていました。そのときの経験や考え方をときどきビジネスシステムにも重ね合わせて見ることがあります。そうですよね、同じプロセスという言葉を使っています。

それで、違いは何かということを考えたとき、真っ先に浮かぶのは、ビジネスプロセスにはオペレーションとかコントロールという概念が乏しいよねということなのです。それは、なぜかというと、どうもプロセスに人間が入っているかいないかの違いではないかと思ったのです。

ということは、人間が入ってくると、オペレーションやコントロールが難しいということを意味します。化学プロセスでは少なくともプロセスフローには人間が登場しません。人間が登場するのは、オペレーターとして、プロセスのオペレーションとコントロールを行います。ここが大きく違うように思えます。

そうであれば、そうしたことができるような構造にするには人間系をはずしてみたらいいのではないかと考えたわけです。

そして、ただはずしただけではいけないのでそれらはCMS(Contents Management System)に預けたわけです。ということでBPMSで扱うコンポーネント(アクティビティ)を書類という“箱”にして、ある程度約束ごとをもったものを登場させたというわけです。

化学プロセスも単位操作(加熱、冷却、圧縮等の処理)の連なりであり、それらが非人間系なので法則性があり論理的なプロセスが形成できる。ですから、書類を作成して発行するというのを化学プロセスの単位操作と同じようにハンドリングすればいいのです。しかも、組織というこれまた非論理的な要素もこれで排除できます。これはスイムレーンの問題なのであとで詳述していきます。

さて、おわかりになってでしょうか。ある切り出し方をすれば化学プロセスのように、あるいはエンジニアリング的にやれるのです。

そして、残った部分は人間系であり、恣意的な要素になりますが、これらは思い切って人間くさい“ゆるい”場所(情報共有の場)にもっていってしまうのです。こうした構造化がこの技法のポイントのひとつです。

一方、開発サイドからみると、上述のように工学的な問題に近づけたとしても、まだあいまいさは残り、そうしたモデルでも作るときはみなばらばらになっても困るわけで、それなりの集団としての秩序が維持されなくてはいけません。

そうした場合、これはいったい何をもってその秩序とやらを、また約束事を担保できるかと考えると、それは“お作法でしょ”ということになります。作法は「型である」と言えます。ですから、基本的な型を決めておくということになります。

よくある開発方法論などは、どうしても工学的なアプローチやプログラミング的なアプローチであり、ビジネスの観点からすると、すごくなじみがなくわかりずらい面があったように思います。「作法」というと、それほど確固としたものではなく、だいたいこんな風にしたらいいぐらいの感じで決めていけばいい。ただし、芯ははずさないようにすることが大事です。

ですから、作法に則ってやっていけば、誰でもほぼ同じような業務プロセスができてくるのです。ここが非常に重要なポイントになります。

こうして作られたものは、ある意味狭い範囲ではあるかもしれませんが、標準化されたものであるといえます。そうすれば再利用性が高まることは言うまでもありません。

作法は型なのでそれを表現するための様式も用意する。基本は書類に相当する“シート”ですが、そのほかにも“カード”、“サポートシート”があり、それらを綴じると“ブック”になり、これは業務プロセステンプレートになります。これらの“ブック”を集めたものが“ライブラリー”となります。それぞれの概要はつぎのとおりです。

ライブラリー:ブック(業務プロセス)を集めたものでインデックスを貼って分類する。
ブック:シートを時系列的に並べて綴じたもので、業務プロセスを表現する。
シート:業務機能コンポーネントを始点シート、終点シート、中間シート、サポートシートとして作成し、シートにカードを貼り付ける。コンテを書いてから作成する。
サポートシート:意思決定をサポートするコンポーネントで主にEXCELのようなスプレッドシートで管理する。
リレーションカード:シートにおいて参照、連絡、分岐などの関係性を表す。参照カード、連絡カード、サービス連携カード、分岐カードなどがある。
%E4%BD%9C%E6%B3%95%EF%BC%88%E5%9B%B3%EF%BC%89kailasBook.jpg
こうした作法に即した体系で自分たちの業務プロセスをドキュメントとして残しておき、ビジネス環境の変化に迅速に対応していけるようにしていくことが重要となってきます。

さて、次回は前提となる考え方について書くことにします。
 

2008年5月15日

業務プロセス設計作法 ~作法を考える上での前提~

これから提示する作法は、もちろんどんなものにも適用できるかというとそうではありません。まず、注意しなくてはいけないのは、実装を意識したボトムアップの手法だということです。

事業戦略とかビジネスゴールから業務プロセスに落とし込んでいくトップダウン手法がありますが、本作法はAsIsベースのボトムアップ手法です。実際には両者の組み合わせでおこなうハイブリッド型のアプローチが有効になります。

こうした組み合わせもケースでいろいろなやり方がでてきます。AsIsのプロセスを切る出して、そのプロセスをベストプラクティスモデルと突き合わせて改善していくというオーソドックスな場合や、新規事業などはそのままモデルを適用する場合もあります。また、IT化のレベルが低い会社などでは、まず現状のシステムの見える化をするだけで十分だという場合もあると思います。ですから、トップダウンだとかボトムアップだとかはあまり気にしない方がいいのかもしれません。

要は、自分たちが現に行っている事業がどういう業務プロセスから成り立っていて、それが役に立っているのかを把握できるかである。それが分かれば、今のままでいいのか、変えなくてはいけないのかが明らかになるのではないでしょうか。

基本的には、「書類コンポーネントをベースにしたCMS-BPMSを使った業務アプリケーション構築」のための設計になっています。

ただし、それだけに特化したものでもありません。プロセスというものは機能の組合せで成り立っていることは何度も申し上げていますが、その機能をコンポーネントと捉えていく考え方であれば適用は可能です。すなわち、そのコンポーネントを書類というようなオブジェクトを想定するのか、また違ったものに定義してもかまいませんが、同程度の粒度でみているものであれば、同じように設計が可能です。

BPM(Business Process Management)アプリケーションを考える場合は、多くの場合はマスタデータは整備されているという前提に立ちます。業務プロセスをまわすために必要なリソースデータ、例えば、顧客、取引先、商品、従業員マスタなどは既に用意されていて、それらを参照するようにしています。

ただし、BPMでももちろんデータを扱いますので、データディクショナリーを保有し、データの一貫性やデータベースの重複の回避など、整合性を保つ必要はあります。

もし、整備されていない場合はデータモデリングから入り、マスタの構築を行ないます。

同じように、ビジネスルールについても、別途保持しているという前提です。それらのルールに従って、分岐の発生や意思決定の方法が規定されていきます。もちろん、そのプロジェクトで新たに出てくるビジネスルールもあります。

こうした、前提条件についてもこれからの作法の中に出てきますのでそこでまた議論したいと思います。

2008年5月16日

業務プロセス設計作法 ~前提の補足説明~

この作法では書類というコンポーネントを主体にお話していますが、書類という類型化された整理の仕方になじまない方もいらっしゃるかもしれませんので、何がなんでも書類にするということではないということです。前回も“同程度の粒度のものであれば”ということを言っていますがそこをもう少し補足しておきます。

大事なことは書類にすることではなくて、書類の作成から発行までがちょうど業務処理の単位と同じであると言っているのです。同時に、その書類を作るということは何かのデータを確定することを意味しています。ここが重要なポイントで、ですからもし書類がいやなら、“確定シート”でもかまわないのです。

従来の考え方でみると、といってもBPMは最近の話で、BPMでない場合はどうしていたのだろうかというのが気になりますが、モジュールだったのでしょうか?

BPMでもこのあたりの考え方、すなわちアクティビティをつなげてプロセス化するといっても、そのアクティビィティの粒度をどうするのかの答えがなかったのではないのか、というか、統一感を持った粒度設定ができていないと思います。

そこがこの作法の肝です。データを確定するためにする振る舞いは別の場にして、順番にデータを確定しながら業務を進めていくということがプロセスであると規定したわけです。人間系の不安定なアクティビティやアクションを違う場所に移したことが意味があることなのです。大きなプロセスには例外処理のようなものを極力排除していきます。

ですから、ここのルールを守ればいいのであって、この作法で言う「書類」を「シート」と読み替えてもらってかまいません。このあたりは、重要なのでこれから随所に出てきますのでよく理解しておいてください。

2008年5月17日

きた~BPM!

昨日、IBMの「IMPACT JAPAN SOA CONFERENCE」に行ってきた。まずはその盛況ぶりにびっくりした。場所は恵比寿ガーデンプレースにあるウェスティンホテル東京だったのだが、会場となった地下2階のフロアーは人で溢れていた。カンファレンスの後のカクテルパーティは部屋に入りきれずロビーみたいなところも開放していた。

参加者が千数百名ということで、午前中の基調講演は1ヶ所で行なわれたが、午後からの個別セッションでは5会場に別れた。ぼくは、ほとんどBPMに関するトラックで発表を聞いたが、その中でも言っていたが、SOA関連のセッションがいろいろあるなかで最も人気が高かったのがBPMがらみのものなのだそうだ。

こんなことは去年では考えられなかったわけで、やっと今年ブレークしていくような、そんな感じがした。SOAは浸透したので次はBPMだということなのでしょうか。

総括から先に言うと。さすがIBMということで、BPMを的確に理解して、その体系や製品群にしてもちゃんとしたものを提示していた。ただし、物足りなさもあるのでそれは後で記す。

元々は昨年の秋にIBM本体から発表されたSmartSOA(ちなみにぼくは1年前に作った体系にSmartBPMという名前をつけようとしたらすでにあったのでやめた経緯がある。SmartSOAはいいんですね)をベースにして、今年4月にラスベガスで開催された「IMPACT 2008 CONFERENCE」の日本でのSOA版といったところです。IBMのSOAに対する熱気が伝わってきます。

こうしたIBMの全社的な取り組みに比べて、NEC、富士通、日立、NTTデータなど日本の大手ベンダーの感度のなさは情けなくなる。もう間違いなくIBMやOracle、SAPに引き離される。Oracle 、SAPもまたBPMに対する力の入れようは加速している。

もう何年来もBPMの有効性を叫んできた身としてはうれしい限りである。これが一過性のバズワードになることはありえないので、正しく導入することを啓蒙したいと思っている。そういう意味ではIBMの今回のプレゼンは間違ってはいないものでさすがだと思った。

個々のセミナーについてのコメントは別途するかもしれませんが、いくつかのキーワードあるいはキーメッセージについて書いておく。

・“Sense&Respond”(感知して応える)
・差別化は“オペレーション”の革新から
・ドキュメント中心処理/意思決定入力によるアウトプット
・プロセスの自動化/エンジニアリングの考え方
・高頻度反復型の業務改革
・KAI(Key Agility Indicator)
・ビジネスアナリスト(業務理解能力、可視化・分析能力)
・ビジネスプラットフォームを作る(SOUP:Service Oriented United Process)
・ヒューマン・タスクの実現/ビジネス・ルール外出し/パッケージ活用
・ワークフローからBPA(Business Process Automation)へ
・ビジネスの「産業化」=オペレーションエクセレンス
・機能指向からプロセス指向に
・モデリングは、目的の明確化、規則を定める、利用ツールの特定が重要
・規則とは、命名規則、プロセス層の数(3~4)/深さ、プロセス粒度、1枚に書くタスク数(15以下)、イアウト、色の使い方、コメントの使い方、分岐条件の使い方
・企業IS部門の役割、責務が重くなる(ビジネスとITの仲介)
・SOAによる段階的システム導入

詳しくは、当カンファレンスのサイトに資料がそのうちアップされますのでそこを見てもらうとよいと思いますが、
このキーワードおよびキーメッセージを見て思うのは、これってぼくが1年以上前に言っていたことと同じじゃんということである。IBMの人はぼくのブログを読んでいるに違いない。(笑)

まあ、だからこそIBMを評価しているんだけれど、ただ今回で足りないことがある。発表しなかっただけかもしれないが、具体的なプロセス設計、開発の実践論ところが抜けているのだ。

いわば、トップダウンアプローチ色が強い、BPRの進化形というイメージで語っていることがいささかIBM的の香りがする。大上段に構えて、ビジネスを分析して、モニタリングして改善していくんだということがかなり強く出ている。

そんなことは先進的な大企業しかできないのであって、おおかたの企業は、まずはプロセスを見える化することで、それを実践的な話としてどうやっていくのかが最大の課題なのである。プロセスがきちんと作れていなのにモニターしてもしょうがないのだ。

だから、ユーザからの質問でもSOAは中小企業には適用できないのではないのかとか、近くの席に座っている人がいみじくも言ったのだが、どうせIBMのツールなんかは高くて使えないよなみたいな声が出てくるのだ。そこが、今回のなんか物足りなさが残ったところなのである。

でもいいのだ、そこがぼくの狙いどころである。巨象にはできないことをやるのだ。そう、“ラストワンマイルは俺のものだ“
 

2008年5月18日

ゾディアック

これは実際に起こった事件の映画化です。1960から70年代にアメリカで起きた連続殺人事件でいまだに犯人がつかまっていないという。

この事件に巻き込まれた、刑事、新聞記者、新聞社に勤める漫画家の3人を中心に物語が展開する。ゾディアックと名乗る殺人鬼を追いかけることにのめり込んで人生を狂わせたのだという。でも新聞記者にしても奥さんは逃げて行ってしまうが、またもとの鞘におさまったようだし、それはそれで人生なのではないかと思うが。

最初はミステリアスにそしてサスペンス的に進行してどうなるかと思ったが、だんだんわけがわからなくなった。なんというか、作り方が粗っぽいのだ。結構ややっこしい内容だから、ある程度緻密に作らないと頭が混乱してしまう。余計なエピドードはいらない。

途中でゾディアックらしい名前がでてくるんだけど、結局違うのだが、そいつはだれよみたいなことになる。
要するに、面白い題材なんだけど拡散していて絞りきれていない。もう少し工夫をすると、というより、誰が主人公なのかはっきりさせてその人間を追いかけた方が良かったと思う。おしいな。

Zodiac
posted with yusukebe.com::AmazonSearch on 2008.5.18
  • UMD Universal Media Disc / ワーナー・ホーム・ビデオ (2007-11-02)
  • Amazon 売り上げランキング: 27604
  • Amazon おすすめ度の平均: 3.0
    • 3 この映画の見方をおしえてもらいたい
    • 3 ドキュメントタッチのスリラーが好きなら。
    • 3 UMDで良かった・・
    • 2 流れが退屈でした
    • 3 「セブン」を超えられない監督
Amazon.co.jpで詳細を見る


 

2008年5月19日

業務プロセス設計作法 ~作法その1~

プロセスの始点と終点を決めます

まずは、プロセスの始まりと終わりを決めていきます。これは単純なことなのですが意外と重要なことです。よくプロセスがどこで始まってどこで終っているのかがよくわからないものを見かけることがあります。そういうプロセスって本当は必要ないプロセスかもしれません。

それと終わっていることは終わっているのだが単にどこかのファイルにしまっておくだけでほかに何も使わなかったりするなんてこともあります。

さて、ここで始点と終点を決めましょうと言っていますが、どうやって決めたらいいのでしょうか。

プロセスの始まりを考えてみましょう。これは、何かの依頼があって始まります。依頼のされ方も顧客からだったり、上司からだったりといろいろなパターンがありますが、いずれにしろ依頼がきてそれを受付けることから始まります。

それでは終点は何なのだろうか。これは、そのプロセスが何のためにあるのだろうかということを考えてみたらいいと思います。

プロセスというのは最終的にはビジネスの結果を表現することで終わります。もう少し具体的に言うと、リソースデータを書き換えることと新たなイベントデータを生み出すことにつながることです。別な言い方をすると、BS(貸借対照表)とPL(損益計算書)に反映するための活動プロセスなのです。

そうした観点から、始点と終点を特定していきます。詳しくはそのあとの個別の議論で行います。

では、始点と終点のどちらを先に決めるのかという問題があります。それは、お客さんからの要求によりプロセスが提起された場合は始点を先に決めます。また、内部で発生したような場合はBS、PLを意識して終点を先に決めます。

作法その1のポイント
・「○○から○○まで」という風に書き出します。(始点と終点を決めてからでよい)
(例)受注から出荷まで、見積依頼受付から見積まで
・顧客接点のプロセスの場合は始点を先に決める(お客さんの要求が最優先) 
・内部プロセスの場合は終点を先に決める(BS、PLに繋がることを意識)

2008年5月20日

業務プロセス設計作法 ~作法その2~

始点は「依頼を受付ける」ところから始まり、通常「○○依頼受付書(メモ)」が最初の書類となります

プロセスが開始されるのは、どこから依頼があって、それに基づいて行われます。その依頼のされ方はいくつかのパターンがあります。

1)外部からの依頼
2)内部からの依頼
3)ルール化されたトリガーによる依頼

外部からの依頼というのは、顧客や取引先からのもので、その中でも特定されているのか、不特定多数からかに分類することができます。

特定顧客かそうでないかで依頼の受付け方が違ってきます。特定顧客の場合は、おおかたの場合そのまま受付けにつながりますが、不特定顧客の場合は、その顧客が真の顧客になるのかどうかとか、要求をよく吟味しなくてはいけないとかいった前処理が必須となります。

従って、この場合は受付タスク管理の仕組みで一旦オペレーションする必要があります。よくある例はコールセンター機能です。

ここで許可された依頼を後プロセスへとエスカレーションすることになります。

その他では、ルール化されたもののなかでスケジュール化されて依頼がやってくるものがあります。例えば、月末・期末になったら必ず行われるものなどがありますが、これらは自動的に受付されますので、受付というアクティビティはスキップさせることができます。

それ以外では、「○○依頼受付書(メモ)」という書類コンポーネントを起こして受付けることになります。ここには、依頼内容などを5W1Hの観点で書き出すことにします。

もちろん依頼は、様々な手段、例えば電話、FAX、電子メール、Webサイトなどで来ます。ですから、そこから自動的に後プロセスに流すのは危険なような気がしますので、基本的には一旦切って人間が介在させたほうがよいと思います。

もちろんWebサイトからオンラインで取り込むことや受付タスク管理から自動的に書類を起こすこともできます。要件によって使い分けることになります。

作法その2のポイント
・プロセスの始点は依頼を受付けるところから始まる
・ルールが決まっているもの以外は受付タスク管理の仕組みで受付を許可するか決める
・受付タスク管理と下流プロセスへのエスカレーションは手動でかまわない
%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%891.JPG
 

ソルチクの夏

この映画を観終わったときに、なんとこの映画は古式蒼然たる映画化と思ったのである。しかし、だんだんじわじわと伝わってくるものがある。それが何かというと、ある意味普遍的なものを恥ずかしげもなく、照れもせずにどうどうと表現したことかもしれない。

見てるほうで照れてしまう。だって、韓国と日本という距離感、1年に一回しか会えない(どうして会えないのかしらないが)、方や外交官の息子、かたや流しの娘という設定(なぜか貧しい娘は日本の女の子)、恋心にゆれる女の子4人、このなんとも古典的な情況設定はどういうこと?

しかもですよ、歌が「なごり雪」なのだ。ええ、七夕に雪ですか。舞台は東京じゃないですよね。という具合になんとなく不釣合いもある。

チルソクというのはハングルで七夕のことらしいが、お分かりのように韓国の高校生の男の子と日本の女子高生は30年まえに陸上競技大会で出会って、一年に一回しかあえないが文通していて恋心を通じあわせるというもの。おいおい、素人の恋愛映画じゃあるまいし、と思ってしまうが意外と見終わった感はいいのだ。

なんなんのだろうかと考えてもしょうがない。人間って何も劇的な生活や人生を送っているわけではなく、べたであれ、背筋がこそばゆくても、無垢なことは素直に気持ちいいのかもしれない。

そんな映画、佐々部清監督の「チルソクの夏」であった。
 

チルソクの夏 特別版
posted with yusukebe.com::AmazonSearch on 2008.5.20
  • DVD / 角川エンタテインメント (2004-10-29)
  • Amazon 売り上げランキング: 27197
  • Amazon おすすめ度の平均: 4.5
    • 5 ディテールにまでこだわった至高の青春映画
    • 4 奇跡の昭和テイスト
    • 4 いつかお互いが分かり合えるといい
    • 5 コンキチ&ナターシャの絵本ナビ
    • 4 邦画青春映画の佳作
Amazon.co.jpで詳細を見る


 


2008年5月21日

業務プロセス設計作法 ~作法その3~

受付タスク管理表は、スプレッドシートに依頼事項や受付状況を記載します

その2でも述べたように外部顧客(特に不特定多数の顧客)の依頼については、そのまま受付というわけにはいかない場合が多くあります。そうした場合は、依頼の背景や内容を吟味しながら、あるいはお客さんと会話しながら受付を許可するか決定していきます。

そのための管理シートとコミュニケーションができるものを用意します。そこに、記入し、許可されたものが下流のプロセスに流れていくようにします。

この機能は、大きいものではコールセンターがこれにあたりますし、その他、問い合わせ窓口、苦情相談等々様々な形がありますが、基本的には案件管理の仕組みは同じだと考えています。もし、すでにこうした機能を保有している場合はそれらを活用したらよいと思います。

ただし、ここでのポイントは単に受付担当だけで決めるのではなく、その場に決定権限のある管理担当の人も参加させていくことです。そうすることによりスムーズな意思決定ができるのです。

シートはスプレッドシート型(EXCELライク)のものを使用し、依頼における5W1Hやステータスなどをカラムに設定し、案件ごとに記入します。表はわかりやすいように2階層ぐらいに分けて管理したほうがよいでしょう。

登録された案件にメンバーがアクセスして、顧客との会話あるいは内部メンバーとの連絡・確認を行って受付の許可を行います。

作法その3のポイント
・受付タスク管理はスプレッドシート型の管理表を使う
・5W1Hの観点で依頼内容などを記載する
・下流のオペレーションをする人もそこに参加する

2008年5月22日

業務プロセス設計作法 ~閑話休題(1)~

BPMとワークフローの違い

BPMというとよくワークフローとどう違うのですかと質問されます。今までは、まあ同じようなものですよと答えていました。ASPとSaaSの違いを聞かれたときも同じようにしていました。ただ、よく考えていくとどうもそれではまずいように思え、そこのところをきちんと整理しておく必要があるのではないかと考えたのです。

@ITに日本BPM協会の宇野澤さんが書いた「5分で絶対わかるBPMS」には、BPMSの機能として次の9つを挙げています。

・BPM実行エンジン
・プロセスモデラー
・シミュレーション機能
・組織モデラー
・ワークフロー機能
・ビジネスルール管理
・ソフトウェア開発
・システム連携機能
・プロセスモニタリング機能

このなかでワークフローという機能が出てきますが、簡単にいうとこの機能だけがワークフローにあって、それ以外の機能をもったものがBPMSであるとも言えます。

ただし、そうみるとBPMSがたくさんの機能を持っているように見えますが、必ずしも全部なくてはいけないかというとそうではありません。使う機能には段階があります。

最初に業務プロセスを作って動かすには、BPM実行エンジンとワークフロー機能だけあれば最低限のことはできます。

プロセスモデラー、シミュレーション機能、組織モデラーといったモデリング機能については、プロセスを最適化したり、プロセス変更をしたりする場合に用いられますので、ToBeモデルを書く場合に必要になります。

また、プロセスモニタリング機能はきちんとプロセスが動いてからの話でパフォーマンスなどを測定し改善につなげるわけです。ですからこれはもう少しあとに使う機能になります。そのほか、ビジネスルール管理は別のソフトがあったり、コメントしておくくらいで済んでしまう場合もあります。ソフトウエア開発はそのままフレームワークを使うだけでいいものがありますので、新たに開発はあまりしない方がいいと思います。

ワークフローとの違いの話に戻ると機能の違いというよりその形態の違いが大きいのではないかと考えています。

どういうことかと言うと、両者とも“単位業務処理”という箱をつないでフローにするという基本部分は同じですが、この箱の粒度が違うのではないでしょうか。

すなわち、従来のワークフローと呼ばれた業務アプリケーションはこの粒度が小さいものが多かったように思います。書類作成とか確認とか承認といったようなアクションレベルをつないでフローを作っているように思います。ですから比較的短いプロセス、例えば申請業務や書類の回覧といったものに適用されています。

ところが、BPMSはそうしたアクションレベルのものもありますが、それよりも粒度の大きいアクティビティのレベルを箱にしています。さらにもっと上の階層であるサービスや別のプロセスそのものをも対象にしています。

すこし乱暴かもしれませんが、本技法でいうミクロフローがいわゆる従来型ワークフローでマクロワークフローがBPMということかもしれません。

また、ワークフローは人や組織を意識しますが、BPMSはあまり意識しません。ここのところも違いがあるように思えるのです。(ここは誤解されそうですから後の作法で説明します)

ですから、SOAやSaaSといった概念にフィットするものとしてBPMSが評価されているのではないでしょうか。ここがBPMSとワークフローの大きな違いであると考えています。

単にフローを作るだけのワークフロー製品から業務プロセス、業務アプリケーションを構築する基盤としてのBPMSというような位置付けなのです。

先日のIBMのカンファレンスでも“ワークフローからBPA”というような言い方をされていました。BPAというのはBusiness Process Automationということなので自動化ということがワークフローとの違いであるといった感じで話していました。

ただ、自動化とひと言で言われても、手作業をIT化するのも自動化だし、プロセス全体を自動制御するのも自動化ですから、ちゃんと定義し、使い方を気をつけた方がいいと思います。ですから自動化というよりコントロール&オペレーションの概念が反映されてきているのがBPMだといった方がよさそうだと思っています。
 

2008年5月23日

業務プロセス設計作法 ~作法その4~

終点は最終的なアクティビティとなる書類です

この最終的なアクティビティというのは何のことでしょうか。以下の2つになります。

(1)依頼に対する回答
(2)ヒト・モノ・カネの出入り

ここの(1)の依頼に対する回答というのは、お客さんから依頼されたことに対して、報告や情報提供を行うことである。簡単な例では苦情が来てそれに対して回答するというのもひとつのプロセスになります。書類は「○○報告書」とか「回答書」のようなものが主なものになります。

(2)の場合が少し複雑でよく考えてみる必要があります。本来的には、企業にとっての最終アクティビティはカネにつながるものといっても差し支えないのです。モノを出荷するといってもそれが出荷したところで終わるわけではなく、最終的には代金回収して入金で終わります。例えば、出荷作業が完了して完了報告書ができ出荷履歴登録が終わると、代金請求を行い入金があってプロセスは完結します。

そう考えると大部分がカネになって終わることになるのでそこを最終的なアクティビティとすればよいのだが、それだとプロセスも長くなってしまい、見えずらくなるため、出荷(登録)といった区切りで切ることにします。別な見方をすると、例えば代金回収プロセスなどは上流が違っても共通的なプロセスになるので、モノとカネは別途独立させたほうが分かりやすいとも言えます。

このヒト・モノはカネと切り離してもいいのですが、そうすると何をもって終わりとするのかという問題があります。これは、DBの登録・更新をもって最終アクティビティとみなすことで対応します。

すなわち、前述したように出荷履歴登録などのようにデータベース登録の時点で中間点ではあるが、プロセスの終点ということにします。もう少手前で在庫で一旦終わらせるということもあります。この場合の書類は、「登録依頼書」とか「作業完了報告書」といったものになります。

これは、プロセスの終点は決算書(BS/PL)に繋がるものであるという見方をさしています。言い方を変えると、“勘定科目データ“を生成するためにプロセスがあると考えます。

作法その4のポイント

・終点は依頼への回答とヒト・モノ・カネの出入りで抑える
・DBの登録も中間点であるが終点とみなせる
・決算書のデータを生成するためにプロセスがあるという観点でみる

応援グッズ

自分のひいきのチームを応援するための応援グッズなるものがたくさんあるが、今日近くのスーパーで横浜ベイスターズのそれを見つけて、思わず買ってきた。

それはなんだと思いますか?砂糖です。スティックタイプのやつです。

その袋にREACH FOR THE STARSと書いてある。去年は缶ビールじゃあなかったけ?ぜんぜん勝てないから格下げかな。まあ、この砂糖を入れて力をつけてこれからがんばって欲しいと思う。

え、そりゃ甘い?!
 
BaySugar.JPG
 

2008年5月24日

4-2-3-1

ぼくは特に理由があるわけではないが、サッカー本はあまり読まない。でもこの「4-2-3-1 サッカーを戦術から理解する」(杉山茂樹著 光文社新書)は版を重ねていて評判がいいので買って読んだ。

これはたいへん面白かった。

サッカーの戦術、この本では布陣という言葉を使っているが、こうしたことを本に書いてみな理解できるのだろうかと思っていた。ところが多くの人が読み評価している。そういう意味では、サッカーファンの目も肥えてきたということかもしれない。昔はスター選手を追うことや選手起用法とか選手交替にはうるさくいっていたが、戦術的な話はあまりされていなかった。

ただそれはいたしかたないことで、どうしてかというと多くの人はテレビを見てあれこれ言うわけで、そうなると布陣がどうなっているのかとかはよく分からないのだ。実際の競技場に足を運んでスタンドから両チームの選手の配置や動きを見ないとわからないのだ。だから実際に観戦する人もずいぶん増えてきたという証左かもしれない。

この本の著者の杉山茂樹は有名なサッカー選手でもなく、ライターとして世界のサッカーを眺めている人で、それであるがゆえに、選手個人のプレーよりも全体を俯瞰できる目をもっているのかもしれない。彼の言いたいことを集約すると、

・戦術を具現化するためには、布陣というのが非常に大事である
・今は攻撃的な布陣が主流、かつてのイタリアのような守備的な布陣は嫌われている
・基本は数的優位をどこで確保するか、攻撃的ということはいかに高い位置でそれができるか
・サイドからの攻撃が絶対有利、強いやつには横から崩す

こうしたサッカーを欧州や南米の監督たちは知恵を絞って実現している。サッキ、ベンゲル、ヒディングなどの監督たちは非常に戦略的である。特に日韓ワールドカップで韓国を4位にし、ドイツワールドカップでは豪州を率いて日本を破ったヒディング監督の心憎い采配が記憶されるでしょう。

翻って、日本の歴代の監督、加茂周、トルシエ、ジーコはどうなんだろうか。著者によればみなけちょんけちょんである。オシムにしても疑問を呈している。

しかし、その指摘はなるほどと思われるので、ぜひ岡田監督にはこの本を読むことをお薦めする。さて、今晩のコートジボワール戦で岡田ジャパンはどう戦うのだろうか。
 

4-2-3-1―サッカーを戦術から理解する (光文社新書 343)
posted with yusukebe.com::AmazonSearch on 2008.5.24
  • 杉山 茂樹
  • 新書 / 光文社
  • Amazon 売り上げランキング: 185
  • Amazon おすすめ度の平均: 4.0
    • 3 重要な一面だが、サッカーはそれだけではない。
    • 2 これだけでは…
    • 5 これであなたもにわかサッカー監督に!
    • 5 システムの重要性
    • 5 戦術、布陣、日本のサッカー界とファンへ一石を投じる一冊
Amazon.co.jpで詳細を見る


 

2008年5月25日

息切れ

昨日のキリンカップのコートジボワール戦に日本代表は1-0で勝利した。前半21分に長谷部のセンターリングを玉田が倒れ込みながらのボレーシュートで鮮やかな先取点を奪うと後半は相手のペースになりながらも何とかしのいで勝利をものにする。

この試合昨日紹介した「4-2-3-1」という本の影響でつい布陣に目がいってしまったのと、サイドからの崩しができるかどうかが気になった。

で日本代表の布陣だが、4-4-2であったが、まずぼくが注目したのはツートップに大久保と玉田を起用したことだ。身体も大きくないがスピードのある二人をトップに据えたのだ。これは得点力不足解消のひとつの解のような気がする。

これまでの日本のトップは高原にしても巻にしても典型的なトップ型でそのためによくわかんないんだけど、「トップの選手に当ててそれから展開するんだ。だから、くさびのパスが大事だ」とか言われて、彼らにフィードするんだけど、屈強なディフェンダーにことごとくつぶされてしまう。

昨日の二人はそんなことができないから、ディフェンダーから一瞬のスピードで離れて、ゴールを背負うのではなく横にしてボール受けていた。そのためにゴールに向かうスピードが上がっていた。

このことは重要で前を向く姿勢が昨日は全体的に出てきたように思える。特に最近代表に加わった松井、長谷部、長友、玉田がその姿勢を強く見せていた。今までのチームはパス回しはするんだけど一向に前を向かいみたいなところがあって、それを相手からみると高い位置でボールを奪われてピンチを作るというのがよくあった。昨日も駒野や今野、遠藤が危ないバックパスをしていた。

おそらく岡田監督は意識的にそういう選手を起用しているように思える。だから、中村俊輔が入ったときにどうなるかが見ものではある。

それから、サイドでどれだけ高い位置を保てて数的優位ができるかどうかであったが、前半はできたが後半はだめという結果であった。得点のシーンなんか典型だがうまくサイド攻撃ができていた。ただこれは早いプレッシングがあってこそできるので元気がいいときはそれができたのだが、後半はばててしまい相手のペースになってしまった。

まあ、ここが課題なのだが、どうしたらよいのかである。口で言えば、目一杯ではなく少し余裕をもってプレッシングもサイドアタックもできるようにすることと、全力疾走を続けるのではなく、途中休んでまた全力でというようなメリハリのあるペース配分をすることなのだが、これは言うは易し行なうは難しというもので相手もあるし非常に難しい。しかし、方向性は間違っていないように思えるので経験を積むことで少しずつできるようになるのかもしれない。

日本代表も少し希望がわいてきた一戦であった。
 

骨が折れた

大変だったということではない。本当に骨が折れた、いや折れていたのだ。

昨日、あることで近くの医者に行ったのだが、念のために胸のレントゲンを撮っておきましょうということになり、1月の市の定期健診以来のレントゲンを撮った。

そうしたら、それを診た先生が「あれえ~、骨が折れてますよ、ほら」。ぼくもびっくりしてみると明らかに肋骨が折れていた。素人目にもはっきり折れてくっついているのがわかる。

「何かありましたか?」と先生。そうだ去年の3月21日に池袋であった柳家小里ん師匠の独演会の帰りに終電のモノレールに乗ろうと急いだため改札口手前で思いっきりこけたのである。その時しこたま脇腹を打ってしばらくの間、寝返りも打てなかったことを思い出した。(このことがこのブログに書いてあったので日付がわかるのだ)

おお、そのとき折れていたのだ。痛いはずだ。でも病院にもいかず、そのままくっついちゃったみたいだ。よくスポーツ選手なんか特に肋骨なんかしょっちゅう折れるがそれでも平気だというようなことを言っていたが、まさにそのとおりである。

しかし、よく考えてみると今年の一月にやった健康診断でも同じ胸のレントゲンを撮っているのに何にも言われなかったということはどういうことなのだ?
 

2008年5月26日

業務プロセス設計作法 ~作法その5~

コンテ(業務・仕事のあらすじ)を作ります

映画を作る場合、絵コンテというものを書きます。場面のイメージを絵にしてそこにコメントを入れて並べたものです。それでだいたいのストーリーとカット割がわかるようになります。いわば映画の設計図のようなものです。

業務プロセス設計においても、これと似たようなものを作るとプロセス全体がどのような構成になるのかが理解できるようになります。業務・仕事のあらすじが表れてきます。

コンテの一枚には、「何かを受付けて、何かを決めて、次に依頼する」という事柄を書きます。これら動作のつながりが全体のコンテとなります。ここで決めるということは、あるデータを確定するというように置き換えて考えたらよいでしょう。

一番最後は“依頼する”ではなく、“登録・報告する”となります。

また、この時点でわかっている参照情報や連携サービスあるいは分岐についても書き出しておいてください。ただし、これはそれほど厳密なものである必要はありません。詳しくはそのあとの書類作成のところで見ていきますので気がついたものを記しておくといったことになります。

あくまで全体感と流れを把握することを目的にしていますので、細かいことより、一枚一枚のコンテの粒度の統一感や連続性を考えて作成することが肝要です。

なお、簡単なプロセスであればこれからすぐに業務フローが書けてしまうケースもありますので、超簡便法としてやっていってもかまいません。

作法その5のポイント

・映画の絵コンテのようにコンテを書くことで全体感をつかむ
・受付-確定-依頼という動作の連なりとして表現する

%E4%BD%9C%E6%B3%95%EF%BC%88%E5%9B%B3%EF%BC%89%E3%82%B3%E3%83%B3%E3%83%86.JPG

2008年5月27日

業務プロセス設計作法 ~作法その6~

最終書類の必須データ項目を依頼に対する答えとしてリストアップします

各書類に関連するデータ(属性値)については、最終書類で必要となるデータ項目から遡って決めていきますので、順序としてはまず最終書類のデータ項目のリストアップをおこなっていきます。

最終書類のデータ項目というのは、最初にあった依頼に対する答えとして存在します。すなわち、簡単な例で言うと、お客さんの問い合わせの回答のようなものです。ここでは、必須データだけをリストアップします。あったらいいなというようなデータ項目は排除しておきます。ちなみに、そうした参考情報は書類の説明文のなかに入れることになります。

まずは、依頼された内容に対して最終的に登録・報告すべきデータ項目を確定します。このときの項目抽出の考え方は、顧客視点と決算へのつながりという意識で見ていきます。お客さんが望んでいる答えになっているかという吟味をします。また、BS/PL(特にPL)につながっているものであるのかどうかというチェックが必要になります。

こうした観点での検討は、後の作法にも出てきますが、「目的合致性」や「プロセスの一貫性」などのチェックとも関係してきます。すなわち、このプロセスは最終的に何をアウトプットとして出そうとしているのか、なぜそれが必要なのか、無駄なアウトプットになっていないかという風にみていくことが大事です。

作法その6のポイント

・データ項目の洗い出しは最終書類のデータ項目の確定から始まる
・必須データだけをリストアップ
・顧客視点と決算つながりの視点

キサラギ

密室推理劇というので興味があったので「キサラギ」を観る。監督がテレビ出身の佐藤祐市、この手の映画は脚本が大事なので、脚本は「ALWAYS 三丁目の夕日」の古沢良太。

結論的には面白かった。脚本がよくできている。多分シナリオを考えていたとき楽しくてしょうがなかったんじゃないかと思われる。あれやこれやアイディアを出して、それをつなぎ合わせてストーリーをつくるのは、こうした映画では非常に重要であると同時につぼにはまってくると面白くなると思う。そんな風にしてできた映画だ。

物語は如月ミキというアイドルは死んで1年経つのでその追悼式をやろうという。集まるのがその熱烈なファンである掲示板で書き込みをしていた男たち5人がリアルにはじめて会うところから始まる。

そして、お互いの素性がばれていくとともに謎が解き明かされていく。物語の進行とともに期待感がふくらみ、またひっくり返されたりと飽きることなく見入ってしまった。

こういった密室劇だと「12人の怒れる男」が有名だが、それに比べるとぜんぜん売れなったアイドルのファンの集まりを舞台にしているため、格調は高くはないが面白さは出ていたのでいいんじゃないのとかばってみる。

最初、ネットの掲示板で知り合って初めてリアルに会うということなので、いわゆる「オフ会」のことを想像したがちょいと違うようだった。

しかし、こういう何ていうかある種のゲーム的な映画というのもあっていいと思うのだがいかがでしょうか。
 

キサラギ スタンダード・エディション
posted with yusukebe.com::AmazonSearch on 2008.5.27
  • DVD / キングレコード (2008-01-09)
  • Amazon 売り上げランキング: 744
  • Amazon おすすめ度の平均: 4.5
    • 5 奇跡のワンシーンムービー
    • 4 前評判を裏切らない
    • 5 めっちゃ面白い!!
    • 5 民間放送でこの映画は放映できるんでしょうか?WOWOWならあいますが・・・
    • 4 キサラギ☆
Amazon.co.jpで詳細を見る

 

2008年5月28日

業務プロセス設計作法 ~作法その7~

コンテに従って確定データを中心に終点から遡って中間書類を作っていきます

コンテに従って書類を起こしていきますが、終点すなわち最終書類から遡って書いていきます。この前の作法で最終書類のデータ項目が特定されましたが、そこから出発していきます。

始点と終点の間の中間書類は、最終書類のデータに徐々に追記されていくイメージとなります。すなわち、最終書類の一つ手前の書類ではどうなるかというと、最終書類で確定すべき未確定データだけが残ったものということになります。

このように後ろから遡りながら中間書類の書類名、確定すべきデータ、連携サービスなどを決めていくことになります。必ず後ろからでなくてはいけないということではありませんが、ひとつの書類で原則ひとつのデータを確定していくという考え方ですので、最終的なデータ確定に至るにはひとつ前では何が決まっている必要があるのかというようにみると逆流方式のほうがわかりやすいのではないでしょうか。

ここでひとつの書類でひとつのデータを確定するといいましたが、必ずしもそうでない場合があります。例えば、見積を決めるとき数量と金額は一緒にするとかということがあります。そのとき、同じメンバーで同時に決定していくのであれば、複数のデータ確定をひとつの書類で行ってもかまいません。

作法その7のポイント

・中間書類は最終書類から遡って書いていく
・中間書類は確定データを中心にみていき、データを追記していくイメージとなる
%E4%BD%9C%E6%B3%95%EF%BC%88%E5%9B%B3%EF%BC%89%E3%83%87%E3%83%BC%E3%82%BF.JPG

岡田の戦術は?

サッカー日本代表の岡田監督はちょっと前に紹介した「4-2-3-1」(杉山茂樹著 光文社新書)を絶対読んでいる。昨日のキリンカップパラグアイ戦の布陣は4-2-3-1であった。

4-2-3-1というのは今最もポピュラーな陣形で、従ってそれが本の題名のもなっているのだが、日本ではこの布陣はあまりみない。昨日は巻をワントップにその下に中村俊輔、山瀬、遠藤の3人が並んだ。

さてこのシステムは機能しただろうか?

試合結果は0-0のスコアレスドローであった。パラグアイの巧妙な守備力に押さえ込まれたという感じである。南米のサッカーってつい攻撃に目がいってしまうが、実は守備力のレベルが非常に高い。要は守備でも高い技術力がいるってことなのである。

4-2-3-1が機能するための要件は、サイドをつけるかということと、2列目の3人がどれだけシュートを打てるか、ペナルティエリヤに入り込めるかにかかっている。そう意味で言えば合格点はあげられない。

特に得点への絡み方には不満が残る。唯一山瀬がゴール前で絡んだくらいで、俊輔、遠藤、後半の松井にしても、それができていない。確かに俊輔のテクニックとパスはすばらしいし、遠藤のバランサーとしての能力はすごいのだが、得点を奪うという鋭さが弱いのである。

そして、もうひとつ試したのがバックスの4の右サイドに阿部を起用したことである。これは多分、相手の出方で4バックと3バックをスイングさせるやり方をためしたのではないだろうか。ただその役割が阿部なのかどうかという問題がある。これがうまくできる選手が現れてほしい。

ここで前のコートジボワール戦との対比をしてみると、あの試合は玉田、大久保のツートップで戦ったわけだが、相手が違うので一概には言えないけど、あのシステムの方が機能したように思える。

昨日も時折、球回しが目的のパスや何のためのくさびかわからないフィードなど、旧弊がちらっと見えたので、もう徹底してこの間のコートジボワール戦前半のようなキュートなサッカーをやっていって欲しいと思うのである。
 

2008年5月29日

業務プロセス設計作法 ~作法その8~

中間書類には誰が何を参照して何を決めるかを書き、連続性のあるものにします

さて、中間書類には何を書いてどんなルールがあるのでしょうか。コンテのところでも書きましたように「何かを受付けて、何かを決めて、次に依頼する」というのが一枚の書類のなかに収まり、それらの連なりで業務プロセスを表現していくことがこの技法の大きな特徴です。

その書類に書くものは基本的には次のようなものになります。

 ・決めるべきデータ
 ・登場人物 ・・・確定(書類作成)する人/アドバイスする人/確認する人/承認する人
 ・連絡・調整先 ・・・どこの部署の誰に連絡するか(と調整するか)
 ・参照情報 ・・・何を参照するのか、その情報名とどこにあるか
 ・分岐 ・・・分岐があったらそのタイプや行き先、判断条件
 ・連携サービス ・・・連携するサービス名とやり取りする情報

次に大事なのは、連続性ということで、書類は依頼と受付で取り合うので前の書類の依頼内容が次の書類の受付内容と一致していることが必須です。

また、処理がひとつの書類で完結していることも大事で、単なる確認や連絡のような処理は対象とはならないということです。言い換えれば、書類の中でデータを確定していくということが書類を作成・発行することにあたります。従って、データを確定していない書類は作ってはいけません。そうした確認や連絡などのアクションは書類の中の会話などで表現されます。

作法その8のポイント

・書類に書くものは、決めるべきデータ/登場人物/連絡・調整先/参照情報/分岐・連携サービス
・前の書類の依頼内容が次の書類の受付内容と一致していること
・処理がひとつの書類で完結していること
 

いちばんやさしいオブジェクト指向の本

これは技術SE新書から出た井上樹さんが書いた本である。なぜこのような本を読んだのか。もちろんオブジェクト指向は知っていいる。ネットで調べて知っている(つもりになっている)。オブジェクト指向をやってきた人も知っている。セミナで聞いたこともある。

でどうして本を買って読もうと思ったのか。社長(息子)と話していて、おとうさんオブジェクト指向勉強したほうがいいよみたいな言われ方をされたこともあったのと、もうひとつは今使っているSAVVIONというBPMソフトウエアを作ったDr. M. A. Ketabchiがもともとオブジェクト指向のエキスパートであったということからである。厚い本を読んでもなかなか難しいのでこういう本はうれしい。

でオブジェクト指向がわかったのかと言われると、半分わかって半分わからないというのが正直なところだ。

オブジェクトとは「ある場面において個別に識別できる重要な何か」で、オブジェクト指向とは「ある場面をオブジェクトの集りとして表わすこと」、うんうんなるほど。「オブジェクト指向で登場する重要な概念はたった二つ、「オブジェクトとメッセージ」、うんうんわかるわかる。「オブジェクト指向で世界を理解する。オブジェクト指向で世界を創造する」、ほおー、そうなのか。

ところがどうも食い足りないのだ。結局どういうことかというと、端的に表れているのが最後の章にQ&Aが出ているのだが、それが象徴的なので紹介する。問題は、Qがなかなか的を射ているのだが、答えが外れているということなのだ。

Q:オブジェクト指向で分析・設計すると何が嬉しいのですか?
A:現実世界をオブジェクト指向でモデル化すると、それをプログラミング言語で書けることです。

Q:本当に現実世界をそのままモデル化できるのですか?
A:オブジェクト指向分析で「現実世界をモデル化する」といっても、現実世界にはさまざまな側面や情報があるので、それをすべてオブジェクトで表現しようとすると、オブジェクトの持つ属性や状態や操作は、考えれば考えるほど際限なく出てきてしまいます。そのため、モデル化を行なう際には、現実世界から必要な部分だけを抜粋してモデルに取り込んでいくことになります。

Q:オブジェクト指向では「シームレスな開発ができる」と聞きましたが、これはどういう意味ですか?
A:オブジェクト指向分析から実装までは、一貫してオブジェクト指向で行なわれます。一貫して行なわれることで、各工程でモデルに連続性が生まれ、工程間のギャップが少なくなくなり、トレーサビリティが高くなります。この効果を称して、「シームレス開発ができる」という言い回しが生まれました。中略。
ただし、どんな開発であろうと、分析と設計のあいだには、目的の違いが厳然として存在しており、目的を達成するためのアプローチはまったく異なります。ですので、それを一緒にできるということはありませんので、気をつけてください。

最初半分わかって、半分わからないといったが、その半分わからないのがこのQAのところである。どうしてわからないかということについて書評ではなく別なエントリーで記すことにする。

いちばんやさしい オブジェクト指向の本 (技評SE新書 007)
posted with yusukebe.com::AmazonSearch on 2008.5.28
  • 井上 樹
  • 新書 / 技術評論社
  • Amazon 売り上げランキング: 7104
  • Amazon おすすめ度の平均: 3.5
    • 4 いちばんやさしいとはいえども
    • 2 誰にでも理解は無理な気も。。。
    • 3 パーソナリゼーション
    • 3 基本を押さえた良書のひとつ
    • 5 オブジェクト指向の基本的な構想、仕組みがイメージできます。
Amazon.co.jpで詳細を見る



2008年5月30日

変な表現

巷で変な表現を見かけることがある。
一見すると何でもないように思えるのだが、よくよく考えるとちょっと変だというものである。


hanbaichu.JPG
たくさん品物があるのならいいが、決め打ち物件に対して、”好評販売中”というのもおかしいですよね。 
 


toire.JPG
通報されるから吸うなではなく、火事になるから吸うなじゃないのか。 
 

業務プロセス設計作法 ~閑話休題(2)~

プロセスコントロール&オペレーション

前回の「閑話休題(1)」に出てきたコントロール&オペレーションということです。この概念がBPMの大きな特徴であると考えています。これもなぜ“作法なのか”にも書いたことで再三の繰り返しで恐縮ですが聞いてください。

化学プロセスも同じプロセスという言葉を使いますが、そこではプロセスコントロールとオペレーションということが重要視されています。自動制御も行われています。また、シミュレーションにしても工学的なアプローチが行われていてかなり高度な取り組みがなされています。新日鉄の高炉の制御技術が金融工学に応用されて成果をあげている例も有名でご存知の方もいらっしゃると思います。

実は、化学プラントや鉄鋼の高炉、石油精製などにおけるこうしたコントロール&オペレーションの考え方は、ビジネスシステムにも応用されるはずだと思っています。

ではどうして今まで関連性がなかったのでしょうか。それはまずは企業情報システムにおいてプロセスという概念が乏しかったことがあります。EDP(Electric Data Processing)と言ってもプロセスではなく電子データ計算処理のことだからデータを登録して集計するというシステムが主体であったのです。

そこで、BPMというプロセス概念を入れた考え方が登場したわけですが、従来の考え方の延長で見ていると単にデータを登録するためのフローでしか捉えていないということになってしまいます。

プロセスをコントロールして、オペレーションするという管理を適用してこそプロセス化した意味があります。よく可視化とか見える化とか言いますが、単純に見えるようにしてもたいした意味がありません。それらを事業に貢献できるようにコントロールして、継続させる、発展させることが重要になります。

ところで、IBMが言っているような自動化の段階にもっていくのはそう簡単なことではありません。そのための要件があります。(この自動化という表現は、前にも書いたように気をつけた方がよくて、ちゃんと定義しないといけない。これについては別のエントリーで書く)

それはこれも再三申し上げていますが、“人の要素を排除する”ことです。工学的なレベルに近づけようと思ったら、あいまいさは邪魔になります。おわかりのように人間の介在はあいまいさをもたらします。

ですからポイントは、人間を排除した形のプロセスを作れるかになります。そして、化学プロセスの単位操作にあたる業務アクティビティ(コンポーネント)に人間が入らないものにすればいいのです。ここに書類コンポーネントを組み合わせてフローにするという意味があります。こうした粒度設定にしない限り、正しいBPMは実現できないということがおわかりになったでしょうか。

ただし誤解しないで欲しいのは、人間を排除するといってもマクロのワークフローのところでの話であって、正確にいうと排除ではなく、別の適当な場所(ミクロワークフロー)に移すということですので間違えないようにお願いします。
 

2008年5月31日

金雲富士

この季節になると富士山を見ることができなくなる。そんなわけで、今は毎日、絵に描かれた富士山を眺めている。

先日、日本画家の坂本武典さんからいただいた「金雲富士」である。表題のように金色の雲のなかにそびえる富士山を描いたものである。坂本画伯は熱海在住なので富士山の絵が多く、みなそれぞれ素晴らしいものです。

この絵は、坂本画伯のホームページをうちで制作して運用しているのでその御礼でいただいたものである。

仕事の手をちょっとやすめてながめているとほっとします。それよりなにより夜でも富士山が見られるというのもいいものです。

kinunhuji.JPG
 

About 2008年5月

2008年5月にブログ「mark-wada blog」に投稿されたすべてのエントリーです。新しい順に並んでいます。

前のアーカイブは2008年4月です。

次のアーカイブは2008年6月です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type