1. 序章

最近のSoftware-as-a-Service（SaaS）の時代から、ソフトウェア開発は困難な決定に直面しました。ユーザーが使用する独自の製品ラインを定義できる汎用ソフトウェアを作成するか、ユーザーを特定の方法に導くソフトウェアを開発するかです。タスクを実行するには？

したがって、一方では、ユーザーがタスクを実行するための複数の一般的な方法を提供するソフトウェアがあります。 ただし、反対側には、ユーザーが同じタスクを実行するための専用のワークフローを提供するソフトウェアがあります。 これらの戦略の長所と短所は、意見のないソフトウェアと意見のあるソフトウェアについての議論の基礎です。

このチュートリアルでは、意見のないデザインと意見のあるデザインの概念を調査します。最初に、ターゲットの概念につながったソフトウェア設計に関する簡単なレビューを示します。 したがって、意見のないソフトウェアの概念を理解します。 次に、意見のあるソフトウェアの設計がどのようになっているのかを見ていきます。 最後に、体系的な要約でチュートリアルを締めくくります。

2. 私たちはどうやってここへ来ましたか？

クラウド時代以前は、ソフトウェアソリューションは通常、店舗でシンプルな製品として交渉されていました。 これは、このシナリオでは、製品を選択して支払いを行い、ソフトウェアを希望どおりに使用することを意味します。

説明されたモデルは、確かに、今日でも機能します。 ただし、いくつかの潜在的な落とし穴があります。 たとえば、1回限りの購入ソフトウェアが関連する更新を受け取らない場合があります。 そのため、ユーザーは非推奨のソリューションを長期間使用し続ける必要があります（新しいバージョンのソフトウェアライセンスを購入するまで）。

時間の経過とともに、クラウド時代の台頭により、ソフトウェアをネゴシエートするための新しいモデルがもたらされます。 今では、ソフトウェア自体とそれを実行するためのインフラストラクチャの両方を提供して、ソフトウェアをオンデマンドで販売することが実行可能になります。 ソフトウェアは非常に動的になり、ソリューションはクラウドでホストされ、いつでもどこでも使用および更新されます。

この動きは「as-a-Service」モデルとして知られるようになりました。 私たちの特定のケースでは、Software-as-a-Serviceです。

このモデルにより、業界は顧客にソフトウェアソリューションを提供する方法を再考することになりました。 ソフトウェアワークフローをより柔軟または効率的にしますか？ 一般的なサービスまたは専門的なサービスを販売しますか？ これらの考えはすべて、意見のないソフトウェアや意見のあるソフトウェアの概念に浸透しています。

意見の概念は歴史的に存在し、さまざまなシナリオ（たとえば、プログラミング言語のコンテキスト）に適合していることに注意する必要があります。 しかし、ソフトウェア開発の最近の傾向は、この議論を温めました。

3. 意見のないデザイン

意見のない設計に関する主なアイデアは、システムユーザーが自分で決定を下す完全な能力を持っているということです。これは、通常、システムがタスクを実行するためのいくつかの方法を提供し、ユーザーが選択できることを意味します問題と状況に応じて最適なもの。

意見のないソリューションのキーワードは柔軟性です。タスクを実行するための複数のマナーを提供することにより、意見のないソリューションは意思決定においてユーザーを信頼します。 したがって、物事を行うためのグローバルな正しい方法はありませんが、実際には、ユーザーの判断とリソースに応じて最適な方法が1つあります。

ただし、対処するための優れた柔軟性を持つことは、いくつかの課題ももたらします。 1つの例は、スプレッドシートエディタで構成されています。 通常、これらのプログラムを使用すると、ユーザーは異なる構造を作成して、同じデータを保持および処理できます。 したがって、非効率的なスプレッドシートを採用すると、より効率的なスプレッドシートと比較して、作業コストが大幅に高くなる可能性があります。

同様に、PERLやPHPなどのジェネリックプログラミング言語を使用してソフトウェアを開発する際の誤った決定は、最終的なソフトウェアの複雑なワークフローにつながる可能性があります。

要約すると、意見のないソリューションを採用するということは、道路上の複数の分岐に直面し、すべてが同じ場所につながることを意味します。 したがって、より適切な選択は、利用可能なリソースにより適したものです。

次の画像は、意見のないソフトウェアを使用する場合の意思決定の背後にある中心的な考え方を直感的に示しています。

4. 意見のあるデザイン

一般に、意見のあるデザインは、タスクを実行する正しい方法を示すオラクルと見なすことができます。したがって、意見のあるソリューションは、リソースと、それらをどのように使用するかについての明確な兆候を提供します。

ただし、この特性は、意見のあるソリューションが常に単一の方法（「正しい」方法）を提供することを意味するものではありません。 実際、ユーザーは通常、アドバイスされたワークフロー以外のワークフローを採用できます。 しかし、そうすると、おそらくユーザーはタスクを実行するのに困難と潜在的な問題に直面するでしょう。

意見のある設計に関する重要な課題は、問題が解決策に適合するかどうかを評価することです。 したがって、問題がソリューションリソースおよびワークフローと一致する場合、意見のあるソフトウェアを選択することで、ユーザーは問題を迅速に解決し、最終結果で優れた品質を得ることができます。

それ以外の場合、問題が解決策と一致しない場合は、別の意見のある解決策（より適切な解決策）または意見のない解決策を選択することをお勧めします。

意見のある解決策の有名な例は、wikiページです。 Wikiは、HTMLとCSSの知識がなくても（またはほとんど知識がなくても）Webページのコンテンツを更新するための独創的なデザインです。 したがって、目的のWebページがWikiページに収まる場合は、ページのソースコード全体を開発する代わりに、はるかに簡単で迅速に使用できます。

プログラミングフレームワークに関しては、次に、意見のある設計の例はRubyonRailsです。

要するに、意見のあるデザインは、レンタカーで複数の交通標識のある道路を走行することに似ています。 したがって、道路をたどるのは非常に簡単ですが、道路を出るのは悲惨な決断かもしれません。

次の画像は、直感的な例を考慮した、意見のあるデザインの概念を示しています。

5. 体系的な要約

前のセクションでは、ソリューションがユーザーとどのように相互作用するかについて、意見のない、意見のある設計を調査しました。

要約すると、主な違いは柔軟性に関するものです。意見のない設計は、同じタスクを実行するためのさまざまな方法を促進します。 意見のあるデザインは、通常、タスクを達成するための「正しい方法」を提示します。

このシナリオでは、柔軟性が長所または短所になる場合があります。 主な利点は、ユーザーがリソースとコンテキストに応じて独自の決定を行えるようにすることです。 ただし、不適切な決定を行うと、システム全体またはプロセス全体のパフォーマンスが低下する可能性があります。

次の表は、いくつかの特性を比較し、意見のないデザインと意見のあるデザインの例を示しています。

最後に、意見のないデザインと意見のあるデザインの間に中庸が存在することに注意することは重要です。 これは、タスクを実行するための強力な規則を定義しながら、ユーザーに高い柔軟性を提供することで実現できます。 このようなシナリオでは、ユーザーは物事を行うための「正しい方法」を持っていますが、コンテキストや問題の特殊性に取り組むことができます。

6. 結論

このチュートリアルでは、意見のないデザインと意見のあるデザインの概念を学びました。 最初に、これらの設計に関する最近の議論について簡単な説明を得ました。 したがって、私たちは意見のないデザインを検討しました。 次に、同様に、意見のあるデザインを調査しました。 最後に、体系的な要約で概念の概要と比較を行いました。

テクノロジーとソフトウェアの世界における最新のビジネスモデルでは、意見のないソフトウェアと意見のあるソフトウェアについての議論が話題になりました。 当然、考慮すべきそれぞれに関して、さまざまな長所と短所があります。 ただし、結局のところ、どちらを採用するかは、ユーザーの目的と実行するタスクの要件によって異なります。