yigarashiのブログ

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

事業を深く理解し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やパスワード管理ツールの実装も非常によくできており、もうパスワードには戻りたくないと思わされています。どんどん移行していきましょう。

「 ITエンジニア採用入門」を読んで採用活動の全体像を学ぶ

最近エンジニア採用に関わる機会が増えました。エンジニアリングマネージャーとして、採用プロセス全体を機能させチームを組成する能力を獲得したいと考えており、その足掛かりとして面接官の役割を積極的にアサインしてもらっています。それなりの件数をこなして学ぶ土台ができてきた感触があるので、このあたりでエンジニア採用の全体像を学ぼうと考えました。

採用に関する書籍は数多くあり、どれを自分の教科書とするか迷いましたが、以前見つけてブックマークしていたITエンジニア採用入門がよさそうに見えました。自分が関わる採用市場とかなり近い文脈で、具体的な情報がエンジニアの目線から簡潔にまとめられています。全体像を学びたい自分にうってつけの資料です。これが無料で読めるのは本当にありがたいことで著者の方には頭が上がりません。

主要な学び

EVPとアトラク

ITエンジニアの採用は競争が激しく、採用プロセス全体を通して「自社を選んでもらう」ことが重要になります。そのために自社特有の価値(EVP, Employy Value Proposition)をよく整理し伝えることが重要です。また、候補者の動機づけ要因や衛生要因をよく把握し、そこと自社のマッチングの様子を真摯に伝えることも重要になります。自分はこれまでハードスキルとソフトスキルを掘り下げることにフォーカスしすぎており、こうした部分が疎かであったと感じます。マッチングやアトラクトに関する部分を選考の後ろの方にまとめ、選考結果に影響しないことを明示してリラックスして実施するテクニックも紹介されており、これはぜひ実践してみたいと思いました。

採用プロセスを改善する時の考え方

今回のインプットで、採用改善の大きな前提として採用計画が存在することを強く認識しました。際限なくスループットを上げて多くの人を採用するのが必ずしも良いわけではなく、あくまで事業計画とセットで考えるべきだということです。とはいえ競争の激しさを考えると、採用数の目標を達成するのが簡単ということは滅多にない気もしますが、とにかく採用計画ありきで、量的な改善なのか、質的な改善なのか、いまどれくらいの頑張りが必要なのかといったことを考えるのが良いだろうと認識しました。

また質と量のバランスについても特徴があるように感じました。組織もプロダクトも人が形作るもので、採用においては質の面での妥協が致命傷になりかねません。本当に来て欲しい人に来てもらえるハイクオリティな採用活動を維持しつつ、徐々にスループットを上げていくような、丁寧な改善活動が重要と思います。

エンジニア組織の活動に対する解像度の向上

採用広報の観点で、エンジニア組織がどういった活動をするかは非常に重要になります。エンジニアブログや、セミナー、登壇時の費用補助などさまざまな施策が自社に存在することは知っていましたが、採用への解像度が上がることで、それらの活動に対する解像度も上がったように感じます。たとえば、採用したいペルソナから逆算して、いま組織から足りていないのはどういう種類の発信かといった切り口で考えられるようになりました。もちろん種々の活動の目的は採用だけではないので、広い視野で考えることが前提となりますが、長期目線でどういう力学を作っていくのかを考えるきっかけにはなりそうです。

まとめ

「 ITエンジニア採用入門」を読んで得た主要な学びを整理しました。本記事では特に自分の思考が広がった部分について書きましたが、他にもエンジニア採用に関する基礎的な情報を多く手に入れることができました。1、2時間ほどで読める資料なので、採用に関わるエンジニアはぜひ一度読むことをオススメします。