yigarashiのブログ

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

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

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

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

任せてる側があとから介入する時は丁寧すぎるくらいすり合わせよう

リーダー、マネージャーをはじめとして多くの人が仕事を任せる側になることがあるでしょう。それ自体は経験資源を配りながら自分の余裕を作り出せるもので、普遍的な良い取り組みです。委譲のレベルや立て付けをしっかりと決めて積極的にやっていくべきです。しかし、そうして仕事を任せた時にいつも全てが上手くいくとは限りません。時には支援的な動きを超えて介入が必要になることもあるでしょう。

この介入というのが、圧倒的にコミュニケーションが失敗しやすいポイントです。ここのコミュニケーションで失敗したことがないマネージャーはいないのではと思うくらいです。自分も失敗したことがあります。自分のメンティーも同様の経験をして会話をしたことがあります。頻出シチュエーションとして、いつでも引用できるように情報をまとめようと思います。

なぜ丁寧さが必要か

丁寧さが必要な理由は大きく4つ思い付きます。

  • 任されていた側の自尊心を深く傷付けうるから
    • これまで任されていたのに介入されるのは基本的にショックな出来事です。期待に応えられなかった、うまくやり切れなかった、そういう感情が自然と湧くものです。そこに誠実に向き合うのは委譲している側の責任だろうと思います
  • 自分が十分な情報を持っているとは限らないから
    • 委譲して間接的に情報をキャッチアップしている立て付けだと、細かい状況や意図までは掴めていないかもしれません。自分の論理で強く入り込んで実は違っていたというのは非常に気まずいので、注意深く取り組む必要があります
  • 介入が必要な状況は本来的に認知のギャップを伴うから
    • 支援的な動きを超えて介入が必要な場合は、任されている側のキャパシティを超えて状況がマズい傾向にあります。その人に見えていなかったり腹落ちしていないリスク、課題があるから介入をするわけです。考え方自体が違うことを念頭に置く必要があります
  • 介入が必要な状況はピンチなことが多いから
    • 介入が必要な時は、チームに嫌な空気が漂っていたりみんなが焦っていたり、場がネガティブになっていることが多いです。そこでさらに自尊心が傷ついたり、認知のギャップから紛糾したりするのは本当につらいものです。大変な時だからこそ、それ以外の負担を生まないように注意が必要です

丁寧にやるにはどうするか

上記のようなリスクを回避し丁寧に介入を行うには、すり合わせの対話を行うしかないでしょう。介入する側は、たとえば以下のような内容を伝え、それに対するフィードバックをもらうと良いでしょう。

  • 事実関係
  • できている部分に対するポジティブなフィードバック
  • 認識している課題
  • なぜ介入が必要と思ったか
  • 具体的に何をしてどういう状態にするか

しっかりと話を聞き成果を認めることで相手の自尊心を少しでも守りましょう。そして、自分が認識している事実や、それに対する分析をなるべく豊かに開示し、情報のギャップを埋めていきます。考え方の違いがある場合はどうしてもタフなコミュニケーションが必要なこともあるでしょうが、丁寧さ、誠実さは心強い緩衝材になると信じています。

技術的負債のマネジメントを考える

技術的負債をうまくマネジメントすることは重要です。なぜなら、持続可能な長期的な利益の確保こそが競争戦略における目標であり、技術的負債への対応力はその目標に近づくための重要な組織能力だからです。EMとして組織の成果の最大化を目指す上で避けては通れない課題です。また技術的負債への対応は、単に技術的な課題ではなくそれらを包含するプロダクトの課題です。どうやって解決するかだけでなく、なぜ、いつ、どのくらいやるべきかを、事業責任者などのステークホルダーと合意して初めて対応を進めることができます。こうした課題に対しては、多職種をつなぐメンタルモデルの構築、方向付け、ファシリテーションといったソフトスキルが必要になってきます。EMはエンジニアリングの視点とそうしたスキルを併せ持つことが期待される存在で、技術的負債への対応においても重要な役割を担うと考えています。本記事では、技術的負債をマネジメントする方法についてEMの視点で考えをまとめます。

技術的負債の定義

まずはこの記事において「技術的負債」が何を指すかを定義しておきましょう。原典を辿るなりして世間的な定義を見つけることはできますが、この記事では競争力や成果を主眼に置いて議論をすることから、次のように独自に解釈をして話を進めます。

技術的負債とは事業に好ましくない影響を与えるソフトウェアの性質全般を指すものである。

技術的負債に対応する重要性と難しさ

ソフトウェア開発において、新しい価値を次々と提供し、かつ既存の価値の満足度を必要水準に保つことは競争力になりますが、この競争力は基本的には何も手当てをしなければ低下します。なぜならソフトウェア自体、何も手当てをしないまま開発運用を続ければ技術的負債が蓄積する性質があるからです。一方で何か手当てをしながらでは価値提供のスピードが足りない局面というのが往々にしてあって、一時的に競争力を高めるために技術的負債を狙って積むこともあります。こうした事情を鑑みると「技術的負債への対応」はソフトウェアでビジネスをやるプレイヤー全員に平等な制約と言えるでしょう。技術的負債のことを考えずに儲けられるソフトウェアサービスがあったらぜひ参加したいものです。技術的負債によりうまく対処し、開発能力の面で競争力を維持向上することは、ソフトウェアビジネスにおいて重要だというのは明らかでしょう。

しかし、技術的負債に対応する重要性にはもう一段深みがあると考えています。全員に平等な制約であれば、全員が対応してしまえば差別化要因ではなくなるわけです。しかし世の中はそうはなっていません。なぜか。それはひとえに技術的負債への対応が難しいからであると考えます。全員に平等な課題でありながら対応が非常に難しく、ゆえにソフトウェア事業の主要な差別化要因として競争優位性を生み出せるポイントになるのだと思います。

その具体的な難しさは多岐に渡ります。まず素朴に技術面での難しさはあるでしょう。技術的負債を特定し改善のために過不足なく設計と実装を選択するには相当量の知識と経験が必要です。EMとしてこの技術面の課題をうまく解ける人材を育て能力を引き出すことは重要です。

しかし技術的負債の難しさはそれだけではありません。仮に解くべき課題と解き方を特定したとしても、それをやる工数があるとは限りません。売上目標や顧客要望に基づいて計画された機能の追加や改修と、技術的負債への対応のどれを優先すべきかを考えなくてはなりません。影響を与える対象も時間軸も異なる仕事の価値を比べるのは難しいことです。また技術的負債への対応はタイミングも難しい傾向があります。早すぎても過剰な改善になってしまうし、遅すぎても問題が複雑になりすぎて手がつけられないという具合です。テクノロジーマネジメントというよりは、プロダクトマネジメント的な難しさが付きまといます。多くの事業がこうした難しさの前に建設的な議論を尽くせず、機を逸して競争力を損なっているように思います。ここをうまくやるのがEMの腕の見せどころと言えるでしょう。

基本方針

EMとしてのゴールは、チームが技術的負債について建設的に議論し、実際に技術的な手当てを通じて事業の競争力を維持向上できるようにすることです。特に自分は間接的に各事業に関わっているので、自分が課題を整理したり、特定の仕事をステークホルダーにかけあうようなことは効果的とは言えません。望ましいのは抽象度の高い方向付けによるレバレッジの効いた働きかけです。

この記事では以下の2つの方向付けを提案します。共通するのはステークホルダーの関心に沿って進めることで、可視化、計画と実行のそれぞれについて考えます。

技術的負債をステークホルダーの関心に沿って可視化する

前の節で、技術的負債のプロダクトマネジメント的な難しさ、つまり価値判断の共有とタイミングの難しさについて述べました。この節ではその課題への対処を考えてみます。

技術的負債への対応を行う上での重要なステークホルダーは、事業責任者やPOといった、開発チームが何に時間を使うかに説明責任を負っている人たちになるでしょう。その人たちに対して「システムがXXだから手当てをしたい」と伝えるのが素朴な始め方ですが、おそらくこれでは事態は前進しません。事業の予算や目標を立ててその達成に邁進する立場からは、それが売上やコスト、事業目標にどう関係あるのかが最も重要なのです。それがわからない限りはリソースを投じる判断はできません。技術的負債は、事業の障害になっているという証拠によって初めてステークホルダーに発見されるのです。とすれば、彼ら彼女らの関心に沿って技術的負債を可視化するのが最初にやるべきことになります。

例えばベロシティは可視化の道具として有用です。ソフトウェアをいつ頃にどんな状態にできそうか、大掴みな開発計画を立てるための重要なガイドラインになる指標です。これが乱高下したり下降傾向になることは事業責任者にとって重要な関心ごとになるはずです。そしてそのような指標の変化の裏にはしばしば技術的負債が存在します。「変更しようとした箇所が複雑すぎて整理に時間がかかった」「テストケースが不十分でデグレを起こしたので対応に時間がかかった」といった具合です。なぜベロシティが望ましくない状態なのかという共通の文脈の中で技術的負債を提示できれば、ステークホルダーも実害とともに技術的負債を認識することができるでしょう。これが関心に沿って技術的負債を可視化するということです。

ステークホルダーと共有しやすい関心は大きくふたつあると考えています。ひとつは「想定通りのスピードで開発できているか」です。たいていは予算や目標から逆算した開発計画を引いているわけで、その開発のスピードが出ていないとなれば一大事です。そして技術的負債の結果指標としての側面もあります。上述のベロシティはそれを検査する典型的な指標です。他にも、見積もりとの予実やFour Keysは関連性の高い指標として活用できるでしょう。

もうひとつの共有しやすい関心は「システムの障害が増えていないか」です。システムを利用できない、動作が壊れている、重いといった事象は事業への信頼を損ねるものです。完璧はありえないにしても、その頻度や程度が一定の閾値を超えてしまうとユーザーが離れる原因になってしまいます。より外のステークホルダーへの説明といった胃の痛い業務も増えるので事業責任者やPOにとってもしっかり嫌なイベントです。そしてスピードに関する関心と同様に、こちらも技術的負債の結果指標としての側面もあります。典型的な指標としては、可用性やレイテンシー、Four Keysから変更失敗率や平均障害復旧時間が挙げられるでしょう。

こうした共通の関心を計測し、そこに沿って技術的負債を可視化することで、まずは優先度判断の議論ができる土台を作れると考えます。また、ここまで述べたような指標は、技術的負債に対応するタイミングをはかる上でもよく機能するはずです。これらの指標を定期的に検査しておくことで、開発生産性とシステムの安定性における実害が出て、課題が顕在化しはじめたことをキャッチできる期待があります。エンジニアが最初にキャッチする漠然とした嫌な感じは超えていて、かつ手がつけられない状態になるまでには時間があるという、絶妙なタイミングで問題を俎上に上げられる頻度が高まるはずです。

ステークホルダーの関心に沿った目標を置いて戦略的に取り組む

前の節で説明したのは、技術的負債をうまく共有するための方向付けでした。実際に技術的負債に対応するためには計画と実行も必要です。この節ではそのための方向付けを考えてみます。

まず、前の節でステークホルダーの関心に沿って技術的負債を可視化する方向付けを提案しましたが、実は計画と実行においてもこの考え方は適用できます。例えば、平均障害復旧時間に関する課題感が高まっていてステークホルダーと共有できていたとします。それに対して「ログを出して監視をします」とか「障害対応演習を行います」と提案を始めてしまうと、やはりステークホルダーは判断が難しくなってしまいます。ステークホルダーの関心はあくまで「平均障害復旧時間をどうするか」であって、それをどう解くかはエンジニア特有の関心だからです。「このくらいのリソースを割けば平均障害復旧時間がこのくらい改善する」と大掴みに理解できると、ステークホルダーはリソースを投じる判断をしやすいのです。

もちろん、いつもすんなり目標が置けるとは限りません。数値目標をどのくらいに置くかで悩むこともあるでしょう。それでも「ベロシティの低下を最も招いたであろうXXな性質を取り除く」であるとか、抽象的なゴールを定義する言語化を行うことは、技術的負債への対応にリソースを割く障壁を下げるために重要です。EMとしても、単にこうした方向性を示すだけでなく、目標の設定を手伝うなど委譲のスライダーを動かして助けていくことができるでしょう。

また目標の効用はそれだけではありません。システムの結果指標に着目し、目標から逆算して少ない労力で実行する力が加わるため、戦略的な思考が促されます。変更頻度の高い部分の品質を重点的に高めたり、事業上重要なフローに絞って可観測性を高めたり、そういった鋭いアプローチが自然と生まれることが期待できます。これはリソースが限られている以上とても望ましい振る舞いです。アウトカムに着目して本質的な仕事に取り組むという意味では普遍的なプラクティスと言えるかもしれません。

まとめ

本記事では技術的負債のマネジメントについて考えました。技術的負債には、単に技術面の難しさだけでなくプロダクトマネジメント面の難しさがあり、それを乗り越えるためにはステークホルダーの関心に沿って技術的負債を可視化することが重要です。また、その計画と実行においてもステークホルダーの関心に沿って目標を設定することで、リソースを投じる判断をやりやすくし、また戦略的に取り組むためのガイドラインとすることができます。こうした抽象度の高い方向付けを通じて、EMとして効果的に技術的負債をマネジメントできるのではないかと考えています。

参考文献

「議論すべきトップ3」を準備して1on1に臨む試み

書籍「1兆ドルコーチ」で紹介されているテクニックの中に、「議論すべきトップ5を挙げよ」というのがある。ビル・キャンベルは毎回1on1のために議論すべきトップ5を準備して臨んだのだそうだ。それをすぐに出すことはしないで相手にもトップ5を考えるように促す。それ自体がコーチングであるし、お互いのトップ5を突き合わせて優先度を決めることもトレーニングになるとしている。

自分は以前の記事 事業を深く理解しOODAループを回しまくる最近の自分のEM像に至るまで - yigarashiのブログ でも書いたように、毎週マネジメント対象のチームや個人の状況認識をアップデートしてまとめるようにしている。その中で気づいたことを1on1に持ち込んで話すことも多く、1週間の1on1の準備としての側面も強い。ただ最近この状況認識のアップデートがマンネリ化していて、必要なことを考え抜けているか、1on1を価値ある場にできているかと考えていた。そこに上述のテクニックを思い出したので試してみることにした。トップ5は多いのでまずはトップ3から始める（ビル・キャンベルが特に関わっていたのはGoogleã‚„Appleといったビッグテックの経営層であるから、我々と比べて懸案も多そうである）。

まずは自分で一度考えてみたところだが、今のところ感触がすごく良い。「議論すべき」というラベリングが脳を刺激してくれる感覚がある。単に課題ベスト3は何かと考えるよりも、自分がその人と何を議論すべきかと考えると、自然と具体的な状況やナラティブに沿って思考することができる。その場でことを前進させるニュアンスも強まるので、具体的な行動方針について考えを深めるきっかけにもなった。1on1の準備をしっかりできている感触があるし、チームの課題についてもいくつか発見があった。しっかり準備しているからこそ、それを胸に秘めてコーチング機会をつくる余裕も生まれそうだ。

自分のアクティビティとしては感触が良いので、合いそうなメンバーと「トップ3」のアクティビティをやってみようと思う。この記事はその説明のためのドキュメントでもある。

書籍を読んだ限り、ビル・キャンベルが名だたる経営者に対してこのアクティビティを機能させられたのは、自身もまた優れた経営者であったからに他ならないと考えている。自分もEM、スクラムマスター、エンジニアなど様々な職種における経験・知識・洞察を深めなければ、有益な「トップ3」を準備することはできない。実務家としての緊張感を持ち続けたい。そういった意味でも、1on1に自分なりの仮説を持って臨むというのは良い試みになるだろう。仮説を持つことで学びを大きくすることができる。

CRE(Customer Reliability Engineer)について調べた

EMとして関わっている事業でCREがいた方が良いかもしれないという話題が出た。弊社はてなではMackerelチームでCREが活躍しておりその存在は知っている。しかし同じチームで働いたことはなく、その全体像や期待値について詳しくは知らなかった。仮に自チームで迎えるとなれば、世間的な期待とマッチしたポジションである必要があるし、場合によっては自分がマネージャーをすることになるかもしれない。まずは解像度を一段高めて、具体的な検討を始められる状態になろうと思う。

今回の調査では以下の記事を参考にした。原典とされている文書、弊社CREの発信、検索上位の他社発信と簡単に散らして情報を集めた。

CREに関する調査まとめと思考

CREとはもともとGoogleから生まれた職種とされている。顧客が自社のアプリケーションをクラウドに預ける不安を取り除くことを目的として顧客の信頼性に取り組む。近年この考えをtoC/toBの自社製品へと拡大しCRE職種を設ける企業が増えている。クラウドに関わらず製品の利用においては技術的な障害物や不安が発生するし、効果的な活用のために提案やプラクティスが必要な場合もある。エンジニアが顧客に対して密に支援を行うことで、顧客の成功と製品に対する信頼を大きくし、最終的には事業成果や価値提供を大きくする試みである。

CREが取り組む仕事を自分のメンタルモデルに当てはめると、以下のように整理できると考えた。

  • マーケティング
    • 自社製品や関連領域についてのイベントの運営、記事執筆、登壇といったDevRel活動
  • セールス
    • 製品導入に向けた技術的な障害物を取り除く。商談で技術的な面をサポートしたり、ソリューションアーキテクトのように振る舞い導入に向けた具体的なプランを提案したりとあり方は様々
  • カスタマーサクセス
    • テクニカルサポート、カスタマーサポート、製品ドキュメントの充実、利用状況の分析やサービス利用の支援など
  • プロダクトマネジメント
    • VoC(Voice of Customer)に基づくプロダクトの新たな価値提案や開発

ソフトウェア開発における、いわゆる「ビジネスサイド」に広く活動領域が横たわっており、事業の状況や特性に応じて取り組む仕事や軸足が変わる。その中でも実際に顧客とコミュニケーションを取る、セールスやカスタマーサクセスの領域が仕事量としても多くなりそうには見える。

各領域におけるエンジニアのサポートはCREという職種とは関係なく存在していた仕事で、「セールスエンジニア」のような別の名前で呼ばれたり、開発を主務とするエンジニアが片手間で取り組んだりしていたのだと思う。そうした仕事が網羅的に発見され、また開発チームが割り込みとして処理する非効率や難しさが問題視されたことで、ビジネス領域にオーナーシップを持って主体的に動くCREという職種が生まれたのではなかろうか。ビジネスチームをストリームアラインドチームとして完成させ、製品の技術面や開発チームとの橋渡しをするピースとして、CREの価値を理解できるように思えた。

こうした理解をもとにすると、単にCREをひとり入れれば良いというわけではなく、セールスやサポートといった他の職種を含めたビジネスチーム全体の働き方やバリューストリームの展望を持って期待やポジションを設計する必要がありそうだ。関係者と会話をして具体化していこうと思う。

余談: NotebookLMを使ったしらべごと

今回の調査はGoogleが提供するNotebookLMを使って行った。ざっくり言うと、Webサイトなどのデータソースを登録して簡単にRAGが作れて、その回答や自分のメモを一緒にストックできるサービスである。何か特定のトピックについてしらべごとをするのに向いていそうだったので、今回ためしに使ってみた。データソースを登録して質問をすると出典をつけて返してくれるので、対象のデータソースを対話的に理解することができた。また、前節の自分の言語化をそのまま突っ込んで「間違いや不足している観点を指摘してください」と質問できるのは良かった。ここはこういう出典と整合するとしっかり検査してくれて、まあ致命的な間違いはなさそうだなというのを確認して記事を公開できている。まだまだ荒削りだが期待が持てる体験だった。