2008-03-30

組込みソフトウェアの品質について再考する

組込みソフトウェア工房(Embedded Software Manufactory)への記事投稿がちょうど今回で100回になった。我ながらよく続いていると思う。なんとか、細々とでも続けていきたいのでこれからも懲りずにお付き合いいただきたい。

さて、今回は、ソフトウェアの品質と言えば誰もが引用するISO 9126 のソフトウェアの6つの品質特性、機能性(Functionality)、信頼性(reliability)、使用性 (Usability)、効率性(Efficiency)、保守容易性(Maintainablity)、移植性(Portability)にケチを付けるところから、組込みソフトウェアの品質について再考してみたい。

【ISO9126の品質特性と副特性】

1. 機能性(functionality) - 機能とその特性に影響する特性群。
  • 合目的性(suitability)
  • 正確性(accuracy)
  • 相互運用性(interoperability)
  • 標準適合性(compliance)
  • セキュリティ(security)
2. 信頼性(reliability) - ある状況がある時間続いたときにソフトウェアがどの程度機能するかに影響する特性群。
  • 成熟性(maturity)
  • 回復性(recoverability)
  • 障害許容性(fault tolerance)
3. 使用性(usability) - 利用するのにかかる手間、個人の努力などに影響する特性群。
  • 習得性(learnability)
  • 理解性(understandability)
  • 運用性(operability)
4. 効率性(efficiency) - ソフトウェアの性能やそれに要するリソース量に影響する特性群。
  • 時間効率性(time behaviour)
  • 資源効率性(resource behaviour)
5. 保守性(maintainability) - 何らかの変更を加えるのにかかる手間に影響する特性群。
  • 安定性(stability)
  • 解析性(analyzability)
  • 変更性(changeability)
  • 試験性(testability)
6. 移植性(portability) - 別の環境にソフトウェアを移行させる可能性に影響する特性群。
  • 設置性(installability)
  • 置換性(replaceability)
  • 環境適応性(adaptability)
一見、非の打ち所がないように見えるこの6つの品質特性と副特性。これらに付けるケチとは、6つの品質特性を高めることと、顧客満足を高めることは必ずしもイコールにならないという問題だ。

『ソフトウェア品質とは何か』の 記事で書いたように品質の定義として「品質とは、顧客要求を満たし満足させる程度」というものがある。上記の6つの品質特性を高めることと、顧客要求を満たし満足させる程度である品質を高めることは組込みソフトウェア開発においてはイコールではない。

ちなみに、6つの品質特性のうち、機能性(Functionality)、信頼性(reliability)、使用性(Usability)、保守容易性(Maintainablity)、移植性(Portability)の5つを目指すということと、再利用を見越したソフトウェアの部品化とは目標が同じであるように見える。

再利用戦略は顧客満足を高めることにつながるというスタンスをこのブログでも取っている。でも、ソフトウェアを部品化することと、商品群全体を見据えた再利用戦略とは同じではない。仮に、もしうまいことソフトウェアを部品化することに成功し、ソフトウェア部品を組み合わせるだけでシステムを作り上げることができるようになったら、それはソフトウェア開発と言えるのだろうか? 電気回路設計で部品を組み合わせて回路を書くのと同じではないだろうか。

自分は組込み機器開発でハードウェアとソフトウェアが分かれているのは、ソフトウェアには変更容易性があるからだと思っている。その歴史的な背景を考えれば、組込みソフトはハードウェアとハードウェアの隙間を埋めるような存在であり、隙間を埋められる変更容易性こそがソフトウェアの強みでもあったはずだ。

ただ、ソフトウェアシステムが30万行を越えるようになっても、隙間を埋めるような試行錯誤的な作り方をしていれば品質を維持・向上できない。だから、信頼性を高めたソフトウェアのコア資産を作ってこれを出来るかぎり長い期間、再利用するという戦略は正しいと思うし、実際そうすべきだと思う。

けれども、ソフトウェアの変更容易性を捨てては組込み製品の顧客満足を高めることはできないと直感する。

なぜなら、組込みソフトウェアではビジネス要求とコストや制約条件やら、機能と性能やらとのトレードオフが必ず発生し、それらをすり合わせて最適なバランスポイントを見いだすことが顧客満足を高めるためには必要であり、そのためにはソフトウェアの変更容易性を使わなければいけないからだ。

ソフトウェアの変更容易性の特長を使わなければ最適なトレードオフができないから、例えばコストや性能が犠牲になる。モジュール化されたソフトウェア部品を組み合わせてシステムを構築すると目的の機能を早く確実に実現できるが、コストが見合わなかったり、レスポンスが悪かったり、機動時間が遅くなったりする。

例えば、現実問題として開発工程の終盤でライバル会社が新しい製品をリリースし、市場においてアドバンテージを得るようなソフトウェア機能を見せつけてきたらどうする?

ハードウェアはもう変えられない。もしかしたら、ユーザーにとってはよく使うような機能ではなく、カタログスペックだけの勝負で必要な機能かもしれない。その機能をいれないとダメだ、といっているのは会社の中ではたった一人の声の大きいステークホルダーかもしれない。

でも、現実には多くのプロジェクトはその機能を入れることになるのだ。もしかしたら、ライバル会社が入れてきたのは本当にユーザーに役立つ機能かもしれない。そうだとしたら、嫌々ながらではなく、開発工程の終盤であっても、商品の価値を高め競争に勝つために、その機能を入れなければならない。

そんな芸当はハードウェアではできない。ソフトウェアだからこそできる。ハードウェアを変更したらプリントP板を書き換え、部品を選定しなおし、何回か試作し、性能要件が満たしているか、EMCは大丈夫か確かめなければいけない。確実に数ヶ月以上リリースが遅れる。

ソフトウェアの場合でもリリースは数ヶ月遅れるかもしれないが、ソフトウェアの変更容易性を活用して、機能を基に戻したり、バージョンアップで実現したりする作戦を取ることもできる。

また、きれいにソフトウェア部品を作って、それらをつなぎ合わせて、メモリが足らなかったり、ROM容量が足らなかったり、タイミングが間に合わなかったりすることが分かったらどうする?

そんなときは、作ったソフトウェア部品の一部を壊して、すり合わせの作業をし、制約条件や要求性能をクリアするしかない。顧客満足を満たし、商品の価値を高めるためには機能性(Functionality)、信頼性(reliability)、使用性(Usability)、保守容易性(Maintainablity)、移植性(Portability)を犠牲にしても効率性(Efficiency)を優先させなければいけない場合がある。(この例では6つの品質特性は同時には実現できず、一部が背反している)

そもそも、品質特性には組込み機器の価値を高めるために何かを犠牲にしなければならないというトレードオフの概念はない。悪い言い方をすれば、現場を知らない人たちが抽象論だけで作ったガラスの城のように見える。中身のある実態が見えない。

自分がイメージする美しいアーキテクチャとはまず、顧客満足が高く多くの人がその価値を認め購入し、長い間使い込むほど満足が高まるような商品がそこに実現されており、その中身をのぞいてみると価値の高いソフトウェア資産が独立しており、この資産を使って商品バリエーションを作れるような構造のことだ。

ようするに、商品として価値が高くないのなら中身がどんなにきれいにでも美しいとは思わないし、品質が高いとは思わないということだ。

だから、商品価値が高くないのなら、機能性(Functionality)、信頼性(reliability)、使用性(Usability)、効率性(Efficiency)、保守容易性(Maintainablity)、移植性(Portability)の品質特性が満たされていても意味がない。

ただ、30万行を超えるようなソフトウェアで機能性(Functionality)、信頼性(reliability)、使用性(Usability)、効率性(Efficiency)、保守容易性(Maintainablity)、移植性(Portability)がめちゃめちゃなシステムではバグをほとんどゼロにすることは不可能に近い。だから、品質特性を満たすことができないソフトウェアシステムは、結果的に商品価値(特に潜在的な価値、当たり前品質)が低くなる可能性が高い。

それでもなお強調したいのは、機能性(Functionality)、信頼性(reliability)、使用性(Usability)、効率性(Efficiency)、保守容易性(Maintainablity)、移植性(Portability)を高めることを組込みソフトウェア開発の目的にしたのでは、組込みソフトウェアの最適なトレードオフは成就せず、そのハードウェアにおいて商品の価値を最大限に引き出すことはできないということだ。

そうなると一番難しいのは「品質特性を高めること」と「商品価値を高めるために品質特性を犠牲にすること」のバランスポイントをどこに持って行くかだ。どれくらい品質特性を犠牲にすればよいかを判断するためには、もちろん品質特性とは何か、品質特性がなぜ提唱されたのかも知らねばならない。

さらに、最適なバランスポイントを見極めるためには、トップダウンとボトムアップの両方の視点が必要だし、ユーザーやユーザーが商品を使う環境や、世の中の幅広い科学技術や新しいハードウェアデバイスの情報や既成概念を打ち破る発想の転換もいる。

それが簡単ではないからこそ、組込みソフトエンジニアを極めるのは難しいし、顧客満足を高めることに成功したときの喜びが大きいのだ。

それぞれの業務ドメインのおいて、組込みソフトウェアの技術的ゴールはない。ゴールがないからこそ、その市場のユーザーを満足させるための技術的鍛錬をいつまでも続けていけるのだと思う。
 
もう一つ付け加えるなら、優れた組込みアーキテクトとは組込みソフトウェア開発において商品の価値を最大にする最適なバランスポイントを見つけることのできるエンジニアのことだと言える。最適なバランスポイントを見定めるためには、見渡せる範囲の隅から隅まで知っている必要がある。だから、ソフトウェアの品質特性は知らなくてもいいのではなくて知っている上でどこまで使うべきかを判断できるようにしておく必要がある。

知っているべき範囲は非常に広いので、勉強することがないという状況には絶対ならない。「この技術を使った顧客満足を最適にできるかどうか」という目で世の中を見ながら、「もしかしたら」と思ったら、深く入り込んでその技術を習得し、その技術のメリット・デメリットを頭の中にインプットして必要なときに使えるようにしておく。

これができるようになると広い範囲で問題解決能力を発揮できるようになる。すなわち、どこにいっても「使える」エンジニアになれるはずなのだ。

個人的に、ソフトウェア品質と組込みソフトウェア品質は同じではないと考えている。組込みソフトウェア品質においては、顧客満足を高めることを第一に考え、そのための顕在的な価値と潜在的な価値を高めることを目指し、潜在的な価値を高めるために有効と考えられる品質特性をどこまで取り入れれば、商品価値が最大になるかを見極めるべきだと思う。
 
P.S.

ソフトウェア品質に関して過去に書いた以下の記事も参考にしていただきたい。

理系白書から考えるソフトウェア工学』で書いたソフトウェア工学と自然科学の違い。
  1. ソフトウェア工学は実用的で社会の利益となるような手法・技術を発見することが目的である。
  2. ソフトウェア工学では、よりどころになる自然科学の法則がほとんど使えず、思考や行動が必ずしも論理的でない人間を研究の対象にするしかない。
  3. 自然科学で解明された法則は安定しており寿命は長いが、自然科学に立脚した説明がほとんどできないソフトウェア工学は必ずしも安定ではなく寿命もそう長くはない。
『ソフトウェア品質とは何か』の 記事で書いた品質特性のこと。

また、東京大学大学院経済学研究科教授兼 ものづくり経営研究センター長 藤本隆宏先生が語った「ものの価値について」の話と、広島市立大学情報学部教授 大場充先生のソフトウェア品質の考え方について。『ものづくり戦略とソフトウェア品質』
 

2008-03-21

パフォーマンスを商品の価値に置き換えられない日本の企業

日本の組込み機器メーカーは長期レンジの商品戦略を立てずに商品開発を始めてしまうことが多い。今売っている自社商品や競合他社の商品に何か一つ機能を追加したものを作ろうとしてしまう。

日本の同じ市場で競合するA社、B社、C社がこれを繰り返すので、時間がたつにつれてどんどん機能が盛り込まれた商品が市場にあふれるようになる。

機能は増えているのになぜ商品価格はそれほど上がらないのか? それは、追加する機能はソフトウェアで実現しており、最近のCPUはこのような機能追加を受け入れられるくらい性能が上がっているし、追加のプログラムを搭載してもまだ余裕があるほどメモリは安くなっているから、部品代のアップにはつながらないのだ。

でも、ソフトウェアの開発費のぶんが価格に上乗せされるのでは?

それは、商品の出荷数のNが非常に大きければ、あまり問題にはならない。また、ソフトウェアの場合バグさえなければ、複製したことによる品質の劣化やばらつきはないので、(リリース後の不具合さえなければ)大量生産に対するリスクはない。

ソフトウェアによる機能の追加競争を続けるとどうなるか?

結果的にはユーザーがほとんど使わない機能満載の特長がなんだかよく分からない商品が市場にあふれる。同じ市場でA社もB社もC社も同じような商品開発を行っていればユーザーはそんな使いにくい商品の中から少しでもましなものを選ぶしかない。

でも、誰かがそんな付け足し商品戦略から抜け出して贅肉をそぎ落とし強い主張を持った商品を市場に投入したら、その他大勢を尻目に一人勝ちするかもしれない。

日本の組込み機器メーカーが商品戦略に長けていない理由は、組織内のマーケティング部門は技術を知らず、技術部門は戦略的マーケティングができないからだ。マーケティング部門と技術部門が足らない点を補うように協力できればこの穴を埋めることができるが、多くの組織ではマーケティング部門と技術部門は「顧客はこうなることを望んでいるのだからなんとか実現しろ!」「今の技術で実現可能なのはここまでだ!」といった顧客満足向上のための真剣勝負の議論をしないため、結果的に双方とも適当なところで妥協して機能の付け足し商品ができてしまう。

少し前に流行ったMOT(Management Of Technology :技術経営、例えばこんなスクールがある)を技術部門が勉強すれば、少しはマーケティングの感覚が磨かれるのだろうと思うが、今の日本の企業では技術部門の上位層は自分たちの業務ドメインに関係する技術や人の管理だけできればよいと考えており、技術経営や商品戦略を学ぶ必要性があるなどという想像もできないのだろう。

これまで、日本の組込み機器開発では求められる機能と制約条件(メモリやリアルタイム性等)とのすり合わせを行い、顧客満足を最大にするようなバランスポイントに着地する商品開発を行ってきた。

ところが、今では最適なすり合わせ、トレードオフはどこかに吹き飛んでしまい、入れられるだけ機能を突っ込み、その結果リアルタイム性の低い商品しか作れなくなってしまった。

リアルタイム性が低いというのはハードリアルタイムが求められる部分がクリアできていないというのではなく、ソフトリアルタイム、例えば電源の立ち上げや操作に対するレスポンスが悪くなるということだ。

Tech-on! に「起動時間にもこだわりを!」という記事があった。日本ビクターが2008年2月下旬に発売した液晶テレビ「LT-32LC305」のカタログの「特長」欄の最後の方に「起動時間を10秒から3秒に短縮しました」と書いてあったという。

このブログでも何度も書いているように、最近の情報家電のパワーオン時の長時間化にはうんざりしている。Tech-on!の記事の中ではこの長時間化の原因に一つは「LinuxをOSに採用する機器が増えている」ためだとある。予想通りだ。

要するに商品戦略として機能を追加することでしか競争できない、いや、機能を追加することしか思いつかない組込み機器メーカーが、これまでのように機能・性能・制約条件をすり合わせて最適化することを放棄して、機能追加にお手軽で使用料無料というLinuxという甘い果実に手を出してしまったのだ。

その結果、犠牲になったのは機動時間を含めたレスポンスだ。今、HDDに録画した2時間のテレビ番組をDVDにダビングしているのだが、このダビングになんと2時間かかる。2時間の番組をダビングするのに2時間かかるとは・・・

日本ビクターの液晶テレビの機動時間が3秒というのは「ハイバネーション」技術に,独自の工夫を加えて実現しているらしい。自分は、日本ビクターはこのアドバンテージをカタログの隅でつつましくお知らせするのではなく、もっと大々的に宣伝すればよいのにと思う。この思いが「パフォーマンスを商品の価値に置き換えられない日本の企業」という今回の記事のタイトルにつながっている。

日本の組込み機器メーカーは機器の性能を評価することに慣れていない。特にソフトウェアの性能を評価することに慣れていない。機能があるかないかというON/OFFの判断できるが、パフォーマンスがどれくらいあればよくて、どれくらいではダメなのかについて指標を作るのが下手だ。(個人的にはこのアナログな指標の根拠を会議の中で自信を持って主張できる人材が少ないのだと思う)

ユーザーインタフェースのレスポンスがどれくらいあればよいのかは、基本的にはその商品を使うユーザーが決めるべき事項だ。

10年前の組込みソフト技術者は自分たちのソフトウェアを組込み機器に実装しては、ユーザーインターフェースの善し悪しを、技術者自身がユーザーになったつもりで試作品にさわり確かめながらものづくりを進めていた。

この開発スタイルは分析・設計をしてから実装するのではなく試行錯誤でものつくりをしてしまっているので、ソフトウェアシステムの品質確保という点ではデメリットがあるが、機能・性能・制約条件の最適化を図る、すり合わせる、ユーザーから見た商品の妥当性を確認しながら前に進むという点ではメリットがあった。

ところが近年、組込みソフトの開発規模が増大、複雑化し、プロジェクトメンバーの数も増えてくると、機能・性能・制約条件の最適化を図る、すり合わせる、ユーザーから見た商品の妥当性を確認しながら前に進むことができなくなってきた。

最後の最後にできあがってから、パフォーマンスが悪い、性能が出ていない、制約条件がクリアできない、ユーザーから見て使いにくいことが分かる。でも、そこまで開発が進んでしまってはもう後には戻れない。機動時間が遅いからといって Linux を ITRON に変えることなどできない。

だから、商品開発の要求分析の工程でユーザーニーズを抽出するときに、機能だけでなく、製品に要求されるパフォーマンスもキチンと定義すべきなのだ。

実際には製品に求められる性能要件だけでなく、企業としてのビジネス目標や、競合他社の状況、その組織の得意とする技術などを総合的に分析してこの商品で何を実現するべきかを決定し、その要求を満たすアーキテクチャを設計し、ソフトウェアを実装する。

これらの要求は背反するものもある。ユーザーはほとんど使わないけれど、他社がその機能をカタログでうたっているのでビジネス要求としては入れたいといったものだ。このような市場要求のトレードオフの議論は商品を作ってからするのではなく、商品を企画する段階、要求定義の段階で決着を付けておくべきものだ。

このような商品に求められる市場要求を品質機能展開(QFD)を使って分析し、過去に作ったソフトウェアシステムを分析しながら、市場要求分析と合わせてアーキテクチャを改善する方法を 組込みプレス vol.8 の特集1 『効率化と品質向上2つのアプローチ』に書いた。

何はともあれ、大きなプロジェクトになってしまった今の組込みプロジェクトのプロジェクトリーダーやアーキテクトは、商品に「このソフトウェア」を実装したらユーザーはどんな風に使うだろうかと考える想像力が欠如しているように見える。

これまで日本の組込み機器メーカーは実際にソフトウェアをインプリメントしては動かしてみるという繰り返しをしていたので、ソフトウェアが提供するユーザーインタフェース(特に性能面)を想像する必要がなかったが、ソフトウェアシステムが大規模化した今では簡単に動かしてみることが難しい。(この問題を解決するためにイテレーションの開発プロセスを採用し、イテレーション毎に評価して次のプロセスに進む方法はある。)

商品がユーザーニーズを満たしているかどうかを確かめる行為を Validation (妥当性の確認)と呼ぶ。Validation は、ソフトウェアが設計どおり仕様通りに作られているかどうかを確認する Verification (検証)と同様に、ソフトウェア開発プロセスの中で非常に重要な Activity(活動)である。

Validation と Verification は製品開発の中で V&V と呼ばれ、品質保証部門から「V&Vの計画は立てたか」「V&V のドキュメント(証拠)を見せて」などと言われる。

Validation (妥当性の確認)とVerification (検証)は似ているが同じではない。前述の機動時間の遅い情報家電の話は、設計通りに作られているので Verification (検証)はすべてパスしていると言えるが、できあがった商品が、ユーザーニーズ(ここでは素早い起動)を満たしていないのなら
Validation (妥当性の確認)ではNGの項目があると言える。

その組み込み機器にアクセスするのが他の機器ではなく、人間である場合、Validation (妥当性の確認)とVerification (検証)は一致しないことが多い。ソフトウェア設計者がよかれと思った設計した機能や性能が、作ってみたらエンドユーザーの要望とは違っていたということは、相手が何をするかわからな人間だけに絶対ないとは言えない。だから、市場要求の分析やユーザビリティの研究が大事なのだ。

今のソフトウェアが役割が大きい製品の組込み機器メーカーは、マーケティングと商品企画力が弱く、ユーザーニーズを満たしているかどうかの Validation (妥当性の確認)ができていない。要するにユーザーニーズの本質を分析しきれていない。

大規模・複雑化する組込みソフトウェア開発においては、商品に求められる必須のパフォーマンス(Essential Performance)の分析・定義とユーザーニーズを満たすことができているかどうかの Validation(妥当性確認)がキチンとできているかどうかが今後重要なポイントとなる。

P.S.

記事を後から読み直してふと思ったのは白物家電は機能がありすぎて使い切れない、使いにくいと感じたことがほとんどないということだ。おそらく、白物家電の場合、用途が明確であり、ユーザーが機械にそれほどくわしくない主婦層だということもあり、使いやすさを追求し、必要な機能をユーザーがオペレーションしなくても自動で判断して実行してしまうように組込み機器を作り込んでいるからだと思う。

機能満載で使いにくいのは情報家電の部類だ。情報家電でも iPOD はユーザーインタフェースをよく研究していて使いやすいと感じるので情報家電は使いにくいものしか作れない訳ではないんだと感じる。
 

2008-03-08

三菱電機の携帯電話事業撤退で見えること

三菱電機が携帯電話事業から撤退することを決めた。

このニュースで驚いたのは三菱電機が作っていた携帯電話の数がシェアトップでもないのに2007年度で210万台もあったということだ。売上金額は1000億円とのこと。単純計算でも1台あたり4万7千円で売ったことになる。

これまで日本では消費者が知らないうちに携帯電話の価格の一部を通話料金に上乗せして月賦で払っていた。携帯電話のショップは携帯電話を1台売ると携帯電話のキャリアから販売奨励金を3~4万円程度もらっていた。(金額は正確でない) だから、携帯電話の売値を仕入れ価格よりも下げても赤字にならなかった。携帯を1円で売っても損しないカラクリはここにある。そして、この販売奨励金の金額は携帯電話のキャリアがユーザーから徴収する毎月の基本料金に上乗せしてしていた。

ローンでものを買うのが嫌いな人もいると思うが、ローンを組まされているとも知らずに実際の価格よりも見かけ上2~4万円も安く買っていた人が何百万人もいるということだ。

この携帯電話の価格を見かけ上安く見せかける販売方法は総務省の要請でもうなくなっている。この結果何が起こるか。それは、現在の日本の携帯電話の本当の価格が日の目にさらされるということだ。(総務省の通達:携帯電話に係る端末価格と通信料金の区分の明確化に関する携帯電話事業者等への要請

これまで3万円台で買っていたものが、販売価格が5万円くらいになり月々の通話料金が安くなる。1~2年使い続ければトータルで同じではないかと思うかもしれないが、本当にそうだろうか。

あなたは今携帯電話を持っていて特に不自由なく使えているのに、5万円も6万円もする新しい携帯電話を買い換えようと思うだろうか?

3万円なら少し考えて「よし買おう」という金額だと思うが、5万円の買い物をするのにはそれなりの決心がいるし、自分だけでなく家族を納得させるだけの根拠もいるだろう。

日本の携帯電話はNokiaなどの海外の携帯電話に比べて機能が(異常に)多いと言われている。確かに自分も携帯電話の機能を使い切れてはいない。

【よく使う機能】
・電話として使う
・メールを読み書きする
・今の時間を見る
・WEBブラウザでニュースを確認する

【たまに使う機能】
・写真を撮る
・パソコンにつないでパケット通信する
・アドレス帳の管理
・留守番電話を聞く

【滅多に使わない機能】
・音楽を聴く
・スケジュールを管理する
・アラームをかける
・動画を撮る、見る。
・QRコードを読み取る
・USBマスストレージとして使う
・電卓として使う

自分の場合、冷静に考えれば留守番電話を含む電話機能とメール、WEBブラウザだけでもいいかなと思う。

それなのになぜ、こんなにたくさんの機能を搭載した携帯電話を買うのか、ワンセグのテレビを見たいがために6万円も7万円も出費するのだろうか?

普通に考えれば、商品ラインナップの中でハイエンド機種は機能も多いが価格も高く出荷台数はスタンダードモデルよりも少ない。商品ラインナップの中間に位置するスタンダードモデルや下層のバリュアブルモデルが一番数がでるのが普通だろう。

日本では携帯電話では見せかけの販売価格のからくりがあったために、市場価格が故意にゆがめられ本当は価格が高いハイエンドモデルがばかばか売れていたのではないかと思う。

三菱電機が携帯電話事業から撤退した理由の一つに、今後ハイエンドモデルの売り上げは減り、ますます携帯電話で利益を上げるのが難しくなるという予測があったのだろう。傷口を広げる前の判断としてはタイミングがよかったのではないか。

今後、携帯電話の販売価格が軒並み2万~3万円高くなることで、組込みソフトの世界にも変化が現れそうだ。

日本人は組込み製品の商品コンセプトを考えるのが下手だ。その商品、その組織のアドバンテージとなる機能や性能を前面に出し、その他の部分をそぎ落として特長を際だたせることができない。どんどん機能を追加する。

特に、材料費のアップにつながらないソフトウェアの機能追加については「A社にあってウチにないのなら入れろ」とは言っても「その機能を入れると特長がぼやけるからやめておけ」とは決して言わない。

個人的にはプロダクトマネージャの商品に対する自信のなさがこう言わせているのではないかと思っている。商品をリリースしてライバル会社に売り上げで負けたときに「あっちには○○の機能があるが、ウチにはないからだ」と営業に言われたとき反論できないのでカタログスペック上だけでも他社に負けないようにしておきたいのだ。これではユーザーの本当のニーズを考えた商品開発ができていない。

一言でいえばユーザーオリエンテッドの仕様立案ができない、マーケティングができていない、商品戦略がないということなのだが、この傾向は日本全体に多く見られ組込みソフトエンジニアを苦しめる一つの要因になっている。

携帯電話の見せかけの販売価格の件は、何でもかんでも機能を突っ込めばいいという日本の企業によく見られる幼稚な商品戦略を助長させた。その結果、ユーザーはたいして使わない機能満載の商品を見かけ上本当の価格よりも2万円~3万円安いという理由で「まいっか」というノリで買っていた。

これまでの携帯電話の価格体系は「5万円とか6万円もするなら、もっとシンプルな機能の商品を買おう」という一番多い層の顧客の行動が表面にでないように消費者を暗に誘導してきた。

このことはグローバルマーケットでは Nokia などのシンプルな携帯電話が圧倒的に多く売れており、日本だけで本当は価格が高い端末が何百万台も売れていることで分かると思う。

さて、三菱電機の携帯電話事業からの撤退をきっかけに、携帯電話のソフト開発で食べてきた受託ソフトウェア会社は仕事を失うところが出てくるではないかと考えている。

携帯電話に限らず、日本の組込みソフトウェアはメーカーのエンジニア以上にソフトウェアの受託開発会社のソフトウェアエンジニアのマンパワーに頼っているところがある。

もちろん、日本では携帯電話以外にも組込みソフト技術者の需要はたくさんあるので供給が需要を上回ることはないと思うが、三菱電機の携帯電話事業の撤退で取引先のソフトハウスは新しい仕事を探すのにやっきになっているに違いない。

メーカーサイドは約600人の携帯電話関連の人員を別の部門に振り分けることができるが、ソフトハウスはクライアントとの付きあいをいったん切られると新たなつながりを探すのは意外に難しい。

三菱電機の携帯電話事業の売り上げが1000億円で、ソフトウェア開発費比率が仮に5%だとすれば開発費は50億円だ。この50億円の多くがソフトハウスへの発注だったとすれば、この仕事が突然なくなるわけだし、今後、業界全体で携帯電話の外部発注ソフトウェア開発自体が大幅に減る可能性がある。

極端な話、これまでユーザーは携帯電話の使いもしない付け足し機能のソフトウェア開発費に対して1台あたり5千円以上払っていたことになり、この5千円の積み重ねの50億円が今回消えることになったとも考えられる。

こんな局所的なバブルを生み出してしまった原因は日本の組込み機器メーカーの商品戦略のなさではないだろうか。日本の組込み機器メーカーもそろそろ新製品=(ソフトウェアによる)機能の付け足しという考え方をやめたらどうだろう。

機能を付け足すだけの頭を使う必要のない誰でも考えつく幼稚な商品戦略が減少し、贅肉をそぎ落として特長を際だたせるような骨太の商品コンセプトが当たり前になっていけば、その市場に投入すべき商品群の特長が明確になり、自組織の得意な部分を活かした再利用すべきソフトウェア資産がなにかが見えてくるはずだ。

本当かどうかは知らないが Nokia はそれを成功させたと聞いている。(プロダクトラインがNEのカバーストーリーに登場を参照のこと)
 

2008-03-01

何も指導しないとプログラミングはこうなる

久しぶりにC++のコードを書いた。過去に作った Visual C++ 6.0 で作ったソフトウェアをまた、使わなければいけなくなったのだが手を入れるためには、Visual C++ 2005 に乗せ替えなければいけなかったからである。

ちなみに、なぜVisual C++ 2008 にしないのかというと、ソフトウェアの場合は流行物に飛びつくと痛い目に会うことがあるので自重しているからだ。Windows もXPで購入した数々のアプリケーションソフトウェアがそのまま動くかどうか不安なので、まだ Vista に乗り換える決心が付かない。

さて、久しぶりにプログラムのソースコードに触れることで、プログラミングのやり方について常々考えていたことがふつふつとわき上がってきた。

技術者はどのようにプログラムを書くのかということだ。次に自分が一般的だと思うパターンを書いてみるので眺めてみて欲しい。

【何も指導しない場合のプログラミングのやり方】
  1. まず、何でもいいから目的に近いサンプルのソースコードを探す。目的のほとんどや一部分を実現できている実績のあるソースコードがあれば最高だ。
  2. そのコードをコピーして、そのコードの変数や関数のネーミングルールやコーディングルールを読み取って、それに合わせて必要なコードを付け足す。
  3. コンパイル・リンクしてエラーをなくし、目的を達成するまで試行錯誤を繰り返す。
しかし、この方法では大規模・複雑化したソフトウェアシステムにおいて品質を高めることはできない。

何が足りないかというと、分析・設計してからコーディングをしていないのだ。結果を早く出したいばかりに分析・設計を端折ってしまったり、頭の中だけで済ませてコーディングに入ってしまったりする。

そこで、自分は少しでもこれに歯止めをかけるために、ファイルヘッダ、関数ヘッダを必ず付けるようにしている。

たとえばこんな感じ。(等幅フォントが使えないので /* */ から//に変更した)

//*****************************************************************************
// 概 要 : 電子ポットメイン関数
// 関 数 : main( void )
// 引 数 : なし
// 戻り値 :
// 備 考 :
//----------------------------------------------------------------------------
// 作成日付 : 2006.06.20
// 作 成 者 : 胡麻 太郎
//*****************************************************************************

関数を作る前にヘッダ部分を他の関数ヘッダからコピーしてきて、概要、関数名、引数、戻り値、作成年月日、作成者などを書く。

この大したことがないような関数ヘッダの記述は実はその後ろにいろいろな意味がある。

【関数ヘッダ(クラスヘッダ)を書く意味】
  1. 関数の概要を書くことで関数やクラスの目的や責務が明確になる。
  2. 関数名を書くことで関数名のネーミングルールについて意識することになる。恥ずかしい名前の付け方をするとずっと誰がこの関数の名前を付けたのか証拠が残る。
  3. 引数、戻り値を書くことはインプットとアウトプットを明確にすること。1~3までをやると関数の入出力と目的が明確になる。
  4. 関数を作成した日付と作成者を書いておく、後にプログラムに手を入れたりデバッグするときに役に立つ。一回作りきりのソフトウェアではそれほど大きな効果をもたらさなくても、コードを再利用する確率が高い組込みソフトウェアでは、誰がいつ作ったのかという情報は大事だ。また、作成者を書き入れ署名することでそのプログラムに対する責任を負うという感覚が芽生える。
関数ヘッダ(クラスヘッダ)を書くのがいちいち面倒だと考えているプログラマーには上記のことを理解してもらわないといけないのだが、最初からこのようなルールは設計の規範として「その組織では当然やらなければいけないこと」としてしつけられ、意味も分からず繰り返しているうちに「ああ、ヘッダを書いておいて良かったな」と感じるようになることが多い。

Visual C++ ではウィザードを使うと、勝手に必要な関数のスケルトン(骨組み)がたくさん出来てしまい、当然そのスケルトンに関数ヘッダはない。だから、Visual C++ がはき出すスケルトンの関数にも自分はヘッダを付けるし、プロジェクトメンバーにもそう指導する。

組込み開発の世界では、ソフトウェアの品質が高いかどうかを外から判断するのが最も難しい。

機械設計の場合、設計が悪いと動かないし、生産工程で不良率が上がるし、そもそもできあがったものを先輩や上司が見れば良い設計か悪い設計か見分けがつく。

電気設計の場合は、作り上げた回路が期待通りに動かなかったり、精度が出なかったり、消費電流が大きかったり、煙が出たりして設計の善し悪しが分かる。回路設計がきれいか汚いかは回路図を見ないと分からないが、基本的には完成度の高い部品の組み合わせであるためチェックポイントの種類、組み合わせはソフトウェアほど多くない。

機械設計や電気設計に比べて、ソフトウェアの場合はできあがる完成品に対して設計の粒度が細かい。一行一行のプログラムを技術者が自由に書けてしまうので、たった数十行程度の関数であっても10人のプログラマがいれば、10通りの関数ができてしまう。

どの関数も「よい設計」であればよいのだか、変数を初期化していなかったり、出口が一つでなかったり、入力に例外があると無限にループが回ってしまうようなプログラムになっていることも少なくない。

「一応動くけれどもベテランが見ると危ない」関数は山ほどある。そんな関数が寄せ集まってシステムができあがっているのだ。機械設計や電気設計とソフトウェア開発の最大の違いは、そんな危ない関数の寄せ集めであっても、全体としてはキチンと動くことが多いし、もし、問題が発覚したらすぐに直せてしまうところが違う。

だから、商品をリリースする前なら、ソフトウェアエンジニアはどんどんプログラムを直してしまう。関数やクラスの完成度を高めるのではなく、対処療法で当面の痛みを麻痺させようとしてしまう。体質の改善ではないから、次の開発で楽になる方向につながらない。次の開発で楽になるというのは、信頼性の高い再利用資産が今回の開発で構築され、次の開発でほとんど手を加えずにその再利用資産を使えるというシチュエーションのことを指している。

製品のリリース間際に発覚した痛み(問題)にどんどん絆創膏を貼ってしまうことで、ソフトウェア資産はスパゲッティ化し再利用しがたいものに変質してしまうのだ。

近年、ソフトウェアのテスト技術に関する研究や取り組みが盛り上がっているが、絆創膏を貼るだけでは体質の改善にはつながらない。ソフトウェア品質を高めるためには、不良を取り除く取り組みと不良を作り込まない取り組みの両方が必要だ。

不良を取り除く取り組みを進める一方で、不良を作り込まない取り組みをしていかなければ、開発は決して楽にならない。

組込みソフトウェア開発のリーダー、サブリーダーの方達に「今、開発現場で問題になっていることは何か?」と聞くと90%以上が「品質問題で困っている」と言う。組込みソフトウェアの品質を高めるためには不良を取り除くだけでなく、不良を作り込まないために何をすべきか教えなければいけない。

これはいつ誰が教えるのか? 現状を考えれば、開発現場において経験を積んだリーダーがプロジェクトのメンバーに「設計の規範」として、不良を作り込まないためのルールを守らせることから始めるのは一番効果的だと感じる。

設計の規範の最初の一歩としてお勧めしたいのは、『組込みソフトウェア開発向けコーディング作法ガイド[C言語版]』と『組込み現場の「C」プログラミング 標準コーディングガイドライン』と『組込み現場の「C」プログラミング―基礎からわかる徹底入門』だ。

組込みソフトの初心者はC言語のコーディングスタイルの学習に『組込みソフトウェア開発向けコーディング作法ガイド[C言語版]』を辞書に『組込み現場の「C」プログラミング 標準コーディングガイドライン』を副読本として読むとよい。そして『組込み現場の「C」プログラミング―基礎からわかる徹底入門』で組込みソフトウェア開発のさまざまな設計の規範を学ぶ。

このようなコーディング作法やプログラミングに関する設計の規範は本当は大学のプログラミングの授業で教えて欲しいのだが、20年前の自分の経験も含めて言えばそういった授業が行われているところはほとんどないんだろうと予測する。

まあ、それは無理もないだろう。自分だって、設計の規範が大事だと感じるようになったのは、製品作りを何回も繰り返してからだし、エドガー・ダイクストラが提唱した構造化プログラミングの真意を知ったのも最近だ。

製品としてリリースするソフトウェアの内部を見る機会がほとんどない、大学の先生達にプログラミングの授業では文法を教えるだけでなく、コーディング作法やより信頼性の高いプログラムを書くための設計の規範を教える必要性を感じてもらうのは難しいのだと思う。

だから、一番大事なのは新人の技術者がプロジェクトで初めてプログラミングをするときだ。最初に組織やプロジェクトの設計の規範を教えてそれを守らせることが、その組織がアウトプットするソフトウェアの品質を下支えすることにつながる。

ここで何もしなければ、人間はその本質的な行動パターンから、プログラムを以下のようにして作ってしまうのだ。この状態を脱することができたプロジェクトでも、しばらく監視をしないでいるとすぐにもとにもどってしまう。

【何も指導しない場合のプログラミングのやり方】
  1. まず、何でもいいから目的に近いサンプルのソースコードを探す。目的のほとんどや一部分を実現できている実績のあるソースコードがあれば最高だ。
  2. そのコードをコピーして、そのコードの変数や関数のネーミングルールやコーディングルールを読み取って、それに合わせて必要なコードを付け足す。
  3. コンパイル・リンクしてエラーをなくし、目的を達成するまで試行錯誤を繰り返す。

組込みソフトエンジニア初級者へのしつけがその組織の文化につながるようになれば、ソフトウェア品質向上の道が開かれる。

P.S.

組込みソフトの品質を高めるには設計の規範が必要』の記事もお読みください。