「最後の砦、技術力がアブナイ」では、技術者は自律性、創意工夫、挑戦意欲、変化対応力などを期待されているにもかかわらず、開発現場はそのような技術者に育てる環境や仕組みになっていない。そして、製品開発を成功させるための開発プロセスやプロジェクト管理の仕組みだけでなく、必要なスキルを持つ技術者に育てる仕組みが必要だ、という内容でした。
求められている技術者を育てる仕組みとして、「チーム体制」「経験学習プロセス」「エンゲージメント」という3つのキーワードを紹介しましたが、今回は、この中の「チーム体制」について解説したいと思います。
1. チームとグループの違い
「チーム」という単語は普段から使うので、特別なことには思えないかもしれません。チームによく似た単語に、グループがあります。チームの意味を明確にするために、この二つの定義を比較してみましょう。ある辞書では、次のように説明されています。
グループ：共通の性質で分類した人や物の一団。群。
チーム ：ある目的のために協力して行動するグループ。
チーム ：ある目的のために協力して行動するグループ。
たとえば、会社でサッカーが好きな人が集まって昼休みに楽しむのはグループで、地区大会優勝などの目標に向かって協力して前進しているのはチームということになります。チームとは、特定の目的に対して達成すべき目標をすべてのメンバーが共有し、お互いが連帯責任を果たす補完的な関係からなる集合体、といえるでしょう。
では、製品開発現場にチームは存在するのでしょうか？ プロジェクト・チームで製品開発に取り組んでいるところも多いと思いますが、本当の「チーム」はないのではないかと感じます。チームとグループの境目は実は曖昧です。目標達成への思いや、メンバー間の協力関係などの程度によって、グループと考えることできるし、チームと考えることもできるでしょう。
「チーム」をもっと具体的に定義する必要がありますが、「チーム」をわかりやすく説明している書籍があるので紹介しておきたいと思います。その名も「ザ・チーム」です。
ザ・チーム（日本の一番大きな問題を解く） 齋藤ウィリアム浩幸，日経BP社 (2012/10/4)
著者の齋藤氏は、アメリカ生まれ、アメリカ育ちの日系二世の起業家で、高校時代に友人と始めた自社をマイクロソフトに売却した後、日米で幾つもの企業経営に関わる生粋の起業家です。日本でも、国家戦略会議フロンティア部会など、いくつもの政府会議にも名を連ねて、その経験から「チーム不在の状況こそ、日本の最大の課題だ」といっています。
この本の中で、グループとチームのそれぞれの特徴について次のように言っています。
【グループ】
・共通の性質で集められた集団
・指示されたゴールに向かって、決められた作業を規則正しく実行する形態
・改善や漸進的進歩に適した形態
・指示されたゴールに向かって、決められた作業を規則正しく実行する形態
・改善や漸進的進歩に適した形態
【チーム】
・ある目標を情熱を持って達成するための集団
・多種多様な人材がいて目的や目標を共有している
・メンバーが互いに助け合い、補うことで目標を達成する
・イノベーションや変化対応に適した形態
・多種多様な人材がいて目的や目標を共有している
・メンバーが互いに助け合い、補うことで目標を達成する
・イノベーションや変化対応に適した形態
チームとは、イノベーションや変化対応に適した形態であり、多様な人材が目標を共有し、お互いに助け合ってその達成に情熱を傾けているという特徴を持っているものなのです。
2. 製品開発における「チーム」の必然性
さらに、「チーム」とは次のような特徴を持つものだと言っています。
・信頼関係の上に成り立っている（自分の弱みを見せている）
・多様な個性や特性を持つメンバーからなる
・失敗を許容する、リスクをとる
・メンバーは自由に意見を言い合い、コンフリクトを怖れない
・リーダーはいるがメンバーに階層的な上下関係はない
・メンバーは自分が主体的に行動しようというオーナーシップを持つ
・多様な個性や特性を持つメンバーからなる
・失敗を許容する、リスクをとる
・メンバーは自由に意見を言い合い、コンフリクトを怖れない
・リーダーはいるがメンバーに階層的な上下関係はない
・メンバーは自分が主体的に行動しようというオーナーシップを持つ
これまでいくつもの製品開発現場を見てきましたが、プロジェクト・チームを組んで製品開発を進めていても、このような「チーム」になっているところはほとんどありませんでした。
組織図上、エレキ、メカ、ソフトなどの技術軸でグループ分けされ、仕事のアサインや評価・査定などが、技術軸のマネジャーが主体となっていることで、技術軸のマネジャーの力が強くなり、プロジェクト・チームといいながらも、グループの延長にしかなっていないなど、原因はいくつかあるでしょう。
しかし問題なのは、新しいことにチャレンジしたり、厳しい状況を打破するためのイノベーションを必要とするためにプロジェクト・チームを組んでいながら、チームがグループとしてしか機能せず、開発を定型業務として進めることや開発プロセスを遵守することが優先され、指示に従って、規則・ルールに外れることなく作業を進めることが目的化してしまっていることです。技術者がこういうマインドになっていることを看過することはできないはずです。
今の製品開発に求められているもの、あるいは、トップが現場に対して求めているものは、変化の早い市場にクイックに対応することであり、従来の延長ではない革新的な製品であり仕組みを生み出すことではないでしょうか。そのためには、本当の意味での「チーム」を作ることが必要なのだと考えます。
また、興味深かったのが次の記述です。
アメリカは個人主義の国といわれるが、実は同時にチームの国でもある。いろんな国の移民が集まっているアメリカほど、チームの大切さがわかっている国はない。チームの中で力を発揮できるかどうかが、教育の基本となっている。
アメリカは、子どもの時からチームを作り、チームの中で行動し、チームの大切さを体験する機会にあふれているということなのです。日本はチームワークを誰よりも発揮する資質を持っていると思うのですが、チームの大切さを信じて、チームで取り組もうという意識は低いのではないでしょうか。チームの良さを実感することができるような、チームで行動するための環境や仕組みを提供できていないことに原因があるのではないかと思います。
3. 「チーム」による開発とは
開発現場でも同じことがいえます。「チーム」を製品開発に取り入れることによって、日本人技術者が持っているチームワークの能力を引き出し、開発現場をイノベーションを生み出す環境に変えることができるのに、その仕組みを提供できていないのです。
では、どのような仕組みが必要なのかを考えてみたいと思います。
（1）モジュール化体制
「成功体験が重荷となる製品開発プロセス（解決策ハードウェア編）」の中で、スマートフォンのような機能が複雑化している製品の開発では、モジュール構造に合わせた開発体制にするのが良いと提案しました。この「モジュール化体制」は「チーム」を作るための仕組みのひとつです。
「モジュール化体制」は、モジュールごとに（チームごとに）メンバーが直接寄与できる具体的な目標設定ができるので、目標を共有し、その達成への思いを強化することが容易です。また、ハード担当もソフト担当も一緒になってモジュールという独立性の高い単位に取り組む体制なので、一体感を高めることにもつながります。
（2）キャラクター定義
さらに「チーム」として機能させるためには、メンバーにお互いに助け合い、補い合うマインドと、自ら目標達成のための主体的に行動するオーナーシップを持ってもらうことが大切です。それが「キャラクター定義」です。
「キャラクター定義」とは、メンバーの一人ひとりが、回路や機構、ソフトといった技術的な役割や責任を持つだけでなく、開発業務を進めることに関する特定の役割を果たすようにする仕組みです。開発を進めるチームの中でどのようなキャラクターを演じるのかを決め、メンバーにアサインするということです。
たとえば、机上での地に足がついていない議論を避けるために率先してプロトタイプやデモを作るキャラクターや、新しい部品や技術などの採用に必要になることは何でもやるキャラクター、実験室や評価治具の確保などの環境整備や段取りを考え実行するキャラクターなど、回路やソフトなどのあるブロックを担う役割ではなく、開発をうまく進めるための役割を様々なキャラクターとして定義して、メンバーに演じてもらいます。
メンバーは、アサインされたキャラクターを、開発の最初から最後まで責任持って演じることで、設計を任されている部分に対してだけではなく、開発全体に対する広い視野を持つことになります。また、技術とは関係ない役割分担なので、お互いに助け合うことも容易です。
4. 「チーム」の導入方法
モジュール化体制は、すべての製品開発の現場に適しているとは限りませんが、チームメンバーのキャラクター定義はほとんどの開発現場で採用できると考えています。
製品開発に関わる多くのマネジャーから、PM や PL...
などのリーダーが育たないという話をよく聞きます。これは、技術面だけで考えてメンバーへ仕事をアサインし、開発を進めるという運営業務をプロジェクト管理や開発管理と称して PM や PL に課しているのが原因のひとつだと考えます。メンバーの意識はいつまでも担当部分だけで、開発全体や製品全体のことを考えるようにならず、PM や PL は種々雑多な非常に多くの仕事に追われることになっているのではないでしょうか。
そこで、PM や PL の業務を整理してキャラクターとして独立させるのです。そして、そのキャラクターをメンバーにアサインすることで、ある一部分であっても開発全体の運営業務を任せるのです。メンバーはリーダーとしての視野を持つことにつながり、また、リーダーとしての喜びも味わえることができるでしょう。PM や PL はプロジェクト運営に関する負荷が軽減し、「リーダーなんて雑用に追われているだけですよ」と愚痴をこぼすことも少なくなるでしょう。
まずは、導入のための第一歩として、PM や PL の仕事を洗い出して整理することをお勧めします。整理した業務の一つひとつには、アサインされたときに楽しくなる名前をつけてください。「チーム」のイメージが具体的になるはずです。
「最後の砦、技術力がアブナイ」でお伝えしたように、今こそ技術者を育てることに力を入れるべきであり、「チーム」の導入はそのために有効な方策のひとつです。「チーム」を機能させるには、さらにいくつかの工夫や仕組みを考える必要がありますが、まずは、モジュール化体制とキャラクター定義の導入を検討してみてはいかがでしょうか。