コンセプチュアル・マネジメント

◆問題を解決しながら前に進むのがプロジェクト

しかし、問題の起こらないプロジェクトなどない。むしろ、問題を解決すれば前に進むのがプロジェクトだといってもよい。したがって、問題解決におけるチームというのは、極めて重要な意味を持っている。

日本人は専門性に対して謙虚である。自分の専門以外のことに対しては、専門家の言い分を無条件に信じるし、逆に、自分の専門に対して口出しされることを好まない。従って、異なる専門家が混じったチームで仕事をすることを好まない。

日本の製造業、特に自動車産業の強みに、部品の「摺合せ」というやり方がある。できた部品をうまく組み合わせ、性能の高い製品をつくるという素晴らしい方法であるが、摺合せも裏を返せば、チームとして仕事をしてないないことの証である。最初から、いろいろな専門家が一緒に仕事をし、ゴールを共有して、意見交換をしながら、部品から作っていけば、摺合せは必要ない。逆に、摺合せではできないことができる可能性がある。

ポイントはここだ。グループで仕事をする場合、多様性には限界がある。自分たちの問題を解決するために他の分野の知恵は入ってこない。こういう例がある。


◆システム的な問題解決のためにはチームが不可欠

ＳＧＩのレゴ・システム（ワークステーション）の開発で発生したＡＳＩＣのバグ（予想外の処理遅れ）によりシステムのハングが起こった。ハードウェアの設計チームは問題になったチップを４週間の時間と２０万ドルの費用をかけて、再設計した。ところが、再設計したチップはまた、別の問題を引き起こす。ここで、話はハードウェアの設計チームでは納まらなくなり、プロジェクト全体の問題になった。ソフトウェアのチームから、実行遅延し、タイミングを取るというアイデアがでてきて、当初の問題は解決した。

もし、ハードウェアとソフトウェアがチームだったらどうなっていただろう。４週間と２０万ドルを失うことはなかったに違いない。

この例は非常に単純で、トラブルにおける問題解決という局所的な例であるが、ここから学びたいことは、ハード、ソフトという範囲ではなく、システム的な解決をしようと思えば、チームが不可欠だということだ。


◆サシミとスクラム

プロジェクトの実施においては、グループではなく、チームを作ることが重要である。トラブルだけではなく、設計や、試作などの問題解決においても同様の効果が期待できる。設計などに別の視点が入ることにより、よりよい成果物を作ることができる。

チームは、上の例のように技術的な多様性を実現するチームがよい場合もあれば、工程の多様性を持たせることがよい場合もある。それは、プロジェクトでどのような問題が出てくるかを想定して決めるとよい。

たとえば、ＩＴのように生産が目的のプロジェクトであれば、工程の多様性のあるチームを作るのがよいだろう。上流工程に、製造の視点が入ることになり、製造の際に、より、ユーザの要求にこたえやすい設計が可能になる。日本の製造業の特技であった「サシミ」だ。

こういう書き方をすると、専門的な知識のコラボレーションがチームの目的だという誤解を与えるかもしれない。もちろん、そこにも目的の一つはあるが、それだけではない。むしろ、専門家の専門外の分野での意見が重要である。もっと重要なことは、専門家が専門の垣根をとって、問題解決に当たることである。チームとしてこういう状態ができれば、サシミが「スクラム」に変わり、イノベーションが起こりやすくなる。

こういうプロジェクトは強いし、成果物としてシステムを生み出すことができるのだ。