見出し画像
Photo by masumiyutaka

ITエンジニアが本を書くことで生じる葛藤や不安とその解消 #ふりかえり

masuipeo

私はフリーランスのITエンジニアでありながら、これまで10冊以上の本を書いてきました。
「本を書いている」というと、世間から高い評価をもらうことは多くあります。

一方で、本を書くのには膨大な時間が必要です。
実際、1冊の技術書を読むだけであれば数時間で読めても、その本を書くとなると数ヶ月単位の時間がかかります。

しかも、本を書くことは基本的には自分の持っているスキルを表現するだけで、新たな技術を手に入れることは多くありません（もちろん、文章力は上がりますし、調べる中で知らなかった技術に気づくことはあります）。
執筆している時間を、技術者として勉強する時間に当てていれば、新しいスキルを身につけられたかもしれない、という思いがどこかにあるのです。

そんな中、今年は年間に5冊を出版し、1冊を監修しました。
それだけの時間を執筆などに投じたことの葛藤や不安について振り返り、その解消方法について紹介したいと思います。

（この記事は、「ふりかえり Advent Calendar 2020」に参加しています。）

書いた本について

まず、昨年末に投稿したTwitterの内容を見てみましょう。

ここにあるように、昨年末の時点で、今年は「一年間に商業誌を5冊書く」という目標を設定していました。
まだ今年の世の中がこんなにも変わるとは思っていなかった時期のことです。

そして、実際に書いた本がこちらです。

さらに監修した本がこちら。

年に5冊書き、1冊監修となると、ほぼ2ヶ月に1冊というペースになります。

私は普段、執筆に3ヶ月ちょっと、校正などで3ヶ月、合計半年くらいの感覚で進めているので、これまでの感覚では到底6冊は出版できない状況でした。
つまり、時間配分を考え直す必要があったのです。

ITエンジニアの仕事とのバランス

親戚や学生時代の友人と話をするとき、「今、どんな仕事をしてるの？」という話になることはよくあります。
これまでは「プログラマ」と答えることが多かったものです。
IT関連の仕事はたくさんありますが、ITに関係ない立場にいる人にも通じやすい名前が「プログラマ」だからです。

もともと独立する前はプログラマでしたし、独立した後もメインの収入はシステム開発でした。
しかし、年間5冊の本を書き、1冊を監修すると、使っている時間を考えても、明らかに執筆での売上が多くなります。
独立して10年、今年ははじめて「執筆の売上」が「システム開発での売上」を超えそうです。

ただし、上記のツイートにも書いたように、昨年までに合計10冊の本を書いてきましたが、技術書を書いているだけでは、10冊書いても「印税生活」とはいかないのが現実なのです。

執筆が本業になるのか

そしてこの記事のタイトルのことを意識するようになります。
つまり、本を書くことには葛藤があるのです。

例えば、ある編集者の方が発信された以下のツイートがあります。

ベストセラーというほどではありませんが、年に5冊書くとなると、明らかに執筆のウェイトが上がっています。

このまま本を書いていると、それに時間を取られて、「自分の技術力が通用しなくなるのではないか」「書いた本が時代遅れではないか」「世の中では自分の技術が必要とされていないのではないか」という不安に駆られるのです。

もちろん、私の仕事は以下に書いたように、「特定の技術」「特定の会社」に特化したものではないため、影響はそれほどありませんが、それでも不安は残ります。

この記事は振り返りがテーマでもあるので、この不安に対して、「YWT（やったこと、わかったこと、つぎやること）」の視点で現在の答えを私なりに振り返ったものを紹介したいと思います。

Y（やったこと）

まず「やったこと」（やっていること）は、世の中の変化を捉えることです。具体的には情報収集や書籍の購入など、インプットを増やすことです。
これまでもさまざまな情報収集について取り組んでおり、以下のような記事を書いたりしています。

この中でも触れましたが、新しい情報収集ツールとして、今年はTechFeed Proにエキスパートとして参加させていただく機会を得ました。

これまでなかったツールも活用しながら、自分の技術と世の中の変化を照らし合わせる、ということを常に意識できたことは不安を減らすことにつながったと思います。

また、上記の記事で触れたように、「情報はアウトプットする人に集まる」という言葉がよく使われます。実際、発信しないとその人が何に興味を持ち、何をしているのかわからないものです。この意味では、本を書いていることは情報が集まってくる源泉であると感じています。

発信の方法として、Twitterやブログでの投稿といった手軽なものから、講演での登壇や技術書の執筆など少しハードルが高いものもありますが、やはり書籍の力は大きいと感じています。

W（わかったこと）

本を書いていて気づいたことは、「本を書く」＝「技術の本質に迫る」と感じることです。
ITに関する技術は日進月歩でどんどん変わっていきます。一方で、本は一度書いてしまうと後から変更できません。長く読まれる本にするには、できるだけ本質部分に注目する必要があるのです。

つまり、時代が変わっても変わらないような技術とは何か、という部分に着目する時間が長くなります。
仕事でプログラムを作っていると、「とりあえず動くものを作る」ということが優先される場合もありますが、書籍の場合は長く読んでもらうためにどうするかを考えます。

今年書いた本『ITエンジニアがときめく自動化の魔法』の中では、取り上げていたサービスが執筆中に終了する、という事態がいくつも発生しました。終了したサービスを掲載していても仕方ないので、できるだけ最新のサービスを取り上げるだけでなく、代替サービスを自分で作ることも考える必要がありました。

そこから生まれたサービスが「iCal週間天気予報」で、それが多くの利用者に使ってもらえるようにもなりました。

自分でサービスを作ってしまえば、自分がやめることがないかぎり、そのサービスが続きます。これは1つの解決策として有効かもしれないと考えました。そして、このように書籍の1つの項目であっても、自分の技術力を使って世の中に役立つことを考える（そして実際に使ってもらえる）ことは、不安を減らすことに繋がりました。

T（つぎやること）

上記のサービス終了でも明らかなように、インターネット上にあるサービスはいつ終了するかわかりません。
例えば、CodeIQというサービスで数多くの問題を出題していましたが、サービスの終了とともにその問題は見えなくなってしまいました。

見えないものは存在しないことと同じだと考えると、これは寂しいものです。しかし、CodeIQで私が出題していた問題の多くは、以下の本となって残すことができました。

これはサービスだけでなく、文章などでも同じです。
今年は、技術ブログのサービスであったQrunchなども終了してしまいました。

このように、「Web上の記事は消えるけど本は残る」という事実を考えると、本を書くことは私にとって代え難いものなのです。
このため、今後も書籍を書くことは、求められる限り続けたいと考えています。

この記事が気に入ったらサポートをしてみませんか？