NeWork 開発チームが自主的な改善を行う 20%ルールを1年間運用してみて

NeWork 開発チームでは開発時間の 20%を主体的にプロダクトの改善に当てています。この取り組みの導入の背景や 1 年間運用して見えてきた良かったことや課題などをご紹介します。

目次

はじめに

こんにちは。NeWork 開発チームの 2 年目エンジニアの中里です。普段はアジャイル開発エンジニアとしてフロントエンド・バックエンドを問わず、機能開発や改善を行っています。

この記事では、NeWork 開発チームが開発時間の 20%を主体的にプロダクトの改善に当てている取り組みの導入の背景や、1 年間運用して見えてきた良かったことや課題などをご紹介します。

NeWork とは

NeWork は、コロナ禍に誕生したオンラインワークスペースサービスです。ワークスペース上のルームにワンクリックで入室でき、チームメンバーと気軽に話し始められる体験が売りのプロダクトです。

NeWork は、話し始めるまでの手軽さや打ち合わせ前後のコミュニケーションのしやすさ、メンバーのプレゼンスがわかることによる孤独感の緩和やコラボレーションのしやすさなど、リモートワークの課題感を解決できる設計がされています。

私の NeWork との出会いは学生の頃、コロナ禍に突入してからしばらく後でした。研究室の活動もリモート前提になり、ゼミや打ち合わせの度に打ち合わせ用 URL を発行する手間に辟易としていたところでこのサービスを知りました。
リモートワークに必要なのはこれだ!と当時の私は感銘を受け、インターンシップに参加・入社し、今では作る側になるくらいには良いプロダクトだと思っています。

開発チーム改善活動

NeWork の開発チームでは、1 年ほど前からプロダクトのためになることであれば、開発時間の 20%を費やして良いというルールを設けています。
チーム内ではこの活動を開発チーム改善活動と呼んでいます。

背景

開発チーム改善活動ができた経緯について。

NeWork では 2 週間スプリントのスクラムを行っています。プロダクト(企画)チームが立てた計画に基づき優先度を決めて、スプリントプランニングで次の 2 週間で開発するバックログアイテムを決めています。

計画通りに順調に開発が進むこともあれば、工数見積もりのブレやたまに降ってくる開発以外の社内業務によって開発が遅れることもありました。プランニングで積んだアイテムをスプリント内で終わらせようとして技術的負債を残すこともありました。実際に過去のレトロスペクティブを見ると次のスプリントプランニングの直前まで開発していることもあったようです。

また、特にプロダクトチームの事業計画的におしりが決まっている開発では、後々のスプリントでリファクタリングをやらせてもらう約束をプロダクトチームと決めた上で、スピードを優先させることもありました。

しかし、技術的負債を解消するためのバックログアイテムの優先度は永遠に上がらない上、リファクタリング前提で進めた箇所もどのタイミングでリファクタリングをするのか、どのくらいの時間をかけて良いのかをプロダクトチームと合意を取ることが難しいこともありました。
(※もちろん開発をしていない人にとってはコードがクリーンであることよりもお客さんに新しい価値を提供することの方が大切に見えるのは自然で仕方ないと思います)

他にもエンジニアが自主的に動くための時間を取りづらい問題もありました。
例えば、エンジニアが改善したい点(リファクタリングやライブラリのアップデート、機能改善など)を見つけた場合は、バックログアイテムを作成して、そのアイテムの価値をプロダクトオーナーに理解してもらいスプリントに積んでもらう必要もありました。改善に着手するためのハードルが高く、着手までのリードタイムが大分長くなっていました。
以下は実際にレトロスペクティブで出た課題です。

これらの問題に課題意識を持っている人が多く、レトロスペクティブで議題に挙がりました。 NTT Com 技術顧問の吉羽さんも自身のブログのスクラムで開発チームが自由な取り組みをするには?というポストで、「スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする」ことを推奨されていることも話題に挙がり、 NeWork チームでも 1 スプリントで一律 20%の時間を開発チームが自由に使って改善を行えるようになりました 🎉

活動内容

開発チームの課題意識から生まれた開発チーム改善活動では、具体的に以下を活動内容と定めています。

  • 機能改善
  • 新機能開発
  • リファクタリング
  • 技術動向を調査
  • 優先度の低いバックログアイテムを先取り

実際に課題意識があったようにリファクタリング、次点で機能改善や新機能開発をする人が多い印象です。
我々 NeWork チームは日々の業務でドッグフーディングを兼ねて NeWork を利用しています。毎日使っているからこそ、各々が使いづらく感じるところを改善しているようでした。

例えば、以下の機能は開発チーム改善活動で生まれた/実装中の機能です。

  • ピクチャ・イン・ピクチャ機能 (ベータ機能としてリリース済み)
  • タイル表示スタイル選択機能 (ベータ機能としてリリース済み)
    • タイル表示スタイル: オート
      カメラ映像や画面共有の映像を自動的にタイル表示する (全員が顔出しする会議などで便利です) タイル表示スタイル: オート のデモ映像
    • タイル表示スタイル: フォーカス
      選択したユーザを排他的にタイル表示する (小さい画面で複数の画面を見比べる際に便利です) タイル表示スタイル: フォーカス のデモ映像
  • タイル表示のレスポンシブ対応 (リリース済)
    改善前: 事前に用意されたグリッドレイアウトに映像ストリームを順番に割当
    改善後: ウィンドウサイズや映像ストリームをのサイズ考慮して各ストリームの面積の和が最大化されるレイアウトを動的に作成して割当
  • タイル表示中の映像をズームする機能 (リリース済) タイル表示中の映像をズームする機能のデモ映像
  • ルームメッセージへのカスタムリアクション (リリース済)
  • メッセージのリッチテキスト対応 (実装中)
  • メッセージでのメンション機能 (実装中)
  • メッセージでのリンクのプレビュー機能 (実装中)

日頃から NeWork をご利用していただいている方には、馴染のある機能もあったかもしれません。エンジニアならではの視点での改善や新機能開発が上手く回っており、良い取り組みだと感じています。

ちなみに、上 3 つは私が開発しました。私は自分のアイデアを形にするのが好きで、よく使いにくいところを改善したり欲しいと思った機能を開発したりしていました。(楽しい!)

導入して良かったことと課題

良かったこと

スプリントに積んだバックログアイテムが基本的に消化できるようになった

  • スプリントプランニングの段階でベロシティの 80%をバックログに積み、余った時間を開発チーム改善活動に充てる運用をすることで、工数見積もりのブレを吸収し、スプリント内にバックログアイテムを消化できないことはほぼなくなりました。リリーススケジュールの見通しが良くなったといえます。
  • スプリント内にすべてのバックログアイテムを消化しようと急ぐことがなくなり、精神的余裕ができました。

エンジニアのモチベーション向上

  • リファクタリングやライブラリのアップデートなどをやりたいと思ったらそのスプリント内でできるため、リードタイムがありません。リードタイムがないので構想したものを忘れたり、熱意が覚めることもありません。
  • 20%の時間は自分で裁量を持って好きな開発をできるため、シンプルにモチベーションが上がります。

インタラクションの改善もプロトタイプを通して納得感を与えられる

  • 操作体験が絡む、インタラクションが重要になる改善をバックログアイテムにして計画的に取り組むことは難しいと考えています。プロダクトに使いづらさを感じていても、プロダクトの人がデザインや実装に詳しくないと改善できることに気付けないし、気づけても言語化もし辛いのでバックログにもし辛いからです。
  • それに対して、エンジニアが自由に使える時間の中で、作りながら体験を模索していけるので手触りの良いものが作りやすいです。
  • ステークホルダーにプロトタイプを触ってもらって、納得感を持ってもらった状態でリリースに踏み切れるのも大きいです。

コードの品質が上がる

  • プロダクトバックログアイテムに取り掛かっているときに、気になる実装を見つけたときにすぐにリファクタリングできるのでコードの品質が保たれます。

課題

新機能を作った場合に他チームとの連携が難しい

  • 基本的に、開発チーム改善活動で取り組む内容はスプリントプランニングを通さないので、他のチームの人はスプリントレビューで初めて新機能の内容を知ることになります。
  • 計測やリリースノートなどはプロモーションチームが担当しているため、事前に相談したり、リリースを遅らせることもありました。
  • エンジニアがプロトタイプを作り、スプリントレビューに持っていき、リリースすることが決まってからデザイナが UI を作ることが多かったため、リリースまでのリードタイムがかかります。それを踏まえ、最近はレビュー前に事前にデザインしてもらうこともあります。

新機能が放置されがち

  • 開発チーム改善内容で新機能を作ると、それに関わる人が少なくチーム内での影が薄くなりやすいです。とりあえずベータ機能としてリリースした場合に忘れ去られてることもあります。これは開発した人がアフターフォローをしっかりするべきなのかなと思います。私の開発したベータ機能も本格採用するか削除するかしないと…

コンフリクトが起きる

  • 自由な活動ができるといってもスプリント内の 20%の時間しか使えないので、開発が数スプリントに跨ることも多く、コンフリクトが起こることもしばしばあります。これは仕方ないですね。

おわりに

NeWork 開発チームでは約 1 年間、開発時間の 20%をエンジニアが自由に使える時間、開発チーム改善活動を運用してきました。

チームの一エンジニアとしては、コードの品質向上やエンジニアのモチベーション向上、価値創造につながっており、非常に良い取り組みだと感じています。
実は、この活動を通してできた改善・新機能のうち、機能自体や内部のアルゴリズムなどで 3 件の特許出願を行っています。私も 2 件出願しています。現在審査中で特許として認められるかはまだわかりませんが、それなりに価値のあるアウトプットが自発的にできたこともこの仕組みのおかげだと思っています。

NeWorkは 20 人までのフリープランは無料でお試しいただけます。もしご興味を持っていただけた方はぜひお試しください。

また、2024 年 3 月現在、NeWork では一緒に開発を進めてくれる仲間を募集しています。詳細は以下のリンクをご覧ください。皆さまのご応募を心よりお待ちしています!

hrmos.co

© NTT Communications Corporation 2014