今回のブログは、以前 JIRA Software の Principal Product Manager (プリンシパル・プロダクト・マネージャー) である Jason Wong が Atlassian User Group Tokyo で、JIRA Software の開発のバックシーンと自身のプロダクトマネージメント法について日本語で登壇した内容をブログにまとめました。（執筆：犬山 奈穂）
アトラシアン製品のユーザが主体となってユーザ同士の交流イベントなどを実施しているコミニュティです。世界のいたるところにコミニュティが存在しており、日本にも 東京だけでなく名古屋、大阪、中国地方 などのコミニュティがあります。
JIRA Software の開発チームの構成
JIRA Software は、シドニーを拠点とし、開発者、デザイナー、テクニカルライターとプロダクトマネージャーを中心として開発されています。チームメンバーの平均年齢は比較的若く、世界 12カ国から意志が強い優秀な人材が集まっています。私たちにとって多様性はイノベーションを起こすのに重要な要素だと考えており、アトラシアン社員の多様性に関するデータ から、現在の社員の平均年齢やその他多様性の割合が公開されています。
JIRA Software は、デザインと開発のチームがあり、ジェイソンは Principal Product Manager (プリンシパル・プロダクト・マネージャー) として、デザインのリードと開発マネージャーと「Triad」(= 「三人組」という意味) というグループを組み、JIRA Software チーム全体を管理しています。
プロダクトマネージャーの仕事
より良いプロダクトマネージメントを行うためには、開発者とデザイナーと共に積極的にユーザーエクスピリエンスを把握し、課題を解決する必要があります。例えばアトラシアンでは、様々なデザインコンセプトを付箋に書き、壁に貼り付けています。これを元に議論を重ねながらユーザーにとって最良のものを提供できるようにしています。
さらに、プロダクトマネージャーとして、製品のことだけでなく、議論を意味のあるものにするために、開発者だけじゃなくデザイナーとの関係も非常に大事になります。
「プロダクトマネージャー」と「プロジェクトマネージャー」の違い
「権力」がないプロダクトマネージャー
「プロダクトマネージャー」と「プロジェクトマネージャー」はどちらも「PM」として訳されるため、よくその役割が勘違いされます。この２つの大きく違う点は、プロダクトマネージャーの役割は、ユーザーの要望を理解して、ユーザーのためにいい製品を作る理由と結果を把握する仕事です。これに対してプロジェクトマネージャーはスケジュールの目的を達成するため、お金や人材の予算を管理する仕事です。
プロジェクトマネージャーの仕事は、分野がかなり幅広く「製品のCEO」と呼ばれることもありますが、ここでも大きく違うのは、プロダクトマネージャーには何かを「やりなさい」と言える権力は持っていません。
実は、これが重要で、権力で指示すると、ユーザーの要望がうまくチームに伝わらなくなり、チームと製品がユーザーの欲しいものからどんどん離れていってしまいます。したがって、ユーザーの状況を考え、思いやりのあるサービスのためにチームをうまく動かす「自然なリーダーシップ」がプロジェクトマネージャーにとって大切です。
プロダクトマネージャーの１週間
月曜日の朝 : コーヒーを飲みながらミーティング
先ほど説明した「Triad」の３人でコーヒーを飲みながら、どうしたらチームをうまく動かすことができるのか、チーム間での作業が必要か、リリースしたい機能などについて話し合い、その週の計画を立てます。
水曜日：「Boardwalk」= 「ボードを歩く」形式の会議で進捗を確認
実際のJIRA Softwareボードを使って、今のスプリントの状態をそのままレビューします。この会議のために、チームメンバーが事前に準備しておくことは特にありません。
スプリントの状態がレビュー次第で、バックログの課題を見直し、次のスプリント内容をまたみんなで共有します。また、この会議にはサンフランシスコにあるプロダクトマーケティングマネージャーたちもリモートで参加し、「どの機能がいつリリースできるのか？」といった情報を共有することで、マーケティングと協業しています。
プロダクトマネージャーとしては、それぞれのチームがお互いに連携し合っているか、依存関係を確認しながら、同じゴールに向かって進んでいるか、または調整が必要かどうかを見極めることができる会議です。
金曜日：デモを実際に体験しながらでフィードバックをする
実際に動作しているソフトウェアを見ながら、フィードバックをします。多くは、コードレベルでのデモですが、技術的な成果物だけでなく、開発者にどのようなことに取り組んできたかを話してもらい、新しいデザインやロードマップへ影響するアップデートがあれば、それも共有してもらいます。
プロダクトマネージャーも積極的に ユーザーエクスピリエンス を把握し、課題を解決する必要があります。そのために PM は開発者とデザイナーと共に、様々なデザインコンセプトを付箋を利用して、壁に貼り付けて、議論を重ねながらユーザーにとって最良のものを提供できるようにしています。
この時、お互いに遠慮することなく、意見を言い、評価だけでなく、批判もできる環境を造ることが大切です。アトラシアンの提供している Team Playbook (日本語準備中) では、ふりかえりとチームの心理的な健康状態をチェックできる便利なツールが無料で公開されていますので是非利用してみてください。
プロダクトマネージャーに必要とされるスキル
「自然なリーダーシップ」を確立しながら、プロジェクトマネージャーとして先ほど述べた仕事をより良く行うにはいくつかのポイントがあります。
チームだけでなくユーザーとも関わる
ユーザーの声を最も尊重して、チームとソフトウェアを作る心がけをしています。様々な新しい情報を駆使し、アイデアを出し合い、ユーザーの問題を解決していきます。
不確実性への対応
この世に、完璧なデータなどありません。予想していなかったことが、いつも出てきますが、臨機応変に対応することが大切です。
思い切った決断力
これがないと、チームの行き場がなくなり、何も動かなくなってしまいます。もし、自分で決断できない場合は、決断ができる人探して、その決断権を委託します。例えば、技術やデザインに関する決断なら、その分野に精通した triad の中の人に頼ります。ユーザーのために、ベストな決断をすることが一番大切です。
優先順位の管理
優先すべきものがはっきりわからないと、何に集中すべきなのかがわからずチームとしてうまく機能しません。プロダクトマネージャーとして、常に仕事の優先順位を検討しなければなりません。
開発の管理だけなく戦略も立てる：ロードマップの作り方
プロジェクトマネージャーは、以上の日常のタスクに加えて、戦略も立てます。冒頭に説明した通り、プロダクトマネージャーは製品を作る理由から結果までを把握する開発プロセスの端から端までの面倒を見るのが仕事です。
３つの要望からロードマップを作成する
ロードマップの作成方法にはいくつかありますが、私たちは「ユーザー目線を重視」したロードマップ作りを心がけています。
ユーザーから直接受け取る要望
製品の中にフィードバックボタンや、 NPS 調査 を組み込んだり、パートナーやサポートチームからのフィードバックをとったりして、常にユーザーの声が聞きやすい状態を作っています。また他にも、メールでユーザーにアンケートをとったり、JAC から機能リクエストを受け付けたり、既存のリクエストに投票できる環境をつくることで、どういうリクエストが一番多いのかがわかるように、積極的にユーザーの意見を聞くようにしています。
お客様の潜在的な要望
ヘンリー・フォードの名言に「もし自動車のない時代に、お客に何がほしいか聞いたら、もっと速い馬が欲しいと答えていただろう」というのがあります。これは、英語で「Unspoken Needs」と説明されるのですが、直訳すると「話されないニーズ」となります。これはどういうことかというと、ユーザーからの直接的なフィードバックを違って、ユーザーさえもまだ気づいていないニーズのことを指します。これを、ユーザーの利用データ等やユーザーの直接の声から、「分析」や「予測」して、見出すのです。
会社の要望
ユーザーにとって価値があるものを作るためには、ビジネスモデルも考える必要があります。例えば、チームと会社のリソースと持っている技術を考慮しなければ、うまく動くことができません。したがって、現実的な戦略を賢く立てる必要があります。アイデアを思いつくのは簡単ですが、実際にそれを成功させるのはなかなか難しいものです。
バランスのとれたロードマップを作成するには
しかし、先ほど述べた要望を全て製品に取り込もうとすると、要望が多すぎて八方塞がりの状態になってしまうことがあります。これを解決するには、意思決定するためのフレームワークが役立ちます。
ペルソナを利用する
JIRA Software のチームでは、ユーザーとなるペルソナを利用して、どんなユーザーのために製品を作るのかを考え、彼らが価値を置いていること、スキル、行動様式を考察します。特に、彼らがどのように課題をこなしているか、個人の観念やチームの価値観も含め、製品およびサービスのバリューマップを設計していきます。アトラシアンでよく使っている 3 人のペルソナを紹介します。
- Alana (アラナ) : プロジェクトマネージャー。バックログを設定し、いつプロダクトが完成するのかを予想する。
- Will (ウィル) : チームリーダー。いつもチームの効率性について悩んでいる。チームがアジャイルに動けない状態になってしまうことを心配している。
- Emma (エマ) : 開発者。開発のことだけに専念している。
アジャイルにリリースする
リリースという作業自体は、そこまで難しくありませんが、リリースしたものが実際に役立つかどうかを確かめるのは容易ではありません。JIRA Software のチームでは、アジャイル手法を取り入れて、開発中にもユーザーを巻き込んで開発できる仕組みがあります。
Labs 機能 (ラボ機能)
一般的に「Labs」（ラボズ）と呼ばれているこの機能は、ユーザーが新しい機能を試験的に利用することができるベータリリースの仕組みです。インスタンスの管理者が、この Labs の基に実装されている機能を有効化にすると、ユーザーはすぐに最新の機能を使い始めることができます。これらの機能はベータ版なのにベータ版なので、完璧なものではありませんが、逆にいうと、ユーザーの利用の仕方や意見によって仕様が変更されることもあります。JIRA Software に現在実装されている アジャイルレポートやカンバンのバックログ、スプリントの同時進行機能はこのベータリリースで開発されました。
ユーザービリティ オプトイン
UI の変更を行うと、開発者とユーザーの両方に大きな負担がかかります。私たちがユーザーのために、よりスタイリッシュでモダンなデザインを提供しても、使い勝手が変わり、逆にユーザーに拒否されてしまったなんていうケースもあると思います。また、たくさんのより良いデザインを考案しても、「どれが一番いいのか」を意見や予想だけで選ぶのは難しく時間がかかるため、その分開発チームのスピードも下がってしまいます。
この問題を解決するのに役に立ったのが、「ユーザビリティオプトイン」の仕組みです。いくつかあるデザインを製品に実際に実装し、「オプトイン」すると新しいデザインを試すことができるようになります。もし新しいデザインが気に入らない場合には、「オプトアウト」して、いつもの使い慣れたデザインに戻すことができます。このオプトアウトの割合を「拒否率」として、最も良いデザインを決めるための指標にします。
例えば、JIRA 6.4 でプロジェクトサイドバーをリリースしたとき、この方法で幾つかの新しいデザインをユーザーに直接提供し、その「拒否率」をトラックする共に、沢山のフィードバックを頂きました。その中でも、「オプトアウト」を選択したユーザーのフィードバックを参考にし、新しいデザインのどこが問題だったのかを理解するようにしました。この「ユーザビリティオプトイン」を何回か繰り返し、最初のデザインの拒否率 22% を、最終的に 5.4 % まで減少することに成功しました。これで、自信を持ってリリースすることができたのです。
実は、この「ユーザビリティオプトイン」の方法を始め取り入れようとした当時、チームは「拒否率があまりにも低かったらどうしよう」とか「ネガティブなフィードバックばかりになるかもしれない」といった不安から、この方法に少し抵抗感がありました。しかし、現在は、この方法によって、ユーザーと対話をしながら開発することができるし、目的を明確にしながら更新毎に改善していく達成感から、チームは「ユーザビリティオプトイン」の方法をとても気に入っています。
Experiements (実験)
ユーザービリティオプトインは、UI の変更といった大きな更新には非常に効果的ですが、開発や結果がでるまでに時間がかかってしまうのが難点で、細かい新しい機能に対していちいちこの方法を使うときりがありません。しかし、このアトラシアンで言う「実験」（化学実験みたいに聞こえますね笑）を使うと、こういった細かい機能を気軽に且つ早く結果を確認することができます。
この実験という方法は、「オプトアウト」がなく、一部の新規ユーザーに対して早く開発できる Javascript による一時的な更新したものを提供し、 A/B テストを行うことです。全く今まで製品を利用したことのない新規ユーザーにこれを適用することで、ユーザーに抵抗を与えることなくテストを行うことができます。
アジャイルに開発するためのポイント
アジャイル開発手法をうまくチームで運用していくには、まずチームが課題やスプリントのゴールに注目して開発していく習慣をつけ、製品に存在している課題の解決を行なっていきます。それがある程度できると次は、問題なく動いているソフトウェアをさらに良いものに変えていくために、継続的インテグレーションおよびデリバリーを行うようにします。ただ、何でもかんでもリリースすれば「アジャイルに開発している」という意味ではありません。
この次のステップが重要で、リリースしてから「ふりかえり」を行い、メトリクスを利用して製品の価値があがったかどうかを確認することが大事です。最終的に、ただその課題の開発が終了したから「完了」と定義するのではなく、本当に「ユーザーの満足度が目標値に達したかどうか」を「完了」の定義にすることで、ユーザーの目線で開発し続けるチームを育てることができます。確かにどのように効率的に開発やリリースを行うかを考えるのも重要ですが、ユーザーエクスピリエンスを重視して、ユーザーがその製品を本当に気に入ってもられるようにするような体験を作り出すための開発及びリリースを行なっていくことが重要です。
ソフトウェア開発の哲学
Software is a Service
ソフトウェアはかつて製品として処理を行う単体のものとして考えられていましたが、最近はインターネットをといつでも繋げるようになり、ただ単に処理をするのではなくインターネットと繋がり、他のユーザーやツールからの情報を掛け合わせた便利な機能やデータを提供することができたりと、ソフトウェアがユーザーに接客しているような「サービス」の役割が増えてきました。
オーストラリア人は、来日するとほぼ口を揃えて「サービスが素晴らしい」と言います。それは、日本のおもてなしの習慣から来ているものではないでしょうか？これを、接客だけでなく、ソフトウェア開発においても是非生かしてほしいと思います。
ユーザーがアトラシアン製品を使って開発している製品について知ることが、私たちのインスピレーションに繋がっています。また、プロダクトマネージャーとして、自分たちの作っているソフトウェアがどう使われているかを学び、それを開発チームのカルチャーとして取り入れることがとても大切だと思っています。私たちは、ユーザーの皆さんが作ったソフトウェアやアプリを知るたびに毎度感動し、JIRA Software を通して、よりよいソフトウェアの開発ができるように貢献したいと常に考えています。