年とってくると注意してくれる人がいなくなる
あらゆる組織の若手は最初は先輩社員の指導を受けて育っていきます。ところが年を経るにつれて注意されなくなってきます。わたしも社会人になってから今まで、注意される回数がどんどん減っていきました。もちろん私が成長して注意すべき点が減ってきたというのもありますが、それだけでは説明がつきません。あとから振り返ってみると「これは相当まずいことをしたな、昔なら相当叱られてただろうな」ということが多々あります。では自分の成長以外にどういう要素があるかというと、それなりに大きなウェイトを占めるのが加齢だと思っています。
「技術の前には年齢は関係ない！」という話もあり、実際それはそうだと私も思いますが、年長者は敬うべきという文化がずっと続いてきた日本で実際に年長者に正面からボロカスに注意する人というのはなかなかいません。それに加えて「この年になるまで変わらなかったんだからもう注意しても無駄だろう」「年食ってきたら人間はもう変われない」という意識も働くと思います。本人のいないところで「あいつ使えない」と言われることはあるでしょうが、それは本人には届きません。
実際自分が40歳に達した今、注意してくれる人がいないのは自分にとっての大きな問題のひとつで、定期的に過去の自分を振り返って内省をしています。そうしないと改善のきっかけがないのです。そうしないとプライドが高くて成長が止まった役に立たない人のできあがりです。
この取り組みがうまくいっているかはよくわからないのですが、しないよりは全然いいと思っています。年はとってきて、不可逆なかたちで衰えが出てきているところは多々あれど、今後もできるところは改善、進歩していきたいと思います。
1からコードを書き起こさないプログラマ
以下の記事が面白くて、かつ、自分も似たような観点でなんか書いてみようという気分になったので書きます。
主な対象読者はプログラマの業務がどんなものかピンと来ていない人たちです。
わたしはソフトウェア開発者で、かつ、現在は10万行程度の規模のRookというOSSのメンテナとしての開発をしています。それより前は2700万行ほどあるLinuxカーネルのうち、10万行ほどの規模のサブシステムを扱っていました。
私がこれらを1から書き起こしたかというとそういうことはなくて、どちらも既にあるものの開発に途中から参加しました。書くコードも大規模な機能追加というよりはバグ修正、ドキュメント修正、既存機能に新しいモードを足すようなものが中心です。バグ報告のときの再現プログラムを書くことも多いです。
それ以外にも、わたしは趣味で大きなプログラムを書くことはあまりないです。これまでに一から書いたソフトウェアがいくつかありますが、それぞれ高々数千行、あるいは一万数千行程度の規模です。やりたいのにやっていないかというとそうでもなくて、自由に無から有を作り出すものより、既存のコードにいかに影響を与えずに必要最小限のコードで目的を達するか、というところに一番興味があります。
プログラマといえば自分で一からプログラムを書くというオリジナル作者というイメージがあるかたが多いと思いますが、こういうケースも多々あります。もちろんどちらか一方だけではなく、どちらもたくさんやるというケースもありますが、わたしはこういう具合です、という参考情報でした。
これまでの人脈の広がりかた
はじめに
先日書いた以下の記事の反響がけっこうあったので、その続きのようなものを。
satoru-takeuchi.hatenablog.com
わたしは今も昔も仕事としてOSS開発者をしていて、twitterなどでそれなりに名前が知られていることもあって、昔から「どうすればそういうこと(業務としてOSS開発)ができるのか」「どういうキャリアを歩んできたのか」「Linuxカーネル開発者になるにはどうすればいいのか」ということをよく聞かれてきました。当時わたしが置かれた環境と現在の環境では違いがありすぎるので公開に積極的にはなれなかったのですが、一つの過去事例として何らかの意味はあるかもと思って公開することにしました。
これと似たような話で、わたしはIT業界の知人友人がけっこうな数いて、かつ、かなりジャンルがバラエティに富んでいます。このため、「どうやったらそうなるのか」という質問をよくされます。本エントリはそれについて書きます。どんな時期に何をしたらどういう人と知り合いになってきたか、という観点で書きます。
IT企業のインターンシップに行くまで(~2003)
2003年のM1のときに上記の記事にも書いたように富士通のインターンに参加しました。それまではIT業界の知り合いは皆無でした。学科が材料系だったこと、および他の学科の人との交流もなかったことより、知人友人にもプログラミングに興味のある人は皆無でした*1。当時は自分の一番好きなことを話せる人がおらず、かつ、自分の能力がどれほどのものかもわからず、悶々としていました。
インターンに行くとLinux大好きな人、カーネル大好きな人、プログラミング大好きな人、とたくさん知り合いました。IT企業といえど仕事としてやってるだけで好きではないという人ばかりの職場もあるそうなので、ここは恵まれていたのでしょう。
この時期まではIT業界の知り合いはインターンに参加したチーム、およびその周辺の人たちだけでした。
新卒入社以降数年のカーネル開発者人生の前半(2005~2009年)
就職すると社内の知り合いが徐々に増えてきました。自分のチームからはじまり同じ部署の別チームの人、別部署の人、などなど。ただSEさんと話すことは稀で、お客様を含めた社外のかたと知り合うことは皆無でした。ここまでは大企業の開発者としてはとくに珍しくないでしょう。
その一方で、ベンダと取引先やお客様という関係ではなく、同じOSS(Linuxカーネル)を開発する人たちとつながっていきました。接触の場は主にLinuxカーネルに関するイベントです。古くはOttawa Linux Symposium、OSDLのJapan Linux Symposiumなど。その後はLinuxCon Japan(現在も毎年開催されているOpen Source Summit Japanの前身)などなど。これらのイベントを通して大手ITベンダ(NFH,NTTDなどなど)のLinuxカーネル開発者たちとちょくちょく喋るようになりました。
この時期までは社外のIT業界の知り合いはほぼLinuxカーネル開発者のみでした。
社外イベントの講師(2010年)
たまたま社内でオペレーティングシステムの講義をやっていたこともあって、セキュリティ&プログラミングキャンプというイベント(セキュリティキャンプの前身)で学生にLinux Kernelを学んでもらうコースの講師として呼ばれました。講師は全員現役Linuxカーネル開発者という強烈なメンツで、社外のかたが5,6人いました。当時ほかのかたとは「お互いに顔は知ってる」程度でした。このイベントを通してずいぶん仲良くなりました。講師だけではなく、LinuxやLinuxカーネル、プログラミングが大好きな情熱的な学生さんたちともたくさん出会えました。そのうち一部のかたは現役Linuxカーネル開発者になったりなどして今も縁が続いています。
セキュキャンで特筆すべきは、これまで全く縁がなかったセキュリティ技術者、OS自作lover達、プログラミング言語開発者のかたがたという別ジャンルのかたがたと知り合えたことです。あまりにも世界観が違うのでかなりの衝撃を受けたことを記憶しています。セキュリティキャンプは学生同士、学生と講師が繋がるハブとして過去も現在も機能していますが、教える側の講師も別ジャンルの講師/学生とつながって刺激を受けることも珍しくないのです。
現職のサイボウズの社員のかた*2との縁もここでできました。まさかそのときはサイボウズに入社するとは夢にも思っていませんでしたが…
他にもセキュキャンを機に、当時はさして興味がなかったtwitterをはじめました*3。のちにこれは私の人脈の広がりかたに大きく影響するようになりました。
カーネル開発者人生の後半(2010~2017年)
セキュキャンで知り合ったLinuxカーネル開発者たちを経由して、Linuxカーネル界隈の主だった日本人開発者たちはほとんど知り合いのような状況になりました。技術的な話からくだらない話まで、ずいぶんたくさんした気がします。このかたがたとは今でも関係が続いています。
Linuxカーネルに詳しくなっていくとともに、各種イベントにおいても聞く側だけではなくプレゼンする側になったりして、日本国外の開発者とも知り合いになってきました。主に自分が開発にかかわっているコンポーネントの開発者とよく話すようになりました。
無職時代(2017前半)
前職を辞めてから、とくにやることがなくてツイ廃になりました。2010年から2017年あたりまでは大してフォロワーもおらず、知名度もなく、淡々とネタツイをして過ごしていました。
この年に買った新しいPCについていたとあるCPUの不具合を見つけた*4こと、および、それを面白がってtwitterで調査の進捗報告したことにより応援や注目してくださるかたが増えて*5、いろんなジャンルの知り合いが増えていきました。狙ってやったわけではないですが、知名度もそこそこ上がりました。「いつもtwitter見えます」と声をかけてくれる人も増えました。
ツイ廃だけではなく個人事業主として技術書を書きました。これが結構売れて評判もよかったことから、こちらも知名度が上がり、かつ「本を見ました」というのをきっかけに知り合いも増えたと記憶しています。「この人といえばコレ」という持ちネタがあると相手も話のきっかけがあって、知り合いが増えやすいという印象があります。
このあたりでkernel/vmというカーネルとかVMとかが好きな人たちの集団とかかわるようになりました。ハッカーコミュニティというやつですね。ここではのちに幾つかのイベントの主催もするようになったりして、さらに知り合いが増えていきました*6。
外注エンジニア時代(2017年後半~2018年前半)
この時期に過去の知り合いがいろいろ取り計らってくれたこともあり、Linuxカーネルに詳しい人としてサイボウズに技術顧問(外注技術者)として雇われることになりました。雇ってくれた人とは間接的にしかつながりはなかったのですが、既存の人脈が大きく生きました。余談ですが、twitterでの巻き込みリプライをきっかけになんやかやあって雇われたのでtwitter就職(このときはまだ外注エンジニアだけど)だったりします。
サイボウズ社員時代(2018年後半~)
この年、技術顧問から社員になりました。仕事はLinuxカーネルからすこしレイヤが上がってKubernetes技術者です。さんざ苦労してきましたが徐々に仕事が軌道に乗ってきました。さまざまなイベントに参加したり、登壇したりすることによってKubernetesの技術者とのかかわりが生まれました。この業界でも幸か不幸か「twitter見てますよ」と声をかけられることが多いです。見られるのはこっぱずかしいですが、話すきっかけになるのはいいことだと思っています。
今は会社の次期インフラで使う予定のRookというソフトウェアのメンテナをしていることもあり、海外在住のRookの他のメンテナや開発者たちとも親しくなりました。Rookの開発を通して「Rookの人」「Kubernetesのストレージの人」としても認知されるようになりました。
おわりに
現在の知人、友人の構成は次の通りです。
- 前職の先輩、後輩。ほぼ全て同じ部署か1hop先の部署の人たち。十数人*7
- Linuxカーネル開発者たち(”元”を含む。わたしも今はやってない)。十数人
- セプキャン&セキュキャンをきっかけに出会った人たち。数十人
- kernelvmの多彩な能力を持つ人たち。数十人
- Kubernetes技術者たち。十数人
- 上記の人たちから紹介された人たち。数十人
- Rook開発者たち。数人
- ついった知り合い。数十人。アカウント名しか知らない人多数。お互いIT技術者だが技術的な話を一切しない人もいる
振り返ってみると「人脈を増やしてやるぜ」と息まいたことはあんまりなくて自然と増えていったので、あまり気負わなかったのがよかったのかもしれません。鼻息荒くいくと独特の臭みが出るので避けたほうがいいかもしれません。
その他に読者のみなさまに言えることがあるとしたら、面白そうな人たちがいる場所に飛び込んでみる、発表の場があればやってみる、twitterなどのSNS、qiita、zenn、note、各種ブログなどのサービスから地道に情報発信してみて「この人といえばコレ」というものを作って、ウマが合うひとたちと自然につながっていけばいいのかなと思います。
ではこんなところで、おわり。
仕事としてOSS開発者をやってきた話
はじめに
わたしは今も昔も仕事としてOSS開発者をしていて、twitterなどでそれなりに名前が知られていることもあって、昔から「どうすればそういうこと(業務としてOSS開発)ができるのか」「どういうキャリアを歩んできたのか」「Linuxカーネル開発者になるにはどうすればいいのか」ということをよく聞かれてきました。当時わたしが置かれた環境と現在の環境では違いがありすぎるので公開に積極的にはなれなかったのですが、一つの過去事例として何らかの意味はあるかもと思って公開することにしました。
書き方が難しかったのですが、うまくまとまらなかったので、自分が書くのが楽な日記みたいになりました。
きっかけ
2000年初頭に学部4年のころにLinuxを触りはじめてから「UNIXとかLinuxってすげえ」「こんなものが無償で使えるのか」「これらのソースコードが全部見られるのか」と感動して、「自分も成果物を公開していきたい!」「この道で食っていきたい!(やりかたしらんけど)」と思ったのがすべての始まりです。
その後「プログラムってどうやって動いているんだろう」というのを掘り下げて行ったらカーネルにたどり着いて、Linuxを使っていたのでLinuxカーネルに興味を持って色々調べていました。ここでも「この道で食っていきたい！(やりかた知らんけど)」になりました。
ありがちですが以下の本なんかも読みました。
インターン
B4の頃、私がその手のことをやっていると知っていた友人が「こういうのがあるらしいよ」と、とあるサーバベンダでLinux開発をやっている部署がインターンの募集をしているということを聞きました。当時はLinuxカーネルなんて本を適当に読んだだけでいじったことはあんまりなかったのですが、「まあなんとかなるやろ、落ちても別にダメージはないし、受かって何もできなくてもその時だけのこと。もしうまくいってここに入れればめっけもの」と思って応募しました。とくにわたしは情報工学や情報科学専攻ではなかったので*1、こういう手段をつかわないとなかなかカーネル開発なんて難しいだろうなあという思いはあったので、「これだ！」と思った記憶があります。
エントリーシートの内容はあんまり覚えてないんですが、「実績はまったくないですがプログラミング経験はあります。意欲はあります！」のような勢いだけのものだったと思います。
幸いにもインターンには受かりました。当時は日本のサーバベンダが「これからはIAサーバ*2でメインフレームやUNIXの置き換えでやるぞ！」と怪気炎を上げていて、とにかく育ててでも人材が欲しかった頃なのでわたしのような怪しい人が入り込む隙間があったのかもしれません。
インターンでは実際にカーネルを触ってみたらなんとなく成果は出せたらしく、後日、無事その部署に配属になりました。インターンでやったことは詳しくは書けませんが、たとえばファームウェアが提供するハードウェアの情報が書かれたテーブルを書き換えてCPUを一個論理的に消すとかそういうことをしました。事前にいろいろ調べてはいたのでなんとかなりました。
ここで重要だったのは次のようなことだと思います。
- 友人、知人に「俺はこういうことをしている/したい」と話しておくのは重要。ふとしたことからチャンスは降ってくる。前述の友人もとくにコンピュータやLinuxに詳しいわけではなかった
- 幸いにもインターンで成果を出せるくらいの素養はあったが、応募しなければ何も始まらなかった。やって損はないことはやるといい
- 「どうせ俺は〇〇だから(自分の場合は「情報系学科ではないから」)」とあきらめない。あきらめなければ必ずできるわけではないが、あきらめたら試合終了
OSS開発、Linuxカーネル開発の実績を積む
入社してからは優しく厳しい先輩方に囲まれてゴリゴリLinuxカーネルに新機能を追加していきました。ここではとくにドラマ性はなく、日々必死に仕事をして、小さな改善パッチから始めて大きな機能の取り込みに、といったステップアップをしていきました。このときにLinuxカーネルそのものの知識に加えて、issueの発行のしかた、自分のパッチの効果に説得力を持たせるために議論する方法などを学びました。土台を固めながらの成長に近道はないです。
なお、優しく厳しい先輩方はmemory cgroupsの(当時)メンテナとかLinuxとRubyのデュアルコミッタとか、えげつないかたがたばかりだったので、学べるところがたくさんありました。今思えば、これほど豪華な環境で成長できることはなかなかないのではと思います。ほかにも表には出ないもののダンプの模様が見える超人のような人とか、いろんなすごい人達がいました。
今やってること、OSS開発経験が役立つこと
今は上記サーバベンダは辞めてグループウェアを作っている会社にいます。といってもWebアプリを作ってjsとかを触っているわけではなく、Go言語を使ってKubernetesやらRook/Cephを使ったオンプレインフラ基盤を作っています。
業務はupstreamのRookの開発がいまのところ中心で、メンテナもやってます。ただし最初からupstream Rookの開発をやるために入社したわけではないです。会社が求めていたスキルにマッチしているから入社して、自社インフラを作るにあたってRookにゴリゴリコミットできればいいねということになって、わたしができそうだからやりはじめただけです。
過去の知識についてはオンプレ基盤という性質上、Linuxカーネルの知識はとても役立っています。Rookの開発についてもLinuxカーネル開発で培ったOSS開発の型のようなものがずいぶんと役立っています。LinuxとRookはまったく性質が異なるコミュニティなのですが、型はできていたのですぐに適応できました。この型はなにもOSS開発だけではなく部署間、会社間の交渉にも役立つと思います。
今から業務としてOSS開発するにはどうすれば?
今から業務としてLinuxカーネル開発者になる方法については正直言ってよくわかりません。わたしは5年近く前にLinuxカーネル開発が仕事でなくなって、この界隈の事情に疎くなったからです。他のソフトウェアについてはもっとわかりません。
一般論になってしまいますが、できるところから自分のたずさわりたいOSSについてissue報告したりPR投げたりして実績を積んでおいて損はないと思います。それに加えてイベントなどに顔を出していると関係者の目に留まって…ということは珍しくはないです。実績がなくても界隈の技術者に声をかけるとなんらかのヒントをもらえるかもしれません。
あともう一つ言えるとしたら「企業はOSS開発をしたい人ではなく会社に貢献してくれる人を求めている」というのは重要です。仮にあなたがナントカというOSSのメンテナですと言っても、その企業でそのようなことが求められていなければ仕事としてはできません。そうではなく、そのナントカを使って仕事にしている会社、ナントカの開発によって利益が得られる会社を探す必要があるでしょう。
あやふやな言い方で申し訳ないですが、いい加減なことは言えないのでこのくらいで。
おわりに
なんか抽象的なことばかり書きましたが、わたしが言えるのはこんなところです。まとめると、ありきたりですが「情熱を持つ」「チャンスをつかむ」「実績を出す」「しっかり関係者にアピールする」といったところでしょうか。全部でなくてもかまわないので、できる範囲でやるとよいかと思います。
ついったでメンションとかDMとかしてくれれば追加でなにかお答えしたり、ここに追記したりできるかもしれません。その時々の負荷に応じてベストエフォートで…
ソフトウェア技術者にとっての英語
ソフトウェア技術者にとっての英語について最近思うことをつらつらと書きます。主題は英語学習についてではなく、そもそもの英語学習の必要性、および、問題は英語力ではないこともある、という話です。
「今後この業界を生きていくために英語は必須」とよく言われます。最新情報は英語で書かれたものしかない、仕事相手とのコミュニケーションには英語が中心、などなど。
こういう状況に置かれている人がいるのはその通りなのですが、そうではない場合はどうでしょうか。最新情報など興味がなくて追ってなくても困らない、あるいは興味がない、目の前の仕事は日本語だけで事足りている、という人にとってはどうでしょうか。もちろんできるに越したことはないのですが、必須かといわれると別にそういうわけではないかと思います。人によって重要なこと、緊急なことは違うので、たくさんある選択肢の中で英語だけをむやみに特別扱いする必要はないと思います。
ここからは簡単のためwritingに話を絞ります。なかなかうまく英語の文書が書けない、理解してもらえない、という人はたくさんいます。ただ、その人たちのうちのいくらかについては「この人の問題は英語じゃないな」と思うことがあります。ではなにが問題かというと言語に関係なく、物事を伝える能力です。
英作文が苦手と思っている人は、一度試しに同じことを日本語で書いて、近しい人に見せてみてください。そこで「何書いてるかわからない」と言われた場合、問題は英語がどうのこうのいう前に作文能力に問題がありますので、英語の前にそこを何とかするとよいと思います。この問題を解決するためには理科系の作文技術などの文書作成の訓練に役立つ書籍がいくつもありますので、見てみるとよいでしょう。
「何書いてるかわからない」と言われる場合、作文能力だけではなく、記述対象についての理解が十分ではなくて見当違いなことを書いている可能性もあります。この問題があるかどうかを確認するためには、その領域について十分知識がある人に日本語で伝えたいことを説明してみるとよいでしょう。
他にもいろいろ思うところがあった気がしますが、とりあえず思い出せるところは書いたので、このくらいにしておきます。また思い出したらなんか書くかもしれません。おわり
IT技術についての書籍を商業出版するか同人誌として出すか
IT技術者はさまざまなプラットフォームを通して情報発信して知見を共有するのが好きという印象が強いです。zennやqiitaといったサービスをはじめ、さまざまな場所で貴重な情報が無償で公開されているのは驚くばかりです。
情報発信を繰り返していくうちに自分のコンテンツを形にしたい、具体的には書籍を出したいと思う人も多いようです。そこで目の前に立ちはだかる壁のひとつが出版社から商業出版するか同人誌として出版するかという選択を迫られることです。本記事ではそれぞれのpros,consについて、これまでに商業出版、同人誌出版の両方の経験がある筆者の意見を書きます。
結論から書きますと、わたしは以下のような考え方を持っています。
- なるべくお金がほしいなら、あるいは世の中に広く情報を行き渡らせたいなら商業出版
- ニッチで客層が限られるものについては同人誌
- いずれにせよ普段から誠実な情報発信をし続けるとリーチできる層が広まる
まずはいきなりお金の話をします。具体的な数値や金額は出しませんが、私がかつて商業出版した本は、同人誌として売った場合は到底達成できなかったであろう数を売り上げました。やはり全国の書店に並んだり、そうしてもらうよう働きかけてもらったりしてもらうぶん、リーチできる範囲がはるかに広いと考えておくほうがよいでしょう。
一冊あたりの著者の取り分は出版までにかかわる人の数が全く違うために当然同人誌のほうが圧倒的によいですが、トータルで考えると、よほどコンテンツがよかったり、著者の名声が高かったりする場合を除けば金銭的な見返りとしては商業出版のほうが良いのではないかと推測します。お金はどうでもいいという人も、なるべくたくさんの人に読んでもらいたいという場合は、やはり商業出版に分があるように思います。
ただし商業出版をしたいという場合には上述のように販売するまでに介在する人が多く、たくさんのコストがかかる都合上、ある程度売れるものでないと出版は困難です。おそらく数千部単位の販売が見込めなければ企画として成立しないでしょう。
どうすれば商業出版の話を始められるのかがわからなくて二の足を踏んでいる人は多いようです。第一に、自分のネタに自信があれば持ち込みという手段があります。たとえば私が本を出したことがある技術評論社では持ち込み用のページがあります。他の出版社でもあるところはあると思いますが、探しにいったことがないのでよく知らないです。どの出版社がよいか、という疑問もあるかと思いますが、技評でしか出したことがないので他は知らないです。小ネタとして、「いつからO'reillyで本を出したい…!」という野望をもつかたは多いようです。あの動物の表紙、いいですよね:-)
第二に、過去の実績をもとに出版社から声がかかることがよくあるようです。出版社は売れそうな本のネタがありすぎて困っているというようなことはなく、日々世の中の流れをウォッチして、よいネタを常に探し求めているのです。
同人誌のメリットは何といっても売れるものを作る必要がなく、自分の欲望のままにニッチなコンテンツを作れるということです。わたしのコンテンツはBOOTHと技術書典オンラインマーケットで販売していますが、いかにも商業出版が厳しそうなニッチな書籍が並んでいます。ここを重視するのであれば同人誌がぴったりだと思います。
その一方で、商業出版において出版社がやってくれていた作業をすべて自分でやる必要があります。具体的にはプロによる編集、校正は入りませんし*1、組版から印刷、在庫管理まですべて自分でやる必要があります。この手の作業を全部自分でやりたい、かつ、できる人には苦にならないと思います。その一方で、わたしのように「そのへんはめんどくさいしできるとも思わないので全て人に任せたい」という人にはつらいかと思います*2。
同人誌にするとしたら、どのようなプラットフォームで売るかという選択も必要です。たとえばKindle ダイレクトパブリッシング、BOOTH、zenn books、技術書典オンラインマーケットなどがあります。それぞれみなさんの取り分、プラットフォームそのものの知名度、物理本出版の可否などに違いがありますので好きなものを選べばいいかと思います。場合によっては複数プラットフォームで売ってもいいでしょう。
最近では同人誌と商業出版の架け橋となる技術の泉シリーズというような面白いものもあるようです。残念ながらわたしはここから本を出したことがないので、どういう経緯で出版に至るのかは知りません。それはそれとして、わたしはマニアックな本が好きなので最近はここで本を買うことがよくあります。こういうニッチな文書を書く人にも、そのような文書を書く人、両者ともに嬉しい取り組みがもっと増えてくると面白いかなと思います。
どのような方法で本を出すにしても、わたしは信用が１番だと思います。わたしの場合もたくさん本が売れたりしたのは継続的に有償、無償を問わずコンテンツを配信してきて好評を受けた結果得られたおかげだと思っています。釣りタイトルでアクセス数を稼ぐような真似はせず、正攻法で良質なものを出し続けて信用貯金を貯めるのがよいでしょう。
やや話はそれますが、本にするにしてはあまりにも分量が少ないというような場合は、雑誌やWebメディアの記事にしてもらうという方法もあります。それぞれ上記の書籍の持ち込みと同様、なにかしらのチャネルがあるかと思います。ただしここでは詳細については述べません。
最後になりますが、参考までに現在のわたしのやりかたについて書いておきます。
- 1~4ページくらいの小ネタは無償公開する
- 4~20,30ページくらいの中規模のネタは雑誌記事、あるいは同人誌にする
- 大ネタは書籍にする。上述の小ネタ、中型ネタをまとめたり、一部抜粋したりするのもよい
- どれも自ら積極的に宣伝する(とくに同人誌)。出したからといって目に止まってはじめて売れるわけではない
- 読者の審判を仰いで*3、次に活かす
本記事が、「これから本を出したい」と思っているかたに役立つことを願っています。
時計をあまり見ない生活をはじめました
最近生活をしていくなかで時計をなるべく見ないようにすることにしました。理由は、もしかしたらこれで心に余裕が生まれるのでは、と思ったことです。とくに確たる根拠があるわけではなく思いつきではじめましたが、いまのところ前よりも気楽に生きている気がします。
この取り組みをしようとしたきっかけは、何気なく「今何時だっけ？」と時計を見た時でした。そのときは休日だったこともあって別になにかのタスクをいつまでに片付けなければならないというわけではなかったのに、です。
ここでふと、「自分は時計や時間に支配されていないだろうか」と思いました。さかのぼってみると自分には定期的に時計をチェックする癖があることがわかりました。それはもしかして頻繁にネットサーフィンやSNSのチェックをしてしまうという癖のように、場合によってはあまりよくないことなのではないかと思うようになりました。
そこで時計を出来る限り見ずに、何かしら次のことをしなければならないときにはアラームを使い、それが鳴るまでは時計で時間を確認せずに、気の向くままに気の向くことをすることにすることにしました。
上述のように、いまのところ前よりのんびり生活できていて気楽になったような気がします。とくに定性的になにかが変わったわけではないですが、こうしたことによって何か困るわけでもないので、今後もしばらく続けてみようと思います。
