実績

技術記事の寄稿依頼を受けてから寄稿するまでの振り返り

こんにちは、Tamappeです。

今回はだいぶ振り返りが遅くなりましたが、先週10月23日(金)に開催されたpotatotips #71のイベントで登壇してきた内容と実際に技術記事を寄稿したときの振り返りをしようと思いました。

potatotips #71 iOS/Android開発Tips共有会

このイベントでは「商業雑誌に技術記事を寄稿した振り返り」について登壇してきました。

登壇した内容を貼り付けておきます。

また、下の段落が実際の技術記事を寄稿したときの振り返りになります。

寄稿の振り返り

この記事は10月6日に技術記事の寄稿が完了して、実際の技術記事の寄稿までの取り組みを10月6日に振り返ったものになります。私自身はこういったものは初めての経験でした。そこで今回は数ヶ月前の初心者だった自分に向けてのメッセージになります。

突然の寄稿依頼

iOSDCのネタを検討中の8月中旬頃に出版社の編集者からメールで問い合わせが来ました。その頃、当ブログははてなブログからWordPressに移行したばかりで移行作業に時間を取られていたのを覚えています。

依頼内容のざっくりまとめ

Flutterでのアプリ開発とネイティブアプリ開発の違いを初心者向けに解説した文章を書いてほしいとの事でした。それ以外は特に指定がなくフリースタイルで書いてくださいとの事でした。僕としては『お題』や『目次』を頂いたほうが執筆する内容をイメージしやすいのですが、文章構成含めて自由との事でした。

寄稿までの専門用語

  • 寄稿
  • 初稿
  • 校正
  • 入稿

寄稿について

寄稿というのは「原稿を新聞や雑誌にのせるように送ること」を指します。メールの文言で「寄稿依頼」という言葉があったのですが、これまでの人生でWebライターみたいに他社のサービスに自分の文章を掲載した経験がありませんでしたので、最初はこのワードに反応できませんでした。

つまり、「あんたの書いた記事を私の出版誌に掲載させてくれ」ということを寄稿と呼ぶらしいです。初見だと分かりません。

初稿について

初稿とは雑誌などに掲載される時の「未編集状態の原稿を提出すること」を指します。

校正について

wikipediaには校正について次のように記載されています。

校正は、印刷物等の字句や内容、体裁、色彩の誤りや不具合を、あらかじめ修正すること。校合(きょうごう)ともいう。
出版にあたっては、印刷に先立って仮刷りを行い、それと原稿の内容を突き合わせ、誤植や体裁上の不備を正す。文字や数字ばかりでなく、デザインや発色の確認も行い、特に発色の確認を行う校正を色校正(色校)という。

簡単に言えば、「最初の文章だけの原稿を提出後に出版社側が雑誌として掲載する前の状態」から編集者と一緒に図や執筆した文章に誤りがないかを正すことを言います。

正直、一番イメージと違ったのがこの「校正」でてっきり、原稿を提出したらあとは編集側が全部やってくれる期間だと思っておりました。そうではなく、ほぼ掲載される予定の印刷物を編集者と一緒に修正している作業でした。

プログラミング作業でいえば、機能を開発してデバッグしてQAに渡してテストしてもらう工程があると思いますが、その工程でいうと「QAのテスト」を一緒に行うようなイメージです。もしくはQAと一緒にテスト項目の洗い出しをするフェーズといえばイメージが近くなります。僕的にはこの工程が思ったよりも負担が大きかったです。

この校正が終わると執筆者側で行う作業が実質終わりになります。あとは入稿待ちとなります。

入稿について

最後に入稿についてです。こちらは校正が終わった最終誌面が正式に雑誌に入ることを指します(多分)。この入稿工程が完了できて初めて「寄稿依頼」が完了します。

これで晴れて執筆作業から開放されるわけです。

実際の寄稿の記録

ここからは実際に私が記事寄稿の依頼を受けてから入稿までに起きた内容の記録です。

寄稿スケジュール

  • 依頼されてから執筆まで (約2週間)
  • 執筆から初稿まで (約2週間)
  • 初稿から校正まで (約1週間)
  • 校正から入稿まで (約1.5週間)

結構タイトなスケジュールでした。

執筆の取り組み方

  • だいたいの目次と構成を決める
  • 構成を決めたら書く項目を箇条書きする
  • 1日寝かせる
  • 箇条書きした項目を再考する
  • 再考した項目を参考にして一気に執筆する

寄稿とiOSDCのダブルブッキングに対するスケジュール調整

依頼を受けた最初の悩みポイントは締切日とiOSDCの開催日が近いということでスケジューリングが大変になりそうだなということ。ええ、iOSDCは9月中旬開催でしたのでLT枠が採択されましたので登壇資料も作る時間も確保しなければならなかったんですね。

編集者にその事を相談してみたところ、「無理して体調を崩すよりもカンファレンスを優先したほうがいいですよ」という事で快く締切を伸ばしてもらう案を飲んで頂けました。

ですが執筆の方が自分のバリューが上がりそうだと交渉中に感じたため、逆に早めに終わらすスケジューリングを提案して締切日はそのままにしました。

それぐらいにちゃんと悩みを先に伝えられるコミュニケーション力があれば、ある程度柔軟にスケジュールを飲んで貰えました。

記事入稿までの実稼働 (実際の工数)

これが、おそらく皆さんが気になるところだと思います。実際に技術記事執筆の依頼を引き受けてから記事の入稿までにどれくらいの時間がかかったのかを振り返ってみました。

記事執筆前の下準備 (目次と構成時間)

2.5h x 2セット x 2日間 = 10h

記事執筆 (最初の執筆)

3h x 2セット x 4日 = 24h

原稿の初稿まで (主に修正)

平日: 2h x 3日 + 3h x 1日 = 9h

土日: 3h x 2セット = 6h

締切日: 3h x 2セット = 6h

校正から入稿まで

(校正のやり方の理解)

4h x 1日 = 4h

(実際の校正)

前半

3h x 3セット x 1日 = 9h

後半

3h x 2セット x 2日 = 12h

(全体の確認)

2h x 1セット = 2h

(最終確認)

2h x 1セット = 2h

まとめ

期間 工数 (h)
準備期間 10
執筆〜初稿 45
校正〜入稿 29
合計 84

ということで84時間の工数がかかったみたいです。

ただ、これは文章構成と品質の完成度を上げるために「自発的に」掛けた為です。いざ商業誌に掲載されるとなればデタラメな文章よりもある程度高品質なモノを掲載したい欲求が出てきます。また、入稿前は変な情報が入らないように入念に自分の書いた文章を確認するために時間を掛けています。

作業中のツラミ

初稿中のツラミ

  • 執筆が進まない焦り

下準備でiPadアプリのGoodNote5に執筆する内容をマインドマップに箇条書きしていました。それに従ってひたすら執筆していたのですがそれでも時々指が止まることがありました。

あと執筆していると割とスイスイ進む時があったのですが、あとから見直すと前後でネタが被っていたなんてこともありました。それで片方を泣く泣く削除するのですが、削除すると文字が減りますので減った分別の事を書かないといけないプレッシャーがありました。

まあ、でもこの最初の工程は後半を思い出すとそれほど辛くなかったかもしれません。

初稿締切前でのツラミ

  • 執筆した文章で嘘偽りがないかの確認が割とツライ
  • 専門用語でタイプミスの確認作業
  • 検索ページによって微妙に違う単語でどれを使うかのワードチョイス(iOSでいえば、storyboardやxmlなどの部分)

初稿提出後の感想

  • やっと終わったという開放感で一杯 (iOSDCの資料作成に頭が行く)
  • しばらくブログや文章を書く気力がなくなりました

校正中にツラミ

  • 校正中にiOS 14に対応したFlutter SDKがリリースされて原稿の内容に矛盾が生じてしまった
  • 文章表現を修正するたびに修正前後で全体の文章構成が崩れていないかのチェックが大変
  • 気づいたら初心者視点のワードチョイスを忘れて専門用語を多用してしまう問題

校正締切前のツラミ

  • 最後に誤字・脱字のチェックを行ったのですが、正式名称を使うべきか慣れ親しんだ単語を使うべきかで悩んだこと
  • 最後の最後で執筆した文章に誤りがないかどうか心配になってきたこと
  • 入稿後、revertが出来ない問題

入稿後の感想

  • とりあえず入稿したという事実が記憶から飛んでしまう
  • 文章を書く行為が嫌いになる
  • 仕事が終わったらリポビタンDを投入していた・・・

無事記事の寄稿が完了したあとの感想

正直言うと、しばらく文章を書くモチベーションがなくなりますね。

最後の方は一番最初に執筆した内容の事実確認で誤りがないかどうかの確認作業ばかりになっていました。で確認しながら、この表現はもっと分かりやすい文章に修正できるんじゃないか?みたいに思えてきて疑心暗鬼に陥ることもあったりしました。

良かった点は文章構成力と文章力が格段に上がったということ。直に編集者からテコ入れをされますので、自分が執筆した文章が客観的に読者にとって読みやすい文章だったかどうかの感想が聞けます。

文章を執筆しているとどうしても専門用語を多用してしまうことがあります。専門用語自体はいいんですが、そういったところは必ずと行っていいほど後で読み返すと読みにくいんですね。専門的すぎて現場を知らない人から読んだら「一体どういう意味なの?」みたいに?マークが連発します。

工夫に工夫を重ねましたので、「良い文章はこうやって生み出されるのか!」という学びを得られましたので記事の寄稿はとても楽しめました。

という感じで寄稿についての話しを終わりにします。将来このブログの読者が何らかのタイミングで役に立てればとても幸いです。

それでは、バイバイ。

ABOUT ME
tamappe
都内で働くiOSアプリエンジニアのTamappeです。 当ブログではモバイルアプリの開発手法について紹介しています。メインはiOS、サブでFlutter, Android も対応できます。 執筆・講演のご相談は tamapppe@gmail.com までお問い合わせください。