人を真似るときに気を付けていること

凄い人、尊敬する人などの真似をしたくなることがあります。IT技術に関係ないところでいうと、ちょっとした仕草や服装、髪型、などなどです。本記事では仕事のやりかたを改善するために私が現在やっていることを書いておきます。

現在わたしの身近には要領がよくて作業効率が高い、かつ、強烈に頭が切れるという人がいます。わたしはこの人に学ぶことが多いので真似をしているのですが、真似ようとしていることは前者だけです。なぜなら要領の良さというのは「全体を俯瞰する」、それをもとに「ゴールにつながるものだけをやる、それ以外はやらない」「優先順位をつける」など、ある程度は訓練によってなんとかなりそうなものという思いがあるからです。これに対してキレッキレの頭脳というのは生まれ持ったものであって、かつ、訓練に変えられるようなものではないと思っているので真似しません。

この考え方については別記事にも書きました。

satoru-takeuchi.hatenablog.com

第二に、身心の作りが違う他人と同じ土俵で勝負しようとするのをやめました。たとえば一日4時間睡眠で平気といったようなショートスリーパー、業務でのプログラミングに疲れたら趣味プログラミングで疲労を回復させるアンデッドモンスターのような人がいるのも否定しませんが、自分ではどうなるかを試してみたところ、残念ながら自分はそうはいかないという認識をしました。その結果、無理なものは無理、自分のハードスペックに合ったことをするのが一番、と思えるようになりました。

こういうことが思えるようにならないと「自分はどうしてできないんだ」「一向に改善しない」と疲弊することになります。かくいう私も過去には疲弊していました。

ここまで述べたことは本記事の読者からするとソフトウェア、あるいはアルゴリズムの改善はできるけれどもハードスペックは変えようがない、という例えをするとしっくりくるかもしれません。いずれにしても、できる人のことを闇雲に全部真似ようとするのではなく、まずは「この人はどこがすごいのか」というのを洗い出した後にわが身を振り返って、これなら真似できそうというものを見つけて楽そうなものから真似すればいいのではないかと思います。

「モモ」を読んだ

少年文庫の本だけれども刺さるのは少年ではなく大人ではないかと思います。大変面白かったです。なかなかお目にかかれない、自分の考え方を変える本の一つでした。

本の内容を具体的に紹介するのはやめておきますが、いつも「時間がない、時間がない」とイライラしながら効率を求めて忙しくしている人に読んでほしい本です。何か思うところがあるのではないでしょうか。わたしはこれを見て「もう少し丁寧に生きよう」、「仕事以外で効率を求めるのは控えよう」と思うようになりました。

休みの日は休めばいい

私は休むのが苦手で、オーバーワークになりがちです。最初はとくにそういうことはなかったのですが、今になって振り返ってみると、10代後半から次第に休み方を忘れていったのだと思います。その後何年も試行錯誤を重ねて、ここ最近ようやく自分なりの新しい休み方ができてきました。本記事ではここに至るまでの話を簡単に共有します。

まずはどうやって休み方を忘れたかについてです。だいたい次のような流れだったと記憶しています。

  1. 10代後半でコンピュータに出会ったことによって興味の持てる対象が激増した
  2. コンピュータについての知識を得るために毎日昼夜を問わずに作業していた
  3. 休憩という概念がなく、寝る(気絶する)まで作業して、起きたらまた作業という状態になった。若くて体力があったので死ななかった
  4. 生活のリズムが乱れて疲労が蓄積していった。が、茹で蛙のごとく、本人は気づかない
  5. いつしか疲れているのが当たり前になってきた。どういう状態が元気なのかがわからなくなったし、そもそも休んでいないので休みかたを忘れた。これも本人は気づいていない
  6. 若くなくなって体力がなくなってきたのでつらくなってきた

step4とstep5あたりでは、当初は興味をもって楽しくやっていたものが段々やらなければという義務感にとらわれてやっている割合が高くなっていったようになっていたように思います。「だったらやめればいいのに」と思うかもしれませんが、変化は徐々に出てくるので上述の通り本人は気づかないのです。

今の世の中ではSNSなどで否が応でも自分と他人を比較してしまう機会があるので、「自分はまだまだ努力が足りない」「自分が休んでいる間にも他の人は先に進んでしまうのでは」「あの凄い人は一日中何かやってるっぽい」などという考えに陥りがちです。実際若者のtwitterを見ているとそういう考えにとらわれている人をかなり見かけます。

ここからは私がどうやって休み方を再び会得したのかについて書きます。上記のような、いかにもバッドエンド一直線のようなルートに自分も乗っているなと思う人は参考にしてください。

第一に、パフォーマンスを上げるためには休む必要があるということを体で覚えました。具体的には、自分の成長がどうのとかはすべて忘れて、しばらく何もせずにひたすら負荷を下げて、休みの日は眠り続けました。すると、これまでは何だったのかというくらい元気になり、毎日この状態を維持できる程度に作業するのが効率的ということが認識できて、無理をすることが減りました。

第二に、身心の作りが違う他人と同じ土俵で勝負しようとするのをやめました。たとえば一日4時間睡眠で平気といったようなショートスリーパー、業務でのプログラミングに疲れたら趣味プログラミングで疲労を回復させるアンデッドモンスターのような人がいるのも否定しませんが、自分ではどうなるかを試してみたところ、残念ながら自分はそうはいかないという認識をしました。その結果、無理なものは無理、自分のハードスペックに合ったことをするのが一番、と思えるようになりました。ここで重要なのは、どういう状態なら自分は元気か、パフォーマンスが出せるか、という感覚を取り戻して初めてこの取り組みが可能になったということです。

第三に、仕事を含めた疲れる時間(オン)と休み時間(オフ)を明確に分けるようにしました。わたしは目の前にPCないしスマホがあるとついつい触ってしまい、かつ、そうなると何をやっていようと疲れることがわかったので、休憩時にはこれらのデバイスは別の部屋に置くようにしました。寝室にもそれらを持ち込まないようにしました。趣味もこの手のデバイスが手元になくてもできるものを探して作りました。この施策は他の施策と並行してやっていたのですが、何をすれば自分は疲れるのかという感覚を取り戻してからのほうがより納得感が得られるとともに、効果も上がりました。

ここまでが大体できたというのが現在の状況です。なお、上記のようなことはいきなり全部できたわけではなく、休み方を忘れたときと同じく徐々にできるようになりました。しばらく続けた後にふと思ったのが「あ、休みの日は休めばいいんだ」「なるほど、休憩時間には休憩するといいのか」ということです。自分で書いていてアホだなあと思うのですが、当時、本当にそう思ったのです。

書くべきことはだいたい書いたのですが、最後に一つ。「いくら休んでもまるで疲れが取れない」「そもそも眠れやしない」というような場合は医師に相談するのがいいと思います。これは別に冗談ではなくて、わたしのこれまで出会った人の中では上記のバッドルートのさらに先に進んだ結果、再起不能になった人や命を絶った人も少なからずいます。成長しようと頑張った挙句に身心を壊しては元も子もないので健康第一でいきましょう。

「概説 中国史」を読んだ

これまで中国の各時代の歴史についての本をいくつかばらばらに読んできたのですが、その後に、これらが現在の中国にどのようにつながっているのかを知りたくなって買ったのがこの本です。教科書的に淡々とその時々に起きたことを述べていくスタイルなのですが、退屈になることはまったくなく、すらすらと読めました。数十冊にわたるごっついシリーズではなく高々数百ページずつの上下巻というのが飽きっぽいわたしに丁度よかったです。これからまた各時代について深堀りした本を読む気にさせてくれました。そのときもこの本をまた参照することになるでしょう。

「米の日本史」を読んだ

日本の歴史を日本人とは切っても切り離せない米と言う観点から見た本です。米と日本の関係については「縄文時代から弥生時代に伝わってきて云々」程度の歴史の教科書で学んだ知識しかない私にはいままで想像すらしていなかった多くの知識が得られました。たいへんよい本でした。たとえば稲作伝来については、今日本で主に食べられている品種以外のものを含めた様々な種類の稲がいつどこから伝わってきたのか、その後でどういう理由で現在に至ったのかを、そう考えるに至った理由を含めて丁寧に書かれていました。その他のトピックについても非常に興味深い内容ばかりで、一気に読み切ってしまいました。

趣味でプログラミングをはじめようとするときの様々な誘惑

趣味でプログラミングをはじめようとする人が陥りがちな罠と、それについてのわたしの考え方について書きます。一部については私が実際にひっかかった罠で、それ以外は自分以外の人を見ていて思ったことです。仕事だと話は変わってくるのですが、それについては触れません。

情報量が多い昨今、「さあプログラミングをはじめよう」となっても、目の前には次のような様々な選択肢が待ち受けています。

初心者はこれらのうちのどれを選ぶべきかというところでまず躓いて、まったく先に進めなくなることが多々あります。ただ、このへんは使ってみなければわからない好みの部分が非常に多いので、まずはフィーリングで適当に選んで、合わないものがあれば別のものに乗り換えればいいと思います。なんなら複数を使い分けてもいいんです。

迷いで頭がいっぱいになってしまったら、自分のやりたいことはプログラミングをはじめたいことであってツールを選びたいわけではない、とにかく手を動かしてプログラミングしないと何も始まらない、ということを思い出してもらいたいと思います*1

参考までに、たとえばわたしは次のような流れで使うツールを選んできました。

  • プログラミング言語: なんとなくCがかっこよさそうという理由ではじめて、そのままOSカーネル屋さんになったので使い続ける。日々の作業を楽にするためにbashやらRubyやらを覚えた。Pythonは流行ってたので使ってみようと思ったが音楽性の違いを感じて大して使わないまま、現在は「そこそこ読めるけどあんまり書けない」という状態になっている。あとは仕事でGoを使うようになって、かつ、気に入ったので今も愛用している。
  • OS: 最初はWIndowsを使っていたが、Linuxインストールブームの火が残っていた大学4年生のころに「なんとなくかっこよさそう」「すごそう」という理由で使い始めた。いろいろなツールが無償で手に入って便利だったので、そのまま今に至る。WindowsmacOS上での開発については、やる必要を特に感じていないのでやっていないだけ
  • テキストエディタ: Linuxに入門したころ、当時流行っていたemacsvimの2つのうちのどちらかを選ぼうと根拠の無い決意をして、2つ評価をして上で、より気に入ったemacsを使うようになった。その一方で、vimもrootで作業するときなどに使っている。その後15年ほど経過した去年、.emacsの編集に疲れていたころに「俺は別にエディタの設定をしたいわけでもelispを愛しているわけではないなあ」と気づき、かつ、VSCodeが複雑な設定をしなくてもよくて楽らしいと聞いた。使ってみたら実際その通りだったので、emacsを完全引退して今も使い続けている。

この考え方に異論がある人はいくらでもいるでしょうが、これは「私の意見」なので、とやかく言われる筋合いはありません。みなさんも最初はフィーリング、その後は人の意見を参考にしつつも、あくまで自分の感性を信じて心地よいものに次第に移っていけばいいと思います。

これ以外にも「プログラミングするからには開発を支援するツールをマスターしなければ」と、必死に次のようなものの網羅的な知識を得ようとして疲弊している人をよく見ます。

これらについても、こだわり出すといつまでたってもプログラミングをはじめられないので、まずは小さなプログラムをたくさん書みることをおすすめします。その後に実際に困ったときに使い始めて、かつ、必要なところだけを徐々に覚えていくとよいでしょう。

とくにgitは機能が異常に豊富で、マスターしようなんて思うとかなりキツいですし、そんなことをする必要もありません。実際わたしもgitのコマンドで知っているのはおそらく20個ほどだけですし、それらのオプションについても知らないもののほうが多いです。

上記のツールが必要になるタイミングは典型的には次のようなときでしょう。

  • gitなどのバージョン管理システム: ソースコードのどこをどんなふうに変更したかがわからなくなったとき、安定版と開発版を分けたくなった時、複数人で開発をするとき*2
  • CircleCIなどのCIツール: マージ前、リリース前の手動テストが苦痛になったとき
  • Redmineなどのバグ管理システム: 複数人で開発するようになったとき。脳内で問題を覚えておくのが苦痛になったとき

いろいろ書きましたが、最後にまとめ。枝葉末節にこだわらず、本来やりたいことをするのを最優先に考えましょう。たのしくプログラミングしましょう!

*1:その後ツールにのめりこんで楽しくなった、というのであればそれはそれでいいです

*2:おそらくgitはこのリストの中で一番早く使い始めることになるでしょう。すぐないとやってらくなると思います

重要そうだけど興味のないことを頑張っても大していいことなかった話

時間は有限です。その合間を縫ってひねり出した可処分時間は貴重です。こういう時間は自分が楽しいと思えることにとことんつぎ込めばいいと今では思っているのですが、そうではなかった時の失敗談を紹介します。読者のみなさまの中で、好きなこと、やらなきゃいけないことしかできないという私のようなタイプの人には刺さるかもしれないです。

10年近く前の、まだわたしが若手というカテゴリに入っていたとき、当時ずっと生業にしていたLinuxカーネル以外にも、将来のために何かもう一つ引き出しの数を広げておかないといけないと思っていたことがありました。そういうときに飛びつきがちなのは流行りものです。当時のわたしにはそれがARMサーバでした。当時は何やらやらないと取り残されるのではという空気が身辺にありましたし、カーネル屋さんなのでハードウェアに近いところの知識はあればあるだけ損ではないという思いもありました。

ところがこれが大失敗。本を読んだりラズパイを買ったりしてみたものの大して熱がこもらず大した知見が得られないままに時間を浪費するというありさまでした。ここで何がまずかったのかを振り返ってみたところ、一番の原因は「ARM,もっというとCPUのアーキテクチャに大して興味がない」ことと、「好きなこと、やらないといけないことしかできない」という自分の特性の強さをあなどっていたということでした。気づいてしまえは当たり前で、やる前に気付けよといったところですが、当時は焦りからか非常に視野が狭くなっていたのでしょう。

この後は考え方を変えて、次のようにバッサリと割り切りました。

  • 今持っている技術が陳腐化しそうになったら、その時はその時、追い詰められたら奮起する能力は持っているのでなんとかなるだろう
  • 一番興味があるものから順番に学んでいれば将来それらに活路が見いだせるかもしれない
  • 無理して頑張っても、楽しく学んでいる人にはどのみちかなわない

この変心が正解というつもりはまったくないですが、将来の来るかどうかわからない危機に対して確実でもなんでもない備えを苦痛に耐えながらやり続けるよりも、楽しいと思えることを効率よく学べている今のほうが幸せだとは思います。

この文書がわたしと似た特性を持つ人に参考になれば幸いです。おわり。