はじめに
こんにちは、Repro Booster という製品の開発責任者／プロダクトマネジメントを担当しているEdward Fox（edwardkenfox）です。
前回の記事「ServiceWorkerの落とし穴8選」では ServiceWorker という技術に的を絞ったテクニカルなトピックを扱いましたが、今回は少し趣を変えて「プロダクトマネジメント」に関する私の考えや想いを書いてみたいと思います。Repro Boosterの開発と運用を通して自分なりに「プロダクト開発」について考えたことや、得られた示唆をまとめています。Repro Boosterの開発チームが、どのような考え方を持ってプロダクトや技術に向き合い、そして製品を改善するべく日々の活動にあたっているかという点について、少しでもその温度感や熱量が伝わるような記事になれば幸いです。
Repro Booster とは
2022年11月に正式リリースした、ウェブサイトの表示速度向上を実現するサービスです。「タグを入れたその日から、Webサイトが速くなる」というコピーのもと、タグ（JavaScript）の設置だけでウェブサイトの表示速度が簡単に実現できるということで、リリース以来多くのお客様・サイトでご利用いただいています。
Repro Boosterというプロダクトの原型は私のプロトタイピングと起案から始まったもので、ごく初期の技術的な検証を終えたのちに本格的なプロジェクトとして始動しました。以後の開発は業務委託の方とのコラボレーションや、正式なチーム化といった変遷を辿り、少数精鋭の開発メンバー + 事業開発のメンバーで構成される組織となっています。開発がチーム化されてからは、私はいわゆるエンジニアとプロダクトマネジメントを兼務するプレイングマネージャー的な立ち位置で関わることとなりました。事業開発の責任者らとプロダクトの大きな方針を決めながら、開発ロードマップを策定したり、チームの活動をリードする立場としてプロダクト開発に携わってきています。
プロダクトづくりの難しさ
Repro Booster の起案は2021年頃まで遡り、プロジェクト化の当初より Repro の既存の製品群からは独立した新規事業としてスタートしました。技術的なR&Dや事業のPDCAを回す活動を多く行ってきた上で強く感じているのが、プロダクトをつくることは本当に（それはもう本当に！）難しいということです。さらに、プロダクトづくりの難しさというのは、技術的な難易度やコード／システムの複雑性よりも大きいものである、という点を強調して伝えたいです。これは考えてみれば至極当たり前の話ではあるのですが、あるプロダクトについて、そのプロダクトを実現している方法論（プログラム、アーキテクチャ）はプロダクトの1つの要素にすぎません。プロダクトは他にも多くの側面から成り立っているため（提供方法、価格体系、販売戦略、運用プロセスなど）、プロダクト全体の難易度／複雑性は、部分のそれの総和よりも大きくなります。ことさら新規事業においては、プロダクト開発は技術的な側面に終始してしまうのではなく、常に「顧客は誰か」「顧客が抱えている課題は何か」「我々が解くべき課題はどれか」といった「事業的な」観点から、少ない生産資源をどこに投下するかをシビアに見極めることが要求されます。これは、課題を解くための手段である技術そのものが目的化してはいけない、と言い換えることも出来ます。
一方で、技術を深く掘り下げ尖らせたり、応用の分野や場面を変えることでイノベーションが起こることも事実で、チャレンジングな技術によって形作られる事業の方向性や製品としての「エッジ」というものも確かに存在します。「ハンマーを持つと全てが釘に見える」という有名な言い回しがありますが、これは一般的には「手段を目的化してはいけない」という戒めの言葉として利用されるものです。しかしながら、ハンマーは釘を打つためだけの道具ではなく、釘を抜いたり、釘以外の様々なものを叩いてみたり、あるいはハンマーの新しい使い方を試すことで発見できる新しい利用価値が存在するかもしれません。そういった意味では、手段（技術）の目的化をむしろ積極的に推し進めることで、新しい事業／プロダクトが生まれうることも忘れてはなりません。
話を戻すと、プロダクトの技術的な側面と事業的な側面のどちらにより比重を置くべきか、という議論はあまり重要ではないと私は考えています。より現実的なニュアンスを伴って理解されるべきなのは、多くの側面から成り立つ総体としての「プロダクト」が存在し、フェーズごとに変わっていく「いま足りていないもの」「いまやるべきこと」を見極め、そこに全力を注ぐための意思決定をすることこそが大事だ、という点です。これには非常に繊細なバランス感覚と大胆な判断力を求められ、ある種の冷徹なまでの客観的な眼差しも必要とされます。私自身、この点が十分にできているかというとそうではなく、もっとうまく出来たんじゃないかと反省する経験ばかりです。しかし、やはりそういった活動を通してのみ「プロダクトづくりの難しさ」に向き合うことができ、またその難しさと向き合うことでこそ製品開発が自然と前に進みます。この意思決定の本質的な難しさからは決して逃げてはいけないのです。
ハンマーで全てを叩いてみることで見つかる何かがある。かもしれない。
「対話」の重要性
新規事業はあらゆる側面で高い不確実性を抱えており、特に初期の段階において技術的なアイデアのみを起点としてロードマップを引いてしまうと、かえってプロダクト開発の歩みは遅くなってしまうことがあります。私が経験的に学んだこととして、プロダクト開発を推し進めるキードライバーは、開発メンバーと事業メンバー（あるいは顧客自身）とのコミュニケーション、もっと言うと相互の関心と共感にもとづいた「対話」である、という点があります（もちろんそれ以外のケースも多く考えられます）。いくら初期のプロダクトはコードベースが小さいからといって、考え得るすべての仮説やアイデアをしらみつぶしに実装し、リリース・検証する余裕があることは稀でしょう。重要なのは、テーブルの上に広げられた数ある仮説や可能性の中から、「より確からしいもの」や「後の意思決定にレバレッジが効くもの」を拾い上げることです。もっとも簡便かつ有効なのはドメインエキスパートや事業開発のメンバーと対話することで、対話を通してそのプロダクトにとってのドメイン知識が発見・言語化され、それがシステムの設計や技術選択における軸となる、と私は考えています。
開発に携わるメンバーと事業に携わるメンバーは、往々にして知識・経験も大きく異なり、そういった要因を背景にともすればメンバー／チームの間に溝が生まれることがあります。開発側は「営業は技術のことを分かっていない」と揶揄し、事業側は「開発はビジネスを知らない」と距離を取る図式は、悲しいほどにありふれたものとなってしまっています。しかしながら、知識や経験が非対称であることを所与の固定化された事実として受け取ってしまっては、創造的なコラボレーションの機会をみすみす失ってしまいかねません。ソフトウェアが事業の核となる限りは、どんな職責や役割であっても技術を理解する努力は必須です。反対に、いくらテクニカルなプロダクトであっても、それを事業として成立させるためにはビジネスの文法やノウハウは当然として必要とされるため、開発に関わる人間もドメイン知識を獲得しビジネスの言語を話せるようにならなければいけません。役割や立場に関わらず「プロダクトと事業にとって、いま必要なものは何か」を考え議論する土壌を作ることこそが肝要であり、その触媒となるのが対話だと考えています。
Repro Boosterの開発最初期のことを例に出します。当時はどのような機能や実装が速度の向上に貢献するかを検証する目的で、サイトごとに細かい機能を調整できるよう設定項目として作り込む形で機能性を高めていました。始めのうちはこれで良かったのですが、項目が増えるにつれ設定の手間が煩雑になり、導入までのリードタイムが増えてしまう結果となってしまいました。また導入いただくサイトが増えて分かったこととして、多くの顧客は柔軟な設定よりも入れただけでちゃんと動作し効果を発揮するサービスを求めている、という点があります。事実、設定項目のほとんどは滅多に変えられることがありませんでした。事業側のメンバーとも対話・議論を重ね、Boosterの製品設計としては設定を細かく調整する前提ではなく、「Convention over Configuration（設定より規約）」よろしく適切なデフォルト値を持たせる形にしていくべきだろう、という結論に至ります。そういったをプロセスを経て「タグを入れるだけでサイトが速くなる」という製品コンセプトが研ぎ澄まされ、より使いやすく効果の高い製品になっていきました。
こうした対話とコミュニケーションを通じて共有された気付きや知識（≒ ユビキタス言語の元となる）が仮説を生み、その仮説の検証によって得られた知識を用いて一歩進んだ仮説を立てる、という活動を繰り返すことができるようになります。そして、このサイクルをいかに高速に実施できるかが新規事業にとっての大動脈であり生命線です。さらに、この繰り返しの中で言語化されるドメイン知識が、事業と製品とが進むべき先を指し示す羅針盤となります。
余談ですが、私は過去には「開発」と「事業」という区分を設けることそれ自体が本質的でなく、かえってセクショナリズムを助長するのではないか、と考えていた時期もありました。確かに、こういった区分が互いを「分け隔てる壁」として使われる場合は、いっそ取っ払ってしまった方が劇薬的な恩恵を得られるかもしれません。しかしながら、それぞれの職責を全うしながらも「混ざり合う」ことが組織にとって是とされており、かつ組織内のコミュニケーションの風通しが良い場合には、こういった区分は責任範囲を明確にすることに役立つため、害のあるものではないと考えるようになりました。
ハッカーと画家
少し話の趣を変えます。私の好きな書籍の1つに、ポール・グレアムによる「ハッカーと画家」があります。AirBnBやDropboxなど多くのユニコーン企業を輩出したスタートアップ・インキュベーター「Yコンビネーター」の創始者としても有名なグレアムですが、この本の中で「ハッカーと画家はよく似ている」という主張を展開します。曰く、「作品（= プログラム）というのはその制作の過程において全体の輪郭が見えてくるものであって、それに修正を加えながら全体像自体もブラッシュアップされていく」と言います。この書籍の中で述べられているのは純粋なプログラム／ソフトウェアについてですが、最近になってこのアナロジーはプログラムに留まらずプロダクトを作る活動の総体に関しても適用できるのではないか、と思うようになりました。
同書よりいくつか文章を引用します。
作家や画家や建築家が、創りながら作品を理解してゆくのと同じで、プログラマはプログラムを書きながら理解してゆくべきなんだ。
プログラムの仕様が完璧であるなんて期待するのは非現実的だ。そのことをまず最初に認めて、仕様がプログラムを書いている最中に変わっていっても、それを受け入れられるような書き方をすべきなんだ。
表現にバリエーションはありますが、大筋の意味合いとしては、プログラミングというものは初めから固定化された最終状態を形成するプロセスではなく、形成のプロセスにおいてこそ最終的な形態が立ち上がってくるものである、というものです。非常に含蓄のある言葉ですね。
すでに多くの示唆が満ちた洞察ではありますが、私はRepro Boosterの開発を通して、このアナロジーはプロダクトを作る行為や活動についても同じようにあてはまるのではないか、と考えるようになります。つまり、「プログラムを書く」という部分を「プロダクトを作る」に、あるいは「プログラマ」を「プロダクトマネージャー」に置き換えても成立する、という着想です。先にも引用した元の文を置き換えてみると
「プログラマーがコードを書きながらソフトウェアを理解してゆくのと同じで、プロダクトマネージャーはプロダクトを作りながら理解してゆくべきなんだ」
となります。
私個人としては、プログラミングという活動が、書いては消しを繰り返しながら全体像を理解し、その反復の中で設計を洗練させていくものである、という感覚は経験的に馴染みのあるものでした。一方で、一般的にプロダクトを作る過程は「流れ作業」のように捉えられる場面が多く、上流工程（要件定義や設計）と下流工程（実装やQA／リリース）に分けて語られることがあるのに違和感を抱いていました。アジャイル開発の考え方や、スクラムといった手法に関する書籍も多く読み実践する中で、自分自身の手触りとしても「上から流れてきた仕様を、上から順に作り込んで、全部が完成したらリリースする」というやり方がことSaaSという事業においては適合しない肌感はあったものの、どうにも言語化ができずにいました。そんな時にこのアナロジーを思い付くに至り、喉につっかえていた小骨が取れたような爽快感があったのを覚えています。言うなれば「そう、これでいいのだ！」という腹落ち感です。
これは、全ての計画や予測は無意味であり悪である、あるいは常に場当たり的に対処すべきである、といったことを意味しません。ソフトウェア事業を展開していく上で計画は必ず必要で、その重要性は無視されるべきではありません。ただし、その過程において製品の仕様や最終的な形態・提供価値に「ゆらぎ」が生じることも計画に織り込まれているべきです。また計画に時間的なバッファを持たせれば良い、という単純な話でもありません。SaaSの業界では市場環境やニーズの変化も早く、そういった中で顧客に刺さる製品を作り提供するには真に「アジャイル」なものづくりが求められます。こういった状況下では最初から厳格なものを作り込みすぎないようにし、あえて余白を持たせることが大事になります。作る過程で「何を」「どのように」作れば良いのかが見えてくることは多々あり、見えてきた方向性に沿ってやり方を変えるダイナミズムに身を委ねる胆力が必要です。不確実性は忌み嫌うべき対象ではなく、組織や事業に非連続的な成長をもたらす変数として、むしろ歓迎して受け入れるべき存在となります。
偉大な絵画も偉大なソフトウェアも、"美に対する熱狂的な没頭"が必要な点で同じだという。偉大なプロダクトについても、同じことが言えるだろうか？
原典への回帰
アジャイル開発に関する書籍は数多く存在しますが、アジャイル開発の原典となっているものが何かはご存知でしょうか。ケント・ベックやマーティン・ファウラーらが2001年に公開した「アジャイルソフトウェア開発宣言」という、非常に簡潔で示唆に富んだ文章がその元祖となっています。私自身、アジャイル開発やスクラムをテーマとした書籍は様々読んできましたが、最終的にはアジャイルソフトウェア開発宣言で重要な点は全て指摘されており、これ以上に端的に分かりやすく説明しているものはないと考えるようになりました。
アジャイルソフトウェア開発宣言には次のように書かれています。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck、Mike Beedle、Arie van Bennekum、Alistair Cockburn、Ward Cunningham、 Martin Fowler、James Grenning、Jim Highsmith、Andrew Hunt、Ron Jeffries、 Jon Kern、Brian Marick、Robert C. Martin、Steve Mellor、Ken Schwaber、 Jeff Sutherland、Dave Thomas
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
アジャイルソフトウェア開発宣言は引用されることも多いので、部分的にでも読んだことのある方も多いのではないでしょうか。なおアジャイルソフトウェア開発宣言には、その内容を補足するための「アジャイル宣言の背後にある原則」というものが存在します。あまり光が当たることはないのですが、個人的にはこちらの方がより具体的で詳細な記述があり、より分かりやすくアジャイル開発の本質を表しているように想います。いくつか引用して見てみましょう。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
痺れますね。これらの記述は、私がこの記事を通して書いてきた内容とも非常に良く整合します。開発と事業の人間は日常的に対話の場をもち、スムーズに連携して働く必要があります。また要件の変更といった不確実性は、むしろ新しい知識を提供してくれる機会として歓迎できるだけの準備があると、創造的な活動は自然と生まれます。
振り返って考えてみると、私がこれまで培ってきた感覚知は、すべてアジャイルソフトウェア開発宣言およびアジャイル宣言の背後にある原則に集約されていた、と思えるほどです。失敗を繰り返しながら多くの試行錯誤をしてきましたが、結果的には偉大な先人たちの教えを踏襲していたようで、この事実にはとても勇気付けられます。そして「巨人の肩に乗る」ことがいかに大事か、あらためて痛感している次第です。
まとめ
Repro Boosterの開発と提供を通して私が獲得した気付きや考えについて、「ハッカーと画家」や「アジャイルソフトウェア開発宣言」を参照しながら紹介しました。Repro Booster事業部におけるLookerを使ったデータ活用の取り組み の記事の中で「導入中サイトのパフォーマンスウォッチ会」という取り組みが紹介されていますが、これは私達が実践している「開発とビジネスのコラボレーション」の分かりやすい例でしょう。これ以外にも、アジャイルソフトウェア開発宣言やアジャイル宣言の背後にある原則をいかに組織や製品のアーキテクチャに実装するか、という点に心を砕いて日々の活動に従事しています。
色々と耳当たりの良いことを書いてはいますが、Repro Boosterという製品および事業はまだまだ成長過程にあり、理想とする状態からはギャップがあります。刻々と様変わりする課題と日々向き合う中で、どういった考え方のもと業務に従事しているか、その熱量が少しでも伝わる記事になっていれば嬉しく思います。また、この記事が開発とプロダクトマネジメントの狭間で苦悩する人たちにとって、少しでも新しい視点を得るきっかけになったり、あるいは「これでいいのだ！」と思える一助となれば何よりです。
ということで、Reproでは大量のデータを活用したマーケティングオートメーションだけでなく、Repro Boosterといった新製品の開発にも積極的に取り組んでいます。事業としても技術的な観点からもチャレンジングな環境なので、ぜひ興味を持たれた方はWantedlyからお気軽にご応募ください！
https://www.wantedly.com/companies/Repro/projects
※この記事内の画像はすべてDALL·E 2によって生成したものを利用しています。
