Management

今週は、アフリカのタンザニアにやってきました。

成田からヒマラヤ山脈を辿ってドバイへ入り、ドバイからはソマリアとケニアの上空を通ってタンザニアに着陸しました。
会社から３０時間。長旅でした。
しかし、長旅の疲れを感じさせないのがタンザニアの良いところです。
タンザニアはアフリカの中でも優良な国だと思います。政治が安定したことで経済が発展し続けていますが、どこかのどかなところが残っています。

さて、今回の目的は新システムの導入。
最近はアフリカビジネスがにわかに注目されていますが、そこに参入したことは、私にとってはガス田を掘り当てたのと同じくらいの驚きです。
実態がまったく見えませんが、タンザニアでWEBシステム開発をした最初の日本の会社かもしれません。

タンザニアにはアフリカ最大の港、ダルエスサラーム港があり、多くの物資がこの国に入っては出ていきます。
そのビジネスを支援するシステムを開発したのですが、これはまだ序の口になると思われます。
というのも、タンザニアだけでなく、内陸の周辺国の経済発展の影響もあり、取扱量はうなぎのぼりだからです。
港が手狭になり、新しい港の開発も進んでいるということです。

今回は２つ目のシステム導入になります。
１つ目は日本で実績のあるシステムだったのでスムーズに導入することができました。
しかし今回は、タンザニア現地での業務調査から始め、その後日本に持ち帰り設計からシステム開発まで行いました。

タンザニアのユーザー様は皆、今か今かと待ちかまえ、とても楽しみにしてくださっております。
その期待に応えたいと思います。

Facebookで面白い投稿があった。

某メーカーに勤務する人からの投稿だ。
日経のこの記事 「家電量販５社の経常利益、過去最高に 」 を引用して、

「メーカー各社の損益は青息吐息の一方で家電量販店が一斉に過去最​高益を更新している。
ゲームの不全は明らかなのだと思う。処方箋​はひとつ。ゲームのルールを変えるしかないのだろう。(以下省略)」

つまり、作り手にはほとんど儲けがないのに、販社は過去最高益を出しているなんて納得できない、ということなのである。

そこで私は考えた。
本当だろうか。そしてなぜだろうか。
さかのぼる事15年くらい。インターネットが普及し​出した時、販社は存続が厳しくなると言われていた。
メーカーと消費者がダイレクトに取引できるの​で、卸や小売は要らないというのである。
消費者は販社が得ていた中間マージン分安く商品を購入でき、メーカーは顧客の声を直接聞いて製品開発に反映させることができる、などといいことばかりが闊歩していた。

さて、実際にはどうだったかというと、メーカーと消費者の中間に位置する、家電量販店や価格比較サイト​、ネット書店など、が利益を出し​ているケースが目立つ。
最初の話にもあったように、メーカーは力を落とし、仲介者は力をつけたのだ。

仲介者は単に商品​を右から左に流しているだけではなく、顧客囲い込みのために試行錯誤をしたのだ。たとえば、ポイント制度など典型的な例。
メーカーは、というと努力していなかったわけではない。むしろ、売れる製品を作り続けた結果、販社が利益を出せたのである。
つまり、メーカーは、投稿にあった「利益配分のゲームに負けた」のである。
だからゲームのルールを変えるしかない、というのである。

私はこれに賛成だ。
外を見ればアップルやサムスンなど、メーカーでうまくやっているところはある。
大きなマーケットでゲームのルールを変えるには１社では難しい。
そこで、今までの枠を超え、海外の友人知人を駆使して、今までにない枠組みでの提携を模索する必要があるだろうと思う。
積極的に外に出て、人間関係を築くことで何か新しい展開を見出せないだろうか。

東日本大震災とともにおこった東電福島第1原発の危機。
ニュースで報じられるごとに、メッキが剥がれ「形だけの仕事の積み重ね」が浮き彫りになってきた。
原発も、運用も、組織も、危機対応時には役に立たない、中身のないハリボテ、だったということだ。

この「ハリボテ」の話をする前に、情報システムの変更に伴うリスクマネジメントの事例を紹介したい。

私が社会人3年目のころ、コールセンターで、情報システムのユーザー代表を任されていた。
CRMシステムのリプレイスが決まり、そのためのプロジェクトが始動した。
その情報システムは、顧客にサービスを提供するために必要不可欠であり、顧客対応における効率化にも貢献していた便利な「仕組み」であった。

もしリプレイスに失敗すれば、便利な仕組みを失い、顧客に効率的で正確なサービスの提供ができなくなる。良くてもコールセンター自体の処理能力が半減することは容易に想像できた。
当時、確か１００人くらいのオペレーターがいたが、生産性が半減するということは人件費が倍になるという計算である。

当時の私にはシステム開発とはどのようなものか想像もできなかったが、プロジェクトの過程で、「これはうまく行きそうにもないな」と直感した。
新しいツールに対する要求が複雑で、(私から見て)些細なこだわりが多いのに、開発側がそのほとんどをそのまま網羅しようとしていたからだ。
テスト段階の画面は、まったくクールさがなく、完成したらどうなるのかと思っていたら、それが完成版だと聞かされ、これはダメだと確信した。

そこで私は利用者側のリスクマネジメントを開始した。
起こりうる問題を列挙し、業務に与える影響度合いを定義し、それぞれの対応手順を定めた。
最悪のシナリオは、顧客情報を参照することさえできないというもので、その状態が３時間を超えたら直ちに前のシステムに戻すということにした。
了承すべき人も明確に定めた。
またシステムが利用できない間のオペレーターの顧客対応方法についてもまとめた。
最後に、いざとなったときに前のシステムに戻すという決断を躊躇してしまうだろうと思われた。
サンクしたコストを取り返そうという力が働くと思ったからだ。
なので、関係者全員に説明し、事前にすべて了承を得ておいた。
この段階で私のことを「めんどくさい奴だ」と思われているだろうな、という感じがあった。
でも私はこれをハリボテで終わらせるつもりはなかった。このハリボテとは、見せかけのルールのことである。
とりあえずルールを決めておくが、どのタイミングで誰が判断を下すのかなど、具体的なことを明らかにしておかないことである。

そしていよいよシステムをリプレイスする日がやってきた。
朝９時の営業開始とともに一斉に電話が鳴り、オペレーターらはシステムの操作を始めた。
その途端、新しいシステムは応答しなくなった。オペレーター全員が、顧客情報を参照することすらできないのである。
開発側はすぐさま原因の追究にあたったが、３時間を経過してもその手がかりすらつかめなかった。
前のシステムに戻すという最終決断を迫られたとき、事前に説明を聞き了承していたにもかかわらず関係者の間で躊躇があった。
「本当に戻すの？」「戻してもいいの？」と。またもルールがハリボテになる危機に直面した。
だがここは心を鬼にしなければ、結局お客様に迷惑がかかる。ということで、リスクマネジメントのマニュアルを盾に(というか槍にして)元のシステムに戻させた。
結局、原因が判明し、解決できたのは数日後だったので、元のシステムに戻すしかなく、タイミングとしても最適であったと言える。

さて、東電の福島原発の問題に話を戻すと、こんな話があった。
３月１２日午前１時３０分、官邸は正式にベントの指示を出したが東電は従わず、首相がヘリで現地まで指示を出しにいった。
それでもベントが始まったのは午前１０時１７分。しかし間に合わず、午後３時半すぎに原子炉建屋が水素爆発で吹き飛んだ。
「原発崩壊」の始まりだった、という。
（毎日jpより http://mainichi.jp/select/weathernews/20110311/news/20110404k0000m010149000c.html?inb=yt )

なぜ東電はベントを開始するまでに９時間もかかったのか。想定されていた事態で、マニュアルにも記載されていたのに、想定したとおり動かなかったのだ。
これしか選択肢がなく、迷うまでもない対処なのである。
だが、東電は動かなかった。日本の原発で前例がなく、放射性物質が外部へまき散らされる可能性があったため、躊躇していたというのである。

さらに、その決定権は東電にあると定められているのに「一企業には重すぎる決断だ」と、この緊急時になって自己保身ともとれる行動に出たようだった。

ハリボテの仕事、ハリボテのマニュアル、ハリボテの決断。中身、芯がないのである。

長靴はかず足に放射能が着いて作業員２人が被ばくした問題もハリボテのせいである。
http://mainichi.jp/select/science/news/20110325k0000m040101000c.html
安全に作業するためのマニュアルがあったのに、それが守られていなかったという単純な理由である。
なぜマニュアルで定められているのか、その理由を体で理解していないのである。

結局、マニュアルはハリボテだったのだ。人を守るためには使われなかった。
マニュアルを作成したら徹底した教育が求められるのは、ハリボテにしないためのプロセスなのだ。

芯さえしっかりしていればマニュアルはなくとも、最低限のところは何とかなるものだ。
芯がないからマニュアルがあっても最低限のところが守れない。
芯とは、考え方、モノの本質である。
そう思う。

リスクマネジメントとは「備え」であり、備えとは、最悪の事態を想定した対応であることを書いた。
今日は、前半は地震について、後半はビジネスを前提にして考えてみたい。

今回の東日本大震災では誰もが、さまざまな困難に直面している。
この困難はまだ序の口であるのは明確だ。
リスクマネジメントの立場から考えると、「怪我や人命に関わること」が最悪の事態で、継続的に活動する必要がある。

まずはその可能性を可能な限り除去することが第一であろう。
地震や津波そのものによるものの他に、原発から大量の核が漏れる、鉄道のホームで人が殺到する、水や食料が不足する、といったことも考えておく必要がある。

原発の状況について、今は必要な情報は開示されていると思っているが、３月１５日時点では過小評価に基づいた情報開示であると考えていたため、私は倍以上を前提にしていた。
例えば、退避地域が半径１０キロと公表されたら、２０キロ以上が妥当であろうというように。

食料も何もなくなることを想定して、缶詰を家族用３日分用意した。これを１週間食いつなげられれば、その間に何とかできるだろうと。
リスクマネジメントは、ビジネスについても同じである。
個人の身の安全の延長線上に位置する。
身の安全を顧みずに事業の安全はあり得ない。

繰り返しになるが、リスクマネジメントとは、最悪の事態が起こった時でも自分の身は自分で守れるようにしておくことがポイントであろう。ここでいう自分とは、会社単位、組織単位、職能単位、個人というレベルがある。

ただ、現実はさまざまなコストとの勝負になるから、万全は難しい。
すべてを守ることはできない。何を守り、何を諦めるのか明確にしておく必要がある。
損害を自分で被る心構えもしておかないとならないということである。
それが嫌なら保険を掛けるなどして、あらかじめお金でヘッジしておくしかないだろう。
お金が出せないなら、最悪のケースは諦めるのが最良。責任の所在を議論していたら、復興は進まないので。

また、損害を被った時にどうやってリカバリーするか、その方法を確認しておくだけでもいい。
自分でできるようにしておくことが一番だが、専門性が要求されるものはそうもいかないかもしれない。
だが、最悪の事態になり、復旧させるときにお金を払って専門家にやってもらえるなら、かなり良い。

情報システムでよくあるケースだが、中身がブラックボックスに近い場合、最初から作った方が早いという場合もなくなはい。
顧客情報などのデータだけは作れないので、バックアップは必須である。csvで出力しておくだけでもいいが、その媒体は６０キロ以上離れた場所に保管しておくことが望ましいという話しを聞いたことがある。
データセンターでそれは標準のサービスになっていることが多い。
リスクマネジメントは一過性のものではなく、日々の積み重ねである。
最悪の事態が起こった時に、自社で守れるようにしていないものは、最悪諦める対象であるというのが経営トップからのメッセージとなる。

事業の継続に不可欠なものが見落とされていないか、外部の人間を交えて、議論しておくのもいい方法だろう。