You can read this blog in any language using google translate as follows:

Goto http://translate.google.com/
Paste URL in the box and select "Japanese for From Language" and "To Language". Then click "Translate".

English translated pages are here:
http://bit.ly/xPuXoy

你可以閱讀這個博客,在任何使用“Google”的語言翻譯

本ブログのアクセス統計: 50万アクセスを達成しました。ご訪問ありがとうございました。

50万アクセスまでの経過

2009年12月に始めた本blog。2011年7月ごろに10万アクセスを達成し、2011年12月13日には15万アクセスを達成。
その後、私も更新しておらず、アクセスは少し減りましたが、3月1日には18万アクセス。2012/4/18に20万アクセス、2012/8/21に25万アクセス、2013/1/18に30万アクセス、2013/12/17に40万アクセスを達成しました。しばらく見ていなかったら、2015/5/1に50万2584アクセスになっていました。

2012年9月6日木曜日

ピーターの法則

http://nkbp.jp/OVudIM には、
マネジャーになればエンジニア出身といえどもマネジメント能力がいやおうなしに求められます。これまで技術一辺倒でキャリアを形成してきたエンジニアにとって、マネジメントは「違う仕事」と言っても過言ではありません。

マネジメントに必要なスキルは「コミュニケーション」や「意思決定力」「交渉力」「判断力」などが代表的ですが、エンジニアが“慣れている”とは言 い難いのが現実です。これらに加え、他の専門技術部門との調整や部門内の効率化などもエンジニアのマネジャーには要求されます。

最初からマネジメント能力が備わった”スーパー”エンジニアは極めてまれで、OJTや研修を通じてその資質を体得していくケースがほとんどです。本講座では、エンジニア出身の新任マネジャーが身に着けるべきスキルを、わかりやすく噛み砕いて伝授し、さらに技術者のチームマネジメントに特有なスキルも加えて体系的に学んでいただくカリキュラムです。
本講座を活用いただき、“慣れない”マネジメントに前向きに取り組んでいただけることを願っています。
と言う講座が紹介されています。

なぜ、エンジニアをマネージャにすることが前提なのでしょうか。マネージャをやりたい人は最初からマネージャ。別の職制ととらえることができなければ、ピータの法則(以下に列挙。これは世界共通の悩みらしいのです) http://bit.ly/OaLYsG から逃れられないと思います。
  1. 能力主義の階層社会に於いて、人間は能力の極限まで出世する。すると有能な平(ひら)構成員も無能な中間管理職になる。
  2. 時が経つに連れて人間は悉く出世していく。無能な平構成員はそのまま平構成員の地位に落ち着き、有能な平構成員は無能な中間管理職の地位に落ち着く。その結果、各階層は無能な人間で埋め尽くされる。
  3. その組織の仕事は、まだ出世の余地のある、無能レベルに達していない人間によって遂行される。
以上は、以下のblogにもまとめてあります。

2012年5月27日日曜日: 米国のマネージャ

さらにヒドいことには、「年功」ではなく「年齢」と「入社時学歴」で一律に出世させる「年齢序列」があるので、どうも能力がマイナスになっても出世している人がいるようで、ピータの法則よりも悪いことになっているように思います。

技術が分からないとマネージャは勤まらないのか)
これは問題ないと思います。

2012年7月8日日曜日: トップダウンと権限委譲

に書いたように、トップマネージャは、細かい技術を支持する必要はなく、戦略を示せばよいのでしょう。

さらにマネージメントには、
  1. 技術が分かること
  2. マネージメント(人の育成、モチベート、問題の把握と組織作り)がわかること
  3. ビジネス(お客の心、儲け方、競業の潰し方、お金の集め方) がわかること
のそれぞれに価値があると思います。
ところが、技術者出身の人ばかりで固めると、これがあまりに偏るように思います。
さらには、最近のように技術進歩が激しく、また、新しい技術が続々登場してくると、相当勉強しないと最新技術の勘所は分からなくなります。

顕著なのは、以下のように技術も破壊的に変化しています。
  1. ハードウェアそれも、LSIではなくトランジスタなど個別部品の組み立ての時代から、FPGAやソフトウェアの時代へ変化し
  2. さらに、ASICはどれもほとんど同じで寡占がすすみ、ソフトが主体の端末と、Cloudが、高速な無線・有線網で連携するの時代に変化した 
  3. 今後も大きなトレンドの変化が予想される。高速・低遅延通信(有線、無線) やストレージ。不揮発ストレージなど。。
  4. 製品が高価高品質の時代の人が価格破壊の時代に変化した
  5. 国内の類似メーカの競争の時代から、価値観も全然違う国際市場で、国際競争の時代に変化した
変化に対応できないと、企業が没落していくのは以下に書きました。
2012年9月6日木曜日:家電と自動車の違い
責任分担が必要)
Apple、Intel、Samsungでは技術者は、ある種奴隷のように言われた仕様のものを命をかけて作る。もちろん、お互いにリスペクトしているので誇張した言い方でしょう。
社では、商売をすること、すなわちマーケッティングが一番偉いとも聞きました。

こうやって、責任分担をすることで、エンジニアは技術開発に専念できます。つまり、
  • マネージャ: 業務遂行環境の整備すなわち、予算管理:、人材確保、予算確保、スケジュール管理、モチベーション維持のための施策(宴会、ランチ、完成打ち上げ、完成記念品)
  • マーケッティング:製品仕様の決定: 市場調査、技術動向調査
  • 設計エンジニア:製品の設計、ソフトウェアの場合にはコーディングとデバッグ
  • 製造エンジニア;製造工程の管理
こうすることで、仕様どおりの製品が設計できなければ設計エンジニアの責任、製造できなければ製造エンジニアの責任。仕様通りに作っても売れなければ、マーケッティングの責任。作業環境が悪ければマネージャの責任。と、責任分担がはっきりします。失敗したときにも、余計な部門まで、責任を取らされず、有能な人材のモチベーションを下げることがなくなります。

そうやっている一方で、人事部が存在し採用は人事部がやったり、経理システムがあって、予算は人件費、資材費、設備費などと、最初から費目に別れてしまい、融通が利かなく成っていたりします。税法上は融通できるはずなので、マネージメントの手間を減らし、だれでもできて、ミスを減らす工夫なのでしょうが、事業運営に支障をもたらしていると思います。

米国は、大学でも企業でも、掃除は掃除専用の人、給仕は給仕専用の人にまかせます。小学校からそうです。企業でパーティをやってどんなにちらかしても、掃除の人の仕事だと任せて自分では片付けないことが多いです。「自分のコトは自分でやりましょう」と、小学生に掃除をさせるのは日本の美徳です。が、これを企業経営にまで持ち込むのは、責任分担の不明確化を招くと思います。

Intelでの例)
Intelのx86コアが、 同じチップをボンディングオプションで、一個5,000円足らずのCeleronにしたり、2万円ちかいPentiumに切り分けているのは、よく知られた話しです。

これを技術者がやると、どうなるのでしょうか、安いCeleronはそれなりに安く作り込もうとします。ところが、設備産業であるLSI産業では、大量仕入れ、大量生産をして、大量に売って、速く設備投資を回収した方が儲かります。
実は、原材料費は、設備投資額や設計や研究開発コストに比べればしれているので、多少チップ面積をけちってもしょうがないのです。これは、プロセスが微細化すればするほど、同じ原材料費や人件費あたりにとれるチップ数が増えるので、どんどん顕著になります。

ビジネス的には、これをいち早くみぬいて、すこしでも設計を共通化して、一気に投資回収をしたほうが勝ちになります。

つまり、技術者の意見よりは、ビジネス的な見方のほうが重要になるわけなのです。

Intelがいち早く導入した、Copy exactly生産ラインも同じです。技術者や職人的には、個々の工場で、なるべく良品率を上げるように頑張りたくなります。
 日本のメーカはそうやって進化してきたので、全国に沢山ある工場の製造装置のチューニングが少しずつ違い製造パラメータが少しずつ違いました。しかしこれは大変なデメリットになります。以下に列挙すると。。
  1.  次の世代の微細化プロセスを開発すると、工場毎にそれを会わせ混まないとならず。直ぐに生産が立ち上がらない。技術者を何度も派遣しないとならないし、一番値段が高く売れる立ち上げ時期の生産が遅れる。
  2. ある工場で作った製品は、その工場で最後まで完成させないとならない。ところが、全工場が同じ仕様で動けば、
    1. 生産量を増やしたいときには別な工場で作れる。つまり
      1. 需要供給のバランスの変化に柔軟に対応できる
      2. ある工場が障害で停まったときには、続きを他の工場で作れる
 などの差がでてきます。プロセス技術開発の技術者というよりも、ビジネスとか生産者の視点が必要になると思います。



blog comments powered by Disqus