これまでのBLOGを読んでこられたなら私の仕事人生、楽しいことばかりなように思われるかもしれない。楽しいこともありましたが沢山失敗を積み重ねてきています。失敗談を人生経験であるかのように書いてきていますがこれから数回にわけて実際の失敗談を書いていこうと思います。
動機はというと、以前Telsa創業者のElon Muskさんのインタビューを読みました。彼は今でも採用面接に関わるそうです。彼が一番最後になるそうですが決まってする質問は”これまでの仕事で一番大変だった失敗談”。彼はその候補者が実際の当事者なのか、周辺にいただけなのかを見分けることができるそうです。周辺で見ていただけの傍観者はTeslaには不要だとか。つまり実経験者が欲しいということですね。実経験については何度もこのBLOGでも書いているので考えを共有します。
私？立派に面接で経験を話せますが彼の下では働きたくはない。。。優れたビジョナリーですが人間としての性格はかなり難癖がある方です。Steve Jobsと並び称させるほどに。
最初の話題は私が日系のUS法人でその会社が社内で使うシリコンの開発責任者をしていたころの話です。チップとファームウエアを開発するチームの責任者兼プロジェクトリーダー（日本だと通常課長職）についていました
非常に複雑なSoCで開発は難航したのです。25年も前のことで開発ツールなどもまだまだ途上段階でした。実機を使わないと最終的な検証ができないような複雑な設計でシリコンバレーの優秀なエンジニアを雇って。。。というプランで始めたようです（私は後からマネージャとして現地で採用された）。
クリスマス商戦に間に合わせる必要がありどうしても見切発車でシリコンの量産を始めました。量産にGOをかけた後も引き続き実機でチップとファームウエアの検証は続けていたのです。テストチップはもう作っていたのでチップの納品はすぐ始まり組み立て工場で最終製品（家電品）のアセンブリが始まりました。ファームウエアは最後にFlashメモリを焼くだけなのでアセンブリの終わった機器をいったん箱にいれて最終ソフトのリリースを待つだけにしておくのです。時間は刻刻と過ぎるのです。海外に発送するためにはある日時出向の貨物船にコンテナをロードする必要があります。
そんな状況下、アセンブリ工場から10に1程度の割合で不具合がでると報告がありました。当初、暫定ファームウエアに不具合があるのではないかとソフトエアエンジニアにデバッグをさせましたが何をやってもその不具合がよくなりません。そこでハードウエア（チップ設計）のエンジニアも入れて検討を始めました。最終的にチップ自体に小さなバグを発見。しかもそれは同期回路の設計ミス。同期は確率の問題になりますから常に不具合になるわけではないのです。とても厄介なバグですね。デザインレビューなどで何度も確認をする箇所なのですがそれでも不具合がでた。
チップのバグは、量産に入っていると皆をパニックにします。ソフトウエアなら簡単に？パッチを当てることも可能ですがチップはハードと言うように硬直なのです。
部長辺りがもうパニックで社内の顧客側の部長、部門長、執行役員に連絡をとりただただ誤っておりました。私は子会社にいたので直接の上下関係はありませんが開発資金はすべてその部から出ていたのです。私はその上司でもない部長に連れられて顧客側の部長、部門長、執行役員出席の対策会議に出席しました。謝っている部長を後目に執行役員は私にどうするんだ？と。まだ若いころで経験を積み始めたころですからプレッシャーは大きかった。クリスマス商戦は100億円規模だから絶対に逃せない。しかし会社のブランドもあるから確率的とはいえ不具合をそのままには出来ない、というのがあちらの言い分。どうします？
提案と対策は
１．チップの量産の設計データは必要最小限の変更で済む対策を検討してホットパッチと言いますが量産を止める期間を数日程度にする。
２．既にアセンブリを終わっている機器については外付けにしたロジックでその不具合を解消するパルス信号を発生させ入力する。そのためには今あるすべての機器を再度開けて手作業でそのロジックを付ける（オートメーションではできない）。PCBの配線をカットしてチップの端子（足）もカットして空中配線になるのですがCMOSデバイスをハンダ付けするのです。家電の平均寿命が数年だからできる手立てです。安全に問題があるシステムならこんな手法はもちろん不可です。
３．作業に日数を要するので船便での出荷は不可。急遽航空便（貨物便）を手配する。
４．設計の再検証を行う
という内容ですがコストはすべてこちら持ちでこの段階で利益（社内なので外部からは見えません）はゼロになってしまいます。
これだけのことを実行しようとすると関連する部署、会社だけでも１０以上になります。
設計には不具合はつきものなのですがいざ自分が当事者になるとストレス、プレッシャーは半端ではないです。数百億のビジネスだと最初に釘をさすのは部下の立場から見ると逆効果ではないかと後年思いました。まるで”俺のビジネスをどうしてくれるんだ？”と脅しを受けたように感じるものです。
とりあえず設計の全責任は私にあったので（設計部隊のマネージャ兼プロジェクトマネージャ）飛行機の手配とPCBをカットする人員の手配は手伝ってもらいましたがその他は私の部下をなだめすかしてやり終えた。最小限の変更で済ませる方法が中々見つからず苦労しました。
しかも利益が出ないのでボーナスを出すこともできないため（バグを作っといてボーナスというのは日本的感覚では理解されない）、その後このチームはちょうどドットコムがシリコンバレーを席巻していた時期だったのであっという間に散会してしまいました。私も友人の誘いで小さなベンチャー企業に参加しました。そのベンチャー企業実は7か月で退社しています。それが次の私の失敗談になります。
何度も失敗していますが、そんな中で 信頼できる上司とは
不都合が発生したときに相談に乗ってくれ、対外的に失敗した部下を守ってくれる
そんな上司です。失敗を隠したりする必要はないです。部下は失敗もします。責められるのですが対外的にそんな部下を守れるか、は重要な要素だと思います。もちろん部下が不正、怠けたなど最大限の努力をしていなかったといった場合もありますがそれは内部事情。内部は内部で十分検証し必要な手続き等をとるのはもちろんです。しかしながら対外的に”部下の不祥事、責任”と言うのは出てこないはずなのです。対外的には”上司の責任”なのですから。
ストレスは非常に大きくなります。特に”おかね”が全面に見えてくるような状況下に置かれると。開発エンジニアはビジネスから少し外れているので良くわからないこともあります。エンジニアはスケジュールは日常接するので経験を積みますが”おかね”（予算だけではなく）にはあまり関わってきません。そこがエンジニアからマネージャに移行して最初に接する違いということもできます。お金はプレッシャーを与えます。社会にでるとお金とは常にかかわりを持つようになります。人はお金にはあまり寛容ではありません。
料理。失敗の連続。ポテトサラダを作りましたがハムを入れ忘れた。色がなく美味しそうに’見えない。
料理、失敗すると食べるのが嫌になりますが捨てるわけにもいかず頑張って全部食べています。家族の協力は得ることができません。