部品表と工程表

今年の初め頃だったが、ある集まりを手伝うことになった。中高校生くらいの若い子達が20人くらい集まるので、彼らに昼食を出す。わたしと連れ合いはその食事作りのお手伝い、という受け持ちになった。わたし以外は全員、年配の女性達だ。集会場所の横にはそれなりのキッチン設備があり、食器もそろっているので、そこに集合となった。前日までのメールでは、シチューを作ると聞いていたのだが、当日集まっていたら、なぜかメニューはカレーと野菜スープに変更になっていた。ともあれ、食材もそろって、さあ調理と言うことになった。

ところで、この調理の進め方がなかなか見物だった。わたしは男なので、食器洗いその他の力仕事に回り、実際の調理は女性達が受け持つ。皆、何十年と料理をしてこられた方ばかりだ。ただ、わたしも一応、料理の心得はあるので、どんなプロセスで進むかは理解している。まず材料を洗い、切り、大鍋に適時投入して、煮て味付けをする。そのかたわらご飯を炊いて、織機を用意する。それだけのことなのだが、現場は大騒ぎだった。

まず、この集団には、采配をふるうリーダーがいない。2、3人、それなりにリーダー格というか、まあ仕切り屋のタイプの人はいる。だが回りの人たちも黙っていない。みな、料理については一家言ある女性ばかりだ。だからどの材料をどれくらい使うか、どう切っていつ鍋に投入するか、味付けには何をどれくらい入れるか、まあ実に喧々がくがく、議論が続く。議論だけでなく、彼女たちはしゃべりながら実際に手が動き、勝手にやってしまう。もうどうなることやら、ホントに昼食時間までに間に合うのか、などハラハラして見ていたが、幸いというかカレーも野菜スープもなんとかそれなりに出来上がって、腹を空かせたティーンエイジャー達の胃袋にあっという間に飲み込まれた。

この集まりはまあ、ボランティア集団のようなものである。こういう集団では、会社のような上司・部下関係が無いし、指示=命令原理も働かない。誰か図抜けたリーダーがいればその人の判断と采配で、皆が一応動くだろう。だが、そういう人もいなかった。それでも何とかなったのは、女性達の調理のスキルもあるが、一つにはカレーとスープという料理が、材料にも味つけにもある程度幅があっても、まとまりやすい料理だったからだろう。

それにしても、同じこの仕事を、わたしの勤務先の同僚達がやったらどうなるだろう、と想像してみた。ボランティアの組織だ。賛同者が集まり、業務命令系統はとくにない。でも、きっと、自然にこうなるだろう:
(1) まず、料理は何を何人前作るか相談の上、決める。
(2) 必要な食材のリストを作る。食材の種類と、数量と。必要ならば、スペックつき(たとえば豚肉ならば「バラ肉」とか)で。
(3) 調理の手順のリストを作る。それに必要な調理器具もリスト化する。
(4) 食材調達の担当者を決めて、買い物を任せる。
(5) その間に、調理器具と食器の準備をする。必要な食器を集めて洗い、並べる。
(6) 食材が来たら、これも分担して洗い、カット、下ごしらえをする。
(7) 調理をする。この作業にはやはり、多少はスキルのある経験者をあてる。
(8) たぶん何人かで味見をして、OKとなれば盛りつけ、配膳作業をする。

たぶんこうしたことが、なかば自然に進むだろう。なぜなら、これはエンジ会社が普段やっている、エンジニアリングの仕事そのものだからだ。誰かがリーダー役を引き受けるだろう。あるいは長老が、誰か若手を指名してリーダー役にするかもしれない。皆、そのリーダーの采配と交通整理に従う。難しい問題が起きたら、皆で相談して解決する。それでも迷ったら、リーダーの責任で打ち手を決断する。これがたぶん、わたし達のスタイルだ。もちろん、調理の腕前は熟練の女性達にはかなうまい。でも、何とか必要なものを必要なタイミングに必要な量だけ、届けられると思う。

とくに大事なことは、最初に大まかな計画を立て、必要な材料や道具や手順のリストを作ること。これがないと、全体の仕事量も、作業の分担も、そして納期も見通せないからだ。

わたしの勤務先が特別だというつもりはない。たぶん大方の会社は、少なくとも製造業なら、こういう風に仕事を進めると思う。ものづくり企業に共通なDNAというのがあるとしたら、その一つは、最初にいろいろなリストを作ることにあるだろう。リストなんか作らなくても、あの女性達のように、ものは作れる。だが、仕事の見通しは、格段に落ちるだろう。

必要なリストは何だろうか? あるいは、もっと抽象化して問題を捉えるなら、生産という仕事に必須な基準情報は何なのか。

それは大きく、「もの」(=マテリアル)に関する情報と、「製造作業」に関する情報とに分かれる。「もの」に関する情報は、まず、どういう品目(材料・製品を含む)があって、それはどういった使用・属性を持つか、というリストになる。これは通常のIT用語で言うと『マテリアル・マスタ』(品目マスタ)と呼ばれる。ついで、ある製品は、どのような部品・材料から成っていて、どれだけの数量を要するのか、という製品構成に関する情報が必要だ。これが『部品表』(BOM = Bill of Material)データである。ただしBOMがマスタとしてITシステムの中に整備されているかどうかは、その企業・生産形態に依存する。

では、製造作業に関する情報はどうか。これはまず、製造に使う機械・設備の情報と、具体的な作業の情報に分かれる。前者は、機械リストとか、会社によっては作業区(ワークセンター)マスタと呼ばれる。もう少し進んだ形では設備構成マスタというデータ形式になる。設備構成マスタとなると、その中に階層構造が表現されて、たとえば作業区1の圧縮機Aには、補機として潤滑油ポンプA1がある、といった事情がわかるようになっている。つまり一種の、機械設備に関する部品表みたいなものである。かなり保守業務のレベルの高い企業では、こうしたマスタが必要とされる。

後者の、具体的な作業の情報については、特定の製品・品番ごとに、(通常は複数の)製造作業が生じる。つまり、各作業に必要な機械・設備は何で、その順序はどうで、各作業条件は何で、(もしあれば)マニュアルや作業標準はどれで、といった属性が並ぶ作業マスタがいる訳だ。これは基準情報である。ただし、個別の作業指示が出される場合は、それぞれの作業にIDをふり、これに着手・完了のタイミングを指定し、さらに必要な機械・設備などをアサインしたリストを作ることになる。これは、しばしば『工程表』と呼ばれる。英語でBOP(Bill of Process)と呼ぶこともある。

以上をまとめると、生産という仕事に関する基準情報は大きく4種類に分けられる:

マテリアルに関する情報
・マテリアルの属性情報 → マテリアル・マスタ(品目マスタ)
・マテリアルの構成情報 → 部品表(BOM)
製造方法に関する情報
・機械・設備の構成情報 → 作業区マスタ、ないし設備構成マスタ
・製造作業の属性情報  → 作業マスタ、あるいはその具体型としての工程表(BOP)

なお、ここで注意しておきたいことがある。それは「情報」と「データ」の区別だ。これについては以前、『ITって、何?』というシリーズで長々と述べたことがあるから詳しくは繰り返さないが、
・「情報」とは人間に意味をもたらすもので、基本的には不定形
・「データ」は定型化された記号の並びで、機械的処理に適する
という区別がある。今日はA社の業績ニュースが流れて株価が上がりました、が情報。各社の株価が定型化されて並んでいる株式欄が、データ。情報を定型化して機械で処理したり、データを読み取って人間に意味を提示するのが、IT(情報技術)である。上に述べた基準情報の例でいえば、人間は情報だけあればいい。ただ、量が増えたときには、紙に記録してリスト化したり、さらにコンピュータの中に収めてマスタ・データ化する方がベターだ。

もう一点。上の説明では、『工程』という言葉をあえて使わぬように説明した(「工程表」は別として)。これは、工程という用語が業種・会社によってかなりいろいろな意味に使われているためだ。大きく分けても、工程をプロセス=作業群の意味で使うケースと、ワークセンター=作業区の意味で使うケースがある。それらをごっちゃにしているケースだって、少なくない。工程表という用語だって、それなりにブレがある。

本当はこうした用語類は、わが国の生産管理の発展のためには、共通化した方が良い。しかし、抽象化・標準化への希求がかなり弱いわたし達の社会では、それぞれの業界や特定の大企業が勝手に作った方言を、グループや系列会社に押しつける例が、よく見受けられる。業界を横断して工場づくりの仕事をしている我々エンジニアリング会社にとっては、まことに不便な状況である。本来だったらアカデミアの学者が先導して、こうした状況を改善すべきなのだろうが、あいにくその動きも薄い。

そこでわたしは、せめてこのサイト内では整合性のある用語を使うように心がけており、とくに多義語である「工程」は極力使わないようにしている次第だ。かわりに、わたしは製造業務のプロセスを呼ぶときは『工順』(英語でRouting)と呼ぶようにしている。わたしの考える製造という仕事のプロセスの構造を、図に示すと次のようになる。
e0058447_12531915.jpg
図 製造という仕事のプロセスの構造

もっとも「工順」という言葉だって、作業の集合を指す場合と、単に一連作業の中の連番(数字)だけを指す場合があるから、曖昧性は残るのだが、「工程」よりは誤解が少ないだろうと考えて、こうしている。

なお、図の中には「リソース」(Resource=製造資源)という言葉が出てくる。これは、作業の間は占有するが、作業した後でも別の作業に再利用できるようなものを指す用語だ。具体的には、作業する人・機械設備・治工具・金型などが含まれる。つまり、機械とか作業者とかよりも、1レベル抽象度を上げた用語である。このリソースのリストのことを、「資源表」(BOR = Bill of Resource)と呼ぶこともある。

かくして、製造業には、大きく言っても4〜5種類の基準情報が必要であり、それをきちんと整備・保守していく仕事が生じることになる。こうした仕事は全て、「間接業務」=直接お金を生まない仕事である。だから、しばしば日陰の仕事、縁の下の力持ち的な業務とみなされ、不況の時は優先度が下げられたりもする。そして、そういう態度自体が、生産性の低下をもたらし、さらに不況を加速するというダウン・スパイラルが生じる。これは、企業の持つ思考と行動の習慣=OSがバグっている状態だ。

なぜ企業には基準情報が必要なのか? それは、情報・データを再利用可能な状態に保つためだ。さらにいえば、仕事を予見・計画可能な状態に保つために必要なのである。冒頭に紹介したように、たまに集まるおばさま達の集団なら、基準情報など無くても、なんとか料理はできる。いや、それこそ、「ちょっとカレーの味が薄いみたいだから、ここにある和風だしを入れちゃいましょ。」などという、臨機応変な小技(大技?)を繰り出すことだって、できたりする。だが、これを仕事にして食堂を開くなら、もう一歩上を目指す必要がある。きちんと計画できて、繰り返し可能な仕事の状態にするべきなのだ。部品表と工程表は、そのための武器なのである。


(本記事を書くきっかけとなったのは、OpenLearning(https://open.netlearning.co.jp)が提供する「応用情報学」講義シリーズの中の、京都情報大学院・上田治文教授による「企業経営の情報学」Wee 2・Lesson 3「工場のIT化の核 部品表のコンセプト」を見たことである。わたしの用語・見解とはいろいろ異なっているが、4種類のマスタの整理など、いろいろと学ぶべき良いヒントをいただいたことを記しておきたい)






# by Tomoichi_Sato | 2017-03-22 12:56 | サプライチェーン | Comments(0)

「理屈を言うな」という理屈

15歳の時の4月。高校の入学式を終えたわたし達・新入生は、各クラスでの挨拶と簡単な自己紹介のあと、体育館に集められた。「オリエンテーション」という行事があると言うことだった。どういう行事かの説明はなかった。

新入生ばかり400人あまりが集められた後、体育館の扉が閉められたが、中には先生達の姿はなかった。壇上には学ランを着た屈強な上級生達が十何人か立って、両手を後ろに組み、胸を反らして立って、わたし達新入生をにらみつけた。どうやら『応援団』という存在らしかった。その中の団長格とおぼしき人が壇上の中央に立って、上半身を腰から前にかがめ、わたし達に向かって、かすれた声で

「ウース」

という声を発した。いや、正確には文字化が難しいのだが、とにかく強引に文字にすると、そういう音声だ。何事か、と驚いてきょとんとしているわたし達に向かって、壇上の、そして左右通路の応援団員達が、わたし達に口々に「返事はどうした!」「声が出てない!!」と大声で怒鳴りつけはじめた。どうやら壇上の人は「押忍(オス)!」とわたし達に呼びかけているのであり、わたし達はそれに対し、同じく「オス!」と大声で答えなければいけないのだ、という理屈が飲み込めるまで、たぶん10分くらい混乱の時間があった。

わたし達がようやく「オス」と声を揃えて返事することができるようになると、今度は校歌斉唱を命じられた。何人か固まって座っているブロックが指名され、校歌の一節ずつを歌え、というのだ。伴奏は応援団の大太鼓だけ。校歌と言っても、わたし達には簡単な歌詞のプリントが、入学手続きのときに、手続き書類の束と一緒に、渡されていただけだった。当然誰も歌えないし、覚えてもいない。無体な要求である。

だが立たされたものの口もきけずに黙っている新入生達に対し、応援団員は怒鳴った。「オリエンテーションまでに覚えろと書いてあったはずだ!」 たしかに配られたその紙をもう一度よく見ると、「オリエンテーションで校歌斉唱の練習をするので、その時までに覚えてくるよう、諸君と約束しておく」と書いてある。だが志望校合格に浮かれている新入生で、そんなものをまともに受け取った者はほとんどいなかった。

応援団員は恩着せがましく、では、一節ずつ我々が歌って示すから、お前たちはそれを復唱して繰り返せ、と指示した。かくて順繰りに新入生達は立たせられ、数節ずつ歌わされた。声が小さかったり、歌詞を間違えたりすると大声で叱られ、良しとされるまで、何度も何度も繰り返させられた。その間、回りの生徒がよそ見をしたり上の空だったりすると、すぐに通路の団員がとんでくる。体育館の扉は閉められ、出口にも守りを固めるように団員が立っている。実際に暴力がふるわれた訳ではないが、ほとんど脅迫的な雰囲気である。このような拷問に近い時間を、あとどれくらい過ごさなければいけないのだろうと、わたし達は思った。

ところで、あるブロックにさしかかって、うまく歌えないといって叱られた中の一人が、勇敢にも壇上の応援団員に向かって、必死の声を上げた。「たしかにプリントには『諸君と約束しておく』と書いてありますけれど、僕たちはとくに約束した訳ではありません。」 こうした火に油を注ぐような口答えに、応援団はどう反応するだろうかと固唾をのんだ。はたして、壇上にいる団長格の人は怒って、

理屈を言うな!

と一喝した。全員がしんとなる。そのとき、横に立っていた、もっと小柄で温和そうな人が彼を手で制して、言った(後で知ったが、実はこの人が団長なのだった)。

「たしかに理屈だ。だが、入学したら校歌を覚えるのは当然ではないか。君たちには春休みの長い期間があったはずだ。そんなに大変なことを、君たちに要求した覚えはないし、君たちから『約束できません』と言われた覚えもない。」

こう言われると、誰も反論できない。結局、オリエンテーションは2時間ほど続き、わたし達は校歌の1番はなんとか全員で歌えるようになった。だが校歌は全部で3番まである。明日もまた放課後にオリエンテーションの続きがあるのだ。わたし達はくたくたの心と体を抱えて、家路についた。

それにしても、理屈を言うな、という世界があるのか・・。帰り道、わたしは思った。本サイトの読者はお分かりと思うが、わたしは理屈っぽい人間である。だがわたしの高校は男子校だった。進学校ではあるが、古い高校で、バンカラの気質も残っていた。男社会で、しかも上級生下級生のタテ型序列の強い世界では、理屈を言うな、というセリフが通ってしまうんだ。理が通っても、力でねじ曲げられてしまう場所があるのだ。15歳のわたしは、このとき大きな教訓を得たと思う。

前回、「設計の『なぜ』を考える」で、わたし達は「なぜ」を問いかけたり答えたりするのがヘタだ、と書いた。だが、そもそもわたし達は、議論という行為自体が下手だ。そして、それは文化に多少根ざしたものだと、わたしは思う。理屈を言うな、は普通のノーマルな日本語である。賛成するにせよしないにせよ、意味するとことは誰にも通じる。だが、このセリフを外国語で言えるだろうか? とても難しいと思う。英語なら、”Don’t tell me your reasoning."といった感じだろうか。だが、あまりしっくりこない。イタリア語やロシア語で、これに類する言い方は可能なのか。アラビア語で、あるいはヒンディー語ならどうか。もしかしたら中国語や韓国語なら、似た言い方はあるのかもしれないが。

もちろん、どこの国に行っても、無体な要求、非道な連中は存在する。ただ西洋や中洋のように文化の根底が理屈っぽい社会では、そういう連中でも、自分たちが道理を蹂躙している、という自意識はあるのではないか。意識してやるのと、無意識にやるのでは、大きな違いがある。

理屈を言うな、というセリフは、どんなときに発せられるのか。それは、自分たちが共有している意思や熱情や気分に、水を差すな、という時ではないかと、わたしは考える。場を壊すな、といいかえてもいい。というのは、理屈というのは、自分と対象とを引き離すはたらきがあるからだ。『客観化』と呼んでもいい。自分と対象、自分と相手がほとんど一体化しているときには、理屈は無用で、入り込むスキマはない。たとえば恋愛に理屈はない。あるいはスポーツや勝負事で皆が一丸となっているとき、その行為の中に理屈を持ち出すのはヤボだ。そしてもちろん、上下関係の中にも。

理屈、つまり道理というのは、誰に対しても通用する。つまり公平である。万人に公平に与えられているのが、論理だ。こういうものは、上下関係の中の対話には、いささか邪魔なのだ。たとえば男子校の運動部のような場所では。あるいは一般に、タテ社会の中では。わたし達の社会における運動部(体育会)というのは、ある種、軍隊の中の人間関係を再現、ないし予習するための場所である。そこでは論理より熱情が優先される。

そして身分や立場の上下がある間柄には、議論はふつう成立しない。議論は一応、「対等」な間で行うものだからだ。

では、そもそも「議論」とはどのようなものだろうか。わたし達エンジニアが仕事の上で議論するとき、それはどのようなプロセスをとっているか、考えたことがあるだろうか? わたしの理解では、(少なくとも西洋社会では)議論は以下のようなプロセスを経る:

(1) まず参加者の共通の前提や目的を確認する。
(2) 議論の対象となる事実について、客観的・多面的に検討する。
(3) 問題となっていることや対策に関し、相互の意見を出し合う。
(4) 互いの視点や意見を組み合わせて発展させる。
 (ここで揉めたら、(1)や(2)に立ち戻って考え直す)
(5) 合意点を見つける。

つまり議論というのは一種の共同作業であり、一緒になにか建物を建てるような仕事なのである。まず(1)で共通の地盤を固める(ここが無いとそもそも議論にならない)。ついで(2)で、議論という建物の土台をつくる。事実というのはたいてい多面的で、見る人の視点によって見え方が異なる。だからここの部分は念入りに進める必要がある。そして、どちら側も「この上に建てて大丈夫」という風な認識を得るべく、客観的にものごとを記述することをつとめる。そして、このステップには自分の熱情や思い込みを持ち込めない。この『客観化』こそが、対象と自分を切りはなすような、“水くさい”部分なのだ。

その先も一応、順番に意見を応酬し合う、一種の共同作業である。互いにブロックを積み上げ合うような行為だ。そして互いに合意できる結論にたどり着く。それは建物の最上階に見晴台を築くのに似ている。これが議論のプロセス、あり方である。

だから、こうした議論では、基本的に「勝ち負け」がない。対等な立場同士の、共同作業だからだ。また通常の個人間の議論のみならず、学問上の論証も、ビジネスの交渉も、いや刑事裁判でさえ、こうした枠組みの中の『議論』の一種である、というのが西洋風のとらえ方だ。

まあ、議論に勝った負けたはないと言っても、もちろん人間だから、それぞれ途中や結果に対して不満もあり得よう。優位に立った方が、勝ち誇るような態度をとることもある。だが、原則として、議論は勝負ではない(和解に至らぬ民事訴訟やディベートという一種のスポーツは別として)。そしてもちろん、議論とは、どちらが頭がいいかの優劣を決める場でもなければ、言葉による喧嘩や暴力(口げんか)でもない。

こういう認識が文化(OS)の中で共有されていないと、意味のある議論ができなくなる。とくに、議論は口げんかではない、ということは早くから子ども達に教える必要がある。また、自分の意見に意固地にこだわらず、議論を通じて、オープンに変えていけるような態度を身につけさせなければいけない。

そして、議論とは広い意味で「学び」の一部である。なぜなら、「学び」とは考え方や知識や意見の変更をもたらすものであり、議論とはまさにそうした結果を生むためにするものだからだ。議論がきちんとできない組織では、認識も深まらないし、学びも行われない。そうした組織では、きっと同じような思い込みが受け継がれ、同じようなミスが繰り返されるだろう。

人間集団はいろいろな形で、不可避的に「上下関係」「優劣の順位」を作りたがる。それは一種、本能の一部なのだろうし、組織に一定の規律や効率をもたらすといってもいい。ただ、上の意見が下に対して絶対で、「理屈を言うな」という言葉で上下間での対等な議論を抑制してしまうと、組織は硬直化していく。理屈を含む議論はその解毒剤なのだ。少なくともわたしは、そう信じている。

私の高校が今でもあんなオリエンテーションという行事をやっているのかは知らない。たぶん、あんな野蛮なやり方は、今の時勢に合わないだろう。だが、15歳の記憶力はたしかに絶大だった。同窓会で集まると、いい歳したおっさん達が声を揃えて、今でも「こーしゃの、いーしずえ、動きなき〜」と校歌を歌うことができる。それと同時に、わたしはあの「理屈を言うな」という一言を忘れていない。あの一言はわたしに、偉大な教訓を与えてくれた。それは逆説的な仕方でわたしに、道理というものが弱い立場の者をまもる武器にもなりうるのだと、教えてくれたのだ。


<関連エントリ>
 →「設計の『なぜ』を考える」http://brevis.exblog.jp/25540003/ (2017-03-07)


# by Tomoichi_Sato | 2017-03-13 22:16 | 考えるヒント | Comments(3)

設計の「なぜ」を考える

まだ駆け出しだった頃、工場改善コンサルタントの話を聞いたことがある。それなりに面白い話がいろいろあったが、1番よく覚えているのはヘアドライヤーの話だった。このコンサルタントは、製造業、とくに電気系メーカーの設計部門を訪れた際は、必ずヘアドライヤーの冷風スイッチについて、尋ねることにしていると言っていた。

「ヘアドライヤーには、温風のスイッチのほかに、必ず冷風のスイッチがありますよね。御社の製品にも、ついていると思います。ではこの冷風のスイッチは、何のためにあるんですか?」

皆を集めてこう質問すると、たいてい誰も答えない。日本の会社は、皆そうだ。でも繰り返して尋ねると、中には元気のいい若手社員が手を上げて、こう答えたりする。

「はい。それは、あの、夏なんかの暑いときは、冷風で頭を乾かしたほうが気持ちいいからです。」

するとコンサルタント氏は続けて聞き返すのだそうだ。「それは本当ですか? じゃぁ、夏に冷風で頭を乾かしている人、手を上げてください。」実際には、手をあげる人はほとんどいない。そこで彼はとどめの一言を放つ。

「アメリカのメーカーに行ったら、こういう答えが返ってくるんです。『髪の毛は熱風を当てると柔らかくなるが、冷やすと硬くなる性質があるので、スタイリングをするときには最初は温風を当て形を作り、最後に冷風スイッチを使って固めるのです。』・・ところが皆さんはそれを作っているのに、なぜそれがあるかを知らない。」

アメリカの技術や製品を日本に持ってきたときに、何も考えずに形だけ真似するから、こういうことになる。何のためにあるんだか理解しないまま、機能をつけてしまう。そのためムダに設計も検査もコストが上がる。・・コンサルタント氏は私たちに、そう教訓を述べた。

もう一つ彼は例をあげた。「どこの工場に行ってもスパナって言う工具がある。知ってるでしょう? ところでこのスパナって、なんだか妙に握りが太くて持ちにくいじゃないですか。だから職場によっては工夫して、わざわざ細い棒を持ち手側に縛り付けて、持ちやすくしている」(彼は黒板に図を描いた)。「でも、なんでこんなことしなくちゃいけないんです?」——無論、わたし達は答えられない。

「それはね、最初にスパナをアメリカから持ち込んできた人間が、そのままのサイズで複製したんですよ。だからアメリカ人のデカい手に合わせた握りになってる。考えないでただ真似したんじゃ、工夫にならない。」

このコンサルタントの言うことがどこまで正確なのか、私はよく知らない。でもその時の私の頭には、『直輸入技術』の弱さ、脆さが刻み込まれた。それは「技術導入は麻薬のようなものだ」といっていた大先輩の言葉を思い起こさせた。外国からの技術導入は、最初は楽だが、次第に自分で考え、開発する力をなくしてしまう。

わたしはエンジニアである。最近はもう自分で設計する事はほとんどなくなってしまったが、それでもエンジニアだと思っている。なにか設計したら、結果は図面や仕様書に落とし込む。その結果が下流側部門のインプットとなって、関連する設計や調達や製造に使われる。それがエンジニアの仕事だ。

だが、エンジニアとして先輩の仕事に学び、自分の成長の糧とするときには、それだけでは足りない。設計の結果だけではなく、考えと仮説を学ぶ必要がある。先のコンサルタント氏による、冷風スイッチのエピソードは、そのことを示している。「技術を伝える」とは、結果としての形だけを教えるのでは不十分なのだ。「なぜ」そうなのかが大切だ。ノウハウ(Know How)より、ノウホワイ(Know Why)が大事だと、わたしの勤務先のトップマネジメントも、よく口にしている。

だから設計をするときには、設計の理由を記した設計ノートやメモやコメントを、なるべく作って残すようにしましょう。

・・というだけでは、実は話はまだ終わらないのだ。

なぜなら、わたし達は「なぜ」を問うたり、「なぜ」と問われたりするのに、文化的に不慣れだからだ。そうでなければ、どうして、誰かが大勢に理由の問いかけをしたとき、皆、遠慮したかのように答えないのか。間違っていても、推理を述べればいいではないか。間違いだったら、そこで学べばいい。別に命を取られる訳でもない。それなのに、「間違った答えをいうと恥ずかしい」という気持ちが先に働くから、誰も人前では答えなくなる。あとで廊下で講師をつかまえて、小声で確かめたりする。それで知識を共有できるだろうか。知らないことの方がもっと恥ずかしいはずなのに、皆が知らなければ、怖くないのだ。

「なぜ」の問答に不慣れなわたし達が陥りやすい「なぜの罠」は、何種類か考えられる。

説明1 「そういう慣習だから、昔からそうだから」
 よくある答え方である。上の冷風スイッチと同じだ。これでは理由を説明していることにはならない。

説明2 「目的はこうだから、機能はこうだから」
 なぜ冷風スイッチがあるのですか? それは、冷風を送れるようにするためです・・これは、質問のたんなる言いかえに過ぎない。その機能の目的が、使用者にとってどんな時どのような意義や利便を提供するか、の答えになっていない。答えのはるか手前で止まっているのに、なんだか答えたような気になっているだけである。

説明3 「それはこういう仕組みなんです」「こういう経緯でそうしました」
 ここのボタンを押すと裏で自動的にこのモーターが作動して・・とか、その機能はもともと別の形で実装する予定だったんですが経緯があって・・とか、詳しい説明が続く。だが、それは単に詳細化して説明するだけで、WhyではなくWhat, Howを述べているだけだったりする。こういう答えもありがちである。

説明4 「顧客が(誰かが)決めたから」
 いやあ、お客さんが(あるいは先輩が、他部署が)そうしろと言ったんですよ・・こういう答え方は、WhyではなくWhoを述べている訳だ。言われたことは忠実にやる。しかし言われないと自分では意見やスタンスがない。これは、受注型ビジネスにたずさわるエンジニアに広く見られる傾向ではないか。すなわち、設計へのオーナーシップの喪失である。本当は、これがけっこう深刻な問題だという気がする。

説明5 「自分のセンスで決めました」
 この自信に満ちた答え方は、言い方を変えると「なんとなく決めました」と同じである。設計者のセンスはもちろん、大事だ。設計という仕事は一種のアート(技芸)としての側面があり、設計者の感性を磨くことは訓練の一部と言っていい。センスがあまりにもない人は、ちょっとその仕事に向いていないな、と判断される場合もある。
 だが、感性に頼りすぎる仕事ぶりは、他者にうまく説明できないし、理解もしてもらえない。エンジニアは感性と理性のバランスが大切なのだ。そして、スティーブ・ジョブズ級の感性の持ち主ならともかく、普通クラスの会社員に「俺の感性を信じろ」と言われても、当惑するだけだろう。
結局、こうした罠に陥りやすいのは、設計という仕事において、「なぜ」をあまり問わず、考えない習慣にあると言えないだろうか。

いや! そんなことはない。我々は「設計レビュー」を要所要所で実施していて、そこできちんとチェックしているのだ、とおっしゃる論者もあろう。なるほど。それは素晴らしい。きっとそうした組織では、設計レビューの基準が(それもレビューの方法・手順や体制ではなく、基準が)明確なのだろう。

だが、設計レビューという行為は、しばしば設計書の記述ルールや整合性チェックにとどまる場合が多くないだろうか? つまり、IT分野の例を出せば、設計の「なぜ」を問う代わりに、以下のような項目の確認に時間を費やすのである。
・ネーミングルール
・エンティティ(要素)の洗い出し
・要素間のリレーション
・記述法とフォーマット
・図面間の整合性
・入出力の検証可能性
これはこれで、結構だ。だがこうしたレビューをいくら重ねたって、「いらない機能」「非効率な構造」をあぶり出すのに役に立つだろうか?

かくして、『機能しないレビュー会議』という問題が生じるわけだ(その証拠に、ネットで検索するといろんな関連記事が出てくる)。設計レビューを本当に機能させたければ、きちんと「なぜ」を問いかけ、まともに「なぜ」を答える習慣づけの必要がある。

そもそも、設計のアウトプットが、単なる工学計算の結果ならば、わざわざ誰も「なぜ」を問うことはしない。「この熱交換器の伝熱面積はどう計算したの?」「HTRIの推算式を使いました」「あっそう。」それだけの話だ。そこにはHowはあるがWhyはない。Whyが登場するのは、「この流体は一部が熱で気化して混相になるはずなのに、なぜ液相の伝熱計算式を使ったの?」というような、『判断』が登場する場合だ。

そして、設計業務の一番の肝は、判断(design decision)にある。設計のdecisionとは、本質的にトレードオフ間の決断である。われわれがなにかの設計時に直面するのは、
・安定性と俊敏性
・冗長性と効率性(燃費)
・頑健性と軽量性
・複雑性と保守性
・オマケ機能と製作工数
・品質とコスト・・
といった、「あちらを立てるとこちらが立たず」風の状況下において、どのようなバランスをとるかという決断なのである。そして、決めるためには、なんらかの仮説や推測が要る。「なぜ」の問いは、まさに、設計者の仮説を言語化するためにあるのだ。

設計という行為の中核がこのようなトレードオフの判断である以上、わたしは人工知能(AI)が将来、自動設計をしてくれてエンジニアの職をどんどん駆逐する、などという想像には組みし得ない。AIどんなに発達しても、機械だけでは決して設計問題を自動的には決められないだろう。

なぜなら、それは仮説設定と価値判断だからである。

設計の結論だけでなく、思考のプロセスと判断基準を示すこと。それがエンジニアの仕事であり誇りであってほしいと、わたしは思う。このことは、以前紹介したように、人に説明するとき「なぜ」からはじめるべき(Start with Why)という金言とも一致している。だから、「なぜ」にもっと真剣に向き合おう。

<関連エントリ>
 →「『なぜ』からはじめよう - 仕事の目的を設定する」 http://brevis.exblog.jp/24334345/ (2016-04-18)

# by Tomoichi_Sato | 2017-03-07 22:01 | Comments(0)

プロジェクト&プログラム・アナリシス研究部会」(3月28日)開催のお知らせ: 満員になりました

(大変恐縮ですが、下記の研究部会は大勢の方から参加申込みがあり、満員となりました。なお、予約なしに当日の参加はできませんので、ご了承ください)


「プロジェクト&プログラム・アナリシス研究部会」2017年の第2回会合を、下記の要領にて開催いたします。

今回は、JAXA・宇宙航空研究開発機構のチーフエンジニア室長である岩田隆敬氏をお招きして、JAXAのプロジェクトマネジメントについてご講演いただきます。

ご承知の通りJAXAは日本の宇宙開発の中心団体です。「はやぶさ」の例を見れば分かるとおり、宇宙開発は技術的難易度の点でも、また天体条件その他の環境制約の厳しさの点でも、チャレンジングな仕事の極致といえるでしょう。その難しさを克服するため、米国のNASAは1960年代以降、アポロ計画という「プログラム」、その下の個別ロケット・ミッションの「プロジェクト」という概念の元、さまざまな管理技術を開発しました。宇宙開発分野は、いわばモダンPMの育ての親なのです。

日本版のNASAともいえるJAXAもまた、我が国のプロジェクト・マネジメントの頂点の姿を示すと言っても過言ではありません。トップクラスのプロジェクト遂行はどのようなものか、興味深い話が聞けると思います。年度末のお忙しい時期とは思いますが、ぜひご期待ください。


<記>
■日時:2017年3月28日(火) 18:30~20:30
■場所:研究室棟B会議室(研究室棟1階)※定員:36名
 ※キャンパスマップの【10】
  (いつもの建物とは別ですのでご注意ください)

■講演タイトル:「宇宙航空研究開発機構(JAXA)のプロジェクトマネジメント

■概要:
人工衛星やロケットのような宇宙システムは、大規模かつ複雑、高価で、新規開発要素が多い上に、極限環境を飛行することを特徴とする。世界の宇宙機関の事業の大部分は、こうした宇宙システムの開発を中心に据えたプロジェクトで構成されており、宇宙機関は、プロジェクトを確実に遂行するために、開発の段階的実施、フェーズ移行審査、文書によるベースラインの明確化等といった共通のマネジメントを取り入れている。本講演では、宇宙航空研究開発機構の例を取り上げて、プロジェクトマネジメント推進の背景や、体制・仕組み、開発プロセス、審査、進捗確認、計画変更、スコープ設定、人材要件・育成、知識蓄積・継承などについて、紹介する。

■講師: 宇宙航空研究開発機構(JAXA) チーフエンジニア室長 岩田隆敬様
■講師略歴:
岩田隆敬(いわたたかのり)
・東京大学航空学科宇宙工学コース卒業、同大学院航空学専攻工学修士
・米国Stanford大学大学院航空宇宙学科M.S.(Master of Science)、
  Ph.D.(Doctor of Philosophy、主専攻:航空宇宙工学、副専攻:電気工学)
・宇宙開発事業団(現、宇宙航空研究開発機構(JAXA))入社
 ・陸域観測技術衛星(ALOS、「だいち」)プロジェクト
   高精度な姿勢軌道制御系、恒星センサ、GPS受信機や、大型の太陽電池パドル
   系、及び、地上の高精度指向決定システムの開発から運用までを主担当
 ・研究開発本部誘導・制御グループ長
   誘導・制御技術の研究開発とプロジェクト連携を指揮
   恒星センサ、GPS受信機や、GCOM-W1、ALOS-2、SPICAの姿勢軌道制御系
   開発を担当
 ・統合追跡ネットワーク技術部参与・計画マネージャ
   衛星の追跡管制の統括、予算要求、将来計画を担当
 ・現在、チーフエンジニア室室長
   プロジェクトの独立評価、PM/SEの体制・ルール/標準の維持・推進、研究開発
   マネジメントの推進を担当
・専門: 航空宇宙工学(特に、航法・誘導・制御・ダイナミクス)
・PMP

■参加費用:無料。 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金\2,000が免除されます。

会場の人数に上限があるため、参加を希望される方は、できましたら前日までに三好副幹事までご連絡ください。


以上、よろしくお願いいたします。
佐藤知一@日揮(株)

# by Tomoichi_Sato | 2017-03-03 23:56 | プロジェクト・マネジメント | Comments(0)

書評:「スティル・ライフ」 池澤夏樹・著

スティル・ライフ」 池澤夏樹・著 中公文庫(Amazon)


「この世界がきみのために存在すると思ってはいけない。世界はきみを入れる容器ではない。
 世界ときみは、二本の木が並んで立つように、どちらも寄りかかることなく、それぞれまっすぐに立っている。」

この不思議な小説は、こんな風にはじまる。『スティル・ライフ』というタイトル、そして冒頭の文章の主語の選び方とセンテンスの結び方、抽象的な叙述の仕方などから、この作者はよけいな湿り気のない、透明度の高い文体で物語をつむごうとしていることを、読者はまず感じる。

続く最初のシーンでは、バーの高い椅子に座る「ぼく」と友人の、静かな対話が描かれる。その友人は、水のグラスをじっと見ている。何を見ているのかとたずねる「ぼく」に対して、彼は、ひょっとしてチェレンコフ光が見えないかと思って、と答える。宇宙から振ってくる微粒子が、グラスの水の原子核と衝突すると、かすかな光が出る。それを待って、というのだ(これはスーパーカミオカンデの観測原理だが、この小説発表当時はまだ存在していなかった)。

わたしは池澤夏樹という作家について、ほとんど何も知らぬままこの小説を買って読み始めたのだが、どうやら理科系的な資質の人らしいと、この辺で感じる。たしかに本の見返りの作者紹介には、北海道で生まれ、国立大学の物理学科を中退した、とある。もちろん、理系文系の区別など、便宜的なものでしかない。東工大を出た吉本隆明より、青山学院の英文を出た姫野カオルコの方が、よほど非情緒的でクラリティの高い文章を書く。でも、どうやらこの小説は理系読者に好ましい、何か不思議な魅力を持っている。

主人公の「ぼく」と、友人の佐々井は、ともに染色工場で働いていて知り合いになった。工場で働く主人公というのも、今どき珍しい。色番号を指定して糸を染める工場の工程を、作者は「ロットサイズ」などの言葉を使いながら淡々と、正確に記述する。その仕事で何がカギになるのか、何に人々は悩むのかを、手短な文章とエピソードから描いていく筆致は、なかなか達者だ。

「染色なんて、分子と分子が勝手にくっつくのに、人は少々手を貸しているだけなんだ。」——人には手の触れられない領域がある。人が全てをコントロールすることはできない。この小説には、分子とか星とか、他の小説には滅多に出てこないような単語がときおり登場して、主人公や読者たちの視線を、ふいに遙か遠い所へと誘う。『遠い視線』、これこそが池澤夏樹の小説の魅力だろう。

物語はその後、佐々井の提案によって意外な方向に展開していく。それは、ふつうなら欲望とスリルにあふれた、波乱含みのストーリーになるはずの話だ。だが、遠い視線から語るこの小説では、どこか淡々と、ひどく静かにことが運んでいく。そう、まるでタイトルの示す「静物」のように。

「大事なのは、山脈や、人や、染色工場や、セミ時雨などからなる外の世界と、きみの中にある広い世界との間に連絡をつけること、一歩の距離をおいて並び立つ二つの世界の呼応と調和をはかることだ。
 たとえば、星を見るとかして。」

冒頭の文章に続くこの段落こそ、透明な叙情性に満ちた本作品の方向性を決定づける道しるべ、記念碑なのだろう。その後、同じ作者のエッセイも少し読んでみたが、やや理屈っぽく生硬な部分があって、必ずしも読みやすいとは感じられなかった。だが、この作品は本当に素晴らしい。端正で静謐な、若い文学としての美しさに満ちている。本作品は1988年の中央公論新人賞と芥川賞を受賞した。



# by Tomoichi_Sato | 2017-02-25 16:56 | 書評 | Comments(0)

Pushで教育し、Pullで成長する

子どもがまだ小さかった頃、よく「きかんしゃトーマス」を一緒に見た。このイギリス製の人形劇は、どうやら英国社会を引き写しているらしく、階級制になっている。機関車はおおむね真面目で勤勉だが、彼らに引かれて走る客車はいつも適当な連中で、機会があればサボることを考え、しょっちゅう脱線事故などの面倒を引き起こす。つまり機関車(Engine)は、技術者(Engineer)のような中産階級を連想させ、客車はすぐにストやサボタージュをする労働者階級を思わせる、という具合だ。
あるとき主人公のトーマスが、例によって客車にトラブルを起こされ、手を焼いていた。すると、となりの線路をゴードンという機関車がちらとトーマスを横目で見て、「人生は勉強だな」といって通り過ぎるシーンがあった。きかんしゃゴードンは中年男を思わせる横柄なキャラなのだが、この台詞はなぜかぴったりと役にはまっており、見ていたわたしと連れ合いはその後しばしば、小さなトラブルに遭遇するたびに「人生は勉強だな」と言い合って笑ったりした。

人はいくつになっても成長できる。逆に言えば、人は一生、学び続けなければならない。ゴードンの名台詞はこのことを表している。ところで、英国のコンサルタントであるMarcus Buckinghamの説によると、人間の学習スタイルには、「分析型」、「行動型」、「観察型」の三つのタイプがあるのだそうだ。それによると、
・分析型は事前の学習時間を十分とる
・行動型は早く未経験の環境に置く
・観察型は手本になるベテランの傍らで、仕事を俯瞰的に見ながら模倣させる
というのが、それぞれOJTのやり方としてふさわしいらしい。このことは、稲山文孝氏の「アプリ開発チームのためのプロジェクトマネジメント」http://brevis.exblog.jp/24117407/ という本で読んだ。

なるほど、とは思ったものの、上記の3タイプはあくまで英米人の類型かな、とも感じる。わたし達の社会なら、このほかに「感情型」だとか「競争型」とかを付け加えたくなる。感情型は好きな人を手本にして感性や情に訴えて学ばせる、「競争型」は試験を課して成績で競わせる、と言う具合だ。

まあ人間の類型論は医学・心理学から社会学まで、いろいろなバリエーションがある。だが、学びという点で見ると、大きく「受動型」と「能動型」に二分できるのではないかと、よく感じる。というのは、この区分は、育成・訓練におけるマニュアル整備の是非の論議に、しばしば登場するからだ。マニュアル論議といういうのは、仕事について伝えるべき一切合切、なるべくすべてをマニュアル化すべきか、という論争である。いや、親切すぎると相手の「学び」が働かなくなるのでは、という疑念や、緊急時対応はどこまでマニュアル化できるか、といった疑問もこれに近い。マニュアルがないと対応能力が下がる。しかし、あまりすべてをマニュアル化すると、今度は「想定外」に対応できなくなるパラドックスが生じる。

こういう議論では、どうも意見に世代間ギャップがあるな、とわたしは感じている。おじさん世代(わたし自身を含む)にとって、知識は稀少資源だった。わたしが社会人になった頃は、パソコンというものすら存在していなかった(きっと日本昔話みたいに聞こえるだろうなあ)。知識はほぼ全て、紙の中にあった。そして、知識情報は自分の個人的資産として「囲い込む」(机の中にしまっておく)ものだった。人が知らないことを知っているのが、自分の優位性だ——そういう感覚が強かった。

その時代、「技術は盗むもの」と信じられていた。教えすぎてはいけない、と。教えなくても優秀な人は、自然に身につけるものだ。何より、生まれつきのセンスが一番大事で、あとは「やる気」、気持ちの問題だ。つまり、自分から知識を取りに行く(Pull型)の態度が主流だったのだ。

ところで、このような態度は時代とともにかわっていく。若い世代(定義は難しいがバブル時代以降か)にとって、知識は世界に氾濫しているものだ。知識はネットでふんだんに流通している。あとは自分で好きに探せばいい。知識は他者から与えられ(Push型)、選び取るものになった。情報整理とフィルタリングの感度が自分の優位性だ、と感じているのではないか。

このギャップは、世代間で知識情報を伝達する「教育研修」において、重大な影響を与える。シニア世代は、若手が取りに来るのを待っている。若手は逆に、シニアが教えてくれるのを待つ。つまり「教育のデッドロック現象」が起きているのだ。こうなると、組織的な「学び」が働きにくくなる。それは、同じような間違いやトラブルを繰り返す原因になるだろう。

このところPMの教育について、ずっと考えている。マネジメント能力の育成は、知識教育だけではまったく不十分だと、わたしは思う。そもそもマネージャーとは、教育すべきものなのか、それとも自己成長なのか? 「俺の背中を見て育て」というおじさん世代にとって、マネジメント能力は自分から取りに行く(盗む)のが当然という考え方が強い。おまけにその世代は、マネジメントの仕事を伝達可能な形で言語化していないことも多い。

もちろん、マネジメントの能力には、言語化できる部分とできない部分がある。つまり属人的なソフト・スキル(技能)の部分と、軽量化し伝達可能なマネジメント・テクノロジー(技術)の部分とがある。そして後者は、先ほど述べたマネジメントの「マニュアル化」の議論につながりがちだ。どこまでマニュアル化できるのか、またマニュアル化すべきなのか?

こうした育成をめぐるPushとPullの議論が混乱する理由は、いろんなレベルの知識情報をごっちゃに話していることにある。そこで知識のレベルを「基本」と「応用」に分けて考えてみよう。

(1) 基本レベル

仕事に必要な基本的知識は、伝える側=先輩が、受け手=後輩に教えこむべき(Push型伝達)ものだろう。そうでなければ、組織として効率がわるすぎる。基本レベルとはつまり、テクニカルで伝達可能な知識やハード・スキルである。そして、そのためには知識に関するPushのシステム(仕組み)を作り上げる必要がある。つまり、教科書化・マニュアル化する訳である。あるいは昨今ならば、 ITツール(e-Learning)も活用することになる。

システム(仕組み)である以上、教える側の体制も構築しなければいけない。なぜなら、「人に教える」こと自体が学びにもなるからだ。組織としては、それを評価褒賞にも組入れる必要がある。

(2) 応用レベル

これに対し、応用的な知識やスキル(主にソフト・スキル)は、受け手が自分から学びに行く(Pull型)べきものである。そうでなければ、能力として本当には身につくまい。そのためには、Pullの知識獲得のための態度・思考習慣(OS)を持つことが必要だ。また、応用レベルは一般にマニュアル化に向かない。範囲が広く例外事象が多いため、教科書・マニュアルでカバーするには効率がわるすぎるからだ。

そこで中心になるのは、学ぶ事自体の面白さだ。身につけば、仕事の幅を広げるのに役に立つ。いや、直接すぐに役に立たなくても、いつか役に立つ潜在的可能性があればいい。そして応用レベルの問題には、必ずしも正解はない。だから、自分の頭で考え、自分のスタンスや価値観を持つ態度が求められる。


以上の二つのレベルのあり方は、ちょうど、学校教育でも実現されている。小中学校の基本レベルは、義務教育であり、先生が生徒に知識をプッシュで教え込む。子どもの側は、なんでこんなことを覚えなけりゃならないのか、などと疑問を持つこともあるが、そこは問答無用ということになっている。これに対し、大学・大学院というところは、(本来は)応用レベルを学ぶ場所だ。そこではいちいち、手取り足取り、教えたりしない。自分の頭で考えて、レポートや卒論などにまとめることが要求される。

ただし、(1)の基本レベルと、(2)の応用レベルを結ぶために、大事なことがある。それは、基本レベルを教える過程の中で、同時に「自分で学びに行く態度」を育てなければならない、ということだ。これがあるからこそ、応用レベルで自ら成長していけるのだ。そのためには、教え手が見本(モデル)となって示す必要がある。質問されたら、誠実に答える姿。難しい問い(つまりよい質問)に対しては、必ずしも全知ではない姿。そして自分も新たに学んだ、学べて面白い、という姿を、見せること。これがあってはじめて、基本レベルの生徒にも「学ぶ態度」が少しずつ身についていくのだ。
e0058447_23012569.jpg
しかし現実を見ていると、どうやら「学ぶ態度を教える」ことが、ミッシング・リンクとなって 欠けていることがある。そうなると、基本レベルから応用レベルに壁を越えてジャンプできない。学校教育でも、高校から大学へはジャンプがある。これにつまづくと、昔なら五月病にかかった。今は、大学自体がPush型中心の、手取り足取りやたらと面倒見のいい(?)教育に、重心を移してきている。そうなると今度は、社会に出たときがジャンプになってしまう・・

そこで大切になるのが、知識のナビゲーター(水先案内人)を組織の中にたてることではないだろうか。まだ十分にPull型の「学ぶ力」が身についていない人を、知識のある場所や、よく知っている先達に適切に導く役柄だ。わたしのこの小さなサイトも、及ばずながらマネジメント・テクノロジーへの水先案内役をしているつもりだ。

もう一つ。これもわたしの仮説だが、Pull型を習慣化し身につけるのは、一人の意思だけでやるのはしんどい。そこで、上級レベルへと学ぶ人のためのコミュニティがいるのだ。その証拠に、だから大学はゼミ方式になっているではないか。

思うに、Push型の教育は、ビジネス化できる。世に沢山、予備校だとか塾だとか資格学校だとかがあるのを見れば明らかだ。ところが、Pull型の成長は、ビジネスになりにくい。「学びに行く態度」を教えるには、マンツーマンの部分が必要であり、マスプロ教育の大量生産に比べるといかにも効率がわるいからだ。

それと同じことで、今の世間のPM教育には「応用」への道筋が欠けているように感じられる。基本レベルは、たとえばPMBOK Guide(R)でカバーできる。そこには有用な知識情報がライブラリ化されている。そしてPMP資格のための教育プロバイダーも多い。だが、本当は「PMBOK以降」への準備が同時に必要なのではないか。PMPは出発点に過ぎない。PMBOK以降も自分で考え、学び続けるための方法と場所がいるはずだ。だからこそわたしは、研究部会の仲間とともに、PMを学ぶためのオルタナティブな仕組みを構想しているのである。

最近、職場の大先輩が語っていたのだが、仕事はあるところから面白くなる、という。最初のうちは覚えることも多いし、担えるのは小さな役割に過ぎない。しかし基本レベルをマスターして、うまく先に進めると、Pushで与えられた専門の枠を超えて、周囲も巻き込んで大きな仕事をつくれるようになる。そして複利計算的に、自分を拡大再生産できるようになる。学ぶ能力自体が資産になるのだ。この大先輩は、基本から応用にジャンプするための、Pullで学ぶ力を身につけたからだろう。

学ぶ力とは、潜在的な能力をみずから獲得するための力である。すなわち学ぶ力とは、能力を得るための能力だ。それを身につけることは、単なる「即戦力」などの教育よりも、ずっと大切なことなのだ。

「教育の目的は、自分たちが聡明ではないことを教えることである。」(アラン・ケイ)


<関連エントリ>
 →「学ぶ時間をどうつくるか」http://brevis.exblog.jp/24292367/ (2016-04-10)


# by Tomoichi_Sato | 2017-02-20 23:04 | プロジェクト・マネジメント | Comments(0)

花粉症の対策として、「蒸しタオル法」を試すことをおすすめします

昨年の4月に、「わたしが花粉症の薬を飲まずにすむようになった、1日3分の簡単な習慣」http://brevis.exblog.jp/24285190/ というエントリをアップした。今年も花粉が飛びはじめ、アレルギーの人間にはしんどい季節が始まったようなので、ここにその内容を再掲しておこう。とても簡単な方法だ。わたしは毎年、医者にかかってアレルギーの薬をもらっていたが、昨年は一度もその必要がなかった。その方法とは、

毎晩、寝る前に蒸しタオルで3分間、鼻を温める

というだけである。蒸しタオル(いわゆる「おしぼり」状のもの)をつくり、仰向けになって顔の真ん中にのせて、3分間、じっと鼻筋や目のあたりを温める。すると、なんとなく顔の緊張や目の疲れが和らいで、リラックスする。それだけで、あとは眠ればいい。

蒸しタオルといっても、じっさいには乾いたタオルを水に濡らして、電子レンジでチンすれば出来上がる。あまり熱くしすぎると顔に乗せていられないが、ぬるすぎると3分たつ前に冷めてしまうから、タオルと水の量とレンジの時間は、頃合をはかる必要がある。わたしの場合はやや熱めにしておいて、(理容師さんがよくやるように)両手でぽんぽんとはたいて、表面を少し冷ますようにしている。まあ、温度や鼻筋を温める時間については、あまり神経質になる必要はないようだ。気持ちいいと感じることが大切なのだろう。

この方法で万人の花粉症が予防できるとか、治るとか言うつもりはない。たぶんその人の体質や、日々のストレスにもよって違うだろう。わたしだって今年はどうなのか、まだ分からない。ただ、昨年の春、この方法を教えて、「確かに効いた」「楽になった」という方が何人かはいたので、ここに再度書く次第だ。さしてコストがかかる訳でもないし、ひどい副作用もないと思うので、一週間程度は試してみていただきたい。もっともわたしは医師もなんでもないので、at your own riskでお願いする、と書いておこう。また、重い症状の方は、専門医にかかることをお勧めする。ただ、たった一人でもいい、この方法でどなたか読者諸賢の春の悩みが少しでも軽くなるならば、望外の喜びである。


<関連エントリ>

# by Tomoichi_Sato | 2017-02-19 09:21 | ビジネス | Comments(0)

契約音痴は、まだ続いている

10年ほど前のことになるが、プロジェクトマネジメント学会に呼ばれて「トワイライト・サロン」で講演を行ったことがある。テーマは「海外プロジェクトの共同遂行におけるリスク要因」で、海外の企業と組んで共同でプロジェクトを進める際に、どんなリスクが考えうるかと言う話だった。共同で組む場合、ジョイント・ベンチャーや、コンソーシアムなどいくつかの契約上のパターンがある。また、スコープをどう分担するかも問題だ。これらを考えた上で、最適なフォーメーションをデザインする必要がある。わたしは同僚のAさんと一緒に、来場者の前でこうした問題についての考え方をお話しした。

講演の後質疑応答の時間になって、幾人かの方が質問に立った。ところで、PM学会の参加者は昔も今も、ほとんどがIT業界の人たちである。話題も、IT開発系プロジェクトがなぜかデフォルトになってしまう。その中の1つは、プロジェクトがスタートしたしばらく後になって、顧客がいろいろ要求上の変更を持ち出し、設計が混乱しスケジュールが遅延する場合、どうすべきかと言う質問だった。これ自体はどこの業界でも起こりうる典型的な問題だ。そして、特効薬も正解もない。

正解はないが、状況に応じて、いくつかの選択肢を考え、プラスマイナスを評価して決める、というのがマネジメント問題の定石である。変更要求はコストにも納期にも影響を与えうるため、まずは顧客にそれを伝えて理解させる必要がある。ただ、その状況と伝え方次第で、対応策は変わりうる。一般論でいえる話ではない。わたし達は状況をより理解するため、質問者の方にいくつか質問を逆に返すことになった。どんな種類の成果物を作るプロジェクトなのか。規模はどれくらいか。技術的難易度はどうか、そして顧客の特性は。

こうした質問を重ねて、少しずつ全体像が分かってきた。だが、相手はいささかじれてきたのかもしれない。わたしが最後に「どんな契約条件だったのですか?」とたずねたら、「いや契約の問題なんかじゃないんです!」とほとんど金切声で叫んだ。しかたなく、わたしはそれ以上の議論をやめてしまった。

だが、もちろん、契約の問題なのである。おそらく顧客が最初に決めた一定金額以上の追加を払ってくれないから、この問題が生じているのだ。かかった費用をそのまま支払ってくれるならば、つまり今の用語で言う「準委任契約」ならば、むしろ相手が迷って要求をかえるたびに、自分の収入が増えるのだから、この質問者はむしろエビス顔だったに違いない。しかし、この人にとって、プロジェクトは技術の問題、ないし顧客の誠実さ、つまり信義の問題に思えたらしい。

今日のIT業界では、こんなこと言う人は随分減ったに違いない。要件定義と実装以降をフェーズ分けして別契約にすることは普通になったし、スコープや作業量が見積もりにくい場合は、一括請負ではなく準委任で契約することも、わりと当たり前の知恵となってきた。

今さらとは思うが解説しておくと、「一括請負契約」とは成果物を納入して一定の対価を得る契約のことである。「委任契約」は元々は民法の用語で、依頼人が弁護士などに法律行為の代行を依頼する契約である。「準委任契約」はそれに準じた形の契約で、ただ、依頼するのが法律行為ではなく、通常のビジネス上の行為である場合に用いられる。委任契約も準委任契約も、普通は働いた時間に応じて対価が支払われる。

長らく、わたし達の社会では、システム開発は一括請負契約がデフォルトであったようだ。これは元々、ソフトが計算機ハードウェアのおまけ扱いから出発したことや、元請けが計算機メーカーの場合が多かったという事情から来たのだろう。一括請負の方が、金額が最初に確定できるため、発注者側での予算措置がしやすいという面もあったに違いない。

だが、ITの世界では要求が不明確で、あとから変更の発生するケースが少なくない。一括請負の場合、途中の追加変更に対して、請負側は追加請求の権利を有する。だがお金を払う発注者の方が「お客様は神様」で、取引で有利な立場に立つことが多い。その結果、受託側が追加費用をもらえず、コストだけ負担する赤字プロジェクトが生まれる。最初の質問者のケースは、まさにこれだったのだろう。

ところで、長らくこのような状態が続くと、受託側のIT産業自体が弱ってきてしまう。そこで『カウンターベイリング・パワー』が働き、最近はIT業界の側が契約上で、いろいろな自衛手段を講じるようになった。その結果がフェーズ分けであり、また準委任契約の導入であった。これ自体は、ある意味、健全なことだ。

ところが世の中の振り子は、ときどき逆に振れすぎることがあるらしい。1月に開催された「プロジェクト&プログラム・アナリシス研究部会」では、コンサルタントの本間峰一氏を招いて『システムトラブル相談センターの概要と開設の背景』という講演をしていただいた。本間氏は一般社団法人アドバンストビジネス協会が開設した「システムトラブル相談センター」のキーパーソンでもある。いろいろなITプロジェクトのトラブルを見てこられたが、最近は逆にITベンダーに有利な契約のために、発注者側が難儀をするケースも出てきているという。

ここで問題になるのが、準委任契約のあり方である。一般に、IT開発の最初の要件定義と、最後の総合テストないし運用テストは、準委任契約で行われることが多くなった。最後のテストでは、かかる工数が発注者側の運用環境に依存するし、また既存のレガシーシステムとのインタフェース・テストなども含まれることが多い。だからここを準委任でやること自体は一見、適正なことに思われる。ところが、ここで交わされる準委任契約が、ともするとITベンダー側に非常に都合のいいようにできているという。

たとえば、瑕疵担保責任の所在である。実装は一括請負だが、ユーザにとって納品物を受け入れるかどうかは、最後のテストの結果を見て判断することになる。ところがそこは準委任契約だから、成果物に責任はありません、というケースがあるらしい。何かバグが見つかって直す必要があったら、ユーザがお金を払わなければならない。これでは実装の品質が低ければ低いほど、ITベンダーは収入が増えるというおかしなことになる。それに、納期の問題だ。準委任だから、完成義務はない、納期は保証しません、という。

もう一つ問題の所在となるのは、System Engineering Service(略称SES)とよばれる契約形態である。これはIT会社の元請けから、下請け会社にSEを配員してもらうために発注するサービスだが、準委任契約の業務委託になっている。しかし、その実態は派遣契約にきわめて近い。IT業界は知っての通り多重下請け構造なので、SESの再委託もある。準委任の準委任という訳だ。どこの誰に責任があるのかさっぱり分からなくなる。

ためしに質問してみた。「準委任契約というのは、プロフェッショナルなサービスを提供するための仕組みです。である以上、プロとして仕事の品質を保証する責任があるはずでは?」 だが答えは「そこが曖昧なんです」だった。

わたしは驚いた。海外プロジェクトの契約の常識から、あまりにかけ離れているからだ。わたしは数年前まで、あるプロジェクトで海外企業と実費償還契約のもとで足かけ3年半ほど働いた経験がある。実費償還(Cost Reimbursable)契約というのは、日本の準委任にほぼ対応する概念で、人件費や経費など、つかった費用に応じて支払いを受けるようになっている。

ところが、海外企業との実費償還契約というのは厳しいのだ。まず、プロジェクトへの配員は、顧客が経歴書を審査し、きちんとした経験・能力が認めることが条件だ。勝手に協力会社の人間をアサインするなど、もってのほか。また一旦、配員されても、仕事ぶりの質が低いと、欠格として解任(Disqualify)されてしまう。働いた時間に応じて対価が払われるが、毎週タイムシートを顧客に提出し、チェックと承認を受ける必要がある。出張も外出も、顧客の事前の承認がいる。

それどころかプロマネは毎週のミーティングで、消費したMan-Hour(人時)と、作成し提出した設計成果物と、進捗率計算を報告しなければならない。顧客はこれを元に、生産性をモニタリングする。生産性が低いと叱責され、キャッチアップ・プランを出させられる。契約にはスコープと成果物が明記され、全体の契約金額にも上限(Cap)が設定されている。追加変更にかかわる作業は全て、書類で申請し承認である。自分たちのミスで余計な人時やコストを浪費したときはどうするか、納期に遅れたらどうするか、等々、ことこまかに契約書で決まっている。これが、世界の常識なのだ。

契約というのは、発注者と受託者の間のリスク分担を決めるための仕組みでもある。だから、一括請負契約と実費償還(準委任)契約とは、あれかこれかの二者択一ではない。両者のあいだには、インセンティブやペナルティ、変更と単価精算など、様々なバリエーションと知恵が存在するのだ。全体として何らかの納品物にかかわるケースならば、納期条項も成果物の品質責任も、支払額の上限もついているのが当たり前というのが、わたしなどの感覚だ。

これに比べると、本間氏の説明で聞いた日本のIT業界の準委任契約は、ほとんど派遣契約も同然のゆるさである。いや、派遣の場合、二重派遣は違法になるが、SESだと何重にも委託できてしまうから、もっとまずいとも言える。ひどいケースでは、ITベンダー側の営業が、こうした契約をたてに上手く立ち回って、弱り果てた顧客からどんどん金を搾り取っているという。

こうした状況が不健全なのはいうまでもない。契約を盾にとれば、技術力の不足をごまかすことができると思うのは、明らかに間違いだ。契約を盾にとって信義にもとるようなことをするのは、契約の精神に反している。それに技術力がなければ、最終的に顧客の満足は得られない。顧客満足こそ、ビジネスの安定の最大の基盤ではないか。

ただし、誤解しないでほしいのだが、わたしはIT業界全般を責めているのではない。むしろ逆だ。IT開発プロジェクトの発注者の側が、あまりに契約について音痴であることが、問題の根本だと考えている。一括請負契約なのに、後からどんどん追加変更を言い出す、最初の質問者の事例も、その一端だ。また逆に、準委任だからといって、ベンダーに妙に有利な条件をのんでしまうのも、やはり問題だ。私たちの社会では、長らく信義則で動いていたので、契約について弱い人が多い。だから準委任契約というと、成果物責任がなく、たんに「善良な管理者の注意義務」(「善管注意義務」)があるだけです、という説明に納得してしまうのだろう。

米アリゾナ州立大のDean Kashiwagi教授はプロジェクトとアウトソーシングの専門家で、"Best Value Procurement”という方法論を創案し、数千もの顧客に対し成果を上げてきた。昨年フランスで会ったとき、彼は「外注に関わる問題の8割以上は、じつは発注者側の能力不足に起因している」と語っていた。彼の実践範囲はITに限った話ではない。だが、なかでもITプロジェクトは、どこの国でも、難しいのだ。ITの発注者側にこそ、よりきちんとしたプロジェクト・マネジメントの理解が必要なのだと、わたしも声を上げていうことにしよう。


<関連エントリ>
 →「契約なんかこわくない」(2008-07-17)



# by Tomoichi_Sato | 2017-02-13 23:00 | プロジェクト・マネジメント | Comments(0)

意外性に動じない心を持つために

大学3年生の時、専門科目の学生実験があった。わたし達の班は「流動層の伝熱測定」という課題が与えられた。流動層というのは、丸い円筒形の容器の中に、細かな粒子(粉体)を半分くらいまで入れて、容器の底のノズルから気体を送り込んでやる装置だ。気体の流量がある点を超えると、それまでは単なる粉の集まった固体のように見えた層の中に、急に泡が生じて、全体がまるで液体のようにふるまい出す。これを流動化開始速度と呼ぶ。中で起きているのは、固体と気体とが混じり合って、液のような乱流を示す現象だ。化学プラントでは、細かな触媒粒子を使う化学反応で、反応熱が大きいときに、よくこのような装置を使う。中が良く混ざるので、熱がホットスポットのように集中しないですむからだ。

さて、わたし達の班は指定された運転条件で実験装置を動かし、得られたデータを元に計算した。ところが、教科書に載っている伝熱係数の推算式と、結果が3割も違う! どうしようか。皆で相談したが名案もなく、また実験を最初からやり直す時間もなかった。わたし達は、結果の面接を担当するK教授のところに、おそるおそる行った。K先生は当時、学会長をされていた著名な学者である。にこやかな方だが、学生から見るとちょっとコワい。どうなるだろう。もしかしたら居残り再実験を命じられるだろうか・・?

ところが、K先生はわたしたちの班のレポートのグラフを見て、一言「良く合っているじゃないですか」と講評された。え、良く合ってる? だって3割もずれてしまったんですよ。すると、K先生は笑いながら、その後わたしが一生忘れない言葉を口にされた。「これだけ複雑な現象の挙動を推算する式なんだから、精度はそんなものですよ。」

わたしの専門は化学工学だ。英語で言うとケミカル・エンジニアリング Chemical Engineeringである。これは化学プラントの設計論なのだが、そうか、その中心となる反応装置の設計の精度って、ときには3割も違うことがあるのか。もちろん、わたし達の実験が拙劣だったという事情もあるだろう。だが、両対数グラフでばらつく点群から、むりやり相関をとった推算式なのだ。1〜2割程度ずれても、意外ではない。いやむしろ、これほど複雑な現象に対して、なんとか1〜2割程度の誤差で推測できるモデル式を作れる工学の力が偉大なのだ。

帰り道に、班の仲間がいった。「それにしても、電気・電子工学の連中がきいたら驚くだろうな。電気回路の実験なんか、3割どころか3%ずれたって大目玉だろ。それだけ精密な分野なんだもの。」 わたしも考えた。「彼らは、結果を正確に予測できる分野にいるのだ。あいにくぼくらは、違う。」

その後、エンジニアリング会社で働くようになったわたしは、何年かして奇妙なことに気がついた。わたし達の業界では、プロジェクト・マネージャーという職種が一番大事である。プロマネは偉い。個人が偉いのではなくて、プロマネという職種が、あらゆることの最終決定と責任を持つエラい『役割』なのだ。ただ、わたしの勤務先には百人単位のプロマネたちがいるが、有能な人、業界で名を知られて上位に上がっていく人たちには、ある傾向が見えた。

それは、有能なプロマネにはなぜか、化学工学と土木工学の出身者が多い、という事実だ。わたしは直接、統計的なエビデンスを示すことはできないが、経験的にそう感じる。エンジニアリング会社というのは工学のデパートみたいな所で、機械・電気・建築・制御・・と、ほぼありとあらゆる分野の専門技術者がいる。他方、日本には「プロジェクトマネジメント学科」をもつ大学は事実上1校しかない状態で、プロマネのキャリアは普通、別の専門技術を学んだ者がなっていく。だから、あらゆる専門の出身者がプロマネにいて良い訳だし、中には文系出身者だって立派にいる。

それなのに、なぜか先の二つの工学の出身者が、プロマネの中ではいやに目立つのである。わたしの業界には俗に「御三家」と呼ばれる大手3社があるが、何年か前は、3社の社長がそろって土木技術者、それも東北大学の土木科出身だったことがある。皆、プロマネ経験者である。国内だけではない。海外の同業他社でも、優秀なプロマネのキャリアを見ると、ああ、この人もシビル・エンジニアかケミカル・エンジニアだったんだ、と感じることが多いように思う。

(念のため言い添えておくが、この2分野だけからプロマネが出ている、などと主張しているのではない。機械出身の優秀なプロマネや電気出身の有能なプロマネだって知っているし、いろんな出身者が事実いる。だが、化工屋と土木屋がなぜか他より少し目立つのだ)

これは、なぜだろうか?

断言していいが、大学の化学工学科は、マネジメント教育にあえて力を入れたりはしていなかった。少なくともわたしの時代はそうだ。わたしは今、出身学科に頼まれて、年に2コマだけプロジェクト・マネジメントを教えているが、たぶんそれで全部だ。ではなぜ、プロマネを多く輩出できるのか?

たしかに化学プラントのプロジェクトでは、基本設計を担うのは化学工学出身者だ。プロセス産業では、最初の基本設計をプロセス設計とよび、これを担当する技術者をプロセス・エンジニアないしプロセスシステム・エンジニアという。しかし、基本設計の担当者だからプロマネになれる、というほどこの分野のプロジェクトは単純なものではない。それに、土木はどうなのか? こういっちゃ失礼に聞こえるかもしれないが、土木設計はプラント設計の中心とは、言いがたい。必須で、とても大切な仕事だ。だが、機器や配管を支えるための架構や土台の設計で、むしろ縁の下の力持ちに近い。なぜ、ここから有力なプロマネが輩出するのか?

模範的な答えは、たぶん、「シビル設計と工事は、プロジェクト全体のクリティカル・パスに乗ることが多いから」かもしれない。たしかに、架構や基礎は、最後に設計が決まって、最初に施工しなければならない。設計というのは、ふつう上から下に進む。上物の重量や位置が決まって、はじめて下の設計ができるからだ。そして工事というのは、下から上に積み上げて進むしかない。だから、シビル工事はつねに最後まで図面が決まらず、最初に手をつけなければいけない。クリティカル・パスに乗りやすいから、彼らはプロジェクト全体を見て仕事をする経験を積むことになる・・

たしかに、その通りだ。だが、クリティカルになりやすいといえば、配管だとか回転機だとかだってそうだし、制御弁だって空冷熱交だって受電設備だって、そうではないか。機械工学や計測工学や電気工学にだって、チャンス(?)はほぼ、公平なのだ。なのになぜ、化工屋と土木屋なのか。

わたしの推測は、「化学工学と土木工学では、意外な事態が出現しても、あまり動じないから」ではないか、というものだ。結果が3割違っても、化学工学者が驚かないことは、最初に紹介した通りだ。では土木は? 土木の世界では、「しょせん掘ってみないと分からない」という言葉が表している。土木工学は地面とその下を相手にする仕事だ。理論はある。推測もある。だが、地面を掘ったら何が出てくるか、じつは分からない分野なのだ。でかい石塊かもしれない。岩盤かもしれない。遺跡だったりすることもある。だが、それに一々驚いていては、シビル屋の仕事にはならない。

理論はある。推測式もある。だが、意外な事態に動じない。内心、驚きはするだろう。だが、そこからすぐに回復する。推測が当たらなかったからといって、「こんな推測はナンセンスだ」などと言いもしない。だってモデル化と推測は工学の命綱なのだ。それを捨てたら、ほんとに何の根拠もないバクチになってしまう。工学と博打は違う。似ているように見えるかもしれないが、違うのだ。

マネジメントという仕事の要件について、わたしはずっと考えているし、人に教えたりもしている。マネジメントという仕事の中核には、「人を動かす」という行為がある。他人に働いてもらって、共通の目的を達すること。自分で直接、手を動かすことはマネジメントとはいわない。このことは、本サイトでも繰り返し書いている。しかし、それと並んで、必要なことがある。それは、「先読み」と「決断」の能力である。

先を読んで、手を打つこと。これがマネジメントとして重要だ。先を読まないマネージャーなんて、何のためにいるのか分からない。ダメなマネージャーは、ただ目の前の問題つぶしだけにかかずらう。目の前のボールを反射的に追いかけるだけの、ダメなサッカー・プレイヤーのように。先を読むということは、計画を立てるということだ。計画はマネジメントの重要な一部で、だからこのサイトのテーマは『計画とマネジメントの技術ノート』なのだ。

だが、「決断」については、もう一つ、死活的に重要なことがある。それは、予想外のことが起きても動じない、ということだ。リーダーは、簡単にうろたえてはいけない。たとえ驚いても、感情的にアップセットしてはいけない。なぜなら、ネガティブな感情に動かされているときは、決して良い判断ができないからだ。

意外性に動じない心を持つために、大事なこと。それは、先読みの予測が当たらなくても、あまり驚かないこと。とくに自然現象ではなくて、人々を相手にしたときには、なおさらだ。人を動かすことの複雑さ・予想のつかなさは、流動層の比ではない。自分で予測はするが、予測の精度について限界をわきまえていること。土木と化工の二つの分野は、たぶん、こうした覚悟を早い時期から身につけざるを得ないのだ。それが、良きプロマネを生み出す土壌になっているのだろう。・・これがわたしの想像である。そういえば、GEの伝説的経営者ジャック・ウェルチも、化学工学出身だったな。

だからといってわたしは、企業がもっと土木や化工出身者を重用すべきだ、などといっているのではない。それにこのわたし自身、化学工学の出だが、業界に名の知れたプロジェクト・マネージャーという訳でもない。出身だけでは、動じない力は決まらないのだ。

では、どうしたらいいのか? 動じない心、といえば、度量の大きな人物の特徴である。まるで西郷隆盛か誰かみたいな。だが、西郷さんのような器量の大きな人物に生まれつかなかったわたし達は、どうしたらいいのか?

わたし自身が動じやすい人間だから、ここから先は、推測である。

まず、「ああすれば、こうなる」式の予測は当たらないこともある、という認識を身につけること。これは最低条件だろう。

その上で、たぶん大事なプラクティスが三つある。まず第一に、推測・予測には精度があり、その有効範囲があるということを、きちんと意識し共有することだ。工学的な推測だけではない。法律上の、あるいはビジネス上の予測についても、同様だ。当たらない可能性は1〜2割あるな、といった判断を、意識の上にのぼらせること。あるいは言葉にしておくこと。精度がわるいときには、フォールバック・プランとか保険をかけるとかいったことも、手を打っておく。そうすれば、意外な事態に驚いても、動揺は小さくなる。

二番目に、リスク・マネジメントをきちんと実施すること。とくに、事前のリスク・アセスメントを、複数の仲間で一緒に行うこと。計画している事柄について、起こりうる事象を、よってたかって洗い出し、その発生確率や影響度を、ラフでもいいから数字で考えてみる。これは一人でやるより、複数の目で見る方が、絶対に有用だ。こうすれば、想定外な事象は少なくなる。

三番目。これはなかなか難しいことだが、自分の感情をコントロールする訓練をつんでおくこと。感情筋を鍛える、とでもいおうか。リーダーにとって、一番まずいのは感情的になること、つまり自分の感情に自分が乗っ取られる事態だ。部下から見て、感情的なリーダーほど始末におえないものはない。それは誰しも経験があるだろう。

自分の感情をコントロールするにはどうしたらいいか。それには、まず、「自分は今、どのような感情を持っているか」を自覚することが大切だと、心理学は教える。自己チェックすることで、自分の感情を対象化できるからだ。対象化したからといって、すぐにその感情が消え去る訳ではないが、それでも無意識に振り回されることからは、多少避けやすくなる。こうした感情のトレーニングは、若いときに、意識して訓練をしておく方がよい。自分の経験でも、管理職に就く中年になってからでは、遅いと思う。

感情をコントロールするとは、決して感情を押し殺すことではない。また感情を表に出さぬよう、能面のように我慢することでもない。そうした無理は、むしろ害がある。感情はわたし達の生活を豊かにする、一種の資源である。わたし達はむしろ、感情を豊かに育てる必要がある。そうすることで、妙に歪んだり暴発したりしないようにできるのだ。

まあ、こんなことは、わたし達の文化や教育の中には、あまり根付いていない。わたし自身、だいぶん遅くなるまで気がつかなかった(おまけに短気だし気が小さいし、ずいぶん人に迷惑をかけたろうと思う)。ただ、一つ方法がある。それは、ネゴシエーション=交渉の練習をすることだ。交渉は感情的になったら負けだし、感情を読まれるだけでも不利になる。絶好のトレーニングの機会なのだ。だからこそ、わたしは自著「世界を動かすプロジェクトマネジメントの教科書」の最後の章に、あえてネゴシエーションの練習風景を入れたりしたのだ。

世の中のことは、なかなか、はかりがたい。余計なことだが、昨今は、海をはさんだ隣国の権力者の、予見しがたい判断や行動に、大勢が右往左往しつつあるように見える。法律や道徳やルールで権力者に枠をはめ、その行動の予見可能性を高めようとすることは、人類社会の知恵だと言っていい。予測可能にしておくことは大切だ。

だが、予測が外れたときにも、動揺して自分の判断が狂わないように、自分の心のレジリエンシーを高めることも必要なのだ。そこの重要性が、どうもわたし達の社会では、あまり認識されていない。「ああすれば、こうなる」の類いの、決まり切った予見、正解、公式ばかりが闊歩しているように見える。それはあまり安全なこととは、いえない。国家レベルのことはともかく、せめてわたし達の身の回りだけでも、もう少し「動じない心」を育てたいではないか。


<関連エントリ>



# by Tomoichi_Sato | 2017-02-07 23:12 | リスク・マネジメント | Comments(1)

お知らせ:浜松でプロマネ育成研修セミナーを開催します(3月11日・18日)

来る3月に、NPO法人浜松ソフト産業協会が主催する

 「プロジェクトマネージャー育成研修」

の講師を務めます(静岡大学大学院事業開発マネジメントコースと浜松信用金庫が協賛予定)。
 これは11日と18日の土曜日二日間にわたって開催される研修セミナーです。わたしはその初日を担当し、

 「モダンPM論への誘い — プロジェクトをマネジメントする『技術』とは何か

と題して、プロジェクト目標の設定(ミッション・プロファイリング)、WBSの作り方、アクティビティの構成要素、プロジェクト組織と役割、そしてリスク・マネジメントなどについて講義する予定です。また関ものづくり研究所の関伸一氏によるプロジェクト・ケーススタディを加え、PMに必須な基本的スキルを1日できちんと身につけられるよう、演習を交えた実践的なレクチャーを行うつもりです。

 二日目は静岡大学の八巻直一名誉教授による、PERT手法(スケジューリング)の実際などに関する研修です。

 場所は静岡県浜松市の浜松情報専門学校 6階実習室です。
  (静岡県浜松市中区中央3丁目10-31)
 定員は20名で、有償ですが、実践的で役に立つ内容となっています。

 昨年も浜松で同じタイトルのプロマネ育成研修を行いましたが、今年はさらにバージョンアップした内容になっています。なお主催はソフト産業協会ですが、内容は必ずしもIT分野のプロジェクトだけに限らず、技術リーダーを目指すエンジニアの方全般に役立つよう考えております。

 単なる資格試験のためのお勉強ではなく、本当に実務に役立つプロジェクト・マネジメントの基本を身につけたいと考えている方、上記URLにある案内パンフレットの申込先にて受け付けしております。定員が限られておりますので、お早めにお申し込みください。積極的なご来聴をお待ちしております。

  佐藤知一

# by Tomoichi_Sato | 2017-02-05 18:50 | プロジェクト・マネジメント | Comments(0)