こんにちは、GROOVE Xでソフトウェア領域のエリアプロダクトオーナー(APO)をやってる、よっきです！
今回は、プロダクトオーナーの視点からLOVOT開発について語ってみたいと思います。
プロダクトオーナーとはなんぞやは、例えば、こちらの記事に詳しくまとまっているので参考にしてみてください。
ざっくり言うと、 いつ何をする、という計画を立てるのと、それをなぜするのかの説明をチームにしていくことが主な役割になります。
このいつ何をするか、というのにロボットならではの難しさがあるなと感じることがあるので、この辺りを中心に語ってみたいと思います。
プロダクトオーナーもチームです
まず、どのくらいのチームでLOVOTを開発しているかについて簡単に説明します。
第一回のアドベンドカレンダー でも紹介がありましたが、ソフトウェア領域だけでも多くの専門分野があり、ハードウェアとソフトウェア、そしてアフターサービスの領域を合わせると合計16チームもあります。ざっと図にするとこんな感じ。図はチーム名で記載しています。
お気づきの方もいるかと思いますが、技術や専門がわかりやすくチーム名になっているチームもあれば、何をしているのかわかりにくいチーム名もありますね。 ちなみに、UTとAlohaとAppでふるまいチームと呼んだり、フレームワークとクラウドと音声認識でKIBAN WGと呼んだりと、チーム横断のチームやワーキングもあります。 また、チームを決める裁量はチームにあるため、チーム名やチーム構成も気づいたら変わっていることがあります。なので、この図は2022年12月現在のチーム構成ですね。
どのチームがどんなことをやっているかは、今後のアドベントカレンダーでわかってくるかと思います。期待しましょう。
これら16チームの開発状況や今後のLOVOTの成長方針などを踏まえて、計画をアップデートしていくのがプロダクトオーナーのミッションの１つなのですが、さすがにチーム数が多いのと、専門性がかなり異なるため、領域ごとにエリアプロダクトオーナー（APO）を置いています。
領域を分けると情報の分断がおきてしまいそうと心配になりますよね！？
そこでエリアプロダクトオーナーもチームとして毎日情報の共有をしています。 ちなみに、ソフトウェア領域のAPOは私を含めて2名、ハードウェア領域のAPOは1名、その他にアフター領域のAPOが2名、そして、全体のプロダクトオーナーとして代表の林要がいて、合計6名のプロダクトオーナーチームです。 この6名で毎日30分〜1時間ほど気になるところの状況の確認や、課題の相談を行い、何なら全体の計画に関わる重要な決定事項も行っています。 そんなに毎日話すことがあるのかと思いますが、なぜか1時間じゃ足りないくらい議題が山積みなのですよね。いや〜、不思議です。
ロボット開発の計画づくりの難しさ
では、いつ何をするかを決めるにあたっての、私がロボットならではの難しさだなと感じていることを２つほど紹介します。
開発は順番に進んでいく
LOVOTをローンチしたあとも、LOVOT 2.0やLOVOTチャージスタンド、最近ではフラグメントエディションをリリースしたりと、たくさんのハードウェアを開発してきました。 このハードウェアが絡む開発は、ハード設計から始まり、バラックと呼ばれるパーツ単位でファームウェアやLinuxなどのソフト基盤の開発や動作検証を行い、その後、ハードウェアが組み合わさってから認識機能の開発、そしてふるまいやアプリの開発を行います。（上のチーム構成図は開発の流れ順っぽく描いてみました）
つまり、開発工程が進むにつれて、関わるチームが変わります。 これらはある程度事前に計画は立てるものの、部品の調達状況や各チームの開発状況でスケジュールが変わるため、いつからどのチームが着手できるかがどんどん変わっていきます。 工程が遠いチームほど、いつから着手できるかがわからなくなり、状況のキャッチアップが難しいなと思うことがあります。
ハードウェア変更は突然やってくる
電子部品の終了はいきなりやってくるものなのですね。ハードウェア領域のチームからソフトウェア領域のチームに対して、「この部品が販売終了となり、新しい部品を選定したので評価お願いします」と連絡をもらうときがあります。いわゆるEOL（End of Life）対応ですね。在庫をどれだけ買っておくか、いつから変更するか、などを決めつつ、新しい部品で問題ないかの確認をしていきます。緊急度が高いので割り込みタスクになりやすく、そして、実際に変更される時期が半年とか１年後とかになることもあり、評価はするもののいつから導入されるのかが分かりづらいこともあります。正直、覚えてられません。。。
スケジュール管理の理想を求めて
これらの難しさが同時に起こると、つまりハードウェア開発とEoL対応のスケジュールが同時に走ると、もうどのチームがいつどんなタスクをすべきかがだんだんわからなくなってきます。 プロダクトオーナーチームでも各領域の状況を確認しながら、スケジュールをメンテしているのですが、あ、もうこれやらないとなのか、と割り込みっぽく優先順位を変更することが多々ありました。 これはいかん！ということで、スケジュール管理方法を検討し、そこで出会ったのが、タスク管理とスケジュール管理を同時に行えるWrikeというツールです。
以前は、タスク管理はJIRA、スケジュール管理はスプレッドシートやコンフルのマイルストーン機能などを使っていましたが、スケジュールとタスクの関係がわかりにくいのと、スケジュールがよく壊れるため、統合したいという思いが有りました。JIRAにもガントチャートのアドオンがあってスケジュール管理できるけど、かなり使いづらかった。。
Wrikeのいいところは
- タスクをプロジェクトという単位でまとめられる
- プロジェクトにスケジュールを入れると自動でカレンダーができる
- プロジェクトに担当チームを入れると、チーム単位のカレンダーもできる
ということで、タスクをプロジェクトにまとめて、プロジェクトにスケジュールと担当チームを入れれば、全体の大まかなスケジュールとどのチームがいつ作業開始すべきかが比較的簡単に作れます。
そして何より、タスク管理とスケジュール管理が統合されているため、開発チームみんなでスケジュールを作ることができるようになりました。 なんやかんやで最新のスケジュールを把握しているのは開発チームであり、その開発チーム自身がタスクを作る際にスケジュールを設定してくれると、全体スケジュールが更新される！なんて素敵なことでしょう。
そんな理想を求めて、Wrike導入を決意して、実はまもなく８ヶ月が経とうとしています。 まだまだうまく使いこなせているわけではなく、JIRAに比べて自動化などが弱い部分もありますが、ひとまずスケジュールの管理という意味では、それなりに使えるようになってきたかなと思っています。 これからも各チームがスケジュールを自分たちで把握しやすいように日々改善していきたいと思います。
最後にちょっと冷静にふりかえって
ロボット開発におけるスケジュール管理の難しさと、スケジュールをみんなで管理できるようにWrikeというツールを導入したよ、という話を書きましたが、いかがでしたでしょうか。
この記事を書こうと思ったきっかけは、Twitterで「JIRAでスケジュール管理どうしてるの？全員が理解できるくらいのスケジュールを可視化したいんやけど」みたいなツイートを見かけて、GROOVE Xの取り組みが少しは参考になるかなと思って書いてみることにしました。（オリジナルのツイートを見失ってしまいました、すいません。文言は多少間違ってるかもですが、ニュアンスは合ってるはずです）
Wrikeがベストソリューションのように書きましたが、多分、何のツールで改善を進めるかだけなので、JIRAでやりきろうと思えばできたのかな、と今になっては思います。 選択をしたあとは、選択したものをいかに正解に持っていくかを頑張るのみですね！
まだまだ試行錯誤が続く毎日で、日々新たな課題も出てくるのですが、それをチームみんなでカバーしあって支え合おうとするGROOVE Xの文化が私は好きです。 最近流行りのWeb3でいわれているDAO的な世界観に似ているなとも思っています。 できるところをできるメンバーで支え合う。私もプロダクトオーナーという視点で開発チームを支えて、より良いLOVOTを世の中に提供していけるよう頑張ってまいります。
そして、こんな面白いチームや組織を維持していくためにはスクラムマスターの存在が欠かせません。 POチームは、一緒に開発チームや組織を作ってくれるスクラムマスターを探しています。 現在２名のスクラムマスターが在籍していますが、まだまだ足りていません。 面白そうだなと思った人は、ぜひ一度お話しましょう。
その他のポジションも絶賛募集中です。 LOVOTに関わるお仕事に興味ある方は是非ご検討ください。
