スプリントをやめてゴールに熱中したっていい

最近、自分のチームがやっていて良いなーと思う開発プロセスを紹介します。そのチームにはスクラムで言うところのスプリントがありません。ふりかえりや定点観測のために定例イベントはありますが、そこに向けて何かを計画したり約束することはありません。チームが目指すのはただひたすらに「次のゴール」です。プロダクトの次のフェーズを実現するとか、ある仮説の検証を完了するとか、大きな目標から逆算してマイルストーンを設定して、そこに向けて計画と約束をします。スコープが先にあって締切を決めることもあるし、締切が先にあってスコープを調整することもあります。チームに必要な成果に沿ってリファインメントや計画を進めて、最終的にチームみんなで達成の自信があることを確認して開発を始めます。

このやり方の良いところは、圧倒的にゴール意識が強まるところです。意味的な強度が高いまとまりで開発のフェーズを切ることができるので、次はここを目指すんだぞ！というのが非常にわかりやすいです。締切とスコープの両方を自分たちでコントロールすることで、そこに対する納得感やコミットメントも強まります。スプリントがあると、どうしてもその枠に収めることが優先されてしまって、良いゴールを設定するのが難しいと感じることが多かったのですが、いっそスプリントをやめてゴールのことだけ考えるようにしてみると、これが意外と気持ちよく回るなという感じでした。スクラムの基本から外れることで、逆に確約、集中といった価値基準が強化されているのも面白い体験です。

一方でこのやり方がうまくハマるのは、プロダクトの初期フェーズであることが関係しているようにも思います。やることをコンパクトにまとめやすく、意味のあるゴールを2週間程度で達成できるからこそ、スプリントというタイムボックスをやめても高頻度の検査と適応が実現できています。これが、たとえばどうやってもアウトカムになるには3か月必要であるとか、取り組む仕事が多様になってまとめづらいとか、そういった話が出てくると、スプリントのリズムを復活させたほうが良いかもしれません。

EM of EMsになった - 現在の働き方とそこに至るキャリア戦略

EMキャリアの近況報告シリーズです。2024/4にEM of EMsになったので、現在の働き方やそこに至るキャリア戦略について書きます。これまでの様子は以下です。

• エンジニアリングマネージャーを目指す若者の戦略
• EMキャリアを切り拓く「最強の現場リーダー」という働き方
• エンジニアリングマネージャーの最初の学び - このロールは何なのか
• 事業を深く理解しOODAループを回しまくる最近の自分のEM像に至るまで

現在の働き方

私が所属する株式会社はてなでは、いくつかの事業からなる事業本部を組織しています。自分はこの事業本部付きのEMにあたります。事業責任者と横並びになる形で、エンジニアリングで本部全体に貢献する責任を負っています。EM of EMsとは言ったものの、実はまだ各事業にEMはいなくて難しいところなのですが、大半のマネジメント能力が完結している各事業を外から支援する形なので、抽象度としてはEM of EMsと言って差し支えないでしょう。前任者もEM of EMsを名乗っていたので問題ないはずです。

本部を分解すると各事業になるので、基本的にはそこがうまく回るように動きます。EMの4象限のうちプロダクト・テクノロジー・デリバリーは各チームのリーダー陣が引っ張ってくれるので、その人たちの成果が大きくなるよう働きかけつつ、残るピープルマネジメントの大部分を引き受けています。自分のスパンオブコントロールはしっかり超えているので、EMの育成を急ぎ進めているところです。より間接的なアプローチになるので、情報収集や距離感にはしっかり苦戦しています。

また、そうしたプロダクト開発のマネジメントだけでなく、P/Lや事業計画といった経営との接続にもエンジニアリングの側面はあり、そこの情報提供や説明責任も自分の仕事です。インフラ費用や見積もりといった情報が、適切なタイミングに適切な精度で各チームから出てくるよう働きかけたり、事業戦略、人件費、組織の能力、育成等を踏まえて増減員を提案したりします。そこで関わるのは、会社のお金を預かって数字に徹底的にコミットする事業責任者たち、そして経営陣です。その環境で見劣りしない仕事をできているかは常に気にしています。

加えて、本部単位の組織戦略やビジョンを打ち出す活動もしています。直近では、事業から逆算してインパクトを出せるエンジニアを増やすべく「事業を成長させる組織」というビジョンを発信しています。そこからブレークダウンする形で、事業計画をなるべくオープンにして巻き込んだり、エンジニアの育成に事業責任者の目線を入れたり、いろいろ打ち手を試みています。事業と組織のシナジーを生み出しながらストーリーを構築していく仕事は非常に面白いです。

全社の技術グループにおいてもチーフエンジニアという肩書にはなっており、書類選考や面接など採用に関わる仕事を定常的に行っています。

そこに至るキャリア戦略

もともとは1チームのEMをやっていて、それはそれで面白かったのですが、もう少し抽象度の高いレイヤーで考える方が面白そうだなと思うようになりました。プロダクト開発にしても、具体的な仕様や作り方よりも、戦略としての位置付けのほうが面白いといった具合です。社会人キャリアの中でも言語化や抽象化を評価されることが多く、扱う情報の抽象度を上げることは自分の能力にマッチしていそうです。やってみたい、ワクワクする、今よりバリューを出せる、といった思いが自然と湧きました。そんなわけで本部EMを目指そうと考えました。

まずは自分の持っている仕事や役割を整理して、もとのチームのマネジメントをしながら隣のチームのヘルプに行くことにしました。ちょうど手が足りず困っていて、どうにかならないかと相談されていたのでした。ヘルプ先のチームでは最初はバリバリ実装をする想定だったのですが、結局チームの目標整理やファシリテーションのバリューが上がってきて、EMとして振る舞うことになりました。そのチームには自分の倍近いキャリアのベテランが複数人いて、最初は戦々恐々としていました。しかし仕事をしていくにつれて、働きぶりを称賛してもらったり、「マネジメントをちゃんとやるってこういうことなんだ」と声をかけてもらったり、EMとしてちゃんと成果が出ている実感を得られるようになりました。彼らと一緒にいてもなお自分のマネジメントスキルが重宝されたという事実は今でも自信の源になっています。結果として複数チームをマネジメントすることになり、マネジメントのスコープがチームから事業へと広がりました。

最初のラダーを登ってひと息ついたところで、本部EMになるにはどうしたら良いだろうと考えました。数人チームでお試しでリーダーになるのとはワケが違います。どうしようかと困っていたところ、偶然TwitterでLayerXの@makoga(小賀昌法)さんに雑談のお誘いをいただきました。小賀さんと情報交換する中で、「事業や組織の具体的な未来像を考えて、そこに向けて採用や育成に取り組んでいる」という旨の話を聞きました。そこで私はピンときました。本部EMに求められるのは、まさに事業や組織の未来の姿を描きそこに向けた手を打てることです。であれば、自分が本部EMになった場合の組織の未来像を提案し、具体的な道筋を示すのが最初の一歩だと考えました。各チームの人員計画、自分を抜擢するメリット、全社状況から見た現本部EMの次のチャレンジなど、自分を本部EMに異動するのに必要なロジックを積み上げて、当時本部EMだったid:taraoさんに共有しました。

結果は合格も合格で、1年ほどかけて組織を変化させる想定だったはずが、提案から1ヶ月もしないうちにid:taraoさんから退職の意向を聞くことになりました。僕が追い出したとかそういうネガティブな話でないことは転職エントリを見ていただければ分かるのですが、まあ色々と噛み合って、4月の半ばから本部EMをやることになりました。準備する間もなく変化を迎えたのはかなり大変でしたが、5年間お世話になった先輩からの最後の課題（ギフト）として精一杯取り組みました。これは皮肉でもなんでもなく、急ピッチで本部EMの仕事を身につけるこの2ヶ月は、自分の仕事人生史上で最も充実した楽しい期間になりました。無事なんとかなって元気にやっています。

これからについて

これまで目まぐるしくキャリアを駆け上ってきましたが、流石にスピードが鈍化するタイミングだろうなと思います。自分がコミットする時間軸が半年〜3年という非常に長いものになりました。もちろん目の前の緊急度の高い課題もあるのですが、最終的に事業と組織の成長として返ってくるにはどうしても時間がかかります。望んで今の職務を得たからには、組織にもたらした成果を確認するまでは続けるのが筋だろうと思います。

また、最近発売した「エレガントパズル」の4章にあるように、職位や影響する人数は仕事の違いに過ぎないことを胸に刻む必要があるでしょう。もちろん素朴にVPoE、執行役員という形でキャリアラダーの上を見据えることもできるでしょうし、それは十分すぎるくらいにチャレンジングな目標になるはずです。一方で、複雑でインパクトの大きい課題にアプローチできているか、コンフォートゾーンを出られているかという視点も大事そうです。今の仕事を楽しみながら、少しずつ次のことを考えようと思います。

そして今回の異動で、ついに自分の仕事がマネジメント100%になりました。移行期間から数えてもう3ヶ月ほどコードを書いていません。そして困ったことに(?)マネジメントが楽し過ぎて、プレイヤーに戻りたくないという思いも抱いています。このまま突き進んでEMとして行き詰まることはないのか、ありがちな不安は付きまとうわけです。この件を同僚のEMであるid:daiksyさんに相談したところ、「でもマネージャーを極めるだけで全然時間足りないですよね」と核心を突かれてしまいました。非常に共感するところで、最近は徐々に腹が決まってきています。マネージャーという働き方を徹底的に追究する方が楽しそうな気がするので、プレイヤーとしての帰還不能点といった話は忘れて、行けるところまで行ってみるか！という感じです。

また大きな変化があれば記事を書きます。

「真摯な質問」のコツを知って誘導質問しない信頼できるマネージャーになる

「真摯な質問」は対話の基礎を成す重要な要素です。「組織を変える5つの対話（p.41）」では、真摯な質問の特徴を次のように挙げています。

本当に答えを知りたい。

答えを聞いて驚くことがあってもそれは当然である。

答えに応じて自分の考えや行動を変えることをいとわない。

つまり純粋に新しい情報を求める意図のみで行われる質問のことです。裏表のない創造的な対話が相手の自律性を引き出します。マネージャーとして同僚の力を引き出すための強力な武器であると考えています。本書では続けて、真摯ではない質問についても述べています。

それとは対照的に、真摯ではない質問は何か新しいことを学ぶよりも自分の主張をするために使われます。本当は意見の表明であるのを隠していたり、自分の思い通りの結論に相手を導こうとしていたりするのです。

しかし、こうした質問が悪意から来るとは限りません。自分が望んだ結果を得ようと無意識に発せられることもあるでしょう。また、コーチングの文脈においては自分で気づくことの価値が繰り返し語られています。時には「答えを知っているけどあえて質問する」という振る舞いをすることになるかもしれません。そこで誘導質問を避けるのはかなりのテクニックが必要です。たまにある1on1や傾聴スキルが嫌いであるという話題は、こういうところに原因の一端があるのではないかと思います。相手が何か思惑を持って、答えを隠して自分を試そうとしているのは気持ち悪いものです。私自身ここがうまくできず、同僚とぎこちない会話をしてしまうことがありました。

しかし今ではこうした質問に自覚的になり回避できることが多くなりました。実りのある会話ができていると感じるシーンが増えていて、マネージャーという仕事の楽しさが増しています。以下ではいくつかのコツを紹介します。

コツ(1): ティーチング

まず相手の状況や課題が一般的な概念や典型的なプラクティスなど、普遍性の高い情報で説明できると思う時は、ティーチングに切り替えてそれを教えます。まずはそれを知っているか相手に聞くところから始めると丁寧でしょう。その上で、「いまの説明を聞いてどう思いましたか」「いまの状況に適用して考えてみるとどうなりますか」といった質問をします。相手に伝わっているかどうか、意味のある回答になったかどうかを確かめる質問になっており、自然と真摯な質問ができています。下手に遠回りするよりも建設的で安全な対話をできているはずです。

コツ(2): 期待の伝達

自分がリーダーやマネージャーとして、明確にやって欲しいこと、期待する振る舞いがある時は、それは遠回りせずにはっきりと伝えます。誘導するような質問をして勝手に相手に失望するのが一番良くありません。その上で、期待に応えられそうか、障害物がないかといったことを聞きます。これも真摯な質問になっています。

コツ(3) 相手の脳内について聞く

相手の脳内、つまり感じたことや考えていたことは、どこかに書き出されていない限りは未知の情報です。たとえば直近の仕事を題材に話すようなケースでは、何をしたか、どういう結果になったかといったことは知っていたとしても、「なぜそうしようと思ったか」「結果に満足しているか」といった相手の脳内の情報は知らないことが多いでしょう。そういった真摯な質問をできる部分を見つけて対話を進めることで、よいふりかえりの機会を作ることができます。

コツ(4): 自己マスタリー

「学習する組織」において、自己マスタリーというあり様が説明されています。組織が望んだ結果を得る能力を磨き続けるために必要な要素とされています。重厚な内容でひとことで説明するのは難しいのですが、ひとつの特徴として、自分が見ているのは現実の一側面であると認めて客観的な見方を探究し続ける姿勢があります。真摯な質問はこの姿勢の先にあるものだと思います。自分の結論はどこまで行っても完全ではないと信じられるようになった時、「今のを聞いてどう思いましたか」という心からの質問をできるようになると思っています。

コツ(5): 本当に知らない状況を作る

真摯な質問をする一番シンプルなコツは答えを知らないことです。マイクロマネジメントを避け、同僚の細かい状況を知りすぎないようにしておくことで、逆に対話の質が向上するケースがあるように思います。何をしたのか、なぜそうしたのか、それについてどう思っているのか、知らないからこそ真摯に一気通貫のストーリーを聞いていけるわけです。ストーリー全体を一緒に辿ることで、内省の機会としてもよく機能します。当事者ではない方がうまくコーチングができるというのは、こういうところから来るのかもしれません。

以上、5つのコツを紹介しました。真摯な質問を使って、信頼できるマネージャーを目指していきましょう。

経験学習のために「ブログ記事のネタ30個出す」が予想以上に良かった

経験学習サイクルとは、人の学習のモデルのひとつで、「経験」「内省」「概念化」「実践」の4ステップを繰り返して学ぶというものです。本記事では、「ブログ記事のネタを30個出す」というアクティビティが予想以上に経験学習に有用で面白い体験につながったので、その様子について書こうと思います。

4月にチームのEMから複数事業をまとめる本部付きのEMへとロールが代わり、怒涛の勢いで新しい経験を積んできました。経験学習サイクルで言うところの「経験」の部分を超高密度でやってきた状態です。そうは言ったものの、以前から抽象度の高いマネジメント手法も知識としては触れていましたし、「学習する組織」「Fearless Change」「組織を変える5つの対話」あたりを新たにインプットして取り組んだという点では、「経験」の前の「実践」からスタートしたと言えるかもしれません。まあとにかく、可能な範囲でインプットをして、目の前の仕事に全力で取り組んだということです。自分としては上手くやれたと感じる部分が多かったのですが、いかんせん組織の具体的な状況や課題にかかりっきりで、自分の経験を「内省」や「概念化」のステップに進めることができていませんでした。うまくいっているが、それを言語化しきれていないもどかしい状態です。ブログ等のアウトプットも滞っており、せっかく良い経験をしているのにプレゼンスの向上に活かせていない点も気になっていました。4月にチーフエンジニアを拝命して、社のEMの顔のひとりとして社外でも存在感を発揮していく期待があるわけなので、頑張っていかなければなりません。

つまり、自身の経験学習に関する課題と、アウトプットに関する課題がそれぞれある状態でした。これらを同時に解決するアイディアとして「ブログのネタを30個出す」という脳筋なアクティビティを思いついたのでやってみたところ、予想以上に良い体験をしました。これが今日の本題です。ブログのネタを出すためには、まずは自分の仕事ぶりを思い出す必要があります。日々やっていることや上手くいったことをふりかえり、学びとしていいネタになるものはないかと探して回ります。これが経験学習サイクルの「内省」になります。さらにネタとして昇華するためには、仕事の内情や経緯を事細かに書くわけにもいきませんから、実業務の文脈を弱めて一般化した学びにする必要があります。都合の良いことに、これが経験学習サイクルの「概念化」になります。そして30個という無茶な数字にしたのも良い点でした。15個を過ぎたあたりから苦しくなってきて、自分の経験を何度も何度も精査して問いを発することになりました。ふりかえり自体が目的だとこんなに根気良くふりかえるのは難しいのですが、ネタを探すという目的があることで自然と深めることができました。

結果として、自分の学びを程よく概念化したネタを30個捻り出すことに成功しました。この記事もそのネタのひとつです。流石に30記事全部書いてやろうという元気はないですが、30個も出すと上位7〜8件の質がかなり高いので、熱が冷めない内にどんどん書いていきたいと思います。記事として具体化する過程でさらに学びもあるでしょう。また、経験学習の違うアプローチとして、最近アルムナイ採用で話題の同僚 id:daiksy さんにコーチングもお願いしているのでそちらも楽しみにしようと思います。きっとまた違うネタが生まれるでしょう。私は今回、自分の経験の密度に自信があったので「30」という数字を置きましたが、ここは自分なりにストレッチした数字を置けば良いだろうと思います。ぜひお試しください！

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

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

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

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

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

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

生まれたバリュー

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

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

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

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

他業務への良い影響

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

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

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

まとめ

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

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

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