黒柴の来歴　その４

ようやく通信系のシステム開発に参画する

金融系のシステムは半年くらいで終了して、その後いくつかのプロジェクトにサポート的に参画した後、通信機器の開発プロジェクトにアサインされた
このシステムは大手通信会社が持つ基幹的な複数の通信網を相互に交換する通信プロトコルの変換システムであった

専用ハードで全体的な管理は専用の制御システム上に構築されており、開発言語はCで、一部が8086アセンブラだった
配属のときに書いたように、自分は通信系のシステム開発を行う部署に配属されたのだが、このプロジェクトでようやく通信制御の初歩である状態管理プログラムを学んだ
この状態制御の考え方は、その後もいろいろと活かせているのだが、自分と同じように通信制御をやったことがない人（特に情報管理など明確な状態制御が不要なシステム開発ばかりやってきた人）には、なかなか理解してもらえない
教育用の資料なども作っては見るが、それが活用できるプロジェクトも頻繁にはないので、教育するような機会もない
設計の考え方など、埋もれさせるにはもったいないと考えているのだが、誰にも引き継げないまま、自分のエンジニアとしての終わりが見えてしまった

テストの状況を管理する？

設計、製造と進んで、単体テストに着手し始めた
このとき、メーカーのエンジニア（この人がいわゆるプロジェクトリーダーで開発のマネジメントを担当していた）が、単体テストの管理をするために、収束曲線を作成するように指示してきた

収束曲線については、以下のリンクにある説明が分かりやすかったので、引用しておく

https://monoist.itmedia.co.jp/mn/articles/1001/18/news128.html

ITMedia

プロジェクトリーダーは、単体テストごとにテスト項目の実施見込みと実施結果、バグの検出見込みと検出結果について、収束曲線を作成するように指示してきた
テスト項目やバグの検出見込み数については、メーカーが提供する指標値（KStepあたり何件というやつ）を元に算出して、それを適当に実施予定日付でグラフ化した

しかし、単体テスト、しかも関数ごとにこれを作るという指示である
関数のステップ数によっては、テスト項目数、バグの検出見込みともに一桁で、作業期間として準備を合わせても1日で完了してしまうものもある
その中で、どうやって収束曲線を作ればよいというのだろう

結果的には、1日で完了したテストを3～4日かけてやったようにグラフを書いて、一応完了とした
こういう「捏造」は、指標値を示されたバグを検出数にもあった
簡単な関数でも、指標値から１件以上のバグの検出が必要となったりする
検出されないと、品質確認会議のようなところで指摘対象となるので、不具合の検出をでっち上げたりもした
そのようなこともあり、ようやくテスト作業の管理方式を一つ学んだが、自分としては、納得いかないものが残った