PR

ディシプリンド・アジャイル・デリバリーの基本モデル「方向付けフェーズ」を理解する

2014年11月12日(水)
藤井 智弘

開発構想と初期計画

利害関係者が多岐に渡るときは、プロジェクトの方向性について合意を取り付けることがとても重要です。方向付けフェーズは、ビジネス状況や技術的観点を踏まえて合意を形成することであり、それを明文化するのが開発構想(ビジョン)です。開発構想は、DADの源流とも言える統一プロセス(Unified Process)における要求管理の主要な成果物の一つであり、同じく統一プロセスを源流とするSAFeにも存在しています。開発構想にどんなことを記載するか、DADでのガイドをピックアップしてみます。

  • 解決すべきビジネス上の課題
  • 重要なフィーチャー
  • 利害関係者のリスト
  • 制約:予算枠、スケジュール上の制約、技術的選択肢、準拠すべき標準規定の有無等

これらを「しがらみを制御する」という観点で、(やや順不同ですが)個々の項目を考えていきましょう。

利害関係者のリスト

方向付けフェーズで合意された事柄は、構築フェーズ以降に発生するであろうさまざまな変更依頼を扱う際の判断基準となります。そう考えると、合意事項そのものが適切な利害関係者で議論されたものであるか否かが重要であることがわかります。
利害関係者のリストは、投資の意思決定の過程で、適切な部門の適切な関係者が関与していることを確認・宣言するものであり、それをもって合意事項の妥当性・正当性を担保することになります。

利害関係者代表者説明責務
スポンサー福沢諭吉当該システムを利用するビジネス部門の代表者。予算の承認・執行権限、プロジェクト全体の最終決定責任者必要なリソース(資金、人員、資材)の提供責任
プロジェクト全体の管理責任
プロダクトオーナー大石内蔵助開発チーム側とユーザ部門との間に立ち、ユーザや利害関係者のニーズを開発チームへ提示する開発スコープの決定と優先順位付け
利害関係者と開発チーム間の調整
ショップオーナー芥川龍之介Webショッピングモールに出店する店舗のオーナー
Webショップ機能の仕様策定に参画
設定されたデモセッションに参加しフィードバック提供
代表者はユーザビリティ試験に参加
パートナービジネスマネージャー宮沢賢治販売代理店経由のビジネスを統括するマネージャー。当該部門は、Webショッピングモールシステムの直接の利用部門ではないが、当該システムのサービス開始によって代理店政策に影響が出るため、各種の調整が必要となる
システムの投資検討への参画
ビジネス面での影響の観点からのフィードバック提供

注意が必要なのは、利害関係者は単なる「新システムのユーザ候補一覧」ではないという点です。
我々はすでに多くのしがらみ(他部門との協業・競業、相反する利害、政治力の差等々)にさらされています。たとえば以下のようなことが考えられます。

  • コンシューマー向けサービスを強化すると、売り上げに大きく貢献してくれている代理店ビジネスに負の影響が及ぶ可能性がある。オンライン販売部門は新システムによるメリットを直接享受する一方で、これまでの稼ぎ頭である代理店ビジネス部門が売り上げを落とすかもしれない
  • 内製化率を高めると外注費は削減できるが、相対的に低い技術力のために品質を落とす可能性が高いので、ビジネス的なリスクを生む元凶になる可能性がある。開発部門よりも品質保証部門に負荷がかかる。開発部門の論理が、ビジネス部門に負の影響を与えかねない事態は看過できない。

利害関係者のリストアップとは、問題解決や投資がビジネス面も含めどういう領域にどのような影響を及ぼしうるかを見極める作業という側面があり、方向性を決める上でとても重要なステップなのです。

「解決すべきビジネス上の課題」と「重要なフィーチャー」

「方向付けフェーズ」の話を初めて聞いた人は、ほとんど例外なく「ウォーターフォール型プロセスの要件定義工程と同様のもの」と誤解します。ここで、両者の違いを強調しておきましょう。
ウォーターフォールでの要件定義工程は、システム要件を網羅的かつ詳細に定義します(正確には「定義を試みて挫折します」でしょうか)。一方、アジャイルでの方向付けでは要件(この場合はストーリー)を網羅的かつ詳細に定義することはしません。これはBRUF(Big Requirement Up Front)と呼ばれ、むしろ積極的に避けるべきアンチパターンと考えられています。
またウォーターフォールでは、要件定義工程で要件を確定することが基本です。設計工程からみると、それは実現すべきシステムのあるべき姿の定義であり、ユーザ(発注側の立場)から見ると、それはリリース時点で手に入ることが約束された機能性の契約です。
これに対して方向付けにおける主たる議論は、投資対効果に向けられます。対象となるビジネスの課題やニーズを考え、それらを解決するためにシステムはなにができればいいのか、ハイレベルの機能性(これがフィーチャーです)を関係付けられればいいのです。ですから開発構想も、ターゲットと定めた主要なビジネス上の課題と、それに応える2〜3個程度の主要なフィーチャー(feature)が記述されていれば十分とします。

次回は、アジャイルとしての要件管理としてフィーチャーやストーリーの話に入っていきましょう。

HPの開発・テスト・検証ツール [PR]
日本ヒューレット・パッカード株式会社

日本アイ・ビー・エム株式会社を経て、現職は日本ヒューレット・パッカード株式会社でHPソフトウェア事業統括 テクニカル・コンサルタントを務める。
いまだ誤解の多い”ちょっと新し目の技術”を、きちんと咀嚼しお伝えして何ぼのこの世界、「アジャイルは品質が…」という若干の誤解に基づく不安にも、きちんと丁寧に答えをだしていこうと思う毎日。

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています