不確実性の時代に、アジャイル開発で向き合っていこう

第4回:アジャイルに対する誤解(1)--設計せずにいきなり作る?文書を書かない? - (page 2)

岡本修治 (KPMGコンサルティング) 新田明広 (KPMGコンサルティング)

2023-03-03 06:20

 スクラムによる開発を始めるに当たり、必要な情報をどのように整理すべきかという課題に対しては、さまざまなフレームワークにおいてスクラムの「拡張」が提唱されました。すなわち、スプリントによる開発を開始できる状態にする上で最低限実施すべきこととして、開発活動の大まかな計画を立ててチームを組成し、要求(ユーザーストーリー)を洗い出し、要求を実現していく上で理にかなったシステムの基本構造(アーキテクチャー)を検討することが必要なのです。

 アジャイル開発は、不確実性に対処していく上で最も有望な手法である一方、もともと小規模な開発チーム向けに考案されたものであるため、それをどのようにエンタープライズ開発にスケールアップしていくかが課題でした。その解決を目指したエンタープライズ向けのアジャイルフレームワークの代表例として、ディシプリンドアジャイル(DA)やScaled Agile Framework(SAFe)などがあります。それらの詳細は後続の回で改めて触れます。

「足りない情報がありますか?」「いえ、十分足りています。すぐにでも作れます」

 2つ目の、「アジャイルで標準的に作成する成果物」については、(a)開発に着手する段階で必要な情報と、(b)エンドユーザーにリリースし、運用していく段階で必要な情報、とを分けて考える必要があります。まず(a)については、筆者の過去の経験談を基に解説します。

 ある企業においてDAの適用を支援した際、要求と概要設計を固めるために、ユースケース図やアクティビティー図など、統一モデリング言語(UML)ベースのラフなモデルをプロダクトオーナー同席のもとフリップチャートに書き出し、短期集中的に議論するというアプローチを採りました。要求定義や設計を従来型の書面でレビューする形式をこれまで採られていたクライアントにとって、このような方式や進め方は、いい意味でショックだったようでした。

 具体的には、方向付けフェーズ(注:DAにおいて、図2の左側の四角に記載された作業を行うフェーズ)の最終日に、筆者が「次の反復における活動をどうすべきと考えているか(もう少し要求や概要設計の方向付けを継続する必要があるか、それとも構築を開始するか)」と問いかけたところ、スクラムマスター担当のマネジメント層から、「アジャイルの要求定義や設計のやり方は分かったが、成果物としてもう少し何か残しておく必要があるようにも思う。その点について、一般的にはどう考えるべきか」という質問がありました。

 筆者は、「これまで我々が作ってきた成果物(フリップチャートに書き出したUMLのモデルや画面遷移、DBテーブルの項目一覧、その他仕様などのメモ)の情報で、明日から開発を始められますか?それともまだ何か足りない情報がありますか?」と逆に質問しました。それに対する答えは、あえて原文のまま書きますが、「いや、全然作れますよ」というものでした。「では早速明日から作りましょう」と、構築フェーズに着手することに関係者全員一致で合意しました。

 一方の(b)に関しては、プロジェクトライフサイクルの終盤、システムの仕様が安定し、その内容を文書に落としても手戻り修正が発生する可能性が低くなったタイミングにおいて文書を書くためだけの反復を行うというアプローチが採られるのが一般的です。この点については次に説明します。

現状踏襲を見直してみる

 ウォーターフォール方式からアジャイル開発に変わっても、必要な文書は作成します。ただし、重要なことは、必要な文書とは何かを改めて見直してみることです。ウォーターフォール方式の場合、開発した現物が目に見える状態になるまで半年あるいは数年先となるため、初期の段階においては、文書でしか構築するシステムの確からしさを確認するすべがありませんでした。このため、作成する文書も多くなりがちです。

 一方、アジャイル開発の場合は、短い期間で現物が見える、操作できる状態になるため、文書に頼らなくても現物で確認することが可能になります。このような変化も踏まえて、必要な文書を見直していくことが肝要です。

 アジャイル開発を始めるに当たっては、後になって認識齟齬(そご)が発生しないように作成する文書を、チーム内およびステークホルダーとも合意しておくことが必要です。作成する文書を選定する場合には、ウォーターフォール方式で作成していた文書を参考にすることが多いと思いますが、安易にそのまま踏襲して全て作成するといった方針は避けるべきです。ウォーターフォール方式で作成していた文書についても、改めて作成する目的やこれまでの活用度合い、今後の活用方法を見直して、選定を進めていくことが望まれます。

 また、作成する文書を選定するもう1つの観点は、コストです。文書の作成には、当然ながら労力が発生します。システム開発を発注する企業にとっては、作成される文書に対しても対価を支払っていることに十分に留意する必要があります。その労力や対価に対して、見合う価値を該当の文書が提供できるのか判断する必要があります。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ホワイトペーパー

新着

ランキング

  1. セキュリティ

    「デジタル・フォレンジック」から始まるセキュリティ災禍論--活用したいIT業界の防災マニュアル

  2. 運用管理

    「無線LANがつながらない」という問い合わせにAIで対応、トラブル解決の切り札とは

  3. 運用管理

    Oracle DatabaseのAzure移行時におけるポイント、移行前に確認しておきたい障害対策

  4. 運用管理

    Google Chrome ブラウザ がセキュリティを強化、ゼロトラスト移行で高まるブラウザの重要性

  5. ビジネスアプリケーション

    技術進化でさらに発展するデータサイエンス/アナリティクス、最新の6大トレンドを解説

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]