エンジニアとデザイナーで「モブライティング」をやってみた話 〜 ドキュメンテーションの工数削減術

こんにちは。UXデザイナーの近藤です。

みなさんは、ユーザー向けのドキュメントをどのように作っているでしょうか？
デザイナーが書くケース、エンジニアが書くケースなどさまざまだと思いますが、どのケースにおいても、関係者に質問や相談をしたり、レビューと修正を繰り返したりと、煩雑になりがちではないでしょうか。

そこで新たな試みとして、エンジニアとデザイナーが同じ時間で共同作業する「モブライティング」をやってみたところ、工数を大幅に削減できました。実施の背景や進め方、実施してみて感じたメリットや課題についてお話ししたいと思います。

実施の背景

私は、インターネット広告の配信設定を行う社内ツールの開発・運用を行っているチームで、エンジニアと連携しながらツールのUI設計や改善、UXリサーチなどを行っています。
エンジニア9名、デザイナー1名というチーム構成（2022年10月時点）の中で、より効果的・効率的に業務を進めていくためには、エンジニアとデザイナーとのきめ細かな連携が不可欠です。そのため、モブデザイン（※）などの手法を適宜採り入れながらUIの仕様検討を行うなど、エンジニアとデザイナーの協働を推進しています。

チームでは複数の社内業務用ツールを運用しており、その一つに、広告掲載面に関する情報の管理を行うツールがあります。このツールでは社内ユーザー向けのドキュメント（ヘルプ）が提供されていなかったため、作成することになりました。

従来のチーム内フローでは、担当者が原稿を作成 → チーム内の複数のメンバーがレビュー → レビュー結果を受けて担当者が修正 → 再レビュー という流れが標準的でした。
しかし、デザイナーが原稿を作成するとなると、技術的な仕様についてエンジニアに確認しながらの作業となるため、時間がかかります。逆に、エンジニアが原稿を作成する場合、ユーザー視点でわかりやすいドキュメントにするため、デザイナーに意見を求めたいことも出てくると思います。また、レビューにおいても、文字ベースでのやりとりは煩雑になりがちです。

どのメンバーも他の開発タスクや設計タスクを多く抱えているため、ドキュメント作成に工数を割きすぎず、なるべく効率良く進めたいと考え、モブライティングを実施してみることにしました。

モブライティングとは

モブデザイン（※）をライティングに応用した手法です。ここでは、「文章を書く人と、書くテーマについて詳しい知見のある人が集まり、記載内容についての意見出しや合意形成を行いながら、文章の作成やレビューを実施すること」と定義しました。

※モブデザイン：デザイナー問わず3人以上で同時にデザインの工程を進める手法。モブデザインについての詳しい内容は、「 ペアデザイン・モブデザインを導入してみませんか？品質向上やプロジェクトの効率化 」の記事をご参照ください。

進め方

1. ドキュメントの基本方針を決める

モブライティングを始める前に、ドキュメントの基本方針を明確にしました。どういった粒度でどこまで情報を網羅するのかなど方針を決めておくことで、モブライティングを実施するにあたってメンバー間で共通認識を持つことができ、スムーズに進められるのではないかと考えたからです。

ドキュメントの方針については、UX（ユーザーエクスペリエンス）を考慮して、デザイナーから以下の提案を行いました。

• 入力方法の説明や入力上の注意点をドキュメント上で細かく記載しない（ドキュメントで解決するのではなく、入力フォームの改善やバリデーション対応など、ツールそのものの改善で対応すべき）
• そのため、まずはチュートリアルのような基本的な内容にし、ユーザーからのニーズに応じて適宜拡充していく
• ユーザーからのニーズやフィードバックを収集できるよう、投稿フォームをドキュメント内に設置する

提案をふまえ、モブライティングに参加するメンバーだけでなくチーム全員で議論し、合意形成を行いました。これによって、アウトプットのイメージについてあらかじめチーム内で認識あわせができ、モブライティングを円滑に進めていくうえで大いに役立ちました。

＜ユーザーからのニーズに応じてドキュメントを拡充していけるよう、ドキュメント内に設置することになった投稿フォーム＞

2. モブライティングの参加者、実施方法を決める

ドキュメントの基本方針について検討した際、あわせて、モブライティングの参加者も話し合いで決めました。ツールのUX改善施策の推進担当者3名（デザイナー1名、エンジニア2名）のほか、モブライティングに興味を持ったエンジニア2名がレビュアーとして参加してくれることになり、計5名で実施することになりました。

他の開発や設計のタスクとの兼ね合いを考慮し、モブライティングは1回につき1時間程度、週1回程度で実施することとしました。ヤフーはオンライン中心の働き方となっているため、Zoomで画面共有をしながら実施しました。ファシリテーションは、モブデザインの実施経験があることからデザイナーが担当しました。

3. ドキュメントの構成（項目立て）を決める

文章を書く前に、ドキュメントの骨子を決めるための項目出しを行いました。
前述の基本方針「チュートリアルのような基本的な内容にする」をふまえ、内容の粒度について参加者で意見を出し合った結果、業務フローに沿った設定のステップを「1.〇〇情報登録」「2.△△登録」「3.□□作成」「4.××情報登録」「5.☆☆発行」のように項目化しました。

4. 文章を書く

骨子が決まったら、いよいよ文章を書いていきます。まずは、前述の項目立てに沿って各ステップでどのようなことを書くか、参加者で意見を出し合いました。

「ステップごとに、どの画面で何の設定を行うのか説明するのがよいと思います」

「ドキュメントの基本方針で『入力方法の説明や入力上の注意点をドキュメント上で細かく記載しない』ということになったので、具体的な設定内容は書かず『〇〇画面で必要事項を入力し、〇〇を発行してください』くらいの粒度でよいのではないでしょうか」

「そうですね。設定項目についての詳しい説明が必要な場合は、入力フォーム上のツールチップなどで対応するのがよさそうですね」

「設定画面へのアクセス方法も、画面キャプチャーを入れて説明しておくとよいのではないでしょうか」

「5つめのステップは、審査完了後に設定可能になることを書いておくほうがよいと思います」

「〇〇で必要な設定がケースによって異なるので、ケース別に必要な設定がわかるようにしておくとよいのではないでしょうか」

など、話し合って決まった内容をもとに、デザイナーが文章化していきました。その際、ツールの仕様などについて不明点があればその場でエンジニアに確認できたため、スムーズに書き進められました。
Zoomで画面共有を行いながら文章を作成し、意図したとおりの内容になっているか、文章はわかりやすいかなど、その場でレビューしてもらいました。「〇〇でケース別に必要な設定は、文章だとわかりにくいので表形式にしたほうがよいかもしれませんね」など、レビューで出た意見をふまえてその場でブラッシュアップしていきました。

このように、参加者がその場で意見を出し、出た意見について参加者間で合意形成をしながらリアルタイムに反映していくことで、書き直す二度手間や「持ち帰って直します」というタイムラグもなくなり、効率があがりました。

5. レイアウトを整える

社内向けのドキュメントは、主に情報共有ツール「Confluence（コンフルエンス）」を利用して作成されています。ツールの社内ユーザー向けドキュメントもConfluenceで作成し、文章を書いた後、見出しのスタイルなどを設定してレイアウトを整えました。

文章にあわせて掲載する図（ツールの画面のキャプチャー）も、その場で作成していきました。文章を書く時と同様、デザイナーがZoomで画面共有しながら作業を行い、他のメンバーがその場でレビューしながら、ドキュメントを完成させていきました。

＜モブライティング中のZoom画面＞

メリットと課題

モブライティングを実施した最大のメリットは、全体の工数を大幅に削減できたことです。内容の検討、文章作成、レビューを同時に進めることができ、手戻りを防いで効率良く進められました。

＜従来のチーム内フローとモブライティングの工数比較＞

一方で、課題も見つかりました。今回実施した事例では、参加者が5名とやや多かったため、メンバーの発言の頻度に偏りが出てしまいました。人数が多いと多角的に意見を出し合えるメリットがありますが、参加者全員がバランス良く関われるよう、ファシリテーションの工夫が必要だと感じました。

また、レビューに関しても、モブデザインの場合と異なり文章を読んでいくため、ある程度の時間が必要になります。モブライティングの時間内だけでは十分なレビューを行えない場合もあるため、必要に応じて別途時間を設けるなど、レビューの質を保つための工夫も必要かもしれません。

おわりに

前述のとおり、実施方法などに工夫の余地はあるものの、モブライティングによるメリットは非常に大きいと感じました。

今回はデザイナーとエンジニアの協働事例でしたが、テクニカルライターとの連携など、さまざまな場面で応用できるのではないかと思います。
プロセス全体を通して実施することが難しい場合は、部分的に採り入れてみるのもよいかもしれません。このTech Blogの記事を執筆するにあたっては、私が原稿を作成した後、チームメンバーによるレビューをモブライティング形式で実施しました。テキストベースでのレビューと比べて、メンバー間でのコミュニケーションをとりやすく、レビュー結果をふまえた修正方針のすり合わせをスムーズに行えました。

モブライティングはまだ確立されたやり方があるわけではないため、今後も試行錯誤を重ねていければと思っています。