タイム・コンサルタントの日誌から(2003年)
Christmasメッセージ--クリスマス・ツリーの法則 (2003/12/23)
今から18年ほど前、私は研修派遣先の米国東西センター(East-West
Center)で、初めて外国でのクリスマスを体験していた。東西センターとは米国連邦政府がアジア・太平洋地域の学際的な研究と教育のために設立した機関で、ホノルル市に本部が置かれている。ハワイ大学のキャンパスに隣接しており、学生や研究者の行き来も自由で、ある程度一体化して運営されている。
観光地ワイキキだけでしかハワイを知らない人に(念のため)言っておくと、ハワイはアメリカである。当たり前のことを言っているようだが、ハワイは米国の主流派、つまりキリスト教徒の白人の文化が支配している。ハワイ州自体は特殊なところで、大陸本土からも離れているし、また20世紀初頭に統合されるまでは、独立した王国として、ポリネシア系の人々が米国とは別の言語・別の文化・別の宗教をもって統治していた。しかし、今では完全に米国の一部として、かなり文化的な同化が計られている(ここらへんはかつて琉球王国だった沖縄県の地位に似ていなくもない)。
私のいた研究所のオフィスは、クリスマスが近づくと、研究スタッフや秘書たちがお祭りらしい装飾をしはじめ、フロアの中央にクリスマス・ツリーを置いた。天井近くまである、かなり大きくて立派なツリーである。もちろん、もみの木だ。そして女性たちが嬉々として赤や金色の飾りを枝にぶら下げ、最後に白い綿を枝にのせて雪の降り積もった景色を創り出す。
そのホールでクリスマス・パーティを開き、ケーキや飲み物を楽しんで、小さな贈り物を交換しあう。それはなかなか心温まるひとときだったが、参加しながらも、私は軽いめまいのような気分になった。なぜなら、実はそこは冷房のきいたオフィスであり、窓の外を見ると、椰子の樹の葉が強い陽光に照らされて、緑に光っているのだ。どうしてこの常夏の島にあって、針葉樹に雪の降り積もる、北国の風景をクリスマスのために演出しなければならないのだろうか? 私はそこで、「クリスマスツリーの法則」とでもいうべき心理的な慣性の存在に気がついたのだ。
私の気づいた「クリスマスツリーの法則」とは、“クリスマスツリーはクリスマス自体よりも異国に流通しやすく、クリスマスはキリスト教自体よりも異文化に伝播しやすい”、ということだった。いいかえれば、「思想の体系よりも祝祭の方が人に印象を与えやすく、さらに祝祭よりも祭りのシンボルの方が、移転しやすい」ということだ。
現在のクリスマスは、もともと欧州の北方地域における「冬至の祭り」が、キリスト教に習合して出来上がったものだ。新約聖書によれば、イエスの誕生の時には羊飼いたちが野宿をしていたわけで、季節が冬であったはずはない。しかし、いつのまにか一年が最も暗く底に近づく北国の冬の祭りとして定着し、育ってきた。だから樅の木であり、降る雪であり、サンタクロースにトナカイなのだ。
そして、同様な法則は、じつは人間活動にかかわる、あらゆる分野で見つけることができる。無論、ITの世界でも。経営管理の思想体系よりは、ファッショナブルなメソドロジーの方が流通しやすいし、さらにITツールの方が売りやすいという事実がある。ITツールは、ときには元の理念を離れて、どんどん一人歩きしていってしまう。たとえば計画思想を忘れたAPSのように。それはホノルルで北国風のクリスマス・パーティを楽しむことに似て、少々不思議な光景ではある。
そうした現象の滑稽さについて、私は繰り返し批判してきた。しかし、それもまた思考の変化をうながす一つの契機だとすれば、それほど無価値であるとは言い切れないな、と最近は思うようになった。
「日本人はキリストも信じていないくせにクリスマスを祝うのはおかしい」という人もいる。また、「クリスマスはキリスト教とは本来無関係なのだから祝うべきではない」という厳格なクリスチャンもいるようだ。しかし、私はどちらにも賛成できない。私は祝祭は宗教にとって本質だと思うし、世界中でより大勢の人が平和を祈る方が、そうでないよりはずっと良いと思うからだ。
シンボルは祭礼への通用門であり、祭礼はあらゆる宗教が抱える中心命題、すなわちこの世の意味についての問いに通じていく通路なのだ。誰もが、より良く生きたいと、心の内では願っている。そして、1年の底にあたる冬のこの時期に、来年はより平和で、より喜ばしい年であるようにと思い、また家族や友人たちにもそう願う。今年もまた、18年前に異国で知り合った友人たちに、クリスマスのメッセージを送る季節になった。日常の違いを超えて、少しでも私たちが分かり合えるように祈りながら。
Merry Christmas!!
カリフォルニア州のハイテク産業は、まだ失業率が増え続けているが、その増加の速度は鈍ってきている、という。その日の朝の新聞には、そんな記事が出ていた。
「でも、そんな統計なんか調べなくても、シリコン・バレーの景気を見るもっと簡単な方法があるんです」--隣の運転席でハンドルを握っているソフト会社のマーケティング・ディレクターは、私にそう言った。サン・ノゼのダウンタウンにあるインキュベーションオフィスから、私を空港まで送ってくれる道中のことだ。「それは、この街の車の混雑でわかるんです。一時はほんとにがらがらだったのに、最近はまた少しずつ車の数が増え始めていますから。」
米国のIT不況は、ようやくシリコンバレーの中心地で、底を打ちはじめているらしい。しかし、その牽引役となる技術的ブレークスルーが何なのか、私自身にはまだよく分からない。オープンソースか、Web
Servicesか、Wi-Fiか、XMLか--その直前に参加したCOMDEXのトピックに頭をめぐらせたが、これだ!というべき花形が思いつかない。まさか、いくら話題になっていたとはいえ、ウィルス対策やSPAM防止が産業全体を引っぱるとは思えないし・・・。
運転しているその人は、以前はApple Computerに勤めていて、日本にも何度か行ったことがある、と言う。じつは、私も早くからのMacユーザーでしたよ、と答えた。そうだ。今でこそ会社でも家でもWindowsを使っているが、私が最初に個人で買ったコンピュータはMacintoshだった。1987年のことだ。Appleが発表したばかりのソフト"HyperCard"のデモに感激して、Mac
Plusを買いに走ったのだ。そのときの興奮や期待に満ちた気分を、私はずいぶん久しぶりに、なつかしく思い出した。
あの不思議な高揚感を、いまIT産業のどこに見いだしたらよいのだろう。2001年のネット・バブル崩壊以来、B2Bから一転して内向きになりだした企業の情報システムは、次第にERPの機能的肥大化への道を走りだしている。今ではライバルの進化を止めるために敵対的買収をかけるところまで、ことは進んできてしまった。巨大な資本力を持つごく少数のソフトウェア企業しか、この業界は生き残れないのだろうか・・
そのとき、私のバッグの外ポケットに入っていたHP200LXのアラームが鳴りはじめて、私は空想から我にかえった。HP200LXは個人用電子機器(PDA)のはしりの時期に現れた名機だ。Hewlett
Packard自身はもう何年も前に、この機器の製造を中止したのに、私はいまだに肌身離さず持ち歩いている。万が一の時のため、家にはもう一台同じモデルを買って置いてある。そして、このHP200LXは、なんとまだDOSベースで動いている。私はまだDOSアプリを使っているのだ。
私がHP200LXから、ほかの最新鋭のPDAに乗り換えないでいる理由は単純だ。このマシンのハードとOSとソフトが、非常にバランス良くできているからだ。200LXは、80186というCPUをもつ、掌サイズのIBM
PCコンパチの機械だが、HPはそこに、使いやすいOS風Shellをかぶせて、その上で動くアプリを何種類もROMで提供した。その中にはQuicken,
Lotus 1-2-3, cc:Mailなどがあり、また各種の商業ソフトやフリーソフトが出回っている。井上毅氏作のアウトライン・プロセッサ「IP」は、「革新的生産スケジューリング入門」をはじめとする私の本の原稿を書き起こすときの、とても大事な道具だ。
なぜ、このマシンは名機なのか。それは、設計思想がきわめて明確な「見切り」の上に立っているからだ。カラー液晶も、バックライトも無い。そのかわり、単3電池2本で、1ヶ月は動く。ごく小さいが、クリック感の明瞭なフル・キーボードを持っている。このマシンの設計者は、何が重要で何が余計かを明晰に見極めて、不要なものは見事に切捨てたのだ。その結果、この小さな機械は1991年に市場に現れたときの姿のままで、現在でも価値を持って生き続けている。
ここには設計思想がある。そういえば、Apple Macintoshもまた、きわめて個性的な設計思想でつくられた商品だった。好き嫌いはとにかく、語るに足りる思想Design
Philosophyがあること--それが、本当は初期のITに感じた高揚感の源泉ではなかったか。
そして、思想とは見切りなのだ。何をとるかではなく、何を捨てるかについての。それは、ユーザ(使用する人間)に関する洞察から生み出される。だから、「思想」は市場調査からは生まれてこない。
おそらく、思想などというものは巨大ビジネスに成長するには邪魔なのだろう。Appleが最後までメジャーになりきれなかったのも、Sunが苦しんでいるのも、そのせいなのだ。今は無思想の巨大OSベンダーやERPベンダーが跋扈する時代だ。しかし、あまりにも巨大な存在は、自らを壊してしまう力(カウンターベイリング・パワー)を呼び寄せる可能性がある。だからこそ、我々はもう一度、頭をリフレッシュして、「思想」に立ち返る必要性があると思うのだ。
米国で開かれる世界最大のコンピュータ業界の展示会・COMDEX Fallは、毎年業界の大物が基調講演に招かれ、その内容によってITの世界のトレンドが計られるイベントだ。私は今年、2日間ほど見学する機会を得たが、11/17に行われたSun
Microsystems社CEO、Scot McNealy氏の基調講演は、なかなか興味深いものだった。
周知の通り、Sunは’90年代半ばからunixサーバ製造とJava言語の開発で躍進してきたが、このところDellなど低価格なWindowsサーバの追撃に合い、収益は低迷している。
Sunの発表したポイントは4点あった。まず、低価格なCPUチップメーカーである、AMD社との提携を発表したこと。AMD社のチップはIntel
x86と互換性のあるアーキテクチャで、これまではPCに使われてきた。Sunは自社製品のSPARCチップ路線を(ある意味では)捨ててでも、低価格サーバ製品にIntel互換のCPUを使うことで価格競争力を回復させようとしている。
2番目に、Java DesktopとSmart ID Card(一種のSmart ID Card)という新製品の紹介をした。Java Desktopは、現在Windowsがほぼ独占しているDesktop
PC市場に挑戦する製品で、モニターと小さな筐体とキーボードのみからなる。ハードディスクもCD/DVDドライブもついていない(らしい)。いわゆるThin
clientのコンセプトである。そして、かわりにネットワークに接続し、サーバ側からアプリケーションを実行する。
アプリケーションの中心は、Sun社のStar Office Suiteである。これはMS Office互換製品だが、価格が圧倒的に安い(オープンソースのためライセンスは無料で、年間サポート費が$50のみ)。そして、インターネットでMicrosoft
社のホームページにアクセスして、PowerPointやExcelのファイルを何の問題もなくあけてみせるデモをした。
3番目のポイント(そしてメディアが一番関心を示したニュース)は、このJava DesktopとStar Office製品を、中国のIT産業政策の中核を司る中国標準ソフトウェア公社(CSSC)に対して、何と一気に50万セットもの販売契約を結んだ、という発表であった。つまり、中国はMicrosoft社の独占を嫌って、オープン・ソースに未来を託す決断を下したという訳だ。中国が今後何億台のデスクトップを使うことになるか、想像してみて欲しい。今後の世界規模のITビジネスを考える上で、このニュースが示唆するところは非常に大きい。
しかし、技術的に言うならば、もっとも興味深かったのは、Java Desktopと組み合わせたJava Cardの利用である。Java
DesktopにはID Card用のスロットがあり、ユーザはここにカードを差し込むだけで、すぐにログイン可能な状態になる。そして、いろいろと作業をした後、カードをいきなり(ログアウトもせずに)引き抜くと、別のJava
Desktopに差し込んだ。すると、さきほどの作業状態が完全に再現されるのである。IDやセッションなどの情報がすべてカードに記憶されるため、いちいちPCを持って歩かなくても、どこでも自分の作業環境をすぐに作れる。
彼の基調講演自体は非常に面白かったし、こうした場で話のうまさを披露できる米国の企業経営者が多いのは、うらやましいことである。しかし、このニュースに対して、その日のSunの株価はほとんど変化がなかった。目前の収益に直接結びつくニュースが欠けていたからだろう。Sunの苦境は、自社のunix
OSであるSolarisの改良にもたもたしている間に、世間の注目がLinuxに移ってしまったことにある。Java desktop自体、実はSolarisではなくLinuxベースなのだ。ハードメーカーとしてのSunは、これからが正念場となるに違いない。
なお、MicrosoftのBill Gates会長の講演は日程の関係上、きくことができなかった。しかし、関連記事の内容から見て、新バージョンであるWindows
Sercer 2003の紹介、Active Directoryの利点の説明、セキュリティ対策の強化などを話したようである。また、現在開発中の新OS(コードネームは"Longhorn")の紹介もあったはずだ。
Longhornは、まったく新しいWin FS というファイルシステムを持ち、メールも画像も音声も同じ操作方法でナビゲーションできるらしい。この製品は2006年発売予定である。が、あまり待ち遠しくはない。
私の感覚からすると、ファイルシステムを少しぐらいいじったり、操作方法に手を加えたりしても、イノベーションとは言えない。もういい加減「ファイル」という概念から脱皮するくらいでなければいけない、と思うのだ。人間が操作したい対象は、所詮データのオブジェクトである。それがファイルなのか、DBのレコードなのか、はたまたビューなのか、そんなことはもはやユーザが心配すべき事ではないはずだ。
Sunの発表は面白かったが、その発想はこれまでの発展の延長線上にあるものばかりで、その「面白さ」はもっぱらMS対Sunというシーソーゲームの観客的面白さでしかない。サーバ、デスクトップ、ネットワーク端末、オフィス・アプリケーション・・・そういった「カテゴリー」の中で、価格競争や多少の機能競争をしたからといって、今のIT業界の苦境を救えるとは、私には思えない。
「ITって、何?」の第16回にも書いたように、IT業界の発展とは、つねに“新しいカテゴリー”の創出によってダイナミックに生み出されてきたものだ。定まったカテゴリーの中での改良競争だったら、モーターショーの新車競争と何が違うだろうか。ドットコム・バブル崩壊後、地盤沈下し続けるITの世界を立て直すために、そろそろ発想の構造改革をしなければならないときが来ているはずである。
先日、最適化エンジンのベンダーの方とお話しする機会があった。線形計画法のパフォーマンスの改善、混合計画法と制約論理言語の組合せなど、興味深い話題がつきなかったが、そのうち、こんな質問を受けた。「どうですか、最近、スケジューリングなど最適化ソリューションにかかわるビジネスの方は好調ですか?」
私はこう答えるしかなかった。「最適化はビジネスにはなりません。我々の顧客が抱えている問題は、最適化以前の段階で解決を必要とするものがほとんどですから。それに、私が最適化エンジンを組み込んだシステムを顧客におさめる時も、私は口が裂けても『最適化』などという言葉は使わいません。」
ご承知の通り、私は前から“スケジューリングは最適化の問題ではない”、と一貫して主張してきた。自分の本にもそう書いたし、学会発表でもそう述べたし、またこのサイトでもそう主張してきた。しかし、これまでのところ、私の主張に賛同していただけたのは、APS導入のコンサルティングに真面目にかかわっておられる、ほんの一握りの実務家にすぎなかった。
で、現実はといえば、ベンダーはあいかわらず最適解という夢を商品に売りたがるし、高級(高給)経営コンサルは最適戦略を語りたがっている。大学の研究者達は最適化手法を論文にしたがるし、ジャーナリズムは最適化が日本の製造業を救う、との物語を作りたがる、という訳だ。
「しかし、佐藤さん。求めるものが最適解ではないとすると、いったい何なんですか?」
「簡単です。実行可能解ですよ。製造業の世界では、実行可能解を探すこと自体がたいへんなんです。最適化エンジンを使うのも、ベターな解を効率よく見つけたいからで、ベストな解なんて最初から求めちゃいません。」
「そりゃ、たしかにMRPなんかは無限能力計画だから、実行不可能な解が出てくるでしょう。しかし、今のAPSを使えば、実行可能解などいくらでも作れるでしょう?」
そこで私は、化学産業の典型的なバッチ・プラントの実例を出して、普通のAPSでは問題が解けない理由を、1ダースぐらい立て続けに並べた。その詳細については、すでに「バッチ・プロセスにおけるスケジューリングの特徴」で述べたから繰り返さないが、要するに、APSの中で作る生産モデルというのは、現実の製造工程が持つ多種多様な制約条件の近似でしかないのである。問題を正確に記述できないのだから、出てくる答えも近似解であって、その最適性を云々すること自体、ナンセンスなのである。
しかし、もう一つ私はつけ加えるべき点があった。「そもそも、最適はおろか実行可能よりも以前に、多くの製造業では乗りこえなければいけない課題があります。それは、可視性という課題です。そもそも、自分が製品や半製品や原材料をどれだけ抱えているのか、そのうちどこまでが引当可能なのかさえ、把握できていないようでは、どうやって正しく実行可能性を判断できますか? どのワークセンターにかかっているどのロットが、どの受注オーダーに対する仕掛品なのかも判別できずに、誰が工場をコントロールできますか?」
私が主に現在かかわっている、ERPやMES、WMSなどの実行系システムは、もっぱらこの『可視性』を確保するための仕組みである。私はつねづね、製造におけるITは車のカーナビのようなものだ、と説明している。MESやWMSはいわば、GPSで自分のいる位置を可視化するための装置なのである。そして、APSというのは、より近くて混雑の少ない道を示してくれる、最新式のカーナビのようなものだ。
そして、カーナビの地図に相当するものが、製造業における標準手順書や部品表、マスタの類だ。まず、ここから整備し直さなければならない顧客も、実はずいぶん多い。ほとんど、まともな地図も持たずに車を出している運転手のようだ。
だが、地図を持っているだけでも、ましかもしれない。どの道を通って、何時にどこに行ったか、記録さえしていない会社だって、実はたくさんある。とりあえず、目的地には着いたというだけで、これでは町の流しのタクシー運転手以下である。実際に行なったことを記帳する--これが最低限の管理レベルであろう。
こうしてみると、製造業にはいくつかの管理レベルがあり、それぞれのレベルごとに抱えている課題が違っていることがわかる。IT業界の方は、プロセス能力成熟モデルCMMをご存じだろう。5段階に分かれていて、こういうやつだ:
Level 5 Optimizing
Level 4 Managed and Measurable
Level 3 Defined
Level 2 Repeatable but Intuitive
Level 1 Initial/Ad Hoc
これにならって、勝手に製造業の管理レベルを決めさせてもらうと、こんな風になる:
(1)最適化(Optimized)のレベル:理想だが、不可能
(2)実行可能(Feasible)のレベル:事実上の最高水準。SCPを活用。
(3)可視的(Visible)のレベル:大企業も、多くはこの段階。ERPやMESを導入中。
(4)稼働(Operable)のレベル:一番普通のレベル。互いに整合性のとれない台帳データや帳票類が各部門に分散していて、バケツリレーで仕事をこなしている。
(5)記録された(Trackable)レベル:最低の管理レベル。これ以下は企業活動の名に値しない。
さて、あなたの知っている企業は、このうちどこに当てはまるだろうか? また、工場の外側に目をやると、企画や営業や調達などのホワイトカラー業務は、どうだろうか? 最適化まで、はるかなる険しい道のりが、まだ続いているようでなければいいのだが。
組織能力を支える、プロジェクトの"気づき"(2003/10/26)
最近、プロジェクト・マネジメントに関する注目が高まっている。とくにIT企業でそれが活発だ。
今年の秋に開かれた、米国PMI(Project
Management Institute)の大会でも、その傾向は明らかだったようだ。恒例の「Project
of the Year」発表では、ソルトレーク・シティ冬季オリンピック遂行Projectがトップ授賞した。が、その他はPMIの従来の伝統にしたがって、重厚長大型産業の建設プロジェクトが選ばれた(ちなみに昨年度のProject
of the Yearは、小生の勤務先・日揮が参画した、Hawiiyah
Gas Projectだった)。しかし、授賞式はがらがらだったとのことだ。もはや大半の参加者はIT関係者であって、こうした分野には興味を持てないのだ。
右足をエンジニアリング業界に、左足をIT業界においている私のような人間の目から見ると、PMIの策定したPMBOK Guideは、あまりにも重厚長大型プロジェクトに偏り過ぎているように思える。だから、逆に最近のIT業界の「PMBOK熱」ともいうべき状況は異様に思える。所詮ガイドブックにすぎないPMBOK
Guideの一言半句を暗記して、どうなるというのか。もともと、教科書に頼り過ぎる人間は、プロマネには向かないのに。
とはいえ、プロマネ払底の日本のIT業界にとっては、何も知らずにプロジェクトを切り回すより、PMBOKでもいいから基礎をきちんと理解する人間が増えるのは、歓迎すべきことである(ついでにいうと、日本のIT業界はアナリストも払底しているのだから、米PMIに"ANBOK"かなにかを作っていただくといいかもしれない)。
ところで、ITよりも他の業界に目を転じると、世の中には、もっとはっきりプロマネがいない分野が多数ある。その典型が、日本の中堅ゼネコンと、受注生産の産業設備・機械(重工メーカー)の世界である。医薬品開発や金融商品開発も、それに近いところが多い。こうした企業では、プロマネが足りない、のではなく、そもそも全然いないのだ。なぜプロマネが存在しないのかというと、そこで行われている仕事が『プロジェクト』として認識されていないからだ。
プロジェクトとは何か。私の考えでは、それは三つの条件をみたしている必要がある。
(1)複数の人間の共同作業であること、
(2)ゴールを達成すると終了すること、そして
(3)なんらかのリスクをともなうこと、
の三点だ。そして、その観点から見ると、明らかに「それはプロジェクトです」といいたくなる仕事は、上記に限らず、いくらでもある。
にもかかわらず、組織内の多くの活動が、プロジェクトと認知されず、責任主体のプロマネがいないために、本来なら持ち得たはずの効率を達成できずにいる。まあ、最終的な責任は誰かの上にかぶせられるのかもしれないが、必要な権限を与えられなければ、誰がすき好んで仕事の成り行きに責任をとるだろうか。
プロマネがいないから、プロジェクトと認識されないのか。それとも、プロジェクトという認識が足りないから、プロマネが任命されないのか。ほとんどの場合は、後者だろう。「これはプロジェクトだ」という"気付き"が鍵なのだ。
ちなみに、現在のPMBOK Guideでは、この"気付き"を助ける仕組みが、いささか欠けている。プロジェクト・マネジメントの能力は、じつは組織の持つ、この気付きと、それを支える人々の習熟度に深く依存している。
PMIは、組織全体でのPM能力を評価するために、近いうちに"Organizational Project
Management Maturity Model"(通称"OPM3")とよぶ基準を発表する予定だ。また、これとは別に、カーネギーメロン大学のプロセス成熟度モデルから発展したCMM
Integratedと呼ばれる基準も、PM能力評価に関連して注目を集めている。ただし、この両者とも、組織をアセスメントするには、いささか大げさなものになりがちだ。
そこで最近私は勤務先で、もっと簡便な組織のPM能力に関するアセスメント・ツールを開発した。これは、特定のプロジェクトマネージャに対しても、事業部や全社組織レベルに対しても、使えるようになっている。また、PMI/PMBOKが主に想定するような大規模・物量中心のプロジェクトだけでなく、知的成果物中心のソフトなビジネス、あるいは製品開発型のプロセスに対しても、適用できるよう工夫した。さらに、単一企業組織だけでなく、コンソーシアムや自発的参加型NPOの活動にも使えるようになっているつもりである。(まだ正式に公開していないが、興味ある方は小生までお問い合わせください)
多くの組織における問題は、PMBOK Guideの手法を単純にインプリメントするだけでは解決しない。そもそも、「これはプロジェクトである」という気づきが、多くの人に欠けているからだ。組織全体のPM能力をアセスメントするための諸手法が、これを助けるヒントになれば幸いだと思っている。
サプライチェーンのリスク・マネジメント(その2)
--解決のありか(2003/10/10)
最近、米国では天然ガス価格が高騰している。政府と石油ガス業界の関係者、そして大口ユーザである化学業界や電力(発電)事業者等が集まって会議を開いたが、うまい解決案にいたらずに終わった。合意できたのは、省エネルギーへのさらなる努力が必要だ、という、あたりまえの方針だ。もっとも、これまでブッシュ政権は、「省エネは個人の問題だ」といって済ましていたのだから、この“あたりまえ”の合意だって多少の前進ではある。
天然ガス価格のみならず、石油の価格も世界的に高止まりを続けている。石油が下がらない事に関しては、昨年末からつづいたベネズエラのゼネスト、米国がしかけたイラク戦争の混乱など、説明可能な要因はあった(これらのリスク要因については、一応私もこのホームページにおいて「ベネズエラの『痛みを伴う改革』」「海の向こうで戦争がはじまる」などで、繰り返し注意を喚起してきたつもりだ)。
しかし南米一の石油大国を揺るがしたゼネストが終焉し、イラク戦争も一応の決着がついてアラビア湾の航行に安全が戻っても、不思議なことに石油価格は世界的にあまり下がらない。これから北半球は冬を迎えるのに、灯軽油が高価なままだと、欧州や東アジアの庶民生活を直撃するだろう。
これらの現象について、(財)日本エネルギー経済研究所は、じつは米国内のサプライチェーンの脆弱さが原因だと分析している(日本経済新聞9月5日記事)。今年だけでなく、原油価格は2000年にも高止まっていた。この時は、戦争もゼネストもなかった。これは米国北東部の大寒波がきっかけで、石油製品の在庫が異常な低水準になったからだという。
サプライチェーンの在庫が払底して、市場における融通の自由度が失われると、サプライチェーンのリスクに対する危険性が高くなる。その状況は、価格にすぐに反映する。
米国内のガス消費量は過去10年間で35%も上昇し、石油消費量も増え続けている。しかも、米国は産油国でありながら、すでに石油の55%を輸入に頼る状況になっている。2001年にはカリフォルニアで大規模な停電が起こり、それは結局、今回のDavis知事のリコールの遠因になったが、その原因は発電用の安価な天然ガス不足だった。需給のバランスが、あきらかに合わないのだ。
米国のガス価格高騰のおかげで、世界の石油市場も高止まりになる。天然ガスと石油の価格が世界でいろいろな形でつながっているためだ。こうした米国のサプライチェーンの脆弱さが原因で、世界的に石油の値段が跳ね上がるのでは、たまったものではない。
サプライチェーン・マネジメントの教える戦略は、サプライチェーンのリスク管理に真っ向から対立する、と前回書いた。前者は供給経路をスリム化して在庫をゼロにしろと説く。後者は供給経路を冗長にして在庫を持て、と教える。では、どうしたらいいのか。
そのヒントは、通信工学にある。通信路における情報伝達速度の向上と、耐ノイズ性の向上との矛盾は、サプライチェーンの悩みとよく似た問題である。そして、通信工学(情報工学)の教える方策は、こうだ。(1)まず、通信電文を効率よく符号化して、可能な限り無駄を省いて圧縮する。(2)次に、意図して冗長性をつけ加える。ただし、その冗長性は、受信側がノイズを除去できるようなロジックにしたがって、つけ加えなければならない。この手法は、シリアル通信におけるチェック・ディジットからATM通信に至るまで広く応用されて、成功を収めている。
われわれがサプライチェーンの問題に取り組むときも、方針は同じだ。
(1)まず、冗長性を省く。不要な在庫や過剰な供給経路を発見して、すべて排除すること
(2)つぎに、意図して冗長性を付け加える。つまり、脆弱性の予見される部分に、バックアップ的なサプライヤーや、変動を吸収するためのバッファー在庫をおく。「良い在庫・悪い在庫」で述べたように、“出来ちゃった在庫”ではなく“意図した在庫”は善なのである。
このような手順を行なえば、サプライチェーンのスリム化とリスク管理のバランスをとることができる。英語のことわざに、『すべての卵を一つの籠に入れてはいけない』というのがあるが、分散化がリスク管理の基本である。意図した在庫とルートの分散化こそ、サプライチェーンの強靱さを守るのである。
サプライチェーンのリスク・マネジメント
(2003/10/01)
偶然にも先月は国内で工場の事故・火災があいついだ。新日鉄の製鉄所で爆発事故があったと思ったら、すぐにブリジストンの工場でも火災が発生し、かと思うと今度は地震が引きがねとなって出光興産の製油所のタンクが火を噴く、といったぐあいだ。30日の夜には新日本石油の製油所まで出火があった(こちらは幸い短時間で鎮火したが)。
出すだろうな、と思ったら案の定、経済産業省は工場の安全体制について指示だか通達だかを出した。問題が起こったら、あわてて指示を出す。問題が起こらない限り、何の確認も質問も出さない。お役人というのは(少なくとも経産省という役所は)、前もって問題を予知しリスクに対処するという、プリベンティブ・メンテナンス(予防保全)やリスク・マネジメントの考え方が、さっぱり身に付いていないところらしい。
ところで、新日鉄とブリジストンの工場の火災事故で、トヨタが自動車生産量を見直す羽目になったと報じられている。大規模な爆発事故が起こったのに、有害物質拡散の事実確認や近隣住民への影響をさておいて、自動車メーカーの生産量を心配するとは、ずいぶんこの国のメディアは報道スタンスが歪んでいるな、と思う。が、それはさておき、この日本のサプライチェーン・マネジメントの模範生である自動車メーカーの困惑は、想像以上だろう。
じつは、リスク・マネジメントで必要とされる方策は、一般にサプライチェーン・マネジメントが教える戦略と、真っ向から対立する。そのことに多くの人は気がついていないようだ。そして、両者を同時に満足できる原則とはどのようなものか--これが今回のテーマだ。
サプライチェーン・マネジメントの参考書では、だいたい、次のような戦略が推奨されている:
(1)不要な在庫を削減し、在庫量をサプライチェーン全体にわたって最小化すること
(2)サプライヤーの数を絞り込み、安価で継続的な供給が実現できるようアライアンスを組むこと
(3)需要と供給を機敏に同期化できるよう、計画と意思決定権限を集中化すること
ところで、供給活動において、リスク・マネジメントの見地から必要とされる方策は、どのようなものだろうか。リスクというものは、それが小さな故障であれ、ディザスターと呼ぶしかないような大規模な災害であろうと、正確には予見しがたい事象のことを指す(規模の大小というのは、それを計るものの立場で決まるわけで、絶対的な基準があるわけではない)。
サプライチェーンというのは、物的供給のためのシステムである。サプライヤーからメーカーを通り、販売者から最終消費者へと、商品を受け渡す仕組みである。それを動かすのは需要情報や指示情報だ。そこにおける予期せぬ外乱とは、すなわち、供給経路が遅延ないし遮断されたり、ストックが物理的損害を受けたり、情報が隔絶したりする事象を指す。
したがって供給システムが、予期せぬ外乱や遮断に対して、安定性を保つためにとれる手段は、基本的に二つしかない。それは、どこかに変動を吸収できる余分なバッファーをもうけるか、あるいは供給経路を冗長化するか、である。つまり、言いかえれば、在庫をもつか、さもなくばサプライヤーを複数用意するか、なのである。上記の(1)と(2)の要請と、真っ向から対立することが、これでおわかりだろう。
さらに、物的供給経路ではなく、情報経路が遮断されるリスクに対しては、意思決定権限をローカルな単位に分散して、中央からの指示が無くても自律的に行動を続けられるようにするしかない。つまり、(3)の要請に背くわけだ。
こう考えていくと、サプライチェーンのリスク・マネジメントがいかに矛盾に満ちたものであるか、理解できると思う。それでは、この二律背反を解く原理や方法はないのだろうか。じつは、あるのだ。それも、思いがけないところにヒントがある。長くなってきたので、これについては、次回書きたい。
(この項続く)
The Time Value
of Money(その3)--無償のものの便益 (2003/09/09)
プロジェクトの経済性を分析する際には、財貨の時間的価値を考慮する必要がある。そのために開発されたDCF法(Discounted
Cash Flow)では、金利に類似した「切捨割引率」という概念を導入し、プロジェクトの将来にわたるキャッシュフローを現在価値に割り戻して、収支を評価するのだ、と前回書いた。
その例に挙げた農業設備のプロジェクトでは、初年度の投資額15億円に対し、1年度から25年度まで毎年1億円の収益があるとしても、割引率5%で計算すると、純現在価値(NPV
= Net Present Value)はマイナス9千万円以上になる。したがって、このプロジェクトは経済的には成り立たぬという結論が導かれた。
ところで、このケースを、切捨割引率を少し低くして4%で計算すると、純現在価値は6,221万円の黒字となる。4%ならばプロジェクトの採算はプラスになるわけだ。そこで、割引率が何%のときに、プロジェクトの純現在価値がちょうどゼロになるかを逆算してみると、4.39%という数値を得る。これを、プロジェクトのROI(Return On Investiment)という。
ROIとは、プロジェクトの価値を金利に換算した数値である。ROIが高ければ高いほど、価値が大きい。したがって、互いに独立した複数のプロジェクト計画があって、その投資の優先順位を決める場合には、投資額の大小ではなく、ROIが高い方から選んで行くべきである。これは、要するに、金融工学と同じ思想である。
ところで、世の中には、収益に直接リンクしないプロジェクトも沢山ある。たとえば、川に橋を架けるプロジェクトはどうだろうか。通行料を取れるような橋は例外で、多くは無料で利用だ。あるいは、業界の関係者が集まって、特定の標準規約を定めるプロジェクトはどうだろう。これも利用料を徴収できない(すべきでない)ケースは多い。農業施設のように収益に直結するプロジェクトはともかく、収入を生み出さない、無償のプロジェクトの便益はどう考えるべきだろうか。
じつは、世銀の経済性分析手法は、この問いにもちゃんと答えを用意している。それも意外な答えを。
たとえば、それまで隔絶されていた地域の間に橋を架けると、行き来する交通量が増え、交易がさかんになる。経済活動がより活発になるわけだ。その効果は、単純には税収の増加にあらわれる。どれくらい経済効果が出るかは、両側の地域人口や時間距離、産業の状況などをベースにシミュレーションで推定することができる。そこで、この橋によって増加した分の経済活動を、プロジェクトの収益と見なして、DCF法を使うのだ。
これは、どういうことか。プロジェクトの経済性は、そのプロジェクト単体の直接収入や費用だけでは、正確に評価できないということだ。プロジェクトを正しく評価したければ、そのプロジェクトを含む、もっと大きな経済社会の中で果たす機能を見抜く必要がある。これが、世界中で社会開発型プロジェクトに投資してきた、世銀の考え方だ。
この思想を理解すると、某国の高速道路公団をめぐる論争が、いかに低次元で的はずれなものか分かろう。が、この問題はさておき、通常の企業活動の中にも、じつは無償のものと思われ、単なるコスト・センターと信じられれているプロジェクトが、多数ある。
その典型的な例が、情報システム開発プロジェクトの評価だ。この場合、投資額の推算は可能でも、プロジェクトの期待される便益が計算しにくいことが多い。(ちなみに最近、IT投資に関連して、ROIという言葉がよく聞かれるようになったが、これはDCF法の考え方がベースになっていることを知っておく必要がある)
SCM構築では、まだしも導入効果を物流費低減や在庫削減で評価できる。しかし、ERP導入などの場合、はっきり言って経済効果を計算するのは容易ではない。そもそも、企業活動の可視性を高めることがシステムの最大の効用であって、費用削減がねらいではないからだ。
他に例えば、物流センターの構築などもそうだろう。物流はコスト・センターで、何の付加価値も生まないと、広く信じられている。いかに3PLにアウトソースするかが、賢い企業戦略であるかのような主張さえはびこっている。
こうした議論は、無料の橋は儲からないから架ける価値がない、という主張と本質的に同じだ。企業の中には、一見無償だが重要なものがたくさんあるのだ。タダのものの便益が何か、冷静に判断できない財務家や経営者は、もう一度経済性分析を基礎から学ぶべきだと、私は思うのである。
(この項 終わり)
The Time Value
of Money(その2)--DCF法を知らない会計士 (2003/09/01)
大規模な投資をともなうプロジェクトは、長期間にわたる投資とリターンを考える必要がある。ただし、財貨には時間的価値があるから、今日の100万円は来年の100万円とは異なる価値をもつことを考慮して、プロジェクトの経済性評価を行なうべきである、と前回書いた。これがDCF法(=
Discounted Cash Flow法)の基礎である。"The Time Value
of Mone"とは、世銀(世界開発銀行)が、このDCF法を用いたプロジェクト経済性分析手法を理解してもらうため、入門用に作成している教育資料のタイトルだ。
DCF法の理論は、ある意味では単純である。いま、15億円を投資して農業用水の灌漑プロジェクトを計画しているとしよう(むろん、事業の対象は別に農業などの社会開発に限る必要はなく、工場を建てる場合でも情報システムを作る場合でも、考え方は同じである)。さて、この灌漑事業が完成すると、翌年から、農地の収穫が増大し、毎年1億円の収入増を見込めるとしよう。この灌漑設備は向こう25年間はもつと仮定しようか。
そのとき、プロジェクトの投資回収期間は15÷1=15年だ、などと考えては落第である。これでは、財貨の時間的価値を評価したことにならないからだ。では、どう分析すべきか。
まず、このプロジェクトに投資する資金の調達コストから、評価のための金利を定める(これをCut Off Rate=
切捨割引率という)。これは当該国の成長率や社会情勢、投資リスクその他から総合的に判断するのだが、かりに5%としよう。そして、この5%という切捨割引率のもとでDCF法を適用すると、このプロジェクトは採算がとれないという結果になるのである。
その理由を説明しよう。まず初年度(0年)の投資はマイナス10億円のキャッシュフローである。1年目の収益は名目1億円だが、切捨割引率5%を用いて現在の価値に直すと、実質は1億円÷1.05=9,524万円のキャッシュフローのプラスである。複利計算なので、2年目の収益の実質的な価値は、1億円÷(1.05*1.05)=9,070万円になる。同じように計算していくと、
3年目は、8,638万円、
10年目は、6,139万円、
25年後は、2,953万円
にしかならない。25年間のキャッシュフローの合計は、14億0939万円となる。初年度のマイナス分15億円とあわせると、合計マイナス9,061万円となる。これを、このプロジェクトの「純現在価値(Net
Present Value = NPV)」という。
プロジェクトの純現在価値がマイナスであるとき、そのプロジェクトは実現する価値がない。なぜなら、そこに投資するくらいなら、そのお金を銀行に預けて金利を受け取る方が儲かるからだ。このプロジェクトを、投資回収期間が15年だと評価してゴー・サインを出したら、それはお金をどぶに捨てているのに等しい。
DCF法は、あらゆるプロジェクト経済性分析と金融工学の基礎である。いやしくもMBAを名乗るもので、DCF法を知らないMBAなど米国には存在しえないだろう(聴診器の扱いを知らない医者が存在しえないように)。実際のケースでは減価償却や支払利息、税金の扱いなどがあって計算は複雑になるが、考え方は単純である。
にもかかわらず。私は1982年に会社で新入社員としてこの手法を学び、仕事を始めてから、’90年代の前半に別の仕事領域に移るまで、10年間の間、ただ一人として、DCF法を理解し業務に日常的に使っている、国内の会計士や銀行員に会ったことはなかった。驚くべき事ではないか。それは、日本では会計士も銀行も、プロジェクトの採算性をまともに評価する能力をもっていないという事を意味していた。
中小企業診断士の資格を取るため、財務管理の教科書を読んだときも、「プロジェクトの投資採算性分析は、財務理論で最も難解な部分に属する」との記述を見て、ほとんど絶句した。上述したDCF法の考え方自体は、非常に単純なものだ。複雑といえば、実際原価計算などの方がはるかに複雑ではないか。
にもかかわらず、上記のような感想が、なぜ出てくるのか。それは、DCF法が財務の「計画系」業務だからではないか、と私は考えた。いわゆる会計が、財務の「実績系」を処理しているのに対し、プロジェクト分析のような仕事は、“未来形”の収支を扱う。ここにも、わが国の「計画系にたいする弱さ」がもろに現れていたs。金融にたずさわる人たちは、将来の尺度を現在価値に割り戻すという、基本的なアイデアさえ受け入れられずにいたのだ。
では、彼らはどうしていたか。じつは、対象事業の損益計算書を向こう10年分か20年分作り、その損益の立ち上がり方だけで判断するのである。これは、複数の銀行の本社調査部や企画担当者から直接きいた話だ。そして、事業に融資するかどうかは、相手の保有する担保能力か、あるいは実績ベースの信用で決めるのである。
ある銀行のごときは(これは大手財閥系の大支店長だったが)、私がプロジェクト経済性分析の説明を終えるやいなや、“それで、日揮さんは債務保証はされるのですか”と聞いてきた。建設業者が債務保証するのならば貸してあげましょう、というわけだ。
プロジェクト・ファイナンスなどという概念は、この国では絵空事だ--少なくとも、それが’90年代初めまでの現実であった。なぜなら、DCF法によるプロジェクト分析もできず、また、その後ろ側にあるリスク評価もできずに、プロジェクト自体を担保とする融資などありえないからだ。東京ディズニーランドのような少数の例外はあったかもしれない。しかし、担保と実績がなければお金を貸してもらえないのなら、誰が新規プロジェクトなどに手を出せるだろうか。我々の経済が行き詰まった原因のいくばくかは、プロジェクトの評価を学ぶ気の無かった、会計士や銀行家のせいだと言ってもいいのではないだろうか?
The Time Value
of Money (2003/08/24)
フィージビリティ・スタディという言葉をご存じだろうか。ふつう、「企業化計画」との訳語がついている。うまい翻訳だと思うが、これはじつは意訳だ。フィージビリティfeasibilityという英語は本来、“実現可能性”を意味する。フィージビリティ・スタディとは、言葉をそのまま直訳すれば、『(事業の)実現可能性の検討』になる。
私がエンジニアリング会社である日揮に入社したとき、配属された先は、プラントの基本計画とフィージビリティ・スタディを担当するチームだった。そして、そこで真っ先に教え込まれた技法の一つが、経済性分析のためのDiscounted
Cash Flow = DCF法だった。
フィージビリティ・スタディは一般に、技術的な実現可能性、市場面での実現可能性、そして経済的な実現可能性、の3本柱からなっている。経済的な実現可能性とは、言いかえれば採算性のことだ。ただし、プラントのような、運転期間が何十年間にもわたる大規模プロジェクトでは、通常の採算分析はあまり役に立たない。そうしたケースで用いられるのが、世界銀行の開発した分析法、DCF法である。
DCF法の計算手続きは、ときに複雑なため習熟が必要だが、基本的な考え方はシンプルだ。それは、「金銭の時間的価値」をベースにしている。
金銭の時間的価値とは何か。それは、今この時点で所有している100万円と、来年の100万円では、その価値が異なるという考え方だ。なぜなら、そこに金利が発生するからである。金利がもし年率5%だとすると、今年の100万円は来年の105万円に相当する。--なあんだ、それなら当たり前の話じゃないか、と思われるかもしれない。が、それでは、「金利」の本来の意味を考えたことがおありだろうか?
ご存じかどうかは知らないが、現在でもイスラム法は金利をとることを禁止している。金利とは不道徳なものだ、と考えられているからだ。したがって、厳密なイスラム法で運営されている中東などの社会では、銀行は金利を受け取ることも払うこともできない。融資金利と預金金利の差で、収益をあげることが許されていないのだ。
じつは、キリスト教社会でも、中世から近世のはじめまで、金利は禁止されていた。神から人間に課された労働を経ずに、金が金を生む金利は、「自然法」に反するとされていたのだ。高利貸しは存在したが、社会の表面に出ることは許されなかった(この役割を非キリスト教徒であるユダヤ人がしばしば担っていたため、欧州のユダヤ人問題は一層ややこしくなったものと思われる)。
しかし産業が発達して農業よりも重要なものとなってきた18世紀のイギリスで、資本需要を満たすために、株式(share)と呼ばれるものが発明された。株式の出資者は、企業の利益から配当を受け取ることができる。事実上の金利を受け取ることができるようになったのだ。やがてこうして金融市場を発展させたイギリスの制度は、産業革命とともに広く世界に模倣されるようになる。今日のイスラム銀行でも、預金者は出資の「配当」の形で金利を受け取ることができる。
金利とは、資本調達のニーズがあるところで発明された。それは、資金調達のコストを表す指標なのである。限られた資源であるところの資金を、どこかに貸し付ける。貸し付けたそのお金(元金)は、返済されなければならないが、それに加えて、その期間のしきんという資源の占有に対して、フィーを払う。このフィーは、元金と、期間に比例する。これが金利の意味である。
現在の100万円が来年の105万円に相当する--金銭にはそれだけの時間的価値がある、とはそういうことを指している。これから、逆に、来年の105万円、あるいは再来年の110万2千百円を、年率5%という割引率で(ちょうど手形を割り引くように)、現在の価値に引き戻す計算を、Discountingという。Discouted
Cash Flowとは、あるプロジェクトの、将来にわたるキャッシュフローを、資本コスト(金利)の考え方をつかって現在価値に割り戻して評価する手法である。
私は以前このコラムで、「Time is Money」というタイトルのもと、短納期は低価格を超える価値がある、と説明したことがある。もともとこの言葉は、18世紀の米国大統領ベンジャミン・フランクリンのセリフであった。そしてこの言葉は一般には、時間を無駄にして怠けてはいけない、との金言としてのみ、理解されている。そして、彼がこれを語ったとき、じつは資金は金利を生む、という概念を念頭においていたことは、あまり知られていないようだ。しかし、多くのプロジェクトにかかわり、また経済についても熟知していた彼は、こう主張していたのだ:金銭は時間的価値を持つ、と。
“猫型プロジェクト”のマネジメント法(2003/07/08)
世の中のプロジェクトには二種類あることをご存じだろうか? プロジェクトといえば、最初にスコープをきちっと決めて計画を立て、プロジェクトマネージャが強力なリーダーシップを発揮し、チーム員をぐいぐい引っぱって進めていく・・・そんな風にすべきだとPMの教科書類には書いてあるし、私も参考書にそう書いている。そのために、EVMSだCPMだという技法もあるのだ、と。
たしかに、マスター・スケジュールも立てず、クリティカル・パスの何たるかも知らないでプロジェクトを始めるのは、海図も持たず舵取りの仕方も知らないまま船出をするようなものだ。これで無事に航海して目的地にたどりつけたら奇跡だろう。とはいえ、世の中には、そんな事例がいくらでもあるのも事実である(とくに某IT業界では・・)。
しかし、百戦錬磨のプロマネをもってしても、PMBOK Guideに書かれているような近代的技法の数々を適用しても、さっぱり成功しないプロジェクトというのも、実は存在する。スコープは不確定で、スケジュールは“可及的速やかに”とされており、予算の大枠は存在するが、細目を決めがたい・・・そんな種類のプロジェクトも、確かにある。たとえば、新しいカテゴリーの新製品を作るような仕事や、博覧会の展示パビリオンを作るような仕事がそれである。
ある米国のプロジェクトマネジメント・コンサルタントは、こうした種類のプロジェクトを“猫型プロジェクト”と呼んでいる。PMBOK
Guide風の伝統的なこわもての管理手法は、この種のプロジェクトには全く向かない、と言う。それは、猫に対して犬のしつけを強要するようなもので、相手はこちらの言うことを聞くどころか、そっぽを向いて去っていってしまう。
米国PMIが制定したPMBOK Guideは、どちらかというとスコープがかなり明確で、かつプロジェクトの内容が物量で規定されるようなタイプのプロジェクトを念頭に書いている。いってみれば一括請負型プロジェクトである。こうしたプロジェクトは、計画上の自由度が少ないが、管理対象の物量が多いため、計数管理手法と軍隊型のリーダーシップに向いている。これは“犬型プロジェクト”だ
しかし、猫型プロジェクトは性格が全く異なる。猫型プロジェクトは基本的に自由度が非常に大きいので、予測より発明の要素が強い。白いキャンバスに絵を書くようなものだ。始めた時点では、どこにたどり着くか、プロマネを含めて誰もよく分からないのだ。ここには命令の原則は通用しない。猫は呼んでも来ないし命令も聞かない。自分の気ままな思いつきで行動する。どこに行くか分からない。猫のように気ままなのだ。
猫型プロジェクトの難しさは、自由度が大きい条件下で、発想をどう育てるかという難しさである。そこに必要な手法は、軍隊式チームワークではなく、思いつきを生み出すためのコミュニティ・マネジメントであるという。
多くのプロジェクトマネジメントの解説書は、どうもPMBOK Guide的プロジェクト観に偏りすぎていると、私も思う。プロジェクトの世界は多様なのだ。その多様さを、そのまま活かせるようなマネジメント力こそが、求められていると言うべきだろう。
忘れもしないが、社会人になって初めてやった仕事は、LNGタンクの容量計算だった。プラントのタンク容量など化学工学的計算で決めるのだろうと思っていた私に、与えられたのは意外にも乱数シミュレーション・ツールだった。今ならPC上のダイナミック・シミュレータを使うところだが、当時はまだホストコンピュータ上で動く手作りプログラムだった。
LNG、すなわち液化天然ガスは、産出国で液化したものをLNGタンカーという極低温・高圧に耐える特殊な船に積んで、日本などの消費地に輸送する。このタンカーは数台が定期的に産地と消費地を往復するのだが、気候条件などでどうしても積み出しスケジュールに変動が出る。この変動を吸収できるだけの製品在庫量=すなわちタンク容量を求めるのが私の仕事だったのだ。
ここで私はごく初歩的なな法則を学んだ。製品の在庫量は、プラントだけの都合では決められない、ということだ。供給側が連続生産で、引取り側が不連続(タンカーという単位のバッチ引取り)である限り、そこには製品タンクがなくてはならないのだ。
ところで、シミュレーションを繰り返していくうちに、製品タンクの容量は船の到着時間の変動などよりも、もっとずっと大きな要素で決まってしまうことに私は気がついた。それはプラントの定期保守による生産ダウンだった。LNGプラントは定期的に一部をシャットダウンして、点検保守が必要になる。その間、生産量が落ち込むのに、引き取り側はおかまいなしに製品を運び出していってしまうのだ(これは長期販売契約の性質上やむをえない)。
定期保守は、あらかじめスケジュールが決まっていて、変動の入り込む余地は少ない。しかし、マクロな意味での生産と消費のギャップは、製品タンク内の容量で調整するしかないのだ。これは業態から必然的に導き出される法則で、だれかがメンテナンス不要・金属疲労ゼロの大規模コンプレッサーでも発明してくれない限り、逃れようがない。
この時以来、私は、在庫が悪で在庫ゼロが善だ、というような公式を無条件では信じなくなった。たしかに、在庫は需要と供給のギャップの結果として生じる。そして在庫には保管費用や在庫金利がかかる。だから、生産を需要に極力同期化して、在庫を減らし、ただ不可測の変動を吸収できるよう必要最小限の安全在庫だけを持て、と生産管理学は教える。
しかし、業種と製品によっては、生産と消費を完全に同期化することなど不可能なのだ。生産は連続で消費はロット単位だったり、生産は通年で可能だが消費は季節性があったり、生産は大量だが消費は小口にわける必要があったり、需給にギャップが生じるシチュエーションはいくらでもありうる。そういうケースでは、製品在庫は「必要として」現れてくる。
私は、在庫量のレベルを見て、良い・悪いの基準をあてはめるのは、おかしいと考えている。在庫を判断するとしたら、それが意図しておかれた「必要在庫」なのか、意図せずに結果として生み出された「出来ちゃった在庫」なのかの、区別だけだ。明確な意図があれば、目的合理性から判断は可能だ。そして、何も意図がない混沌の中で出来ちゃった結果については、その是非を議論すること自体ナンセンスだと思うのである。
プロジェクト・マネジメントの世界は動いている
(2003/06/07)
1年ぶりに米国に行って来た。6月1日からボストンで開かれた"ProjectWorld
2003"に参加するためだ。帰り道、米大陸を横断する飛行機内で、つくづく思った。プロジェクト・マネジメントの世界は動きつつある--しかも、かなり急速に。プロジェクトマネージャを自認し、仕事にしている人たちも、そうでない人たちも、この変化にキャッチアップするため、最新のPM手法を学ぶ機会をつくった方がいい。そして、あらためてPMとは何かを考え直すべき時が来たようだ。
CPM(クリティカル・パス法)がデュポン社で開発され、PERTの手法が原子力潜水艦プロジェクトのために米海軍で(正確には彼らのコンサルタント会社によって)開発されたのは、1950年代の終わりのことだ。両者は別々に、しかしほとんど同じ時期に現れた。時代がそれを要請したのだろう。『プロジェクト』という概念が米国で成立する時期だったのだ。
それから40年以上の歳月がたった。その間、あまり進歩がなかった、とまでは言うまい。しかし、他のManagement
Scienceの分野と比べると、穏やかな歩みでしかなかった。たとえば生産管理でのMRP→MRP II→APSといった劇的な進化を考えると、その違いがわかる。
プロジェクト・マネジメントの世界が、再び変動しはじめるきっかけを作ったのは、1996年版のPMBOK
Guideの制定だった。正式には、"A Guide to the Project Management
Body of Knowledge"という、一種のハンドブックである。作成者は非営利の業界団体PMI(Project
Management Institite)で、80年代半ばから続いた努力の集大成であった。ここで、用語・概念の共通化、管理対象の9分野の定義や、アーンドバリュー分析といった基本的手法への手引きがそろったわけだ。
それをきっかけにして、従来は建設・エンジニアリング業界中心だったPMIに、他の分野、とくにIT業界から、かなりの数の参加者が来るようになった。その前は数千人単位だった会員数は、いまや全世界で10万人を超えている。その半分以上がIT業界といわれるが、かなり広い業界で『プロジェクト・マネジメント』が注目されているのだ。今回のProjectWorld
2003でも、金融業界や医薬品業界に向けたワークショップが開かれている。
こうして世界中から、より多くの有能な人材が参加するにつれ、従来のPERT/CPM手法を広めるだけではなく、その枠にとどまらぬ新しいアイデアがどんどん生まれつつある。古い革袋に新しい酒、という訳だ。
その沸騰する中心の一つが、Project Portfolio
Managementという考え方である。これまで単一プロジェクトの中だけで考えがちだったPM論の枠を超え、複数プロジェクトをかかえる企業において最適ポートフォリオをつくるため管理手法だ。そのための技法もいろいろ提案されている。ソフトウェア的にも、Primavera社等の専門ソフトが続々このPortfolio
Management用ツールを出しはじめたばかりか、Microsoft社も最新版のMicrosoft Project 2003
サーバー版で採用したから、おそらく今後の中心トレンドとなることは間違いない。
もうひとつ、今回"ProjectWorld 2003"に参加して感心ことは、女性の参加者の多さだった。全体の4割以上が女性だったと思う。少なくとも米国にあっては、プロジェクトマネージャとは、もはや根性と体力と男臭さで勝負するような「男のための職業」ではなくなりつつあるのだ。そして、それはとても良いことだと思う。
このように、今、PMの世界はホットで非常に面白い。私自身も今年はプロジェクト・マネジメントをキーワードとした新しいビジネスに挑戦しようと考えている。当分この世界からは目が離せなさそうだ。
i2 Technologies社は復活できるか
(2003/05/26)
2001年に米国のネット・バブルが崩壊したとき、e-Commerce業界についで大きな被害をこうむったのはSCMソフトウェアの業界だった。SCMとe-Commerceが隣接する概念だったからだ。また、多くのSCMソフト・ベンダーは、電子商取引のサイトを自分で設立して運営するビジネスモデルに転換したため、傷口を広げてしまった。IBM-Aribaとならんでトロイカ体制を組んでいたi2 Technologiesも、そのためにかなりのダメージをこうむった。
しかし、米i2社の最大の問題点は、バブル時代に顧客と結んだ契約の遂行で、あちこちつまづいたことだった。当時は、景気が良かったせいで、驚くほど大ざっぱな契約でも、顧客のCIOは喜んでサインしたようだ。しかし、パッケージ・ソフトの開発力の高さと、個別プロジェクトのSI能力とは別ものだ。こうしてあちこちのプロジェクトでつまづいて、同社の収入は見る見る落ちていった。
最近になって、さらに悪いニュースが入った。同社の会計処理に疑問符がはさまれ、監査法人の再調査が行なわれることになったのだ。ENRON事件以来、市場はこの種のニュースに非常に敏感になっている。かくて、同社の買収の噂が現れては消えるようになった。昨年はCRM大手のSiebelの意向が取りざたされた。今年に入ってからは、インド最大のIT企業Infosysが買収するとの噂も流れた(i2の創始者はインド系の人だから信じる人も少なくなかった)。
そのi2社のプライベート・フェアであるi2 PLANETがこの5月にLas Vegasで開催された。参加者は1,500人と、昨年の半分だ。3年前のSan
Diegoのお祭り騒ぎがウソのようだ。しかし、AMR
Researchのレポートによると、静かではあるが沈滞したものではなく、むしろサプライチェーン・マネジメントの実務者による、ごく真面目な雰囲気の会議だったという。
同社のCOOには、昨年から日本支社長だった中根氏が就任している。中根氏はご存じの通りIBMのOBだが、数年前まではSAP
Japanの社長で、日本におけるERP市場立ち上げの功労者(扇動者?)だった人だ。氏は、PLANETの席上で、今後のi2社の方向性として、顧客重視・コンタクト窓口の一本化・柔軟な価格体系、などの政策を打ち出した。顧客別のコンタクトに任命された者は、今後の90日アクション・プランをまとめる責任を負うという。こうした政策は、過去に同社が忘れていたことが何であったか、逆にあぶり出してくれる。
ところで、こうした動きに対して、1,500人の参加者はどう反応したか? AMR Researchによれば、かなりポジティブだったようだ。そして、何より意外なことに、参加者の多くは同社の財務的危機状況を認めつつも、その製品に対する信頼を捨てていないようだ。彼らの多くは、経営者から“いつ倒産するかも分からぬ会社の製品を使いつづける必要があるのか!?”といった疑問を投げかけられているであろうにもかかわらず、である。それだけ同社の技術には信頼が高いのだ。
サプライチェーン・マネジメントは、簡単ではない。ソフトを買ってくればすぐにどうにかなるような、単純な代物ではないと、本当の実務者は理解している。そこにはかなりの技術的な深さが必要なのだ。今回、ようやくVersion
6を発表したi2 Technologies社が、現在の深刻な危機を脱出して復活できるのかどうか--それは誰にもはっきりとは分からない。しかし、鍵となるのは、明らかにSCMへの真摯な取り組みの姿勢しかないはずである。
SONYの「ウォークマン」は1970年代の後半に初めて発売された。電池駆動で、ステレオ・カセットテープで、ポケットに入りそうなくらいに小さかった(でも実際にはそこまで小さくなかったので、ストラップで肩から下げるか腰のベルトに通して使ったが)。テープなのに録音はできずに再生専用、そして、スピーカはなく軽量ヘッドフォンのみで聴く方式だ。
こんな偏った機能を持つ奇妙な機械は、それまで誰も考えたことがなかっただろう。風変わりなこのオーディオ機器は、実際には既存の技術だけを組み合わせて作られたものだった。が、市場に現れてから、はじめは徐々に、しかし次第に爆発的に売れるようになり、最終的にそれは新しい一つの音響機器のジャンルの代名詞になった。
私は要求定義の仕事に向かうごとに、このウォークマンのことを思い出す。私も普及しはじめた頃に買って、すぐに気に入った。もともと音楽が好きな人間なのだ。とはいえ、“持って歩ける個人用音楽環境”というものが、どれほど自分の風景を変えてみせるものか。それは体験してみるまでは分からなかった。私はそのような道具を求め、欲していた。そう、『要求』していたのだ。しかし、自分で実際に手に入れるまでは、自分の『要求』の中身を具体的に定義することができなかったことも、確かなのである。
システム開発の仕事は、知っての通り、アナリストによる『要求定義』の作業からはじまる。エンドユーザの要求事項を分析し、どのような機能を持つシステムが必要かを、客観的に定義してみる作業だ。<しかし、はたして、要求定義は本当に可能だろうか?>
こんなことをいうのも、ERPパッケージをベースにしてしか発想しない「業務コンサルタント」が、あちこちでAs isとTo
beを振り回してフィット&ギャップ分析をやる光景が、目につくようになったからだ。
ユーザの要件を定義し、それがパッケージの提供できる機能範囲とどう重なり、どうずれるかを判断する。それがフィット&ギャップだ。そして、パッケージでカバーできない要求は、あきらめるか(BPR)、別の方法で回り道をして実現するか(ワークアラウンド)、さもなくばプログラムを追加開発するか(アドオン)、どれかを選ぶことになる。
なるほど、けっこうだ。だが、ユーザが要求するものを実現し提供することが、システム・ベンダーの役割だという無言の前提が、そこにはある。しかし、ユーザが求めている(と言っている)モノは、本当にユーザが必要としているものなのだろうか。ユーザはそれほど、自分が何を必要としているのか正しく認識できるのだろうか。
ウォークマン出現以前の人たちは、ラジカセや携帯できるテープデッキを買っていた。それが自分たちのほしいものだと思っていたのだ。しかし、本当に何がほしかったのかは、それが具体的な姿をとって目の前に現れてみるまでは、いや、それどころか自分で実際に使ってみるまでは、分かっていなかったのだ。
アナリストやコンサルタントの仕事とは、機能のメニューをユーザに見せて、その中からほしいもの選ばせることで終わっていいのだろうか? それはパッケージという釈迦の掌の上で踊っているだけではないか。レストランのウェイトレスと、どこに違いがあるというのだろう。
有能なアナリストとは、ユーザが「ほしい」と言ったものではなく、ユーザが真に必要としているものを提示できる人でなければならない。しばしば顧客は、自分が本当に欲しいものを知らない。要求と必要は、実はちがうのだ。
たとえば、自分は’70年代はじめの人間に向かって、「ウォークマン」を要求定義できるだろうか。新しいジャンルを創造するような仕事は、顧客の意識の中に浮かんでいる要求を分析するだけでは決して出てこないことを覚えておいた方がいい。ウォークマンを定義することとは、ウォークマンを発明することなのだ。
1990年から2000年までの20世紀の最後の10年間、それは"Two up, two down"だった--という言い方を、アメリカではしている。’90年代の10年間を通して、経済的に上昇したのはアメリカと中国であり、逆に急降下してしまったのが日本とロシアだ、という意味である。
’91年をピークとするバブル経済の崩壊の後、日本経済がダウンスパイラルに陥ってしまったことは事実だ。これは日本人だったら、誰しも苦い感情を込めながらも同意するだろう。これを称して“失われた10年”などという。もっとも、すでに10年以上たったのにまだトンネルの先の光はまだ見えてきていないが。
しかし、これは私の持論だが、日本の生産管理において、これとは異なる“失われた10年”があったと思う。それは1980年代である。’80年代とはどのような時代だったか。それは、一言でいって“ジャパン・アズ・ナンバーワン”の輝く栄光の時代である。日本の製造業は世界一。JIT、カンバン、TQC、TPM--日本の生産管理思想が最強の製造業を支えている。そう皆が考えていた時である。
なぜそれが失われた10年間だったと、私が思うか。それは簡単で、もう日本は欧米に学ぶものは何もない、と誰もが信じていたからだ。むしろ欧米が長蛇の列を作って日本に教えを請いに来る時代だ、と皆が盲信していた。しかし、その80年代は、ちょうどアメリカでMRPIIが成立した時だった。情報技術によって、生産・在庫管理学が統合された、ちょうどその瞬間に、日本は学習をやめたというわけだ。これが暗黒でなくて何であろうか?
どんな組織も、ちょうどその頂上にいるときに、崩壊の種子が孕まれる。それは、強者の傲りによって、他者から学ぶ柔軟性を失うからだ。そう、それは日本の経営学も例外ではなかった。以前の経営学といえば、テイラー理論やホーソン実験をはじめ、欧米の学説の翻訳・解説で成り立っていた。しかし、貿易黒字額の増大と比例して、突如「日本的経営理論」の世界に対するスポークスマンと相成ったわけだ。
(日本のいわゆる対米黒字額は、実はサービス分野の収支が含まれていない。これは知っている人は知っていることである。例えばコンピュータ・ソフトのライセンス料など、実物経済に直接結びつかない知的財産の分野では、日本はずっと輸入超過だった)
日本の生産管理学が暗黒から目を覚ましたのは、’90年代も半ばに入ってからである。日本の製造業の急落と自信喪失、そこに追い打ちをかけるようにERPやSCMという、欧米発の新しい考え方が登場してきた。ERPは、会計学的にはABC(活動基準原価管理)をベースとし、生産管理的にはMRPIIをベースとしている。SCMはといえば、APSやTOC理論を武器として実現されてきた考え方である。
あなたがMRPIIを良いものだと考えるかどうかは、私は知らない。しかし、APSやTOC理論は、いずれもMRPの限界を乗り越えようと登場してきた考え方で、そのベースにはMRPの手法やデータ形式ががっちり根を張っている。その基礎は、日本人がすべて学習をスキップしてきた栄光の、あるいは暗黒の’80年代に確立されたものだ。
だから、MRPの基礎も知らない人間が、ERPやAPSを自由自在に捌けると思うのは、危険だと知るべきだろう。いや、危険である以前に、なによりもまず滑稽なのである。もういいかげん、目を覚まそう。知らないことは恥ではない。学ぶに遅すぎることは決してない。そして、真剣に学べば、それなりに自分たち独自のものに作り替えていく力を持っているのが、この国の人々だと私は今でも信じている。
前回「流れ行く情報」でも書いたように、フローの情報とストックの情報とは区別すべきだ。ITツールは、情報のフローをスムーズに流すだけでなく、情報をストックし十分に生かしきってこそ、はじめてその最大のメリットが出せる。
この視点は、最近のERPをめぐる議論においも有効だと思う。日本のERP市場は、90年代を通して急成長してきたが、2000-2001年頃に一度、厳しい落ち込みを経験する。これは、大企業に対して会計系機能中心に売ってきた市場が一巡したためだ、と説明されてきた。たしかに、それもあるだろう。
くわえて、2000年問題への対応がERP導入ブームを加速していた事情も大きかった。2000年問題のためにERP、では本末転倒だ。それはみな分かっていたがが、こうしないと大規模IT投資への経営トップの承認が得にくいという、不況下での日本特有の台所事情もあったのだ。
一方、90年代終わりは、米国におけるITバブルの絶頂期にもあたっていた。ERPパッケージ自体の値段も、導入コンサルタントの単価も、かの国では雲の上はるかにかすむほど上がりきっていた。その結果として、日本の大手ユーザもかなり高価なものを買った(買わされた)ことになるはずだ。まさに、“見栄で買うERP”である。
こうした反省から、『ERPは高価すぎないか』という疑問がしだいに口にされるようになってきた。現在のERPは、ライセンス料とカスタマイズ等の導入構築費用を合わせて、ユーザ一人あたり数十万円から百万円を超える金額が、ゆうにかかる。日本のERP市場は一応、落ち込みから回復してきており、そのターゲットも会計系から生産系に、大企業から中堅企業へと、広げている。が、そうなるとかえって、その高価さがきわだって感じられるようになったようだ。そして、これに歩を合せるように、アプリケーション導入コンサルの単価もじりじり下がってきている。
これに対して、日本のERP市場の特殊性を指摘する声もあるだろう。とくに、自社業務の個別性にこだわって、大量のカスタマイズやアドオンを作っていけば、お金はかかるのが当然だ、と。それにも確かに一理ある。アドオンの数が500とか1,000だとかにのぼるプロジェクトの例を聞くと、果たしてそれでもパッケージ利用と言えるのだろうかと思ってしまう。
だから、『業務をパッケージに合わせてBPRすべきだ』という議論もよくきく。が、私はこれにはいろいろな留保条件つきでなければ賛成できない。第一にまず、パッケージの出来が良くなくてはなるまい。「ベスト・プラクティス」なる宣伝文句を真に受けて、パッケージの欠陥機能に業務をあわせてIT導入経費の節減をねらうなど、本末転倒を額縁に入れて壁に飾ったようなものだ。
“欧米ではパッケージに会わせて云々・・”という、見てきたような議論もよくきくが、英米仏の大企業の事例につきあってきた私自身の経験から言わせてもらうと、彼らだっていろいろな留保条件付きでしぶしぶそうしているのだ。
そういうわけで、ERPパッケージのユーザは、今のところカスタマイズ/アドオンの出費からのがれるすべは無さそうだ。そして一度アドオンをはじめると、次はバージョンアップの対策をどうする、という問題に直面する。だからこそ、ERPは導入費用のみならず運用・保守費用も高額だという批判が出てくるのだ。
ここら辺を敏感に感じてか、最近のSAP社は直販モデルに向かっている。従来、インプリメンテーション・パートナーと称するSI業者にカスタマイズとアドオン開発を任せる、卸売り方式だったビジネスを、直販方式に転換しようとしているのである。このため、すでに大手のパートナーとのあいだに少しずつ摩擦が生じているようだ。Oracle社などは、日本を除き、すでに直販モデルが多い。カスタマイズの方によりビジネス・チャンスを感じているということなのだろう。
しかし、もとの問題に戻ると、ERPが高価かどうかは、そもそも各ユーザが自分で判断すべきことではなかったか? 自分自身の費用便益分析がきちんとできていれば、高価かどうか相場を見ずとも分かるはずのことなのだ。むろん、それで間接人員が何名減らせるとか、ダウンサイジングによってホスト計算機のリース代が何円節減できるとか(どうせリース切れになる手前だったのだが)、そんな後ろ向き費用削減効果ではなく、新システムのもたらすはずの、便益の分析だ。
結局それは、ERP導入の目的や期待が何なのかという、根本の問いにかかっていることになる。これ自体はけっこう難しい問題である。計画系のSCMソフトと違って、実行系のERPソフトは、効果が定量的に予測しにくい。ERPを入れたら結果として在庫が下がるだろうとか、納期遵守率が上がるだろうとか思っていたら、それは完全な誤解である。「在庫削減」という目的があり、その手段として正しいERPを導入したら、それは下がるかもしれない。しかし、そのためには仕事のプロセスだって改革しなければならないはずだ。
最新式のゴルフクラブを1セット買ってきたら、次の日からハンデが10下がると思う愚かな人間は、むろんいるまい。新しいクラブを買ったら、それを活用しきるために、新しいフォームを身につける必要があるだろう。
ERPは、データの可視性をてこにして、仕事のやり方を改革するためのツールである。今の仕事のやり方のままで、結果だけを改善してくれると思うのは浅はかだ。ERPは仕事を省力化してもらうツールという誤解があまりにも多すぎる。たとえば、本社は楽になった(可視性が高まった)が、工場は大変になった、という事例が現実にはいくらでもある。
そして、あえて念を押しておくが、ERPを、「フローの情報」をスムーズに流すための道具として使うだけでは、高価に過ぎると私は思う。ERPの最大のポイントは、大福帳的に一元化された膨大なデータが自動的に蓄積できることなのだ。ストックとしてのデータを分析・活用しない限り、本当の意味でのERPの価値は生まれてこないだろう。多くのユーザ企業が、ストックの情報の意義を理解し、“見栄で買うERP”のレベルから脱却することを、切に願っている。
いまからちょうど150年前の6月、ペリー提督ひきいる黒船が浦賀沖に姿を現した。彼の主目的は、開国を要求する大統領の親書を幕府に手渡すことだった。そういう意味では、ペリーの航海の最大の任務は「情報の伝達」にあったと言ってよい。
しかし、日本に来航した艦隊4隻のうち、3隻が測量船だったことは、あまり知られていない。じつは艦隊のもう一つの大きな任務は、江戸湾そのほか沿岸の測量と海図作りだった。
なぜ海図か。それは、海図が軍事行動のときにもっとも重要な情報となるからだ。だから、ペリーのもう一つの目的は、「情報の収集・集積」だったとも言えよう。
そして彼らは当初の目的通り情報を把握すると、その後、お得意の砲艦外交を行なって、有無を言わさず東洋の島国を開国させてしまった(軍事的威圧を背景にして小国を動かす砲艦外交は、ほとんどアメリカの国是といっていい)。
それから約90年後、日本を占領した米軍は、日本全土の地表をくまなく撮影して膨大な航空機写真をとった。これも、重要な軍事情報だ。彼らが発明した「戦略的爆撃」と称する、非武装市民の効率的な殺戮のためには、どんなぼんくらな飛行機乗りでも、あるアベレージの攻撃能力をもたせなければならない(ここら辺の発想がいかにもアメリカ的なのだが)。そのためには、正確な写真という情報の集積と分析が必要だったのだ。
ところで、話は突然かわって日本企業のことになる。日本のビジネスマンは地球の果てまで、ありとあらゆる国々で商売を広げてきた、栄光の歴史を誇っている。それで、その結果得られた膨大な海外情報というのは、どこにどう集積されているのだろう? それは私たち国民の共有財産となっているのだろうか。せめて、各企業内では、それなりに共有され分析し尽くされているのだろうか。
おそらく、そうではあるまい。これは推測だが、日本の企業は、情報の伝達には巧みでも、情報の蓄積分析は各人の名人芸まかせ、というところがあまりに多い。言いかえるならば、フローの情報はうまくさばいても、ストックの情報は大切にしない。
日本の企業が情報システムを導入する最大の目的は、業務の効率化だ。そして、情報伝達のスピードアップ。この目的意識は、90年代後半からのインターネットの進展にともなって、いっそう情報の流通速度の側にシフトしてきた。電子メールの普及は、それまで企業内で閉じていた情報のやりとりを企業間まで広げることになった。
しかし、日本の企業が情報システムを導入するとき、情報のストックとフローを意識して区別し、その両者を活用しようとしている例は非常に少ないと、私は感じている。
念のため注記しておくが、情報のストックとフローとは、データベース屋がいうトランザクションとマスタ、ではない。あくまでも、利用形態のことを言うのだ。すべてのトランザクション・データがコンピュータのどこかにたまっていっても、それが二度と見向きもされなければ、それはフローの情報と呼ぶべきだ。
仕事の情報が、流れ行く雲のように切れぎれになって地平線の彼方に散ってしまっていいのだろうか。情報は、何のために電子化するのだろうか。ネットワークにのせると電話やFAX並みに速く届いて便利だから? ちがう。それではITの便益の半分以下しか使っていない。
蓄積し、検索し、分析できること。それがデータの力だ。データの力を最大限に活用してはじめて、ITの価値を100%使っていることになるのだ。だから、今の日本の社会は、まだ脳細胞の半分以下しか活用していないかもしれない。
アメリカ人たちが組織的に何かを行なうときには、情報を収集し蓄積し、多角的に分析して有効に利用していく。そのシステマティックやり方は、ほとんどアメリカの文化にビルト・インされた本能のようなものだ。そして、この点においては、日本とアメリカの差は絶望的なほど開いていて、この百数十年間のあいだに縮まった形跡がない。
あなたがアメリカのことを好きか嫌いか、彼らを見習うべきと思うかどうかは、知らない。しかし、情報技術のほとんどの要素は、米国で生まれ育ったことは覚えておいた方がいい。そうなるのは、それなりの必然性が、文化の中にあったからだ。もしもあなたが、日本の情報技術を素晴らしいものにしたいと希望を持っているならば、あなたの企業がストックの情報を共有し分析できるように、そのことに価値を認めるように、宣撫していくしか道はないだろう。
スケジューリング問題においては、「自由度」を、あたかも貴重な資源のごとく、大切に扱え--これが私のかねてからの主張である。拙著「革新的生産スケジューリング入門」の構成も、この原則で貫いた。
自由度とは、計画者が問題を解く際に、選びうる選択肢の数のことだ。数学的に言えば、解空間の広さに相当する。線形計画法のようなORの考え方に慣れている人ならば、制約条件によって規定された解の閉空間をイメージすることはたやすいだろう。
スケジューリングなどの問題では、解は複数の選択肢の組合せで表現される。これを静的な、最適化の枠組みの中で取り扱うのではなく、自由度の利用に注目した動的な適応制御の問題としてアプローチすべきだ、というのが私の提案である。
ところで、こう書くといかにも、自由度は純粋に理論的な概念であるかのように受け取られそうだ。たしかにそこには、数学的な計測手段と意義付けが必要だ。しかし、自由度の概念は同時に、企業活動のマネジメントにおける具体的な意味と有効性を持っている。むしろ、そちらのほうが重要なのだ。
自由度の具体的意味とは何か。自由度とは、計画担当者が選びうる選択肢の範囲である。つまり、自由度とは権限範囲のことなのだ。彼(彼女)が計画を決める際に、どれだけの範囲の中から手を選べるか。工場全体で考えることが許されるのか、それとも一部のラインや製品ファミリーだけを任されているのか。計画対象期間はどれだけか(向こう数週間か当日分だけか)、ワークセンタの稼働時間は変えられるのか、人の配置は動かせるのか(それとも労組の厚い壁で不可能なのか)、等々・・。
およそ計画の良し悪しというものは、計画者に与えられた自由度の範囲、すなわち委譲されている権限範囲の広さによって非常に左右される。計画を評価するときには、与えられた権限範囲の中でどれだけベストを尽くしたか、で計られなければウソだ。自由度もないのに、誰が結果責任を負えるだろうか?
もし、担当者にたった一つの決められた解しか許されていなかったら、それは自由度ゼロ、つまり権限無し、を意味している。計画経済の巨大な官僚組織の末端には、「NOと言う権限」しか事実上持っていない人たちが、ごまんと居た。いまの日本の企業社会には、そんなナンセンスな仕組みは存在しない。しないはずだ。さもなければ、行く末は某大国の末路と同じことになってしまう訳だが・・
自由度とは権限範囲を意味し、それはすなわち、結果にたいする責任を問われ、評価される範囲を意味している。自由度なくして責任なし。組織人にとって、およそ自分の責任範囲外の事情で責められる事ほど、やる気を削ぐものはない。だが、何事も欠乏しがちなこの国にもまだ、自分の頭で判断し行動できる人間だけは幸いにも沢山いる。そうした英知を仕事の成果に結実させるためにも、我々は自由度を大切にしなくてはいけないのだ。