開発者はビジネスドメインを理解する必要がありますか、それとも仕様は十分ですか？

私は、電子工学の高度な技術であるためにドメインを理解するのが本当に難しい会社で働いていますが、これは複雑なドメインでのソフトウェア開発に適用できます。

私が取り組んでいるアプリケーションには、ドメインでの経験がなければ理解が難しい多くの情報、グラフ、およびメトリックが表示されます。開発者は、特定のチャートにこの種のメトリックを表示する必要があることを指定するなど、ソフトウェアが何をする必要があるかを記述する仕様を使用します。このメトリックは次の算術式です。

この方法では、開発者は実際にビジネスと彼がこのタスクを行っている理由を理解していません。仕様が非常に詳細な場合でも問題ありませんが、仕様が詳細でない場合、または作成者がユースケースを忘れた場合、開発者が解決策を見つけるのは非常に困難です。

一方、すべての開発者をすべてのビジネス面でトレーニングすることは非常に長く困難な場合があります。

詳細な仕様をもっと重視する必要がありますか（しかし、私たちが知っているように、完全な仕様は存在しません）、またはビジネスドメインを理解するようにすべての開発者を訓練する必要がありますか？

編集：会社は外部の開発者を使用でき、すべてのドメインの編成は約2週間になる可能性があることを念頭に置いてください

仕様は事実上決して十分ではありません。ドメインの知識を持たない開発者は、仕様に誤りがあることを指摘することはできず（ほとんどの場所で頻繁に発生します）、設計の選択が不適切です。

私の経験では、非常に異なる3つの業界で働いていたので、ドメインについてあまり知らない状態から始めることができますが、最終的にそれを学ぶ必要があり、誰かがそれを詳細に理解する必要があります。

本質的な問題は、クライアントと開発者のインピーダンスにあります。彼らは何かを望んでいますが、それを見たときだけ知っているので、あなたは自分の問題を解決したいのですが、その問題が何であるかを常に明確に知ることはできません。（クライアントの）業界のドメイン知識があれば、開発者はそれをより簡単に、曖昧な「欲しいもの」を具体的な「問題」に翻訳して解決することができます。

逸話的な例として、私の以前の仕事は、プラント管理ソフトウェアを含む化学産業でした。ドメインの事実上ゼロの知識から始めましたが、上級開発者とクライアントから提示されたサブ問題を解決するために必要なコードを実装することができました。時間が経つにつれて、クライアントのレベルでより簡単にコミュニケーションできるように、業界を学ぶ努力をしました。彼らの業界を理解するにつれて、私は実際の問題が何であるかを理解し始めました。「このモジュールのすべてのデータ値を追跡する必要がある」などと言ったら、それを本当に意味するものに変換できます。つまり、「このセンサーが生成した各値の履歴保持されますが、常にそのセンサーからの最新の読み取り値に基づいて評価されます。」

そのため、ドメインの問題はコードの問題ではなく、2つの間の翻訳は簡単ではないため、誰かがドメインの知識を必要とし、できれば開発者が必要です。最終的には、チームで維持する価値のある開発者はドメインを選択する必要があります。そうすれば、コードのニュアンスについてより多くの情報に基づいた選択を行えるようになります。

プロジェクトの誰かがかなり完全なドメイン知識を持っている必要があります。その人は開発者である場合とそうでない場合があります。

アジャイルプロジェクトでは、クライアントプロジェクトの所有者はその人であり、彼らはチームと協力して緊密に協力しています。非アジャイルプロジェクトでは、チームの誰かがその知識を習得する必要がありますが、通常はそうではありません。これが、非アジャイルプロジェクトが失敗しやすい理由の1つです。

多くの優れた答えがあります。それらを読んで検索した後、誰も重要な問題に言及していないことがわかったので、私は自分自身を追加します：バグ。

チームに十分な権限とドメインの専門知識を備えた十分な人員が提供されていない場合、遅かれ早かれバグが避けられません。ドメインの知識を考えると、不可能または無意味な価値/結果/関係があります。仕様が明示的にそれらを指摘することを望むかもしれませんが、実際にはあなたが到達できる最善の方法は最も明白なものを避けることです（金利がマイナスになった場合、またはそのようなことを私に警告してください-これはエラーである可能性がありますが、注目に値するほど奇妙な）。

これは、選択の理由を理解することに深く関係しており、最良の場合には、より良いソフトウェアにもつながります（要求の背後にある理由を実際に知っている場合、それを与えられたものとして受け入れるのではなく考えることができるからです） ）。

アインシュタインは「しかし、公式ではなく思考とアイデアがすべての物理理論の始まりだ」と言ったことを覚えておいてください。つまり、抽象的な公式ではなくアイデアについて考えるのです...

英語のみを知っている人と日本語のみを知っている人を部屋に置いた場合、それぞれの言語の専門家であるにもかかわらず、日本語から英語に翻訳することはできません。同じ理由で、ソフトウェア開発の専門家でもない最高のドメインエキスパートに24時間365日アクセスできる場合でも、ドメインの知識のないエキスパートプログラマでさえ、構築する必要があるものを理解することはできません。

仕様は、ドメイン要件の「日本語」をプログラミング要件の「英語」に翻訳する試みです。Google翻訳に匹敵する翻訳品質が得られたら、それはあなたの幸運な日です。ほとんどの場合、品質はそこにないだけなので、少なくともいくつかのドメイン知識を取得する方法はありません。ある程度の持続性があるため、プロジェクトの終了までに適切な「翻訳者」になるため、会社に対する価値は大幅に高まります。ほとんどの場合、あなたはその過程で多くの楽しみも持っているので、それは双方にとって好都合な状況です。

ビジネス知識の何らかの側面がなければ、質問をせずに仕様書の内容を不注意にコーディングする開発者になってしまいます。キーボードを叩く人だけでなく、優れたソフトウェアを作るには「Thinkers」が必要だと思います。「何を」しているのかだけでなく、「なぜ」とそれがどのように全体像に当てはまるのかを理解することは、開発チームの満足度を高めるのに役立ちます。

ドメインの知識を得るようにしてください。仕様は、最終製品が何をすべきかを示すチェックリストであり、製品の検証に必要です。開発者として、あなたが解決しようとしている本当の問題は何かを常に理解しようとするべきです。ドメインの知識を得ると、それを理解するのに役立ちます。

変更部分（ルールセットなど）を理解し、それらを個別に配置するので、設計とコーディングが簡単になります。あなたはそれでマスターである必要はありませんが、彼らの言語でエンドユーザーと話すことができるでしょう。

基本的な知識があれば車を運転できます。しかし、乗り心地を楽しみたい場合は、正確に使用する方法についてさらに学ぶ必要があります。他の取引と同様に、ドメインを理解することは必須ではありませんが、それを行うと楽しいです。

私は、ビジネスを知っている開発者は、金の重さの価値があると思います。

ビジネスにいくつかの要件があり、一部のビジネスアナリストがそれらを技術的な要件に変換する「従来の」シナリオでは、開発者は必然的に2つのことが起こる可能性があるものから作業を行います。

1. 複数の障害点があります。ビジネスアナリストがすべてのビジネス要件を完全に翻訳していない場合や、開発者がそれらを技術仕様に完全に翻訳していない場合があります。「部屋の周りの秘密」シナリオの変形。コミュニケーションの緊急性。

2. ビジネスオーナー、ビジネスアナリスト、または開発者の1人または全員は、通常考えられない重要な項目を見逃すほど組織に新しい人です。ビジネスを熟知しているベテランの開発者は、他の役割の人々を教育して製品をより完全なものにすることができます。

ほとんどの場合、仕様の各機能の価値、仕様をどの程度実装する必要があるか、仕様機能の組み合わせを満たすコストの間にはトレードオフがあります。多くの場合、上記のすべてを実行するための知識が1人、または実際のソフトウェアアーキテクトやコーダーを含む密接に作業しているチームに存在する場合にのみ、適切なトレードオフを行うことができます。

そのような極度にローカライズされた知識と、場合によっては直感さえなければ、結果は、書面での仕様に非常に近い非常に高価でほとんど役に立たない製品として簡単に終わる可能性があります。

上記の問題のない仕様を作成するコストは、アーキテクトおよび/またはコーダーを訓練して、あまり詳細ではない仕様で作業するのに十分なドメイン知識を持たせるよりも多くの場合があります（合法性およびビジネス契約がこれを許可している場合）。

はい、開発者はある程度ビジネスを知る必要があります。彼らは毎分詳細を知る必要はありませんが、レポートXの用途とビジネスプロセスでの使用方法に関する基本的な理解が必要です。開発者がビジネスについて理解すればするほど、提供できるソリューションは向上します。

私の経験*に基づいて、問題領域の知識とソフトウェア開発の知識を持つ一人の個人は、問題領域の優れた知識と優れた知識のある2人よりも問題の最適な解決策を見つける可能性が高いです。一緒に働くソフトウェア開発の。

単一の個人の脳で起こるコミュニケーションは、個人間のコミュニケーションよりも何倍も速くて良いという単純な事実に帰着すると思います。

*この質問に答えるために私が描いている主な経験は、会計ソフトウェアパッケージの開発に10年以上費やしたことです（開始から「メンテナンスモード」まで）。ソフトウェア開発に関する私の知識は同僚と比較してかなり良かったのですが、問題の領域に対する理解が不足していることで障害を感じることがよくありました。

私はビジネス側から来て、取引の基本を学ぶことにほとんど関心を示さない開発者と仕事をする誰かとして答えたいと思います、時にはそれらの基本を知らなくてもよいことを誇りに思っているようです：問題は開発者は、一見しただけでは結果の誤り（疑わしい結果、間違った兆候など）を見ることができません。詳細なテストケース（最近まで開発されていませんでした）または結果の継続的な監視が必要です。これまでのところ、コミュニケーションを容易にするためにソフトウェア開発の基本を学ぼうとする限り、開発者にも同じことをするよう促したいと思います。

する必要はありませんが、なぜしたくないのですか？

私は気が進まないプログラマーで、特にある程度ドメインを学ぶことができないプログラマーを心配しています。「アイボリーコードタワー」から抜け出すことが重要です。

コードがどのように使用されるのか、どのような目的のためにひどい仕事のように聞こえるかわからないコードを書く あなたが大聖堂を建てることができるとき、誰がただレンガを壊したいですか？

開発者がより深く関与し、ビジネスの上級者になるほど、少なくとも中レベルのドメイン知識を持つか、その業界の重要な可能性のある微妙な分野を開発チームが理解できないことが重要になります。

ただし、低レベルのタスクには仕様で十分なはずです。要するに、労働力をより低いレベルに訓練することが最善です。彼らは世界で最高のポリグロットプログラマかもしれませんが、問題をかなり深く理解できない場合、彼らは常にプログラミングを失敗または死に追いやる運命にあります。

常に何らかの仕様があるはずです-すべての開発者がドメインの専門家になることを期待することはできません。同時に、開発者が何のためにあるのかを本当に理解せずに盲目的に仕様に従っている場合、結果はクライアントが望んでいるものとは異なる場合があります。開発者がある程度適切な（専門家ではない）レベルの理解さえ持っている場合、仕様の誤りや欠落を見つけることができることがよくあります。彼らはまた、最終製品をより良くするプロセスに貢献し、フィードバックを与えることができます。

クライアントと開発者を連携させて、開発者に理解を深め、仕​​様の作成を支援することを仕事とするドメインエキスパートを採用する価値があるかもしれません。

どちらの方法でもこれを答えるのは難しいと思います。

たとえば、フリーランスの開発者が、開発するすべてのアプリケーションの背後にあるビジネス（または科学）をどのように理解できるかはわかりにくいです。この状況では、ビジネス自体を本当に理解するよりも、開発者が仕様やビジネスモデルについて適切な質問をすることを知っていることが重要だと思います。

一方、エンタープライズ開発者は、同じビジネスにしばらく携わっていると仮定して、数か月後（またはおそらく数年後）にビジネスがどのように機能するかを実際に学習する必要がありました。大規模なチームでは、開発者よりもビジネスをより明確に理解するアーキテクトがいる場合があります。

孤独な開発者を抱える中小企業では、開発者がオーナー/マネージャーと頻繁に話し合い、間違ったことを実行しないようにすることが重要です。

したがって、これについて考えられる多くの方法がありますが、キーはすべての場合で同じです：コミュニケーション。

ソフトウェア開発は私が知っている唯一の職業であり、それはあなたがあなた自身の職業に堪能であるだけでなく、あなたが働いている職業の基本的な理解を必要とすることです。クライアントの言語の他の開発者。開発者として、常に他の人に頼ってトレーニングすることはできません。時には、通常の勤務時間外の時間に、個人的な調査で自分で調査する必要がある場合があります。

観光業界の企業として、私たちも同じ問題に直面していたので、私はあなたがここで何を意味するか本当に理解しています。私がジュニア開発者だったとき、私は大学で観光についても勉強していました。ですから、私はコンピューターサイエンスのバックグラウンドから来たのではなく、観光に関する知識が高いと推測できます。

当時は他のソフトウェア会社との関係で製品を構築していましたが、ドメイン固有の知識は多くありませんでした。あなたが説明したように、多くの分野横断的な懸念などがあるため、あなたが観光産業で製品を構築している場合、それを正しくするのは本当に難しいです。

したがって、この運動は長期的に多くの悪い結果をもたらしました。その後、私たちは大きな一歩を踏み出し、私はプロジェクトのビジネス部分ではなく、開発だけに集中し始めました。産業知識とプログラミング知識があるので、プロジェクトはこれまで以上に効率的になります。言うまでもありませんが、コインの両面で経験があるため、意思決定を迅速に行うことができます。

あなたの質問に対する具体的な答えとして、それは私の個人的な意見では確かにイエスです。チームが取り組んでいるプロジェクトが長期的なプロジェクトである場合は、難しい道を進み、ドメイン固有の基礎と詳細についてスタッフをトレーニングします。

開発者が長期にわたって会社/業界に滞在する場合、彼らはゆっくりと、しかし確実に「ビジネス」を学びます。

一部の企業は、「ビジネス」のトレーニングを認め、提供しています。金融会社はその良い例です。

ビジネスについて詳しく学ぶほど、ユーザーとの会話が容易になります。彼らはあなたにもっと自信を感じるでしょう。システムがユーザーの期待どおりに機能しない場合、システムがどこでうまくいかないかという癖をより容易に理解できます。

あなたの質問に答えるために、仕様は私の経験では決して十分ではありません。一般的な問題は、多くの場合、十分な情報が含まれておらず、すぐに古くなることです。

一部の企業では、ビジネスドメインの経験が必須になる場合があります。彼らは、雇用時にドメインでの経験を持つ開発者を探します。一部の企業は、これを実際の技術スキルよりも高くしています。（金銭的経験はなく、インタビューは非常に一般的ではありません。確かに英国では）。

個人的な経験から、仕様はドメインの知識を持っているチームの誰かがあなたと協力している限り十分です。

私は非常に専門的な業界で働いています。私たちは放送メディア用のソフトウェアを作っています。放送に関することはほとんど知りませんが、コードとデータは知っています。また、放送を理解しているプロジェクト管理チームに優秀な人がいます。この式は、ここ数年、クライアントが好む優れた機能を考え出すのに十分なものでした。