8ヵ月間のSoftware Design連載を組織的にバックアップしたノウハウを共有します！

こんにちは。モノタロウで開発を担当している河本です。2021年7月から2022年2月に技術評論社様で発刊されている Software Design にモノタロウにおけるPython大規模開発に関する取り組みを連載させていただきました。そして無事に8か月分の雑誌連載を完遂することができました。ここでは、雑誌連載プロジェクトの体制やスケジュール、成功させるために取り組んだことについてご紹介します。

Software Designの記事の再紹介
連載のきっかけと狙い
プロジェクト体制
スケジュール
プロジェクトを成功させるために取り組んだこと
さいごに

Software Designの記事の再紹介

全8回の連載のテーマは「Python」、「大規模」、「レガシー」の3本柱でした。

連載してきた記事は以下になります。

以下はSoftware Design誌の書影です。

振り返ると連載は8本、執筆者は14名でした。レビューも含めるとさらに多くの社内エンジニアに協力いただきました。また、当初は連載は6本の予定でしたが、ご好評をいただいていると担当編集の方から連載追加のお話をいただき、計8本となった経緯があります。

連載のきっかけと狙い

Software Designに連載することになったきっかけは、2021年4月上旬に担当編集の方から弊社テックブログの「20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog」を見てお話をいただいたことがきっかけでした。

もちろん断る理由がありません。当時、弊社としてもエンジニア組織の拡大をしているところでした(現在もです！)。Software Designというテック業界で非常に有名な技術雑誌に連載していただくことで、テック業界でのモノタロウの認知度向上、その先のエンジニア採用につなげていきたい、という狙いがありました。

また、連載の中でも触れていますが、モノタロウのECサイトと基幹システムは20年強の歴史があります。サイトやシステムもその中で変わってきていますが、その背景や変遷はやや暗黙知なところがありました。この連載を通じてそれらを明文化したい、この連載を読めばモノタロウの開発や文化がわかる、という裏の狙いもありました。

プロジェクト体制

テックブログよりも雑誌の執筆/編集が格段に難しい理由は以下です。

原稿の締切を確実に守る
固定されたページ分量に原稿を収める
原稿内容の品質を確保する

締切に間に合わず原稿を入稿できなければ、先方に多大なご迷惑をおかけしてしまうことに加え、弊社の信用を損なうことにもつながるため、絶対に避けなければいけません。また、雑誌に掲載するページ数が決まっており、基本的にそのページ数に収まる原稿にする必要があります。多すぎても少なすぎてもダメです。さらに、多くの方に読まれる商用誌であるため、内容の技術的な正しさや読みやすさ、アピールポイントの訴求などの品質を維持することもとても重要です。

上記のことを踏まえ、スケジュール管理のために社内で連載プロジェクトのとりまとめをする事務局を設置し、品質確保のために編集作業を外部のプロ編集者に依頼しました。企画・編集作業はラムダノートの鹿野さん、高尾さんにご協力を依頼しました。 www.lambdanote.com

スケジュール

雑誌連載プロジェクトは2021年5月から2022年2月の約10ヵ月間の全8本でした。 1つの原稿を完成させるのに約2ヵ月を目安に考え、締切から逆算して各回の執筆者に執筆を依頼しました。

1つの原稿を作成する際の基本的な作業フローと関係者は以下の通りです。

上記とは別に定期的に進捗状況を確認しました。

プロジェクトを成功させるために取り組んだこと

はじめにも記載した通り、無事に8か月分の雑誌連載を完遂することができました。このプロジェクトを成功させるために、執筆面と進行面において特に意識して取り組んでことは以下の通りです。

執筆面
- 執筆の優先度を上げる
- 執筆と編集を分ける
- 執筆者が複数の場合は執筆責任者を決める
進行面
- 定例を設定してリズムを作る
- キックオフを開催する
- 真の締切よりも前に締切を置く

執筆面の「執筆の優先度を上げる」では、執筆担当者の原稿作成の優先順位が上げられるように社内で準備しました。具体的には半期の評価目標に含めてもらいました。目標に含めない場合、本来の開発業務に圧迫されてしまい、原稿作成の時間を取れないリスクがあったためです。また、業務時間に時間を確保することを担当者の上長にも理解してもらい、業務の優先度調整をしてもらうためでもあります。

「執筆と編集を分ける」では、原稿の編集はプロの編集者であるラムダノート様にご協力していただきました。執筆者が原稿作成に加えて、原稿の編集/推敲までやるとなると負担がとても大きくなってしまいます。それに比べて、編集/推敲は他の人がやってくれる、特にプロがやってくれるとなると執筆者の心理的負担が大きく下がります。実際、執筆者が書きたいことを思うがまま書いた原稿に対して、ラムダノート様のほうで意図をヒアリングして、とても良い感じの構成に編集してくれたため、大変助かりました。

「執筆者が複数の場合は執筆責任者を決める」では、執筆者間での意識合わせや進捗確認/調整を執筆責任者がしてくれて、進行をスムーズにできました。

進行面の「定例を設定してリズムを作る」では、毎週短い時間でも良いから状況を確認共有する場を設けることでその後の見込みをたてたり、アクションを設定することで着実な進捗を実現できました。また、課題があれば早期に対策を打てました。

「キックオフを開催する」では、執筆者との期待値調整や執筆者の心理的負担を和らげることができました。具体的にどんな内容の原稿を書いてほしいか、やる作業は何か、スケジュール感はどうか、などを確認することに加え、プロの編集者が入るので記事の品質を担保できることを認識してもらいました。

「真の締切よりも前に締切を置く」では、ラムダノート様やSoftware Designの真の締切とは別に少し前に社内としての納期を置くことでバッファを用意しました。それにより、不測の事態が起きてもそのバッファで挽回することを考えていました。しかし、これについてははじめの1,2回くらいしかやっていません。基本的に執筆者が前倒しで作業を進めてくれていたのでバッファを使うことはなく、納期の二重管理はやめました。