「COMPANY」を開発するWorks Human Intelligenceのデザイナーたち
25年以上の歴史を誇る人事管理システム「COMPANY」を開発するWorks Human Intelligence（以下、WHI）は、"「はたらく」を楽しくする"をミッションに掲げるソフトウェア開発企業だ。
今回登壇したのは、「COMPANY」のUI/UXチームのリーダーである古澤杏奈氏、UI/UXデザイナーの扈文茜氏、大川澪氏、バックエンド、フロントエンド開発者の竹原百合子氏の4人である。セッションは4つのテーマをもとに、4人が回答するスタイルで進められた。
──最初のテーマが「WHIのデザイナーチームって？」ということで、まずはどんなチーム構成で活動しているのか聞かせてください。
古澤杏奈（以下、古澤）：2年前のチーム発足時は2名でしたが、現在は7名のデザイナーがいます。内3名はUXリサーチャー、デザイナーとして入社していますが、他4名は社内のコンサル、開発、営業、QAなど、さまざまなバックグラウンドを持つ人材で構成されています。ただエンジニア500名に対してデザイナーは7名と、デザイナーが極端に少ない現状です。
以前のチーム体制は、開発者とUIUXチームが組織的に分かれており、案件が発生したタイミングでUI/UX設計のサポートに入っていました。しかし製品数も多く、それぞれ状況や成熟度、技術、業務知識が異なり、スピーディかつ的確にUI/UX設計をするのが難しい状況でした。
そこで、各製品を主務で担当するOn-siteデザイナーと、各On-siteデザイナー全体を横軸で繋ぐCentralデザイナーに分け、実際にエンジニアのチームに入ることで製品理解を深め、サポートできる体制にしました。
この体制により、各製品の状況をオンタイムでキャッチし、スピーディかつ効率良く設計ができるようになりました。また、Planningにも参加し、UI/UXの問題を早期に発見すべく取り組んでいます。
役割としては、CentralデザイナーはCOMPANY全体のUI/UX向上を目指し、デザインガイドラインの設計・整備を担当。On-siteデザイナーがいない製品のUIUX設計、デザイナー同士が連携できる体制を構築しています。
扈文茜（以下、扈）：On-siteデザイナーはエンジニアと協業し、各製品の課題解決に向けたUI/UX設計や、UI/UXナレッジを共有しています。
竹原百合子（以下、竹原）：開発サイドとしてもUI/UXは長年の課題だと思っていたので、専門部隊ができたことはとても心強いと感じています。
歴史ある製品のデザイナー的難所とは？
──次のテーマは、実際に開発者と設計をしているOn-siteデザイナーの視点から、「歴史ある製品のデザイナー的難所」についてです。
古澤：COMPANYの開発プロセスは、要件定義からテストまでの工程を全て開発者が担当しています。
扈：UI/UXデザイン領域についても開発者が行っていました。一人の開発者が最初から最後まで携わってモノを作る、まさにCOMPANYの職人ですね。一方、デザイナーはより専門的なデザインスキルを活かし、ペルソナ・ユーザージャーニーマップ・プロトタイプ作成などで開発者や製品をサポートしています。
実際にどんなやり方でサポートしているかを表したのが、以下の図です。まず、製品・機能の課題について、開発者からOn-siteデザイナーに相談がきます。私たちは業務のキャッチアップとともに課題を整理して、デザイン上の解決策を提案します。開発者に解決策の合意を取った後は、実装面の条件を確認しながら、画面のUIチェックや実装のサポートを行っています。
──実際On-siteデザイナーとして、どこが一番難しいと感じますか？
扈：COMPANYは機能の充実性と設定の柔軟さから、多くのユーザー企業にご利用いただいている一方で、その多様さから最適なUI/UX設計が難しいという課題もあります。私たちがよく直面する問題は、一度リリースした機能やUIを変更することが容易ではないことです。
苦悩1：UI/UXの概念がない時代の「ボタン」
例えば、ボタン上の文字が説明文のように長かったり、たくさんの機能ボタンが縦に並んでいたりする画面があります。その結果、長すぎる文章は情報が伝わりにくく、ボタンの配置は押し間違いに繋がりやすいなど、画面が煩雑で使いにくい状態になっていました。
苦悩2：UI/UXの概念がない時代の画面への「慣れ」
多くのエンドユーザーがほぼ毎日使っている画面には、「慣れ」という問題もあります。業務システムで「ずっとここにあるもの」と認識されているボタンを変えたことによって、重大なミスに繋がることも十分ありえます。
──すでにリリースされた機能を考慮しつつ、改善するのは難しいですよね。それをどう乗り越えたのでしょうか？
扈：ユーザーの使い方を調査し、開発者と議論して納得してもらった上で、ボタンの文言を短くし、位置を押しやすい場所に固定するデザイン改善を行いました。改善前画面と改善後画面を用意して、段階的にUI/UXを考慮した改善後画面に移行する方針で進めました。また、マニュアルの紹介や告知も平行して行い、徐々にユーザーが改善後の新デザイン画面に慣れる期間を設けました。
古澤：デザインを改善する工夫として特に意識している点は、「今回の修正でどこまで変更可能か」です。状況によって簡単な修正だけで済む改善案と構造の修正が必要な案など、いくつかの案を準備しています。
竹原：UI/UXチームと担当した案件でデザイナーに相談したときに、「どこまで修正可能か」「どうして難しいのか」を開発者側に確認してくれたのでとてもやりやすかったですね。最終的な実装の判断を開発に任せてくれた点もすごく助かりました。また、改善案件の仕様や要件を伝えた上で、柔軟な選択肢をいくつか提案してくれたのも良かったです。
UI/UXに対する意識、重視するマインドをどう高めていったのか
──次のテーマは「UI/UXの歴史」です。開発者とデザイナーの協業は、UIUXチームができた当時からうまく進められていたのでしょうか。
古澤：正直、最初はうまく進められていなかったです。そもそも20年前はUI/UXという概念がなく、開発側は機能を実装することが最優先であり、これ以上プロセスを増やすことは避けたいという状況でした。
竹原：すでに確立している開発プロセスに工数負担を増やすことなく、どうUI/UXの観点を組み込んでいくのか。開発者の立場でも具体的な歩み寄り方がわからない状況でした。また、ユーザーが「業務として」何をしたいかを改めて共有する手間もあるし、それをUI/UXチームに理解してもらえるかという不安もあったと思います。
古澤：そのイメージを払拭するために試行錯誤しましたが、やはり開発チームにUI/UXを認知してもらい、協力し合いながら改善していくことが重要だと実感。そこでUI/UXを知ってもらうための資料をたくさん作成してプレゼンしたり、勉強会を開催したりしました。
SlackにUI/UXやデザインに関する相談窓口を作り、いかに開発者に工数をかけずにサポートできるかといったアプローチも行いました。まさに忙しい職人に認めてもらおうと必死な弟子のようでした。
竹原：開発者としては、前提となる業務や機能などの説明をするのに時間がかかるので、デザイナーにUI/UXを相談するのは少し気が引けていました。しかし、Slackの相談窓口は気軽に聞くことができてよかったです。UI/UXチームは前提となる条件や状況を理解しているので、ライトなコミュニケーションだけで適切で丁寧な助言をしてくれましたね。
古澤：一方で、Slackでの相談はリリース直前、実装後の相談が多かったので、改善できる範囲が狭く、スタイルのアドバイスしかできないという課題も見えてきました。
そのため、実装前の開発プロセスの上流から設計段階からデザイナーが入れるように、機能企画書(カタログ)レビューや設計レビューから参加させてもらうようにしました。今では、新規機能開発や新サービス設計時は、設計段階から呼んでもらい、実装前にUI/UXを設計するお手伝いをしています。
これからのUI/UXチームとして目指すこと
──4つ目のテーマ「これからのUI/UXチーム」では、チームとして今後は何を目指していくのか聞かせてください。
大川 澪（以下、大川）：現状を表現すると、「やっと職人が振り向いてくれた」という感じでしょうか。思想の啓蒙活動を重点的に行い、設計からデザイナーが関われる体制の構築ができてきた段階です。これからは開発者と同じ方向を向き、COMPANYという製品の課題や未来の話ができると考えています。
とはいえ、私たちが製品のユーザビリティに影響を及ぼせている部分は多くはない状況です。"COMPANYをもっとよくしたい！その価値をお客様に届けたい！"というミッションのためには開発者の力が不可欠。UI/UXに割くリソースを最小限にしつつ、より良いUI/UXを実現する仕組みを我々デザイナーが作っていく必要があると言えます。
古澤：我々デザイナーができることとしては2つ。1つは、デザイナーが入ることによって発生する「説明コスト」を極限までなくすこと。開発者と同じレベルで製品の話ができるように、「業務の理解」を引き上げる必要があります。
課題の温度感などを一緒に把握することで、コミュニケーションコストを下げるために必要な「現場理解」も重要です。そのために自分が担当している開発者チームのミーティングや、Slackのチームチャンネルにも参加しています。最近は開発締め後に雑談会を開いて、デザイナーと開発者が雑談をする場も設けています。
扈：2つ目は、デザイナーが入ることで開発者のアウトプットの質を最大化することです。これを実現するには、開発者に「自分が考えるよりも早くて、よりよいものができる」と思わせるデザイナー自身の実力が必要です。
まずデザイナー個人のUI/UXデザインスキルを磨き、「UI/UXに困ったら相談できる駆け込み寺であること」「良いUI/UXができるデザインシステムの構築」、そしてデザインが製品に反映されるまで、「オーナーシップをもって見届けること」が大切だと感じています。
今回のテーマでもある歴史ある製品のデザイナーだからこそ必要な力とは、「妥協点を探りながら最適解を見つけていく力」と「説明のできるデザインを常に提案し続けること」だと思います。
──最後に、「伝統的なシステム開発職人の良きパートナーになるために」の答えを教えてください。
大川：我々なりのアンサーは、「職人の作る製品や、置かれている状況をデザイナーが職人と同じくらいよく理解すること。その上で、職人が製品を作りやすい環境をデザイナーが柔軟に作っていくこと」です。
歴史ある製品だからこそ、デザイナーは柔軟にフローやルールに縛られることなく、開発者とともにオーナーシップを持って製品をよりよくしていきたいと思います。
