キリンカップで、またまた日本代表がベルギーに4-0で快勝だ。得点者も長友、岡崎、中村憲剛、矢野とばらけていて、こういう点の取り方が日本の生きる道だろう。

特に、前半の前半の戦い方はかなりいい線いっていた。憲剛を生かすフォーメーションのようだが、かなり機能していた。ゴール前の狭いところで俊輔、大久保とパス交換ができるので、ベルギーのような大きいディフェンダーには有効だったようだ。

こうなるとこの形が見えてきたので、選手が変わっても同じようにできるパターンを作っておく必要があると思うのだが、後半選手が変わってしまうと形も変わってしまっていた。俊輔が抜け本田が入り、憲剛が抜けて興梠が入り、さらに矢野の投入ですっかり攻撃のパターンが違ってくる。

2プラトンくらいの態勢を作っておいたほうがいいと思う。そうでないと、一人の選手がでられなくなると戦術が変わってしまう脆弱さを抱えることになるからだ。

まあ、負けるよりいいに決まっていていい気分でウズベキスタン戦に望めるだろが、前の試合にいい試合をしたからといって、次もうまく行くとは言えない。

この間のUEFAチャンピオンリーグ決勝での前の試合ふがいなかったバルサが大事な決勝ではいい試合をしたように、一旦この2試合のことを忘れて気持ちを新たにして戦ってほしい。そうすれば、必ずW杯出場の切符は得られるはずだ。
　

さて、コンテを作ってアクティビティが特定されその順番も決めましました、そして、最終的に確定すべきデータ項目も設定しました。次はその中間のアクティビティのプロパティを見ていきます。

この場合、終点から遡って決めていくことになります。それぞれのアクティビティで確定するデータを定義するのに、終点のひとつ前は何を決める、その前はという見方の方が分かりやすいからです。しかし、結果的には、始点からデータを追記して行くというイメージでもあります。簡単な例として見積依頼プロセスでのデータ項目表を末尾に載せておきました。

中間のアクティビティにはそこに記入するデータ項目や参照情報といったものを記入するシートで整理した方がいいので、そうしたシートを使うことにします。遅ればせながら、始点も終点も同じようにシートに記入していきます。

コンテでは簡単に書いていた参照情報などはここではきちんと定義しておきます。必要情報は下記のような項目となります。

・ 前シート名、No
・ プロセス名、アクティビティ名（書類名）、シートNo
・ 作成者、メンバー、承認者
・ データ（確定データおよび参照データ）
・ 分岐
・ 参照情報、連携サービス
・ ビジネスルール
・ 後シート名、No

そして、これらに付随する関係性を表現するためのカードを用意します。そのカードの種類としては、参照カード、連絡・確認カード、サービスカード、分岐カードがります。そこに必要事項を記入し、シートとの関係を明確にしておきます。

もうひとつ、必要に応じてサポートカードを用意します。これは、意思決定を行なうために、例えば計算をしてみるとか、設備の稼動スケジュールが知りたいだとかといった支援機能を記入します。

ここまで書ければプロセス設計はおおかた終わりになります。始点シート－中間シート－終点シートという並びがマクロワークフローになります。そのそれぞれのシートに書かれた内容がミクロワークフロー（情報共有サイトのサイト構造）を表現しています。

中間シートでどんな情報をもとに、誰に確認をとって意思決定（データ確定）し、誰が承認したかを記述し、それをインプットとアウトプットを整合させて途切れずつないで業務プロセスが出来上がることが理解できたでしょうか。

プロセス設計作法について書いてきたが、その作法で表現したいプロセスはどんなものでしょうか。それは再三、言っているように「シンプルで一貫化されたきれいなプロセス」です。

そのためにチェックしておかなくてはいけないいくつかのチェックポイントがあります。それは次の7つであると考えています。

①なぜそのプロセスが存在するかが明確になっているか　【合目的性のチェック】
②業務プロセスとデータが途切れず流れているか　【一貫化のチェック】
③業務プロセスが複雑で分かりにくくなっていないか　【シンプル化のチェック】
④業務機能で似て非なるものを一緒にできないか　【共通化のチェック】
⑤同じ業務処理なのに部署によって違っていないか　【内なる標準化のチェック】
⑥業務機能で例外処理がないか、へんなこだわりはないか　【外なる標準化のチェック】
⑦電子化やシステムに置き換えができないか　【IT化のチェック】

それでは、ひとつづつ簡単に見ていきましょう。合目的性では間違えてはいけないのが、目的の明確化とは違うということである。目的が明確になっていればいいというわけではなく、それが会社の目的とつながっていることが重要です。

一貫化ということでいうと、プロセスが途中で切れてしまっているとか、前後でつながっていないとかがないようにすることです。

シンプル化は見える化の重要な前提条件となります。冗長的なプロセスにならないように、アクティビティの数はできるだけ少なく、分かりやすい構造にしなくてはいけません。

社内には似たような業務処理が散在していることがあります。少しくらいの差だったら共通化したらどうでしょうか。逆に言うと、共通化できる粒度でプロセスを描けないかということなのです。

標準化には内なる標準化と外なる標準化があります。本来同じ業務処理をおこなっているはずなのに、部署によって違うというケースがよくあります。確かに、仔細なレベルではそうかもしれませんが、あるレベルでは標準化できるはずです。

また、業界標準とはかけ離れたり、へんなこだわりプロセスがないかというチェックも必要です。
最後は、プロセスを描いていくと手作業でつなぐケースも出てきます。そんなときIT化をしたらどうかという見方をすることも大切です。

以上、7つのチェックポイントを示しましたが、これまで提示した作法はこうしたチェックが自然にできるように作られています。ここでは、繰り返しませんが、作法のひとつひとつを吟味していくときれいなプロセスのためにそうなっていることがおわかりになると思います。

これからはパターン化の話になります。これまで3回にわたって設計作法を見てきましたが、その作法に基づいてプロセスを記述していくとだいたい同じようなパターンになってきます。

事例をもとにそこを考えていきますが、前にも言ったように、プロセスには顧客起点と内部プロセスがるといいましたが、これからは分かりやすいように顧客起点（広義の意味で従業員起点も含めます）のプロセスについて取り上げてみます。どちらも結局は同じなのですが、プロセスも短くなじみやすいのでそうしています。

前回のデータ項目の例で出てきた見積依頼プロセスについて見ていきましょう。これは、あるお客さんから見積依頼がきて、それに答える形で見積書を提出するというプロセスを想定します。見積の対象は何でもかまいません。プロダクトでもいいですし、工事みたいなものでも、開発工数でもかましません。

作法に従えば、依頼受付は案件管理の仕組みで受けるというようになっていますが、ここでは、簡単にするために依頼をそのまま受付けてエスカレーションするということにします。

まずは受付内容を明確にします。ここでは、ある設備工事の見積依頼として、依頼先部署・氏名(who)、工事名（What）、依頼内容・理由（Why）、場所（Where）、工事希望日（When）、希望施工方法（How to）を確認しておきます。できたら、予算（How much）も聞けたら聞いておきます。

これが分かると、この依頼に対する答えが最終アクティビティのデータ項目になります。そうすると、最終確定データは、「見積作成者」「工事仕様」「納期」「見積金額」などになります。

ですから、これらのデータをどういう順番で決めていくかを並べて“コンテ”を書きます。普通に並べると、まず見積する人を決め、次に中味の仕様と納期を決め、そして最後に見積金額を確定するということになるでしょう。その結果を依頼先に返して、その履歴を保管してプロセスは終わります。これはあくまでサンプルですのでバリエーションはあると思いますが、基本的なパターンになります。

そして、それぞれのデータ確定においては、いくつかの情報を参照することがあります。見積作成の担当を決めるにも、今誰がどんな仕事を抱えていて空いているのかといったこと、工事仕様では過去の工事履歴も知りたいでしょうし、関係部署からのアドバイスも欲しくなります。

また、納期にしても外注業者の状況とか資材の在庫状況もあるかもしれません、そして、金額決定も原価計算結果や業務ルールも参照するでしょう。

そうした各アクティビティにおける関係性について書き出していきます。ここはケースでまちまちですからここまでにしておきます。

ここで気付かれたかと思いますが、依頼されたことを、だれが、どのように、いつまでに作業して答えるかというパターンになります。ただし、それがそのまますんなりと流れていくとは限りません。従って、作業指示を行なう前にレビューというアクティビティを入れています。すなわち、作業前の最終確認で、もしそこでNGなら差し戻すようにします。

一方、アクティビティの中味の方は、参照情報や連携がきまれば、それを情報共有型ウエブサイトに配置し、そこの中で設定された関係する情報を参照しながらデータ確定を行ないます。

この基本的なプロセスパターンを下図に示します。

さて、みなさん、このパターンで様々な業務を考えてみてください。実は、このプロセスは“顧客（従業員）サービスプロセス”と呼べるもので、従来の業務システムでは意外とカバーしきれていない部分です。ですから、以前にも言いましたが、BPMをいきなり基幹のところに持って行くのは抵抗があるかもしれませんが、こうしたところから始めるのがいいかもしれません。

また、ミクロワークフローの実現の場である情報共有サイトや情報参照などではウエブ系の技術が生かされるところでもあります。ここはそうクリティカルなところではありませんので、新技術の適用もやりやすいでしょう。

それでは、宿題です。似たような顧客サービスプロセスである修理サービスについてプロセスとデータ項目を設計してみてください。修理サービスというのは、それこそ修理対象は何でもよく、コピー機かもしれませんし、生産設備かもしれませんが、ここでは店舗の修理サービスを想定してみてください。

フランチャイズ店があってそこの店舗の修理依頼が管理会社に来て、それを施工会社へつなぎ、作業員が行って修理して、修理結果を報告するというプロセスを考えてください。パターンに従って自分で書いてみてください。すぐに描けると思いますがいかがでしょうか。
　

いま、こうして業務プロセスパターンの研究をしていますが、なぜパターン化するのか、パターン化すると何がいいのかといったことを提示しなくてはいけないと思っていたところに、Yuzoさんという方から下記のようなコメントをいただきました。

非常に本質的で、示唆的なご意見だったので、本文で紹介しつつそれに答える形で標題の疑問について考えてみたいと思います。コメントほんとうにありがとうございました。

私もビジネスプロセスを研究しております。

研究にいたった経緯は、企業の経営コンサルティングや事業再生に携わる中で、中長期で成果がでない企業や倒産してしまう企業を目の当たりにして、”なぜ短・中・長期で業績が改善しないのか”を自省も交えて悩んだ結果、ビジネスプロセスに行き着きました。

最近のある企業でCOOという役割を頂く機会があり、試しに商品設計・販促・契約・調達?サービス提供・アフターフォロー・クレーム対応までのビジネスプロセスをすべて1人で行ってみました。試しとは言っても、もちろん、仕入先やお客様も含めて本番です。

ここで、ビジネスプロセスの究極は、1人ですべてを行うことだということに気がついたのです。
逆に言えば、多くの企業は機能別組織で分業化され、階層化されて組織自体が肥大化していくうちに、セクショナリズムや職位やでき、現場（仕入先やお客様）から遠ざかっていることにより様々な問題が行っているということを体感しました。

早速、私は、お客様との面前での反応やお声を拾って、商品設計や仕入先にフィードバックしましたが、あっという間に売上が10倍になったり、提供までのリードタイムが3日→30分に飛躍的に短縮されたり、労働生産性が2倍以上になったりと効果が現れはじめました。

このビジネスプロセスを1人で行ったことの教訓として、

（1）プロセス（人の活動）は標準化すべきではなく、お客様に合わせて柔軟に対応できるように人の活動を見直す

（2）機能（営業部やマーケ部や購買部）でビジネスプロセスを細切れにするのではなく、お客様を基点に商品や地域といったプロセスで組織を再構築する
→こうすることで、営業・マーケ・購買が1つの部になり、その目標はお客様満足や売上として一本化されるため、今までのお客様ではなく各部の上司の顔色をうかがった活動が是正される

（3）経営層や中間管理職は、機能ごとではなく、プロセスごとに責任をもつ
→数字しかみない経営陣や中間管理職は、プロセスに責任をもつようになることで、自ずと現場検証や自分が旗を振ることになり、余剰人員や労働生産性を改善せざるをえなくなる

ほかにも気づきはありますが、このあたりで。

私自身は、上記の理由からビジネスプロセスをパターン化することに意味はないと考えております。
ビジネスプロセスはお客様の心変わりやシーンに合わせて柔軟にスピーディに良いものとして提供するものだと考えているからです。

パターン化してしまうと誰でもできるようになりますが、人は考えて行動する生き物ですから、パターン化せずに個性を活かす方向が自然ではないかと考えています。

では順番にみていきましょう。

「ビジネスプロセスの究極は、1人ですべてを行うことだということに気がついたのです。」

ということですが、ビジネスプロセスは人や組織に左右されるものではなく、あくまでその会社のビジネスにとって必要なプロセスはどうあるべきかを追求したものであるべきです。以前にも書いた作法でもスイムレーンは書かないほうがいいと言ったのはこのことです。

ですから、一人ですべてを行なうことというのは裏返して言うと、プロセスが人や組織を前提としないようになっているからこそ一人でできるとも言えます。しかも一人ですから一貫化されたものになります。

（1）プロセス（人の活動）は標準化すべきではなく、お客様に合わせて柔軟に対応できるように人の活動を見直す

これが、私が主張している2段ワークフローで言っているところです。すなわち、人間の活動を主体にしたプロセスをミクロワークフローとして、その上位階層のプロセスは、システム主体で動かせるマクロワークフローというふうにして分けて考えています。そして、標準化あるいはパターン化すべきと言っているのはシステム主体で構成できるマクロワークフローのレベルのことを指しています。

ご指摘のお客様に合わせて柔軟に対応できるようにするための仕組みはミクロワークフローのレベルのことで、ここは“ゆるく”作りますが、それでもどんな種類の情報をもとに人は活動するのかというようなことはある程度パターン化してもいいように考えています。

（2）機能（営業部やマーケ部や購買部）でビジネスプロセスを細切れにするのではなく、お客様を基点に商品や地域といったプロセスで組織を再構築する

これもその前のご指摘と似ていると思いますが、組織から独立したプロセスにするということと、それが途切れることなく一貫したものであることは大事です。おっしゃるとおりプロセスありきから組織を見ることが必要になると思います。

（3）経営層や中間管理職は、機能ごとではなく、プロセスごとに責任をもつ

この場合、機能の定義がありますが、組織という感じに受け取れますが、そうだとおっしゃるとおり、プロセスごとに責任を持つことが必要です。ただし、この場合でも、誰がどのレベルのプロセスに責任を持つかがあります。トップやミドルマネージメントが現場レベルの細かいところまでは責任をもてませんから、切り分けが要るように思います。

すなわち、ミクロワークフローである現場での単位意思決定（私はこれを機能と呼んでいます）のようなレベルは、現場のリーダが責任を持つものだと思います。

その単位意思決定の連なりとなるマクロワークフローである業務プロセスに対しては、事業部長などのような事業の責任者がその責任を負うというのが必要となります。（中小企業の経営者は別としてプロセスの責任者は経営者ではなく事業部長のような立場の人だと思います)

こうしてみていくと、業務プロセスの階層化という考え方やビジネスの競争力の源泉がプロセスのどこにあるのかといった議論になるかもしれません。

私の主張しているパターン化というのは、マクロワークフローレベルのプロセスパターンとミクロワークフローレベルの意思決定“支援機能”のパターンのことを言っています。ですから、パターン化すべきプロセスとそうでないところがあるということを言いたいのです。

繰り返しますが、お客様との接点のようにケースバイケースで不安定で非定型なプロセスまでパターン化しろということではなく、そこはむしろ“情報共有の場”を提供することで人の知恵や個性が生きるようにすることを提案しています。

最後に、なぜパターン化する（マクロワークフローレベルです）かですが、それがビジネスの競争力の源泉がプロセスにあるのかという提起につながります。言い換えれば、プロセスに差別化要因がなければパターン化してもかまわないとも言えます。

私は、このマクロワークフローレベルのプロセスにはそれがないように思うのです。ですから、工学的な扱いができると思っていて、工学的ということはモデル化できるということで、そのためにはパターン化するということです。

そうすれば、その部分では属人的にならず、人や組織が変わっても、同じようなプロセスを維持できるのでそのたびに変更するようなことをしないですむからです。

このことは、SCOR（Supply Chain Operation Reference model）のような標準化されたリファレンスモデルを見るとわかるかもしれません。

SCORでは、計画プロセス（PLAN）と4つの実行プロセス（SOURCE、MAKE、DELIVER、RETURN）を徐々に分解していきます。ところが、細かく分解していくとだんだ人間系になったり、分岐が増えたり、固有性が出てきます。ですから、SCR自体ではレベル３までが共通フレームワークとなっているわけです。

言い換えると、上位プロセスでは標準化ができているのです。ですから、どこのレベルまで標準化でき、どこのレベル以下は標準化できない（標準化しないほうがいい）かを吟味していく必要があります。私はSCORで言えば、レベル４までを標準化したらと言っています。

では、どこに差別化要因があるのでしょうか。もちろん最大のものは商品やサービスにあるのですが、業務プロセスのところで言えば、私はプロセスそのものではなくて、そのプロセスをオペレーションするところの優劣ではないかと思っています。

迅速で効率的な質の高い、そして顧客満足度を高められるオペレーションができるかどうかで差がつくように思うのです。そこでは、的確な業務ルールや判断基準、優れたリソース、有益な参考情報取得、さらに不断の改善努力などが相まって他社と違うビジネスオペレーションを実現し、それがビジネスに貢献していくのではないでしょうか。
　

最近は原作がある映画が多いような気がする。特に漫画を原作としたものも多い。この李闘士男監督の「デトロイト・メタル・シティ」も人気漫画をベースにしているらしい。らしいというのは、読んだこともないし、知らなかった。

映画の中味から少し離れるが、この原作があるときの映画の評価は微妙だ。当たり前のように、原作よりいいか悪いかという評価がされてしまう。

よくユーザレビューみたいなサイトで、出てくる批評が、「原作と違うからよくない」というのがある。これは批評にはなっていないのであって、映画になったとたんに原作とは無関係に独立した作品になる。

従って、原作が書かれた媒体がいいに決まっていると思うかもしれないが、原作より映画の方が面白いというケースもある。

例えば、つい最近テレビで放送していた「東京タワー」を観たが、これは本よりも映画の方がよかった。
以前にこのブログでリリーフランキーの原作本を読んでそれについての記事を書いたが、あまり評価していなたかったのだが、映画の方が面白かったのである。

さて、デトロイト・メタル・シティのことである。若杉公徳原作のコミックで大変人気のある作品を映画化したものである。主演は松山ケンイチで、普段は内股で歩くような大人しい子が、デスメタルバンドのボーカルになると全く逆のキャラクターに変身してしまうという役柄を見事に演じている。

ただ、それはそれで面白いのだが、原作の漫画を読んだこともないので分からないのだが、原作では多分コマから飛び出しそうな迫力で描かれていると思う。何とも劇画的なシチュエーション設定だし、登場人物もそうなのだ。その荒唐さを実写化するのは難しいということかもしれない。

まあ、主演の松山ケンイチ、加藤ローサもがんばっているし、宮崎美子の母親もいい味出していたし、それより何より松雪泰子の女社長は見ものである。だから、もうちょっとなんだなあ。
　

マクロとミクロの2段ワークフローでプロセスを設計していくと、ミクロワークフローすなわち単位意思決定のアクティビティでは様々な情報を参照することになります。ある意思決定（データ確定）を行なうために、様々なデータベースを参照したりルールや基準に基づいたりといったことが起こります。

そのために必要な情報類を配置するわけですが、そういった情報にはどんなものがあるかを考えてみましょう。参照情報の種類を次の８つに分類してみました。

①業務ルール・判断基準
②マスタデータ
③履歴情報
④計画情報
⑤リソース状況
⑥外部環境情報
⑦シミュレーション・計算結果
⑧契約・規制

業務ルールや判断基準については、意思決定では不可欠の情報になります。この業務ルールや判断基準が競争優位の源泉だったりしますので、きちんとルールに従うということと、絶えず実績や環境変化に応じてブラッシュアップすることが大事になります。

マスタデータはいわゆるマスタで顧客、商品、取引先、従業員などのデータです。

履歴情報は文字通り過去に行なったプロセス実行の結果を参考にします。なんだかんだと言ってもあの時はどうだったかいう情報は貴重です。前例踏襲では進歩がないかも知れませんが困ったときは有効です。

計画情報というのは参照情報ではなく、プロセスに組み込まれるものだと言われるかもしれませんが、だいたいが実行プロセスに直結するような計画プロセスは少ないように思うのですがいかがでしょうか。それはそれとして、例えば予算なども計画情報と考えればよく参照することになります。

リソース状況というのは、ヒト・モノ・カネという保有資源が今どういう状況にあるかということで、マスタデータということでもあるのですが、もう少し現状で動いている状況も知りたいものです。例えば、担当者をアサインする場合、誰が今どんな仕事をしていて、あるいは予定が組まれているかだとか、設備の稼動状況なども重要な情報となります。

外部の動向といった情報も時として参照します。同業他社あるいは業界の動きなどやそれこそ為替レート、原油価格などといったものもあるかと思います。

意思決定する場合、単に今ある情報を参照するだけの場合もありますが、一旦計算してみてとか、シミュレーションをしてみてとかいったことも考えられます。与信チェックなんかもある意味シミュレーションのようなものでしょう。今風の言い方だと意思決定のためのサポートを外のサービスから得るということかもしれません。

最後の、契約や規制はコンプライアンス上必要ですから、いつでもチェックできるようにしておく必要があります。

その他にもあるかもしれませんがおおかたこんなところだと思います。これからの時代、どんどんデータは蓄積され、またクラウドでも膨大な情報が格納されて、いくらでも使えるようになっています。しかし、それを活用しきっているかというとまだぜんぜんできていないように思います。

そういうとすぐにデータウエアハウスを作ってBIツールでデータ解析しましょうというような話になるのですが、そのデータ活用をどんな場面で行なうかの議論ができていないように思います。単に個人の知的生産性の向上のためでは限界のような気がします。

そうではなくて、ビジネス実行の場面でより質の高い意思決定をするために活用することでデータの価値が生かされると思います。そのための第一歩として、業務プロセスと参照情報の関係をきちんと整理して、そこに有用なデータを配備することから始めることが重要であると考えています。
　

近頃、コミュニティばやリである。どうもこの言葉の響きから何やら居心地のよさそうな感じがする。しかし、居心地のいいことがいいコミュニティかというとそうでもないのではないだろうか。単なる仲良しクラブじゃんという思いもある。

そんなわけで「サロン化のワナ」というタイトルでこのことをエントリーしようと思っていたら、同じようなことが書いてある本に出会う。「社会をつくる自由」（竹井隆人著　ちくま新書）である。著者はまだ40歳の気鋭の政治学者で集合住宅を通して社会を見ている。

まずは、「通俗的なる自由」と「社会をつくる自由」との対比を見せるが、この「社会をつくる自由」があまり聞きなれないし、よく分からない。そこで著者は、ゲーテッド・コミニティというコミュティを持ち出す。

このゲーテッド・コミニティというのは、“全体の周囲に、高い塀やフェンスといった外壁を張り巡らせて、取り囲み、その出入りは監視を施した数箇所のゲートに限定するという多数の住宅で構成される居住区“をいう。アメリカでこういう言い方で呼ばれるようになったが、日本では分譲マンションがそれに似ている。

著者は、この分譲マンションの管理組合のような組織に参加していくことが「社会をつくる自由」を得る萌芽になると述べている。すなわち、仲良し同士で好き勝手に自由気ままに振舞うことではなく、利害が一致しないかもしれない人々とのコミュニティこそ、個人が社会と向かい会う場なのであるということである。

そしてそこには、「責任」ということが自覚されなければいけないと言っている。単なる仲良しコミュニティの無責任さに異議を抱いている身にとっては納得である。

その他、住民運動、エコロジーやコンプライアンス、格差論議などの「いかがわしさ」もすぱっと切り捨てる。かなりの部分共感できて、読んでいて気持ちよくなる。

結局、「集合住宅デモクラシー」という概念を提示しているが分かるようでわからないところがあるのでよく考えてみたいと思う。集合住宅に入れない人はどうなるんだろうかとか。

それと、コミュニティというとネット上のコミュニティのことが言及されていないのである。そこのところは現代では重要なテーマであると思うので、ネットのコミュニティが仲良しクラブなのか、それとも新たな個人と社会の関係性をもたらすものであるのかを論じてほしかった。
　
　

ついにW杯本出場を決める。昨日のウズベキスタン戦で前半早々の岡崎の得点を守りきって、１－０の薄氷の勝利。やったぜ。

もうひやひやの連続で、こんな試合展開だと以前の日本代表だったら後半終わりぐらいにポンと点を入れられ引き分けていうことになっていたかもしれない。それを０点でしのぎきったことはこのチームの成長を感じる。

ただ、言っちゃなんだが、この程度の相手にあんな試合をしていたのでは本大会では勝ち進めないだろう。まあ、グランドコンデションや無茶苦茶なレフェリーなどの悪条件があったとしても、もう少し自分たちのペースへ持ち込めないといかん。ほとんど相手のサッカーにあわせていただけで、だから後半になっても相手が疲れるよりこちらが疲れてしまっていた。

でも、勝ったのだから素晴らしい。さて、これからは本大会でベスト４をめざすのだから、そのための準備をしてほしいが、キリンカップで見せたようなサッカーをどんな条件でもできるようにさらに磨きをかけて欲しいと思う。
　

2000年から住友信託銀行が一般の人から応募した「60歳のラブレター」が8万通以上になったそうで、それを元に作られたもろベタな題名の映画「60歳のラブレター」には3組の男女が登場する。

メインは、中村雅俊扮する大手建設会社で専務まで上り詰め、定年を迎える夫とその妻原田美枝子、そして、医者で妻と死に別れた井上順と売れっ子の翻訳家戸田恵子の恋愛、そして魚屋でありながら昔フォークソングバンドで歌っていたイッセー尾形とその妻綾戸智恵という豪華な顔ぶれ。

この三組がそれぞれ微妙に絡みあって展開する物語が、錯綜しているようでいてうまい具合に流れに合っていて、それだけでも古沢良太の脚本と深川栄洋監督の演出に拍手したくなる。

何を隠そう（別に隠すことでもないが）ぼくはただいま60歳だから、もうオレは中村なのか尾形なのかと思い、井上の立場もいいなあとかすごいリアルな感じで観た。

それにしても、みんなカッコイイというのが正直な感想なのである。まあここに登場するストーリーは劇的だが、誰にでもプチ劇的なことってあって、例えばぼくの場合、井上順にはなれないが、中村雅俊のエピソードで言えば、やっぱり30年前の気持ちがどうだったのかという問いに思わず引くし、30年間仕事優先できたかもしれない。しかし、ぼくはかろうじて定年前にそれを打ち破るべく早期退社をして、会社で定年を迎えることは回避したのである。

この3組で、いちばん感動はイッセー尾形と綾戸智恵の夫婦かもしれない。ネタばれになるのであまり言わないが、入院して大手術をしてその回復を待つ夫が、妻の前で奏でるギターなんてしびれますよね。しかも曲が、「ミッシェル」なんですよ。ということで、ぼくも昨年妻ががんの手術をしたので、そんなとを思い出すのである。

いずれにしろ、熟年男女が交わる愛のメッセージに驚かされる。ぼくらの年代ではそういうのをキザといったんだけどな。この3つの手紙が選ばれた時点でもうこの映画は出来上がりだ。あとはそれに向かってストーリーを考えるだけでいいくらいに、秀逸な手紙である。

先週も大学の研究室のクラス会があって、北九州や名古屋、静岡から来てくれて、女性一人を含めて6人が集まって呑んだのだが、名古屋から来たT君が、奥さんが最近小説を書き出したというのである。

そして、非常に奥さんに感謝していて、というのも自分の両親の世話をして見送ってくれたので、これからは彼女の好きなようにやらせてあげたいし、そのための協力は惜しまないというようなことを言っていた。映画のようにカッコよくないかもしれないが、なんか素直に感動したのである。

結局、この世代は高度経済成長の中で結婚して仕事一筋で、そして妻たちもまだ良妻賢母思想の残りかすがあって、そんな夫婦が量産され、その後時代は変わっていきいつのまにか遺物のように扱われ、それぞれがどう対処していいのかおろおろしたというのが正直なところではないだろうか。

しかし、この映画を観ていると60歳といってもまだまだこれからという感じになる。60歳前後のひとを“アラカン”というらしいのですが、このアラカンだけではなく、若い人にもぜひ観てもらいたいいい映画です。
　

なぜプロセス志向が保守とか運用に影響を及ぼすのかを考えてみましょう。一見変化がないように見える領域ですが、実は大きな変化というか、変革をもたらすのです。というより、ここが非常に重要な意味を持つようになってきます。システムを作ることより、それを保守し、運用することのウエイトが相対的に高くなってくるのです。

プロセス志向では、業務プロセスを効率的に動かしてこそ事業に貢献できるということを重要視しています。オペレーションエクセレンスが主要目標になります。それは一時的ではなく、継続的な営みでもあり、不断のブラッシュアップが欠かせません。

こうしたパラダイムに適応した保守・運用とは一体どういうことになるのでしょうか。従来の保守・運用管理はシステムがダウンしない可用性や安定性を保持し、正しくデータを更新することに重きが置かれていました。いわば、ちゃんと決算ができることを担保することです。

ところがプロセス志向では、もちろん今のことは大事であることは言うまでもないのですが、それに輪を掛けて業務プロセスの稼動状況を把握し、適正にオペレーションできているかが大事になります。そのために、BPMSにはプロセスの制御や監視の機能が装備されています。

大事なのは、その機能を有効に使うには、“だれがどこに責任をもってオペレーションしている”かを明確にする必要があるということです。いままでだと、どちらかというとシステム側の稼動についての責任という見方でしたが、これからは、ビジネス側のプロセスオペレーションの責任が問われていくようになります。

実際にそうしなければ意味がありません。だから、基幹業務ではアウトソーシングなんてできないはずで、しっかりと自分たちの手でControl&Operation をしなくてはいけません。
　

日本が近代で初めて対外戦争を仕掛けた日清戦争がどんなものであったかは、歴史的事実としてある程度は知っているが、国民の目線で戦争をどう感じていたかはわからない。そんなアプローチで書かれた「日清戦争　「国民」の誕生」（佐谷真木人著　講談社現代新書）を読む。

ですから、この本に出てくるものが、新聞、唄、演劇、子供の遊びといった社会現象的な捉え方が多くなっている。

この戦争は「巨大な祝祭だった」と述べているように、国民がこぞって参画し支持したものであり、国中が浮かれていたのである。今から考えると信じられないほどナショナリズムが芽生え、一丸となった。

その空気を作ったものにメディアの存在が大きいことが書かれている。この場合のメディアは新聞である。それまでは、世の中に伝播する大きなメディアがなかったが、この戦争では、やっと出てきた新聞ジャーナリズムが重要な役割をはたすこととなった。

はじめて従軍記者なるものが登場し、戦争を報道したわけではあるが、それはみな日本軍を称賛する記事で溢れるのである。それでしか、戦争の実像をしりえない国民はその記事を見て熱狂したのは言うまでもない。

そうした雰囲気の中で醸成されたのが、これまで歴史的に日本と中国との関係は対等に近いものがあったのが、日本の優位性、先進性を共有するようになり、“文明的に遅れたかわいそうな中国を救ってやるのだ”という驕りである。これはずっと引きずっていく。

それは、別の意味で「国民」が形成されたことであり、「国民国家」の誕生でもあったのだ。そして、その国家がご存知のように後のいくつかの戦争を経て、太平洋戦争で破滅するのである。しかし、その太平洋戦争と日清戦争とでは国民の意識は大きく変貌しているように思う。

ただ変わらないのは、メディアの影響力の大きさであろう。結局、言論を封じ込んで広範で柔軟な議論ができないように規制して、いつのまにか偏狭な“空気”を作ってしまうのであるが、それは今も残っているようで怖ろしくなる。

たかだか百十数年まえの戦争であるだが、今とはずいぶんとかけ離れた景色であり、国民感情である。しかし、同じ国民があれほどまでに熱せられることがあったということを知るだけでも価値があるのでご一読を薦めます。
　

先日、いつも見る数少ないテレビ番組のひとつである「情熱大陸」で水戸岡鋭治という工業デザイナーが紹介されていた。この人は、九州の鉄道車両のデザインを手がけるというユニークなデザイナーで、番組でも猫電車が登場していた。

年齢が62歳だからぼくらの同じ団塊の世代である。すごくエネルギッシュな人で見ていて感動したので、その人が番組の中で語ったことで印象に残ったことばをいくつか書く。

・ 売るためではなく使うためにデザインする

工業デザインの本領はこの“使うため”ということが非常に重要で、えてして見てくれだけでかっこいいものを作ればいいとなりがちだが、この機能性を追求することを忘れてはいけない。

・ 良いデザインではなく正しいデザインをする

ここらあたりも分かるようで難しいところだ。この違いをぼくなりに考えてみた。“良い”ということは、皆あるいは多くの人にとって“良い”ことはあり得るのだろうか。かなり難しいことのように思える。それに対して“正しい”ことは、普遍的であり、どんな場合にも通用することのように思える。ですから、まずは“正しいデザイン”をすることなのである。

・ 並走しないと若い人は育たない

上からの目線で教えてやるではなく、一緒になってやってこそ覚えるし、育つのだ。

で、この番組を見ていて、そうだ業務システムにも工業デザインの考え方を採り入れたらいいのではないかと思ったのである。この後見た「カンブリヤ宮殿」に出ていた川崎和男のこともあって、なおさら意を強くしたのである。

これまでの業務システムのユーザインターフェースをとってみても、決して使い勝手をよく考えてデザインされているわけではないと思う。大体のケースではIT開発者が従来の形態をなぞるようにして決めていることが多い。あるいは、最近ではウエブデザイナーが見た目はかっこいい画面を作ったりしている。

そうしたユーザインターフェースは本当の意味で使うひとのことを考えているとは思えないのである。どんな人がどういう仕事をこなすためにその画面を使っているのか、どんな機能がそこでは優先度が高いのかといった考察がなされているのだろうか。

場合によっては、同じ業務でもやる人によってインターフェースが変えた方がいいかもしれない。システムを操作するんだから、もう少しその操作性に気を使った方がいいと思う。

どうもこれからはこうした発想を持つ必要があると最近特に感じるようになった。そのためには、「使うための正しいデザインを若い人たちと一緒に考えて行こう」と思うのである。
　

もうまったり感いっぱいの映画「ジャージの二人」を観るとこちらも何となくまったりとしてくる。監督が中村義洋で「鴨とアヒルのコインロッカー」や「フィッシュストーリー」とはまた一味ちがう作品で、でもこういうのって嫌いじゃないです。

ストーリーは、避暑地に出かける親父と息子が別になにかするわけではなく、ぼーっとひと夏を過ごすのである。だから、特別のエピソードもなく、静に時が流れていくのだが、そんな中でも少しずつお互いのいま置かれている現実が垣間見せられる。そのじわっと来るリアル感が避暑地の生活との対比で滲みてくる。

この親子二人を演じているのが、シーナ＆ロケッツの鮎川誠と堺雅人である。外見は全く異質であるが、二人の会話を聞いていると何気に親子らしさを感じてしまうほどうまく演じていた。

特別のエピソードがないかわりに、コネタがぽんぽん飛び出してくる。だいいちジャージを着るという設定からしてそうだ。そして、携帯のアンテナやファミコン・ビデオネタとかBLTサンドイッチとトマトの絡みとか、化膿症と和小の混同などそこら中に埋め込まれている。それを見ながら、クスッと笑うのもこの映画の楽しみ方のひとつでもある。

ということで、ぐずぐずしないではっきりしてよと言っているような人はダメかもしれないが、“なんとなく”という雰囲気が好きなひとには面白い映画である。
　

ここに、「ITスキル標準　V3　2008」がある。これを参照しながら、プロセス志向における必要人材やスキルセットを考えていきましょう。

プロセス志向と言った場合、まず浮かぶのはプロセス設計のところだと思います。ビジネス要求を解析してそれを業務プロスに落とし込むところです。そこの役割を担うのはITSSではどのスキル標準なのでしょうか。

基本戦略系のコンサルタントでしょうか。それともソリューション系のITアーキテクトあるいはアプリケーションスペシャリストでしょうか。どうもいずれもちょっと違うように思います。ということは、業務プロセスを設計する人材のスキルセットがないということになります。

経営とITの融合とか言っていてもそこの橋渡しをする人材を定義していないのです。先日もこのITSSに実際に携わっているひとと話したときも、ここが抜け落ちていることを認めていました。

これからはビジネスアナリストとかビジネスプロセスデザイナーといった、名前はともかくとして、そうした役回りの人材を置くことが非常に重要になってきます。経営戦略や事業実行方針をちゃんと理解し、それをITで実装するところをマネジメントできる人たちである。

さて、先回のプロジェクト編でも書いたように、プロセス志向では、少数精鋭で素早くプロジェクトを回していくようになるわけで、そうなると、必然的に多能化ということは避けられないと思います。ですから、ITSSにあげられているような細分化したスキルではなく、もう少し広い範囲の能力が要求されてきます。

そして、大きくビジネスエンジニアとテクニカルエンジニアの2極分化と相互融和が図られるものと推測しています。すなわち、ビジネスの要求をきちんと理解し、その業務プロセスをどう実装するのか、どうオペレーションしたらいいのかを的確にユーザに提供できる人材とビジネスを俊敏かつ効率的に回すための仕組みに必要な機能を設計し、コーディングできる人材である。さらに、この異質の人材同士でコミュニケーションが取れることも必須である。

ITSSもそうですが、各企業のなかでもこうした必要人材の配置を急ぐ必要があると思います。ただし、そうはいってもという事がもちろんありますので時間がかかるかもしれません。さらに、こうしたスキル価値が変化するわけですから、従来のように仕様書に基づいてコードを書いていた人たちはどうなるのかという問題があります。

きれいごとで言うと、ビジネス寄りにいくか、クリエーターとして究めていくかになりますが、もうひとつは、運用エンジニアとして生きる道もあるような気がします。運用といっても従来のようなシステム運用というより、ユーザが行なうビジネスオペレーションに対するサポートという領域が重要になると思っています。

少なくとも、これからの必要人材スキルは変化していくものと思われるので、ITSSにとらわれないで今のうちに準備しておくことかもしれません。

この陳腐な表現が似合うような騒動が鳩山総務相辞任だろう。日本という国もずいぶんと暇な国とあって、民間の会社の社長を気に食わないからといってあれだ叩く政府首脳もひどいものだ。こういう政治的な話題に突っ込むのは嫌いだが、この件はひとこと言いたくなる。

鳩山総務相は辞めるとき「政府に尋問の筋これあり」という西郷隆盛の言葉を引用したらしいが、「征韓論」と「かんぽの宿」を一緒にする感覚がわからない。

そういえば、この人の感覚はひどいもので、草彅剛のときも「最低の人間」といったらしいが、あんな事件？を一面で乗せる全国紙と同じように感覚がおかしいでしょ。それとずっと前に定額給付金のことでインタビューされたとき、これを何に使いますかと問われ、おいしいうなぎやさんがあるのでそこのうなぎを食べますと言った。まあ、目くじらを立てることじゃないかもしれないが、思わずのけぞった。

正義の味方は「月光仮面」だけでいいから、もっと“政治”をやってほしい。総務省の官僚と戦わなくてはいけないのにどうもつるんでいるように思える。

自民党の幹事長が、国民は鳩山総務相の味方であるみたいな発言もしているようだが、それはテレビや新聞のアンケートに基づいて言っているだけで、それが正しい世論だと思っているのだろうか。そんなミーハーなポピュリズムで判断している党の重鎮もいかがなものだろうか。

同じときのニュースでイランの大統領選挙の報道があったが、両国民のあまりにもかけ離れた切実さになんとも複雑な思いにかられたのである。
　

この挑戦的なタイトルに惹かれて読んだ。「ウェブはバカと暇人のもの」（中川淳一郎著　光文社新書）は、インターネット上のニュースサイトの編集者である著者が、ネットの幻想はもう終わったと宣言し、題名のとおり、バカか普通の人で暇をもてあましている人たちのものでしかないと言っている。

おりしも梅田望夫のインタビュー記事が話題になっていて、以前Twitterで、「はてな取締役であるという立場を離れて言う。はてぶのコメントには、バカなものが本当に多すぎる」といってしまってブーイングを受けたことなどに言及していて、この本でも梅田さんは「頭のよい人」にまつわる話であって、「普通の人」「バカ」について書くのだと言っている。

要するに、ネットの世界はそんないいことばかりではなくて、気持ち悪い世界なのである。そして、テレビを越えるとか喧伝されてきたけど、やっぱりメジャーはテレビで、たとえば芸能界の大御所はブログなんて書かないし、有名になりたかったらテレビに出るのが一番である。さらにネットはいつもテレビネタが満載なのであるというような話である。

確かに、Web2.0がもてはやされたころには、ネットの未来は明るいと誰でも思ったが、双方向コミュニケーションといったって、頭にくるコメントで埋め尽くされたり、誰でも情報発信できると言ったって、どこのラーメンがうまいとか、うちの猫がかわいいと言われても何もおもしろくない。

そして、みなが同じようにググルわけだから、同じ情報をもち、モツ煮のうまい居酒屋は決まっていて、そこで誰かがブログに書いたとおりのメニューを頼んで、いい店発見と書く。

著者は気持ち悪いと書いていたが、僕は気分が悪くなると言うほうが当たっている。だいぶ前になるが、IT関連の大きな情報サイトであるテーマで会議室を開いたことがある。専門のサイトを作ってと考えたが手っ取り早いのでもともと備わっていた機能を使ったのだ。

ところが、最初にうちはよかったのだが、だんだんアクセス数が増えてなんと一日6000くらいまでいったのだが、そうなると多種多様な意見が書き込まれてきて、収拾がつかなくなる。なかには、最初からけんか腰みたいな人もいたり、売名行為か金儲けでやっているんだろうなんていうコメントがあったりして、とても不愉快になったりする。

本当は、出した意見をきちんと理解しそれで反論なり意見を言うというのが筋だろうが、そうした真の双方向コミュニケーションなんて無理だと知って、途中でやめてしまった。まさしく、厭な気持ちになって気分が悪いのだ。

ただ、ぼくはこうして毎日ブログを更新しているが、そういう範囲ではネットに過度に期待もしていないし、失望もしていない。

この本で少し注文があって、確かにネットはバカと暇人のものかもしれないが、頭のよいひとも徐々に入ってくるような気がする。ネットはうるさいということを前提として、そうした雑音をスルーする術を知った人たちが増えてくると思う。

それと、今は企業もネットに幻滅させられたと思うが、よくその失敗を精査するとともに、その技術と精神を不特定多数の「バカ」と「普通の人」を相手にしなくてもすむ企業内の仕組に組み入れることがこれから求められてくるようにぼくは思う。

こうした本を読んで、一度ネットのもつ理想と現実、光と影、陰と陽を見直してみるのもいいことだ。
　

この映画も癒し系のようだ。吉田恵輔監督、宮迫博之主演の「純喫茶磯辺」はそんなほのぼの感のある映画だ。

妻が家を出てから仲里依紗扮する高校生の一人娘と暮らすダメ親父が、父親の遺産が入り、何を思ったのか喫茶店を始めるというところから話が始まる。喫茶店といっても今様ではなく昔のあの喫茶店でセンスがわるい店である。

当初はお客が来なかったが、麻生久美子の謎の女の子がコスプレでウエートレスをするようになると客も増えてくる。そこで織り成す男と女のエピソードが展開される。宮迫の親父と麻生久美子、仲里依紗の娘と客の変態男、そして、もとの妻との関係、元彼との関係とそれぞれが少しずつ“外れた”キャラクターなのである。

ここではストーリーというより、出演者の演技力の方が注目といったところで、仲里依紗と麻生久美子、別れた妻役の濱田マリの3人の女優さんが健闘している。仲里依紗のほうとうに自然の演技はすばらしい。いまどきの高校生ってこんな調子なんだと思わずすうーと入ってくる。

また、麻生久美子はかわいい顔をしながら偽悪的で何を考えているのかわからないという女を演じていて、結局不器用でうまくいかない感じを好演していた。

こういうお決まりの小ネタをはさんだほのぼのとした映画もいいけど、なんか見終わってうんよかったねくらいで、やはりインパクトが薄いような気がする。なにも派手にやれということではないがずしってくるやつがほしいのだが。

2,3日前いつもBPMオフ会でお世話になっているwkzkさんのブログ「今年は違うよ、わきぶろぐ！」で「ボケて」というサイトが紹介されていた。

このサイトは実は僕の息子とその友達で作った会社「オモロキ」から提供されているものです。昨年の9月に公開されて、今年の5月にガンマ版にバージョンアップしたので、その紹介を載せようと思っていたのをそのままにしておいたので、この機会に遅まきながら触れておきます。

このサイトは「写真大喜利」といった趣で、ネット上の写真をネタにそこにひと言かぶせるわけです。見るだけでもおもわず吹き出すような言葉もあっておもしろいし、自分で投稿するとなおいっそう楽しくなります。

これに対する最大のほめ言葉は、WKZKさんが言った”本当にくだらなくて最高です！”ではないでしょうか。

この3月には書籍化もはたしましたので（コンビニとAmazonで売っています）、ぜひウェブと本の両方で楽しんでください。
　

さて最終回は、ユーザとベンダーの関係の変化、あるいはIT業界にもたらす影響などについて考えてみましょう。

これまでの議論で、システムの構造から設計・開発や運用のやり方、プロジェクトの進め方、必要人材など多くの領域でこれまでとは違ったものになっていくことがお分かりになりましたでしょうか。

そうした変化は当然、ユーザとベンダーの関係にも影響していきます。直接的には、プロジェクト体制やマネジメントが変わって行くでしょう。

ここでこれまでの両者の関係をみてみましょう。簡単に言うと「情報の非対称性によるインセンティブの歪み」が特徴的であるように思います。

どういうことかというと、情報システムに関する情報は、専門家であるベンダー側のほうが圧倒的に情報を持っていて、ユーザ側の持つ情報は多くはありません。まずは、この情報のアンバランスがあります。

こうしたアンバランスがもたらすものは何かというと、悪く言うとベンダーが何をしてもユーザはわからないということなのです。ですから、ユーザはベンダーから開発にこれだけ人月がかかりましたからお金をくださいと言われても、高いけどしょうがないなあと言って支払うのです。こんな関係がいいわけありません。

こうした歪みを修正できる可能性がプロセス志向にはあります。なぜなら、ユーザが自分たちで作りたいと思ったシステムがそのまま実現できるようになり、しかも初期の段階でその姿が見えるようになるからです。

専門的、技術的なものは隠蔽されたビジネスコンポーネントをベースにユーザとベンダーが会話するのです。

こうしたことは、ユーザにとっては僥倖ですが、ベンダーにとってはどうでしょうか。問題はここにあります。このモデルでは、おそらく従来のようなコストとは全く違ったものになるはずで、大方のケースで低く抑えられるようになります。

ウオーターフォール用にたくさん抱えた人材を遊ばせることになりかねないので大変なことになってきます。だからといっていつまでもユーザが知りませんということはないのであって、徐々にユーザは気が付き出しています。

普通に考えれば、ITはそもそも使われてナンボですから、使われ方や使うものが変わったら、当然そのビジネスモデルも変化するのです。それを、自分たちのビジネスを守るために、ユーザに不当に費用を負担してもらうなんてことは本末転倒なのです。

そういう意味では、ベンダー側がユーザより先んじてビジネスモデル、収益モデルを変えていく必要があるのですが、どうも自己保全に軸足がいっているようでお先が思いやられます。こんことをしていると、わが国のSIerと呼ばれる会社はどうなるかはおわかりですよね。
　

SIerのユーザに対する不満によくでてくるフレーズは、「要求をまとめてくれない」「仕様を決めてくれない」というものがある。だったら作らなけりゃいいと思うのだが、そんな状態でもシステム開発プロジェクトをはじめてしまうという変な産業なのである。

どうしてそうなっているかというと、人を抱えたベンダーはシステム開発をやり続けなくてはいけないのだ。一所懸命になって、「こういうことでしょ」「こうしたらいいでしょ」とユーザに言って、やみくもに突っ込んでいく。

ユーザにメリットがあろうがなかろうがどうでもいいことで、ただプロジェクトを起こせばいいというだけのインセンティブで動く。それで、ユーザはというとできてから、お前らの言うことを聞いて作ったけどこれじゃあダメなんだけどと言う。すごい世界だと思いませんか。

これは、単純にSIerを非難しているわけではない。もちろんユーザも悪い。そうした構造、関係性が歪んでいると言っているのである。それを気がついているのかいないのか誰も言い出さないというのが怖しいのである。

今から、その怖しいことを言う。SIerはおせっかいをやめたらどうだということである。ユーザに対して、こうしろああしろと言わない。ITがKPIだとかROIなんて言わないのはもちろんのこと、ユーザ側から要求仕様がちゃんと出てきたらやるという風に変えてしまうのである。

そういうと、ユーザがその要求仕様が作れないから困るんだとすぐ言うが、それでもいいじゃないかということだ。すなわち、この部分はユーザに責任をもってもらうっていう当たり前のことなのだ。

結局要求仕様というのはビジネスとしての要件が最初に出てくるわけだから、そのビジネス要件を満たすものができれば、どういう効果をもたらすかはユーザが責任もって定義したらいい。その投資対効果で実施可否を決める。

従って、両者の関係は、ビジネス側から見ると、要求はこちらでちゃんと考えるからとやかく言うな、そのかわりITでそれをきちんと実現してくれとなる。一方、IT側から見ると、ビジネス要求をちゃんと定義してくれたら、それを効率的、機能的に作ってやりましょう、あるいはこんなソリューションを使えという関係になる。

しかし、こんなことを実際にやろうとするとすごい構造改革となる。従来のビジネス形態がまるで変わってしまう。ただ、ここを突破しないと、ビジネスとITのWin-Win関係は永遠にできないはずである。もちろんなかにはこうしたことを提言する人もいることはいるが、しょせん双方から“野次っている”だけなのである。

ではここを打破するにはどうしたらいいのだろうか。ぼくは、「ベンチャーが実績を積むこと」だと思っている。使う方も作る方もベンチャーがやって、今言ったような関係を作ってしまうことをぜひ実行してほしいと願っている。そのためにクリアーにしなくてはいけないことをよく考えて乗り越えてもらいたいのである。それこそ若い元気のある人たちの出番である。
　

昨日は、夜にBPM協会のワーキンググループの会合があったので、サッカーW杯予選の最終戦の中継が見られなかったので、帰ってから夜中に録画を見た。

この試合は２－１でオーストラリアに負けたが、両者モチベーションがあがらない中で、両チームともセットプレーでしか点が入らないという凡戦だったのであまり中身のことには言及しないで、テレビの見方のことについて書く。

いや、別に大それたことを言うわけではなく単に”消音”にして見ていたということだ。要するに、テレビの実況と解説の音声を聞かないで画面だけを追ったのである。これがまたよかったという話である。

もともと、テレビ朝日の松木のぼんくら解説を聞きたくなかったということもあったり、ただわめくだけのアナウンサーにも辟易していたので、ちょうどよい機会だからそうしてみた。

こうしてみると当たり前だが、変な解説で見方がゆがめられているのがよくわかる。実に冷静に広く見ることができる。どうしても音声で表現しているシーンに眼がいってしまうが、無音だと自分の切り口で見ることができる。

だから、昨日はオーストラリアの側で見ることをした。オーストラリアがどうしたら日本の守備網を破るのかとか、日本のサイド攻撃をどう防ぐのかという見方である。

岡田監督も試合後のインタビューで崩されていなかったと言っていたがそのとおりでオーストラリアの攻撃は単調でただ個人の能力で突破することしか考えていないのが分かる。しかし。そんなチームに勝てないのだから情けない。

まあ、昨日はセットプレーでやられたわけだが、あの高さに阿部勇樹ではつらいのだ。１点目なんか闘利王ひとりにケネディとケーヒルの二人が襲いかかってやられている。やはりこういうチームにはでかいセンターバック2人が必要なのだろう。中沢と闘利王のどちらかが欠けるとこうなってしまう。

ワールドカップまで1年、センターバックの発掘といまいちど人もボールも動くサッカーの習得なんだろうな。
　

一昨日のエントリーでユーザが本当にシステム化を必要とし、何を実現するか明確になったたときにこそITの導入をすべきで、そうした関係を築くには使うほうも作るほうもベンチャー企業同士でやったらどうかという提案をした。

どうしてそう思ったかのそのヒントは、先日ある若い人と呑んでいたとき聞いた話にある。彼は、コンサル会社を経て、事業再生を行う会社で実際に破綻した会社を再生させる仕事やっていた。

そのとき、再生のためのシステム再構築を検討するのだが、もちろんお金がないから、本当に必要なのかを見極めること、あるいは必要なところだけに投資すること、そして何よりも安いコストでなくてはやれないことを突き詰めざるを得なかったということなのである。

そして、それを実行するためには、名だたるSIerは問題外で、名は知られていないがキラリと光るものをもっていて、ユーザのために早く安く作ってくれるところを必死に探したという。実際にそういう会社があるのだそうだ。

そして、導入ではそうしたある意味チャレンジャブルな方法でやっても、誰も文句は言わない。既成のそこそこ業績をあげているような会社では、必ず壁になる社員がいるが、一旦つぶれた会社は、そんなことを言っている場合ではないわけで、這い上がるために改革しかないからである。

ぼくは、ここにシステム化の原点を見る思いがする。

今言ったような既成の会社は、誰にも文句を言われない無難な方法で、しかもお金もそこそこあるので、安心して頼めるなじみの会社にやってもらうというのが多く見受けられる。

お互い持ちつ持たれつの関係でずーっときている。ITがあるいは導入したシステムが役に立とうが立つまいが関係ないのであって、両者は継続的にプロジェクトがあることが重要なのである。

だから、お金がない、しがらみがない、既成概念がない、そんな会社が初めて正しいシステム導入ができるような気がしたのである。それに該当するのが、破綻して再出発しなくてはいけない会社なのだが、そんな会社は数多くあるわけではないので、それと似たような環境ということでベンチャー企業を対象にしたらどうかと言ったのである。
　

三沢光晴が逝ったからではないだろうが、平日の昼間だというのにほぼ満席となった「レスラー」を観る。すばらしいできばえの感動的な映画である。

何しろ、ラストシーンがいい。最近の映画特に日本の映画のラストのしまらなさを嘆く身にとっては久々の“終わりよければすべて良し”といったところ。何となく期待を持たせて始まるが、最後にいったいこの映画はなんだったのだなんてことが結構ある中では出色である。

ミッキー・ローク扮するとっくに峠を過ぎたプロレスラーが満身創痍になりながらプロレスを続ける。そんなプロレスフリークだから、財産もなくトレーラーハウスのようなところで暮らし、娘にも見離される孤独を抱え込む。

そんなとき試合後に倒れてしまう。当然引退ということになり、スーパーで働くが、どうしてもプロレスの世界が忘れられないで・・・。というストーリーであるが、べたと言ってしまえばそうかもしれないが、その生き様、悲哀をミッキー･ロークが渾身の演技で表現してみせる。もうはまり役もいいところだ。

また、ミッキー･ロークが思いを寄せるストリッパーを演じたマリサ・トメイもすばらしかった。老いぼれたレスラーと場末のバーのストリッパーという取り合わせはそれだけで絵になってしまう。

さらに、プロレスのシーンも楽しめて、特に内幕を語らせて、思わず笑ってしまった。プロレスファンならずとも堪能したのではないだろうか。

近頃では、少なくなった“肉食系”男子のロマンを感じさせる映画で、勇気をもらえる。こうして映画が観ている人に勇気を与えるというのは映画の原点なのである。ぼくは「映画とは人生の応援歌」であるというのが持論だが、それを見事に示してくれた映画であった。
　

だいぶ前に「向田邦子と昭和の東京」という本についてエントリーしたが、そこの中に頻出したのが、「父の詫び状」というエッセイである。いまからその本（文春文庫）のことについて書く。順序があべこべになってしまったので、いまさら中身がどうのと書いても、前出の本のほうがはるかに適切に案内してくれる。

それで、どうしようかと思案していたら、そうだ普段ブログを書いている身にとって、向田邦子のようなうまい文章をどうしたら書けるのかを探るのもおもしろいなあと思ったのである。それには、エッセイがもちろんいいわけだから、この作品なんては格好のお手本となる。

そこで、きっとうまい文章は、最初のところ、すなわち出だしの文章がすばらしいのではないかという仮説を立てて検証してみることにした。

実際にブログを書いてみて分かるのは、最初の言葉が決まるとあとはすんなりと筆が進むものだ。本の中のいくつかの文章から、最初のセンテンスが冴えているのを抜き出してみた。

「記念写真」
写真は撮るのもむつかしいが撮られるのもむすかしい。
「自然な顔で笑ってください」
といわれただけで不自然な顔になり、こわばった笑いが印画紙に残ってしまう。カメラに媚びている自分にふと嫌気がさし、口許は笑っているのに目はムッとしていたりという奇怪なことになったりする。

「身体髪膚」（ところでこの漢字を読めて意味がわかりますか？“シンタイハップ”と言ってからだ全体のことです）
ほんのかすり傷だが久しぶりに怪我をした。
玄関の三和土に小銭を落とし、拾い上げて立ち上がった拍子にドアの把手に頭をぶつけたのだ。左のこめかみに、三センチほどの臙脂の毛糸を貼りつけたような傷が残り、十日ばかり目を伏せて歩いた。

「ごはん」
歩行者天国というのが苦手である」。
天下晴れて車道を歩けるというのに歩道を歩くのは依怙地な気がするし、かといって車道を歩くと、どうにも落ち着きがよくない。

「魚の目は泪」
子供の頃、めざしが嫌いだった。
魚が嫌い、鰯が嫌いというのではない。魚の目を藁で突き通すことが恐ろしかった。見ていると目の奥がジーンと痛くなって、とても食べる気持ちになれなかったのだ。

「昔カレー」
人間の記憶というのはどういう仕組みになっているのだろうか。他人様のことは知らないが、私の場合、こと食べものに関してはダブルスになっているようだ。例えば、「東海林太郎と松茸」
という具合である。

「鼻筋紳士録」
自分のうちで犬を飼っている癖に、よその犬を可愛がるのは、うしろめたいが捨てがたいものがある。
うちの犬に済まないと思いながら、撫でたり遊んだりする。おなかひとつ掻いてやるにしても、うちの犬を凌がないように気を遣いながら、微妙な反応の違いを味わっているのである。

とこうして書き出してみると、思わずうまいと思ってしまう。読者をすっと引き込ませるし、作者がどういう心根の持ち主でどんな生活をしているのかが覗えるのである。

こうした表現力の源のひとつが言葉であろう。昔のものには雰囲気のあるものが多い。そうした情緒のある言葉がだんだん消えていってしまっていてさびしい気がするのはぼくだけなのだろうか。
　

昨日は、恒例の柳家小里んの独演会に行く。ただし、今回は伯母さんの葬儀が終わってから出かけたので最後の演目である「船徳」しか聴けなかった。

伯母さんというのは、僕の母親の姉で享年93歳なので大往生といったところである。4年前に大腿骨を骨折してしまい動けなくなったので施設に入っていたのだが、先週の木曜日の朝、係りの人が起こしに行ったら息がなかったという。ですから、何にも苦しまずにすうっと心臓が止まったようだ。こういう死に方はいいなあ。

伯母さんの家は茅ヶ崎なので、そこで告別式を行い火葬して、近くの海前寺というお寺で初七日の法要と精進落しをして、いとこの車で辻堂に送ってもらってそこから池袋演芸場に駆けつけたのである。

今回の独演会は、下の息子と一緒に聴くことになっていて、中入りで合流する。そしたら、息子は行きつけの銀座の「Ｍ」のマスターの隣にちゃっかり座っていた。いつものようにママやＫちゃんなど「Ｍ」ご一行様も来ていた。

小里ん師匠の「船徳」はいい感じで楽しめた。以前、「東西三人会」で古今亭志ん橋師匠が同じ演題で噺したが、また違った小里んさんの味が出ていてよかった。この手の噺は合うのかもしれない。

終わってから、息子と定例呑み会に切り替えて一緒に近く居酒屋にいく。息子は最近落語にはまっていてＣＤで枝雀や志の輔を聴いているようだ。そんな彼が感激していた。新宿末広亭の定席には行った事があるが、こうした独演会は初めてだったので、定席寄席の短い噺と違ってこうしてじっくり聞くと感動したようだ。

彼曰く、落語というのは、プレゼンテーション能力を磨くのに役にたつという。まくらで聞いている人の気をひきつけ、身振り手振りでわかりやすく、ときに笑いをとってぐいぐい自分のペースにもっていき、最後にオチをいれる。こうした落語の“聞いてもらえる技術”がいいのだという。なるほどと思ってこちらが勉強になった。

それやこれやの話題であっという間に時間が経ち帰りの途についたのであります。日曜日だったので湘南新宿ラインもがらがらでゆったりとして疲れなかった。これから日曜日に呑むのがいいかなと言ったら、息子は“明日ぼく仕事ですよ”と軽くいなされてしまった。
　

こう見えても僕は理系出身なので、つい合理的な思考というか、理屈はどうなっているのだろうかという頭で考える。以前にも「情緒から論理へ」と「浅い論理的思考」で書いたことの延長の話ですが、新聞やテレビの話題に理系の人がちゃんとチェックしているのかと思わざるをえないことに出会う。

ここに二つの例がある。ひとつは、いささか古くなったが経済産業省が発表した「対象のエアコンや冷蔵庫、テレビは10年前に比べ省エネが約40％進んでおり、二酸化炭素（ＣＯ2）の排出量を年約400万トン削減。」というニュースである。

これを読んで、なんとも単純な計算でびっくりした人もいたと思う。まず、みんな10年前の製品の買い替えなのか、容量は変わらないのか、新たな製品の製造や流通のときに出たCO2はカウントしているのか、といった疑問がすぐに出てくる。マクロで考えると売り上げが伸びて雇用を創出できたらいくら省電力の製品を作ってもCO2は増えます。

もうひとつは、電気自動車です。これも単純にガソリン車から電気自動車に変えるとCO2が減るというのもよく考えてみる必要があります。電気を作るのに火力発電だとたっぷりとCO2を出すわけで、電気自体で排出しなくても、発電所で排出しているのです。

乱暴なことを言うと価格に反映されていて、エネルギー単位あたりの価格が高ければそれだけCO2の排出量も多いのです。分かりやすいのは、電気ストーブと石油ストーブを比較することでしょう。灯油のほうがかなり安いですよね。ですから、同じエネルギーを出そうとすると電気ストーブの方がCO2をたくさん出しているのです。

ただこの場合の増分の電気を火力発電という前提を変えると、すなわち原子力発電や水力発電だと話が変わります。これらはわずかしかCO2を排出しませんから、この発電所からできた電気を使えばCO2は出ません。

ですから、正確に言えば、原子力発電でできた電気を使う電気自動車は温室効果ガスは出さないのです。それを、原子力発電所の新規建設なしで電気自動車を走らすと環境を悪くするのである。環境推進派の人たちは原子力発電を推進しなくてはいけないのだ。

目先のことだけではなく、全体のサイクルを見るとか、深く突き詰めて考えるとかの態度が必要な気がする。このあたりはまだまだ情緒的な言論がまかりとおっているようだ。
　

昨年のカンヌ国際映画祭で「ある視点」部門の審査員賞を受賞した黒沢清監督の「トウキョウソナタ」を観る。この作品では、ばらばらとなった家族がやり直しができるかといったテーマで、日本のどこにでもありそうな家庭を描いている。

そうした風景が海外でも通じるのだとちょっぴり意外であった。しかし、よく考えてみると、家族の崩壊と再生は世界中の共通のテーマなのかもしれない。

家族は夫婦と大学生と小学生の男の子二人の4人家族が舞台である。親父はある企業の総務課長なのだが、ある日、総務の仕事を中国にアウトソーシングすることになって会社を辞める。

再就職しようにも、求人先の面接であなたはわが社にきて何ができるのですかと問われ、まわりとあわせるのがうまいとか、カラオケですと答えて、これでは再就職もおぼつかない。しかし、失業したことを家族に内緒にしているのである。

同じように失業中の高校時代の同級生が登場するが、ウソの電話で自作自演の演技をする。このエピソードはこんなご時世だから非常にリアルで身につまされる。

だから家に帰ってもギクシャクというかしらけた雰囲気で各人が勝手に振舞っているのである。この家庭の有様もぼくのうちも同じ家族構成なので多少似通ったところがあるが、唯一わが家はお互いに隠しごとだけはしないというのが救いでもある。え、そう思っているのはぼくだけ？

家族というものの崩壊というのは、親たちの“こんなはずではなかった感”と子供たちの“いかげん親のエゴはやめてよね感”の葛藤で、親たちはやり直せないかと悶えるのである。

夫婦役が香川照之と小泉今日子で、この二人はいまや引っ張りだこなのだそうだ。今回もぴったりで、香川照之のリストラされてもがき苦しむ表情、小泉今日子の思いっきりの開き直りの表情がなんとも印象的であった。

ともあれ、黒沢監督の光と風の使い方がすばらしい演出もみごたえがあり、堪能できる作品に仕上がっている。
　

BPMという観点で語っているが、やめようかと思う。なぜかと云うと、それだと何かはやりもののことをしゃべっているようで、本質から外れるからである。

だから、業務システムをどうやって作っていくかということから考えいこうと思う。多分実はそこが大事で皆そう思っているが、新しい技術やサービスは出てくると、どうしてもそこに引っ張られて、それがビジネス的にどうなのかという風に考えない。新しい物がいいものだと錯覚する。IT一つでビジネスなんてそう簡単に変わるわけがない。

業務システムって本質的には何も変わっていない。しかし、業務システムが“本質的にどういうものなのか”ということを議論していないことや、そこのフィロソフィーがない中でＩＴの適用を議論するから、変なところに行ってしまう。

あくまでビジネスありき、ユーザありきです。だって、ビジネスやユーザに貢献できないシステムを作って何になるのですかということです。こういうことを言うとすぐにビジネスの経験がないからとか、ビジネスをやっている人がちゃんと仕様をかいてくれなければできないよという声が聞こえてきそうだが、そうだろうか。そんなことを考えてクリエイティブなことができた人がいただろうか。

ということで、これまで書いてきたことが中心となるが、もう一度本質的な立ち位置に戻って、ITというものが、実際のビジネスあるいは個人の仕事にどう貢献できるかどうかを考えていこうと思う。実は、ブログで書くということは、書いたら終わりではなくて、しつこく同じことを書くことも大事なような気がするのだ。

ということで、これから繰り返しになるかもしれないが、新たに読者になった人もいるし、もう一回確認したい人もいると勝手に思って、しつこく経営・事業とＩＴのことを語っていこうと思う。

さて、これから「再びビジネスとITを語ろう」というテーマで書いていきます。まずは、ビジネスの言葉で考えることの大切さをみていきましょう。

昨日もBPMという言い方をやめようと言いましたが、システムの言葉だとどうしてもビジネスの実相から離れてしまうように思います。ERPを入れること、CRMを入れること、Sales Forceを使うことといったところが目的化してしまうからです。

その原因は、ユーザ側もシステム側も両方に責任があると思います。ユーザ側では、自分たちで自らの業務プロセスをデザインできないでいることです。もちろん、一部の先進ユーザはできていますが、大部分は業務のデザインができていないのです。

目の前の局部的な業務は自分たちの方言で説明できるのですが、特に業務全体、あるいは会社の事業執行における位置づけなどといったところのデザイン力が弱いように思えます。俯瞰力がないという言い方かもしれませんが、要は全体を見渡せる力がないように思うのです。

従って、システム側に事例を示してもらうとか、パッケージの機能から説明してもらうとかしないと自分たちの業務を整理できないのです。

一方、システム側はすぐシステム機能の話をします。どの機能を使おうかというアプローチになります。業務の構造とか組織の機能とかいった観点の深堀ができないというか、しようとしないことがあります。

それは実際にその業務の経験がないからということもあるのですが、その固有性や特殊性に目がいってしまい、無理だと思ってしまうのです。

ところが、別の角度からすなわち共通性とか、標準性といった見方で見ていくと、基本的な骨格はパターン化でき標準化できることがわかります。

ということで、現状では双方が自分たちだけで通用する言葉で語っているためにお互いを理解できないという齟齬が生じているのではないでしょうか。

そのために、ビジネスの要求としてビジネスの言葉で提示した与件がシステムの実装になったときにシステム側の都合のいいように歪曲されてしまうということが起きているような気がします。

いまこれだけ技術が進化し、実現機能も多種多様化していることを考えてみると、ビジネスの言葉で表現した仕様がそのまま実装されていくというのは、できない話ではないと思うのです。

そのためには、ビジネス側はみんながわかるような平易で簡潔なデザインをする必要があります。ここでいうデザインとは簡単にいえば、個人の仕事および業務プロセスのオペレーションスタイルを作るということです。

質の高い仕事を迅速にこなすためのスタイルをデザインし表現できることが大切です。それは、楽しく仕事ができるにはどうしたらいいのかに対する答えになるように思うのですがいかがでしょうか。
　

銀座パトスで、“おっぱいバレー、シニア１枚”というのが恥ずかしくて下を向いて入場券を買う。そうしたら、売り場の女の子が大きな声で“はい、おっぱいバレー、シニア1枚です”と大きな声で言う。こうして、そそくさと入場して、その「おっぱいバレー」を観る。

正直面白かった。タイトルとはちと違うがまじめな映画なのである。単純だといえばそうなんだが、思わず涙をこぼしてしまった。

教育とは、先生と生徒とはといったベタで根源的な問いに答えているのである。物語は、北九州のある中学校に綾瀬はるか演じる女教師が赴任してくる。そこで、男子バレー部の顧問に就くのだが、このバレー部は練習もしないし、部員も5人しかいないというダメ男子の集まりでなのである。

そして、中学生の男の子なら誰しも夢見る“おっぱい願望”で頭の中がいっぱいなのである。そんな、中学生に対して大会で１勝したら先生のおっぱいを見せてあげると約束してしまうのである。さあ大変、それから彼らは目の色を変えて練習に励むというお決まりのストーリー。さて、その結末は？

この設定は、誰しも興味をそそりますよね。そして、その間に教師として悩む姿が自分の中学生時代とダブって映し出されて、生徒とともに成長していくのである。

そんな不純な動機で生徒を扇動するものではないと思うかもしれないが、鰯の頭も信心からではないが、やる気が出るきっかけなんてものは何でもよくてモチベーションがあがればいいのかもしれない。それが、中学男子は“おっぱい”なのだ。

思い起こせば、ぼくらの中学生時代も似たようなもので、道程イコール童貞という妄想ばかりで、経済性と聞いただけでええ“性”だといってにたりとしていた。そして、在日の友達の家は、いつもお母さんが働きに行って留守なので、昼間なのに雨戸を閉めて、二人で「映画の友」を開いておっぱいを拝んでいたのである。それが、何のモチベーションになったかは忘れたが。

この原作は実話にもとづいているらしいが、時代設定が昭和５４年で場所も北九州であるから、確かにありそうな話である。それで考えるに今の都会でこんな物語が成立するのかと気になる。昔から、先生は出来損ないの子が可愛いものなのだ。ひょっとしたら、現代の先生は頭のいい子が可愛いのではないだろうか。

まあ、綾瀬はるかの映画のようであるが、ぼくはちとこの女優さんの能天気さがひっかかる。この映画でも最初に赴任したときはまだ未熟な教師という演技はそのものずばりみたいなのだが、だんだん成長してそれなりのプロになるといった感じが出ていないのだ。ずっと未熟な教師で終わっている。他の作品でもおしなべてそういう演技なのである。可愛さだけでというのもそのうち通用しなくなるのでは。

わが国ではまだ、「ものつくり」立国を主張する人がいるが、そのときの“もの”が従来のような“ハコ”、すなわちハードをさしている場合が多い。本当にそうなのだろうかという疑問を抱いていたので、その疑問に答えてくれそうだったのでこの「ものつくり敗戦」（木村英紀著　日経プレミアシリーズ）を読む。

わかりやすいように目次を示すことにする。

序章　　日本型ものつくりの限界
第1章 先端技術を生み出した2つの技術革命
第2章 太平洋戦争もうひとつの敗因
第3章 システム思考が根付かない戦後日本
第4章 しのびよる「ものつくり敗戦」
終章　　「匠の呪縛」からの脱却―コトつくりへ

こうして書くとこの本の文脈がすぐに分かると思います。すなわち、大きな流れでいうと、ある時期強いと言われた日本のものつくりも第二、第三の科学革命を経て変化する波に乗り切れないでいる。

いまでも象徴的なのは、ハードウエアからソフトウエアの時代になってきているのにソフトウエアの技術をもっていないのである。このことは、ぼくが今いる世界であるITもまったく同じで、ソフトウエアの技術はほぼ欧米からのものに依存している。

ここで出てきた第二の科学革命というのは、その前に第一というのは、ガリレオ、ニュートンらによる近代科学の確立であるが、そのあとにおとずれた大量生産、大量消費生んだ科学と技術の結びつきである。

そして、第三の科学革命は、これまでの自然科学とはちがって人工物を対象とする科学の登場である。そして、第三の科学革命の申し子が「システム」なのである。

こうした変化に対して、日本のシステム技術あるいはシステム思考力は欠如していたために、太平洋戦争における敗戦もここに負うところも多かったのだ。

では、戦後にそうしたことが改められたのかというと、そのままずっと以前の労働集約型モノつくりに固執してきたのである。もうこうした労働集約型技術は成立しないのだ。機械からシステムへの移行が第三の科学革命なのに、機械を道具のように使うという逆の方向に目がいっているのである。

なぜそうなったかは、かなり難しい問題で著者も数学を教えなくなったこととか論理的な思考訓練がなされていないとか言っているが、それだけではないような気がする。

たしかに、著者が指摘するように日本は「理論」｢システム｣「ソフトウエア」が弱いが、そこをどう底上げしていくのかみんなでよく考えていく必要がある。

この本は、そうした問題の所在を明確にしてくれて、大切な問題提起をしてくれていると思う。良書である。皆さんもぜひ読んでください。
　

いまの政府の経済対策が効果を発揮しているのかよく分からないが、少なくとも将来に悪影響を及ぼすことは間違いないように思う。

前にも書いたように今回の日本の経済危機は、外需依存でやっと支えられていたのが、外需先である米国のつまずきで一挙になくなってしまったからに他ならない。そうなると、もともと弱い内需では、この危機を乗り越える力はない。だからというわけで、無理やりその需給ギャップを埋めるべく内需振興のために1４兆円だかいくらかを拠出したのである。

しかし、よく考えてみると、２つのおかしなことがある。ひとつは、あわてて本来ならやらないでいいようなことをやっているわけで、いままでやる必要がないということで予算化できないものもこの際だからやってしまおうというのである。

しかも、国営まんが喫茶と揶揄されるようにまだまだハコモノにお金をつけているのである。やらなくてもいいことをやってどんな効果があるというのだ。

もう一つは、エコ家電だエコカーだとか言って、一気に買い替えを促すキャンペーンをやっている。地デジが何でエコなのかわからないようなこともまかりとおっている。このキャンペーンはいつまで続くか分からないが、いいですか、これが一巡したらそのあとどうなるのでしょうか。

もうしばらくは自動車も家電も買わなくなりますよね。そのときはどうするのでしょうか。景気が回復して輸出がどんと増えているとでも思っているのでしょうか。

よーくみていくと、この経済対策というのは、特定の産業の製品に対する過剰消費を煽っているだけなのです。もうこれ以上そんなにほしくないのにものを買えと言っている。スーパーではやっている不用品を下取りしてくれるやつだって、そのまま使えるものまで買い換えるのである。モノはあふれ飽和しているのにさらに買えと促している。

結局、内需だけで食っていこうとすると「過剰の経済」でやっていかざるを得ないのだが、そんなことはありえない。過剰はすぐに限界が来て後は先細るだけだから、北朝鮮になってもいいというならいいが、そうではなかったら、グローバルのなかで生き抜いていかなくてはならない。

そう思うと、昨日も書いたが、“コト”をつくれない日本の将来に暗澹たる気持ちを抱くのはぼくだけだろうか。

悲喜子さんのブログで「要件定義に関するモヤモヤまとめ」というエントリーがありました。そのモヤモヤが、「要件定義は業務知識がないとできない？」というのと、「お客様自身は、本当に必要なものを気づけない？」です。このモヤモヤはよく分かるし、いろいろな議論があると思います。

ただ、｢要件定義｣（要求定義でもいいのだが）といった場合、それが何を意味しているのかをはっきりさせておかなければいけない。「要件」とは文字通り“必要な条件”のことだが、では“誰が必要としている”ことなのか、あるいは“どうしたいから条件を決めなくてはいけないのか”ということです。

ここの定義でぜんぜん変わってしまいます。すなわち、ユーザ側のもつ要件なのか、システム側の要件なのかです。それによって、条件も違ったものになります。

例えば、ユーザ側の要件であれば、ビジネス上あるいは業務遂行上でこんなことをしたい、あんなことができたらというのが要件になります。それは、ITを使わなくてもいいわけであって、むしろITを使わないほうがよかったりする場合もあります。

一方で、システム側の要件というのは、システム（IT）にとって必要なことであるから、システムの載せられるかどうか、システムが持っている機能に合っているかどうかとなります。すなわち、システム化要件という切り口になるわけです。

わかりやすいのはパッケージを使う場合を考えたらいいと思います。パッケージの持つ機能に合わせられるかというのが要件になるわけです。だから、要件定義をフィットギャップだと思っている人もいます。

こうしてみると、どちらも自分の都合のいいように定義しているわけでこれを共通定義にもっていかなくてはいけないと思います。そのときの軸足はやはりユーザ側であると考えています。根本的にビジネスあってのITだからです。ビジネスあるいは業務の要件をそのままITに落とすことができればいいのです。

こうしたとき、悲喜子さんの問いかけが問題になるわけで、お客さんだけで要件定義ができるのかということと、できないならシステムサイドで定義するにも業務知識がないからできないということになります。

それでこの問題は両者とも共通的に言えるのですが、まずお客さんだけで要件定義ができるようにすべきで、先進ユーザはほっておいても自分たちでモデル化できるが、そうではない会社がいっぱいあって、そこには、「何を決めるか」ではなく、「決めてほしいこと」をシステム側が整理してインタビューすればいいと思うのです。

どういうことかというと、ビジネスや業務の構造、オペレーションのし方、管理のポイントなどはかなり標準的なものであると考えています。すなわちパターン化できるわけです。そのパターンを当てはめてその“中身の空白”を埋めるようにするのです。

ここのところが重要で、今言ったことは業務知識がなくてもできるはずです。では業務知識が要るのはどこなのでしょうか。それは、その空白の内容なのです。一番分かりやすいのは「ルール」です。ある意思決定をするのにどういう基準で行うのか、何を制約としてみるのかといったことです。ここは、会社や業種固有の者があり、外部では窺い知ることはできないかもしれません。

しかし、どういうルールで、どういう基準で決め手いるのですかということは聞くことができます。ですから、どういう決め事をどういう順番で流す（これを業務プロセスという）のかを明らかしに、その決め事の“決め方を”一緒に定義すればいいのです。

ですから、別の言い方をしますと、競争優位の源はルールにあり、業務プロセスにはあまりないのではないでしょうか。この競争優位の源、差別化の要因はユーザ自身が自らの手で定義しなくてはいけません。それを導いてやるのがシステム側の役割です。

従って、モヤモヤの答えは、要件をビジネス上の要件とすれば、要件定義でのシステム側の詳しい業務知識はなくても、意思決定のルールを引き出せる程度の知識があればだいじょうぶだし、お客さんが何をしたいかは、空白の箱を埋めていくような形で引き出せばいいのです。もしそれが出てこないようならそのプロジェクトは成立しないのであって、無理やり進めてはいけないのである。