![見出し画像](https://assets.st-note.com/production/uploads/images/158995893/rectangle_large_type_2_81800f3cb4e98057d4d34061000cff69.png?width=1200)
SDxマンガFAQ(3)「SDxってまずいの?」
![](https://assets.st-note.com/img/1729642052-5QW7gSCDmVhjLxyYwGaZHf08.png)
ソフトウェアデファインドの欠点とは
ソフトウェアデファインド(SDx)は対象の機能をソフトウェアで定義するものです。ソフトウェアの持つ柔軟さから、SDxで対象製品やサービスの企画から実装、運用までのアジリティを向上させるキモになります。
しかしこのソフトウェアデファインドにも欠点があります。その多くはソフトウェアが根源的に持つ欠点に由来します。ソフトウェアの欠点とはその柔軟さにあります。柔軟さはソフトウェアの最大の利点ですが、柔軟さが故の欠点の原因にもなっています。ここではこれを見ていくことにします。
いい加減な企画・仕様 - 開発時
ソフトウェアデファインドでは、ソフトウェアで機能を柔軟に定義することができることから、逆に後で決めればいいという後回しの考えで企画立案や仕様制定がいい加減になってしまう可能性があります。
なお「いい加減」はいいことも悪いことにも依存しない中立的な意味ですが、この場合は悪い意味です。また「適当」も「いい加減」と同様に中立的な意味です。いい加減で適当です。
これはソフトウェアの持つ根源的な欠点であり、アジャイルソフトウェア開発ではその傾向があります。この意味ではSDxとアジャイル開発はよく似ています。
いい加減な実装・テスト - 開発時
これもソフトウェアの柔軟さから由来する欠点ですが、製品やサービスの実装がいい加減で適当なものになります。たとえば使いにくい機能でも後で変更すればいいと考え、適当な機能実装になってしまいます。
あまつさえ、機能にバグがあっても後でデバッグすればいいと考え、出荷テストがいい加減になってしまうことさえあります。
これもアジャイル開発にある欠点と同様です。もちろん、ソフトウェアデファインドもアジャイル開発もこの欠点を許容しているわけではなく、この欠点を生み出す傾向性があることです。
遅い実行速度 - 利用時
ソフトウェアで機能を実装することは、ハードウェアで機能を実装する場合と比較して、機能の実行速度は遅くなる傾向があります。例えば、電源ボタンを押しても、直ぐに電源が入ったり切れたりしません。これは裏でソフトウェアが色々としているからです。
もちろん全体のハードウェアの実行速度が向上すれば、ソフトウェアによる遅延は無視できる程度になります。このときは気にする必要はないでしょう。
面倒なバージョンアップ - 利用時
SDxの利点であるバージョンアップも、利用者からみれば、面倒なものです。そもそも最初からあるべき機能がバージョンアップという名前で後で追加されただけです。これは利用者に対する欺瞞もいいところです。
もちろんバージョンアップされないSDxは最悪です。バージョンアップがないSDxはSDxではありません。
使えない/バグが多い機能 - 利用時
これは開発時のいい加減な実装・テストの裏返しになりますが、利用者にとっては使えない機能があったり、あまつさえバグがある機能があったりすると、これは最悪です。
ソフトウェアデファインドがユーザファーストになるか、ユーザラストになるかは運命の分かれ道になるのが、これになります。
ソフトウェアデファインドのトレードオフ
前節の「SDxの利点」で紹介したSDxの利点と今回の欠点は、裏表の関係になっています。つまり両者は同じものですが、その主従がどちらにあるかだけです。
SDxが利点を活かせるのか、欠点で使えないものになるのかは、このトレードオフに掛かっています。これを決めるのはユーザです。ユーザファーストこそ、SDxの決め手になります。これをキモにしてSDxを実現していきましょう。
SDxマンガFAQ案内
前節:ソフトウェアデファインドの利点 次節:SDxと従来との違い
いいなと思ったら応援しよう!
![五味弘](https://assets.st-note.com/production/uploads/images/138020459/profile_6d4ce6cd20d18410d612304666e1e338.jpg?width=600&crop=1:1,smart)