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

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

各位:

プロジェクト&プログラム・アナリシス研究部会」の2017年第4回会合を開催いたします。

今回は、製造業におけるプロジェクトの一つである、受注設計生産のスケジューリングについて、この分野の専門家である(株)シムトップスの伊藤昭仁様にご講演いただきます。

日本の製造業の生産形態は、高度成長時代の大量見込生産から、次第に受注生産中心へと移っています。中でも、顧客の個別仕様に合わせて、受注してから設計し生産する受注設計生産(一品受注生産ともいう)は、プロジェクトの一種でもあり、もっとも生産管理の難しい形態ということができます。それは設計・調達というホワイトカラー業務と、製造現場の両方をシームレスにコントロールする必要があるからです。また、生産スケジューリングの基礎データとなるBOM(部品表)が、受注時点ではまだ固まっていない、という難しさもあります。

この受注設計生産プロジェクトの分野において、早くからスケジューラをはじめとするソリューションを開発してきた伊藤氏から、現実に即したお話を伺います。また久しぶりにIT業界の方のご講演でもあります。

いささか直前のご案内になりましたが、ぜひご参加ください。

<記>

■日時:2017年10月12日(木) 18:30~20:30

■場所:慶応大学 三田キャンパス・北館会議室2(1階) (定員:28)
キャンパスマップ 【1】

■講演タイトル:
「受注設計生産のプロジェクトスケジューリングの課題と改善期待効果」

■概要:
 量産を前提にしない受注設計生産では、事前に基本マスターの整備ができず、プロセスフロー(BOP)の定義が困難な場合が多い。その結果、ストラクチャー型のBOM (部品表)を前提にした生産管理システムや生産スケジューラの適用を難しくしている。これらの現状の課題と、受注設計生産へのプロジェクトスケジューリングを適用するための取組みと日々の工程管理における改善期待効果を述べる。

■講師: 株式会社 シムトップス 伊藤 昭仁(いとう あきひと)

■講師略歴:
 1991年 株式会社シムトップス 設立と共に入社20年以上にわたり、受注設計生産の製造業向けの生産スケジューラ/工程管理システムの導入前の提案からシステム導入後の立ち上げサポートまで、広範囲の業務に従事。国内主要自動車メーカの金型部門、工機部門、試作部門、半導体製造装置から発電設備などのプラント設備まで、幅広い受注設計生産タイプの生産工場へ100社以上のシステム導入経験を持つ。

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

 参加を希望される方は、確認のため、できましたら当日までに三好副幹事(miyoshi_j@kensetsu-eng.co.jp)までご連絡ください。

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

by Tomoichi_Sato | 2017-09-28 07:51 | プロジェクト・マネジメント | Comments(0)

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

講師急病により先月の講演を延期いたしましたが、幸い復調されましたので、あらためて8月8日(火)に開催させていただきます。
会員の皆様にはご心配をおかけいたしました。(7/19 佐藤知一・追記)
----------------------------------------------

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

今回は、雪印メグミルクの松本卓夫様を講師にお迎えして、同社の企業再生のプロジェクトについてご講演いただきます。

ご承知の通り、旧・雪印乳業を中心とした雪印グループは、2002年に企業存亡の危機を迎えます。四面楚歌の中、会社に残られた方々は、生産と物流をカバーするサプライチェーンの改革に、収益回復と業績再生の希望をつなぎます。

その渦中を奔走し、改革プロジェクトをリードされた当事者である松本様から、具体的なお話を頂戴します。ある意味で、我が国が必要とするプロジェクト・マネジメントの生きた姿を示すと言っても過言ではありません。サプライチェーンの改革と企業の復活はどのようなものか、興味深いご講演に、ぜひご期待ください。


<記>
■日時:2017年8月8日(火) 18:30~20:30
■場所:慶応大学三田キャンパス 北館会議室2(1階) (定員:28)
※プロジェクターあり
キャンパスマップ・【1】

■講演タイトル:「雪印メグミルクのSCM構築と統合工場(阿見工場・総合物流センター)建設の概要

■概要:
雪印メグミルクでは雪印乳業時代の2003年から2009年にかけてSCMシステムの開発導入と業務改革を実施し、大きな収支改善を実現した。また、さらに高度なSCMの実現のため既存3工場を集約した乳製品統合工場と原料・製品保管と保税機能を有する総合物流センターを建設し、サプライチェーンの全面見直しによる収支基盤の強化を実現した。これらの取組みとプロジェクトの概要を述べる。

■講師: 雪印メグミルク(株) 松本卓夫(まつもと たかお)様
■講師略歴:
1981年 早稲田大学 理工学部 工業経営学科卒業
      雪印乳業 入社
      福岡工場 本社 技術部 装置技術部 SCM推進部 物流部
2007年 本社 生産部 担当部長
      生産設備 企画導入施工・装置開発・SCMシステム開発 総括
2011年 会社合併により、雪印メグミルク 生産技術部 副部長
2012年 乳製品統合SCMシステム構築プロジェクト統括マネージャ
      阿見工場システム構築・阿見総合物流センター建設
2015年 生産技術部 装置開発グループ 副部長
      生産設備技術開発・FA開発導入・SCM開発 総括

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

会場の人数に上限があるため、参加を希望される方は、できましたら前日までに三好副幹事(miyoshi_j@kensetsu-eng.co.jp)までご連絡ください。
以上、よろしくお願いいたします。


佐藤知一@日揮(株)


by Tomoichi_Sato | 2017-07-19 23:14 | プロジェクト・マネジメント | Comments(0)

ビジネス・マネージャーとは何をする人か

数年前、製造業に働く方から相談を受けた。その企業では、西南アジアの某国でプロジェクトをはじめるという。プロマネ以下、何人かのチームでその国に乗り込み、現地企業と共同で新しい製品の製造ラインを作る仕事だ。そこで、何かアドバイスがあれば頂戴したいという話だった。

もちろん、わたしはその会社の製品について何も知らないから、技術的アドバイスなどしようもない。できるのはマネジメント的なアドバイス、つまりプロジェクト・マネジメント面での助言ということだろう。そこで、チーム編成やプロジェクト期間などについて少したずねた後で、わたしは申し上げた。

ビジネス・マネージャーを任命してチームに入れるべきです。
 営業畑でも、法務でもいい。文系の人を任命してください。」

技術的プロジェクトだからと言って、技術者ばかりでチームを編成するのは賢いやり方ではない。そう、わたしは申し上げた。もちろん文系といっても、英語が一応しゃべれることが望ましいですが(その国でビジネスをやるなら、英語のコミュニケーションが必要になる。大学教育は英語で行っているはずだから)。
−−でも、ビジネス・マネージャーって、何をするんですか?

それが先方の疑問だった。なるほど、知らない人には分かりにくいかもしれない。

日本には理系と文系という、諸外国にはあまり見ない不思議な制度的区分がある。理系の人は文系のことは知らなくて良いし、文系の人は技術に興味がなくてもて当然だという、思考習慣がある。MITすなわちマサチューセッツ工科大学に、経済学や言語学の講座があってもいいじゃないかと考える欧米流とは少し、ギャップがある。

ただし英語では(つまり、英語でビジネスをする業界では)、Technical と Commercial という区分がある。たとえば、きちんとした国際入札は普通、Technical Proposal と Commercial Proposalのに分冊の作成が要求される。日本語でいえば。技術提案書と商業提案書かな。

技術提案書には、設計面での提案や、遂行方針などが記される。そして商業提案書には、価格(明細・合計)、支払・保証など契約面についてが書かれる習慣だ。通常の日本の商慣習に翻訳すれば、前者が「見積仕様書」、後者が「御見積書」になるだろう。

そして国際入札では、まずTechnical Proposalの評価(技術評価)で合格した入札者のみ、Commercial Proposalが開封されるルールになっている。入札の選定は、値段だけでは決めない。いや、先に値段を見て安い応札者に対して、技術面をネゴしたりもしない。まして、技術的には優秀だが値段が二番手以下の応札者に対し、一番札の値段を教えて値引き要求をしたりもしない。これが国際的な慣習で、それを破ると業界内で信用を失う。つまり二度とまともに入札ができなくなる(応札者がいなくなる)、という仕組みである。このようなTechnicalとCommercialの区別と順位付けが、国際入札の仕組みを守っているのである。

さて、Proposal全体を取りまとめる責任者は、PM=プロマネである(あるいはProposal Managerともいう)。そしてCommercial Proposalの部分をまとめるのが、BM=ビジネス・マネージャーの仕事なのだ。

しかし、BMの仕事が一番大事になるのは、受注後の遂行段階である。そして、客先との交渉(ならびに、その準備)が主要な仕事の柱となる。追加や変更に伴う交渉においては、BMが過去の書類やメールなど、証拠(エビデンス)を全部まとめ上げる仕事をしてくれる。そして変更に伴うインパクトや、作業費用を見積もるのもBMだ。さらに過去データや外部企業の事例を探してきて、交渉の材料にするのだ。ここまで揃えば、プロマネの交渉の仕事はずいぶんやりやすく、楽になる。

なんだそれ、営業の仕事じゃないか、と思われた方もいるかもしれない。かもしれないが、貴方の会社の営業マンは、受注後もプロジェクトにはりついていられるだろうか? それも海外プロジェクトの現場で? せいぜい、たまに来て手伝うだけではないだろうか?

それに、交渉以外にもやる仕事はたくさんあるのだ BMは金銭や契約や雇用・労務に関わる一切の仕事に責任を持つ。もう少し具体的に列挙すると:

- 客先への請求と支払いに関わる事項
- 変更(Change Order)と見積・交渉に関わる事項
- プロジェクトの資金管理とキャッシュフローに関わる事項(海外プロジェクトならば外貨と為替も)
- 要員の手配・採用に関わる事項(海外ならばビザ手続きも)
- 外部発注企業に対する契約と支払いに関わる事項
- 執務環境に関する事項(海外プロジェクトならば宿舎の手配も)

こういうこと一切合切を仕切るBMがいなかったら、どうなるだろうか? こうした事柄は、いずれにせよ不可避である。避けて通れないのだ。となると、結局誰かがやるしかない。そして、それはつまりプロマネの仕事になってしまうのだ。技術に専念したい技術系プロマネにとって、こうしたことは「雑用」に思える。わたしは技術以外のことを、雑用として軽んじる見方には組みしないが、そう考える人は現実に多いだろう。

ここで、R・ハインラインの名作SF「月を売った男」 に出てくる挿話をわたしは思い出す。この物語の中で主人公は、自分が月ロケットの設計図に集中したいときにかぎって、運送業者がトラックの手配について文句を言ってくる、といって嘆く。すると彼の片腕になる男が現れて、そうした「一切の雑用」を自分が引き受けます、だからボスは技術に集中してください、と宣言するのだ。

ソフトウェア産業における生産性の問題を論じた「人月の神話」 の著者Brooks Jr.は、この「月を売った男」のエピソードを引用し、技術系PMの下に、商務に強いBMがいるのが理想だ、と書いた。たしかに一つの考え方である。

いや、ちょっとまって。ウチの会社にはそんな、営業面も法務も人事も会計も総務もわかるような、しかも英語も話せるようなスーパーマンはいないよ。そんな声も聞こえる気がする。たしかにそうかもしれない。

だが海外のライバル会社には、専門のBMがいるかもしれない。BMの交渉力やサポートが案外、赤字と黒字の分かれ目になるかもしれない。だったら、今からでも育成するしかないのだ。そのためには、まず、ビジネス・マネージャーという専門職種が必要なのだと、会社が認識することが先決だ。

以前にも書いたが、わたしは「文系」と「理系」という人材の区分をあまり認めていない。わたしの勤務先には、いわゆる文系出身ながら、エンジニアリング会社のプロマネとして立派な仕事をしている人が何人もいるし、まだ駆け出しだった若い頃について勉強した先輩も経済学部出身のエンジニアだった。またわたし自身、理系と文系の両方の資質を持った人間だと自覚している。だから、「技術屋だから契約オンチでいい」とか「営業マンだから設計の話は知りたくない」といった、自分で壁を作ってしまう人々の態度は、一種の怠惰だと思っている。

だが、文系・理系という区分は世間に流通しているし、そういう形で自己規定している人も多い。だったら、せめてその範囲内では責任感を持ってもらいたい、というのがわたしの期待だ。だから営業マンであって労務や会計は素人であっても、せめて「文系の守備領域」については、技術屋に対して自負を持ってくれるだろうと思い、冒頭に述べたような提案をしたのだ。

念のためにいうけれど、プロマネ人財だって、固有技術も管理技術もよくわかり、かつ人徳があってリーダーシップも豊富な、スーパーマンみたいな人は滅多にいないと思う。で、スーパーマンがいなくても仕事がある程度成り立つためには、仕事の仕組み(システム化)が必要なのだ。そしてプロマネを補佐したり助けたりする支援組織や専門機能が必要である。

もちろん、ちゃんとしたプロマネをまず、意識して育成しなければならない。ただプロマネは最終責任者なのだから、BMの領域についてだって、少しは知る必要がある。つまり契約や請求や会計や雇用について、せめてBMとちゃんと会話が成り立つ程度には、概念と用語の知識が必要である。そしてBMの側にとっても、営業や財務や法務など本社の専門部署からのサポートが必要なのである。

冒頭にあげた会社が、うまくBMを任命できたかどうか、残念ながらその後の話はまだ聞いていない。社内で見つけるのは、そう簡単でなかったろう。ただ海外ならば、逆に欧米人の専門家を雇う手段だってある。まあ専門家を呼べば、たぶん高給取りだろう。しかし、それで技術者達が技術に専念でき、赤字を回避できるなら、総合的には安いものだ。

それは、マネジメントの価値とコストの比較論である。マネジメントはリーダー職の片手間仕事ではない。とくに海外プロジェクトならば、なおさらである。契約社会でのプロジェクトには、「文系」的な職域に強い人材も、必要なのだ。技術力だけでは勝てない。そのことの認識が、海外に打って出るときの第一歩なのである。





by Tomoichi_Sato | 2017-07-10 22:32 | プロジェクト・マネジメント | Comments(0)

課題展開図からプロジェクトへ

Kさん、追伸です。

長文のメールを差し上げたばかりなのに、すぐに追伸とはお恥ずかしい話ですが、ちょっとだけ補足しておきたいことを思い出しましたので。それは、もう一つの経営戦略の視点、つまり、「What(何を目指すか)」から「How(いかにアプローチするか)」への話です。
(サイト読者への注:前々回「中堅エンジニアのための経営戦略入門」http://brevis.exblog.jp/25732183/ 、および前回「中堅エンジニアのための経営戦略入門(2)」http://brevis.exblog.jp/25754847/ の記事を参照のこと)

経営者の仕事とは、ざっくり言ってしまうと、次のようなステップから成り立っています。

(1) 企業の「ありたい姿」(使命・ビジョン・ゴール)を示す
(2) 「あるがままの姿」(現状)とのギャップ=課題を明らかにする
(3) 課題解決の方途(戦略)を決める
(4) 経営資源を再配置する(組織の変更を含む)
(5) 遂行をウォッチし問題解決を支援する
(6) 結果として新たな経営資源を獲得・蓄積する
(7) 適時(1)に戻る

課題という言葉の意味については、ずいぶん以前にご説明しましたが、覚えていらっしゃるでしょうか(「超入門・問題解決力 - 問題とは何か、課題とはどう違うか」http://brevis.exblog.jp/12188859/ )。課題とは能動的なもので、“あるべき姿”を思い描いて、現実をそこに向かって変えていくためのポイントです。一方、問題とは、(意識的にであれ無意識であれ)“期待していた状況”と、現実の状況のギャップを指します。上記の(2)で言っているのは、まさに課題の方です。能動的な課題設定は、経営者の重要な職務の1つです。

ついでに言うと、マネージャーの仕事も、大なり小なりこれの縮小版である、と考えることができます。ただし、違いは、中間管理職の場合、主たる使命・目標は「上から与えられる」ことでしょう。逆に言うと、自分で目標設定ができない・ビジョンを生み出せない人は、どこまで出世しても、内実は中間管理職であるといっていいかもしれません。こういう人は未来志向ではない訳で、つまり主体的に生きていない事になりますね。じつはよく見かけるタイプですけれども、
・言われたとおりのことをします、という受注型(受け身型)エンジニア
・正解だけを追いかけたがる入試型秀才
・世間から与えられた競争のモノサシでひたすら勝とうとする競走馬型人間
といった人たちで、環境が大きく変わると絶滅していってしまうのです。

さて、(3)のステップで使う道具立ての一つに、『課題展開図』があります。これは最上位の課題を1番上に書き、その課題を解決するための部分的課題をその次にかき、さらに部分課題を解決するための方策を次のレベルにおく、といった形で作られる図です。例をご覧ください。
e0058447_22061180.jpg
この例ではわかりやすいように、最上位の課題として、「会社の競争力再生」をおいています。そしてその次の中間課題として、「販売力の向上」と「コストの削減」をあげました。販売力の向上という課題を解決するために、2つのプロジェクトが生まれます。1つは新製品開発で、もう一つは海外市場の開拓です。さらにコストの削減という課題を解決するためには、生産合理化と物流改革という2つのプロジェクトがあげられています。スペースの関係で非常に単純な図になっていますが、構造はご理解いただけると思います。

ここであげているプロジェクトは、すべて自発型のものです。例えば新製品開発プロジェクトの目的は、販売力の向上であり、その目標としては、6ヶ月以内に新製品を出荷する、性能を3割以上向上する、が挙げられています。プロジェクトの目標は、具体的な数値をもとに、客観的に成否がはかれる形にすることが望ましいのですが、目標設定は当然ながら課題解決の目的に合致したものでなければなりません。ですから、1年以上かけてじっくり開発するとか、外観を変更するだけで性能はちょっぴり変えるとか、あるいは最小の開発予算で出荷するとかいった目標設定は、不適切だということになります。

さて、ここでどうしても『プログラム』という概念について、ご理解いただかなくてはなりません。プログラムとは、プロジェクトの上位概念です。通常はひとつのプログラムの中に、複数のプロジェクトを包含します。ちなみに米国の「アポロ計画」は、英語では"Apollo Program"でした。プログラムは、配下のプロジェクトを有機的に連携させながら進めることによって、目的を達成する活動です。課題展開図をご覧ください。この例では、「販売力の向上」を達成する活動群が、一つのプログラムに該当します。プログラムは、単なるプロジェクトの集合体ではありません。当然ながら、コンピュータのプラグラムとは全く別の概念です(よく混同されるのでこまるのですが^^;)。
プログラムとは、企業組織が新しい能力を得るために行う、時限的な営為です。これはじつは、英国政府が作成した標準書である"Managing Successful Programmes”(通称MSP)の考え方です。英国では、政府自らがこうしたいろいろなマネジメントに関する標準的解説書を制定して、例えばオリンピックや、鉄道網の敷設といった大規模公共事業を成功させるべく、適用しているのです。

プログラムは能力獲得が目的ですから、通常は、経営資源・設備の増強や、その質的向上を伴います。しかし設備を作ったり、人や組織を増強するだけでは、仕事は終わりません。設備や人が新しい「能力」を獲得して、はじめて目的が達成されるのです。そのためには、プロジェクトの結果(アウトプット)を、能力(アウトカム)につなげるチェンジ・マネジメントが重要な仕事になります。MSPではプログラム・マネージャーは、チェンジ・マネジメントの責任者と歩調をとって働くべし、と規定されています。何か大きな成果物や箱物を作って、それで一丁上がりとはならないのです。

プログラム・マネージャーの仕事は、大きく分けると4つあります。
・必要なプロジェクト群の構想・設計
・各プロジェクトの起動・完了(+中止)
・プロジェクト・マネージャーの任命と経営資源の配分
・プロジェクトの成果物を活用した、価値の具現化(課題解決)

なお、図の例では、経営レベルの最上位課題が、いきなりプログラム・レベルの中間課題に展開されていますが、これは企業組織の規模によりけりだと思ってください。大企業ならば中間に複数のレベルがあるでしょうし、中小企業なら経営課題からいきなりプロジェクトにつながるケースもあるでしょう。ともあれ、経営課題を解決するための手段(戦略)として、プログラム/プロジェクトがあるのだ、という点を理解いただきたいのです。

なお、ついでにいいますと、プログラムの上位概念に、『ポートフォリオ』があります。ポートフォリオとは、企業内、あるいは独立したビジネス・ユニット内で、互いに経営資源を取り合う関係にあるプログラム/プロジェクトの集合体です。経営資源(リソース)とは、人・設備・資金などを含みます。

経営者の仕事の(4)にあげたように、限りある経営資源の配分は、とても重要です。ポートフォリオに含まれる様々なプログラムを、適切に優先順位付けを行い、優先度の高いものから配分していきます。優先順の判断には、費用と効果のマトリクスをよく使います。ポートフォリオ・マネジメントの目的は、必要なリソースの配分ですから、企業内でポートフォリオをくくり出す際には、あまり部門単位(研究所・IT部など)の断面だけで集合体をとらえてはならなりません。研究→開発→マーケティング→生産準備という風につながって、はじめてビジネスの成果を生み出すのが普通だからです。

課題展開図に話を戻しますと、よくある間違いを二つだけあげておきます。一つめは、最上位の経営課題を次のレベルに展開する際、その設定を間違えることです。しばしば、そこに既存組織の単位をおいてしまうのです。たとえば「競争力の再生」なら、「営業部門の課題」「製造部門の課題」という風に分解してしまう。こうしたやり方がなぜ間違いかと言うと、現組織がカバーしていない問題が抜け落ちてしまうからです。また、組織間にまたがる問題が見えなくなりがちです。

もう一つのありがちな間違いは、重複や漏れがあるような改題展開をしてしまうことです。MECEな課題展開をしなければなりません。MECEとは、Mutually Exclusive and Completely Exhaustiveの略で、「漏れもなく、落ちもない」状態を表す略語です(もともとはロジカルシンキングで使われていた用語です)。日本全国の地図を、47都道府県にわけた場合、そこには漏れも重複もありませんよね。あるいは製品を部品表(BOM)に展開する際は、上位の親品目を下位の子部品が漏れも重複もないようにカバーする訳です。これがMECEです。

だから課題展開図とは、企業の経営課題のBOMだといっていいかもしれません。BOMの作り方によって、製造のしやすさや効率性は大きくかわります。上手な課題展開こそ、経営戦略の腕の見せ所なのです。Kさんも、ぜひこういった視点を持ちながら、製品開発の仕事を進めていかれることをおすすめします。ああ、すみません、また長くなってしまいました。最初に「ちょっとだけ補足します」なんて書いたのに(-_-;)。今度ぜひまた、会ってお話できる機会が持てるといいですね。


<関連エントリ>
 →「超入門・問題解決力 - 問題とは何か、課題とはどう違うか」http://brevis.exblog.jp/12188859/ (2010-02-21)
 →「中堅エンジニアのための経営戦略入門」http://brevis.exblog.jp/25732183/ (2017-04-28)
 →「中堅エンジニアのための経営戦略入門(2)」http://brevis.exblog.jp/25754847/ (2017-05-07)

by Tomoichi_Sato | 2017-05-14 22:06 | プロジェクト・マネジメント | 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)

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)

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

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月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)

プロジェクト・コミュニケーションのベーシック(2) ~ ドキュメント・インデックスを作る

前回の記事「プロジェクト・コミュニケーションのベーシック ~ 情報のトレーサビリティを確立する」で、英語で言うCommunication Managementとは、日本語的感覚でいう「コミュニケーションの管理」ではなく、むしろ『情報伝達のマネジメント』に近い、と書いた。だから、伝達のトレーサビリティ確保が大事になる、と。

今回はその続きである。だがもう一歩進んだあり方として、「ドキュメントのインデックス化」の話をしたいと思う。ドキュメントのインデックスとは何か? 簡単だ。それはプロジェクトが作成する文書・図面類をリスト化して、多少の属性を付加したものである。「ドキュメント・リスト」と呼ばれる場合もある。

なあんだ、そんなのならいつでも作ってるよ。そういって、ドキュメントが保存されているサーバのプロジェクト・フォルダから、ファイルのリストを印字して持ってくる人がいる。ファイル名の他に、作成日、更新日、ファイルサイズ、種類などの属性が並んでいる。--これのことでしょ?

全然違うのだ。そんなリストは、プロマネにとってどんな行動の契機も与えない。そのファイル・リストを見たら、まだ出来上がっていないドキュメントが何と何か、分かるだろうか? どの図面が予定よりはるかに遅れて作成されたのか、問題発見の手がかりになるだろうか。誰を応援したり督促したりすべきなのかの、判断材料になるだろうか? なるまい。

プロジェクト・マネージャーという職種は、最初に計画を立て、実行段階ではその計画からの逸脱をチェックしながら、問題をつぶしたり変更を追いかけたり、決断を下したりして、なるべくプロジェクト全体の生み出す価値を高めていくのが仕事である。だから問題発見のツールをいろいろ持っていて、そのセンサー感度を上げる仕組みが必要だし、問題解決のためには、何がいつどこで起きたのかを、正確にさかのぼってたどれる道具が必要なのだ。

ドキュメント・インデックスは、そのためのツールである。これ自体は、単純な表になっている。プロジェクトで作成しなければならないドキュメントを、すべて、重複も漏れも落ちもなく、計画段階であらかじめリストアップしておく。そして、各ドキュメントは、誰が担当で作成するのか、WBSのどのアクティビティで作成するのか、したがっていつ作成される予定なのかを、あらかじめ決めて書いておく。

つまり、ドキュメント・インデックスは、初期段階では「まだ存在していない文書の属性付きリスト」なのである。ファイル名のダンプリストじゃ役に立たないことは、おわかりだろう。それは「すでに存在している文書のリスト」を示すだけだ。あるいはもう少し高級な、いわゆるContents Management System風のリストも、役に立たない点では変わりない。そうした道具立ては、存在しているファイルの『在庫管理』には有用だろう。だが、まだ存在しない、これから作成すべきドキュメントについてのコントロールには、あまり役に立たない。

ドキュメント・インデックスというは次のような構造をしている。持つべき主な属性は、以下の通りだ:
e0058447_22301426.jpg

(1) ドキュメントのID
(2) ドキュメントの名称
(3) ドキュメントのリビジョン番号
(4) プロジェクトNo.およびWBS No.
(5) 発行目的
(6) 作成者・検討者・承認者
(7) 発行予定日
(8) 発行実績日
(9) ドキュメントを構成する電子ファイルのリスト

すべてのドキュメントは、ユニークなIDを持っていなければならない。これは当たり前のことだ。従業員番号のない社員がいてはいけないのと同じである。何かをトラッキングしたりコントロールするためには、IDがいる。これは情報システムの世界では常識であろう。(それなのに、自分が仕事をする段になると、設計文書をタイトルだけで『管理』して平然としているシステム・エンジニアがいたりするのは若干、謎である)

ドキュメントにはリビジョン番号があるのは当然だが、WBSの中のどのアクティビティで作成されるものかを示すことも(当然ながら)大事である。誰が担当で、いつ出来るのかは、それによって決まる。作られたら、次にどこのアクティビティで利用されることになるのかも、注意しなければならない。かつて「仕事の最小単位--アクティビティの構造を学ぶ」にも書いたように、文書(情報)はアクティビティのアウトプットであると共に、次のアクティビティのインプットともなるからだ。

ちなみに、わたしの勤務先では、ドキュメントのIDは、種類を示すコードと、それを作成するアクティビティのWBS No.を元にして構成している。一つのアクティビティから複数のドキュメントが作られるのが普通だから、後ろに連番をつける。かつ、それを電子ファイルの命名規約にもしている。ついでながら、仕事のプロセスを示すFunctional WBS (F-WBS)は標準的なコード体系にしたがっているため、どのプロジェクトでも、たとえばポンプの設計図書は同じF-WBS No.を持っている。だから、ドキュメント番号やファイル名称を見ただけで、「これはポンプの調達仕様書だな」と分かる仕組みになっている。

それから、インデックスには、何のために発行されるのかという目的がいる。つまり、顧客に出す承認用(For Approval)だとか、顧客からOKをもらった施工用(For Construction)だとか、あるいは据付工事後の最終納品版(As-Built)といった区別である。もちろん、顧客に気に入られないと、承認用を2回も3回も出し直し、という事態だってありえる。だからリビジョン番号と発行目的は、1対1にはならないのである。ちなみに「発行」という用語は、英語のIssueの翻訳だが、耳慣れないと思う人もいるかもしれない。これは、正式版として社内関連部署や顧客や外注先に対して配布する作業を意味している。「出図」という言い方をする企業もある。

作成者・検討者・承認者の項目は自明だろう(スペースの関係で一つにしているが、実際には別々にするのが普通だ)。

そして何よりも大事なのは、「発行予定日」と「発行実績日」である。プロジェクトの計画段階で、ドキュメント・インデックスを作る際に、個々のドキュメントの発行予定日を記入しておく。これは、プロジェクトのマスター・スケジュールに合致していなければいけない。そして、遂行段階に入って、実際にどんどんドキュメントが作成されるようになったら、それぞれの実績日を記入していくのである。

この予定日と実績日があるから、プロマネは問題を事前に検知したり、メンバーに上手に督促したりすることができるようになるのである。「今週、発行予定のドキュメントはこれとこれです。担当者はもし何か問題を抱えているようなら教えてください。支援します。」といった風に、週次のミーティングでいう訳である。

そして実際に発行されたドキュメントは、必要とする関連部署(下流側のアクティビティに関わる部門)や外部ステークホルダーに送付するとともに、プロジェクトのセンター・ファイルに保管する。情報伝達のトラッキングが必要になったら、プロマネは(あるいは、もう少し大規模なプロジェクトの場合は、専任のライブラリアン役の担当者が)、そのセンター・ファイルと、インデックスの履歴をチェックする。これがドキュメント・コントロールの仕事である。わたしが勤務先でこのようなやり方を初めて知ったときは、その見通しと効率の良さに舌を巻いたが、わたしの先輩達はどうやら何十年か前に米国の同業者達のやり方に学んだらしい。

またこうしたデータがあると、横軸に日付をとって、縦軸に発行予定ドキュメント数の累計をプロットしていけば、S字カーブが得られる。これに実績の線を書き加えれば、プロジェクト全体の遅れや進み具合が一目瞭然になる。一般に、設計作業の進捗は目に見えにくく、把握しづらい。ドキュメント・インデックスは、その進捗を可視化するためのツールになるのである。

e0058447_22311024.jpg
わたしの業界では(海外の大規模プロジェクトは特に)進捗に応じて顧客が支払う契約が多い。このとき、設計の進捗を、発行されたドキュメントの数で測るのである。全体で100部の図面やドキュメントを作成する予定であり、現時点では45部が発行済みだから進捗45%、といった計算である。単純だが、分かりやすい。むろん、図面には情報量の大小があるし、ドキュメントだって厚いのも薄いのもある。だからそんな進捗計算なんかナンセンスだと、いえないことはない。だが、今日までに100部作成する予定なのに、まだ10部しか出来ていなかったら、やはり何かおかしいと判断するきっかけにはなる。測れないものは、マネジメントできない。もし設計をマネージしたいのなら、設計の進度を測る何らかの仕掛けが必要なのだ。

最後は、そのドキュメントを構成するファイルのリストである。本文はWordだが添付資料はExcelの表です、といったものはよくある。こうしたセットを、ひとつの「ドキュメント」として扱うのである。だから、個別のファイル単位にしか属性を扱えないCMSみたいなツールは、ちょっと不便だということになる。

と、ここまで読んだ読者の方は、二つの疑問を持たれるかもしれない。

Q1: 本当に最初の段階で、プロジェクトが作成すべきドキュメントを全部もれなく洗い出せるのか? 途中でどんどん増えてしまったりするのではないか。
Q2: ドキュメントの発行予定日なんて、そんな初期に決められるはずがない。

このような疑問は、プロジェクトの「初期の段階」という理解にズレがあるために生じると思われる。まさかプロジェクトの初日に、ドキュメント・インデックスを作れる訳はない。プロジェクト計画がある程度進んで、WBSが作成され、マスター・スケジュールが出来上がったタイミングでなければ、もちろん作ることはできない。それはすなわち、プロジェクトの全体像の目鼻がついた段階だ。目鼻とはつまり、成果物の構成(Product-WBS, P-WBS)がだいたい決まり、かつ、それを作るまでのプロセス手順(F-WBS)が見えて、アクティビティ・マトリクスができた時点である。
(アクティビティ・マトリクスとWBSについて知りたい方は、拙著「世界を動かすプロジェクトマネジメントの教科書 〜 グローバルなチャレンジを成功させるOSの作り方」参照のこと)

もちろん、プロジェクトの遂行途上で、インデックスにドキュメントを追加せざるを得なくなったり、あるいは削除(キャンセル)することもあり得る。追加は、当然ながらユーザの意向でスコープの増加があった場合、そして当初の見積が不足していた場合の二つがある。だから、この両者は区別できるようにしておかなければならない。そしてプロジェクトが完了したときに、自社理由で増えた分と、外部理由で増えた分が、それぞれどれだけあったかを調べ、次にドキュメント数を見積もるときには、どう教訓(Lessons Learned)を生かしたら良いかを、考える材料にするのである。こうしたことをしない限り、見積の精度など向上する訳がない。

そして、ドキュメント・インデックスを作る理由は、まさに自分たちの予測能力を高めるためにあるのだ。ドキュメント・インデックス作成というのは、プロジェクトのマスター・スケジュールなどと似ていて、プロジェクト全体を表す一種の『モデル』なのである。プロジェクトという複雑な、かつ見通しにくいシステムをモデリングする事。これこそが、プロジェクト・マネジメントの中心技術でなくて何だろう? 最終形を見通さぬまま、なりゆきでドキュメントを積み上げていっただけでは、最後に手元に残ったリストを見ても、次に生かすのは至難の業だ。経験から学ぶためには、自分が何を見通して、何を見通せなかったかを、後から追えるようなトレーサビリティが必要なのである。


<関連エントリ>

by Tomoichi_Sato | 2016-10-12 23:37 | プロジェクト・マネジメント | Comments(2)

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

プロジェクト&プログラム・アナリシス研究部会」2016年の第5回会合を、下記の要領にて開催いたします。今回は研究部会WGのメンバーとの検討をもとに、久しぶりにわたし自身が講演いたします。この問題に関心をお持ちの方のご来聴をお待ちしております。

<記>

■日時:2016年10月21日(金)18:30~20:30
■場所:三田キャンパス・北館会議室2(1階)(定員:28)】
 キャンパスマップ・【1】

■講演タイトル:「プロジェクト・マネジメントの教育に対する新しいアプローチ

■概要:

受注型プロジェクトに多く携わる企業では、プロマネの育成はつねに重要な課題です。PMP資格の取得奨励などを進めても、なかなかそれだけでは実効性が上がりません。片や、自発型プロジェクトを進めるべき企業や官庁などでは、「プロジェクトをマネージするには技術がいる」という意識すら薄く、結果として幾多の失敗事例がメディアをにぎわす状態が続いています。

本講演では、“教育とは自己成長を支援するプログラムである”という認識に立ち、企業内や大学での教育に携わってきた経験を元に、エンジニアがPM能力を高めるための新しいアプローチについて提案します。今回の内容は、当研究部会の中で自主検討してきた「PM教育WG」の途中経過報告でもあり、参加者による積極的なディスカッションを期待します。

■講師: 佐藤知一(さとう ともいち)
日揮(株)勤務、静岡大学客員教授、東京大学・法政大学講師、工学博士・PMP

■講師略歴:
 1982年4月 日揮株式会社入社
 1985年10月~1986年9月 米国East-West Center 環境政策研究所 研修派遣
 2001年5月~2002年4月 仏Technip社との電子調達サイト Operation Manager
 2010年6月 「リスク確率に基づくプロジェクト・マネジメントの研究」により学位取得
 2016年9月~ 現職(日揮株式会社 グローバル戦略室)に至る
〔受  賞〕日本経営工学会論文賞(2009)

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

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

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


佐藤知一@日揮(株)

by Tomoichi_Sato | 2016-10-08 09:36 | プロジェクト・マネジメント | Comments(0)