開発者はビジネスドメインを理解する必要がありますか、それとも仕様で十分ですか？
私は電子工学の高度なテクノロジーであるためドメインを理解することが本当に難しい会社で働いていますが、これは複雑なドメインでのあらゆるソフトウェア開発に当てはまります。
私が取り組んでいるアプリケーションには、ドメインでの経験がなければ理解するのが難しい多くの情報、グラフ、およびメトリックが表示されます。開発者は、仕様を使用して、ソフトウェアが実行する必要があることを説明します。たとえば、特定のグラフがこの種のメトリックを表示する必要があり、このメトリックが次の算術式であることを指定します。
このようにして、開発者は実際にはビジネスを理解しておらず、このタスクを実行している/理由を理解していません。仕様が本当に詳細であればこれで問題ありませんが、詳細ではない場合、または作成者がユースケースを忘れた場合、開発者が解決策を見つけるのは非常に困難です。
一方、すべての開発者にすべてのビジネス面をトレーニングすることは、非常に長く困難な場合があります。
詳細な仕様をもっと重視する必要がありますか（ただし、ご存知のように、完全な仕様は存在しません）、ビジネスドメインを理解するようにすべての開発者をトレーニングする必要がありますか？
編集：会社が外部の開発者を使用する可能性があり、すべてのドメインへのフォーメーションが約2週間になる可能性があることを覚えておいてください
仕様は事実上決して十分ではありません。ドメインの知識がない開発者は、仕様に誤りがある場合（ほとんどの場所で頻繁に発生します）を指摘できず、設計の選択が不十分です。
私の経験では、現在3つの非常に異なる業界で働いているので、ドメインについてあまり知らないところから始めることができますが、最終的にはそれを学ぶ必要があり、誰かがそれを詳細に理解する必要があります。
本質的な問題はクライアント開発者のインピーダンスにあります。彼らは何かを求めていますが、彼らがそれを見たときにのみそれを知って、あなたは彼らの問題を解決したいが、その問題が何であるかを常に明確に知ることができない場合があります。あなた（開発者）がもたらすことができる（クライアントの）業界に関するドメイン知識が多ければ多いほど、漠然とした「欲求」を具体的な「問題」に変換して解決することがより簡単になります。
事例として、私の以前の仕事はプラント管理ソフトウェアを含む化学産業でした。私はドメインの知識を事実上ゼロから始めましたが、上級開発者とクライアントから提示されたサブ問題を解決するために必要なコードを実装することができました。時間が経つにつれ、クライアントのレベルでより簡単にコミュニケーションが取れるように、業界を学ぶ努力をしました。私は彼らの業界を理解するにつれて、実際の問題が何であるかを理解し始めました。彼らが「このモジュールのすべてのデータ値を追跡する必要がある」などのことを言うとき、私はそれを彼らが実際に意味すること、つまり「このセンサーが生成する各値の履歴記録をX日間保存する必要がある」に変換できます。保持されますが、常にそのセンサーからの最新の読み取りに基づいて評価されます。」多くのドメインの問題には、クライアントが内部化した非表示のルール（データの保持期間など）がありますが、明示する必要があります。
つまり、ドメインの問題はコードの問題ではなく、2つの間の変換は簡単ではないため、誰かがドメインの知識、できれば開発者を必要とします。最終的には、チームを維持する価値のある開発者はドメインを取得する必要があります。そうすることで、コードのニュアンスについてより多くの情報に基づいた選択を行うことができます。
プロジェクトの誰かは、かなり完全なドメイン知識を持っている必要があります。その人は開発者である場合とそうでない場合があります。
アジャイルプロジェクトでは、クライアントプロジェクトのオーナーはその人であり、彼らはチームと協力して密接に作業しています。非アジャイルプロジェクトでは、チームの誰かがその知識を習得する必要がありますが、通常はそうではありません。これが、非アジャイルプロジェクトが失敗しやすい理由の1つです。
英語しか知らない人と日本語しか知らない人を部屋に入れると、それぞれの言語のエキスパートであるにもかかわらず、日本語から英語に翻訳することができません。同じ理由で、ドメインの知識がないエキスパートプログラマでも、ソフトウェア開発のエキスパートではない最高のドメインエキスパートに24時間年中無休でアクセスできる場合でも、何を構築する必要があるかを理解することはできません。
仕様は、ドメイン要件の「日本語」をプログラミング要件の「英語」に変換する試みです。グーグル翻訳に匹敵する翻訳品質を手に入れたら、それはあなたのラッキーな日です。ほとんどの場合、品質はそこにはありません。そのため、少なくともsomeドメインの知識を習得する方法はありません。ある程度の持続性があれば、プロジェクトの終わりまでにまともな「翻訳者」になるので、会社に対するあなたの価値が大幅に高まります。ほとんどの場合、あなたはその過程で多くの楽しみを持っているので、それは双方に有利な状況です。
すばらしい答えがたくさんあります。それらを読んで検索した後、誰も重要な問題について言及していないことがわかったので、自分のものを追加します：バグ.
チームに十分な権限とドメインの専門知識を持つ十分な人々が提供されていない場合、遅かれ早かれバグが入り込むことになります。ドメインの知識を考えると、不可能、または無意味な値/結果/関係があります。仕様が明示的に指摘することを期待することもできますが、実際に到達できる最善の方法は、最も明白なものを回避することです（金利がマイナスになった場合に警告するなど）。注目に値するほど奇妙です）。
これは、選択の理由を理解することに強く関連しており、最良のケースでは、より良いソフトウェアにつながります（要求の背後にある理由を実際に知っている場合、それを所定のものとして受け入れる必要はなく、考えることができるためです） ）。
アインシュタインが言った 「しかし、式ではなく思考とアイデアがすべての物理理論の始まりです。」 つまり、抽象的な式ではなくアイデアで考えるということです。 ..
ビジネス知識のいくつかの側面がなければ、質問をせず、仕様が言うことを無意識にコーディングしない開発者になってしまいます。キーボードを強打できる人だけでなく、優れたソフトウェアを作るには「考える人」が必要だと思います。 「何をしているのか」だけでなく「なぜ」を理解し、全体像にどのように適合するかを理解することで、開発チームの満足度が高まります。
ドメインの知識を身に付けてみるべきだと思います。仕様は、最終製品が何をすべきかを示すチェックリストであり、製品の検証に必要です。開発者は常に理解を試みる必要があります解決しようとしている実際の問題は何ですか。ドメインの知識を取得すると、その理解に役立ちます。
変更部分（ルールセットなど）が何であるかを理解し、それらを個別に配置することで、設計とコーディングが容易になります。 マスターになる必要はありませんが、エンドユーザーと自分の言語で話すことができます。
あなたはそれの基本的な知識で車を運転することができます。乗り心地を楽しみたい場合は、正確な使い方を学ぶ必要があります。他の取引と同様に、ドメインを理解することは必須ではありませんが、それを行うと楽しいです。
ビジネスを知っている開発者は、金の価値があると思います。
ビジネスにいくつかの要件があり、いくつかの ビジネスアナリスト がそれらを技術的な要件に変換する「伝統的な」シナリオでは、開発者は必然的に次の2つのことが起こり得るものを取り除きます。
複数の障害点があります。ビジネスアナリストがすべてのビジネス要件を完全に翻訳していない場合や、開発者がそれらを完全に技術仕様に翻訳していない場合があります。 「部屋の秘密」シナリオのバリアント。コミュニケーションの緊急事態。
ビジネスオーナー、ビジネスアナリスト、または開発者の1人またはすべてが、組織にとっては初めてであり、通常は考えられない重要な項目を見逃してしまいます。ビジネスを熟知している経験豊富な開発者は、製品をより完全にするために、それらの他の役割の人々を教育するのに役立ちます。
ほとんどの場合、仕様の各機能の値、仕様をどれだけ厳密に実装する必要があるか、仕様の機能の任意の組み合わせを満たすコストとの間でトレードオフが発生します。多くの場合、上記のすべてを実行する知識が1人、または実際のソフトウェアアーキテクトやコーダーを含む密接に連携しているチームに存在する場合にのみ、適切なトレードオフを行うことができます。
そのような極端に局所化された知識、そして恐らく直感さえもなければ、結果は、書かれた仕様に非常に厳密に適合する非常に高価でほとんど役に立たない製品として簡単に終わる可能性があります。
上記の問題がない仕様を作成するコストは、多くの場合、あまり詳細に記述されていない仕様で作業するための十分なドメイン知識を習得するためにアーキテクトやコーダーにトレーニングするよりも高くなる可能性があります（合法性とビジネス契約でこれが許可されている場合）。
貿易の基礎を学ぶことにほとんど関心を示さない開発者と協力し、時にはそれらの基礎について知る必要がないことを誇らしげに思えるビジネス側からの誰かとして答えたいと思います：問題は、開発者は、一目で結果の誤り（信じられない結果、間違った兆候など）を見ることができなくなります。これには、詳細なテストケース（最近まで開発していませんでした）または結果の継続的な監視が必要です。これまでのところ、コミュニケーションを容易にするためにソフトウェア開発の基本を学びたいと思っている限り、開発者にも同じようにしてもらいたいと思います。
必須ではありませんが、なぜしたくないのですか？
気が進まなくて、特にある程度ドメインを学ぶことができなかったプログラマーを心配します。時々「象牙のコードタワー」から抜け出すことが重要です。
コードがどのように使用され、どのような目的でコードが作成されているかは、恐ろしい仕事のように聞こえます。大聖堂を建てようとしているときに、レンガを壊したい人はいますか？
開発者が関与するほど、ビジネスの上級者になるほど、少なくとも中級レベルのドメイン知識を持つことが重要になります。または、重要である可能性がある業界の微妙な領域は、開発者チームには理解されません。
ただし、仕様は下位レベルのタスクには十分なはずです。要するに、労働力をより低いレベルに訓練することが最善です。彼らは世界で最高のポリグロットプログラマーかもしれませんが、問題をかなり深く理解できない場合、彼らは常に失敗または死の行進プログラミングに運命づけられています。
はい、開発者はある程度ビジネスを知る必要があります。細かいことをすべて知っている必要はありませんが、Xがどのような目的で使用され、ビジネスプロセスでどのように使用されるかについての基本的な知識が必要です。開発者がビジネスについて理解を深めるほど、提供できるソリューションが向上します。
私の経験*に基づいて、問題ドメインの十分な知識とソフトウェア開発の十分な知識を持つ1人の個人が、問題ドメインの優れた知識を持つ1人と優れた知識を持つ1人の2人よりも、問題の最適な解決策を見つける可能性が高くなりますソフトウェア開発の共同作業。
個人の脳内で起こるコミュニケーションは、個人間のコミュニケーションより何倍も速くて良いという単純な事実に帰着すると思います。
*私がこの質問に答えるために利用している主な経験は、会計ソフトウェアパッケージの開発（開始から「メンテナンスモード」まで）に10年以上費やされたことです。ソフトウェア開発に関する私の知識は同僚と比較してかなり良かったのですが、問題の領域に対する理解の欠如にしばしば不自由を感じました。
開発者が企業/業界に長期間滞在する場合、開発者はゆっくりですが確実に「ビジネス」を学びます。
一部の企業は、「ビジネス」のトレーニングを認め、提供しています。金融会社はこの良い例です。
ビジネスを学べば学ぶほど、ユーザーと話しやすくなります。彼らはあなたにもっと自信を感じるでしょう。システムがユーザーの期待どおりに動作しない場合、システムがどこで問題を起こす可能性があるのかについて、より簡単に理解できます。
あなたの質問に答えるために、仕様は私の経験では決して十分ではありません。一般的な問題は、十分な情報が含まれていないことが多く、すぐに古くなってしまうことです。
一部の企業では、ビジネスドメインの経験が必須になる場合があります。彼らは、採用する際に、ドメインでの経験を持つ開発者を探します。一部の企業は、これを実際の技術スキルよりも高くしています。 （経済的な経験はなく、インタビューは非常に一般的です。確かに英国ではここです）。
some仕様は常に存在する必要があります-すべての開発者がドメインの専門家になることを期待することはできません。同時に、開発者が仕様が何であるかを実際に理解せずに盲目的に仕様に従うと、クライアントが望んでいる結果が得られない可能性があります。開発者がある程度まともな（しかし専門家ではない）レベルの理解さえ持っていると、仕様のエラーや脱落をキャッチできることがよくあります。彼らはまた、最終製品をより良くすることができるプロセスに貢献し、フィードバックを与えることができます。
クライアントと開発者を連携させて、開発者の理解を深め、仕様の作成を支援するドメインの専門家を雇う価値があるかもしれません。
どちらにしても答えは難しいと思います。
たとえば、フリーランスの開発者が、開発するすべてのアプリケーションの背後にあるビジネス（または科学）をどのように理解できるかを理解するのは困難です。この状況では、ビジネス自体を実際に理解するよりも、開発者が仕様やビジネスモデルについて適切な質問をすることを知っていることが重要だと思います。
一方、エンタープライズ開発者は、同じビジネスにしばらく携わっていたとしても、数か月後（またはおそらく数年後）にビジネスがどのように機能するかを学んだはずです。大規模なチームでは、開発者よりもビジネスをより明確に理解するアーキテクトがいる場合もあります。
孤独な開発者がいる中小企業では、開発者がオーナーやマネージャーと頻繁に話し合い、間違ったことを行ったり実装したりしないようにすることが重要です。
したがって、これについて考えられる方法はたくさんありますが、キーはすべての場合で同じですcommunication。
ソフトウェア開発は、私が知っている唯一の職業であり、自分の職業に精通しているだけでなく、自分が働いている職業の基本を理解している必要があります。クライアントと通信するためのドメインを十分に理解することが重要です。クライアントの言語で他の開発者。開発者として、あなたは常に他の人にあなたを訓練することに頼ることはできません。時々、個人的な調査で自分自身で立ち上げなければならず、しばしば典型的な労働時間外の時間です。
私が観光業界の会社として同じ問題に直面したので、ここであなたが何を意味するのか本当に理解しています。私がジュニア開発者だったとき、私は大学で観光も勉強していました。だから、私はコンピューターサイエンスの出身ではないが、私の観光知識は高いと推測できます。
私たちは当時、他のソフトウェア会社との関係で製品を構築していましたが、ドメイン固有の知識は多くありませんでした。おっしゃるように、分野横断的な懸念が多いなど、観光業で商品を作るのは難しいですね。
したがって、この動きは長期的には多くの悪い結果をもたらしました。その後、私たちは大きな一歩を踏み出し、私はプロジェクトのビジネス部分ではなく開発のみに焦点を合わせ始めました。私は産業知識とプログラミング知識を持っているので、プロジェクトはこれまで以上に効率的に成長します。言うまでもありませんが、私はコインの両面での経験があるので、より迅速に決定を下すことができます。
あなたの質問への具体的な回答として、それは私の個人的な意見では確かにイエスです。チームが取り組んでいるプロジェクトが長期的なプロジェクトである場合は、難しい道を進み、ドメイン固有の基本事項と詳細についてスタッフをトレーニングします。
個人的な経験から、ドメインの知識を持っているチームの誰かがあなたと協力している限り、仕様で十分です。
私は非常に専門的な業界で働いています。私たちは放送メディア用のソフトウェアを作っています。放送についてはほとんど知りませんが、コードとデータについては知っています。プロジェクト管理チームには、放送について理解している優秀な人材がいます。この式は、過去数年間、クライアントが好む優れた機能を思いつくために十分なものでした。