本記事では、ソフトウェアプロダクト開発において、スクラムから独立した エンジニア × デザイナ × マーケタ の少人数チーム(以下、ミニチーム)を作って活動することにより、事業優先度が低く後回しになりがちなユーザビリティの課題を解決していった事例や学びを紹介しています。
目次
- 目次
- はじめに
- エンジニアが自由にプロダクト改善に取り組むことの難しさ
- ミニチームの発足
- ミニチームの課題解決フロー
- ミニチームの改善事例
- ミニチームのメリットと課題
- メンバーからのコメント
- おわりに
- (付録) ミニチームの改善事例の詳細
はじめに
こんにちは、NeWorkチームの中里です。
「なんとなく使いづらいし、ユーザーもモヤモヤしていそうだけど、ビジネスインパクトが小さいから後回し…」 —— そんな課題、あなたの担当するプロダクトにもありませんか？
NeWorkでも、まさにそうした機能を改善できずにいましたが、思い切って専任の少人数チームを作り、改善活動に取り組みました。この記事は、具体的な取り組み内容とそのチームのエンジニアとして 1 年程活動をしていた私目線での得られた学びやメリット、課題を紹介します。
NeWorkとは
NeWorkは、NTT Comが提供するオンラインワークスペースです。 「リアルよりも話しかけやすい」コミュニケーションを実現することを目指し、オンラインでも気軽に声をかけ合える環境を提供しています。
残念ながら、NeWorkは約1年後の2026年3月31日をもってのサービス終了を発表しています。これまでご利用くださっていた皆さまには申し訳ない気持ちでいっぱいです。 しかしサービス終了が決まってからも前向きな気持ちで活動は続けてきました。本記事もそのような気持ちから執筆したものとなっております。
NeWorkのチーム編成
NeWorkには、以下のようなチーム体制があります。1
- プロダクトチーム: サービスの企画を担当
- プロモーションチーム: 販売推進やマーケティングを担当
- 開発チーム: 実際の開発を担当
開発体制としては、プロダクトチームがプロダクトオーナーを務めるスクラムチームが3つ存在し、そこに開発チームのメンバーがそれぞれ参加して、2週間のスクラムで開発しています。
- スクラムチーム1: Web 全般
- スクラムチーム2: 主にエンタープライズ
- スクラムチーム3: モバイルアプリ
エンジニアが自由にプロダクト改善に取り組むことの難しさ
このプロダクトが大好きな私は、開発優先度に物足りなさを感じることがありました。たとえば、 全ユーザーの1%にも満たないエンタープライズプランの管理者向け機能に多くの開発時間を割く一方、すべてのユーザーが利用する通話画面の課題は後回しになってしまう。 このようなやるせなさを感じることが何度もありました。
NeWorkチームはアジャイル開発を行っており、NTT Comの中では比較的柔軟に動ける組織です。しかし、多くの企業に見られる傾向として、どうしても事業計画の遂行や収益拡大を最優先に考えないといけないプレッシャーがあります。 「本当はもっと改善したい部分が山ほどある」と感じていても、ビジネスを成立させるために、すぐに収益化につながる機能を優先せざるを得ない、というわけです。
1年前に投稿した「NeWork開発チームが自主的な改善を行う 20%ルールを 1 年間運用してみて」という記事では、スプリント内で最大20%の時間を自由に使ってプロダクトのためになることを行う、という制度を紹介しました。 このルールのおかげで、新技術の調査や技術的負債の返済、開発基盤整備、エンジニアのアイデアの実現などはある程度進められるようになりました。しかし、2週間スプリントの最後の2日間だけ自由に使えるといっても、そこで終わらなかったタスクは次回の自由時間まで2週間も空いてしまう。 結果として、20%ルールの中で"ユーザー体験まで深く考え抜いた課題解決"を行うのは難しい現状がありました。
ミニチームの発足
こうした課題感をなんとか解決しようとして生まれたのが、ミニチームです。 このミニチームはスクラムチームとは完全に独立して活動し、メンバーの入れ替わりはありましたが、最終的には以下の4名体制で改善を回していました。
- エンジニア - 2人
- デザイナ - 1人
- マーケタ - 1人
以下の図は、NeWorkにおける全体のチーム体制を視覚化したものです。
ミニチームの改善活動はディスカバリーを行い、ユーザーストーリーを書くところからスタートします。そこからデザイナがデザインを起こし、エンジニアが実装し、マーケタが効果計測をする —— つまり、一連の流れをミニチーム内で完結できる仕組みです。
とはいえ、デザイナとマーケタはミニチーム専任というわけでもなく、ミニチームをメインにコミットしつつ、スクラムチームのタスクもこなすという体制を取っていました。
ミニチームの方針としては、直ちに大きな収益効果は見込めないものの、ユーザーが実際に使いにくさを感じている箇所の改善を担当していました。これは、スクラムチームが事業計画を軸に開発を行い、さらにユーザーフィードバックの中でも収益面や事業方針に影響しそうな課題を解決するという方針を補うことを狙ったものです。
もっとも、ミニチームの活動は“ビジネス的に意味がない”わけではないと考えており、収益面でもよい結果をもたらす効果はありえると考えています。たとえば、トライアルからの有償契約につなげるうえでの使いやすさの向上や、導入後に解約を減らす効果が期待できるといったことです。
ミニチームの課題解決フロー
ミニチームで行っていた「どのように課題を見つけ、どうやって解決していくか」のプロセスをご紹介します。いろいろな方法を試した結果、最終的には下記のような流れに落ち着きました。
1. 課題選定
まずは、課題の選定です。
課題のネタとしては、プロダクトチームがユーザーフィードバックやチーム内フィードバックに ICE スコアリングをして Notion のデータベースにまとめてくれているので、これを参照しています。
ICEスコアリングとは以下の 3 つを元に優先度を判断するフレームワークです。
- Impact（影響度）
- Confidence（成功率の自信度）
- Ease（実現のしやすさ）
スクラムチームの場合は、これに Business（有償契約につながるか） も加え、B-ICEという形で独自に採点していました。 一方、ミニチームは "B"を外した純粋なICE のスコアが高い課題 を優先的に見ていました。つまり「ビジネス的な収益には直結しないかもしれないけど、多くのユーザーの利益になり、難易度も高くない」という課題を見つけるわけです。
また、私たち自身も普段から NeWorkを使って仕事をしている（いわゆるドッグフーディング） ので、日常的に「ここ不便だな…」と気づいたらバックログに投げ込む、というケースも多いです。あとはユーザーからは報告されていないような小さなバグでも、発見次第対処するようにしていました。
2. 見つけた課題が解決する価値のある課題か見極める
見つけた課題がユーザーが本当に解決したいものかという視点は、案外見落としがちです。ミニチームは少人数でリソースが限られているので、本当に価値がある課題かどうかを厳しく見極めるようにしていました。
そこで取り入れているのが、 「前提 / As-is / To-be」 というフレームワークです。課題に着手する前に、以下の 3 点をしっかり書き出して整理します。
- 前提: 「誰がどのような状況におかれているか」
- As-is: 「いま、実際にどうなっているか」
- To-be: 「理想的にはどうあるべきか」
ここで、As-is / To-be を客観的に書けない場合は、そもそも改善の優先度が低いと判断してスルーするようにしていました。
そして私たちは、この「前提 / As-is / To-be」をユーザーストーリーとして活用しています。 一般的なユーザーストーリーは「誰が / なぜ / 何をしたい」を書く手法が主流で、NeWorkの他のスクラムチームもこれを採用しています。しかしミニチームでは、すでに存在するNeWorkの課題を解決することがメインであるため、より客観的に“現状のプロダクトの課題”と理想とのギャップを浮き彫りにできる「前提 / As-is / To-be」のほうが適していると考えました。
実際、「誰が / なぜ / 何をしたい」を使っていた頃は、「この技術を使えば新しい機能が作れそう！」という、いわゆる“How”ベースのひらめきに突っ走ることがありました。この手法だと案外自分たちに都合のいいストーリーが書けてしまうため、アイデアに勢いがつきすぎると「この機能、絶対いいじゃん！」と客観性を失ってしまうケースがありました。
そこで、私たちは As-is / To-be を明確に書き出し、課題の本質を客観的に捉えることを意識するようにした結果、より確かな価値につながる改善を行えるようになったと感じています。
我々が書いていたユーザーストーリーの例
- [前提]: ルームに入室する際に、認識されているマイクが存在しない場合は自動的に聞き耳入室になり、通常の入室はできないという仕様がある。
- [As-is]: 上記の仕様をユーザーは知らない（知ることができない）ため、この事象に遭遇した際に不具合だと勘違いしてしまい、問い合わせや別の通話アプリに移動してしまう。
- [To-be]: 認識できるマイクが存在しないユーザーがルーム入室時に不具合だと誤認せず、解決方法が理解できるようになっている。
3. 他チームとの連携
ミニチームはスクラムチームから独立していますが最低限のスクラムイベントには参加して、情報共有や進捗をすり合わせていました。
- デイリースクラム: 日々の進捗をお互いに簡単に確認
- スクラムオブスクラムミーティング: 各スクラムチームや関連チーム間での連携を図る
さらに、NeWorkそのものを使って仕事をしていることも大きいです。NeWorkは「誰がどこで、どんな話をしているか」がひと目でわかるインタフェースと、「聞き耳」という機能で発言せずとも会話を“聞く”ことだけをできる仕組みがあり、透明性の高い働き方ができています。
「あ、あのチームが今 ○○ 機能をいじってるっぽい？ じゃあタイミングがかぶらないように注意しよう」
みたいな、ちょっとした情報共有や調整を自然と行え、コミュニケーションにあまりコストをかけずに、コードのコンフリクトを防いだり解決するべき課題が被らないようにしています。
（ところで、入社以来NeWorkを使って仕事をしているので、NeWorkのサービス終了後、どうやって仕事をしていけばいいか…路頭に迷っています）
4. デリバリープロセス
NeWorkのデリバリープロセスはデイリーリリースが基本です。ステージング環境(developブランチ)で1日間ドッグフーディングしたインクリメントは自動的にプロダクション(mainブランチ)環境へデプロイされる仕組みになっています。詳しくは「リリース頻度を毎週から毎日にしてみた」という記事で紹介しています。
ミニチームは要件定義〜デザイン〜実装までチーム内で完結するため、改善の多くがプロダクトオーナーやステークホルダの目にほとんど触れません。
大きめの変更についてはスプリントレビューで関係者に見てもらい、リリースの判断を仰ぎます。一方、小さな改善であればわざわざレビューを待たずに mainブランチへマージ → 自動リリースの流れに乗せてしまい、次のスプリントレビューで事後報告という形を取っていました。
こうすることで、Feature Flagをわざわざ設定する手間やリードタイムを短縮できているのもポイントです。もちろん、こうしたやり方はマネージャ陣の協力や信頼関係が不可欠で、理解を示してくれているマネージャ陣には本当に感謝しています。
ミニチームの改善事例
ミニチームでは以下のような改善を行ってきました。詳細は本記事の末尾の付録に記載しましたのでご興味がありましたらご覧ください。
- デフォルトのルーム名を変更
- ルームバブルのクリック入室
- 招待リンクの送信
- にゃわーく
- ルーム名の折り返しの改善
- バーチャル背景のアップロード
- オンボーディング
- タイルレイアウト選択機能
- デバイスの切り替えトースト
- フォールバック入室の通知
- プロフィール画像の拡大
- カメラの映像と画面共有の同時配信
- 通話中に画面をOFFにしない
- 通知音量調整
- ワードバブル(仮)
- 離席
- 通話中の UI からルーム詳細を開く動線の追加
ミニチームのメリットと課題
メリット
ユーザー対話で高評価を得ている機能は、ミニチーム発のものが多かった
社内外のユーザーと話す機会があると、「あの機能すごく便利ですね」と言われるものの多くがミニチームで作った機能でした。小さな改善でも直接的にユーザー体験を向上させることが多く、結果的にプロダクトのファンを増やすことにもつながったと思います。
コミュニケーションのオーバーヘッドが小さい
チームが少人数であるため、PBI(Product Backlog Item)の記載を必要最小限の簡素な形で進められました。加えて、デザインやインタラクションなどの細かな仕様は口頭ですり合わせることで、ドキュメント作成にかかる手間を大幅に削減できたのも大きなメリットでした。
簡単なバグ修正のリードタイムが短い
問い合わせがあってから、早いもので最短 2 日ほどで不具合を修正しリリースできることもありました。
体験価値の向上を軸に越境できるチーム体制
ミニチームでは、エンジニア・デザイナ・マーケタといった職種の垣根を越え、 全員が「ユーザー体験の向上」を共通の目標として捉えていました。必要であれば、誰もが仕様検討やデザイン検証、アンケート作成、計測設計などに積極的に関わる姿勢ができていました。
特徴的だったのは、エンジニアとデザイナがペアデザインを行うケースがあったことです。たとえば、エンジニアがデザインの素案を作り、それをリアルタイムでデザイナがレビューするという流れです。こうすることで、エンジニアはデザインスキルを学び、デザイナは技術的制約や実装容易性をその場で把握できるため、拡張性と実装難易度を考慮したデザインの感覚の醸成に繋げられるメリットがありました。
また、ミニチームでは、ディスカバリー（課題の洗い出し）からデザインの方向性検討、実装、検証、そしてリリースまでをほぼ自分たちの裁量で進められるという特徴がありました。振り返ると、これはいわゆる“プロダクトエンジニア”的な動きに近かったのかもしれません。
「プロダクトエンジニア」という言葉は、AtlassianのSherif Mansourさんが「Product engineers」という記事で提唱して話題になった概念です。具体的には、フロントエンド・バックエンド・デザインなどの領域を横断しながら、ビジネス面やユーザー体験を総合的に考え、愛されるプロダクトを作るエンジニアのことを指すと認識しています。
ミニチームでの動きがどこまで理想的な“プロダクトエンジニア”に近かったかは分かりませんが、少なくとも私自身のキャリアにおいては、NeWorkの価値を高めるために幅広い経験を積めたことが大きな収穫だったし最高にやりがいを感じていました。
課題
効果測定手法が定まっていなかった
まず、適切なKPIが定まっていませんでした。もともとは新規登録ユーザーの定着率（1週間・4週間後の利用率）をKPIにしていましたが、利用率は企業やチーム単位の導入状況に大きく左右されるため、短期的な成果を見る上では参考になりにくかったです。
結果として「体験の改善」を数値化することは簡単ではなく、ユーザーテストやアンケートによる定性的な評価を行うのがベストかと議論しましたが、コストが高いという課題もあり、十分に手をつけられませんでした。
さらに、個々の機能改善の効果測定についても、必ずしも十分にできていたとは言えない状況でした。ボタンなどの明確なユーザーアクションを伴う改善は計測しやすく、ある程度の効果は数値化できたものの、ユーザビリティのような心理的変化はほとんど見えていませんでした。
振り返ってみると、社内のNeWorkユーザーの集まるSlackチャネルが存在したので、そこを活用して気軽に意見を聞ける仕組みを整えておけば、定性的な評価も比較的低コストでキャッチできたのではないかと感じています。
収益拡大に寄与しているか、定量的に示せなかった
ミニチームでは、トライアルユーザーの体験向上や解約率の低減といった観点から、長期的には収益やブランド価値に貢献できると考えています。
そして、ミニチームがプロダクトにおいてなかなか手の回らない箇所を率先的に改善し、スクラムチームが大きな機能や収益拡大施策に専念できるようにしている、という構造を意識していました。
もっとも、直接的な収益拡大にどこまで貢献しているかは、定量的に示すのが難しいという課題もあります。多くのメンバーには理解をいただきつつも「収益に貢献しているわけではないのでは？」と思われがちで、開発の現場から距離の遠いステークホルダに十分説明できていなかったかもしれません。この点はもう少しコミュニケーションを取るべきだったと感じています。
メンバーからのコメント
本記事執筆にあたり、デザイナとマーケタの方からもコメントをいただきましたので、以下に紹介します。
デザイナ 齋藤
ミニチームの活動はただ純粋に”おもろかった”。 ちゃんとユーザーが欲しているものを作れている感覚、コミュニケーションや管理のストレス無かったこと、頑張って作った機能がユーザーに刺さった反応など、複合した結果”おもろかった”に集約されています。 各メンバーからもこのコメントが出ていることを考えると本当に良い活動だったのだと感じます。デザイナー目線でも、開発メンバーと共創でものづくりをしていく過程は通常のAgile開発よりもスピードが速くとても多くの学びを得られました。
今まで NeWorkをご利用いただきありがとうございました。 サービス終了になってしまった以上、私は次の価値を作りに行きます。そしてまたいつか、皆さんの手元にその価値が届くことを願っています。
マーケタ 藤原
NeWorkが大事にしている「誰が言ったかではなく、何を言ったか」をものすごく体現できているチームだったと思います。私は新入社員としてこのチームに加わりましたが、フラットな関係性のおかげで、自分の意見を素直に発信しやすい環境でした。互いに「違うものは違う」「良いものは良い」と率直に意見を交わせたことが、何よりもユーザー視点での改善につながったと思います。
また、効果検証を担う立場として、私たち自身が「使いたい！便利！」と感じる機能ほど、実際のユーザーも気に入って使ってくれていました。（ルームをクリックして入室する機能や、にゃわーくなど…） ミニチームでの経験を通じて、サービス提供者とユーザーが対立構造にあるのではなく、一緒に使いやすいプロダクトを創っていく関係性を築くべきだと実感しました。
NeWorkとしては一区切りとなりましたが、これまでの経験を活かし、毎日使いたくなるプロダクトづくりに携わっていきたいと思います。今までありがとうございました！
おわりに
ミニチームのリリースした機能が好評だったことを考えると、活動自体には一定の効果があったと感じています。一方で、ビジネス面への貢献度をどう評価するかは、引き続き課題として残ります。周囲の理解を得た上で良いプロダクトを生むために必要なことだと思うので、これからも考えていきたいです。
個人的には、この活動を通じてさまざまな経験を積むことができ、確かな成長を実感しています。ミニチームを任せてもらえたことには、大変感謝しています。
もし同じようなプロダクト改善専任の少人数チームを立ち上げるなら、独立性や裁量、目的意識の共有、迅速でフラットなコミュニケーション、そしてマネージャやステークホルダの理解・信頼が重要になると思います。
残念ながら、NeWorkはサービス終了となってしまいますが、終了を惜しむ声をいただけたことや「NTT Comにはこうした良いサービスを作れる人がいる」と思ってもらえた（と信じています）ことは、私にとって大きな財産です。今後も、この経験を活かしてより良いプロダクト作りに貢献していきたいと思います。
(付録) ミニチームの改善事例の詳細
さいごにミニチームが改善した事例をいくつかご紹介します。これ以外にも小さな改善やバグ修正を行っています。
デフォルトのルーム名を変更
NeWorkでワークスペースを新規作成した際のデフォルトのルーム名を変更しました。
変更前は「定例」、「開発チーム」、「朝会」、「カフェ」というルーム名でしたが、これは多くの人にとって具体的に利用しているイメージが湧きにくいルーム名でした。そこで、具体的な動作に結びつく「雑談ルーム」、「ミーティングルーム」、「作業ルーム」というルーム名にしました。また、1つを未定義にしたことでルーム名を自由に定義できることを暗示しています。
ルームバブルのクリック入室
ルームバブル自体をクリックするだけで入室できるようにしました。 改善前はルームバブル上の青い入室ボタンか、「…」からしか入室できずわざわざカーソルを合わせるという心理的負荷がありました。 改善後は押下範囲の拡張により、操作性が上がりました。さらに直接聞き耳に参加することも可能になりました。一方で誤操作を起こしやすくなったため、通話中のルーム移動時にダイアログを出すオプションや機能をOFFにするオプションも用意しています。
招待リンクの送信
ワークスペースの招待リンクをNeWork上で送信できるようにしました。 これまでは招待リンクをコピーして別の方法で共有する方法のみでしたが、相手のメールアドレスを指定して招待を送信できるようにしています。
にゃわーく
エイプリルフールのお楽しみとして、『にゃわーく』モードを実装しました。 アイコンやルームリアクションが猫仕様になったり、入退室音が猫の鳴き声になったりします。
ルーム名の折り返しの改善
ルーム名が自然な位置で折り返されるように改善しました。
バーチャル背景のアップロード
ユーザーがバーチャル背景をアップロードできるようにしました。
それまでバーチャル背景機能はありましたが、ユーザー自身がバーチャル背景をアップロードできないためベータ機能という位置づけでした。 バーチャル背景のアップロード機能や、自身の映像を反転させるか選択できる機能を追加し、ベータから正式な機能にしました。
オンボーディング
NeWorkを初めて使うユーザーに対してオンボーディング機能を追加しました。
これまでは、NeWorkを初めて使うユーザーには使い方を紹介する動画をポップアップで表示していました。しかしクリック率(再生率)が著しく低く、NeWorkの基本的な使い方を理解する前に離脱しやすい状況だったため、チュートリアル形式でオンボーディングできる機能を実装しました。
タイルレイアウト選択機能
タイルレイアウト選択機能を正式リリースしました。
開発チーム改善活動で「タイル表示スタイル選択機能」としてベータリリースされていた機能を、フィードバックを元に改善し、正式リリースしました。
デバイスの切り替えトースト
音声入出力デバイス・映像入力デバイスが切り替わったときにそれを知らせるトーストを実装しました。
ユーザーの意図に反して使用中のデバイスが認識できなくなり別のデバイスにフォールバックした場合に、気付けるようにしています。
フォールバック入室の通知
音声入力デバイスがない状態で室内に入室しようとすると自動的に聞き耳入室をするが、その際にその旨をトーストで通知するようにしました。
これにより、ユーザーにマイクを繋ぐなどの具体的な動作を動機づけられるようになりました。
プロフィール画像の拡大
プロフィール画像を拡大表示できるようにしました。
一般的には、画面にユーザーアイコンがある場合、クリックなどで拡大して表示できると期待されます。NeWorkではできなかったので実装しました。
カメラの映像と画面共有の同時配信
カメラの映像と画面共有を同時に配信できるようにしました。
NeWorkの特徴として、複数人が画面を共有できる点が挙げられます。一方で、これまでは画面共有とカメラ映像を同時に配信できないという制限がありました。たとえば、チームメンバーが全員カメラをオンにして会議をしていても、画面共有をしている人の表情だけは確認できない状態でした。これでは不便なので、全員がカメラ映像と画面共有を同時に使えるようにアップデートしています。
通話中に画面をOFFにしない
パソコンを一定期間触らないと自動的に画面がOFFになる設定をしていても、通話中は画面OFFにならないよう変更しました。
もともとブラウザは映像が流れている場合、画面をOFFにしない仕組みになっています。しかし、「誰も映像を配信していないルーム」で通話を続ける場合は、画面が消えてしまうことがありました。今回の対応により、映像がない状態でも通話中は画面が消えないようになり、より快適に会話を続けられるようになりました。
通知音量調整
通知音量を調整できるようにしました。
1on1やルームへの呼び出しの呼び出し音が聞こえなかったというフィードバックや、逆に入退室音がうるさいというフィードバックなど、通知音量に対するフィードバックは千差万別でした。 そこで、好みに合わせて調整できるようにスライダーで音量を調整できるようにしました。なお、人間の聴覚特性に合わせて低い音量レベルでより細かい調整ができるようにスライダーを実装しています。
ワードバブル(仮)
ルーム内の会話から話題を抽出して、ルームバブル上に表示する機能(ワードバブル(仮))を実装しました。
ルームの外から、ルームの中で行われている会話の内容や温度感を把握できるようにすることで、ルームに参加しやすくする機能です。 開発中にサービス終了が決まり、社内向けのリリースに留めました。
離席
一時的に席を外していることを表せる、離席機能を機能を実装しました。
リモートワークにおいて、宅配や着信などで突発的に席を外さざるを得ないことは少なくありません。そして、自分が話者ではないときにそれを伝えることは難しいです。そこでワンボタンで離席状態を表現できる機能を実装しました。
通話中の UI からルーム詳細を開く動線の追加
通話中にそのルームの詳細パネルを簡単に開ける動線を追加しました。
これまで通話中にルームの詳細を開くときは、ルームバブルの「…」から開く必要がありました。特に映像をタイル表示しているときは、タイル表示を非表示にしてから「…」ボタンを押す必要があり手間でした。 そこで、通話中でも常に表示されている場所に、ルーム詳細を開く動線を追加しました。
- 執筆時点では、開発体制は縮小しています。↩
