アジャイル開発とは、従来の重厚な開発プロセスの問題点を解決するために、新たに生み出された開発手法のことです。計画・設計・実装・テストの開発工程を、機能単位の小さいサイクルで繰り返し行うため、優先度が高い機能から素早くサービスを提供できて、仕様変更にも柔軟に対応しやすいという特長を持ちます。本記事では詳細は省略しますが、アジャイル開発概要や手法について理解を深めたい方は、当サイトに掲載されている「アジャイル開発とは？代表的な手法や進め方を解説！」記事を参考ください。
いわゆるアジャイル開発の教科書的な著書や記事は過去に多数執筆されてきましたが、いざ実際に現場に新しい開発手法を導入すると当然のことながら、教科書には答えがない様々な課題を抱えることになります。本記事では、アジャイル開発の一手法である「スクラム開発」に実際に筆者が取り組んだ経験から見えてきた開発現場のリアルな課題とその対応策を前後半に分けて紹介していきます。
「アジャイル開発とは？代表的な手法や進め方を解説！」（Digital Business Sherpa）
著者プロフィール
伊藤忠テクノソリューションズ株式会社
新事業創出・ＤＸ推進グループ ＤＸビジネス推進事業部
デジタルイノベーション部 データ・アジャイル課 横尾 和哉
2017年伊藤忠テクノソリューションズ株式会社に入社後、金融・流通業界のお客様を中心にDX企画・開発を担当。
お客様企業の内製化支援及びアジャイル開発推進を経験。
DX時代におけるアジャイル開発の普及
本題に入る前に、DX時代においてアジャイル開発が普及した背景について簡単に触れていきたいと思います。経済産業省が定義する「デジタルガバナンス・コード2.0」によると、DXとは、現代の変動の激しいビジネスの世界において新たなデジタル技術を活用してスピーディにビジネス変革を推し進めていくことで、競争優位性を高めていくことと解釈することができます。迅速に変革を進めようとすると、従来の受託開発のように、事業会社の情報システム部が定めた仕様に基づいて、外部委託の開発ベンダーが長期間かけてウォーターフォール開発をする方法では限界があります。そのため、各事業会社はシステムの内製化及びアジャイル開発を推進して、ビジネスの変化に柔軟かつ迅速に対応できるような体制作りが急務となりました。ただし、全てのシステム開発にアジャイル開発が適している訳ではなく、バックオフィス業務や会計処理を自動化する基幹系システムのように、高い品質が求められ納期が明確に決まっているようなケースでは、ウォーターフォール開発を採用した方が適することが多いです。事前に組織内で開発手法の採用基準を明確にしておき、いくつかの開発手法の中から適切なものを選択できることが、第一に大切なことであると考えています。
出典：「デジタルガバナンス・コード2.0」（経済産業省）
アジャイル開発を阻む様々な課題と対策
本題になりますが、筆者が、過去顧客企業のシステム内製化支援案件で取り組んだアジャイル開発(スクラム開発)や、実際に直面した課題や対応策について、各パートに分けて紹介していきます。
プロジェクト立ち上げ期に気をつけたい事
既存の社内規約・文化との向き合い方
日本の大企業では、過去のシステム開発や障害対応の経験から自社独自の様々な社内規約が定められていることが多いです。特に金融業界などミッションクリティカルなシステムを多く取り扱ってきた社会的影響度の高い業界においては、ウォーターフォール開発を前提とした開発ガイドラインやシステム設計規約、プロジェクト管理規約が存在します。
しかしながら、アジャイル開発において、それらの規約に則り重厚なドキュメント作成・テスト実施や、社内承認を通すための膨大な説明資料作成などを開発チームが行うと、素早く繰り返しリリースするアジャイル開発のメリットを十分に享受することが難しくなります。また、アジャイル開発チームを組む場合、顧客企業の業務部門がカウンターになることが多く、システム開発に伴う各社内規約に精通している人材が身近にいない可能性があります。そのような場合は、プロジェクト開始時など早い段階で顧客企業の情シス部門やリスク管理部門の有識者と連携して、プロジェクトを進める上で必要となる事務手続き、品質判定基準・承認フロー、システム設計規約や成果物スコープ等の既存の社内規約について把握しておく必要があります。
そして、顧客社内の規約を確認した結果、アジャイル開発を考慮した内容になっていない場合は、アジャイル開発に適した規約への改正及び文化醸成の支援をするのもアジャイル開発チームのミッションの一つとして考えられます。
筆者が参画していたスクラム開発案件においても、開発初期の各種資料作成やリリース準備などは、一部ウォーターフォール開発を前提とした顧客社内規約に則り対応せざる得ない部分がありました。そのため、明らかに現状に馴染まない既存の規約・文化については課題を整理して、顧客経営層からトップダウンで各関連部門に既存規約見直しの必要性を説いて頂くことで、従来保守的なシステムリスク部門から積極的な協力を得ることができ、結果としてアジャイル開発を考慮した規約への変革を迅速に進めることができました。
ドキュメント成果物スコープについて
ドキュメント成果物のスコープに関する定義も、プロジェクト立ち上げ期に検討が必要なポイントになります。ウォーターフォール開発を前提とする開発ガイドラインや企業カルチャーに、そのまま準拠して全てのドキュメント作成を行うと工数が膨れ上がりスピーディな開発が難しくなってしまいます。また、アジャイル開発では仕様変更が発生する可能性が高いため、変更時の資料修正の工数も膨大になってしまいます。そのため、プロジェクト計画時に、各ドキュメントを作成する目的を明確にして、必要性が高くないドキュメントに関しては、成果物スコープから外すことや他の手段での代替を検討するべきです。システム特性や重要度にもよりますが、基本設計書レベルのものは、仕様の明文化や運用引き継ぎの観点で作成が求められるケースが多いです。そのため、成果物スコープには原則含めつつ、システム特性に合わせて記載フォーマットの工夫をするようなアプローチが望ましいです。
一方で、詳細設計書、プログラム設計書レベルのものは思い切って成果物スコープから外すことをオススメします。アジャイル開発だから全く不要というわけではありませんが、作成工数に見合うメリットが明らかに少ないケースが多いからです。例えば、設計者から実装者への詳細指示の観点で考えると、アジャイル開発では短期間のうちに同じ担当者が設計、実装を一気通貫で行うことが多いため、わざわざ資料化する必要性は低いと考えられます。
ただし、後から開発担当者以外が仕様や機能詳細を十分に把握することができるように、基本設計書の拡充や、ソースコードへのコメント記述を必須ルールとするなど、詳細設計書を残さないデメリットを軽減する対策は検討するべきです。
まとめ
新しい開発手法を採用するにあたって、今までの社内規約・文化が適さないケースは往々にしてあります。そのため、アジャイル開発が社内に浸透するまでは、関係各所に対する地道な説得が求められることが多いです。顧客や関係者の理解を十分に得るためには、アジャイル開発だから一般的にこうするべきという説明では不十分であるため、一つ一つの事柄に対して本来の目的や必要性を分かりやすい言葉に落とし込み、周囲を巻き込みながらアジャイル開発に適した社内規約・文化を根付かせていくこともアジャイル開発チームの重要なミッションの一つだと筆者は考えます。
後編は、「アジャイル開発におけるテストの考え方」、「スクラムチームの各ロールが十分に機能するための工夫」をテーマにして、引き続きアジャイル開発現場の課題と対策についてお伝えします。
※部署名、役職名、その他データは公開当時のものです。
