スクリーンショット_2019-02-15_10

エンジニアの執筆活動がテーマの本「Write Your Way to Success」を読んだ

技術書を英語で読む取り組みの一貫で Write Your Way to Success というエンジニアによる執筆活動・書籍出版がテーマの本を読んだ。薄い本だったが興味深い内容だった。


著者は誰?

Azat Marden氏。存じ上げておりませんでした。Node.JSやExpress.jsで著名なエンジニアらしい。

本書籍は、この著者がNode.jsやExpress.jsに関する本を自己出版し、後年には大手出版社Apressからのアプローチをキッカケに Practical Node.js  を出版するに至った経緯・出版する為にした事・拡販する為にした事、等の実話に基づいて書かれている。


著者が本を書く意識を高めたキッカケ

元々著者はRailsメインのエンジニアだったようだが、2012年にRailsエンジニアとして転職を試みたところ、(著者の見立てによると)スキル不足が原因で5,6回不採用になってしまったらしい。それをキッカケに別の技術=Node.jsへの関心を高めていき、初歩的な内容でも学んだことをブログに書き始め、さらにはベンチャー企業でNode.jsトレーニングコースを主催するまでになった。

著者はこのトレーニングコースの成果物を纏め、Leanpubにて Rapid Prototyping with JS という名前で公開した。公開した事で「他の開発者と知見を共有する」事のメリットを悟った著者は、人に物事を教えたり共有したりすることこそが最善の学習方法と考えるようになった。

I remembered that the best learning is when you teach somebody else.

自分も雑にgistに残しておいたメモにstarやはてブが結構付いてた、という経験がある。自分にとってはメモレベルでも、他人が読んだ時に単なるメモレベル以上の価値が感じられるというケースは往々にしてあると思っていて、遠慮せず公開していくメリットは案外大きいのかも知れない。


"ProgWriter"

本も書くプログラマーの事を著者は "ProgWriter"(Programmer + Writer) という造語で呼んでいる。著者によると "ProgWriter" のモチベーションは「単にコードを書くだけでは気付けなかった曖昧な機能や落とし穴に気付き、それを学んで定着させること」にあると言う。

入門記事や公式ガイドに書いてある内容を身に付けるだけでも動くシステムは書けるかも知れないが、普通に開発している分には気付かない事・必要が無い事を知っておく事で品質や生産性を向上させる事が出来る。深掘り知識を持っているメンバーがピンチを救ってくれるというシーン、エンジニアなら何度か見てきた経験があるんじゃないだろうか。

It creates motivation to research, learn, and document some obscure functionalities, features, and pitfalls that otherwise likely would have never been discovered just by using the code.

特にテックリードのようなポジションでは、「自分のアイデアを、同意が得やすい方法で示す能力」が要求される場面が多い。アイデアや考えをoutputする場数を踏む事で表現力を磨く事が出来、自分の言葉の説得力も増す事が出来る。

開発の現場で「地雷を踏む」という言葉を使う事があるけど、率先して地雷を踏みその周辺情報を共有する事で、後に続くエンジニアが短時間で効率的にその技術を学ぶ土台を作る事が出来る。そうしたある種の奉仕精神が有るか無いかが "ProgWriter" の素養があるかかどうかの分岐点かも知れない。地位や名声を得る事を自己出版の最優先の動機にしても、あまりメリットは無い(書籍内ではこれが数字を使って説明されている)。


バズらせる為の戦略/テクニック

3つだけ抜粋。


【何をテーマに書くべきか?】

1. 今注目されている比較的新しいテクノロジを選ぶ
2. すでに人気を博しているトピックのベストセラーを見つけ、その本の欠陥を調べ・対処し・より良い本を作る


【Kindle(Kindle Publishing)の活用】

多くのKindle本は印刷本よりも安価であり、事実上あらゆるデバイス/プラットフォーム/ OS用のアプリがある。Amazonというプラットフォームの力も含めて訴求能力が高い。


【トピックの注目度をテストする】

そのトピックに関するブログ記事を書き、WebサイトやSNSで共有する。著者がオススメしている共有先サイト(※英語圏)は下記

• Hacker News
• Product Hunt
• Facebook groups
• Google groups
• LinkedIn groups
• Meetup.com forums

著者がExpress.jsというトピックを選んだ理由は、Express.jsに関するブログ記事でトラフィックが25%増えたからだったらしい。そして著者はここで Express.jsに関する本を最初に出版する人にはなりたくなかったので、誰かが最初にこのトピックに関する本を出版するのを待つ という判断をしている。その理由は、Express.jsの市場規模がもっと大きくなると読んでいてそのタイミングを待ちたかった為だと言う。こうした嗅覚というかマーケティングセンスは、エンジニア誰しもが備えているような資質では無い気がしていて、この著者はそういう面でも「売れる本を売れるタイミングで出すセンス」があるエンジニアだなと感じた。


100 - 1 = 0

Rapid Prototyping with JS を出した際に些細なタイプミスを見逃してしまい、それをほじくり返すような鬱陶しいメールが大量に送られてきたという経験を経た結果、執筆・出版は開発以上に入念にデバッグするべしと思うようになった。という話が書かれていて、何だか生々しかった。この感覚は出版経験が無い自分にはちょっとピンと来なかったかも知れない。読者厳し過ぎなのでは。。。?

対価を貰っている以上は内容に関するフィードバックがシビアになるという事が分かるエピソードだったが、些細なミス1つで、読者はそのミス以外にどれだけ素晴らしい内容が書かれていても目を通さなくなる事もある、という事は頭の片隅に置いておきたい。

books are like software: it’s better to have fewer features with no bugs than lots of features with bugs. Again, I learned this the hard way when I released half-baked portions of Rapid Prototyping with JS



儲けは大事。ただし最優先事項では無い

全編でとにかく金にまつわる話が多い。本当に伝えたかった事は金や儲けの事では無いはずなんだけど、「多くのエンジニアに自己出版にチャレンジして欲しい!」という想いが熱いがあまりに、そのメリットを強調しようとした結果金にまつわる話が想像以上に多く散りばめられてしまったという顛末なのかな?と想像した。何をしたらどれだけコストが掛かるのか?そのコストはいくら本が売れたら挽回できるのか?それらが具体的な数字と共に数多く語られててリアリティがある。

コーヒーショップで執筆中に、執筆なんて止めてこのコーヒーショップでバイトした方が稼げるんじゃないか?と疑問を感じた事もある ぐらい対価へこだわりは強いようなんだけど、著者が一番伝えたかった事はあくまで「自己出版を経て自らの技術的なスキルを高めること」であるという事は、ちゃんと全編を読めば分かる。

Developing the skills to formalize ideas and thoughts is a must for technical leaders who need to learn, practice, and improve their ability to persuade (and their ability to present their ideas in the best way).


3ヶ月程前に個人事業主に専念し始めて自分のスキルやナレッジをどうoutputすべきか?どうニーズを探るべきか?という事に関心を高めていたので良いインプットになった。

「カフェでコーヒーでも飲みながら一気に読んでくれよw」と著者も書いてるぐらいページ数的には薄い本なので、時間つぶしには良さそうな本でした。

※自分の英語力では一気読みなど不可能だった。。

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