judの日記： 技術者は不幸せなんだけど

技術者は幸せかという難しい問いが。

まぁ、たまたま労働力が余っているからという理由で、UNIX-Cやインフラ関係のスペシャリストである俺を、携帯音楽プレーヤーの開発セクションに異動させて、その日から成果をあげることを期待するというのはおかしいと思うんだ、某社。

で、その商品は2006年6月10日に発売されたけど、これは当初GW商戦に向けて開発されていたんだよね。で、量産開始3日前の時点で、上層部には問題ナシと報告しておきながら、実は未解決のバグが260件残っていた。このときの開発リーダーの演説は今も脳裏に焼きついている。

これら問題を1週間で潰して、マレーシアの工場でPC接続でファームウェアを手作業による上書きで更新すれば、発売には間に合います。皆さん頑張りましょう。

まぁ、現実は厳しかったってことだよな。

上層部

[vn (10720)]

3日前にそんな報告を受けてしまう上層部は、ある意味では気の毒。
でもそんな報告をさせる企業体質を作った責任は誰にあるんだろう?
そんなことを思いました。

Re:上層部

[jud (15801)]

商品寿命が短くなってサイクルも短くなり、
イチ事業部が恒常的にどこかに遅れを抱えているうちに、
それに慣れちゃっただけだと思うんだ。

もちろん、それだけじゃないとは思うけど。
コンピュータ業界特有の、バグはあって当たり前という
悪しき風潮も少なからず。

上書きで更新 / Judge Point

[espy (3615)]

昔は組み込みソフトウェアは、マスクROMに書き込まれていたので、
量産開始時はバグfixされていなければなりませんでした。

フラッシュメモリの発達によって、「とりあえず生産開始しちゃえ。出荷前に書き換えればいいし」
という判断がまかり通りやすい状況になってますね。
(最悪、Webでアップデート出せば‥‥という甘さにまで)

逆に、「バグ500件」と聞かされて、あと○日でなんとか減らせると判断するか、
これはまずい、工程を延ばそうと判断するのかが偉いヒトの役割で。

バグのランク付け・点数化や、工程を次へ進めるチェックポイントでその点数にしきい値を設けるなど
組織的にルール化することで判断を誤らないようにしているのが昨今の会社だと思いますが、
部署によっては偉いヒトのヤマカンや根性論でうやむやにされている例もチラホラ．．．

Re:上書きで更新 / Judge Point

[jud (15801)]

この製品開発では、バグにはちゃんとランク付けもされてましたし、テスト専従と評価専従の部署から評価を貰ってるにもかかわらず、（現場のリーダーが）見積もりを誤っていたわけで。

今回の例だとたとえ達成できたとしても開発リーダーの甘い見積もりのせいでリスクマージンはゼロだったわけで、誰かひとり病気で休むとか、新しいバグが2～3個出てくるとか、飛行機が台風で半日欠航しただけで頓挫するような状況でした。判断もクソもあるかいや、ってな状況。そこを判断するのが偉い人なはずなんだけど、偉い人（経営的判断ができる事業部長などクラス）には正しい進捗報告が上がっていなかったらしいので責められない。

組織において、嘘つきは裏切り者に等しいと思うんだ。