はじめに

この記事は10年以上前の新卒時のやらかしを当時の記憶を思い出しながら書いているため、用語や整合性のズレ、肝心のやらかしが複数要因のどれだったか不透明なためにそれぞれの対処法を書いているなどの問題があります。
また、現場特有かもしれない開発フロー・やらかし内容を書くにあたって特定の可能性があるため、当時の関係者に配慮するための事情説明により乱筆乱文となっている事をご了承ください。

背景

10年以上前にとあるソフトウェア会社の組込み部署に新卒で入社し、携帯電話(ガラケー)開発の現場にN人の中の一人として出向していた時の話です。
新卒で現場出向する事例はあまり無いのですが、学生時代にC++とD言語でコードばっか書いてた時の作品をスキルチェックの為に見せたり、研修でのWindowsアプリやH8マイコン課題の結果から、新卒でも大丈夫だろうとの事で出向と相成りました。

現場は、そこで携帯のハードウェアからソフトウェア、出荷のライン管理まで¹すべてを行う1000人単位の人達が働く大規模な事業所で、僕はその中の電波調整チームに配属されました。
電波調整とは、読んで字の如く、電話をする際の基地局からの受信感度に応じた送信出力を調整する機能の事です。
談笑の場で出力が最大のままだと携帯が熱くなりすぎるし、脳が溶けるよ、と言われたりした事を覚えています²。

携帯電話の出荷・出荷フロー

やらかしを書くにあたり、どの工程に影響を与えたのかを把握出来るように開発・出荷フローを解説します。

最初は数台の試作機から始まります、その時の各工程はおおよそ次の通りです。
・ハードウェア: パーツの確保量に応じて従来品、他社パーツの検討、パーツの出力や抵抗値の変化への回路図からの引き直しなどを行う。
・ソフトウェア開発: ハードウェアのパーツ変化に応じ、ソフトウェア(電波調整ソフト・ROM)側で設定値の調整、機能のON/OFFを行う。
・ライン組み: 携帯電話にソフトウェアのROM焼き、電波調整処理を行う効率的、かつコスパ・速さのバランス調整を行う。

この中で電波調整チームが関係するのは、全部です。
新機種の開発が決まると、ハードウェア屋さんにパーツで使う機能、調整値を確認し、それに応じた電波調整ソフトの修正、ROM側のロジックの修正を行い、リリース日程を確認し、どのくらいに試作機製造にとりかかれるかの日程を試算し、ライン工程に日程の連絡を行う、
というのを、まあ5、6機種以上は並行して進んでいました³。

どのフローでやらかした？

ここまで書くと大方予想が付きますね、はい、この本番機を製造してる最中に調整絡みの修正が必要になり、工場で稼働していた数日分の作業が無に帰しました。
金額は覚えていないのですが、なにせ数万台の製造が必要なので、そこで働くプロパーの方、ライン作業をしている作業員の方、その他関係者方々の人数も少なくないかと思います、その方たちの数日分の働きが、無意味なものとなったわけです。

なぜやらかした？

上記の開発・出荷フローを見れば、試作3まででソフトウェア側も仕様が確立している為ありえない事ではありますが、当時は大きなパラダイムシフトの過渡期でもありました。

新たな調整システムFDT(Fast Device Tune)の到来

電波調整というものは何かと時間がかかるもので、かつ調整時間の短縮がモロにコストにも影響を与えるものでした。
そりゃあ工場で携帯電話にROMを焼き、シールドに入れて電波調整ソフトを走らせ、調整値を書き込む、という作業を作業員が数百(数千？)人規模で、何年・何十年も行っているわけですから、電波調整処理が1秒縮むと数百万、数千万の費用が浮く、と言われた事があります。

そんな中でQualcommが新たな調整システムを提案してきたわけです。
今までの電波調整処理は

1. テスターと携帯電話を繋ぐ
2. チャンネルを1に設定(この時、携帯電話側とテスター側の両方にチャンネル1切り替え処理を発行し、完了を待つ)
3. テスターから電波を受信し、その時の出力値が適正となる調整値がどの程度か計測しながら調整する
4. 3.で得た調整値を書き込む
5. 全12チャンネル(確か12だったはず)分、2. 3. 4.を繰り返す

てな事をやっていたわけですから、テスターへのリクエスト・レスポンスの待機時間がかなりの時間を占めてしました。
これがFDTになると

1. FDT対応テスターと携帯電話を繋ぐ
2. FDT処理を走らせる(内部で携帯電話とテスターのチャンネル切り替えが謎の技術で同期して、各チャンネルの調整値が求められる)
3. 2.で得た調整値を書き込む

で済むわけですから、もうめちゃんこ、めっちゃんこ速くなったわけです。
なので是非導入したい、ってなった時に電波調整側の開発を(コードを書くのだけは得意な)僕が担当する事になりました。

なにをやらかした？

FDTの実装は、電波調整アプリ側とROMロジック側の両方に行ったのですが、なにせ従来の開発も並行して行っていたため、わりといっぱいいっぱいになり⁴、FDT調整にバグを残したのと、従来の調整機能洗い出しにミスがあったのを残したままとなってしまいました。

やらかしの原因と対処

上記2つのどちらかがやらかしの原因なのですが、なにせ10年以上前の記憶でどちらが原因だったかを覚えていないため、それぞれの対処方を記載します。

FDT調整のバグについて

こちらですが、調整処理を走らせる際に内部ではチャンネル毎の調整値を配列内データとして確保していたのですが、取捨選択の際に0番目のデータを捨て配列データをずらす、という処理をしており、その際にmemcpy関数を使用しました、C言語の経験がある方はこの時点でまずいと分かるのですが、当時は気付かずにいたために発覚が遅れ、後日の修正となってしまいました。
なお、これは大企業あるあるなのですが、調整値周りがおかしいと報告を受けて、memcpy周りがおかしいと気づき、memmoveに書き直すのが5分で、そこから動作検証の為にROMのリビルドが2時間⁵、検証に1時間、再発防止案の提出が必要で、原因に「同配列でmemcpyを使っていた」、防止案に「GNUドキュメントをちゃんと読む」と書いて上司に確認してもらい、プロパーに提出し、ハンコを貰って完了するまでで丸々1日かかりました。

調整機能洗い出しのミスについて

こちらは僕はその場しのぎの対応しか出来ませんでした、ハードウェア屋さんとの洗い出し時にチェックリストを作ってしっかりやる、という稚拙な事しか出来ていません。
それよりも別会社の現場先輩が機能のON/OFF、設定値をヘッダーファイルにまとめ、それと内容が同期したExcelファイルを用意してハードウェア担当に提出し、回答してもらった内容をコピペで済ませて責任の所在が調整チームに集中していた当時の問題を解決する、という取り組みを行って見事達成した事を評価したいです。

本番環境なのにソフトウェアバグ、もしくは仕様ミスが残っていたことについて

形式上の責任はハンコを押したプロパーとなるのですが、根本の原因としては海外機種という事もあり試作を何段階か飛ばしても問題無かった事(飛ばすとそれだけコストが浮く)、FDT調整への過渡期でスケジュールが割とひっ迫しており、色々前倒しとなってしまった事にあるかと思います。

バグ発生時期と影響範囲の関係図がありますが、このやらかしはその最大級を引き起こしてしまったものだと改めて思いなおしました。
大企業病という言葉がありますが、リスクヘッジを考えるとしょうがないかなという気がする場合もあります、バグの発生によって数百、数千への影響が考えられるなら、そのバグを発生させないために慎重になるのは当然です、リコール問題まで発展する時期にやらかしたら目も当てられないですからね。