問題は明らかだ！手は打っているのに何年経っても状況は変っていない！？
日程遅れ、繰り返される品質問題、若手のモチベ―ションダウンなど問題はわかっている。ずっと対応策を組織全体で展開しており、その成果は出ていると報告されているのに、なぜか何年経っても状況が変わっているようには思えない。何が間違っているのか、どこで間違ったのかを知りたい。
組織を挙げての問題対策が、以下のようなことが起こって、対策の実施そのものだけが成果として挙がっていて、結果、状況が変わっていないことが起こっています。
- 問題の本質を見ていない
- 目標を正しく捉えていない
- 出された対応策の正しさを検証していない
- 組織が変化する時間を読めていない
現状を正しく分析し、正しい目標設定と成果測定、対策案の評価、時間間隔を伴った計画を立てることで、本当の成果を勝ち取ることが出来ることについて、組織改革全般、リーン製品開発の展開などにおける実例を挙げながら詳しく解説します。
本記事の内容
組織改革活動で陥りやすい失敗パターン
製品開発組織の改革、いやどんな改革活動でも戦略的なアプローチが成功の秘訣と言えます。
逆に戦略のない活動は、様々な問題を引き起こすことになるのです。
戦略的でない活動とは
- 現状分析の精度が低い
- ゴール設定が曖昧
- ゴール達成までの道のりが設計されていない
3つの中でも最も懸念があるのがゴール設定で、例えば「開発効率向上」などの目標は、
- 開発効率が具体的に何を指すのか
- 現状や達成すべきゴールをどう評価・測定するのか（数値で評価できないものは、達成度や成果があやふやになる）
が、曖昧なケースが非常に多いように思います。
目標を曖昧にする傾向は、そもそも数値として目標設定が困難である場合もあるのですが、誰もが理解しているだろう、という安易な思い込みで有耶無耶にしているケースもあります。また、実はハードルの高い目標の場合、無意識にあとで出来ない言い訳を用意するために、あえて不明確にしておくということが起きることもあるように思います。
目標を誰もが反論できないレベルで評価・測定できるようにすることは、改革活動で絶対に必要な要素なのです。
また、現状分析の精度が低いことは、そもそも問題の本質を理解できていないことに通じます。
問題の本質がわからなければ、ゴール達成がどれほど困難なのかが実際には理解できていないことになります。さらに言うと、現状が正確に把握できない別の理由は、自社以外の状況を知らないからということがあるのです。
つまり、自社のやり方に対する強い思い入れ（これが当たり前）が、現状認識をゆがめてしまうということです。
だから、現状分析にはベンチマークが大いに役立つのです。
3つ目のゴール達成までの道のりに関しては、ある程度やるべき施策が見えてくると、その施策を実現することが目標になってしまって、本来のゴールをないがしろにしてしまうことが、多くの企業で起こっていることを指します。
施策そのものに盲目になると本来の目標が見えなくなり（施策実行を目標化）、さらに成果を測定できない（本当のゴールに対する達成度が不明）ことで、PDCAが全く機能しなくなるのです。
また、施策そのものの正しさを評価しないケースも多いと思っています。
思いついた施策に盲目になってしまうということです。
例えば、品質問題が多発している場合、その対策としてデザインレビューを強化するということが浮かび、施策展開することがあります。
デザインレビューが品質問題に効果がないわけがない、と考えてしまい、デザインレビューの実践レベルを一生懸命に評価しようとして、元々の品質問題が多発しているという問題がどの程度改善しているかを見ずに、デザインレビューの質が悪いからダメなんだ、というような本末転倒の事態が起こるのです。
また、施策実行の障害や副作用を考えないで改革を進めると、目標達成までの時間感覚が失われ、責任の所在も不明確で、いつの間にか活動が停滞したり、目標が縮小されたり、場合によっては活動そのものがなかったことになったりします。
いかがでしょうか？
これまで開発現場を多数見てきて、上記のようなことは本当にたくさん起きています。
そしてこれは、改革活動全般で一般的に良くある失敗パターンについて述べてみたのですが、次にもう少し具体的にリーン製品開発という手法導入における実際の例からも失敗パターンを見ていきます。
リーン製品開発導入での失敗事例
リーン製品開発手法については、別記事「トヨタ式リーン製品開発とは」を参照ください。
リーン製品開発で重要な要素は以下の３つです。
- チーフエンジニア制
- セットベース開発
- A3報告書
それぞれの要素に大事なポイントがいくつもあるのですが、もっとも有りがちで気をつけたい失敗は、これらの要素の形を真似して取り入れようとすることです。
リーン製品開発手法は、すべての要素を取り入れないと効果がないわけではありません。
それぞれの本質的な意義を取り違えずに、自分たちの組織で応用できること、手法の本質を取り入れることで達成したい目的を達成できるはずです。
ところが、手法を学び、体制をトヨタと同じように変えれば、すべてがトヨタ並みに良くなるという誤った考えを持ってしまうケースが散見されます。
トヨタ以外のどんな会社も絶対にトヨタにはなれません。
あくまでトヨタの良さを学んで、自社独自のやり方を発見し、実践することでのみ、達成したい目標に到達できるのです。
しかも、ゴール設定もあやふやにして、トヨタ並みに強い組織に変わるという妄想を抱いてはいけません。
自分たちの現状はどこで、ゴール、つまりどこに行きたくて、どうやっていくかという戦略を立てることが大事なのです。
形を模倣しようとすることが、まず最初の失敗パターンですが、以下、それぞれの要素での失敗パターンも見ていきます。
チーフエンジニア制の失敗
強いカリスマリーダーとして知られるトヨタのチーフエンジニア制（主査制度とも呼ばれる）ですが、トヨタ以外の様々な会社がこの制度を真似して取り入れようとしますが、まったく出来ません。
アメリカのフォードですら、真似しようとして出来ずに、フォードのトップが業を煮やしたという逸話もあるくらいです。
私が所属していた企業も、約30年前にこの制度を真似して取り入れました。
プロジェクトマネージャー制（PM制）ということで、30年経った今でも形は残っているようですが、内容は似ても似つかないものです。
確かにPMBOKなどを学んで、プロジェクトリーダーとしての経験を積んで、形としては開発チームとは少し離れたところで、プロジェクトの日程管理、関連区との調整などをやっているのですが、トヨタのチーフエンジニアとの最も大きな違いは、お客様の欲しい車を企画し、技術的なチャレンジ設定して開発チームを技術的に引っ張り、パートナー企業との連携でプロジェクトを強力に進め、販促活動を先導し、という一車種をビジネスとして成功させるためのすべてのことで先頭に立つトヨタのチーフエンジニアに対して、多くの企業のPMさんは、日程管理と関連区との調整役のみをやっているということかと思います。
それでも、ある意味、全体の開発システムとして機能してはいるので、やっている本人たちにあまり大きな問題意識はないのだと思います。
しかし、経営トップからの売上要求、顧客満足度をアップしてブランド価値を高める責任、品質、コスト、販売タイミングなどで他社を凌駕する責任をもって、厳しいQCD目標を達成するリーダーシップにより、継続的に良い製品を出していくという体制にはつながりません。
一方、そうは言っても商品企画チーム、開発チーム、生産チーム、購買チーム、営業チームというそれぞれの責任者が仕事、責任を分担することで、良い製品を出し続けているのであれば、これを変える必要はないのだと思います。
でも、トヨタの真似をしたいという背景には、少なからず現状に対する不満があるはずです。
その現状の不満を解消するためにチーフエンジニア制を導入するのであれば、その達成したい姿になるように、トヨタの制度をうまく活用しなければ意味がありません。
このケースは失敗には見えないかもしれませんが、本来達成したいことが達成できていないとしたら、やはり失敗パターンだと思います。
セットベース開発の失敗
セットベース開発は、リーン製品開発手法の中でも肝になるものです。（参考記事：「セットベース開発を理解する」）
ごく簡単に説明すると、設計構想段階で複数の方式が浮かんだとすると、その複数の方式をすべて残したまま、未知の知識を小さな実験（MVEという）で獲得しながら、一歩一歩技術や知識を蓄積して関係者が合意しながら方式を絞っていくことで、チャレンジ度の高い製品を高品質に作り上げていく開発手法と言えます。
もっとも多い失敗パターンは、この手法を複数の方式を並行検討して進めることだと、単純な理解をして、複数方式を最初に一つに絞らずにやることで、期間短縮や品質向上が図れるという短絡的な考えを持ってしまうことです。
セットベースは、要素開発を地道にしっかりとやりながら、製品全体を開発する手法という理解もできます。
しかしながら、その本質的な狙いや求めるべき効果は、単に要素開発を一歩ずつ進めるということに留まりません。
セットベース開発をなぜやるのか、というところから考えてみましょう。
構想段階で、与えられた製品企画を達成するために、いくつかの方式案があったとします。
製品全体の開発方針を決める段階で、採用する方式を一つに絞って開発を進めるということなのですが、複数の方式で製品全体を考えると、その分多数のリソースが必要になります。
通常のやり方では、製品全体を作って評価・修正していくという考え方から、方式を一つに絞って製品構想を固めます。
そして決めた方式で、詳細設計を始めて製品全体の試作機を作り、評価・デバグをして修正すべきところを洗い出し、修正設計をして再度評価を行います。
全体を作ってしまってから発生した問題は、たくさんの要素が絡んでいることで、解決するのに時間がかかったり、モグラたたき状態になって問題がなかなか収束しない傾向があります。
つまり、開発者は品質問題と向き合って、問題の収束に多大な時間をかけ、しかも収束するまでの時間が不確実で、市場が求める日程に遅れることが頻発するということになります。
こういう状況であるならば、むしろいきなり試作機を作るのではなく、不明な技術やリスクのある所を一歩一歩確認しながら進めましょう、というのがセットベースであり、また、複数の方式をチャレンジ度の高いものと低いものを組み合わせることで、プロジェクトそのもののリスク回避を行いながら、難しい課題にもチャレンジできるというやり方をするために、セットベースは有効となるのです。
失敗というか、セットベースに関する間違った解釈をして、方式の並行検討がセットベースと思い込み、もともと要素技術としてやらなければならないことなのに、複数の方式を並行検討していることで、自分たちのやり方はセットベース開発である、というような間違いをするケースを時々見かけます。
繰り返しますが、形ではないということです。
何を達成したいのか、それに対してトヨタのやり方の何が役立つのか、という発想でセットベースの実践を考えて欲しいと思います。
A3報告書の失敗
A3報告書は、単に報告書のフォーマットをA3用紙にするということではありません。（参考記事：「A3報告書文化による製品開発革新」）
無制限に書きたいことを書く通常の報告書ではなく、一枚の紙面に伝えたいことをわかりやすく全て書き尽くすことで、短時間に正確に伝えるべきことを伝えることを目的にします。
企業内の知識を幅広く利活用することで開発の効率を上げるということが狙いということですが、過去の失敗を二度と繰り返さないということや、他の部門での経験をベースに次のイノベーションの起点にしたり、ベテランの知識を後進に効果的に伝えることで企業の財産を守る、というようなことが可能となります。
チーフエンジニア制やセットベース開発よりも、わかりやすく成果も出やすいのではないかとの想いから、まずA3報告書を取り入れてみようという企業も少なくありません。
ただし、ここでの失敗パターンは、活動開始から出来るだけ早い時期に、A3報告書を出来るだけたくさん貯めることを目標に、メンバーにとにかくA3報告書を書くように仕向けることです。
ノルマのような形にしてメンバーに負担をかけるだけでは、本質的な目的は達成できません。
知識やノウハウを企業内で広く共有し利活用して成果を挙げるためには、その目的や利活用するためのシステムをメンバーで共有してモチベーションを上げることがとても重要です。
さらに、折角書いた報告書が広く読まれて活用されるためには、報告書の質を向上する必要もあるし、またそもそも他者から求められる、つまり読んでもらえる題材の報告書を書く必要もあります。
ただ何でもいいから件数を増やそうというやり方では、達成したい目的には到達できないということです。
また、これも良くあるパターンですが、A3報告書活動は企業内のナレッジマネージメントとして導入されるケースがあります。
このときに、蓄積された報告書、文書を検索しやすい環境を作る、すなわち文書管理システムを作ることに走ってしまうのがもう一つの失敗パターンです。
報告書を通して、会社内の知識資産を流通させ、それで過去トラブルの再発防止、イノベーションの加速、ベテランのノウハウの活用ということを達成するためには、検索の仕組みをどうこうする前に、報告書の質を高めたり、書く題材そのものの精査が必要なのです。
いつの間にか、本来達成したいことではなく、文書管理システムの整備という手段が目的化されることで、この活動は失敗するわけです。
製品開発組織の改革で成果を確実に挙げるための提言
製品開発組織の改革における失敗パターンから、失敗する原因は以下の２つに集約されます。
- 改革のための正しいプロセスを知らない
- リーン製品開発のような手法や理論の形だけを真似ようとする
１の正しいプロセスは、いわゆる直感的な対策によって失敗するということなのですが、現状を把握して、ゴールを決めて、そのギャップを埋めるという基本的な３ステップをしっかりとやるだけでかなり改善されると思いますが、さらに思いついた施策を疑わない、というところは、組織内だけでは解決が難しいかもしれません。自社の当たり前に入り込んでいるからです。
客観的な改革プロセス・フレームワークや、見識のある第三者からのアドバイスが必要だと思います。
２の形だけを真似ようとする例は、手法そのものの理解不足が一つの原因です。
書籍を読んでわかったつもりになってしまい、自分たちで実行できるとやってみるものの、形は出来ているようだけど成果がまったく伴わないケースがたくさんあります。
弊社のセミナーに参加いただき、セミナー後のフィードバックで時々あるのは、
”わかりやすい説明をありがとうございました。自分たちがこれまで書籍を読んで学んできたこと、準備してきたことが間違ってなかったとわかりました。”
というコメントを残し、後は自分たちでやってみます、と言ったものの一年後には、
”形は出来たと思うのですが、開発期間は短くならないし、手戻りも減りません。どうしてでしょうか？”
となることがあります。
書籍などで説明されている手法・理論は、出来上がったものの中味を解説しているだけです。
- なぜ、手法を導入しなければならないか？
- どういうゴールを目指すのか？
- 今、どういう状況なのか？
- 現状からゴールまでどうやって達成させるのか？
ということは書籍には書いてません。
私のセミナーでは、そのプロセスの流れについて解説していますが、それがどれくらい難しいものなのか、どんな所で躓くのか、そして躓いたときにどうやって対処するのか、など、とても数時間のセミナーでは伝えることが出来ないのです。
要するに、にわか勉強をしてわかったような気になって出来ると思ったけど、結局出来ない、ということが起きているということなのです。
ですから、今回、紹介した失敗パターンが当てはまるようであれば、ぜひ、弊社までお問い合わせください。
相談については無料でやっています。（一時間程度のオンラインでの相談）
まずは、問い合わせフォームよりご連絡ください。
それでもどうしても独力で進めたいということであれば、このあと少しだけヒントをお伝えすることにします。
戦略的な組織改革を実行するプロセスはTOC（制約の理論）を取り入れる
- 戦略的な組織改革を実行するプロセスはTOC（制約の理論）を取り入れる
- 適切なゴール設定をする
- 戦略的な実行計画を立てる
改革を行うに当たって、ごく当たり前のプロセスですが、前述のように意外に出来ていないのが実情です。
この当たり前のプロセスを組織で学んで実行するためには、TOC（制約の理論）の思考プロセスを取り入れることを提案します。
ただし、TOCの問題解決フレームワークは、当たり前のことの積み重ねではありますが、フレームワークとしては結構大きなもので、すべてを体得するのにはそれなりの時間がかかります。
TOCを専門とするコンサルティング会社などで研修を受けると、期間は一週間程度、費用は一人当たり数十万円というところでしょうか。
もちろん得られる効果は大きいと思うので、それだけの投資の価値はあるかもしれません。
弊社では、TOCの思考プロセスとリーン製品開発手法の展開を組み合わせた「連鎖式組織改革法」を実践しています。
この「連鎖式組織改革法」のフレームワークを体得できるワークショップを開催していますので、改革の基本的なプロセスを理解するのであればぜひ活用してください。
連鎖式組織改革法の実践ワークショップ
世界の成功事例であるトヨタから学び
強力な問題解決フレームワーク（TOC）を応用して
50年勝ち続ける製品開発組織に変革する！！
全8回（4時間×8回）のワークショップです。
今なら期間限定の特別価格で提供中です。
- TOC（制約の理論）の全体像を理解する（4H）
- 根本問題の発見（4H）
- 現状ツリー（4H）
- トヨタのリーン製品開発概論（4H）
- 解決策を考える（4H）
- 未来ツリー（4H）
- 詳細計画に落とし込む（4H）
- 課題解決提案のまとめ（4H）
.
ナレッジ・マネージメント活動に関する提言
ナレッジ・マネージメントに関しては個人的な思い入れもあり、多くの企業でぜひ成功していただきたいと思っています。
繰り返しになりますが、多くの企業がナレッジ・マネージメント改革を例えば文書管理システム構築という活動に置き換えてしまう傾向があります。
まさに施策そのものを目標化してしまうことの例で、これは本当に多くの企業で起きています。
なので、戦略的活動という観点から、まずは活動全体の方針・戦略を確認すべきです。
例えば、組織としての達成目標が開発効率向上としたときに、ナレッジ・マネージメント活動はその中でどんな役割でゴール達成に貢献するかを明確にしましょう。
ナレッジ・マネージメント活動単独で数値目標を立てられれば、それが一番いいのですが、全体活動との繋がりが強くて単独測定が困難な場合は、全体活動と常に連携しながらPDCAを回す必要があると思います。
なので、全体の数値目標、測定法はこの活動のスタート時点でもマストなのです。
ナレッジ・マネージメントが、本質的には、社内の知恵、知識資産を潤滑に回転させることで、失敗を起こさない強い組織にすること、及び他社に負けないイノベーション（市場に新たな顧客価値）を生み出すシステムを作ることと認識していただきたいと思います。
現状分析に関する提言
現状の報告書のあり方、使われ方の課題の捉え方が、人によって異なっている気がしています。
組織全体の想い、つまり改革チームが設定した課題に対する組織全体の納得感を得られる活動となるように、TOCを使って現状分析をしっかりとやりたいと思います。
ゴール設定に関する提言
ここが最大のハードルだと認識しています。
全体の「開発効率向上」をどう定義するか、その測定方法をどうするか、これが出来た後で、ナレッジ・マネージメント活動としてのゴールをどうするかを詰めるべきです。
これには、新たなシステムでどんな世界を作るかという世界観を持ちたいです。
シンプルで多くの人から共感を得られる世界観を作ることで組織全体のゴール・イメージを明確化出来ます。
そして、そのためにはベストプラクティスを少し深掘りする必要もあります。
トヨタのA3報告書やセットベースを使って、どんなシステム、運用がされていて、それがどんな成果を生み出して、それに対して自社の現状はどうか？というTOC的なアプローチと、もっと別の考え方はないか、という夢を追うようなアプローチの両面で進めたいところです。
ここで一つ、メンロイノベーションズ社というアメリカの会社が実施して成功しているペアプログラミングを例にお話しをさせていただきます。（参考記事：「リッチ・シェリダン（Joy Inc.)から学んだこと」）
これはアジャイルの手法の一つであるのですが、ペアプログラミングの運用でこの会社が得たものの一つが組織全体でのナレッジの共有ではないかと思っています。
40人ほどの小さなソフトウェア受託会社が、すべての仕事をペアで実施する体制で、残業ゼロ、利益は右肩上がりを達成しています。
ペアの間で自然にナレッジが共有される、ペアが周期的に変わるので、ナレッジの拡散が行われる、ペアの会話が会社全体に広がって、社内は会話に溢れ、自然に知恵が広がっていく、そしてこのやり方が、実は個人個人が自主的に知恵を増やそうという学習意欲を掻き立てているということです。
ナレッジ・マネージメントは、文書、報告書だけがターゲットではないことも考えてみたいですね。
成果を確実に刈り取るための提言
繰り返しになりますが、ゴールを数値化して測定可能な状況を作るのが絶対条件です。
その上で考えられる解決策のアイデアを出していきます。
そして、その解決策から、目標を達成するイメージを組織全体で作ることが大事なのです。
すべてのことは「因果関係」で連鎖のように繋がります。
この考えを組織内で徹底して理解していただきたい。
つまり、何か手を打つ→組織に変化が起きる→さらに別の変化を引き起こすという、実は当たり前のことが、あまり一般的には理解されていないということなのです。
組織改革は組織や人の考え方、行動を変えることです。
そして、変化には時間が必要だということもあまり意識されないケースがあります。
だから、施策を考えたら、そこからどんな変化がどれくらいの時間で起きるかを予め予測を立てることが、本来、実施計画の中に含まれているべきなのです。
そして、更に重要なのは、この変化を予想するときに、障害になることと副作用をしっかりと予測する必要があります。
多くの人は、自分の考えたアイデアは、良いことばかりが起きると考えてしまいます。
しかし、現実には様々な障害が起こり、変化を止めてしまったり、良い変化も起きる反面、予期せぬ悪いことが起こって、成果が思うように現れないことがあるのです。
というよりも、多くの企業の改革が障害と副作用によって頓挫してしまうと思っています。
さらに深読みをすると、そんな失敗が日常的に起こっていて、だからあまり改革に真剣に取り組まない風潮が組織内に出来上がってしまうということが起きています。
また、人間の悪い習性として、失敗したときの言い訳を最初につくるために、ゴール設定を曖昧にしたり、施策さえ実現すれば自分は成果を挙げたことになると、目標をすり替えてしまったりするのです。
改革を成功させるためには、これらは絶対に避けなければなりません。
よって、解決策（施策）の検討段階から、障害、副作用の検討を入れるように、TOCの未来図を作る作業、あるいはその考え方を取り入れたいということに繋がります。
報告書管理に関する提言
戦略や方針に関する提言に加えて、戦術的な面での提言をさせていただきます。
狭義のナレッジ・マネージメントでは文書情報の活性化に取り組むということになります。
このときに、多くの企業では、今存在する情報、報告書に対して、どうやってアクセスできるようにするかという発想からスタートしがちです。
つまり、アクセッシビリティーを上げる文書管理システムを作ろう、という発想になるわけです。
しかし、技術情報がなぜうまく活用されていないかという現状をしっかりと検証してみると、多くの場合、そもそも活用されるに値する文書になっていないことが非常多いということが、活性化されない本当の原因であることがあります。（いずれにしても検証すべき）
そうなると、アクセッシビリティーよりも、報告書の質を高めて、組織内で活用されることで大きな成果を生むような報告書をたくさん作っていかなければならなくなるのです。
そして、報告書の質を高めるということが、実際にはどういうことなのか？それを組織の全員が理解することが重要になってきます。
ここの話が、全体の目標「開発効率向上」と繋がっていなければならないと思います。
開発効率とはそもそも何なのか？
単に同じことを重複してやっていることを避けることなのか？
失敗を繰り返すことを指しているのか？
ヒット商品の確率が低く、収益向上のスピードが遅いことなのか？
どれを達成したいのか？
つまり、これがゴール設定の数値化と測定方法の確立ということなのですが、報告書の質向上という意識を社員全体につける場合も、そもそも会社が何を目指していて、だから今の報告書のあり方はこんな問題、課題があって、それで今、我々はこういう報告書の質改善に取り組んでいるという図を全社で共有すべきです。
アクセッシビリティーにも問題があるのだとしたら、それは何が問題で、どんな状態に変えたいのか、全体目標との繋がりはどうなっているのか？（つまり、これをやれば開発効率は上がるのか？）
すべての活動は同じように、全体目標から繋がっているべきなのです。
なぜ、報告書の質を上げなければならないか、その結果、全社の目標に近づくことができるという意識が出来た上で、現場レベルで、実際にどんな報告書を書くべきかのノウハウ、さらに良い報告書を書かせるためのマネージャ―としての指導方法を作り上げる必要があります。
いきなり「質の高い報告書とは」のような指導をするのではないということです。
具体的な手順としては、まずは背景の教育、その上で、報告書の活用方法（再利用の仕方、再発防止方法など）の指導、最後に質の高い報告書を書くテクニックの身につけ方という手順が良いと思います。
テクニックに関しては、事例集のようなものと、勘所的なもので始めながら、徐々に日々の実際の活動から得られたノウハウを蓄積できるような仕組みを作るのが良いと思います。
弊社のA3報告書に関するE-learningは、質を上げるための理由、背景などの解説（一般的な考え方）と、活用方法の事例紹介、そして標準的なテクニックを提供するものになっています。
初期導入として使ってもらえたらうれしいです。
報告書の質向上について実際に各企業で進める場合は、基礎教育の後には、改革の意義などの戦略の理解を深めるための施策も必要だと思います。
また、各企業単独の活動としてやる場合は、背景をもっと企業独自の迫力のあるものにすることと、基本的なテクニックの基盤教育から、継続的にノウハウを積み上げていくための仕組み、あるいは仕掛け作りが重要だと思います。
リーン開発、セットベース開発実践に関する提言
戦略的な考え方については、ナレッジ・マネージメント活動への提言と同じです。
まずは、全社目標は何かというところからスタートすべきです。
さらに、現状ではなぜダメなのか？ということを考える癖が必要だと思います。
セットベース開発を自分たちは出来ていると思っているが、実際に開発期間は短くなっていないなどの声は本当に良く聞こえてきます。
多くの会社で同じことが起きていると思っています。
かつて、在籍していた会社でリーン開発の概要を技術系役員数人に説明したときに、「そのセットベースはうちでもすでにやっている」と2人の役員が言ったことを思い出します。
でも、実態はまったく違っていました。
今考えると、単に要素開発をしっかりとやる風潮があることを言いたかったようです。
つまり、セットベースという形をインプリすることと、リーン製品開発が手法、理論として成し遂げたいことは、必ずしも同じではないということなのです。
手法をインプリすることは、成果を達成することとは次元が違うということだと思います。
まさに施策の実行を目標化している例になってしまうわけです。
一番重要なのは、成果、つまり開発効率向上という全社目標達成ということです。
これが出来ていないなら、そのセットベースはまったく意味がないことになります。
なので、セットベースの形が出来ているかどうかを評価するのではなく、開発効率向上という目標が達成できているかどうかをチェックすべきということです。
その上で、成果が達成できていないなら、それは何故なのか、もう一度現状をしっかり分析することが必要になります。
多くの企業が陥るのは、繰り返しになりますが、手法のインプリを目標化してしまう誤りと断言できます。
全社の活動でも、リーン開発の展開そのものを絶対に目標化してはいけません。
つねに達成すべきゴールを見ることが、特にマネージメントとしては求められるのです。
だから、ゴール達成度は言い訳できないような測定方法でチェックすべきです。
リーン製品開発を展開するときに、例えばセットベースが出来ているかどうかという判断基準を持たないようにしてください。
その上で、達成したい成果は何か？それが今出来ていない原因は何かという現状分析を客観的、冷静に思い込みを排除して捉えることから、もう一度やるべきと思います。
提案したいのは、各企業の組織問題に関して、例えばセットベースに関わるところにフォーカスして、TOCなどを使いながら現状分析をしっかりやることです。
組織改革の全社展開に関する提言
組織改革の最後の難関は部分的に試行した改革の全社展開だと思っています。
しかし、これには秘策があります。
かつて、日本企業がTQCやCS活動で成功してきた事例を思い起こしてみてください。
トップから末端社員までが、一つの手法や考え方を共有して、熱狂して会社変革に取り組むことが実際に出来ていたのです。
それはある意味、宗教的な進め方です。
リーン生産やリーン開発を使って成功したカリスマ社長の事例もあります。（参考記事：「リーン生産、リーン開発を学び続け変革し続けるカリスマリーダーから学ぶこと」）
全員が同じ方向を向く、非常に有効な方法だと思っています。
もちろん、本当の宗教ではありません。トップ、ミドルが率先して一つの考え方を学び、実践しているという姿を見せ続けることです。
特にトップが外部から知恵を入れて学んでいる姿は、社員に少なからずインパクトを与えます。
宗教という言葉が悪い印象を持つ場合があるのですが、大事なことは目的、目標を共有することと、そのやり方も広く賛同されることが重要です。
大事な言葉は繰り返すべきで、TQCでは、「次工程はお客様」「問題意識をもつ」「改善し続ける」などの言葉が社内に溢れていました。
言葉としての繰り返しに加えて、活動を奨励することが大事で、例えばQCサークルが最もいい例です。
見本を見せて、やらせてみて、誉める。山本五十六の教育方針ですね。
リーン製品開発の肝は、仮説検証を小さく回すこと、失敗から学び堅牢な組織を作ることと、合わせて新しい価値を世の中に生み出す、つまりイノベーションを「知識資産」を中心に回すことで成し遂げることだと思っています。
QCサークルをモデルにした例を考えてみると、「リーンな事例」「リーンシンキングによる改善事例」をグループワーク、デイリーな仕事と別に行い、それを発表、共有するような活動なども考えてみると良いと思います。
以前にいた会社で、10人くらいの亜流組織を作って、「開発戦略は意思決定を遅らせろ」という本を与えて、半年間、好きなことをやって何か新たしい製品を提案しろという無茶なことをやったことがあります。
ものすごく高いモチベーションでリーン開発の実践を進めてくれました。
まとめ
組織改革は、どんな企業でも何らかの形で進めているはずです。
もちろん改革が順調に進んで、企業業績が常に右肩上がりという会社もたくさんあります。
しかし、2008年のリーマンショックの前後あたりから、日本の製造業に陰りが出てきているように感じています。
大多数の製造業企業が、組織を変革することが出来ずに収益が伸び悩んでいます。
かつての成功体験がマイナス要素になっているようにも思うし、市場環境、顧客の購買行動などの急速な変化に対応できていないからのようにも見えます。
筆者は、多くの企業が好景気の時代に効率化を求める代わりに、組織力や個人力を犠牲にしてしまったのではないかと考えています。
もしそうだとすると、問題の病巣は長い時間をかけてゆっくりと進行した結果、今の状態になっているものと推察されます。
変化はゆっくりと確実に進行します。
だったら、良い変化を起こすトリガーも早く与えないと手遅れになってしまいます。
組織に変化を起こすという概念を企業全体が持つには、かつて日本企業がTQCを展開したときのように大きな力、大きな波を起こす必要があります。
変化は状況が連鎖することで起こしていきます。
弊社の独自手法である「連鎖式組織改革法」は、組織改革の本質を捉え、トヨタの成功事例の本質を読み、組織変化を連鎖的に起こしていくことで、確実に変革を起こす手法であります。
本記事に賛同いただけましたら、ぜひとも弊社へお問い合わせの上、「連鎖式組織改革法」をお試しください。
この記事を気に入ってくれたら、下の”いいね”ボタンをお願いします！！
