Comments
Transcript
5．プロジェクト管理と PLM TTM（Time To Market）の短縮に伴い、製品
５．プロジェクト管理と PLM TTM（Time To Market）の短縮に伴い、製品開発効率化のためプロジェクト（PJ）制に よる製品開発体制が増え、益々PJ 管理の必要性が高まっています。すなわち、これまで述 べてきましたようにコンカレントエンジニアリングやフロントローディング、原価企画な どを当該 PJ 内で円滑に進めるには、PJ の進捗（工数、コスト、品質）や各工程でのイン プット／アウトプット（成果物）情報などが管理されている状態（みえる化）になければ うまく行きません。みえる化のためには、情報がディジタル化されていること、進捗を示 す指標が明確化されていることが必要です。PJ 管理を人手主体でやっていては、関係者が 適時に見られないばかりでなく時間も掛かるし誤りも発生します。 ５．１ PJ 管理とは PJ 管理の機能は、PMBOK（米国 PMI が提唱する PJ マネジメントのための標準的なフ レームワーク）によると、スコープ（開発の目的とその範囲）管理、タイムマネジメント、 コストマネジメント、品質マネジメント、組織（人的リソース）マネジメント、コミュニ ケーション（コミュニケーション方法と適用箇所）マネジメント、リスクマネジメント、 調達マネジメントの８つの機能があり、これらを統合して管理することが９つ目です。近 年、日本発の複雑な問題に対しいくつかのプロジェクトに分割して全体として統合しよう とする P2M（プロジェクト＆プログラムマネジメント）もあります。 （詳細は、それぞれの 資料を Web などで参照願います。 ） PLM の視点からは、その製品のライフサイクル全体を PJ ととしてみなした管理が必要 かも知れませんが本章では、 （要望の多い）製品開発の PJ 管理に焦点を当てて述べること にします。 ５．２ WBS（Work Breakdown Structure）と BOM ある製品群の製品開発業務プロセスは、基本的に同じです。従って、業務プロセスを整 理してあらかじめ雛形として標準化しておくと便利です。また、業務プロセスを整理する 場合には、BPM（Business Process Modeling）により現状のプロセスを分析すると業務プ ロセスを明確化できるとともに業務の棚卸も行え BPR（Business Process Reengineering） できるメリットもあります。業務プロセスは、WBS の形で階層化し整理することが有効で す。仕事の手順はこれで定義できます。個々の製品開発には、その製品構成を明確化し、 業務プロセス項目と合わせて作業項目を確定することが必要です。 製品構成は、BOM から取り出すことができますのでこれを使います。PJ の当初は、末端 の部品まで現れていませんが、開発が進むにつれて詳細化していきます。ここで重要なこ とは、図面を書いた結果で BOM が出来るのではなく、BOM を最初に考えた後で設計を行 なうということです。すなわち、トップダウン的、戦略的に製品開発を進めると言う事で す。部品の標準化やモジュール化はこのような進め方をしないと良いものが作れません。 ５．３ PJ 管理と成果物 PJ で予定のスケジュールに対し進捗がどうなのかが重要なことはいうまでもありません。 進捗は、予定のスケジュールに対し現状どの程度まで進んだかは予定工数との比較だけで 判断するのは不十分です。その作業で出力される成果物としてのドキュメントの出来栄え や品質情報、議事録などを見ることにより総合的に進捗を判断します。進捗の判断は、出 来うる限り定量化された指標で判断できるようにすることが望ましいです。成果物は、製 品構成に対応しているので BOM をベースに管理されるべきです。これが出来ると経営者に とっても PJ がうまく進んでいるかどうかが見えるようになります。ワークフローオートメ ーションによって検図・承認などの進捗状況も見ることができるようにすることも含め、 見える化は業務をディジタル化すると言うことです。 ５．４ PJ 管理と人的リソース お客様からしばしば要望のあるのは、要員管理の問題です。PJ に適切な要員が割り当て られるのか、要員の全体としての稼動状況や要員計画が充分かなどを管理したいというこ とです。このような人的リソースを管理するには、人事データベースとともにスキルデー タベースの整備が必要になります。スキルデータベースを作るのには、技術とそのレベル を明確に定義するとともに個々の要員の技術レベルを判定することが必要です。このデー タベースが整えられれば PJ 管理において負荷を考慮した適切な要員計画が可能となります。 最近は、製品開発の期間短縮のため PJ 制をとる企業が増えており PJ 管理ツールの要望 が多くあります。これまで PJ 管理ツールを導入しても定着化できなかった企業もたくさん あります。ガントチャートを PJ の開始時に書いて、終了時に結果を書いて上位に報告する だけと言った使い方しかできていない企業も多々みられます。この原因は、担当者にばか り負担がかかる割には担当者にメリットがないため実績入力がタイムリに行われないこと、 スケジュールの変更が頻繁に起こり、予定変更入力が追従できないことなどによります。 これらの対策として、実績はできるだけ自動的に収集できる仕組みが必要です。実績の自 動収集には、それぞれの成果物の出来具合についての指標を定義することが必要です。例 えば、３DCAD 作業において作成したフューチャー数で判断するとかが考えられます。仕 様書などではページ数や項目（目次）数で簡易的に図れるかもしれません。いずれにして も BOM ベースに各種情報が管理されていることが必要です。これにより、既存成果物は、 担当者が参照したり流用編集したりできるようになり生産性をあげるこことが出来るよう になります。すなわち、コンカレントエンジニアリング・フロントローディングが可能に なるということです。これまでの整理をすると PJ 管理を成功させるには、WBS や BOM、 人事 DB、指標などのインフラ整備がどれだけできているかが成功の鍵であると思います。 （図 10 参照）