Adobe XDの開発:ベータ版の再定義を目指して

BY 公開

ソフトウェアの開発は、とても満足度の高い挑戦になる場合があります。幸運にも、私は才能に溢れた開発チームを率いて、アドビの新しい試みであるAdobe Experience Design CC(以下Adobe XD)の開発に関わっています。この開発を通じて取り組んでいることのひとつは、ソフトウェア開発手法の見直しです。デザインコミュニティとの会話を大切にしながら、彼らの希望や必要性に適合した製品づくりを確実に行えるようになるためです。私の過去の経験では、こうしたプロセスの構築はいつも容易なものではありませんでした。以前、私は2つの大きな問題と格闘していました。

ひとつは、バグ修正は困難を極め、新機能の追加はほぼ不可能に近い状況、を数多く経験していたことです。コードのどの行を修正するにせよ、それは、例えるなら、大規模な工業団地の配管工事を、敷地内の配管図も作業結果の確認方法も無く行うような状況でした。コードの品質は劣化を続け、メンテナンスは非常にコストの高い作業になりました。プロジェクトには楽しさも達成感も無く、なによりも、次善の解決手段を手にしたはずのユーザーにとって非常に悪い状況でした。

そこに、ふたつ目の問題です。多くのプロジェクトは、ユーザーの要件に合わせるという意図が明示されていたのにもかかわらず、期日を優先して、しばしば突貫工事で開発が行われました。その結果、企画側では適切なユーザー調査無しで、開発側では大急ぎでの実装となり、目標の日程どおりに出荷できたとしても、製品はバグを多く残し、そもそもユーザーがさほど必要としていないものになっていきました。

それほどまでに好ましく無いことが起こるのは何故でしょうか?

ソフトウェア開発は、3つの主要な要因、品質、時間(リリースの)、スコープ(機能の)との戦いです。我々はこれを「鉄のトライアングル」と呼んでいます。プロジェクトにおいては、3つの要素のうち2つだけを解決できます。3つを解決しようとしても、1つ諦めることになるでしょう。例えば、期日とスコープを優先すれば品質が犠牲に、品質とスコープを優先すれば公開日の延期を検討することになるでしょう。

実装したい機能を決められた時間内に詰め込みたいという欲望が、品質(含むパフォーマンス)に深刻な被害をもたらしている現場がたくさんあります。

ソフトウェアの「鉄の三角形」
ソフトウェアの「鉄の三角形」

多くの人々が、この問題に直面しました。そして、より良い方法の存在を理解して、開発手法の発展に着手しました。

その成果として、業界にはより優れたエンジニアリング手法が登場しました。エンジニアリング作業の中に品質を構築することに注力した、アジャイル開発やエクストリームプログラミングです。目標は、鉄の三角形の「品質」を犠牲にせずに、定期的に少しずつ機能を追加することです。これにより「スコープ」を柔軟に設定できるようになります。また、機能を開発するだけでなく、自動テストの仕組みもつくり、常にコードの特定の箇所が動作しているかどうかを確認することにより、よりソフトウェア開発の管理が容易になります。

私は、こうした手法を、最初にApacheのオープンソースプロジェクトで、次いで商業的なプロジェクトで実践しました。良い手法を採用したことで、私のソフトウェア開発の日々は楽しいものとなりました。

もうひとつ大きな変化がありました。アイデアから実装に至る製品開発の、管理方法の大幅な進化です。リーン製品開発のような方法論により、検証可能な特定の仮説を実験を通じて確認したり、個々の意見の代わりにデータ解析による決定を行うなど、本当のユーザーの課題の発見が遥かに重視されるようになりました。これは、より練り込まれた、そして解決すべき課題により適したソリューションへとつながります。

アジャイル開発やリーン製品開発などの方法論は新しくはありませんが、それらを学び、作業に取り入れるにつれ、ユーザーのニーズや期待に今まで以上に適したソフトウェアを提供できる力を体験してきました。そして今、こうした方法論をAdobe XDという野心的なプロジェクトに適用できることに幸せを感じています。

数ヶ月前、開発チームはAdobe XDの最初のベータ版を公開しました。モバイルアプリやWebサイトを始めとする画面上の体験をデザインし、プロトタイプをつくり、チームで共有するソリューションです。最初に公開されたのはMac OS Xのデスクトップ版でした。下がそのスクリーンショットです。シンプルで集約されたユーザインターフェースです。

Adobe XDのデザインワークスペース - ユーザーの気が逸れないようUIはシンプルに
Adobe XDのデザインワークスペース – ユーザーの気が逸れないようUIはシンプルに

当初から、Adobe XDはパフォーマンスと品質を念頭につくられました。それは、デザイナーが、イライラすることなく考えたままにデザインできることが重要と考えたためです。多くのデザイナーから、不十分なパフォーマンスや品質は、苛立たしいだけでなく、クリエイティブな表現を素早く制作し続ける行為の邪魔になるという声を聞きました。これは複数画面上の体験を制作する際には特に重要なポイントです。

プロジェクトを始めるにあたり、製品として使えるレベルを達成するまでに時間がかかるだろうことは理解していました。また、ユーザーの声を学び、反映させるために、ユーザーにできるだけ早くソリューションを提示するべきであることも分かっていました。それに加えて、我々は高品質の体験を提供したかったのです。

どのようにしてそれを達成しようとしたと思いますか?

小さくて堅牢な基盤から始める

「ベータ版」のソフトウェアを使ってみたら、たくさん機能があったものの、品質もしくはパフォーマンスに問題があった、という経験は誰しもあるのではないでしょうか。ベータ版にあまり機能を詰め込むと、機能の深さや品質が犠牲になります。これは、機能について考慮する時間も、実装を検証する時間も十分に取れなくなるためです。次の更新時には、深さや品質の改善が試みられることになりますが、後から品質を保証する仕組みを構築するのは、大変困難で時間がかかる作業です。下の図はその様子を表しています。

理想的ではないシナリオ: 品質と深さを犠牲に初期に多くの機能を構築
理想的ではないシナリオ: 品質と深さを犠牲に初期に多くの機能を構築

このアプローチは、そもそも「ベータ版」を出す理由を踏み外しています。ベータ版は、開発中のツールのビジョンや機能を共有し、フィードバックを得て、製品の方向性や実装に反映させるためのものです。とどのつまり、製品が成功する可能性を高めることが目的です。

しかし、品質と引き換えに機能を増やした場合、製品が導くビジョンは、品質やパフォーマンスに対する不満に打ち消されるでしょう。そして、フィードバックは、機能やビジョンについてではなく、バグに対する懸念に集中することでしょう。結果として、ユーザーから最も重要な事を学ぶ機会を失うことになります。

ユーザーから正しく学び、成功する可能性を増やすために、Adobe XDは、以下の条件を満たす最小限の機能の組み合わせから始めることにしました。

  • 対象のユーザーにとって重要な詳細が深く把握できている
  • 信頼に足るデザインと詳細な実装の計画がある
  • 定められた品質基準を満たすように構築されている

その後、ユーザーからのフィードバックを元に、実装済みの機能の品質向上や新しい機能の優先順の決定を行い、一歩ずつ新しい機能の追加を繰り返しました。

次の図はその様子を示したものです。

Quality-from-start2

上の図が示しているのは、最初のベータ版の時点から、品質とパフォーマンスにおいては、正式に公開された製品レベルの体験の提供を目指しているということです。「鉄のトライアングル」に沿って言うなら、スコープを限定することで、決められた期間内に高品質のベータの公開を繰り返しています。この進め方であれば、ベータ版の製品との違いは機能が少ないことだけです。ユーザーは品質に悩まされる事無く製品の使用に専念でき、製品チームは学ぶ機会が増えることでしょう。

品質を保つために、開発は信頼できるごく少量のコードから始められました。追加する機能には、完了の定義(DoD)の形式で、高いハードルを設定しました。我々のチームのDoDには、コードレビュー、ユニットテスト、コード網羅率などが体系的に実践されるよう定義されています。ベータ版の更新は毎月行うことに決めました。これはデスクトップアプリケーションとしては短い間隔ですが、長期的な視点からは、頻繁に更新を行うほど、より多くの機能を提供し、ユーザーからの声を聞く機会も増えると考えています。

まとめると、この進め方の主な利点は2つです。

  1. ユーザーによる迅速な検証:我々が開発した機能がそのまま問題なく使われることは稀でしょう。頻繁に更新することで、フィードバックを得る機会が増え、必要に応じた修正を短期間に行えるようになります。例えば、Adobe XDのカラーピッカー、ペンツール、共有機能は、ユーザーによる検証結果により既に修正されました。
  2. ユーザーへの約束の繰り返し:更新の度に、得られたフィードバックに応じて開発の優先順位を調整し、最も重要と思われる機能を先に開発するように調整しています。一方で、更新時には、次に開発する機能は確定済みのため、個々の機能の実装に時間がかかる事はあっても、更新ごとに確実にユーザーへの価値を提供できます。

結論

Adobe XDの発表以来、 コミュニティからは大きな反響をいただきました。これまで毎月ベータ版の更新を行い、来月の分も予定通り進行中です。ユーザーからのフィードバックは、品質やパフォーマンスに対する苦情は少なく、機能に対する議論に集中しています。我々の開発手法はまだまだ改善を続ける予定であり、この先に何を学べるのか今から楽しみです。

Adobe XDにはこれからも新しく刺激的な機能の追加を計画しています。是非、皆さんのフィードバックを聞かせてください。Mac版のAdobe XDのベータを試したら(Windows 10向けにも開発中です)、UserVoiceにバグや既存の機能に関するコメント、そして新しい機能のリクエストを書き込んでください。


この記事はMaking Adobe XD: Redefining Beta(著者:)の抄訳です。

  TAGS

  AUTHOR

akihiro kamijo

アドビのコンサルティングチームでリードアーキテクトとして主にUIデザインプロジェクトに関わる。現在は独立してデザイン/開発に関連のマーケティング企画や情報発信、プロジェクト支援を行っている。