要件を整理して、ユーザーの仕事を理解して、UIに落とし込む。ソフトウェアの「デザイン」と呼ばれる一連の作業は、勉強しているときは楽しかったんです。このブログでも『The Elements of User Experience』や『プロセス・オブ・UI/UX』のレビューを書いていて、「なるほど、こうやって設計するのか」と思っていました。
仕事でもデザインはやってきましたが、ある案件でめちゃくちゃ大変な思いをした時の話を備忘録的に書いておきます。
この記事を読んでも愚痴しか書いてないのが申し訳ないですが、読んでいただければ幸いです。
何をやろうとしていたか
ある専門職の仕事を支援するwebアプリケーションを作ることになりました。チームで判断して決めた案件です。
そのアプリは、専門家が職場の状況を素早く理解して、すぐに意思決定できるようなものです。データを蓄積して分析する機能もある、かなり複雑なソフトウェアでした。
複雑だからこそ要件定義が重要で、ユーザーがいつ、どこで、どんなことをして、どんなことを求めているのかを理解する必要がありました。ユーザーストーリーマップを作ろうとしたのは、そのためです。
現場が見えない
工場時代にも「現場の人の仕事を理解して、ツールを作る」ということをやっていました。あのときは、目の前に現場があったんです。ラインで作業している人を横で見て、「あ、ここで毎回手が止まるな」と自分の目で確かめてからツールを作れていました。納得してから手を動かせる。それがどれだけ恵まれていたか、今回の案件で思い知りました。
今回は、現場を見ることがほぼできなかったんです。専門家の仕事なので、自分が横で見てもわからない部分が多い。ヒアリングで話を聞いても、「それは状況によりますね」と返ってくる。こっちが整理して「こういうことですか？」と確認すると、「まあ、だいたいそうですけど、例外もあって…」となる。ずっとその繰り返しでした。
1週間缶詰でヒアリングして情報設計をやったこともあります。さすがに1週間もやればかなり進みました。でも、専門家に対して失礼のないように話を聞き続けるのは、想像以上にしんどかったです。終わったあと、ぐったりして何もできない日がありました。
何より困ったのは、状況によって判断が変わるケースが多すぎることです。同じ業務でも条件次第でまったく違う動きになる。Miroに付箋を並べて、スプレッドシートで表にして、何度も構造化を試みました。整理するたびに「あ、このパターン抜けてた」と気づく。終わりが見えないんです。
情報は整理できても、UIに落とし込めない
情報の整理自体は、時間をかければできるんです。でもそれをUIに落とし込むのに、またものすごく時間がかかりました。
よくあるアプリではなくて、色々な情報が連携しているので、OOUIのテンプレート的なUIでは実装できませんでした。「画面をどう設計すればいいのか」という問いに、整理した情報だけでは答えが出ないんです。情報の構造がわかっても、それをどう並べて、どう見せれば専門家が使えるものになるのか。そこにまた別の難しさがありました。
こうして、要件整理とUI設計を行ったり来たりしているうちに、半年が溶けていました。
技術を学びたいのに
半年のうち、1ヶ月ほどまったくコードを書けない時期がありました。自分はフロントエンド、バックエンド、インフラのスキルを伸ばしたかったのに、毎日やっているのは情報整理とヒアリングと資料作成。技術を学びたいのにコードが書けない日が続くのは、正直かなりつらかったです。
それに、あまり興味をもてない案件でもありました。そのドメインを将来かけて詳しくなりたいとは思えなかったし、ドメインに関わっている人たちとの関わりも少しストレスでした。それでもやり続けていたのは、仕事として引き受けたからです。やると決めた以上はやる、という気持ちだけで動いていました。
おわりに
最終的には上司に相談して、整理に関わる時間を少なくしてもらいました。あのまま一人で抱え続けていたら、もっとしんどいことになっていたと思います。
振り返ると、問題はユーザーストーリーマップというツールの方じゃなくて、現場が見えない中で専門家の仕事を構造化しなきゃいけない状況の方でした。ソフトウェアを作る技術と、ユーザーの仕事を理解する技術。どっちも必要なのはわかっているんですけど、同時に伸ばすのは本当にしんどかったです。
正直、どうすればよかったのか、今でもわかりません。同じような経験をした人がいたら、どうやって乗り越えたのか聞いてみたいです。
