目次


アジャイル手法に沿ったソフトウェア・プロジェクトのスコーピング

アジャイルの原則を適用して開発を正しい軌道に乗せる方法

Comments

多くの場合、ソフトウェア開発方法論は忠実に遵守されていますが、代替手法にこだわって失敗する可能性はあります。そうは言っても、ソフトウェアのスコーピング・プロセスに関しては、その責務を果たすのに最良の手段としてアジャイル方法論に一貫して従うべきです。その根拠として、ソフトウェア・イニシアチブを前進させるには、アジャイルが効果的かつ効率的なフレームワークになることが幾度となく証明されています。

Helastel 社はプロジェクトのスコーピングを実に真剣に受け止めており、このことは、成果にはっきりと表れています。同社は最適な最終「成果物」に至るまでの経路を描き出すために、あらゆる角度からのユーザーの見方を理解した上で、ビジネス要件に関する的を射た質問に要約しています。このプロセスをサポートするのにアジャイル方法論が大いに役立つのはなぜなのかを説明しましょう。

ソフトウェアのスコーピング手法の選択は極めて重要です

一部の開発者やプロジェクト・チームは、他のあらゆるソフトウェア開発方法論に優先して、特定のソフトウェア開発方法論に宗教的熱意を持って従っていますが、これは疑問の余地がある慣例です。革新的または画期的な新しい手法の潜在的価値を封印するのではなく、「餅は餅屋」の戦略を採用し、幅広い代替手法の中から最良のものを選ぶことで、組織は多大な利益を得ることになります。

この意見は、私がプロジェクトに関わるごとに真実味を増していますが、1 つの非常に重要な分野には当てはまりません。その分野とは、ソフトウェアの初期スコーピング・プロセス (プロジェクト全体が成功するための経路を描き出すことを目的に、検討範囲を絞り込むプロセス) です。初期スコーピング・プロセスに関しては、アジャイルが突出して優れた手法であり、私はアジャイル理念の狂信者と自称してはばかりません。

ソフトウェアのスコーピングとは何か?

根本的に、優れたソフトウェア・スコーピングを要約すると、協議のために質問をして意見を聞くプロセスということになります。このプロセスは、通常のクライアントとサプライヤーの間での対話や、文書化された希望の要求リストを集めるというだけのことではなく、集中的で目的を定めたプロセスです。

効果的なソフトウェア・スコーピングによって、以下の目的が達成されることになります。

  • ビジネス・ニーズの点でもユーザーの期待値という点でも、根底にあるプロジェクト要件を確定する
  • 最も有意義な変化をもたらすことになる目標に合意する
  • 以降の開発プロセス期間内に摩擦を減らす上での基礎作りをする
  • 予算大綱およびスケジュールと併せて、極めて重要な成功要因を文書化する

アジャイルを選ぶ理由とは?

ソフトウェア・スコーピングにアジャイル手法が最良の方法論およびツールセットとなる根拠は、ソフトウェア・イニシアチブに正しい推進力を与えるのに極めて効果的かつ生産的なフレームワークとなることが幾度となく証明されていることにあります。アジャイル手法は、プロジェクトを開始する時点、そしてプロジェクトが展開する中でも、プロジェクトのニーズを全体的に理解して最適な最終成果物への最短ルートを計画する推進力となります。

アジャイル手法がスコーピングに最適な方法論である理由をひと言で言うと、アジャイル手法は最初に大まかな要件を確立し、後から要件を詳細化していくよう促すためです。

導入方法

組織がビジネス上の課題を解決するためにテクノロジーが必要であることを認めると同時に、プロジェクトのスコーピング・プロセスがスタートを切ります。

その後に続く混乱の中では、プロジェクトの計画担当者たちの堅実さよりも、迅速に進めたいという熱意が優勢になります。ここで重要となるのは、正しいバランスを取ることです。手抜きをするというリスクは誰も歓迎しませんが、プロジェクトに早速着手してエネルギーと誠意を具体的なアクティビティーに変えたいという意欲が上回って、そのリスクを敢えて負うことになるという事態は珍しくありません。

アジャイルの原則は、この初期段階において欠かせない自制心を植え付け、プロジェクトの目標を徹底的に調べなければならないことを支持する一方で、あまりにも多くの不必要な些事で負担がかかりすぎないようにします。

深い関与を促す

あらゆるソフトウェア開発イニシアチブに共通して必要なのは、初期段階でプロジェクトのスコープを見極めることです。それと並行して、この初期段階は外部のソフトウェア開発者/開発会社とクライアントについて知るための大切な時間にもなります。スコーピングのセッションに利害関係者全員が関与して、テクノロジーのパラメーターと基礎となるワークフローだけでなく、長期的なビジネス戦略を徹底的に調査すると、このセッションの成果は倍増するはずです。セッションに招かれた経営者は共有される情報の詳細レベルに度々驚かされるとともに、ソフトウェアの専門家になるよう期待されていないことを知って安心します。このプロセスで、ソリューションを求める背後の理由を調べるための強硬な質問をクライアントに迫って、想定した額面通りの金額を盲目的に受け入れるどうかをテストされているような気にさせるのではなく、クライアントをそのようなプレッシャーから解放された気分にさせたときに、深い関与が生まれます。

前述したとおり、スコーピング・セッションでの調査によって大まかな要件を確立するという目的を複雑化する必要はありません。アジャイル手法は、両方の長所を生かすよう促すものです。プロジェクトのデリバリー・フェーズが本格的に開始される前から開発チームをあまりにも多くの些事で行き詰らせることがないよう、組織を誘導して大まかなニーズを把握させるための柔軟なアクション指向の手段、それがアジャイル手法です。

極めて詳細な初期スコープの欠点

プロジェクトの当初から極めて詳細な要件を探ろうとすると、アジャイル方法論のリーンで効率的な原則をはねつけることになります。極めて詳細な初期スコープの欠点としては、以下が挙げられます。

  • 貴重な時間の浪費と不必要な遅延の発生。スコーピングの段階で、考えられるありとあらゆるソフトウェア機能のリストを作成して時間を無駄にするという過ちはよく見られます。包括的なリストを作成したとしても、開発プロセスの後の段階で特定の作業項目がキャンセルになったり見直されたりする可能性があるからです。それによって、重要なビジネス目標を達成するまでの時間に遅れが生じると、費用削減の効率化に時間がかかったり、ROI 計画が台無しになったりします。さらには、新たな収益を創出する製品やサービスが完成したとしても、その時点ではすでに競争上の優位性が失われているといった事態も考えられます。
  • 予算における明確さの欠如という落胆。詳細な作業項目について、前もって完全に予算を見積り、スケジュールを立て、同意に至ろうとする努力は、経理担当者が夢見る理想の状況のように思えますが、経験を積んだソフトウェア開発プロジェクト・マネージャーはそれを実現するのは無駄な試みであることを知っています。開発者たちは苦労して得た経験を生かし、現実的でありながらも、アジャイル方法論のダイナミックな長所からそれほど逸脱することなく、予算の期待値を提示できるようでなければなりません。論理的に考えて、有益なソフトウェア・プロジェクトにはある程度の柔軟性を伴う、寛容なスコーピング手法が必要です。
  • 組織は自らの要件を把握するのが得意ではないという事実。結果がすでにわかっているのに、わざわざプロジェクトのスコーピングを行うのはなぜでしょうか?資格のあるソフトウェア開発者を関与させることの価値には、独立したアドバイスとコンサルティングの専門知識によって、組織がそれまでにまったく把握していなかった要件が導き出されることも含まれます。プロジェクトの規則や条件は常に変わり、しかも変化する市場原理、ユーザーの嗜好、あるいは他の影響要因を明確に予測することはできません。ソフトウェア開発のノウハウを追求する組織は、組織を導くアジャイルなプロジェクトのスコーピング・プロセスを信頼して、厳格なパラメーターにとらわれずにプロジェクトを運営する方法を学ぶ必要があります。

変化に適応する

直感に反しているように感じるとしても、ソフトウェア・プロジェクトを進めるのに最良の方法は、あらゆる紆余曲折をあらかじめ把握せずにプロジェクトを開始することです。変更は避けられないものであり、よく練られた計画を立てたとしても、変更によって計画が台無しにされます。急速に展開する市況や顧客行動などの要因に応じて絶えず期待値を修正するよりも、柔軟に流れに従うほうが遥かに良策です。

幸い、アジャイル手法は他のソフトウェア開発手法とは違って、プロジェクトのスコープを絞り込むことはしません。

変更が発生することがわかっているとしたら、その機会を利用できるよう備えてください。アジャイル手法では進んで変更に取り組み、変更がもたらす潜在的なダメージを吸収するために、スコーピングの段階からプロジェクトの完了に至るまで変更を考慮に入れます。その一方で、プロジェクトを融通の利かない型にはめ込むことはせずに、予定外の機能追加という恐ろしい事態を最小限に抑えます。

予定外の機能追加を防ぐ

予定外の機能追加は、プロジェクトの開始直後に起こる無慈悲に思える作業要件の急増です。最悪の被害を防ぐためにどんなに頑張ったとしても予定外の機能追加が必要になった場合に備えるには、効果的な変更管理プロセスに従うことが最善の方法です。

他の比較的逐次的なソフトウェア開発方法論では、予定外の機能追加に対処できません。例えばウォーターフォール開発手法は真に適応型というよりも、極めて様式化されたプロシージャー駆動型です。この場合、変更の導入がプロジェクトの極めて重要な進路の妨げとなって、遅延、同じ作業の繰り返し、チームの士気の低下、予定外の多額のコストという結果を招く可能性があります。

それとは対照的に、アジャイル手法に従うと変更に対処しやすくなり、予定外の機能追加というリスクが小さくなります。その理由は次のとおりです。

  • 目前の目標以外に気を取られることがありません。
  • 同等のワークロードを交換できます。
  • 不測の事態を許容できます。

目前の目標以外に気を取られることがありません

アジャイル手法は、まだ始まっていない先の段階も極めて重要であるものの、それには気をとらわれず目前の目標を重視する姿勢でいるよう、開発チームを促します。実際のところ、プロジェクトの先の段階に関する開発者の個人的な見解は、スコープが突然変更されたとしても、そうすることで破壊的な影響が及ぼされないようになるのであれば、現実的な見解である限り、明確には定義されないままになります。この原則は、変化する要件、そしてあえて言うなら気が変わりやすいクライアントに、チームがあまり気を取られないようにする効果があります。したがって、企業全体が最新テクノロジーのあらゆる可能性を利用できるとともに、市場とユーザーのニーズと完全に同調することができます。

同等のワークロードを交換できます。

プロジェクトで、土壇場になって X を放棄すると同時に、新しい要件 Y の作成を優先させる必要が生じることは珍しくありません。より厳格な方法論では、プロジェクトの進行中に新しい要件を採用すると、破壊的な影響が出て、プロジェクトが数週間遅れるといった事態になり兼ねませんが、アジャイル手法の場合、影響はそれほど大きくありません。唯一の条件は、2 つのタスクを完了するために必要な作業の量がほぼ同じであることです。

不測の事態を許容できます

変更を取り込んでワークロードを交換できるとしても、それには限界があります。アジャイル手法で許されるトリックのすべてを使い果たした末に、どこからも時間を捻出できないという問題に直面することもあります。この問題から得た発想が、緊急用の予備の時間を設けておくことです。すべてのことが失敗した場合、思いがけない展開に他の時間をすべて費やしたとしても、予備の時間を使って対処すれば、プロジェクトをスケジュール通りに進めることができます。この許容時間は、各開発スプリントに組み込んで、必要に応じてリセットすることができます。プロジェクト全体に対して合計許容時間を設定すると、思ったより早期にその時間が使い果たされる可能性があります。

まとめ

ソフトウェア・スコーピングにアジャイル手法を適用して、構造化されていながらも動的な方法でスコーピングを実施すると、ビジネス目標に忠実に沿った高品質のソリューションを迅速に提供できるようになります。

ただし、アジャイル手法によってソフトウェア・デリバリーが容易になるわけではありません。アジャイル手法はソフトウェア・プロジェクト全体を容易または単純にするための方法論ではないからです。タスクがどのような優先順位でどのように編成されるかに関わらず、各タスクに相当する作業量を前もって評価するのは簡単なことではありません。その評価には根拠のない仮定が入り込む隙もあります。また、スプリントとプロジェクトの管理を取り仕切るための基礎作りでも、スプリントとプロジェクト管理を取り仕切るための取り組みにおいても、予期しない問題が発生する可能性があります。成功に不可欠な要素は、経験を得ることと、慎重に考慮された手法を利用することです。

アジャイル原則は初めから、大まかな要件を決定するプロセスをサポートし、不必要に細かい要件については後に残します。これにより、変更を肯定的に取り込むための基礎が築かれて、変更によってプロジェクトが遅れたり、追加費用が発生したりすることがなくなります。

ソフトウェア・プロジェクトのスコーピングをアジャイル手法に従って実施するということは、開発者が素晴らしいコードを作成することに集中する時間を増やせるだけでなく、組織が最新のデジタル機会を最大限に利用できる状況にあることに、ビジネスの利害関係者が安心できることを意味します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps
ArticleID=1052887
ArticleTitle=アジャイル手法に沿ったソフトウェア・プロジェクトのスコーピング
publish-date=11302017