エンタープライズアジャイル品質保証の基礎~アジャイルプロセス標準整備事例のご紹介

企業としてアジャイル開発を効果的に活用するためには、アジャイルプラクティスだけではなく、マネジメントプロセスの整備が不可欠だ、と様々な試行錯誤を通して、多くの企業により認識されてきています。とはいえ、自社のプロジェクトガバナンスを実現するために、どのようなプロセス標準を定義すべきか、どのように整備すればよいのかなど、まだ模索中の企業もいらっしゃると思います。ここでは、株式会社シーエーシーの実体験を通して、エンタープライズアジャイルプロセス整備の過程およびあり方について探ってみます。

1.はじめに

近年、各企業では競争力の維持・強化のためデジタルトランスフォーメーション(DX)をスピーディに進めることが求められていますが、DXを実現するためにはアジャイル/DevOps手法の導入が不可欠です。では、アジャイル/DevOpsに対しどのようにプロセス標準を整備すればよいのでしょうか?残念ながら現時点では決定打といえるものは存在していないようです。

株式会社シーエーシーでも数年前よりアジャイル/DevOpsのプロセス標準整備を推進してきましたが、その過程で業界団体や国内外のアジャイル関連イベントに参加してアジャイル開発のあるべき姿を模索してきました。また、同業他社やユーザー企業とも情報交換し、加えてプロセス改善コンサルタントや著名なアジャイル専門家にアドバイザーになっていただくなどして情報収集を続けています。昨年は海外のアジャイル専門会社が当社グループの一員となりましたが同社との協業にも取り組んでおり欧米流のオフショアアジャイルのノウハウを共有するための活動を行っています。

アジャイルのプロセス標準整備の在り方の議論の一助とすべく、こうした活動から得た知見を当社のプロセス標準整備活動を通して紹介します。

2.プロセス標準整備の経緯

当社のアジャイル/DevOpsプロセス標準整備の取り組みの変遷を概説します。

(1)アジャイル開発用のプロセス標準類を持たず、社内品質保証体制の例外扱いとする

初期段階ではアジャイルにプロセス標準は不要と考え用意はしていませんでした。これからアジャイルを立ち上げようとしている企業ではこうした状況が多いようです。

しかし、拠り所となるプロセス標準がないと現場まかせとなりガバナンスが効かなくなる危険性があります。特に期待通りにプロジェクトが進まない場合には、各作業のエビデンスが少ない、作業が可視化できない、説明責任を果たせないなどのネガティブな側面に起因してプロセス標準欠如の問題がクローズアップされる可能性があります。

(2)アジャイルに関するガイドを整備する

次の段階では技術者の知識の共有化を図る目的でScrumXPを採用したアジャイルプロセスに関するガイドを整備しました。アジャイルにはさまざまな手法や流派がありますので会社としてアジャイルをどのように捉えたかということを明らかにする意味では有効でしたが、ガイドは強制力が無いいわば参考書でありガバナンスという点では上記(1)と同じような弱みがあります。国内でアジャイルに取り組みはじめた企業ではこのレベルが多いようです。

当社の場合はガイドの内容が比較的一般論に寄っていたため、実務での具体的な手順・手続きに関する情報が不足していることが課題でした。あくまでも「開発現場の自己責任でガイドをうまく活用してください」というスタンスでしたのでプロジェクトにとっては自由度が高いとはいえ負荷の高い施策であったといえます。

(3)アジャイルプロジェクトに必要な知識体系を整備し、軽量な標準と相当数のガイドを準備する

アジャイルのプラクティス自体はシンプルですが実際に必要な知識・経験は多岐にわたります。しかも必要とされる技術要素はプロジェクトによって大きく異なります。そこで当社の技術者のスキルレベルに照らしアジャイル開発に必要とされる知識領域群を「DXプロセス知識体系」として整理し、各プロジェクトはこの知識体系のうち不足する箇所をビルディングブロック的に補うことにより円滑にアジャイル手法を運用できるよう図りました。

また、この知識体系の使い方や、必須となるプロジェクト手続きについて解説する必要最小限の標準書と実務的ないくつかのガイドを策定しました。

(4)アジャイル専門会社のプロセス標準と整合をとる

昨年買収したアジャイル専門会社はRational Unified Processのプロセス標準をアジャイルに援用していましたが、プロセス標準そのままを実行しているのではなくプロジェクトごとに柔軟にプロセスを変化させていました。また、ビジネス上の必要性から純粋なアジャイル手法のプラクティスだけではなく開発前の準備段階やリリース前の作業のためのプロセスを補っていました。これらは当社にはない視点でしたので上記(3)にて構築した知識体系とプロセスにこうしたアジャイルプロフェッショナルサービスの方式を取り入れ整合をとるようにしました。これが現在の当社のアジャイル/DevOpsプロセスの原型となっています。

3.アジャイル/DevOpsプロセス整備の内容

(1)DXプロセス知識体系

図1は策定したDXプロセス知識体系の全体像です。自社の強み・弱みを勘案しアジャイル/DevOps推進に必要な知識領域を定義しています。

骨子としてはScrumXPを中心としたAgileの知識領域を中心に、拡張領域としてCI/CDの自動化技術やマイクロサービスなどのDevOpsの知識領域を配置しています。品質保証や大規模プロジェクトへの対応などプロジェクトにより必要性が異なる知識領域はオプションとしました。またこれらの知識領域のベースにマインドセットやソフトウエアエンジニアリングの基礎知識領域を置いています。なお、これらの各知識領域は包含関係や依存関係があります。

【図1.DXプロセス知識体系】

(2)標準書・ガイド、ツール

上述のDXプロセス知識体系に沿って、軽量な標準書2種類と参考書・自習書という位置づけのガイド8種類を提供しています。また、開発案件のアジャイルへの適合性を判断するツールや国内外のアジャイルに関する定量データ(人気のあるアジャイルプラスティス一覧など)を掲載した資料も用意しました。

一般的にアジャイル手法では継続的な開発という側面が強調され、それ以前の準備については「スプリント0で手短に済ます」という説明に終始することが多いようです。また、リリースタイミングで通常のスプリントとは別に特別に行うべきことも曖昧となっています。しかしプロフェッショナルなアジャイル開発という観点からはこれだけではユーザー/開発者間で認識齟齬が生まれる恐れがあります。当社プロセス標準では初期段階でユーザーと何を合意すべきか、どのような準備をすべきか、リリースタイミングではどのようなタスクをこなすべきかなどについてAgile Project Managementのフレームワークに沿って定義しています。

また、従来のウォーターフォール開発では必須となっていた品質保証活動のアジャイルへの適用方法やプロジェクトとアジャイルチームとの関係性など、PMや開発者が直面するテーマに対して様々な対応策のバリエーションをガイドとして提供しています。

【図2.DXプロセス知識体系に即した標準書・ガイド類】

4.今後の展望

様々な試行錯誤や他社との情報交換を通じて、アジャイル開発を単純なアジャイルプラクティスのみを手掛かりに進めるのでは不十分であり、かつ、大掛かりなプロセス標準を用意するのはアジャイルにふさわしくないとの結論に至りました。そこで、組織として必要とされる知識領域を「DXプロセス知識体系」として定義しこの体系上に実用的なプロセス標準やガイドを整備することにより柔軟性と網羅性を確保するようにしました。また、ScrumXPといった純粋なアジャイルプラクティスだけではカバーしきれない実務的なプロジェクトマネジメントプロセスも整備しました。

今後は、アジャイル/DevOpsの領域で実績を積むことと、そこで培われたノウハウを組織のプロセス資産として取り込むという改善のサイクルを回すことで、内容の充実を図り更なるアジャイル成熟度向上につなげたいと考えています。

おすすめ記事