“なぜそのデザインか”を問い続けるプロダクトデザイナー

もともとはエンジニアとしてキャリアをスタートしました。就活ではWeb系のベンチャーを中心に見ていたのですが、ベーシックを選んだ決め手は「人」と、「あらゆる課題に対して『仕組み』と『テクノロジー』で解決していく」というビジョンでした。

学生時代はアプリ開発や動画制作、作曲など、クリエイティブな活動に打ち込んでいました。選考ではそれらの制作物をお見せしながら、ものづくりへの想いやその背景にある考えをプレゼンしたのですが、その想いに深く共感し、一人の人間として興味を持ってくださったのがベーシックでした。

また、面接でお会いする方々が非常にフレンドリーだったことも印象的です。待機室にいる私に先輩社員が顔を出して気さくに話しかけてくれたり、みなさんが自分の仕事や会社について楽しそうに話されていたりと、組織の空気感そのものが、当時学生だった私にはとても魅力的に映りました。

私はものづくりそのものへの好奇心はもちろん、自分が作ったものを通して誰かの生活や仕事に良い影響を与え、「便利になった」「感動した」という反応をいただけることが何よりのモチベーションになっています。

自分が生み出したものが誰かの役に立ち、ポジティブな変化を生み出す。そんな自分の価値観と、テクノロジーで課題を解決するベーシックのビジョンが重なり、この場所で挑戦したいという想いが強まりました。

一言で言うと、ユーザーに「どう見せて、どう使わせるか」という体験から設計しデザインという具体に起こしていく役割です。

UI設計はもちろん重要な役割ですが、それだけではありません。デザイナーとして絶対に死守すべき「プロダクトのデザインや使い心地の品質」を担保しながら、事業のグロースにデザイナーという立場からどう貢献できるかを常に考えています。

ときには、言葉やテキストだけの議論に留まらず、まず具体のデザインや実際に動くものを形にすることで議論を加速・検証していくような動き方をすることもあります。

その過程で必要になるUI・UXリサーチや要件の整理、他職種との連携、場合によっては実装まで。価値を届けるために必要なあらゆるプロセスに伴走し続けることが、ベーシックのデザイナーに求められる役割だと考えています。

自分の場合はエンジニア出身なので、技術的な制約や工数感を理解した上でデザインを考えられることが強みになっています。

さらに今はAIを積極的に活用しています。デザインドキュメントの作成や業務フローの自動化はもちろん、最近ではプロダクトの利用データをAIで分析し、ユーザーがどこでつまずいているのかを構造的に明らかにして、施策や意思決定の土台をつくるところまで踏み込んでいます。デザイナーがデータと向き合い、事業の判断に入っていく動きです。

私はデザイナーを、「使い心地の品質を守り抜く設計者」だと考えています。ユーザーの課題や事業が届けたい価値を理解し、それを誰もが使える体験として形にする。そして、ときにはデザインだけでなく、リサーチや要件整理、実装まで踏み込みながら、その価値を最後まで届け切る。それが、ベーシックのデザイナー像です。

ユーザーの現実をプロダクトの言葉に変換できる専門家集団をつくること。チームづくりの起点はそこです。UIはその結果だと思います。この定義を軸に、いままさにチームをつくっている段階です。

そこで意識しているのが、言語化です。「なぜこのデザインか」「ユーザーはここで何を感じるか」を言葉にして場に出せるかどうかが、デザイナーとしてのコアな部分です。

デザインを並べて「こちらの方がなんとなくいい」で止まるのではなく、その判断の根拠まで言語化できて初めて、プロダクトの意思決定に本当の意味で参加できるのかなと思います。採用でもスキルは前提として、「今何ができるか」より、そういう思考を言葉にして場に出せる人かどうかを見ています。

チームとして意識しているのは、「なぜそのデザインか」を問い続ける文化です。言語化できる個人を集めるだけでなく、チームとしてそれを当たり前にする場を作ること。その積み重ねが力になっていくと考えています。

ベーシックが提供するワークフロー自動化ツール「workrun」のワークフロー紹介ページを大量リリースするというプロジェクトがありました。各ページには、そのワークフローの流れを説明するフロー図の画像が必要で、これが問題でした。

当時、AIで画像を生成しようとすると日本語が文字化けしたり、ロゴの出力が安定しなかったりと、品質を保証できる状態ではありませんでした。そのためデザイナーが1枚ずつ手動で作成していましたが、大量リリースが必要になったとき、ここが最大のボトルネックになることは明白でした。本来プロダクトデザイナーがリソースを使うべき仕事ではない。でも誰かがやるしかない状態が続いていました。

「マーケやビジネスのチームが自分たちで画像を作れる仕組みを作るべきだ」と判断し、GASのWebアプリを自作しました。AIの画像生成ではなく、HTML/CSSで描画してスクリーンショットとしてダウンロードする方式を採用することで、日本語崩れや出力の不安定さを根本から解決しました。ワークフローの内容をテキストで渡すだけでフロー図が生成でき、テキストやアイコンも自由に調整できるCMS的な機能も組み込みました。

さらに、マーケ・ビジネスチームがすでにCodexを使ってページ自体を生成する仕組みを検証していたことに着目しました。CodexにはSkillsがある。GASアプリと連動するSkillsを作れば、ページ生成のプロンプトひとつで画像まで一気通貫で作れるなと。なのでSkillsの作成もあわせて行いました。

結果として、フォーマットが決まっている画像——フロー図や機能説明図のような類いは、デザイナーを介さずに誰でも即座に生成できる仕組みができました。使った社内メンバーから「他のシーンでも使いたい」という声も出てきており、展開を予定しています。

ルーティーン的なデザイン作業から解放されて、プロダクトやユーザー体験の設計に集中できる。依頼する側は即座に必要な画像が作れる。デザイナーが業務の仕組みそのものを変える。そういう関わり方が、双方にとって良い形だとこの経験で感じました。

AIによって機能自体は誰でも模倣できる時代になりましたよね。機能の多さで競合に勝てる時代は終わった、というのが自分の認識です。

だからこそ作りたいのは、使えば使うほど、その人に馴染んでいくプロダクトです。使い込むほどAIがその人を学習し、ツールがどんどんその人にフィットしていく。普通に使い続けるだけで育っていく。そういうプロダクトは、簡単に他のツールに置き換えられないはずです。

全社的にも「AIによる効率化 × UXによる差別化」を戦略テーマに掲げています。AIに任せられることはAIに任せて、浮いた時間をユーザー理解と上流設計に使う。それがデザインチームの価値になっていくと考えています。