開発の工程を短い期間にまとめ繰り返すイテレーションという考え方があります。開発を細分化することで現場に、そしてユーザーにどのようなメリットがもたらされるのでしょうか。本連載では、開発チームに提案したいイテレーションの手法と重要性について紹介します。
開発を分解して小さくイテレーション（反復）することが重要な5つの理由
GitLabのGrowthチームが2019年後半に結成された時、GitLabではユーザーベースの成長を加速させることを目的とした実験の設計、実装、リリースの経験はまだほとんどありませんでした。経験豊富な人材を採用したものの、実験の実装とリリースにかかる時間を予測することは依然として困難でした。そこでGrowth:Expansionチームが取り組んだ最初のものが「パイプラインの提案」についての実験でした。この実験のアイデアは、ユーザーがCI/CDパイプラインをセットアップできるようにUIをガイドするという、シンプルなものでした。
図1 「パイプラインの提案」ガイドツアーの最初のイテレーション こうして作られたガイドツアーはマージリクエストするページから始まり、CI/CDパイプラインを設定する方法を学習するかユーザーに確認します。オプトイン（許可）したユーザーには、設定を完了するのに必要な3つのステップを案内しました。
Growth:Expansionチームはこれをシンプルな3ステップガイドと見なしたため、完了するための最小の実験になるかどうか最初に考慮することなく、リリースするためにコミットしました。ガイドツアーはGitLabでまだ実施されていないため、私たちとしては作りたかったものです。しかし結局のところ、これは最もイテレーション的なソフトウェア開発のアプローチではありませんでした。今日、私たちが考えているのは「私たちテストして学習できる最小のものは何だろう」という問いです。
チームでのソフトウェア開発における価値観の1つにイテレーションがあります。これは「可能な限り最小で、可能な限り迅速に取り出す」ことを実行しようと努めることを意味します。この価値観はMVC（minimal viable change：最小限の実行可能な変更）の概念から導き出されます[1] 。
振り返ると、「 パイプラインの提案」実験でMVCを採用できなかったと気づきましたが、当時の失敗は最も価値ある教訓の1つ「常に、最初に実行可能な最小の変更を完了するように努めること」をもたらしてくれたので、今となっては感謝しています。イテレーション的ソフトウェア開発の概念はなお価値があります。実験を伴うならなおさらにです。
開発を分解して、小さくイテレーションすることが重要だとする理由が5つあります。
ユーザーがより早く価値を獲得できる
付加価値がないものをリリースするリスクを軽減する
変更の影響に関する分離と理解を容易にする
チームがより早く学習を開始できるように、より早くリリースできる
チームがさらなるイテレーションについてより早く考慮できるようになる。または、より早く実験を中断することを決断できるようになる（時間とリソースの両方を節約する）
以下の図2を見てください。
図2 イテレーション的ソフトウェア開発の力は2つのワークフローから明らか図2の「非実験的な作業」では、チーム1は小さなイテレーションを素早く2回の更新を経てリリースしました。一方、チーム2は大きめのイテレーションを1回のみでリリースしました。チーム1は最初の小さなイテレーションから学んだため、チーム2がより大きなイテレーションをリリースした時にチーム1は彼らのソリューションを2度適用できたのです。チーム2は大きなイテレーションをリリースするためにより長い時間がかかることになり、過去の調査結果を利用してソリューションを最適化するという可能性までも犠牲としてしまったのです。
同じく図2の「実験的な作業」では、チーム1は最初のイテレーションを小さくし、初期の結果を確認しました。これにより、最初のアイデアをさらにイテレーションするか、あるいは破棄して新しいアイデアに進むか、証拠に基づいた決断を下すことができました。このイテレーション的ソフトウェア開発のプロセスを通じて、チーム1はアイデア1を3回イテレーションしてリリースすることも、最初のアイデアを破棄してアイデア2で最初のイテレーションに取り組むこともできます。チーム2がアイデア1で大きな最初のイテレーションにかけた時間と同じ時間で、チーム1はすべての開発を達成できました。チーム1はチーム2よりも早く、成功する成果を得ることと学習に到達することの可能性を高めることができます。
「パイプラインの提案」実験はどのように行われるべきだったか？
いま私たちがプロジェクトを振り返り、何を間違えたのかを見ることは簡単であり、こうした振り返りは失敗の繰り返しを回避することにつながります。GitLabのガイドツアーは構築してリリースするだけのシンプルな実験のように見えますが、結果的には完成まで数ヶ月を要してしまいました。全般的に見れば実験は成功しましたが、実装後に再び着目し、プロジェクトを改善できる可能性があることを確認しました。より多くのユーザーにオプトイン（許可）をうながすために、最初のナッジ（無意識に働きかけること）でイテレーションについて説明することで改善を実装できると判断しました。より小さな実験をすぐにリリースしていれば、より早い段階でイテレーションし、最初のナッジとして最適なものを提供し、より多くのユーザーがガイドツアーから恩恵を受けられたでしょう。
図3 2回目のオプトインの説明ははるかに効果的。より小さなイテレーションをリリースすることで、より多くのユーザーが実験的なガイドツアー機能をオプトイン（許可）するようになる 実験の実装を完了するのに数ヶ月を要したため、実験をイテレーションするのも数ヶ月を要してしまいました。
いま同様の実験をしなくてはならないなら、私たちはさらに小さく開始するでしょう。1ヶ月以内、理想としてはより速く構築してリリースできるものを使うでしょう。例えば最初のナッジにパイプラインの設定方法を説明する既存資料へのリンクを加えたものをリリースできます。それは私たちがナッジの配置、コンテンツ、有効性について検証することを可能にするでしょう。実験のリスクを大幅に減らせたかもしれません。
別の案として、例えばガイドツアーを2ステップに短縮することも可能です。これはGrowth:Conversionのプロダクトデザイナーであるケビン・コモリ（Kevin Comoli）が実施したものです。しかし私たちのアイデアはすでに小さなイテレーションと見えたので、これ以上簡略化する緊急性はないと感じました。最初に可能な限り、小さなイテレーションについて考えてみることが重要である理由がまだ他にもあります。目的としていることが実際に期待通り迅速かつシンプルになるとは限らないからです。自分のアイデアが可能な限り最小のイテレーションであると考えていたとしても、もう一度考えてみてください。
イテレーションの教訓を将来の実験にどのように適用していくか
私たちが「メンバーの招待」実験に取り組み始めた時、体験がどうあるべきかという私のビジョンは「パイプラインの提案」ガイドツアーでの体験よりも複雑でした。「 メンバーの招待」体験の背景で思い描いていたアイデアというのは、どのユーザーでもチームメンバーをプロジェクトに招待できて、かつ管理者（admin）ユーザーが招待を承認する必要があるというものでした。
しかし先述したパイプラインのガイドツアーの教訓から、最初の実験を簡略化することにしました。体験すべてを設計・構築する代わりに、塗装ドアテスト（painted door test）を実施することにしました。これは基本的に、ユーザーの関心を測定するために主たるCTA（call to action：行動喚起要素）を追跡することにフォーカスするものです。
「メンバーの招待」実験においては、塗装ドアテストとして、招待リンクを表示しています。ユーザーが招待リンクをクリックすると「おっと、この機能はまだ準備できていません」とのメッセージを表示し、一時的な対応策を案内しています。これにより、実験で最もリスクが高い問い「管理者ユーザー以外のユーザーが同僚を招待したいと思うだろうか？」を検証できました。
図4 「 メンバーの招待」の塗装ドアテスト実験では、機能の準備ができていないことを示すモーダルウィンドウを表示した。機能の開発にリソースを投資する前に、機能に対するユーザーの関心を測定するのに役立った イテレーション的ソフトウェア開発が重要になる理由
「パイプラインの提案」実験は幸いでした。私たちが最初に取り組んだ実験は低い枝に実る果実のように、容易に解決できる問題だったからです。つまり、限られた投資で十分な利益が得られて、失敗の可能性が低くなるというソリューションでした。明確な改善から離れ、よりリスクの高い実験を模索し始めると、運に頼ることができなくなります。私たちはイテレーションについてより熱心に取り組む必要があり、そしてユーザーエクスペリエンスに価値を高めないもの、あるいはGitLabにプラスの成長を与えないプロジェクトに開発の時間を費やすリスクを減らすため、MVCや小規模な実験へと分解していく必要があります。
