yigarashiのブログ

学んだことや考えていることを書きます

EMがユーザーインタビューをやって生まれたバリュー

わたしは現在、新規事業チームのEMをやっています。その仕事の中でユーザーインタビューが自分の得意技になりつつあり、思わぬ形でEMとしてのバリューを高めることができています。「XXもやるYY」というのはエンジニア界隈で良くある売り文句ですが、「ユーザーインタビューもやるEM」はあまり観測しないように思ったので、そのバリューについて書いてみようと思います。

ユーザーインタビューが得意技になるまで

ユーザーインタビューはUXリサーチにおける代表的な手法です。特にこの記事では、ユーザーの状況や課題を掘り下げるための半構造化インタビューを指すことにします。「1日の仕事の流れを教えてください」といった大まかな台本を用意しつつも、会話の中で得られた情報から「それが大変なのはなぜですか?」などと、自分たちの仮説検証に資する方向に柔軟に話を進めて情報収集するアクティビティです。

特にプロダクトの初期段階の不確実性に対するアプローチとしては随一で、週に5件、10件と回していくことも珍しくありません。我々のチームもご多聞に漏れずインタビューを回しまくっており、インタビュワーが重宝される状況でした。1on1や面接を通して傾聴スキルに覚えはありましたし、ユーザーインタビューを横で見る機会はそれなりにあったので、チームを助けるためにチャレンジすることにしました。

結果としては、自分のスキルをうまく転用できたのか、チームの仮説検証を前進させるインタビューを実施できました。掘り下げ方や会話のスムーズさ、得られる情報量など、インタビューの質に関してチームメンバーからポジティブなフィードバックが多く、どうやらかなり上手くやったようでした。その後もインタビューを重ね、別のチームでもインタビュースキルが機能することを確認し、自分の得意技と認識するに至りました。

生まれたバリュー

まずはチームとして「インタビューをうまくやれる」ということ自体が直接の大きなバリューです。仮説検証を前進させるための要なので、ここがうまくできるかでチームの成果は変わってきます。しかし、それだけではない間接的なバリューも多くありました。

成果の高いユーザーインタビューを行うには入念な準備が欠かせません。半構造化インタビューなので、単にスクリプトを工夫すれば良いわけではなく、仮説検証と相手の発言を紐づけてその場で引っかかる能力が必要です。「知りたいことがあって、そのために話を聞いている」ことを腹落ちしなければ得られない能力です。そのためには、チームがいま把握しているユーザーの状況や、チームが回している仮説検証の情報を自然と深く咀嚼することになります。

こうした活動を通して、PdMと対等に話せるレベルでユーザーと仮説検証を理解することになります。情報を共有してもらっているゲストではなく、自分も知識を運用してPdMと伴走できるようになります。新規事業は特に「何を作るか」が組織の成果を支配するので、そこに適切に働きかける能力は、誰であろうが持っているに越したことはありません。

また、顧客に実際に触れることで、どういう人にどういう意図で価値を届けるかを解像度高く把握できるので、PMFへの道のりがツーカーで通じるようになります。事業計画への助言やエンジニア組織の采配の精度も上がります。他の開発メンバーが、顧客のどういう知識を持っているとよりうまく判断できるかもよくわかるので、ディスカバリーとデリバリーを近づけるためのツボも前より理解できたように思います。

他業務への良い影響

もとは1on1や面接で培った傾聴スキルからユーザーインタビューに取り組んだわけですが、逆にユーザーインタビューを経験することで、他の業務の精度も上がったように思います。

最も見え方が変わったのは採用面接です。これは「相手が自社のカルチャーに馴染んで、成果を高めることに貢献するはずだ」という仮説を検証するインタビューに他なりません。これまでも工夫がなかったわけではないのですが、半構造化インタビューのノウハウを思わぬところで学んだことで、自分の中に信頼できる芯ができました。以前よりも、自分が特に集めるべき情報に腹落ちしながら、相手からうまく情報を引き出す問いを発することができるようになったと思います。

1on1においても、以前より一段と曖昧なキーワードや因果関係に敏感になることができ、相手の思考のリファクタリングをするきっかけを多く掴めているように思います。たとえば「すごく難しくて」という言葉を聞いて、掘れそうなポイントだな、何が難しいのかな、「すごく」って具体的にはどのくらいかな、そう思わせる要因は何かな、といった思考が浮かぶようになったのは、自分のキャリアにおいてありがたい贈り物だと思っています。

まとめ

この記事ではEMである自分がユーザーインタビューをやって生まれたバリューについて書きました。最初は自分がやる仕事なのかと懐疑的な部分もありましたが、プロダクトマネジメントに良い影響を与える能力を獲得し、EMとしても視座を上げることができました。また、インタビュースキルを転用できる採用面接や1on1においても良い影響を確認できました。今ではやって良かったなと思えています。

とはいえ、だからEMはみんなユーザーインタビューをやろう!という話ではないことに注意してください。EMへの期待は事業フェーズや組織ごとに異なります。ユーザーインタビューをするよりも組織の成果を高められる手段があればそれをやるべきです。私の場合は、新規事業という文脈においてユーザーインタビューがやるべきことに見えたというだけの話です。私がユーザーインタビューから得たバリューは他の手段でも得られるでしょう。

私が言いたいのはもうちょっと抽象的な話で、何がどう自分を助けるかは分からないので、やるべきことならなんでもやってみると良いんだろうなということです。組織の成果のために、コンテキストをよく観察し、自分を柔軟に変化させられるEMでありたいものです。

事業を深く理解しOODAループを回しまくる最近の自分のEM像に至るまで

はじめに

これまで自分のEMとしてのキャリアや考え方の変化について書き留めてきました。

前回の記事からおよそ8ヶ月。当時は想像もしなかった様々な経験をし、またひと回り成長できたと感じられるタイミングが来たので、内省を深める意味でも自分の近況をアウトプットしてみたいと思います。

EM"完全に理解した"

ここ半年ほどはとても苦しい期間でした。いわゆる"完全に理解した"(ダニング=クルーガー効果における最初の山)を越えたのか、何をやってもしっくりこない、うまくできている気がしないという感覚に苛まれました。EMは組織の成果を最大化するためにあらゆることをするエンジニア、そして主要な手札は一般的なマネージャー論や、広木大地さんが提唱する4象限、Engineering Management Triangleによって整理されている……そういう教科書的な理解はあっても、自分がうまくやれているという感覚には結びつきませんでした。自分を取り巻く状況も目まぐるしく変わり、慣れないプロダクトマネジメント領域に出張したり、新チームを立ち上げたり、その傍らさらに別のチームに参画したり、コンフォートゾーンから繰り返し飛び出したことも関係していたでしょう。

そうした大嵐を駆け抜け、今は少し自信がある状態に変化しました。少なくとも自分が置かれている変化の激しい環境において、どうすれば成果を大きくできるか、自分なりの考えを構築しつつあるように思います。その内容の普遍性や理論との対応はまだ十分に整理できておらず、状況が変われば的外れな主張になることもあると思いますが、まずは自分の言葉で書き進めてみようと思います。

事業を深く理解し貢献する

EMとして組織の成果を大きくし、組織の目標を達成するためには、事業の深い理解が重要だと腹落ちするようになりました。顧客の詳細な状況と課題、ソリューションの世界観と確度、仮説検証の計画、顧客の分類やリーチ状況、プロダクトと売り上げをいつ頃にどんな状態にしたいのか、それが誰の要請でどういったコミットメントになるのか、使えるリソースはどれほどなのか、リソースのコントロールは可能なのか……自分がいま届く事業の深い理解とはこういったものです。事業責任者と少しでも同じ景色を見て、少しでも同じ情報を使って思考をすることで、自分と組織の目標を一体化し、効果的な采配を自律的に生み出せる度合いが上がったように思います。開発チームはいつごろどんな能力を備えていたいか、このまま進んで組織は目標を達成できるのか、そういったことを上滑りせずに考えられるようになったと感じます。

こうした振る舞いを獲得するにあたって、プロダクトマネジメントに頭まで浸かる経験が非常に重要でした。ユーザーインタビューを通して顧客に会い、ソリューションをチームで考え、PdMと戦略を語り、寝ても覚めてもプロダクトのことを考え続けました。事業を理解している状態とはこういうことか!と感覚を掴み、その理解から発想される采配の精度の高さに手応えを感じることができました。また、プロダクトマネジメントを本気で自分ごとにできたおかげで、その領域の良書と言われる書籍群を深く読み込んで血肉にする機会も得ました。

いずれも現場リーダーとして遠巻きに事業を見ているだけでは得られなかった機会で、なんでもやってみるものだなと思わされた半年でした。

OODAループで変化を乗りこなす

ここ半年で、自分の振る舞いや判断が強く文脈に依存していることを自覚するようになりました。自分が何かをすべきと思っても、それはあくまで個人、組織、事業のその時の状況に基づいた判断であり、状況が変われば判断も更新するということです。情報が増えたらゴールを変える必要があるかもしれないし、プロダクトのフェーズが変われば取るべき手法も変わってきます。上に述べたプロダクトマネジメントに軸足を置いた振る舞いも同様に普遍的なものではないでしょう。チームマネジメントの観点ではSL理論やエラスティックリーダーシップなど、対象の状態に合わせて振る舞いを変えるやり方は鉄板です。

こうした変化への適応をうまくやるために、観察と更新を自分の中で仕組み化することにしました。まず手元のドキュメントに、自分が見ているチームと個人それぞれについて、どういう状態であるか、気にしていることは何か、自分はどう働きかけるかをまとめておきます。そして同様にチームと個人それぞれについて、週ごとに気づいたことをなんでも書き留めるコーナーを作ります。あとは毎週金曜の夕方に、書き留めておいた気づきを見ながら、それぞれの対象が目標を達成できるか、自分の気にするポイントや働きかけ方を変える必要があるかを考えて、最初にまとめておいた自分の認識・判断を更新します。

かれこれ2ヶ月ほど続けていますが、とてもうまく機能していると感じています。マネジメント対象が増えてきたので単純に情報整理としても良いですし、自分の振る舞いを高頻度に指差し確認することになるので、楽な方(自分の場合は細かく指示をするほう)に振る舞いが流れないよう意識しやすくなりました。自分の気になりごとや問いかけを磨く時間も増えたので、メンティーの行動変容につながる1on1も増えたように思います。目標達成に関する問いかけを軸にしているので、成果志向を忘れることもありません。ついでに事業計画など中長期スコープのフックも一緒に置くことで、様々な時間軸でマネジメント対象を考える時間を取れるようになりました。

このやり方を表す一般的な概念として、自分は「OODAループ」が一番しっくりきました。観察(Observe)、方向づけ(Orient)、決定(Decide)、実行(Act)のループで、変化が激しい環境に適応するために有効なモデルとされています。自分がやっているのは、観察を書き留め、自分の振る舞いの方向性を調整し、状況に合った働きかけを決め、実行に移す……まさにOODAループです。

おわりに - 優れたEMを目指して

Google re:Work - ガイド: 優れたマネージャーの要件を特定するにおいて、優れたマネージャーは組織の生産性と満足度を高めるとあり、自分はこの論を体現するひとりになれているだろうかとよく考えます。マネージャーは必要だと成果で語れる存在でありたいし、ここ半年ほどで自分に備わったスキルはそれに足るものであると信じています。まずは今の仕事を一層うまくやっていくのが自分の行動方針です。しかしさらにその先で、より広く、より深く働きかけるには、異なる状況での経験、より大きな絵を描く力、メンタリングスキル、システム思考、チェンジマネジメント、忍耐力などなど、まだまだ伸ばせるスキルがあるように思います。組織の成果を大きくする優れたEMを目指して頑張っていきます。

エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう

2024/1/4 加筆修正を行いました

初稿を書いた後に、さらなる経験、色々な方との対話、各種資料を通じて考え方が更新された部分があったので加筆修正を行いました。主要なポイントは以下です。

  • 仕様案の手戻りが発生しないようにエンジニアに積極的に情報を開示していくのはPOの重要なプラクティスであると分かったので、その考え方に沿って整理しなおしました
  • POになりたてのいわゆるパニックゾーンにいる時に書いた文章で、全体的にエンジニアに責任を転嫁するニュアンスになっていたので修正しました

プロダクト開発のアンチパターン

プロダクトオーナー(PO)が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。

ひとつは、単純に不確実性を下げる手続きとして効率が悪いからです。そもそも、どうしてシステムの制約や可能性を十分に把握せずに仕様が作れましょうか。技術的に何ができるのかは、仕様を考える上であまりにもインパクトが大きい変数です。それを考慮せずに仕様案を作ること自体が筋が悪いと言えるでしょう。

もうひとつには、こうした状況に陥ってしまった時のPOのダメージが著しく大きいからです。そもそも仕様案を作るのはとても大変な仕事です。プロダクトのミッション、戦略、プロダクトゴール、ユーザーの課題、仮説検証の設計、MVPの特定、そういった大上段からのヘビーな分解を繰り返し辻褄を合わせる膨大な情報処理を行うことで、ようやく筋の通った仕様案に辿り着くのです。そうして血の滲むような工程を経て捻り出したアウトプットがエンジニアのひと声で差し戻されると、口から魂が抜けるような思いを味わいます。これをPOの段取りが悪いと一蹴するのは簡単ですが、あまりにPOの負担が大きくないかとも思うのです。

アンチパターンを終わりにする

このアンチパターンを終わりにするためには、もっと前段でエンジニアが議論に参加してフォローしていく世界観が理想だと考えます。POの負担はこれでかなり減ります。単純にPOがひとりでフルスイングし続ける範囲が減ることで、よりアウトカムへのインパクトが大きい部分に思考リソースを割くことができます。最初から技術的な前提を組み込んで議論することで、不確実性を効率良く下げていくことができるので、手戻りによる工数面と精神面のダメージも大幅に減少することになります。

こうした理想の世界に辿り着くには、少なくともふたつの要素が必要だと考えます。

ひとつはチームで不確実性に対処する能力です。POの能力には限界があり、常に明瞭な期待と質の良い提案をできるとは限りません。程度の差はあれそこには常に不確実性が存在します。エンジニアが、曖昧だから、実現できないからといってそれを差し戻していては状況が改善しません。ゴールに納得できるまで話を聞き出す、ゴールに沿って仕様の詳細を埋めたり、実現可能な別の仕様を提案したり、不確実性を自ら下げていくアプローチこそがプロダクト開発を前進させます。このように不確実性の高い抽象的な期待に応えられることは、多くの組織に普遍的なハイグレードエンジニアの要件でもあるでしょう。

もうひとつはPOが早期にエンジニアを議論に巻き込む努力です。ユーザーの課題やプロダクトの目標に日常的に触れて考えてもらうことが重要になります。他のメンバーを信頼し、自己組織化されたチームとして成長できるよう、自らが抱える課題やアイディアを積極的にオープンにしなければいけません。また、自分と同じ目線で思考して前向きな提案ができる、いわゆる「右腕」のようなエンジニアを見つけて頼るのも有効な手段でしょう。

OpenTelemetryをざっくり学んだ

OpenTelemetryについての情報を見聞きする頻度がどんどん上がっており、各種サーバー監視サービスやクラウドでも対応が進んでいることから、そろそろ自分の引き出しに入れたいと感じました。概要を自分で説明できるくらいを目指してざっくり学んだログを自分用に残します。

OpenTelemetryとは

opentelemetry.io

公式トップページにある以下が全てを物語っているとは思います。メトリック、ログ、トレースはお馴染みのObservability三銃士ですね。

OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.

加えて以下の特徴も重要だろうと思います。

Open Source, Vendor Neutral

OpenTelemetryの特徴的な用語・概念

個別の気になった話題

OpenTelemetry Logs

OpenTelemetry Logging | OpenTelemetry

他のテレメトリーとの相互連携が推されているのが面白いと思いました。TraceIdやSpanIdがしっかりログのデータモデルの仕様に含まれています。このあたりのテレメトリーの融合によるo11yの改善は、テレメトリーデータを受け取って可視化するバックエンドサービスの頑張りにもだいぶ左右されるように感じました。面白いサービス、機能がたくさん出てくると良いですね。

OpenTelemetry Metrics

OpenTelemetry Metrics | OpenTelemetry

各ポイントのデータにラベルをつけられるのが面白いと思いました。production/staging、ホスト、サービス、ユーザーごとなど、さまざまな属性をつけて柔軟に可視化する未来が容易に想像できます。

また、MeterProvider、Meter、Instrumentとプログラミングモデルが定義されているのも面白いです。実際アプリケーションで処理の回数を数えたり、何かしら自前でメトリックを吐きたいと思ったとき、どこにデータを記憶しておくか、数字を積み上げるのかなど、微妙に考えることが多くて困った記憶があります。それらをSDKが提供するAPIでレールに載って書けて、勝手にOpenTelemetryに対応した形式にしてくれるのは魅力的に見えます。

Host Metrics Receiver

ここまでの情報を集めたときに、現状よくあるサーバー監視ツールのエージェントがやっているような、ホストメトリックはどう扱われるのか気になりました。OTLCにOTLPでデータを投げつけるとしたら、なんらか別にエージェントを立てる必要があるのか?といったことを疑問に思ったのです。

結論としてはOTLCのreceiverとして実装されていました。

github.com

つまりOTLPはOTLCのデータソースのひとつに過ぎず、Host Metric ReceiverのようにOTLCのreceiverもプラグイン形式で拡張できるということです。exporterが拡張可能なのは直感的に理解できますが、receiverも拡張できるのは個人的に面白いポイントでした(receiverと言いつつ自分でデータを取りに行っているわけなので……)。

リポジトリを流し読みしていたところOTLCの設定ファイルから最小セットのバイナリを生成するツールも発見しました。面白いですね。

プロファイル

OpenTelemetry Meetup 2023-10 - connpassの発表資料をいくつか拝見したところ、第4のテレメトリーとしてプロファイリングの追加も進んでいるという話を見かけました。トレースをさらにドリルダウンして、関数ごとの実行回数やCPU時間、メモリ消費量などを見られるのは、確かに正当進化という印象を受けます。

以下の発表資料の37枚目では「継続的プロファイリング」というワードも登場しており非常にワクワクしました。プロファイリングといえばパフォーマンスに問題があるときに満を持して有効化するものという認識でしたが、その常識が変わり、常にプロファイリングするのが当たり前の未来が来るかもしれないということですね。 speakerdeck.com

まとめ

OpenTelemetryについてざっくり学んだ様子をまとめました。システムの開発運用が大きく改善するのを期待できるプロジェクトという印象で、自分の中でも重要なトピックのひとつに位置付けらました。今回の学びをベースに情報収集・実践を続けていきます。

パスキーが快適すぎる

パスワードレスな認証方式である「パスキー」が急速に普及しています。OS、ブラウザ、パスワード管理ツール、サービス提供者のどれもが整いつつあり、ついに本当にパスワードが必要ない世界がやってきたことを感じます。この記事では、本腰を入れてパスキーを使い始めて快適になるまでの様子をまとめます。技術的な厳密さ・網羅性には踏み込まず、いちユーザーとしての入門記事という位置付けです。

パスキーとは

パスキー - Wikipedia

認証、セキュリティに関しては門外漢なので、Wikipediaのリンクを置いておきます。私よりはWikipediaのほうが信用に足るでしょう。

そこから辿れるホワイトペーパー:マルチデバイス対応FIDO認証資格情報を読むと、多少ストーリーもわかります。FIDO2というデバイスに格納された秘密鍵に依存したパスワードレス認証の仕様に、暗号鍵(と訳されていますが秘密鍵のことで良い……?)をデバイス間で共有できる仕組みが組み合わさったことで利便性が向上し、最近の急速な普及に繋がったということのようです。これまでパス"ワード"を保存して認証していたのを、暗号鍵(キー)を保存して認証するようになるのでパス"キー"ということなのでしょう。

実際に使い始めた様子

基本的に普段使いのiPhoneでパスキーの登録を行い、そのパスキーを1Passwordに保存する形を取りました。1Passwordに保存した方がプラットフォームへの依存性が低く、保存したパスキーを異なる環境から使いやすいだろうと判断しました。各サービスで「パスキーを登録する」を押してからのナビゲーションは大変わかりやすく、まず詰まることはないように思いました。

手始めによく使う以下のサービスでパスキーを有効にしました。

使い始めるにあたって気になった点

事前に「ここがうまくいくと良いな」と思った点がどうなったか列挙します。結論から言うと全てうまくいくようになっていて、非常によくできた仕様・実装だと感じました。

パスキーの保存先や利用するパスキーを明快に選べるか?

パスワード時代にはiCloud Keychainや1Passwordの保存ダイアログが次々に表示されて、とりあえず両方に保存してみたりと、なんだか妙に体験が悪い印象が脳裏にこびりついてます。

どうなったか

iOSではパスキー登録時に保存先を選ぶ明快なモーダルが表示されました。同様に利用時もどのパスキーを使うか快適に選ぶことができます。とにかく体験が良くて嬉しくなったポイントです。

保存したパスキーは別のデバイスで認証なしに使えるのか?

たとえばiPhoneで登録したパスキーをMacChromeで使うといったパターンが想定されました。デバイスを紛失した場合に締め出されないか、という観点でも重要です。仕様をよく知っていれば当たり前なのかもしれませんが、自分にとっては非自明なポイントでした。

どうなったか

iPhoneで1Passwordに保存したパスキーをMacChromeで認証なしに利用できました。ブラウザでパスキーによるログインを選択すると1Passwordがダイアログを出してきて、「Sign in」をクリックするだけでログインが完了しました。非常に良い体験です。

保存したパスキーにアクセスできない環境でログインできるか?

たとえば1PasswordやiCloud Keychainが使えない環境でログインしたいことはあるかもしれません。その場合にパスキーを登録したデバイスからしかログインできないとなると不便です。

どうなったか

bluetooth経由でスマートフォン等を認証器として使う手段が案内されるためログインすることができました。わたしが触った範囲ではQRコードを読み取る手順が案内されました。マルチデバイス対応FIDO認証資格情報のホワイトペーパーにも当該の記述があるため正式な仕様のようです。フィッシング対策を意図した仕様のようで、ここで書いたようなメリットを感じているのは正しいのかという疑問は残りますが、なんにせよ良くできた仕様です。

複数のデバイスからパスキーを登録できるのか?

自分は1Passwordのアカウントが仕事とプライベートで分かれています。GitHubなどで、仕事用のMacのパスキーと普段使いのiPhoneのパスキーを別々で登録できると楽なケースが存在するのでした。

どうなったか

私が触ったサービスはどれも複数のデバイスを管理するUIがあり、複数のデバイスからパスキーを登録できました。

既存のパスワードと共存できるか?

いくら有望とはいえ、まだ新しい技術ではあります。一応パスワードによるログイン手段は残しておきたいと考えていました。

どうなったか

1Passwordでは別のアイテムとして保存が可能でした(パスワードを上書きすることもできます)。しばらく運用を続けて問題ないと自信を持てたタイミングでパスワードを消していこうと思います。

まとめ

パスワードレスな認証方式であるパスキーが急速に普及しています。利便性と安全性を両立した優れた仕様で、対応しているサービスもどんどん増えています。私が触れた範囲ではOSやパスワード管理ツールの実装も非常によくできており、もうパスワードには戻りたくないと思わされています。どんどん移行していきましょう。