人気ブログランキング |

カテゴリ:プロジェクト・マネジメント( 169 )

海外企業との共同プロジェクトにおけるフォーメーション・デザインは、どうあるべきか

前回の記事の末尾にも書いたが、「マネジメント・テクノロジー」という言葉を発案して、わたしに教えてくれたのは、今秋惜しくも亡くなられた勤務先の同僚、故・秋山聡氏である。秋山さんは、この語を《マネテク》と縮めて、『まねてくニュース』なるメールマガジンとデータベースを、社内に発信し続け、多くの愛読者を持っておられた。

秋山さんは高専を卒業後、大学の工学部に編入して修士号を得た、バリバリの理系教育を受けた人だった。日揮に入社後、海外プロジェクト・マネジメント部門で活躍されたが、ある時期より、ライン業務から一切手を引き、PM業務の標準化を中心としたスタッフ的役割に専念するようになった。プロマネ経験者こそが最大の出世コース、と思われているエンジニアリング業界にあって、これは随分と勇気のある処世だったと思う。

日揮においては「プロジェクト・マネジメント技術部」という部門が、一種のPMO的な機能を担ってきた。秋山さんはそこの重鎮として、社内の各種検討活動に参加され、言葉は穏やかながら鋭い発想で議論をリードされた。わたしも同じ部に何年か所属しており、その縁もあって、東大大学院の「プロジェクトマネジメント特論」の講義を引き受けた際、一学期・全15コマのうち3回分を、秋山さんに分担講義していただいた。

その秋山さんとわたしは、2007年に、『海外企業との共同プロジェクト遂行におけるリスク要因』と題する論文を、「プロジェクトマネジメント学会誌」に原著論文として発表した(Vol.9, No.1)。これはエンジニアリング業界の経験をもとに、海外企業との協力におけるフォーメーション・デザインの問題に、初めて正面から切り込んだ研究であった。フォーメーション・デザインとは、プロジェクトの組織と役務分担の決め方のことを指している。単一企業のプロジェクトと異なり、複数企業で同じプロジェクトに取り組む際には、このデザインは簡単ではない。

秋山さんがこのテーマを選んだのは、日本企業と海外企業との共同事業に、どのようなフォーメーションで取り組むべきかが、その成否を決める大事なポイントだ、と考えたからだ。だが、あいにくわたし達が論文を発表して以来、あまり同様の問題意識による研究を見かけない。では、皆が海外企業との共同プロジェクト事業を、問題なく計画し進めているのかというと、必ずしもそうではあるまい。そこで、我々の論文の問題意識をおさらいしつつ、あらためて、良いフォーメーションとはどのようなものか、考えてみよう。

日本企業が海外に事業展開する場合、いきなり日本人社員が現地にいって出店を開いて、すぐ商売になるケースはほとんどない。ふつうは、当該国の事情に通暁した現地企業と、なんらかの協力関係を取り結ぶ必要がある。もちろん、商社や銀行など、先行して現地に地盤を築いている日本企業があって、最初はその道案内を頼りにすることも、あるだろう。だとしても、ビジネスを広げていくには、どうしても日系企業向け以外との、付き合いを増やすことになる。それも、いきなり共同で定常業務を立ち上げることはできないので、どうしても最初は初めての取り組み、いいかえれば共同プロジェクトを実施することになる。

海外企業との共同プロジェクト事業といっても、大きく分類すると、日本企業が商売の売り手の場合と、買い手の場合がある。さらに、その事業が、自発型のプロジェクトの場合と、受注型プロジェクトの場合との、4類型がある。これについては、以前「海外プロジェクトの質的変化と、成功体験の罠」 (2018-09-29)にも書いたとおりだ。この中で特に難しいのは、自分が弱い立場、すなわち受注型プロジェクトの売り手の場合である。そこで、このケースを例にとって、分析してみよう。

プロジェクトは、ものづくり型、サービス提供型、イベント型などに分けることができる。ものづくり型は、文字通り、物的な何らかの成果物を作って、顧客に引き渡すタイプである。たとえば橋を架けるとか、航空機を輸出するとか、水道を建設するとかいった仕事だ。「インフラ・システム輸出」はこのタイプと思っていい。サービス提供型は、たとえばソフトウェア開発とか、コンサルティングとかが該当する(日本企業は、国のスポンサーが付くODA案件以外では、不得意分野かもしれない)。イベント型は、文字通りイベントを開催するような種類のプロジェクトである。

こうしたプロジェクトでは、どれも最初は、何らかの成果物のデザインや設計の役務からスタートする。ついで、その設計をより詳細化して展開したり、原材料や機械・ツール類を手配する仕事が続く。そして、最終的には、製造や構築など、実装フェーズがくる。つまり、いってみれば序破急の3つのフェーズが最低でもあるのだ。

役務分担を考える際には、プロジェクトの仕事の全体を、ある程度の要素に分解する必要がある。プロジェクトのスコープを要素分解して構造化したものを、WBS(Work breakdown structure)と呼ぶ。つまり、フォーメーション・デザインにおいては、WBSをどのように切り分けて構成するかが問われることになる。上に述べた、「設計・調達・実装」のように、仕事の進むプロセスに応じた業務の分解のことを、Functional-WBS (略称F-WBS)という。

これに対して、もう一つの分解の方法がある。それは、成果物の構成単位に切り分ける方法である。たとえば航空機ならば、胴体・主翼部・エンジン・尾翼部、など。ITシステムなら、機能モジュール単位のサブシステム群や共通ルーチン、といった切り分けだ。プラント・工場だったら、製造ライン(ユニット)、ユーティリティ、タンク群、入出荷設備などのエリアを、それぞれ作る仕事という、切り分けになるだろう。このような仕事の分解のやり方を、Product-WBS(P-WBS)と呼ぶ。

ある程度以上の規模のプロジェクトの場合、F-WBSだけでもP-WBSだけでも不十分で、両者を縦横にしたマトリクスで、仕事の分解を考える必要がある(興味のある方は、拙著『世界を動かすプロジェクトマネジメントの教科書』 第2章を参照されたい)。

ここでは、プラント系の例を取り、簡略化のため、F-WBSは「設計・調達・建設」の3段階、そしてP-WBSも3つのエリアで考えよう。下図は、その3つの類型を図式化したものだ。

海外企業との共同プロジェクトにおけるフォーメーション・デザインは、どうあるべきか_e0058447_11402082.jpg
(佐藤知一・秋山聡『海外企業との共同プロジェクト遂行におけるリスク要因』 プロジェクトマネジメント学会誌. Vol.9, No.1, 2007より引用)

一番左の「垂直分業型」は、それをA社・B社・C社の三者が、F-WBS単位で、「設計・調達・建設」のフェーズごとを分担するタイプである。それぞれ技術に特化して強みのある会社、廉価で競争力のある製造業を抱える会社、そして現地の建設工事に強い会社が分担する、といったタイプだ。

ちょっと考えると、それぞれの強みを活かした分担のように思える。だが、落ち着いてみると、プロジェクト・マネジメントは結構、難しくなりそうである。まず、会社間で受け渡すインタフェースが非常に多い。A社からはすべての設計情報を、B社が受け取らなければ、調達はできない。B社からすべての資機材を受け取らなければ、C社は建設工事ができない。どこかに遅れが生じたり、品質問題でやり直しが出たら、誰が調整して責任を取るのか? 

真ん中の「水平分業型」は、逆に、P-WBSを軸に分担するタイプだ。こちらは、それぞれが担当するエリアの設計・調達・建設を、それぞれ遂行する。これもまた、製造ユニットとかタンク群とか、それぞれ得意不得意に応じて、分担を決めることになる。うまく得意分野が噛み合えば、効率よく進められそうだ。

ところが、このやり方にも問題がある。たとえば、工場・プラントの基本設計という仕事は、要するに全体の生産システムを決める業務からスタートするので、必然的に3社の間でインタフェースが生じる。かりにそこはうまく進められたとしても、建設工事の最後に、工場全体のスタートアップという仕事が来る。これまた、全部のエリアが関係する。ユーティリティの電力が来なければ、製造ユニットは動かせない。だが燃料タンクができていなければ、発電用ボイラーが起動できない、といった調子だ。

このように水平分業型では、最初と最後に、インタフェース問題が集中する傾向がある。だが、それでも途中は互いに独立に進められるので、まだしも「垂直分業型」より、エンジニアリング業界では好まれているように見受けられる。

ただ、ここに調達の問題が関わってくると、やっかいになる。たとえば、法規制によって現地国における調達比率を上げることが求められたりする。あるいは、共通の資機材(配管材料や鉄骨など)は、プロジェクト全体でまとめて買うほうが、安くなる、といった要請もあろう。さらにECAによる貿易保証枠や、決済通貨の比率、そして各社の売上額など、商務上の制約がからんでくると、単純に「垂直分業型」だけではすまなくなってくる。

で、結局、図の右のような「混成型」に、なりがちなのである。どうみたって、プロジェクト・マネジメント的には、一番複雑である。リスクは、異なる会社間のインタフェースに潜む可能性が高い。

各社が、共同プロジェクトで自社に損失になりそうなリスクを察知したら、どうするか? 本来は、互いに競技して問題解決を図るべきであろう。だが、相手は初めて組んだ、異国の会社だったりする。自分だけを守る行動にでないとも、限らないだろう。

このような協業に対する離反行動には、いくつかのパターンがある。ここでは詳しく述べないが、興味があれば前述の論文を参照されたい。

ともあれ、互いの離反行動を抑えるような方策も、最初に講じておく必要がある。その代表的な例が、「Profit & loss share」による協業の仕組みである。これは、プロジェクト全体で一つの財布を持ち、利益が出たら、予め決めた分担比率で、それを分け合い、逆に損失が出た場合も、損失を負担し合う、という取り決めだ。ふつうこれは、協業のための契約書に明記しておく。

このようにすると、各社が全体の利益のために、個社の利害を超えて調整しようというモチベーションが働きやすい。

では、各社が別々の財布を管理し続けるような協業の形態を、選びたいときはどうするか? その場合でも、たとえば「互いのミスによる損失は求償しない」といった約束を、契約に入れておくことがある。ミスは完全に防ぐことは不可能だ。だが、互いのミスで責め合っていたら、チームとしての結束にヒビが入りかねない。

海外企業との共同プロジェクトにおけるフォーメーション・デザインとは、以上のような観点を入れて、考えるべき問題である。そもそも、海外プロジェクトは難しい。おまけに、はじめての相手との共同プロジェクトもまた、難しい。難易度が高い仕事なのだから、仕事のデザインは、熟慮が必要なのだ。

ただ、論文にも書いたことだが、我々の業界では、海外企業との共同プロジェクトでリスクを検討する際に,カルチャー・ギャップが主要な議題になることは、あまり無い。

「理由の一つは,基本的な言語・生活習慣等の差異を,過去の類似プロジェクト経験により各社がかなり学習済みな点にある.しかしそれ以上に,『文化』という定義の漠然とした言葉によって,ステークホルダーの行動の潜在的問題を説明してみても,リスク分析は深まらないとの認識があるためである.

プロジェクトは企業同士の組織的行動であり,リスク要因の中心となるのは,個人レベルの生活習慣の違いよりも,会社レベルでの行動ベクトルの違いや,各社の仕事の進め方等の違いである.そうした差異の多くは,じつは経済合理性によって説明が可能であると筆者らは考えている」
(上記論文より引用、下線と強調は筆者)

簡単にいって、企業の行動というのは、各国の文化特性の差よりも、利益追求という共通性の方が、ずっと影響力が大きいということだ。だからこそ、異なる様々な国における、フォーメーション・デザインについて、共通した知恵が形成できるのだ。

秋山さんがずっと探求しておられたのは、プロジェクトにおけるリスクの問題だった。受注型のプロジェクト・ビジネスに於いては、契約と交渉がリスク・マネジメントの鍵になることが多い。その点を重視した秋山さんは、理系だったにもかかわらず、独学で法律を勉強し、司法書士の資格までとられた。東大大学院の講義でも、契約や交渉について、実技演習を交えてユニークな授業を行われた。

あの温和な口調と、独特のユーモアにもう接することができないと思うと、残念でならない。秋山聡氏から教えていただいた様々な事柄にあらためて深く感謝するとともに、故人の魂の平安を、今はただ祈るばかりである。


<関連エントリ>



by Tomoichi_Sato | 2020-11-28 18:00 | プロジェクト・マネジメント | Comments(0)

お知らせ:TOCシンポジウムでプロジェクト・マネジメントに関する基調講演を行います(11月30日 13:00-14:00)

またまた、お知らせです(^^)

TOC(Theory of Constraint)という考え方について、聞いたことのある方も少なくないと思います。イスラエルの科学者・故ゴールドラット博士が提唱したマネジメントに関する理論で、『制約理論』とも訳されますが、最近はTOCと略称で呼ぶ方が一般的でしょう。

TOCはサプライチェーン・マネジメント、プロジェクト・マネジメント、スループット会計、思考プロセスなど、幅広い分野に対する手法を提供しています。とくに90年代に、サプライチェーン・マネジメント分野に与えた影響は大きく、『全体最適』の思想や、生産スケジューリングのアルゴリズムなどにも、そのインパクトを見ることができます。

かくいうわたし自身も、1998年に出版した共著『サプライチェーンマネジメントがわかる本』(SCM研究会・編)の中で、ゴールドラット博士のTOCを、思考プロセスも含めて簡単に紹介しました。これは、まだ邦訳書のなかった当時としては、かなり早い紹介文だったと思っています。

ゴールドラット博士にはどこか教祖的な魅力があるらしく、TOCを実践に移す人たちのコミュニティは、日本でも着実に成長し、博士の没後も続いています。今年の「TOCシンポジウム」はコロナ禍の影響を受けてオンライン開催形式ですが、それなりに大勢の方が参加されると思います。

たまたまお声がけいただき、わたしも今年は基調講演をさせていただくことになりました。ただ、わたし自身はTOCについては素人ですので、得意の知ったかぶりは避けて(笑)、自分自身が考え出したプロジェクト・マネジメントに関する理論について、あえてお話するつもりです。そのエッセンスは、2010年に東大に提出した学位論文に書いている内容ですが(「リスク確率に基づくプロジェクト・マネジメントに関する研究」静岡大学出版・参照のこと)、今回はその後10年間の発展も含めて、できる限り分かりやすい形でご説明するつもりです。

最近は直前のご案内が多くて恐縮ですが、多くの方のご来聴をお待ちしております。


<記>

「TOCシンポジウム&TOCインダストリーフォーラム 2020」

講演タイトル「リスク確率に基づく価値評価とプロジェクト・マネジメントの提案

日時: 2020年11月30日(月) 13:00〜14:00
主催: 日本TOC推進協議会 他

講演概要:
 プロジェクト・マネジメントの目的は、「プロジェクトの価値を最大化すること」にあります。また、プロジェクト・マネージャーの仕事の中核には、つねに「決断」があって、複数の選択肢の中から、プロジェクトの価値が最も大きくなるものを選び取っていく必要があります。
 それでは、あなたの関わっているプロジェクトは、現在、具体的にいくらの価値があるのでしょうか? そして、プロジェクトを構成する各アクティビティは、全体の価値に対し、いくらずつ貢献しているか、ご存知ですか? 典型的なトレードオフ状況、たとえば、値段が高いが品質の良い外注先Aと、安いけれど品質に問題含みの外注先Bから、どちらかを選ぶ時、判断基準はありますか?
 本講演では、リスク確率に基づくプロジェクトの価値評価と、そのマネジメントについて解説します。さらにサプライチェーンの中での中間製品の価額決定や、生産部門と販売部門の貢献度の比較、そしてフロート日数を1日消費することは、いくらのコスト増に相当するのかといった問題を、全く新しい視点から解決します。

申込み: 下記をご参照ください

以上、よろしくお願いいたします。


佐藤知一@日揮ホールディングス(株)


by Tomoichi_Sato | 2020-11-21 00:43 | プロジェクト・マネジメント | Comments(0)

「プロジェクト&プログラム・アナリシス研究部会」(10月8日)開催のお知らせ

各位:

「プロジェクト&プログラム・アナリシス研究部会」の2020年第3回会合を開催いたします。COVID-19感染症問題がなかなか落ち着きを見せないため、研究会日程が定まらず、前回からまた間が空いてしまいました。今回もオンライン開催といたしますので、ご了承ください。

現在のモダンPM論は、設計のマネジメントという重要な仕事について、ほとんど何も語っていません。この問題は、以前から指摘してきたとおりです。エンジニアなら誰でも知っている通り、設計は構築・実装のあり方の大勢を決めます。ですから、きちんとプロジェクトを進めたければ、まず良い設計をすることが先決です。ダメな設計を受け取って、「あとはよろしく」と言われたって、プロマネとしてできることは限られているからです。

しかし、この自明の理に正面から向き合って、プロジェクト・マネジメントを論じる人はわずかです。PMBOK Guide(R) の規定している10のマネジメント知識エリアにも、『設計のマネジメント』は含まれていません。PMBOKの次期・第7版は、従来の構成を根底から変え、プロセスベースから原則(Principle)ベースに転換すると言われています(10の「知識エリア」は、なくなる見込みです)。しかし、現時点では、プロジェクト・デリバリーの原則の中にも、設計論は見当たらないようです。

プロジェクトの成果物が価値あるアウトカムを生み出すためには、その設計が重要です。しかし現実のエンジニアは、過去の事例のコピー&ペーストや、外注先との折衝・チェックといった仕事に忙殺されているようです。設計の業務プロセス自体が、個別化・属人化している事の現れかもしれません。まして、肝心の設計ロジックの構築や、その伝承理解に使える時間は限られています。

今回は、自動車メーカーの設計部門を経験した後、大手ITベンダーでPLM等のコンサルティングに従事してこられた西本明弘様に、設計プロセスの分析・最適化技法である「Design Structure Matrix (DSM)」手法についてご講演いただきます。
昨年12月の梓澤様のご講演に続いて、「設計論シリーズ」の第2弾となる企画です。どうぞ、ぜひご期待ください。


<記>

■日時:2020年10月8日(木) 19:00~20:15

■講演タイトル:
「Design Structure Matrix(以下DSM)の概要と応用~テレワーク時代のプロジェクト管理手法~」

■概要:
設計・開発プロセスは暗黙的かつ多職種連携で、手戻り要因も判りづらい。また、テレワーク時代で細かなコミュニケーションもとりづらく、プロジェクト運営のリスクは増している。
そこで、設計工学手法DSMを応用し、設計プロセス全体を俯瞰してプロジェクトを最適計画&省力運営(PMの負担軽減)する方法について解説する。

■講師:プロセス設計塾 代表 西本 明弘
 
■講師略歴:
三菱自動車にて小型トラック・バスのシャシーフレーム設計。   
IBMにて金融・POSプリンター、自動改頁機構、漢字OCRスキャナーなどの開発。    
IBMにてPLMコンサルタントの後、プロセス設計塾を開業。
2003年より研究しているDSMを用いて、複雑な業務プロセスの改善を支援中。

■シスコシステムズさんのご厚意により、WebExを用いた、オンライン開催となります。
 研究会への参加は、下記のURLからご登録ください。

 はじめてWebexに参加される方は、下記の説明資料も御覧ください(Dropboxへのサインインは不要です)。

 なお、オンライン形式のため、リアルの研究会よりも講演時間は少し短縮しています。ただし、講演とQ&A終了後、希望者だけで別途、オンライン懇親会を行う予定です。

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 
 以上、よろしくお願いいたします。


佐藤知一@日揮ホールディングス(株)


by Tomoichi_Sato | 2020-09-24 18:18 | プロジェクト・マネジメント | Comments(0)

プロジェクトの発想を活性化させる、『チームの思考能力』とは何か?

「あなたは、同期30人の集まるパーティの幹事になりました。
 あなたが最初にすべきことは何ですか?」

以前も書いたが、これは、わたしがプロジェクト・マネジメントを学生や社会人に教えるときに、最初に出すクイズの一つである(「Structured Approachができる人、できない人」)。「店を探して予約する」「日取りを決める」「参加者を確定する」、等々、いろんな答えが考えうるし、どれも間違いとは言えない。しかし、わたしがあえてPM講義の最初にこの問いを出すのは、「計画を立てる」という、もう一段抽象度の高い答えが欲しいからだ。

時限的で一過性の取り組み、それも複数の人が関わって、失敗のリスクも伴うような事に取り組む際は、「まず計画を立てる」という思考習慣がほしい。言われなくても、当たり前のことである。そう思う人も多いだろう。ただ、その『当たり前』が、ちゃんと意識され言語化されていてほしいのだ。

ちなみに上記の記事を書いたのは、8年前の2012年7月だ。この年、わたしは東大大学院の柏キャンパスで、毎週金曜日の午後に「プロジェクト・マネジメント特論」の講義を持つようになった。東大PM講義の資料をもとに、2015年には著書『世界を動かすプロジェクトマネジメントの教科書』を上梓した。もっとも、大学の講義同様では面白くないので、製造業の若手エンジニアを主人公にした、ストーリー仕立ての対話編である(わたしが本を書くときは、なぜか対話篇が多くなる)。

東大柏キャンパスの講義は、今年からは同じ勤務先の後輩に譲ることにした。とても楽しい仕事で好きだったのだが、移動も含め毎週、半日を割くことが、次第にきつくなってきたのである。ただ、同じ東大の本郷キャンパスでの講義は、まだ引き受け続けている。こちらも10年くらいやっているが、年2コマのみなので、時間的にはずっと楽である。幸い評判も良いらしく、複数講師の交代する形式だが、毎年、継続のリクエストを頂いている。

ところで今期は、パンデミック禍の影響で、どこの大学もオンライン授業形式になっている。だから先週の東大本郷の講義も、横浜の自宅からzoomで行った(東大はzoomが標準らしい)。わたしは授業を極力、インタラクティブにやりたい人間なので、ずいぶん勝手が違ったが、まあそこは仕方がない。

プロジェクト・マネジメントの入門編を教える場合、まずは「アクティビティ」の概念と、WBSについて理解して貰う必要がある(無論、ここでいっているWBSとは、プロジェクト・スコープの階層的構成の意味であり、世間で誤解しているようなガントチャートのことではない)。

これを教えるため、上記の同期会パーティの質問に加えて、わたしは次のような簡単なグループ演習を出すことにしている。

「あなたは同期30人の集まるパーティの幹事になりました。企画のはじめから、パーティを終えるまで、やらなければならない作業(アクティビティ)をすべて洗い出してください。
 ただしアクティビティは、1枚のカードに1つずつ、必ず動詞を使って書くこと。」

こういって、いつもは学生たちを二人一組に分け、それぞれの組にPost-It!の付箋カードを、20枚ずつ配って考えさせている。もちろんパーティについては、予算その他、もう少し条件をつけて説明し、イメージが湧きやすいようにしてある。こうすると、一気に教室の中が活性化し、隣同士でああでもないこうでもないと、議論雑談が始まるようになる。

わたしは教室の中を巡回して、課題がちゃんと理解されているかどうかをチェックし、進んでいない班には相談に乗ったりして、授業を進めることにしている。パーティの幹事とは、いいかえればプロジェクト・マネージャーである。プロマネがプロジェクトを始めるにあたり、計画の第1ステップとして、やるべきアクティビティを洗い出してリストアップする。これを体験してもらうのが、この演習の狙いだ。

ところが今回はオンライン形式だったので、やむなくzoomのブレークアウトセッション機能を使って、二人一組に分けて、考えてもらうことにした。Post-Itは配れないので、Excelの表を共有してもらい、そこに書き出すやり方である。

簡単な、ある意味で他愛もない演習だが、学生たちの頭がブーンと回りだす音が聞こえる。ここが楽しいところだ。なぜなら、事を始めるにあたって、最初にやるべきアクティビティ(作業)を、全部洗い出してリストアップする、という行為自体を、たいていやったことがないからだ。

全アクティビティの洗い出しというのは、プロジェクトの最初から最後までを、頭の中でシミュレーションすることに他ならない。パーティ程度なら身近だから、想像力さえ惜しまなければ、別に有名大学の学生でなくたって、ちゃんとできる。逆に東大生だって、考えなければ、答えは出てこない。この問題は正解のない、暗記型では解けない問題だからだ。

この演習をやっていると、開始して10分をすぎる頃から、議論の声で騒がしかった教室の中が、しだいに静かになってくる。だんだんと、洗い出すべきアクティビティの種が尽きてくるのだ。アクティビティの数も、足りなければカードを追加で配る、と宣言してるが、20を超えることはめったにない。これはどこの大学だろうが、あるいは社会人だろうが、あまり変わらない。わたし達の頭の作りは、だいたい似たようなものなのだろう。

そこで、12〜15分たった時点で演習を打ち切りにし、どこかの班を指名して、出した答えを言ってもらう。カードに書き出したアクティビティを、順不同でいいので、はしから読み上げてもらうのだ。他の班は、それを聴きながら、自分たちの出した答えと、どこが一致して、どこが違うかを考えてもらう。聞いているうちに、「え、それがあったか!」という顔が、あちこちに浮かんでくる。

たとえば「店を予約する」とか「参加者数を確定する」とかは、どの班でも書いている。しかし「部屋の飾りつけの調達をする」とか「司会プログラムを作成する」とか「二次会を予約する」とかは、まちまちだ(別に必須ではないから、ないと間違いだとはいえない)。

そして、「参加費を集める」はあっても、「終わってから会計報告をする」は忘れる班が多い。だが30人の集まるパーティともなれば、費用は10万円をかるく超えるだろう。だとしたら、会計報告はしたほうが良いよ、と学生には教える。

時間があるときは、もう一班くらいに、答えを言ってもらう。案外違っているものだし、それでいいのだ。その違いを体験してもらうことが、もう一つの狙いだからだ。

わたし達が頭の中でプロジェクトをシミュレーションするとき、その想像は個人個人の見方、観点によって、かなり固定されてしまう。だから、二人一組で演習するのである。二人で話し合うと、自分の盲点や死角になっていた部分を、相方が気づくことがある。

でも、二人で考えても、まだ視点は固定されがちで、見えていない。それは3人目、4人目がいて、やっと気づくことだったりする。それが、チームの力なのだ。複数の人間で、異なる視点から、対象となる問題を分析して、総合的に考える。一緒に考える能力を持つことーーそれがチームの能力なのである。

チームワークというと、スポーツで、ポジションを決めてパスを回したり、スクラムを組んで一緒に押したりすることを思いがちだ。それはそれで大事である。しかし、複数の人間が同じ問題を、多面的・総合的に考える、というのも、チームの効果だ。このときは、各自の分担や持ち分を超えて、互いに対等に発想できることが大事になる。「複合的な知の創出」だとか「グループによるデザイン思考」、などとカッコつけてよんでもいいし、三人寄れば文殊の知恵、という古い諺を出しても良い。

下の図は、以前「どうどう巡りの議論を避けるために」に描いたものの再掲である。ディスカッションでは、視点が限られているため、ある時間を超えるとだんだん煮詰まっていってしまう。しかし、そこに新しい視点が加わると、また一段レベルがあがるケースが多い。
プロジェクトの発想を活性化させる、『チームの思考能力』とは何か?_e0058447_15253563.jpg
このように、東大生が一人でウンウン考えるよりも、普通の人間が数人寄り集まって、あれこれ議論し合うほうが、こうした想像力の部分では、まさることが多いのだ。このことは、暗記上手で、正解をすばやく手繰り寄せるタイプの受験教育を受けてきた学生には、ちゃんと理解して貰う必要がある。もっとも、直接対面している方が、 オンラインより創発効果は高いが、それでも意義は実感できるだろう。

逆に言うと、プロマネは、自分のプロジェクト・チームが、お互いにフランクに議論して、「知の創出」が闊達に起きやすいよう、組織をマネージしていく必要がある、ということだ。

そしてこれが、とても難しい。たいていの会社組織は、ピラミッド型の構造になっている。上司部下・先輩後輩の関係があり、能力もこの順に高いはずだ、ということになっている。予算や人事評価の仕組みも、その構造の中に組み込まれている。上司一人と部下数名でプロジェクト・チームを組んだ時、その中で、対等に議論できるのか?

わたし達の社会で、チームが知的生産性において十分機能しにくい理由は、チーム内のディスカッションがちゃんとできないからだ。理由は3つほど考えられる:

(1) 権威の存在

上司先輩は、仕事の能力・経験において上である、という建前がある。事実かどうかは別として、彼らは仕事上の意見において、より大きな権威をもっている。意見が異なる場合、権威を持つ側の発言力のほうが強い。賢い上司は、自分の意見は言わずに、部下や若手の発言を待つものだが、(わたし自身を含めて)さほど賢くない上司は、部下の話を遮って、自分の意見を先に出したりする。そうすると、その時点で新しい視点や発想も、打ち止めになってしまう。

(2) 権力者への忖度

上司自身ももちろん、権力を持っている。もっとも、プロジェクト・チームの場合は、複数部門からのメンバーがいて、直属の上司部下関係とは限らない。だが、たとえばプロマネより、もさらに上級のマネージャー(部長や役員など)が、プロジェクト・スポンサーとして影響力を持っていることも多い。この場合、当然ながらチーム員は、その意志を「忖度」して物事を決めやすい。「自分たちとしては、この方式が良いと思う。でも役員は、あの方式を望んでいるんだろうなあ」という具合である。このような場合、判断の結果に自分たちのオーナーシップ(当事者意識)を持ちにくいから、問題が表出すると挫折しがちになる。

(3) 批判・質問を嫌う態度

ワイガヤ的議論では、「なぜ?」「誰が?」「どうやって?」といった質問を投げかけることで、さらに発想をかきたてることが大切だ。だが、他人から質問されると、まるで批判されたかのように反応する人も、案外多い。質問の仕方にも上手下手があるのは事実だが、質問を封じられたり自粛したりしていたら、そこで新しいアイデアの種は芽を出さずに終わってしまう。

ことに(3)番目の問題は根が深い。わたしは授業だとかワークショップだとかをいろいろやってきたが、多くの場合、最後に「ご質問はありますか?」とたずねても、海外と違い、日本ではほとんど挙手して質問する人がでないのが普通だ。だから、本当に相手が理解してくれたのか、講演する側が逆に不安になる。それは、質問=批判である、という通念が邪魔するのかもしれない。ただし日本でも、メールや紙で質問を出させると、それなりに出てきたりする。質問を活性化させるには、一種の「心理的安全性」が必要なのだろう。

かつてオズボーンが「ブレーン・ストーミング」技法を案出した際には、「他人のアイデアを批判しない」をルールにした。しかし質問までは禁じていない。質問=批判を嫌う態度は、「俺の言うことが聞けない(伝わらない)のか?」というスタンスである。逆に言うと、「このアイデアの所有権は俺自身だから、意見への質問・批判は俺に対する批判になる」と考えている訳だ。

こうした態度は、プロジェクトを個人やグループ単位に細分化して分業させ、その間で互いに競わせるような競争原理型の組織で、強まりがちだ。アイデアの発案者=アイデアの権利者、という考えでいる限り、「良いアイデアは組み合わせで生じる」「生まれたアイデアはチーム全体のパフォーマンスを上げるための、共有財産」との思想には、たどり着けない。分業・競争型組織は、繰り返し型オペレーションでは効率的かもしれないが、プロジェクトの計画・設計段階ではクリエーティブになりにくいのである。

それでも、天才的なリーダーがプロジェクトを率いて、彼が一から十まで全てを完璧に計画すれば、仕事はうまくいくはずだ、というのが英米式の思想なのかもしれない。PMBOK Guideなどをよんでいると、紙面の背後にそういった考えを、うっすらと感じるときがある。わたし達の社会も英米型に影響されやすいので、「天才型リーダー」を嘱望する声は高い。

ただ、社会がそんなに大勢の天才を供給できないのも、事実である。東大生は天才的に頭がいい、と思っている人も世の中には多少いるかも知れないが、本人たちに「貴方は天才ですか?」と聞いてみれば分かる通り、そんなのはまるきり見当違いである(笑)。無論、稀には本当に頭のいい人もいたりはするが、そうした人の社会適合性が高いかといえば、また別だ。

わたし達は基本的に、個人個人ではそんなに頭の良くない存在なのである。視点も限られていて、記憶力も頼りなく、判断ミスもする。それでもチームとしてなら、もっと高い思考能力を持つことができる。もし良い成果を出したければ、誰かリーダー個人に頼るのではなく、組織レベルで「知的生産能力」を確保するしかない。そのためにはチームが、対等で率直な議論=ディスカッションの場になるよう、工夫していく必要があるのだ。

<関連エントリ>


by Tomoichi_Sato | 2020-07-11 15:45 | プロジェクト・マネジメント | Comments(0)

「プロジェクト&プログラム・アナリシス研究部会」(5月14日)開催のお知らせ

来る5月14日(木)に、2020年の「プロジェクト&プログラム・アナリシス研究部会」第2回会合を開催します。今回は、PMにおける感情のマネジメントを社会心理学の視点から考えるため、東洋大学の北村英哉教授をお招きしました。昨年から継続的に議論している、『感情』シリーズの第3弾です。

プロジェクトとは不安定なもので、良い方向であれまずい方向であれ、いったん転がりはじめると加速度がつきやすい傾向があります。こうした不安定さには、プロマネ自身やチームのメンバーがもつ、無意識の『感情的バイアス』が、大きな役割を持っていると想像されます。しかしプロジェクトにおける感情の問題は、これまであまり注意を向けられたことがなく、せいぜい組織のモチベーション・アップや報奨とからめて論じられる程度でした。

北村先生の『偏見や差別はなぜ起こる?』によると、偏見などのバイアスは、社会心理学的には「態度」の一種であり、そこには認知・感情・行動の3つの側面がある、のだそうです。無意識のアンコンシャス・バイアスは、認知的には「ステレオタイプ」として現れ、感情的には「偏見」となり、結果としてコミュニケーションを阻害していきます。そして行動面では、社会的差別にまでつながりうる訳ですが、最近のコロナウィルス禍で、わたし達はあらためて、差別がいかに起こりやすいかを実感しています。

プロジェクト・マネジメントの基本は、現実を客観的に見ることにあります。もちろん、だれしも無意識の思い込みから完全に自由にはなれませんが、そのメカニズムがどう働くかを知ることはできます。社会心理学という耳慣れない研究分野の知見が、わたし達の仕事において役立つヒントを提供してくれると期待しております。大勢の方のご来聴をお待ちしております。

(なお、現在の緊急事態宣言と外出自粛要請が、どのような形で明けるかは、まだ不明です。場合によっては、リアル会合+Web会議、あるいはWebのみでの研究会実施とする可能性もありますので、ご了承ください)


<記>

■日時:2020年5月14日(木) 18:30~20:30

■場所:田町キャンパスイノベーションセンター 
 5F スペース:509AB
 (JR田町駅の芝浦口から右方向の階段をおりて、50mほど先の右手の建物です)

■講演タイトル:
「無意識の思い込みの弊害: 感情の社会心理学の観点から」

■概要:
組織内でも対外的にも役割に伴い、人はステレオタイプ的なイメージをもち、それが無意識のうちに働くことでコミュニケーションの阻害要因となることがあります。
こうした無意識の思い込みともいえる「アンコンシャス・バイアス」について近年の知見と、具体例、実践的な対処などをめぐって、感情研究の観点から議論したいと思います。

■講師:東洋大学教授  北村 英哉
 
■講師略歴:
東京大学大学院社会学研究科博士課程中退 博士(社会心理学)、
関西大学教授などを経て、現在、東洋大学社会学部社会心理学科教授。
専門は、社会心理学、感情心理学。 
主要著作:『偏見や差別はなぜ起こる?』(ちとせプレス、共編著、2018年)、『心の中のブラインド・スポット』(北大路書房、共訳、2015年)、『進化と感情から解き明かす社会心理学』(有斐閣、共著、2012年)など。

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。

 以上、よろしくお願いいたします。


佐藤知一@日揮ホールディングス(株)


by Tomoichi_Sato | 2020-04-14 23:21 | プロジェクト・マネジメント | Comments(0)

誰が決断を下すのか? 〜タスクフォース組織のすすめ

先週は入社式のシーズンだった。しかし今年はコロナウィルス禍の影響で、式自体を延期したり、全員集合の形式をやめて、オンライン配信にした企業も多かったはずだ。新入社員の側も、さぞや不安だったろうと思う。通常であれば、入社式のあとは、しばらく集合研修の形で新人教育を行い、その後に正式に部門配属になる。だが、今年はそれも分散型でオンライン教育が中心になるに違いない。

なにせ「人の和」を重視するのが、わたし達の社会の文化だ。だから顔と顔を突き合わせ、親しさを重ねることで組織を作り上げていくスタイルが、好まれる。そして一斉採用なので、「同期」という絆も生まれる。米国の会社のように、個別採用で、入社したら1時間程度の簡単なガイダンスがあるだけ、あとは業務マニュアルをポンと渡されて、割り当てられた仕事をしていく、という風ではない(もちろん米国にだっていろいろな企業があり、これは一部の例だが)。

日本では、民間企業を始め、官庁・公的機関などほとんどの組織が、『機能型組織』(Functional organization)と呼ばれる形態をとっている。だから、入社して組織に配属されるとは、何らかの機能を担う部署の、ピラミッドの一番下に所属することを意味する。

機能型組織とは、図に示すように、上に役員層(エグゼクティブ)がいて、その下に部門長(ミドル・マネジメント)がおり、さらにその下に部員がいる構造になっている。各部門は、それぞれ異なる機能的な役割を担う。たとえば図では、「設計」「調達」「建設」の例を示したが、もちろん業種業態によって、「営業・製造・物流」だったり、「診療・看護・医事」だったり、いろいろだろう。自分の業種で、読み替えて見てほしい。
誰が決断を下すのか? 〜タスクフォース組織のすすめ_e0058447_07534120.jpg
各機能は、さらに、インプット・業務プロセス・アウトプットが、だいたい決められている。設計ならば、設計の予条件や顧客要求などがインプットで、設計計算や結果のチェックや作図・仕様書作成などの作業を経て、2D/3D-CADの製作図面やモデル、技術仕様書、操作マニュアル、部品表(BOM)のリストなど、アウトプットを生み出す。

こうした機能型組織の特徴は、機能(要素技術)をベースとして、分業によって業務を進めていくことだ。部門(部署)ごとに、担当する仕事の種類が異なる(営業/会計/製造など)。各部門は、その機能的な能力・技術を磨くことで、最大効率を目指す。そして部門内では、能力・スキルや経験年数により、序列がつくられ、秩序をもって運営されていく。

機能型組織の長所は、技術蓄積・継承・業務改善が行いやすい点だ。セールスならば営業部門、設計ならば技術部門、経理ならば会計部門、という風に、仕事を進める技術やスキルの、オーナーシップが明確になっている。そして、とくに製造業の場合、権限(予算執行や人事評価)は、ライン部門長に集中している。

ただし、欠点もある。分業によって部門間に壁ができやすい、部門を超えた人材の流動性が抑えられがち、といった事がそうだ。しかし最大の問題は、複数の部門が協力して当たらなければならないような、緊急の課題や、期限付きの活動が、進めにくい点にある。

拙著『世界を動かすプロジェクトマネジメントの教科書』 では、そうした例の一つとして、新製品開発の事案をとりあげた。ある製造業の社長が、たまたま訪問した先の海外企業のトップと意気投合して、その新興国の市場向けに、共同で製品を開発する約束をして帰ってくる。主人公はその会社で働く若手のエンジニアで、技術部門に属しているが、まだ製品開発をリードできるような立場ではない。ただ、明らかに複数部門が関わらなければ、成功しないことぐらいは分かる。

開発案件の担当メンバーの一員となった彼は、その案件の行く末を心配して、大学時代の大先輩にどうしたらいいか、アドバイスをもらいにいく、という設定である。

だが、なぜ主人公は、そういう心配をしたのか? もう一度、図を見てほしい。こういった組織図の、縦横を結ぶ線のことを、英語でなんと呼ぶか、ご存知だろうか。答えは、"Reporting line”だ。つまり、文字通り、レポート(報告)する関係を示す線である。具体的に、誰がどの人に対して報告するか(あるいは逆に、指示がおりるか)を、この線があらわしている。

会社の公式なコミュニケーションは、全部このReporting lineに沿って動かすのが、ルールである。線が結ばれていない人同士は、直接、指示や報告のやり取りはしない(食堂や部活でおしゃべりするような、非公式なコミュニケーションは別として)。ある部門の担当者が、別の他の部門の担当者と、なにか依頼や相談をしたい場合は、線に沿って、部門長を経由して伝達する必要がある。

たとえば設計の担当者は、設計部門長にまず書類や事案を上げ、設計部門長はそれを、調達部門長に渡す。調達部門長は、それを担当者に下ろす。これが会社組織の、公式なルールである。それをバイパスしたりショートカットしたりすると、部長から「俺は聞いていないぞ。勝手なことを決めてくるな!」と叱られたりする。なぜなら部門長は、部内の業務すべてに、一応責任を負っているからだ。

ところで、このような会社に、複数部門にまたがって緊急対応が必要な事案が、何かふってわいたら、どうするか? たとえば拙著にあげたような製品開発でもいい。あるいは今回の、コロナウィルス禍への対策などでもいい。

たとえば図の一番下の点線で囲まれた部分のように、ある事案なりプロジェクトに関わる担当者たちが、何か調整をしなければならなくなったとしよう。その際、彼らは公式なレポーティング・ラインを通してしか、やりとりができない。組織のルール上は、直接お互いに話をすることができないからだ。

しかし、個別の事案の個別の調整を、全部、部長を通して行うのは、果たして現実的だろうか? 部長同士の会議(部長会)なんて、どこの会社でも、せいぜい週に1回か、2週に1回程度だろう。当然ながら、コミュニケーションのスピードが非常に遅くなる。

じゃあ、設計部長が個別事案の相談のために、調達部長や建設部長のところに出向いていって、話すのではどうか? かりに部長同士が、ちょうど空いている時間をうまく取れたとしても、話し合いの結果、意見が対立したら、どうするか。

日本企業はコンセンサス(合意)で進むのが、基本だ。しかし、それでも合意できなかったら、誰が最終的に決断を下すのか? まさか、物理的に声の大きい人か? いや、そんな事はあってはならない(はずだ・・たぶん)。

もちろん組織図上には、「役員」がいる。だが多忙な役員が、個別の事案の調整まで全部、面倒など見きれる訳がない。

ちなみに、具体的な完了条件(ゴール)があり、複数の人が協力する必要があり、そしてリスクがあるような種類の仕事を、『プロジェクト』と呼ぶ。機能型組織では、結果として、複数の機能部門にまたがるようなプロジェクトを進める際に、問題が発生しやすくなる。部門間の課題について、誰が決断を下す人なのか、不明になるからだ。これが、機能型組織の限界だ。

いいかえると、部門横断的に(これをクロス・ファンクショナルといったりする)進めるべき事案が生じても、プロジェクト・マネージャーが存在しないのである。プロマネがいないのだから、プロジェクトの期限(納期)や必要なコストについて、全体を見て判断し、責任を負う者がいないことになる。したがって、プロジェクトの遂行スピードが遅く、誰も終了時期を確約できない状況になりがちだ。

日本の製造業は、機能型組織が強い。逆に言うと、複数の事案やプロジェクトを効率的に回すのには、あまり長けていない、といえるだろう。そしてこの事が、日本企業の競争力を阻害する大きな原因になっているのである。というのも、新製品開発競争や、新市場の開拓、そしてサプライチェーンの海外展開など、部門間を超えて対応しなければいけない課題が、今日では目白押しだからだ。

では、どうするべきなのか? その答えが、『タスクフォース』型チームの組成である。

タスクフォース(Task force)という言葉は、元々米軍が使い始めた、軍事用語である。日本語で言えば「機動部隊」に相当する。すなわち、特定の課題(Task)に対応するために、臨時で動員した人員組織(force)を意味する。

タスクフォースにアサインされた人は、原則として、もともと所属していた部署の仕事は中断して、その特定課題の仕事に専任する。通常は、執務場所も移動して、タスクフォース・チームとして同じ場所に顔を合わせる。そしてチームのリーダーやサブリーダーの指示の下に、仕事をする。そうして、最終的に所定の任務を達成したら、チームは解散となり、メンバーは元の部署に戻っていく。だからタスクフォースは、時限的な組織である。

これに対して、機能部門はパーマネント(永続的)な組織である。永続的だから、若手の教育研修とか、技術蓄積とか、業務改善といったことにも取り組む。タスクフォース・チームでは、原則としてこういった事は行わない。そもそも、仕事のできない、「使えない」人材は、普通タスクフォースにはアサインされない。きちんと能力をもった選りすぐりのメンバーを、一時的に集めて、機動的に課題に当たるのである。

なお、「タスクフォース・チーム」と、「プロジェクト・チーム」は同じものか、違うのか、という問いがある。ネットを調べると、タスクフォースは短期的で、プロジェクト・チームは長期的な仕事に使う場合が多い、などという解説が出てくる。

だが上に述べたように、時限的(有期的)で明確なゴールがあり、複数の人間が協力して当たらないと成功しないような仕事は、原理的にすべて『プロジェクト』である。だから基本的に、両者は同じものだ。実際、欧米のメジャー企業では、Project task force(PTF)という言い方も、よくしている。

タスクフォースの特徴は、とりくむ特定課題について、責任を任されている事だ。必要な権限と、予算と、人員をつけられている。だからこそ、機動的に判断して動けるのである。逆に言うと、細かいこともいちいち上の判断を仰がなければいけなかったり、予算の執行権がなかったり、勝手に人を引き剥がされたりするようでは、タスクフォースは課題解決の責任を負えない。

無論、予算枠が足りない、人が足りない、といった問題は現実にはありがちだ。しかし、だとしたらタスクフォースのリーダーは、その事実を上位マネジメントに訴えるべきだし、逆に上位の管理者(会社の重要なタスクフォースだったら普通は役員層)は、タスクフォースがちゃんと任務を果たせるよう、支援する責務がある。

タスクフォースでは、リーダーが、強いリーダーシップを持つことが大事だ、といった解説もよく見かける。もちろん、それは大切だ。だが、もっと大切なことがある。それは、

 「チームのメンバーは、自分の元の部署の利害や部門長の命令ではなく、タスクフォース・のリーダーの判断に従う

という行動習慣を全員が持つことだ。それを周囲も認めることだ。

たとえば自分が物流部門出身だったとしよう。ある時のリーダーの指示・判断が、どう見ても物流コスト的に余計かかりそうだったとする。仮にたとえそうだとしても、タスクフォースにいる限りは、その指示に従う必要がある。もちろん、リーダーに意見を言うことはあっても良い。しかし、最終的な判断の権限は、リーダーにある。

そこで、出身母体の物流部門の価値基準を優先して、指示を実行しなかったり、あるいは物流部門長にかけあって反論したり、してはいけない。タスクフォースのリーダーと、もとの所属部門の部長の意見が異なったら、タスクフォースの指示で動くべきだ。そうしないと、部門間の合意で決めていたスローなやり方と、何も変わらなくなってしまう。

リーダーはいろいろな角度から、課題の全体像を見て、判断するはずだ。もしかしたら、かりに結果として物流コストが上がっても、製造リスクが下がるのかもしれない。どちらにしても、結果に対する責任は、タスクフォースのリーダーが負うからだ。責任と権限範囲は、対応しなければならない。これが組織の原則である。

時限的で、緊急度が高く、集中して取り組まなければならない課題については、ある程度、権限もタスクフォースのリーダーに移譲(集中)する必要がある。それは、一時的な処置である。安定した時期は、部門間のコンセンサスと、公式なレポーティングラインだけで仕事を動かしてもいい。緊急時は、そうはいかない。

ところが、長らく機能型組織の中だけで生きていると、この原則が見えなくなりがちだ。部門間のバランス・オブ・パワーで生きていると、誰かに一時的に権限が集中するのを、反射的に嫌う傾向がでてくる。これが、タスクフォース組織を活かせるかどうかの、一番のボトルネックなのだ。

もちろん、これは、物流のことをろくに知りもしないリーダーが、何でも勝手に決めていい、という意味ではない。そのために、物流部門から「仕事のできる」メンバーをタスクフォース・チームに入れてもらったのである。そのメンバーも、物流の観点から課題を考え、影響を考慮し、リーダーに提案しなければならない。

つまり、タスクフォース組織を組む際には、影響のありそうな関連機能の部門から、なるべく広くメンバーを入れる必要がある。課題やプロジェクトに利害関係を持つ人のことを『ステークホルダー』と呼ぶ。タスクフォース・チームは、外部のステークホルダー(つまり社内の関連部署の部門長たち)から、やいのやいのと助言だの苦言だのをもらって右往左往せずにすむように、あらかじめステークホルダーの技術や知見を「内部化」しておくのである。

逆に言うと、機能部門長は、タスクフォースに人を出してほしいと要請された場合、余っている人を出すのではなく、ちゃんとした能力を持つメンバーを出す必要がある、ということだ。これもまた、多くの日本の組織では、言うは易く行うは難し、である。部門長は、自部門の都合を第一に考える習慣が強いので、有力なメンバーを割かれるのに抵抗感を持つからだ(それに、大抵の組織では、そもそも有能な人が足りない)。

また、上記に関連して、タスクフォースは、独立した予算枠と執行権を持たなければならない。特定課題に関連する物流コストがアップしても、それは物流部門の成績に集計されるのではなく、タスクフォースのコストになる。こうして、外部からの独立性を担保するのである。

上に述べた拙著『世界を動かすプロジェクトマネジメントの教科書』のケースでも、本当は、共同製品開発のためのタスクフォース・チームの設置を、すぐに社長が命じるべきだったのだ。だが、社長はそういう事をしないで、案件を、ただ機能型組織に任せた(丸投げした)だけだった。誰がプロジェクト・マネージャーで、どう決断していくのかすら、分からない。そういう状況下にあって、主人公がどう動くか、またそれを助けるための組織的な形態は何か(著者としては実はこの部分の解決に苦労したのだが)、ご興味があればぜひお読みいただきたい。〜以上、コマーシャルの時間でした(笑)。

ともあれ、まとめよう。タスクフォース・チームとは、特定の課題を解決するために、時限的に集められた組織である。それがちゃんと機能して活きるためには、守るべき条件がある:

(1) タスクフォース・チームは、独立した権限と予算執行権を持つ
(2) 幅広い関連部署から有能なメンバーを集める
(3) 各メンバーは(出身部署の利害代表者として動くのではなく)、タスクフォース・チームのリーダーの決断に最終的に従う

このようにして、機動的な部隊を動かし、「誰が決断を下すのかわからない」状態を避けるのである。

ただし上記の「幅広い関連部署」を考える際には、ある問題や対策が、どこまで広い影響範囲を持つのかに関して、きちんと豊かに想像力を働かせる必要がある。想像力と書いたが、それは、物事の依存関係(連鎖的な因果関係)を、幅広くたどっていける論理的な思考能力である。

いいかえると、タスクフォースを成功させるためには、『システムズ・アプローチ』が大事だ、という事だ。じゃあ、そのシステムズ・アプローチとは何か、という話になるが、これはまた深い議論が必要なので、別の機会にまた書こう。


<関連エントリ>


by Tomoichi_Sato | 2020-04-07 08:18 | プロジェクト・マネジメント | Comments(0)

プロジェクトの生産性と着地点を測るには

2015年7月、東芝は過去7年間に渡って、「不適切会計」で1500億円以上も利益をかさ上げしてきた、という第三者調査委員会の報告を公開した。これに伴い、田中社長を始め、歴代3社長が退任。日本の産業史上最大の不正会計事件となった。

このときの不正に、実はプロジェクトの『進捗率』の計算が、深く関わっていた。というのも、会計操作の手法の一つが、「進行基準」の悪用だったからだ。

「ああ、会計の話なんか興味ないよ。技術屋としての俺の仕事には関係ないから」とお思いの方も、その手口については、少しだけ知っておいたほうがいい。というのも、これは進捗率をどう粉飾するか、という話だからである。しかも、先々のコスト増を無視していると、結果的に売上や進捗率を粉飾したことになってしまう事があるのだ。そして売上や原価は、エンジニアたちの尻を叩くモノサシでもある。妙な叩かれ方をしたくないならば、少しはその仕掛けについて学んでおくべきだ。

一般に受注型プロジェクトの会計には、完成基準進行基準の二種類がある。そして、複数年次に渡る大規模なプロジェクトでは、進行基準が望まれる。進行基準では、プロジェクトの進捗に従って、毎期ごとに、収益(売上)が計上できる。これに対して、完成基準では、プロジェクトが完了しないと売上が立てられないからだ。普通の経営者にとっては、何よりも売上高が命であり、数年もの間「売上ゼロ」では、何も仕事していないのか、と言われてしまう。

進行基準は、「工事進行基準」とも呼ばれる。建設業会計の世界で発達した手法だからである。しかし作るものが無形のソフトウェアであろうと、工事を伴わぬ大型機械の製造だろうと、考え方は同じだ。

さて、当時の東芝は、次の計算式で工事収益を計上していた(「東芝不適切会計と工事進行基準」清和監査法人」による):

当期の工事収益 = 工事収益総額 × 工事進捗度 - 過年度工事収益計上額
 ただし、工事進捗度 = 累計工事原価発生総額 ÷ 工事原価総額

この計算式自体は、ごく普通のものだ。建設業であれ、受託ITシステム開発のSIerであれ、進行基準に従う多くの企業は、こうして計算しているはずだ。

東芝の不正手口は、「工事原価総額」を少なめに見積もることで、「工事進捗度」をかさ上げする、というやり方だった。いや、少なめに見積もる、という表現は正確ではない。じつは、プロジェクトの途中で予想されたコスト増を、無視して繰り入れなかったのだ。これによって約500億円もの根拠なき売上が立った、と言われている。そして東芝の会計監査法人は、この問題点を見過ごしていた、としか思えない。

「進捗率」を水増しすれば、架空の売上が手に入る? どうしてだろうか。

たとえば、今、受注金120億円のプロジェクトがあったとしよう。この案件は、開始から完成まで、たっぷり3年かかる。そして、プロジェクト原価は100億円、利益額は20億円と計算されていた。想定される年度別の計画は、次のようなものであった:

     発生原価  累計原価  進捗率 
1年目  20億円  20億円  20%
2年目  30億円  50億円  50%
3年目  50億円 100億円 100%

上の式で、進捗度 = 累計原価発生総額 ÷ 原価総額、とあるとおりだ。そして、各年度で、それぞれ計上できる売上と、その年度の発生原価から見た利益額を計算すると、次のようになる:

     発生原価  累計原価  進捗率  計上売上  年度利益 
1年目  20億円  20億円  20%  24億円   4億円
2年目  30億円  50億円  50%  36億円   6億円
3年目  50億円 100億円 100%  60億円  10億円

さて、このプロジェクトの1年目の終わり近くになって、問題が起こった。技術的なトラブルと、顧客側の無理難題が重なって、完成までにさらに40億円もの追加費用がかかりそうだ、という状況が判明したのだ(2年目に10億円、3年目に30億円のコスト増)。まあ、「判明」というのは、経営者にとってであって、担当者レベルでは、最初の頃から「このプロジェクトはまずいな」と思っていたのかもしれないが。

ともあれ、このままでは受注総額120億円に対し、原価総額=140億円になってしまい、赤字プロジェクトに転落である。かりにトラブルのスケジュールへの影響が小さく、なんとか3年以内に終わるとしても、正しくは次のような表になるはずだ。

     発生原価  累計原価  進捗率  計上売上  年度利益 
1年目  20億円  20億円  14%  17億円  ー3億円
2年目  40億円  60億円  43%  34億円  ー6億円
3年目  80億円 140億円 100%  69億円 ー11億円

1年目の進捗率が20%→14%に、2年目の進捗率が、50%→43%に、それぞれ下がった点に注意してほしい。これは、累計原価の総額が100億から140億円に増えたためだ。そこで、
1年後の進捗率: 20÷140=14%、
という計算になる。

だから計上できる売上も、
1年目の売上: 120×14% = 17億円
に減ってしまうのである。結局、17億の売上で、20億円のコスト発生だから、マイナス3億円の赤字になる。2・3年目も同様の計算で、売上は34億と69億、原価は40億と80億で、都合、6億円と11億円の赤字だ。

さて。この計算表を見て、不心得な経営者がこう考えたら、どうなるだろうか?
「トータル40億円のコスト増だって? そんなの、まだ確定していないじゃないか。少なくとも今期のコストはまだ増えていない。来期以降の増分は、最後に確定してから膿を出せばいいのだ」

かくて、現実を無視して累計原価の総額を2年目まで変更せず、最後に帳尻を合わようとすると、こうなる:

     発生原価  累計原価  進捗率  計上売上  年度利益 
1年目  20億円  20億円  20%  24億円   4億円
2年目  40億円  50億円  50%  36億円  ー4億円
3年目  80億円 100億円 100%  60億円 ー20億円

バンザイ! かくて当年度の売上は17億ではなく24億に増え、収支も3億円の赤字から、4億円の利益になる。経営者にとって、赤字と黒字では天国と地獄ほど違う。

お分かりだろうか? プロジェクトで今後発生しそうな(合理的に予見できる)コスト増を無視すると、進捗率も売上も、本来よりもカサ上げできるのだ。だが、結果的にそれは粉飾になる。現実の東芝で起きた事件は、米国の原子力子会社と孫会社を巻き込んでもっと複雑だが、本質だけを単純化すると、上の例のようなことになる。そして、赤字か黒字かは、各社員のボーナスの査定や昇進のみならず、事業部の存続までかかってくる問題なのである。

・・ところで、ここまで我慢して(?)読んでこられた真面目な技術者諸賢は、疑問を感じられたことだろう。「トータル40億円のコスト増って、どうやって推算したんだ? そんな事が、全部終わって金勘定を締める前に、わかるのだろうか? そんな事が分かるくらいなら、誰も苦労しないじゃないか!」

もちろん、本当に「合理的に予見可能」な原価というからには、個別のワークパッケージ単位に、追加変更のコストを積上げ、その発生する蓋然性を評価しなければならない。大規模プロジェクトでは、そこまでプロジェクト・マネジメントを徹底することが求められる。でも、読者が知りたいのは、もう少し身近なプロジェクトの場合だろう。とくに、スコープ=役務範囲の柔らかい(例えばIT系などの)、プロジェクトの場合に違いない。そんなの、本当に可能なのか、と。

ところが、将来のコスト増を、ある程度の精度を持って推算する方法があるのだ。そこにEVMSの技法が関わってくるのである。

前回の記事(「進捗率を何で測るか? −−情報処理技術者試験の問題より」)で、わたしは、「進捗率は、今までどれだけ頑張ったかではなく、あとどれくらい仕事が残っているかで測るべき」と主張した。

では、「あとどれくらい仕事が残っているか」をどうやって推算するのか。答えは、CPI (Cost Performance Index)という、プロジェクト遂行の生産性を測る指標によるのだ。プロジェクトのCPIは、次式で定義される量である:

 CPI = EV / AC

つまり、その時点までの出来高(EV)を、その時点までの実績出費累計(AC)で割った数字である。出来高EVとは、完了したアクティビティの予算の合計であった。もしEVとACの両者がぴったり一致したら、計画通りに仕事が進んでいる訳で、CPIは1になる。EVが1よりも大きければ、当初計画したよりも実績コストは小さくすんでいることになる。逆に、思ったよりお金がかかっているなら、CPIは1以下になる。

さて、米国では国防総省を中心に、EVMSに関する膨大なデータの蓄積がある。それによると、プロジェクト全体のCPIの値は、良きにつけ悪しきにつけ、全体工期の2割を超えた時点から、±10%以内の精度で安定することが分かっている。良いなら良いなりに、まずいならまずいなりに、傾向が定まるのだ。

たとえば前回の出題の例では、EV = 5.9、AC = 7.0であった(単位は人月)。だから、

 CPI = EV / AC = 84%

である。簡単に言うと、100円使って、84円分の成果しか上がらないのだ。プロジェクトの生産性が84%と言い直しても良い。

では、このプロジェクトの累計原価発生総額(完成予定額 EAC = Estimate at Completion ともいう)は、どうなるか? 元の見積では、全部で10人月で終わるはずだった(これをBAC: Budget at Completionと呼ぶ)。一方、これまでに、AC=7.0人月使ってしまった。残っている仕事量は、10 - 5.9 = 4.1人月分になる(元の見積ベースでは)。だが、これも84%の生産性で補正しなければならない。つまり

 EAC = AC + (BAC - EV) / CPI = 7.0 + 4.1 / 84% = 11.9

結局、約12人月だろう、ということになる。つまり、2割ほどコスト増が予想されるのだ。

ちなみに、プロジェクト初期の段階では、CPIの値はかなりアバレるから、まだ推算には使えない。この例では、すでに進捗率=59%なのだから、プロジェクトも中盤に入っており、CPIの値は安定すると予想できる。

なお、プロジェクトを構成する各アクティビティは、それぞれ種類も違う固有の業務内容を持っているのに、CPI値が安定するのは奇妙に思えるかもしれない。しかし、独立した変動を持つ分布を足し合わせると、全体としては分散が小さくなる、というのが統計学の教えるところだ。では、そのような推算が成り立つためには、どれくらいの要素数が必要かと統計学者に聞くと、「中心極限定理から、30以上は必要だ」と答えるだろう。

全体の2割を過ぎた時点で、30個以上のアクティビティの実績データが必要だとしたら、EVMSで完成予想額を見るためには、プロジェクト全体では150個以上のアクティビティからなるWBSを持つことが、条件になる。EVMSというのは、それなりの規模のプロジェクト向けの手法なのである。だから例題のような、トータル10人月程度のプロジェクトにEVMSを持ち出すのは、いささか「牛刀をもって鶏を割く」きらいがある。

ここまではまあ、普通のPMの教科書に書いてあることだ。ところで、この話にまだ、少しだけ先がある。12人月で終わりそうだ、という着地点の推測は、本当はまださらに、補正が必要なのである。

実を言うと、EVMSから導出されるプロジェクトの生産性指標は、もう一つある。それがSPI (Schedule Performance Index)で、次式で定義される:

 SPI = EV / PV

ここでPVは、元の計画上での進捗率である。たとえば、本来70%終わっているはずの計画だったのに、実際の出来高基準では59%しか進んでいないなら、CPI = 59/70 = 91% という事になる(ちなみに問題文には計画上の15日時点の進捗率は書かれていないから、上記の91%というのは、単なる例である)。

SPIは、スケジュール面から見た、プロジェクトの効率性を表す。先に紹介したCPIも、このSPIも、分子にEVが来ている点を覚えておいてほしい。SPIもCPIも、値が高いほどよい。1よりも大きければ、計画より効率よく遂行できていることを示す。

そして、米国で蓄積した膨大なEVMSデータによると、プロジェクトの完成予定額EACは、次の式で計算するほうが、より現実のデータに合うというのだ:

 EAC = AC + (BAC - EV) / (CPI・SPI) = 7 + (10 - 5.9) / (0.84 * 0.91) = 12.4

つまり、先ほどの推算よりも約0.5人月分、さらにコスト増になるという計算だ。

この計算式は、Flemming & Koppelman: "Earned Value Project Management, 2nd Edition", PMI, pp.136-137, 2000.(邦訳「アーンド・バリューによるプロジェクトマネジメント」)に解説されてる。ただ、日本のPM関係の教科書参考書の類では、なぜかあまり書かれていない。日本語版Wikipediaにも、現時点ではのっていない。

それにしても、残っている仕事量(BAC - EV)を、なぜCPIとSPIの両方で割るのか? 明確な理論的説明がある訳ではない。ただ、コスト超過しているプロジェクトは、スケジュールも遅れているので、全体工期が延びる分だけ、さらに余計に費用がかかるようだ、という経験知を示している訳である。

以前の記事で、わたしは「進捗率は予算消化率では測れない」と書いた。実を言うと工事進行基準とは、「進捗率=予算消化率」という定義になっている。ただ、そのかわり、「予算には、今後発生する合理的なコスト増を組み入れること」という形になっている。なので、コスト増が起きると、分母が増えて、進捗率がその分下がることになる。結果として、「残っている仕事量」が反映されるのである。

ソフトウェア開発の売上計上に工事進行基準が義務付けられるようになったのは、2009年からのことである(企業会計基準第15号「工事契約に関する会計基準」及び企業会計基準適用指針第18号「工事契約に関する会計基準の適用指針」)。その1〜2年前から、大手SIerの間で、「これからはもっと真面目に(定量的に)進捗管理をしなければならい」という議論がかわされていたのを、覚えている。

そして、さらに2021年4月以降は、ソフトウェア業界も、会計が「収益認識基準」に変更される。こちらは「もっともっと真面目に」役務項目別のコントロールが義務付けられる。これに各社は、準備対応できるのだろうか。

ちなみに上の説明で、「わずか10人月程度のプロジェクトにEVMSを適用するのは、大げさすぎる」という意味のことを書いた。しかし、そのような態度にも、一つ利点がある。社内で、大小様々なプロジェクトに関するデータが蓄積できることだ。

米国では国防総省が中心になって、EVMSの適用を進めてきた。また90年代以降、一定金額以上の公共事業にも、EVMSの適用が求められるようになった。彼らは、データを蓄積することの威力を、知っているのだ。上に述べた「工期の2割以上をすぎるとCPI値が安定する」といった知見も、そこから得られたものだ。

事実とデータに基づいて、マネジメントが予測と決断を下すこと。そうしなければ、強い軍隊や、勝てる組織などというものは、維持できないというのが、米国流の経営思想である。勇敢な兵士や鬼軍曹だけでは、戦えないのだ。正しいデータと分析が、重要だ。気合と根性だけでは、仕事はスケーラブルにならない。

EVMSという手法には限界もあって、万能ではない。しかし、その限界を知りつつ使ってデータを蓄積するのと、その手法を知らないために使いもせず、データも取らないのとでは、長い間には天と地ほどの差ができる。ITという仕事が、データから有用な情報を組み上げるためのものならば、わたし達自身の仕事についても、やはり数値化の努力をすべきだろう。


<関連エントリ>
 →「
」 (2020-02-08)


by Tomoichi_Sato | 2020-02-18 23:36 | プロジェクト・マネジメント | Comments(0)

「プロジェクト&プログラム・アナリシス研究部会」(2月20日)開催のお知らせ

各位、

来る2月20日(木)に、2020年の「プロジェクト&プログラム・アナリシス研究部会」第1回会合を開催します。今回は、PM教育のためのゲームを開発された、日立ドキュメントソリューションズの岡田様にご講演いただきます。

プロジェクト・マネージャーの人材不足にはどこも頭を痛めており、優れたプロマネの育成研修は焦眉の急です。しかし、プロマネに必要とされる知識とスキルの幅はけっこう広く、身に付けるのは簡単ではありません。

当研究部会でも3年ほど前から「PM教育分科会」を組織して、独自の研修カリキュラムを開発してきました。ただし限られた時間内に、PMのソフトスキルとハードスキルの両面を伝えるのは、至難の技です。

日立さんのアプローチのユニークな点は、モノポリー的なカードゲームを元に、主にソフトスキルにフォーカスした問題解決力の教育を組み込まれた点です。教育における「ゲーミフィケーション」の効果は、最近つとに指摘されていますが、短時間に集中して考える取組みとして興味深いものです。またファシリテーターによる丁寧な指導も、実践的な価値を高める工夫のようです。

プロマネの育成について悩んでいる多くの方に、役立つ内容になると期待しております。開催日の直前のご案内になってしまい恐縮ですが、ぜひご来聴ください。


<記>

■日時:2020年2月20日(木) 18:30~20:30

■場所:田町キャンパスイノベーションセンター 
 5F スペース:509AB
 (JR田町駅の芝浦口から右方向の階段をおりて、50mほど先の右手の建物です)

■講演タイトル:
「ゲーミフィケーションを用いたビジネス人間力養成の取り組み」

■概要:
プロジェクトの現場において、プロジェクトマネージャは発生する問題やリスクに対して限られたリソースの中でその都度適切な意思決定を行うスキルが求められる。これらのスキルは実践訓練などを通して習得できるものであるが、習得には多くの体験を経る必要があり時間を要す。そこで、ゲームを通してチームでプロジェクトを模擬体験する実践訓練手法を開発した。ここで得られるスキルは、プロジェクトマネジメント分野に限らず、ビジネス全般に必要なソフトスキルであると考える。講演では、プロジェクトマネジメント分野以外への展開可能性や、ゲーム中の振る舞いによるプロジェクトマネージャの特性評価の取り組み、ゲームの臨場感向上のためのデジタル化/ゲーム空間の開発に関する取り組みを紹介する。
●YouTube:プロジェクトマネージャの”感性”を磨くボードゲーム「プロ・トレZ」プロモーション映像リンク先
* ダイジェスト版 ・・・・2分
* フル版 ・・・・21分

■講師:岡田 久子
 株式会社日立ドキュメントソリューションズ EPCプロジェクト本部 本部長

■講師略歴:
1998年日立製作所に入社。大規模発電所等の建設管理、および建設管理システムの運用・高度化業務を経て、
2014年より日立ドキュメントソリューションズへ移り、プロジェクトマネジメント支援業務の取り纏めに従事。

■参加費用:無料。
 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。
 参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。

 以上、よろしくお願いいたします。


佐藤知一@日揮ホールディングス(株)


by Tomoichi_Sato | 2020-02-12 07:24 | プロジェクト・マネジメント | Comments(0)

進捗率を何で測るか? −−情報処理技術者試験の問題より

仕事の進捗(しんちょく=進み具合)を何で測り、どう数値化するか。これはいつも悩ましい問題である。

「プラント・エンジニアリング会社のように、物理的に目に見えるモノを作っている分野は、数量が測りやすいからいい。ソフトのように目に見えない成果物を作る仕事は、進捗管理がとても難しい。」

・・こういう意味のことを、IT業界の方から何度か言われたこともある。いえいえ、どういたしまして。プラント・エンジニアリングのプロジェクトでは、設計業務だけで18ヶ月〜24ヶ月もかかる。この間、膨大な図面や仕様書が生成されるが、プラント予定地では1年後にやっと、基礎工事のための穴掘りが始まる程度だ。設計作業の進捗をどう捉えるかは、同じように悩ましい。

もちろん、具体的なものづくりに携わっている企業だって、進捗をタイムリーに正確につかむのは難しい。同時並行に進む作業が多いし、その負荷の大小だって、様々だからだ。

ところで、情報処理技術者試験に「プロジェクトマネージャ」という種目がある。IPAの試験制度の中でも、いわゆる「高度」に分類される資格の一つだ(一応、わたしも持っている)。さて、今を去る2004年秋のことだが、この試験に、進捗率に関して、次のような問題が出たことがある(一部佐藤が改編して引用):

* 10本のプログラムからなるシステムを完成させるプロジェクトがある。
* 1本のプログラムを完成させるには1人月の工数がかかると見積もられた。
* 各プログラムの開発作業は、設計(20%)→コーディング(50%)→テスト(30%)のプロセスからなると推定された。
* 作業開始から15日たった時点で進捗状況を調べたら下記のとおりだった:

* 現時点での進捗率を求めよ
進捗率を何で測るか? −−情報処理技術者試験の問題より_e0058447_21440942.jpg
・・という問題である。

どうやらこのシステム、ほぼまったく同一規模のサブシステム・プログラム10本からなっていて、なおかつ、その間のインタフェースも結合テストもいらないらしい。随分とありそうにない、不自然なシステムだが、まあ試験問題だから文句を言っても仕方がない。

とにかく10個のタスク(アクティビティ)があり、それぞれが設計・コーディング・テストの3段階からなるから、全部で30個のサブタスク(サブ・アクティビティ)から構成されたプロジェクトだ、ということになる。

進捗率を問われている訳だから、なにか基準となるモノサシが必要だ。では、一番単純に考えて、「完成したプログラムの本数」を基準にしてはどうか? 全部で10本のプログラムを作らねばならない。15日たった現時点で、できあがったのは3本だけだ。だったら、3 / 10 = 30%ではないか。

これはこれで、シンプルで分かりやすい尺度である。これをかりに『完成数基準』と呼ぶことにしよう。

ところで、別の考え方もありうる。プログラムが完成まで至っていなくても、設計やコーディングがそれぞれ終わっているのなら、一定の進捗があったと言えるはずだ。で、その進捗率は、どう測るのか。それは、工数によるウェイトがいいと思う。

15日たった現時点で、設計は10本とも完了している。設計の工数はそれぞれ0.2人月と見積もられている。またコーディングは6本完了だ。1本あたり0.5人月だから、3人月分の仕事が終わっている。そしてテスト。これは3本×0.3人月で、0.9人月分。だから合計、5.9人月分の仕事までは進んだ訳だ。だから、全体工数の10人月で割ると、5.9 / 10 = 59%となる。この考え方を、『見積基準』と呼ぼう。

いやいや、よく考えてみよう。工数の見積なんて、いつでも大した精度がなく、あてにならないものだ。ウェイトをつけるなら、実際に掛かった工数を重みにすべきではないか。表によれば、設計には合計2.5人月、コーディングには4.0人月かかり、テストにも1.5人月使っている。合計7.0人月だ。だとするならば、進捗率=70%が妥当ではないか。この考えを、『実績基準』と呼ぶことにする。

結局、この問題は、次の三つのどれかを選べ、という問いになる:

3/10=30%? (完成数基準)
5.9/10=59%? (見積基準)
7.0/10=70%? (実績基準)

さて、あなたなら、どれを選ぶだろうか?

上の3つの計算例でも分かる通り、進捗には、さまざまな定義が可能である。いわば決め事の問題であって、その点で原価管理にも似ている。原価にも、様々な計算手法がありえる。その中から、どれを選ぶかは、企業のマネジメント方針次第なのである。

しかし、『進捗率』を数字で計算する以上、合理的かつ整合的な算定方法として、皆が合意できることが条件になる。

その観点から、完成数基準の計算:
 3/10=30%
を見ると、どうなるだろうか?

15日目の現時点で進捗率30%ならば、100%完成まで、15 / 30 * 100 = 50だから、あと50日かかる計算になる。じゃあ、このプロジェクトは、あと35日必要だと言えるだろうか?

進捗管理の目的は、きれいな進捗レポートを作ることではない。進捗率を測る最大の目的は、完了日を予測するためにある。完成数基準は分かりやすく単純だが、この目的のために有用だろうか?

考えてみてほしい。横軸にプロジェクト開始からの日数を取り、縦軸に進捗率をとって、グラフにプロットするとする。もしこのプロジェクトが理想的に進めば(=つまり、各プログラムが予定通り並列に開発されると)、29日目までは完成数=ゼロである。30日目に、10本のプログラムが全部、同時に完成する。

進捗率のグラフは、ずっと0%のまま29日目までx軸にはりついていて、30日目にいきなり100%になる。このグラフを見て、完了日の予測ができるだろうか? 理想的にプロジェクトが進むと、完了時点が予測できなくなるような基準は、役に立つだろうか。
進捗率を何で測るか? −−情報処理技術者試験の問題より_e0058447_21464971.jpg

では逆に、実績基準の計算:
 7.0/10=70%
は、どうか?

いま仮に、現在までにトータルで9人月かかったとすると、90%進捗、ということになる。もし12人月かかっていたら、120%進捗、という計算にならないだろうか? これは明らかに不合理である。

予算消化率で進捗率は測れない。これまで、どれだけ頑張ったか、どれだけ工数や予算を使ったか、で進捗を測ってはいけないのだ。この点はよく覚えておいてほしい。世間の人は、ここを誤解しているケースが非常に多いからだ。

進捗率は、今までどれだけ頑張ったか、ではなく、あとどれくらい仕事が残っているかで測るべきなのだ。

では、あとどれくらい仕事が残っているのか。それは、未完了の仕事(コーディング4本とテスト7本分)を見る必要がある。その仕事量は、4 * 0.5 + 7 * 0.3 = 4.1人月だと見積もられている。全体が10人月分の仕事量だったのだから、41%残っている。となると、進捗した分は、差し引き100 - 41 = 59%となる。

したがって、見積基準の計算:
 5.9/10=59%
が正解らしい、とわかる。

実を言うと、この当時、経産省主導の資格試験は、正解を公表していなかった(もっと後には公表するようになったが)。だから、上に述べたのは、あくまでも佐藤の推測した回答である。しかし、これが正解だろうと思う。なぜなら、この見積基準の進捗率とは、EVMS (Earned Value Management System)の標準的な手法だからだ。

EVMSは、モダンPMの技法の三本柱の一つだ。EVMSでは、進捗率を次のような方法で定義する。

1. 各Activityに見積った工数を、ProjectにおけるそのActivityの価値とする
2. 全Activityの価値の合計は、Project全体の価値に等しい
3. 完了したActivityの価値の合計を、「出来高」(アーンドバリュー)と呼ぶ
4. 出来高をProject全体の価値で割ったものを進捗率と定義する

この問題では、完了したサブ・アクティビティの価値(見積もられた工数)の合計は5.9人月だった。だから、5.9 / 10 = 59%になるのである。いいかえると、EVMSの進捗率計算は、見積基準なのだ。

さきほど、完成数基準で進捗率のグラフをプロットすると、値がずっとゼロのままで、使い物にならなと書いた。逆に言うと、進捗率計算の主目的が完成日予測にあるのならば、理想的な進捗の指標とは、グラフがちょうど直線で進んでいくような形だろう。これならば予測は、かなりやりやすい。

これに対してEVMSの進捗カーブの形は、通常、もう少しS字カーブ型になる。プロジェクトの最初はゆっくりと立ち上がり、やがては活況に入ってぐんぐんと進捗があるが、最後の方になるとまたカーブが寝て、ゆっくりとした収束になる。だからプロジェクトの一番初期と、一番最後の頃は、EVMSの進捗率から完了日予測を正確にするのは難しい。しかし両端の時期を除けば、まあまあ予測には使える。こういうこともあって、EVMSの進捗率計算は広く使われている(少なくとも欧米では)。
進捗率を何で測るか? −−情報処理技術者試験の問題より_e0058447_21501962.jpg

ただし、EVMSの進捗率によるコントロールは、万能ではない。この点についてはすでに何度か記事も書いたので、ここでは繰り返さない。だが、舶来の手法で、試験問題にも繰り返し出されると、なんだかそれが『正解』だと思い込み、暗記してそのまま従うような風潮が、わたし達の社会には無い訳でもない。

繰り返すが、進捗率計算というのは、いろいろな定義が可能なのである。少なくともそれが合理的で整合的である限りは、各社がいろいろと工夫して使っていい。ただ一つ言えることは、「過去こんなに頑張りました」という事をベースにして計算してはいけない、という点だけだ。

これまでの努力を言いたい気持ちは、もちろんわかる。それをきちんと、ステークホルダー達に説明する必要もある。だが、それは過去に属することだ。言ってみれば、タクシーメーターの料金なのである。ここまで、これだけ走り、料金換算でこれだけかかりました。だが、タクシーメーターをいくら懸命に見つめても、この先いつになったら目的地に到着できるかは、分からない。つまり、進捗の指標にはならないということだ。

進捗コントロールというのは、もっと未来志向の行為なのである。


<関連エントリ>
 →(2010-02-17)

 → (2019-05-26)


by Tomoichi_Sato | 2020-02-08 21:56 | プロジェクト・マネジメント | Comments(1)

エンジニアリングとは統合力(インテグレーション能力)である

「エンジニアリング」という言葉を聞くと、読者諸賢はどのような仕事を想起されるだろうか。都会的なオフィスで遂行する、理知的な設計とデザインの仕事? それとも製図板と作業着とノギスをともなう、泥臭い仕事? あるいは企画と要求仕様だけを与えて、どこか海の外でやってもらう設計の力仕事?

エンジニアリング会社』と呼ばれる職場で、もう30年以上も働いている。会社には、机と椅子とPCと、あとは人が並んでいるだけだ。自社の工場は持っていない。建設現場はあるが、建設労働者を雇っているわけでもない。資機材は世界中の製造業の会社に頼んで作ってもらい、物流業の会社に頼んで現場まで運んでもらう。据付け組立工事は、現地の工事業者にお願いしてやってもらう。

じゃ自分たちは何をやっているかというと、設計図や仕様書を書いて、あとはプロジェクト全体をマネジメントしている。だから従業員は全員がホワイトカラーで、それも8割以上がエンジニア職種だ。

わたしの属するエンジニアリング業界には、国内で「専業」と呼ばれる大手が3社あるが、どこもほぼ同じような業態である。もっとも、国内には「エンジニアリング」と名前のつく企業が、大小様々に存在するし、分野もいろいろだ。わたしの勤務先は、「プラント・エンジニアリング」と呼ばれることも多い。ただしプラントばかりを作っているわけではなく、各種工場から病院まで、いろいろな施設を作っているので、『総合エンジニアリング』を自称している(が、たしかに売上の8割はプラント系である)。

こうした(プラント)エンジニアリング会社は、顧客にプラントや工場を作っておさめるのが仕事だ。なお日本では「プラント」と「工場」は別のものを指す(と思われている)が、英語で工場長はPlant Manangerであり、自動車工場はCar manufacturing plantである。だから両者を無理に区別する意義は、あまりない。

エンジニアリング会社とは、実は製造業やエネルギー産業の、生産技術部門(とくに工務部門)が独立してアウトソーシング先となった業態である。生産技術とは、製品設計と製造をつなぐ、「工程設計」「生産設備設置」を担う仕事だ。

こういう職務は、仕事量に波がある。増産と新工場設置のときは忙しく、定常運転に入ると暇になる。だから社内に抱えるより、アウトソーシング先として独立したほうが、お互い便利である。わたしの勤務先はたまたま、最初から独立したエンジ会社だったが、ライバル企業たちは、石油会社や化学会社の工務を担う子会社として出発した。

この業界では、工場づくりのプロジェクトを「EPC」と略称することが多い。EPCはエンジニアリング(Engineering)・調達(Procurement)・建設(Construction)の頭文字である。だが、先ほど書いたように、PとCの実作業は、外部の企業に発注するのが原則だ。自分で手を動かしてやっているのはE(エンジニアリング)のみである。だからまあ、「エンジニアリング会社」と呼ぶのかもしれぬ。

で、そのエンジニアリングというのは、冒頭に書いたようにカッコいい仕事なのか、泥臭い仕事なのか? 実は、エンジニアリングの日常というのは、次のような事の起きる日々である・・

***

<ある日の、機械設計部門にて>

「大変です。例のリアクター機器ですが、発注先のメーカーから、外形サイズが大きくなるって連絡が来ました。」
「どれくらい?」
「全体で、xxくらい増えるらしい、と。」
「いまさら勘弁してよ。もう配管設計部門に、ノズルの位置情報を渡して、設計をはじめてもらっているぜ。手戻りになるじゃないか!」
「そうですね。」
「それだけじゃなくて、機器の近くのパイプラック自体にも、位置的に影響するかもしれないな。ぎりぎりのレイアウトだから。なんでそんなにサイズが変わったの?」
「保温のためのジャケットの条件に変更が出たんです。顧客の要望で、上流側のプロセス設計部門から連絡がありました。それをメーカーに伝えたら、サイズに影響が出ますと返事が来たんです。」
「まずいな。それだと費用の追加請求も言ってくるぞ。納期にも影響が出るかもしれない。配管設計部門と調達部門と、一緒に相談したほうがいい。」

<その日の午後、配管設計部門の会議卓コーナーで>

「これだけサイズが増えると、機器周りの配管ルートをかなり変える必要がありますね。配管長も増えるし、コストアップになります。ラックとの距離を元のままにして、機器全体の位置をずらせないんですか?」
「逆側のメンテナンス用アクセスにも制限があって、もう壁からギリギリなんです。」
「調達の立場から言うと、このメーカーとの過去の経験から見て、確実に追加を言って来るね。まあウチが変更指示を出したんだから仕方ないけど。」
「納期は?」
「そっちの方が心配です。メーカーの側に余分な材料の在庫がなくて、サブオーダー(注:発注先の機械メーカーから、資材メーカーに手配をかけること)を出すとなると、2〜3ヶ月かかる可能性ありかも。」
「そんなに遅れたら、建設の機器搬入スケジュールに間に合わなくなるな。」
「納期もありますが、もう一つ。これ、機器全体の重量も増えますよね。そうすると、基礎にも影響するかもしれません。」
「げげ。建設現場ではもう、コンクリート基礎の工事が始まっちゃているぜ。どうしようか?」
「対案は2,3考えられますが、影響範囲が広いから、ぼくらだけでは決められません。エンジニアリング・マネージャーを呼びましょう。」

<翌朝、プロジェクト・ルームの会議室にて>

「・・皆さん忙しい中、緊急に集まってもらってすまない。例のリアクター機器No. KK-ZZZのサイズ変更への対応を、すぐに決めたい。まず、現状の位置のままサイズが増えた場合のインパクトを、各部から言ってほしい。下流側から行こうか。まず建設と調達から。」
「3ヶ月も納期が延びたら、建設の搬入据付けスケジュールがひっくり返ります。あの機器を据え付けないと着手できない後続工事がみんな遅れます。プロジェクト全体の納期に影響がありえます。」
「調達として心配なのはコストアップですね。あのメーカーはこういうチャンスに、必ず余計に上乗せして要求してきますから。」
「じゃあ設計側にいって、配管の影響は?」
「サブパイプラックが近くにあるので、干渉を避けるためには配管ルートを迂回する必要があります。」
「そうなると調節弁の位置も変わるね。計装のケーブルルートも見直さなけりゃ。」
「重量増による構造設計へのインパクトは?」
「今の程度の重量増なら、コンクリート基礎への影響は限定的です。幸い余裕は見ていました。」
「助かった。さすが。」
「ただ搬入のためのスペースが増えるので、架構の柱スパンに引っかかります。工事がそこだけ遅れます。」
「うーむ、そうか。とにかく、影響度合いは分った。対案は3つ。今の機器位置のままでいくか、場所を強引にずらすか、それとも入口の上流側の温度条件を変えて、リアクターのジャケットサイズがあまり増えないようにするか。」
「どれも簡単じゃないですが。」
「うん。でも、とにかく各案のPros/Consを表にまとめて書き出そう。その上で、コストと納期に一番インパクトが少なそうなものを選んで、決めることにする。」

***

まあ、これはいくつかの事実をもとに作ったフィクションである。まるで1日で決着するように書いたが、現実はもっと時間が掛かるし、こんなにカッコよくはない(笑)。ただ、肝要なポイントはおさえたつもりだ:

(1) エンジニアリングには複数の専門技術分野がかかわっている
(2) エンジニアリング・マネージャーという職種がいて、設計分野間の調整と意思決定をする
(3) エンジニアリングには基本設計→詳細設計という流れがあり、その一部は外部組織(発注先のメーカーなど)が担っている
(4) エンジニアリングの意思決定は、設計の品質や効率や整合性だけでなく、調達から実装までの全体を見て判断すべきである
(5) エンジニアリングにおいては、外部からの変更・変動への対応が、不可避である

エンジニアリングとは、基本デザインから実装までをカバーする仕事である。広義のエンジニアリングは、基本設計や要件定義に始まり、資機材やツールの調達、実装・設置工事・建設、そして試運転といった領域までの業務を含む。つまり発明・アイデアを現実化するまでの、トータルな仕事をさす言葉として、使われる。もう少し狭義には、基本デザインをインプットとして、それを実装可能なレベルにまで詳細設計する仕事を指す。その場合にも、様々な分野の工学的な要素技術を組み合わせて使うことになる。

エンジニアリングとは統合力(インテグレーション能力)である_e0058447_15401504.jpg
そしてエンジニアリングという業務の中心にあるのは、統合=インテグレーションである。

複数の機能要素を組み合わせて、全体として有機的な働きを実現するような仕事を、インテグレーション(統合)と呼ぶ。『有機的』というのは、目的意識があって、要素間のつながりやシナジーがあり、かつ環境の変化に柔軟に対応できる、というほどの意味である。目的意識もなく、環境変化に対応もできないような、要素の単なる寄せ集めを見て、わたし達は「有機的」と考えたりはしない。

そして、設計における統合力を担う職務を、「エンジニアリング・マネジメント」と呼ぶ。それはオーケストラの指揮者のように、一種の専門職である。交響楽団には、弦楽器だとか管楽器だとか、様々な専門の演奏職種がある。それらをまとめて、作曲家の提示した楽譜(=基本デザイン)に従い、現実化する。

楽譜に指揮者の「解釈」の余地があるように、実装にはいろいろな自由度がある。加えて、実際には完璧なデザインはありえないし、実装段階でのヘマをリカバーしなければならない場合もあるし(汗)、何よりも演奏会場と違って、エンジニアリングの場は外部環境に対して開かれている。顧客要求も市場環境も法規制も変化する中で、適応していかなければならない。

したがって、エンジニアリングにおいては、チェンジ・コントロール(変更管理)が重要である。設計とは実は、チェンジの積み上げである。むしろチェンジこそ本質である、といってもいい。設計の全体性をなるべく保ったまま、環境変化・条件変化に対して『適応制御』することが、エンジニアリング・マネジメントであろう。

マネジメントであるからには、設計のジャッジも必要に応じて担うことになる。そのためには、先読みとリスクテーク、そして何が良い成果であるかについての評価の価値観を持たなければならない。それも、部分的尺度ではなく、全体を見通した判断が必要である。

それを可能にするのは、設計プロセスと成果物に対する、「システム」としての見方である。変更の範囲と因果関係の予測ができないと、良い判断はできない。また外部機能→内部構造という階層性の理解、そしてV字モデルに従った詳細化と検証テストのコントロールが要求される。

ただ上の例に示したように、それはエンジニアリング・マネージャーだけが、一人で頑張って実現できるものではない。むしろ、協調的な働き方ができる組織力が望まれる。互いに独立し並行して進んでいるが、共通の着地点を目指すような、「すりあわせ」的な働き方である。ちょうどオーケストラの楽団員のように。そして変化を予見しながら、最小限の余裕を見越して設計できるスキルが望まれる。

エンジニアリング・マネージャーという職種は、わたし達の業界では普通の存在だが、分野によっては違うかもしれない。「エンジニアリング」という言葉の指し示す内容について、念のため最近、ゼネコン業界、工作機械メーカー、電子業界、IT業界などの知人にたずねてみたが、たしかにかなりの幅がある。それでも共通していたのは、「複数の設計技術要素を束ねる仕事」だという点だった。やはりエンジニアリングでは、統合力が、問われるのである。


<関連エントリ>
(2017-04-09)


(2019-11-21)




by Tomoichi_Sato | 2020-01-12 15:48 | プロジェクト・マネジメント | Comments(0)