NOW TO THE FUTURE

音楽とインターネット育ち、駆け出しマーケターのブログ。

モブエディティングでより良い「チームでの記事編集」を模索し始めた話

「モブプログラミング」(モブプロ)というプログラミングの手法があります。

1台のパソコンの前にチームで集まって、「ここはこういうコードを書く必要があるよね」などとワイワイ話しながらコードを書いていく、プログラミングの方法です。

群れる(=モブ)プログラミングだから、モブプログラミング。詳しくは、このあたりをご覧ください。

www.wantedly.com

そんなモブプログラミングを、最近「モブエディティング」という形で、記事編集に応用してみています。

なぜモブエディティングを始めたのか

より良い記事編集を行うために、1人の編集者だけが編集して終わるのではなく、別の編集者(上司も含む)もレビューに参加する体制はよくあると思います。

レビュー自体は悪いものではありません。客観的な視点を取り入れることでしか発見できないミスや、改善すべき点もありますから。

しかし、レビューを取り入れた仕事の進め方をしていて、このような苦痛を味わったことはないでしょうか。

  1. レビュー&指摘対応のやり取りが何度も続いて、疲弊する。自分にボールが飛んでくるたび、別の仕事を中断して対応する必要がある(脳のスイッチングコストが発生する)ので、疲弊する。
  2. レビュアーは修正された内容を、レビューされる側は指摘された内容を確認/理解する(情報を同期する)ことに意外と時間を取られてしまう。指摘の誤解もときどき発生して、タイムロスになる。

これらの苦痛を回避するために、モブエディティングを試すことにしました。元ネタのモブプログラミングがまさしく、プログラミングにおけるこれらの苦痛を回避できると言われているのです。

冒頭で「モブプログラミングは、1台のパソコンの前で、チームでワイワイしながらプログラミングする手法」と説明しました。

これはつまり、モブプログラミングでは「いま扱っているプログラムが、どういう意図を持って、どういう変更が行われているのか」をチームメンバー全員がリアルタイムで共有できることを意味します。

これが、前述したレビュー体制の苦痛を軽減するのに役立つわけです。つまり、「レビューと指摘対応のたびに発生する、脳を別の作業から切り替えるためのスイッチングコスト」と「レビューや修正の内容を毎回確認/理解するコスト」を削減できるのです。

図をまじえて、とても分かりやすく解説されている記事があったので、一部を引用しておきます。

tech.bizreach.co.jp

モブプロのメリット

メリット1: レビュー&指摘対応の手戻り工数を大幅に減らせる

コンテキストスイッチというのは、一つの作業から別の作業を行う際に、前に何を行なっていたか思い出すのに時間がかかり、効率が悪くなる現象を指します。

メリット2: 分担によって発生する作業が減らせる

タスクの分担等のは一見効率的ですが、実は分担の前後で「分担の計画」や「同期するための作業」が発生しています。

これを記事編集の仕事でも応用できるのではないか、と考えたわけです。

今やってみているモブエディティングの形と、実感しているメリット

では、具体的にどう応用しているか。

元ネタのモブプログラミングそのままではないので(というか結構アレンジしています)、現状試しているやり方を簡単に書いてみます。

  1. 担当者は、ライターさんの原稿をひとまず一通り編集してしまう。
  2. 一旦、レビュアーに編集した原稿を渡す。この際、「一通り目を通して、気になる点に目星をつけるだけしておいて(実際に赤入れはしなくていい)」とお願いする。
  3. レビュアーが気になる点に目星をつけるあいだに、担当者は1時間程度、レビュアーと都合が合う時間を押さえる(原稿がそもそも長い、もしくは修正範囲が広範に及ぶ場合は、数回分の時間を確保することもある)。
  4. 押さえた時間で、気になった点の共有と、その検討・反映までを一気に行なってしまう。

このやり方を行なうメリットは、結局はモブプログラミングと同様です。レビューや指摘対応のたびに発生する、別の作業からのスイッチングコストと、「進捗状況の同期」=「前回のレビューから何が変わったかの把握」にかかる工数を大幅に削減できることです。

今の時代は、デジタルで原稿のやり取りが簡単にできますから、「わざわざ時間を合わせて、一緒に作業するなんて!」と思う方もいるかもしれません。僕も最初はそうでした。しかし1度やってみると、予想以上にサクサクと原稿編集を完了まで持っていけるやり方であることに気がつき、驚きました。

注意したほうが良さそうな点

何度かこのやり方を実践してみて、2つほど注意したほうが良さそうな点も分かってきたので、書いておきます。

注意1:スキルが高い人は、低い人が考える時間をのんびり待ってあげるか、逆にガンガン引っ張るかのどちらかに振り切ったほうがいい

気になった点の共有から、その検討・反映までを一気にリアルタイムで行なうため、スキルが低い人がいると、スキルが高い人はどうしても「なんでこんなに修正の検討に時間がかかるんだ」と感じがちです。

ここでイライラしたり、「私はこうするのがいいと思うけど、あとは考えてみてね、任せるね」などと言って、中途半端に答えを出して突き放すと、メンバーは不安になり、このやり方は上手く機能しなくなります。

この手法では、その場の心理的安全性を高く保つことが非常に重要なのです。

そのため、スキルが高い人は、低い人が考える時間をのんびり待ってあげるか、逆にガンガン引っ張ってあげるかの、どちらかに振り切りましょう。

いずれに振り切っても、知見(暗黙知を含む)を共有して、チーム全体のスキルを高めることに役立つので、長い目で見るとメリットがあるはずです。最初は慣れないかもしれませんが、ここはスキルが高い人が寄り添ってあげるしかありません。

※話がややこしくなるので、あえてここまで書きませんでしたが、元ネタのモブプログラミングには「暗黙知の属人化を減らせる」という利点もあります。詳しくは先ほども引用した記事「本格的モブプロ導入のために確認しておきたいこと」などをご覧ください。

注意2:すべての工程・チームに向いているやり方ではない

ここまで、モブエディティングは万能かのように書いてきましたが、実際はそうでもありません。

まず、モブエディティングは使う工程の見定めが重要です。例えば、先ほどモブエディティングの手順にて、最初に下記のステップを記しました。

  1. 担当者は、ライターさんの原稿をひとまず一通り編集してしまう。

状況やチームのまとまり方によっては、初稿のフェーズからモブエディティングしてもいいかもしれません。しかし、一切の方向性が定まっていない状態だと、モブエディティングに呼ばれた側は困惑する可能性が高いです。そのため、最初は単独で編集するのが基本的にはやりやすいかと思います。

このほかのフェーズについても、モブエディティングより通常のレビュー体制で進めるのがいい場合もあります。いろいろ試して、合う部分と合わない部分を見定められるといいでしょう。

また、そもそもチームメンバーの性格やチームの風土によって、モブエディティングが全般的に向かないことさえあります。モブエディティングは目的ではなく、あくまで手段の1つであって、無理に使うべきものではないことを忘れないことが大事でしょう。

おしまい

まだ試行錯誤の段階ですが、チームでより良い記事制作をするために、上手く取り入れていけるといいなと思います。

テレビ会議やGoogleドキュメントなどを活用して、リモートワークのメンバーがいるときでも活用できると、なお使い勝手が良くなりそうですね。