distributed-agile-team.connpass.com
今週も分散アジャイルチームの会に参加してきたので、会の様子と感想を書いていこうと思います。(前半30分は別イベントに参加しており聞けていませんでした)
会の概要
先日Twitterでとあるツイートをみかけまして、そこからいろんな考察ができそうだということでちょっと雑談してみたいと思います。
デザイナーがスクラム入って何して（何をさせれば）いいかわからんは厳しい言い方するとこのへんなのかなって思ってる。多分全部に遠慮が掛け合わさってるんだろうけど。
— HikaruTayama (@HikaruTayama) 2023年5月6日
- スクラムわかってない
- デザインだけやるのがデザイナーと思ってる
- 事業を進める気がない
会の様子
UXデザイナーのプロセス論
UXデザイナー/UIデザイナーという職能に関しては理解できるものの、プロセスに関してはあまり定義されていないのがきになるという話がきょんさんからありました。
ひろみつさんの周りだとUXデザイナー/UIデザイナーと言った時に何をしているかはめちゃくちゃふわっとしている一方で、プロセス論としてはHCDがよく挙げられているということでした。
スクラムとHCDの相性
HCD云々というよりも、バックログアイテムをユースケースだけで語ると開発者が働きやすいけどデザイナーは働きにくいということになりやすいよね、という話がありました。
また、HCDはディスカバリーフェーズのプロセスなので、スクラムが始まったタイミングでスタートするのはそもそも相性が悪いのではないか？という話もありました。*1
他にも、デザインを専門としていた人がCXO的な立ち位置になるモデルケースが少なかったり、デザインに投資したことでレバレッジが効くといった成功体験の積み上げができていないのは一つの課題ではないかという話も出ていました。
強いデザイナー
ひろみつさんから、強いデザイナーにも色々あるよねという話がありました。
例えば、業務も分かるし技術もわかるというデザイナーも強いだろうし、複数案件を並行してもそれぞれのPJで貢献できるようなデザイナーも強いだろうということです。
ひろみつさんの志向
ひろみつさんが今後どういうデザイナーを志向しているかという話で、
という話が挙がっていました。
また、ひろみつさんはエンジニアあがりのデザイナーなので、技術とデザインの隣接性も重視しているということでした。
具体的には、工場の現場で班長さんが管理するようなシステムに対してわくわくするそうです。
スクラムとデザインの相性
ここまで離席されていたかわにしさんが戻ってきたこともあり、ここでスクラムとデザインの相性の話に移っていきました。
かわにしさんの近況
かわにしさんは現在武蔵野美術大学でデザインの基礎を学び直している最中だそうですが、そこで学んでいる内容だとタイムボックスとの相性の悪さは感じるそうで、どういう形にしたらみんなと歩調を合わせてやっていけるのかの形を見つけるところがスタートになるんじゃないかな？ということでした。
デザイン業務に関する工数割当
きょんさんとしては、デザインの工数をまともに割り当てていないというのを感じる*2そうで、デザイン領域においてコストやメリットの言語化能力が低いorコストを払う気がないのでは(スクラム関係なく)レベニューを得ることは難しいと感じるそうです。
工数の問題が起きる原因には、上記以外にも、
- デザインリテラシーの低さから完成に近い成果物でないとデザインを評価することができない人(=デザイナーに自分のリテラシーのなさを丸投げしてしまっている)が多いが故に無限に工数がかかってしまう
- プログラミング領域よりも多くの人がフィードバックすることができる(プログラミング経験がない人がソースコードにフィードバックするのは不可能だが、デザイン領域に知見がない人がデザインにフィードバックすることはできてしまう)
もあるんじゃないかという意見が挙がっていました。
ユーザーからのフィードバック
ユーザーやPOなどからフィードバックがもらいにくいという話から、解こうとする課題が間違っているとエクストリームユーザーやアーリーアダプターがいなかったりして、フィードバックをもらうのが難しいのはある意味当たり前だよね、という話が出ていきました。
これを踏まえると、スクラムはデザインと相性が悪いという話は、解くべき課題かの見極めができていないPJが多いことに起因しているのでは？という議論になり、「なかなかアーリーアダプター見えてこないから見栄えの良いものを作ってなんとかフィードバックしてもらおう」みたいにPOがなってしまうとつらいよね、という話になりました。
デザイナーはクリティカルな議論が苦手？
以前デザイナーを束ねていたマネージャーときょんさんが話した時に、「うちのデザイナーってクリティカルトークが苦手なのでその特性がスクラムで言うストレートトークと相性が悪いんだよね」と言われたそうで、それって本当なの？という話をしていきました。
ひろみつさんの周りだとデザイナーとクリティカルトークという話だと「まあそういう人もいるよね」位の感じにしか捉えられずあんまり実感がないそうですが、違う職能間においてデザインに関するレビューをするのが下手だと感じるそうです。
また、かわにしさんの周りだと(大学院に通っているというコンテキストはあるものの)講評を日常茶飯事に受けることはあるのでクリティカルトークには慣れているけれど、違う職能の人からフィードバックを受けると的外れに感じてしまうというのはあるかもしれないということでした。
ユーザーを考えていないデザインをしてしまう環境
デザイナーがユーザーに寄り添った設計ができずに、チーム内から「そのデザインはパフォームしないよね」と言われて、ユーザーからも全く同じフィードバックをもらってしまうみたいなことがあるという話から、それはどういう環境だとそうなるのか？という話をしていきました。
デザイナーが作業者になってしまうような環境だとこうなってしまうのでは？という話や一般的にありふれたサービスUIに寄せてしまった結果ストーリーと逸れたUIになってしまうという話はありつつも、ひろみつさんやかわにしさんの周りだとこういった事例が想像できないため、一般化して考えるのはちょっと難しいシチュエーションだということです。
また、アート系をバックグラウンドに持ったデザイナーだと、そういう場面がもしかするとあるかもしれないという話も出ていました。
スクラムに対する理解度の低さとデザイナー
元Tweetに翻って、スクラムガイドに書いてあるのはミニマムな定義なはずなのに、現場でどう実装していくのかを考えずにスクラムガイドの話だけを参照して「スクラムにデザイナーが入るのは難しい」と言ってしまっている人がいるのは気になるという話が出ていました。
上記のようにスクラムガイドの話だけを参照してしまうと、デザイナー云々というよりもほぼすべての現場でスクラムは難しいという話になってしまうのが気になるそうです。
そのため、元Tweetにあった木浦さんの意見だと、別にデザイナーがコードを書けなくたっていいし、デザイン領域で木浦さんがやっている取り組みもピュアデザイナーの話からはそれているみたいな話になってしまうということです。
また、荒本さん云々の会話も、本来的にはScrum IncはScrum@Scaleを推していく立場のはずなので限定的な議論をしたのではないか？という推測をしているという話も出ていました。
全体を通した感想
久々の雑談会を満喫できました。
自分は「どういうデザイナーと働きたいか？」よりも「どういう人と働きたいか」が上位にあって、こういう人と働きたいはあってもこういうデザイナーと働きたいか？の視点ではあまり考えたことがなかったので、コメント含めて色々なデザイナーの事例やデザイナーに対する問題意識が聞けて面白かったです。
