今回は、問題解決、特にトヨタで実際につかわれている問題解決手法について語ります。
僕はトヨタ系のＩＴ企業で２０年以上勤めていました。
問題解決の手法は、日々の業務の中に浸透していて、業務そのものが改善、問題解決の連続でした。
トヨタが世界一になったのも日々改善という考え方が根付いていたからだと思います。
トヨタ式の問題解決手法（８ステップ）
トヨタ式問題解決８ステップとは
トヨタで使われている問題解決の手順を８ステップと言っていました。
その手順とは、次のようになります。
８ステップの流れ
| 問題発見 | 解決すべき問題を発見しテーマを選定 |
| 現状把握 | 現状の問題を複数視点で分析し重大な問題を特定 |
| 目標設定 | 具体的な数字で達成目標を設定 |
| 真因分析 | 問題の真因を追及 |
| 対策立案 | 真因を解決するための対策を立案し実施対象を決定 |
| 対策実施 | 対策を個人、チーム、周囲を巻き込む等して実施 |
| 結果評価 | 目標達成度合いの評価 |
| 定着展開 | 残課題への対応、内容の標準化および他への展開 |
理解するまでの壁
僕はとあるＩＴベンダーからトヨタに転職したのですが、転職してから３年くらいは、上司が語っていることがさっぱり理解できませんでした。
「Ａチームのシステム開発が１週間遅れていて、問題です」
「それは本当の問題じゃなくて単に現状にすぎないから」
何言ってるんだこの人？？？ って感じでした。
そのときの僕はそのシステム開発プロジェクトのプロジェクトマネージャ兼、リーダーだったから、
【Ａチームのどこが本当に遅れているのか】
【その遅れがプロジェクトにどう影響するか】
というところまで分析・判断して報告して欲しいということだったのですが、当時はまるで理解できませんでした。実際に理解できるようになるまでには、かなりかかりました。
上司はトヨタ自動車から来ていたひとでしたが、一言。
「トヨタの哲学だからね！」
哲学だからか、僕にはなかなか理解できなかったです。
問題解決の例
前のケースでひとつ例をあげてみます。
例えばシステム開発しているチームのメンバーが５人いたとします。
＜現状把握＞
チームメンバーのＸさんの担当部分だけが１週間遅れで、その他の人の部分は順調
Ｘさんの担当のＹモジュール開発が完了している予定だったのに、他のシステムとつなぐためのインターフェース部分の開発が１週間遅れている。ただし、実装してテストするだけであれば、未完成部分を完成させるには１日程あれば可能。
【問題】Ｙモジュールのインターフェース部の開発遅延：▲１週間-実必要工数は１日
（現状を細かく把握しどかに問題があるか、問題の絞り込み、特定）
解決がもう１週間長引けば、５人でつくったモジュールをあわせるから問題になるけど、１週間以内に解決するなら問題なし。
（影響を把握、判断）
＜目標設定＞
上記分析にもとずいて目標を設定
【目標】
一週間以内にＸさんの担当部分を完成させる。
＜真因分析＞
よくいわれる、「なぜなぜ５回」です。
なぜ、Ｙモジュールのインターフェースの開発が１週間遅れているのか？
→インターフェース部分の開発ができない
なぜ、インターフェース部分の開発ができないのか？
→他のシステムとのインターフェースがわからない
なぜ、他のシステムとのインターフェースがわからないのか？
→インターフェースの仕様書がない
なぜ、インターフェースの仕様書がないのか？
→前工程の設計のときに他のシステムとのインターフェース仕様を決めなかった
（この部分で今回の対策はうてます）
なぜ、他のシステムとのインターフェース仕様を決めなかったのか？
→誰も他のシステムとのインターフェースがあることを把握していなかった
→前工程で調査する工数がなかった・・・
などなど、今後この問題を再発させないためにも、なぜは繰り返すといろいろなことが見えてきます。
ちょっと強引ですが、「なぜなぜ５回」やってみました。実際の場合、この程度のことなら５回もやらなくてもわかりますね（笑）
【真因】
他のシステムとのインターフェース仕様が決まっていない
＜対策立案＞
真因を解決するための対策を立案します。
【対策立案】
他システムとのインターフェースを決めてインターフェース仕様書を作成する。
必要工数：ここで現状把握で把握した開発に１日という部分も活きてきます。
インターフェース作成：調整２日、仕様書１日
開発・テスト：１日
担当者もＸさんに決めます。Ｘさんの次の作業をＺさんにアサインして問題なし。
ということで、どうやら間に合いそうです。
注意すべきは、真因分析次第で、対策が全くかわってくることです。
Ｘさんが体調をこわして休んでいる、というケースもあるかもしれない。
→対策は、他の担当をアサインして開発するになると思います。
インターフェース部分のプログラムが技術的に難易度が高くＸさんのスキルでは実装できないのかもしれない。
→対策は、他のスキルのある担当で対応するとか、スキルのある担当がＸさんをサポートするなど。
これらもみな、問題を特定して、現状把握をしっかりとして、なぜなぜ分析をした結果としてあぶりだされるものとなります。
＜対策実施＞
ここまでくれば、あとは時間との闘いですね。
【対策実施】
他システム担当者とインターフェースを決めて、開発する。
対策立案で、問題なくできそうだという見込みもたっており、なんとか完成。
＜結果評価＞
評価は、目標に対して達成したかどうかで〇か×かになります。
今回は、対策が間に合ったということで、
【評価】〇
ですかね。
＜定着展開＞
いままでの流れで一通り開発の遅れはとりもどせて、ちゃんちゃんとなるかというと、そこまで終わらせないのがトヨタ式です。
プロジェクト内の話だとすると、同じような他システムとのインターフェースがある部分に漏れがないかを調べてその対策をとるとか、漏れが発生した原因をさらに細かく分析して、二度とおきないように、再発防止策をとるとかします。
この活動をカイゼンと言いますね。なんかカタカナで書くようです。
そういえば、カイゼンって英語で、”improvement”かとおもっていたら、違うらしいです。
"kaizen" と書くんだとか。
近いニュアンスは、”continuous improvement"。ようするに、継続的な改善！
いつの時代でも、カイゼンし続けるものが最後には勝利するのだと思います。
トヨタのやりかた（個人から組織、会社へ、カイゼン哲学）
組織への定着（個人、組織、会社）
問題解決というと、大きな課題があるときにその問題を解決するために特別な対策をうたなければいけないときに、例えばコンサルタントをいれて行うものだ、という捉えられ方をするかもしれません。トヨタでは違いました。トヨタの問題解決はイコール日常業務、問題解決の連続なのです。
自分の仕事で非効率なところがあれば、日々それを改善する。組織的な改善を行うためには、チームをつくって改善を行う。それが他組織をまきこんで行った方がいいときには、改善のためのチームをつくって改善を行う。
会社単位でも同じです。組織の代表として担当が決められ、集められて改善策を検討する。その結果をそれぞれの組織に持ち帰って、集まって検討した結果を組織に展開する。
そのような改善チームがいくつもあって、活発に活動していました。
このような継続的な活動が組織を強くしていくし、会社の成長にもつながっていたんだとつくづく実感しています。
問題がおきて困った時
これまでの自分の経験をもとに、各種問題に対するコンサル、ご支援、問題解決を会社に定着させるお手伝いなどを実施しております。
もしお困りの時、興味がわいた時には一度ご相談ください。下記にリンクも貼っておきます。
