あなたは会社の偉い人です。いま社内に、絶賛開発が行われているプロジェクトがあります。当初のリリース目標を超えてしまったけど、なんとか…今日…出すぞ…！とチームが奮闘している時に、あなたは、作られた製品の中に致命的な不具合をたまたま発見してしまいます。せっかくリリースできそうなのに、どうしてこんなタイミングに限って……ってこと、ありますよね。（あるよね？）

今回は、会社の代表としてそんな不具合を発見してしまった、先日の私の心の中の葛藤のようなもののお話です。

課題の発見と報告

ここ最近、私はプロダクトのプロトタイピングを続けており、そのアプリの配布にDeployGateを使っています。そんな最中、新しいバージョンのDeployGateのリリース候補版が社内向けのクローズドトラックに降ってきたので、そちらを試しに使っていたところ不具合を発見してしまいました。この不具合は再現性があり、特定の条件を満たさないと発生しませんが、該当するケースは容易に想像できてしまうものでした。

一方で、私は開発チームに直接的に関与していないものの、直近忙しそうに仕事をしている様子も見えており、ようやくリリースに手が届いたこの状況に外野から邪魔に入るのもちょっと憚られます。少し迷いましたが、とはいえ、顧客に影響する課題を見過ごすことはできません。私は控えめに「こんな課題を発見しましたが、既知ですか？」とSlackチームのチャンネルに書きました。

すると、すぐにエンジニアから「既知ではなかった」という反応が返ってきました。それに加え「あなたは以前プロダクトリリースの判断を持っていたわけなんだから、『直せ』『次でいい』という情報を直球で出してほしい、その判断をするコストがめちゃくちゃ高いから、よろしく頼む」という話も出てきました。

確かに、私の書き方には迷いが溢れていました。なので、今回の自分からのオーダーとしては、顧客の立場で考えると混乱が発生するバグ、不具合なので、直してから出してほしい。遠慮がちに言ってしまったけど、顧客に問題が起きるほうがダメだから、今後は直球で言っていくね、と伝えました。

組織のリーダーとして、ダメなモノはダメ、と言って、改善を求める。これ自体はいい話であります。

振り返ってみる

しかし「顧客に問題が起きる方がダメ」が十分に明らかなのであれば、何も迷う必要はなかったはずです。実際そこに疑いを持つ必要はなく、不具合の報告を煙たがる人も誰もいませんでした。自分の中で、勝手に何かと戦っていたわけです。私の遠慮はどこから来たんでしょう。

振り返ってみると、私が懸念していたのはリリースに向け高まっているチームの空気を悪くすることと、チームの自律的な動きを妨げてしまうことでした。いま現在プロダクトチームを管掌しているのは私ではなく、CPOのhentekoです。どこまでCPOに「任せる」か、すなわち、「手出しをしない」かという迷いがありました。

なぜ手出しをしないのか。任せた部分に手出しをするのは基本的にアンチパターンです。手出しをしたところから確認する側とされる側という構造が生まれ、結果的にマイクロマネジメントに繋がっていきます。任せたからには失敗も含めて任せないと、手出ししていたら互いにいつまでも成長できません。

本質的には、リリース前に不具合の発見がなされることや、その仕組み作りはプロダクト開発組織が持つ責務です。不具合の発見が外でなされた（かつ、その優先順位がわからず、チームに混乱を来してしまった）という今回の現象は、あえて口出しをせず、実際に顧客に出して問題にぶつかって自分達で解決してもらった方が、その前後の議論も含めてチームが成長できた可能性はあります。

課題をリフレーム

プロダクトの成長とチームの成長、どちらを優先するか？この小さい組織でそこの整理を優先すべきか？などなど続く議論は思いつきつつ、はてそんなところが迷いの中心なんだっけ？

なんか遠くまで来てしまった気がするので、一旦議論をズームアウトして考えます。

まず「できあがったプロダクトの不具合について報告する」をやっていた自分はどんな立ち位置だったのかを考えました。これ自体はプロダクトの利用者の立場でやっていることです。今回ユーザーとしてたまたま不具合に直面し、それがたまたまリリース前のビルドだった。なので報告自体は、ドッグフーディングをしていた1ユーザーとしての行動です。もし「パイロットユーザーから不具合の報告がありました」だったら、迷うことはなかったはずです。立ち位置が曖昧な報告をしたことが、責任者としての私に判断を求めてしまうミスディレクションにも繋がったと考えられます。

また、利用するユーザーの立場での提起はモノ(What)に対する課題で、組織のマネジメントが見るのは手段(How)に対する課題と考えられます。チームの外からHowに口出しするのは問題があります。一方で、製品の問題というWhatを出すこと自体は誰でもできる。そうあるべきだと思います。なので、どんな立場であっても、課題の報告自体を遠慮する理由はないです。先の自律的な動きを妨げてしまうのでは、という不安もちょっと違うということがわかります。

……と、そんなことを考えていた最中、再び近しい不具合報告をする機会が得られました。

なので今度は「ユーザーとして」の期待値と現状を書いた上で、あとはCPOに判断を投げました。すると、意思決定がなされ、チームとの調整がなされ、迷いなくプロセスが進行していきます。行われた意思決定は、自分がするであろう判断とは異なる内容でしたが、チームの協力もあり結果として自分の想像よりもいい形で進んでいます。

任せる練習は続く

そんな感じで、今回は任せたことに対しての口出すべきかどうかの難しさを経験したよ、迷ったら立ち位置を明確にして、内容がWhatであればどんどん出していくのがよさそう、って話でした。

そんな話をほぼ書いた後で、いつもの英語のコーチにこの話をしたら、いつも通りだけど君は分析的に考えすぎ！いつまでもストレスから解放されないぞ！って突っ込まれました。たしかに。そうだわ。気付いてなかったわ。ということで、一度判断をしたあとで second-guess をしない、は、まだまだ修行中です。

ともあれ、迷ったときに「いま自分はどの立ち位置でこれを見てるんだ？」を考えるのは一つのいいリフレームの手法だなと思いました。

今月はそんな感じで！