give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

「レールに沿った人生はつまらない」と本気で考えていた元・若者が語る、現在の心境

はじめに:「レールに沿った人生」というキーワード

最近ネットで「当たり前のように大学に入って、大学を出たらすぐに就職するような、レールに沿った人生はつまらない」という若者の話題を見かけました。

そんな話題を見ていると「レールに沿った人生(※)はイヤ、か・・・そういえば僕も学生の頃はそんなことをよく考えていたなあ」とふと懐かしくなりました。

※注:ここでいう「レールに沿った人生」とは「いい大学に入って新卒で大企業に就職することを良しとするような人生」のことです。

バンド活動に明け暮れて就職活動しなかった大学時代

僕は大学時代、ほとんどバンド活動に明け暮れていました。
大学の講義は単位をもらって卒業するために、とりあえず出ていた、というような感じです。
講義の中には「へ~、面白い」と思うものもいくつかありましたが、だからといってその分野を深く研究してみようとは思いませんでした。


母親が教育ママだったこともあり、小さい頃から勉強は結構「できる方」でしたが、「じゃあ勉強していい大学に入ってそこからどうするの?」っていうと特になりたい職業もありませんでした。
高校時代からバンドを始めて、音楽にのめり込み、大学に入る頃には「このまま音楽を続けたい!プロになる!!」みたいな考え方になっていました。


当時の僕はそんな学生だったので、「大学を出たら就職?そんなレールに沿った人生、まっぴらごめんだ!!」と本気で考えていました。
しかし、教育ママである僕の母親としては「息子は大学に入った、だから次はいい会社に就職!これが母親としてのゴール!!」と鼻息を荒くしていた(と思う)ので、まあ母親とぶつかることぶつかること!
大学生活の終盤になってくると、


「淳一、そろそろ就職活動・・・」
「うるせー、おかんは黙っとけ!!俺は音楽を続けるんや!!」


みたいなケンカをしょっちゅうやってました。


ちなみに音楽をやるために大学を中退する、という考え方は全くありませんでした。
大学時代は十分時間があったので、学生を続けながらバンド活動をする、という生活に特に支障が無かったからです。


母親が就職活動、就職活動とうるさいので、学生時代に一回だけ就職活動なるものをやったことがあります。
で、神戸にある中小企業から内定をもらったのですが、最終的には内定を辞退しました。
なぜなら、大学時代にバイトをしていた塾の塾長から「大学出てからもうちで働けば?」と言われ、「じゃあ塾講師を続けながらバンドをやればいいや」と思ったからです。


というわけで、僕は「レールに沿った人生を生きてほしい」という母親の意向を蹴飛ばし、晴れてレールから外れた人生を歩み出すことになりました。
大学卒業後、僕は「塾講師のバイトをしながらプロを目指すバンドマン」になったわけです。

音楽活動も頓挫、塾講師のバイトもクビ → 仕方なく就職活動

が、「プロを目指してバンドを続ける」という生活は1年も経たないうちに頓挫しました。
僕がやっていたバンドは「(表向きには)音楽性の違い」「(実際のところは)人間関係のゴタゴタ」により、解散してしまったのです。


それからしばらく、ソロで音楽活動をしたりもしましたが、今度はバイト先の塾長との人間関係のゴタゴタにより、塾のバイトまでクビになってしまいました。
いやあ、人間関係って難しい。


音楽活動はなかなか思い通りにいかない、塾講師のバイトもクビになった、どうする俺??


という状態で僕が選んだのは、(あれだけ忌み嫌っていた)就職でした。


教えることは結構好きだったので、「学校の先生になる」という選択肢も考えたのですが、教員免許を取るためにもう一度大学に入り直さなくてはならず、あまりにも遠回り過ぎるということで断念しました。


はっきり言って、スーツを着て就職活動することには非常に抵抗があったし、できることならサラリーマンなんてなりたくない、と思っていたのですが、その頃は学生時代のような「俺は音楽を続けるんや!!」という気持ちの勢いもなかったので、「まあ・・・就職でもするか・・・」と諦めの気持ちで就職活動をしました。

消去法で選んだプログラマという仕事

僕は大阪にある中規模のSIer(ソフトウェア開発会社)のプログラマとして中途採用されました。
プログラマの仕事を選んだのはハッキリ言って「消去法」です。


「土日に出勤するような仕事はイヤ」「人と話すのは嫌いだから営業なんてムリ」みたいな理由で選択肢を消していき、「んー、パソコンやインターネットは昔から好きだし、バンドのホームページとかも自分で作ってたから、コンピュータ関連の仕事でもするか・・・」という理由で、その会社の採用試験を受けました。


採用試験に受かったのはちょっとラッキーで、どうやら僕が卒業した大学のOBがたまたまその会社にたくさんいたので、ひいきしてもらえたみたいです。(と採用面接で言われた)

「やりたいことと向いていることは違う」

その会社から内定をもらったときも実は学校の先生になるか、就職するか迷っていたのですが、面接でその会社の常務の人から、


「やりたいことと向いていることは違うんだよ。キミはこの仕事に向いている」
「プログラマはいいぞ。プログラマになれば手に職が付く」


と言われ、「じゃあ、一回やってみるか」とその会社に就職することにしました。


特に「やりたいことと向いていることは違う」という言葉はすごく印象的(ただし、「向いている」の根拠は不明)で、今でもすごく頭に残っています。


まあ、その会社はすごいブラックな会社だったんですけどね。


ブラックはブラックだったんですが、プログラミング未経験の僕を中途採用してくれたし、プロジェクトによってはとても刺激的で「プログラミングって面白い!!」と、この仕事にのめり込むきっかけを作ってくれたので、その点には感謝しています。
(もう一回戻ってこい、と言われたら全力で拒否しますけど)

「レールに沿った人生」も思っていたほど悪くない

そんなわけで、僕は一回レールから外れ、数年後にまたそのレールに戻ってきました。
でもまあ、実際にサラリーマンとして働いてみると思っていたほど悪くないものでした。
少なくとも「レールに沿って働くやつは全員バカだ!!」と憎むほどのひどい環境ではありません。
(最初入った会社はブラックだったけど)


特に僕はプログラマという技術職で、「勉強すればするほどスキルが伸び、社内外の評価が上がり、転職しやすくなる」という点は、「勉強はできる方」だった僕に向いていたと思います。


その後、妻と結婚し、子どもが生まれ、「子どもを自然の中で育てたい」という理由から妻の実家がある田舎(兵庫県西脇市)に引っ越し、西脇にある(正確には「あった」)外資系の半導体企業の社内プログラマに転職しました。


転職してからは残業が減り、休日出勤もなくなり、反対に給料が増え、田舎に大きな家も建て、マイカーを購入し、まあまあ悪くない暮らしができるようになりました。


学生時代には自分が結婚して、子どもを育てて、家やクルマを買うなんてことは全く想像もしなかったんですが、10年もしないうちに、ふと気づくとなんか絵に描いたような「幸せな家庭」を築いていました。


本当にビックリです。(今でもあまり実感がないかも)
学生時代にあれだけ忌み嫌ってたサラリーマンですけどね。
レールに沿ったような人生ですけどね。
でもこんな人生も悪くないです。

レールからちょっと外れた(?)現在

それから今度は東京にあるソニックガーデンという会社に転職しました。
今は自宅からリモートで働いています。
通勤時間はゼロになりました。


副業で電子書籍の翻訳をやったり、技術雑誌の原稿を書いたりして、お小遣いを稼いだりすることもできています。


ネットでブログを書いたり、Qiitaに技術記事を書いたりしているうちに、Ruby界隈ではそこそこ顔を知られる存在になってきました。
ずっと田舎で暮らしてるんですけどね。


このへんは世間でいう「レール」からはちょっと外れている気もします。
(単に「ちょっと珍しい」というだけですが)

一度もレールに沿っていないのにお金を稼げている妻

ちなみに妻は自宅の敷地内で小さなパン屋をやっています。
営業しているのは毎週金曜と土曜だけという、変わったパン屋ですが、おかげさまで毎日売り切れています。


妻は大学を出ていません。就職もしていません。
(ついでに言うと学力もそれほど高いわけではない・・・)
パン屋をやっていますが、専門学校に入ったり、よそのパン屋で修業したりせず、完全に独学でやっています。
もともとパン屋をするつもりもなかったのですが、趣味が高じて店を持つことになりました。


彼女もレールに沿った人生は歩んでいませんが、いつのまにか自分でお金を稼げるようになっていました。

僕や妻はうまくいった、だが。

長々と書いてきましたが、結論として僕や妻の場合はレールから外れてもなんとかうまくやっています。今のところは。


だからといって、全員が全員うまくいくと思っていません。


レールから外れてしまい、そのまま転落していくような人生もあると思います。
最初からレールに沿った人生を歩み、幸せになる人もいると思います。
レールに沿った人生なんて歩むんじゃなかった、と嘆いている人もいると思います。


人生なんて可能性やリスクのかたまりです。
運によって人生が大きく変わることは多々あります。
100%成功するレールも、100%失敗するレールもどちらもありません。
その人は、たまたまうまくいくか、たまたま失敗するか、そのどちらかです。


僕自身も過去を振り返ると「あのときは本当にラッキーだった」と思う瞬間がたくさんあります。(アンラッキーだった瞬間も多いけど)
自分の実力だけで今の自分があるとは全く思っていません。

運と努力と勇気

とはいえ、運以外の要素もあります。
それは努力と勇気です。
運はコントロールできませんが、努力と勇気は自分でコントロールできます。


僕も妻もプログラミングの勉強やパン作りで努力してきました。(努力と言えど、半分は趣味ですが)
また、転職するときや店を開くときには「失敗するかもしれない」という恐怖心を抑えて勇気を出しました。


努力は100%報われるとは限りません。
僕は音楽で必死に努力しましたが、音楽の努力は報われませんでした。


ですが、努力をしないと成功の確率を上げることはできません。
努力をせずに運が巡ってくるのを待つだけだと、成功する確率は限りなく低くなるでしょう。


これらの内容をまとめると、


「一生懸命努力して成功する確率を上げろ」
「チャンスがやってきたら勇気を出して新しいことにチャレンジしろ」
「最後に、運が良ければ成功する(悪ければ失敗する)」


というのが成功する(かもしれない)人生の秘訣なんじゃないかな~と自分では思っています。

失敗ではなく「Lesson&Learn」

失敗についてもひとこと言っておくと、失敗も100%役に立たない失敗、デメリットしかない失敗は滅多にないと思っています。


僕は失敗を失敗と呼ばずに「Lesson&Learn」と呼ぶようにしています。
つまり、「失敗という経験から新しいことを学んだ」とプラスに考えるのです。


成功する経験だけでなく、「なるほど、こうやってもうまくいかないのか」という失敗する経験を積むことも、人生におけるひとつの勉強です。


自分や家族の命を落とすような失敗さえしなければ、「失敗したけど、勉強になった。次はうまくやる!」と考えることができます。
(僕もうまくいかなかった音楽活動や、塾講師時代に体験した人間関係のゴタゴタでいろいろ学びました・・・)

まとめ:「レールに沿った人生」がいいか悪いかは、あなた次第

まあそんなわけで、「レールに沿った人生はつまらない」と考えていた「元若者」の現在の心境をあれこれ書いてみました。
僕の場合は一回外れたけど、なんかうまく戻ってこれたし、レールに沿ってるのか外れてるのかわからない現在の状況も別に悪くないぞ、っていう感じです。


でも何度も言うとおり、僕がうまくいったからといって、他の人もうまくいくという保証は一切ありません。
これはあくまで「こういう人生を送った人もいる」という単なる一例です。
「レールに沿った人生はイヤだ」と思い悩む「現若者」は、自分で自分の人生をどうするのか、どうしたいのか、じっくり考えてみてください。

あわせて読みたい

とりあえず勉強はやっててよかったな、と思います。僕の場合は。

人間関係でよくゴタゴタする人は「人を動かす」を読むといいです。

今思えばもう少し自分の父親が仕事は楽しいぞ、って言ってくれれば、あそこまで就職を嫌がったりしなかったかも?まあ、今さらいいんですけどね。

なぜ田舎に移住したのか、という話を書いています。

妻が起業したときのエピソードをトークイベントで話したことがあります。

SIer時代はブラックでしたが、技術者としていろいろと学ばせてもらう機会は多かったです。

Qiitaに「サンプルコードでわかる!Ruby 2.4の新機能と変更点」という記事を書きました

お知らせ

Qiitaに「サンプルコードでわかる!Ruby 2.4の新機能と変更点」という記事を書きました。

サンプルコードでわかる!Ruby 2.4の新機能と変更点 - Qiita
f:id:JunichiIto:20160912050418p:plain

これは去年書いた「サンプルコードでわかる!Ruby 2.3の主な新機能」という記事のRuby 2.4バージョンです。

先日開催されたRubyKaigi 2016に参加したみなさんは、Ruby 2.4に関する話題もたくさん聞いたのかもしれませんが、僕は参加していなかったので一人でさみしく新機能を調査しておりました・・・。

もしかすると、RubyKaigiに参加した人だけが知っているマル秘情報があったりするんでしょうか??
記事の内容に関して間違っている部分や捕捉事項等があれば、Qiitaのコメントや編集リクエストで指摘してやってください。

Ruby 2.4のサンプルコード

記事内で使用したサンプルコードはこちらに置いてあります。

"ruby test/ruby_test.rb"でテストコードが実行できるようになっているので、みなさんもRuby 2.4をインストールして動かしてみてください。


以上、「サンプルコードでわかる!Ruby 2.4の新機能と変更点」というQiita記事に関するお知らせでした!

テストコードにまつわる5つのエトセトラ

はじめに

ひとつ前のエントリでRSpecの話を書いたので、それにちなんで最近僕の身の回りで起きたテストコードに関する雑多なエピソードをいくつか書いてみます。


その1:テストコードを書いてない処理で見事にバグを出してしまった・・・!!

僕はソニックガーデンの中では「テスト番長」の異名を持っていて、基本的にテストコードはしっかり書くタイプです。
ですが、どうしてもリリースを優先しなければいけないときは、やむを得ずテストコードを後回しにして先にリリースすることもあります。

先日リリースした「テストを後回しにしたコード」は、リリース直後は問題なく動いていました。
その数週間後、別の仕様変更が入り、変更したコードをリリースしました。
「テストは全部パスしているので大丈夫なはず~!」と思ったら、リリースの翌日に変なシステムエラーが発生。

エラーが起きている場所を見て、ガーン。
例の「テストを後回しにしたコード」でしっかりエラーが起きていました。
正常系のフィーチャスペックを書いておくだけで、確実に検知できたエラーです。
やっぱりテストはちゃんと書いておかないとダメだな、とセルフ反面教師になりました。

その2:JavaScriptのテストも書いておかないとRailsのアップグレードはしんどい

結構昔に作った社内向けのツールを先日Rails 5にアップグレードしました。
基本的にテストはしっかり書いていたのですが、ソニックガーデンに入社して間もない頃に作ったRailsアプリで、当時不慣れだったJavaScriptを実行するフィーチャスペック("js: true"を付けるスペック)はひとつも書いていませんでした。

そのため、JSを使った画面の動きはいちいち手作業で確認せねばならず、非常に手間がかかりました。
ちゃんと"js: true"のフィーチャスペックも書いておかなければいけませんね。

ちなみに、テストを全く書いていないRailsアプリだったらもっと悲惨なことになるのは言うまでもありません。

その3:すぐに終わるテストはRailsのアップグレードがラク

これまた先ほどのRails 5アップグレードのエピソードです。
社内向けツールは小規模なRailsアプリでテスト項目が少なく、全部のテストを実行しても20秒以内に終わります。
なので、アップグレードの作業中は頻繁にテストを再実行して、エラーや警告を潰していくことができました。

普段の開発ではここまでテストを再実行することはありませんが、「速いテストのありがたみ」をしみじみと感じました。

昔から開発し続けている大きなRailsアプリだと15分とか20分ぐらいかかるものもあるので、気軽に全部を再実行するのは厳しそうです。
こういう場合はRSpecのフィルタリング機能を使ったりして、頻繁に再実行するのは特定のspecだけに絞り込んだ方がいいかもしれません。

その4:テスト番長は社内でRSpecの質問に何でも答えてくれます

RSpecは僕の得意分野なので、社内で他のメンバーがテストの書き方で困っていたら気軽に質問や相談に答えるようにしています。

「伊藤さん、ここのテストコードがうまく動かないんだけど、一緒に見てくれる?」
「テストコードの共通化で悩んでるから相談に乗って~」

といった質問や相談があれば、だいたい数分で「はい、論破」・・・じゃなくて「はい、解決!」しています。

RSpecって、それなりに動きにクセがあるので、ハマってしまうときはとことんハマってしまうんですよね~。
まあ、僕も昔はよくハマってたんですが、かなりの経験値を積んだので、「こういうときはこう書く」「こういうエラーが出たら、たぶんこれが原因」というテンプレートがだいたい頭の中にできています。

Twitterとかを見ていると「RSpecがうまく書けない!思った通りに動かない!キィ~~ッ!!!」という悲鳴をよく見かけるので、「あ~、僕が見たらすぐに直るんだろうなあ。お手伝いしてあげたいな~」と思ったりします。

RSpec相談コンサルとかやったらいいお小遣い稼ぎになるかも?
1回500円でどうですか??(笑)

その5:雑に書けるときは雑に書くのが最近の趣向

これはRSpecの書き方の話です。
RSpecって結構「RSpecらしく書くこと」を求められたりします。
たとえば、describeやcontextでしっかりグループを分けましょう、再利用するデータはletやsubjectに切り出しましょう、ひとつのexample(it)の中でテストするのはひとつの項目だけにしましょう、等々の方針です。

典型的な例がBetter Specsを読め、Better Specsに書いてあるとおりにspecを書け!っていうパターンですね。

これはもちろんそれぞれに意味があってのことですし、かつては僕もそうあるべきだと思っていました。

しかし、最近は「そこまでがんばってキレイにしなくてもいいのでは?」と考えるようになってきています。
その結果、テストコードがだんだん雑になってきています。

具体例を挙げるとこんな感じです。
まず、RSpecらしく書いたバージョンはこれです。

describe Cloth do
  describe '#price_with_tax' do
    let(:cloth) { Cloth.new('RSpec Tシャツ', price) }
    subject { cloth.half_price }
    context '割り切れる場合' do
      let(:price) { 1000 }
      it { is_expected.to eq 500 }
    end
    context '割り切れる場合・その2' do
      let(:price) { 2000 }
      it { is_expected.to eq 1000 }
    end
    context '端数が出る場合' do
      let(:price) { 999 }
      it { is_expected.to eq 499 }
    end
  end
end

次に、雑に書いたバージョンがこちらです。

describe Cloth do
  describe '#half_price' do
    example do
      # 割り切れる場合
      cloth = Cloth.new('RSpec Tシャツ', 1000)
      expect(cloth.half_price).to eq 500

      # 割り切れる場合
      cloth.price = 2000
      expect(cloth.half_price).to eq 1000

      # 端数が出る場合
      cloth.price = 999
      expect(cloth.half_price).to eq 499
    end
  end
end

ポイントとしては、

  • describeやcontextのグループ分けは必要最小限にする
  • contextに相当するものはコメントで書く
  • ひとつのexampleの中で、まとめて複数のテストを書いてしまう
  • letやsubjectに切り出さず、ローカル変数にしたり、毎回同じようなコードをベタ書きしたりする
  • "it 'returns half price'"とか"it '半額の値を返す'"のような説明文を省略して、"example"だけで済ませる

みたいな感じです。

メリット・デメリットはいろいろありますが、メリットだけを挙げると、

  • 思いついたテストパターンを上から下へさくっと書ける
  • どれをletやsubjectにすべきか、どうcontextを分割すべきか、といった「テストコードの設計」に頭を使わなくて済む
  • 「意図した通りにコードが動いていることを検証できる」という点では、RSpecらしいテストコードと変わりがない

みたいになるかな、と思います。

あと、RSpecらしいコードを追求して「RSpec、かくあるべき」を全面に出してしまうと、初心者の人たちに「RSpec怖い」「RSpec難しい」「RSpecわけわからん」という恐怖心を植え付けてしまわないかな~という懸念も感じたりします。

もちろん、RSpecらしいコードを完全に放棄したわけではありません。
テストコードの内容によってはRSpecらしく書いた方が、読み書きがしやすかったり、保守性が高かったりするケースもあります。
そういう場合はRSpecらしいコードを書くようにしています。

「よくわかんないけど、これが巷で言う守破離の「離」ってやつ?」なんて自分では考えたりしています。(間違ってたらすいません)

2016.9.5 追記

Qiitaに「雑なRSpec」の記事をもう少し詳しく書きました。
よかったらこちらもどうぞ。


まとめ

というわけで、テストコードに関する最近の雑多なエピソードを書いてみました。
まとめると、「テストコードって大事!テストコードって楽しい!」ということですね。

・・・えっ、全然違う?
いや、「テストコードって大事!テストコードって楽しい!」っていう思いは昔から変わってないので、そういうことにしておいてください。

ではではこのへんで!

PR:RSpecの電子書籍を販売しています

僕が翻訳した「Everyday Rails - RSpecによるRailsテスト入門」という技術書を電子書籍で販売しています。
RSpec初心者の方でも十分わかりやすい内容になっているので、まだ読んでない方はぜひ読んでみてください!

Everyday Rails - RSpecによるRailsテスト入門
f:id:JunichiIto:20160424081240p:plain