アジャイル開発の導入時、どうすればUXデザイナーの専門性が活かせるか?

2012年12月12日

アジャイル開発を導入する方法はさまざまなところで語られてきましたが、その多くはチームのメンバーがプログラマーであることを前提としていました。しかし最近のアプリケーションではユーザー体験が重視されてきており、それを設計するUXデザイナーが開発チームに参加するようになってきています。

能力と考え方の変更がアジャイル導入を助ける

InfoQの記事「能力と考え方の変更がアジャイル導入を助ける」は、UXデザイナーがアジャイル開発に参加したときに経験する不安やその解決法の参考になる内容です。許可を得て、以下に転載します。

能力と考え方の変更がアジャイル導入を助ける

(作者 Ben Linders、翻訳者 徳武 聡、投稿日 2012年12月10日)

アジャイルを導入するとき、仕事や役割に対する心配にどのように対処すればいいだろうか。どうすれば製品開発に専門性を活かすことができるだろう。デザイナーがその能力を用いてアジャイルで価値を提供する方法について、そして、アジャイルの手法を理解するための意識の変え方について2つのブログ記事が情報を提供している。

仕事を変えることへの心配はアジャイル導入の失敗の原因だ。Jeff Gothelf氏は“How We Finally Made Agile Development Work”という記事で次のように書いている。

アジャイル導入失敗には多くの原因があります。中でも、ウォーターフォールの世界に慣れた人を新しい働き方に順応させることは最も対策されていません。ある種の役割の人は (...) 中心の仕事は変わりません (...)。しかし、どのように仕事が変わるか不透明な人もいます。

初めに、アジャイルの導入に対してデザイナーの間で不安が広がった。

アジャイルによって安全なデザインフェーズから、プロダクトマネージャ、ソフトウエアエンジニア、品質保証担当者が働いている荒々しく変化の速い現実に突入しなければなりませんでした。

"これはデザインじゃない!"、と私たちは叫びました。私は最高の仕事ができていませんでしたので、ビジネスに対して価値を提供できていないと感じてしまいました。

そして、解ったのは、すでに持っている能力を活用してアジャイルに対して別の手段を取る必要があるということだ。

ソフトウエアをデザインする方法について再考しなければなりませんでした。私たちの専門性や能力、手法、ツールは不可欠なものでしたが、その使い方、使う人、使うタイミングはすべて変えなければなりませんでした。

デザイナーが提供する価値はチーム内の他の役割に分散しました。(...) ユーザエクスペリエンスを包括する他の要素を幅広く理解しながら、デザインを促進することが私たちの仕事の大きな部分を占めるようになりました。

Jeff Gothelf氏は次のようなアドバイスをして自身の経験を締めくくっている。

アジャイルの世界で居場所を見つけようと苦労しているなら、現在の仕事を見直して、どのようにすれば素早いチームのニーズに合うように価値を再構成できるか考えるとよいでしょう。さらに自分の役割や能力を超えて考える必要があります。自分の肩書きを超えてどのような価値をチームに提供できるか考えるのです。

製品開発の世界での自分たちの居場所に不安を抱く

Developing UX Agility: Letting Go of Perfection”という記事ではCarissa Demetris氏、Chris Farnum氏、Joanna Markel氏、Serena Rosenhan氏がウォーターフォール開発からアジャイル開発への移行の経験を書いている。

アジャイルの実践者が知っているアジャイルについての文献にはUXについて書かれていませんでしたので、私たちUXデザインチームは自分たちの仕事にとってアジャイルが何を意味するか自力で考えなければなりませんでした。

そして、製品開発の世界での自分たちの居場所に不安を抱くようになった。

今までのやり方で開発に対して価値を提供するのは不可能でした。アジャイル開発の世界で成功するには、自分たちの役割や価値の提案についての考え方を変え、アジャイルの世界での働き方を再構成することで生まれる、UXデザイナーにとっての新しい機会を認識する必要がありました。

考え方を変えることがユーザーエクスペリエンスデザイナーのアジャイルプロジェクトでの働き方を理解する助けになった。

典型的なウォーターフォールプロジェクトではひとつの調査フェーズがあり、ひとつのデザインフェーズがあり、ひとつのユーザビリティテスティングフェーズがあるだけです。(…)アジャイル開発では、このような活動する機会が複数回行っても (...) 問題ありません。

(...) 高品質の製品を作ることは重要ですが、製品を磨きすぎて変更できなくなってしまうほど凝り固まってしまうのは最善ではありません。

最初はぎこちなく感じるかもしれませんが、完璧を目指すには漸進的な方法を用いる必要があります。(…) 期限内に十分な品質になっているかどうか考えることで、過剰な設計を防ぐことができます。

そして、自分たちの経験を以下のように締めくくっている。

[アジャイル開発に移行するのは]ソフトウエア開発の新しい時代の幕開けであり、この新しい時代ではアジャイルの反復的な性質から直接チャンスが生まれ、ユーザのニーズにあったUXのデザインを実現することができます。考え方を多少変えれば、アジャイルプロジェクトでのUXの完成に奮闘するための新しい手法を見つけることができます。

あわせて読みたい

DevOps アジャイル開発 UX




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本