アジャイル型システム開発におけるBTABoKの活用について

１．アジャイル開発の利点と問題点

アジャイル開発は、ソフトウェア開発の分野で広く採用されている手法であり、その迅速な対応力と柔軟性が評価されています。アジャイル開発の主な利点としては、短期間でのリリースが可能であること、継続的なフィードバックを受けて改善を繰り返すことができること、そしてビジネスの変化に迅速に対応できることが挙げられます。これにより、顧客満足度の向上や市場への迅速な対応が可能となります。

しかし、アジャイル開発にはいくつかの問題点も存在します。例えば、要求の変動やコミュニケーションの複雑さ、品質管理の難しさなどが挙げられます。これらの問題点は、プロジェクトの進行を妨げる要因となり得ます。本コラムでは、このような問題点に対応する課題を支援するために、ビジネステクノロジーアーキテクチャ知識体系であるBTABoK（Business Technology Architecture Body of Knowledge）をどのように活用できるかについて考察します。

２．アジャイル型システム開発での具体的な問題点

アジャイル型システム開発は、その柔軟性と迅速な対応力が評価される一方で、いくつかの問題点や困難な事項も伴います。以下に、アジャイル開発における具体的な問題点を挙げます。

(1) 要求の変動

アジャイル開発では、プロジェクトの進行中に顧客やステークホルダーからの要求が頻繁に変わることが一般的です。これは、ビジネス環境の変化や新たな市場機会に迅速に対応するために必要なことですが、開発チームにとっては大きなチャレンジとなります。具体的には、以下のような問題があります。

• スケジュールの変更: 要求の変動により、プロジェクトのスケジュールが頻繁に変更されることがあります。これにより、開発チームは計画の再調整を余儀なくされ、進行中の作業に影響を及ぼすことがあります。

• リソースの再配分: 新たな要求に対応するために、リソース（人材、時間、予算）の再配分が必要となることがあります。これにより、他のタスクやプロジェクトに影響が出る可能性があります。

• 優先順位の変更: 要求の変動により、タスクの優先順位が頻繁に変更されることがあります。これにより、開発チームは常に優先順位の見直しを行い、最も重要なタスクに集中する必要があります。

(2) コミュニケーションの複雑さ

アジャイル開発では、チーム内外のコミュニケーションが増えるため、情報の共有と理解が難しくなることがあります。特に、リモートワークや多国籍チームの場合、コミュニケーションの問題はさらに顕著になります。たとえば、以下のような具体的な問題が発生することがあります。

• 情報の一貫性: チームメンバー間で共有される情報が一貫していない場合、誤解やミスコミュニケーションが発生する可能性があります。これにより、プロジェクトの進行に遅れが生じることがあります。

• タイムゾーンの違い: 多国籍チームの場合、タイムゾーンの違いにより、リアルタイムでのコミュニケーションが難しくなることがあります。これにより、意思決定や問題解決に時間がかかることがあります。

• 文化の違い: 異なる文化背景を持つチームメンバー間でのコミュニケーションは、誤解や摩擦を引き起こす可能性があります。これにより、チームの協力体制が弱まることがあります。

(3) 品質管理

アジャイル開発では、短期間でのリリースが求められるため、品質管理が難しくなることがあります。品質管理面では、以下のような具体的な問題が発生する可能性があります。

• テストの時間不足: 短期間でのリリースサイクルにより、十分なテスト時間が確保できないことがあります。これにより、バグや不具合が発見されずにリリースされるリスクが高まります。

• テストの自動化: 品質を維持するためには、テストの自動化が重要ですが、初期の設定やメンテナンスに時間とリソースが必要です。これにより、他の開発作業に影響が出る可能性があります。

• 継続的な改善: 品質を維持するためには、継続的な改善が必要ですが、短期間でのリリースサイクルにより、改善のための時間が不足することがあります。

(4) スコープの管理

アジャイル開発では、プロジェクトのスコープが曖昧になりがちで、計画通りに進めることが難しい場合があります。具体的には、以下のような問題が発生することがあります。

• スコープの変更: 要求の変動により、プロジェクトのスコープが頻繁に変更されることがあります。これにより、計画通りに進めることが難しくなり、プロジェクトの進行に遅れが生じることがあります。

• スコープの拡大: 新たな要求や機能追加により、プロジェクトのスコープが拡大することがあります。これにより、リソースの不足やスケジュールの遅延が発生する可能性があります。

• スコープの明確化: プロジェクトのスコープを明確に定義し、チーム全体で共有することが重要ですが、要求の変動によりスコープの明確化が難しくなることがあります。

このように、アジャイル型システム開発には多くの問題が存在しますが、これらの問題に対する課題を支援するための方法として、BTABoKを活用することで、より効果的な開発プロセスを実現することができないかを考えてみます。

３．アジャイル型システム開発の課題への対応におけるBTABoKの活用

BTABoKは、ビジネステクノロジーアーキテクチャの知識体系ですが、アジャイル型システム開発の課題に対応するためにも有効なツールです。ここでは、アジャイル開発における課題に対して活用できるBTABoKで提示されているモデルや手法について紹介します。

(1) 要求の変動への対応

BTABoKでは、ビジネスの変化に対応するためのフレームワークを紹介しており、要求の変動に柔軟に対応することができます。具体的には、以下のようなモデルや手法が活用できます。

• ビジネスモデルキャンバス

  ビジネスモデルキャンバスは、アーキテクチャとイノベーションに使用されるビジネスモデルを提供します。一般的には、顧客と価値提案から始めたいキャンバスを使用し、その後、他の領域に移ります。ビジネスモデルキャンバスは、ビジネスモデル全体を 1 つのビジュアルシートに凝縮する強力な戦略ツールです。それは単なるアーキテクチャではなく、イノベーションを刺激し、ビジネスのあらゆる側面が整合するようにすることです。ビジネスモデルキャンバスは、顧客とそのニーズを優先します。価値提案(提供する中核的なメリット)から始めることで、運用、リソース、財務を調整して、優れた価値を提供することができます。ビジネスモデルキャンバスを用いて、ビジネスの全体像を視覚的に把握し、要求の変動に対する影響を評価します。これにより、ビジネスの変化に迅速に対応するための戦略を立てることができます。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/business_model_canvas.html

• バリューストリームキャンバス

  バリューストリームキャンバスは、顧客から制御、サプライヤー、運用を通じて推進される組織内のどこで価値が生み出されるかを理解するために使用されます。バリューストリームキャンバスを用いて、ビジネスプロセスの流れを可視化し、どの部分が要求の変動に影響を受けるかを特定します。これにより、変動に対する迅速な対応が可能となります。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/value_stream_canvas.html

• アジャイルインパクトキャンバス

  アジャイルインパクトキャンバスは、アジャイル手法が企業、チーム、またはドメインに与える全体的な影響を説明するために使用されます。キャンバスは、ビジネスモデル、組織構造、文化などへの影響について考えるためのツールです。これは、組織でアジャイルを機能させるための最善の方法をブレインストーミングしている多面的なチームによるファシリテーションツールとして使用すると、最も効果的です。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/agile_enterprise_impact_canvas.html

(2) コミュニケーションの改善

BTABoKでは、ビジネスとITの間のコミュニケーションを促進し、ステークホルダーの共通の理解を深めるためのツールを提供します。具体的には、以下のようなモデルや手法が挙げられます。

• ビジネスケイパビリティキャンバス

  ケイパビリティモデルは、組織が顧客に価値を提供するために必要な基本的なスキルとリソースを構造化して分類したものです。バリューストリーム (価値創造のエンドツーエンドのプロセス) に統合されると、機能モデルは青写真のように機能します。これは、潜在的なボトルネック、冗長性、および的を絞った投資によって価値の流れを大幅に改善できる領域を特定するのに役立ちます。これにより、効率が向上し、リソース割り当ての理解が深まり、イノベーションが結果を出す可能性が最も高い場所を特定する能力が得られます。ビジネスケイパビリティキャンバスを用いて、ビジネスの主要な機能や能力を明確にし、ITとの連携を強化します。その結果、ビジネスとITの間で共通の言語を持つことができ、コミュニケーションが円滑になります。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/business_capability_canvas.html

• アーキテクト組織キャンバス

  アーキテクト組織キャンバスは、組織のアーキテクチャ能力を理解し、向上させるために特別に調整された一種のビジネス能力カードです。アーキテクトが組織全体にどれだけ関与しているか、ビジネスからソリューション(戦略から実行まで)の有効性、重要な意思決定の割合、および全体的な利害関係者の関与に関連する指標を定義するチームの範囲に重点が置かれています。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/architect_organization_canvas.html

• ステークホルダーマネジメントプラン

  ステークホルダーマネジメントプランは、あらゆるイニシアティブに影響を与えるグループと個人のリストを提供し、ステークホルダーテンプレート、カード、キャンバスの中核を形成します。このリストの目標は、利害関係者のグループに管理計画を提供することです。このリストは、追加のリンクされた利害関係者カードとキャンバスのセットを使用して作成されます。ステークホルダーマネジメントを通じて、関係者とのコミュニケーションを計画的に行い、情報の共有と理解を促進します。これにより、プロジェクトの進行がスムーズになります。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/stakholder_management_plan.html

(3) 品質管理の向上

BTABoKでは、品質管理のプロセスを標準化し、継続的な改善を促進する、以下のようなモデルや手法を活用することができます。

• 品質アシュアランスアプローチ

  品質保証は、開発プロセス全体を通じて行われるものです。品質保証を早期に開始し、アーキテクチャを継続的にチェックすることは、非効率的な設計を検出することにつながります。開発プロセスの早い段階でエラーや問題を発見することで、修正にかかる費用が安くなります。品質アシュアランスフレームワークを導入し、品質管理のプロセスを標準化します。これにより、品質の一貫性が保たれ、バグや不具合の発生を防ぐことができます。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/quality_assurance.html　

• DevOps アーキテクチャ

  DevOpsとは、ソフトウェア開発(Dev)と情報運用(Ops)を組み合わせて、組織のこれら2つの伝統的に別々の領域間のギャップを埋める一連のプラクティスを指します。これは、アジャイルの原則を従来の品質保証 (QA) 手法と統合することで、コラボレーションを改善し、プロセスを自動化し、効率を向上させることを目的としています。DevOps の主なコンポーネントであるContinuous Integration（CI:継続的インテグレーション）により、テストとビルドのプロセスを自動化できるため、一貫した品質を確保し、バグを早期に検出できます。また、Continuous Delivery（CD:継続的デリバリー）により、迅速な修正と迅速な反復が可能になり、チームは変更を迅速に展開してテストできます。CI/CDパイプラインを構築し、コードの変更を自動的にテスト・デプロイすることで、品質を維持します。DevOps プラクティスを採用することで、組織は、反復的なタスクの自動化、ワークフローの合理化、部門横断的なチーム間のコラボレーションの促進により、市場投入までの時間を短縮し、欠陥を減らし、顧客満足度を高めることができます。

  ⇒ 参考サイト: https://iasa-global.github.io/btabok/dev_ops.html

• テスト自動化

  製品の品質を評価し、欠陥や問題を特定することで改善する活動であるテストは、実行領域テストから選択された有限のケースセット(通常は無限)に対するプログラムの動作の動的検証で構成され、予想される動作に関連し、見つかった欠陥の観点から機能システムと非機能システムを測定します。組織内でテスト自動化ツールを適切に使用することにより、反復的なテスト作業を効率化できます。これにより、テストの時間を短縮し、品質を高い水準で維持することができます。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/tmtt.html　

(4) スコープの管理

BTABoKでは、プロジェクトのスコープを明確に定義し、計画通りに進めるためのガイドラインとして、以下のような手法が提示されています。

• スコープとコンテキスト

  スコープとは、アーキテクチャに関する一連の決定によって影響を受けるビジネステクノロジ戦略の量を指します。スコープとコンテキストは、アーキテクチャエンゲージメントをその影響のレベルとそれが発生する環境に基づいて理解するための2つの側面です。スコープとコンテキストの明確さは、アーキテクトやチームを大幅に節約でき、ドキュメントやテクノロジー手法と同じくらい重要です。スコープマネジメントプランを策定し、プロジェクトのスコープを明確に定義します。これにより、スコープの変更が発生した場合でも、計画通りに進めることができます。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/scope_context.html　

• ASRカード

  ASR(Architecturally significant requirements)カードは、アーキテクチャ上重要な要件を定義するためのツールです。アーキテクチャ的に重要な要件 (ASR) は、アーキテクチャのライフサイクル全体を通じて主要な考慮事項である必要があります。戦略計画の初期段階では、ASR を特定して、アーキテクチャの選択と長期的なビジネス目標の整合性を確保することが有益です。これにより、テクノロジーの選択からリソースの割り当てまで、プロジェクト全体の方向性が導かれます。ASRは、適切に構造化されたアーキテクチャの基盤となり、システムのコンポーネントがどのように相互作用するか、およびスケーラビリティやパフォーマンスなどの側面をどのように処理するかに関する決定を促進します。設計段階では、技術チームが設計のビジョンに沿った選択肢を確保するための絶え間ないチェックとして機能します。要件の変更や新しいテクノロジーを検討する場合でも、ASRは不可欠です。これらの変更が既存のアーキテクチャ上の決定に与える潜在的な影響を迅速に評価し、システムの整合性を損なわない適応を導くのに役立ちます。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/asr_card.html　

• アーキテクト エンゲージメント キャンバス

  アーキテクト エンゲージメント キャンバスは、アーキテクチャプラクティスによって、そのエンゲージメントモデルを理解し、計画するために使用されます。これは、より優れたアーキテクチャの成果をサポートまたは提供するための成果物、タスク、およびツールを定義するために使用されます。アーキテクト エンゲージメント キャンバスを利用して、プロジェクトガバナンスを強化することにより、スコープの変更に対する承認プロセスを明確にでき、スコープの管理が徹底され、プロジェクトの進行がスムーズになります。

  ⇒ 参考サイト:  https://iasa-global.github.io/btabok/architecture_process_engagement.html

このように、BTABoKのモデルや手法を活用することで、アジャイル型システム開発の課題に対処し、より効果的な開発プロセスを実現することができると考えられます。

実際にアジャイル型システム開発の問題点を解決するためには、BTABoKのモデルや手法の理解を深める必要がありますので、BTABoK解説セミナーへの参加などもご検討ください。BTABoK解説セミナーについては、以下のIasa日本支部のイベントのサイトをご参照ください。

https://www.iasa-japan.org/event ご一読いただきありがとうございました。

Iasa日本支部では情報交換や勉強会の場を設けており、アーキテクチャの実践的な活動についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。