製造業エンジニアの道

自分を伸ばし、会社を伸ばす自己革命

パラダイムシフトを先読みする

時代の流れは速い。

技術は日進月歩で進んで行く。

でも、その流れの中にいると、流れの速さに鈍感になってしまうのかもしれない。

 

20年前のワークスタイルやライフスタイルは、思い出そうとすれば思い出せなくもないが、実感として忘れてしまっていることが多い。

 

例えば、ワープロがまだ普及する前、あるいは出始めたころ、人々は文書をすべて手書きで書いていた。

会社の報告書もすべて手書きだ。

 

当時は当たり前のことで、ワープロが出始めたころは、ワープロでやったら返って時間が掛かるし、きっと流行らないんじゃないか、くらいに思っていた。

 

今、手書きで何かを書く機会はほとんどない。

 

電車に乗るとき、駅の入場のときに、定期券を駅員さんに見せて、目視でチェックを受けて入場したし、切符は駅員さんが鋏を入れて入場した。

 

降りるときは、定期の場合は再び目視チェックで、切符は駅員さんに渡して駅を出るしくみだった。

 

駅員さんのチェックは、人間のチェックなので不正を見逃すこともあった。

そして、20年前には、キセルという不正が横行していた。

 

A駅からB駅へという比較的長い区間を定期で通勤、通学するとき、A駅と隣駅間の定期と、B駅と隣駅間の定期券を持ち、つまり間を中抜きして、定期券の総額を安くするという不正だ。

 

キセルという喫煙用の器具が、口元と、たばこを差し込む部分のみに金具を使う、つまり、入り口と出口にのみ金を使い、間は使わないということで、このような不正をキセルと呼ぶことになったのだ。

 

自動改札の導入で、駅員さんの目視チェックがなくなり、切符や定期も電子式になって、入場記録がないと出場できなくなって、電車での不正はほぼ不可能になった。

もちろん、自動改札や電子化によって、われわれも便利に鉄道やバスなどを利用できるようになった。

 

でも考えてみると、いつの間にかキセルつまり不正乗車がすっかり排除されたわけだ。

 

技術というのは、やみくもに進化しているのではない。

基礎技術や要素技術は別として、それらを応用技術として製品にしていく段階で、世の中の進化を支えて、われわれのライフスタイル、ワークスタイルを変革してきている。

 

ニーズに合わせた技術開発、製品開発と言われるが、私は”ニーズ”という言葉は適切でないように思っている。

 

確かに”必要性”があるから、新しい製品や考え方が受け入れられて、世の中が変わっていくのだが、この変革には、なにかもっと必然的な重力というか、エネルギーが働いているように思う。

 

顧客という言い方でもいいし、社会全体を顧客と捉えれば社会なのかもしれないが、顧客や社会が進化したいという強い欲求があって、それが、顧客や社会が明示的に気づいていないことがたくさんあるはずなのだ。

 

人間は思い込みをたくさん抱えている。

今の状態を続けることが楽なので、ある意味、変化を嫌う部分もある。

なので、現状にたくさんの不満があっても、それを何とかしたいとはあまり言わない。

不満や現状の不具合を、自分なりに工夫して回避することで、今の状態を受け入れている。

 

ワープロの事例のように、最初はみんな半信半疑で様子を見ている。

それが、アーリーアダプターと言われる先駆け者、一種の新しもの好きによって使われ始め、それが口コミによって広まり、徐々に使ってない方がマイナーになり始めると、加速度的に広まってデファクトになっていくのだ。

 

駅の自動改札も、もちろん技術的に磁気書き込み、読み取りの技術や、フェリカの発明などによって、便利なシステムが実用化されていった。

 

技術者サイドから言うと、してやったりではないが、便利な世の中を作るために侵食をも忘れて自分たちの想いを達成したということになる。

これは間違いではないし、開発者たちの並々ならぬ想いは心から称賛するに価するものだが、この変革の成功は、開発者の想いだけでは結実しないはずだ。

 

顧客や社会の進化への欲求、進化を促す重力とのマッチングがあったはずだ。

 

ワープロを考えてみる。

 

文字を書きたい、から文字を早くたくさん書きたい。

文字を書いて、それを他人に伝達したい。

文字を書いて保存したい。

 

文字を書く、という一つの行動の周りには、関連する行動が数珠つなぎのように繋がっている。

この一連の行動、ストーリーの中に、顧客の不満や知らず知らずに我慢したり、自分で工夫したりしていることが含まれている。

 

顧客は解決手段を知らない。

そこにワープロなる製品が提案される。

同時に、パソコンが現れ、ハードディスクに代表される記憶装置がムーアの法則とともに進化し、インターネットが普及してきて、

早くたくさん書く。

それを伝達する。

それを保存する。

それらの一連の行動を包括的に実現する世界に少しずつ世の中全体が変化していくわけだ。

 

ここには、技術の進歩と、顧客の進化への欲求重力とのマッチングが明らかに存在する。

 

パラダイムシフトとは、こういうことなのだと思う。

 

さて、次のパラダイムは何だろうか。

ひとつ明確に変わりつつあるのは、ショッピングだ。

Eコマースへのシフト、リアル店舗とEコマースの融合など、インターネットによるショッピング革命は現実に進みつつある。

 

そして、ショッピングの変化で、スーパーマーケットに注目してみたい。

電車の不正と同じく、今、スーパーマーケットでは、万引きの被害との闘いがある。

月に一度くらいの割で、テレビでもスーパーの万引き問題を取り上げている。

 

中でも熟年の人たちの万引きは、見ていて何かやりきれなさを感じる。

 

10年以内には、万引きがこの世の中からなくなると私は考えている。もちろん、電子決済やRFIDなどの技術の進歩が背景にあるのだが、何よりも顧客や社会が、その進化を強く求めていて、その変化への強い重力が働いているからだ。

 

イノベーションは偶然の産物だという人がいる。

きっとこれまでの多くの偉大な発明の中で、技術の進化としては成功していても、世の中に受け入れられなかったものがたくさんあるはずだ。

 

成功したものも、世の中に受け入れたこと自体は偶然だったものも多い。

 

パラダイムシフトを先読みするということは、顧客や社会が進化したいと願う重力を読むことだ。

それは、顧客の口から語られることはない。

 

顧客がどんな思い込みをしているか。

顧客が、一連の行動、つまりストーリーの中で、どんな我慢や工夫をしているか、そこに進化を願う重力が存在するはずだ。

 

それを技術者が見つけることを強く期待したい。

 

 

技術者として会社に飼い殺されないために

「自分の技術力を伸ばしたい。」

多くのエンジニアは、技術力向上を切望している。

 

どうやって技術力を磨いていくか、というと、いい仕事をしながら自然と技術が身に付くというのが一番効率的だ。

 

でも、仕事は選べないとなると、いい仕事についてる他人がうらやましく見えたりすることもある。

 

なんだか忙しいけど、自分が伸びてる感じがしない、というケースも多い。

毎日、雑用やら、振り返るとあまり意義を見出せない打ち合わせばかりで一日が終わってしまう。

 

そういう一日をずっと続けていると、一年二年があっという間に過ぎて、自分は何をしているのだろう、と運のいい人はあるときに気付いたりする。

 

さて、自分を守るのは自分しかいないということに気付いてほしい。

 

忙しい職場だから、近くの先輩、上司、同期や後輩しか普段は見えない。

なので、みんなが同じような状況だからと安心してしまうのかもしれない。

 

見てほしいのは外の世界だ。

好きなことを好きなようにやって、技術力をすくすくと伸ばしている輩は山のようにいて、自分の会社からは見えないだけなのだ。

 

長い間、ひとつの製品群を持続的に進化させている企業では、技術者もなかなかいい仕事には巡り合えない傾向がある。

システムが、不必要に複雑で肥大になり、すべてを知っている人間がだんだんいなくなっている世界がそこにはある。

 

そう、すべてを知らない先輩に教わることほど不幸なことはない。

そして自分もすべてを知らないまま後輩に教えることになる。

 

すべてを知る。

つまりこれは、自分が担当している製品のアーキテクトになるということだ。

 

パーフェクトを目指す必要はない。自分の担当モジュールしか知らないところから、隣のモジュールとの連携、その上の階層の全体像を把握する。というように段階的に上位層から担当モジュールを語れるようにする。

 

簡単な話だ。

興味を持てばいい。

忙しくても興味を捨てないことだ。

 

新人が入ってきたり、新しい同僚がきて何かを聞かれたとき、答えられなかったことを放っておいてはいけない。

 

なぜ、自分はその疑問を持たなかったのか、あるいは疑問を持っていてもそれを解決しなかったかを、しっかりと振り返ることが大事だ。

 

無知なことに興味がなくなったら、エンジニアとしては失格だと思わなければ、技術力が伸びていないことを会社のせいにすることから逃れられない。

 

あまりにも多くの無知を放置してきたので、もう今さら聞けない、ということかもしれない。

しかし、それを更に放っておくと、エンジニアとしては先がないだろう。

 

ひとつ方法がある。

わからないもの同士を集めて、「勉強会」という名前にして、「今さら聞けない」を帳消しにしてしまうことだ。

 

これは結構、有効だと思う。

私もこれをやって何度も難局を切り抜けてきた。

 

「勉強会」とは、素敵な言葉だ。

私は、今は教える方が主だが、教えられる方でもたくさんの「勉強会」に参加している。

 

勉強したいという熱を持った人たちの集まりは、実に効率的に勉強が進む。

 

「技術力を上げる」という言葉だけでなく、「勉強」するための行動を起こせば、会社に飼い殺しになる危険を避けられるはずだ。

 

 

グローバルで浮いてる日本企業

グローバルEMS企業(アメリカを本拠とするグローバル企業)の日本支社で開発部門の責任者をやっていたころの話。

 

まだフォックスコンが台頭する前、ソレクトロンとかフレクトロニクスといったメガEMSが日本に進出してきて、ソニーNECなどから日本の工場を買収して、日本でのEMS事業の拡大を狙っていたころ、私はジェイビルという世界ではあまり目立たないけど、EMS事業では世界で4位の会社で働き始めました。

 

当時、多くの欧米企業が、製造での付加価値よりも、製品企画や開発にこそメーカー企業が勝負するチャンスがあると、製造のアウトソーシングが進んでいました。

Apple、シスコ、HPなど、経営資源を企画や開発にシフトして成功している会社が多数出てきていました。

 

ところが、日本企業は、1970年から80年代にかけて、TQCで品質の日本として、製造業では押しも押されぬ存在となり、Japan As No.1 という本が大流行しました。

 

この成功体験が染みついていたせいか、日本でのEMS企業の進出はほぼ失敗に終わります。

部分的に、EMSを利用しているケースは多数あるものの、フォックスコン以外のEMSは、2018年現在、ほとんどが撤退しています。

 

この件に対しては、まだたくさん言いたいことがありますが、このときのひとつの経験談をお話ししたいと思います。

 

当時、EMS企業で日本での開発責任者をしておりましたが、人件費の問題などで、開発リソースは中国を活用そようと、開発拠点の本部を上海に置いていました。

私も、上海で多くの時間を過ごしましたが、特に日本企業の開発マネージャの方たちを上海にお招きして、ビジネスチャンスを伺っていました。

 

そのときの私の上司は、ドイツ人で、でもとても仲良くしていて信頼関係も厚かったのですが、ある日本企業の開発部長を上海に招待してミーティングを行ったのですが、この部長さん、日本人同士の会話では饒舌なのですが、海外の人たちとのミーティングでは口をつぐみます。

 

英語が苦手ということなので、私が通訳を務めますが、それでもあまり口を開きません。こちらのプレゼンにも無表情で、私が日本語で本音を引き出そうとしても、眉につばを付けるような感じで、終始しかめっ面をします。

まあ、打ち合わせとしては失敗だったのですが、会議が終わって、ドイツ人の上司が私のところに来て、

「お前は良く我慢できるな。ずいぶんといやな思いをいただろう。」

と言いました。

「根っからの日本人ですね。」

と私が言うと、

「日本人は、いつも自分たちが特別だと思ってないか?」

と言いました。

 

ちょっとドキっとしましたね。

自分たちがいつも特別。。。

知らず知らずのうちにそんな思いが日本人の中に生まれていないか。。。

 

そしてトドメの一言。

「彼らを二度と俺の前に連れてこないでくれ。」

 

お互いの違いを理解し、受け入れ、そしてグローバルでビジネスをする、という世界で、日本企業はいつまでも大量生産時代の成功を忘れられずに、自分たちの成功の上で立ち止まっている。

 

もう、そういうのをやめたいなと、強く感じています。

 

 

マインドマップで右脳を刺激

f:id:kamonk:20180621180413j:plain

マインドマップは、会社勤めのころ、アイデア検討の場で使っていたのですが、どちらかというと他人が使っているのを見よう見真似で使っていたというのが正直なところでした。

本来の意味や成り立ちなどを知らないまま、発言内容を関連付けながら整理していくツールなのだと思っていたわけです。

 

10日ほど前に、知り合いがマインドマップの講師をしていて、奨められるままに一日コースの講習会に参加してきました。

講師の方は、マインドマップを作ったというTony Buzan氏に直接教わったということで、最初に、世の中で使われているマインドマップは、亜流も多くて本来の意味を誤解しているものも少なくない、という話がありました。

 

マインドマップの活用方法は4つで、

  • 思考整理
  • イデア発想
  • 記憶
  • コミュニケーション

なのだそうです。

マインドマップの作り方として大事なことは、

  • キーワードをつなげていく(文章を書かない)
  • 色をたくさん使う
  • イメージ(画像、イラスト)を使う

ということで、特に私が使っていたものは、文章を書いていたように思います。

人々の発言の主旨を簡潔に書いていくようなイメージを持っていましたが、実は本家のマインドマップでは、文章は入れないのだそうです。

 

また、色やイメージも意外でしたが、実はマインドマップは脳の構造と同期するように考えられていて、右脳と左脳を効果的に使うようにするものだとの説明でした。

 

確かに、右脳を動かすというのはイメージを使うというのを聞いたことがあります。また、色も脳を刺激したり、記憶に残すためには重要なのだそうです。

 

右脳といえば、七田式というのが有名ですね。

幼少時から右脳教育をすると絶大な効果があるなどと言われ、七田式は子供の教育として広く知られています。

 

自分の右脳が動いているのか、以前、七田式の本を何冊か読んで試してみたことがあります。オレンジチャートというのがあって、オレンジ色の下地に、真ん中に紺色の丸が書かれているシンプルな画像です。

これを30秒ほどじっくりと眺めて、目を閉じると残像が残るのですが、元の色(オレンジの下地に紺色の丸)が残像として残っていれば右脳が動いているということらしいのです。

私は、何度か試してみたのですが、何度やっても残像は色がひっくり返ったもの(紺の下地にオレンジの丸)しか見えず、これはつまり右脳が動いていないのだそうです。

 

繰り返し訓練すると、少しずつ残像が元の色になり、しかも、その残像が残る時間がどんどん長くなるということで、右脳が活発に動くと、残像の色を自分で変えたり、形まで思ったように変えられるようになると、その本には書いてありました。

結局、当時は右脳があまり動いていないらしい、という事実を突きつけられて、あきらめて引き下がったのですが、ここでまた、右脳を使うという場面に出くわして、少しばかり腰が引けたのですが、反対に今度こそ、右脳の活性化に成功してやる、という想いも芽生えて講習を受けました。

 

話をマインドマップに戻します。

多くの人が経験があるように、文字や文章を記憶するのはなかなか難しいものがあります。でも、イメージや色は記憶に残りやすいですよね。

そのイメージや色と、キーワードが、書いた位置や周辺の他のキーワードと関連づけられると、キーワード同士がつながっていきます。

これは講習の中でも体験しました。

 

また、キーワードとイメージが並ぶことで、実はそこに書かれていない、他のキーワードやイメージ(どちらか一方でいい)が浮かんでくるのです。

これは、プレインストーミングにも似てるかもしれません。

イデアが他のアイデアを呼ぶというものです。

 

製品開発の中で、私が実践してきたアイデア発想は、課題に対して抽象度を高くしながら、近視眼的な見方を、様々なこと、様々な技術領域やビジネス領域に視点を広げて、他の領域からアイデアを借りてくる、ということをやって成果を出してきました。

 

もしかすると、マインドマップは、その考え方にプラスして、さらにアイデア発想を促進するものになるかもしれません。

 

マインドマップは、組織の中での強力なコミュニケーション・ツールになりえるものかもしれません。

講師は、マインドマップ以外でも先生業をしているとのことですが、生徒さんたちの悩みを聞くときに、マインドマップを使うのだそうです。

生徒が悩みについて話すことを、色で分けて、時々絵のようなものも書いて板書するのだそうですが、生徒さんは、それを見ているうちに、勝手に自分で解決策を見つけて納得して帰っていくことが、時々あるそうです。

絶対に解決できるとは言えないでしょうが、面白いエピソードですね。

 

さて、右脳が動くかどうかは別として、マインドマップを自分の仕事に活用したいと思うようになりました。

さて、どうすればいいか?

 

とにかくたくさん書いてみることと教わりました。

書き続けることで、自分で気付いていくことなのでしょう。

 

ということで、毎日、朝にその日のやるべきこと、つまりスケジュールをマインドマップで書くことにしました。

 

本来、カラーペンと画用紙を使って、手書きで書くのがいいのだそうです。

 

そういえば、パソコン文化になって、文字すら自分では書かなくなった現代人にとって、自分で鉛筆やカラーペンを使った”手書き”というのは、大いに脳を刺激するものかもしれません。

 

私も、講習が終わって10日間、毎朝起きると、画用ににカラーペンを使ってその日の為すべきこと(ToDo)をマインドマップに書き出します。

 

たった20分程度で、今日一日やるべきことをイメージとキーワードを使って表現します。これ、意外と気持ちいいです。

朝、まっすぐに画用紙に向かって、その日を創造し、それを自分なりに表現して自分に対して約束をする。

朝から、とても気持ちがシャキっとして、気持ちが昂ります。

 

ほんの小さなアクションですが、これは癖になりそうです。

 

冒頭の画像は、iPad用アプリ(Buzan公認アプリ)で作成しましたが、普段は手書きで書いてます。よそ行きにアプリを使ってます。

 

毎日、忙しい。

でも、忙しい中で、何か小さな、でも前に進んでいることを探している人!!

 

参考にしてください。

 

 

 

「知らないことを知ることから」が開発の本質

「自分が何を知らないかを知る」ということは、易しいようでなかなか難しいのかもしれない。

開発現場は忙しすぎて、また、技術の進歩も早くて、わからないこと、知らないことをキャッチアップしていたら、求められる仕事のスピードについて行けないのかもしれない。

 

でも、開発の本質、技術者の本領って、知らないことに大きな興味を持って、それを追求して、アイデアを出すことだと思う。

 

製品全体のシステムが肥大化して、XXの専門家がたくさん現れて、組織はマトリクスされて、隣の部署が何をやっているかなんて、わからないし、わからなくっても全然かまわない、ということが随分と長い間続いてしまったように見える。

 

いろいろなメーカー企業のマネージャーに話を聞いてみると、製品全体をわかっている人間はもういない。製品をゼロから設計できるやつは、もう10年も前にいなくなってる。という答えが返ってくる。

 

「知ってることを知っている」

「知らないことを知っている」(知識ギャップ)

「知っていることを知らない」(暗黙知

「知らないことを知らない」(愚者の天国)

 

下の2つは、まさに「無知は罪」というところだろうか。

上の2つの世界で、知識ギャップをみんなが同じレベルで理解していて、それを会社全体で追い求める、というのが本来の姿だと思う。

 

きっと、20年前は、多くの世界がそうだったように思う。

 

「何にでも強い興味を持つ」

 

5歳児のように、何度も何度も「なんで?なんで?」と聞く。

 

エンジニアは、こうでありたい。

 

アメリカボストン郊外にあるテラダイン・べンソスという会社は、トヨタの開発手法(リーン製品開発)を学び、そこから、独自の開発プロセス"Knowledge Based Product Design”(知識ベース設計)を編み出し、大成功している。

 

新入社員の研修プログラムに、小さなソーラーカーモデルを設計する実習があるのだが、まず、自分たちが何を知らないかを徹底的に出すところから始めさせるのだそうだ。

 

基本に帰りたい!

 

 

儲かるアイデアをどう出すか?

新規事業のためのアイデアを集めようとすると、アイデアはたくさん出るけれども、どうも儲かりそうもないとか、事業としては成功しそうもない、ということになりがちではないでしょうか?

 

事業アイデアを考えるときに、事業を創るということを、いい製品を作ることだと思っていないでしょうか?

先端技術を使って顧客の興味を引く、いい製品を作ればお金は後からついてくると考えている人、特に技術者は多いのではないでしょうか?

 

もちろん、いい製品を生み出すことはとても重要ですが、それと事業を創り出すこととは別だと思っています。

 

事業を創り出す、ということは、”お金を動かす仕組み”を創り出すことだと私は思っています。

いい製品を利用して”お金を動かす”ということです。

そして、”お金を動かす仕組み”とは、まさにビジネスモデルということです。

 

しかし、ビジネスモデルなんて、簡単にできるものでしょうか?

すでに言われていることかもしれませんが、ビジネスモデルは、他の領域から借りてくればいいのです。

 

他の事業領域でうまく行ってるビジネスモデルを、徹底的にパクる(TTP)ことを、組織的にやることが重要だと思っています。

 

でも、パクるのも実はやり方があると思っています。

 

まず、パクるためには、他の領域のビジネスモデル、成功パターンや失敗パターンを深く理解している必要があります。社内に世の中のビジネスモデルを研究して蓄積し、すぐにそれらの情報を活用できる体制などが必要かもしれません。

簡単に言えば、ビジネスモデルの専門家です。

 

次に、そのビジネスモデルの知識を使って、実際に自社領域で一工夫してうまく活用して、付加価値の高い儲かる事業を創り出すということですが、ここにも仕掛けが必要です。

 

それは、「抽象化力」と「アナロジー力」です。

 

多くの人、特に技術者は、物事を近視眼的にしかみれない傾向があります。時に近視眼的に、時に全体を俯瞰して物事をみる、抽象度を自在に変化させながら物事を見る訓練がされていません。

 

そうすると、考え方が凝り固まって、アイデアが広がらないのです。

抽象度を変化させる力は、訓練できます。私はコンサルの仕事の中で、この方法も教えています。

 

抽象度を高くした状態で、自社製品と世の中のビジネスモデルを広く眺め、さらに「アナロジー力(類似力)」で、類似性を発見しながら、自社領域で新たなビジネスモデルを造って行く能力を、個人だけでなく、組織的につけていくと、新規事業の成功確率は大幅に上がる、ということになります。

 

 

 

開発現場の実態

f:id:kamonk:20180607053929j:plain

 

いくつかの企業の開発部門で、このスライドを見せると、多くのエンジニアが大きくうなづきます。

「思い当ることありますか?」と聞くと、

「たぶん全部当てはまるかもしれません。」と返ってきます。

「どれが一番重要な問題ですか?」と聞くと、

う~んと唸って、でも皆の答えは必ずしも一致しません。

 

これらは、現場で実際に出ている”症状”ですよね。

このひとつひとつの原因を考えて対処しようとする、なんてことをあなたの職場ではやってないでしょうか?

 

”熱がある”から解熱剤を飲む、”咳が出る”から咳止め、”下痢気味”だから下痢止め、”背中が痛む”からマッサージ、そして”寒気がする”から厚着をする。

実は、すべての症状の根本の原因が”肺炎”だったとしたら、”肺炎”に手をうたなければ解決にはならない、ということです。

 

ひとつひとつの症状を明らかにすることはとても大事なことなのですが、それぞれに対処療法をとってしまうことが問題なのです。

 

開発現場の症状も、元をただしてみると、実は根本的な原因があるはずなのです。

 

2002年ころに日本でもベストセラーになった「ザ・ゴール」という本はご存知でしょうか?いわゆるTOC(制約の理論)の考え方を小説風に教えてくれる本です。

 

組織の中で起こる問題は、全体を見ずに「部分最適」に終始してしまうことで、解決できないということを教えてくれるのですが、もっと基本的なところは、問題を起こすのはすべて人々の「行動」であって、その行動は、組織の「評価基準」によってもたらされ、評価基準は、組織の「方針」で決まってくるということを理解することが重要なのです。

 

わかりやすく言うと、誰かが悪いことをして、その結果問題が起きてるのではなく、すべての人がいいと思って(会社の方針や行動基準に従って)行動していて、その結果で問題が起きているので、問題解決は、その方針や行動基準の矛盾(対立構造)を理解しないとできないということです。

 

たとえば、いい製品を早く市場に出すというのは、どんな企業でも目指すところ(方針)になります。しかし、その大方針の達成度を評価する基準はいくつかあります。

QCD(品質、コスト、納期)必達!なんて言葉を開発現場では良く耳にします。しかし、3つの基準を本当に平等に扱っているかというと、かなり怪しいと言わざるを得ません。

開発マネージャさんたちが評価されるのは、実は納期の優先順位が一番高いのです。それが一番目に入りやすいからです。

 

”内容を理解していない設計者にサブユニット設計を任せる”ということが、例えば、設計の後戻りを発生させるひとつの「行動」だとすると、その行動をとる優先度の高い目的は、納期を守る、ということになります。

 

それに対して、品質を最重要とする、という評価基準を第一優先にすると、本来は、”内容を知らない設計者にサブユニット設計を任せない”ということにならなければなりません。

 

つまり、ここに組織の対立構造(ジレンマ)があって、しかも、このこと自体を簡単には責められない、ということがわかってきます。

 

そうなのです。

この組織内の対立構造をすべて明らかにして、全体をみて、部分最適でない対応をするために、トップダウンで実態に当たらなければ、いつまでも同じようなところを行ったり来たりという状態になってしまうのです。