00:06
こんにちは、常蔵です。
デザイン・リビューFM第46回目、やっていきましょう。
このデザイン・リビューFMは、世の中の様々なもの、
主に工業製品や、それに関わる出来事について、
私の主観で、勝手にデザイン・リビューをしていこうという番組です。
今回は、技術士ハンドブックを読むの8回目、
発祥のプロジェクト計画と評価から読んでいきましょう。
では本編をどうぞ。
はい、本編です。
プロジェクトの定義とステークホルダー
ではですね、まずプロジェクトとは何かというのを定義しましょう。
まずプロジェクトとは、有期であり、期限があるということですね。
有期であり、始まりと終わりがある。
これが、継続を基本とする定常業務との相違点であると。
そして、プロジェクトは独自の目標を持つ。
プロジェクトには、一つとして同じプロダクト、サービス、使命はない。
毎日同じ製品を生産する工場オペレーション、
あるいは同じサービスを提供する定常業務とは異なるということです。
また、プログラムというのはですね、プロジェクトの上位概念で、
日本初のプロジェクトマネジメントの体系であるP2Mによると、
プログラムとは全体指名を実現する複数のプロジェクトを
有期的に接合された事業であるとしています。
例えばですね、新しい自動車部品工場の建設というのはプログラムになって、
その工場の中のある部品の製造ラインを設置する
ということはプロジェクトと言えます。
典型的なプロジェクトの例というのを示すと、
まずですね、一つ目として化学プラント、石油生成プラント、
医薬品プラントなどの各種プラント、工場の建設。
二つ目として、情報システムの構築。
三つ目として、ビルやラム、下水道設備、高速道路などの大きな建設ですね。
そして四つ目として、研究開発型プロジェクト。
こういったものがありますよということです。
そして、プロジェクトステークホルダー。
ステークホルダー、利害関係者という言葉がよく使われますけれども、
このプロジェクトにもステークホルダーというのが適用できます。
プロジェクトステークホルダーとは、
プロジェクトにプラスまたはマイナスの影響を及ぼす次のような個人や組織であると。
一つ目はですね、プロジェクトマネージャー。
プロジェクトマネージャーがいます。
二つ目として、顧客、プラントオーナー、ユーザー。
例えば、医薬品工場を建設する場合、プラントオーナーというのはその製薬企業で、
コントラクターにとっては顧客であると。
また、その製品である医薬品を購入する将来の消費者はユーザーであると言えます。
そして、ステークホルダーの三つ目としては母体組織。
プロジェクトとして承認し、プロジェクトマネージャーを専任する企業で、
特にはジョイントベンチャーなどの企業体であると。
ステークホルダーの四つ目はプロジェクトチームのメンバー。
五つ目がスポンサー。これはプロジェクトに対して財政的な支援を行う個人や組織のことです。
六つ目は政府、地方公共団体。
価格プラントあるいは医薬品プラントを建設する場合、その建設地の法律だったり条例に従わなければいけません。
特にはその税制面で支援を受ける場合もあります。
そしてステークホルダーの七つ目がサプライヤーですね。
資材や人材を提供するベンダーだったり協力会社。
そして八つ目が環境団体。
工場を建設する場合に地球環境への負荷を考慮したければならないので、
その環境に対して有害であれば、環境団体はそのプロジェクトに対してマイナスの影響力を行使する場合があります。
建設の反対運動だったり、そういうものがあるということですね。
というのがステークホルダーです。
プロジェクトライフサイクル
そしてプロジェクトライフサイクル。
プロジェクトには始まりと終わりがあります。
その中にはフェーズと呼ばれるいくつかの段階に分けることができます。
ある工場を建てるプロジェクトの場合、
引き合いから受注、そして設計・調達・建設・試運転までの数年間をプロジェクトライフサイクルと考えます。
この引き合いだったり受注というのは、プロジェクトのフェーズを区切る重要なイベント。
マイルストーンと言いますね。
このマイルストーンということはよく使うんですけれども、
もともとはローマ帝国が主要な街道に1ローママイル。
1ローママイルというのは千歩ですね。
千歩ごとに標章として標識として設置した石が始まりと言われているそうです。
そしてプロジェクトを遂行するにあたり、最初に決めなければいけないことをスコープ・オブ・ワーク、
役務範囲と、それからスコープを誰が担当するかというスピリット・オブ・レスポンシビリティ、
役務区分というのがあります。
これらですね、役務範囲と役務区分を曖昧にしたままプロジェクトを進めてしまうと、
プロジェクトの関係者の間に疎後が生じて、無用なトルボラグが発生します。
なのでプロジェクトを開始するにあたり、まずはその役務範囲と役務区分というのを明確にすることが必須条件で、
それらを明確にする手段として、WBS、Work Breakdown Structureというものがあるそうです。
ちょっとここでは内容までは説明しません。
そして、プロジェクトリスク管理。
プロジェクトを成功させるためには、リスク管理というのが不可欠です。
その方法はですね、通常のリスクマネジメントと同様で、
まずそのリスク管理の方針を検討し、リスク管理要領を作成します。
そしてそのプロジェクトのリスクを特定して、そのリスクを分析、評価します。
そして最後にリスク対応の検討をするということですね。
プロジェクトの過去の事例を参考にすると、そのリスク管理を効果的に行うことができます。
プロジェクトの完了時には、そのリスク管理について計画、仮定、
そしてその結果で得られた情報というのを教訓として残すことが重要となってきます。
プロジェクトスケジュールとコミュニケーション計画
次がプロジェクトスケジュール。
プロジェクトスケジュールは、そのプロジェクトを予定通りに終わらせるための管理ツールであります。
鎖の強さは、その中の一番弱い輪の強さという例えは、プロジェクト管理によく当てはまるそうで、
そのプロジェクトのスケジュールというのは、時間軸上で目標達成の障害となる弱い輪を洗い出して、各種の対応を促すために作成されます。
そしてその計画において、ローリングウェブコンセプトを適用するという特性を備えているということです。
このローリングウェブコンセプトというのは、段階的詳細化。
これは遠くの波は線として見えないが、近くなるとその形をよく認識できるという事柄から名付けられている計画の方で、
多重構造の側面を持ち絶えず変化するプロジェクトスケジュールにおいては、
はじめは全体を荒く捉えて段々詳細にしていくと、
そして予測の難しい遠い将来を荒く、近い未来を詳細に計画していくと、そういうコンセプトということです。
そしてコスト見積もり。
コスト見積もりは、プロジェクトの計画段階などで、各フェーズにおいて数々の計画を行うときに重要な作業となります。
見積もりの技法としては3つありまして、指数法、係数法、積算法というのがあります。
次はプロジェクト組織と人的資源計画。
プロジェクトを実施する組織は一般的に機能型、プロジェクト型、マトリクス型に分けられます。
それぞれ簡単に説明すると、まず機能型ですね。
機能型というのは一般の企業が概ねこの形で形成されていて、階層構造のピラミッド型の組織となっています。
そしてプロジェクト型組織。
これはプロジェクト達成のためにプロジェクトチームが結成されたもので、
プロジェクトチームに必要な人員というのを元々機能型の組織にいた他の部署から移動させてきて、
その人員をプロジェクト遂行のために必要な期間、完全に拘束してしまうという組織形態となっています。
3つ目のマトリクス型組織ですけれども、
これは機能型とプロジェクト型組織を融合させた形態がマトリクス型組織です。
これはプロジェクトチームにはプロジェクトのマネージャーと少ない人数の要員しかいなくて、
各専門の技術者というのは機能型組織に所属したまま、
そのプロジェクトの業務も兼任ですかね、そういう形で行う組織の形態です。
そしてコミュニケーション計画。
プロジェクトの運営上の情報の質と量を支配する要素としてのコミュニケーション計画というのが重要になってきます。
コミュニケーションにはノイズ、これは情報の理解のずれだったり非効率さ、
それがありまして、その情報の発信者と受信者、それぞれの思い込みだったり、
その各自の業務経験の違いというのがコミュニケーションの疎外要因となり得ます。
発信者の意図というのは、100%受信者に伝達できないということを念頭に置いておく必要があって、
必ずその伝達相手の理解の確認というのを行って、自分の意思が必ずその100%伝達されているかというのをフィードバックを行うことでこの問題というのは対処できます。
そして次は設計計画。
一連のプロジェクト遂行作業の中で、顧客の要件を明確にして具体化すること。
設計業務の計画と種類
これが第一番目に位置づけられる設計業務でありまして、品質、納期及びコスト、QCDの視点から最適化する設計が行われるように計画することが設計計画といいます。
設計の種類として5つここでは分けられていて、概念設計、予備設計、基本設計、
詳細設計、生産設計という5つですね。
概念設計というのはまずプロジェクトの実現可能性を検討するのが概念設計。
次の予備設計というのが、受け負い業者、協力会社の引き合いのための簡単な設計をすると。
そして3つ目の基本設計は、設計要件を確定するための設計ですね。
これは基本設計。
そして最終的には手図までいく詳細設計と、それを生産するための生産設計という5つの段階があるということですね。
この5つの段階を進むにつれて、設計というのは段階的に詳細化され、前工程の設計情報というのがアウトプットがですね、
次の工程の設計のインプットとなります。
次は設計管理。
設計計画に基づいて、各設計段階を円滑に遂行していくためには、次のような管理が必要となります。
1つ目が設計進捗管理。
設計の出来方、出来高、出来高を数値的に、例えばパーセントで表示したり、各マイルストーンの進捗で表すことですね。
2つ目。2つ目の管理が設計変更管理。
設計の要件に変更があったり、設計ミスによる変更が生じた場合、速やかに設計変更通知を発行します。
またその変更の管理表をですね、作成して管理していくということですね。
そして3つ目の管理が設計要因管理。
設計の進捗状況をレビューしたり、適切な設計要因が配置されているかどうかをモニタリングして、
設計要因のパフォーマンスを測定することによって、その完成予定時期及びコストの予想を行って、設計予算管理を遂行していくということです。
4つ目が設計評価。
設計管理、設計評価、調達計画、プロジェクトの評価とフィードバック
これの中に3つありまして、まずは設計審査の全般。
これは一般的なデザインレビューと呼ばれるものですね。
3D CADによるレビューというのも一般的になってきました。
そして設計品質審査。
設計品質に影響を及ぼす書類にはですね、作成者、確認者、承認者の記録が記載されます。
また複数の設計部門をまたぐような書類や作業には、そのレビューミーティングを招集して設計品質確保に当たります。
3つ目がHSE設計審査。
HSEとは、ヘルス、セーフティ、エンバイロメントの略で、衛生、安全及び環境の観点からそれぞれの設計要件が満たされているかをレビューすることですね。
この3つが設計評価となります。
次が調達計画。
調達計画は、プロジェクトに必要な資源をいつ、どのように経済的に購入するかを計画することです。
設計によって決定された仕様と数量がベンダー引き合いによって得られた単価から発注されて、最終的にコストとなります。
次がプロジェクトの評価とフィードバック。
プロジェクトの遂行に際しては、PDCAサイクルを回してプログレス評価を定期的に実施して、計画と実績の差異を早期に把握・強化し、原因を明確にして対策を立案し、継続的に改善を実行することが必要です。
プログレス評価とは、スケジュールとコストの見積もりを計画と実績の差異と比較して評価するものです。
プロジェクトの終了時には、完了報告書、顧客満足度、ステークホルダーからのフィードバック、不適合事例、失敗事例、計画との相違、お客様からのクレーム、成功事例に対するノウハウ、
プロジェクト中に起きた大幅な変更に対する理由・対応・結果、リスクマネジメントの適切性、ステークホルダー間のチームビルディングの有効性、コミュニケーション方法の適切性をレビューします。
プロジェクトの遂行においては、QCD、品質、コスト、納期はトレードオフの関係にありますが、近年は高品質の製品を短期間に低コストにして製造すべしと、鬼のような顧客要求が強くなっているということです。
その顧客の満足度を得るには、プロジェクト計画を綿密に立案して、計画との差を遅れなく把握・評価して、その原因を特定してフィードバックして改善していく、PDCAを回していくしかありませんということです。
難しい。これは難しいですよね。
以上、8章のプロジェクト計画と評価でした。
クロージングです。
今回は技術士ハンドブックの8章、プロジェクト計画と評価を読んでいきました。
次回は9章の倫理をやっていきます。
最近は、豊田など大手自動車メーカーの検査不正が明らかになり、大きな問題となっています。
技術者個人の倫理だけではなく、会社としての企業倫理、そういった話も出てくる9章です。
このアプリの機能は6月に終了しますというアナウンスがありました。
いつ終わってしまうか、戦々恐々としているんですけれども、
今日6月9日の時点ではまだ提供されています。
次の収録環境が決まるまでは、しばらくポッドキャストはお休みするかもしれません。
ということで、今週はここまでです。
ポッドキャストの感想・質問は、
ハッシュタグデザレーFM、デザレーはカタカナ、FMはアルファベットで、デザレーFMでお待ちしております。
各ポッドキャストアプリでの評価も、ぜひぜひお願いします。
ではお疲れ様でした。ご安全に。