みなさんはこういった経験をしたことがありますか？
大谷洋生氏：では僕の発表を始めようかなと思います。「エンジニア主導の仕様検討：はじめの一歩を踏み出す」というタイトルで、話をさせていただきたいと思います。よろしくお願いします。
まず自己紹介ですね。SmartHRから来ました。エンジニアをしています。大谷と言います。ふだんはRailsを書いたりReactを書いたり、あとはFlutterを書いたりとかしています。
次です。突然ですが、みなさんはこういった経験をしたことはないでしょうか？ 例えば、PMが仕様を検討してエンジニアに作り始めてもらったら、実はできないことがわかったとか。あとは、PMが開発におけるブロッキングを多く抱えてしまっているみたいなことですね。
今日は、私たちのチームがどうやってこういう課題に対処したのかということをお話ししたいと思います。
チームの人数増加に伴い出てきた課題1 仕様検討のボトルネック化
まず前提のお話です。僕のチームで起こったことを話します。先ほどの迫さん（迫康晃氏）のお話はこの労務管理という大きなプロダクトの中でのお話だったんですが、今回僕がお話しするのは右側です。人材マネジメントという、マイクロサービスみたいになっている1つのサービスのチームの話ですね。なので、比較的小さいチームでの話なんだなということを認識しながら聞いてもらえればなと思います。
（スライドを示して）この図ですね。サービス構成的にはこうなっているんですが、今回はこの右側の、1つのサービスのチームの話をします。
次です。前提が長いんですが、チームの状況についてお話をします。人数の推移みたいなものをざっくり書いてるんですが、1年前は1チームでPMの方が1人、エンジニアはまぁ5人ぐらいという感じでしたが、6月時点ではチームが2チームになりました。1つのプロダクトを2チームで作っていたという感じですね。PMの方は変わらず1人で、エンジニアが8人に増えました。3人増えたかたちです。入れ替わりとかもいろいろあったんですが、増えた感じでした。
プロダクトが成長するにしたがってチームの人数が増えてきたというのが、コンテキストとしてあります。そういう背景の中でチームがどういう課題を抱え始めていたかという話をします。
大きく分けて2つなんですが、まず1つ目ですね。チームが2チームになったんですが、PMの方が1人のままだったんです。なので、シンプルに物理的に手が足りないという課題がありました。
これは具体的にどういう問題になるかというと、仕様検討がボトルネックになるんですよ。
その話をするにあたって、当時のチームがどういう切り分けになっていたかというと、PMの方の責務が要求定義と仕様検討の部分に責任を持つような感じになっています。当然グラデーションではありますが、大きく分けるとこうです。
エンジニアはその仕様検討の先の設計とか、実装の責任を持つ感じの分解になっていました。なのでPMの方の手が足りないと、仕様検討のところがどんどんボトルネックになってくるという感じのお話です。
チームの人数増加に伴い出てきた課題2 術的な観点で手戻りが発生する
次です。技術的な観点で手戻りが発生するということが起きていました。
誰しも経験があるんじゃないかなと僕は思っているんですが、例えばPMの方が仕様をまとめてくれて「こういう仕様でいきましょう！」と、仕様書をペラッと出してくれるわけですよね。
すると、エンジニアがレビューをする時に「現行の仕様と噛み合わなくないですか？」とか「なんかちょっと工数がかかりそうですね」とか「そもそもこれは実現できるんですか？」みたいなことを言って、ボコボコにされてしまうということが起こったりしていました。PMの方はそれを持って、もう1回直してレビューするというプロセスを繰り返すわけです。
そうするとどうなるかというと、「手戻りが発生するのは良くない」とみんなそう思うので、それが発生しないようにしようとすると、どんどん仕様検討のコストが上がってくるんですよね。そうするとリードタイムが伸びるので、お客さまに価値を提供するまでの時間、ここがボトルネックになって、だんだん長くなってしまうことが起こっていました。
エンジニアがHowの提案をやってみる
これにどう対処したかという話をします。やったことはすごくシンプルで、「エンジニアがHowの提案までやってみようよ」というふうに変えてみました。（スライドを示して）これは先ほど見せた図なんですが、上が今までで、下が「今はこうなっています」という感じの図です。エンジニアの責務が設計・実装だけに閉じていたのを、もっとグッと左に伸ばしてみよう、仕様検討まで入り込んでみようというのが今回のアプローチです。
フローで話をするともうちょっとわかりやすいかなと思うので話すんですが、以前は「PMの方に要求定義書を書いてもらう」というのがスタート地点でした。これはどちらも変わらないんですが、要はユーザーのペインがどこにあって、どういうことに苦しんでいるかみたいな話をまずは書いてもらいます。それを持ってPMの方がそのまま仕様書まで書くというのが以前のフローでした。
それをもらってエンジニアが設計・実装をして、質問があったらPMの方にエンジニアが確認する感じのフローでした。なので、PMがずっとボールを持っているようなイメージですね。
これがどういうふうに変わったかというと、要求仕様書をPMの方に出してもらうのは同じ。そこから、それをもらったエンジニアが詳細な仕様まで考えて提案をするというところが違います。
そのあとPMの方とエンジニアとかチームで仕様をすり合わせて決定して、設計・実装してというところは一緒ですが、そのあともちょっと違っていて。考慮漏れとか曖昧な仕様って、実装しているとどうしても出てくるじゃないですか。
そういう時にどうするかというと、PMの方に「どうしたらいいんですかね？」という投げ方をするんじゃなくて、エンジニアが「うーん、この場合はこうしたら良いと思うんですけど、どう思いますか？」とチームに提案をするんですよね。なので、PMの方じゃなくて、エンジニア側でずっとボールを持ち続けるようなイメージに変わったという感じです。
ポジティブな変化、うれしい誤算
それでどういうことが起こったかというと、ポジティブな変化がたくさん起こりました。まず、抱えていたペインですね。手戻りがあるとか、リードタイムが長くなるみたいな感じのお話ですが、手戻りが減って、リードタイムがすごく短くなりました。技術的な観点での手戻りがなくなったわけじゃないんですが少なくなったので、リードタイムが短くなるということが起こりました。
また、これによってPMの方が未来の価値により多くの時間を使えるようになってきたというのもうれしい変化でした。
次です。これはけっこううれしい誤算だったなという感じなんですが、エンジニアは機能開発に対してもっと自分事化できるようになったというのが、すごく良い話として今回挙げられるかなと思っています。
今回の変更って、要はエンジニアの業務の範囲を増やすことになるので、平たく言うと大変さが増えるかなということは、けっこうみんな薄っすらと思っていたんですよね。ですが、やはりイチエンジニアとして、ユーザーの課題をどうやったら解決できるかに頭を使いたいというのは、たぶんみんな同じかなと思っていて。そこをけっこう自分たちでちゃんと考えられ、仕事が普通に楽しくなったというのはメチャクチャ良い話だったなと思います。
次に、エンジニアに意思決定のスキルが身に付いてきたという話があります。エンジニアがPMと仕様を「どれがいいかな」とキャッチボールをするわけですよね。その中で、「意思決定ってどうやったらもっとスムーズになるんだっけ？」みたいなスキルがだんだん移譲されてくるようなことが起こりました。
例えばどういうことかというと、仕様検討をしていると「ここのケースってケアしなくて良いんだっけ？」「こういう機能って必要じゃないんだっけ？」みたいな、「どうしたらいいんだっけ？」「作ろうか、作らないか」という話が出てくることって、よくあると思うんですよね。そういう時にどういうような判断ができるようになってきたかというと、データを見て判断できるということが、まずできるようになっていきました。
例えば「80パーセントぐらいのユーザーには、ここの見た目がこうなる」とか「レスポンスがだいたいこれぐらいで返るよね」ということが、データベースのデータを見ながら会話ができるようになってきたんですよね。
そうすると「80パーセントぐらいはこういう感じになるんだったら、残りの20パーセントのケアの仕方はこうすればいいよね」という感じの会話が自信を持ってできるようになるので、けっこう定量的な目線で作り過ぎを防げるようになったというのが、今回あった話でした。
「良い話ばかりしていて、なんか悪いことは起こらないの？」という話が気になるかなと思うんですが、今のところはちょっと見えていない感じです。この仕組みが走り出しておよそ2ヶ月ぐらい経っているんですが、けっこう良い感じになっているというのが正直な感想です。ぬか喜びにならないことを祈っています。
はじめの1歩の踏み出し方 PM編
最後に、はじめの1歩の踏み出し方をすごく具体的に……。僕たちのチームでどういうふうにやったかというお話をします。一言で言ってしまうと、「PMとエンジニアのそれぞれがどういうところに責任を持つのかという境界をちゃんと見直しましょう」ということを、もしチームの仕様検討がボトルネックで悩んでいる人がいたら、ちょっと考えてみてほしいなと思っています。
それぞれPMとエンジニアで意識してほしいというか、僕たちがやったことがあって。まずはPMの方の話からします。PMの方は「3つをちゃんと明確にしましょう」というのが言いたいことです。課題、スコープ、ゴール。この3つです。
課題は、当たり前なんですが、「ユーザーはどういうところにペインがありますか？」という話をちゃんと明確にしましょう、という話です。「当たり前だろ」と思うかもしれないんですが、できていないことが意外と多かったりする例はあると思います。
僕は次がけっこうメチャクチャ大事だなと思っていて。「やることとやらないことをちゃんと明確にしましょう」というやつですね。課題があって、それに対してアプローチが薄っすらと頭の中にある状態の時に「こういう機能を提供しましょう」という話はできると思うんですが、やらないこと、「スコープアウトしますよ」ということを事前に決めるのが明確に大事かなと思っています。
これをやらないでエンジニアに「仕様検討をやってね」と言うと、スコープが無限に広がったり、「どこまでやったらいいんだっけ？」みたいな感じで悩みが発生してしまうので、スコープの明確化はメチャクチャ大事かなと思います。
最後にゴールですね。これはもう、課題に対する解決策が出された時に「どういう状態になるんだっけ？」ということをちゃんと明確にしましょうという話です。
はじめの1歩の踏み出し方 エンジニア編
エンジニア編です。これは「仕様検討をスムーズにするためにどうやったら良いか」という、けっこうHow寄りの話です。幅出しと、比較と、決定という3つです。
幅出しは、要は松竹梅とかの幅を持ってHowを出しましょうという話です。1つだけ仕様をポンって出しても、良いのか悪いのかが、判断できないんですよね。
できるなら3つですが、2つでも良いです。比較できるようにして、「こっちとこっちの提案があります。どっちのほうが良いですかね？」ということが語れるようになるとすごく良いと思っています。
あとは比較ですね。案出しが2つ、3つできたら、ここはみなさん自然にできるかなと思うんですが、メリデメであったり工数であったり、判断するにあたっての判断材料をもっと肉付けしてあげるのが大事かなと思っています。
最後は意思決定をちゃんとしましょうという話で、これは投資対効果とかいろいろと材料が出ると判断軸が出てくるんですが、そのあたりを踏まえつつ、PMの方とキャッチボールして意思決定ができるとメチャクチャ最高という感じかなと思います。
PMの方はしっかりとWhatを握り、エンジニアはHowの提案をやってみよう
まとめです。いろいろとしゃべったんですが、仕様検討の手戻りにもし悩んでいる方がいたら、これはあくまでも僕たちのチームでうまいこといった話なので、プロジェクトとかチームによっても変わるかもしれませんが、「PMの方はしっかりとWhatを握りながら、エンジニアはHowの提案をやってみよう」とすると、うまいこといくかなと思っています。
という感じです。というわけで僕の発表は以上になります。ありがとうございました。
