マネジメントの成熟はこれから
さて，このように機能の増大が爆発的に進んだからには，開発の体制をもう一度見直す必要がある。ただし，ここ5年間の規模の増大があまりに急激であったため，正直，ソフトウエア開発のマネジメントそのものは，当社も含めて業界全体で十分こなれているとはいえない状況である。
この記事は，「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。詳細はこちら。
そういう状況だと何が起こるか。とにかく何とか発注者である通信事業者の要求に応えようとするから，結局，いろいろなところに無理が出る。マネジメントそのものが，ともすると実態に追い付かないという事態が発生する。そうはいっても，事業者自身も非常に厳しい競争にさらされているため，やはり出荷ギリギリのタイミングまでいろいろと要望が出てくる。我々はこれをネガティブにとらえるべきではないと思っている。それだけモノづくりは厳しいのだということの表れだと認識している。
では開発現場では，どう対処しているか。まず第一に考えるのが，開発効率の向上や低コスト化だ。ブラウザやメーラー，Java，AV機能などで規模が指数関数的に増大している中，開発コストの低減で乗り切ろうというわけだ。この「低コストで開発できる」というのは，非常に聞こえがいいため，実は危険である。すると現場で何が起きるかというと，「じゃあ安いところで作ればいい」という議論になる。もしくは，トップ層から「年率何％，開発スピードを向上するのだ？」と問われ，「分かりました。10％向上させます」と苦し紛れに開発現場が答えてしまう。しかし，年率10％の効率向上を10年間続けたらどうなるか。0.9の10乗といったら，とんでもない開発スピードになる。そんな向上は現実にはあり得ない。
従って，根本的に何かを変えないといけない。単に現場の開発速度が速くなればいいとか，安いところでやればいいというような発想では，実は今のソフトウエア開発の窮状を脱することはできない。問題の解決にならないのである。
まずはバグの原因分析と分類から
そこでまず何よりも解決しないといけないのは，バグである。ソフトウエアの品質というのは，このバグの数で決まるから，まずはこの問題の芽をきっちり分析する必要がある。バグの原因は非常に多種多様である（図3）。携帯電話機の新機種が発売されると，私のところには1日に数回，市場品質レポートというのがメールで来るようになっているのだが，これはもう，毎日，ドキドキしながら見ている。
図3 欠陥（バグ）の分類
バグの種類というのは多種多様である。主な種類を分類した。
バグの種類を分析すると，まず多いのは，そもそも事業者からの要望に応えられていないというものだ。ただし，事業者からすると，バグなのか仕様なのかあまり判別がつかない。例えば，操作性が悪いとか，性能が悪いということだ。これ自体が実は品質の欠陥である。この手の欠陥は，非常に厳しいおしかりを受ける。
それから仕様通りに動作しないというバグ。一番応えるのは，やはり上流工程で設計を誤ってしまった場合である。よくあるのが，要求仕様があいまいというものだ。例えば，ある新機種に新しいコンポーネントを組み入れようとする。実は，その新しい機能は，他のアプリケーションとの連携が10個あるのだが，どのように連携するのかが仕様には明確に書かれていないといったものだ。
昔の例でいうと，データ・フォルダだ。データ・フォルダは，本来，いろいろなアプリケーションから使えないといけないわけだが，仕様には「関連アプリケーションとの関係」と1行しか書いていなかったとする。こういうとき何が起こるかというと，現場はそれを勝手に解釈してしまう。「まぁ，いいや。関連アプリケーションか。じゃ，住所録と電話帳くらいかな」となる。実際には，ブラウザあたりから呼び出しがあったりして「あぁ，忘れていた」となる。こういうことはよく発生する。従って，要求仕様書というのは，非常にキッチリと考え抜いた上で書かないといけない。開発を始めて，コーディングに着手し，テストをやったころに，仕様のミスが分かったときが一番大変だ。手戻りがとんでもない量になる。上流工程をしっかり詰めるというのは重要なことである。
アルゴリズムの設計ミスも，件数は少ないもののいざ発生すると非常に応えるたぐいのバグである。これをやってしまうと，何よりも所望の性能が出ない。性能が出ないということは，下手をすると製品にならない，出荷できないかもしれない。商品として使い物にならない。従って，本当に注意しないと危険である。かなり優秀な人材を充てておく必要があるだろう。
それからインタフェースの設計ミスである。これは新機能を搭載したときに，一番よく発生する。当社もインタフェースを決める際，まずは決めたものは変えさせないというポリシーを採っている。インタフェースの取り決めは，担当者同士でやりとりして全体設計の中に落とし込むというふうに行っているが，これが意外と漏れてしまうものだ。
次に，コーディングの誤り，つまり実装段階の誤りである。開発量が極端に増えているため，当社では設計書の読み方が分からないということがある。設計書を書いた設計者自身が悪いこともあるし，それを読む側に問題があるときもある。人材の教育に問題の要因があるという面もあるだろう。あまり頻繁にバグを出す人がいると，やはり何か別の仕事をしてもらわないと，と思うこともある。ただし，これをすぐに実行してはいけない。本人自らが「やはり自分は向いていないのか」と思うくらいまで付き合う必要がある。あまり厳しいペナルティを科すと，今後は現場が疲弊してしまう。
さらに，開発環境の不具合というのもある。例えば，コンパイラのバグや，ハードウエアのバグもある。我々も携帯電話機にLinuxを適用する過程で，いくつか気付いたものだ。
環境という意味では，ソース・コードの登録ミスというのもある。考えられないかもしれないが，実際，起きている。例えば，あるモジュールのバージョンを上げたとする。その後，1通のメールが各開発担当者に入る。「4月1日から，Xに関連するソース・コードの登録場所をこれこれに変更して下さい」という内容だ。このメールが3月20日くらいに届く。ソース・コードの登録場所は変わった。しかし，それは4月1日からのことである。3月20日に連絡を受けたのでは，忘れてしまう。開発者からすれば，まだ先のことだ，と思うし，連日徹夜しているから忙しいさなかであり，いざ4月1日になったときにはメールのことを忘れてしまうのである。そうすると何が起きるか。プログラムをリンクしたときに，全然違うものにリンクしてしまう。とんでもないビルドができてしまう。こうした管理の徹底は着実に行う必要があるが，なかなか容易なことではない。（つづく）
