Timersでプロダクトマネージャーしてます わた と申します。メガネとウイスキーとコーヒーを愛するメガネです。ついに、深みの入口、ボトラーズ系ウイスキーに手を出しつつあります。
さて、今回はTimersで主に採用されている開発方式であるアジャイルの中でも、SCRUMの成功要件のひとつについて、お話ししたいと思います。が、その前に、そもそもどんな体勢でプロダクトマネジメントをしているのか？を整理したいと思います。
誤解を恐れず言ってしまえば、POなきプロジェクト制のプロダクトマネジメントです。なんじゃそりゃ！？と思った方は、続きを読むから、ご一読ください。
POなきプロジェクト制のプロダクトマネジメント
Timersでは、「プロダクトの全部は俺が決めるぜ！」的な意味での絶対神的なプロダクトマネージャー（PO：プロダクトオーナー）は明確には定義されておらず、プロダクトマネージャー組織や経営陣を交えた合議によってプロダクトバックログ（開発項目/施策）の優先順位をつけるといった運用をしています。
また、各プロダクトバックログは概ねFeature等の開発を伴うものとなっており、それらの単位で開発プロジェクトを起こし、そこで基本的にはSCRUMが採用されており、そこにはSCRUMでいうPO(Product Owner)/SM(SCRUM Master)/TEAMが存在します。プロジェクトの規模が小さいとSMがいなかったりはします。
Timersでは、POをプロダクトマネージャー職のメンバーが担当することが多いのですが、ここでいうPOはプロジェクトのFeatureを開発する前提として妥当な範囲のユーザーストーリー部分の物作りを任されているという状態です。つまり、PO/プロダクトマネージャーは全体像を意識しながら、個別Feature開発プロジェクトでは、ものづくりへのコミットが求められる状態となります。
Feedback文化
じゃあ、どうやってそのプロダクトとしての一体感を醸成していくのか？という問いが生まれますよね。そこで、出てくるのが、Feedback文化です。
わかりやすくいうと、「広く意見をもらおう」ということです。ユーザーストーリーや機能の概要や数値的な狙いをまとめたもの※へも、意見をもらう。画面のデザインができれば意見をもらう。出荷可能と思われるプロダクトができた場合にも意見をもらう。この意見だし、意見をもらうという姿勢は立場の上下、所属組織の如何に関わらず誰でもやるということです。
※プロダクトマネジメント用語でいう、個別の機能開発におけるPRD(Product Requirement Document)のことだと思っていただいて良いと思います
心優しい穿った読者の方は「ふふん、それは決められない病にかかるに違いない」と思ったことでしょう。そこで、登場するのが、用語の定義よろしくPOですね。プロダクトオーナーです。意見は無限に拾い続けても、それこそ意見の中での矛盾も出れば、個々人の好みも出てくる。全てを拾っては決められないので、そこを決めて前に進めて行く役割があるのがPOです。わかった上で取捨選択するのです。
この意見をもらうこと、意見を出すこと、そして決めて前に進むこと。結果、プロダクトが良いものとして育つ土壌。これを、Feedback文化と呼んでいます。
そこでSCRUM
と、このようなFeedback文化の中で、開発手法として取り入れられているのがSCRUMです。これがまた難しいんですよね。アジャイルサムライを読んでも、エッセンシャルスクラムを読んでも、心の底からスクラムパーソンになって、スクラムすることが難しいんです。（だから、楽しいとも言える）
そんな中、様々なキャリアや技術を持つメンバーとプロジェクトをするわけです。いきなり簡単にできるわけがない。
- もっと仕様詰めてからプロジェクトしましょうよ：いやユーザーストーリーは考えたんだけど…
- え？これ動いているんですけど、さらにコントロールが難しい挙動させるんですか？：それ自体は出荷可能プロダクトなのはわかるけど、Feedbackを経て、また、POとしても求める水準はもっと高みにあるんだ
- 他のプロジェクトとの掛け持ちで忙しいのでDaily SCRUM欠席で！：Daily SCRUMは本来、メンバーのためのものだよ！！
と、教科書には書いてないが、日本の文化的にありそうな事象は普通に発生します。まぁ、ここは日本ですからね。そして、みんな色々考えて動いていることもわかるので、否定する気も起きないのです。
でも、プロダクトマネージャーは折れてはいけません。それが、プロダクトマネージャーだからです。プロダクトマネージャーが折れるということは、プロダクトを諦めることになるからです。頑張ろう。酒飲もう。
言いたかったことは、まだまだSCRUMの運用自体も成長過程にあるってことです。
エンジニアである前に、デザイナーである前に、チームのメンバーなんだ
ようやく主題「SCRUMの成功要件のひとつ」です。先に、僕がメンバーとして参画したプロジェクトでの学びです。シンプルなことなのですが、「エンジニアである前に、デザイナーである前に、チームのメンバーなんだ」ということです。
昨今、はてな界隈でエンジニアとしての立ち居振る舞いとか流行っていますが、それ以前に、チームのメンバーで入っている限りは、エンジニアである前にチームのメンバーなんです。そして、Timersには上述のFeedback文化があるのです。
チームのメンバーであれば、UIデザインに意見を出すべきだ。チームのメンバーであれば、ユーザーストーリーの解釈や実現に意見を出すべきだ。それは、エンジニアやデザイナーといった職種/職能以前に、なすべきことだってことです。
例えば、僕はデザイナーでないけど、誤字脱字は見つけることができるし、文字配置に違和感を発することはできます。僕はエンジニアリングはしないけど、論理的にありえそうなイレギュラーケースはどうする？的な質問はできたりします。チームの中でクリティカルパスになりそうな遅延タスクがあれば、それを声に出して（Slackに書いて）質問することができます。
だったらやろう！それがチームのメンバーとしてやることなのだから。
そういう考えを是とするならば、上述した「他のプロジェクトとの掛け持ちで忙しいのでDaily SCRUM欠席で！」ってのは、猛烈な悪なわけです。仮に忙しいのであれば、それはオーバータスク状態なので、マネージャーと掛け合うべきだし、仮に自分の担当部分の実装が終わっていたのであったとしてもメンバーとしての責務は終わっていないのです。
それ、SCRUMじゃね？
はい。そうです。仰々しく、かつ、長々と書いてきましたが、チームのメンバーがチームのメンバーとして前向きにガッツリと取り組む。職種/職能は発揮することは当然としながらも、職種/職能以前にメンバーとしてチーム、ひいてはプロダクトにどのように貢献できるのか？を考えながら、能動的に取り組んでいる状態とすることです。
これを、文字どおり、スクラム、がっぷり四つでグイグイ前に進む様子というのですね。
現場の実践で見つけたSCRUMの成功要件のひとつ、それはSCRUM（という姿勢）のチームだよ、という話でした。
積極採用中!!
子育て家族アプリFamm、カップル専用アプリPairyを運営するTimers inc. では、現在エンジニアを積極採用中！ 急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください！ 採用HP : http://timers-inc.com/engineerings
