freeeでは、2025年1月よりデザイナーの役割を「ApplicationDesigner」※1として再定義しました。
本記事では、デザインスペシャリストとして活躍する服部 有里が、デザイナーとしてどのように自身の役割と向き合い、変化してきたのかをご紹介します。
※1 「ApplicationDesigner」の定義については、カジュアル面談資料にて紹介しております。
５年間の変化
前回の記事では「人を軸に考える」がテーマでした。そういった新卒時のマインドに変化はありましたか？
そうですね。変わったと思います。具体的には業務に軸を置くようになりました。人だけじゃなく、業務です。
フリーの提供しているものって業務システムだからです。業務システムで使いやすい状態を提供するには、考えるべきは業務だろうっていうふうに、いまは変わりました。「人」っていう軸だと、ざっくりした「ユーザーのために！」って視点になると思うんです。それに対し、業務システムでは「どんな種類」のユーザーかっていうのが重要なのかなと思ってます。その「どんな種類」っていうのはユーザーの行う業務により決まることに、ここまで働いてきて気づきました。
ユーザーには業務があり、その業務ごとに対象となる具体的なユーザー像を規定すべき、ということですか？
そうです。ユーザーっていう形にしてしまうと、いろんな業務をしている人がひとまとめになってしまいます。結局、その具体が見分けられないと、コレコレの業務ではこのユーザーはやりづらい、みたいなことが発生してしまう。しっかり具体的に「この人はこういう業務しているんだ」っていうふうに捉えると良いかなって気づきました。
そこにも繋がってくるんですが、「人を軸に考える」方法として、学生時代に人間中心設計を学ばれたと書かれていました。シニアのデザイナーとして活動するなかで、この考え方は同じですか？
そうですね、当時は人間中心設計っていうのはデザインの中心的アプローチであり、開発全体をつかさどるものと理解していました。今は実務を通し、これは開発プロセスのなかで使われる「考え方」のひとつなんじゃないかなっていう理解に変わりました。
開発プロセスが実体で、人間中心設計はそこで使う「考え方」のひとつということですか？
というより、業務システムの開発ではUI設計するにも様々な考え方やフレームワークの活用が必須だと思ってます。
また、ユーザー視点の反映は重要ですが、それだけでなく業務上の要求や機能要求、技術的制約などをチーム間で視点を揃え設計することが大切だと考えています。
たとえば、ワークフローという規模が大きい機能は、登場人物が多く状態が複雑になりがちでした。いまは、ユーザーの視点だけでなく業務を踏まえた設計が必須だったのだろうと思ってます。現在のフリーでは、シニアデザイナーに期待される役割のひとつに「解く価値がある問題を見つけ、チームが同じ水準で理解できる業務の要求に落とし込む」というのがあります。まさに当時、これができていればコストや手戻りが少なくできたのにと思います。なので、いまは要求工学やビジネスのフレームワークの知見も組み合わせて活用してます。
「モノ」を通じた「伝える・汲み取るコミュニケーション」
5年前の記事のテーマ「伝える・汲み取るコミュニケーション」については、現在どうでしょう？
大きく変わったこととして、相手の話を聞くときも自分が話すときも、つねに「モノ」をつくって皆で見ながら話すようになりました。
「モノ」っていうのは、 ユースケース図とかUMLも使うし、ビジネスフレームワークも使います。ポンチ絵とかフロー図とか、その時々に必要な形でつくります。
話してるだけだと空中戦になっていつまでも終わらないし、議論と軸がぶれていろんなことを言われます。そこで「モノ」を出すことで、議論がピンどめができます。皆で問題定義にフォーカスするため、「同じ夕日を見る」状態をまずつくる。
会話が空中戦になるのを、みんなの視点を「モノ」にピンどめし「同じ夕日を見」れるようにして解決したんですね。
そうです。全員の視点や理解を同じテーブルに上げて「同じ夕日を見る」ことで双方の理解が深まるし、話すべき内容をピンどめできます。これまでは、なにもせずUI設計やその後続の開発プロセスに進んでいたので、あとで議論が発散していました。これを、ちゃんと1つの話さなくてはいけない話題に収束できる工夫をしたら、当時感じていた課題が解決できたように思います。
なるほど。発散と収束みたいなイメージをしました。このやり方は、UI設計ではどんなメリットがありますか？
まずはアウトプットの手戻りが減ります。
もう1つは、そのアウトプットを出すための時間が減ることです。
手戻りが減るというのは、あとから「こういうのも欲しいんだけど」みたいな会話が起きなくなる。スピードが出るというのは、話題をピンどめして直行でいけるので、必要なことだけ考えてUI設計できる効果を得られます。
デザインスペシャリストになって
次は、デザインスペシャリストとしての動きを教えてください。この役割の定義に、迅速な開発のために仕組みを設計すると書かれています。服部さんはどんなことをして、システム開発の生産性向上に貢献していますか？
過去の開発からいま関わっているチームまで共通した課題があったので、そこを解決するように開発の仕組みを変えました。
超上流工程が十分に行われず要求が不足するとか、要求を記述せず画面案を他の職能と合意形成するとか、V字モデルでいうバリデーションがされないとか、そういう構造の問題がありました。このため、プロジェクトの初期に超上流工程をやりましょう。方法としてモデル駆動開発をやりましょうと持ちかけました。チームでドメインモデル図やユースケース図を用い要求を分析し、ちゃんと言葉として要求を定義する。それをUI設計やソフトウェア設計へ反映する流れに、チームで開発プロセスを変えました。
この話は高い抽象度の活動に見えますね。より具体のデザイナーの仕事であるUI設計業務に対しては、どのような影響を与えましたか？
1つは手戻りが発生しないことですね。もう1つは、 UI設計がボトルネックにならないこと。多分この2つだと思います。
もともと、先に話したような超上流の課題がありました。結果どうなっていたかって言うと、 UI設計の段階で要求を議論してすり合わせる。そういうことが発生していました。つまりそれって、画面をつくらないと前に進めないし、なんなら手戻りも発生するし、すごくUI設計の負担が高かったです。これを手前に持ってくることで、UI設計の質を改善できたと思います。
興味深いですね。 UI設計をするときにはじめて要求を考える…どんなやり方なんですか？
ざっくりPMからやりたいことを聞いていたり、「こういう課題を解決したい」みたいなのは聞きます。そこから、競合はどういうふうにしてるんだろう？と、ある程度自分のなかで顧客に必要な情報や行動の案を出します。で、いったん仮のイメージをつくる。そこで初めて手前の行動や必要な情報など、前提の誤りが明らかになるやり方でした。
5年間で直面した最も挑戦的な課題はありますか？
いま話した、チームで自分たちの開発プロセスを変えたのが1番大きいかなと思います。
これは自分の課題というより、そのチーム全体の課題でした。そのため、進め方や誰を巻き込むのかの選定が難しかったと思ってます。全体にすぐ効果を出すのは難しいので、まずは限られたメンバーからモデルをつくるとか、協力者を見つける。そのうえで、社内の有識者に協力をお願いしたり、チェンジマネジメントのテクニックみたいな書籍も読みながら、進めました。
この挑戦をなさったとき、服部さんや周りは、どのように協力し合ったり、どんな反応をしてましたか？
最初は課題を定義しても、あまりピンと来られてなかったんです。
「確かに言われてみればそうだよね」という形で、強い課題感は感じてませんでした。ただ、そのなかでも私とすこし考えが近い方がいたので、一緒に協力してやっていきました。チームのエンジニリングマネージャーにこういった課題を共有し、「チームとして取り組めば成果が出ると思う。やれる環境をつくってくれないか」みたいな相談もしましたね。
チームで協力しての開発プロセス改善や、それによる具体的なUIの製品品質向上に取り組まれていたことが伝わりました。5年のあいだ、新しい方が来たときはどのようなコーチングやメンタリングをし、彼らの能力開発に貢献したか教えてください。
直近ですと、社内でチームの開発プロセスに私と似た課題を感じている方が何人かおり、相談を受けて改善のアドバイスをしました。
お話を聞くなかで、その人自身の持つ技術や、関わるチームの状況、主要メンバーの発言や思惑などを自分の頭のなかでステークホルダーの関係性として整理します。そこから、協力を仰ぐべき人やアプローチ方法の提案をしてました。自分の経験だけでなく一般的なテクニックを元にしたり、自分が過去に相談をした方に教えていただいた知識を伝えてました。
その方々のチームの状況や関係者の方の発言を加味し、過去の経験も生かし、一次情報や一般論も踏まえて教育に取り込まれてたということですね。
そうですね。一般論は大切だと思います。
展望
デザインスペシャリストとして追求したい分野はありますか？それはフリーの事業成長やミッションの実現にどのように貢献すると考えてますか？
超上流工程を極めたいなと思ってます。
要求分析や定義の技術ももちろん必要ですが、後続の開発プロセスがよりスムーズに進むようなプロジェクトマネジメントの知識やハードスキルを身に着けて、チームの生産性をさらに上げたいです。自分のためというより、チームが強くなるため自分の技術を使いたいと思ってます。こういう実践を見た別のチームが真似をし、元のチームが実践をサポートする。単純ですけど、そういうふうに真似をしてサポートして、みたいな動きが広がれば事業成長のスピードは上がるかも、と考えてます。
超上流工程の技術を強化したい理由は、個人のスキルアップというより、チームが強くなるためなんですね。強くなったチームを他のチームが真似し、会社全体が強くなるってことですね。
はい、その通りです！
これからシニアを目指すデザイナーに向け、服部さんのご経験から「シニアとしての成長」に焦点を当てたメッセージをお願いします。
先の質問とも繋がるんですけど、業務システムの開発では、デザイナーは画面に色を付ける職種でなく開発者の一員だと思ってます。だからこそ、業界標準の正しい知識やテクニックを繰り返し実践してハードスキル、ソフトスキルを身につけることが大切だと考えています。これは、私自身も日々しています。
得た技術を自分だけにとどめておかず、エンジニア、 PM、関わる全ての職種に還元することがシニアとしての成長につながるかなと思ってます。伝えるってことは、より高い技術が必要になります。結果として自分自身の技術も磨かれていくし、周りも良い状態になっていくだろうと思っているからです。
―――――――――――――――――――――
ご一読いただきありがとうございます！freeeのApplicationDesignerの姿はいかがでしたでしょうか？
freeeでは一緒に働く仲間を募集しています。この記事を通じてfreeeが気になった人は、まずはカジュアル面談にぜひお越しください！
