ポストコロナ時代に求められるアジャイル開発

ここ1、2年のテレワークやデジタル取引の普及から分かるように、新型コロナウイルス感染症の流行は日本のデジタル活用を一気に数年分進めました。感染拡大が収束した後も、経済再生や社会課題の解決・実現に向けてデジタル活用の動きはさらに進展していくと考えられます。ただ、その実現のためにはデジタル化による業務の効率化やコスト削減だけでなく、ビジネスモデルの変革を伴った、デジタルを中心とした新サービスの創出が重要な鍵となります。
一方で、ポストコロナと呼ばれる今の時代は、未来が見えづらい状況にあります。1年後はおろか、1カ月先のことでさえ予想がつきません。誰にも正解が分からない時代のソフトウェア開発では、充実した計画を立てて進める開発技法（WFモデル開発が代表的）よりも、試行を繰り返しながら正解にたどり着く開発技法が重要になってきます。「Plan」で考えるのではなく「Do」で探る、「テスト&ラーン」が可能なソフトウェア開発技法こそが「アジャイル開発」です。

アジャイル開発の特徴

アジャイル開発の特徴を、WFモデル開発との比較から見ていきます（図表1）。

WFモデル開発は、変化の少ない安定した環境において、予測可能性があり、かつ確実性のある開発を目的とする際に選択されるのに対し、アジャイル開発は混沌（こんとん）とした激しい変化のある環境の中で、迅速に価値を提供することを目的に選択されます。そのため、WFモデル開発では大規模なシステムを一気に作り上げますが、アジャイル開発では小さく作って、リリースした製品を試しながら正解に近づけていくというやり方を取ります。

また、WFモデル開発では知識や情報を文書化した「形式知」で共有し、それをベースに顧客の要求のうちシステム化する対象を要件として取り決め、正式な承認を受けます。要求は、変化する場合でも予測可能な範囲の進化に留まります。

一方、変化が激しい環境で用いられることが多いアジャイル開発では、時間や手間がかかる文書化よりも、個人間の「暗黙知」を共有することで意思疎通を図ります。そのため、同じフロア内で開発チームの中に入って一緒に活動する専任の顧客を通じて意思決定を行います。顧客の要求事項はバックログと呼ばれる優先度の高い順に並べたリストで管理し、定期的に内容を見直します。そうすることで、その時点で常に最も優先順位の高い要件を開発するのです。アジャイル開発ではこのようにして「予測できない変化」に対応していきます。

開発チーム編成の違い

WFモデル開発とアジャイル開発では、開発チームの編成において、チーム員の技術レベルにも違いが見られます。図表2は、適用する手法の理解と利用の観点から、技術者の技術レベルを定義しています。最上位のレベル3は、適用条件に合うように手法そのものを改訂できる技術力を持つ人たちです。一方、レベル1は手法を適用できる技術力であることを意味しており、どの程度、適用できるかによって、1B（手法をマニュアルなどに沿った手続き的な部分で遂行できる）と1A（手法を自由裁量の部分で遂行できる）に分かれます。

開発チームの人員構成について、WFモデル開発とアジャイル開発の違いを表したのが図表3です。WFモデル開発では、技術レベルの高い人がチーム員にタスクを割り振り、プロジェクトを進めていきます。そのため、1割の高レベル技術者（レベル3）と、3割程度のレベル1Bという構成となります（右）。これに対してアジャイル開発の場合は変化への対応が重要になるため、チーム員には常に応用力や自由裁量が求められます。結果として、レベル2～3の高いスキルを持った技術者が全体の3割、レベル1Aの技術者が7割という構成となります（左）。WFモデル開発では組織全体から幅広く人材を活用できるのに対し、アジャイル開発では変化に対応可能な応用力のあるレベルのメンバー構成が求められるところにチーム編成上の特徴があります。

アジャイル開発の課題

ここからはアジャイル開発に特有の難しさや課題について説明していきます。

短期間で作る必要がある

アジャイル開発の難しさは「短期間」でモノを作ることにあります。WFモデル開発ではリリースまでに半年〜1年をかけるのに対して、アジャイル開発ではわずか1〜2週間で動くソフトウェアを作っていきます。 図表4は、アジャイル開発手法の１つであるエクストリーム・プログラミングを提唱したケント・ベック氏が、アジャイル開発をウォーターフォールモデルや繰り返し開発と比較したものです。

アジャイル開発では最初にシステム全体の分析を行い、その後はバックログの優先順位の高いものから、動くソフトウェアを短期間で作っていきます。図左側の、WFモデルが時間軸に沿って大きな四角が縦方向に積み重ねられているのに対し、図右側のアジャイル開発は小さな四角が横方向に隣り合って表現され、分析から設計、実装、テストを短時間で「ブレンド」して実施していく様子が描かれています。ブレンドとは「それを開発するのに最も適した方法で開発してよい」ということ、つまり要件に合わせて自由裁量で開発を進めるができ、必ずしも設計→実装→テストの順に進めなくてもよいことを意味します。ブレンドはアジャイル開発においては非常に重要な考え方であり、より高度な技術が求められることになります。分かりやすい例として挙げられるのが、アジャイル開発で開発手法として選択されることのあるTDD（テスト駆動開発）です。TDDではまずテストコードから実装し、テストコードが成功するようプロダクトを実装していくという順序で開発を進めます。

自己組織化に時間がかかる

アジャイル開発の難しさを考える時に直面するのが、「自己組織化」という問題です。開発チームの中で各技術者が主体的に、適材適所で役割を果たすことを「自己組織化」と呼びます。アジャイルの開発チームには上下関係に基づかないフラットな体制が推奨されており、個々の要件に応じて、適任と思われるチーム員が自律的に役割を果たしていきます。
しかし、自己組織化を実現するのは簡単ではなく、時間もかかります。特に日本のソフトウェア産業では多重下請け構造が定着しており、開発チーム員の多くはチームリーダーからタスクを割り当てられ、それに従う形で作業を進めてきました。指示通りに作業することに慣れた技術者が、ある日突然、主体的に行動する「自律した技術者」に変わることは困難です。自己組織化を実現するにはそれなりの時間がかかるため、自己組織化するまでの期間にどう対応するかが問題となるのです。

よく用いられるプラクティスが知られていない

アジャイル開発についての知識・理解不足から来る問題もあります。アジャイルを実現するために有効な手段・モデルにプラクティス（開発習慣）があります。図表5は、欧米の技術者がよく用いるプラクティスの一覧です。マネジメント系・技術系とも上位10位まではここ10年程度変わっておらず、これらはほぼ標準的に用いられるプラクティスと言えます。ところが、初めてアジャイル開発に取り組む人はこうした情報を往々にして知りません。どのプラクティスを実施するかをゼロから検討するのでは、アジャイルをうまく進めるのは難しいでしょう。

このような知識不足により、アジャイル開発と「アジャイルっぽい開発」が混同されるという状況も生まれています。例えば、プロトタイプ（試作品）を作っているつもりが、いつの間にかそれが本物に変わってしまったというようなケースです。プロトタイプは、正常系の主要な機能は動くために一見完成しているように見えますが、多くの場合、異常系や性能などが考慮されていないため、製品として使い物になりません。プロトタイピングは設計課題を解決するための手法であり、アジャイル開発とは異なります。

「仕様書を書かない開発」をアジャイル開発と誤解されるケースも目立ちます。ソースコードを読めば仕様は分かりますが、その仕様を実現するために、なぜそのように設計したのかという設計理由は、ドキュメントに残しておかなければ後から確認できなくなります。リリース後の改造や保守の際に設計理由が分からないと、開発に時間がかかってしまうだけでなく、不用意な修正のためにバグを作り込んでしまう危険性があります。アジャイル開発でも、仕様書が必要であることに変わりはありません。

日本の品質レベルを支えてきた強みの活用が不十分

図表6は、マサチューセッツ工科大学教授のマイケル・A・クスマノ氏の論文（2003年）から引用した、開発プロジェクトのパフォーマンスを国際比較したものです。注目すべきは新規コード行数／人月（生産性）と、出荷後12カ月バグ数／KL（品質レベル）です。約20年前のデータですが、この時点ではいずれも日本が他国に比べて桁違いに優れていたことが分かります。
この日本の品質レベルを支えてきた技術が、バグにこだわる考え方と取り組みです。代表的なものが「レビュー」であり、「バグのなぜなぜ分析と水平展開」であり、「品質ゲート^※1 」です。こうした技術を持っていることは、品質保証における「強み」だと言えます。ぜひともこの技術をアジャイルにも活用すべきですが、現状は十分に活用されているとは言えません。

※1：プロジェクトのフェーズ（工程）間に一定の基準を設け、基準を満たすソフトウェアのみ次工程へ進めるというように門（ゲート）を設ける品質保証の方式

客観性を担保しにくい

アジャイル開発における代表的なメトリクスに「ストーリーポイント」と「ベロシティ」があります。これらのメトリクスは、どちらも相対値であるため、客観性を担保しにくいという問題があります。ストーリーポイントとは「その要件を実現するのに必要な作業量の相対値」であり、具体的には、基準となるある機能を実現するために要した作業量を10とした場合、今回の開発対象は基準に比べて難易度が高いので12とする。というように、開発チームの過去実績を基に、見積もり対象の開発に必要な作業量を数値化します。ベロシティは、毎回のスプリントで完了したバックログのストーリーポイントの合計値で表現されるものです。こうしたメトリクスは開発チーム内では分かりやすく有効ですが、チーム外の人には理解できず、客観的な比較や、基準値としての横展開も困難にします。

品質重視のアジャイル開発のポイント

ここまで、アジャイル開発の難しさと課題を見てきました。これらを押さえた上で、品質重視のアジャイル開発を進めるにはどうすればいいかを考えていきます。

プロセス品質とプロダクト品質の両面で品質を確保

ソフトウェア開発において品質を確保するには原則中の原則があります。それは、「プロセス品質」と「プロダクト品質」の２つの面から評価するということです。アジャイル開発でもこの原則に変わりはありません。

プロセス品質では、ソフトウェア開発で実施すべきことをきちんと実施しているかを評価します。アジャイル開発に特有の「短期間」に対応する場合には、後からバグ出しをする方法では間に合いませんから、初めから品質を作り込む工夫が必要です。先に述べたプラクティスについても、良いとされるものはあらかじめ開発プロセスに組み込んでおき、これを的確に実行できる開発チーム編成が必要です。

一方、プロダクト品質は実際に作成した成果物の出来ばえを評価します。あらかじめ成果物の合格基準を決めておき、出来上がったものが基準を満たしているかを常に確認します。具体的には、Doneの定義（動くソフトウェアが完成しているか、プロダクトをリリースしてよいか判定する基準）と、客観的メトリクスによる定量分析から、プロダクト品質を確認します。Doneの定義には、プロセス品質とプロダクト品質の両面から基準を構成する必要があります。審査基準を可能な限り自動計測・自動判定する仕組みにしておくと、品質の良いものが作られていることが常に分かるようになります。

「プロセス品質」向上のポイント

プロセス品質を向上させるために組み込むべきプラクティスについて見てみましょう（図表7）。先述したように、マネジメント系・技術系とも上位10位までのプラクティスはほぼ決まっています。それらを確実に実行するよう、プラクティスを選択しましょう。アジャイル開発の初心者は「スプリント計画」や「デイリースクラム」というようなマネジメント系のプラクティスに目が行きがちですが、品質を決めるのは「ペアワーク」や「テスト自動化と継続的インテグレーション」などの技術系プラクティスです。加えて、これまで日本の品質レベルを支えてきた「レビュー」「ドキュメント化」「バグのなぜなぜ分析と水平展開」などの技術についても、プラクティスとしてアジャイル開発に取り入れることを強く推奨します。

アジャイル開発ではフラットな開発チームが推奨されますが、プラクティスを確実に実行するには一定以上の技術力を確保する必要があります。そのためには、技術リーダーが鍵になります。技術リーダーには開発組織の上位20%に入る技術レベルがあり、コミュニケーション能力も備えている技術者を設定することをお薦めします。一方、チーム員は、適用する技法に沿って自由裁量の部分を遂行可能なレベル1A以上の技術者が望まれます。

「プロダクト品質」向上のポイント

プロダクト品質の向上に関するポイントについても確認していきましょう。その１つは、Doneの定義をあらかじめ明確化し、開発チーム内はもちろんのこと関係者全員が共有しながら開発を進めることです。先述したように、Doneの定義はプロセス品質とプロダクト品質から構成します。図表8は、私がお薦めするDoneの定義です。出荷可能な基準をあらかじめ明確化して、認識をあわせた上で開発を行い、客観的に審査します。プロセス品質についてはその多くを自動計測・自動判定できるような項目で構成しています。なお、プロダクト品質については、できれば開発チームではない第三者的な品質技術者が確認することを推奨します。

比較を可能にするメトリクスも重要です。特に推奨したいのは、他チームや過去のアジャイル開発事例、さらにはWFモデル開発との比較を可能にするメトリクスの収集です。具体的には、Done判定後のバグ、工数、テスト項目数の３つです（図表9）。
「Done判定後のバグ」件数は、WFモデル開発における出荷判定後のバグの件数に相当します。こうした絶対値によるメトリクスを取ることによって、他の開発との比較が可能になり、さらに自分たちのアジャイル開発が客観的にどのように変化しているかを確認できるようになります。

おわりに

アジャイル開発は、短いWFモデル開発ではなく、まったくパラダイムの異なる開発方法です。しかしアジャイル開発においても、ソフトウェア開発での品質確保の原則であるプロセス品質とプロダクト品質の両面から取り組む必要があるのは同じです。具体的なポイントは「プラクティス」「開発チーム編成」「Doneの定義」「客観的メトリクス」の4つに集約されます。これらを参考にアジャイル開発を適用し、新しいサービスの創出に役立てていただければ幸いです。

この記事をシェアする