仕様は変化しやすいが、要求の寿命は長い

先日あるソフトウェア技術者の方から以下のような質問を受けた。

【現場の問題点】

新製品のソフト設計を最適な手法を模索しながら行っています。仕様の明確化が重要だと思いますが、ハード設計に依存してしまい、洗い出しても保留になることが多くあります。こういった場合、どう対処すべきなのでしょうか？

そこで、以下のように回答した。

【回答】

まず、第一に要求品質を明確化することが重要です。要求品質には2種類考える必要があります。

1. ユーザー要求、市場要求から展開した品質
2. 同等の製品、製品群で発生した不具合の対策から展開した再発防止策に基づく品質
   

次に、1と2の要求を細分化して優先度を付けます。顧客要求・市場要求だけでなく、ビジネス目標などの要因も加味します。

ここまでで、要求品質が明確になり、どんな機能や性能が重要なのかがわかります。

仕様の明確化よりも要求の明確化の方が大事です。仕様は変化しやすいですが、要求の寿命は長いからです。

次に、要求を実現できる技術があるのかないのかを明確化します。この段階で試行錯誤しているのなら、それは要素技術検討の段階ですから実現できる目処を立てます。（部品の入手性、安定的に生産できるかどうかも検討します）

この作業にはトレードオフが必ず発生するので、その製品が使われる市場や実現技術など広い知識と経験が必要です。知識や経験が不足しており見切り発車すると、後工程での手戻りが多く発生します。未確認の技術要素は早め早めに実験して目処を立てます。

ソフトウェアの設計で注意すべき点は、今回の開発だけでなく次の開発、またその次の開発で共通なソフトウェア資産は何か？　固定的な要素は何か、変動的な要素は何かを見極めることです。要素技術検討の段階でハードウェアが確定していない機能については、ハードウェアに変更があったときのことを考えてチューニングしやすい構造（アーキテクチャ）を選択します。

上記のアプローチが成功すれば、寿命が長く変化に対応しやすいソフトウェア資産ができあがるはずです。

【引用終わり】

回答を書いてみて、「仕様は変化しやすいが、要求の寿命は長い」というフレーズはいいなと感じた。

この話はオンデマンドで作るソフトウェア開発と組込みソフト開発の最大の相違点であり、組込みシステムでは同じ市場に同じような製品を投入し続けるということは、要求に普遍性があるからだということに通じる。

普遍的な市場要求、ユーザー要求がキチンと把握できていないと、次の製品を作るときに「他社がやっているから」とか「組織のお偉いさんが入れろと言っているから」といった理由で、付け足し要求を実装し、現在の製品がクリアできている市場要求・ユーザー要求を実現している機能や性能をデグレードさせてしまうケースがある。

一通り一般的な要求を実現すると、カタログスペック上で他社と比べて負けているところだけが目に付き、強いユーザー要求でもないのにそのおまけの機能を実装しろという輩がかならずいる。

営業担当は自社の商品が売れない理由を他社の商品ができていて自社の商品ができない機能や性能があるからだということが多い。

実際、それが理由で売り上げが低迷していることもあるのだろうが、その機能を実装したからといって売り上げが大幅にアップすることはほとんどないように思う。

ここの問題点は、作る側も売る側も商品のコンセプトをちゃんと理解しておらず、市場要求・ユーザー要求の本筋で勝負することを忘れてしまっているということだ。

商品のコンセプトが明確になっており、市場要求・ユーザー要求の本筋の部分でどんなくふうや、トレードオフをしているのかがいつも頭の中に入っていれば、「（枝葉末節的な）このスペックが足らないから売れないのだ」という販売サイドの主張に対し、「それは市場やユーザーの本筋の要求ではなく、それを実現しようとすると、レスポンスや複雑性が増すことによる安全性や信頼性の面でリスクが生じる」「この製品のこの機能や性能は今も昔もお客さんに満足されており、その満足度を下げるリスクが現実になると売り上げを下げる危険がある」「基本機能のこの面を強化すれば、より顧客満足度を高めることができる」というような意見を即答できる。

組込み機器は制約条件が多いので、要求と制約のトレードオフがいろいろなされ、その微妙なバランスで現在の製品ができあがっていることが多い。実現した機能や性能にソフトウェアが絡んでいる場合、なかなか外には見えないので、どんな影響があるか何も考えずに「こんな機能も、あんな機能も、全部追加してしまえ！」という乱暴な指示を出す者もいる。

その結果、要求と制約のトレードオフがくずれ、いままでできていた基本機能を損ねてしまったら、元も子もない。

だいたい、市場要求、ユーザー要求だって実は十分に満たせていないことに気がついていないだけかもしれない。要求はあるけれど、さまざまな制約条件で十分に満たせていない状態で商品をリリースしていることはよくある。その本質的な要求と制約条件を忘れてしまうと、技術革新が起こって制約条件が緩和されたにも関わらず、その新しいデバイスや技術を使うことを忘れ本質的な要求実現を改善することよりも、どうでもいい付け足しの機能を追加することに走ってしまう。（「洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない」を参照のこと）

組込みソフトエンジニアは「仕様は変化しやすいが、要求の寿命は長い」ということを忘れずに、この商品やサービスに求められている要求は何か、その要求に優先度を付けると何が一番大事なのかを常に頭の中にいれておかなければいけない。

それを忘れてしまうと、ステークホルダかクライアント、声の強い者に、こねくり回し的な仕様変更や仕様追加を指示され安易に受け入れてしまう可能性が高くなる。

組込みソフトエンジニアのモチベーションが最も下がるのは、お客さんの満足を高めることに貢献しないような仕様変更や仕様追加を突きつけられたときだ。「あーあ、こいつ分かってないな・・・」と思いながら、仕様を押しつけられそうになったら、本質的なユーザー要求に戻ってとことんディスカッションすべきだと思う。