yigarashiのブログ

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

新卒エンジニアからSaaS事業責任者へ - AIが拡張する事業貢献とキャリアの可能性

株式会社はてなid:yigarashi (五十嵐)です。2026/2/1付で「AIを活用したインタビュー分析SaaS toitta」の事業責任者を拝命しましたので、現在の働き方やそこに至る戦略について書きます。これまでの様子は以下です。

その後のEM of EMsとしての活動については以下で発表しました。

なぜ事業責任者をやろうと思ったか

EMとして事業貢献を志向する中で、どうしてもエンジニアリングとP/Lや事業KPIの間の距離を感じ、そこに不自由さを感じるようになっていました。その時点で組織のビジネス領域の動きに不満があったわけではないですし、エンジニアリングを通じて生まれるプロダクト価値こそが事業のコアであるとも思っていました。しかし、自分が事業に貢献していくぞと思考を整理していくと、やはり思考ツリーの一番上には売上と書くわけです。そしてその下にリード、商談、解約数、アップセル数とSaaSっぽい指標が現れ、さらにその下にプロダクトKPI、開発生産性……とようやくエンジニアリングで直接的に動かせそうな指標が出てくる。事業に貢献すると言いながら、自分が動かせると感じられる変数がどうしてこんなに少ないんだろうと、徐々に理想像とのギャップを感じるようになりました。

そんな折、事業の拡大や組織の様々な変化によって、全領域を受け持っていた立ち上げPMの業務量が近いうちに限界を超えることがわかってきました。EMとしても、プロダクトマネジメントボトルネックになりがちという形で課題を観測していました。そこで状況を整理していくと、プロダクト思想だけはどうしても代えが効かず、立ち上げPMがプロダクトマネジメントに集中できることが事業にとって最適であることが見えてきました。

ちょうど最近 プロダクトマネージャーの業務マップを更新しました - inSmartBank というエントリが公開されており、そのマッピングが我々の状況を的確にモデル化していたので以下に引用します。

プロダクトマネージャーの業務マップ
https://cdn-ak.f.st-hatena.com/images/fotolife/s/smartbank/20260119/20260119093527.png より

まさに立ち上げPMは「PM as a 新規立ち上げ」の領域を担っていました。これを「PM as a プロダクトマネージャー」に絞り込むということです。では残った上側の事業領域をどうしようかとなった時に、自分から手を挙げさせてもらいました。EMとして行っていた戦略構築や、方針の言語化と発信、組織マネジメントといったスキルを生かせる仕事が多く、かつ自分が理想とする事業貢献とのギャップを埋めるのにも最適なポジションだったからです。客観的に見ても、立ち上げから携わって経緯をよく把握しており、自分がワークするという前提さえクリアできれば、人員配置としてはかなり筋が良い提案でもありました。新卒エンジニアとして働き始めて7年、エンジニアリングの外に飛び出してP/L責任を負うということで、自分の中でも思い切った決断をしたとふりかえっています。

事業責任者を任されるためにやったこと

自分がやると決断し宣言することと、実際にそのポジションを任されることは別です。エンジニアだった人間が突然ビジネス領域も含めた事業マネジメントができるのか、EMとしての仕事はどうするのか、様々な懸念があることは誰の目にも明らかです。およそ1年かけて、大きく以下の3つの取り組みで徐々に実務に関わりながら懸念を解決していきました。

(1) EMの後進育成

自分はEM of EMsとして2事業のエンジニアチームを管掌しており、それだけでも十分にフルタイムの仕事でした。素朴にはとても事業責任を追加で負うことはできません。しかしまさにその頃、各事業チームでEM候補者がメキメキとスキルを伸ばしている真っ最中で、彼らに業務の大半を担ってもらうことが現実的になっていました。そこで、その流れをさらに加速するべく委譲と育成の動きを強めました。まずは一部のメンバーの目標管理や、期変わりのタイミングにおけるチームの体制設計を委譲していきました。特にチーム全体を委譲しきれそうなメンバーに対しては、「EM養成講座」として、自分が半年間で行う仕事とそこで考えていることを言語化し、複数回の対話セッションで共有するプログラムを実施しました。以下の記事は、講座のなかで社の文脈に依存しない部分を切り出したものとなっています。

yigarashi.hatenablog.com

そのような施策を積み上げることで、各チームのEMやシニアメンバーのメンタリング、全社のリソース調整のインターフェース、採用のリードといった業務に絞り込んで、自分の時間の15〜20%程度までEM業務を圧縮しました。ちょうど自分が3ヶ月の育児休業を取るタイミングでもあったので、そこともうまく噛み合いました。各チームのEM候補者にも正式にEMの職種をつけることができ、これまで以上にストレッチして挑戦してもらえていると考えています。社のエンジニアセミナーで、本格的にEM業務に取り組んだ経験を話してもらうこともできました。

(2) SaaS事業責任者としてのインプット

SaaS事業責任者として仕事ができるよう、把握すべき知識を整理しひたすらインプットしました。

まずはビジネス領域の各職種、セールス、マーケティング、カスタマーサクセスについて、それらしい書籍を見つけてきて読み漁りました。経営者としての視点もあると良いと考え「世界標準の経営理論」を読んでみたり、Harvard Business Reviewの購読も始めました。またとにかく実践知を浴びることが重要なフェーズであるとして、ALL STAR SAAS BLOG、ProductZine、MarkeZine、noteの#スタートアップマガジン、SaaS経営者のnoteなどを購読し読みまくりました(これは今も続けています)。特にALL STAR SAASが提供するSaaS PLAYBOOKは濃密な実践知の塊で、折を見ては面白そうな記事をピックアップして読んでいます。

子供が生まれ、寝かしつけなどで耳だけが空いている時間が増えたのでポッドキャストも重宝しました。ALL STAR SAASとZero Topicをよく聞いています。SaaS事業を引っ張っている人たちの生の言葉遣いは、非常に参考になる部分が多いですしモチベーションの刺激にもなります。

加えて、事業の対象ドメインであるユーザーリサーチについても徹底的にインプットを行いました。書籍をいくつか読んだ上で、界隈で最大のカンファレンスであるResearch Conferenceの過去アーカイブを2倍速で回してだいたい全部見ました。他にもDeep Researchで企業の実践事例を集めさせてひたすら読み漁ったり、自分自身でもGo to Marketのためのリサーチプロジェクトをリードし、顧客に対して自分でリサーチをやってみたりもしました。事業ドメインについて一定把握することができたものの、「顧客を知る」部分はまだまだ甘すぎると感じており、自分もイベント出展や営業を通じて顧客と直接触れ合う経験をもっともっと増やしていく必要があります。

以上のようなインプットにより、まずは知識のベースラインを構築することができました。関係者とのコミュニケーション、マネジメントで頓珍漢なことは言わずに済んでおり、むしろ理解度や打ち返しが期待を超えているとフィードバックいただけることも多く、おそらくうまく行っているだろうと捉えています。

(3) AIで事業責任者としての能力を補強する

上述のようにインプットを行いましたが、それだけでうまく事業運営ができるわけではありません。本来は、そこに実際の経験を重ね合わせて、長い時間をかけて事業運営のスキルを獲得していく道のりが待っています。しかしそんなことを待っている時間はないので、AIを活用して経験知を擬似的に獲得することを試みました。

まずGo to Market、セールス、マーケティング、カスタマーサクセスといった自分が新たに管掌する領域について「MBAの講師になって、SaaS経営のスキルを伸ばすためのレポート課題を作って」と頼みます。すると、今のセグメント設計はどうなってますかとか、各セグメントの受注率は、事業として注力すべきセグメントとその理由は、顧客の成功の典型パターンは、NRRは、ARPUは……などなど、SaaS事業を解像度高く分解する問いが山のように生成されます。それらの問いに沿って、HubSpotやら売上集計シートをこねくり回したり、商談の動画を見漁ったりして、自分なりの見解を言葉にする作業をひたすら行いました。

また事業が置かれている状況や自分の考えを、一般的な見地から位置付けるのにもAIが非常に役立ちました。というのも、ビジネスサイド未経験者の弱みとして、経験に依存する定石や相場の勘所が極端に欠けてしまう点が挙げられます。たとえば商談からの受注率がN%であると明らかにすることはできるが、それが良いのか悪いのか、伸び代があるものとして課題化すべきかの判断基準が自分の中にないのです。そういう時に、もうざっくりと「SaaSでアポからの受注率がN%って普通かな?」とAIに聞いてみるわけです。そうすると「状況によって異なります。エンプラですか?SMBですか?単価は?」みたいな問答が始まって、その概念に向き合う時の定石と相場がいつの間にか掴めてきます。

他にも、たとえばマーケティングについて考えていて「状況を打開するためにXXXの施策をやったら良いんじゃないか」といったことは当然思いつくわけです。そういうときも「AAAな状況でXXXの施策をやるのはどれくらい一般的ですか。事例を探してください。他に考えられる施策も列挙してください」などと聞いてやると、自分のアイディアを一定相対化しながら視野を広げることができます。

このように、AIを活用して大外しをしない70〜80点くらいのロジックや方向性を固めた上でビジネス領域の施策・メンバーに関わるよう意識しました。そうすると、大筋は合っているので他メンバーのアイディアもスムーズに乗ってうまくいくか、一般的にはそうなんだが現場の事情としてはこういう困りがあってと一気に解像度を上げられるか……という感じの分岐になって、効果的に仕事をできるシーンを増やせていると考えています。AIがなければ、まともな仕事ができるようになるまで正直もう1〜2年かかっているなという感触があります。AIによって自分の事業貢献やキャリアの可能性を大きく拡張できていると感じています。

まとめ

本記事では、およそ1年ほどかけてエンジニア・EMからSaaS事業責任者へとコンバートした様子について書きました。地道な委譲やインプットに加えて、AIを活用した能力の補強を積極的に行うことで、難しい職責が伴うポジションへの移行を堅実かつ高速に行うことができました。今のところ、事業責任者としてのパフォーマンスについてはポジティブなフィードバックを多くいただけており、あとはしっかり数字を伸ばすことで抜擢に報いたいと思います。AIによって仕事がなくなるという悲観論も絶えませんが、一方でAIによって新しい可能性が拓かれているのも事実です。AIを活用してキャリアを大きく転換した例として、読んでいただいた方の刺激になれば幸いです。

toittaについて

最後に、自分が事業責任者を務める「AIを活用したインタビュー分析SaaS toitta」について紹介します。

ja.toitta.com

toittaでは、ユーザーインタビューの動画をアップロードするだけで、これまで膨大な時間がかかっていた分析作業の下処理を自動化するとともに、これまで埋もれがちだったユーザーの生の声にいつでもアクセスできるプロダクト開発体験を実現します。キーワード検索や、リサーチに特化したAIエージェントによる探索で、過去のユーザーインタビューのデータも、開発方針や仕様を検討するための資産としてこれまで以上に活用いただけます。

AIによってソフトウェアを作る能力がどんどんコモディティ化し、また適用できる領域も広がるなかで、競争は「いかに顧客の生々しい課題にフィットしたものを作れるか」に急速にシフトしています。toittaによって、ユーザーの生の声に基づく意思決定が加速することで、大きな競争力を生み出すことができると考えています。無料トライアルも実施しておりますので、自分の組織で「インタビュー大変そうにしているな」「ユーザーの声をもっと聞いていきたいな」と感じる方は、ぜひ一度お問い合わせいただければと思います。

ユーザーインタビューを取り巻く現場課題とAI事業による解決の取り組みについて

はじめに

Research Advent Calendar 2025 20日目の記事です。

こんにちは、株式会社はてなid:yigarashi です。コンテンツ本部でEM of EMsを務めるかたわら、最近はtoittaというインタビュー分析を支援するサービスの事業責任者補佐も兼務しています。エンジニアリングや組織だけでなく、事業ドメインであるユーザーリサーチにも深く取り組んでいます。そんな経緯もあり、HCD-Netフォーラム2025にて「ユーザーインタビューを取り巻く現場課題とAI事業による解決の取り組みについて」というタイトルでtoittaにおける課題解決の様子を発表しました。本記事では、その内容を紹介し、発表では話しきれなかったAIによるユーザーインタビューの変化の展望について議論します。

発表の概要

当日の発表資料は以下をご覧ください。本記事でも簡単な概要を紹介します。

ユーザーインタビューを取り巻く現場課題の調査

toittaは2024年10月に正式リリースした、ユーザーインタビューの分析を支援するサービスです。リリース当初はユーザーであるリサーチャーの方々の強いペインポイントが、分析のための前処理(書き起こし、話者分離、切片化)や発話データへの立ち戻りづらさにあることが明白で、非常にスムーズに開発を行っていました。しかし開発が進んで機能と顧客からの要望が増えるにつれ、おそらく多くのスタートアップが経験するのと同じように、開発の方向性についてチーム内で意見がまとまりづらくなりました。リサーチャーの活動や課題に対する共通理解が不足していることが根本的な原因と考えられ、改めてリサーチを行うことにしました。

リサーチを進めた結果、企業におけるユーザーインタビューにおける共通の行動パターンや課題が見えてきました。特に重要な示唆を以下に列挙します。

  • 計画、募集、実査、速報、分析、活用の流れを経るのが大半である
  • 多くのプロセスにおいて、自然言語を用いた情報処理の難しさと膨大さによって阻害されている。例としてインタビューの設計・レポートなど活動全体を当初の仮説や目的に一貫させて成果に繋げる難しさなど
  • 価値をもたらすことに失敗(ないし失敗を予期)することで、リサーチに投じられるリソースが減少し、さらにリサーチの成功体験が減少する悪循環が確認された

チームでは調査結果を踏まえ、ユーザーインタビューが計画時の問いに説得力を持って答え成果を挙げることが重要な価値であり、悪循環を好循環に変えるレバレッジであるという共通認識を持ち、機能の開発につなげることができました。

AIによる課題解決の取り組みについて

上述のようにユーザーインタビューの課題の多くは自然言語を対象にした情報処理に関係するもので、従来のソフトウェアの能力とは非常に相性の悪いものでした。結果としてテクノロジーの恩恵を受けづらい領域だったと考えます。しかし生成AIによるブレイクスルーで、精度の高い書き起こしや話者分離、またそれらを柔軟に操作する能力が急速に実用化されています。我々もそうした流れに乗って事業を行っていますし、国内外でも様々なリサーチ関連サービスが生まれています。

生成AIとユーザーインタビューの相性の良さを鑑みても、今後もAI活用が進み、ユーザーインタビューのあり方が大きく変化することは避けられない流れだろうと思います。だからこそ、その新しいプロセスをどのように設計するかが今後の重要な論点であると考えています。そこで議論の基礎となるのは「人間が主体である」という理念だと考えます。

人間中心のAI活用について

発表後、HCD-Netの関係者の方から強くポジティブな反応をいただいたポイントがありました。それは、ユーザーインタビューにおけるAI活用において、人間が主体であり続けるという考え方です。toittaの重要な設計思想のひとつでもあるので、この点に専門家の方から後押しをいただけたのは非常に心強く感じました。我々自身がインタビューを外注している方々に行ったリサーチでも、実査には必ず同席するという点が一貫しており、人間が自らユーザーの声に触れる価値というのは広く重要視されていると言えそうです。たとえばAIが実査を行うとしても、AIがインタビューをしてきて終わりという効率化に倒れるのではなく、AIと人間が同席してより充実したインタビューを行うといった方向が浮かび上がってきます。

最近、Unprintedに掲載された記事「『AIペルソナ』が業界トレンドに? 生成AIで激変する『デザインリサーチ』」で、Ubie社の畠山さんとアンカーデザイン社の木浦さんが語られた内容も、非常に共感するものがありました。畠山さんは「70点のプロダクトを作るならAIペルソナでも可能ですが、その先の100点、120点を目指すとしたら、現状のAIでは難しい」と述べています。また木浦さんは「『事実は小説より奇なり』と言いますが、ユーザーインタビューをしていると、『まさか』という経験をしている方が山ほどいます。これが生身の人間にインタビューするおもしろさ」と語っています。

もちろんAIによって効率化が進み人間を代替する部分は出てくるでしょう。しかしAIのアウトプットはあくまで平均化されたもので、生身の人間が発する声を再現するには至っていません。AI時代のユーザーインタビューに残る価値のひとつは「生身の人間が生身の人間の話を聞きにいって120点の成果を出せること」になるはずです。その人間の活動をいかにAIで支援し、能力を拡張していけるかが重要だと考えています。

各社のデザイン・UX教育の取り組みとAIの価値

HCD-Netフォーラムの他の発表で印象的だったのは、各社でデザインやUXの教育に熱心に取り組んでいることです。人間中心設計の一連のスキルを組織に実装し拡大するものから、顧客と話したことがないメンバーにとにかく顧客と話させてデザイン思考の一歩目を促すようなものまで、様々な切り口で取り組んでいる様子がありました。それらに共通するのは、教育を通じた組織の変革に非常に長い時間と多大な労力がかかることです。

ここにもAIの活躍機会があるように思います。AIによる価値は様々な整理のされ方がありますが、人にうれしいAIのためのUXデザインガイド(People + AI Guidebook)では、「自動化」と「能力の拡張」という形で整理されています。たとえば書き起こしのような本質的ではない仕事を自動化する、実査や分析のような難しい仕事をAIが補助することで専門家ではない人たちの能力を拡張する、といったようなことです。いずれの価値も教育コストを下げ、デザイン・UXのハードルを下げることにつながります。リサーチにおけるAIの活用には、その成果が届く範囲を広げるような価値が秘められていると考えます。

おわりに

本記事では、HCD-Netフォーラム2025での発表を起点に、AIを活用したユーザーインタビュー支援の取り組みと、今後のAIによる変化の展望について会場で得た刺激をもとにさらに展開した議論を紹介しました。皆様の参考になれば幸いです。

EMとパラドキシカル・リーダーシップ

ハーバード・ビジネス・レビュー2025年9月号の入山章栄先生の連載にて、パラドキシカル・リーダーシップという概念が紹介されていた。近年勃興しつつあるリーダーシップ理論とのことで、Webで検索してみると2023年あたりから関連する書籍や記事が見つかる。その出自も含めてEMと深い関連性が感じられ、エンジニアリングマネジメントをうまくやる上で参考になる理論のひとつになるように思った。この記事では当該連載を参照しながらパラドキシカル・リーダーシップを簡単に紹介し、わたしの体験や考えを踏まえたEMとの関連性について議論する。

パラドキシカル・リーダーシップとは

パラドキシカル・リーダーシップとは、不確実性の高い環境に適応するため、一見矛盾するように見える複数のリーダーシップスタイルを統合して発揮するあり方とされている。このハイブリッド型の像を理解するためには、ここに至るまでのリーダーシップ論の変遷を押さえる必要がある。

出発点は「リーダーが上、フォロワーが下」という古典的なヒーロー型のリーダーシップである。このカテゴリではふたつのリーダーシップ理論がよく知られている。ひとつはトランザクショナル・リーダーシップ(TSL)。これは「部下を観察し、その意思を尊重しながら、心理的な取引、すなわち報酬と罰を用いた交換関係の中で、部下に真摯に向き合うリーダーシップ」、外発的報酬や罰に基づく管理型の側面が強い像とされている。もうひとつはトランスフォーメーショナル・リーダーシップ(TFL)。これは「ビジョンと啓蒙を重視するリーダーシップスタイル」とされ、カリスマ性、知的刺激、個別配慮を併せ持った概念である。部下の内発的動機を刺激しながら組織のゴールにアラインするスタイルでより現代的な像であると言える。ただし両者は相反するものではなく、状況に合わせて使い分けることで成果が向上することが知られている。給与やポジション、機会といった外発的な報酬と、やりがいや使命感、学びといった内発的な報酬の両方がバランスよく提示されるべきというのは直感にも合う。

しかし2000年代に入ると、トップダウンの力強いリーダーシップに代わって、倫理性、誠実性、社会性を重視するポスト・ヒーロー型のリーダーシップが台頭する。倫理性を重視し、規範に基づいて部下と誠実にやり取りを行うエシカル・リーダーシップ。他者を機軸にし、利他性を重視したサーバント・リーダーシップ。自分らしいあるがままの姿を見せ、意思決定の透明性を高めていくオーセンティック・リーダーシップの3つが例として挙げられている。この中で日本のソフトウェア業界でもよく知られているのはサーバント・リーダーシップだろう。心理的安全性のムーブメントとも連動する形で、部下を尊重し自律的で働きやすい環境を作ることが重視されるようになった。

ここでパラドキシカル・リーダーシップにつながる課題認識が生まれる。個人の尊重や裁量ばかりが強調され、必ずしも成果につながらないぬるい組織・リーダーシップの問題が叫ばれはじめたのだ。そうした良くない例の傍らで成功している像としてパラドキシカル・リーダーシップが注目されているわけだ。組織の目標を重視するヒーロー型のリーダーシップと、倫理性、誠実性、社会性といった側面を重視するポスト・ヒーロー型のリーダーシップを統合していくことで成果を最大化していくのだ。具体的には以下の5つの構成要素があるとされている。

  • 自己主張性と柔軟性の両立
  • 規律と自立の両立
  • 均等性と個別対応の両立
  • 距離と親密さの両立
  • 仕事中心と人間中心の両立

「パラドキシカル」と名前がついているが、これらの軸を両立させ、一貫して組織全体の利益と部下への配慮を追求する思想が感じられれば、むしろ部下から見ても矛盾は感じないともされている。まだ十分に確立されたリーダーシップ理論ではないようだが、これまでの潮流を引き受けた新しいスタイルとして注目を集めている。

ここまでの説明は以下の記事を参照したものである。有料版となってしまうが興味のある人は読んでみてほしい。 これからのリーダーは「強さ」と「優しさ」の矛盾をマネジメントする [第6回]「ポスト・ヒーロー時代」のリーダーシップ理論 | 入山 章栄 | ["2025年9"]月号|DIAMOND ハーバード・ビジネス・レビュー

EMとの関連性

一連のストーリーを読んでまず感じたのは、EMの出自と非常に似ているという点である。トップダウンウォーターフォール型の進め方ではソフトウェア開発の不確実性に対応できず、アジャイルのムーブメントを中心として、裁量を持った強いチームが自律的に軌道修正しながら進めるスタイルが台頭した。そのなかでマネージャー不要論も叫ばれ、Googleなど複数の大企業で実際にマネージャーを廃止する実験も行われた。しかし多くの実験は「マネージャーが必要である」という結論に至った。ひとえにその方が成果が出るからである。昨今のEMの盛り上がりはこうした経緯のもと生まれていると理解している。つまり心理的安全性や自律的なチーム、チームの高い裁量といった文化を重要な前提としながら、エンジニアリングが生み出す事業成果を最大化するように方針を示したりコーチしたりするロールの有用性が明らかになったのだ。

SCRUM MASTER THE BOOKなどを引くと、スクラムマスターとマネージャーの兼務は望ましくないとされている。前者はチームの成長、後者は成果が目標で、それらは矛盾するシーンもあり望ましい働きかけの仕方も違うからだ。しかし競争が激化した現代の事業環境の要請はより高いものになったと言わざるを得ないだろう。当然短期的な成果へのコミットは必要で、長期的な利益のためにチームの健全性や成長も必要である。それらを矛盾したもの、トレードオフとして処理するのではなく、統合し両立させて追求することが求められているように思う。その点で、現代のEMがパラドキシカル・リーダーシップを期待されるシーンが多いと言えるだろう。

実際、優れたスクラムマスターがEMとして活躍されているケースが多く観測されており、EMキャリアのエントリーポイントとしてスクラムマスターが設定されることも珍しくない。これは単なる偶然ではなく、EMが現れた経緯をパラドキシカル・リーダーシップという切り口で整理すると、むしろ必然と言える。チームを尊重する優れたコーチとしてのスキルと、チームを成果に向かわせるマネージャーとしてのスキルを兼ね備えていることが期待された結果である。

自身の経験をふりかえっても同様のことが起こっている。当初はチームの開発プロセスやコミュニケーションに課題がありスクラムの推進に取り組んだ。その後EMとしてマネジメントスキルを高めていき、所属本部のEM of EMsを拝命する時に当時の本部長から伝えられた期待は「事業にコミットするエンジニア組織を作って欲しい」であった。EMないしマネージャーは組織の成果を最大化する存在と考えていたのでその期待に違和感はなかった。それまで培ったソフトウェア開発やマネジメントについての価値観が統合され、自然と「EMの仕事は成果と成長の統合である」と整理して今日に至っている。エンジニアの目標設定で意識していること - yigarashiのブログでも書いたように、組織に必要な成果と各人の状況を踏まえた育成プランを両立させ、短期と長期のトレードオフを解くようなマネジメントスタイルを続けている。

EMにパラドキシカル・リーダーシップが期待される傾向があるとすると、反対にパラドキシカル・リーダーシップ像を積極的に取り入れることでEMとしてより上手く立ち振る舞える可能性もある。「自己主張性と柔軟性の両立」から、自分の中に組織の成果を最大化するための強い意思・計画を持ちながらも、周囲の意見を聞く姿勢を維持できているかという問いが立つ。「規律と自立の両立」からは、組織人として成果を出す期待を高くかけながらも、自律的なチーム運営をできているかという問いが立つ。「均等性と個別対応の両立」も同様である。一貫した方針で平等な判断をしながらも、各人の状況や希望に寄り添えているかを考えるきっかけになるだろう。

もちろんすべての組織でEMにパラドキシカル・リーダーシップが期待されるとまでは言わない。ただ、世間的なリーダーシップ像の変遷とソフトウェアエンジニアリングにおけるマネジメントの要請はよく整合しており、ロールに対する解像度を上げたり内省を深めるよいきっかけになるはずだ。

エンジニアの目標設定で意識していること

はじめに

マネージャーにとって目標は組織の成果を大きくするための強力なツールです。しかしジュニアなマネージャーにとって、目標設定をどのように行うかは、なかなかまとまった知見を得づらく不安を感じやすいようです。本エントリでは私がエンジニアリングマネージャーとして目標設定で考えていることをまとめてみます。

まず前提として、私は自社でWebサービスを開発している事業会社のエンジニアリングマネージャーで、ソフトウェアエンジニアの目標管理を行なっています。組織全体の制度としてはMBOに近く、組織の目標があり、そこに向けて各メンバーも個人目標を設定し、その達成度合いによって評価します。一回のイテレーションの長さは半年で、(その是非は様々あるとして)評価は給与査定と連動しています。状況が違えば私がこれから述べることが当てはまらないケースも多分にあるかと思うので、そこは各自でうまく受け取ってください。

マネージャーの役割は全体最適

目標設定におけるマネージャーの最大の役割は全体最適を図ることだと考えています。各メンバーの目標とその相互作用をよく調整することで、組織の目標達成能力を高め、メンバーの自律性を引き出し、そしてメンバーの成長機会をより多く作ることができます。それらを通じて組織の成果を最大化することがマネージャーの仕事です。これは各メンバーが独立に目標を設定するだけでは追求するのが大変で、メンバーひとりひとりと信頼関係を結んで情報を集め、全体を調整することに集中するマネージャーだからこそ期待される仕事であると思っています。

私は目標を大きく3つの観点から設計しています。それは、組織目標の達成、メンバーの志向、メンバーの成長、の3つです。それぞれの観点から満たすべき条件が導かれるので、それらをなるべくカバーするように目標を調整していきます。ここからは、それぞれの観点について詳しく述べ、目標設定のエッセンスをお伝えしようと思います。

観点1: 組織目標の達成

マネージャーの仕事は、組織の成果を最大化し、組織の目標を達成することです。よって目標設定において第一に考えるべきも組織の目標達成であると考えます。個人の目標を集めたときに、組織の目標達成に必要な仕事が完遂できるようになっていなければいけません。素朴な例では、組織の目標達成にプロジェクトAとプロジェクトBの完遂が必要であれば、Aにコミットする人、Bにコミットする人が分かれるように気を配る必要があるかもしれません。こうした気配りをするには、そもそも会社や事業が何を達成したいのかを解像度高く知る必要があります。プロジェクトA、Bの存在、その規模や期限を知らなければ、全体最適など図れるはずもありません。まずは自分が上位の計画を十分にインプットできているかを確認し、そうでなければ自分をもっと巻き込むよう上司に働きかけましょう。

そして厄介なことに、現代のソフトウェア開発における仕事を完遂する能力は非常に複雑です。要はチームとしてプロダクションレベルのソフトウェアを素早くデリバリーする必要があるわけですが、そのために考えるべき項目の数は10や20は下らないでしょう。特定技術の習熟度、設計のスキル、プロジェクト管理、プロセス改善のスキルなどなど、挙げればいくらでも出てきます。各メンバーが何をどこまでやれるかを把握し、チームとしての能力を担保していくことになります。上に述べたプロジェクトA、Bの例でも、各プロジェクトで技術的な妥当性を担保できる人はいるか、プロジェクト管理ができる人はいるか、チームの心理的安全性や信頼関係に気を配れる人がいるか、育成する人とされる人のバランスは適切か、足りないならば誰かに両方のプロジェクトを見てもらうか、全員でA、B順番に取り組んだ方が良いのでは?、しかしそれは事業上は許容されるだろうか……こういったことを考え抜いて組織の成果を大きくしていくのです。

こうした視点については同僚の id:onk による体制を考えるときに意識していること - id:onk のはてなブログをよく参照しています。組織の目標達成に必要な組織能力と、各メンバーのスキルに基づいてどのような発揮を期待するとそれを担保できるのかを考えるヒントになるだろうと思います。

観点2: メンバーの志向

観点1は組織目標から導かれるいわゆる組織の論理です。組織の論理で導かれる個人目標を押し付けるだけでは、組織能力がマネージャーの能力で頭打ちされてしまいますし、メンバーの内発的動機を生かすこともできません。メンバーの「こうすると良いのでは」「こういう仕事がしたい」という志向を聞き出し、期待に反映していくことで、自律的に組織目標に向かってもらうことも重要です。メンバーの志向も含めて全体を設計するには、日頃からそうしたコミュニケーションを行って情報収集をしたり、スキルビルドやキャリアのストーリーを作っておく必要があります。

情報収集については、こういう仕事をやりたいとか、何が苦手だとか、チームはここが微妙だとか、傾聴を土台にしてメンバーの考えを日々聞くことの積み重ねに尽きます。単に状況を聞くのではなく、そのときに感じたことを聞いたり、内省を促したり、豊かな情報を引き出せる問いを手札に持っておくと良いでしょう。自分の期待を伝えることで初めて、チームの状況認識を間違えているとわかったり、気分が乗らない仕事がわかったりすることがあり、マネージャーからラフに期待のアイディアを当ててみるのもオススメです。私はよく「チーム/XXさんの状況を〜〜と認識しているのだけど、まずこれは合ってますか」「その上でこういう仕事をお願いすると良さそうと考えたのだけど、XXさんはどう思いますか?」といった形で話を聞いてもらっています。

キルビルドやキャリアも日々の積み重ねが重要です。目標設定の時期に突然「何がしたい?」と聞かれても、多くの人が困ってしまうだろうと思うのです。やはりここも日々のコミュニケーションが大事で、日常的にメンバーのスキルビルドやキャリアを話題にしていると自ずとストーリーが見えてきます。たとえば最終的にはEMを目指したい、そのために今はこういう経験を積んでいて、次はこんな経験ができると良さそう……といった具合です。そうした認識を揃えておくと、どんな仕事がWin-Winになるか互いに腹落ちしやすく、前向きに取り組める目標をスムーズに設定できることが多いと感じます。

最後に、メンバーの志向を取り込む上で最も重要な点は、上述のような日々のコミュニケーションで最大限考慮をしつつも、マネージャーが組織に必要だと思うことを妥協してはならないということです。そこを譲って組織が目標を達成できなくなるとしたら、マネージャーがいる意味はありません。必要ならば毅然とした態度で期待を呑んでもらい、期待に応えた場合にしっかり評価すること、期限を決めて次の機会を用意することなどを約束し、良い交換関係を築くのもマネージャーの重要な振る舞いです。それすら叶わないのであればメンバーの入れ替えや補充を検討しましょう。

観点3: メンバーの成長

観点1、2だけでも、メンバーがモチベーション高く組織目標に取り組める枠組みを作れており、目標設定としては及第点と思います。しかし、そこにさらにメンバーの成長の要素を組み込めると目標の効果がさらに高まります。メンバーの成長を助け継続的に組織能力を向上させることはマネージャーの重要な仕事であり、目標はメンバーをコンフォートゾーンの外に連れ出す枠組みとしても有用です。

私がよく提案するパターンは、いわゆる「ふつう」「5段階のうちの3」の評価基準をその人の等級に相当する難易度に設定して、加点要素として上位の等級に相当する成果を設定するものです。たとえばジュニアなテックリードに対しては、妥当な技術的判断でプロジェクトを完遂させるといったことをベースラインとし、事業インパクトのある非機能開発の提案・実行や、中長期の技術ロードマップの策定を加点要素とするといった具合です。こうしたアレンジを行うには等級とロールの掛け合わせで様々なペルソナを知識として持っておくことが重要です。そうした知識は形式知になっているのが望ましいですが、上位のマネージャーの暗黙知にとどまっているケースも少なくありません。目標の案をレビューしてもらうなど、対話の機会を作ることで理解を深めましょう。

また、成長を意識した目標を設定する場合は特に、その人の道を開け適切な支援を得られるように全体調整に気を配ります。たとえばCさんがスクラムマスターに挑戦するのに、チームのシニアなエンジニアDさんもスクラムマスター相当の目標を持ってしまっては、十分な挑戦の機会が生まれないかもしれません。このような場合では、Cさんが挑戦していくことをチームに周知して協力を求めたり、Dさんの目標に「Cさんの指導を通じた成功」を加えたりして、チームのコラボレーションに方向付けを行います。チームに構造と明確さをもたらすこともマネージャーの重要な仕事です。

実践に向けて

最後に、ここまで現れなかったものの実践において重要であろう話題を補足します。

チームの戦略を言語化する

ここまで述べた3つの観点をもとに全体を調整していくのは非常に複雑な作業です。あの要素も、この要素もと考えていくと、いつまでたってもまとまりません。私はこの複雑さへの対処として、チームとしての戦略を言語化することにしています。具体的には、チームとして何を達成すべきで何が障害になるかという状況分析、そしてそのために、どういうフォーメーションが望ましいのか、何を重点的に行なって、何をやらないのかといった方針です。要は各メンバーの目標の前提となる制約をしっかりと作り込むということです。マネージャーとして、どこにどうリソースを投下して成果を得るつもりであるかという思考の軸を言語化しておくことは、目標設定という仕事の強力な補助になると思っています。戦略プランニングについては書籍「良い戦略、悪い戦略」をオススメしています。

重要な心構えとして、そうした戦略を一発で作り切ろうとしないということです。どこかでチームの状況やメンバーの志向を取り違えてハレーションを起こすことになります。まずは各メンバーとラフに話して情報収集を行い輪郭を浮かび上がらせていき、叩き台として作った案を見てもらって、思いついたアクションや改善ポイントを取り込んでさらに磨いて……というフィードバックループを回してまとめるのが良いだろうと思います。その過程自体がメンバーの腹落ちを深めていくでしょうし、チームの現実に基づく良いレバレッジが見つかりやすくなります。多少時間はかかりますがバリューの大きい作業だと思っています。

マネージャーがどこまで考えるか

ここまで述べた内容だと、観点2でメンバーの志向を取り込んで自律性を意識しているものの、マネージャーが考えすぎている、メンバーを子供扱いしているのでは、という印象もあるかもしれません。私としても、必ずしも「マネージャーが」それらの観点を取り込んだ目標設定を行う必要はなく、全体最適が図られていればどんな過程でも良いと思っています。たとえばマネージャーの視点を内面化したシニアなプレイヤーがいるチームでは、メンバー同士が話し合うことで多くの観点を網羅し、また目標の相互作用も調整することができるかもしれません。組織の状況や自身のキャリアプランがよく見えていて、現状を追認するだけでケチのつけようがない目標になるメンバーもいたりします。そのようなケースでは、マネージャーは場の用意や、各メンバーとの評価基準の合意など、より少ない仕事で十分と言えるでしょう。マネージャーは組織の成果を最大化することに対する説明責任を負って、その実行の方法は柔軟に検討できるものだと考えます。

SMARTな目標

具体的な目標の内容についても言及しておきます。良い目標を立てる上ではSMART(具体性/測定可能性/達成可能性/関連性/時間制約)に沿うのが一般的だろうと思います。

まず簡単なところとして、観点1から関連性と時間制約は自然に現れるだろうと思います。組織の目標を達成するための個人目標であるので、組織の目標に関連する発揮・成果をなんらかの締切(最低限は評価時)までに実行することは前提となるでしょう。本記事で述べた観点から達成可能性も導かれるはずです。その人の今の姿にマッチした期待を設定すること、そしてその人の成長の観点から、達成可能だが難しい次のレベルの課題も設定できることが理想です。加えて、本人がコントロール可能かという観点はよく精査しておく必要があります。

具体性については様々なすりあわせの仕方があるだろうと思います。具体的な仕事や達成条件を書き下すことも考えられますし、等級やロールなど情報量の多い言葉を使うことで詳細な期待が共有できることもあります。最も注意するべきはマネージャーが自身が抽象的な目標の文言で思考が止まってしまうことです。評価の時期になってみて、そういえば何ができたら評価できるかわかってなかったな……と気づくことが意外とあるものです。そうしたミスを減らすには、自分が同じ目標を課せられた場合のアクションプランを言えるか点検してみるのがオススメです。

測定可能性が最も頭を悩ませるポイントです。何か特定の成果物や数値を目標に設定できて、それが本人に十分コントロール可能であるという状況であれば簡単なのですが、いつもそうできるとは限りません。定性的な条件をよくすり合わせたり、定性的に望ましい発揮の件数を目標にしてお茶を濁すこともあります。究極的にはマネージャーが期待する成果に適切な報酬で報いるという交換関係が成立すれば良いのではないかと思っていて、当人同士の間で評価プロセスに納得できていて、かつ組織目標が達成できているのなら、神経質になりすぎないのが現実的な落としどころではないでしょうか。一方で、ここを妥協してしまうところに自分のマネージャーとしての"格"が現れているような気もして、悩ましく思いながら取り組んでいるポイントです。

さいごに

本記事では、私がエンジニアリングマネージャーとして目標設定の時に考えていることを述べました。目標設定におけるマネージャーの最大の役割を全体最適を図ることとし、その時に考慮する3つの観点、組織の目標、メンバーの志向、メンバーの成長について詳しく述べました。加えて実践の場で役に立つであろう話題をいくつか補足しました。目標設定は、組織の成果を大きくし、またメンバーのジャンピングボードを生み出すインパクトのある仕事だと思っています。皆様の参考になれば幸いです。

マネジメントが主務になって痛感するソフトウェア開発の不確実さ

EMになってかれこれ1年半ほど経過しました。仕事でほとんどコードを書かなくなってからは1年くらいが経ちます。代わりに組織やヒトのマネジメントが主務になっています。情報収集をしてチームの軌道修正をしたり、メンバーの活躍や成長を助けたり、組織の成果を大きくするための変化を企画したりといった具合です。何かを考えておく、文書にまとめるという仕事が日々大量に襲ってきます。それらを効率よくこなす訓練をしていくと、日々の仕事の不確実性はどんどん下がっていきます。この件は30分で結論を出す!この企画書は1時間でまとめきる!それを見積り通りやれるようになっていきます。パフォーマンスを出す上で、仕事に不確実性はないし許容できないというマインドが強くなるのを感じます。

そんな暮らしの中で、月に1件くらい開発タスクをやることがあります。チームの負荷を下げるためメインラインではない保守運用を巻き取ることにしているのです。その仕事に対して、これは1時間でカタをつける!とマネージャーのモードで入っていくと酷い目に遭うことが多いです。エラーと実装をいくら読んでも原因の見当がつかないとか、他の仕様との兼ね合いで問題の箇所がいじりづらいとか、エンジニアをやっていた時は当たり前の日常ではあったものの、予想を超える障害物が当然のように次々と現れます。マネジメントが主務になったからこそ、ソフトウェア開発って大変だな……と改めて痛感します。アジャイルな見積もりと計画、スクラム、DevOpsといった道具はやっぱり必要なんだと再確認できます。そして、そうしたカオスな課題に対して、しっかり計画をして、約束をして、達成をしていく開発チーム、やっぱりすごいなと素直に思います。コードを書かなくなると、この感覚やリスペクトが薄れていく恐怖というのがあって、それを忘れないためにこういう記事に残してみたところです。