Backlogユーザーのみなさま、こんにちは！12月9日土曜日、Backlog World2023「Re:Boot-未来への帰還」が開催されました。
本ブログでは、公募LTの様子をレポートします！
目次
フルリモート開発チームが挑む新規事業開発｜リコーITソリューションズ株式会社 茶屋 彰仁
一人目のご登壇は、リコーITソリューションズ株式会社の茶屋さんです。
茶屋さんには、現在開発に携わっている「toruno」のフルリモートでの新規事業開発のプロジェクトで、工夫していることを発表していただきました。
東京・横浜・鹿児島からフルリモート
まずは、開発チームの体制です。
- 企画は、東京の大森
- 商品担当は、東京の晴海
- スクラムマスターは、横浜
- 開発チームは、鹿児島と東京の大森
このように、チームメンバーが物理的に離れた場所で働いているため、「素早い意思決定」や「プロダクト開発のためのコミュニケーションロス」が、発生しないように気を付ける必要がありました。
プロジェクトを推進するためのツール
リモート環境においても素早い意思決定を行い、コミュニケーションロスを回避するために、茶屋さんのチームが使用しているツールを見ていきましょう。
- プロジェクト管理にはBacklog
いくつかのプロジェクト管理ツールを使ってみた上で、現在はBacklogを活用しています。
- コミュニケーションツールは、Teamsのオンライン会議、oViceでのオンライン会議
開発初期は、Teamsのチャットをメインで使用していましたが、コミュニケーションに時間を要し、コミュニケーションの齟齬が発生してしまうことがあったため、変更したとのこと。
oViceのバーチャルオフィスを利用することもあります。チームのメンバーは大抵バーチャルオフィス内にいるため、スケジュールを確認せずに気軽に声がかけられるのがメリット。「実際にオフィスに出社している時のような雰囲気が伝わってくるのも楽しいですよ」と茶屋さんは言います。
Backlogの優先順位の決めかた
続いて「Backlogの優先順位の決めかた」のポイントです。
日々、顧客と営業が擦り合わせを行うなかで、顧客の声を元に打ち手をプロットしています。その際、「開発工数の数」と「グロースの仮説」の二つの軸を基に、サービスの成長に対するインパクトの大小で優先順位をつけています。開発工数が少なく、サービスの成長に対するインパクトが大きいものが優先度が高くなります。こうして優先度をつけたものをBacklogにPBIを落とし込んでいる、と茶屋さんは説明します。
フルリモートでの開発体制
最後に、フルリモートでの開発体制についてです。
開発体制は、ペアワーク、モブワーク（三人以上で開発する）、ソロの3つの体制があり、
基本はペアワークで開発を行っています。
ペアワークでは、知識や暗黙知の共有ができるため、開発に関わる人のスキルアップにも繋がっています。
三人以上のモブワークは、大規模な機能開発の設計時や、今まで使ったことのないアーキテクチャを採用する時、実装難易度の高い時に活用しています。
モブワークにより、新しく得た知識をチームメンバー全員に展開することが可能となり、ユーザーへの価値提供も早くなるというメリットがあります。
最後に茶屋さんは、こう締めくくりました。
「全員が同じ方向を向き続けるために、振り返りとは別に向きなおりという活動を導入し良い効果が得られています。また、毎日30分のリファインメントをしたり、企画だけでなく開発チームからも意見を吸い上げたり、MVPはどこにあるかを常に考え続け、計画にフィードバックをしたりしています。」
茶屋さんのセッションでは、一つのやり方に拘らずに、目的や用途によって、柔軟に体制を変化させることで、得られるメリットが大きいことを学びました。
2024年に長崎に事業所を開設する予定とのことで、今後の事業展開も楽しみですね！
Backlog APIと生成系AIで考える課題優先度｜株式会社Fusic 清家 史郎
続いて、Fusicの清家さんのご登壇です。
Fusicに入社して8年目の清家さんは、Backlog上でさまざまなプロジェクトに参加しながら、コミュニティ活動でも多くBacklogを使用しています。Backlogを使う機会が多いからこその課題を感じ始めたところから、清家さんのプロジェクトが始まりました。
直面した課題：Backlogでの情報の”過集約”
電話での口ぐせは「今の会話、Backlogに書いときますね」だという清家さん。お客様との会話記録などあらゆる情報をBacklogに集約することで、情報共有もできて、経緯を残すこともできるというBacklogの利点をフル活用して、さまざまなプロジェクトに携わっていました。
しかし、徐々にBacklogでの「情報の過集約」が起きてしまいます。案件の情報はBacklogに集約されたものの、ご自身のリソースの限界が近づいていたのです。未対応タスクが増えるなかで、清家さんはさらにもうひとつの課題感を抱えます。それは、「プロジェクトの優先度」です。膨大なタスクの優先度設定が不明瞭になっている状況でした。
- 優先度設定の課題：その1
無闇に優先度高を利用しない結果、優先度が全て一律な状態になってしまう。 - 優先度設定の課題：その2
プロジェクトを横断して見た時に、自分の判断、またはお客様判断があり、判断する指標が実はブレている。
その結果、本質的に優先度の低いBacklog課題が、残骸のように配置されるという事態を生んでいました。
そこで清家さんは、タスク優先度の課題に対して、
Backlog API × OpenAIによるアプローチに取り組むことを決めました。
Backlog API × OpenAIによるアプローチ
まず、Backlog APIの概要です。
Backlog APIでは、課題、Wiki、ファイルの追加や取得を始めプロジェクトのユーザーの管理などのプラウザ上のBacklogでできる操作の大部分をAPIから行うことが可能です。
このBacklog APIで出来ることは、なんと154通り※！
※2023年12月時点の情報です
「Backlog APIは、エンジニアからするとドキュメントが充実しているAPIを触らせてくれる天国です！ぜひ触ってみてください！」と、清家さんは話を続けます。
この【Backlog API】を【生成系AI】と組み合わせていきます。
情報が集約されたBacklogのデータ構造を確認し、プロジェクト→課題→コメントの3つの構造から自身のタスクを抽出、タスクの優先順位を考察していきます。
ここで抽出するタスクはこの２つです。
- 最近自分が投稿した課題・稼働した課題
- 自分が「担当者」になっている課題
これらの課題を自分が処理すべき課題として扱うことにする。
↓
OpenAIへ全容を把握させるために課題に紐づいているコメントを取得する。
↓
OpenAI側に渡すプロンプトの構成を行い、プロンプトを生成する。
Backlog API×生成系AIが示した優先順位
そして生み出された出力と考察を見ていきましょう。
スライドにはGPTが出力した「アクションの優先度と提案」が映し出されました。
清家さんの仕事であるエバンジェリスト業と技術広報のタスクが、最優先、優先度高・中・低の順に並べられています。
ちなみに最優先タスクは、
「来週の月曜のイベントがあるため速やかに集客を行う必要がある」となっています。
来週の月曜日に行われるため急を要するのと、集客用のURLがあることから優先度が高くなっていることがわかります。（赤枠部分）
この、Backlog API×OpenAIによるアプローチによる出力と考察を振り返り、清家さんはこう話を続けます。
「壁打ち役としては十分です。壁打ちしながら優先順位を決めましょう」
Backlogの「AI要約」機能がリリース
こうして清家さんがプロポーザルを行った後に、事件は起きます！
なんと、同じタイミングで、BacklogにOpenAIを連携した「AI要約」機能がリリースされたのです。
Backlogに集約されていく情報について、「AI要約」機能により簡単に要約ができるようになりました。
清家さんからも、「絶対便利だから使いましょう！」とのお墨付きもいただきました！笑
ありがとうございます！
最後に、プロジェクトの振り返りを4つのポイントにまとめてセッションを締めくくりました。
- Backlogにすべてを集約すると情報の宝庫になる。Backlogを使っていきましょう
- Backlog APIを使うとエンジニアは解き放たれます。Backlog APIを使っていきましょう
- OpenAIを使うとやはり完璧な訳ではないが、大枠は外さない。壁打ち役に使っていきましょう
- Backlogが生成系AIを使った要約機能を出しています。皆様使っていきましょう
Backlogの情報集約性にOpenAIを組み合わせることで、タスクの優先度判断の壁打ち相手を作るという清家さんの技術が光るプロジェクトでした！
心が折れそうになった時に大切にしていること｜株式会社ドリーム・アーツ 清水 健一
Backlog World 2023 最後のセッションは、ドリーム・アーツ 清水さんのご登壇です。
「本日ラストということで、心拍数が上がってApple Watchが震えております（笑）」
清水さんのひとことで、会場は笑いと温かい空気に包まれました。
プロジェクトマネージャーは孤独を感じやすい
清水さんは、株式会社ドリーム・アーツのCSXグループでゼネラルマネジャーとして、さまざまな大型プロジェクトに携わってきました。しかし、あるプロジェクトにおいて「心が折れそうになる出来事」が起こります。
まず、その内容を見てみましょう。（登壇資料より）
・自社の都合でしか物事を考えない
・直前にどう考えても無理な作業を依頼しようとする
・誰も彼も他人事、責任の擦り付け合い
・要件定義で決まっていたことを平然とひっくり返される
・そもそもの仕様が分からない、情報開示されない
・うまくいかないことは全て障害扱い
途中からこのプロジェクトに参加した清水さんですが、周囲から辛辣な言葉を投げかけられたり、オンラインミーティングにカメラオフのままで参加されたりと、どうフォローして良いのかがわからなくなりました。
ご自身の体験によりコロナ禍においては特に「人を信じるということが難しくなった」「プロジェクトマネジャーやリーダーは孤独を感じやすい」と、清水さんは語ります。
本当に心が折れそうになった時、折れてしまっても良いと思います。でも、逃げることなくどこかで向き合わないといけない時もある、と言葉を続けます。
「心が折れそうになった時に大切にしている3つのこと」について教えてくれました。
心が折れそうになった時に大切にしている3つのこと
- 「メタ認知による客観視」
メタ認知とは「認知を認知すること」です。心が折れそうな時にも、Backlogを活用し、朝会用wikiやガントチャートで認知を見える化し、凡事徹底することを大切にしたと清水さんは説明します。
- 「感情に支配されないこと」
問題やトラブル、課題などに対する負の感情を書き出すことで、自身の言動を客観的に見返します。週次でアウトプットしセルフトークを行うことで感情に支配されず、次にどうすべきかを冷静に考えることができます。 - 「信念を失わないこと」
リーダーとメンバーの関係性は、あくまでも役割の違いです。その上で、「今から何ができるか」という解決策に注力し、チームのため、組織のため、社会のために協力し合う、貢献するという考えを持つように心がけます。
「チームのため」協力しあった結果
こうして、心が折れそうな状況を乗り越えた清水さんは、最後にプロジェクトメンバーとの集合写真を見せてくれました。
「みんな、そんなに晴れやかな顔はしていませんが……（笑）」と、清水さんの照れくさそうな笑顔はとても晴れやかでした。
立場や役割の異なるチームのメンバーをまとめ、プロジェクトを推進するPMには、こういった人間関係のトラブルや感情の行き違いが発生することもあるでしょう。Backlogの活用で事態を客観視することが、心の支えにもなったのであれば、嬉しい限りです！
おわりに
日々の業務でBacklogを活用し、プロジェクトを円滑に進行している3名の「知恵と経験」を共有していただいた今回のセッションでは、多くの聴講者がうなずきながら話に聞き入っている光景が見られました。登壇者の皆さん、本当にありがとうございました！