製品開発組織の正しい組織改革の進め方をバーチャル討論（第三回：実践方法）製品開発革新の具体的な実践方法

鴨志田さん、いよいよ今回が最後になります。今日もよろしくお願いします。

前回は、製品開発組織のあるべき姿について話をしましたね。結論としては、それぞれの企業の状況を見ないと一般論として語ることはできないものの、比較的陥りがちな、効率を追い求めた結果、個人の力が弱っている企業については、「社員に任せる仕事のやり方」というのがあるべき姿の一つであるという話をしました。

そして、社員に任せるやり方をする際には、失敗させる余裕も必要だという話もしました。

さらに、社員に任せる仕事のやり方ということを改革の出発点にするならば、そこからどんな変化が組織に起こっていくのかを検証してみることで、多くの組織問題をいっしょに解決することができるかもしれないという話もしましたね。

ある一つの施策でも、それが根本問題に対するものであれば、そこから派生していく変化を捉えた未来の状態が自分たちの目指すあるべき姿になっていれば、その改革は成功確率が上がるわけです。

では鴨志田さん、すでに議論したことではありますが、あるべき姿に変えていくための組織改革の進め方で、これまでのやり方の問題点は何でしょうか？

そうでしたね。複数の課題が因果関係で繋がっていることを意識せずに、すべての課題に一つ一つ手を打つような、いわゆる対症療法になっているということが一つの問題で、もう一つは、大きな経営課題についての評価法が確立されないで、施策実行レベルなどの代替え手段で評価してしまうことで、本来目指すべきものを見失ってしまうことがある、ということでした。

さて、このような問題点を認識した上で、どうやってあるべき姿への組織改革を実践するべきなのでしょうか？

確かにTOCのフレームワークは有効なのですが、前回もお話ししたように、TOCの考え方は実は当たり前のことをしっかりとやることなんです。

なので、TOCを意識せずに、これまでの議論を踏まえて鴨志田さん自身で考えてみませんか？

何か具体的なケースで考えていきましょう。仮に、トップオーダーとして開発中の品質問題発生件数を半減させ、常態化している開発日程をまずは日程厳守、さらに開発期間の20%短縮を3年以内に達成させなさい、と言われたことを想定して、どうやって改革を進めるか考えていきましょう。

わかりました。まずは鴨志田さんの考えで進めていきましょう。

でもまず最初は、これまでの御社の考え方だったら、どのように進めるかを考えてみましょう。

まずどんなことから始めますか？

なるほど、やはり問題を局所的に捉えて課題解決をしようとしていますね。

では、本質的にはどうすればいいのですか？

そうですね。ここはとても大事なところです。

開発中に品質問題が多発しているというところで、直接的に品質問題を発生させている原因を捉えようとしていますが、設計者の検討不足、知識不足というところが、なぜ起こっているのかが十分に検証されていないように思います。

その辺りを少し深掘りしてみたいのですが、御社の今までのやり方で進めた場合、挙げてくれた施策は本当に問題解決につながるのでしょうか？

そうですね。結論から言ってしまうと、開発中の品質問題の発生原因に関する分析が不十分なのです。

一つひとつの悪い症状はお互いに因果関係で繋がっている。ということは品質問題の発生原因も色んなことが繋がって起こっている可能性があるということです。

何か一つ原因と思われることを思いつくと、それで安心してしまって他の原因を考えなくなってしまい、そこだけに着目するから本質的な解決に繋がらないんです。

では話を戻すと、組織で起きている問題をすべて挙げて問題の連鎖をみてみるとおっしゃいましたが、その連鎖に品質問題は入っていそうですか？

そうですね。私の経験からもそう思います。

今回、御社の問題を細かく分析することが私と鴨志田さんの議論の目的ではなく、開発組織の改革をどう進めるかということを一般的な考え方として導き出したいので、ここでは根本の問題が「社員が主体的に動けていない」ということだとして、話を先に進めましょう。

では、鴨志田さん、根本問題を掴めた、そして根本問題からターゲットとなる品質問題の発生の件と日程遅れの件が繋がっていることもわかったとして、その先はどうしますか？

その通りです。

開発組織がプロセスに従って製品開発のQCDを計画通りに達成するという成果物をアウトプットする流れに、制約を加えて止めてしまっているのがボトルネックです。

組織の生産性は、ボトルネックで制約を受けてしまっているわけなので、この制約を緩めてやれば流れは今よりもスムーズになるはずです。

では、「社員が主体的に動けていない」というボトルネックをどのように解消できますか？

ハハハ、そうですね。

実はここが企業ごとのアイデア勝負のところです。答えは一つではないし、絶対的な正解というのがあるわけでもありませんが、それでは話が進まないので、あくまで例として考えられる対応方法をいくつか挙げて、それをベースに話を進めていきましょう。

良く挙がってくるアイデアとしては、製品開発における一人一人の責任範囲を広げるために、プロジェクトメンバーを少しずつ減らしていくというものがひとつ。具体的なやり方としては、比較的失敗が許される小型のプロジェクトを、若手主体の少人数に任せるお試しプロジェクトからスタートし、少しずつ広げていきながら組織として経験を積んでいくというものです。

他には、同じような考え方ですが、手を挙げた人にプロジェクトリーダーを任せて、やはり若手主体の小数メンバーにテーマを任せるというものもありました。これは新しいコンセプト商品のテーマを公募するような形にして、組織としてもリスクを取りやすい状況で、やはり失敗を許容しながら成功体験を積んでいくようなアイデアもあります。

キーワードはリスクを取れる状況に少しずつシフトしていく考え方だと思います。

リスクを取りやすくするために、例えば全就業時間の20%を、個人ごとに設定したリスクテーマに張り付ける、あるいは自由なテーマをやらせるというようなアイデアもあります。

あとは、人事制度を絡めるようなアイデアですが、単に個人のキャリアアップ計画を人事や組織がバックアップするというだけではなく、個人のスキルで他のプロジェクトへの貢献度を測って、貢献度にしたがってインセンティブを与えるようなことで、個人のスキルアップを本気で奨励することで、組織全体の底上げを図っていくようなことも考えられますね。

今挙げたアイデアの中で、鴨志田さんはどれが良いと思われますか？あくまで話を進めるための選択ですが。

なるほど、やった経験もあり、また一時期うまく行ってたものが、うまく行かなくなったとしたら、その原因なども考えていけるので面白いかもしれません。

では、新規製品を手を挙げた人に任せる、という施策が挙がったとして、その次にやることは何だと思いますか？

完璧ですね。結構、地道な作業ですが、「新規製品で手を挙げた人にプロジェクトを任せる」という施策について、もう少し具体的にイメージを固めて、それをやると組織がどんな風に影響を受けていくか、次に何が起きるかを考え、次に起こることが予測できたら、その次は？という風に変化の連鎖を最後まで行っていきます。

そしてこの因果関係の連鎖を図として残しておきます。

ただ、ここで勘のいい方は気づいているかもしれませんが、そんなに良いことばかり起こるわけではありません。悪いことも起きてしまうかもしれません。また、そもそもこの施策自体が、簡単に出来るかもわからないわけです。

つまり、そもそもこの施策を実行する障害と、実行した場合の副作用ということも考えておくのです。

前回もお話ししましたが、人は自分の出したアイデアは良いものだと思いたいですよね。だから、実は良いことしか考えない傾向があります。そしてこれが失敗に結びつくのです。

なので、最初の段階で、良いことと悪いこと、そして実行するための障害を考えておくのです。

どうですか？出来そうですか？

全部を検証することはしませんが、ちょっと考えてみてください。どんな良いことが起こり、どんな副作用があって、また実行にどんな障害がありますか？

なるほど。実際に御社でやった経験があることなので信憑性がありますね。この例を取り上げて正解だったかもしれません。

では、今となって、この施策を成功させるための考えは思い浮かびますか？

全員にチャンスがある。でも普段は全員、既存製品の開発をしている。でも、いつでもチャンスを拾おうとする環境もある。そういう世界が作れないかということですよね？

アイデアというのは、何かまったく新しいものではなく、組み合わせだったり、何かを単純に減らすだけだったり、別の領域でうまくやっていることの応用だったり、つまり、どこにでもあるものから生まれたりするんですよね。

いいんじゃないですか。それ、ホントにありじゃないですかね。

まあ今回は、進め方の手順を確認するのが目的なんで施策の内容にはこれ以上踏み込みませんが、実は今の手順が大事なんです。

つまり、根本問題を見つけて、ますはその対応方法を考える。そしてその対応方法によって目標が本当に達成できるかを因果関係を使って検証していく。さらにそのときに施策による副作用や施策実行の障害を挙げて、その対応を考える。すると施策そのものが洗練されていくんです。

そしてもっと大事なことは、施策の内容に関して、検討メンバーで議論を進めていくと、最初は漠然とした施策内容が、メンバー間でイメージが共有されていき、より具体的なものになっていきます。

言い換えると、根本問題に対応する施策を考えて、それで目標達成が本当に出来るかを検証して、課題があればもう一度施策のやり方に戻り、ということを繰り返しながら、これから作っていく組織、プロセス、あるいはシステムについての世界観をメンバーで作っていくことが、本当にやるべきことだと思うのです。

私のところに相談に来る会社は、多かれ少なかれ何らかの問題、課題を抱えています。

なので、私の見えるところでは、こういうことをしっかりとやっている会社は少ないように感じます。

恐らくですが、トヨタなど外からはうまく出来ていると思われている会社は、きっと当たり前のことを大事にしてきた結果、良いところを長い期間守れているのかもしれません。

ただ、トヨタだって大きな会社であって問題がゼロというわけでもないと私は予想します。成功している会社を神格化してしまうのも問題ありだと思っています。

問題なのは、なぜ当たり前のことが出来なくなってしまったのか、あるいは当たり前のことを犠牲にしてしまう何かがあったのか、あるいは他のことを優先してしまったなどと考えると、問題の真相に近づきやすくなるかもしれません。

どうですか？トップから与えられた目標を達成するための組織改革の進め方は、わかっていただけたでしょうか？

そうですね。世界観を作った後が実際の改革活動ということになります。

ここにも多くの注意すべきポイントがあるのですが、ここでは簡単に説明しておきます。

まずは、施策、つまり作るべき世界観に到達するまでには、様々な障害があります。これは先ほども少し挙げていただきました。

実際に活動を始めるための詳細計画を立てるときには、この障害を一つずつクリアしていくための中間目標を設定します。いわゆるマイルストーンというやつですね。

そして、いくつかの中間目標を無事に通過した先に、最終目標があるという計画を作るのです。でも、これって当たり前のことですよね。

実際の活動中は、この中間目標を目安に大きなPDCAを回します。大きなというのは、大きなPDCAの中に小さなPDCAを回すことが出来れば、もっと早く確実に目標に近づけるのだと思っています。

そしてPDCAを回すということは、何か計画に不備があれば、そこで立ち止まって計画を修正したり、少し後戻りしたりすることも必要だということです。

さらに、PDCAを回すときの手掛かりとするのは、施策の検証をするときに作った因果関係による問題解決のチャートです。ここで検証した組織が変化していくことを予想した図を、活動経過のチェックをするために活用します。

また、計画・実行フェーズで注意すべきもう一つのポイントは、この組織が変化するために必要な時間です。組織改革はある意味、組織の文化、メンバーの考え方なども変えていくことです。だから一朝一夕には行きません。この時間感覚をしっかりと組織全体で持つことが大事なんです。

手を打てばすぐに答えが出るものと、時間がかかるもの、それらをきちんと管理すること。場合によっては、ゆっくりとした変化を感知して活動にフィードバックを与えることも必要なんです。

実はそこが最大の問題なのかもしれません。

変えることを良しとしない人は組織内に大勢います。その人たちを正論で説得するのは至難のワザかもしれません。

トップの考えが変われば、そこから下を従わせることは可能です。トップの説得が一つの鍵でしょうね。

しかし、それも難しいときには、そこが我々コンサルタントの出番なのですよ。わが社、フューチャーシップ（株）では、今日お話しした経営トップからの目標を達成するための当たり前のことを当たり前にやる進め方を独自のフレームワークに仕立ててあります。

そしてそのフレームワークを使って実績を出してきています。御社トップや組織内で、そのやり方を布教することも出来ます。

弊社はまた、これまでのクライアント企業様とのお付き合いから、組織改革における陥りやすい落とし穴についてもたくさん学んでいて、その失敗談からさらにノウハウを積み上げもしています。

必ずお力になれると思いますよ。

いやいや、鴨志田さんもおっしゃったように、御社内でも反対派はたくさん出てくるでしょう。私どもの説得でもゆるぎなく反対する方もいらっしゃるかもしれません。

だから、出来るだけ多くの人が、本当の進め方をいっしょに理解していて欲しいのです。推進派の皆さんと私どもコンサルタントが協力して早く確実に進めることが大事だと思うのです。

さて、話は尽きないですが、一通りの議論は出来たと思うので今回の討議はここまでにしましょう。

鴨志田さん、ありがとうございました。

.

.

三回にわたる討議をやってきました。一回目は開発組織の現状認識について、二回目は目指すべく姿について、そして最終回の今回は、どうやって改革を実践していくかということについて開発組織のマネージャ―である鴨志田さんと議論をしてきました。

できるだけ、広い視野から議論することと、実例に近い話題を使うようにしてきましたが、お役に立てたでしょうか？

今回お話ししてきた開発組織の改革手順は、本質的には当たり前のことの集まりなのですが、多くの企業にとって実践は易しくないものかもしれません。

特に、組織内での考え方の周知は、ぜひ弊社のコンサル・サービスの活用もご検討ください。