誰が技術設計書を書くべきですか？ BAまたは開発者？
私はSnrとして働いています。大手製造会社のBAで、新しい要件管理プロセスを実装しました。
承認された要件ドキュメントを受け取った後、技術設計ドキュメントを介してソリューションを定義するように求められたことのない内部開発者が多数います。彼らは通常、ソリューションの書面による参照や、なぜそれが選択されたのか、関連するリスクを伴うことなく、コードを先に進めます。
現在、私たちのリリースマネージャーは、ソリューションとテクニカルデザインドキュメントを書くのはBAである必要があると述べています。特に、完成が容易なTDDテンプレートがあるため、開発者から直接提供する必要があると私は思います。
BAがDevelopersソリューションを繰り返し解釈しようとするのは時間の無駄であり、それがDevelopersソリューションを誤って解釈するリスクを冒していると思います。 BAはそれほど技術的ではありません！ :-)
私の経験では、それを書いたのは開発者/建築家でした。
BAがテクニカルアーキテクトでもない限り、「どのように機能するか」ではなく、「何をするか」に関心を持つ必要があります。その結果、BAが要件を記述し、テクニカルアーキテクトがソリューションを記述し、開発者がコードを記述します。
時々（またはかなり頻繁に）これらの役割は誰かによって共有されるため、開発者は自分のコードのアーキテクトになることも、後輩が開発するTddを書く領域の専門家になることもできます。 BAがTAになることもありますが、それらはビジネスの背景ではなく技術的な背景からのものである場合に限ります。
私が今働いているところには、ビジネスの人々から基本的な要件を取り、それを技術的な要件に変えた（つまり、賢明なものにした）技術設計権限があり、上級開発者はソリューションドキュメントを書いて、 TDAがレビューし、開発者がそれをすべてコード化します。技術的な要件は、テストチームがシステムテストを作成するためにも使用されます。
私の現在の仕事では、以前よりも技術的に傾いているBAがいますが、それでも技術設計ドキュメントを書くことを期待していません。開発者は常にそれらを記述し、その後、建築家はそれらにサインオフしました。
ただし、xmojmrのコメントを支持して、ウォーターフォール時代のドキュメントについては非常に勤勉でしたが、いくつかの弱点があることに気づきました。
- 技術文書は、開発が始まる前に完了することが期待されていました。実際には、私たちにできる最善のことは、技術的な詳細で知識に基づいた推測を文書化し、開発が進行するにつれて頻繁に修正することでした。
- ドキュメントに入力された内容の多くは定型文であり、したがって、誰にとってもほとんどまたはまったく本当の意味がありませんでした。
- 技術ドキュメントの対象読者は、開発者（今後コードを保守する人）でした。この点で、それは全く役に立たなかった。問題を修正したり、出力を微調整したりする必要がある人は、技術文書では何の価値も見つけられません。メンテナーが必要とする詳細の種類は、コード自体にあります。コードに存在する詳細レベルに近づくように技術ドキュメントを強化しようとすると、労力が重複するだけでなく、コードとドキュメントの同期が失われます（おそらく、バージョン1が出荷される前でも）。
アジャイルワークフローに切り替えたとき、技術文書を意図的に破棄しました。 「十分なドキュメント」という考え方を採用しています。つまり、書き留める必要のある決定や、説明する必要のある決定的な点がある場合は、その種のウィキを用意しています。一部のプロセスは、製品の所有者にとって有用であるため、まだ正式なフロー図があります。しかし、ドキュメントからフォーカスを顧客のニーズを満たすためにシフトすることで、すべての利害関係者がより幸せになり、製品はこれまで以上に安定しています。
この質問への回答は、各企業の組織に大きく依存しています。前述のように、理想は、技術文書がプロジェクトのソフトウェア開発者/エンジニアと話し合った後、ソフトウェアアナリストによって作成されることです。ただし、グループにアーキテクトがいない場合は、ワークロードを共有する必要があります。つまり、技術文書の執筆を重荷として考えるのをやめ、より多くの技術知識を得る絶好の機会と考えてみませんか？
私の意見では、重要な技術的背景がないため、このドキュメントを自分で書くことはできません。ただし、開発者は他の資質を欠いているため、適切に構成された技術文書を完全に作成することはできません。開発者が本当に資格があり、完璧な技術文書を書くことができたとしても、彼はかなりの時間を失うと思います。それは、実装フェーズではるかに効率的に費やすことができます。
ですから、開発者と何度も話し合った後、技術文書を書くことをお勧めします。このようにして、2つのメリットがあります。-重要な技術的知識を習得します。この知識はあなたの将来にとって重要な資産になります。 -開発者が実装により多くの時間を費やすため、プロジェクトの期間は短くなります。そして彼はまたあなたに感謝します;）