INDEX
デザイン・業務に対する姿勢とこだわり
強みと弱み
スピード感のある対応と提案力を強みに、安定して成果を出せる進め方へ
デザイナーとしての強みと弱みについて教えてください。
強みは、納期を意識したスピード感と、相手が判断しやすい提案へ整理する力です。一方で、責任感から複数案件を抱え込みやすいため、優先順位と進行管理を意識しています。
納期を意識した、スピード感のある対応
私の強みのひとつは、納期を意識しながら、必要な成果物を早い段階で形にする対応力です。
デザイン業務では、十分な検討時間や情報が常に与えられるとは限りません。特にスタートアップや新規事業では、要件が完全に固まっていない状態でも、短期間で仮説を整理し、関係者が議論できる材料を準備することが求められます。
そのような場面では、最初から完成度の高い成果物を目指すのではなく、まず判断に必要な骨格をつくります。画面構成、情報の優先順位、提案の方向性などを早めに可視化し、関係者からフィードバックを得ながら精度を高めていきます。
早く作ること自体を目的にするのではなく、早く見せることで、認識のずれや手戻りを早い段階で発見することを大切にしています。
相手が判断しやすい形へ整理する提案力
もうひとつの強みは、ハッカソンやアイデアソン、実務での提案経験を通じて培った、提案資料・プレゼン資料の構成力です。
製薬会社の案件、AR領域の営業企画、グルメ横丁の投資提案資料など、さまざまな場面で、クライアントや上長の意図をくみ取りながら提案を組み立ててきました。
提案資料では、単に情報をきれいに並べるのではなく、読み手が次の順番で理解できることを意識しています。
- 現在どのような状況にあるのか
- 何が課題なのか
- なぜ、その課題へ取り組む必要があるのか
- どのような解決策が考えられるのか
- 複数案の中から、なぜこの案を推奨するのか
- 実行した場合、どのような変化が期待できるのか
デザイナー自身が理解できる資料ではなく、意思決定者、営業担当、エンジニア、クライアントなど、異なる立場の人が同じ方向を向ける資料にすることを重視しています。
前例にとらわれず、伝わる方法を考える
自己紹介スライドや提案資料の見せ方についても、既存の形式をそのまま踏襲するのではなく、相手にとって何が理解しやすいかを考えて工夫してきました。
文章だけでは伝わりにくい場合は図解へ置き換え、複数の論点がある場合は比較表へ整理します。サービスの将来像を伝える場合は、利用シーンや画面イメージを使って、完成後の状態を想像しやすくします。
見栄えを整えるだけではなく、相手の理解と意思決定を支援することもデザインの役割だと考えています。
責任感から、複数案件を抱え込みやすい面
一方で、責任感が強い分、新しいタスクが入ると早めに着手しようとして、複数案件を抱え込みやすい面があります。
依頼を受けた時点で気になる部分を確認し、先回りして準備を進めることは強みでもあります。しかし、複数の案件が同時進行になると、タスクの切り替えが増え、集中力や判断力を分散させる原因にもなります。
特に、短時間で終わると思って着手した作業が想定以上に広がり、別案件の時間を圧迫することがありました。
タスクの見える化と、着手順の改善
現在は、依頼を受けた順番ですぐに着手するのではなく、緊急度・重要度・影響範囲・必要時間を確認したうえで、着手順を整理するようにしています。
- 今日中に判断が必要なタスク
- 他メンバーの作業を止めているタスク
- 要件確認だけ先に行うべきタスク
- 集中時間を確保して取り組むタスク
- 関係者へ相談・委任できるタスク
また、自分の中だけで優先順位を決めるのではなく、複数案件が重なった時点で関係者へ共有し、優先順位を合意することも意識しています。
今後もスピード感を強みにしながら、個人の頑張りだけに依存せず、より安定的かつ再現性高くプロジェクトを進められるよう改善していきたいと考えています。
業務姿勢
QCDを意識し、限られた条件の中で最適な着地点をつくる
デザイン業務でのこだわりについて教えてください。
大きく2つあります。ひとつはQCDを意識し、納期へ責任を持つこと。もうひとつは、見た目からではなく課題から考えることです。
品質・コスト・納期のバランスを考える
私がデザイン業務で大切にしていることのひとつは、QCDを意識することです。
- Quality：利用者や事業にとって必要な品質
- Cost：制作・実装・運用に必要な工数と費用
- Delivery：成果物や機能を届ける期限
デザイン品質を高めることは重要ですが、納期や開発コストを無視して理想だけを追求すると、プロジェクト全体にとって最適な判断にはなりません。
反対に、納期を優先するあまり、最低限必要な使いやすさや情報設計まで省略すると、リリース後に問い合わせや改修が増え、結果として大きなコストが発生します。
そのため、プロジェクトの状況に応じて、何を守り、何を段階的に改善するのかを整理することが重要です。
特に重視している「納期に応えること」
スタートアップや中小企業では、限られた人数と予算の中で、早くサービスを市場へ届けることが求められます。
そのため私は、完成度だけを追求するのではなく、期限までに何を実現する必要があるのかを明確にし、優先順位をつけて進めることを意識しています。
たとえば、リリース時点で必要なMVPと、その後の改善項目を分けることで、品質を極端に下げずに納期へ対応できます。
- 今回のリリースで必須となる体験
- ユーザーが操作できなくなる重大な問題
- リリース後でも改善できる表現や装飾
- 利用状況を確認してから判断する機能
- 将来の拡張を見据えて構造だけ整えておく項目
早い段階で成果物を共有する
納期へ対応するためには、完成直前まで一人で作り込まないことも重要です。
ワイヤーフレームや簡易モックなど、粗い状態でも方向性が確認できる成果物を早めに共有します。
関係者が確認できる状態を早くつくることで、要件の不足や認識のずれを発見しやすくなり、終盤での大きな手戻りを減らせます。
納期を守ることも信頼設計のひとつ
デザインは、完成した画面だけで評価されるものではありません。
関係者へ適切なタイミングで共有すること、期限内に判断材料を提示すること、問題がある場合に早く相談することも、プロジェクトを前へ進めるための重要な役割です。
納期へ応えることは、単なる進行管理ではなく、クライアントやチームとの信頼関係を築く行動だと考えています。
上流工程
課題起点で考える、イシュードリブンのアプローチ
上流工程では、どのような考え方を大切にしていますか？
要望をそのまま画面へ反映するのではなく、まず何が本当の課題なのかを整理することを大切にしています。
見た目を考える前に、解くべき問題を確認する
私がデザイン業務で大切にしているもうひとつの考え方が、課題を起点に考えるイシュードリブンのアプローチです。
デザインの依頼では、「この画面を見やすくしたい」「ボタンを目立たせたい」「メニューを追加したい」といった具体的な要望を受けることがあります。
しかし、その要望をそのまま実装しても、根本的な問題が解決しない場合があります。
たとえば、「ボタンを目立たせたい」という依頼の背景には、次のような異なる課題が考えられます。
- ボタンの存在に気づいていない
- ラベルの意味が伝わっていない
- 押した後の結果が想像できない
- 情報量が多く、視線が分散している
- その操作を行う必要性が理解されていない
- ボタンへ到達する前の導線に問題がある
原因によって、必要な解決策は変わります。
色を強くするだけで解決する場合もあれば、ラベル、情報構造、画面遷移、サービスの説明自体を見直す必要がある場合もあります。
曖昧な違和感を、扱える課題へ分解する
「気づきにくい」「わかりにくい」「使いにくい」といった言葉は、問題の存在を示していますが、そのままでは具体的な設計へつなげにくい表現です。
そこで、誰が、どの場面で、何をしようとして、どこで迷ったのかを分解します。
- 対象となるユーザーは誰か
- どのような目的で画面を利用しているか
- どの操作の前後で問題が起きているか
- 必要な情報が不足しているのか
- 情報はあるが、見つけられないのか
- 理解できるが、操作しづらいのか
- ユーザーと事業側の認識に差がないか
違和感を細かく分解することで、議論可能な課題へ変換し、適切な打ち手を検討できるようになります。
独りよがりなアイデアで形にしない
デザイナーが魅力的だと思う表現が、必ずしもユーザーや事業にとって最適とは限りません。
そのため、個人の感覚だけで解決策を決めず、既存データ、ユーザーの声、問い合わせ内容、競合サービス、業務フローなどを確認します。
限られた情報しかない場合も、事実と仮説を分けて整理し、何を検証すべきかを明確にします。
KPTなどを使って論点を可視化する
状況に応じて、KPTなどのフレームワークも活用します。
- Keep：現在うまく機能しており、維持すべきこと
- Problem：ユーザーや事業に影響している問題
- Try：次に試す改善案や検証方法
既存画面を全面的に否定するのではなく、機能している点を残しながら、改善すべき点を明確にできます。
課題を整理すること自体が目的ではなく、その後の意思決定と具体的な設計につながる粒度まで落とし込むことを意識しています。
優先順位
事業インパクト・ユーザー影響・実現性から、取り組む順番を決める
課題の優先順位付けも行っているのですか？
はい。すべての課題を同じ重さでは扱わず、ユーザーへの影響、事業への影響、実現コストなどを見ながら順番を整理します。
課題を並べるだけでは、改善は進まない
サービスを調査すると、多くの課題や改善案が見つかります。
しかし、それらをすべて同時に解決することは現実的ではありません。課題を列挙しただけでは、どこから着手すべきかを判断できず、関係者ごとに優先したい項目も異なります。
そこで、主に次の観点から優先順位を整理します。
- ユーザー影響：どれだけ多くのユーザーが、どの程度困っているか
- 事業インパクト：売上、継続率、利用率、問い合わせなどへ影響するか
- 緊急性：放置すると重大な問題や機会損失につながるか
- 実現コスト：デザイン・開発・検証にどの程度の工数が必要か
- 依存関係：ほかの機能やプロジェクトの前提になっているか
- 検証可能性：実施後に効果を確認できるか
重要度と実現性のバランスを見る
大きな効果が期待できても、開発に長期間を要する改善だけを選ぶと、成果が出るまで時間がかかります。
一方で、小さな改善だけを繰り返しても、根本的な課題は残ります。
そのため、短期間で実行できる改善と、中長期的に構造から見直す改善を分けます。
- すぐに修正でき、影響も大きい項目
- 検証のために小さく試せる項目
- ほかの改善の前提になる構造的な項目
- データを蓄積してから判断すべき項目
- 中長期ロードマップで対応する項目
競合分析からモック作成まで、一貫してつなげる
優先順位が整理されると、デザインの方向性を実務へ落とし込みやすくなります。
理想としているのは、次の工程を分断せず、一貫してつなげることです。
- 課題と目的の整理
- ユーザーや業務フローの確認
- 競合・類似サービスの分析
- 情報構造と機能要件の整理
- ワイヤーフレームによる構造検討
- 複数パターンの比較
- モック・プロトタイプによる具体化
- 関係者との合意形成
- 実装後の確認と改善
画面を制作する工程だけではなく、課題を発見してから成果を検証するまでを連続した設計活動として捉えています。
ユーザーと事業の双方に貢献する
ユーザーにとって使いやすくても、事業として継続できなければサービスは成長しません。
反対に、事業側の都合だけを優先すると、ユーザーの負担が増え、長期的には利用離れにつながります。
ユーザーの目的と事業上の目的が交わる場所を探し、双方にとって意味のある改善へつなげることが、プロダクトデザインにおける重要な役割だと考えています。
語れるテーマ
課題解決型のデザイン思考と、複雑な情報を整理する進め方
デザイン領域で、特に語れるテーマはありますか？
課題解決に基づくデザイン思考と、複雑な情報を整理して設計へつなげるプロセスについてお話しできます。
課題解決型のデザイン思考
デザイン領域で語れるテーマとしては、課題解決に基づくデザイン思考や、情報整理の重要性があります。
特に関心があるのは、イシュードリブンで課題を絞り込みながら、複雑な情報をどのように構造化し、具体的な解決策へつなげるかというプロセスです。
ユーザー視点で課題を正しく捉え、それを情報設計や画面設計へ落とし込むことが、良いUXの土台になると考えています。
情報量が多いほど、優先順位が重要になる
BtoBサービスや管理画面では、多くの情報や機能を扱います。
すべての情報を省略せず表示するだけでは、ユーザーが次に何をすべきか判断できません。
そこで、情報を次の観点から整理します。
- 最初に確認すべき情報
- 意思決定に必要な情報
- 必要な場合だけ開く詳細情報
- 補足として提供する情報
- 別の画面へ分けるべき情報
情報を減らすことだけが整理ではありません。
必要な情報を残しながら、ユーザーが理解しやすい順番とまとまりへ変えることが重要です。
画面単体ではなく、行動の流れを設計する
ひとつの画面がわかりやすくても、その前後の画面遷移が複雑であれば、サービス全体としては使いにくくなります。
そのため、画面単体ではなく、ユーザーが目的を達成するまでの行動を確認します。
- どこから画面へ入るのか
- 画面上で何を判断するのか
- 次にどの操作を行うのか
- 失敗した場合にどこへ戻るのか
- 操作後に何が変化したと理解できるか
この流れを整理したうえで、必要な画面と情報を設計します。
実務へ再現できる形で共有する
デザイン思考やUXという言葉を抽象的に説明するだけでは、実際の業務で使いにくい場合があります。
そのため、実務で経験した課題をもとに、どのような情報を集め、どのように分類し、どの段階で関係者と確認したのかを具体的に共有することを意識しています。
手法を紹介するだけではなく、制約がある状況でどのように使い分けたのかまで説明することで、ほかのプロジェクトにも応用しやすくなります。
テーマを選んだ理由
完成したデザインだけでなく、意思決定までのプロセスを言語化する
なぜ、課題解決と情報整理をテーマに選んだのですか？
実務の中で、完成したデザインだけでなく、そこへ至る考え方や判断理由を説明する機会が増えたからです。
結果だけでは、デザインの価値が伝わりにくい
このテーマを選んだ理由は、実務の中で、課題の捉え方や解決までの考え方を周囲へ説明する機会が増えてきたからです。
完成画面だけを見ると、どの部分が工夫されているのか、どのような制約を解決したのかが伝わらない場合があります。
同じ見た目の画面でも、次のような背景によって設計の意味は変わります。
- ユーザー調査から導いたものか
- 技術的制約を考慮したものか
- 既存ユーザーの学習コストを抑えたものか
- 短い納期の中で優先順位をつけたものか
- 将来の機能追加を想定したものか
そのため、「この画面にしました」という結果だけではなく、どの課題に対して、何を比較し、なぜその案を選んだのかを説明することを大切にしています。
意思決定の理由を共有する
判断理由を言語化すると、関係者が賛否を伝えやすくなります。
個人の好みとして提案するのではなく、目的や課題に照らして説明することで、議論を前へ進められます。
- この情報を上に配置した理由
- この機能をMVPから外した理由
- このコンポーネントを採用した理由
- 競合と異なる導線にした理由
- 複数案からこの案を選んだ理由
個人の経験を、チームの知識へ変える
デザインの判断が個人の中だけに残ると、担当者が変わった際に同じ議論を繰り返すことになります。
プロセスや判断基準を資料、Figma、ガイドラインなどに残すことで、個人の経験をチームの知識へ変えられます。
実例を交えながら、ほかの人が再利用できる形で共有できることも、自分の強みのひとつだと考えています。
仕事のやりがい
期待に応え、成果と次の信頼につなげられたとき
仕事でやりがいを感じるのは、どのようなときですか？
クライアントや社内の期待に応え、制作物だけでなく、その先の成果や信頼につなげられたときです。
任せてもらえる信頼が、仕事の原動力
仕事でやりがいを感じるのは、クライアントや社内の期待に応え、その先の成果につなげられたときです。
20代の頃から、新規事業の立ち上げや提案業務に関わる機会が多くありました。
その中で、「この領域は任せよう」「次の提案もお願いしたい」と信頼していただけることが、自分の大きな原動力になってきました。
最初からすべてを任せてもらえるわけではありません。
小さな依頼へ丁寧に対応し、期待された納期と品質へ応えることで、少しずつ担当領域が広がっていきます。
期待どおりではなく、期待を超える提案へ
依頼された成果物をそのまま制作するだけでなく、背景にある目的を理解し、必要に応じて別の案や改善点も提案することを意識しています。
依頼内容を変えることが目的ではありません。
相手が実現したいことを理解したうえで、より良い方法がある場合に、理由とともに提示することが重要です。
期待されたものを納品して終わるのではなく、相手が想定していなかった選択肢や気づきを返せたときに、大きなやりがいを感じます。
成果物だけでなく、検討過程を評価された経験
過去には、製薬会社とのプロジェクトで、「企画の検討過程も含めて価値がある」と評価いただいた経験があります。
最終的な成果物だけでなく、課題の整理、比較案の検討、提案に至る思考や姿勢まで認めていただけたことは、今でも印象に残っています。
デザインの価値は、完成したビジュアルだけではありません。
曖昧な状態から論点を整理し、関係者が判断できる状態をつくるプロセスにも価値があると実感した経験でした。
成長の原点
修正へ対応するだけでなく、対話から意図を確認するデザイナーへ
ほかに、やりがいを感じるポイントはありますか？
関係者と信頼関係を築き、デザインだけでなく、プロジェクト全体を前へ進められたときにもやりがいを感じます。
駆け出し時代に経験した、修正の繰り返し
デザイナーとして駆け出しの頃は、クライアントの意図が十分に見えないまま制作し、修正や差し戻しが重なることがありました。
指示された修正へ対応しても、背景の目的を理解できていなければ、別の箇所で再び認識のずれが発生します。
この経験から、修正指示の内容だけを見るのではなく、「なぜ、この変更が必要なのか」を理解することが重要だと考えるようになりました。
営業担当と連携し、クライアントと直接対話
そこで、営業担当と連携しながら、クライアントと直接会話する機会を増やしていきました。
要望を聞くだけでなく、利用者、目的、優先事項、社内事情などを確認し、自分の言葉で理解し直すようにしました。
- 誰に向けた成果物なのか
- 最終的に、どのような行動を促したいのか
- 現在どのような問題が起きているのか
- 今回、最も優先したいことは何か
- 過去案のどこに不満があったのか
- 社内で誰が意思決定するのか
直接対話することで、修正指示の背景を理解しやすくなり、別の解決案も提案できるようになりました。
制作からディレクションへ視野を広げる
この経験を通じて、提案力やディレクションの視点が養われました。
単にデザインを制作するだけでなく、要件を整理し、関係者の認識をそろえ、次の判断を促すことも、デザイナーが貢献できる領域です。
エンジニア、営業、企画、クライアントなど、それぞれの立場によって重視するものは異なります。
その違いを理解し、共通の目的へつなげることで、プロジェクトを前へ進めやすくなります。
関係者との信頼も、プロジェクトの成果
完成した画面や資料だけでなく、関係者が安心して相談できる状態をつくることも、プロジェクトにおける成果のひとつです。
問題が発生したときに早く共有できること、異なる意見を率直に話し合えること、判断理由を説明できることが、継続的な改善につながります。
デザインの成果と同時に、関係者との信頼関係を築きながらプロジェクトを進められたときにも、大きなやりがいを感じます。
まとめ
課題を見極め、伝わる形に整理し、チームと成果へつなげる
私がデザイン業務で大切にしていること
私がデザイン業務で大切にしているのは、見た目を整えることだけではありません。
- 納期を意識し、早い段階で判断材料をつくること
- 要望の背景にある、本当の課題を確認すること
- 課題を分解し、優先順位をつけること
- ユーザーと事業の双方にとって意味のある解決策を考えること
- デザインの判断理由を言語化すること
- 関係者と認識をそろえ、プロジェクトを前へ進めること
- 個人の経験を、チームで再利用できる知識へ変えること
スピードと品質を両立する
スピードを重視することと、品質を大切にすることは、必ずしも相反するものではありません。
早い段階で仮説や構造を共有し、フィードバックを受けながら改善することで、納期へ対応しながら品質を高められます。
一人で完成させてから共有するのではなく、チームと一緒に精度を上げる進め方を大切にしています。
画面の先にある成果を見る
デザインのゴールは、画面や資料が完成することではありません。
ユーザーが迷わず目的を達成できること、関係者が判断しやすくなること、事業が前へ進むことが重要です。
課題を見極め、情報を整理し、適切な形で伝え、実行へつなげる。
これまで培ってきたスピード感、提案力、情報整理力、対話力を活かしながら、今後もプロダクトとチームの双方へ貢献できるデザイナーを目指していきます。
