転載済み
https://zenn.dev/thiem/articles/9cdedec94be25a
注意：
抽象度中、具体度中の記事です。
全てのプロジェクトに適切なものかはプロジェクトに応じますのであくまで参考程度に。
非機能要件↓
大事なこと
大事だったなのは、プロジェクトごとに当たり前と当たり前じゃないが分かれるギリギリのところをお客さんに怒られない程度に継続して対応したこと。
あとプロジェクトとお客さんでは、より優先してプロジェクトの健全性をとるという信念。
※あくまで冷静に
※ここでいう怒られない程度とは、webサイト作成など目に見えるわかりやすい開発に対して、目に見えない非機能要件がプロジェクトの成功率を左右することはよくあり、そういった地味なものへの目に見えづらい対応を、
目に見える制作物の開発速度を8割以下にはしない程度で対応するということ
※結局は3ヶ月〜半年などのスパンで見たら、バグの発生率、対応工数などを下げるので確実にペイできるとお客さんとコミュニケーションをとり納得してもらうことが大事。
具体例（抽象度中くらい）：
・適切なコードレビュー体制
・コーディング規約の設定
・ペアプロの有効な活用（全てではなく、毎スプリント要所での実施計画）
・コード品質、スクラム単語、マイナー技術などに関してチームメンバーからチームメンバーに対する勉強会
・コーディング上でのアーキテクチャの継続的な再設計
・デプロイ作業の自動化（全てではないが、頻繁な更新があったり、手作業リスク、複雑性などに応じてマストとするべき箇所はある）
※cloudfrontのbehaviorが70個とかあったので、cloudformationにしたり、ブランチマージ時に開発環境のアプリケーションを自動デプロイしたり
・マルチベンダーでの責任範囲の明確化（マルチベンダーの場合に限り）
・インフラパラメータ(awsなど)のwiki管理（インフラも対応している場合に限り）
・リファクタリングを週1-2時間
・知識共有を週2-3時間
・1タスク切りを最大1時間の単位まで分解する
・開発ルールの蓄積
・開発上の細かい問題をgit hub issueの活用し、継続的に潰すこと
・品質指標の定義と見える化（コードカバレッジ、コード重複、コードスメルなど）
・非機能要件の前もったストーリー化
・使用開発環境の前もった需要予測と実装（実例でいうとstaging環境）
・要求要件、条件を明文化しwiki化(wikiだったり、チケット自体にだったり、チケットからwikiへのリンクだったり)
・チーム及び個人の開発速度の見える化と最適化のための仕組みづくり（ここだけでかなり話が長くなるので抽象度高いところで割愛）
・「ざっくり見積もり」による4半期ごとのマイルストーンの作成と予算どり（優先度はやや低）
・unitテスト実装
・e2eテスト実装（優先度はやや低）
・スクラムのフレームワークの定期的な復習（優先度はやや低）
→ここにヒントや答えがあることがよくある
e.g.それぞれのイベントのタイムボックスの制限時間など