本記事では、メトロールで実際に運用している「新製品の開発フロー」を詳しく解説します。
「画期的な新製品を生み出し続けること」は、製造業の醍醐味であり、変化の激しい市場で会社が生き残るために無くてはならない取組みの1つです！
一方で、企画段階から製品をお客様に届けるまで、気が遠くなるほど多量のタスクを確実にクリアしていかなくてはなりません。
長期的なプロジェクトではプロセスが複雑となり、
- どこから手をつければいいのか。
- いつまでに何を終わらせればいいのか？
- 情報を誰にどうやって共有すればいいのか？
- 誰が決めるのか？
膨大な課題を前に、メンバーは途方に暮れてしまうこともあると思います。
メトロールでは2023年に、従来の製品開発の「プロセス」や「チーム体制」を見直し改革しました。
新しいシステムや管理ツールを導入した結果、製品開発の「効率」だけでなく、開発した「製品の品質」まで向上し、成果を実感しています。
痛々しい失敗談も含めたメトロールのリアルな「開発フロー改善事例」が、エンジニアの皆さんの実務でお役に立てれば幸いです。またメトロールの製品開発チームの運営が具体的にイメージできる内容です。
ぜひ参考にしてくださいね！
このブログでわかること
- メトロールの製品開発の進め方
- 製品開発の遅れを招くNG行動
- 製品開発においてベストなプロジェクトの組織体制
- 効率よく製品開発が進む「管理ツール」とその活用方法
目次
メトロールが目指すは「独創性の高い製品開発」
メトロールは、東京都立川市で「産業用センサの開発・設計・製造・販売」を自社で一貫して行っています。
新製品開発には特に注力しており、創業当時から「真似はされても、真似しない」をモットーに、自社ブランドの高精度センサを世に生み出してきました。
革新的な技術や製品の開発が高く評価され、関係省庁から表彰もされています。
メトロールは「研究開発費・設備投資額」売上比率 ２０％以上。開発のための投資を惜しみません！
開発チームで問題が噴出！プロジェクトが立ち行かない事態に。
コア業務である「製品開発」ですが、従来のやり方ではプロジェクトが進まないケースが近年増えていました。
具体的には以下のような問題が挙げられます：
- 「タスク化の漏れ」と「担当者の割り振り（アサイン）漏れ」が起きる。
└担当者不明の課題が放置され、開発期間が延びる。 - 開発プロセスで「承認確認」の枠組みやルールが曖昧。
└製品評価が不十分のまま次工程に進み、後に問題が発覚して「手戻り」が生じる。 - メンバー間で情報共有が甘く、全体の状況把握やプロセスの振り返りに手間取る。
└プロジェクトの方向転換が必要な場面で、迅速な意思決定ができない。 - チーム全体の進捗管理をする明確な「リーダー」がいない。
└自分以外の業務が把握できず、メンバーにタイムリーなフォローができない。チームの効率が上がらない。
これまではうまくいっていたのに、なぜ？
従来の開発方法では通用しなくなったワケ
これまで順調だった製品開発が、ここにきて立ち行かなくなったのはなぜか。
従来のやり方を分析して浮かび上がってきた２つの原因について解説します。
- 原因１．開発領域の拡大
- 原因２．マネジメント層の薄さ（トップ集約型チームの限界）
原因１．開発領域の拡大：メカ単体領域から メカトロ・ソフト領域へ
「メカ単体領域の開発」から「複数の専門領域が絡んだ開発」に変化したことが、大きな要因の１つです。
メトロールはメカ領域が得意分野で、これまで「機械式センサ」を主力製品として手掛けてきました。
しかし近年では、ソフトウェア・電気・流体（エア）・無線技術など「メカ以外の専門性を組み合わせた開発案件」が増えています。
メカ技術者だけで完結する開発であれば、
- メンバー間の知識の差が小さい
- 作業分担やフォローがしやすい
- 現場で意思決定をしてもミスジャッジが少ない
などのやり易さがありました。
一方、異なる専門分野のメンバーが関わる開発となると、互いの技術領域に関与しにくくなります。
考え方やスキルの異なるエンジニアが連携するには、開発プロジェクトに「体系だった仕組み」と「明確な管理者」が必要になりますが、この2つの要素が大きく不足していたと言えます。
原因２．マネジメント層の薄さ：「トップ集約型」の管理
メトロールの従来の開発チームは、”トップ集約型”の構造でした。
【トップ集約型】
・各メンバーが課題をトップに直に報告／相談して指示を仰ぐ
・トップ自ら各担当者にタスクを割り振り・作業を承認する
「トップ集約型」のチームの問題点
メンバーやプロジェクトが増えると単独ではタスクを管理しきれず、タスク漏れやアサイン漏れが頻発します。
また、実質的なリーダー役を毎回経営陣が担うため、メンバーのマネジメントスキルが育ちません。
このままでは製品開発事業が停滞してしまう！将来的に会社の存続をも左右する大問題でした。
そこで、従来の開発方法を改善し、開発フローを体系化することを決意しました！
この改革の達成目標として次の５つを掲げました。
開発フロー改革で達成したいこと
- 責任者不在によるロスタイムの回避・開発期間の短縮
- 信頼できる製品を市場に出す
- 分野の異なる専門家を一つにまとめる体制づくり
- PJをマネジメントできる人材の育成
- 開発ナレッジの蓄積
余談ですが・・・・
メトロールの「トップ集約型」は、エンジニアだった創業者の当時の開発スタイルをそのまま引き継いできた慣習です。
柱となる商材がまだ無かった頃、お客様の個別オーダーに応えることで製品を開発していました。
フィードバックを受けながら微調整していく手法によって、現場主導の柔軟性とスピード感がメトロールの強みとなりました。
今回の開発フローの改革は、よりレベルの高い環境で挑戦を続けるために必要な土台作りととらえています。
次章からは、メトロールが開発フローに実際に取り入れた具体的な施策について説明していきます。
開発フローに新たに取り入れた３つの施策
開発フローの改革で、メトロールでは新たに「３つの仕組み」を導入しました。
- プロダクトマネージャー制
- 商品化フレーム
- 管理ツール「バックログ」の活用
1. プロダクトマネージャー制
■プロダクトマネージャー制とは
「プロダクトマネージャー」（PdM)は、
・「開発する製品（プロダクト）の方向性を定め、プロジェクトを実行する責任者」です。
・PJ全般に携わる「現場の司令塔」を果たします。
PdMが現場の意見を集約することで、PJの全体の進捗を正確に把握できる体制になりました。
PdMの役割は大きく４つ
- 目標とタスクを定義する
- タスクに担当者を割り振る（アサインする）
- 担当者から業務の結果報告を受ける
- 上長へ作業の進捗を報告・相談する
プロダクトマネージャーを置くことで生まれる４つのメリット
メンバーと最終承認者（社長）の間に、PdMを置くことでどのようなメリットが生まれるのでしょうか。
メリット１．市場のニーズに合わない製品開発を未然に防ぐ
PdMは[経営側]と[現場側]の認識を調整し、常にユーザ視点を重視した開発を推進します。
「ユーザー視点で開発を進めること」はプロジェクトでは最も重要です。
しかし長期的なプロジェクトでは、現場の判断が製品の完成を優先し、「ユーザーはどんな製品を求めているか」という当初の開発目的を見失いがちです。
PdMは、小さな「現場判断」も漏れなく集約し、常に経営陣と連携しながら、ユーザーのニーズに沿った製品開発を確保できます。「開発した製品がユーザに受け入れられない」というリスクを最小限にすることができるのです。
メリット２．チーム全体のタスク管理の向上
PdMは各メンバーから作業報告を受ける権限を持ち、チーム全体の進捗状況を正確に把握することができます。
個々のタスクしか見えていない状況で起こりがちな、
・「○○さんがやってくれてると思ってた！」
・「え？それ私がやることだったんですか？？」
といったムダな混乱や停滞時間を回避。タスクの抜け・漏れや、担当者のアサイン漏れによる遅れを解消します。
メリット3. PJの迅速な軌道修正・方針転換を可能にする
PdMは工程が計画通りに進んでいるか常にチェックし、問題が発生した場合には適切に経営陣に報告します。これにより、迅速な経営判断を下せる環境を整えることができます。
メリット4. チームワークの意識向上
PdMはプロジェクトの全フェーズにおいてタスクを管理を行います。自身の技術領域だけでなく、他のメンバーの責任範囲も理解を深めることで、異なる部門間の連携をサポートします。
例えば、
・量産フェーズは、[生産技術部]や[製造部]
・評価フェーズでは、[品質保証部]
・販売フェーズでは、[営業部]
状況に応じてPdMがメンバーにフォローを促し、柔軟なサポート体制を構築できます。
2. 商品化フレーム
製品開発フローに導入した2つ目の施策は「商品化フレーム」です。
■商品化フレームとは？
商品化フレームは、新製品の企画から市場に送り出すまでの工程を体系的にまとめたものです
以前はメンバー間でふわっとした曖昧な共通認識で進んでいたプロセスが明確になりました。
大手企業で多くの開発経験を積んだベテランエンジニアが商品化フレームのたたき台を作りました！
承認プロセスの明確化のメリット
商品化フレームにより、以下のことがメンバー全員の共通認識となりました。
- 開発プロセスがどのように進むか
- 各フェーズで何をクリアしなければならないか。
- どのフェーズに誰が関与しているか
- 次の工程に進むには何を達成し、誰の承認が必要なのか
これにより、開発が進んだ後に項目の抜け漏れが発見されて作業が手戻ることがなくなりました。
また、評価が不十分なまま製品を市場に送り出すといった重大なミスも確実に防げるようになりました。
3. バックログの活用
3つ目の施策として、プロジェクト管理ツール「バックログ」を導入しました。
バックログを使用することで、以下の悩みが解決しました。
誰がどのタスクを進めているのか、メンバー全員が把握できます。タスク漏れを防ぎ、担当者不在のまま放置される課題も無くなりました。
作業の進捗もリアルタイムで確認できるので、フォローやスケジュール変更もスムーズです。
タスクごとの資料をバックログで一元管理することで、誰でも必要な情報に短時間でアクセスできます。
現状把握・プロジェクトの振り返りが円滑になり、計画変更や軌道修正の判断が素早くできるようになりました。
新入社員のキャッチアップや、引継ぎもスムーズです。
各課題におけるメンバー間の会話も貴重な情報として記録します。新プロジェクトでも似たような課題は常にあるもので、過去の開発経験から学びを得やすくなります。
メンバー間の「会話」は、
「誰がいつどんな役割をもっていたか？」「どんな段階を経てプロジェクトが進んだか」を知る重要な情報です！
開発フレームのまとめ
以上、メトロールが従来抱えていた開発課題をクリアする施策の解説でした。
3つの施策は課題解決に相互に機能しています。
新システムを運用してみての感想と今後の課題
インタビュー①：【若手エンジニア】すぎさん
製品開発フローの新システム導入で今回はじめてＰｄＭを任された製品開発部 すぎさんに率直な感想を聞いてみました。
Q. 新しいシステムを導入して、開発チームは以前と比べてどう変わりましたか？
新しいシステムでは報告・承認手続きが増えたため、開発スピードは以前よりやや低下した感はあります。ただ結果として、抜け漏れによる手戻りなく完成度の高い製品を効率的に造ることができるようになったので、本質的な開発に近づいたと思います。
Q. すぎさんはPdMを任されていますが、マネジメント業務に負担を感じることはありませんか？
PdMはメンバーがやっている作業の内容を知らないと務まりません。私自身はメカニックが専門ですが、電気電子や生産技術も学ぶのは好きなので、そこに関しての負担はあまり感じてませんね。
ただ、チーム全体をマネジメントするのはまだまだ苦手です。
・メンバーへの指示の出し方
・スケジュールの組み方
など、マネージャーとしての仕事は、経験豊富な先輩にアドバイスを受けながら実践の中で学んでいるところです。
複雑な要素が絡み合った画期的な製品を造るためには、なくてはならないスキルなので、一つ一つ経験を積みながらマネジメント力を磨いていきたいですね
Q. 開発フローにおいて、今後の課題は何ですか？
ルールを細かく設定しすぎてしまうと、メンバーが指示待ちになったり主体性がなくなったりしてしまう恐れがあります。
昔からメトロールのエンジニアは自由に面白いものを造ってきた歴史があるので、そのクリエイティビティを阻害しない仕組みにしたいと思っています。
今後、エンジニアの個性を最大限に活かす、メトロールにあった運用ルールのあり方を見極めて、さらに突き詰めていきたいですね。
インタビュー②：開発チームの統括・PdMのアドバイザー役 つのさん
つづいて、PdMの指導役となっているつのさん。
大手企業からの転職組で、前職でのマネージャー経験はおよそ２０年。１０００人規模のビッグプロジェクトも束ねたこともあるマネジメントのエキスパートです。
Q. つのさんはメトロールに入社後（2022年）、新しい開発フローの立ち上げに中心的に関わってきました。 メトロール流のやり方にテコ入れした理由を教えてください。
これまでのメトロールは特にルール化された仕組みがなく、その時々で開発の中心となっていた技術者のパフォーマンスに左右されている状態でした。その人次第で開発が停滞したり、逆にもうちょっとデータ取った方がいいんじゃないの？っていう状況で進んでしまうケースもあったようです。
エンジニアが思い描くモノを造ると面白い製品が出来上がるんですが、やっぱりココが抜けてない？って指摘してくれる人が明確でなかったんですね。あらかじめブレーキを踏む役割の人を定めて、メンバーは承認が通るように事前にデータを取って理屈を固めていく。そういうやり方が必要だと感じました。
Q. 実際に新システムを運用してみてどう感じていますか？
メトロールの「ちょうどいい規模感」で新システムが上手く回り始めているという実感がありますね。
というのも、前の会社は「仕組み」にとらわれすぎて大変だったんです。大手企業にありがちなんですが、各プロセスで承認ゲートやブレーキをかける役割の人が多すぎて、開発がなかなか前に進まないことが多々ありました。
その点、メトロールはPdMや他のメンバーが行き詰っているところを少ない人数で互いに補完しているので、今のところうまくいっています。アクセル踏む人を助けようとゲート役の人が手を差し伸べる、だからプロジェクトが進むんです。みんながブレーキ踏む人に徹したらアクセル踏む人は途中でくじけちゃいますから。
PdMだけが背負うのではなく、みんなでプロジェクトを進めようと努力しているところがいいカタチですね。
Q. PdMを指導する立場ですぎさんのサポートをしていますが、PdMに大事なのはどんなスキルですか？
プロジェクトを完遂するには多くの障害があって大変なんですが、どんなことがあっても最後までやりきる、というのが大事だと思います。メンバーが困っていたらみんなが助けようとする「結束感」をどうつくっていくか。PdMには「周囲を巻き込む力」を身に着けていって欲しいですね。
あとは、会社の事業としてプロジェクトを継続できないと判断する場合、「その根拠や材料を経営側に適切に伝えられる」というのもマネージャーとして大事なところです。
これまで一生懸命やってきたものであっても、「やり続けて結果がでるか／でないか」そこを見極めないといけない。技術的な内容が絡んでくると経営陣ではわからないこともありますよね。だから現場を知るエンジニアがPdMをやることが重要なんです。
PdMは「経営者が正しくジャッジできる材料をどう集めてどう提供するか」が肝心。
すぎさんが迷っているときは、「すぎさんはどうしたいか」「なぜ迷っているのか」理由も必ず聞くようにしています。そこまで共有していくとだんだんと自分の物差しが出来てくると思いますね。PdMは単なるチームの調整役にとどまらず、会社の意思決定にも関わるのでその辺の感覚も磨いてほしいですね。
まとめ：まだ世に無いモノを創り出すために
いかがでしたか？
今回ご紹介したメトロール流製品開発のノウハウが、少しでも読者のみなさんの参考になれば幸いです。
「開発」はメーカーの心臓部であり、企業ごとにそれぞれの手法、風土が色濃く出るところだと思います。だからこそ、長年当たり前になった習慣やルールを
・このやり方は最善だろうか？
・もっと生産性を上げられないか？
・削れるコスト、時間のムダはないか？
を改めて見直すと、出来上がった製品を通してその効果を実感できるかもしれません。
メトロールでは、開発フローを改善したことで、これから新規で加わる技術者にとってもチームに合流しやすくなったと確信しています。
まだ世の中に無い新しい価値をぜひ、私たちと一緒に開発しませんか？
メトロールでは一緒に働く仲間を探しています。
メトロールは生産設備や工作機械などの自動化に貢献するセンサーメーカーです。東京都立川市で作ったセンサは世界74ヶ国、7000社以上のお客様にご利用いただいています。次世代のものづくりや設備に使用されるユニークなセンサの企画から開発・製造までを一貫して行う開発型メーカーでもあります。
メトロールブランドを共に支え世界へ広めてくれる仲間を探しています! 少しでも興味を持っていただけた方は、メトロールまで気軽にご連絡ください。まずはカジュアル面談からという方でもOKです!