mark-wada blog

昨年末になるが、財団法人「社会経済生産性本部」というところから「労働生産性の国際比較　２００６年版」というレポートが出ている。なぜ今頃そんな話を持ち出してきたかというと、ちょっと前にこれに関連した朝日新聞の記事を見たのと、ある会合で日本のIT投資が先進国で最低だというような話を聞いたからである。

このレポートは、各国のGDPを全就業者数で割った値を「労働生産性」として、その値を比較している。労働者一人が働いて生み出す付加価値が多いほど生産性が高くなるというわけだ。その報告では、日本の労働生産性（2004年）は59,651ドル（798万円）で、OECD加盟30カ国中第19位、主要先進7カ国間では最下位というショッキングな結果となっている。

ちなみに第1位はルクセンブルグ（90,683ドル／1,213万円）、第2位は米国（83,129ドル／1,112万円）です。

ただこれだけだと、何だ日本は非常に非効率の国なのかと思ってしまうが、こうした情報は、きちんと解析しないと間違った理解になる。ちょっと思いついたところでもいくつか解き明かすべき疑問がわいてくる。
１． 全産業にわたって労働生産性が低いのか
２． いつから低くなったのか
３． 労働生産性に与える影響因子は何か
４． 失業率が高いと労働生産性があがるのか
５． 個人の問題なのか、組織の問題なのか　　　等々

日本の生産性が低いのは全産業というわけではなく、低いのはサービス業や小売、建設業などで、金融や製造業は高いのである。そのなかで製造業は、OECD加盟国24カ国中第3位、主要先進国中2位となっている。製造業はここまでかなり省力化・省人化対策を実行し、人員削減を行なった結果、生産性の向上をもたらしたと考えられる。そのため、おそらくそこから溢れた人員がサービス業に流れていって、賃金低下を受け入れつつ、雇用をある程度確保することが行なわれたのではないだろうか。従って、サービス業の付加価値額はそれほど増加していないにもかかわらず就業者数の増加で生産性を悪化したと考えられる。

この労働生産性における上昇率をみると、2000年から2004年では上昇率が回復して主要先進7国中2位につけているが、その前の10年間がずっと最下位を低迷していた。まあ、あの高生産性の国であった日本は、失われた10年でその地位を失ってしまったのだ。

こうした労働生産性に影響を与える因子は何だろうか。単純に分子はGDPで、分母は就業者数だから、GDPを増やして、就業者数を減らせば生産性の数値は大きくなる。だから、日本は失業率が4.7%といちばん低いから、サービス業でもどんどん人を減らしていけば追いつくのではないかと思うかもしれませんね。ところが、そんなに簡単な話ではなく、仮にGDPはそのままで失業率をいちばん高いドイツ並みの10.5%にしたところで相変わらず最下位は変わらないのです。

ということは、朝日新聞にも書いてあるように、ざっくり言うと「生産性向上のための投資をしていない」ことと、「非正規雇用の拡大による仕事への意欲の低下」に起因するのではないだろうか。さて、これからここをどう乗り越えていくのかが勝負だ。

ただ、忘れてはいけないのは、労働生産性をあげれば、みんながハッピーになるという単純な構図ではないところに難しさがある。生産性が低くても雇用が確保できてればいいとか、無償のサービスをお互いで享有できる社会でいいとか、日本の社会の構造をどうするかに関連してくる。

こうして見ると、「労働生産性」という情報から様々なことがわかってくる。だから、浅くつかまえるのではなく、一歩踏み込んで考える“質の高い情報のさばき方”が必要になってくる。変な話、これができれば労働生産性も上がるというものだ。

ただ、少なくとも、労働生産性を向上させるIT投資はどんどん進めていってほしい。データ的にもITに投資すると生産性は確実に上がることが分かっている。

結局、「働きたくなるIT」が重要キーワードですね。ですから、このあたりのことを今後書いていこうと思う。

働きたくなるITを考える場合、ITの使い手であるひとりひとりのユーザが企業からどう見られているかが非常に重要な要素になる。旧来の労働者という概念では、歯車のひとつ、将棋の駒のイメージとなってしまうが、これからの企業ではそうではなくて「社員ひとりひとりの個性を尊重し、そしてひとりの消費者でもあると捉える」方向にいくように思う。

ここがEnterprise2.0の大きな変化であると考える。そうした個性を持ったユーザへ役に立つITを提供できるベンダーが生き残れるし、そうしたソフトウエアが普及していくだろう。

ここで、世の中で言っているEnterprise2.0について考えてみよう。リアルコムという会社は、特徴としてつぎの３つをあげています。
１． 集合知　　・・・Enterprise向けBlog、SNS、Wiki
２． エクスペリエンス　・・・GoogleのエクスペリエンスをEnterpriseに
３． マッシュアップ　　・・・情報系のコアデータ統合管理基盤

１の集合知というのは、企業内においてBlog、SNS、Wiki等のコラボレーションツールを活用し、現場の集合知を収集し、ワークスタイルを変革しようといういものである。

２のエクスペリエンスというのは、ユーザが自宅でできることを会社でもできるようにということで、Webの世界でGoogleにより瞬時に欲しい情報が手に入るように、Enterpriseでも瞬時に欲しい情報が手に入ることが当然となってくるというもの。

また、システムの多様性・複雑性が増す一方でガバナンス要求が強化されつつあるEnterpriseにとって、３の「マッシュアップ」のような相互運用が可能なシステムアーキテクチャは理想的である。

とまあ、確かにこの３つの技術あるいはコンセプトは重要な特徴ではあるが、その中味については若干異論がある。なにか期待が大きすぎやしないだろうか、もう少し落ち着いて考えたほうがいいのではないだろうか。というのも、Web2.0はもともとは個人ベースでしかもネット好きのひとたちでもてはやされているわけで、それを企業内に持ち込んでも、最近はリテラシーがあがったといえどもまだまだ一部の先進的な企業をのぞいてはそう簡単に浸透しそうもない。

だからといって、あきらめろと言っているのではない。まずは、定常的な業務システムのなかにこうした要素を取り入れていったらどうかということだ。すなわち、これまでこのブログで述べてきたことを再度繰り返すようなことになるがお赦しを。

集合知で言えば、ワークスタイルを変革しましょうなんてことではなく、もともとそういうスタイルで仕事をしてきたのをWebの仕組みを使って効率的にやりましょうということです。「ユーザ目線のBPM」や「ビジネスコンポーネント指向開発」でもさんざん議論したように、情報やデータを確定させるための作業というのは、利害関係者間の情報共有的動作で進めていくわけで、そこでは参加者の知恵を出しながら決定していくことになる。まさに、集合知の世界である。

エクスペリエンスという意味では、Googleというより、Blogを書いている人やインターネットで買い物をしている人、mixiをやっているひととか、そういうネットに抵抗感のない人種がどんどん増えてきていることが大きい。まだ、年寄りには拒否反応を示すひとがいるが、だいぶ少数派になってきた。従って、高度なものは難しいにしてもブラウザや検索エンジンを使ってシステムにさわるぐらいはだいじょうぶそうだ。ある業務パッケージの会社のひとが売り込みにいくと、最近では、家で使っているBlogのようなシステムがなぜできないのかと問い詰められることが多くなったと言っていた。そういう時代になってきたのだ。

マッシュアップは、これもWebにあるサービスをもってきてすぐに企業に適用できるかというとこれもそう簡単ではない。だいいち、社員全員に使わすとなったら無理な話でしょう。ここでも、「ユーザ目線のBPM」と「ビジネスコンポーネント指向開発」で提案している、オープンCMSとBPMの組み合わせこそ、マッシュアップのひとつであると考えている。このオープンCMS（広義の意味の）により提供されるさまざまなサービスをつなぎ合わせて効率的で魅力ある業務プロセスを作ることこそ、Enterprise2.0的マッシュアップであるといえる。

要は、Enterprise2.0というのは、まず通常の業務システムのなかに少しずつWeb2.0の技術を入れ込んでユーザひとりひとりの使い勝手や効率的業務処理を支援することにあると考えている。

２００７年問題とやらで、団塊の世代の持つ技術やノウハウが消えていってしまうと危ぶまれている。もう定年を迎える人が出てくるのでもはや遅いのであろうか。いや、現実には、能力のある人やノウハウの蓄積のある人は６５歳くらいまで働くだろうから、それまでに何とか技術伝承をしておかなくてはいけない。

これは、どういう業界で起きているのだろうか、実はIT業界はこういう問題はないのだ。昔の技術を持っていても役に立たないのだから。製造業や建設業などで問題となるのだろうか。

筆者は、最初に入った会社が化学メーカーだったので、この現場の技術やノウハウの大切さとか伝承の難しさなどがある程度理解できる。ちょっと話がそれるが、この問題がおきた原因について考えてみたい。

われわれが入社したころは、現場にはバリバリのたたき上げの人がたくさんいてものすごく恐かった。それぞれがその道の高い技能をもって、自信ももっていた。しかし、それを後輩にオープンに開示するかというとそうではなくて、われわれは盗むようにして技術を習得したものだ。今だとISOなどで基準書だとかマニュアルだとか整備するようになったが、当時は肝心なところはベテランの頭の中にあった。

でいつごろから技術・技能が継承されなくなったのだろうか。筆者は詳しく調べたわけではないので、独断と偏見かもしれないが、大学進学率と関係があるとみている。

どういうことかというと、昔の現場の技術を支えていたのは、地元の工業高校や商業高校をでた人たちだった。かれらは、優秀でしっかりとした専門知識も身につけ、何よりもその道のプロになろうという意欲があった。また、それが会社のためにもなったし、自分たちの生活を確保することにつながったのだ。それが、日本が豊かになるに従ってそうした実業高校に行っていた子たちが、みな大学に進学し出したのだ。

彼らは、大学に行って一体何をしたのか？おそらく、これも推測の域を脱していませんが、都会で遊ぶことと簡単にかっこよくお金儲けができそうな幻想を身につけたのではないだろうか。本来、こうした子が社会の基盤をしっかりと支える労働者として機能することが大事であったが、その層が消えてなくなってしまったということだ。確かに、雇用状況も悪く、そうした人材育成がままにならなかったのはよく分かるが、そういうときこそ国や地方が施策として社会構造を維持し充実させることが必要だったと思う。

この空洞により、日本の特に製造業を中心にしたモノつくり産業における技術継承は大きく遅れたのではないだろうか。いまこそ、工業高校とか商業高校を復活させるか、大学でその役割を担うかすべきであると思う。格差社会のなかで中間層を埋める存在として、こうした技術、技能をもったひとたちを育て、評価することが非常に重要であると考える。

話をもとに戻すと、この技術伝承とITの関係を考える。ふつうには、やめていく人たちに頭の中にある知識、ノウハウを紙に書いて残してくださいと言うか、インタビューして聞き出してそれをドキュメント化するという方法がとられる。それで、出てきますかねえ。おそらく、そんなやりかただと限界があって、顕在化するのは一部で多くのノウハウは隠れたままになってしまうのではないだろうか。

さて、それをどうやって引き出していったらいいのだろうか。そこで強調したいのは、「ビジネスコンポーネント指向開発」がその答えであると言いたい。

いったいなぜ技術伝承に有効なのか。もう何度も言っているが、「ビジネスコンポーネント指向開発」では情報やデータの確定前のプロセスとその後のプロセスでは性格も違うし、作りも違ってくる。すなわち、確定前プロセスは不安定で不定形であり、一方確定後プロセスは安定で定型的である。そこで、経験やノウハウが発揮される、あるいは必要とされるのどちらかというと、前者のあいまいななかからみんなの知恵を出しながら固めていく作業プロセスであろう。

そうした、情報共有型の仕事の進め方は、そのメンバーにベテランの人を入れるようにして、ただし、そのひとがリーダシップを採るのではなく、若いひとが引っ張っていくようにし、ベテランのひとはアドバイザーとして位置させ、何か行き詰まったときや問題が生じたときなどに助言をもらいながら進めるイメージだ。

そうすれば、いろいろなケースを想像しながらノウハウを吐き出す作業とは違い、実際のビジネスの局面で意見を言ってもらうわけだから、非常に実務的だし、その場で若い人の教育にもなるという効果もある。また、そのベテランのコメントがカテゴライズされ、アーカイブされるから、あとで検索して活用も容易になるというものだ。

だから、繰り返すが単に聞き書きしてデータベース化するのもいいが、こうした実践の場で自然に経験やノウハウが引き出せる仕掛けが非常に効果的であると思う。

日常の業務処理のなかで、情報活用というのが重要な作業となる。最近は、社内外のいろいろなデータベースからの情報やインターネットを介した情報交換などで、非常に多くの情報に接するようになった。多いということは逆に玉石混交で、そのなかから有用な情報を見つけ出すことはすごく大変である。

また、その情報をどう活かすかが重要で、小売業などはＰＯＳデータを品揃えにどう反映させるかが生命線みたいなところがある。まあ、小売業ではなくても一般の会社における、しかも個人の事務処理のようなところでも、この情報を取捨して、それをどう活かすかは労働生産性を高めるためにもよく考えておく必要がある。

その情報処理プロセスでよく言われるのは、もはや問題解決型のやり方には限界があって、仮説検証型に変えていかなくては創造的な仕事はできないというようことである。そしてさらに、この仮説を立てるのはコンピュータにはできないから、人間がやらなくてはいけない。ここが人間が能力を発揮する唯一のプロセスだから、みんなその能力を鍛えよみたいになってくる。

確かに、そうかと思ってしまうところもあるが、待てよちょっとちがうんじゃないかと思ってみる。まずは、問題解決型というとなんだか言われたことを決められた手順でこなしていくイメージをもってしまうが、本当にそうだろうか。じゃあ、いったいだれがいろんな情報あるいは起こった事象から、問題であるところを見つけ出すのだろうか、問題として設定するのだろうか。実はこの問題設定(発見）能力は大事な能力で、これをおろそかにするとトンチンカンな方向に行ってしまうケースはよくある。

一方、仮説検証能力も、収集した情報を分析してそこから未来を予測するというのが情報処理プロセスの大きな目的と考えれば、非常に重要な能力であるといえる。

ですから、情報のさばき方は二つの方向性があって、ひとつは情報の中から問題点を見つけそれを解決するようにもっていく方向、もうひとつは、情報を分析し、その関係性から予測モデル化する方向である。だから、どちらか一方ということではなく、問題解決型アプローチと仮説検証型アプローチをバランスよく使い分けることが必要である。

場合によっては、ひとの役割もそういう体制にしてしまうこともありえるのではないでしょうか。その最も典型はお役所でしょう。キャリアは仮説検証型能力を生かす役割であり、ノンキャリアは問題解決の専門家でしょう。

ところが、一般の企業においてはどうなっているのかというと、総合職と一般職があるが、どうもそのへんが曖昧になっていて、すなわち、乱暴にいうと何でも求められていて、みんなが類型化された立派な社員になれと言っているような気がする。

ここでちょっと矛盾したようなことをいう。これまで書いてきたことと関連すると思ったのは、サッカーのことである。サッカーチームというのも、仮説検証型のフォワードと問題解決型のバックスとで成り立っていると言えないこともない。いま、その代表チームでオシム監督が盛んに言っている“ポリバレント”ということが注目されている。“ポリバレント”というのは多様性ということで、ひとりが複数のポジションをこなせるようにすること、また、攻撃だけではなく守備もできる、あるいはその逆ができることでる。だから、あまり役割を固定化せずに多様性をもってやろうよ、それにより様々な局面における対応力をチーム全体で高めていこうよということである。

どうも、この考え方というのは会社でも役所でも通用するものではないかと思われる。その前提は、あくまでどちらか一方できちんとできてこそ、別の能力を持つほうにいけるのであって、最初からなんでもやるのではなく自分のホームグランドを持ってからであることは言うまでもない。

今回は、ＩＴのことはあまり出てこないが、いまは溢れる情報を社員それぞれが多様性をもったアプローチで処理していくことが大事であると言いたかったのである。次回にこの情報あるいはデータをどう読むのかという若干ＩＴに近づけた話をする。

玉石混交の情報の集まりから“玉”を抜き出すことはむずかしい。データが何を語っているのかを見つけることが最終的にめざすところであるが、その前に多くのデータのなかから、冷静に客観的に必要な事実を選び出すことが至難の業だからだ。どうしても、こうなってほしいからとか、こうあるべきだからといった予断が入り込む。無意識のうちに結果に合わせた事実選びが始まるのだ。効した恣意的なデータ解析を行なっていながら、あたかも客観的な解析結果であるという主張にだまされることが往々にしてある。

例えば、粉飾決算なんていうのは最たるもので、利益という指標は事実ではなく単なる意思表示に過ぎない。黒字倒産が起こるというのも、データを読み間違えると会社をつぶしてしまう例である。

また、よくあるのは事業の収益が悪化してその説明を経営から求められたとき、ネガティブな事実はどこかにいってしまい、いまから市場はよくなるから収益は改善されるという、あらかじめそういう結果がでるようなデータを並べることがある。経営者はこれに鵜呑みにしてはいけないのだ。逆にこういった恣意性を見抜く力があるひとが立派な経営者になる。

この見抜く力とは何なのだろうか。それは、科学的、論理的というよりある種の勘ではないかと思う。勘とは、経験に裏打ちされたセンスではないだろうか。また、センスはものごとの本質と構造を理解し、おのれを客観視できる俯瞰力によってもたらされると思う。

ですから、データを見たとき、いったいこの情報の本質は何なのか、どこに位置するのかを考える癖をつけることが、正しいデータを選び出すのに重要な態度ではないでしょうか。

また、こうした恣意性を排除するために客観的なデータに頼った経営を行なう経営者もいる。様々な数値化された経営指標に基づき、その打つ手も予測モデルによっておこなっていくというもので、いわゆる「計器飛行」経営というわけだ。この意図は、人間が自分の目でみたものを頼りに行なう「有視界飛行」だと、たえず目先の天候に右往左往してしまい安定した経営ができないからということなのだ。

まあ、どちらがいいかというのは難しいが、「計器飛行」といえども危機的状況では「有視界飛行」にならざるを得ないわけで、その切り替え方を柔軟にそして適正にするとういうことが大切なのではないでしょうか。

少しオペレーショナルな話からそれてしまったので元に戻すと、データには数値データとテキストデータがあるが、数値データについては、データマイニングなどのシステムによりよくなってきていると思われる。小売業などで行なわれるクラスター分析など統計的手法は有効であり、だから一般の会社でも缶ビールとオムツの関係までいかないにしても、もう少し統計的な手法を取り入れてもいいような気がする。

一方、テキストデータについては最近のキーワード検索技術、コンセプトサーチ技術などが充実していて、これらを活用した情報収集は高度化してきている。このあたりの話はまた後で議論しいていくことにする。

この連載は、大きな目次がないなかでとりあえず書き出しているので、脈絡のない話が続いているようですがご容赦のほどを。最後にはまとめてみようと思います。主題は、ITという道具をうまく使って知的労働の生産性と質をあげるにはどうしたらいいのかということなので、これだけは忘れないようにします。

さて、いまITを道具といったが、使う道具としてだけ捉えていればいいが、問題は目で見るものがITを通して見ることになることだ。すなわち、PCのディスプレイ、携帯のメール、テレビ画面などを見ながら世界を認識することになる。だから、バーチャルとリアルの世界という問題が生じる。

いまの若い人たちは小さいときからテレビゲームに慣れているので、ゲームで起こっていることがひょっとしたらリアルの世界でも起こると思っていやしないだろうか。最近の凶悪な少年犯罪が起こるたびに言われるが、普通の人間にとっても大なり小なりリアル世界とバーチャル世界の境界がぼやけてきているのは確かだろう。

これを会社における仕事で考えてみると、今はどこの会社にも机の上にひとり1台のPCが置かれ、それに向かって仕事をする風景が当たり前になっている。でも、これってつい最近の形態で、われわれの若いときは机の上は電卓とトレッシングペーパー（青焼きコピーをしなくてはいけないので）だけで、ときどき窓の外の景色を眺めながら、隣の人とおしゃべりをしながら仕事をしたものだ。

それが、個人にPCが配られると一日中PCのディスプレイとにらめっこだ。いったいみんな何をしているのだろうか。以前勤めていたとき、たまにフロー全体をながめることがあるが、全員がびっくりするほど一心不乱にPCを凝視しているのを目にするとある種の滑稽さを覚えることがある。そうなると、PCはホワイトカラーの生産性をあげたかどうか疑問になるが、そんな状態でもそれ以上に効果をもたらしているというのがここでのスタンスです。

さて話を戻すと、結局株のトレーダーの例を引き出すまでもなく、今はマウスのクリックひとつで多額のお金を動かしえるわけで、仕事がゲーム感覚になってしまうのではないだろうか。実際の仕事とゲームの決定的な違いは何かというと、ゲームは失敗してもリセットが効くが仕事はそれが効かないということだ。

PCのディスプレイから多くの情報が手に入り、そこで作業することであらかたの仕事がすんでしまうため、リアルな世界のことをあまり知らないことになる。筆者は以前、新入社員教育でこうしたことに関連して必ず言っていたことがある。“みなさん、山本五十六が真珠湾攻撃をするときに、実際に真珠湾を自分の目で見たかどうか、どちらだと思いますか。実は、何回か実地に足を運んでいるんです。それで、あの作戦を考えていたわけです。だから、あなたたちもたえず現場に足を運んで、そこで何が起こっているか自分の目で確かめることを忘れないでほしい”というようなことを話している。

製造業なら工場、流通業なら店舗といったように、実際にモノを作っている、販売しているところに行くと何かを感じられると思うので是非実行してもらいたいものだ。

ちょっと前に朝日新聞の星浩さんが、「知の運動神経」という言葉を使っていた。ぼくは「仕事の運動神経」あるいは「仕事神経」ということも言っておきたい。運動神経の悪いヤツを「運動オンチ」という。だから、「仕事オンチ」というのもあるような気がする。

なんというか、例えば、ある仕事を命じられとき、普通ならある段取りで手際よくできるようなことでも、余計なことをやったり、肝心なことが抜けてたりとかするひとがいる。いくら言ってもまた同じことを繰り返す。あるいは、報告書を書かせても何を言いたいのかさっぱりわからず、結論も書いていないこともあるといった風に、一生懸命やっているんだけど、どこかしっくりしていないというか、合っていない感じである。そういうのを目の当たりにすると、こいつ仕事オンチじゃないのかとつい思ってしまう。

筆者は、運動神経はあるほうだと思っているが、音痴である。だから、カラオケで唄えと言われるのが嫌いなので、なるべくカラオケのない店に行く。それでもどうしても言われることがあるので、１曲だけ何とか唄える歌を用意してある。まあ。それであらかただいじょうぶなのである。音痴というのは、耳が悪いというか音を聴く能力が弱いからだと思っていて、従って、仕事オンチというのも自分の周りの仕事や会社の事業の状況だとかいったものがどう動いているかを感じ取る力が元来弱いのじゃないかと思う。

で、そうした人たちも生産性があがるような仕掛けってあるのだろうか。

実は、運動神経でいえば、スポーツ選手がみんながみんな運動神経がいいとは限らないし、全部の運動がまるでだめという人は少ない。例えば、キャッチボールもろくにできないのにスキーはすいすい滑るとか、逆上がりができないけどゴーカートを乗り回すとか、意外に得意技があったりする。また、運動によっては、ある型にはまったら、それで十分通用するというものもある。例えば、野球のバッティングなんかそうだと思う。

で結局、この意外な得意技を見つけてやることと型にはめることによって「仕事オンチ」のひとが救えるのじゃないかと考えている。ある意味、仕事というのは“おさまりがいい”というのが大事で、勘違いしている人がときどきいるが、変に特異性を発揮されても困るのであって、“おさまり悪い”ことは個人の生活でやるべきだと思う。「仕事オンチ」のひとも“おさまりよく”しようよねということです。

こうしたことも一種の多様性だと思うが、おそらくこの多様性を見つけて、生かすのはＩＴの力をうまく活用することから達せられるのではないでしょうか。参加型のアーキテクチャ、情報駆動型プロセスなどがこうした手助けをしてくれるような気がする。

これまでの議論はＩＴについてというより、仕事に対する姿勢や態度といったことに焦点があたっていた。そこで最終的に行き着くところというのは「仕事が好きですか」というところになる。すなわち、何をするにしても、やっていることに工夫をこらしたり、改善したり、自分の思うようにするといった振る舞いは、結局は好きなことに対してしかやらないのだ。

仕事が好きになること、あるいは仕事が楽しくなることと言い換えてもいいが、どういうことなのだろうか。桑田の話を先のエントリーで書いたが、よく、プロ野球の選手が「結局、私は野球が好きなんですね」なんてコメントを言ったりするのを聞くことがありますが、そういうことなんだろうか。この野球選手、別に野球選手でなくてもサッカー選手でもテニスプレーヤーでもいいのだけれど、ほんとうに野球が好きで、サッカーが好きでということなのだろうか。

どうもそうではなくて、あることに関わったらそれに対して極めたいという気持ちが働き、それに真摯に向かい合い、そうしていると対象となっているものに愛着がわき好きになっていくということではないのかと思ってみる。だから、「結局、私は野球が好きなんですね」と言っている野球選手ももしかしてサッカーをやっていたら「結局、私はサッカーが好きなんですね」というのではないでしょうか。だって、いろいろなスポーツをやってそれを比較してこちらがいいということはできないのだから。

これは、仕事でも同じで銀行に入った人が「銀行員が好きなんです」というのと一緒で、これにしてもひょっとしたら役人になっても同じことを言うのでしょう。従って、どんな職業でも職種に関係ない部分における仕事、すなわち、最初は与えられた仕事かもしれませんが、確実に早くこなし、そのうち自分なりの工夫もし、相手に喜ばれるという行為を楽しく思ってやることができるかどうかということで、これができる人はどんな業態や会社でもうまくできるのでしょう。

ということで、仕事が好きであることが大切であるが、それだけで成功するとは限らないのが世の中なのですね。これは、前々回に書いたように仕事はリセットが効かないわけで、また特に会社での仕事ってかなりの部分対人関係で決まるところがあるので、すんなり自分の思い通りにはいかないのです。

だから、近頃“めぐり合わせ”というのがすごく大きなファクターであるような気がしている。いくら優秀なやつでも上司に恵まれなかったばっかりに自分の成果を評価してもらえなかったり、あるいは能力を発揮する場をつくってもらえなかったりとかが起こる。また、それ以外にもたまたまその時期に何かが重なって、不本意なほうの仕事についただとか、そういった“めぐり合わせ”によってずいぶんと違った生き方になる。しかし、これはしかたがないことでそれを嘆いていても始まらないわけで、そのなかで精一杯自分を認めてもらうことに全力を傾注することだと思う。

これからこうした人間関係のことも含めていろいろ考えていこうと思います。

さて、次回からはもう少しＩＴっぽい話にしたいと思います。日常の会社での行動の多くは情報処理です。情報を収集し、それを編集・加工し、発信することになります。このそれぞれのアクションにＩＴがどう使われ、生かされているのかを議論していきたいと思います。

情報を処理するためのインターフェースは画面と帳票になる。またこれらは、データモデルとプロセスモデルをつなぐ役割でもある。

このエントリーでは、主に画面について考えてみることにする。いま、繰り返して言っているように、企業情報システムも大きく変わろうとしている。本当に事業の役に立つシステムにどうしたらいいのか模索している。従って、システム全体あるいはコンセプトも変化していくのなら、コンピュータの使い方、画面の利用の仕方も以前の使い方と違ってくるはずなのだ。

ところが、いまのビジネスシステムの画面は昔のメインフレーム端末画面とそう大きくは変わっていないように思える。必然的に20年も前のオペレーションと大差ないのではないでしょうか。家庭ではブラウザを使ってインターネットと自在に会話しているのに会社の仕事ではそこまでやっていないというのが実状でしょう。いやー、ネットの使い方とビジネスは違うよとおっしゃる人もいるかもしれませんが、そうなのでしょうか。

情報処理には「時制」がある。未来の行動に向かって準備する、現在の仕事を処理する、終わった仕事を記録する、という３種類のパターンが考えられる。従来のコンピュータシステムは、そのうち“終わった仕事を記録する”ということに重きを置いた設計になっている。すなわち、生産実績、出荷実績、売上高などを登録するという機能である。今の話は、基幹業務システムのところのことで、ここでは、グループウエアの中にあるスケジュール管理だとかメールだとかは別の話にします。

一方、インターネットを使うのは、どちらかというと“未来の行動に向かって準備する”要素が大きく、何かをするためにネットから情報を得ているということが主な使い方になる。

ところが、現在形であるところの“現在の仕事を処理する”ということに対して、コンピュータが有効に使われているかどうかは、どうもあやしいような気がする。

ちなみに、ネットではどんどん現在形や過去形が入り込んできている。ネット購買やブログに日記を記録しておくなどである。

従って、これからのビジネスシステムは、コンピュータをうまく活用して“現在の仕事を処理する”ことを考えていくことが重要になると考えている。

そうした見方をしたとき、いまの様々な業務システムの画面は、使いやすいものになっているのだろうか。画面の種類をみてみると、だいたい、登録、参照（問合せ）、出力、閲覧（チェック）といったものが主体になっている。すなわち、金額、数量を登録するために過去のデータやマスタを参照して、そして入力したデータの出力とチェックを行なうといったアクションのために画面が構成されているような気がする。

もちろん、なかには手配や指示を行なったりするものもあることはあるが、そうした手配や指示は実際には帳票をFAXしたり、電話、メールで依頼するといったやり方も多いのではないでしょうか。

結局、従来の画面は業務プロセスと画面の一体感がないのだ。いま、BPMが注目されて、ビジネスプロセスをちゃんと設計しましょうよということになっても、プロセスをただ作ればいいわけではなく、そのプロセスをスムーズに回して、制御していかなくてはいけない。そうでないと、せっかくいいプロセスを作ってもどこかで停滞が起きたり、迂回プロセスを作ったりして、業務改善にも何にもならないことになる。

そのためには、画面を使って、そこから明確な指示を出して、その結果をその画面に返してもらうというアクションが必要になってくると思う。“情報がアクションを誘導する”というイメージだ。

ですから、賢明な読者の方はお分かりだと思いますが、「ビジネスコンポーネント指向開発」のフロントエンドツールであるCMS（Contents Management System）が、その役割を担うのに適した画面を提供してくれるというわけです。

前回は、画面のことについて論じたが、今回は帳票について考えてみる。帳票の枚数って数えたことがありますか？　おそらくすごい数になるのではないでしょうか。数もさることながら、その様式についても数多くの種類があり、しかも細かい。表の枠の角はまるみをおびていなくてはいけないとか、どうしてそんなことにまでこだわるのかと思えるケースが頻繁に出てくる。

だいぶ前の話だが、SAPが日本に導入が始まったころ、ある先進企業に行って事例を聞いたことがあったが、そこはアドオンの嵐で機能の７割がアドオンだったという、それならパッケージを入れなければよかったのに、と思える話で驚いたことがある。ところが、さらにびっくりしたのは、その7割のアドオンのその7割が帳票だったという笑うに笑えない話を思い出した。

ことほどさように、日本の企業は帳票が大好きで、帳票だけで仕事をしているのかと思うこともある。もちろん、法定帳票はしかたがないが、そのほかの帳票って本当に必要なのだろうか。

いったいどんな帳票を出しているのだろうか、「○○一覧表」「○○履歴」などなど、その帳票を見ながら、入力や指図、手配を行なうためのもののようだが、意外と気づかないが多いものにチェックリストがある。入力したデータ、計算されたデータが正しく反映されているかどうかチェックするのである。これらは、画面やファイルの閲覧で済ませられるはずだ。画面にしても、こうした閲覧に対しては、検索機能やプルダウンなどで相当改善されているはずで、しかもマルチウインドウズなのだから画面上に並べてみればいい。

確かに、紙の一覧性というのは捨てがたい利点ではあるが、帳票というのは、単に紙に出力するだけにとどまらないのだ。出力された帳票を綴じたり、糊付けしたり、そして最後はファイリングするというわけで、その手間や保管スペースはばかにならない。だから、ペーパレスはかなりのコストダウンにつながることなのである。

さらに、紙を回して仕事をすることはやめたほうがいい。捺印の問題があってそうすぐにはできないかもしれないが、それこそ、事業所や営業所をまたがって帳票を回すと郵送費をかけていているわけで、そうではなくて、紙（ファイル）は共通フォルダーにあって、情報がネット上を駆けめぐるというのが、これからの仕事のやりかたの主流でしょう。

一旦しみついたクセ（仕事のやりかた）は変えたくないのが人情だが、これからは絶対ペーパレスを指向すべきだ。

余談だが、だからと言って会社から紙がなくなる、あるいは大幅に減るとは思っていない。おそらく、画面を印刷して机の上に載せて仕事するひとも多いのではないでしょうか。まあ、それはそれで、かまわないと思う。持ち運ぶ必要もないし、ファイリングする必要もないのだから。

人はどういうプロセスで理論を組み立てていくのだろうか。もう少し情報処理的な言い方をすると、ルールや法則をみつけてそれをパターン化するという作業がそれに当てはまると思うが一体どうやっているのだろうか。個人的な情報処理という動きのなかでも、自分なりのプロセスで自分なりの法則を見つける、あるいは自分の考えが正しいかどうか検証している。

このプロセス、すなわち「理論」と「現実社会の実態」との整合性を調べる方法には「演繹法」と「帰納法」の２つがある。（「データはウソをつく」（谷岡一郎著））　「演繹法」というのは、特定の理論が、現実社会の実態と合致しているかどうか調べることで、「帰納法」とは、現実社会を計測し、データ化したものからそれらを矛盾なく華麗に説明しうる理論を構築することである。

マイクル・シャーマーの定義では、「帰納」とは、現存するデータから、一般的な結論を導き出すことによって、仮説を組み立てること、「演繹」とは、仮説にもとづいて特定の予測をたてることである。

そして、ほとんどの科学者が正しい方法論と考えるのは演繹法である。なぜなら、帰納法だと、データに合わせた理論を探すわけで、そうなると「ないものが見えてしまう」可能性があるということらしい。

ただし、以前のエントリーで「問題解決型」か「仮説検証型」かというのがあったと思うが、概ね「仮説検証型」のプロセスがいいということだが、結局どちらか一方だけではなく両方のバランスではないかと言ったことがある。この場合も同様で、必ずしも演繹法だけが正しいというわけではない。

例えば、実際には、とっかかりとしてはだれでも帰納法的なアプローチから入るのではないでしょうか。いろいろな事象をみてだいたいの理論の組み立てを行なうだろうから、これは帰納法的であるわけだ。

「生物と無生物のあいだ」（福岡伸一著）にもここのあたりのことがちょっと書いてあって、DNAのらせん構造を明らかにしたのは、ジェームス・ワトソンとフランシス・クリックであるが、かれらはそれこそ全く「演繹」的に自分たちの仮説を立証していったのだが、実はその陰にロザリンド・フランクリンというX線結晶学者の功績があったことはあまり知られていない。

DNA結晶にX線を照射して、その散乱パターンの写真撮影に成功していたのである。その写真を見てワトソンとクリックの理論ができあがったのである。彼女の研究の進め方こそ、全く「帰納」的なアプローチであった。ただひたすら個々のデータと観察事実だけを積み上げていった。ただ、DNAの構造を明らかにすることだけをめざしたのだ。一方、ワトソンとクリックは、直感やひらめきできっとこうなっているだろうというモデル化を行なってそれに近づこうとした。

おそらく、この両者のアプローチが合体したからこそ偉大な成果が誕生したのだ。何か革新的な業績を上げるには「演繹」的でなくてはならないが、それを後押しする「帰納」的なバックアップがなければ成し得ないと言える。

また、ITからそれてしまったが、情報処理のことでいえば、人間が「仮説検証型演繹的アプローチ」を担い、コンピュータが「問題解決型帰納的アプローチ」でサポートするという形になるのかなあと思ってみるのだが。

なぜみんなものごとを難しく考えるのだろうか。世の中に難しいものってそんなにあるのだろうか。だって、それぞれの構成要素にばらしていくとそれ自体は単純なものになっていく。単純なもの（こと）が集まると難しくなるのだろうか。

ここで、あたかも難しいように装っていることを考えてみる。どのようにしてわざと難しくしているのかということである。

・難しい言葉を使う・・・中味は単純なんだけど難しい言葉を使うので理解が難しい
・あいまいな定義・・・あいまいなことはどっちにするか迷うので難しくみえる
・誰かの受け売り・・・自分で理解できないから、言っていることがつじつまが合わない
・ディテールが気になる・・・些細なところが難しいだけなのに全体が難しいと思わせる
・量が多い・・・ひとつひとつは単純だが多すぎてさばくのが難しいだけのこと

こういうことって、よくよく頭の中で整理していくと、実は簡単なことだったりすることが往々にしてあるような気がする。

結局、単純化することが恐いのかもしれない。単純化とは標準化であり、汎用化だから、例えば自分の仕事を単純化したとたん誰か他のひとに取って代わられるかもしれない。また、レポートなんかでも、単純に簡素に書いてくれればいいのにあたかも私はこんなに一杯仕事をしました、あるいは私はこんなにいろんなことを知っていますよと言わんばかりに書き綴り、難しいレポートができあがる。私はこんな難しいことをやっているのですよとか、自分だけしかわからないことがあるように見せかけて自分の価値を高めたいという気持ちなんでしょうね。

ITを使って効率的な仕事をするというのは、こうした“エセ難解族”をなくすことにつながる。別な言い方をすれば、業務処理プロセスを単純化、標準化してITにのせていくわけだから、難しく考えていたらプロセス化できないのである。

だから、シンプル化志向でいかないと、ITで置き換われるようなことを依然として人間がやってしまって、ITではできない人間の能力である判断能力、分析能力を発揮することまで手がまわらなくなるという事態になる。この判断して、分析する能力を生かすことでITとよりよい補完関係を保つことができるのではないでしょうか。

これまでの議論からちょっとずれた話かもしれないが、ドキュメント化ということについて考えてみる。

システム開発を行なうとその工程の中に必ずドキュメント化というタスクが割り当てられる。要件定義書、機能仕様書、設計標準、データ定義書、運用手順書等々多くのドキュメントを揃えて、プロジェクトは終わる。

ちょっとここで当たり前のように作っているドキュメントって本当に必要なのか立ち止まって考えてみてもいいような気がする。なぜかというと、こうして一生懸命つくったドキュメントが稼動してからあとどれだけ使われているのかをみるとどうもあやしいのではないでしょうか。

最初の頃は開発したばかりだから、ドキュメントなんか見なくてもわかる。むしろ時間が経ってあれはどうだったかなあといって見るようになる。ところがそれにはそのドキュメントをきちんと抜けがないように永続的にメンテナンスをしなくてはならない。一度、書いてあるものと実際が合わなくなったら、その時点でそのドキュメントは信用されなくなるという宿命をもっている。そして、捨て去られたドキュメントがどれだけあるのか。

完璧なドキュメントを維持するのは不可能に近くなるということなら、いっそのことドキュメントを書かないで済まないか、あるいは、システムの一部として持つというふうには発想を変えられないかということである。

いま、内部統制やISO、セキュリティなどの絡みでドキュメント化の重要性が謳われているので、それに逆行するようなことを言っているのだけれど、単に紙に書いて残すということではなく、何か別の方法で、開発をしながら自然と仕様書だとか定義書だとかができてしまうというようにはいかないものか。

もちろん全く何も書かないことは難しいので、最小限のドキュメント化を指向すべきではないでしょうか。それが“システムの一部として持つ”ということにつながる。すなわち、泥臭くヘルプに入れてもいいですが、フレームワークやテンプレートあるいはコンポーネントの括りで機能をつかめば、そこに書いてある説明でだいたい事足りるはずだ。

例えば、家庭では家電や自動車はほとんど何も見ないであつかえますよね。そして、難しい設計書なんてもらいませんよね。

システム開発もなぜそうならないのだろう。それはみんな違ったものを作るからだとぼくは思う。だから、なぜそうしたか、どうやって作ってあるか、どう動かすかについてちゃんと説明できるものが要るというわけです。

繰り返すが、どうもドキュメント化しないといけないという常識にとらわれて無駄なことをしているように思えてならない。極論すれば、ソースプログラムがドキュメントなんだからそれ以上の説明は要らないとも言える。

このドキュメントを書かない、書かなくてもユーザは理解できるというのが、望ましいと思う。これは、具体的にはプログラムを書かない、既存のフレームワークを使う、必要最小限のことはヘルプに埋め込んでおくなどになる。それでこそユーザの使い勝手のよいＩＴになると思うのだがいかがでしょうか。

少し前のはてなの人気エントリーで1000ものブックマークをもらったものに「『忙しい人』と『仕事ができる人』の20の違い」というのがあった。小林英二さんという人の「モチベーションは楽しさ創造から」というブログの記事です。

この手の話は受けるのですね。忙しい人が多いのかもしれませんね。皆、自分の忙しさを何とかしなくてはと思ってはいるが、そこから抜け出せないでいる。ぼくは前に忙しさはドライビングフォースという記事を書いたことがある。そこにも書いてあるが、忙しいこと自体は悪くはなくて、むしろ忙しくないと脳が活性化しない。だから、忙しい人がダメだと誤解されそうなタイトルはよくないので、本当は「忙しさを嘆く人と忙しさを楽しむ人の違い」と言ったほうがいいのかもしれない。

このブログで言っている20の違いはどれもなるほどと思わせるものばかりで、思い当たるふしが皆あると思う。それで、この20の項目をながめていて、もうちょっと整理してみたほうがいいなあと、ほら理系の性分が頭をもたげたのであります。ぼくなりに煎じ詰めていったら次のような6つの要素で括れるのではないかと考えた。

１．忙しさに対する認識
「忙しい人」は、忙しいことをカッコイイと思っていて、その状態に甘んじて受け入れている。
「仕事ができる人」は、忙しいのは無能の証明だから、絶対いやだと思っている。

２．時間の使い方
「忙しい人」は、プライベートな時間をとらないので気分転換も出来ず体調不良になり、学習の時間も取れていないので成長もできない。
「仕事ができる人」は、優先的にプライベートの時間をとり、適度の運動や睡眠で快調、そしてどんなに忙しくても学習時間の確保しチャレンジしている。

３．時間に対する考え方
「忙しい人」は、スケジュールを作っても終了時間への認識が甘く、トラブル対応で乱され、納期ぎりぎりで仕事をする。
「仕事ができる人」は、スケジュールは絶対遵守する意識が高く、仕事を前倒しでかつ他の仕事と並行してこなすことができる。

４．段取り･準備
「忙しい人」は、納期がせまっているものを優先的に、目的を明確化せずに、また段取りに時間をかけずにに始めてしまう。根回しも出来ていないのであとでトラブルがおきてしまう。やっつけしごとばかりで、しかもルーティンの仕事に時間がとられる。
「仕事ができる人」は、仕事の目的を明確にし、十分な段取りや根回しで仕事を始めるので、目標に対する寄与・貢献度が大。同じような仕事は、何も考えずにできるようにしてあり効率的。

５．作業環境
「忙しい人」は、集中できる環境が作れない。電話がかかってきて邪魔される。
「仕事ができる人」は、集中できる環境が作れる。電話がかかってこないように手を打っておく。

６．コミュニケーション
「忙しい人」は、他人に依頼したことを忘れるし、他人に仕事を頼むのも下手で、仕事を断れなくてためこんでしまう。相手の期待以下なのでいつも手直しが発生する。
「仕事ができる人」は、自分しかできない仕事を中心に、他人にうまく仕事を頼んだり、フォローをして、相手の期待以上にこなし手直しがないようにできる。

勝手に煎じてしまいすいませんが、さらに乱暴に「仕事のできる人」の持っているスキル、資質をいまはやりの「○○力」であげてみると

１． 時間制御力
２． スタイル形成力
３． 業務遂行力
４． 段取り力
５． 環境構築力
６． コミュニケーション力

こじつけ風のところもありますが、なんとなく「できる人」のイメージがわいてきませんか。

いきなりITとサプリメントと言ってもどういう関係なのかわからない。別に直接関係があるわけではなく、最近サプリメントを採る人が増えた風潮をながめていて、これはITの世界も似ているなあと思えたので、こんな表題をつけてみたのである。

サプリメントは元来栄養補助食品だから、不足する栄養素を補充するものである。それがビタミンであったり、ミネラルであったりする。昔はこんなものはなかった。終戦直後はみな栄養失調だったけど、その後は普段食べている食物から採れば十分であったはずなのに、なぜこんなものがもてはやされているのだろうか。

健康ブームに乗った商法なんだろうけど、朝飯をカロリーメイトで済ましてしまう若者に受けたのかもしれない。さらに、年寄りにはあの手この手のサプリメントを提示し、ガンにならない、関節痛がなおる、ボケ防止などと煽っている。グルコサミンだ、ヒアルロン酸だと言われても何じゃこりゃと思ってしまう。亜鉛だクロムだといったものまである。

それで、これは○○の病気に効くというふうになっているが、それだけ飲んでも効果があるとは思えない。人間の体なんかもう数え切れない数の栄養素でバランスされているから、単品で摂取しても効くわけではない。

人間は誕生してからずーと食物からそれぞれの栄養素を採りながら健康維持できる仕組みになっているので、単体で採ってもうまくいかないのではないだろうか。結局、バランスのよい食生活をすることが一番なのだ。

そこでITの話である。なぜ似ているかというと、企業の情報システムを考えたとき、企業という組織体は健康で活発に活動しなければならないから、そのためにいろいろな栄養素を採ることになる。そのひとつがITであると考えられないことはない。

会社のどこかで血の流れが悪くなったら、そこにITを導入して流れをよくする、頭の回転が悪くなったので、そこをIT化して、いい判断ができるようにするといったことを考えると、何となくITの姿がイメージできますよね。

そんなとき、今のITはサプリメント発想に近くなってやしないかと危惧するのである。すなわち、処方箋としてすぐにミクロ的な技術やソフトウエアを提示して、それで解決できると言っているように見える。企業の仕組みは、人間と同じように様々な要素から成り立っているわけで、そうした全体を考えて、バランスのよい処方を提供する必要がある。

それをソリューションと呼んでもいいが、要は、局所的な痛みや不具合だけに目を向けるのではなく、それに至った体質だとか免疫力などから改善していくという姿勢が大事だということである。

もちろん、技術オリエンテッドという側面も必要ではあるが、そうしたときも常に根底にこうした本質を見る目と全体感、バランス感覚を忘れないようにしたいものだ。

先日エントリーした「「科学的」って何だ！」の中で、科学というのは「わかるか、わからないか」という世界の話で、人間が関わるところでの議論はみんな「納得する」の世界のことになるというようなことを書いた。

これを情報システムの世界についてみていくと、どうも今は「わかるか、わからないか」の世界ばかりで動いているような気がする。突き詰めれば、コンピュータの０か１かの話になるわけで、厳密さ、正確さが求められる。この厳密さはハードウエアとかOSのところでは当然であるが、アプリケーションの領域に行くとだんだんゆるくなってきてもいいのではないだろうか。

それが、コンピュータ屋さんはそこにまで厳密さを要求している。特に基幹業務と言われているところでは顕著だ。はたして、そこまで必要なのだろうか。

例えば、業務アプリケーションをながめてみると必ずしも「わかるか、わからないか」の世界だけではなく、「納得するか、納得しないか」の世界も現にあるといえる。フロントエンドのところや顧客接点では、まさにこんな世界ばかりではないだろうか。言い換えれば、システムというのはゆるいところからだんだん固めていくプロセスでもあるといえる。

そう考えると、一旦この厳密性を外してみたらどうだろうか。ゆるくするのだ。どういうことかというと、極論すると、決まった処理順序、規則などを決めないのだ。もっと人間臭い世界にするのだ。

少し飛躍するかもしれないが、これはWeb2.0の本質のひとつではないだろうか。集合知や参加型のアーキテクチャなんてゆるさそのままの世界でしょう。

飛躍ついでにさらに言うと、よくSEは業務をわからなくてはいけない、業務の経験がないと要件を固められないと言われますが、この場合の業務というのは、おそらく現場の人が長年培った仕事のやり方であるはずです。もしそうなら、いつまでたってもわかるはずはない。例外的な処理やその人独特のやり方で固まっているわけだから。会社って組織的に動いているようで、実は個人でしか動いていないんですね。

そこでだ。そんなものは要件にしてはいけない。単なるひとつのケースとしなくてはならない。ただし、例外や固有を省いたところは厳密なものになる。そこは、“科学的”な世界にもって行けるので、業務を知らなくても論理的な思考回路をもっていれば要件定義ができる。

“納得”の世界はゆるくしてやればいい。そして、“納得”したいひとに作らせればいい。

若いSEのひとよ、おまえこんなことも知らないのかと怒られても嘆くでない、あなたの知らない業務はどうでもいいことなのだ。あなたが、磨かなくてはいけないスキルは、確定させたデータを会社のコアデータベースにどうマッピングさせるかということだ。
　
この硬軟をもたせてバランスをとることこそ、これからのシステムおよび開発に望まれるものと思う。