開発部署の体制変更に合わせてJiraの使用方法を変えてみた　フィルタークエリとボードを工夫すれば、どんなチーム体制にも対応できる

鶴田氏の自己紹介

鶴田未奈美氏（以下、鶴田）：私は朝日新聞社の鶴田と申します。本日はよろしくお願いします。冒頭に紹介いただいたとおり、本日は「どんなチーム体制にも対応！　Jiraのおすすめ機能」というタイトルで発表します。

まず簡単に自己紹介をすると、私は2017年に新卒で朝日新聞社に入社しています。最初はバーティカルメディアサイトの開発を数年間担当して、その後、朝デジ事業センターというところのPOとして朝デジのグロースに取り組んでいます。よろしくお願いします。

本日紹介する事例に関してですが、「朝デジ（朝日新聞デジタル）」開発している部署で、体制変更を行い、それに合わせて「Jira」の使い方も変えてみたというところで、この事例をメインにお話しします。

本題に入る前に、我々が開発しているプロダクトを簡単に紹介します。朝デジはサブスクモデルで展開しているもので、Web版、アプリ版の両方を提供しています。アプリ版のほうは「朝デジアプリ」と呼ばれるものと、新聞のレイアウトでそのまま読むことができる「紙面ビューアーアプリ」の2つを展開しています。

「チーム間の情報共有がしにくい」課題のあった体制

では本題に入ります。どのような体制変更をしたのかというところで、先に以前までの体制（がどのようなものだったのか）をお話しします。同じ朝デジを開発する部署でも、開発フィールドごとにチームを分けていました。例えばアプリの開発をするチーム、Webの開発をするチーム、あと課金導線の開発をするチームというかたちで、フィールドごとにチームを分けていました。

ただ、これだとチーム間の情報共有がかなり難しく、結果としてお客さまの一連の体験を意識した開発がしづらいという課題が挙がりました。

ここで言う「お客さまの一連の体験」とは、例えばWebとアプリをシーンによって使い分けているお客さまの行動であったり、アプリの改良をしている途中で課金導線に入るスムーズさだったりです。そのあたりを意識した開発がしづらいという課題が出てきました。

（スライドを示して）この課題を受けて新しい体制をどうしたかというと、このようなかたちに変更しました。まずチームは開発チームとしてひとまとめに集約して、あとは目的によってサブチームを作るというかたちに変更しています。例えばリテンション改善を目的とした開発をするチーム、会員獲得を目的とした開発をするチームといったかたちで、サブチームを切って対応しているのが今の体制になります。

体制変更にともない行ったJiraの使い方の変更

この体制変更だけでもかなりチーム間の情報共有の難しさといった課題は解消されたのですが、この体制に合わせてJiraの使い方を変えてみた結果、かなり課題の解消につながったと思っています。そこで、次にどのようにJiraの使い方を変えたのかをお話しします。

まず以前の体制でJiraをどう使っていたのかというと、チームごとにJiraのプロジェクトを切って対応していました。これはプランによるところもあるのですが、Jiraのプロジェクトをまたいで開発状況を確認するということは、少しハードルが高い状況にありました。

例えば弊社が契約しているプランでは、Jiraのプロジェクトをまたいでロードマップを確認することはできない状況にありました。

各チームでJiraのプロジェクトを設けていたことによって、チームごとに開発管理が独立してしまっていたという課題がありました。

そこで新しい体制では、Jiraプロジェクトは1つに集約して、ボードを活用して課題の表示を分割するというかたちに変えています。

（スライドを示して）具体的なイメージはこのようなかたちで、Jiraのプロジェクトは開発チームで1つだけ設けて、あとはチーム全体用のボード、サブチームA用のボードといったかたちで表示を分割しています。

ボードとコンポーネントについて

先ほどから出てきているボードがどういうものかというところで、今回（このイベントに）参加しているみなさんはすでに知っているかと思いますが、少しお話しします。

ボードは設定をカスタマイズすることによって、課題の表示を柔軟に変えられるようになっています。1つのJiraプロジェクト配下で、ボードごとにロードマップやカンバンの出し分けが可能になっています。

今回の我々のパターンでは、開発チームというJiraのプロジェクト配下にサブチームAだったり、チーム全体用ボードといったかたちでボードを作っています。左のナビからポチポチと切り替えることで、ロードマップなどの表示も切り替えることができます。

次が最大の魅力なのかなと思うのですが、ボードのカスタマイズにはフィルタークエリを使うことができます。これに関しては後ほど詳しくお話しします。

今回、我々はフィルタークエリの中でコンポーネントという要素を使っているので、少し脱線してコンポーネントについて補足します。

コンポーネントはプロジェクト内の課題を細かくグループ化するためのもので、今回我々はサブチームごとにコンポーネントを作成しました。コンポーネントではそれぞれリードを設定することなどもできるので、かなりサブチームの概念に合っているというか、管理に適しているものかなと思います。

（スライドを示して）こちらがフィルタークエリの設定例です。例えばサブチームAのボードであれば、先ほど作成したコンポーネントを使用して、スライドのようなかたちでクエリを組むことができます。

今回、我々はプロジェクトとコンポーネントの指定のみで、かなりシンプルなクエリを設定しているのですが、本来フィルタークエリではコンポーネントやプロジェクト以外にも、アサインやラベルも使用することができるので、かなり柔軟な設定が可能になっていると思います。

例えばというところで、例を書いているのですが、プロジェクトもまたいで指定ができるので、DEVチームとCRチームのプロジェクト配下で、かつPMメンバーがアサインされている課題のみを表示するといったかたちで、込み入った設定も可能になっています。

なので、どんなチーム体制にも対応できるかなということと、兼務が多いメンバーの課題管理にもかなり役立つように思います。

「朝デジ」開発部署におけるボードを使い分け

では最後に、我々がどのようなシーンでボードを使い分けているのかを紹介します。

まずチーム全体用のボードをどんな時に使っているかというと、主にPO、PMがプロダクト全体の開発状況を把握したい時に使用しています。例えばロードマップを使った開発優先度決めや、検討中の案件の貯蓄に全体用のボードを使っています。

一方でサブチーム用のボードはどんな時に使っているかというと、主にスクラムイベントの時に、カンバンを使ったデイリースタンディングだったり、バックログを使ったリファインメントの時に使っています。

Jiraの使い方の変更で、一連の体験を意識した開発がしやすくなった

このようなかたちで体制変更に合わせてJiraの使い方を変えてみた結果、チーム間の情報共有がかなりスムーズになって、結果としてお客さまの一連の体験を意識した開発がしやすくなったと思います。

あと、これは肌感覚ですが、Jiraの使い方を変えた結果、特にステークホルダーの多い大規模案件へのPMの調整コストが、20パーセントぐらいはカットできたのではないかと思っています。

フィルタークエリを駆使してボードで表示分割すれば、どんなチーム体制にも対応できる

まとめです。これが今回一番お伝えしたかったことで、タイトルにも立ち返るのですが、フィルタークエリを駆使してボードで表示分割をすれば、どんなチーム体制にも対応できるということで、本日の発表を終わります。

最後に、弊社の宣伝になってしまって恐縮ですが、我々は一緒に朝デジの成長を目指してくれる方を募集しています。TECH×MEDIAというところで、もし興味があれば、リンクを覗いてもらえると幸いです。

以上になります。ご清聴ありがとうございました。