Lavieleaf

おもったことをなんでも書くことろ

EM の仕事もデザインすることかも


はじめに

デザインリサーチの教科書の木浦さんのセッションを聞いて、「デザイン」という言葉の射程について見方が変わった。 デザインというと UI や椅子のような有形物を思い浮かべていたが、本質は「誰かの目的を達成するために形を与えること」であって、対象が有形である必要はない。

そう考えると、EM としての自分の仕事のうち、期初のミッション設定も立派なデザインだと思う(当たり前かもしれないが)。

これまでは、アウトカムが何かを考え、定性・定量の成果をどう設定するかに意識が向いていた。 それが型を知って、どこがどう良くて、どこが弱いのかを根拠付きで言えるようになったのでその見方の変化を残しておく。

デザインは目的がないと良し悪しが語れない

  • Wassily Chair: 工業生産に適した素材・構造で、より多くの人に椅子を届ける。
  • Egg Chair: 長旅を経てホテルに着いた人が、公共スペースの中でプライベートにくつろげる。

同じ椅子でも目的が違えば評価軸が違う。良し悪しはデザインの中ではなく、目的との距離にある。 だから目的を置き去りにしたまま「良いミッション」を単体で語ろうとすると EM の決めの問題になる。

デザインの型

型はシンプルで、成果物に対して次の 5 つを問う。

  • ユーザ: 誰のための成果物か
  • 属性: 年齢、職業、役割、利用頻度
  • 文脈: 初めて使う、急いでいる、失敗できない、など
  • 目的: ユーザの動詞で何を達成するか(提供側の要求は目的ではなく文脈に置く)
  • 評価: 定性(インタビュー、観察)・定量(ログ分析、AB テスト)でどう観測するか

この型に「有形であること」はどこにも出てこない。 だから SLI/SLO 定義のファシリテーションも、障害対応フローも、期初ミッション設定も、どれも同じ型で問える。

ミッション設定に型を当ててみる

前提として、「やっただけでは評価されない。成果は外部に存在する」という評価思想がある。 だからどのミッションにも、定量か定性の評価が必ず紐づくようにしている。

例として、SRE メンバー(在籍 3 年、プロダクト貢献の手触り感がほしい)の 2026 年ミッションに型を当ててみる。

現在取得できていない、本来必要なメトリクスを明らかにし、取得を実現する。可観測性を高めた結果の改善事例を 1 件以上つくり、知見として共有する。

こんな感じで毎回、定性・定量を意識して考えている。でも型を当てると、弱いところが理由付きで浮かんでくる。

  • ユーザが書かれていない → メトリクスを見て判断する開発エンジニア
  • 「本来必要」の根拠がない → ユーザの目的(CUJ の健全性を判断したい)を定義して初めて「本来」が決まる
  • 「共有する」はアウトプットであってアウトカムではない → 観測すべきは、受け取った開発者の判断・行動が変わったか。定性で見るなら「誰に何の変化を聞くか」を期初に決める
  • 改善事例 1 件は本人の目的(手触り感)に合っている → SRE の外部変化を、直接ユーザ(開発者)の行動変化に置く。因果の距離が短いことが手触り感になる

これでどこが強くてどこが弱いかを根拠付きで言えるようになったこと。 デザインするというのは、判断の再現性と説明可能性を持たせることなのかもしれない。

デザインはフラクタル構造になってる

ここまではメンバーのミッションに型を当てた話だが、ひとつ上の階層を見ると、そのミッションを設定している自分の仕事もまたデザインで、 ユーザはメンバーで、目的は「メンバーが期末に外部の成果を自ら指し示せること」、評価は「メンバーが自分のユーザを言語化できたか」。

さらにメンバーの中では、開発者に向けて SLI/SLO をデザインして、開発者はエンドユーザに価値を届ける。 同じ型が各レイヤーで再帰していて、上位のデザインの良し悪しは下位で良いデザインが生まれたかで測る。

flowchart LR
    A["EM のデザイン\nユーザ:メンバー\n良さ:メンバーが自分のユーザを言語化できたか"]
    B["メンバーのデザイン\nユーザ:開発エンジニア\n良さ:改善事例と開発者の行動変化"]
    C["開発者のデザイン\nユーザ:エンドユーザ\n良さ:実際に届いた価値"]
    A -->|同じ型| B
    B -->|同じ型| C

    style A fill:#1971c2,color:#fff,stroke:none
    style B fill:#0c8599,color:#fff,stroke:none
    style C fill:#2f9e44,color:#fff,stroke:none

だからメンバーにも同じデザインの型を渡したい。 自分の成果物のユーザは誰か、文脈は何か、目的をユーザの動詞で言えるか、外部の変化をどう観測するか。

さいごに

正直、ピープルマネジメントがデザインだなんて当たり前のことを言っている気もする。

ただ自分にとっては、「成果を意識したミッション」が「どこがどう良いか説明できるミッション」に変わった。 再現性を持たせることがデザインなのだとしたら、マネジメントも、手を動かす IC も、同じようにデザインしているのかもしれない。

参考文献

  • 木浦幹雄『デザインリサーチの教科書』(BNN, 2020)