技術や品質の観点
最終更新
役に立ちましたか？
最終更新
役に立ちましたか？
ウォーターフォールかアジャイルかに関係なく、技術や品質の観点は重要です。
プロダクトやシステムが達成すべき品質は、開発手法によって決まるのではなく、そのプロダクト自体が、誰のためにどう使われるかによって決まります。 たとえば、銀行のオンラインシステムであれば、金額を間違うことも、振込が遅延することも、振込の画面でエラーがでることも許容されず、詳細なテストケースをすべて網羅しなければいけないかもしれませんが、 使い捨てのキャンペーン申し込みサイトであれば、多少の不具合があっても関係ないこともあります。
つまり、どの程度の品質が必要になるかによって、開発にかかる期間やコストは大きく変わってしまいます。
そこで開発を始める前に行うのが非機能要件の明確化です。 以下にあげるような項目(※)について、全員が共通理解を持てるようにします。
可用性（継続性、耐障害性、災害対策、回復性など）
性能・拡張性（業務処理量、性能目標値、リソース拡張性、性能品質保証など）
運用・保守性（運用時間、バックアップ、運用監視、計画停止、予防保守など）
移行性（移行時期、移行方式、移行対象データ、移行計画など）
セキュリティ（制約条件、セキュリティ診断、アクセス制限、データ秘匿など）
システム環境・エコロジー（システム特性、適合規格、環境条件など）
なお、小規模な新規プロダクトの場合などでは、上記で触れた項目をすべて考えるのは無駄になる可能性があります。 プロダクトがマーケットに受け入れられるか分かっていないうちに、プロダクト以外のことに多くの時間を使うのは得策ではないので、 プロダクトの成長を見ながら随時必要なタイミングで検討していけば良いでしょう。
※IPA公開のを元に作成
非機能要件を踏まえて、アーキテクチャや開発言語の選定を行います。 たとえば以下のような項目を検討すると良いでしょう。
プロダクトのアーキテクチャをどのようにするか
どの開発言語でどんなフレームワークを使うか
テスト自動化にはどんなライブラリを使うのか
インフラに何を使うか
もちろん初期の時点では決めきれず評価や検証が必要な場合もあります。 すべての検証を事前に行う必要はありません。 後から変更すると大きなコストがかかるようなものについては、優先順位を上げて早めに検証しておくと良いでしょう。 検証の際は、タイムボックスを設定して、時間がかかりすぎないようにします。 検証の結果が芳しくない場合は、早めに変更の判断をします。 ほかに検証したい項目があれば、プロダクトバックログの中に入れておくようにします。
完成の定義とは、プロダクトバックログ項目が完成したと言えるために満たさなければいけない品質条件です。 例えば、ユニットテストがある、統合テストが実施済である、静的解析で重大な警告がない、リリースノートが用意されている、コードがレビューされている、といったあるべき状態を定義します。 プロダクトバックログ項目は、この完成の定義を満たしてはじめて「完成」となります。 定義を満たしていない場合は、プロダクトオーナーの受け入れ確認をしてはいけないですし、条件付きで完成とするようなこともできません。
類似のものとして、プロダクトバックログ項目の受け入れ基準がありますが、受け入れ基準は、そのプロダクトバックログ項目が持つべき機能性の確認であり、プロダクトバックログ項目ごとに異なるのに対して、 完成の定義は、複数のプロダクトバックログ項目で共通して満たす必要がある非機能性の確認となります。
完成の定義はプロダクトの性質やビジネスのゴールによって変わります。 金融系のアプリケーションと使い捨てのキャンペーンサイトでは満たすべき非機能性に違いがあるのは当然です。
完成の定義は、プロダクトオーナー（最終決定者）と開発チームが中心となって考えます。 プロダクトオーナーはもちろんステークホルダーと協働していく必要があります。 ここでのステークホルダーには、大きな組織であれば、社内の品質管理部門などが含まれることがあるでしょう。
完成の定義を決める上では、「なぜ？」「なにを？」「誰のために？」をはっきりさせることが重要です。
完成の定義を複数設けることもあります。 たとえばスプリントでの完成の定義、リリースでの完成の定義のような形です。 セキュリティ試験のように毎スプリント実施するのが難しいような項目を、リリースでの完成の定義にいれるわけです。 一方で、このような形にすると、スプリントで完成しても、すぐには本番にリリースができないので、状況の変化に柔軟に対応できないこともあります。 理想的には、スプリントでの完成の定義とリリースの完成の定義の差分は小さくなるようにしていきましょう。 ただし、そうするためには、スクラムチーム全体の成熟が必要になります。
アジャイルマニフェストでは、「包括的なドキュメントよりも動くソフトウェアを」としていますが、これはドキュメントが不要という意味ではありません。 「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」とあるように、ドキュメント自体にも価値があります。
ドキュメントもプロダクトの性質によって求められるものが変わります。 保守・運用の資料はひとたび本番としてリリースしたタイミングから使われることになりますが、最初になければいけないわけではなく、リリース前までに揃っていれば良いでしょう。 一方でアーキテクチャーの全体像のようなドキュメントは共通理解を形成する上で、初期から継続的にメンテナンスしていく必要があるかもしれません。 つまり、初期の段階で必要なものを明らかにしつつ、必要に応じて追加したり削除していくのがアジャイルなやり方です。 また、ドキュメントの作成は必ず手作業でやらなければいけないわけではありません。 自動化できるものは自動化しましょう。 例えば、APIドキュメントのようなものは、ツールで自動生成できるので、継続的インテグレーションに組み込むことで、一切作業することなく最新のドキュメントを用意し続けることができます。
必ず作成・更新しなければいけないドキュメントがある場合は、完成の定義に含めたり、プロダクトバックログ項目を追加するようにしてください。
スクラムではコーディング作業とテスト作業は密接につながっています。 つまり、コーディングやテストとやその他必要な作業が完成し、プロダクトオーナーの受け入れが終わって、はじめてその機能が完了したことになります。
完成の定義を満たしていない（非機能要求が未対応）もの、プロダクトオーナーが受け入れない（機能要求が実現されていない）ものは、スプリントでの成果と見なされません。
初期の段階では、開発に必要な環境の準備も必要です。 まず、個人の開発環境を用意します。 このとき、後から参加した人が簡単に開発環境を手に入れられるように仮想化や自動化などを組み合わせるようにしましょう。 開発環境構築手順書を用意する方法もありますが、ドキュメントのメンテナンスコストや、実際の作業の手間を考えると無駄が多いと言えるでしょう。
個人の開発環境以外には、デモ環境やプロダクトオーナーの受け入れ確認環境も用意しておきましょう。 そうすることで最初から継続的に完成したものをリリースできるようになります。 そして、継続的インテグレーションサーバーやバージョン管理ツールなど、開発に必要なツールセットも用意しておきましょう。 最初に用意しておくことで、統合された環境を作ることが可能になります。
ツールはメジャーなものを使います（下図）。 そうすることでインターネット上で多くの情報を入手できるようになります。
アジャイル開発では、ソフトウェアが動く状態を維持しながら機能を追加していきます。 つまり、頻繁に何度もテストをしなければいけません。
小規模リリースのたびに手動でテストすると、コードベースが大きくなるにつれて、テストのコストがどんどん膨らんでいきます。 こうなると開発できる機能の量が減っていき、それに伴ってビジネスの成果も減ってしまい良くありません。
スクラムではフレームワークを定義しているだけで、テスト自動化を含む技術的なプラクティスについては一切触れていませんが、事実上はテスト自動化が必須です。 品質保証計画や非機能要件を踏まえて、どのようにテストを自動化していくか考えるようにしましょう。
スクラムを適用する場合には、3つのロール、3つの作成物、5つのイベントすべてを実施しなければいけません。
一方でエクストリームプログラミング（XP）では自分たちが必要なものを選べばよいことになっています。
前述のとおりスクラムには技術プラクティスの定義はないので、XPなどからほかに必要なプラクティスを選択するとよいでしょう。 最初から盛り込みすぎると、学習コストが高すぎたり時間がかかりすぎたりするので注意します。 また、一度プラクティスを適用したからといって変更できないわけではありません。 機能しないプラクティスを外したり、もっとよいプラクティスが見つかれば置き換えてください。
