米国人たちと机を並べてプロジェクトで働いて、最初に学んだこと

はじめてアメリカ人たちと机を並べて仕事をしたのは、もう20年以上前のことだ。当時わたしは、国際プロジェクト本部という部署にうつったばかりで、職種はプロジェクト・エンジニア（の見習いのようなもの）だった。プロジェクト・エンジニアとは、プロマネの配下で、様々な連絡調整業務を行う役割である。わたし達の業界では、プロジェクト・マネージャーになりたかったら、必ずプロジェクト・エンジニアとしての経験を積む必要がある。プロマネへのキャリア・パスの一部であるととともに、一種の下働きであり、わたしはさらにその見習いだったという訳だ。

わたし達は中東における、ある大型プラントの入札見積業務を進めていた。自社が単独で応札するにはリスクが大きすぎるため、米国の同業であるX社との共同プロジェクトの体制をつくって、仕事に臨んだのだ。我々の業界では、大型案件の入札見積となると、それ自体が6ヶ月〜1年近くの期間を要し、費用も（人件費を含めると）かるく数億円単位がかかる。つまり、入札自体がそれなりの規模のプロジェクトである。

さらに、見積設計業務の一部は、英国にある関連会社に依頼していたので、プロジェクトは日米欧の三極体制になった。中心オフィスは、横浜にあるわたしの勤務先（当時はまだ郊外の上大岡という場所にあった）に決まり、遂行チームは『アマルガム』スタイルとなった。アマルガムとは合金という意味だが、つまり複数の会社のメンバーが、区別なく机を並べて、ワンチームとして働くやり方である。プロマネはアメリカ人、副プロマネは日本人で、二人は文字通り横に並んで窓際に座っていた。仕事の言語は、すべて英語であった。

同じ業界で同じ案件の仕事に携わりながら、働き方から仕事の進め方まで、日米でこうも違うのか、と印象に残ることが沢山あった。アメリカ人たちは、朝が早い。7時台にはオフィスに来て働き始め、そのかわり5時をすぎるとさっさと帰ってしまう。長時間残業はしない。だが、なぜか能率が高いので、仕事はちゃんと進んでいく。

それでも見積業務の追い込み期に入ると、米国人のプロマネは厳かに「No Saturday」を宣言した。つまり土曜日も全員出勤して、仕事をしろという訳だ。10数名いた米国人のスタッフは、文句も言わず従った。もちろん我々日本人だって、同じく土曜日返上である。

いまでもよく覚えているのは、見積書提出の直前の土日だった。当時はまだ見積書は紙で提出し、しかも客先要求に応じて10部近くのコピーを収めなければならなかた（客先はそれを社内の関係各部門に配布してレビューするのだ）。複写された紙は、ダンボール箱に何箱にもなる。仕分けは外注先の複写会社がやってくれているが、万が一にも落丁・乱丁があってはならない（なにせ1千億円級の受注がかかっているのだ）。

わたし達は椅子を並べて車座になり、全員がコピーを手にして、一人の読み上げる掛け声にしたがって、章ごとのページ数があっているか、白紙が挟まっていないかを、全ページめくりながら確認した。米国人のプロマネから庶務の日本人女性まで、同じ輪に座って、一緒に紙をめくっていく。OKならば、そのファイルは完成品の段ボール箱にしまう。バカみたいに単純な、雑用作業だ。だが、プロマネ自身、文句も言わず当然の事のように皆を手伝って、淡々とこなしていく。

わたしはその姿を見て、なんとなく、「プロジェクト・マネジメント」という仕事の本質の一部を、垣間見たような気分になった。プロジェクト・エンジニアの仕事とは、ある意味では雑用の集合体なのである。自分で設計図を引くわけでもなく、自分で資機材を運ぶわけでもない。そういう仕事はすべて、社内や社外に専門職がいて、彼らが引き受ける。プロマネと、その配下のスタッフ（プロジェクト・マネジメント・チーム、略してPMTと呼ぶ）は、ただ計画をして、その手配と連絡調整などの情報の交通整理をし、そして問題解決をしていく役目なのだ。

ただ、そうしたいわば『雑用』の進め方において、アメリカ人と我々とでは、明らかに違う点があった。1つ目は、いろいろな細部が、かなりシステム化（定型化）されていることだ。2つ目に、彼らは必ず最初に「計画を立てる」ことだ。

ある日、顧客からFAXが入って（そう、当時のコミュニケーション手段はFAXが主体だった）、面倒な追加要求が来た。我々の見積作業スケジュールに、いろいろな部分でインパクトがありそうだ。FAXはまず、プロマネの机の上のIn Boxに届けられる。かれはその内容を見て、左上の角に小さな付箋紙を貼り、机上のOut Boxに置く。

その付箋紙には、プロジェクトに関わる各部署・各専門家の略号が、表形式にリストアップされている。プロマネは、FAXの内容に応じて、配布すべき先に、AやIなどの文字を書き込む。「A」はActionの略で、要アクションを意味する。「I」はInformの略で、情報として承知しておくべきことを意味していた。上記のような面倒な要求のときは、もう少し具体的なアクション内容を、手短に付記する。

庶務の人は定期的に、プロマネの机のOut Boxをあけて、その付箋紙の指定した通りに複写をとって、チーム員や関係部署に送付する。オリジナルの紙は、プロジェクト・チームの部屋のキャビネットに「センター・ファイル」する。入ってきたFAXは、送信元ごとに連番がふられており、センター・ファイルする際に、インデックスの表に、連番・受信日時・タイトル等を書き込む。返信するときには、その「連番・受信日時・タイトル」を書くことによって、どの連絡に関する事項だか、明確になるようにする。

こういうやり方が、「システマティック」という事なのかと、はじめて納得がいった。プロマネの仕事の半分以上は、情報の判断と交通整理である。それがムダなく、能率的に、かつ誰にとっても明確になるように行われる仕組みになっている。どこの部署にいつ、どの情報が届けられたか、すなわち『情報のトレーサビリティ』が、客観的に追えるようになっている。

21世紀の今は、顧客とも社内外の連絡も、すべて紙ではなく電子化されている。だが、紙ベースで上記のような仕組みが確立されていたからこそ、それをスムーズにITシステムに移行できたのだ。いいかえると、紙でちゃんとした業務のプロセスが構築されていなかったら、コンピュータを持ち込んだって、急に「デジタル化」などできないのだ。

ところで、上記のような厄介な要求が来た場合、プロマネは、PMTのスタッフの一人である『プロジェクト・コントロール・マネージャー』に、「A」（要アクション）の記号を書き、さらに右横に”DEVELOP PLAN”と付記した。わたしはなぜか今でも、その角ばった手書きの字体を覚えている。つまり「計画を立てろ」と指示したのだ。

この「プロジェクト・コントロール・マネージャー」というのは、計画立案と進捗管理の専門家である。このときは、同じく米国人がこの役職だった。でも、このプロジェクト・コントロール・マネージャーという役割がまた、日本人にはわかりにくい。日本語ではマネジメントもコントロールも「管理」だから、日本語訳すると「プロジェクト管理管理者」になってしまう。何それ？

英語的には、コントロールは、マネジメントの下位概念と理解するほうがいい。マネージという動詞には、どこか「暴れ馬を乗りこなす」ような語感がある。ところが、コントロールという動詞は、もっと精密な、飛行機や自動車を乗りこなす、つまり「制御」に近いニュアンスなのである。プロマネを船長にたとえるならば、コントロール・マネージャーは「一等航海士」というところだろうか。海図に航海の線を引き（＝計画立案）、操舵して予定通り船を動かす。だが、航路の判断など重要なところは、船長の指示に従う。

コントロールにおいては、数量をもとにした、メトリクスを用いたやり方が、ほぼ必ず選ばれる。それが技術提案書の作成の進捗状況であれ、見積コストの積算状況であれ、最初にリストや表を作り、カバーすべきアクションや対象をリストアップする。そして、その中でどこまでが完了したか、比率や％ではかっていく。必要ならば重み付けするが、重み付けが難しい場合は、単純な項目数だけでもいいから、カウントする。

だが、日本人にこれをやらせると、「適当な重み付けができませんから」といって、数値化それ自体を放棄する事が多い（なので結局、毎回進捗を聞いて回らなければ状況が把握できなくなる）。正確でなければ数値化に意味はない、と考えるのは技術者らしい、といえば言える。だが、その裏には、なぜか仕事のマネジメントにおける数値化への警戒感のようなものが潜んでいたりする。その点、米国人は、数字は状況判断の目安だと割り切っているように見える。

もっとも、今うっかり「日本人は」と書いたが、これは習慣化すれば、別に日本人だって普通にできるようになる。なにも文化や国籍の問題ではないのだ。仕事をどうシステマティックに進めたいか、という思考習慣、いわば『OS』の違いなのである。

ただ、このようなOSをちゃんと組織全体で作り上げているかどうかが、結局はITシステム導入だとか、業務の「デジタル化」における差を生み出すのである。たとえば、あなたの職場では、「センター・ファイル」は昔から行われていただろうか？　インデックスはきちんと作られていただろうか？

米国流の、あるいはもう少し広くいって欧米流の仕事のやり方は、役割分担と専門分化をベースにした分業体制が基本にある。組織を作り、仕事を部分部分に分割して、それぞれ専門担当者に割り当てる。ただ、そのままだと足並みが揃わないから、全体を指揮するリーダーが必要になる。まるでオーケストラのようなものだ。

オーケストラなので、皆を動かすためには楽譜（＝計画）がいる。それを全員に、正しく配らなくてはならない。そういうところから、彼らは仕事における情報（Information）と伝達（Communication）を重んじるようになる。コミュニケーションを効率よく、正確に進めるためには、定型化された番号や記号や数字を使うのがいい。かくて、彼らは自然と「データ」を仕事の中に織り込んでいく。

これに対して、「あ・うん」の呼吸で互いの間合いを見計らって、多少出たとこ勝負の即興的に進めていく日本の組織のあり方は、お能の囃子みたいだ、と言えなくはない。楽譜はあってもメモ程度で、お互いの目配せや顔の表情と、受けての側の「察し」が、主な情報伝達である。こういう組織に、定型化されたデータは発生しようがない。小規模な組織だから、必要性も小さい。仕事の成果は、各人の個人的力量に依存する。

・・こう書いていくと、なんだか米国流を礼賛し、日本式を批判しているように見えるだろう。だが、そういう意図ではない。どちらのやり方にも、長所短所があることを、わたしもいろいろな仕事を通じて知っている。ただ、思考習慣として、英米企業は最初から大規模志向で、システム化の方向を向いているが、日本企業はそういうマインドが薄い、ということを言いたいだけだ。

だが、そういう違いを無視して、欧米風の考え方を直輸入しがちな傾向が、わたし達の社会の特徴でもある。その結果として、「なかなかデジタル化が進みません」みたいな話題が、あちらでもこちらでも出てくることになる。

最近、わたしの所属する中小企業診断士の研究会である「生産革新フォーラム」（略称MIF研究会）が、製造業のDXをめぐって、座談会を開いた。その内容が、「日経ものづくり」誌に掲載され、また「日経XTech（クロステック）」にも転載されたので、URLを下記にご紹介しておこう。

製造業DX担当者会（前） https://xtech.nikkei.com/atcl/nxt/column/18/00001/04877/

製造業DX担当者会（後） https://xtech.nikkei.com/atcl/nxt/column/18/00001/04879/

この記事は、いろいろと具体的な差し障りのある生々しい話題のため、匿名座談会の形式になっている。佐藤がこの話者の中にいるかどうか、当てていただくのも一興かもしれぬ（笑）。ともあれ、デジタル化問題の基本にあるのは、仕事の進め方に関する思考と行動の習慣、つまりOSなのである。OSの問題を無視したまま、ただ応用として「データ・ドリブンな経営」などを望んでも、それはかなわぬ夢というものだ。

＜関連エントリ＞

　→「新任リーダー学・超入門(4)　測れないものはマネジメントできない」 (2011-08-26)