概要
テクニカルストーリーは、アジャイル開発プロセスにおいて、システムの機能追加やユーザーエクスペリエンスの向上ではなく、システムの品質や効率を高めるために必要な技術的なタスクを指します。主なタスク内容は以下の通りです。
- 技術選定やアーキテクチャ検討
- コードのリファクタリング
- 性能やセキュリティなどの非機能要件への対応
- 技術的負債の削減および解消
また、プロジェクトによっては、デザイナーによるデザインシステムやデザインガイドの作成・更新もテクニカルストーリーの一部として扱うことができます。
テクニカルストーリーの必要性
テクニカルストーリーは、以下の理由からソフトウェア開発プロジェクトにおいて重要な役割を果たします。
-
非機能要件や技術的負債の可視化
- 機能追加以外の要件や技術的な課題をバックログ化することで、これらの課題を可視化し、優先順位付けを行うことができます。
- これにより、開発チームは技術的な問題に適切なタイミングで対処できます。
-
対応内容のトレーサビリティ確保
- テクニカルストーリーを用いることで、課題への対応内容をタスクとして記録し、トレーサビリティを確保できます。
-
技術的な改善の促進
- テクニカルストーリーを定期的に見直すことで、システムの技術的な改善点を継続的に識別し、対処できます。
- これにより、システムの品質や保守性が向上し、長期的な開発効率の向上につながります。
テクニカルストーリーの構成
テクニカルストーリーを効果的に管理するには、明確な構成と階層構造が必要です。テクニカルストーリーは通常、以下のような構成で管理されます。
--- ゴール
|-- エピック
|-- ストーリー
|-- スパイク
ゴール
ゴールは、テクニカルストーリーの最上位に位置づけられ、達成すべき目標や目的を明確に定義します。ゴールを設定する際は、具体的で測定可能な指標を用いて達成基準を明確にすることが重要です。これにより、チームは目標に向かって一丸となって取り組むことができます。
エピック
エピックは、ゴールを達成するための大まかな方針を示し、複数のストーリーで構成されます。エピックは、ゴールとストーリーの間を橋渡しする役割を担い、ゴールを達成するために必要な機能や改善点を大まかに描写します。
ストーリー
ストーリーは、エピックを実現するための具体的なタスクや要件を記述します。ストーリーには以下のような特徴があります。
- 技術的な実装や改善に関する詳細な内容を含む
- 開発チームが実際に取り組むタスクを表す
- 受け入れ基準を明確に定義し、完了の判断基準を示す
- ストーリーポイントを用いてタスクの規模や複雑さを見積もる
ストーリーを書く際は、INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) の原則に従うことで、より効果的なストーリーを作成できます。
スパイク
スパイクは、不確実性の高い技術的な調査やプロトタイピングを行うためのタスクです。スパイクは、新しい技術の導入や複雑な問題の解決に役立ちます。スパイクの結果は、後続のストーリーの見積もりや実装に反映されます。
テクニカルストーリーの例①(要件定義フェーズ)
ゴール: 要件定義フェーズ1.0の完了
エピック: 非機能要件1.0の定義
ストーリー1: セキュリティ要件の定義
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| 認証・認可要件の定義 | ユーザー認証・認可の方式と実装方針を定義すること | 3 |
| 暗号化要件の定義 | 機密データの暗号化方式と対象範囲を定義すること | 2 |
| 脆弱性対策要件の定義 | 既知の脆弱性に対する対策方針を定義すること | 5 |
ストーリー2: 可用性要件の定義
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| 稼働率要件の定義 | システムの目標稼働率を定義すること | 2 |
| 障害復旧要件の定義 | 障害発生時の復旧目標時間と手順を定義すること | 3 |
| 負荷分散要件の定義 | 負荷分散の方式と適用範囲を定義すること | 3 |
ストーリー3: 性能要件の定義
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| レスポンスタイム要件の定義 | 各機能のレスポンスタイム目標値を定義すること | 3 |
| スループット要件の定義 | システム全体のスループット目標値を定義すること | 2 |
| 同時接続数要件の定義 | 同時接続ユーザー数の目標値を定義すること | 2 |
ストーリー4: 保守性要件の定義
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| 運用監視要件の定義 | 監視対象と監視方法を定義すること | 3 |
| ログ管理要件の定義 | ログの取得範囲とログ保持期間を定義すること | 2 |
| バックアップ要件の定義 | バックアップ対象とバックアップ頻度を定義すること | 2 |
スパイク: 非機能要件のベンチマーク調査
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| 非機能要件のベンチマーク調査 | 類似システムの非機能要件を調査し、目標値の妥当性を検証すること | 5 |
テクニカルストーリーの例②(アーキテクチャリファクタリング)
ゴール: マイクロサービスアーキテクチャへの移行
エピック1: モノリシックアーキテクチャからマイクロサービスへの移行設計
ストーリー1: ドメイン分析とサービス分割
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| ドメインモデルの作成 | システムのドメインを分析し、境界づけられたコンテキストを特定すること | 5 |
| サービス分割の設計 | 特定したドメインに基づいて、マイクロサービスへの分割方針を設計すること | 8 |
ストーリー2: サービス間通信の設計
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| API設計 | サービス間の通信に使用するAPIを設計すること | 5 |
| メッセージングシステムの選定 | 非同期通信に使用するメッセージングシステムを選定すること | 3 |
ストーリー3: データ管理の見直し
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| データ所有権の見直し | 各サービスが所有するデータを明確化すること | 5 |
| データ同期方式の設計 | サービス間でのデータ同期方式を設計すること | 8 |
エピック2: Kubernetesへの移行
ストーリー1: アプリケーションのコンテナ化
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| Dockerfileの作成 | 各サービスをDockerコンテナ化するためのDockerfileを作成すること | 5 |
| コンテナイメージのビルドとレジストリへのプッシュ | コンテナイメージをビルドし、コンテナレジストリにプッシュすること | 3 |
ストーリー2: Kubernetesマニフェストの作成
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| デプロイメント、サービス、コンフィグマップ等のマニフェストの作成 | 必要なKubernetesマニフェストを作成すること | 8 |
| ステージング環境へのデプロイと動作検証 | ステージング環境にデプロイし、正常に動作することを確認すること | 5 |
ストーリー3: 本番環境への移行
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| 本番環境へのデプロイ | 本番環境にデプロイすること | 8 |
| モニタリングとアラートの設定 | 必要なモニタリングとアラートを設定すること | 5 |
| 移行完了後の性能テストと監視 | 性能テストを実施し、監視を継続的に行うこと | 5 |
エピック3: リファクタリングの実現可能性評価
スパイク1: マイクロサービスアーキテクチャの技術調査
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| マイクロサービスを実現するための技術スタックの調査と選定 | 適切な技術スタックを選定すること | 8 |
スパイク2: Kubernetes移行のインパクト分析
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| Kubernetesへの移行による既存システムへの影響分析 | 移行によるシステムへの影響を明確化すること | 5 |
スパイク3: リファクタリングの工数見積もり
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| 各ストーリーの実装に必要な工数の見積もり | 各ストーリーの工数を見積もること | 8 |
スパイク4: リファクタリングのROI分析
| タスク | 完了条件 | ストーリーポイント |
|---|---|---|
| リファクタリングによるコスト削減効果と投資対効果の分析 | リファクタリングのROIを分析すること | 5 |
まとめ
テクニカルストーリーは、アジャイル開発プロセスにおいて、システムの品質や効率を高めるために必要な技術的なタスクを管理するための手法です。ユーザーストーリーがユーザーの視点からシステムの機能や価値にフォーカスするのに対し、テクニカルストーリーはシステムの内部構造や非機能要件、技術的負債などにフォーカスします。
テクニカルストーリーは、エンジニアやテクニカルに詳しいメンバー間でのコミュニケーションを円滑にし、技術的な課題や対応方針について共通理解を得るために役立ちます。また、議事録やトレース、タスク管理としても活用できるため、プロジェクトの透明性や追跡可能性を高めることができます。
本記事では、要件定義フェーズやアーキテクチャリファクタリングを例に、テクニカルストーリーの具体的な活用方法を紹介しました。これらの例を参考に、皆さんのプロジェクトでもテクニカルストーリーを適用し、システムの品質や開発効率の向上に役立てていただければ幸いです。
最後までご覧いただきありがとうございました。テクニカルストーリーを活用することで、プロジェクトの技術的な課題に効果的に対処し、より高品質なシステムを開発できることを願っています。