初めまして。松浦です。
これは TECHSCORE Advent Calendar 2015 の4日目の記事です。
タイトルにもありますように、配属から半年が経過した新卒の文系出身エンジニアですが、周囲からの推奨もあり、 TECHSCORE BLOG への記事の投稿を決意しました。
今回は、この半年での手痛い“失敗”のケースを3つ取り上げて、
- どのような失敗をしたのか
- どんな損をしてしまったのか
- どのような対策が上手くいったか
という、3段の構成（＋まとめ）で話を展開していきます。
必ずしも技術に直接関連する失敗ばかりというわけではありませんが、私の失敗ケースやその失敗に対する対策について書くことによって、特に新卒として入社していく人にとって有益な話になればと思います。
失敗1：「もっと早く質問すればよかった」
どのような失敗をしたのか
例えば、
- 忙しいのではないか、と思って先輩に質問するのをためらってしまった。
（そして実際に先輩が忙しくなるというマーフィーの法則的な展開も） - 一度質問したが、改めて取り組むとよく分からない。しかし、同じことを質問するのは気が引ける。
- そもそも、何が分かっていないのかも明瞭としてないので、どう質問していいか分からない。
などといった状況で、なかなか質問できず、作業が進まない、ということがありました。
その結果、ようやく先輩に質問して、「もっと早く質問すればよかった」と思うわけです。
このような失敗は、私がこの半年でもっともよく行ってしまったものです。
おそらく、新卒社員の方の多くが、先輩に質問できずに困ったことがあるのではないでしょうか。
どんな損をしてしまったのか
質問できなかったことによる損はいくつかあると思いますが、
私の場合だと何と言っても時間の浪費が挙げられます。
特に最初のころ（配属後1~2ヶ月くらい）は、上述のような状態に陥ることが多かったです。
週に少なくても数十分~数時間のロスが発生したのではないかと考えられます。
月単位でそのロスを計上すると、実に数十時間のロスにもなるかもしれません。
「その時間をうまく使えれば、もっと技術を学べただろうに」ともったいなく思えます。
また、質問することがうまくできないと、心理的にも大きな負担になります。
「新卒でうまくいかないパターンとして多いのが、質問ができなかった結果、一人で抱え込んでしまって、挫折することだ」というのは私のメンターの言です。
さすがにそこまでにはならなかったものの、質問に躊躇して悶々とする時間は、非常に居心地が悪いです。
どのような対策が上手くいったか
「もっと早く質問すればよかった」
このような事態を招かないために行った対策の中で、効果が感じられたものを挙げてみます。
- 期限を設ける
タスクに取り掛かる際に、きっちり期限を決めておき、
「ここまでにこれができておかなければ相談する」
と細かく決めておくと、質問はしやすくなりました。期限があると、人は動きやすいようです。
（このことは、後ほど詳しく取り上げています） - 複数の質問先を作る
質問する相手が隣の先輩だけ、という状況は、経験上マイナスになることもありました。
すぐ隣では、忙しそうにしていたり、考え事をしていたりする姿がよく見えます。
相手に慣れていない最初のころは特に話しかけづらいことが少なくなからずありました。そもそも質問する相手が1人だけというのは、あまり効率がよくありません。
その人が本当に忙しかったりするとすぐに回答はもらえません。
その人が必ずしも答えを持っているとも限りません。ですので、分からないことができたときに、質問できる人を複数持つことはメリットがあります。
私も、幾人かに気軽に質問できるようになると、業務をするのにも気が楽になりました。
（作業の内容などにより、他の人に作業の質問をしにくいという状況はありますが、それでも質問や疑問を話せる相手が複数いると、心情的に余裕が生まれます）
まとめ
すぐに質問することは、自分で考えなくなるのでよろしくないという論もあります。
その考え方には、確かに一理あると思います。
しかし、新卒で知識が足りていない場合は特に、
調べたらさらに新たに分からないことが発生する、ということが起こりがちではないかと考えています。
さっさと見切りを付けて質問する方が得られるものは多かった、というのが私の半年の感想です。
失敗2：「なぜそうなるのか」が分かっていない
どのような失敗をしたのか
「なぜそうなるのか」についての意識・理解が欠如していた結果、失敗をしてしまったという話です。
少し前に、こんなミスをしました。
（以下、Ruby on Rails のコードです）
|
1 2 3 |
Customer.order(:name).find_each do |customer| # 処理の内容 end |
実際のコードは、もっとメソッドがチェーンされていてややこしいものなのですが、要するに、「Rails の find_each メソッドに、ソート条件の指定を入れていた」というミスです。
find_each は、分割してレコードを取得し、処理を行うメソッドで、大量データを扱うときに便利です。
しかし、制約事項として、ソート条件を指定できません。
分割して取得する際、シークエンスな id でソートを行うためです。
こうすることで、例えば、 find_each の処理中に新たなレコードが登録されても、ソートされたレコードの最後に挿入されるため、処理の重複・欠落が発生しないようになっています。
...と、このような原理であることを十分に理解できていたならば、上記のミスはしなかっただろうと思われます。
（実は、 find_each については、過去に丁寧な説明を受けていたので、なおさら痛恨の出来事でした）
どんな損をしてしまったのか
上記のミスは、幸いなことにそもそもソート条件の指定がなく、実際の損にはつながりませんでした。
とはいえ、損が発生しなかったというのは、たまたまに過ぎません。
「なぜそうなるのか」ということを意識も理解もせずに使っていると、どこかで落とし穴にはまる。
損をしなかったとはいえ、この失敗を通じて、そのような教訓を痛感することになりました。
なかなか手痛い教えだったので、今回記述することにした次第です。
どのような対策が上手くいったか
ここでは、
「きちんと理解しているかどうかを確かめる」
「より本質的な部分を理解できるようにする」
ということに対して、私が取っている対策を取り上げます。
- 文章にして説明してみる
「頭では理解できているつもりでも、言葉が出てこない」
ということは、経験したことがある人が多いと思います。
文章にするとなると、できない人はもっと多いのではないでしょうか。私にしても、この記事を書くに際して、頭の中では、
- どのような失敗をしたのか
- どんな損をしてしまったのか
- どのような対策が上手くいったか
を整理できているように思っていましたが、文章にしてみると、どうにも上手くいかない。
改めて頭の中の情報を言葉にして整理してはじめて、文章が生み出せました。自身の思考を整理するうえでも、この方法は非常に有効だと思われます。
- 原典にあたる
「なぜこのような挙動をするのか」
を理解するには、原典たるソースコードに当たるのが一番の近道です。ソースコードを読むのは、その言語についてある程度の理解がなければきつい作業です。
（最初のころは、本当に読めるようになるのだろうかと何度も疑いました）しかし、ある程度理解できるようになったなら、ソースコードを都度読んでみることは、挙動が直截的に分かったり、新しくオプションを発見したりと理解度が格段に高まるという効果があります。
（他にも、そこで書かれている技法の勉強にもなるなどの効果があります）先の find_each の例で言うと、実際のソースには、
1234# NOTE: It's not possible to set the order. That is automatically set to# ascending on the primary key ("id ASC") to make the batch ordering# work. This also means that this method only works with integer-based# primary keys.と、コメントで「ソート条件を設定できない」と注意書きがあるというのが分かったりします。
（ integer の primary key がないとそもそも使えないとも書いています）
英語も平易ですし、あらかじめ読む機会を作っておけばミスしなかったな、と少し後悔しました。また、 find_each のコードを読むと、ブロックを渡された場合には、
123find_in_batches(options) do |records|records.each { |record| yield record }endと、 find_in_batches というメソッドが呼び出されており、
具体的な処理やオプションの対応はそちらで行っていることが分かります。オプションとしては、batch_size オプションで、一度に取り出す件数が指定できたり、start オプションで、最初に取り出すレコードの id を指定できたりすることが見受けられます。
（start オプションは使ったことがなかったので知りませんでした）実際のソースコードを見てみると、「そうなっていたのか！」と驚くことがよくあります。
より本質的な部分を理解する上では、原典にあたることは非常に重要だと思います。
まとめ
タスクがたまっていたり、時間に制約があったりすると、「こうすれば意図した挙動が実現する」などの表面的なことにとらわれがちでした。
そういう状況では、「なぜそうなるのか」「どうやってその挙動を実現しているのか」というより本質的なことに対する問いかけは、しばしば見落としがちになってしまいます。
しかしながら、そういった、より本質的なことが抜け落ちると、時として手痛い失敗として返ってくるということがここで得た教訓です。
失敗3：「後でやろう」は結局やらない
どのような失敗をしたのか
例えば、こんな失敗をしました。
週末の金曜日。就業時間も終わり、明日は休日。
「業務で少し調べておきたいこともあるし、休みの時間を使ってやろう」そう考えて迎えた休日。
「いや、待てよ。部屋の掃除をしてないと。知り合いと会う約束もしていたぞ。それから…」
次々と現れる、やりたいこと。ついつい調べものを後回しにして、そちらに時間を使ってしまう。そしてその夜。
「まあいい、調べものは明日にしよう」
言わずもがな、明日もまた同じような思考に至り、結局やらないわけです。
どんな損をしてしまったのか
このような感じで、ついついやるべきこと・やっておいた方が良いことを後回しにして、結局やらなかったり、後で冷や汗をかいて対処することになったり、という失敗をよくしてきました。
勉強用に購入した本が積ん読状態になっていたり、気付いたら資格試験の応募期限が過ぎていたり。
このブログ記事の執筆についても、なかなか手が付けられず、結局苦労をすることになりました。
「先延ばしにせずやっておけば、今頃もっと技術が伸ばせていただろうに」
振り返ってみると、そう思わずにはいられません。
どのような対策が上手くいったか
そもそも、どうして先延ばしにしてしまい、うまく行かないのでしょう。
人間には、長期的な目標達成より、目先の利益や欲求に惹かれがちになる傾向があるそうです。
行動経済学では、「現在（志向）バイアス」と呼ぶそうです。
将来のためにやっておくべきと思うことよりも、目先のしたいことをしてしまいがちだということですね。
（ブログ記事を書くよりゲームをすることを選択しがちという感じです）
犯しがちなこの失敗の根底には、少なくとも人間のこの傾向があるようです。
この傾向に対処するために行った中で、効果があったように思われる方法を挙げてみます。
- 締め切りを設定する
人間、締め切りが近づくと、重い腰がようやく上がるようになります。
過去に行われた実験で、3つのクラスに3本のレポートを書かせてみた際、
- Aクラス：「最終日に3本のレポートをすべて提出する」
- Bクラス：「自分たちでそれぞれ締め切り日を作る」
- Cクラス：「1週間に1本ずつ提出する」
とした場合、もっとも良い成績を上げたのはCクラスだった、というものがあります。
適切な期限の締め切りを誰かと合意している場合が、最も取り組みやすいということのようです。
（実体験として、このブログも、締め切りが近づくにつれ、タイピングの速度が上がりました） - やるべきことに必要なものだけ持って場所を変える
そもそも、衝動的にやりたくなること（例えばゲームとか）を優先しがちなら、そのようなものを物理的に切り離して、極力排除した環境に身を置くのも1つの手段です。
このブログの執筆の際には、PCだけ持って、スタバなどに行ったりしてみました。
スマホなど衝動的にいじってしまいそうなものを持っていかない方が、進捗が良かったです。
（締め切り効果も満点でしたが、物理的にそれをやるしかないという状況は効果十分でした）
まとめ
行動経済学などの本を読むと、人間は不合理な行動を時として取るということが分かります。
今回のケースだと、「人間はやるべきことを先延ばしにしがちだ」ということを認識して、先延ばしをしないような対策をしておく必要があると言えるでしょう。
結び
以上が、この半年間での手痛い失敗3つでした。
見返してみると、当たり前のことが多数書かれているように思われます。
要するに、当たり前のことを当たり前にできることが大事ということなのでしょう。
私の失敗の話が、何らかの形で参考になるようでしたら幸いです。
