連載記事の内容
第三回 問題の根本（コア・クラウド）を見つける
３つのUDEに対するクラウドを完成させる
第二回では、「責任者が不明確になっている」というUDEに対するクラウドを作ってみたところまででした。
今回は、別の２つのUDEをクラウドで表現してみます。
第一回で挙げた15個のUDEのうち、重要そうで、「責任者が不明確になっている」とは質の異なるものを選びます。今回は下記の２つのUDEを取り上げることにします。
- 日程遅れが常態化している
- 製品全体を理解できる技術者が減少している
第二回で説明した手順に従って、２つのUDEをクラウドで表現していきます。
まず、「日程遅れが常態化している」という問題の本質を考えてみます。
この問題については、様々な要因が考えられるし、企業ごとに多少事情が異なるかもしれませんが、共通なことも少なからずあるので、少し深く考えてみます。
まず、なぜ日程が遅れるのか、いくつかの仮説を考えてみると、
- もともと無理な日程で進めようとしている。
- 予期しない問題がいつも発生し、その対応に時間を取られる
- 最初の試作での品質が悪く、品質問題解決に時間がかかる
ここにどんなジレンマがあるのか、私の経験で言うと、製品企画の段階で、確立されていない技術と確立されている技術が混在したまま、技術の完成度が不明確なまま製品開発を進めようとすることが、根本の原因のように思っています。
まずは試作機を作ってみなければ何もわからないじゃないか！という考えが、上層部にも現場にも行きわたり、大きな技術リスクを背負ったまま、製品開発をスタートすることが当たり前だという考え方が、会社そのものの考え方になっているような気がします。
試作機を作る前に、大きな技術課題を解決する、いわば”急がば回れ”という考えに思いも及ばないことに気づいていないのではないでしょうか。
直観的に、すぐにモノを作ることが一番早いやり方だと信じている人は多いと思います。それ以外のやり方があるのかと反論されそうですが、トヨタの開発手法は、セットベース開発とも呼ばれ、技術課題を小さな実験を繰り返して、知識として積み上げ、すべての技術課題を解決してから詳細設計に入るというやり方をしています。
これも一見、当たり前のように聞こえるかもしれませんが、多くの製造業の開発組織では、これが出来ていません。一般的に、いくつもの技術リスクを残したまま、一点突破で詳細設計をスタートするやり方をポイントベース設計と読んでいます。
このような背景を考えて、私は、下記のようなクラウドを考えてみました。
このクラウドの検証をしてみると、音読して特に違和感を感じないのですが、個人的にまだしっくり来ないところがあります。
技術課題を全部解決しなければ始めない、というのはあまりに極端と思われるからです。
開発を始めてから技術課題が出ること自体は悪いことではないし、むしろ開発中に技術課題が出てくるのは当然のことで、そもそも技術課題を解決する能力にも問題があるのではないか、という思いです。
日程遅れを常態化させている組織の行動は何か？
例えば、開発チームのメンバーの多くが、製品に対する知識を十分に持たないまま製品開発を任されているという仮説はどうでしょうか？
企業の成長とともに、社員数は増え続け、会社の売上を上げていくために開発機種数も増え続けているとします。
製品開発を経験しているベテラン、中堅の人数と、新しく入ってきた若手の人数とのバランスが、少しずつ変化しているとしたら、チームとしての製品に対する知識レベルは平均して低下しているのではないでしょうか？
さらに、たくさんの機種を短期間に効率的に開発するために、分業化を進め、開発プロセスを標準化して、エンジニアの能力に任せるというよりは、機械的に機種開発を進めているとしたら、やがて組織としての開発能力は低下していき、問題解決能力も低下するのではないでしょうか？
これが、製品開発における日程遅れ常態化の原因だとしたら、そこにはどんなジレンマが生まれているのでしょうか？
ということで、もう一つクラウドを考えてみました。
いかがですか？
「日程遅れが常態化している」というUDEに対するクラウドとしては、個人的には2つ目のクラウドの方がしっくり来ると思います。
このようにクラウド作成は、音読してのロジックの精査とは別に、本当に問題の本質を捉えているかどうか、自分なりに検証することが大切です。
次に、3つ目のUDE「製品全体を理解できる技術者が減少している」という問題の本質を考えてみると、日々の開発の仕事をする中で、製品全体の知識を得るチャンスが減っているということが起こっていると仮説をたてます。
製品全体の知識を得るためには、自分の担当以外の人たちが何をやっているのかを知る必要があります。日々の開発活動を見ているだけでも、どんなことで悩んでいて、どんな課題を抱えて活動しているかを見ていれば、他の人たちのやっている「技術」というのが理解できてくるように思います。
また、製品全体の開発をインテグレーションする過程を見る必要もあるかもしれません。
個々のサブユニットを組み合わせて、つなげていく作業や、サブユニットを統合した上での結合テストなどを通じて、サブユニット間のつながりを理解することができます。
ここまで考えてくると、お気づきの方もいらっしゃるかもしれませんが、責任者不明確というUDEのときと同じで、マトリクス組織のジレンマが関係しているかもしれません。
私が見てきた多くの企業で、専門組織中心の開発体制が敷かれています。
普段、コミュニケーションをするのは、同じ技術分野を担当するXXの専門家と言われる人たちで、製品開発を進める他の技術領域の人たちと、まったく接点がないわけではありませんが、もっぱら考えるのは自分の専門領域で、他の領域の人たちの現在の仕事、悩みなどをリアルタイムで共有することはありません。
他の領域で問題が起これば、その内容を知ることはあっても、それを担当者がどんな風に悩み、周囲に相談し、どうやっ解決するかを直接見ることはありません。
マトリクス組織は、縦横組織とも言われます。どちらも大事なのですが、両方の良い所、悪い所をしっかりと押さえておかなければ、結局、片方の特徴に引きずられてしまいます。
専門家を作ることは、会社の技術を育てることになりますが、専門領域がどんどん小さくなっていくと、その技術者は他の分野で使い物にならない技術者になってしまうと私は危惧しています。
また、専門家意識が強くなると、製品全体への愛着や執着が薄くなっていくようにも感じています。
個々の省領域の技術、つまり要素技術を伸ばすか、要素技術を結集して製品全体を組み上げる力を伸ばすかの対立になっているのではないでしょうか？
責任者不明確のクラウドと同じクラウドではつまらないので、今回はちょっと目線を変えて、下記のようなクラウドを考えてみました。
さて、これで３つのUDEに対する３つのクラウドが出来上がりました。
３クラウド法によるコア・クラウド（根本原因）の発見
15個のUDEから３つを選んでそれぞれのクラウドを作成しました。
UDE１：責任者が不明確になっている
UDE２：日程遅れが常態化している
UDE３：製品全体を理解できる技術者が減少している
TOC（制約の理論）の問題解決フレームワークでは、３クラウド法といって３つのクラウドから共通性を見出してコア・クラウドを発見する方法が示されています。
具体的には、３つのクラウドから、３つのA（A1、A2、A3）、３つのB（B1、B2、B3）、３つのC（C1、C2、C3）、３つのD（D1、D2、D3）、そして３つのD’（D’1、D’2、D’3）を抽出し、文章の共通性を抜き出します。
個人的には、機械的に国語力のような形で文章の共通性を見つけていくやりかたよりも、３つのクラウドをしっかりと読み解いて、共通性のある新たなクラウドを作成する、という方法を取りたいと思います。
上の３つのクラウドを眺めてみて、共通のジレンマを考えてみます。
いずれも企業としては、良かれと信じて採った考え方が、何か別の大事なことを置き去りにしてしまって、その結果、様々な問題が起こっている構図と考えることができそうです。
この３つのクラウドを見つつ、現実の開発組織の事情などを考えてみると、様々な企業が、既存事業、既存製品のラインナップを拡充して、競合よりも早く、何か小さくてもいいから技術進歩を示せる製品群を出し続けることを優先してきた結果、一つ一つの製品をお客様の満足度や品質を第一に考えて、優れた製品を安定して開発する組織能力を育成していく考えを置き去りにしてしまったのではないかと考えられるのではないでしょうか？
私なりに３つのクラウドを統合したクラウドを以下のように作ってみました。
いかがでしょうか？皆さんの組織では当てはまりますか？
本質的には、技術者の育成よりも、機種開発の効率化を優先にして会社運営をしてきてしまったツケが回ってきているように感じています。
もちろん、すべての会社に当てはまるわけではありませんが、冒頭で紹介したように私が支援してきた多くの企業では、少なくとも共通性があると思っています。
社員の増加と開発機種数の増加に対して、十分な準備が追い付かなかったという事情も見えるのですが、技術者のレベルに関係なく、そこそこの製品を失敗なく作る続けるということを重視してきたことで、技術者の潜在能力を信じて任せることで、顧客にも社内にも驚きをもたらすような製品開発の可能性を潰してしまっているように見えます。
大切なのは、この状態からどう脱却するかということですが、クラウド作成では、この先どうすべきかという考えは封印して、まずは、現状、何が起こっているかを客観的、冷静に、そして正しく見極めます。
皆さんから、この考え方、このクラウドに対するご意見をいただければ大変うれしいです。
さて、３つのUDEをランダムに選んで、３つのクラウドを作り、そこから３つのクラウドに共通する内容を表現して代表する１つのクラウドを作ってみました。
TOCでは、これをコア・クラウドと呼びます。
３つのクラウドから共通する内容を抽象化して表現することが、少し難しい作業になるかもしれません。
文章を単純に共通する内容にまとめていきながら、本質的な問題を読み解いていくことでコアクラウドを完成させていくということになります。
コア・クラウドは、もしかすると、これがすべての問題の根本の原因、根本のジレンマであるかもしれないという仮説として捉えます。そうです。この段階では、あくまでも仮説です。
ただし、少なくとも15個のうち、３つのUDEを表現するクラウドにはなっています。
次回は、このコア・クラウドが、３つのUDE以外、15個すべてのUDEと因果関係があるのかどうかを検証していきます。
もし、コア・クラウドが15個全部のUDEと因果関係で結ばれれば、このコア・クラウドを解決すれば、開発組織の大きな問題はすべて解決できることになります。
コラム：
３つのクラウドからコアクラウドを見つけて、コアクラウドを根本問題と捉えていくのを３クラウド法と呼んでいますが、本質的には起きている現象の因果関係の元を辿っていくことで根本問題を見つけることもできます。
コアクラウドを使わないで、根本問題を見つけて、組織改革をしていくストーリーを本にしました。
筆者の実体験をベースにしているので、かなりリアルな物語になりました。
詳しくは、「製品開発組織の常識をぶち壊せ！！」出版のご案内を参照ください。
次回もお楽しみに。
TOCを使った組織問題の解決手法
今すぐ確認する
この記事を気に入ってくれたら、下の”いいね”ボタンをお願いします！！
