Club-Zコラム第26回

【第26回】イノベーションのための「チーム体制」

株式会社RDPi　　代表取締役　石橋　良造

2013.04.18

開発現場でも同じことがいえます。「チーム」を製品開発に取り入れることによって、日本人技術者が持っているチームワークの能力を引き出し、開発現場をイノベーションを生み出す環境に変えることができるのに、その仕組みを提供できていないのです。

それでは、どのような仕組みが必要なのでしょうか？ 今の開発現場の問題を解決する開発体制を組むことが、「チーム」を機能させることになると考えています。

■技術軸ベースの体制の限界

スマートフォンが顕著ですが製品の多機能化、複雑化は避けられません。また、ネットワークなどの技術は驚くほどの早さで変化しており、その対応も避けては通れません。しかし、このような状況に対応できず、次のような問題を生じている開発現場は少なくありません。

• 購入するデバイスや高機能部品が増え、さらに、それらのデバイスや部品も並行して開発が進んでいるため、製品開発中にバージョンアップや仕様変更が発生する。そのために、以前動いていたものが動かなくなり、計画外試作を作ることになってしまう。
• アプリケーションソフトやシステムソフトが稼働しないと、デバイスドライバーも含めたハードウェアのユニットレベルの完成度確認ができない状況が増えており、基本機能であるにもかかわらず、設計試作や量産試作で評価することになっている。そのため、量産試作の完成度が低くなっている。

詳しい分析は別の機会にお伝えできればと思いますが、開発体制が原因のひとつだと考えています。先行技術開発、企画、設計、製造というように工程で分かれていたり、電気、メカ、ソフトというように職能で分かれている組織体制が問題を引き起こしているのです。前述のように、たとえプロジェクト・チームを組織していても、技術軸の影響力が強く、開発の流れが分断されているのです。

技術軸で分かれていることによって、技術者間のやりとりが増えて開発期間が長くなったり、やりとりのヌケやモレが起きて不具合を起こしていることが、従来のようにはリカバリーできなくなっているのです。そもそも、分断された一部を担当する意識になっている技術者では、高機能化、複雑化の進む製品開発は難しいのです。


■製品構造に合わせた開発体制

今の製品開発に求められているのは、結束が強く、変更などに素早く対応可能な開発体制です。そのためには、技術者にとって、機能や性能などの目標が開発作業に直結していて、目指すべきものが身近で明確であることが大切です。

このような状況に適した開発体制は、製品の構造、構成に合わせることです。現在は多くの製品でモジュール化が進展していますから、体制もそれに合わせたモジュール化を目指すのです。

図55　モジュール化体制　※画像をクリックすると拡大表示します

モジュールとは、製品を構成する密にまとまったひとかたまりの機能単位で、スマートフォンであれば、ディスプレイ（パネル）、カメラ、電源・電池、無線、 Wi-Fi というような単位になります。良いモジュールは、その中では機能やデータなどが密接に結びついていながら、他のモジュールとは疎結合になっています。

モジュール化を意識した体制でなくても、実際の開発現場は、同じ製品を開発していながらも、モジュールによって開発の特徴ややり方が異なっているはずです。技術要素はもちろんのこと、部品・部材のサプライヤーの特徴や動向、アウトソーシングの必要性やその実施方法、完成度評価の観点やその判断方法、そして、担当する技術者の育成方法など、開発する部分（モジュール）によって大きく違うのではないでしょうか。

たとえば、カメラモジュールは、海外の中小企業を中心に協業できるサプライヤーを見つけ、設計段階から協業することが重要になるでしょうし、Wi-Fi モジュールであれば、Wi-Fi Alliance や 3GPP などの団体の動向調査や、大手デバイスメーカーとの契約やコミュニケーション方法が重要になるでしょう。モジュールによって、重視すべき工程はもちろん、開発の進め方も違うでしょうし、技術者に必要なスキルも違います。一律に同じ開発工程、同じ進捗管理、同じ体制では適切なマネジメントはできないはずです。

したがって、モジュールごとに、その特性、特徴に合わせた開発プロセスやプロジェクト管理、パートナーやサプライヤーとのリレーション管理、技術者の育成方法などを「設計」して実践する、そういう体制が理想的です。

この「モジュール化体制」はまさに「チーム」そのものです。モジュールごとに（チームごとに）メンバーが直接寄与できる具体的な目標設定ができるので、目標を共有し、その達成への思いを強化することが容易です。また、ハード担当もソフト担当も一緒になってモジュールという独立性の高い単位に取り組む体制なので、一体感を高めることにもつながります。


■キャラクター定義

さらに「チーム」として機能させるためには、メンバーにお互いに助け合い、補い合うマインドと、自ら目標達成のための主体的に行動するオーナーシップを持ってもらうことが大切です。それが「キャラクター定義」です。

「キャラクター定義」とは、メンバーの一人ひとりが、回路や機構、ソフトといった技術的な役割や責任を持つだけでなく、開発業務を進めることに関する特定の役割を果たすようにする仕組みです。開発を進めるチームの中でどのようなキャラクターを演じるのかを決め、メンバーにアサインするということです。

図56　チームメンバーのキャラクター定義例　※画像をクリックすると拡大表示します

たとえば、机上での地に足がついていない議論を避けるために率先してプロトタイプやデモを作るキャラクターや、新しい部品や技術などの採用に必要になることは何でもやるキャラクター、実験室や評価治具の確保などの環境整備や段取りを考え実行するキャラクターなど、回路やソフトなどのあるブロックを担う役割ではなく、開発をうまく進めるための役割を様々なキャラクターとして定義して、メンバーに演じてもらいます。

メンバーは、アサインされたキャラクターを、開発の最初から最後まで責任持って演じることで、設計を任されている部分に対してだけではなく、開発全体に対する広い視野を持つことになります。また、技術とは関係ない役割分担なので、お互いに助け合うことも容易です。