エンジニアの副業と執筆
私がこのアドベントカレンダーでお伝えしたい事は「エンジニアの副業と技術書の執筆はとても相性が良い」ということです。オススメです。
ここでは実際に私が体験した技術書の執筆についてご紹介しながら、その相性の良さを感じて頂いたり、実際の進め方をイメージして頂ければと思います。
執筆した技術書のご紹介
副業で技術書を執筆した様子をお伝えするにあたり、少しだけ、実際に私が執筆した技術書について説明（もとい、宣伝）をさせて下さい。
執筆したのは、「Microsoft Azure Technology 1ヶ月でクラウドエンジニアになる本」という、ミラクルソリューション様から出版された Microsoft Azure の入門書です。
全てを担当したわけでは無いので偉そうな事は申し上げられないのですが、私が担当した章は以下の3章です。
- Chapter2 2-1 Azureと管理ツール
- Chapter2 2-4 サブスクリプションのコスト管理
- Chapter2 2-6 ストレージアカウントとサービス
書籍名の通り、Microsoft Azure を中心に取り上げた入門者向けの技術書となっており、用語の解説やキャプチャと手順が記載されてた書籍になっています。
紙はもちろん、電子書籍でも入手が可能ですので、是非お手に取って頂けると幸いです。
どのように執筆していったか
ここからは実際にどのような流れで執筆を進めていったのかについてご紹介していこうと思います。
執筆のきっかけ
まず副業で技術書を執筆することになったきっかけですが、これは実はたまたまです。現職の仕事に少し気持ち的な余裕が出たタイミングだったこともあり、何気なくクラウドソーシングのサービスを眺めていた時に目に留まったのが、この技術書執筆でした。
予め副業での技術書執筆に的を絞っていたというわけでは無く、自分のスキルセットを検索条件にして出てきたのがきっかけだったので、タイミングも良かったと思います。
もちろん応募の際には、案件主へのアピール（技術書の執筆実績が無くても、手順書を作っているとか登壇したことがあるとか）を盛り込むと話もまとまりやすいかと思います。
無事執筆できるようになるといよいよスタートです。
執筆スケジュールを立てる
担当の章は決まっていたので、まずはその章でどのようなことを書くのか、盛り込みたいキーワードや章立てを考えます。その際は、既存の公式ドキュメントのみならず、既にある書籍、wikipedia 等を見ながら、時には実際に操作をしてイメージを固めていきます。
イメージが固まったところで、執筆スケジュールを立てていきます。
細かく精度の高いスケジュールを作成することはあまり意味はないので、大きな塊としてアタリを付けながら、画像のようなタスク管理表に落としていきます。
キャプチャの取得
ここからいよいよ本格的な執筆の作業に入ります。まずはキャプチャの取得です。キャプチャの取得方法は色々ありますが、私は普段 Windows を使っていて Lightscreen というソフトを愛用しているので、それを用いて取得していきます。
キャプチャを取得する際には、以下のようなことに気を付けるのがオススメです。
- ブラウザのキャッシュや履歴は削除しておく
- 余計なタブ等は開かず、プライベートブラウジング機能等を用いる
- 実際に使用するかどうかは不明でも、多めに&細かめにキャプチャを取得する
- 何のキャプチャであるかわかるようにファイル名を直しておく
図・表を作成する
続いて、キャプチャと同様に重要な図・表を作成していきます。
デザイン修正は出版社側で実施頂けることになっていたので、私の方では Microsoft PowerPoint を用いて概念図等を作っていきます。特に図の場合、フォントサイズや枠で囲む際の線の太さなどに注意が必要です。
また必要なアイコンセット等は既にあるものを流用せず、予め公式などから入手し利用することも大切です。一通りのキャプチャや図表が揃ったところで、いよいよ文章を書き進めていきます。
いざ、執筆
文章を書く際に用いるツールについては、私は Google ドキュメントを用いていました。
特にクラウドソーシング等で執筆を行う場合には納品時の形式が指定されている場合もあるため注意が必要ですが、
基本的には書きやすいツールを使えばよいかと思います。
文章を書く際には、以下のようなことに気を付けていました。
-
正しい用語を用いる（サーバ、ユーザ、半角英字の大文字・小文字等）
-
表記揺れを起こさない（です・ます、体言止め）
- 手順の記載形式・粒度を揃える
ポイントは、最初から完全を目指さず、まずは70点くらいを目指して全体を通すことです。その中で書きやすかった部分や書きにくい部分、不足していると感じる部分が見えてくるので、それを踏まえて更に加筆修正したり、場合によってはキャプチャの取得や図表の修正を行って完成を目指します。
「完成した」と思えてからも、例えば翌日とか、パソコンでは無く紙に印刷して確認してみるということでケアレスミスや違和感に気付けることもあるので、最後まで気は抜かないようにしましょう。
ぶっちゃけやってみてどうだったか
前章で技術書の執筆イメージは膨らんだかと思いますが、「実際のところオイシイの？？？」というのが皆さんの気になるところかと思うので、私なりにそれにお答えしようかと思います。
Q.儲かるの？
A.（もちろん契約に従った謝礼を頂いていますが、）コスパは悪いと思います。
私の場合、業務終了後の平日夜や週末を使いながら足掛け2ヵ月ちょっとをかけ、文字数は3万文字、図表は50種強を執筆しています。なので、サクッと稼げるタイプの副業ではありません。
普段から技術ブログを書いている等、慣れや好奇心のようなものがある方に向いている副業かと思います。
Q.何が得られた？
A.達成感と、自身の技術に対する振り返りの機会が得られました。
月並みなのですが、これは間違いなく言えることかなと思います。
1点目の「達成感」については、「エンジニアとしての対外的アピールになる」と言い換えることができるかもしれません。
ここは価値観が分かれるところですが、私の場合、研究内容が学会誌に掲載されたりした学生時代の記憶はとてもいいものだったこともあり（大変でしたが）、第三者の方に見て頂ける形でアウトプットが残り、それを自身の実績に出来るというのは大変魅力的でした。
2点目の「自身の技術に対する振り返りの機会が得られる」については、皆さんにも納得頂けるのではないでしょうか。
他人に教えることで学習内容の定着が図れるという、アレです。もちろん振り返り方は様々ですが、他の方に分かりやすく伝える工夫をしたり、うまく執筆できなかった時に改めて調べたり理解を試みるその過程こそが、自身のエンジニアとしての技術力の底上げになっているのだと思います。
執筆において気を付けること
ここまで良いことばかりを書いてきましたが、これから皆さんが副業で技術書の執筆を行う場合に気を付けた方がいいことについてもご紹介しておこうと思います。
お伝えしたいのは以下の4つです。
- 周囲の理解を得る
-
作業時間を十分確保する
-
情報漏洩に注意する
- 納期を守る
周囲の理解を得る
1点目の「周囲の理解を得る」については、例えば会社の副業規定を確認し、必要な届け出をすることや、家族の理解を得て協力を仰ぐことがこれに該当します。
執筆作業そのものは基本的に一人で進めるため孤独なものになりがちですが、定められたルールを守りながら、時には周囲に支えてもらいながら、最大限のパフォーマンスが出せるような環境を作って執筆を進めていきましょう。
作業時間を十分確保する
2点目の「作業時間を十分確保する」についてはそのままです。
先程もお伝えした通り、私が執筆した3万文字・50種の図表とその作業は2ヵ月を要しています。これは実は当初の見立てに対して2倍近くかかっていて、見積もりが甘かったなというのが正直なところです。
依頼を受けて執筆をする場合は当然「納期」を守ることが大切で、それが次の副業につながることもあります。自分を過信せず、計画的に執筆を進めるようにしましょう。
情報漏洩に注意する
3点目の「情報漏洩に注意する」については、特に校正などが入らない場合に注意が必要な内容です。
作業手順のキャプチャ等を撮る際、アカウント名やメールアドレス、API キー、URL等、様々な情報が入り込んでしまう可能性があります。紙であれ電子媒体であれ、これらが公になるというのはとても危険なことであると認識し、適切な対処を行うことが大切です。
ちなみに私の場合は、Microsoft PowerPoint にあるトリミングやぼかしを用いて対応を行っていましたので、まだこの機能を利用したことが無い方は一度確認してみると良いかと思います。
最後に
以上が私の技術書を執筆した副業の体験談です。
特に入門書であれば、「まだその知識・経験を持っていない昔の自分」をイメージしながら執筆を進めることができ、なおかつ新たにこの業界に飛び込もうとしている方のお役にも立てるので、是非挑戦して欲しいと思います。
ちなみに次は Java や Spring を題材にしたウェブ学習コンテンツを執筆予定ですので、ご興味がある方は是非お声がけ頂けると嬉しいです。それが終わったら、 Java & Azure でなんか書きたいなぁ。