はじめに

みなさんに毎週目にしていただいている、CodeGrid。この記事では、このCodeGridがどんなふうにできているのか、その工程を編集の丸山がご案内します。

著者とレビュアー、そして編集者のホンネもちょっぴりお見せしますので、楽しんでいただけますと幸いです。

（イラスト：たかしまてつを）

記事テーマを決めよう

CodeGridの記事は、まずはテーマを決めることから始まります。テーマは、「ネタ決め会議」と呼ばれる毎週のミーティングで決めます。参加者はCodeGridの総合的なディレクションを行うエンジニアの中村と編集者2名、そしてスタッフのスケジュール状況に詳しいディレクターです。

記事のテーマは、基本的には、

• フロントエンドに向いたテーマか？
• エンジニア界隈で流行っているか、興味を持ってもらえそうか？
• よい技術／よいサービスかどうか？

ということを総合的に考えて決めていきます。

ネタ決め会議以外にも、「こんなテーマ、CodeGridにいいんじゃない？」という投稿がSlackでスタッフから上げられることもあります。社内のエンジニアやデザイナー、ディレクターが案件で使ってみたり、個人的に使ってみたりして、実感をもっておすすめできるものを取り上げています。

基本的には、著者が「書きたい」と思うテーマでの執筆を依頼していますが、案件の状況によっては忙しいときもあります。そんな場合は各人の案件スケジュールを把握しているディレクターの出番。いつぐらいからなら頼めそうか、見通しを教えてもらって調整します。

新しい技術やサービスに関しては、「いつ記事に取り上げるか？」ということはとても悩ましいものです。CodeGridは速報性のあるニュース媒体ではないとはいえ、タイムリーに取り上げることは必要です。その一方で、早く記事として取り上げても、対応ブラウザが少なかったり、まだ広く使われる段階じゃない場合もあります。その見極めも大切。

ここだけの話ですが、「すごい技術が出た！」と思って記事にしても結局広まらず、あとから振り返ると「……外しちゃったね、この記事」ということだって、これまであったのでした。ただ、新しい技術への知識欲を満たせるものだったり、すぐに便利に使えるものだったりするものは、早めに記事にするようにします。

また、テーマによっては著者が単独で執筆するより、座談会形式でいろいろな人の意見を紹介したほうがよい場合もあります。ときには、そのテーマに詳しい外部のエンジニアをお招きする座談会を開くことも。そんなことも、会議では検討されるのです。

ネタ会議担当者、中村のホンネ

個人的に読みたいテーマを、この人ならおもしろく書けそうという観点から執筆を勧めることもあります。たとえば「サーバーレス実行環境Cloudflare Workers」のシリーズは、フロントエンド・エンジニアのスキルの幅を広げるのによいテーマですが、何より僕が読みたかった記事です。このシリーズはCloudeflareに詳しい杉浦が書いていますが、彼ならおもしろく書いてくれそうだなと思ったし、そのとおりになりましたね。

自分がそれほど必要としていなくても、多くの人に求められていそうな情報はもちろんOK。個人的にはReactやTypeScriptは現時点で使わないしあまり興味もないけれど、今のフロントエンドで求めている人も多いのはわかるから、そういったものは記事にします。
（Jamstackエンジニア：中村）

締め切りって、いつ……？

原稿の依頼とともに、著者に伝えるのが締め切りです。CodeGrideでは原稿の締め切りは、配信の2週間前が基本となっています。その2週間の間に、編集とレビューを通して、記事としての精度を上げていくわけです。

締め切りに対する考え方は、著者それぞれです。毎日少しずつ書く……というより、何を書くかを時々考えたり合間合間に調べ物をしたりしながら、1〜2日で一気に書く、という人が多いようでした。

編集者は、頃合いを見計らって「進行いかがですか〜？」と聞いたりもしますが、案件が忙しいスタッフには声をかけるタイミングが難しいことも。そんなときは、ディレクターに相談したりもします。

記事の公開予定日時や原稿の締め切り設定はTrelloで管理しており、このTrelloのボードはピクセルグリッドのスタッフならだれでも見られるようになっています。ですから、締め切りが過ぎても「まだ配信までちょっとあるから大丈夫だな……！」と著者に思われてしまうことも。逆に、編集者に「この著者はギリギリでも、きちんと上げてくれるはず……！」と思われていることも！？ そんな駆け引きは、社内で運営しているメディアならではかもしれません。

執筆担当者たちのホンネ

自分の中での理解がそこまで深くない場合、執筆に時間がとてもかかるものがあります。これは書き出そうと思った時点ではわからないので、書き出してからそういう状態に陥り、なおかつ案件も忙しいみたいな状態が訪れると結構大変……。
（テクニカルディレクター：高津戸）

締め切りはときどきTrelloで確認しますが、頭に入れておく程度です。たまに忘れます。ネタ決めのときに想定していたものより、書いていくとややこしい感じだと遅れがちです。
（フロントエンド・エンジニア：國仲）

原稿が来ない……！ そんなときは、「あんまりしつこく締め切りを連呼しても……」「でも、もう来週公開なんだけど……」という、自分の中でのせめぎあいがあります。
（編集：丸山）

おれは……しんのしめきりをしっているぞ！！！あるんだ……しんのしめきりは……。
（フロントエンド・エンジニア：坂巻）

さあ、執筆ですよ！

テーマが決まり、締め切りが設定されたら、著者が執筆に入ります。原稿はMarkdown形式で書かれます。頭の中で考える、マインドマップのような手法で考える、見出しなどのアウトラインを項目出しするなど、執筆のスタイルは著者それぞれです。著者の中でまとまらない場合は、編集者やレビュアーを含め、一緒に構成を検討することもあります。

重要なのは、その記事の想定読者です。たとえば、「Flexboxについては一通りわかっている人が、次のステップとして読めるようにしよう」とか、「Vue.jsを知らない入門者が使えるようになる記事にしよう」などということを考えます。これも記事のテーマ決めの段階で著者と編集者が相談することもあります。

エンジニア全般に役立つ記事にしたい気持ちはもちろんあります。でも、誰に向けて書いているかをある程度設定しないと、無駄に説明が長くなったり、逆に説明がなさすぎて理解が難しくなってしまったりするのです。

原稿中にデモがある場合は、まずデモを作るという著者が多いようです。デモを作っているうちに、説明しなくてはならないことが見えてきたりもします。ただし、このデモも、標準仕様解説の場合は難なくできても、実践系の場合は、知っておいたほうがよい機能を適度に取り入れ、しかも、必要以上に複雑にならないデモでないといけません。そのため、どんなデモを作るかを決めるのに時間がかかるということも。一筋縄ではいきません。

執筆担当者たちのホンネ

原稿には、正確さに欠けることを書かない。自分の意見と参照元に書いてあることは明確に分ける。
（テクニカルディレクター：高津戸）

実際に書くテーマが決まった時点で、だいたいのプロットは頭の中にある（むしろ、それがないようなテーマは書きたくないし、書けないし、書かない）状態からスタートです。
（シニアエンジニア：杉浦）

長期連載の場合、1つの記事に独立性を持たせられるかという部分に気を遣います。連載だと各回の前後につながりが生じますが、つながりを持たせつつも、1つの回を読んだだけでも「あるテーマにおいて一定の知識を習得できた」っていう、一定の満足感を得られる内容になっているか、というところですね。
（フロントエンド・エンジニア：森）

編集して記事として整える

原稿が上がったら、編集作業に入ります。この工程があるのも、CodeGridの大きな特徴の一つです。

編集者が注意するのは、読者がその記事を読み、つまずきなくわかるかどうか、というところ。そのためにはその原稿のテーマの本筋がわかりやすくなっているかを注意し、文章や見出し、節の分け方を見ていきます。

また、作業工程がある原稿ではそのとおりにやってみて動くかどうか、用意されたデモが原稿どおりの動作になっているかのチェックを、できる範囲で行います。

特に「当たり前」と著者には思われてスキップされてしまっている工程がないか確認しますが、この「当たり前」かどうかは難しいところ。一般的なエンジニアにとって「当たり前」であるなら、余計な解説はないほうがよい場合もあります。このあたりは想定読者も踏まえて、著者に確認します。

こういった編集作業について、詳しくは「技術文章編集テクニック | CodeGridの作り方」でも紹介しています。

「適度な分量かどうか」というのもチェックし、場合によっては記事を分割することも著者に相談します。丁寧に解説したり、補足を追加していったりすると、つい長くなってしまうのですが、「読者にとってちょうどいい」分量になるようにします。

また、表記統一も編集者の仕事です。CodeGridではよく使う用語については表記ルールを作って、それに沿って統一するようにしています。サービス名や用語などは、公式サイトを確認します。

編集担当者のホンネ

編集時に注意することは、内容が正確なこと。正確というのは、言語の厳密さを求めるということではなくて、ざっくり正しくて、陥ってしまうとマズい誤解に近寄らないくらいのラインを描くこと。ただ、これを完全に自分の判断でするのは危険なので、エンジニアからヒアリングし、そのラインを自分の中につくることを心がけます。

内容を盛り込みすぎて本筋が見えにくくなってしまっている場合は「補足」「注釈」や「コラム」といった本文とは異なるレイヤーに情報を分けるのも、編集あるあるテクニックです。
（編集：外村）

レビューって何をするの？

原稿の編集が終わると、著者以外のエンジニアに読んでもらう「レビュー」に回します。エンジニアにレビューしてもらうというのも、CodeGridの特徴の一つ。ここでは「技術的な間違いがないか」のチェックのほか、「その技術を知らない人が読んでもわかりやすい内容になっているか」もチェックしてもらいます。

レビュアーは、仕様に関わる部分で気になる部分があれば、仕様を確認したり、記事中のデモをじっくり見たりします。ときには、ブラウザのバグトラッカーを見たりすることもあるとのことです。

レビューでのやり取りはGitHub上で、コメントやsuggestionなどを使って行います。suggestionで指摘する場合は、レビュアーそれぞれ気を遣っているようです。たとえば、「レビュイーの負担にならないように、ほぼそのまま使ってもらえるレベルのsuggestionをするように心がけている」というレビュアーもいれば、「『これを取り込んでほしいな』って思いが強いときにsuggestionを使う」というレビュアーもいます。ただ、どんな場合でも、GitHub上でやり取りが残るので、指摘や修正はわかるようになっています。

原稿やレビューのやり取りはGitHubやSlackで社内のスタッフならだれでも見られる状態で進めています。中には、レビュー担当ではなくても「読んじゃいました。ここ、違うかも」と指摘してくれるスタッフもいて、助かっています。

レビュー担当者たちのホンネ

自分が技術的に知っていることでも「知らないフリ」をして読んでみるようにしています。あとは、レビューのコメントが「これ違う気がする」だけでは、著者として「では、どうするのがいいの？」と感じてしまうはず。「こうなればもっといい」の具体例を示してレビュイーを支えつつ、文章の信用が上がるためのレビューをできるようにしています。
（フロントエンド・エンジニア：小山田）

「これは知らなかったー」とか「好みの言い方だなー」とか、「わかりやすいぞ」と思ったところなど、良かったなと思ったところもコメントするようにしています。著者へのポジティブなフィードバックもあればいいかなと思ったのと、ここがよい・おもしろいと思うポイントって人によって結構違うと感じるので、それが可視化されるとおもしろいなーと思ったためです。
（フロントエンド・エンジニア：矢倉）

そして、公開へ

通常、CodeGridは木曜日に新しい記事が配信されます。この日は、編集がもっともバタバタと作業する日です。それなりの日数を設けて原稿が上がっているとはいえ、当日まで著者やレビュアーとのやり取りが続いていることもあるからです。

レビューが終わった記事は、記事を担当する編集者とは別の編集者が最終校正を行います。厳密に決めているわけではありませんが、プレビューされた記事を一度プリントアウトして校正することが多いです。これは、これまで見てきた「モニタ画面」から「紙」で見直すことで、新たな気持で読む、という意味合い。たまたま現在の編集2人は紙媒体出身なのでプリントアウトしていますが、たとえばiPhoneやiPadで見直す、などでもいいかもしれません。

校正が終わると、記事をまとめてメールマガジンを作成します。メールマガジンはテスト配信を行い、リンクなどがきちんと機能しているかのチェックを行います。

ここまできたら、あともう一息。記事を公開します。まずプレビューサイトで表示に問題ないか確認し、OKなら本番サイトを公開。確認できたら、メールマガジンを配信します。

最後に、事前に著者に確認しておいた記事公開をお知らせするツイートを流して、配信作業は終了。お疲れさまでした。

編集担当者たちのホンネ

公開時に一番大切なことは、慌てない。動じない。動じない。動じない（大切なことなので3回言いました。焦るし、動じるので、笑）。
（編集：外村）

いつからか、配信が終わると編集の2人がSlackのcodegridチャンネルで絵文字のカレー🍛を出すようになったのですが、これは暗黙の「おつカレー」の意。配信が大変だった日は、ひそかにカレーのお皿が増えたりしています。
（編集：丸山）

まとめ

CodeGridのつくり方をご紹介しました。記事として名前が出るのは著者ですが、そのほかにもさまざまな人の目や手を通して記事ができ上がります。

一番当たり前で大切なのは、きちんと月4回、記事が読者に届けられることです。それは有料媒体では必須ということはもちろんですが、どんないい内容の文章でも、宇宙の彼方のどこかの星の瓦礫の下に埋まっていたら、残念ながら「無」になっちゃうかもしれない、という気持ちがあります。

著者とレビュアー、そして編集者のみんなの力ででき上がった記事も、読者のみなさんにお届けできて、読まれてはじめて完成します。読者のみなさんに日々の思考や業務に役立ててもらったときが記事の本当の完成時なのです。

今後とも、CodeGridをどうぞよろしくお願いいたします。