「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより（発行日順）のページへ
 ソフテックだより技術レポート（技術分野別）のページへ
 ソフテックだより現場の声（シーン別）のページへ

ソフテックだより第１６２号（2012年5月23日発行）
現場の声編

「マイコン用ソフトウェア開発での失敗談～処理速度が間に合わない！～」

1. はじめに

私は、ソフテックに入社して18年目を迎えます。主にマイコン用ソフトウェア開発を行ってきました。

マイコン用ソフトウェア開発で十分に気をつけなければならない点として、大きくはROM容量、RAM容量、処理速度の3点があげられますが、実は、これまでに私は3点それぞれで失敗した経験があります。

今回のソフテックだよりでは、私が入社5年目の時に、処理速度が間に合わない問題を起こしたことについて書きたいと思います。問題解決のために、先輩社員が最初からソフトウェアを作り直すことになってしまったという、非常に大きな失敗でした。

私は、入社5年目までに表 1の開発に携わってきました。マイコン用ソフトウェア開発の一通りのことは経験したつもりでしたので、私としては自信を持って仕事ができるようになっていました。

入社	携わった開発	概要
1年目	CPU評価作業	量産を控えたマイコンCPUの評価作業評価プログラム作成およびテストを担当
2年目	大型システムの物件対応	OSを搭載した大型システムへ、物件対応の変更を行う開発
3年目	大型システムに接続される端末機器開発	端末機器はシステム内に最大500台接続される正確な処理が必要であるため、アセンブラで開発ベースとなるソフトを流用して作成
	上記端末機器をシミュレーションするシミュレータソフト開発	シミュレータだが実際の端末機器と同様に正確な処理が必要処理速度の問題が発生したが、プログラムの一部高速化を行い自力で解決
	大型システム内モジュールの開発	各種モジュールソフトを3本作成
4年目	大型システムの物件対応	2年目に行った物件対応とは別の物件対応を2件対応

表1. 入社5年目までに携わった主な開発

2. 失敗したシステムの概要

大失敗した開発の要求仕様とCPUスペックは以下の通りでした。

【システム構成】

システム構成概略図は図 1の通り。マスタ－スレーブ間を中継する位置付けのソフトウェア開発を担当。マスタは既に完成しており、スレーブは顧客が開発を担当。顧客と同時に開発が進められた。

図1. システム構成概略図

【仕様概要】

スレーブが収集した状態を通信で受け取り、それをマスタに通信する。マスタとは600bpsの通信、スレーブとは19200bpsの通信を行っている。マスタからは一定間隔で通信が行われており、マスタと通信を行っていないときにスレーブとの通信を行う仕様であるため、同時に両側と通信を行うことはない。

【CPUスペック】

CPUクロック: ：1MHz、中速モード動作前提（CPUクロック分周比8分周 ※1）
ROM容量: ：60Kバイト
RAM容量: ：2Kバイト

マイコン用ソフトウェア開発の経験者であれば、このCPUスペックと要求仕様から、処理速度に注意しなければならないことは分かると思います。しかし、当時の私は「今までやってきた開発の延長線上のような内容だから大丈夫だな」という安易な気持ちで、処理速度のことは全く頭にありませんでした。

3. 開発着手から処理速度が間に合わないと分かるまで

処理速度が間に合わないと分かるまでは表 2のような状況でした。当時の私の行動や心境も思い出してみました。

日付	状況	私の気持ち
10/19	顧客より仕様提示。CPUは明確に決まっていなかったが、暫定CPUは決まっていた。	この時は、まだ私が開発担当することは聞いていない。
11/01	見積書を提出。見積もり前提条件として、8ビット以上のCPU、C言語で開発する前提としたが、CPUクロックやROM/RAM容量の前提条件は含めていなかった。納期は1/31。社内スケジュールでは1/22完了予定。私は年明け1/11から別件で長期出張（この時点では6月まで確定）に行くことが決まっていたため、単体テスト完了までを担当して、システムテスト以降は当時顧客窓口を担当していたAさんに引き継ぐ体制となっていた。	「年明けの長期出張までに、きちんと終わらせて引き継ごう」という気持ちで開発を開始。
11/16	設計が完了。設計資料として、フローチャート、モジュール仕様、データ定義書を作成。この段階で、レビューは実施していない。	「必要十分な設計書を作成できた」と実感して、開発を進める。
11/19	暫定CPUに問題があることが分かったため、顧客からCPU変更の連絡あり。8ビットCPUでCPUクロックは1MHz、消費電力を抑えるため中速モード動作（CPUクロック分周比8分周）の前提。顧客は処理速度への懸念を示されており、C言語で開発することに問題がないか確認があったが、速度の問題が発生する部分はアセンブラと併用することで対策すると回答。	確定になったCPUのことは、ろくに調査せず、CPUクロックや動作モードも気にせず。もし、処理速度の問題が出たときは「部分的にアセンブラで書けば大丈夫だろう」という考え。
12/10	コーディングが約90%完了。別件の作業が割り込んだため、一時作業中断。	「基板到着前にここまで出来ていれば、大丈夫」という気持ちで別件作業に移る。
12/20	基板が届く。しかし別件作業が、まだ終わらず。	「遅れているが、あとは単体テストを頑張るだけだから大丈夫」という気持ちで別件作業を継続。
12/26	別件作業が完了。開発に復帰してデバッグを開始。予定より作業が遅れており、また、年明けから引き継ぎ作業を行う予定だったため、年末年始の休暇中も出社してデバッグ・単体テストを実施することに。	「年末年始の休暇中にも作業すれば遅れを取り戻せられる」と考え、作業を実施。
01/05	単体テストが約90%完了。しかし、処理速度が全く間に合わない状況であることが分かった。マスタから要求コマンドを受信して10ｍｓ以内に応答を返す仕様だが、70ｍｓ後に応答を返していた。また、19200bpsの受信割り込みは0.57ｍｓ間隔で入ってくるが、割り込み処理に2.8ｍｓを要しているため、受信データの取りこぼしが発生していた。	デバッグ・単体テストも順調に進んでいると思っていたが、休日出勤した最終日に処理速度が全く間に合っていないことが分かり、愕然とする。

表2. 処理速度が間に合わないと分かるまでの状況

4. Aさんに引き継いでから開発が完了するまで

Aさんに引き継ぎを行ったあと、開発完了までは、以下のようになりました。

日付	状況	私の気持ち
01/17	Aさんが検証した結果、中速モード動作のままでは、全ての処理をアセンブラで作り直したとしても、処理速度が間に合わないことが判明。消費電力を抑えるため、CPUクロックはあげられないことは聞いていたので、高速モード動作（CPUクロック分周比2分周）に変更できないか、顧客に相談。この時点では、私が作成したC言語のソースコードを元に高速化する検討が行われていた。	「高速モードに変更することを認めてもらえれば、なんとか今のプログラムを高速化ではいけるのではないか」と期待。
01/25	高速モード動作に変更することで顧客から了解を得た。ただし、動作モードはプログラム実行途中に切り替えられるので速度の問題が発生する部分だけ高速モード動作に切り替え、更に通信が行われていない間はスリープモードに遷移して消費電力を抑えることになった。また、引き継ぎを行ったAさんは顧客窓口に専念し、Bさん（当時の私の上司）がソフトウェア製作を担当することになった。 1/31納期の直前であったが、現実的に納期に間に合わせることができない状況と判断し、顧客に納期の延長を相談。当初、2月初旬から顧客がスレーブと接続して試験を実施する予定であったが、顧客の開発スケジュールにも遅れがあり、接続試験開始時期が延びていた。顧客が接続試験を開始する2/23までの納期延長を認めていただいた。	高速モードに変更して良いこと、納期延長を認めてもらえたことでひとまずホッとする。また、Bさんはマイコンソフト開発のスペシャリストなので、「Bさんなら何とかやってくれるだろう」という安心感・期待感が出てきた。
01/28	会社に戻る機会があり、Bさんに対して、現状のソースコードの説明を行う。	そのまま使えそうなソースコードはあったので、「なるべく使えるところは使ってもらいたい」という気持ちで説明。
02/01	Bさんが検証した結果、高速モード動作であってもC言語での記述では処理速度が間に合わないことが分かったため、全ての処理をアセンブラで作り直すことに決定。	全ての処理をアセンブラで作り直したということを数ヶ月経ってから知って、非常にショックを受けた。
02/21	2/23納期が厳しい状況であり、更に2/28へ納期を延ばしていただいた。
02/24	2/24から2泊3日の日程で、全社員参加の社員旅行が実施されたが、このような状況であったため、AさんとBさんは社員旅行への参加を取り止めた。	社員旅行の期間は出張先から帰社することができたので、社員旅行に参加することに。 AさんとBさんに対して、心苦しい思いもあったが、旅行先ではそれなりに楽しめたような…
02/27	顧客へのリリース完了。	リリース直前の状況は聞くに聞けなかったが、無事にリリースが完了したことを知ってホッとした。

表3. 引き継ぎを行ってから開発完了までの経緯

途中で、全ての処理をアセンブラで作り直すと聞いていましたが、もしかしたら自分の作成したソースコードが一部でも使われているのでは、という思いと期待がありました。しかし、出張から戻ったあとで成果物を確認してみたところ、私が作成した設計資料およびソースコードは全く残っていませんでした。
入社1～2年目の時には、一部分を先輩に作り直しされたことはありましたが、入社5年目にもなって全てのソフトウェアを作り直しされたことに非常にショックを受けたことを憶えています。「本当に全部を作り直す必要があったのか？使えるところは使えたんじゃないのか？」と、その時は納得できない気持ちもありました。しかし、今思うと中途半端に流用することで速度の問題を解決できない可能性もあるため、高速化することを徹底したBさんの判断は間違っていなかったと思います。

5. 部長2人から突然の呼び出し

長期出張中に、数日間、会社に戻る機会がありましたが、問題が発生したあとの1月21日に、部長2人（現在の取締役2人）に突然会議室に呼び出されました。部長2人と私1人という組み合わせは滅多にありませんから、今回の問題を強く叱られるんじゃないかと思いました。
実際には、そのような雰囲気は全くなく、割り込み処理時間や割り込みタイミング、処理を高速化するにはどうすれば良いのかなど、終始、技術的な内容について3時間の講義を受けました。
技術的な講義の目的もあったと思いますが、まだ問題解決の目処がたっていない時期だったので、私が作ったソフトの聞き取り調査が主目的だったのだろうと思います。講義を通じて、現状ソフトの問題点がいくつか見つかったので、私からAさんに連絡しました。

6. 失敗を経験して

失敗の原因は、仕様の要求分析、システム設計が不十分なまま開発を進めてしまったことにあります。フローチャート、モジュール仕様、データ定義書などの設計資料は作成していましたが、開発のポイントが処理速度であることを理解していなかったため、処理速度が間に合うかの検討が全く行われないまま、開発終盤で気づくことになってしまいました。その当時は、いかに汎用的なプログラムを作るかに拘っており、高速化に反する側面を持つプログラミングを行っていました。

保守性の高い汎用的なソフトウェア開発を心がける必要はありますが、時には要求仕様を満たすために保守性や汎用性を犠牲にすることもあると学びました。また、システムの背景やCPUアーキテクチャ、Cコンパイラの特性までもきちんと理解したうえで、仕様の要求分析、システム設計を行う必要があることを学びました。

この時、失敗したことや部長2人からの講義内容は、今でも思い出して、開発に役立てられています。この時の経験も含めて、高速なマイコン用ソフトウェア開発の注意点について、ソフテックだより第109号技術レポート「マイコン用ソフトウェアの高速化」で紹介しています。

最近では高速クロック、大容量のROM/RAMを搭載できるCPUが多くなり、以前に比べてリソース(※2)を気にすることが少なくなりました。しかし、まだ量産コストを抑えるためにスペックの低いCPUを使用する開発案件はあります。また、いくらスペックの高いCPUだからといって、何も考えずに開発を進めると処理速度が間に合わないという状況にもなりかねませんので、どのような条件でも、仕様の要求分析やシステム設計をしっかり行ったうえで、開発を進めるように心がけています。

（M．A．）

[注釈]

※1: CPUクロック分周：
CPU内蔵の分周器でCPUに入力されるクロックを分周（2分の1、4分の1、8分の1など）することで、消費電力を削減することができる。また、CPU内部モジュールのタイマ間隔やシリアル通信速度を調整するために分周することもある。
※2: リソース：
資源のこと。コンピュータの世界では、メモリやCPU時間までもリソースに含まれる。

「マイコン用ソフトウェア開発での失敗談 ～処理速度が間に合わない！～」