静かなリーダーシップの実践

前回の投稿で「問題解決型デザイナー」についてのあり方について書いたが、もう少し自身のデザイナー観に踏み込んでみたいと思う。

デザイナーでなくとも働く者であれば誰しもどこかのタイミングで「プレイヤーとして続けるべきか」「マネジメントに進むか」という選択肢に出会うことになる。私はどちらかというと前者で、自身がマネジメントが向いているとは思っていない人間だ。ただ、マネジメントをしたくないからダメだ、というようなことはないと思っている。

「プレイヤーとしての立場を保ちながらも、チーム全体に良い影響を与えたい」と考えるスタンスは、これからの時代にとても重要だと思う。リーダーシップとは必ずしも前に出ることではなく、支える・導く・仕組みを整えることも立派なリーダーシップの形だと思うのである。

1. 「シニア・スペシャリスト型」のキャリアを築く

マネージャーではなく、「スペシャリスト」としてチームやプロジェクトに深く貢献する立場。

• 現場の第一線で手を動かしながら、周囲のクオリティ向上を牽引
• 若手デザイナーのメンターや技術的リファレンスとして存在感を持つ
• UX品質やプロセスの整備に貢献し、チームの土台を強くする

これは「支えることでチーム全体を底上げする」形のリーダーシップである。

2. 「仕組みで支える」視点を持つ

直接リードしなくても、プロセスや仕組みを通じてチームに良い影響を与えることができる。

• デザインガイドライン、コンポーネントライブラリの整備
• UXレビューやナレッジ共有会の企画運営
• プロジェクトの振り返り文化の導入
• チームのワークフローの改善提案（Notion・Figma・Slackなどの活用法の最適化）

こうした仕組みづくりは、リーダーシップの裏側で重要な貢献であり、私の「サポート力」や「考える力」が活きる部分である。

3. 「チーム変革のサポーター」になる

「変革」に関心があるのなら、自分が前に立つのではなく、変革の実行者を支える補佐的立場に回る方法がある。

• 組織改善を推進するマネージャーやPdMと協働し、現場の声を翻訳・提案する
• ワークショップや共創の場でファシリテーションや観察役に回る
• 変革のアイデアを「小さく試す」プロトタイプ実験を主導する

これは「チームの影の力持ち」として、変革の種を撒く重要な存在である。

4. 「実践知」を言語化・可視化する

私がプレイヤーとして経験してきたことを、チームや他者に伝えられる形にすることは、非常に価値がある。

• UI設計やUX改善のナレッジをドキュメント化
• プロジェクトの学びを事例として社内にシェア
• 後輩やチームへのアドバイスを「チェックリスト化」する

これにより、自分のプレイングがチーム全体の財産になる。これは一種の「間接的なマネジメント」と言える。

私が目指せる姿

前に立つリーダーよりも、後ろからチームを押し上げるような存在。それが私らしさであり、今後ますます求められる役割であると信じたい。

• シニアデザイナー / プリンシパルデザイナー
• デザインエヴァンジェリスト / プロセスアーキテクト
• メンタリング型リーダー
• 仕組みづくりと支援で動く変革パートナー

「前に出るタイプではない」としても、こうしたチームの基盤を整える動きこそ、これからの時代の「静かなリーダーシップ」である。そして、それはチームにとってかけがえのない役割と言える。

静かなリーダーシップとは

「前面に出るタイプではなく、支援・改善をしたい」のであれば、“静かなリーダーシップ” はとても有効的。

通常のリーダー	静かなリーダー
指示を出す	気づきを促す
会議で引っ張る	ドキュメントで調整する
ゴールを声高に掲げる	日常の行動で信頼を築く

静かなリーダーシップでできるネクストアクションは以下の通り。

アクション	目的
自分の作業意図や仮説をSlackやFigmaで軽く共有	認知のズレや誤解を防ぐ／思考プロセスが見えることで信頼感UP
自分なりの「作業ガイド」「仕様メモ」などをNotionに小さく作成	属人化を避けつつ、仕組み化のきっかけを作れる
会話で「それって◯◯という課題が背景ですか？」と確認する	受け身でなく“構造的な理解”を持っている人と認識される

静かなリーダーシップの実践シート

概要

項目	内容
🎯 目的	・職位に関係なく「信頼されるキーマン」になる・議論やプロジェクトを“整え”、前に進める力になる
👤 対象	・チームを支えるのが得意な人・空気を壊さずに変化を起こしたい人・業務委託など立場的に発言権が限られている人
🧭 軸	「観察力」×「仮説」×「整理力」＝ 静かに響く影響力

構成例

関係性構築のアクションチェック

状況	実践アクション	チェック
会話が少ない	Slackのスレで「◯◯という意図ですか？」と軽く確認・深掘り	☐
他職種が困っていそう	「少し整理してみたので共有しますね」とNotionでまとめ投稿	☐
自分の意見を伝えたい	「一案ですが、〜という仮説でこう考えてみました」と添えて発信	☐

デザインの価値を“届ける”アプローチ

課題	実践アクション	チェック
UIの優先度が低い	小さな改善を実装ベースでFigmaに提案＋「改善ログ」にまとめる	☐
PdMの意思決定が偏る	スプリントのリファインメントで「このケース、AとBどちらに寄せますか？」と問いを投げる	☐
UX課題が見過ごされる	「現時点では支障ないと思いますが、将来的にこういうリスクもあります」と補足する	☐

3. チーム文化に“静かに効く”習慣づくり

状況	実践アクション	チェック
横の共有がない	自分の進め方・設計意図を毎週Notionに軽くメモ（見たい人だけ見ればよいスタイル）	☐
チームの声が見えない	「最近、◯◯について困ってる人いませんか？」とゆるく投げてみる	☐
意見がぶつかりやすい	ファシリ時に「今それぞれの立場でどう見えてますか？」と状況の見える化から始める	☐

使い方の例

• 自分で週1回ふりかえる：「今週はこういう“支える行動”ができたか？」
• チーム改善の相談をされたときに、行動のヒントとして使う
• 新しいチームに入った時の「初動で信頼されるための指針」として使う

静かなリーダーシップの実践シート（現場リソースが限られる編）

目的

• 正社員やPdMほどの権限はなくても、プロダクト改善に“静かに効く存在”になる
• 自分の立場で最大限できる工夫を積み重ね、信頼を蓄積する
• 徐々に「この人に聞いた方がいい」「関わってほしい」と思わせる立場に変化させる

静かなリーダーシップ実践アクション

リソース不足時の“提案の仕方”を変える

状況	実践アクション	補足
ミニマムでの解決しか受け入れられない	Figmaで「MVP案」「UX最適案」の2パターンを出す	二段階の選択肢を見せることで、提案の意図と理想をセットで提示
PdMがワイヤーフレームを作ってしまう	「元の意図をくみ取って、こう整理してみました」とブラッシュアップ版を作る	PdMの意見を否定せず、プロの視点で整え返す
「今は実装無理そう」と言われる	Notionに「将来的に検討したい改善アイデア」として軽くストック	無理に通さず、アイデア管理だけしておくことで機が熟すまで待てる

エンジニアやPdMに「頼られる存在」になるための静かな工夫

課題	実践アクション	補足
UIUXへの理解が浅い	Figmaファイルに注釈コメントを丁寧に残す（Whyベースで）	見た目ではなく意図を伝えることで信頼感が高まる
要件がふわっとしている	Slackで「これは◯◯と△△どちら寄りですか？」など、選択肢ベースで整理	相手が考えやすくなり、設計を“共同”で進められる
意見を聞いてもらえない	「参考ですが…」とNotionやSlackでナレッジ共有（成功事例・UXリサーチ）	押し付けず、共有するスタイルで信頼を構築

チームとの“薄くても効く”横のつながり

状況	実践アクション	補足
デザインチームが個人主義	自分の進め方やtipsをNotionで週1記録・共有	見たい人が見るだけの形式で気楽に続ける
コミュニケーション不足	Slackの投稿に対して「いいね」だけでも反応し、軽く流れを拾う	絡みすぎず、観察しつつ存在感を出す
実績が社内に伝わりにくい	月1で「改善されたUIのBefore→After」をNotionで共有（小さくても）	見える化することで、貢献度がじわじわと伝わる

一週間の軽やかな実践スケジュール（例）

曜日	アクション例
月	リファインメントで「意図を確認する質問」＋MVP案と理想案を出し分け
火	Figma注釈やコメントに「Why」を追記／Slackで軽く観察
水	Notionの「改善ログ」に1件アップ（スクショあり）
木	チームの投稿に反応／ちょっとしたリサーチ記事をSlackに共有
金	1週間の気づきをNotionにまとめ（自分のためでもOK）

ゴールイメージ

• 「この人がいると、なんかプロジェクトが整う」と思われる存在
• 意見は押しつけず、でも“頼られ始める”
• 裏方っぽい立ち回りなのに、なぜか意思決定に巻き込まれていく

自分のやり方やノウハウを伝えるコツ3原則

① 「パターン」で語る：属人性を薄める

② 「問い」で伝える：共感と発見を生む

③ 「定点」で出す：見に来てもらえる形にする

原則①「パターンで語る」〜人に伝わる“型化”〜

やり方を抽象化して「使いまわせる知恵」にする。具体 → 抽象 → 汎用化、という流れがコツ。

例）「タスクの優先度が見えづらいとき、どうしていますか？」と聞かれたら
👉 こう伝えると伝わりやすい：

状況整理→選択肢整理→意思確認の3ステップで進めていく。
Notionで「目的」と「制約」を先に書き出してから、A案・B案を簡単に可視化 → SlackでPdMに方向性を確認してから着手、という流れですね。

こうすることで「自分のやり方」→「誰にでも応用できるパターン」に変わり、価値が伝わりやすくなる。

原則②「問いで伝える」〜一方通行にしない〜

あえて「提案」や「正解」ではなく、問いを共有する。

例）Slackでノウハウを共有するとき

最近Figmaファイルを複数人で編集するときに、
・「仕様としてどこまで明記すべきか」
・「注釈は多い方がよいのか、少ない方がわかりやすいのか」
悩む場面がありました。

私は最近こうしてます →（やり方簡単に共有）
皆さんどうしてますか？考え方などあれば聞いてみたいです〜

👉問いをベースにすると、他人にとって“余白がある”情報になり、返信もしやすくなる。

原則③「定点で出す」〜続けられる仕組み化〜

毎週○曜日に「共有ログ」をNotionに書く／Slackに1行メモ投稿する
　→「見る人が決まっていなくても、発信している」というスタンスが信頼に変わる。

例）Notionでこんなテンプレを使うと続けやすい：

📌 今週の気づきログ（5/13週）

🎯 問題：ボタンの配置をどう最適化するか迷った
🔍 やったこと：クリック率・ユーザーの視線調査を確認
💡 決めた基準：スマホでは「親指領域」を優先、PCでは視線導線を優先
📘 補足：調査リンク貼付

伝える技術テンプレート

タイプ	伝え方	メリット
型で伝える	「私は◯◯→△△→□□の流れでやっています」	汎用化・真似しやすい
問いで伝える	「皆さんはこういうときどうしてますか？」	返答を引き出しやすい
定点で発信	「今週はこういう気づきがありました」	継続性・信頼性が出る