<   2015年 08月 ( 5 )   > この月の画像一覧

在庫のデータ構造を考える

「わたし」は新米のエンジニアである。最近、先輩からオフィス備品類の在庫管理を手伝うようにいわれた。ペンだとかノートだとかフォルダとかいった文具類が中心である。これまである意味、ルーズな管理だったが、経費節減の折、きちんと在庫数量を管理した方がいい、と部長が方針を出したとのことだ。今まで、各人が勝手にネットからモノを注文して取り寄せ、請求伝票だけが部の庶務係に回される。これをやめて、部で必要数量を考え、集中的に購入し、部のキャビネに保管しておく。そして各人が必要時に庶務係に申請して受け取る、という管理方式にかえることになった。その、キャビネの在庫管理の仕組み作りが、「わたし」の仕事だ。

在庫管理の仕事ははじめてだ。だからいきなり部の仕組みを作り始める前に、たとえば自分の家のモノを在庫管理するとしたらどうするかを考えてみることにした。題材は何でも良いが、出入りの多い食べ物にしてみよう。

在庫管理というのだから、何よりもまず、「在庫の表」が必要なはずだ。何が何個ある、そういう台帳のようなものだ。そのイメージは、表(1)のようにするのが良さそうだ。まず、品番がある。次に品名が来る。そして在庫数量と、数量単位だ。ここでは、いろいろなモノに品番をふって管理するのがポイントだ。たとえば「玉ネギ」ならば品番A12がといった風だ。こうすると、いかにも“プロが管理してる”っぽい感じがするではないか。うん、これがいい。

ところで、この表の中では、品番と品名は一対一に対応している。していないとこまる。同じA12が、ある行では「玉ネギ」で、別の行では「ほうれん草」では何が何だか分からなくなる。ということは、品番と品名の関係は、別の表で管理して、両者を関係づけるのが良さそうだ。つまり、在庫量のデータを表す(2a)「在庫テーブル」と、品名を登録する(2b)「品目マスタ」である。こういう風に、依存関係が混乱しないように独立させるやり方を、『正規化』と呼ぶんだと先輩が言っていたな。ま、この程度は初歩だよ、ワトソン君。
e0058447_2265817.gif


ん? でも、ちょっと待てよ。考えてみると、同じ食べ物でも、家の中の置き場所はいくつかあるな。まず、冷蔵庫。それと冷凍庫か。一方、物置に近い場所にストッカーもあって、腐りにくい野菜類はそちらに置いたりもしている。うーん。じゃ、在庫テーブルには、保管場所の欄も必要らしい。同じ品番が、複数の保管場所に存在することもあるからな。となると、本当は台帳は(3)の「保管場所別在庫テーブル」みたいな形をしているべきなのか。そして、(2a)の「在庫テーブル」は、それを集計サマリーした結果の表ということになりそうだ。うむ。これでいいだろう。
e0058447_22162039.gif


「わたし」はリラックスしようと思い、冷蔵庫からジュースの1Lパックを取り出し、コップについだ。そして無意識のうちに、このジュースはいつ買ったかなと、パックの賞味期限を確認した。そのとき、ふと自分が大事なことを一つ見落としていたことに気がついた。

在庫量というのは、日々、変動しているではないか。たとえばこのリンゴジュースも、自分が買ったときには1リットルあったが、飲んでいくうちに少しずつ減っていく。ただ、それを毎日まさか測ったり確認したりはできない。だって手間がかかりすぎるもの。ということは、在庫数量のデータを台帳に登録したら、その登録日も同時に記録しないとまずいのだ。となると、あるべき台帳の姿は(4)の「保管場所別在庫テーブル・登録日付き」みたいなイメージになりそうだ。
e0058447_22164552.gif


これでいいのだろうか? なんだか「わたし」は少し自信がなくなってきた。そもそも、部の備品を管理したいんだったよな。庶務係がまとめて注文を出す。文具が会社に届く。それを部のキャビネにしまう。各人が、たとえば「わたし」が、ペンを必要なときに、庶務係に伝票を書いてペンを1本払い出してもらう・・。

そうすると、ペンの在庫量のデータというのは、いつの時点で登録するんだろう? キャビネの中にペンが何本はいっているのかを登録するのは、ペンが文具屋さんから到着したときなのか、それとも各人に払い出すときなのか・・。

「わたし」は急に、驚くべき真理に気がついた。いや、革命的なアイデアと呼ぼうか。「在庫は登録すべきデータではない!

業務のプロセスを考えてみると、実際に人が把握しているのは、保管場所にモノが出入りする数なのだ。保管場所にいくつモノが入っているか、ではない。表(5a)の入出庫テーブルを見てほしい。家の食べ物の例で行くと、たとえば8月12日に玉ネギを1個、冷蔵庫に入れました。結果、冷蔵庫の中の在庫量は1個になりました。さらに14日に、八百屋から6個、玉ネギを買ってきてストッカーに置きました。結果、ストッカーの在庫は6個になりました。ところが翌日、冷蔵庫から1個、出して料理に使いました。すると冷蔵庫の中はゼロ個になり、今度は20日にストッカーから1個、玉ネギを取り出して冷蔵庫に移しました・・

自分たちが把握し、きちんと登録すべき実体は、入出庫のデータであって、在庫量はそこから計算で導出されるデータなのだ。そして入出庫の種類は、供給による入庫、消費のための出庫が基本だが、ある保管場所から別の保管場所に移動するための入庫と出庫もある。移動の場合、全体の在庫量は変化しない。
e0058447_2292029.gif

そして、考えてみると、部の備品在庫量も、月単位の記録が必要になりそうだ。そのためには(5b)のような「月別在庫サマリーテーブル」を、(5a)から計算して作成すればいい。表には月初材料量と、最新の在庫量を、それぞれ日単位で集計して更新する。過去の月については、最新在庫量=月末在庫量、ということになる。じつにスマートじゃないか。ああ、自分はなんて優秀で頭が良いんだろう!「わたし」は仕事の進み具合に満足した。

これで完璧だろうか? もう、見落としていることはないか?

慎重な「わたし」は、もう一晩だけよく考えてみることにした。そして夕食のために豚肉の玉ネギ炒めを作っているときだった。なぜか冷蔵庫に玉ネギが見当たらないのだ。たしか残っていたはずなのに。わたしは冷蔵庫の中をひっくり返し、中身をほとんど空っぽに出して探したところ、ようやくケースの後ろに引っかかって、つぶれかかった玉ネギが見つかった。あーあ、これじゃ食べられないや。

そしてなぜかふと、自分が研修のために工場見学をしたときのことを思い出した。その工場では、ちょうど資材倉庫で「棚卸し作業」というのをやっていた。半期に1回の作業ということだった。部品類を全部棚から出して、数を数え直すのだ。なんでそんなことをやるのですか?とたずねたところ、「帳簿の数と現物の数が合っているか確認しているのさ」、という答えだった。「そして、傷んだり古くなって使えない部材は捨てるんだ」と。

部の備品キャビネでも、同じ作業をやらなければいけないかもしれない。棚卸しかあ。そのデータは、どう扱うんだろうな。「わたし」は(6)のような「棚卸しテーブル」を想像した。品番と、保管場所ごとに、棚卸し作業日を決めて、確認できた在庫量、そのうち廃棄すべき数量を入力する。結果として現在庫数量が導出される。

でも、もしかしたら棚卸しというのは、入出庫の一種として扱うこともできるかもしれないな。でもまあ、作業のサイクルが別だから、別の表にした方が便利かもしれない・・。
e0058447_2211278.gif

せっかく夕方に感じた自信と高揚感が、夜のうちに傾きかけたばかりではない。翌朝、「わたし」はもっと面倒なことに気がついた。工場では確か、「ロット管理」というのをやっていた。これ、部の備品でも必要になるだろうか? 工場でなぜロット管理が行われているかは、一緒に見学に行った同僚の質問に、工場の人がこう答えていた。「不良が見つかったとき、それがロット固有の不良ならば、そのロットだけを破棄すればいい。もしロット管理していなかったら、全品を検査して破棄しなければいけない可能性が高まる」と。

まさかペンやノートにロット管理が必要だとは思わないけれど。でも、もしロット管理が必要だったら、(7)のような「ロット別受払テーブル」がいるんだろうか。それを集計サマリーして在庫量のデータを作るのかな。でも、ロットがいつもひとまとめで扱われるとは限らない。ロットの中から一部だけ払い出したら、それはどうするんだろう。それと、もしかりにロット不良が出たら、それは在庫量のデータとしてはどう扱うんだろう・・「わたし」は頭がくらくらしてきた・・

・・というのは、むろんフィクションである(最初から分かっていたと思うけど^^;)。ただ、この例を通して、在庫のデータモデルについて、いくつか教訓を学ぶことはできる。

(1) 在庫は実体データではない。入出庫から導出されるデータである。
(2) 在庫量は日時と紐づいてはじめて意味を持ち、通常はその履歴も必要だ
(3) 在庫管理には棚卸し業務が必須である。(棚卸し業務を経てはじめて実在庫量が確定し、それが収支決算のベースになる場合も少なくない)
(4) 在庫をロット管理する場合もある。

そして、この新米君のケースでは省略したけれども、在庫金額(=単価×数量)、消費期限、シリアル番号、引当処理と有効在庫、品質検査結果による減損やロットアウト、倉庫間移動などなど、数々の業務要件があるのが普通だ。また、例に挙げたテーブルだって、まだまだ改良すべき余地もある(長くなるからもう書かないが)。だから、たかが在庫管理システム、などとあなどると、結構痛い目にあうこともある。在庫管理は奥が深いのだ。

世間で言うモノの管理(わたしの用語では、マテリアル・マネジメントないしマテリアル・コントロール)というのは、なぜか会社の中で単純業務と軽んじられるケースがある。モノを設計したり加工したりする方が本質だ、と思う人々や、お金の管理の方がずっと大切だと信じる人々などに囲まれて、仕事をしている。そして、在庫量は見えて当たり前、在庫はちゃんと管理できて当たり前、みたいに扱われたりする。このような風潮は、少しは反省されてしかるべきだと考える。そういったマインドセットのまま、自社のサプライチェーンが国境を超えて広がると、あっという間に仕事のプロセスが混乱してくるのは目に見えている。

それと同時に、在庫データを扱うシステムについて、システム屋さんたちももう少し腕を磨いたらどうかと思うことがある。上の例でも分かるとおり、ちょっとした在庫管理でも、それなりのエンティティとリレーションの組立が必要になるのだ。むろん、こうしたデータ構造の問題に決まった『正解』はない。データ・モデリングという仕事は、客観的・科学的な面もある半面、どうすればエレガントで美しく作れるかという、技芸(英語で言うArt)の面も併せ持っているからだ。そして、この両面を磨くのに、在庫のデータモデルほど、格好の例題はないと思うのである。
by Tomoichi_Sato | 2015-08-30 22:26 | サプライチェーン | Comments(0)

人を使うということのオーバーヘッド

なんだかひどく忙しい。そう、あなたは感じている。やらなければならない仕事が山のようにたまってしまった。このままでは期限までにアウトプットが出せそうにない状況だ。自分の下に誰かつけてもらって、やるべき仕事量を分担して進めるしかない。

あなたは上司に窮状を訴え、一時的な手助けのために、なんとか若手を一人つけてもらえることになった。この部に入ったばかりの、まだ右も左も分からない新米だ。しかし贅沢を言っていられる状況ではない。周りも皆、忙しいのだ。儲かってもいないのに、ウチはなぜこんなに忙しいんだ?  あなたは独り言をつぶやきつつ、そもかくその新米を席に呼ぶ。頼みたい仕事を説明するためだ。

頼む仕事は、比較的単純だ。あなたが作ったExcelシートに条件の数字をインプットして、何種類かケーススタディをしてほしい。あなたは、ある案件の原価と収支を計算して、売価や条件を関連部門に連絡しなければいけないのだが、その計算の一部を新米に頼む訳だ。本当は、必要な資材数量や外注価格も調べて、インプットの数字も作ってほしいのだが、それには過去の実績を調べたり、関連部署に問い合わせたりしなければならず、ある程度経験がなければこなせない。だから自分で以前作成した計算用シートへのインプット作業だけを頼む訳だ。とはいっても、検討すべき条件にバリエーションがいろいろあるため、ケーススタディの数もけっこう多い。だから、そこだけでも分担してくれれば少しは助かる。

・・と、思ったのだが、何なんだこの新米。端末で表を見せて説明してやっても、眠たそうな顔をしているだけで、分かったのか分からないのか不安だ。質問もしてこない。打てば響くように、即、作業に向かってくれるのを期待していたのだが、心許ない。「分かった?」と念を押しても、「はあ・・」と頼りなげに答えるばかり。いったん席に戻ったが、しばらくするとまたあなたのところに来て、「それで、インプットのデータはいつそろうんですか?」という。まだ全部はそろわないから、できている基本ケースから着手してくれと言ったじゃないか。すると次は、「このセルに入力しても、結果がすぐ出ないんですが。」という。だからそこはマクロを呼び出すんだよ。

あなたは内心、舌打ちをしながら、しかたないので指示書を書くことにする。インプット諸条件の表(まだほとんどは空欄だが)、Excelの入力セルとマクロの起動、出すべきアウトプットとケーススタディの諸条件。ケーススタディ数は、結果によってはさらに増減する可能性がある。ともあれ最低限のケース条件を決めて、その新米に渡した。指示書を作成するだけで、2時間以上もかかってしまった。これじゃ何のために手助けを入れてもらったのか、わからない。

半日後、新米が最初の計算結果を持ってきた。あなたは数字をちらっと見るが、なんだか変だ。表の入力欄を追いかけてみると、案の定、インプットの場所を間違えている。自分でチェックもできないのか!とあなたは叱って、もう一度やり直しを命じる。その後もまごまごして、結局、最初の答えが出たのは夜になってからだった。あなたが自分でやれば、たぶん1時間以内に終わるはずの仕事だったのに、指示書を作りアウトプットをチェックしていたおかげで、二人で半日、つまり1人日もの工数がかかってしまった。

教訓1:人を増やしても、生産性はすぐには上がらない。指示や教育に必要な余計な手間(オーバーヘッド)が生じるためである。

明くる日の夕方、あなたは数ケースの計算結果を新米から受け取る。ところで、横並びの表を見ているうちに、原価に関しては期待した傾向が出ていないので、少し疑問に思う。中身を再度、一つひとつ追いかけていくと、新米の間違いに気づく。計算ミスではない(そもそもExcelなんだから)。だが原価計算に関して、配賦の考え違いをしているのだ。使えない奴だなあ! あなたは内心、毒づく。人事部も、もっと戦力になる人間をとってくれよ。だいいち、大学でもっと即戦力になるよう、教育すべきじゃないの?

(ここでちょっと一言。大学で、ほんの少しだが教えている立場から弁明しておきたい。学校で教えておくべきことと、企業で社内研修で教えるべき事の線引きは、どこが適当だろうか? 答えは簡単である。社会において共通性の高い、汎用的な知識・スキルは学校で教え、企業ごとに違う、個別化されたスキル・能力は企業内で育てるべきなのだ。たとえば簿記の知識などは汎用的だ。だから会計や簿記教育のコースが成立する。しかし、原価の基本原理はともかく、配賦となると、企業ごとに違う。経営方針を反映しているからだ。

「即戦力」という言葉が、企業内業務の個別性を含んだところまで意味するなら、それを学校教育に求めるのはおかしい。逆に、学校教育に多くを期待したいなら、自社内の業務をなるべく社会や業界の標準にあわせていく必要がある。むろん後者は、多数の企業が同じマインドで協力しなければ実現しないわけだ。

この関係はちょうど、情報システムにおける手作りとパッケージ利用の違いに似ている。業界で共通性の高い仕事は、パッケージソフトが存在するし、それに任せておけばいい。他方、他社とは差別化した業務は本来、競争力の源泉だ。当然ながらそれをサポートするパッケージソフトなど、世の中には存在しない。

問題は、競争力の源泉でもないのに、他社とは違う個別化された特殊業務が、あちこちに存在していることだ。それは確実に生産性の足を引っ張っている。そういう状態に無自覚なまま、「即戦力」だとか「クラウド活用」だとか叫んでも無意味であると思う。だが話がそれたので元に戻そう)

ともあれあなたは、自社の原価に関する配賦基準を説明し、計算のやり直しを命じる。正しい答えが出てきたのは3日目になってからだった。今度からこの種の計算は、ちゃんと指示書をマニュアル化しとかないとまずいなと、あなたは思う。Excelももうちょっと表を分かりやすく作らねば。バカでも間違えずにインプットできるようにしないと、あぶない。

教訓2:人を使って効率が上がるのは、より標準化・定型化された業務である。個別化され臨機応変が要求される業務は、他人に外注するにはあまり向かない。

さて、あなたはいくつかのケーススタディの結果を携えて、企画会議に臨む。その場で議論が発展し、さらに検討すべきことが出てきた。あなたは自分の部署に戻り、新米に指示しなければいけない。口頭で背景を説明し、指示書を改定・追加するわけだが、ひどく面倒な作業に感じる。最初から、新米君も一緒に会議に連れて行けばよかったのか。少なくとも、こんな二度手間は不要になるはずだ。

だがその三日後、次なる企画会議に新米を参加させてみると、2時間の会議の中で、かれに関係ある話題は5分ちょっとで、あとの時間はぼおっとして座っているだけだということが分かった。ただ、その話題がいつ出てくるかが、なかなか事前には読めないのだ。しかも会議に参加している間は、確実に新米君の作業が止まってしまう。

だが、少なくとも会議に出させたおかげで、あなたがなぜこんなケースを追加したのか、どういう結果がほしいのか、了解はさせられたと思う。つまり、仕事の「コンテキスト(文脈)」を新米君にも共有させたのだ。しかし、やっかいなことに、コンテキストを理解したらしたで、こんどは新米が「こうすべきじゃないでしょうか?」などと言い出すようになった。お前さんの中途半端なアイデアなんぞ、期待しとらんのよ。いわれたことだけ、きちんとやってくれ。あなたは、そう言いたくなるところを、ぐっと飲み込んで、ただ聞き流すことにした。

そうこうするうちに、ようやく企画も方向性が決まってきた。あなたが彼にやらせたケーススタディも20を超えたが、やっとミスが減ってきた感じだ。企画会議でも、少しはぴりっとした顔つきになってきた(思いつくアイデアは相変わらず的外れだが)。いろいろ忍耐もしたが、少しは育ったかなと思う。「育成とは忍耐だ。」と先輩が言っていたセリフを、あなたは何となく思い出す。

・・というところで、思わぬ展開があった。この案件自体が、海外生産で対応することになったのだ。競争力を出すため、という命題なのだが、おかげで原価計算から何から、全部やり直しである。しかしトップの指示だから、しかたがない。あなたは、この新人にやらせた計算作業を、今度は海外子会社にやらせなければならない。となると、まずExcelの表も指示書も、英語に翻訳する必要がある。それはまだ我慢できるとしても、あの、多部門を巻き込んだ企画会議のドタバタを、こんどは子会社と繰り返すのかよ、とあなたは思う。案件の企画というのは、クロス・ファンクショナルな、相互調整と交渉の仕事である。やるべきケーススタディの条件も、すべて最初から決める訳にはいかない。20のケースを決めて、まとめて「計算してくれ」と依頼するなら、まだしも楽だ。だが、結果を見ながら条件を微調整して、といった進め方を、言葉も働く時間帯も違う相手と、うまくできるだろうか。

案の定、企画の仕切り直しは当初の倍以上の期間がかかってしまった。とにかく海外子会社あてだと、何を頼むにも一から十まで事細かく説明し文字にしないと伝わらない。いや、文字に書いたって、あちこちで誤解と混線が生まれるのだ。結果が出るまで任せきりにできないから、途中経過も逐一チェックし、軌道修正をかけてやらなければならない。本当にこんな事やっていて、コストダウンにつながるの? むしろエンジニアの手間が増えるばかりじゃないの。何せ相手は、話のコンテキスト(文脈)を共有していないのだから。

教訓3:コンテキスト(文脈)を共有しない海外相手の作業外注は、同じコンテキストを共有する日本人同士より、余計なオーバーヘッド(手間)が倍以上かかる。

コンテキスト・レベル」というのは、アメリカの文化人類学者E・ホールが言い出した概念だ。社会の中でのコミュニケーションにおいて、どれほどお互いがコンテキスト(文脈)を共有しているかに関する、無意識の前提である。ハイ・コンテキストな社会では、お互いが「言わずと分かる」以心伝心・暗黙の了解が、コミュニケーションの基本的スタイルになる。ロー・コンテキストな社会では、すべてを言語化して伝えないと分からないはずだ、というコミュニケーション・スタイルが基本になる。ホールは調査の結果、アメリカ先住民はハイ・コンテキストだが、白人社会はロー・コンテキストであるという意味のことを述べている。アメリカに比べて北欧社会はもっとロー・コンテキストだ、とも。

先日、訪日したスペインのPM学者Dr. Javier Pajaresさんと話していたら、同じヨーロッパ内でもコンテキスト・レベルに差があり、たとえばスペインに比べてドイツはずっとロー・コンテキストだが、旧ソ連のCIS国家はかなりハイ・コンテキストに思える、と言われていた。国際会議で、たまたま旧CISの教授が、ドイツ人の教授と、1対1の会食を希望した。他人のいない場所で、本音で話したいことがあったらしい。しかし、それを遠回しな形でしか伝えなかったために、ドイツ人はPajaresさんをはじめ、知人のイタリア人やら誰やらをみんな呼んでいたので、やってきた旧CISの教授はびっくりしてしまったという。「ドイツ人に何かを伝えたかったら、そのものズバリを言わなきゃダメだよ。ドイツ人にとってYesはYes、NoはNoなんだから」というのが、彼の解説であった。

何度も書いていることだが、「人に働いてもらって目的を達すること」が、『マネジメント』という行為の中核である。人を動かすのだから、テレパシーでも使えない限り、言語化して伝えなければならない。ただし、その手間は、相手と共有する文脈、そして相手がよって立つ文化のコンテキスト・レベルに依存する。日本は非常にハイ・コンテキストな社会である。だから、あまり事細かく言語化しなくても、下にいる人間は、上の意向を忖度(そんたく)して動く。

このやり方に慣れていて、これがそもそも当然であると思っている人が、いったん国境を越えると、あまりに指示に手間がかかるといって驚くことが多い。驚くだけならまだしも、怒ったりあきれたり、さらに「相手はバカだ」と思ったりする。そうなると、ビジネス的コミュニケーションのはずが、感情的なやりとりに転化してしまう(ここに、人種的偏見が微妙に影響したりするから、ますます始末におえない)。そうなったら協力的仕事などうまくいくはずがない。

でも、落ち着いて考えてみると、わたし達の普段の仕事でも、コンテキストを共有しない相手とか、世代が離れていて感覚の違う相手とかだと、やはり大小の違いはあれど似たようなギャップがあるはずなのである。それに気づいて、落ち着いて対処できる態度が身についているかどうかが、じつは大事なのだ。

どんな業界でも職場でも、仕事量には山と谷がある。そして個人の能力にも限界がある。それを超えて仕事量を柔軟に増大したければ、他者を使うときの原理と、コミュニケーションに必要なスキル・態度を身につけなければならない。そして、人を使うときには、それにともなう手間=オーバーヘッドが余計にかかるのだ。一人を二人に増やしたって、生産性は2倍にはならない。3割か、よくてせいぜい5割増し程度だ。それを8割増しくらいに持って行くためには、きちんとした標準化等の準備が必須である。

あいにく、わたし達は、そうしたことをあまりきちんと教育されていないようだ。少なくともわたし個人は、人の使い方を体系立てて教わったり、コーチングを受けた記憶がない。だが、「人を使う」という行為は、課長やマネージャーの地位に就くはるか以前から、実務では必要になる。とくに海外とやるときは、組織的な習慣化(=OS化)が望ましい。だから「世界を動かすプロジェクトマネジメントの教科書」みたいな本を書いた訳だが、たとえ国内とやるときだって、相手が社内にいるときだって、最低限、知っておかなければいけないことがあるのだ。上にあげた3つの教訓などは、その代表例だろう。こうした集合的な知恵とスキルを、わたし達はもっと組織内で蓄えるべきではないかと思うのである。
by Tomoichi_Sato | 2015-08-23 14:52 | ビジネス | Comments(0)

忘れない、という行き方

ある日、あなたは福島県から来た企業家に会って、こんな話を聞く。
「震災から4年余りが経ったが、地域の復興はなかなか進まないばかりか、世間の人はもう忘れたがっているようにさえ見える。あなたは東大で環境の研究をしておられるそうだが、東北の環境浄化や自然エネルギー活用のための斬新な案をお持ちではないだろうか。もし良いアイデアがあれば、わたしも事業の傍ら応援したいし、資金獲得のお手伝いくらいはできると思う。」

あなたは「環境再生ないし自然エネルギー活用による、東北地域復興プロジェクト」の案を考えて提案することを約束した。
プロジェクトの総予算は3億円とする(ちなみに復興庁の今年度予算は3.9兆円で、「再生可能エネルギー」関連だけで計23億円ある)。また、必要に応じてクラウドファンディング(「セキュリテ被災地応援ファンド」等)でも公募できる。

・・これは、東大の大学院・新領域創成科学研究科でわたしが教えている「プロジェクトマネジメント特論」の、グループ最終課題として今年出題した問題である。受講する院生はほとんどが環境学系の所属のため、このようなテーマ設定にしてある。グループ編成は、5〜6名。班の中で、プロマネ・APM(アシスタントプロマネ)・チーフデザイナー・プロジェクトコントローラーなどの役割分担を決めて、約1ヶ月半で事業構想とプロジェクト計画を作る。発表は、8分間の動画ファイルを作り、それを皆の前で提示してもらう。

なお、これはプロジェクト・マネジメントの授業なので、事業コンセプト(概略イメージ)だけでなく、予算・期間を提示してもらう。プロジェクト計画は、以下の図表と説明を入れるよう義務づけている:
・ActivityリストとWBS構造図
・ネットワーク・スケジュールとガントチャート
・予算表 (自分たちの人件費は時間あたり2,000円。他の費用は「月刊積算資料」などを参考にする)

採点はわたしがするのではなく、出席者全員に採点表を渡して、他の班を採点してもらう仕組みにしている。内容の良さ、そしてプレゼンテーションの上手さ。両者の評点を集計して、総合評価を決める。プロジェクト・マネジメントは知識だけあってもしかたがないので、学期末のペーパーテストやレポート提出ではなく、グループ課題での発表にしているのだ。

今年の最終発表会で一位になったグループの案は、『阿武隈ダイヤモンド・ チャコールプロジェクト』というタイトルのものだった。プロジェクト実施の場所は福島県浜通地方にある川内村。この村は1960年代までは、豊かな森林資源を活かし、日本一の木炭生産量を誇っていた。しかしエネルギー革命で電気や石油が燃料の主役になってからは、住民は里山を捨て、原発産業などに従事するようになった 。そこに、東日本大震災である。現在の川内村は、仕事を失い、人が戻れない状況にある(村の東部は避難指示地域)。そこでこの班は、製炭業を復活させ川内村を再建するプロジェクトを提案する。

そのキーとなるのが、高品位な木炭(チャコール)という訳である。これを『阿武隈 ダイヤモンド・チャコール』と名付け、世界一のブランドを川内村から作る!という。この班は実際に教室に木炭を持参して、皆の前で簡単な実演をした。炭と炭を打ち合わせると、高級な木炭はカンカンという硬質な良い音がするのに対して、量販店で売っているBBQ用の安い炭はボソボソッという音しか出ないのだ。百見は一聞に如かず、である。単なる木炭にも、ずいぶんと品質ランクに差がある事が分かる。良い木炭は当然、用途も広いし単価も高い。

この班は製品の試作・分析から量産準備までをプロジェクトとしてとらえ、3億円の投資で、IRR=10%が可能であると試算した。経済性評価ではちゃんと感度分析をしている。またスケジュールも、クリティカル・パスを求めただけでなく、モンテカルロ・シミュレーションを実施して、工期の達成の幅まで検討している。まあ限られた期間内の院生の仕事だから、計画の精度は高くないが、プロジェクト計画のアプローチは、下手な上場企業よりもずっとしっかりしている。

2位になった班は、畜産廃棄物(家畜糞尿)からのバイオガス発電のプランを出してきた。売電による収益で畜産農家を支援するという案だ。プレゼンテーションは地味だったが、他の受講生からの評価はなかなか高い。きちんとPREET/CPMでスケジュールを作成し、コンティンジェンシー・リザーブ(予備費)によるリスク対策もみている。ほかにも面白い案がたくさんあったが、紹介しきれないので割愛しよう。

こうしたプロジェクト・プラン立案のグループ演習を課すのは、班で共同作業すること自体がちょっとした「プロジェクト体験」にもなるからだ。そのためには、アイデアが宙で空回りしないよう、予算規模の制約をつけるとともに、地に足がついた具体的な地域性が必要になる。だから福島県を選んだのだ。

いま、なぜ福島県か。それはもちろん、「忘れないため」でもある。

課題発表会の直前、わたし自身も東北を旅行した。震災から4年後の現在、現地がどうなっているのかを、少しでも見ておきたいと思ったのだ。最初に福島県の郡山に入り、それから二本松、土湯温泉、さらに飯館村を通って福島県の浜通地方に出る。そして国道8号線沿いに、被害の最もひどかった太平洋岸の浜通地域を通る。このときはボランティアのバスに同乗させてもらい、カリタス原町センターのスタッフの方に案内していただいた。そのあと、岩手に抜け、最後に宮城県の涌谷町・仙台市を通って帰ってきた。

浜通地方の原発事故被害にあった地域は、今もまだ多くが避難指示区域で、立入り制限ないし居住制限下にある。居住の制限された区域は、昼間のみ、地域に入れる。実際、多くの除染作業従事者が入って働いており、除去した表土などは黒いビニール袋(通称「トン袋」)に詰めて、空き地などに並べている。わたしたちの乗ったバスは国道8号線を走ったが、「帰還困難地域」に入ると、道の両側に鉄のバリケードが並ぶ。国道からそれて、中に立ち入れないよう制限しているのである。山野も町も、道の両側の建物も、ほぼそのままの姿で残っている。青葉は陽光に輝いている。だが、住む人がいないのだ。この異様さは、実際に走ってみないと分からない。制限区域をすぎて、南相馬市の人の暮らす地域に入ると、なんだかほっとする。人がいることが、こんなにも安心するものなのか、と思う。

福島県ではあちこちに、空間線量計が立っている。二本松市の幼稚園の庭に立っているのを見たときは、なんともいえぬ困惑を感じた。幼稚園の庭には砂場があるのだが、鶏小屋のような屋根とプラスチックの囲いがつけられている。子ども達はどうしても砂遊びがしたい。砂はもちろん新しいものに入れ替えてあるが、周囲を取り囲む山野は除染ができない。だから、砂が風雨にあたらないようにつけてあるのだ。線量についていえば、わたし達の通った国道8号線で最も高い場所は、8μSv/hr以上あった。一応参考までにいうと、従来の放射線管理区域の目安は、約0.5 μSv/hrである。周知の通り、放射線の健康影響にはいろいろな議論がある。だが、8μSv/hrとなると、率直なところあまり無用な長居をしたい気分になる場所ではない。

写真を2枚だけあげよう。上は、常磐線富岡駅前の光景だ。4年前の津波にえぐられたままの商店街の建物が、今も手つかずで残っている。ここらはまだ除染作業も進んでいないため、撤去修復にも戻れないのだ。下の写真は、南相馬市の常磐線小高駅の自転車置き場である。4年前の3月11日の朝、通勤・通学の人達はここに自転車を駐輪して、常磐線に乗っていった。そしてそのまま、誰も取りに戻れずに日々が過ぎたのだ(かりに帰還しても、自転車は汚染している可能性が高いから引き取れないだろう)。列車もその日以来、動いていない。ここではまだ、時間が全く止まってしまっている。
e0058447_2324034.jpg
e0058447_233232.jpg

郡山市では、「ふくしま心のケアセンター」所長で、精神科医の昼田源四郎先生にお目にかかった。昼田先生とお会いするのは2年ぶりである。震災後、岩手・宮城・福島の3県にそれぞれ「心のケアセンター」組織が立ち上がった。昼田先生は福島大学を退任されたあとすぐ、所長として臨床心理士などの職種のスタッフを集めて組織されてきた。しかし震災後3年経ち、4年経っても、まだ相談件数は目に見えて減っていない。そればかりか、「ハサミ状格差」「支援疲れ」などの具体的な事例をあげて、まだ困難が続いている事を語られた。

こうした心のケアセンター組織は、阪神淡路大震災以来の教訓として作られたものである。昼田先生によると、阪神・中越大地震のいずれのケースも、心のケアセンターは約10年で役割を終えたという。そして、岩手県や宮城県も、おそらく10年程度で完了できる。しかし福島県の場合は、自分の見たところ30年か40年かかるのではないか、と言われた。長年、精神科の臨床に携わってこられた専門家の洞察とはいえ、まるきり一世代分の時間である。福島の問題の難しさが浮き彫りになっているといえるだろう。

このような困難を抱える地域に対して、わたしが復興のために何かとびきりの名案を持っている訳ではない。たぶん、誰にもないだろう。学生達の示した案もまた、かりにフィージブルだとしても、福島県全体を救える訳ではなく、広大な東北地方から見れば「点」のようなものである。

しかし、小さな点と点をつないで、少しずつ状況を改善し続けるしか、道はないのだとわたしは思う。だから昼田先生は30年かかるといわれたのだろう。

ただ、有用な策を考えるためには、現実がどうだったのか、そして現在どうなっているかを知る必要がある。ところで震災後4年もたったのに、あの東日本大震災は何だったのか、その被害状況はどうだったのか、具体的な全体像を多面的・客観的にまとめた書籍や研究は、いまだに決定版がほとんど見当たらない。たしかに、途方もなく大きな事象ではあった。だが、個別の専門家達による、群盲象をなでるかのような分析やレポートはあるが、全体像が分からない。全体像が分からないと、どこから優先して解決に手をつけるべきかも見えないことになる。ポートフォリオ・マネジメントもなく、プログラム・マネジメントもなく、ただ個別のプロジェクトが動いているきりなのだ。

どうやらわたし達の社会は、大きな出来事を、カメラを引いて全体を冷静に認識・理解する能力が、欠けているのではないか? わたしの中で、そんな疑問が大きくなってきた。リスク・マネジメントの語は、震災前後から流行語になった。しかし、リスク・マネジメントの中核にあるのは、「学ぶ能力」である。自分たちの過去の経験を直視し、教訓を学び取る能力。自然災害はいつでも起きうるし、人為ミスの災害も完全には防ぎ得ない。である以上、わたし達は、痛い思いをした経験に学んで、少しずつ賢くなるしかないのだ。その賢さを、次の世代に伝えなければならない。

もちろん経験の中には、あまりに傷が大きすぎて、思い出すことさえ苦痛であるような記憶もあるだろう。だからといって当事者が、それを忘れられる訳でもない。そうした記憶は、おそらく他の多くの人が共有することでしか、薄めることができないのだろう。深く傷ついた人びとは、周囲が支えなければならない。他者がかわりに記憶することで、たぶん当事者は心にふたをしていけるのだ。

福島の人達が、「忘れないでください」と言い続けているのは、そういう意味なのだと思う。わたし達は、忘れやすい。過去は水に流して、未来志向に生きていく方が、ポジティブでカッコいい。だが、マネジメントを学生達に教えている以上、忘れない工夫と技術も、わたし達には必要なのだ。


<関連エントリ>
 →「まだ何ひとつ終わっていない」 (2013-09-16)
by Tomoichi_Sato | 2015-08-13 23:10 | 考えるヒント | Comments(0)

プロジェクト・マネジメントについての新著を、9月に出します

お知らせです。
9月初旬に、プロジェクト・マネジメントについて新しい著書を技術評論社より上梓します。

 「世界を動かす プロジェクトマネジメントの教科書」 佐藤知一・著

 出版社の新刊紹介ページ:(概要・目次を見ることができます)
 http://gihyo.jp/book/2015/978-4-7741-7604-8

 Amazonでもすでに予約可能になっています!
 世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方
e0058447_235327100.jpg

本書の中心テーマは、『海外型プロジェクトの進め方』です。現在、海外への事業展開を検討し、チャレンジしている日本企業は多いですが、わたし自身が見聞きした範囲では、いくつか共通する弱点を抱えているように見受けられます。国内ではうまくいったはずの仕事のやり方が、一歩海外に出たとたん通用しなくなる、というのはよくある話です。それはPM技法的な能力の不足もさることながら、組織のスタンス自体がずれているからです。たとえば、もし、

- 計画がきちんと立てられず、行き当たりばったり
- だれが何を決めるのかわからず、意思決定が遅れる
- 以心伝心・暗黙の了解で動いて、言葉にしない
- 契約感覚に乏しく、地雷を踏んでしまう

といった項目に、一つでも思い当たることがある方は、ぜひ本書を手に取ってご覧ください。本書は通常のPMの標準書に書かれている技法論もカバーしていますが、それよりももっと底にある組織の思考・行動習慣(これをわたしは組織の『OS』と呼んでいます)に、何が不足しているかを解説しています。

本書の内容は元々、東大大学院でのプロジェクト・マネジメント講義資料を中心にまとめたものです。ただ、単なる教科書ではなく対話形式とし、これから初めて海外プロジェクトにチャレンジする製造業の若手エンジニアを主人公に、多少のストーリー性を加味した形にしました。

海外型プロジェクトの進め方について問題意識を持っておられる方、あるいは中小規模のプロジェクト実務に携わっていながら世間のPM標準では満たされぬ思いを感じておられる方々に、ぜひ読んでいただきたいと願っております。


佐藤知一
by Tomoichi_Sato | 2015-08-08 23:54 | プロジェクト・マネジメント | Comments(0)

YesとNoのゲーム - コミュニケーションを教えるということ

最初に、『Yes/No』ゲームについて説明しよう。Q&A(質疑応答)ゲーム、ともいう。4、5人ずつのグループでやるゲームだ。大人でも、子供でも、むろん学生でもできる。

ルールはとても簡単である。出題者は、何か具体的で、目に見えて手で触れる、形のあるもの(人でもいい)の名前を紙に書いて、隠しておく。回答者はグループに分かれて、順番に、出題者に対して1つずつ質問をしていく。このとき、質問についてのルールが2つある。一つ目は、質問は必ず、相手が「Yes」か「No」か、または「どちらでもありうる」の三種類のどれかで答えられるような質問であること。二つ目のルールは、誰かが既にした質問を繰り返してはいけないこと。基本はこれだけだ。

たとえば、出題者が「ビーチボール」という答えを用意していたとしよう。質問する側の最初のグループが、
「それは食べられるものですか?」とたずねる。答えは「No」だ。
二番目のグループは、「それはどこの家にもあるものですか?」と聞いてみる。出題者は「うーん、Noかな。」というだろう。
さらに三番目のグループが、「手で持てる大きさのものですか?」と質問し、「Yes」の答えを得る・・といった具合である。こうして順番に質問を浴びせていき、最後に、「それはビーチボールですか?」とたずねて「Yes」の答えを得た班が勝利者になる。

「それは何ですか?」「それはどうやって作るものですか?」といった質問ではなく、必ず「Yes/No/どちらもありうる」で答えられる質問、というところがミソだ。このように、答えの選択肢が限定されている質問のことを、コミュニケーション論の分野では、Closed Questionと呼ぶ。他方、「それは何?」のように答えに限定がない質問は、Open Questionという。このゲームは、いいかえると、有限の数のClosed Questionをつかって、どれだけ早く正解に絞り込めるかを競うゲームだといってもいい。

むろん、このとき、他の班の質問と答えも利用していい。というか、利用しないと、競争に勝てない。しかもルールの二番目、「同じ質問を繰り返してはいけない」が厳然としてあるので、他の班の質問をちゃんと聞いていなかったら、失格になる可能性がかなり高くなる。

わたしはこれを、大学でプロジェクト・マネジメントを教える講義の中で、何度か演習に使ってみた。そして、非常に効果があるという実感を得ている。学生から毎回提出してもらう出席シートでの反応も、概して良い。ゲームとして面白いだけではない。何となく、コミュニケーションの勉強になったという実感があるのである。

「コミュニケーション」はプロジェクト・マネジメントの中核にあるスキルだ。そもそも『マネジメント』という言葉の中核的な原義は、「人に仕事をしてもらって目的を達すること」である。他の人を動かすのには、テレパシー能力でも持っていない限り、言葉にしてコミュニケートする必要がある。「言葉にして伝えること」は、マネジメントの第一歩なのだ。だから、PMBOK Guide(R)などでも、コミュニケーションは10個の知識エリアの一つに組み込まれている訳だ。

ちなみに、IT技術の分野でも、もっとも重要視されるスキルは「コミュニケーション」である。IPA(情報処理推進機構)のアンケート調査によると、IT企業と教育機関とが重視したい教育項目のトップは、ともにコミュニケーション能力だという(次表参照)

IT企業が重視してほしい教育 トップ5
(1) コミュニケーション能力 61.2%
(2) 問題解決能力 42.6%
(3) 文章力・文章作成能力 30.7%
(4) チームワーク・協調性 25.5%
(5) プログラミング技術 22.2%

教育機関が重視している教育 トップ5
(1) コミュニケーション能力 59.4%
(2) 問題解決能力 29.3%
(3) チームワーク・協調性 24.7%
(4) 文章力・文章作成能力 20.1%
(5) プログラミング技術 19.2%
 (情報処理推進機構 IT人材育成本部編「IT人材白書2013」p.41より抜粋して引用。マルチアンサーなので合計は100%を超える)

どちらも、「プログラミング技術」は第5位にすぎない点が面白い。コーディングの能力より、まず人と話し合える能力を、というわけだ。3位の「文章力・文章作成能力」も、コミュニケーション能力の一部だと考えれば、その重要性はもっと高いことになる。

(ついでながら、「プロジェクト・マネジメント」はIT企業側で7位・11.7%、教育機関側で11位・8.8%しか重視していない。どうやらPMの知識教育は、IT業界ではろくに期待されていないらしい)

なお、上の数字と、新卒採用時に重視する観点(同書 p.83)を比較すると、さらに面白い。

「新卒採用時に重視する観点」
(1) コミュニケーション能力 75.9%
(2) 主体性・積極性 63.7%
(3) チームワーク・協調性 40.1%
(4) 潜在能力・成長可能性 29.3%
(5) 社風との適合性 22.5%
(6) ITに関する技術力 22.3%

「ITに関する技術力」については、入社後習得・育成が可能であると考えられているためか、「コミュニケーション能力」等の資質的な項目よりも下位に位置づけられる結果となっている(p.83)。つまり、「コミュニケーション能力」、「主体性・積極性」、「チームワーク・協調性」などは入社後の習得・育成が可能でないと企業は考えているわけだ。

これほど期待されているにもかかわらず、わたし達の社会では、うまくコミュニケーションができない場面をしばしば見る。また、どうやったらコミュニケーションのスキルを高められるかについて、社会的な合意もないようだ。本来、学校教育の場では「国語」がその任に当たっているはずだ。だが、わたし自身の記憶を振り返っても、現国・古文・漢文の三教科を通して、自身の的確な意思疎通能力を鍛えられたという実感がない。なにか美的な、文学鑑賞能力を問われた記憶はある。漢字の書き取りもずいぶんやらされた(今やワープロを使っているのでほとんど忘れたが^^;)。だがリアルタイムの、切実な意思疎通を、上手にできる教育をうけたとは思えぬ。

コミュニケーションには大雑把にいって二種類のモードがある。おしゃべりモードと切実モードだ。おしゃべりモードは、対話自体が目的のようなもので、何かを伝達することは副次的である。ところが仕事上のコミュニケーションや、日常生活でもある種のコミュニケーションでは、「これをどうしても伝えたい」という切実モードが主体になる。伝達媒体は、対面の会話のこともあるだろうし、メールや、あるいは文書の場合もあろう。ただし文書やメールでうまく伝わらないときは、結局、対面での説明に持ち込まざるをえないから、結局、会話での伝達が一番ボトムラインになるのだ。

ところが、この対話的なコミュニケーションが、教えるのも学ぶのも、案外難しい。時間と手数がかかる上に、相手によって会話の筋道がかわり、再現性が低いから、一定の型を真似ればすむ訳にはいかない。ペーパーテストができないから、教室でのマスプロ的な教育カリキュラムにも乗りにくい。

対話的なコミュニケーションにおいて大事なのは、相手の話を聞きながら、同時に考えることである。聞くことと考えることが、同時にできなくてはならない。そして、相手が知っていることと自分が分かっていることのギャップを、常に意識する必要がある。説明とは、両者の間にある知識・認識のギャップを埋める行為だからだ。

このトレーニングのために、最初に述べた「Yes/Noゲーム」が有効なのである。このゲームにおいては、
→注意して聞く
→聞いたことを覚えておく
→同時に考える
の三つのことをリアルタイムに実行しなければいけない。しかも、勝つためには、それを数人の仲間と一緒にやらないといけないのだ。

もっとも、「Yes/Noゲーム」のルールを説明すると、そんな効率の悪いClosed Questionでは、いくら質問を重ねても、正解に到達するには際限もなく時間がかかるのではないか、と批判する学生があらわれる。だが、実際にやってみると分かるのだが、大学生レベルの知的能力をもっていれば、普通の出題ならだいたい20問以内に正解にたどり着く。Closed Questionという道具は、賢く使えば、かなり効率よく相手を追い込むことができるのだ。

そして、これができる人は、交渉が上手な人である。交渉(ネゴシエーション)こそ、プロマネに求められる能力の中でもトップクラスのものだろう。人を説得し、動かすことこそ、PMの仕事なのだから。そして交渉においては、きわどい局面ではOpen Questionは役立たない。価格交渉で「じゃあ結局いくらまで払っていただけますか?」などと問うても、相手がまともに答えてくれるはずはない。このとき、「でも、何か得るものがなければ、お互いに帰れませんよね?」「やはり納期よりも金額ですか?」「それって、たとえばベンツ1台より高いですかね?」・・といった風に、相手の刃を避けつつ、鎧の隙間を狙っていく能力が必要だ。むろん、笑顔や声色やボディランゲージも、巧みに取り入れながらだ。

こうした交渉の基礎的能力づくりとして、Yes/Noゲームは有用なのである。このゲームについては昔からなんとなく知っていたが、あらためて学んだのは、英語教育家として著名な故・中津燎子氏の著書(「英語と運命」)からだった。本来このゲームは子どもの教育用だが、わたしはあえて学生相手に試してみた。

試してみて驚くのは、ルールの二番目、「他と同じ質問を繰り返してはいけない」を破って失格になる者が、ときどき現れることだ。なぜか。他人の発言を、よく聞いていないのだ。上の空で聞き流して、自分の中だけで考えている。これでは良いコミュニケーションができるわけはない。そして、おかしなことに、こうした傾聴の態度・姿勢は、初等中等教育では、ちっとも訓練されていないのだ。つまらぬ教師の話を聞き流すのは、分からんでもない。だが、聞き流したら即、失敗となるゲームの場で、なぜ集中して聞かないのか。

「相手の話を聞いていない」人は、わたし達のビジネスの場でも、しばしば出会う。何を話しても、どうしても聞いてくれない。自分の側の論理だけを、一方的に繰り返す。その相手が権力があったり、顧客だったりしたら、もうお手上げに近い。だが、その相手だって、最終的には聞かないことで損をしているのだ。当然だろう。この世は取引と協力、ギブ・アンド・テイクでできている。テイクしかしない人と、誰がまともな関係を取り結ぶだろう? だれが本当の情報を奏上するだろう?

Communicationという英語は、本当は「伝達」という意味で、一方向にむかった動詞である。相手に着実に伝えること。これがCommunicationなのだ。そして、伝えるためには、逆説的なようだが、聞く耳を持たなければならない。日本ではなぜか「コミュニケーション」は双方的で、だからお互いに責任のない、ふわふわしたもののように理解されがちだ。それはおしゃべりモードの場合だけである。わたし達が何かマネージしたければ、切実モードのコミュニケーション・スキルを身につけるしかないのだ。


<関連エントリ>
 →「書評:『英語と運命』 中津燎子・著」(2014-06-08)
by Tomoichi_Sato | 2015-08-02 10:48 | ビジネス | Comments(0)