テクニカルプロダクトマネージャーとして考えていること#2「テクニカルプロダクトマネージャーの役割②」
フルカイテンでテクニカルプロダクトマネージャーを担当しているパンサー師匠です。
今回はテクニカルプロダクトマネージャーの役割の1つである「ビジネス要件と開発チームの橋渡し役」について語りたいと思います。
前回の振り返り
前回はプロダクトマネージャーの定義を紹介すると共に、役割の1つである「プロダクト開発においてビジネスと技術のバランスを取る」について語りました。今回はその続きとなるため、未読の方は以下から確認いただくと、より今回の話が理解しやすいかと思います。
ビジネス要件から動くものができるまで
「ビジネス要件と開発チームの橋渡し役」と聴いて、どんなことを感じるでしょうか。
「そんな役割は必要だろうか？」「ビジネス要件の担当者と開発チームが直接コミュニケーションを取れば済む話では？」と感じた方もいるかと思います。
必要性を論じる前に、まずはビジネス要件から動くものができる過程について話したいと思います。
ビジネス要件はそれだけでは何の価値も生み出しません。ビジネス要件を適えるプロダクトを開発し、それをユーザーに利用いただくことで、やっと価値を提供できます。
それでは、ビジネス要件がプロダクトになるまで、どのような過程があるでしょうか。ウォーターフォール開発の工程で言うと以下のようになります。
要件定義
基本設計
詳細設計
実装
単体テスト
結合テスト
システムテスト
リリース
上記の「要件定義」は、ビジネス要件を適えるためのシステム(あるいはプロダクト)の要件定義を指している点にご注意ください。ビジネス要件の要件定義ではありません。
動くものができるまでの工程にフォーカスすると、ビジネス要件が実際に動くプロダクトになるには、要件定義、基本設計、詳細設計、実装と4つの工程が必要です。
では、なぜビジネス要件から実装に辿り着くまでこれほどの工程を挟まないといけないのでしょうか。ビジネス要件からすぐに実装することはできないのでしょうか。
ビジネス要件とコードのギャップ
実装とは、プログラムのコードを書くことですが、プログラムのコードを書くには、書くべき要素が揃っていて、かつ、具体的である必要があります。曖昧なものが1つでもあるとコードにはできません。
一方で、ビジネス要件の中身はどうでしょうか。
ビジネス要件は、ユーザーにとっての理想を表現したものであるべきで、どのように実装すべきかは情報として含まれていないことが普通です。要はユーザーにとっては実装なんてどうでも良いのです。
そう考えると、ビジネス要件とコードの間には大きなギャップがあると思いませんか。ビジネス要件から動くものができるまで、4つの工程が必要な理由はまさにここにあります。
どのように実装すべきかは書かれていないビジネス要件を基に、実装すべき要素を漏れなく100%明確にする必要があり、それをいっぺんにやることが難しいから、4つの工程を設けて少しずつ具体化していると言えます。
ビジネス要件によって規模や難易度は大きく異なるため、例えば「詳細設計は省略しても問題なく進められそうなため省略する」というケースもあるかと思います。ただ、そのようなケースにおいても、省略しているのはドキュメントに残して内容を確定させるという行為であり、詳細設計の本質的な部分、つまりコードに近づけるために徐々に具体化させるという行為は開発者の頭の中で行われているはずです。
ここまで読んで、「うちの場合、ビジネス要件に実装すべきことが書いてあるけど・・・」と思った方もいるのではないでしょうか。
そのような方は注意が必要かもしれません。
なぜなら、ビジネス要件が実装についての事項を多分に含んでいる場合、ビジネス要件が実装に寄り過ぎている可能性があるためです。
そうなると本質であるユーザーの理想を十分に表現できていなかったり、見てもユーザーの理想が分からないということになります。5W1Hで言うと、Whatは分かるしHowは想像できるけど、Whyが分からないという状態でしょうか。そのようなビジネス要件はビジネス要件としての役割を果たせていないと言えます。
もちろんユーザーの理想をしっかりと表現した上で、補足情報として実装したいことを書いてあるのであれば、それほど問題はありません。
アジャイル開発の場合
説明の都合上、ウォーターフォール開発における工程を取り上げましたが、4つの工程が必要というのはアジャイル開発であったとしても同じことです。
アジャイル開発の場合、ウォーターフォール開発のように工程毎に内容をドキュメントに落として確定させる、ということはしないため、明確な工程が無いこともあるかと思います。
ただ、ビジネス要件とコードのギャップを埋める必要があることはウォーターフォール開発と同様であり、どこかでウォーターフォール開発における要件定義〜実装に該当することが行われているはずです。
小さく早くリリースし、フィードバックを得て改善するサイクルを回すことに重きを置いたり、仕様変更に寛容だったりする点は違いとしてありますが、本質は変わりません。
アジャイル開発でも実装すべき要素が漏れなく100%明確になっていなければコードにできないのです。
ビジネス要件と開発チームの橋渡し役
では、「ビジネス要件と開発チームの橋渡し役」はなぜ必要なのでしょうか？
それは前述の通り、ビジネス要件とコードの間には埋めるのが難しいギャップがあるからです。
裏を返すと、ビジネス要件とコードの間のギャップを埋めるのが難しくないケースにおいては、必要ではないと言えます。
そして、その難易度を決めるのは以下の2点です。
ビジネス要件の解釈難易度と実現可能性
開発チームの実力
ビジネス要件は多種多様です。開発者が見て、すぐに解決策を思い付くようなものもあれば、意図がよく分からず解決策を検討するスタート地点に立つことすら困難といったレベルのものまで様々です。また実現したいことは分かるけど、実現手段が思い付かないということもあると思います。
そして、ビジネス要件をどう捉えるかは開発者次第です。
開発チームも多種多様です。まず構成するメンバーは皆、能力が違いますし、それぞれに得手不得手があるのは当然です。
チーム構成も百戦錬磨の実力者揃いというチームもあれば、比較的経験が浅いメンバーで構成されている場合もあります。
開発チームが、ビジネス要件が関わるドメイン知識を高いレベルで備えていて、解釈難易度が高いビジネス要件でも難なく消化してしまうこともあるでしょうし、逆に開発チームにビジネス要件がなかなか正しく伝わらないということもあると思います。
「ビジネス要件と開発チームの橋渡し役」が果たすべきことは、ビジネス要件がコードになるまでの一連の過程で、開発チームがスムーズに動ける状態まで持っていくことです。そのため、ビジネス要件と開発チームの関係により、果たすべき役割の範囲は変わってきます。
開発チームが上流工程の経験が少ない場合、その領域をある程度担う必要もあるでしょう。あるいは経験が少ない場合でもあえて任せてサポート役に徹して、成長を期待するような場面もあるかもしれません。
つまりこれさえやればOKというものはなく、状況に応じて果たすべき役割を見出して実行していく必要があります。
「ビジネス要件と開発チームの橋渡し役」は多くの組織において必要な役割と考えます。なぜなら、ビジネス要件と開発チームの間には状況に応じて大小様々な溝が発生するものだからです。その溝を適切に埋めていかなければスムーズな開発は望めませんし、出来上がったプロダクトが期待に沿わないものになってしまうということすらありえます。
「ビジネス要件と開発チームの橋渡し役」をテクニカルプロダクトマネージャーの役割の1つとして挙げましたが、必ずしもテクニカルプロダクトマネージャーが担う必要はありません。
重要なのは肩書より役割です。
例えば、開発チームのベテランメンバーが担っても良いと思います。
実際にテクニカルプロダクトマネージャーを置いていない組織においては、開発チームのメンバーがその役割を暗黙的に果たしているということはあると思います。
一方で、テクニカルプロダクトマネージャーを置いて、役割として定義することにより、責任の所在が明確になり、より開発がうまく回るということもありえるでしょう。
まとめ
いかがでしたでしょうか。
今回はテクニカルプロダクトマネージャーの役割の1つである「ビジネス要件と開発チームの橋渡し役」について深堀りしてみました。
最後に改めて私が考えるテクニカルプロダクトマネージャーの定義を紹介しておきます。
プロダクト開発を行う組織における1つのポジションであり、(ビジネス寄りの)プロダクトマネージャーと共にプロダクトの成功に責任を持ち、プロダクト開発においてビジネスと技術のバランスを取りつつ、ビジネス要件と開発チームの橋渡し役を担う者
ではまた次回にご期待ください！