目標志向で山に登ろう - Mirai Translate TECH BLOG

みらい翻訳のプラットフォーム開発部でVPoE兼アーキテクトのSatieこと里山です。

この記事は、みらい翻訳のカレンダー | Advent Calendar 2022 - Qiita の12日目です。

はじめに

みらい翻訳では各部署で4半期毎に目標を設定し、振り返りをしています。目標と振り返りの内容は社内で共有されます。また、重要な施策については、定期的に経営会議でも進捗や成果を共有して、目標に向かって進めていくようになっています。

この目標設定は会社の目標から各部署、各チームへとブレイクダウンされるのですが、ここで課題となるのが各レイヤー間で目標設定・振り返りを行いそれをまとめるとよく「それってなぜやるんだっけ？」という質問が出ます。

つまり各レイヤー毎の目標が繋がっていないように見えてしまっているんです。もちろんそんなことはなく、ブレイクダウンしつつ目標設定をしているので繋がりはあるのですが、それがどうもわかりやすく表現されていないのだと感じていました。

また、もう一つ課題があります。各レイヤーで使う言葉の抽象度が違うこともあり、繋がりが分かりにくいというのもあります。現場に近いレイヤーだと実際のタスクそのままで語られる場合もあるし、経営層ではコストや売上などよりお金に近い言葉になります。

さらに、開発現場ではその開発が何のために行われるか理解しいれば、開発現場からよりよいアイデアや改善が見つかるかもしれないという期待があります。

そのような課題解決とよりよい成果のための表現方法として Climbing Routes (クライミングルート)を考えてみました。

Climbing Routes とは

一言で言うと、目標を設定して、その目標を成すために必要な条件をまたその次の目標としてロジックツリーを組み立てるイメージです。ロジックツリーを掘り下げると各レイヤーの追うべき目標/タスクがどのような関連があるか繋がっていくはずというものです。

頂上の目標設定から

ここでは、素早くとか最小などという曖昧な言葉が用いられています。よくそれが定義できていないと考えられない的な意見も聞きますが、結局そのレイヤーで観測可能で実現可能な数値が出せるならそのレイヤーの目標で設定すればいいのです。例えば売上20%増とかね。ただその目標が果たして妥当なのか判断に迷うなら恐れず曖昧性は残してとにかく書き出して、後で何度も見直したり議論した方が実りが多いかなと思います。

一つの目標が一つのチームだけではできないこともあるでしょう。逆に言えば、目標がそれぞれどのチームの目標と繋がって同じ目標に向かうかが明確になり、例えば、協力したり活動を促したりもしやすくなるかなと思います。

そして、自チームで掲げる目標をさらにブレイクダウンしていくことでやるべき目標がどのようなタスクを設定すれば、達成できるか見えてくると思います。このときに曖昧性がある目標についてもその曖昧性を小さくする目標も設定するとよいかなと思います。上位レイヤーで決まらないことがどこで解消されるかも明確になっていいのかなと思います。(さらに、曖昧性がどこでコストとしてかかるかも分かっていいのではと思います)

一旦、他のチームの目標と考えていた中にも開発が関わることがあるかと思います。その場合でも、何のためか瞬時に把握でき、また同じ目標に向かうことが明白であれば、バックログの優先順位においても議論しやすいかと思います。このような利用方法により所謂縦割り組織の弊害をいくらかは軽減できるのではないかと考えています。

タスクからボトムアップ

どのレイヤーでこのClimbing Routesを作るかにもよると思いますので、開発現場から考えてみます。この例はQAチームです。

まずは、今のタスクがなんのためかを考えて書いてみてください。

そして、自分たちのチームではこれから先の目標について判断が付かないなというところまで登って見てください。

ただし、いきなりスッキリとした目標に出来ない場合もあるかと思います。そういう場合は、次のように課題ベースででもいいです。とにかく言語化することです。スマートにするのは後回しで構わないと思います。

さて、この例では QAフェーズのリードタイムが最小である を目標とすると、これを実現するためだけで目標は実現できるでしょうか。もちろんそれだけで問題無いという判断もあるでしょうし、そうでない場合は明確になっている目標から課題を探し出し、あらたな目標とすることで何のために新しい取り組みが追加されたかも明確になります。

さらに、これらの目標が繋がっているということは、自分たちのスコープだけでは改善できないことも、ルートを辿って改善できないか検討が出来る可能性があります。

もし、MVPのレビューがソフトウェアエンジニアだけだったと突き止めたら、そこにQAエンジニアのレビューが出来ているという状態目標を設定しましょう。担当チームも所掌を侵害されたと感じるのではなく、同じ目標に向かうために喜んで協力してくれるはずです。

発見した課題がどこかのチームの目標のブレイクダウンでも同じ目標に向かっていれば、協力し合うよね

どこまで出来たか、何をしているか

このClimbing Routesでこれまでどこまで出来たか、そして今何をしているかを記載すれば、節目の振り返りで思い返して言葉でまとめる時間を取らずとも分かると考えています。さらに、この後どうするかまでも見えてくるのではないでしょうか。

今回の例では抽象度高いところからタスクに近い粒度まで一気に書いてありますが、実際はもっと細分化されたりすると思いますので、適宜分割した方がよいでしょう。スクラム開発であれば、エピックやユーザーストーリとそのタスク、サブタスクで表現されるところはそれでも構いませんし、エピックより大きな目標や抽象度の高い目標を整理するのに使えるのではと思います。

さいごに

Climbing Routesは今まで見てきたように、今行っているタスクの目標が最終的にどの目標に繋がっているか、他のチームの行っているタスクとどこで交わるのか、そして今までどこまでやってきたのかが表されています。

現在のみらい翻訳では、このClimbing Routesを一部のチームで取り入れ、何のためにその開発をするのか、何を目指すのかの言語化にトライしています。まだ、Climbing Routesというシステムの未成熟さはあると思いますが、もっとよい表現方法や考え方などありましたらお知らせ頂けると幸いです。

おまけ

経営会議やBiz層との話でよくロードマップで示せ的な話が出て来てますが、しばしば機能ロードマップ的なイメージが先行している場合があります。それはアウトプット思考であり、さらにスケジュールのコミットも求められることもあり、ロードマップでは目標志向で開発を進める点でマッチしないと考えていたので、今回、目標志向と各レイヤーの連携が分かるような表現方法を考えてみました。