開発の工程を短い期間にまとめ繰り返すイテレーションという考え方があります。開発を細分化することで現場に，そしてユーザーにどのようなメリットがもたらされるのでしょうか。本連載では，開発チームに提案したいイテレーションの手法と重要性について紹介します。

開発を分解して小さくイテレーション（反復）することが重要な5つの理由

GitLabのGrowthチームが2019年後半に結成された時，GitLabではユーザーベースの成長を加速させることを目的とした実験の設計，実装，リリースの経験はまだほとんどありませんでした。経験豊富な人材を採用したものの，実験の実装とリリースにかかる時間を予測することは依然として困難でした。そこでGrowth:Expansionチームが取り組んだ最初のものが「パイプラインの提案」についての実験でした。この実験のアイデアは，ユーザーがCI/CDパイプラインをセットアップできるようにUIをガイドするという，シンプルなものでした。

こうして作られたガイドツアーはマージリクエストするページから始まり，CI/CDパイプラインを設定する方法を学習するかユーザーに確認します。オプトイン（許可）したユーザーには，設定を完了するのに必要な3つのステップを案内しました。

Growth:Expansionチームはこれをシンプルな3ステップガイドと見なしたため，完了するための最小の実験になるかどうか最初に考慮することなく，リリースするためにコミットしました。ガイドツアーはGitLabでまだ実施されていないため，私たちとしては作りたかったものです。しかし結局のところ，これは最もイテレーション的なソフトウェア開発のアプローチではありませんでした。今日，私たちが考えているのは「私たちテストして学習できる最小のものは何だろう」という問いです。

チームでのソフトウェア開発における価値観の1つにイテレーションがあります。これは「可能な限り最小で，可能な限り迅速に取り出す」ことを実行しようと努めることを意味します。この価値観はMVC（minimal viable change：最小限の実行可能な変更）の概念から導き出されます（※1⁠）⁠。

※1

MVCはできるだけ最小にすることをおすすめします。ユーザーが成果を改善できるように，可能な限り迅速に変更できるように目を向けてください。

振り返ると，「⁠パイプラインの提案」実験でMVCを採用できなかったと気づきましたが，当時の失敗は最も価値ある教訓の1つ「常に，最初に実行可能な最小の変更を完了するように努めること」をもたらしてくれたので，今となっては感謝しています。イテレーション的ソフトウェア開発の概念はなお価値があります。実験を伴うならなおさらにです。

開発を分解して，小さくイテレーションすることが重要だとする理由が5つあります。

• ユーザーがより早く価値を獲得できる
• 付加価値がないものをリリースするリスクを軽減する
• 変更の影響に関する分離と理解を容易にする
• チームがより早く学習を開始できるように，より早くリリースできる
• チームがさらなるイテレーションについてより早く考慮できるようになる。または，より早く実験を中断することを決断できるようになる（時間とリソースの両方を節約する）

以下の図2を見てください。

図2の「非実験的な作業」では，チーム1は小さなイテレーションを素早く2回の更新を経てリリースしました。一方，チーム2は大きめのイテレーションを1回のみでリリースしました。チーム1は最初の小さなイテレーションから学んだため，チーム2がより大きなイテレーションをリリースした時にチーム1は彼らのソリューションを2度適用できたのです。チーム2は大きなイテレーションをリリースするためにより長い時間がかかることになり，過去の調査結果を利用してソリューションを最適化するという可能性までも犠牲としてしまったのです。

同じく図2の「実験的な作業」では，チーム1は最初のイテレーションを小さくし，初期の結果を確認しました。これにより，最初のアイデアをさらにイテレーションするか，あるいは破棄して新しいアイデアに進むか，証拠に基づいた決断を下すことができました。このイテレーション的ソフトウェア開発のプロセスを通じて，チーム1はアイデア1を3回イテレーションしてリリースすることも，最初のアイデアを破棄してアイデア2で最初のイテレーションに取り組むこともできます。チーム2がアイデア1で大きな最初のイテレーションにかけた時間と同じ時間で，チーム1はすべての開発を達成できました。チーム1はチーム2よりも早く，成功する成果を得ることと学習に到達することの可能性を高めることができます。