tl;dr
- Software Design への寄稿を狙っている方は、ブログに技術をアウトプットしてみるとチャンスがある
- 連載初心者は体力に加えて精神への負担がめちゃデカい
- 技術のアウトプットにより誤りの指摘や炎上が発生する可能性もあるが、やってみると想像よりもポジティブなフィードバックが多かった
はじめに
事業推進部の Defensive チームで働いている @strinsert1Na です。普段はチームメンバーに後ろ指を指されながら、脅威インテリジェンスの生成やそれに伴うソフトウェアの開発を行っています。
唐突ですが、Software Design 2022年8月号を以って『今日から始めるサイバー脅威インテリジェンス』の連載が終了しました。2022年3月号からの連載となりますので、サイバー脅威インテリジェンスに関する内容で、全6回に渡って寄稿したことになります。
サイバー脅威インテリジェンスSD連載の最終回は総まとめということで、OpenCTI を使ったインテリジェンスの蓄積と共有をやります! MISPを使用している組織がいたら使用感を見比べてみてくださいな。
— 身代わり用 (@strinsert1Na) 2022年7月14日
明日発売です。
Software Design 2022年8月号 #gihyojp https://t.co/RwEmAwAiXP
本稿は、これまでまともにアウトプットを出してこなかった筆者が体験した
- Software Design 様にて半年の連載をするようになった経緯
- 執筆方法や執筆のスケジュール感
- 連載を終えての感想
等を綴った後語りポエムです。本稿を通して、商業誌に寄稿をしたいけれども何をしてみたらいいのかわからない方への参考や、技術的な内容をアウトプットしてみたいけれどもあと一歩が踏み出せない方への後押しになれば嬉しいな、と思っています。
なお、Software Design に執筆した技術的内容については、また別のブログでお話する予定ですのでそちらもご一読いただけると幸いです。
連載までの経緯
事のキッカケ
発端は弊社が2021年8月にエンジニアブログを立ち上げることになったことから始まります。
弊社はHPのリニューアルと同時にブログを立ち上げることを目指しましたが、残念ながらブログに記載するための記事がまだ一本もない状態でした。このままでは新規同時リリースができなくなってしまいます。そこで、2020年に行った社内アドベントカレンダーの記事に白羽の矢が当たりました。社内アドベントカレンダーは外部公開されていませんし、すでに執筆してある内容をベースに加筆修正するだけで形になるため、短い期間で記事を掲載することができます。問題は誰の記事を選抜するかですが、「ブルーチームセキュリティっぽいことを書いてくれたこの人の記事がいいんじゃない」という話が浮上し、結果的に筆者の記事を技術ブログ用に改変して掲載する方針になりました。
当初、筆者は外部に向かって記事を書くなんてことは全く考えておらず、書いている内容もほぼ自己流の調査やトリアージ方法ばかりでした。もちろん、言葉遣いや構成もかなりひどいものです。事の経緯を聞いた筆者は「まぁ名前公開しないし、こんなもんでいっかー。ほとんど見られないっしょ」程度の軽いノリで、社内用に書いたポエムを加筆修正したものを記事として掲載する流れになりました。
執筆当時のスペックはこんなものです。
・ 記事に書いたこと: 自己流の情報収集
・やっていたこと: マルウェア解析とそれに伴うインテリジェンス業務を半々、約3年の経験
・ 誇れる実績: 一部の資格取ったことしかない(カンファレンスでの発表などなし)
そして以下の記事が、その現物となります。サイバー脅威インテリジェンスに関する話題を『導入編』(2021年8月25日公開)と『技術編』(2021年9月9日公開)に分割した、2本立ての内容としました。
掲載を確認した後の筆者は「一応最低限の義務は果たしたかな。もう記事を書くことなんてないでしょう。」程度に考えていましたが、これが全ての始まりでした。むしろこれだけで雑誌の連載につながるなんて当初は1 mmも想像していませんでした。
「エンジニアブログの問い合わせが来ています!!」
ブログ掲載のことも忘れかけていた2021年10月14日、CTOからいきなりslackのmessageが飛んできます。
CTO「@strinsert1Na さんのブログ記事を見た Software Design の編集さんから寄稿依頼がきていますよ。」
......
......🤔🤔🤔
はて、ブログ記事? あーそういえば2ヶ月くらい前に書いたな。そんで、Software Designって......
......😳!?
......もしかして本棚のラックによく飾ってある、あの"Software Design"ってコト！？
当時は本当に驚き、感情が一周回って「ブログって意外と人に見られているんだな」というどこか他人事のような感想を抱いたのを今でも覚えています。そして、ドキドキしながら編集さんからのメッセージを確認すると、以下のような内容が書いてありました。
- サイバー脅威インテリジェンスの初歩から、実際に分析に必要なサービスまでが纏まっていて興味が湧いた
- 上記の内容を軸にして、全8~10回、各回6ページ程度の連載を執筆するのはどうか
- できれば、攻撃者側の意図を汲んで、手を動かしながら対策するという目線を入れたい
- もし興味があればオンラインミーティングで話しましょう
......なるほど、本当にオファーのようです。間違いメールではなさそうです。
へーこんなこと現実にあるんだぁーと思い「software design 寄稿」などとググってみると、同じような状況で寄稿依頼をいただいている方のブログを複数発見できました。ブログにアウトプットするという行為だけで、チャンスが巡ってくることがあるんだなと思った瞬間です。
- nao さんの投稿、「シェルスクリプトの使い方」の寄稿
- 仁科俊晴さんの投稿、「第1特集 Dockerアプリケーション開発実践ガイド 第3章」の寄稿
そして「風・・・なんだろう吹いてきてる確実に」状態になった筆者はオファーを2つ返事で了承、ミーティングで連載の方針や執筆の段取りなどを決め、『全6回, 各回8ページ程度』の予定で連載を行うという方針となりました。(1回のページ数が多めなのは、6ページだと書きたいことが書けずに終わらなそうな分量だったためです。)
そしてさりげなくミーティングの際にオファーの経緯を深掘りしてみたところ、
- オファー当時はセキュリティ関連の連載がなく、セキュリティ関連で記事になる内容がないか探していた
- セキュリティを専門にしていない人でも理解しやすく、そして手を動かせる内容のものがいいと思っていた
という状況にたまたま筆者のブログがマッチしたようです。要するに、寄稿のオファーがきた理由は 「めちゃくちゃ良いタイミングで、たまたま編集さんの需要にマッチするブログを書いた」 からで、さらに言い換えると「とても運がよかったから」というのが妥当でしょう。たまたま2本買った宝くじが当たったと考えるのが自然です。しかし、せっかくいただいた貴重な機会です。「世のため人のためになるアウトプットを出そう」というモチベーションのもと、約9ヶ月に渡るはじめての連載生活がスタートしました。
執筆のスケジュール
執筆スケジュールは、企画段階のミーティングで「連載のテーマ/連載回数/ページ数」などについて調整し、その内容が承認されれば毎月決まったスケジュールで原稿を完成させていていく流れとなっていました。全体と隔月に分けて、大まかな流れをざっくり紹介します。
全体スケジュール
筆者の場合、前節でお話ししたオンラインミーティングが10/18に行われ、ミーティングをもとに「今回の連載のテーマ/タイトル/見出し案(全6回分のアジェンダ)」を11/07に提出しました。
そして上記の企画案が翌月の10日に承認され、そこからは当初の計画通り執筆開始という流れです。10-11月は全体構成や取り上げるツールの選定などに時間を費やしていましたが、振り返ってみると、あまりガチガチに見出しを決めなくてもよかったかなと思っています。理由は、連載が後半の方になればなるほど「雑誌に取り上げられた脆弱性を利用した具体例」などのアドリブ変更を頻繁にしていたためです。なるべくすぐ実践で使えるような内容にしたい気持ちがあり、直近1ヶ月で発生したサイバー脅威の具体的な内容やその検知方法について積極的に取り入れるようにしていました。
それに対して Software Design さんの方からは「180度変更とかでなければ筆者の書きたい方向性で書いてもらって全然大丈夫ですよ。分量足りなそうならページ数伸ばしますよ。」とおっしゃっていただき、毎回心からの感謝をするばかりでした。全体を通して臨機応変な執筆がしやすく、初心者でも非常に書きやすかったというのが率直な感想です。
1ヵ月単位でのスケジュール
連載が開始されると、こちらのスケジュールに沿って作業を進めていきます。寄稿には「原稿作成」の段階と、原稿を誌面のフォーマットに沿って修正する「校正」の段階の2段階があります。これらの作業が終わると晴れて入稿となり、次号の雑誌に記事が掲載される運びになるわけです。それぞれの段階での作業を、簡単に説明します。
原稿作成
前半は、提出した見出しをベースに記事を執筆する作業です。月のちょうど真ん中に原稿の〆切日があるため、その日までに事前に決めた分量程度の原稿を執筆して納品します。納品のフォーマットには指定がなく執筆者側で書きやすいものを自由に選定して良いとのことだったので、筆者は HackMD で執筆しました。
当初はTexなどで書くことを覚悟していたのですが、markdownで執筆できたので書きやすく、かつ編集コメントもHackMDのコメントで管理できたので非常に執筆作業がしやすかったです。
そして具体的な執筆スケジュールはだいたい以下のような感じでした。
| 稼働日数 | 累計日数 | やったこと |
|---|---|---|
| 2 | 2 | 時事ネタ集めと技術検証 |
| 1 | 3 | 全体の骨組み作成 |
| 7 | 10 | ひたすらに執筆 |
| 1 | 11 | 原稿で使用する画像素材の作成 |
| 1 | 12 | 妻に軽く見てもらって感想をもとに修正 |
| 1~2 | 13~14 | まっさらな環境で記事通りにやってみてうまくいくかの再現 |
筆者の場合、まとまって執筆ができる日がほぼ土日しかなかったことと執筆の才能不足が相まって、第1週目の土日でネタ収集と技術検証、2週目の土日でほぼ執筆完了までいかないと詰みペースとなり有給必須となりました。原稿提出の直前に技術的な間違いがないかを検証するための日が丸一日欲しいと思う日が多かったので、2週間＋休み1日が一番無理のないスケジュールだったなと個人的には思います。
執筆量は、筆者の場合8ページなので、文字数換算で約10,000字が目安です。しかし毎回気持ちが溢れすぎて15,000字くらいになり、不必要な部分を編集の方にカットしていただきました。本当に毎回面倒な作業をありがとうございました。このような編集の方とのやりとりを2~3回程度行い、文章・内容に問題がなさそうな場合は記事が無事納品されます。その後は編集の方でレイアウト作業へ移行していただき、初校の完成を待った後に校正の作業に移ります。
校正
初校とは原稿を元に作成された誌面用のPDFです。この段階になって初めて各ページに生まれる余白や白黒印刷時の画像の見やすさがわかるため、空白にコラムを埋めたり、読みやすいように一部文章を加筆/削除したり、画像を再作成する作業を行ったりします。
校正段階だと大きな変更を行うことは少ないため、比較的軽めの修正を2~3回程度のやりとりをしながら行っていき、1週間程度で校了、そして月初に入稿が行われます。校正はGoogleドライブで共有されたPDFにコメント入れる形で行うことができたので、執筆と同様ストレスフリーに修正をすることができたので快適でした。
校正の最終段階にくると執筆者側はほとんどやることがないため、脅威動向が変わったりツールのメジャーバージョンが上がらないことを祈りながら次の原稿の準備を始めるという感じです。(決まりではないのですが、Software Design さんからの執筆の"お願い"に「ツール・ソフトウェアはなるべく最新バージョンのものを利用する」というものがあります。とあるツールは原稿を作っている途中でメジャーバージョンが上がり、どうしようか悩みましたが覚悟を決めて最新のメジャーバージョンに対応した内容にしました。)
完走した感想
改めて振り返ってみると、「仕事が終わった後にまた研究職っぽいような仕事をしている生活」が約半年続いたような感覚で、「半年はひたむきに駆け抜けてきたなぁ」というのが素直な感想です。
特に1月と5月は本業が過渡期を迎えたこともあり執筆ペースがかなりギリギリで、年末年始休暇とGWでの書き溜めがなければ確実に落としていたと思います。よく言われますがいつもギリギリを生きすぎですね。
積もる話はいくらかあるのですが、書きすぎてもスペースがなくなってしまうので大きなトピックにして2点だけ書きます。
"連載" をしている全ての人を尊敬できるようになった
どんな形でも、連載を経験した方は同意していただける方が多いのではないかと思います。
連載前の筆者は「まぁ連載といっても1ヵ月スパンだし全然余裕あるでしょう」と高を括っていましたが、実際に体験してみると想像以上にハードでした。理由は2点ほどあると考えています。
1点目は、「決められたスパンで、ほぼ一定量の価値を生み出すことの難しさ」です。連載を承諾した当初、筆者は執筆活動を『やったことを綴る定期レポート』か何かと勘違いしていました。しかし、その実態は読者に対して価値を提供する行為であって、マインドとしては日中に行っている仕事とほとんど変わらなかったです。ブログ執筆の際のマインドとの大きな違いですかね。(かなり酷い書き方ですが、本稿レベルの内容だとただ自分の感想文を綴っているだけなので何も気にせず筆が進みます。)
実際に執筆をしてみると、当初のテーマからのブレ/要求される技術レベルの飛躍/気持ちが溢れ出すぎて文字数制限を大幅オーバーなど、一度書き切ってみたら仕様に合っていないものが生まれるなんてことがよくありました。そして、テーマからブレたりお気持ちが入りすぎるほど、内容がターゲットからズレて面白くありません。「興味をそそられるような面白い話を、テーマを一貫させて、約1万字程度に納めて記述する」ことができるというのは1つの能力だなぁと今でも思います。筆者の連載は、エンジニア(but セキュリティ専門ではない)の妻の感想と編集の方の大幅カット・修正によって、読者の方々が毎号なんとか楽しく読める形になっていました。圧倒的感謝です。
そしてもう1点目が、「外部からの反応がものすごく気になる」という点です。これは精神面の話なのでメンタルが強い人にとってはほとんど影響がないと思うのですが、筆者にとって「実名で一般公開する」行為はものすごくプレッシャーで、結果として全ての作業に想像以上の時間がかかった要因となりました。具体的には、以下のような感情が連載期間中常に襲ってきます。
- 執筆した内容が間違っていないか
- 記事が炎上しないか(特にセキュリティ界隈怖いからめっちゃ叩かれそう......)
- 執筆した内容よりもっと良い方法があったら申し訳ない(連載の内容はほぼ自己流だから、ベストプラクティスは違うかも.....)
- 「1 + 1 = 2 」みたいな話するな、とか思われていないか?
- そもそも興味なくて誰も読んでくれていなかったら悲しい
結果として、これまでほとんどすることがなかったエゴサが捗るようになり、Software Designの最後に載っている「Reader's Voice」も毎号確認するようになりました。人って唐突にメンヘラになれるんですね。筆者なんかよりも有名で頻繁にアウトプットをしている人は、毎日このプレッシャーと闘っているんだなぁと思うと本当に尊敬します。もう休載した漫画に文句は言わないと心に誓いました。
最終的に、技術をアウトプットしてみてよかったと思えた
これまでアウトプットをしたことがない人の中にも、筆者と同じような感情が渦巻いてあと一歩を踏み出せないという方がいらっしゃるのではないでしょうか。
しかし連載が終了した今振り返ってみると、筆者の場合、 Software Designに寄稿させていただいたことによって発生した「Negativeなこと」は全くありませんでした。(もしかしたらこれを機に発掘されて炎上するかもしれませんが.....)
むしろ想像の真逆で、「この脆弱性こっちでも対応したことある!」, 「あのツールってこういう使い方があったんだ」のようなポジティブ方向の感想をいただくことが多かったです。たしかに、Negativeなフィードバックをいただいたこともありました。しかし、それは「あの号の話は退屈だったから、こうこうこうの方がよかったんじゃない?」程度のもので、これは次号以降の執筆をより良いものにするために有益なフィードバックです。自分の執筆した内容が少しでも世の中の役に立っていることがわかり、たいへん嬉しく感じました。
また、雑誌にはTwitter accountを掲載させていただいていたのですが、同じような業種に携わっている方とのコミュニティも広がり日常生活もかなり有意義になりました。一部紹介したツールについては作者本人からも反応をいただき、本当に喜ばしい限りです。
Software Design 7月号の「シグネチャを活用して高度なインテリジェンスの生成」記事でHayabusaが紹介されていて、嬉しいです！
— 田中ザック (@yamatosecurity) 2022年6月22日
(Gentooユーザのせいか昔からnano派ですが、この機会にVimをマスターしようかな〜) pic.twitter.com/aLR4k5oK8g
まとめると、初心者にとって表現のアウトプットは肉体だけでなく精神にも大きな負担となる可能性があります。自分で生み出した価値・表現をアウトプットしている全ての人は、大小あれどこの不安と闘っているのでしょう。
それと同時に、アウトプットというのはやってみると意外とポジティブなことが多いということがわかりました。「自分でやったことをまとめて外部に発信する」という行為は面倒ですしそれ相応の体力を消耗します。数回アウトプットしただけでは全く注目されないかもしれません。しかし、意外とそれは様々な人に見られていて、表には見えないけれどもきちんと評価してくれる人もいると思います。怯えている方はその一歩を踏み出してみると、思ってもみないチャンスに巡り合えるかもしれません。
感想ではない、が得られたもの
最後に感想ではないんですが、筆者は考えが行き詰まったときに現実逃避を兼ねた筋トレをするため、身体はなぜか健康になりました。(当初1年かけてStage 8までしか進まなかった"リングフィットアドベンチャー"が半年でStage 20まで進みました。)
毎年健康診断で「運動してください」と釘を刺されていたので、これを機会に筋トレを継続的に行っていきたいと思います。
おわりに
本稿では、軽い気持ちで投稿した社内ブログからSoftware Designで連載するまでになった流れ、連載中の作業内容、そして筆者の感想を垂れ流しました。
当初は「あまり高度な内容でもないし、どうせほとんど閲覧されないでしょ」程度の軽いノリで執筆した内容が、いつの間にか泣く子も黙る商業誌で連載されるようなボリュームにまで成長するなんて想像もできず、今振り返ってみても運が良かったなぁと思います。特に、筆者がブログに執筆した内容(詳細は技術編で紹介する予定)はその道のプロにとっては些細な内容であり、これが公開されたことによって世界が良い方向に変わるなんてことは到底考えられません。しかし、ブログに投稿しただけでコミュニティの広がりや新たな挑戦の機会につながったことを踏まえると、「表現をアウトプットをする」という行為そのものの影響力が非常に大きい ということが、皆さんに伝わったのではないかと思います。(ただし、これが炎上方向に行ってしまうと怖いので、心配な方は第三者の目を通しましょう。)
本稿が、Software Design などの商業誌への寄稿をしてみたい方、技術のアウトプットをしてみたいけれども不安を拭えない方への参考になれば幸いです。
最後に、本連載の執筆にあたり編集、デザイン、校正様々な面からサポートしていただいた山崎様にはたいへんお世話になりました。筆者が書く文章はこのブログ記事のように毎回はちゃめちゃで、図の修正を含めてそれをなんとか皆さんが理解できる格好にしていただきました。心からの御礼を申し上げます。コミュニケーションツールはslack、原稿執筆はHackMD、PDFのレビューはGoogleドライブと、すべて普段使用しているツールで活動が行えたので、初心者でも何一つ困ることなく連載を続けることができました。
また、連載期間中に日常生活を支えていただき、尚且つプロトタイプのレビューまでしていただいた妻にも感謝申し上げます。そして、執筆をサポートしていただいた弊社およびチームの皆様、本当にありがとうございました。
皆様に心からの感謝の意を示し、本記事の締めとさせていただきます。
少しでも興味を持っていただいた方は、また技術編でお会いしましょう 👋
※ NFLabs. はセキュリティを中心とした様々なエンジニアリングを行っています!
これからも皆様に有益な情報を発信していく予定ですので、Twitterのフォローと本ブログの「読者になる」ボタンのクリックを、ぜひぜひお願いします!!
