近年、ソフトウェアの分野で要求分析の重要性が叫ばれている。対象となるソフトウェアに求められている要求をしっかり分析することはもちろん重要だが、特定のクライアントがエンドユーザーとなるビジネス系の受託開発ソフトウェアと、特定の分野の不特定多数のお客さんに提供する製品に搭載する組込みソフトウェアでは、ソフトウェアに対する要求についての考え方を変えなければいけない。
組込みソフトにはさまざまな制約条件が科せられるため、要求のすべてを満たすことが難しい。要求が多様になればなるほとリアルタイム性能などの性能要求を満たすことが難しくなるし、性能の高いプロセッサを使うことを余儀なくされコストアップにつながってしまう。
パソコンをプラットフォームとするアプリケーションソフトウェア開発では、組込みソフトウェアに比べれば遙かにリッチなプラットフォームが存在し、競争相手もまったく同じ環境で開発を行うことが分かっているので、要求と制約条件のトレードオフに頭を悩ませるより、ユーザー要求を間違えることなく、できるだけ早くすべて満たすことが目標となる。
ここには、組込みソフトのような強い制約条件や頻繁に発生するトレードオフは存在しない。
ところが、組込みソフトの場合は、エンドユーザーは特定分野の不特定多数のお客さんであり、必ずしも要求は「これだ！」という確約の採れたものではないし、求められるのは機能だけでなく、性能もあるし、安全性や信頼性も要求され、コストは安ければ安いほど喜ばれる。
そうなれば、当然要求に対して何をどれくらい実現すればよいのかについて優先度を付ける必要があり、その分析結果と、自分たちの得意なスキルを照らし合わせて、トレードオフをし、自分たちの商品でどんな機能と性能を実現するのか決断しなければならない。
最近の情報家電を見ると、商品に求められる要求の分析、特に優先度付けやトレードオフが必ずしも十分にできていないように思える。
例えば、5年前に買った 29インチのブラウン管のテレビは5万円台で非常にお買い得だった。ところが、このテレビ買って後悔したことが一つある。電源を入れてから画面が出るまで12秒かかるののだ。音声はタイムラグなしで出力されるのだが、映像が10秒以上かかるのは、せっかちな自分には耐え難いしうちだ。
また、2年前に買った250Gバイトのハードディスク内蔵のDVDプレーヤも5万円台でお買い得だった。こちらは、画面はすぐでるのだが、システムのイニシャライズが終わるのに20秒近くかかり、電源を入れてすぐに録画予約をすることができない。しかも、DVDのディスクが入っている状態で電源を入れるとシステムのイニシャライズ時間は30秒に伸びる。
新しい機能のほとんどを使いこなすことができず、昔使っていた VHSのビデオデッキと同じくらいの機能しか使わない一ユーザーにとって、この状態は性能のデグレードになる。
もちろん、メーカー側にはそれなりの理由があって、多用な要求を満たして他社とカタログスペックで負けないためには、Linuxなどのプラットフォームを搭載する必要があり、さまざまな内蔵デバイスの診断や、メモリチェックや OSの立ち上げをしている間に10秒くらいは立ってしまうのだろう。
でも、自分というユーザーにはそんなことはどうだっていい。電源入れたら早く立ち上がって、基本機能を使えるようにして欲しいのだ。そして、電源の立ち上がり時間で痛い目にあったので次からは素早く立ち上がる機種を選ぶ。もしも、その機種が他社に比べて機能がちょっとくらい少なくたってかまわない。基本機能を早く使う方が自分にとっては大事なのだ。
自分はこのような不満が自分だけの不満だけではないと考えている。だとすると、この情報家電を作ったメーカは先に挙げた、組込みソフトにおける要求の優先度付けに失敗していることになる。
おそらく、パソコンと同じようなプラットフォームを用意した時点で、組込み機器における制約条件やトレードオフのことを忘れてしまったのだろう。
ただ、現場のエンジニアは要求の優先順位に矛盾が生じていることについて、実はよくわかっているという意見もある。プロジェクトが大きくなってしまったり、組織が決めた方針を覆すことができないため、ユーザー要求の優先度がいびつになってしまった商品ができあがってしまっても、自分の力ではどうしようもないというのだ。
一昔前なら、ユーザーニーズの調査や商品企画、プラットフォームの選定などは、組込み機器開発のプロジェクトメンバーが行っていた。その状況なら、お客さんの要求と自分たちの得意な技術を考慮して、要求と機能・性能の実現の最適化が可能だった。
ところが、今ではプロジェクトの規模が大きくなり、要求も多様化してしまったため、要求の正確な分析と要求の実現能力のバランス判断が崩れている。
今、組込みソフトエンジニアの求められているのは、ユーザー要求の分析と自分たちの得意なスキルでどの要求を実現するのかを可視化して、自分たちの技術でどんな商品を作れば顧客満足を最大にできるのかという設計のコンセプトを明確にすることである。
組込みソフトウェア開発の世界では「見える化」をもう一歩踏み込んで「見せる化」が必要になっている。
ユーザー要求・市場要求の正確に分析し、その分析結果を基にソフトウェアシステムをどのように構築するのか、何がこの商品のアドバンテージになっているのか、何かこの商品のコア資産なのかを、組込みソフトエンジニアが可視化し、それを組織に示し、アーキテクチャ設計を主張し、場合によってはそのアーキテクチャを実現するためのプラットフォームを選択して、その選択の実現を組織に迫らなければいけない。
また、すでに自分たちが何世代かにわたって作り上げたソフトウェアシステムの構造を見えるようにして、どの部分がコアな資産であり、そのコア資産の品質を高めるために、何をしなければいけないのかを明確にし、そのために必要な環境や工数、費用を主張する必要がある。
そうしなければ、組織が決めた環境を、顧客満足が最大にできないことを知りながら使い続け、割り切れない気持ちを引きずることになる。
これを避けるために組込みソフトエンジニアがやるべきことは自分たちが「選択したもしくは選択したいアーキテクチャ」が顧客の要求にフィットしているということ可視化して主張するための「見せる化」だ。
それをしないと、プロジェクトはどんどんネガティブになって、メンバーには受け身の考え方が蔓延し、現場は問題解決の力を持っていながら顧客満足の高い商品をアウトプットできなくなり、競合に負け、価格を下げることでしか勝負できなくなり、忙しさは変わらずに給料が下がるという悪循環に陥ってしまう。
この悪循環を断ち切るための組込みソフトウェアシステムにおける要求分析の方法とその実践の仕方については、いずれわかりやすく説明する機会を作りたいと思う。
【組込みソフトで要求の重要度を分析しなければいけない訳】
組込みソフトウェア開発では要求の洗い出しだけでなく、要求の重要度を分析する必要がある。
↓なぜ
組込みソフトウェア開発では要求を実現する際にトレードオフが発生しやすいため、要求が示す意味と優先順位を分析し分析した結果を明示的に残しておくことが重要となる。それが、商品の開発コンセプトにつながり、どの他社の商品との差別化につながる。
また、その組織が独自に持っている強み・得意な技術を、顧客要求の強い部分にぶつけることができれば、競争力の強い商品を作り上げることができる。
0 件のコメント:
コメントを投稿