PLAIDEngineer Blog
エンジニア積極採用中

「KARTE Blocksリリースの裏側」の裏側 - 複数人で連載記事を書く方法

Blocks Team

Posted on

「KARTE Blocksリリースの裏側」はKARTE Blocksが2021年9月14日に正式リリースされたことを記念して開始した連載シリーズです。
2021年11月8日に公開した「KARTE Blocksを支える技術」から11月19日に公開した「KARTE Blocksにおけるポジショニングの考え方とその狙い」まで10本の記事を公開しました。

このように複数人での連載記事を書く場合にどのように進めるべきか、「KARTE Blocksリリースの裏側」という連載ではどのように進めていったのかについて紹介します。

最初に編集者を決める

複数人で書く場合に重要なのが、編集者を決めることです。
複数人で書く連載は、記事の内容がバラバラになりやすいです。
そのため、連載としてのバランスの良さを求めるならば、それを管理する編集者を決めておくことが重要です。

編集者は次のような役割をもっています。

  • コンテンツのアサイン、進捗の確認、目標設計をすること
  • コンテンツのクオリティコントロールをすること
  • コンテンツの誤字脱字、表記揺れなどの減らすこと
  • コンテンツの公開状況を管理すること

連載をコントロールできる人がいないと、おそらく連載のどこかで歪みが発生してしまいます。

想定読者と目的と目的外を決める

記事を書きはじめる前に決めることとして、読者の想定ターゲットと何を目的とした連載なのかです。

「KARTE Blocksリリースの裏側」は、KARTE Blocksのリリースが完了した後に、
リリースを記念してリリースまでの裏側のブログを書いたら面白いのではというところから企画が開始しました。

「KARTE Blocksを支える技術」で紹介していたように、メルカリさんの「連載：「メルカリShops」プレオープンまでの開発の裏側」を参考にしています。

この企画をBlocksチームでどうするかを話し合ったときに、まず最初にすり合わせをしたのは想定読者と目的です。
この想定読者と目的が連載の記事間で統一性がないと、チグハグしたものとなってしまいがちです。

そのため、「KARTE Blocksリリースの裏側」では主な想定読者をエンジニアやデザイナーを含む開発サイドの人という設定をしました。
具体的には、話し合いをしたミーティングノートには次のように書かれていました。

  • 想定読者は誰か(誰が読むべきか)
    • 一言でいうとだれが読む: 開発サイド向け
    • エンジニア、デザイナーなど開発サイドの採用につなげたいため
    • そこから派生してPdMやカスタマーサポートに話が広がるのはOK
  • 連載の記事ごとに具体的な対象は変化する
    • Engineer
    • Designer
    • 新規事業に興味があるPdM

また、連載の目的についても、次のように開発者へのKARTE Blocksの認知の向上を設定しています。

  • エンジニア採用につなげる
  • （優先度は低いが）Blocksの認知向上につなげる

連載の目的を設定する際に、連載の「目的ではないこと」を設定することも重要です。
「目的ではないこと」を明確にすることで、記事の内容の方向性がずれにくくなります。

「KARTE Blocksリリースの裏側」の「目的ではないこと」として次のように設定しました。

  • KARTE Blocksの集客は目的ではない
    • 認知度向上は目的だが、クライアントになってもらうこと自体は目的ではない
    • プロダクトの説明が中心となることは避ける意図

ひとつの記事でも長くなってくると、何を目的として何が目的外かが段々とぶれてきます。
特に連載のように期間が長く、量も多いコンテンツを扱う場合はこの傾向が強くなります。
そのため、目的と目的外をあらかじめ書き出しておき、記事を書くタイミングで確認することは重要です。

連載のコンテンツの案を出す

「KARTE Blocksリリースの裏側」では、Blocksチームでどのような記事を連載で書くかを話ながら決めていきました。
複数人での連載で難しいのは、記事のコンテンツの被りやコンテンツ同士のバランスの悪さが出てしまう点です。

まずは、コンテンツの元となるトピックをBlocksチームで出し合いました。
トピックをまとめるのにはNotionを使い、トピックをデータベースのTableに記録し、そのトピックの主なカテゴリのラベルをつけていきました。
このラベルは、主に想定読者がエンジニアなのか、デザイナーなのかといった分類をする際に役立ちます。

NotionのTableで管理していたトピック

トピックを出し合って、そのトピックのカテゴリ別で分類してみると、どのような記事が書けるのかがある程度見えてきます。
Notionでは、データベースのViewをBoardにして、カテゴリのラベルをGroup byすることで、カテゴリ別の表示ができます。

NotionのBoardでカテゴリ別表示したトピック

それぞれのトピックのサイズは1つのセクションぐらいのものから、1つの記事になるようなサイズまでさまざまでした。
これらのトピックをもとにどのような記事を書いていくかの検討を進めました。

連載の記事の方向性を決める

連載のコンテンツの元となるトピックを出してカテゴライズしてみると、さまざまな記事を書けそうなことがわかりました。

ここで、実際に記事を書く際に、2つのパターンが考えられます。

  • 記事をカテゴリごとに書いていくパターン
  • 記事を複数のカテゴリ横断で書いていくパターン

最終的に「KARTE Blocksリリースの裏側」では、後者の「記事を複数のカテゴリ横断で書いていくパターン」を採用しています。
それぞれのパターンのメリットとデメリットについて見ていきます。

記事をカテゴリごとに書いていくパターン

「記事をカテゴリごとに書いていくパターン」のメリットは、担当の決めやすさや書きやすさです。
たとえば、"フロントエンド"というカテゴリについて書くことを決めれば、書く人が決まりやすく、書く内容もカテゴリに沿ったものとなります。

一方で、カテゴリで書くデメリットとしては、タイトルが退屈なものとなりやすいことです。
たとえば、"フロントエンド"というカテゴリに書くということが決まった場合、その記事のタイトルはおそらく「xxxのフロントエンド」や「xxxのフロントエンド技術スタック」などになります。
これは、タイトルに限らず内容もこの枠に囚われてしまいやすいです。

記事を複数のカテゴリ横断で書いていくパターン

「記事を複数のカテゴリ横断で書いていくパターン」のメリットは、個性的な記事になりやすいことです。
これは、複数のカテゴリの話をまとめる必要性があるため、記事の内容に深みが生まれやすいためです。
複数のカテゴリの話が集まるため、読者にとっても知らない話に遭遇しやすくなる可能性が高くなります。
これによって記事としての面白さが出やすいと考えています。

一方で、カテゴリ横断で書くデメリットは、書くのが難しいことです。
特に複数人で書く場合は、カテゴリが混在するため、誰が描くのかの調整も難しくなります。

どちらのパターンで書くかを話しあっていたときに、チームの形にあわせることにしました。
Blocksのチームの人は「フロントエンド」や「バックエンド」という役割があるわけではなく、それぞれがそのときの最適な形を取ります。
そのため、チームの動きから見てもカテゴリごとに書いていくのではなく、カテゴリを横断した形で書くのが適切だと考えました。

カテゴリ横断の記事候補を考える

「KARTE Blocksリリースの裏側」では「記事を複数のカテゴリ横断で書いていくパターン」を採用することに決めました。
カテゴリ横断で記事を書くと面白さが出る可能性はありますが、難点は何を書くのかという記事のテーマを決めるのが難しいことです。

この記事と担当者を決めるのにも、先ほどNotionで管理していたトピックを利用します。
NotionのデータベースTableでは、Relationsを使うことで別のTableのデータを参照できます。

記事候補という新しいのTableを作成し、Relationsとして先ほどの記事のトピックのTableを参照します。
そのトピックをいくつか集めて、そのトピックに対して仮のタイトルをつけてみてしっくりくるかどうかという作業を繰り返すことで、記事候補を作っていきました。

トピックをまとめた仮のタイトルをつけたテーブル

たとえば、次のようなトピックがあった場合、これらのトピックはなんとなくプロダクトを改善するというテーマがありそうです。

  • リリース後のLiveやファネルを使った改善
  • Blocks内でBlocksを使う
  • ポチポチ会でのドッグフーディング
  • TechTouchでSelf Serveを促す仕組みをノーコード（一部ローコード）で開発した話

これらのトピックをまとめた記事候補として「ユーザーが自分でBlocksを理解・学習するための仕組み」を作り、この記事を書く担当者を決めることで進めました。（タイトルは仮案なので、記事の大まかなテーマがわかるもの程度にしていて、実際に公開時のタイトルとは異なるものがほとんどです）

最初にトピックを出し合っていたので、カテゴリ横断でもそれぞれの記事に個性があるテーマになったと思います。
また、担当者は基本的にはメインを1人にしています。
1つの記事を複数人で書くのは難しいため、分からないことは他の人に聞くぐらいがバランスが取れます。

最終的には10記事分ほどのテーマと仮のタイトルを決めて記事を書いていくことにしました。

記事を書く

書くテーマと担当が決まったのであとは書くだけです！

しかし、現実は簡単には記事を書けません。
記事を書き慣れてない人がいたり、テーマをどう記事に落とし込むが難しかったり、時間がなかったりといろいろな理由があります。

連載は1日ごとに公開していくのがよくあるパターンです。
そのため、いつから開始するかが決まれば、いつまでに記事が書き終わっていないといけないかという締切が決まります。

「KARTE Blocksリリースの裏側」の企画は、Blocksが2021年9月14日に正式リリースされた少し後の10月頃に始まりました。
そのため、11月頃に開始できるといいねという話をしていました。
これは、12月だとアドベントカレンダーが始まってしまい、連載の強みが埋もれてしまうためです。

最終的には開始日を2021年11月8日として、準備できる期間は一ヶ月弱ほどなりました。
長いように見えますが、チームメンバー7人で10記事を書く予定だったのでギリギリになることは予想されていました。
ここでは、記事を書く前、記事を書いている間、記事を書いた後に分けて、どのような形で進めていったのかついてみていきます。

記事を書くまえにやったこと

複数のカテゴリを扱う記事が中心となっていたため、いきなり書きはじめるのは難しいです。
また、エンジニアやデザイナーで投稿場所が異なる(エンジニアブログとデザイナーブログなどで異なる)ため、投稿予定の記事を管理する場所を用意しました。

  • GitHub
    • 主にエンジニア向け
  • Notion
    • デザイナーやPdM向け

エンジニアはMarkdownで書くことに慣れていたので、記事を管理するGitHubリポジトリを1つ用意しました。
用意したといっても、GitHubリポジトリを作成して、Markdownで書くようにディレクトリ構造を決めただけです。
このときに合わせてtextlintを設定し、action-textlintを使いPull RequestでLintが動くようにしました。

textlintのルールはtextlint-rule-preset-ja-technical-writingを少し緩くしたものとtextlint-rule-prhで辞書を管理していた程度です。
CIでのチェックもレビューコメントにLint結果が出るようにしただけで、Lint結果がエラーでもマージできるようにしていました。
これは、書籍などとは異なり連載全体で表記の統一がそこまで求められるものではないためです。
そのため、あくまで参考程度のものとして扱うようにしました。

リポジトリで記事を管理したのは結果としては良かったと思います。
投稿前に同じような表記のミスをまとめて修正したり、連載の全体間を見る際には一箇所にまとまっていることは便利でした。

デザイナーやPdMはNotionで記事のドラフトを書いてもらいました。
統一的な場所で管理するよりも、書いてもらうことが優先されるため、一箇所で管理することにはこだわりませんでした。
Notionの場合は、Notionのコメント機能などを使いレビューしたり、直接編集して表記を合わせたりしています。

GitHubとNotionどちらもそれぞれの良さがあるので、好きな方を使ってもらうことにしました。

記事を書いている間にやったこと

書く場所を用意したので、あとは書くだけです！

しかし、やっぱりそう簡単には書けません。

記事を書くときに難しいことは、主に次のことがあります。

  • 何を書けばいいのかわからないこと
  • 書き終わらないこと

「何を書けばいいのかわからないこと」については、最初にトピックを決めていたのでまったく決まらないということはありませんでした。
ただし、1つの記事を完成させるには、トピックをどのような順番で、どのような構成で書くかを決める必要があります。
この点に関しては、アウトラインを書いてもらってレビューしたり、一緒に話しながらアウトラインを書くことで進めました。

もうひとつの「書き終わらないこと」については、記事を書くことに慣れてない人が陥りやすいです。
最初からしっかり書いてしまい、トピックが多いとなかなか書き終わらないことで疲れてしまいます。
そのため、まずは多少乱雑でもいいので、書き終わることが重要であるということを伝えていました。

多少乱雑でも一度書き進めてみると、何を伝えたいのかが本文に出てきます。
この文をもとに改めてアウトラインを整理したり、他の人にレビューしてもらうことで記事の落とし所が見つけられます。
どうしても文章を書き進めてしまうと深みにハマってしまうことがあるため、別の視点(アウトラインや別の人の視点)を活用することで進みやすくなります。

書いている途中の記事をレビューする場合は、文章の流れや過不足といった構造を指摘します。
細かい表記や誤字の細かい修正は、文章がある程度完成した段階でまとめてやることにしました。

記事を書いた後にやったこと

記事の本文が大体完成したら、あとは公開に向けて細かい修正をしていくだけです。

今回はあまり時間がなかったため、表記揺れや誤字脱字といった細かい調整は編集者がまとめて対応しました。
記事はリポジトリで管理していたので、まとめて修正したりprhの辞書で単語や表記をある程度合わせたりしています。

具体的には、長過ぎるセンテンスは分ける、表記揺れをprhの辞書で統一する、リンクを補足するなどの読んでいてストレスがないような文章にする修正をしました。

連載の掲載順を決める

連載といっても人によって読むタイミングや気づくタイミングは異なるため、すべての記事を順番に読むことは期待できません。
そのため、掲載順はそこまで重要ではなかったです。

最初をKARTE Blocksの全体感がわかるKARTE Blocksを支える技術にした程度で、あとは記事の依存関係をみて書いた順番で掲載しています。

順番に読むことは期待できないとはいえ、扱うのはカテゴリ横断の記事であるため、重複する要素や暗黙的な依存関係が記事にでやすいです。
そのため、仮に順番で読んだとした場合に、わかりやすいような順番にしています。

この記事の依存関係を発見する方法としては、それぞれの記事のアウトラインやトピックを取り出して、トピック同士の重複関係を可視化して見つけています。

また、開始日にすべての記事が完成していたわけではなく、掲載をしながら記事を完成させていました。

連載記事の公開

連載の開始日が近づき、いよいよ連載の記事の公開です。

連載が普通の記事とは異なる点としては、単独の記事ではなくゆるい繋がりがある点です。
「KARTE Blocksリリースの裏側」は記事ごとに著者も異なり、記事の順番も特別な意味はないため、アドベントカレンダーなどのリレー形式が近いです。
この場合にも、記事同士にはゆるい繋がりが存在します。

連載をする場合に重要なのは、次のふたつだと考えています。

  • どうすれば連載を購読できるかを伝えること
  • 連載の記事同士の繋がりを持たせること

「どうすれば連載を購読できるかを伝えること」はこの連載では難しいポイントでした。
なぜなら記事を公開するのはブログで、複数の場所になることが想定されていました。
この場合に、読者が連載の新しい記事を知る方法を伝える必要があります。
ブログなので、RSSを購読すれば読めますが、全員がRSSリーダを使っているわけではありません。

この連載では、@KARTE_BlocksというTwitterアカウントをフォローする形で連載を購読できるという伝え方に統一しています。
連載用のニュースレターを用意する方法も検討していましたが、時間が足りなかったので断念しました。

「連載の記事同士の繋がりを持たせること」では連載の目次ページを作る方法と記事同士で相互にリンクさせる方法(記事へ目次を入れる方法)があります。
目次ページを作る方法は運用が簡単で、各記事から目次ページへリンクを貼るだけでよいというメリットがあります。
一方の記事同士に相互リンクさせる方法は、記事同士の関係が密接になりますが、記事を公開するたび記事のリンクを更新しないといけません。

今回は、記事同士に相互リンクさせる方法を選択しました。
目次ページを挟むと他の記事をみるのに1click増えてしまうのと、記事の総数が10個程度と数が限られていたためです。

連載のメリットは、連載の他の記事を見てもらえる確率が単独の記事より高いことにあります。
このメリットを生かすために、多少の手間があっても、読者の負担が少なくなる方法を選択しました。

連載記事の公開後

記事を公開した後は、社内に周知したり、TwitterなどのSNSにシェアしたりします。
このときに、シェアしやすいように各記事のポイントをまとめた絵を用意したり、OGP画像を用意して設定したりしています。

これは、各記事がしっかりと書かれていて長くなっているため、まずは興味を持ってもらうために作成していました。

karte-blocks-inside-1

全ての記事のポイントをスライドにまとめてみたGIF画像

「KARTE Blocksリリースの裏側」完結 🎉

「KARTE Blocksリリースの裏側」という連載シリーズを最後までみていただきありがとうございます！
この記事をもって「KARTE Blocksリリースの裏側」は完結となります。

「KARTE Blocksリリースの裏側」の全10記事を合計すると18万文字近くあります！
まだ読んでない記事がある方は、是非読んでみてください！
また「この記事が面白かった」などの感想や「KARTE Blocksリリースの裏側」の連載に対する感想などを #KARTE_Blocksのハッシュタグに書き込んでください！

  1. KARTE Blocksを支える技術
  2. インクリメンタルに新しい技術を取り入れる方法
  3. セカンドパーティコンテンツをもつサードパーティスクリプトの作り方
  4. AWSが落ちてもGCPに逃がすことで落ちないシステムを作る技術
  5. ユーザーが自ら理解・学習するためのテックタッチなアプローチ
  6. 爆速で価値あるプロダクトをリリースするためのチームビルディング
  7. CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方
  8. 0→1のフェーズで複数のユーザー体験をつなぐUIデザインを考える
  9. リリース後に落ちないように、新規サービスで備えておいたこと
  10. KARTE Blocksにおけるポジショニングの考え方とその狙い

KARTE Blocksは2021年9月14日に正式リリースしてからも引き続き改善していっています。
今回の連載は、リリースしたタイミングでのKARTE Blocksの裏側を詳細に解説していきました。

これからもKARTE Blocksをよろしくお願い致します。