細分化とコードレビュー見直しによるイテレーション的ソフトウェア開発のメリット

第1回 イテレーション的ソフトウェア開発が重要である理由

この記事を読むのに必要な時間:およそ 2 分

「パイプラインの提案」実験はどのように行われるべきだったか?

いま私たちがプロジェクトを振り返り,何を間違えたのかを見ることは簡単であり,こうした振り返りは失敗の繰り返しを回避することにつながります。GitLabのガイドツアーは構築してリリースするだけのシンプルな実験のように見えますが,結果的には完成まで数ヶ月を要してしまいました。全般的に見れば実験は成功しましたが,実装後に再び着目し,プロジェクトを改善できる可能性があることを確認しました。より多くのユーザーにオプトイン(許可)をうながすために,最初のナッジ(無意識に働きかけること)でイテレーションについて説明することで改善を実装できると判断しました。より小さな実験をすぐにリリースしていれば,より早い段階でイテレーションし,最初のナッジとして最適なものを提供し,より多くのユーザーがガイドツアーから恩恵を受けられたでしょう。

図3 2回目のオプトインの説明ははるかに効果的。より小さなイテレーションをリリースすることで,より多くのユーザーが実験的なガイドツアー機能をオプトイン(許可)するようになる

図3

実験の実装を完了するのに数ヶ月を要したため,実験をイテレーションするのも数ヶ月を要してしまいました。

いま同様の実験をしなくてはならないなら,私たちはさらに小さく開始するでしょう。1ヶ月以内,理想としてはより速く構築してリリースできるものを使うでしょう。例えば最初のナッジにパイプラインの設定方法を説明する既存資料へのリンクを加えたものをリリースできます。それは私たちがナッジの配置,コンテンツ,有効性について検証することを可能にするでしょう。実験のリスクを大幅に減らせたかもしれません。

別の案として,例えばガイドツアーを2ステップに短縮することも可能です。これはGrowth:Conversionのプロダクトデザイナーであるケビン・コモリ(Kevin Comoli)が実施したものです。しかし私たちのアイデアはすでに小さなイテレーションと見えたので,これ以上簡略化する緊急性はないと感じました。最初に可能な限り,小さなイテレーションについて考えてみることが重要である理由がまだ他にもあります。目的としていることが実際に期待通り迅速かつシンプルになるとは限らないからです。自分のアイデアが可能な限り最小のイテレーションであると考えていたとしても,もう一度考えてみてください。

イテレーションの教訓を将来の実験にどのように適用していくか

私たちが「メンバーの招待」実験に取り組み始めた時,体験がどうあるべきかという私のビジョンは「パイプラインの提案」ガイドツアーでの体験よりも複雑でした。⁠メンバーの招待」体験の背景で思い描いていたアイデアというのは,どのユーザーでもチームメンバーをプロジェクトに招待できて,かつ管理者(admin)ユーザーが招待を承認する必要があるというものでした。

しかし先述したパイプラインのガイドツアーの教訓から,最初の実験を簡略化することにしました。体験すべてを設計・構築する代わりに,塗装ドアテスト(painted door test)を実施することにしました。これは基本的に,ユーザーの関心を測定するために主たるCTA(call to action:行動喚起要素)を追跡することにフォーカスするものです。

「メンバーの招待」実験においては,塗装ドアテストとして,招待リンクを表示しています。ユーザーが招待リンクをクリックすると「おっと,この機能はまだ準備できていません」とのメッセージを表示し,一時的な対応策を案内しています。これにより,実験で最もリスクが高い問い「管理者ユーザー以外のユーザーが同僚を招待したいと思うだろうか?」を検証できました。

図4 ⁠メンバーの招待」の塗装ドアテスト実験では,機能の準備ができていないことを示すモーダルウィンドウを表示した。機能の開発にリソースを投資する前に,機能に対するユーザーの関心を測定するのに役立った

図4

イテレーション的ソフトウェア開発が重要になる理由

「パイプラインの提案」実験は幸いでした。私たちが最初に取り組んだ実験は低い枝に実る果実のように,容易に解決できる問題だったからです。つまり,限られた投資で十分な利益が得られて,失敗の可能性が低くなるというソリューションでした。明確な改善から離れ,よりリスクの高い実験を模索し始めると,運に頼ることができなくなります。私たちはイテレーションについてより熱心に取り組む必要があり,そしてユーザーエクスペリエンスに価値を高めないもの,あるいはGitLabにプラスの成長を与えないプロジェクトに開発の時間を費やすリスクを減らすため,MVCや小規模な実験へと分解していく必要があります。

著者プロフィール

伊藤俊廷(いとうとしたか)

GitLab APAC/Japan シニアソリューションアーキテクト

日本のSIerでソフトウェア開発,プロジェクト管理,技術調査,海外勤務等の業務に従事し,自身でも新しい開発ツールの導入,組織の文化醸成の難しさを痛感した。その後,開発経験を活かし,アプリケーションセキュリティベンダーにて,セキュリティテストのソリューションを戦略顧客に導入する任務を担った。現在は,GitLab APAC/Japanのシニアソリューションアーキテクトとして,顧客のDevOpsでの成功に向けた課題解決を行う。

バックナンバー

細分化とコードレビュー見直しによるイテレーション的ソフトウェア開発のメリット

  • 第1回 イテレーション的ソフトウェア開発が重要である理由