VMwareがBroadcomに買収される:半導体企業が?

 “謎”の半導体企業「ブロードコム」とは? ヴイエムウェア買収合意で脚光は、びっくりであった。
 仕事でSymantecのソフトを導入することになって、その時はじめて、SymantecがBroadcomに買収されていたのを知って驚いた。Broadcomは、半導体メーカーだからだ。さらに、Vmwareまで・・・。海外は、業種を越えたM&Aがあって、ちょっとびっくり。日本なら、シナジー効果がないと言われてしまいそうだ。

今さらマネージャーをやるはめになるとは

 転職してから3年になる。気持ちよく、製品開発をやってきたのだが、社長からマネージャーをやってくれと言われる。それも、開発ではない、現場寄りの仕事だ。
 経験もないし、それ以上にマネージャーなんてやりたくないのだが・・・。でも、他に人材がいないのも確かである。3年も所属すると、それなりに情もわくので、結局、了承してしまった。やれやれである。

ルネサスが閉鎖した工場を再開:そんなことができるとは・・・

 ルネサスが甲府工場を再開、300mm対応でパワー半導体の生産へというニュースには驚いた。何と2014年に閉鎖した工場を再開するのだという。
 そんなことができるとは、びっくりである。もう8年も経過しているので、たぶん、設備は全て刷新。従業員だって、転職しているだろうから、経験者がどこまで集められるかもわからないだろう。再開といっても、何が再利用できるのだろうか?

品質不正問題が体質になる原因

 前回、品質不正問題がなぜか体質になってしまう、という話を書いた。
 なぜ、体質になってしまうのだろう?
 三菱などの大企業は、新卒一括採用である。たぶん、今でも、社員の大半は新卒採用だろう。そうなると、そもそも、新卒採用の社員が品質不正問題に気づくかという疑問がある。何も知らずに入った部署でやっていることに疑問を持たないというのはよくある。
 さらに、部署を異動することでキャリアを積むエリート組以外は、同じ部署で何年も変わらないという固定的な人事も問題なのだろう。銀行などでは、不正防止のため、一般社員でも定期的に異動させる、という話があるが、メーカーではそうはいかない。
 この環境の中では、一度できた前例はそのまま踏襲することが正しいということになり、それが体質になっていくのではないだろうか?

不正は繰り返される:なぜか体質になってしまう

 三菱電機の「骨太の方針」に暗雲、変圧器でも品質不正が判明し全社調査も延長を読むと、本当に会社における不正の問題はやっかいだと感じる。特に品質不正問題は根が深い。なぜか、会社の体質になっていることが多いからだ。
 ある製品での品質不正問題が発覚する。そうすると大抵の場合、他の製品でも品質不正を続けている場合が多い。たぶん、長年、続けている間に、その会社では、その仕事のやり方が、会社の標準になってしまっているのだろう。

人のコードを見る:参考になる

 事情があって、同僚のC言語ソフトのデバックを手伝うことになった。経験の浅い担当者のデバッグを手伝うことは、よくあることだが、今回はかなりのベテランである。いろいろと参考になる書き方があった。とくに、continueは使ったことがないので、なるほど、こう使うのかと参考になった。

境界値テストの重要性

 前回、Firefoxほどのソフトウエアが大文字ー小文字という昔からあるバグでハングアップしたという話を書いた。
 先日、ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方という本を読んでいたのだが、最も重要な開発者テストは、境界値テストだと書いてあった。これって、昔からある話ではないか・・・。アジャイルなんて用語が全くなかった時代から、境界値テストはやっていた。時にループで間違いやすいからだ。
 結局、開発手法は変わっても、昔からある典型的なバグは残り、昔から有効だったテストは今も有効なのだろう。
 プログラミングの基本は変わらない、ということかな。進歩はしているのだろうが。

昔からあるバグは、やっぱり今でもある

 変なブログの表題だが、Firefoxのハングアップ障害、悪いのはグーグル?それとも「例の問題」かという記事を読んだ時の素直な感応だ。
 Firefoxがハングアップした原因が、ヘッダーをContent-Lengthという文字列でのみ判定し、実際の通信でcontent-lengthというヘッダがっきた時に正しく判定できなかったことにある、という。大文字、小文字の問題とか、デリミタがスペースだったりタブだったりする問題とか、文字列がらみのバグの典型のようなバグである。
 こんな昔からあるバグをFirefoxほどのソフトウエアが見逃していたというのは、少しびっくりである。いくら言語や開発環境が進歩しても、本質的にバグになりやすい部分は変わらないのだろうなあ、と思った。

久しぶりの在宅勤務:何だか孤独

 コロナの大流行を受けて、一旦なくなった在宅勤務の制度が復活した。久しぶりに在宅勤務にしたら、かなり孤独感がある。
 最初に在宅勤務を開始したときは、そんなことはなかった。通勤がなくなり、かなり集中できるので、快適であった。
 大きく2つの理由がありそうだ。1つは、仕事の内容である。私のやっているソフト開発は、アプリケーションではなく、ハードウエア寄りの部分なので、基本的には1人で開発する。その場合、集中できるので、在宅の方がやりやすい。今は、その開発が一段落ついて、他のメンバーと関わることも多い仕事になったので、仕事内容と在宅勤務とがぴったりの相性ではない。
 もう1つは、連続して出社して、居心地の良さがあったということだ。通勤はイヤだが、会社の居心地は悪くはない。転職したとはいえ、会社生活そのものは長いので、全く違和感はない。
 とはいえ、時代は、出社だけでなく在宅も並行して使うというのが流れだろう。私の通っている会社は、コロナが収束すれば在宅勤務をなくすつもりのようだが、そんなことでいいのだろうか。と思う。

利益の5割が何で決まるのか?

 新たな技術を学ぶ前に「マイことば」や「アイことば」を持とうという記事を読んでいたら、「利益の5割は仕事のとり方で決まる」という言葉に出会った。システム構築の現場では、その通りだ、と思う。
 一方、メーカーの場合、利益の5割は設計で決まるのではないか?
 自分の業界の利益構造を理解することが重要だと思う。