プロセスを変える

Profile

しゅう206

フォローする

大規模なプロジェクトを運営するリーダーになったら、
皆さんは、まず、何から手をつけるだろうか。

---

例えば、製品開発プロジェクトを想定してみよう。

そこでは、当該製品を開発（設計）する部門だけではなく、
例えば、次のような、多くの関連部門とも、協業することになる。

●先行要素技術を提供する研究部門
●工法・設備を仕上げる生産技術部門

●生産を担当する製造部門
●生産コストを調整する原価部門
●生産量を調整する生産管理部門
●製品の品質システムをマネジメントする品質部門
●製品の保管・輸送を担当する物流部門
●販売を担当する営業部門

製品開発プロジェクトの実態は、外からは分かりにくいため、
一般に「製品開発」と言うと、直接的に製品設計を行う機能や、
個別技術課題の解決機能が、注目されることが多い。

エンジニアによる「製品開発」「ものづくり」と言うと、
それしか思い浮かばない人も、少なくないと思う。

量産設計や試作ステージ、あるいは性能評価など、
関連部門が協業しあって、多くの課題がクリアされなければならない。

実際、製品化に失敗したプロジェクトのうち、少なからぬ例で、
立派な要素技術、優秀なメンバーを準備したにも関わらず、
そのような機能界面部分での躓きが顕在化し、失敗につながっている。

ひとつの部門としての「製品開発機能」ではなく、
プロジェクトとしての「製品実現機能」が、重要な鍵を握る。

---

大規模プロジェクトのリソース（人・モノ、時間、予算）と、
検収条件（目標値）は、予め、トップから与えられることも多い。

そのため、プロジェクトリーダーの当面の仕事は、
検収条件を達成するために、上のような関連部門のメンバーを含めて、
プロジェクト全体を、うまくマネジメントすることにある。

今、クロスファンクショナルなチームに所属し、
いくつかの製品開発プロジェクトに、横串で深く入り込み、
開発プロセス上の課題解決や、個別課題の解決アシストをしている。

複数プロジェクトで、リーダーの仕事に関わってみると、
多種多様、うまい/へた、モチベーションと意識など、
プロジェクトマネジメントのあり方も、いろいろ見えてくる。

単一のプロジェクトの中に入る人は少なくないが、
同時並行で複数プロジェクトを見ている人や、
大規模なプロジェクトの全体が見える位置にいる人は、
さほど多くないかもしれない。

そのような立場から気付いたこと、分かったことなどを、
これから、時々に、紹介してみたい。

お気に入りの記事を「いいね！」で応援しよう