ビジネスアナリストはAPIユーザーストーリーを作成する必要がありますか？
私は、S/W開発会社でビジネスアナリストとして働いています。以前の会社では、資産管理のBAでしたが、BAはよりビジネス指向（つまり、技術的な傾向が少なかった）でした。
現在、ウェブアプリケーションを構築しています。JIRAを使用して、機能要件のユーザーストーリー、受け入れ基準などを記述しています。
機能要件を説明するユーザーストーリーを書いています。
例えば：
クライアントユーザーとして、アカウントを登録したら確認メールを送信して、登録が完了したことを確認します。
合否基準：
- 登録ウィザードは、ウィザードがクライアントユーザーを登録すると、登録された電子メールIDに電子メールを送信します
- 確認メッセージが画面に表示され、クライアントユーザーは登録が完了したことがわかります
- クライアントユーザーは、[完了]をクリックすると自動的にポータルにリダイレクトされます。
関連するAPIチケットも作成する必要があると考える開発者もいれば、BAの役割ではないと考える開発者もいます。
重要なのは、私がITを研究している間、実際にAPIを詳細に研究したことも、以前にプロの開発者として働いたこともないということです。私は直接ビジネス分析に移りました。
ソフトウェア開発プロジェクトでAPIチケットを作成するのはBAの役割ですか？それとも、私が書くストーリーのサブタスクとして関連するAPIチケットを書くのは開発者の役割ですか？
私が訪れたすべてのBAサイトは、ユーザーストーリー（私が提供した例のように）を書くときの機能的/非機能的要件についてのみ話し、APIチケットを書くことについては話しません。
ありがとう！
コメントで既に言及されている重要なポイントは、APIが外部要件であるかどうか（システムがサードパーティにプログラムでアクセスする可能性を提供するため）、または内部実装の詳細であるかどうかです。
前者の状況では、APIをビジネス要件の一部として見るのが賢明な場合があるため、BAが責任を負うことになります。後者の場合、APIをチームの開発者の責任に任せる方が理にかなっていることがよくあります。
これは単なる「本によるモデル」であることに注意してください。組織内の「典型的な開発者の役割」と「典型的なBAの役割」の分離を厳密にしたい場合は、あなたとチーム次第です。本当にアジャイルなチームは、理論モデルがそれらを定義する方法ではなく、それらの間で最もうまく機能する方法で責任を分配すべきです。
まず最初に....あなたがビジネス志向のBAなら、あなたはビジネスプロセスアナリストです。あなたが技術的に傾いているBAである場合（そして、ほとんどの場合、開発のバックグラウンドから来ているでしょう）、あなたはBusiness Systems Analystです。業界がこれら2つのタイプのビジネスアナリストを明確に区別する時が来ました。
上記の説明に基づいて、あなたが開発者でもなく、システムがAPIを介して通信する方法を理解していない場合、あなたはビジネスプロセスアナリストです。私が現在ビジネスシステムアナリストとして働いており、私のバックグラウンドはC＃.net Web開発であるので、あなたが占めている役割には、開発者であった人が必要です。
ソフトウェア開発プロジェクトのビジネスアナリスト（ビジネスシステムアナリスト）として働くことが予想される場合、開発中の製品についてAPI仕様を定義するのはあなたの責任であり、期待される詳細の一部はヘッダーになります。解析されるクエリパラメータ、論理データ型、フィールド長など。
API仕様は、必ずしもシステムの「方法」ではない（したがって、ダニエルのコメントで私が言ったことに同意しません）。送信先の「どのような」情報を記述するという点で、システムの「何」の一部です。電子メールプログラムと論理データ型（物理データ型ではない）。
メールプログラムに送信する情報を開発者に伝える必要があります。私があなたのプロジェクトの開発者だったら、私もあなたに同じ質問をするでしょう。簡単な例えは、あなたに私にあなたに車を作るように頼むなら、でしょう。車両を何に使用するか、何人の乗客を乗せるか、頑丈に使用するかどうかなどを教えてください...これらの質問への回答に基づいて、車、バイク、トラック、トラクター、4x4を組み立てます。したがって、メールの場合、受信者の数、CCまたはBCCがあるかどうか、メールがモバイル向けに最適化されているかどうか、プレーンテキストまたはHTMLかどうか、送信時に暗号化または匿名化が必要かどうかを知ることにも興味があります。電子メールなど.......このストーリーの「方法」の例は、電子メール、つまりSMTPの送信に使用するプロトコルです。これは開発者に委ねられています.....これが役に立てば幸いです。
Ps：説明されているシナリオでは、API仕様は2つのシステム間で交換される情報を定義するため、これをユーザーストーリーの成功基準の一部として個別のストーリーとしてではなく、それを私が書きます。最も重要なことは、情報が文書化されていることです。
また、APIを内部で使用するか外部で使用するかを誰もが質問する理由もわかりません。..ユーザーストーリーがすべてを語っていると思います... Webアプリケーションの一部として登録フォームを作成していて、電子メールプログラム（おそらく組織の電子メールプログラム）と連動するWebアプリが必要です。みんな、答えはユーザーストーリーにあります!!!
tl; dr;（ユーザーのコンテキストで）APIユーザーストーリーを記述することはできませんが、すべてのバックログ項目がユーザーストーリーであるとは限りません。
コメントで、APIはアーキテクチャの一部であると言っています。それ自体は、ユーザーが消費する製品ではありません（AWSなどのユーザーがサービスを管理するために活用するAPIを備えた製品とは対照的です）。そのため、APIのユーザーストーリーを（ユーザーの観点から）作成することはできません。もともとユーザーストーリーは実際にはユーザーによって作成されたものであることを覚えておいてください。
さらに、この場合のAPIは、開発者が別のユーザーストーリーを提供する方法であり、提供されるものではありません。あなたの例を使用すると、メール確認とは何か、APIへの呼び出しは、チームがその機能を実装する方法であり、タスクカテゴリに明確に分類されます。
もちろん、ユーザーストーリーはスクラムには必要ありません。 「REST APIへの確認メールの呼び出しを追加」は、バックログアイテムになる可能性があります。これはユーザーストーリーではありません。このようなバックログアイテムの代わりにユーザーストーリーを使用することをお勧めする理由はたくさんあります。しかし、必要な状況に陥った場合、本質的にそれを持っているのはアンチスクラムではありません（実装に関する開発チームの自律性を侵害している可能性がありますが、それは別のトピックです）。
最後に、誰でもバックログにアイテムを書き込むことができます。スクラムは、製品の所有者がバックログの優先順位付けと状態に責任があると言っています。チームが別のユーザーストーリーまたは他の種類のバックログアイテムの必要性を見つけた場合、それらを書き込むことが許可されます。
ドメイン、API、APIテストに精通していて、常識がある限り、誰でもAPI要件を記述できると思います。しかし、一部のビジネスアナリストとプロダクトマネージャーが基本的で本質的な詳細なしにAPIストーリーを作成しているため、開発者やテスターにとってストーリーが役に立たなくなっています。したがって、開発者とテスターは要件自体を把握する必要があります。
たとえば、ヘッダー、クエリパラメータ、サンプルレスポンスなどが記載されていないAPIストーリーを見ました。一部のAPIには日付、パーセンテージなどのフィールドがありますが、これらのフィールドに必要な形式がありません。 （米国または英国の日付形式？、小数点以下1桁または2桁のパーセンテージ？BAまたはPMは、これらのような簡単な質問をするために、本当に高度な知識が必要ですか？）すべてのストーリーで、さまざまなハッピーパスまたは通常のユースケースシナリオへの対応については、決して言及されていません。
ドクター・ブラウンが正しく述べたように、執筆要件は、BAやPMだけでなく、チーム全体の責任になる可能性があります。ただし、BAまたはPM=がスキルがなく、それを行うのに十分なほど賢くない場合は、開発者とQAがその責任を負う必要があります。
いいえ。APIは2つ（またはそれ以上）のソフトウェア（クライアント側とサーバー側のコードなど）間のインターフェースです。そのため、一般に、APIの性質は、これら2つのソフトウェアの構築と保守を担当する開発者またはチーム間で交渉するのが最善であると思います。
これに対する明確な答えはないと思います。それはあなたのチームが何を必要としているか、そしてあなたのソリューションに依存します。説明させてください：
一般的にアジャイルで言えば、私たちの目標はエンドユーザーに価値を提供することです。 APIやその他のテクニカルストーリーには、価値のない、または少なくともコンテキスト外の何かを作成するリスクがあります。 「API xzyで住所フィールドを取得したい」のようなストーリーを想像してみてください。技術的には正しいかもしれませんが、なぜそれを行っているのですか？実際、疑わしい実装を禁止している場合もあります。
それで、私たちがすべきことは、エンドユーザー向けのストーリーを書くことです。
これを言って、私は多くの場合にAPIストーリーを書きました：-APIが公開されている場合、ユーザーは、機能的だけでなく非機能的部分にも既得権を持つユーザーまたはシステムになりますAPI（たとえば、「最小呼び出し数」）。その場合、APIストーリーを書くことは十分に正当化されるかもしれません。 -また、さらに議論の余地があるかもしれませんが、すべてのサービス提供の一部として内部構成サービスを使用する多数のサービスを持つシステムをイメージングする場合、個々のサービスを所有するチームが存在する可能性があります。この場合、APIストーリーを記述してチーム間で通信することは理にかなっています。そうは言っても、サイロで作業するリスクがあるので、私の質問は次のとおりです。
これに対処する優れた本（マイクロサービスを使用しているかどうかに関係なく）は、Sam Newmanの著書 『Building Microservices』で、彼はこれに関するさまざまなパターンについて説明しています。 https://samnewman.io/talks/principles-of-マイクロサービス/
また、アジャイルポッドキャスト The Burn Up には、これに関するエピソードが5月に掲載されます:)