エンジニアの問題解決能力を高める仮説検証による思考法

 

エンジニアの品質問題に対する解決能力が低下しているように感じる!!

開発段階で品質問題が起きることはある程度やむを得ないが、問題が発覚してから解決する前の時間がこの何年かで遅くなっている気がする。問題解決力が低いことは、問題を発生させることにも通じているように感じる。エンジニア一人一人の問題解決能力を高める方法を知りたい。

 

品質問題は、発生させないことが重要であって、弊社が推奨するリーン製品開発手法は、品質問題を上流で食い止めることが出来る開発手法なのですが、それでも起きてしまった品質問題は、出来るだけ速やかに解決したいところです。品質問題がなぜ起きるのか、品質問題の原因を追究し、解決するための思考法について解説する。

 

 

 

なぜ品質問題が起きるのか?

 

製品開発において品質問題が発生する理由は様々です。

  • 人為的なミス(ヒューマン・エラー)
  • 未熟な知識、理解力不足によるミス

などが考えられますが、実は私の経験では、開発現場で最も頻発する品質問題は、

  • ユニット間の連携、コミュニケーション・エラー、及びアーキテクチャーによる機能配分の理解不足

だと思っています。

開発者の中で中堅以上のエンジニアは、得意とする専門分野を持っています。

あるいは、機能別組織に所属していて、担当ユニットに関する知識は十分に備えています。

また、機能別組織は、担当するユニット開発に責任を持っているため、個人としてだけでなく、組織として品質問題を防ぐ役割も果たしていることが多いと思います。

しかし、機能別組織への依存度が強くなった組織では、製品全体を理解するエンジニアが減少しているという問題を持っている場合があります。

いわゆるアーキテクトと言われる、製品全体のアーキテクチャーを考えられる人、あるいは少なくとも全体の原理を良く理解している人です。

専門分野を強化すると、反比例するようにアーキテクトが減少するのですが、多くの製造業で開発効率を高めるために、機能別組織を強化していったことで、いわゆるジェネラリストタイプのエンジニアが減ってしまったのかもしれません。

このように、ユニット内の開発に関する品質問題は減少する反面、ユニットを跨ぐ品質問題が多発するようになったと考えられます。

 

 

製品開発の分業は、既存製品のマイナーチェンジを行うには非常に都合がいいやり方です。

領域ごとの専門家が、繰り返し自分の担当するユニットを開発します。

それぞれの担当領域を開発して、積み上がったものが製品全体となるわけです。

各担当は、自分の担当領域に関することは全責任を持てますが、ユニット間の繋がりについては知識も責任感も希薄になりがちです。

ベテランのエンジニアは、それでも経験とノウハウによって、問題発生を食い止めますが、いつの間にか製品全体に関する知識や経験が組織から失われていき、品質問題がなくならない状態になっていくと考えられます。

 

品質問題を解決するための思考プロセス

 

起こってしまった品質問題を解くカギは、正しく仮説を立てられるかどうかです。

医師が診察で、難しい病気の正しい病名を見つける状況を考えてみましょう。

熱や血圧、胸の音、扁桃腺の状況など、一通りの診察の後は、問診でどこに痛みがあるか、それはいつか、頻度などを聞いていきます。

どんな痛みなのか?それ以外に症状はないか?など根掘り葉掘り聞かれることもあります。

この時、お医者さんの頭の中では、いくつかの仮説があって、問診への患者さんの答えによって仮説を絞っていくのだと推察されます。

医者の優劣を付けられる立場ではありませんが、おそらく優秀ではないお医者さんは、少しの診察で

「ああ、これは風邪だよ」

などと決め打ちしたりします。

まあ、もちろんそれが当たっていることもあるのでしょうが、もしかすると重大な疾患を見逃してしまうかもしれません。

では優秀な医師とはどういうことかと考えてみると、たくさんの仮説を持っている人ではないかを思うわけです。

たくさんの仮説は、知識と経験から生まれるものと考えられます。

もちろん、正しい診察をしようという情熱のようなものもあるのかもしれません。

いずれにしても、知識と経験による仮説を一つ一つ状況と照らし合わせて、真実に近づけていく思考プロセスだと思うわけです。

製品開発における品質問題の解決も同じことだと思います。

症状や状況から、仮説を立てて、しかも出来るだけたくさんの仮説を立てて、得られる情報から仮説を絞っていき、真の原因にたどり着くというプロセスが必要です。

 

 

仮説を立てるには、製品の原理を深く理解し、各ユニットの働きだけではなく、ユニット間の連携なども理解している必要があります。

もっと大事なことは、品質問題の事例を知っていることが大事なのです。

医師が、症例をたくさん知っていることと同じです。

どんな不具合があると、どんな症状が出るのか、ということを知識として持っているから、症状から仮説が立てられるわけです。

 

仮説検証力を上げるために製品アーキテクチャーを簡単に理解する方法

 

仮説・検証で品質問題を解決するためには、まずは、製品全体に関する理解を深めることです。

製品アーキテクチャーを全て把握するには、それなりの時間や経験も必要です。

なので、まずは製品全体に関して興味を持つこと、そして全体の構成と繋がりをボンヤリとでも良いので頭に入れておくことです。

私がエンジニアの方に勧めているのは、機能構造展開図を使って、製品を機能と部品構造に分解してみることです。

機能構造展開図は、VA(Value Analysis)などで使われるツールですが、製品の全体構成と機能を把握するにはとても良いツールです。

 

 

上図は、LED電球を機能構造展開図に分解したものです。

図の左側が機能、右側が部品構造になります。

機能は、階層的に分解します。

電球の最も上位の機能は、「狙ったところを明るくする」という機能です。

そして、そのために「電気エネルギーを供給し」、「光を発生させ」、「光を外部に広げ」、「電球を固定します」。

さらに、「光を発生させる」を分解すると...という具合に機能を分解していきます。

右側の部品構造は、逆に一番右から左に行くにしたがって全体から細かな部品に階層的に分解していきます。

機能を分解した最も最下層の機能とそれを達成するための部品が繋がります。

一つ一つの部品が一つの機能を達成している場合もあるし、複数の部品で一つの機能をカバーしている場合もあります。

また、一つの部品が複数の機能に関係している場合もあります。

製品全体で、機能がどのように分担されているかがわかる図になっているわけです。

慣れないと作ること自体が難しい場合もありますが、周りの人たちと協力して議論しながら作ることで、チーム全体で製品全体への理解を深めることが出来ます。

そして、全体への理解を深めることで、仮説を立てやすくなり、問題解決力を向上させることができます。

 

仮説検証力が上達する考える習慣

 

仮説・検証によって品質問題を解決するためには、製品全体への理解力を上げることが最も効果がありますが、自分たちで考える習慣を持つことも大切です。

前項の機能構造展開図も、製品全体を知らないメンバーにとってはハードルが高いかもしれませんが、まず、自分たちの力で考えてみることで、知識レベルが一段上がるはずです。

与えられるものを待つのではなく、自ら進んで学ぶことが大事というわけです。

そして、効果的に知識をつけるために、有効なキーワードがあります。

  • それは何故ですか?
  • そうするとどうなるのですか?

「それは何故ですか」は、いわゆる”なぜなぜ五回”と言うやつで、わかったつもりにならずに、学びかけたものを確実に自分のモノにするために必須の言葉です。

なんとなくわかったような気になって、質問しないままでいると、結局は自分の知識になりません。

わかるまで聞く、ということを組織全体でやるようになると、組織のコミュニケーション能力、学習能力は格段に高まります。

「そうするとどうなるのですか?」は、因果関係を追っかけるために、とても有用な言葉です。

製品の原理は、すべての部品、すべての機能が連鎖して繋がっています。

つまり、言い換えると何かの変化が別の変化と因果関係で繋がって、大きな機能を果たしていると言えるわけです。

製品の原理、アーキテクチャーは因果関係ロジックで語ることが出来ます。

エンジニアの方に勧めているのは、普段から因果関係でものごとを考える癖をつけることです。

「それはなぜですか?」と「そうするとどうなるのですか?」を口癖にすることで、論理思考力が高まり、知識吸収力が大幅に上がります。

 

論理思考力を強化するセミナー

なぜなぜ思考、因果関係ロジックを身に付けるための「論理思考力強化セミナー」を開催しています。

TOC(制約の理論)の思考プロセスを使い、TOCのフレームワークで用いるUDEと対立解消図(クラウド)の使い方を学ぶことで、思い込みを排除し、問題の構造を客観的に捉えるトレーニングをすることで、論理思考力を向上させます。

論理思考力向上セミナー
  1. 事実、仮説、意見の識別
  2. 制約の理論(TOC)概要
  3. 組織の問題点を見つける
  4. 対立構造図(クラウド)の作り方

 

 

参考記事:「製品開発における品質問題の問題解決能力を高める方法

 

 

Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA