« 2010年7月 | メイン | 2010年9月 »

2010年8月 アーカイブ

2010年8月 1日

情報システムについての誤解

ITproに連載された記事でいつも感心し参考になるものに「ダメな“ユーザー企業”を叱る!」というのがある。前シリーズ「ダメな“システム屋”にだまされるな!」も好評ですぐに書籍になった。著者は佐藤治夫さんで、元野村総研にいてその後スタッフサービスのCIOを務めた人である。

実は、ぼくはその佐藤さんを知っている、というか佐藤さんが野村総研時代に一緒に仕事をしたことがある、というか正確に言うと仕事をしそうになったことがある。あるプロジェクトの依頼先の一つだったが、残念ながら最後の最後でうまくいかった。その時の対面にいた佐藤さんとのおつきあいはおもしろいものであった。

話はそのことではなく、つい最近書いた記事についてである。その記事は、「日本の国民性は情報化に向かない?」と題したもので、その「“シロウト”が情報システムに口を出す」というくだりのところでちょっとひっかかるものがあった。そこにはこう書いてある。

例えば、自動車産業を見た時、クルマの機能、性能、デザインなどについて“シロウト”が何かを言っても、そのまま製品開発に反映されることはありません。安全性、快適性、工場での生産性など、シロウト考えでは及ばない観点があります。ですから、利用者も自動車メーカーも監督官庁も、みんな“プロ”の技術者に任せるべきだと考えています。  一方で、情報システム産業を見た時、情報システムの機能、性能、デザインなどについてシロウトに大きな発言力があります。安全性、信頼性、開発・保守の生産性など、シロウト考えでは及ばない観点・・・かと思いきや、“ユーザー企業”の中の権力者が「私は聞いてない」「自分は反対だ」「おれは責任を持たない」と叫べば、それまでの検討内容はどうにでも曲げられます。  日本では、プロであるはずのシステムエンジニア(SE)という名の技術者が、その資質を持たないことも多く、これが“ユーザー企業”の中の権力者が幅を利かす根本要因になっています。
ここに書かれていることは比較的よく言われることでもあるのだが、何が気になったかというと、“クルマ”をつくることと“情報システム”をつくることは同じなのかということである。どうもこれは誤解ではないだろうかと思う。

つまり、情報システムはクルマではないのであって、クルマに相当するのは「ソフトウエア」や[ハードウエア]、何とか「パッケージ」までではないだろうか。情報システムとはそうしたソフトウエアやハードウエアを使ってつくるシステムなのであるからちょっと違った意味である。ソフトウエアを作るには”シロウト”はやはり口は出しません。

逆に、クルマの例で見ると、情報システムに似ているのが、クルマを使うバスとか、運送とか、宅配や引越システム、土木作業、タクシーなどのシステムのことに相当すると思う。手段とそれを使ったサービスシステムという区分けがあるように思うのである。

そう考えると違う景色が見えてくる。情報システムは企業では業務システムと言い換えてもいいので、その業務システムを構築するということは、クルマを作る人とそれを使ってサービスを作る人は明確に分かれているように、サービスを作る人が担うものです。

ところが現実には、SEと言われている人たちは、自分たちの仕事はクルマを作ることだと思っている。佐藤さんも勘ちがいしている。だからそこでサービスシステムを作りたい“ユーザー企業”の中の権力者との齟齬が生じるというわけである。何を作るのかがかけ離れているのだからこんなことになる。

とりわけSIerと呼ばれている業界の間違った常識が一向に改まらない限り日本のIT業界の不幸は続く。ソフトウエアとかツールを作ることとサービスシステムを作ることは全く違うことを早く気がついてほしいものだ。だって、トヨタやホンダは日本通運にもならないし、クロネコヤマトにもならないのだから。

ダメな“システム屋”にだまされるな!
posted with yusukebe.com::AmazonSearch on 2010.7.30
  • 佐藤 治夫
  • 単行本(ソフトカバー) / 日経BP社
  • Amazon 売り上げランキング: 59987
  • Amazon おすすめ度の平均: 5.0
    • 5 身につまされる想いがあります
    • 5 全てのシステム屋システム開発企業経営者は一読を!
Amazon.co.jpで詳細を見る

   

2010年8月 2日

間違いだらけの業務システム開発-はじめに

このブログを書き出したのが、2006年8月からなので4年間書いたことになる。その中でITについての記事がおおよそ3分の1を占める。いまこの間に書いたものを振り返ると現状で問題があることを繰り返し述べていて、それを変えていかなくてはいけないという主張に染まっている。

ということは、いま行われている業務システム開発と呼ばれるものは間違っていると言っているに等しい。いやちゃんとやっているという人もいると思うが、概して問題ありと感じている人の方が多いと思う。そこで、これまで書いてきたものが主で新しい指摘は少ないかもしれないが、「間違いだらけの業務システム開発」と題して、様々な角度から常識を疑う目をもって考えてみたいと思う。

はじめに指摘すべき最も重要かつ基本的な問題は、ビジネスありき、事業ありきというベースが欠如しているということを挙げておきたい。何も考えていないわけでもないだろうから、欠如というと言い過ぎかもしれないので、そういう意識が薄いとでもしておく。

ビジネスありき、事業ありきは当たり前でしょうとみなさん言うと思いますが、ほんとうにできていますかということです。頭の片隅においておくだけじゃ何もならなくて、開発プロジェクトの目的にしても、開発方法論にしても、この考え方を取りこんだものになっているかということである。少なくとも現実のビジネスの実相を反映したものにおちているとは言い難いと思う。

この根本的な立ち位置が間違っている可能性がある。「役に立たない正しいシステム」を作り続けてはいないだろうか。ビジネス上のメリットを生み出しているのだろうか、事業に貢献できているのだろうかが問われなければいけない。先進の技術を使うことで終わっていないだろうか、はやりのクラウドにすればやることはやったと思っていやしないだろうか。

ビジネス上のメリットを生み出す、あるいは事業に貢献するためにはどういう仕組みが必要なのかと考えたとき、最初に浮かぶものはITシステムではないということを肝に銘じなければいけません。極端な例でいえば、起業してすぐのベンチャーで商品がバカ売れしているような場合に、社長一人で全部やれているうちはそれが最良なシステムかもしれないのだ。

ということで、いちばん最初の間違いは、システム化の必要なあるいはシステム化を検討する場合の立ち位置である。ITだけの導入が前提ではなく、その会社の事情(規模や成熟度といってもいいかもしれない)によって、ビジネス上のメリットや事業に貢献できるにはどのようなシステムが必要なのかという思考アプローチが肝要なのに、何でもITシステムを入れればいいのだというスタンスのことである。

次回からは個別の局面における間違いについて考察していきます。

2010年8月 3日

街場の小経済学その10

先日、茨城空港に中国の春秋航空という会社の便が就航した。何と上海―茨城を片道4000円という席もあるという。徹底的にコスト削減をおこない、そうした低価格が実現したという。こうなると、ちょっと日本まで遊びに行ってくるわという感じになる。

そのかわり、機内のいろいろなサービスは有料だそうだ。食事はなしで、水を飲むのにもお金がかかる。しかし、それでもいいというお客の方が多いはずで、むしろこれまでのように必要ないサービスまでついてくるという方がおかしのだ。

機内食だって、狭い座席で窮屈な思いをして食べてもそんなにうまくない。酒やドリンクだって、タダだからって飲みすぎて倒れるやつもでるっておかしいでしょ。だいいち、飲むやつと飲まないやつがいたら不公平です。サービスが均等にできないのに全部を航空運賃に均等に入れて、個別サービスを無料にすることが変なのである。

アメリカの国内の飛行機もバスみたいなもので、スチワーデスもいわばバスガイドなわけで、過剰なサービスがない機能性重視の交通手段なのである。昔は飛行機に乗るのがステータスシンボルであったが、今や単なる移動手段となっていると思う。従って、これから、先の春秋航空のような低価格路線が増えてくるのは間違いない。

春秋航空の乗務員のコストが日本の航空会社の10分の1だそうだ。操縦士のコストも3分の1らしい。これじゃあ、JALが今からどうがんばっても追いつかない。やっぱり生き残れないかもしれない。

2010年8月 4日

間違いだらけの業務システム開発(プロジェクト編その1)

システム化プロジェクトは開発するもの

前回は、はなからITシステムを入れるということではなく、それぞれの会社の事情や成熟度に応じて、場合によってはITを使わないでシステム化をする方がいいケースもあるというようなことを書いた。ここでは、システム化プロジェクトで開発をしてしまうという間違いについての話です。

こう言うと、怪訝な顔をする人も多いと思います。だれしもが、普通に”システム開発“と言います。しかし、業務アプリケーションのことでいえば、業務の仕組みを開発するのですかとツッコミたくなる。ソフトウエアやツールであれば確かに開発ですが、業務の場合、開発するとはいったいどういうことなのだろうか。

そのまま字句通りに解釈すると、業務の仕組みあるいは業務プロセスをそうしたプロジェクトで開発すなわち新たに作り出すことを意味する。そんなことをシステム化プロジェクトでやるんですか。そもそも何とか管理システムの開発プロジェクトというような言い方がおかしい。いや、今までと違うプロセスや機能を盛り込んでいくからやはり開発でしょうと反論がくる。

しかし、よく考えてみてください。そんなことをITベンダーと一緒にやりますか。ここには二つの感違いがある。一つは、業務プロセスはITプロジェクトとは関係なしにビジネスサイドで開発しておくものであるということです。しかも、どこの会社にも業務プロセスはすでにあって(もちろん手作業でやっていたとしてもプロセスです)、それを事業という観点で変えていくわけです。新しいビジネスモデルの創出ということです。

もうひとつは、IT側で業務の仕組みを“開発”してしまうこともあるということです。これは最新の機能を盛り込んだ営業システムですからそれに変えた方がいいですよとなる。別に現状業務を分析してこうしたほうがいいという結果がでていなくても、カッコよくこれはベストプラクティスですからとか言って変えてしまうのです。

ですから、システム開発ではなくシステム構築の方がなじむように思います。家を建てるときでも、家を開発するとは言わないで建築するというのと同じです。このことは、そんなに厳密なことを言わなくてもいいじゃないか思うひともかなりいるかもしれませんが、思った以上に影響があると言いたいのである。

システム化のプロジェクトに入ったら開発してはいけないのだ。家を建てるのと同じように、ユーザの活動スタイルにあわせて設計されたものをそのとおりに組み上げるというのが望ましい姿である。へたに開発しようとするから、仕様変更が、そして手戻りがおきるのである。
  

2010年8月 5日

ネットがあれば履歴書はいらない

ご存知佐々木俊尚さんのネット社会で生きるための本「ネットがあれば履歴書はいらない」(宝島社新書)である。「仕事するのにオフィスはいらない」(光文社新書)の続編みたいな内容である。

要するに、ネットのブログやツイッタ―で自分のプロフィールから様々な意見を発信していれば、それを見ることでその人の人となりがわかるから、わざわざ履歴書なんて書かなくてもいということらしい。

こうした話はウエブサービスをやっている会社なんてとっくにそうなっていて、技術者は自分の情報発信のサイトはもちろん持っていて、そのほかにコミュンイティに所属してそこでも発言しているから、どのくらいのスキルレベルなのかはすぐにわかる。だから、しょっちゅう会社間を移動する。

それはそれでいいことだと思う。自分のスキルレベルややりたいことにマッチする会社あるいはプロジェクトをみつけるか、みつけてもらうという働き方である。それが、そうした一部の技術者だけではなく、もっと広がってきているという。そのために必要なのは、セルフブランディングとかエゴサーチなのだそうだ。

エゴサーチという言葉はあまりなじみがないが、グーグルやヤフーなどの検索エンジン(そのうちヤフーはグーグルになってしまうが)で自分の本名やペンネーム、ハンドルネームなどを検索して、ネットで自分がどのように見られているのかを調べることなのだそうだ。

なぜ、そんなことが重要かというと、徐々に一般の企業の人事担当者がこのエゴサーチをすることが増えて来ていることにある。こうしたエゴサーチに引っかかってもらうには、ちゃんとセルフブランディングをしておく必要があるというのだ。

そして、このセルフブランディングをするためのウエブサービスが紹介されていて、Gmail、ブログ、SBIビジネス、フレンドフィールド、ツイッタ―、タンブラー、Firefoxなどである。ぼくもほとんど利用しているが、何といって最近ではツイッタ―でしょう。

ただ、こうしたサービスを利用すればいいという話ではなく、一番大事なことは発信している情報がどれだけ役にたつのか、他の人たちが知りたがっていることなのか、おもしろいと感じてくれるのかということである。それには、自分のオリジナルな考え方とか感じ方をもたないと誰にも相手にしてもらえないのである。これは、ネットでもリアルの世界でもまったく同じこともあるのだ。
  

ネットがあれば履歴書はいらない-ウェブ時代のセルフブランディング術 (宝島社新書)
posted with yusukebe.com::AmazonSearch on 2010.8.4
  • 佐々木 俊尚
  • 新書 / 宝島社 (2010-01-09)
  • Amazon 売り上げランキング: 19976
  • Amazon おすすめ度の平均: 3.5
    • 3 ネットは履歴書とはちがう ?!
    • 4 ツイッターがあれば履歴書はいらない
    • 4 ツイッター、SNS、ブログを個人の営業ツールに変える
    • 3 そのまま実践できるか?
    • 3 フリーランスの人とか向けかも
Amazon.co.jpで詳細を見る
  

2010年8月 6日

鴨川ホルモー

なんとも変てこなタイトルである。鴨川は京都の鴨川なのだが、ホルモーは意味不明で、競技のことなのか、でもなんか最後に叫ぶ言葉でもある。そんなおかしな映画「鴨川ホルモー」を観る。万城目学の同名の小説を本木克英が監督した。

物語は京都大学に2浪で入学した山田孝之扮する冴えない学生が、青竜会というわけのわからないサークルに誘われ、最初は胡散臭そうにみていたが、ご多分にもれず可愛い女の子につられて入会してしまう。

それからが、このサークルの実態が徐々に明らかになるのと、その可愛い彼女との恋愛ごっことそれに割り込む栗山千明が演じる独特の雰囲気の女子学生もからんでドタバタが始まる。ホルモーというのは、鬼を戦わすという変な競技でよくわからないが、CGでつくったキャラクターが可愛い。

まあ、言ってみればキャンパス映画なのであって、サークルが奇妙なだけでそこで繰り広げられる恋愛や友情、自立していく様などは普通の青春映画である。このあたりは、いつの時だでも、あるいはどこでも変わらない青春がある。

それにしても変てこな映画だが、こういうハチャメチャを楽しむ心根は忘れないでいたいものだ。くだらないと言ってしまえばそれまでなのだが、たまには破目を外したくなる時があるように、何にも可も忘れて笑い転げるのもいいものだ。

出演している、山田孝之、栗山千明の他にも、荒川良々や濱田岳、石田卓也、芦名星などいい味を出している。最近、こうした若い俳優さんが健闘している。時々、2世だと思うがひどいのもいるが、概して個性的でいきいきしてたのもしい。
  

鴨川ホルモー [DVD]
posted with yusukebe.com::AmazonSearch on 2010.7.25
  • DVD / ポニーキャニオン (2009-10-07)
  • Amazon 売り上げランキング: 11965
  • Amazon おすすめ度の平均: 4.0
    • 4 好き嫌いが別れる? (内容の記載あり)
    • 5 原作も映画も面白い。
    • 2 原作本の方がかなり面白かった!!映画は肩すかしです…
    • 3 これはあの漫画の良い所どりなのでは…
    • 5 山田ー
Amazon.co.jpで詳細を見る
  

2010年8月 7日

ツイッタ―再考

ツイッタ―については、その良さや有用性がよくわからなくて、あまり使っていない、というかほとんどつぶやいていない。有名人ならその知名性から多くのフォロワーがついてくれるし、つぶやけばすぐに反応してくれる。ところが、ぼくみたいな無名人がいくらつぶやいても誰も相手にしてくれない。そんもののどこがおもしろいのかと冷ややかな目で見ていた。

さらに、SNSだとか掲示板だとかであまりいい思いがなかったこともある。掲示板なんかで反応が返ってくるのはいいのだが、うれしいものがある反面、明らかにチャチャを入れたり、反対することに生きがいを感じるような、斜に構えた批判的な人がいる。だから、そんなコメントに接するたびに気分が悪くなるから投稿もしないし、見もしなくなった。

ところが、最近気がついたのはSNSとか掲示板と全然違うということである。何が違うかというと、基本的に双方向のコミュニケーションではないことなのだ。ぼくは以前にWeb2.0の特徴あるいは良さの一つが双方向コミュニケーションであると言ったが、その双方向性が故に功罪合わせ持つのだ。

しかし、ツイッタ―はもちろん双方向のコミュニケーションも行うのだが、それで成立しているわけではなく、単方向の組み合わせという程度なのである。このゆるさが、爆発的な人気を呼んだのでハないかと思う。言いっぱなしでいいので斬り合わずにすむのである。従って、匿名の必要性が薄くなり実名でも恐くない。

ただ、ではフツーの人はいったい何のためにツイッタ―をつかうのだろうか。天気がいいとか、うまいものを食ったとか、そんな私的な日常性をつぶやいたところで誰も見向きもしないわけだし、仲間同士の会話であっても、それならメールや電話で十分だろうという話である。

かろうじて、ネット上あるいはメディアで話題になったトピックスについてつぶやくのが最低限の表現かもしれない。これとて、ぼくはしょせん“リアクション芸”であると言っているのだが、何かツッコミがあってはじめて成立するものだと思う。

次が、ある特定のジャンル、たとえば趣味のこと、音楽やスポーツのことなどに絞ることでしょう。ただこれとて、単につぶやくだけではその発信の価値は低い。結局、自分のオリジナルの考え、思い、知識、経験といったものを発信している場を裏で持っているということが大切のような気がする。

そういう意味で、ツイッタ―とブログはどちらか一方と言うのではなく、両方の組み合わせというのが望ましいのではないでしょうか。ツイッタ―がブログへの“呼び水”になるという位置関係のことです。と言いながら、ツイッタ―はマメじゃないとできないようで、どうもぼくのようなズボラな人間は使いこなすにはけっこう時間がかかるようなのである。

2010年8月 8日

年寄とこどもにしわよせ?

先週の木曜日の夜にぼくの姪が出産した。予定日が7月27日だったから10日ばかり遅く生まれた。3200gの元気な女の子である。早速、ぼくの携帯に産婦の母親である姉から写真が送られてきた。姉も初孫なので大喜びである。うちのばあちゃんにとっては曾孫である。

こうした新しい命の誕生はやはりうれしいもので、みなで無事に大きくなれと願う。そして、そのために親はありったけの愛情を注いでやれよと思うのである。これは古今東西営々と続けられたことだと思うのだが、それを覆すような事件が起きている。

3歳と1歳のわが子を家に閉じ込めて遊びほうけたため、2人を死なせた母親が逮捕された。何ともやるせない思いである。一方で人が生まれ一方で生まれた子を殺す、そして子どもが欲しいと願いながらも叶わない夫婦がいる。不条理な世の中だがそれが現実である。

また別な相を眺めてみると、100歳以上の高齢者の所在不明者がぞろぞろ出てくるという問題が起きている。いったいどこに行ってしまったのだろうか。現代版楢山節考なのだろうか。こどもの遺棄もそうだが、なにかひずみみたいなことが起きるとその犠牲になるのは年寄と子どもなのだ。

両者の事件を結びつけようとして、家族のきずなや互助的な共同体がなくなっただとか社会制度が問題だとか声高に言うつもりはないが、どうも二つの問題があるように思う。利他的な行動のインセンティブが減退していること、プライバシー侵害の過剰反応である。

利己的な行動へ走る人が増えているのは確かなように思えるが、なぜだかもよくわからないし、どうしていいのかも答えがなかなかない。簡単にはいきそうもない。ただ、個人情報保護法という行き過ぎ感のある法律のおかげで、この利他的行動の抑制が起こったことは否定できないのではないでしょうか。

以前にも指摘したのだが、この法律は「個人情報」を保護する法律であって、けっして「個人」を保護するものではないことを知ってほしい。ここらで、原点に立ち返って個人を保護するためにどういう法律、制度にしたらいいのかをしっかり議論してほしい。

上の二つの事件でもある程度強制力を効かせた「お節介」をしていれば防げたかもしれないと思うからである。それが、もしその「お節介」が行き過ぎたということで責められるかもしれないから、踏み込むのはやめようという意識で抑制されている可能性がある。

いずれにしろ、こうした問題はすぐには処方できるものではない。長い時間でできた風潮でもあるからである。切ないけど地道に人と人との関係性の修復をすることなのだろう。
  


  

2010年8月 9日

間違いだらけの業務システム開発(プロジェクト編その2)

開発プロジェクトではコードを書く

前回、開発プロジェクトではなく構築プロジェクトの方がなじむというような話をしましたが、ここではまだ開発プロジェクトという言い方にしますが、そうしたプロジェクトでは、ウォーターフォール型であろうが、アジャイルであろうが、みな一生懸命コードを書きます。前者のスタイルでは大勢のプログラマーを抱えて、せっせとコーディングをします。

おそらく、この瞬間でも世界中で言語は違えど同じコードをかきまくっていることでしょう。これはどう考えてもおかしいと思いませんか。なぜこんなことがおきているのだろうか。

ひとつには、ITベンダー側の事情がある。人月でこなすビジネスが染みついているため、そしてそのための多くのプログラマーを抱えてしまっていることがあって、それをプロジェクトではコードを書かないでいいですよとなったら大混乱になるからである。もしわかったとしてもできないのだ。

しかし、これはユーザからみたら困ったもので、本来なら短納期、低コストでできるシステム開発がベンダー側の事情でユーザに負担を強いている構図となっている。ユーザも薄々はわかっていると思うのだが、ITは専門的なものだからしかたないとあきらめている面がある。

前回も家を建てることを引合いに出したが(クルマの生産と比肩するより、家の建築の方が類似していると思う)、家の建築現場では普通そこで柱や窓枠を作っているわけでもないし、部屋の位置や大きさを変えることはしない。設計どおりなるように調整はするが、その程度である。

それと同じように、システム開発も設計ができたら、原則コードを書かない、もちろん多少のコーディングは要るが、それは例えば現場あわせのインターフェースのところだけとかにすべきである。そのために、モジュール化やコンポーネント化、各種フレームワークの活用などで対処できるようにすべきなのである。

そんなもの、ユーザによってシステムの中味が千差万別だから絶対無理だという人がいます。しかし、その千差をコードで書く必要がありますか、万別というがよくよく見ると共通的なものになってやしないですか。

ぜひ、開発プロジェクトではできるだけコードを書かないようにするためにはどうしたらいいのかをよく考えてもらいたいのです。コードを書くから開発に時間がかかるし、テストが大変だし、バグも出るし、変更に手間取るしというふうにいいことは何もないのである。
  

2010年8月10日

間違いだらけの業務システム開発(プロジェクト編その4)

正しいシステムを作ることがゴールである

この“正しい“という意味をちゃんと定義しなくてはいけないのだが、これも一見”正しい“ように思えます。ここには二つの間違いが潜んでいます。その正しいののは誰にとって正しいのかということと、作ることが目的なのかということである。

前者の誰のために正しいかについては、往々にして作り手側すなわち開発ベンダーや開発者にとってではないでしょうか。データベースの設計は技術基準にしたがってやりました、コードは社内のコード標準であり、プロジェクト管理はPMBOKに則りやりましたとなる。

そして、ユーザの要求からシステム要件に落としてその通りに開発をして、テストでも問題ないことを確認しましたである。ここには、そのシステムが役に立つものであるのか、ビジネス要求に応えるものであるのか、事業に貢献できるもにになっているのかという視点がないのである。だから、正しいではなく役に立つシステムを作らなくてはいけないということである。

次に、ゴールですが、今の話にもあったように、役に立たない正しいシステムを作ったって何もならないのはお分かりだと思います。それと何といってシステムというのは、それが動いてこそ効果を生み出すわけですから、作って終わりではないのです。

ところが、プロジェクトの終わりはシステムが稼働してすぐに解散です。まあそれでもいいのですが、ビジネスにおける成果をみる、もっと言えば継続的に事業貢献ができることを確認していくことがシステムに要求されていることです。

まあ、現実的にはずっとプロジェクトを継続するわけにはいかないでしょうから、開発が終わって本番が稼働してという段階で終わらすのでしょうが、どうも今のやり方では非常に大がかりな開発プロジェクトを立ち上げるくせに、戦略やビジネスモデルの立案とか、稼働後のパフォーマンス確認、向上といったフェーズに対する傾斜が弱いということを指摘したいのである。

なぜそういうことが起きているかというとあまりにも開発に時間とリソースをかけ過ぎるという側面もあるように思う。これからは、システムの開発はごく簡単にすませ、もっと戦略的なところや、オペレーショナルなところの重要性を自覚してプロジェクトを運営していくことが大切なことではないでしょうか。
  
システム開発は、”正しいシステムを作ること”ではなく、”役に立つシステムを正しく作ること”でなくてはいけないのです。ここを間違ってはいけません。
  


  

2010年8月11日

間違いだらけの業務システム開発(プロジェクト編その3)

申し訳ありません、「プロジェクト編その3」を抜かしてしまいました。順序が逆になりましたが、掲載します。

ユーザが仕様を早く決めてくれないから開発期間が長くなる

これが間違いっておかしいでしょとみなさん言うと思います。たしかに、開発プロジェクトでは、ユーザがなかなか仕様を決めてくれないために仕方なしに見切りで進めていって、あとでひっくり返されるという痛い目にあっているからそう思われるのでしょう。

私の経験上でもよくあったことですが、まず最初にユーザの担当者を決めてもらうのですが、だいたいにおいてキーパーソンは出てきません。キーパーソンと言うのは文字通り軸になっている人ですから、本来の業務が忙しくて、そんなプロジェクトに関わっていられないというわけである。

これもよく考えるとおかしな話なのですが、日本の企業の開発プロジェクトでよくある話である。従って、担当者は新人であったり、ひまな人がアサインされたりします。そんな状態ですから、仕様なんて決まったようで決まっていません。最後の方の、さあもうすぐ本番だから運用のテストをしようなんて頃になって、キーパーソン登場です。

こんなんじゃダメだとなり、仕様変更です。そしてあわてて変更開発をして、それが原因で不具合発生です。ですから、タイトルの意味は正しいのです。しかし、よく考えてください。ユーザが早めに仕様を決めてくれば解決するのでしょうか。というか、ユーザはどんなシステムができ、どう動くかもわからない段階で仕様をびしっと決められるものなのでしょうか。

私はユーザの立場に長いこといましたから言えるのは、仕様はきちっと最初に確定はできません。何となくこうしたいでは決まらないし、これでやると決めても技術的に無理だなんてこともあるわけです。ということは、無理なことを言っているのです。つまり、ユーザは仕様をなかなか決めてくれないという前提でプロジェクトを進めるべきだと思うのです。

そのために必要なことは何でしょうか。早い段階で動くシステムを見せてやることではないでしょうか。この早いというのは2つ意味があって、ひとつは開発の初期段階でプロトタイプがあるということと、もうひとつはユーザから要求が出たらすぐに実現してあげることです。

現在の開発ではアジャイルが増えてきましたが、まだまだ、仕様を固めて、それから時間をかけてコードを書いて、できたころには最初の仕様は何だったっけみたいな話になる。これじゃあ、ユーザだって最初から真剣になりません。尻に火がついてからでいいやとなってしまうのです。ぜひ、ユーザのせいにしないでユーザが本気になるやり方を考えてもらいたいのです。

2010年8月12日

電子書籍の衝撃

今回も佐々木俊尚さんが書いた「電子書籍の衝撃」(ディスカバー携書)を読む。電子書籍については、それほど興味があったわけではなく、そのうち広まったら手にしても遅くないと思っていた。ただ、ちょっと前にある人から電子ブックを見せられてちょっと感動したのと、iPADの登場でそろそろちゃんと見ておこうかという気になったのである。

改めて非常におもしろかった。とりわけ電子ブックプラットフォーム戦争という章で、アマゾン、アップル、グーグルの熾烈な争いは驚くとともに彼らのしたたかさを非難するより敬意を表したくなる。

アマゾンのキンドルの衝撃から始まったこの戦争は、先行するキンドルを追い打ちするようにアップルが果敢に挑み、逆転されるとアマゾンはアップルモデルをそのままコピーして巻き返しを図るといった図式である。そこに、豊富なコンテンツを保持したグーグルがどう割り込んでいくのかといった展開はまだまだ予断を許さない。残念ながら日本の会社の名前はない。

それと非常にわかりやすかったのは、電子化のインパクトについて音楽の例で示してくれていることで、iTune、iPODの例でその変化を追ってくれているのがよかった。そうなんです、電子ブックも同じ歩みをしていくはずである。

この本では、佐々木さんが電子ブックの円環という表現で提示していることが主題となっていて、その中のそれぞれの要件について検証を加えたものである。それは次のようなことである。

・キンドルやiPADのような電子ブックを購読するのにふさわしいタブレット。
・これらのタブレット上で本を購入し、読むためのプラットフォーム。
・電子ブックプラットフォームの確立が促すセルフバブリッシングと、本のフラット化。
・そして、コンテキストを介して、本と読者が織りなす新しいマッチングの世界。

ここでまだあまり注目されていないが、重要なのは後の2つで、簡単にいえばだれでも書き手になれる時代になったということである。有名作家だけが書き手になるわけではなく、ブラガーでもいい作品を書きさえすれば公にさらすことができるのだ。

おそらく早晩、いまの作家・出版者・取次店・書店といった世界は消滅していくだろう。しかしながら、著者も言っているように「電子ブックの出現は、出版文化の破壊ではない」ということをよく認識することです。いつの間にか読者を忘れた自分たちの既得権を守るためだけの出版文化から、本来の読みたい本を読みたいように読むための仕組みに変わっていくだけのことかもしれない。

その新たな形態として最後に書いてあるコンテキストを介しての読者と本のマッチングという姿だろう。これはもう一部の人もやっているし、ぼくもいくぶん実行しているのだけど、簡単にいうと、自分の好みにあった人が推奨する本を読むという行為である。いまはこれが売れ筋ですよ、これが話題ですよといって押しつけられて読むというプッシュ型から、自らの頭で選ぶプル型の読書スタイルである。

こうした潮流は抗しがたい事実であるから、こんな風潮はおかしいとか、今の文化を守らなければいけないと思うより、そのなかでどう振舞うかを考えた方がいいと思う。新聞の電子もしかりで新聞社がつぶれるとか出版社がなくなることへの感傷なんて捨てなくてはいけない。だいいち、記事がなくなるわけでもないし、小説がなくなるわけではないし、プラットフォームがどうなっても良い記事や良い小説は変わらないからである。
  

電子書籍の衝撃 (ディスカヴァー携書)
posted with yusukebe.com::AmazonSearch on 2010.8.8
  • 佐々木 俊尚
  • 新書 / ディスカヴァー・トゥエンティワン
  • Amazon 売り上げランキング: 1807
  • Amazon おすすめ度の平均: 3.5
    • 4 ITによるコンテンツ支配
    • 4 電子書籍について一通り知るならこの本!
    • 1 210円相当
    • 4 出版業界の人には耳の痛い話ばかりだけど、なるほどなって思うところも多いです
    • 5 出版業界の人、必見な1冊
Amazon.co.jpで詳細を見る

  

2010年8月13日

引き出しの中のラブレター

これは、シチュエーションを思いついた時に勝ったと思ったのではないか。同じラブレターという言葉が出てくる「60歳のラブレター」よりは一般受けする映画であろう「引き出しの中のラブレター」を観る。「60歳のラブレター」も非常によかったのだが、それはぼくら団塊だけに受けたようだ。

監督が三城真一で主演のラジオパーソナリティを演じるのが常盤貴子である。いまマスメディアがネットに移行している中、ラジオの存在感はあまり変わらないような気がする。とはいえ、ぼく自身がラジオを聴いているわけではないのであまりえらそうなことは言えないが、自分の経験(オールナイトニッポンにはまったことなど)とうちのばあちゃんが深夜や聴いているのをみるとそう思うのである。

その特徴は、パーソナリティと一対一の対話をしているという錯覚なのではないだろうか。お気に入りのパーソナリティが自分だけに語りかけてくれていると思い込むのである。そんな女性ラジオパーソナリティの番組に北海道の高校生から手紙が届く。

ぜんぜん笑わない祖父をどうしたら笑わすことができるかという内容である。そして、番組でその方法を募るのである。どうして思い入れたのかというと少し前に亡くなった自分の父親と重ね合わせたからである。死ぬまで父親とうち解けなかった自分がいたのである。

そこから、実際にその高校生に会いに函館に行ったりする。でクライマックスは、実家に残った妹が送ってくれた父親が書き遺したが投函できなかった手紙を読むシーンで、あれだけ頑なに家をでてパーソナリティをやることに反対していた父親が、実はひそかに応援しているということをつづった文面である。もう涙ボロボロになる。

そこからこのパーソナリティが、胸に秘めた思いを伝えられないことって誰でもあって、そんな人たちをラジオがちょっと背中を押してあげられるようなものをつくりたいと願い、それが叶って「引き出しの中のラブレター」という番組が作られる。

そして、メインは函館の高校生一家なのだが、様々な境遇の人々が登場し、その人々を追いかけるオムニバス映画と化していく。これまた、最後はお決まりではあるが、笑わないじいちゃんのその理由もわかり、そして番組に過去にわかれた妻への思いがつづられた手紙が届くというストーリーである。これも涙ボロボロである。

素直にこう言う映画は感動します。でもだいぶ涙腺が弱ってきたなあ。
  

引き出しの中のラブレター [DVD]
posted with yusukebe.com::AmazonSearch on 2010.8.7
  • DVD / よしもとアール・アンド・シー (2010-03-03)
  • Amazon 売り上げランキング: 8878
  • Amazon おすすめ度の平均: 4.0
    • 3 良かったけど謎がたくさんです。
    • 3 昔見たような懐かしい感じ
    • 3 TV的演出が惜しいなあ・・・。できればオール北海道ロケで観たかった。
    • 5 手紙の効力って凄いです
    • 4 目新しさはないのだけど・・・
Amazon.co.jpで詳細を見る

   

事故を考える

わが家のお盆は昨日の朝にお墓に行って霊を背負ってきて、家の玄関先で迎え火をたいて霊を家に入れます。その後は毎日お線香をあげ、お供えを取り変えてささげます。そして、16日に送り火を焚いて送り返し、お寺に行ってお施餓鬼に出て塔婆を立てて終わります。

で、お盆だからというわけではないが、昨日も中東のアブダビで4人の技術者が自動車事故で亡くなった事件が気になった。ぼくの大学時代の同級生ももうずいぶんと昔だが中東で自動車事故に会い死んでいるので人ごとではなく痛ましいかぎりである。そして、最近立て続けに海外で邦人が事故に巻き込まれている。

さらに一昨日は、日航ジャンボ機の墜落事故から25周年ということで御巣鷹山への慰霊登山の模様をメディアが一斉に伝えていた。520名という命を奪った未曽有の航空機事故で、もちろん当時のことはよく記憶している。犠牲者に坂本九が含まれていたり、墜落するまでのわずかな時間で書いた遺書など今でも心を痛める。

ここで事故のことを考えてみたい。航空機事故は一度に多くの犠牲者がでるので注目されるが、自分にとってどれが恐いかという話である。ことわっておくが、どの事故がかわいそうだとか、痛ましいとかいっているわけではなく、個人としての感じ方を言っている。だから、社会現象的には飛行機や船、そして鉄道といったものの事故が大きく報道されるが、実は身近な自動車事故が恐ろしいと思うのである。

ここに統計がある。道路、鉄道、航空、海上の交通事故による死亡者数の長期推移である。これをみると、ダントツに道路での事故による死者が多いのがわかる。鉄道も結構多かったのが最近ずいぶんと減っているんですね。道路事故も1970年前後に比べると大きく減らしている。

jikosisu.JPG

この数字からも自動車事故が一番身近だし恐いのは当然かもしれない。ぼくは、飛行機も船も乗る機会は少ないからなおさらだ。自動車は被害者になるだけではなく、自分でも加害者にもなることがあるから、より悲劇的で、ここも航空や海上と違うところでもある。被害者に近い数の加害者がいるわけだから、ある意味犠牲者は死者の数以上なのである。

そうみていくと人類が生み出した道具や機械のなかで武器以外で最も多くの人を殺したのが、いや殺し続けているのが自動車ではないでしょうか。これは、かなり恐ろしいことなのだが、最近は世間ではあまり声高に言われない。

昔、ぼくらが子どもだったころ、交通戦争という言葉もあったくらい、自動車(特にダンプカー)は悪者だったはずなのだが、いまやエコカー減税と称して、お国も人殺しの道具を奨励している。おっと言い過ぎたかもしれないが、いつのまにか人間の歩いている道を占領してわがもの顔で走っているのをみるとついもう少し謙虚でいようよと言いたくなるのである。
 

2010年8月15日

システム開発プロジェクトの成功とは

いま、「間違いだらけの業務システム開発」ということで連載しているが、開発プロジェクトがうまくいったのか、そうでなかったのかという実態がどうなっているのかを知ることも参考になると思う。

いささか古いので恐縮ですが、日経コンピュータの2008年に行われた「第2回プロジェクト実態調査」ではシステム開発プロジェクトの成功率が31.1%だったという報告がある。その5年前の第1回の結果が26.7%だから、さほど向上していない、まあ同じようなものだ。大方7割のプロジェクトが失敗だったという。

ところで、ここでいうプロジェクトの成功率とは「Q(Quality)、C(Cost)、D(Delivery)」、すなわちシステムの「品質」「コスト」「納期」の3点について当初の計画を順守できたかどうかを尋ね、品質、コスト、納期の3基準すべてで「当初計画通りの成果」を収めたプロジェクトだけを「成功」と定義している。けっこうハードルが高い基準だ。

ただ、これも少々誤解がありそうだ。つまり、システムをつくることをゴールにしているからである。「品質」にどれだけビジネスへの貢献度を加味できているのかがよくわからないので軽々には言えないが、「当初計画通りの品質」というのが微妙である。それ以上に、品質の定義も問題である。

というのも、「当初計画通りの品質」が開発プロジェクトでできるかどうかで、おそらくそれは無理であろうと思う。実際にそのシステムでオペレーションしていくうちにブラッシュアップされて、「当初計画通りの品質」が達成できるではないだだろうか。

ただし、それで終わりではないはずで、求められる品質は日々変化しているわけで、そうなると「当初計画通りの品質」を達成することがゴールではない。その時々でビジネスの要求に応えられる最適な品質を継続的に実現していることが究極のゴールになるでしょう。

さらに、この調査で驚いたのは、5年間でほとんど成功率の向上がみられなかったことである。この間、失敗しないためのプロジェクト管理とかいって、様々な手法や技術が提示されたはずである。それがなにも生かされていないということを意味する。というより、すばらしい手法や技術が有効ではなかったことを意味している。

それはなぜだろうか。プロジェクト管理手法や技術は進歩し、人のスキルも向上したのになぜなのだろうか。答えは、変われていないものがあるからである。作っている業務システムの構造が旧来のものと同じだからである。これは、このブログでも再三指摘したことである。

作っているものが従前から、見てくれではなくて、中味が本質的に進化していなかったら、いくら先進的な技術や開発方法で作ったところで同じことを繰り返すだけなのだ。昔から作られている業務システムは構造的に開発に失敗する要素を素性として内在しているのだ。これが、根源的な問題である。

だから、この構造問題を解決しない限り、次の5年後の2013年に調査しても同じ結果になるのではないだろうか。
  

2010年8月16日

日本人へ リーダ篇

「日本人へ リーダ篇」(文春新書)は、ご存知塩野七生が文芸春秋に連載したものを新書化したものである。2003年6月号から2006年9月号まで巻頭随筆として毎月書いていた。以前は文芸春秋を定期購読していたので、この巻頭随筆で司馬遼太郎の「この国かたち」などを読んだ記憶がある。

さて、サブタイトルにリーダ篇とあるように、リーダたるものどうあるべきかについて、ローマの歴史を照らし合わせながら書いている。塩野七生は何といっても、毎年1巻ずつ執筆して、2006年に全15巻を完成させた「ローマ人の物語」が有名である。ぼくも2巻まで買って読んだが挫折した。

だから、塩野七生のバックボーンはローマなのだ。長いローマの歴史では、ユリウス・カエサルを筆頭に数々の優れたリーダが輩出されているので、彼らとの対比の中で現代の日本のリーダを評価するので非常におもしろい。といっても比較の対象としては小粒すぎるが。

著者はイタリアに住んでいるし、過去の歴史にも通じているので普通の日本人がみる眼とずいぶんと違っている。醒めた客観化ができるのですごく説得力がある。グローバル化した今日では、耳を傾ける価値が十分ある。ただし、ちと保守的なきらいはあるが。

実はお分かりのように、この連載は2003年から2006年までのものだから、4~7年も前のもので、だから小泉純一郎やブッシュがでてきたり、イラク派遣が話題になったりする、しかしながら、その書いてある内容が陳腐化していないのには驚かされる。

おもしろいのは、2000年も前のローマ帝国のことがそう古いことではなく、むしろ現代と相通じるところもあるのが新鮮だった。その中でも感心するのは、知力ではギリシャ民族に劣り、体力ではケルトやゲルマンに民族に劣り、技術力ではエルトリア民族に劣るローマ人がなぜあれほどの大を成したかである。

それは軍事力のみではなく、「もてる能力の徹底した活用」なのだという。言い換えれば、ひとつ一つでは他民族に劣るが、すべてを総合し駆使していく力が断然優れていたからだそうだ。それは自分たちの力だけではなくライバルたちのもつ能力さえも活用したという。

この「敗者同化」の精神こそローマの真髄なのだ。これを、その後の大英帝国を筆頭としたヨーロッパ諸国の植民地政策、あるいは現代のアメリカの戦後処理と比較したとき時代を越えて多くの示唆を与えてくれる。

そうした話が随所にでてきて改めて考えさせられる。最後に、この本の巻頭に載せたユリウス・カエサルの言葉を再掲する。

人間ならば誰にでも、現実のすべてが見えるわけではない。 多くの人は、見たいと思う現実しか見ていない。
日本人へ リーダー篇 (文春新書)
posted with yusukebe.com::AmazonSearch on 2010.8.16
  • 塩野 七生
  • 新書 / 文藝春秋
  • Amazon 売り上げランキング: 312
  • Amazon おすすめ度の平均: 4.5
    • 5 少し古いですが
    • 4 経営者の愛読書塩野七生氏の生活と意見には平凡な老人にも納得出来るところがある
    • 4 歴史家の視点
    • 5 賢者は歴史に学ぶ
    • 5 今日本人に必要なもの
Amazon.co.jpで詳細を見る

2010年8月17日

間違いだらけの業務システム開発(企画・設計編その2)

戦略立案からトップダウンで設計すべきだ

これは、間違いというより、それだけではないという意味です。システム開発の教科書には(ただし、あまり読んだことはないが)、内外部の環境の分析をして、強み弱みを抽出して、バランススコアカードで評価し、CSFやKPIを設定し、戦略、ビジネス要求を練ることが大事であるとなっているようだ。これを要求分析とか要求開発という。

そして、そこからどういう業務システムにしたらいいのかというアプローチで、それは全く正しいのですが、何でもかんでもそうしたアプローチなのかということと、これも何度も言っているのだが、その受け皿となる業務システムの構造がちゃんと対応できているのかという問題を指摘したい。

単なるデータ登録、帳票出力システムでしかなかったらどうなるでしょうか。一生懸命上流の分析、設計をやったとしても徒労に終わることってあるのではないでしょうか。その戦略やビジネスモデルをどうやってシステムに落としていくのかがわからないのです。

プロジェクトの初期で、うちのこの事業の戦略はこうで、そのためのビジネスモデルはこうして、管理するKPIやパフォーマンスはこれこれにしようと決めます。ところが、最初に決めたビジネスモデルがどう実現できているかが見えるような仕組みになっているでしょうか。一生懸命頭を絞って考えたKPIやパフォーマンスのデータがきちんと取れてそれが解析できるようになっているでしょうか。

よく考えてほしいのは、実際にオペレーションする仕組みが上流分析・設計と連動したものでないと意味ががないということです。どうも日本の業務システム開発の現場ではこのことの重要さを理解していないように思うのです。

ですから、もしちゃんと上流分析・設計の結果を表現できる一貫化された、連動性のあるプラットフォームができれば、何も上から下に降ろさなくても、下から上へ要求を出すボトムアップアプローチだってかまわないケースもでてきます。それもそうだし、例えば、顧客の要求に応えるようなサービスプロセスなんては、そんなに戦略的な要素が必要ではないので、すぐに設計に入ってもいいわけです。

つまり、業務プロセスの構造が、ビジネスモデルを実装できるようになっていれば、そこの必要機能を埋めていくことで、あたかも上流設計を行ったように実装できるはずです。似たようなものに、インタビューシートに従って質問していくと、自然とビジネスモデルができていくというようなことがあります。白紙のプロセスの構成要素を色づけていくといった作業で設計することです。

ですから、理想的には上からと下からの両方から攻めるハイブリッド型アプローチが一番かもしれませんね。ハイブリッドばやりなのでそんなアプローチをしてみたらいかがでしょうか。ただし、しつこいようですがボトムアップアプローチが確立していないとだめです。そこを抜きにしたトップダウンアプローチでは、間違いとまでは言いませんが有効性を失っていると言わざるをえないと言っているわけです。
  

2010年8月18日

デジタルネイティブとともに

一年と少しほど前に「デジタルネイティブが世界を変える」(ドン・タブスコット著)という本が注目された。その本のことではなく、そこに出てくるデジタルネイティブという人種とはとか、その行動規範のことである。まずはそのデジタルネイティブ世代が世間からどんな非難を浴びせられているのかから。

a.この世代は、自分たちが彼らの年齢だった頃と比較して頭が悪い
b.ネット世代はネット中毒であり、社会的スキルがなく、スポーツなど健康的な活動に時間を費やさない。
c.ネット世代は恥を知らない。
d.ネット世代は、両親に甘やかされてきたため、ぶらぶらするばかりで定職に就こうとしない。
e.ネット世代は平気で盗む。
f.ネット世代はオンラインでいじめ行為をする。
g.ネット世代は暴力的だ。
h.ネット世代は職業倫理を持たない最悪の職業人だ。
i.ネット世代はナルシステックな最新型「ミー世代」だ。
j.ネット世代は周りに関心を示さない。

いつの時代も若者に対しては理解するより非難する方に向くが、おおかたの大人が抱く感情であろう。しかし、この本の著者は、それは偏見であるとして、ネット世代には以下の8つの行動規範があると説く。

1.ネット世代は何をする場合でも自由を好む。選択の自由や表現の自由だ。
2.ネット世代はカスタマイズ、パーソナライズを好む。
3.ネット世代は情報の操作に長けている。
4.ネット世代は商品を購入したり、就職先を決めたりする際に、企業の誠実性とオープン性を求める。
5.ネット世代は、職場、学校、そして、社会生活において、娯楽を求める。
6.ネット世代は、コラボレーションとリレーションの世代である。
7.ネット世代はスピードを求めている。
8.ネット世代はイノベーターである。

ここに示される行動規範は、決して非難されるようなものではなく、むしろ称賛すべきことかもしれないが、そうした新しさをなかなか認めようとしないのも前世代の人間の行動規範でもある。

しかしながら、こうした行動規範をもった若者がどんどん生まれてきているのも事実なので、否定するより共存する方が賢いのだ。デジタルネイティブと暮らし、デジタルネイティブと働き、デジタルネイティブと遊ぶのである。というのも、彼らの特質である自由、カスタマイズ、情報操作、オープン性、コラボレーション、スピード、イノベーションといった指向性はこれからの世の中で必要な要素なのである。

大人たちは彼らがそれを生かせるような環境を整え、応援するくらいの気持ちをもつことではないだろうか。少なくとも邪魔をしないことだろう。ぼくは、今の立場からいうと、こうした若者の行動規範を受け入れられるような業務システムはどんなものだろうかということに思いを馳せる。それができたらぼくの中で若者と共存できたと言えるのである。
  

デジタルネイティブが世界を変える
posted with yusukebe.com::AmazonSearch on 2010.8.7
  • ドン・タプスコット
  • ハードカバー / 翔泳社
  • Amazon 売り上げランキング: 153066
  • Amazon おすすめ度の平均: 4.5
    • 5 世代間の知識の伝達
    • 5 デジタルネイティブと共存
    • 5 大人が共感できない世代の世界がすぐそこまで来ている
    • 5 この本は,教育に関してもとても学ぶところが多いです
    • 4 「ネット世代」の今後の活躍が楽しみである。
Amazon.co.jpで詳細を見る

  

2010年8月19日

間違いだらけの業務システム開発(企画・設計編その2)

目的を明確化することが重要だ

どんなことでも目的を明確化するということは大事なことです。だが、あえてここでそれは間違いであると言っているのは、システム開発における、もうすこし具体的なそこで作るシステムの目的の明確化について言っています。

陥りやすい過ちは、作ろうとしているシステムがどんなシステム機能をもって、どんなシステム構造にするかということをシステム開発の目的としてしまうことです。少々分かりずらいかもしれませんが、別な言い方をすると手段を目的化してしまうことです。何をつくるかのというWhatを目的にしていまい、Whyを忘れてしまうのです。

目的を明確化しましょうというと、ついこうした間違いを犯すことになりかねません。ですから、こうした場合は、目的合致性とか合目的性をチェックしましょうと言った方がいいと思います。つまり、このシステム開発は本来の目的に合致しているのかということを問うのです。

こうすることによって手段の目的化の過ちがなくなり、正しく目的を達成するための手段はどうしたらいいのかという思考回路になるというわけである。そうなるとお分かりのように、決してIT化するとか、ソフトを導入するとかが全面的な解決策ではないのです。

その会社や組織の能力や成熟度でやり方やシステム形態が変わってもいいのであって、身の丈にあったシステム化が重要であるということは何度も書いてきました。目的のすり替えがあると立派な仕組みを作ったはいいが使いこなせない“猫に小判”システムができあがるわけです。

ここであえて説明するほどではないかもしれませんが、システム開発の目的は、ビジネスあるいは事業に貢献できるかの一点です。どうもこの目的の設定の間違いが無意識のうちにあるような気がします。気をつけたいものです。

2010年8月20日

ブロークバック・マウンテン

「ブロークバック・マウンテン」はアカデミー賞監督賞やヴェネチア国際映画祭金獅子賞など2005年の映画賞を数多く受賞した作品である。そのとき話題になったので観たかったのだが、仕事がムチャクチャ忙しかった時期でもあり、見逃していた。

何とも切ない映画だ。ゲイの映画だというふれ込みなのだが、何のことはない不倫の映画でもある。不倫の相手がゲイであったとともとれる。そう考えると二人の男の身勝手さが浮かび上がってきて、それぞれの伴侶がかわいそうになる。

だから、映画の高い評価の割にぼくはちと首をかしげてしまった。たしかにゲイの二人の男側でみていくと、1963年という人々の偏見や嫌悪は大変であった時代に生きずらかったのはわかる。そうした中で禁断の世界に入り込んでしまった2人が、どう生きていったかを描くことは社会性もあるわけだが、上で言ったように彼らの結婚相手や家族から見たら、私たちをどうしてくれるのと言いたくなるのではないでしょうか。

ただ、人間の世界は大なり小なりこうしたいろいろな形の愛情があるのが現実で、そういった意味では同性愛だからというっだけでない普遍性をもった映画という見方をするとおもしろい。

監督のアン・リーは、ゲイの映画を撮るというより、1963年という保守的な時代のワイオミングという保守的な土地柄で、そうした保守的な風土を揺さぶってみたくなったのかもしれない。何もない静かな水面に石が投じられたときその波紋はどうなるのか。

そして、同性愛の表現も非常に抑制が効いていて、しかも自然の中にそれを置くという映像表現は好感が持てる。静かな中にもゲイの二人以外に登場する人々の心の中は激しいはずであるが、ここでも切なく寂しげである。

結局、最初に少し批判めいたことを言ったが、最後はいい映画だったと言っておきます。ところで、イニス役を見事に演じた主演のヒース・レジャーは、2008年に28歳という若さで亡くなってしまった。死因は複数の処方薬による急性中毒だったという。
  

ブロークバック・マウンテン [DVD]
posted with yusukebe.com::AmazonSearch on 2010.8.12
  • DVD / ジェネオン エンタテインメント (2009-07-08)
  • Amazon 売り上げランキング: 29915
  • Amazon おすすめ度の平均: 4.5
    • 4 愛情のベクトルが同性に向いていた。それだけのことなんだね。
    • 5 苦しみを奥に奥に綴じ込めて
    • 5 愛というもののままならなさ、抜き差しならなさ…。それでも「生きる」ことと「愛する」ことは不可分なはずで。どれだけ破壊的であったとしても。
    • 5 生涯最高の映画
    • 2 日本はリベラルになったよ
Amazon.co.jpで詳細を見る

  

2010年8月21日

管理プロセスのワナ

欧米発のソフトウエアはどうも管理的な色彩が強いように感じるのはぼくだけだろうか。ERPにしてもSales Forceにしても管理する側のツールという性格にみえる。これは、フレデリック・テイラーの科学的管理法を思い出させる。20世紀初頭にひろまった労働者管理の方法で基本原理は、稼業管理、作業の標準化、作業管理のために最適な組織となっている。

そうした考え方をいまだに引きずっているように思え、このソフトの機能どおりやれば効率の良い業務処理ができるはずだということである。ノルマを達成し、経営を安定させるためにはこうした管理プロセスが必要なのだという主張となる。

今の時代でも必要なのだろうか。もちろん、全面的に不要というわけではない。それこそルーティンの繰り返し作業では必要かもしれないが、そうではない部分の比重が増してきている現代では違った対応が要るような気がする。

だいいち、管理という言葉が好きになれない。つい営業管理システムとか購買管理システムとかいってしまうが、そのネーミングも気にいらない。システムが人間のやる業務を管理するという響きなのである。管理はあくまで人間がやって、それを支援するあるいは場を提供するのがシステムだろうと思う。

時として、管理プロセスによるコストダウンよりその管理プロセスを管理するためのコストの方が高くつくという破目に陥るというパラドックスを引き起こす。管理プロセスというと管理することが目的化するわけで、その目的を達成するためにはどんなコストをかけてもいいと錯覚してしまうのだ。

現代は、多種多様の客さまニーズに応えていかなくてはいけない世の中になって来ていて、画一的な管理手法では限界があるのではないでしょうか。そこでは、働いているひとのパーソナリティとか、組織としての協働動作だとか、それぞれの知恵と裁量といったことが重要視されてきて、それが差別化だったりするわけです。

このような変化に対応したソフトウエアや業務システムを開発することが大きな課題だと思っている。それを使うと楽しく働けるクールなITが望まれるのである。

2010年8月22日

乙女の密告

第143回芥川賞は、赤染晶子の「乙女の密告」に決定した。京都のある外国語大学で「アンネの日記」をドイツ語でスピーチするコンテストに向けて苦闘する女子大生の乙女たちが登場し、その指導教授であるドイツ人との関係や、誰がアンネを密告したかといったミステリー仕立てにもなっている小説である。

書評に行く前に選考委員の選評のことである。芥川賞の選考委員は、池澤直樹、石原慎太郎、小川洋子、川上弘美、黒井千次、高樹のぶ子、宮本輝、村上龍、山田詠美の9名である。男5人と女4人ということなのだが、この男と女の各委員の見方がおもしろかったのである。

女性委員はおおむね受賞作に好意的でほめているコメントである。それに対して、男のほうは池澤直樹と黒井千次は評価が高いのだが、石原慎太郎、村上龍、宮本輝の3氏は批判的なのである。特に石原慎太郎は辛辣でつぎのような言葉を投げている。

今日の日本においてアンネなる少女の悲しい生涯がどれほどの絶対性をもつのかは知らぬが、所詮ただ技巧的人工的な作品でしかない。こんな作品を読んで一体誰が、己の人生に反映して、いかなる感動を覚えるものだろうか。アクチュアルなものはどこにも無い。 日本の現代文学の衰弱を表象する作品の一つとしか思えない。

わー、これは厳しい。ぼくはそこまでは言わないが、アンネと現在の自分とを重ね合わせて語るのはおもしろかったし、それなりのリアリティも感じられたが、村上龍も指摘していたように文章の正確さに問題があって、理解が跳んでしまうことがあったのが残念であった。

このことは、直観的ですこし飛躍してしまうかもしれないが、個人的には小説全体の文章から受ける印象がなんとなくマンガを想起させた。何と言ったらいいか、表層的なゾーンで言葉が行きかっているように思えるのだ。吹き出しの文章のように思えたのである。

さて、今度は女性選考委員が女性作家が女性のことについて書いた小説をほめるという構図のことである。そうしたことに対して、塩野七生がおもしろいことを言っている。「作家は絶対に、書く対象に影響される。対象に乗り移るくらいの想いで対さないかぎり、それを書ききることはできない。私の場合は、自分自身が女なのに、わざわざ他の女に乗り移るほどの情熱を感じないといいことかもしれない」

女流作家で男を描く人は少ないように思う。もうそろそろ女流作家は身内の女のことばかり書くのはやめたらどうだろうか。肝心の小説の中身から外れてしまったが、今回はそんな感想を抱いたのである。

乙女の密告
posted with yusukebe.com::AmazonSearch on 2010.8.20
  • 赤染 晶子
  • 単行本 / 新潮社
  • Amazon 売り上げランキング: 788
  • Amazon おすすめ度の平均: 4.0
    • 3 現代的に語りあえる素材
    • 4 暗誦の緊迫感
    • 4 配役が面白く
    • 3 わからないのが密告者
    • 5 ユーモアある解りやすい文章で古典的なテーマに迫る
Amazon.co.jpで詳細を見る

2010年8月23日

キャタピラー

映画友だちS君と久しぶりにテアトル新宿に出かける。このクソ暑い日でも満席という盛況であった。若松孝二監督「キャタピラー」は、主演の寺島しのぶのベルリン映画祭主演女優賞受賞もあってか多くの観客がつめかけた。

これは衝撃的な作品である。戦争で四肢を奪われ、顔も焼けただれて帰還した兵士の妻がその夫とどう向き合いかが描かれている。最初のとまどいから、献身、そして嫌悪と様々な屈折した思いに心揺さぶられる。

この凄惨な姿の兵士はすぐに江戸川乱歩の「芋虫」を想像させられる。やはり、この小説からヒントを得ているのは間違いないと思われるが、まったく同じでもない。すなわち、この姿形が異様だから、衝撃的であるというわけでもないというところにこの映画の意味があるように思う。

最大のみどころはやはり寺島しのぶの演技だろう。賞をもらうのもうなずける熱演だ。上で書いたように、心の葛藤の変化を時には痛々しげに、時には腹立たしげに、時には本能的に、時にはたくましく表する。そのなかに、戦争のむごたらしさ、むなしさ、そしてこっけいさを潜ませていた。若松演出の冴えだ。

ただ、これはぼくの個人的なものかもしれないが、単に反戦映画であるというレッテルは適当ではないと思う。むしろ、人間のもつ本源的な心性、あるいは欲のようなものが強く描かれているように感じたのだ。ただひたすら食べることとやることしかできない男が、その存在の証である勲章と新聞記事を眺めることでかろうじて生きていくが、その救いがはずされたとき・・・。

だから、最後に広島や長崎の原爆投下の映像を流し、死者が何人だったというシーンはむしろ必要なかったのではないだろうか。それがなくとも、十分反戦というより戦争の一断面が多くを語っていたのだから、そこからの広がりを観客に持たせるだけでよかったと思う。

それにしても、S君も言っていたがこれは製作費がぜんぜんかかっていない映画だ。出演者だって名の通った俳優さんは寺島しのぶくらいだし、セットもほとんどないし、撮影日数も少なかったようだ。このあたりは、ピンク映画出身であるという面目躍如である。それでも優れた作品は作れるのだ。


観終わったあとは、時間が4時半と早かったのとS君の家の近くということもあり三軒茶屋の「味とめ」を久しぶりに訪れる。こんなに早いので空いているのかと思いきやすでに満席状態。というのもサンバ祭りをやっていたらしい。

それあるし、今年の2月に放送された「とんねるずのキタナシュラン」で紹介されたこともあり、それを見て来たという人が隣に続けて座る。だから、この暑いのに「いわしのすいとん風鍋」を食べていた。というわけで、映画と酒を楽しんで、また次回の映画観賞会を約して別れたのであります。
  

2010年8月24日

間違いだらけの業務システム開発(企画・設計篇その3)

設計は厳密な設計手法や手順で行わなければならない

普通設計というと、設計法とか設計手順というのだが、どうもそれだとやり方はこうしなくてはいけないという響きがあり、決まりきったものとしてあいまいさが許されないように思えます。ところが、業務プロセス設計の場合、こうでなくてはいけないという厳密なやり方は似合わないような気がします。

その理由は、設計の対象となるシステムは人間が行うものだからではないでしょうか。機械がするのならきちっと決めておかないとうまく動きませんが、逆に人間のやることはある程度の裁量の幅みたいなものを残ししておいたほうがよいように思うのです。

従来のシステム設計では、対象がコンピュータだったので、コンピュータにやらせることを厳密に定義することが大事でした。しかし、人間主体のシステムと考えると、もっと緩くこんな感じでやるといったものの方がなじむのではないでしょうか。IT主体から人間主体へシステムの形態が変化するということは、設計の考え方も変えていかなくてはいけないのです。

そこで言っているのが“作法”ということでです。では、作法っていったいどういうものなのでしょうか。茶道なんかでも作法といいますが、その作法は流派で違ってきます。裏千家、表千家、武者小路千家とあるそうですが、それぞれで作法が違うようです。作法とはそういうもので、ただし、それぞれ枝葉のところでは違っても、幹のところでは共通の“芯”を持っています。茶道でも、落ち着いた心でお茶を楽しもうという精神は各流派とも共通です。

さて、業務プロセス設計における作法のことです。先ほど言ったように人間主体の業務プロセスはきちんとし論理的なモデルにはなりません。だからといって、“なあなあ”のプロセスでも困ります。ある程度の約束事があるべきです。言い方を変えると、約束できるレベルでプロセスを書き出すということです。

業務プロセス設計のように何かを集団でやろうとしたときに、ばらばらにならないように秩序を維持する必要がありますが、そのとき作法が生きてきます。なぜ有効かというと、作法は「型」ですから、メンバーがその型を習得していれば、誰がやってもだいたい同じものができるということなのです。

そこは、技法や手順も同じでしょうという指摘があるかと思いますが、作法は覚えることが少ないこと、それも頭ではなく身体で覚える感覚に近い感じでやれることではないでしょうか。知識として多くのことを学ばなければいけないという方法論は限界があるように思います。シンプルにシンプルにです。ということで何が何でも厳密にやる必要がないことを感じてほしいと思います。


2010年8月25日

間違いだらけの業務システム開発(構造・機能篇その1)

IT化とは機械化、自動化することである

コンピュータが登場した初期のころは、まさに計算機の導入という意味で機械化、自動化が図られた。人間のやっていることを機械にまかせ、大量の処理を早くやらせることで効果を出していた。

しかしながら、こうしたITは一部の計算とかルーティンの処理だけではなく、もっといろいろなことができるようになってきました。そうなると単純なものから人間が考えることだとか、感じること、意思といった領域に入り込むようになりました。

AI(人工知能)もそういったものであったわけです。ところが、そんなに人間は簡単なものではないので、機械化、自動化の延長では限界があることがわかってきました。つまり、人間の考えることややっていることは複雑で恣意的で臨機応変で、それはコンピュータでは無理なのです。

コンピュータ登場以前の仕事は全部人間がやっていたわけです。そのうちのそろばんや電卓でやっていたことや伝票を集めていたようなことをコンピュータが代替するまではよいのですが、机の上で会話しながらとか電話で段取りをするとか、誰かに問い合わせるとかしながら意思決定をすることまでは無理なのです。

当たり前のように、こうしたことは人間が主体となってやるような仕事です。この部分は機械化、自動化はできないと言っているのです。しかしながら、ここで誤解しないでほしいのは、IT化するなと言っているわけではないということです。おわかりでしょうか、むしろ複雑で恣意的で臨機応変の業務処理でも、機械化、自動化はできないが、別の意味でのIT化をしたらいいと思っています。

そこを取り違えると、どこやらの大きなベンダーが、ビジネスプロセスオートメーションなんて概念を提案するというばかなことを言ってしまう。ビジネスプロセスが自動的にぼんぼん進んでしまう世界はどんなに気持ち悪いか想像したことがあるのだろうか。

この辺はなかなか理解できないかもしれませんが、いまの若い人たちのITの使い方を見ていたらわかると思います。スイスイと友だちとの会話、あるいは協働作業やコミュニティ活動などを行っています。ITという道具を使いこなしている姿です。

ネット上のある空間に仲間が集まってきて、同じ目的のためにコミュケーションをとったり、コラボレーションを行ったりするソーシャルネットワークです。これは、ITがそうした“場”を提供しているのです。こうしたスタイルはなぜ企業のシステムの中に入ってこないのでしょうか。

このような“場”の提供だけでも立派なIT化だと思っています。昔は誰かの机のまわりに集まってワイワイやっていたことをもっとオープンにそしてもっと多くの有用情報を参照しながらやれたらいいなあと思うのです。今のITはそれができるはずです。
  

2010年8月26日

日本人へ 国家と歴史篇

塩野七生の「日本人へ リーダ篇」に続いての「日本人へ 国家と歴史篇」(文春新書)である。タイトルのように前著はリーダについてで、この本は国家と歴史についてであるが、そこは明確に分けられるものでもなく、同じようにローマ時代を中心とした歴史と照らし合わせて現代を見ている。

のっけに後継人事についてというのがでてきてこれがおもしろい。歴史上、最高の後継人事だと著者が言うのが、イエス・キリストから、ペテロへ、そしてユリウス・カエサルからアウグストゥスへのバトンタッチだという。

この二つの後継で共通するものは何でしょう。それは、性格から資質から何から何までちがう、二人の男の間で成されたバトンタッチだったということである。イエスもカエサルも一代を築いた革命家であるから、ある意味激しいが、それをついだペテロにしてもむしろ純朴だが頭が切れるわけでもなく欠点も多い、またアウグストゥスにしても戦はまるでだめだし決して無理をしない性格だった。

結局攻めていかなければならないときと守らねばならないときではそれにふさわしいリーダは違うのであって、大事なことはそれを見ぬいていた先駆のリーダがいたことである。これを見るにつけ、わが国の政界、財界の後継者選びの能の無さにがっかりする。

そして、またおもしろいのは、前回にはなぜローマが大を成したかということを書いたが、今回はなぜあれだけ長い間続いた帝国が滅びたのかである。それについて、「亡国の悲劇とは、人材が欠乏するから起こるのではなく、人材はいてもそれを使いこなすメカニズムが機能しなくなるから起こるのだ。」

ここでも、わが国のことに思いをはせる。そうなのだ、人材が欠乏しているわけではないのだ。問題は政治のメカニズムが機能不全に陥っていることが大問題で、これを放置すると亡国の憂き目にあうということなのだ。

本書は、ごく最近に書かれたものであるから、いま今の世相を斬っているので思わずそのとおりだとつぶやいてしまう。特に外交の話は歯切れがよくてさすが海外生活が長いと見る目も違うと思わせる。塩野七生を外務大臣に任命したらどうだろか。イタリア大使でもいい。

今回も、本の巻頭に載せられた言葉を記す。あの有名なニコロ・マキャヴェッリの言葉で、グローバル化した中での日本の立ち振る舞いのことを鋭く突いているようにもみえる。

自分で自分を守ろうとしない者を誰が助ける気になるか。
  
日本人へ 国家と歴史篇 (文春新書)
posted with yusukebe.com::AmazonSearch on 2010.8.26
  • 塩野 七生
  • 新書 / 文藝春秋
  • Amazon 売り上げランキング: 281
  • Amazon おすすめ度の平均: 4.0
    • 4 2006年から2010年4月までの「文藝春秋」の連載をまとめただけ
    • 4 女には冷たい塩野七生という職業
    • 4 日本を内と外から見た人の意見をそろそろ真剣に聞く土壌が日本にも必要
    • 3 ローマ人の物語を書き終えた著者の心境と外から見た日本
    • 5 傍目八目ってことですね
Amazon.co.jpで詳細を見る
  

2010年8月27日

情シス若手勉強会

来月から、標記のタイトルで勉強会をすることになりました。主催は日本BPM協会で、毎月1回、計6回開催し、ぼくがその勉強会のリーダを務めます。

BPM(Business Process Management)というのは、注目はされているみたいですが、いまいち普及していないというのが現状ではないでしょうか。その理由は、いろいろあるかと思いますが、まだユーザの方々の認知度というか、有効性の実感というか、ほんとうにビジネスの役に立つものなのかがつかみ切れていないことがあるように思います。

このBPMという考え方はいくらベンダーやSIerがいいものだと唱えてもユーザがその気にならないことには始まりません。従来のようにソフトウアやパッケージを導入してそれを使いましょうというわけにはいきません。ユーザ自身が自分たちの業務プロセスを設計できなくてはならないからです。

すなわち、ビジネスの要求をきちんとITにつなぐことが重要になってくるわけで、じゃあそれは誰がやることなのだとなってきます。それは、組織的にも立ち位置的にも適任なのが、企業の情報システム部門や情報子会社の人たちです。

こうした部門は、いままでは、業務のことは現業部門、ITのことはベンダーにとられ、単なるメッセンジャーボーイ的な役割かあるいは日常の保守運用部隊でしかなくて忸怩たる思いをしていた人もいたと思います。そうなのです。ついに活躍の場が与えられたのです。

ビジネスとITの橋渡しこそ情シス部門や情報子会社の存在感を発揮する絶好の機会なのです。そのためには、どうしたらいいのか、どんなスキルをつけたらいいのかを真剣に考えなくてはいけないのです。

ということで、頭の柔らかい35歳以下の若手エンジニアの方々を相手に大いに議論していこうと思っています。興味のある方はぜひ下記サイトから申し込んでみてください。

日本BPM協会「情シス若手勉強会申し込み」
  

2010年8月28日

Twib!をリニューアル

ちょうど1年前に公開した「Twib!」をリニューアルしました。「Twib!」というのは、「Twitterホットエントリー」というもので、Twitter上でつぶやかれたURLを集めて、人気順に並べるものです。それを今回新しい機能を追加して、ユーザインターフェースも手直してリリースしました。主な改善点は次のとおりです。

1. インターフェースデザイン刷新
2. バズワード機能の追加
3. 「今、影響力のあるユーザー」表示
4. 100以上のサービスのエンベッド(埋め込み表示)に対応
5. Twitterで特徴的な「写真」「動画」「ライブ」のカテゴリ分け
6. RSS出力の改善により自社ドメインの影響力を図れるように
7. クローラーの修正

詳しくは、「ゆーすけべー日記」をみてください。


最近は、Twitterの影響力が増しているので、このサービスがひょっとするといろいろなところで使われるかもしれない。ネット上でもけっこう反応があり、Yahooニュースでも書かれましたし、他でもとりあげてもらっています。もしよかったら使ってみてください。

http://japan.internet.com/busnews/20100827/4.html
http://journal.mycom.co.jp/news/2010/08/27/054/
http://www.oshiete-kun.net/archives/2010/08/twittertwib.html
  

2010年8月29日

ネパール&チベット料理

一昨日は、以前BPP研究会でいっしょだったY君とネパール料理を食べながら近況報告と意見交換を行う。店は「レッサムフィリリ」といって泉岳寺の近くにあるネパール&チベット料理店である。ここは、ずっと前にぼくがチベット料理を食べたくて探したところである。都内に4,5軒あるうちの一軒である。

なぜ、ネパール料理かというと、Y君が去年仕事でネパールに行っていたということを聞いていたからである。昨日その話を聞いたら、どうもネパール人にシステム開発のやり方を教えてきたらしい。驚きますよね。インドならわかりますがネパールとは。

よく聞くと、ネパール人の技術スキルはけっこう高いとのこと、そのうちアウトソーシング先はネパールということになるかもしれない。しかしながら、最大の懸念は政治だという。昨今の政情の不安定さはビジネス機会などへの悪影響が大きいらしい。どこの国でも通る近代化への道のりかもしれない。

料理は、カレー料理や、小籠包に似たモモ、ラムをミンチにしたものなどを頼む。酒はビールとお米で作ったどぶろくみたいなチャンを飲む。料理はスパイシーな味でなかなかうまい。そんなにくせがないので日本人でもおいしく食べられるはずだ。

Y君には、「Kailas」を見てもらって意見をもらう。いまはデータのモデリングだとかDB設計などを中心にやっているというので、データとプロセスについての議論となる。これは、どちらかがいいとか悪いとかではなく、両方とも大事で、その重要性が現れる領域が違ったりするのでそこの見極めみたいなことをちゃんとしなくてはいけないといった話になる。

こうして親子ほど年齢が違う若い人と二人で呑みながら議論をしているのを周りからみたら変な光景かもしれない。でも、昨日もずけずけ意見を言ってくれるのですごく参考になってあらたな発見もあり楽しかった。彼が忙しさから解放される秋からいっしょに方法論のまとめのようなことをやってくれそうなのでうれしかった。

その後は、久しぶりに銀座の「M」に立ち寄る。話題は世界の料理で、珍しい国の珍しい料理の話題で盛り上がる。ぼくが、昔中国の頤和園の料亭で食べた鯉料理の話をする。生きたまま軽く唐揚げにして出されるが、まだ生きていて皿の上で動くわけで、大やけどを負った魚に箸をいれるのが残酷だったと言ったら、すかさず、マスターが“こいこがれて”いるんだねと言って大笑い。

それから、皮肉っぽくイギリス料理店ってあるのだろうかということから、日本にはどんな国の料理店があるのかという話になって、女性バーテンダーのKちゃんが、世界地図にマッピングしたらおもしろいねと言っていた。そうしたら、そう言うサイトがあったのだ。e-food.jp というサイトでそこによると、東京圏内で料理を食べられる国は、世界70ヶ国+68地方以上だそうだ。世界一周でもしてみるかな。
  

2010年8月30日

間違いだらけの業務システム開発(構造・機能篇その2)

業務は各社様々なのでパターン化、共通化、標準化できない

この表現も間違っているともいえるし正しいともいえる。業務の粒度、プロセスのレベルによって違うということである。どういうことかというと、業務プロセスの固有性はどんなところに現れるかということに関連している。つまり、固有性が出てくるようなところではパターン化、共通化、標準化は難しいが、そうでないところでは可能であるということです。

その辺をもう少し考えてみましょう。固有性というものはいったい何でしょうか。それはいい意味でも悪い意味でもあります。ただ、悪い意味での固有性はその会社にとって弊害になりますし、そんなものをパターン化しても始まらないわけで、これは除外しましょう。いい意味での固有性を考えます。

いい意味の固有性は、別の言い方をすると差別化要素であり競争優位の源泉であるわけです。そう考えると、各プロセスレベルでありそうですね。まずは、上流では戦略こそそれにあたります。この戦略はまだ文脈的ですから、それをもう少しロジカルなものに落とし込んだビジネスモデルが、差別化のための固有性を発現しています。

一方、下流に降りてくるとどうでしょうか。そうなると、業務を行っている個人的なレベルになってきます。すなわち、最終的な業務処理における従業員個々人のスキルや意欲であったり、組織の文化・風土であったり、取引先との関係性だったりが、その会社の固有性を発揮することになります。

ところで、この両者の間には何があるのでしょうか。それは業務プロセスです。正確に言うと、狭義の業務プロセス、すなわち比較的抽象度の高いレベルでのプロセスフロー構造とそのオペレーションではないでしょうか。ここの部分はおそらくどんな会社でも基本的には同じことをやっていると思うのです。

ここで、狭義の業務プロセスと言いましたが、では広義の業務プロセスは何が拡張要素何のでしょうか。それは、ルールマネジメント、リソース管理、ロール設定などです。いまあげたようなことは、重要な機能ですが、そうした機能があるのかどうかというより、具体的な値をどこに設定しているかといったところに差別化要素が入り込みます。ですから、狭義の意味にしたわけです。

ということで、狭義の業務プロセスは、会社や業種が違ってもパターン化、共通化、標準化できると考えています。ここがなかなか理解してもらえないところで、うちの業務プロセスは特殊だと言われたりします。こういう場合は、いったいどこが特殊なのかレベルを分けて吟味したほうがよさそうですね。

こういうところに業務プロセスを書いてもらうと、あっちへ行ったりこっちへ行ったりの複雑で冗長的なフローを書くものです。ぜひ、パターン化、共通化、標準化できるレベルがあって、それができると、このプロセスを核として、上流の差異、下流でのこだわりを付加するというアプローチがとれ、わかりやすい構造になるというのをわかってほしいと思うのです。
  

2010年8月31日

瞳の奥の秘密

これはまぎれもなく傑作だ。第82回アカデミー賞外国語映画賞を受賞したアルゼンチン映画「瞳の奥の秘密」である。平日の午後3時半からの上映というのに3時前に窓口で入場券を買おうとしたらもう数席しかりありませんという。前から2列目の端の方の席をやっと確保する。

口コミで良さが伝わってのことだと思うが、期待にたがわずずっとスクリーンに引き込まれてあっという間の2時間ちょっとであった。何がそうした評価になっているかというと、全体の構成から、時間と場所の出し入れ、細部の描き方の丁寧さ、意外性、ハラハラドキドキ感、ユーモアなどなど多くの要素を無駄なく見事に収めてあることだと思う。

主人公は、刑事裁判者に勤めるベンハミンという名の男で、定年を迎えてやめるのだが、25年前のある事件を題材に小説を書こうとする。それを元の女性の上司イレーネに見せながら、その過去の事件へとシーンが移っていく。

この事件のいきさつを縦糸に、イレーネとの愛を横糸にそれぞれが交錯しつつ物語が進んでいく。その事件は、新婚早々の女性が自宅で乱暴されて殺されるが、犯人をでっちあげて事件の終息を図ろうとすることに疑問をもった主人公が真犯人を追いつめていく。

この流れが、ストーリーの中核を占めているが、そこに殺された女性の夫がずっと真犯人を捜すために駅に通い詰める姿や、いつも酔っぱらっている主人公の同僚の味のある存在感などがちりばめられる。

そして、最後の衝撃的なラストにつながる伏線が仕掛けられている。こうした肝の仕掛けもさることながら、ディテールにも仕掛けがほどかされていて、例えばタイプライターのAという文字が壊れていて打てないというセリフが何度もでてくるが、それもちゃんと意味のあることだったとあとでわかるのだ。

そして、横糸の主人公のベンハミンとイレーネが25年の歳月を経て、一方で事件のことは忘れようという心理とは違い、忘れられない、いや忘れたくない思いを貫くのだ。ここで観客は救われる思いがするのである。

いま言った衝撃的なラストについて書きたい衝動にかられている。非常に重く根源的なことなので言いたいことがあるのだが、しかし、ネタバレになるのでやめておこう。いやあ、実に多くのことを考えさせられる映画であった。久々の星5つですのでぜひ観てください。
  

About 2010年8月

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

前のアーカイブは2010年7月です。

次のアーカイブは2010年9月です。

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

Powered by
Movable Type