根本原因(コア・クラウド)を見つける

第二回では、「責任者が不明確になっている」というUDEに対するクラウドを作ってみたところまででした。
今回は、別の2つのUDEをクラウドで表現してみます。

第一回で挙げた15個のUDEのうち、重要そうで、「責任者が不明確になっている」とは質の異なるものを選びます。今回は下記の2つのUDEを取り上げることにします。

  • 日程遅れが常態化している
  • 製品全体を理解できる技術者が減少している

第二回で説明した手順に従って、2つのUDEをクラウドで表現していきます。

まず、「日程遅れが常態化している」という問題の本質を考えてみます。なぜ、日程が遅れるのか、いくつかの仮説を考えてみると、

  • もともと無理な日程で進めようとしている。
  • 予期しない問題がいつも発生し、その対応に時間を取られる
  • 最初の試作での品質が悪く、品質問題解決に時間がかかる

ここにどんなジレンマがあるのか、私の経験で言うと、製品企画の段階で、確立されていない技術と確立されている技術が混在したまま、技術の完成度が不明確なまま製品開発を進めようとすることが、根本の原因のように思っています。

まずは試作機を作ってみなければ何もわからないじゃないか!という考えが、上層部にも現場にも行きわたり、大きな技術リスクを背負ったまま、製品開発をスタートすることが当たり前だという考え方が、会社そのものの考え方になっているような気がします。
試作機を作る前に、大きな技術課題を解決する、いわば”急がば回れ”という考えに思いも及ばないことに気づいていないのではないでしょうか。

直観的に、すぐにモノを作ることが一番早いやり方だと信じている人は多いと思います。それ以外のやり方があるのかと反論されそうですが、トヨタの開発手法は、セットベース開発とも呼ばれ、技術課題を小さな実験を繰り返して、知識として積み上げ、すべての技術課題を解決してから詳細設計に入るというやり方をしています。
これも一見、当たり前のように聞こえるかもしれませんが、多くの製造業の開発組織では、これが出来ていません。一般的に、いくつもの技術リスクを残したまま、一点突破で詳細設計をスタートするやり方をポイントベース設計と読んでいます。

このような背景を考えて、私は、下記のようなクラウドを考えてみました。

 

次に、3つ目のUDE「製品全体を理解できる技術者が減少している」という問題の本質を考えてみると、日々の開発の仕事をする中で、製品全体の知識を得るチャンスが減っているということが起こっていると仮説をたてます。

製品全体の知識を得るためには、自分の担当以外の人たちが何をやっているのかを知る必要があります。日々の開発活動を見ているだけでも、どんなことで悩んでいて、どんな課題を抱えて活動しているかを見ていれば、他の人たちのやっている「技術」というのが理解できてくるように思います。

また、製品全体の開発をインテグレーションする過程を見る必要もあるかもしれません。
個々のサブユニットを組み合わせて、つなげていく作業や、サブユニットを統合した上での結合テストなどを通じて、サブユニット間のつながりを理解することができます。

ここまで考えてくると、お気づきの方もいらっしゃるかもしれませんが、責任者不明確というUDEのときと同じで、マトリクス組織のジレンマが関係しているかもしれません。

私が見てきた多くの企業で、専門組織中心の開発体制が敷かれています。
普段、コミュニケーションをするのは、同じ技術分野を担当するXXの専門家と言われる人たちで、製品開発を進める他の技術領域の人たちと、まったく接点がないわけではありませんが、もっぱら考えるのは自分の専門領域で、他の領域の人たちの現在の仕事、悩みなどをリアルタイムで共有することはありません。

他の領域で問題が起これば、その内容を知ることはあっても、それを担当者がどんな風に悩み、周囲に相談し、どうやっ解決するかを直接見ることはありません。

マトリクス組織は、縦横組織とも言われます。どちらも大事なのですが、両方の良い所、悪い所をしっかりと押さえておかなければ、結局、片方の特徴に引きずられてしまいます。

専門家を作ることは、会社の技術を育てることになりますが、専門領域がどんどん小さくなっていくと、その技術者は他の分野で使い物にならない技術者になってしまうと私は危惧しています。
また、専門家意識が強くなると、製品全体への愛着や執着が薄くなっていくようにも感じています。

個々の省領域の技術、つまり要素技術を伸ばすか、要素技術を結集して製品全体を組み上げる力を伸ばすかの対立になっているのではないでしょうか?

責任者不明確のクラウドと同じクラウドではつまらないので、今回はちょっと目線を変えて、下記のようなクラウドを考えてみました。

 

さて、これで3つのUDEに対する3つのクラウドが出来上がりました。
それぞれのジレンマは、

  • 開発組織の効率化と個々の機種の品質
  • 開発速度重視と品質重視
  • 技術力強化と総合力重視

これらの3つのクラウドを眺めてみて、共通のジレンマを考えてみます。

いずれも企業としては、良かれと信じて採った考え方が、何か別の大事なことを置き去りにしてしまって、その結果、様々な問題が起こっている構図と考えることができそうです。

この3つのクラウドを見つつ、現実の開発組織の事情などを考えてみると、様々な企業が、既存事業、既存製品のラインナップを拡充して、競合よりも早く、何か小さくてもいいから技術進歩を示せる製品群を出し続けることを優先してきた結果、一つ一つの製品をお客様の満足度や品質を第一に考えて、優れた製品を安定して開発する組織能力を育成していく考えを置き去りにしてしまったのではないかと考えられるのではないでしょうか?

私なりに3つのクラウドを統合したクラウドを以下のように作ってみました。

いかがでしょうか?皆さんの組織では当てはまりますか?

これまでの説明も含めて、かなりの部分で私の思い込みも入っているかもしれません。
皆さんから、この考え方、このクラウドに対するご意見をいただければ大変うれしいです。

さて、3つのUDEをランダムに選んで、3つのクラウドを作り、そこから3つのクラウドを表現して代表する1つのクラウドを作ってみました。
TOCでは、これをコア・クラウドと呼びます。

コア・クラウドは、もしかすると、これがすべての問題の根本の原因、根本のジレンマであるかもしれないという仮説として捉えます。そうです。この段階では、あくまでも仮説です。

ただし、少なくとも15個のうち、3つのUDEを表現するクラウドにはなっています。

次回は、このコア・クラウドが、3つのUDE以外、15個すべてのUDEと因果関係があるのかどうかを検証していきます。
もし、コア・クラウドが15個全部のUDEと因果関係で結ばれれば、このコア・クラウドを解決すれば、開発組織の大きな問題はすべて解決できることになります。

次回もお楽しみに。

第四回「根本原因を因果関係で検証してみる」へ進む

第二回「対立解消図(クラウド)の作り方」へ戻る