【仕事の記憶】（８）アナログからデジタルへ

の続き。

デジタル端末開発を引き継ぐ

首都圏事業所の開発部門で新デジタル方式（CDMA）端末の開発を始めるため、現行デジタル方式端末の開発を自部門で引き継ぐことになった。
従い、アナログ方式端末の新機種開発は打ち止めとなるとのこと。
（結局、自分はアナログ端末のコードはほとんど弄らずじまい。）

ベースとなるコードがあるとはいえ、いきなり「ハイ新機種開発よろしく」とはいかないので、首都圏事業所の開発部門に半年ほど長期出張して、修行・引き継ぎすることになる。
それ以前にも、ちょこちょこと手伝いをしていたので、皆さん顔見知り。
まだ二十代半ばの若輩者だったし「２４時間働ける元気もの」でハキハキ（今とは真逆）していたので、自分より年長の首都圏開発メンバには何かと可愛がってもらっていたと思う。多分。

引き継ぎ当時のデジタル方式端末のハードウェア諸元、システムの特徴は以下のような感じだった。

• 通信方式：デジタルPDC方式（ARIB STD-27B TDMA π/4DQPSK変調）

• CPU：F2MC-16

• OS：RTOS（μITROM3.x）

• プログラミング言語：C言語、部分的にアセンブラ。

• ユーザーインターフェース：ドットのキャラクタ液晶など。

• 外部インターフェース：シリアルポートなど。

通信方式以外は、見た目・機能的にアナログ端末とほとんど違いがない。

自分の担当は、無線通信プロトコルスタックの最下層（レイヤ１）。
搬送波に変調された情報のデジタル化、音声データのデジタル符号・複合を行うDSPの制御、待ち受け・通話周波数への切り替え、受送信タイミングの制御など、一口に説明できない。

RTOS（μITRON）を実装し、基本C言語でコーディングとなっている。
自分の担当部分は、直ハードウェア制御や最も処理時間制約が厳しい箇所なので、一部アセンブラで実装される。

もともと正式な設計書のようなものがなく、コードから仕様や設計内容をリバースエンジニアリングするしかない。
ARIBの仕様書、DSPの制御マニュアル（フル英語...）などを読み込み、記載されている内容をどのように実現しているか確認し、設計ドキュメントを起こす。
TDMAという通信方式は受信・送信タイミングを数十msで細かく制御する必要がある。
どのタイミングで入力・割込みが発生し、制御する必要があるのか、待ち受けや通話中などの状態別のタイミングチャートも作成する。
作成したドキュメントは、元コードの設計・プログラミングしたエンジニア（師匠）にピアレビューを受けて、間違いがあれば矯正する。
引き継ぎ作業だけしているわけではなく、試験なども手伝い、測定器や基地局シミュレータや試験手法なども学習する。

なんとか、長期出張期間に概ね担当部分のコードや作業全般を把握したと師匠にお墨付きをもらえた。
新機種開発に単独で対応できるようになって帰郷した。

職人化してしまえば落ち着いて仕事ができる

この時期以降の各メーカーの開発競争はすさまじい。特にディスプレイの表現能力やリンガー（呼び出し音）の高度化がすごい。
表現能力の向上により、ファンクションキー＋数字の機能呼び出しが、メニュー表示＋上下左右キーに変わり、入力できる文字の種類も爆増する。
呼び出し音は、音階指定で作曲できるようになったかと思えば、すぐさまMIDI音源チップが入り本格的なシンセ音が流せるようになる。
アプリケーションの仕様は複雑になり、開発人員もコードも肥大化していくばかり。自社人員では賄いきれず、協力会社殿に依頼することも多くなった。

一方、自分の担当部分はというと。
通信プロトコルやハードの詳細な仕様把握が必要で、作業内容が特殊な属人・職人的な箇所である。

通信仕様は更新されるし、新機種が出るたびにハードウェアもDSPも刷新される。都度、自分の担当部分も修正しなければならない。
また、800M・1.5GHzと対応周波数帯の違いでも制御が異なるので、同じ見た目でもリリース先の通信事業者が異なればコードも違うものになる。
通信プロトコルのレイヤ１部分だけではなく、RTOSを独自に機能拡張したり、アプリ向けのハードウェア制御ドライバも一部担当していたので、それらも新機種毎に修正したり新規に作ったりする。
それなりに高い品質を求められ、難易度も高く、プレッシャー・ストレスもかかる部分でもあった。

• 不具合を出せば、電話としての最も大事な機能に影響し、製品として致命傷になる。（最悪リコールになる）

• 通信プロトコルやハードウェア制御上の不具合は、ごく稀にしか発生せず、再現が難しいことが少なくない。
  （まる一日ハンドオーバーを繰り返し１度しか発生しない。といったものもあった）
  結局、机上で仕様確認やコードトレースし不具合発生の可能性のある状況を洗い出し、1つ1つ確認する作業となることが多い。
  試験環境でその状況を作り出すこと自体、難易度が高い。

• ハードウェアの不具合であれば、まずソフトウェア側の制御内容に問題がないことを確認・証明の上、動作異常となる手順や現象のエビデンスを測定器などで取得しなければハードウェア担当殿への調査の依頼ができない。

• 技術適合認定を受ける試験までに通話可能なレベルまで作りこみ・動作確認を完了しなければならず時間的制約が厳しい。
  マイルストーンをヒットできない場合、製品開発全体スケジュールへのダメージが極めて大きい。

とは言いつつも、アプリケーション部分に比べれば変更量は少なく、落ち着いた仕事ができるところでもあった。