執筆活動は内なる世界に浸ること

コラム

はじめに

  • こんにちわ、iret 名古屋事業部のインフラエンジニア　新川です。少し遅くなりましたが、2021年4月24日に発売された技術評論社の技術情報誌『WEB+DB PRESS Vol.122』に寄稿させて頂きましたので、執筆活動を通して学んだことを共有させて頂きます。先ず、WEB+DB PRESSのVol.117からVol.122まで全6回の「即効AWSテクニック」という連載企画を当社のエンジニアが担当させて頂きました。そして、私が最終回を執筆させて頂いております。
  • 今回、私が執筆させて頂いた記事のタイトルと概要は、下記となります。
    • 即効AWSテクニック ── DevにもOpsにも活きるインフラ利用
      【最終回】AWSマネージドサービスだけで作るWebサービス実行基盤……使い方次第で金額面でも運用面でも負担が軽減
    • AWS（Amazon Web Services）のマネージドサービスだけを組み合わせて、Webサービス実行基盤を構築するポイントを解説しております。

 

  • 今回、WEB+DB PRESS の記事執筆に参画できたことは、大変光栄なことだと思っています。今回学んだことを次に生かすため、私の視点でまとめ、本記事を書いております。なお、出版物の詳細は、下記を参照ください。ご興味のある方、購入頂ければ有難いです。

 

記事執筆で学んだこと

私が知っている世界は、とても狭かった

  • たかが8ページ・されど8ページです。執筆が決まってから私の回が来るまで、構想を練る期間は、まさに私自身の知識や経験を振り返る作業となりました。
  • 私はAWSの中でもポピュラーなプロダクトを使った経験が多く、読者は既に知っている・やったことがあるかもしれない…。私はインフラエンジニアであり、開発エンジニアなどインフラエンジニア以外の読者が読んでがっかりする内容かもしれない…。1,628円の期待に応える内容だろうか…と、構想を練る期間は不安に感じておりました。また、過去に出版されたWEB+DB PRESS をめくると（当たり前ですが）私の知らないことが多く、まだまだ勉強が足りないことを痛感しました。
  • 悩んでいた私を救ったのは、これまで私が書いたブログです。このブログが私のポートフォリオとなり、ブログを見直しながらテーマの検討を行いました。このブログが執筆をする上での支えとなりました。
  • WEB+DB PRESS を読んで新しい技術に触れること・WEB+DB PRESS を書くために私の知識を棚卸することは、私にとって大変良い学びとなりました。

 

テーマ・アウトラインが9割！

  • 実はアウトラインを作る段階で、1年前の連載企画時に仮決めしたテーマを見直すことになりました。このテーマの立案とアウトラインの作成は大切な工程であり、編集部の方からOK を頂く必要もあるため、時間が掛かる作業でした。
  • テーマ見直し前までは、これまで私がAWS構築でハマった落とし穴の事例を紹介してAWSシステムの勘所を説明するといった内容を計画しておりました。しかし、編集部の方と会話する中でハッとしました。見直し前のテーマには、以下の懸念があったのです！
  • 「失敗談」は作業者の設定ミス（思い込みも含む）などによるもの。「落とし穴（罠）」は失敗を誘引する何かが存在するもの。前者は経験談としての面白さはあるが、読者への説得力は薄く、お金を払ってまで必要とするものか疑問がある。後者は読む側のレベルによって受け取り方が変わる。罠というものは人によって感覚が異なるものであり、書く側も罠と言い切るのは難易度がある。下手すれば、自己満足で終わるかもしれない。私のテーマは後者（落とし穴）の想定でしたが、読者がすぐに試せるテクニックなのか否かの視点で考えた結果、テーマを落とし穴から構築記事へ方針見直しすることにしました。かつ、記事の"おまけ"として、落とし穴として紹介するつもりだった注意事項を2つハマりポイントとして記載することにしました。

 

読者にとって何が美味しいの？

  • 読者の立場になって、今回のテーマ・記事は何が美味しいかを自分なりに考えました。
    • 今回テーマを選定する上で、私が説明するシステム構成がメジャーあるいは流行っており、読者に勧める構成か否か？
    • この記事は読者がやってみたいと思えるものか？、システム構成や説明が難しすぎず、試したくなるものか？
    • 今回、”Webサービス実行基盤をAWSマネージドサービスだけで作る”がテーマであり、記事の導入部分として、マネージドサービスで作るメリットと、システム概要の説明が必要。これが伝わらないと、読者に読んでもらえない！
  • 今回のテーマで採用したシステム構成を説明します。テキストや画像などの静的コンテンツを提供するAWSサービス（Amazon S3）と、APIを実行した結果を表示する動的コンテンツを提供するAWSサービス（Amazon API Gateway、AWS Lambda）に分かれており、Amazon CloudFrontを前段に配置して、各AWSサービスを統合しています。今回、CloudFrontを使用する理由はCDN機能の利用以外に2つあり、記事ではCloudFrontが担う役割を解説しています。

 

 

記事執筆のコツ

Github を記事執筆に利用する

  • 今回、Github を記事執筆に初めて利用しました。Githubにプライベートリポジトリを作成し、編集部の方をコラボレーター（共同開発者）に設定しています。
  • Github を利用することで、執筆や校正がどの程度進んだのか視覚的に確認できます。また、編集部の方からGitHub の issue 機能で質問や修正の提案を受けたり、修正案のマージや変更点・加筆点といった差分の把握も容易に行うことができます。

 

表記を統一する

  • 記事に記載する言葉の表記を統一します。こちらは、指摘は少なかったと思います。
  • 画面に表示されている文字を書く場合の表記を統一します。こちらは細かい部分まで、意識できておりませんでした。（例：画面の名称を表すタイトル、入力欄やボタン名を「」、［］でくくるなど）

 

紙幅を考慮する

  • 紙幅（誌面のレイアウト・文字数）を考慮して、画像やコードを準備する必要があります。
  • 誌面の場合、パソコン・スマフォと異なり画像をズームすることはできませんので、画像のサイズは注意が必要です。スクリーンショットの場合、あらかじめ無駄を省いてキャプチャします。
  • 誌面に載せるコードは文字数によって途中で折り返されてしまうため、可読性を意識して、インデント・改行の調整、必要に応じてコード内の変数名などを修正します。

 

読者の立場になって書く

  • 読者の立場に立って文章を書くことが大切です。以前読んだ、著者・元NHKキャスター　阿隅和美さんの『心をつかみ　思わず聴きたくなる話のつくり方』から学んだことを紹介します。
  • いちばん大事なことは、"話の主役を「自分」から「相手」に180度切り替えること"です。自分（書き手）の利益・満足ではなく、相手（読み手）にとってプラスになること・知りたいこと・喜びにつながることでなければ話を聴いて（読んで）くれません。相手にとって「価値ある時間」とするため、先ず話に関心を持ってもらう"つかみ"と、"簡潔に分かりやすく話す（書く）こと"がポイント。

 

 

最後に言いたいこと

アウトプットの大切さ

  • アウトプットは自分の為に行います。この微差が大差になり、アウトプットの積み重ねが自信に変わり、私の支えになります。
  • 私の場合、最初は自分の為のメモであり、自分の仕事に再利用するためのノウハウでした。いつのまにかアウトプットを仲間と共有し、アウトプットが同じ業界の人の役に立ちました。そして、今回アウトプットが出版物に成長しました。
  • また、アウトプットは私の知らないところでコミュニケーションを行ってくれます。アウトプットは私の名刺となり、会社の販促・採用活動の資料にもなります。そして、自分に返ってきます。

 

チャンスは待ったなし

  • 出版物の執筆は、私の目標の1つでした。iret のお陰様で、"やりたい"と思ったから、そのチャンスが目の前に現れました。
  • 大切なことは、漫然と過ごすのではなく、具体的な目標を持つことと、そのチャンスが来たら躊躇せず、さっと手をあげることです。

 

記事執筆の副産物

  • WEB+DB PRESS の発売後、見ず知らずの方がtwitterで発信してくれた私の記事に関するコメントを見かけました。素直に嬉しいですね。お読みいただいた方々、ありがとうございました。
  • 仕事の仲間が出版を喜んでくれました。実際に購入もしてくれました。私の活動を仲間が喜んでくれたことがとても嬉しかったです。応援をありがとうございます。
  • イチバンは、親孝行ができたことです。先日、父母にWEB+DB PRESS を贈りました。父母が嬉しそうにWEB+DB PRESS を読んでくれました。何よりも副産物です。
  • 最後に、今回の執筆にあたり、技術評論社の編集部のご協力、機会を与えてくださったiret の皆様に心より感謝いたします。

 

参考資料

コラム

Posted by takaaki