企業選びの軸は「やりたいこと」だけではない

就職活動 採用

下記記事に関連してツイッターで呟いたところ反響がありましたので、こちらにまとめ直します。

Rayの取材を受けたときにも感じたことだが、そしてこれはいつの時代もそうなのだが、就活難の原因に、「好きを仕事に」願望（幻想）があることを最近、強く感じている。500人模擬面接をして再確認したのだが、「やりたいこと」と「むいていること」が大きくズレている人多数。そして、「アナタ、そこじゃないでしょ？」という企業選択をしてしまう…。うーん。


私も採用面接官をやっているので、よく同じことを感じます。
社会人になれば大抵の人は実感すると思うのですが、自分のやりたいことだけ仕事にできるなんてほぼありえません。まして新入社員ならなおさらです。
しかしそういった事実を知らずに、あるいはその事実に目を向けないまま企業を選び就職してしまう学生さんは必ずいます。
このような就職は

  1. 「好き」とか「面白そう」だけで仕事を選んだ
  2. イメージと違った、やりたい仕事ではなかった、評価してもらえない
  3. 早期退職


というパターンに陥りやすく、これでは人材にとっても企業にとってもメリットがありません。

好きを仕事にするには覚悟が必要なのだ。
好きかどうかよりも、むいてそうかどうか、活躍できそうかどうかが採用時にも入った後でも大事なんだな。
好きが長く続くとは限らないし。


好きなこととむいていることが合致している人はラッキーだけどね。ちなみに、成功者は意外にもやらなければならなかったことを通じて、自分がむいていることに気付き、それがやりたいことに変わっているという傾向があるかも。

そう、だから「まずは与えられた環境のなかで成果を出す」「与えられた仕事を好きになる」といった覚悟と、「むいているか=強みを活かせるか」という観点が必要になるのです。



ただ、同記事でも指摘されているとおり、その仕事に強みを活かせるかを判断するのは簡単なことではありません。
したがって、OB訪問等を通じて企業研究を深めていくことが大切ではあるのですが、もう少し企業選択の軸を延ばしたり広げたりすることもできるのではないでしょうか。


例えば、「その仕事を通じて何を実現したいのか」というビジョン（夢）があれば、もはや職種や仕事内容は大きな問題ではなくなります。
自分の仕事が何であれ、それに自分で意味付けできるようになるので、モチベーションや成果も自然とついてくるのです。
またビジョンの内容についても、「自分のため（自己実現）」ではなく「他人のため（社会貢献）」のものであったほうがよいと考えます。
「他人のため」に目指すものならば、仮に ”自分のためにはまったくならない仕事” が任されても意味付けできるからです。（実際にはそんな仕事もないと思いますが）


さらに、「何をやるか」ではなく「誰とやるか」という軸も存在します。
「こういう価値観・能力をもった人たちと働きたい」「この人たちに貢献したい」といった動機があれば、仕事どころか事業内容が変わったとしても、その企業に属する意義は変わりません。
ただし、その企業で働く人たちが共有しているビジョンに共感し、一緒に目指していけることが前提となります。
また、人という軸で見極めるためには、その企業の価値観を深く理解するとともに、その価値観の浸透度（企業文化や採用方針に顕れてくるはず）を研究する必要があります。実態がともなっていないところに共感しても意味がありませんからね。



私自身、自分のビジョンや「誰とやるか」という軸にもとづいて今の会社を選び（したがって職種への強いこだわりもありませんでした）、今までやってきたこととはまったく関係のないプログラマという職種に就いています。
しかし、仕事が嫌だとかつまらないとか感じたことは一度もありません。
今回挙げてきた軸に誰もが共感できるということはないかもしれませんが、就職活動のひとつの在りかたとして参考にして頂ければなぁと思っています。

2009年に出たコンピュータ書ならこれを読め！

書籍 技術 レポート

『2009年に出たコンピュータ書ならこれを読め！』に行ってきました。
他にもブログ書いているかたいるけど、備忘録も兼ねて。
なお、個人的にアンテナ引っかかったものが中心となりますので悪しからず・・・笑


まず、昨年度売れたのはやっぱりiPhone関連とtwitter関連。


こちらはサーバ関連。


続いて、システム開発全般（思考法など）。


Ruby関連。


DB関連。


最後に、デザイン関連。


個人的にもっとも読みたいと思ったのは、レガシーコード改善ガイド (Object Oriented SELECTION)でしょうか。
テストを書こうという意識はしているけれど、感覚と経験則にのみ基づいているなぁと感じるので、ぜひ勉強したいです。
次のチーム内の勉強会ではこの本を読もうか・・・。


おまけ。
ランク外ですが、高橋さんもお好きなシリーズということで、TCP/IPの絵本 ネットワークっておもしろい!を購入して帰宅しました。
まだ途中までしか読んでいませんが、入門書としては充分すぎるのではないかと。
図解は頭に入りやすいだけでなく、思い起こしやすいところが良いですね。


自分の小さな「箱」から脱出する方法

仕事 コミュニケーション 書籍

たまには技術以外の話題を。

人間関係やチームの活動におけるトラブルを根本解決する、という内容。
特に興味深かった点は、次の2点です。

  • 自分が箱に入ってしまうこと
    • 「こうすべき」という自分の感情に逆らった行動をとることを、『自分への裏切り』と呼ぶ。
      • 例：「同僚のミスを発見し、教えてあげるべきだと思ったのに教えなかった」
    • 自分の感情を裏切ると、自分のとった行動を正当化するため、世界を歪んだ視点で見るようになる。
    • 結果、「他人の欠点をあげつらう」「自分の長所を過大評価する」等、自分に都合のよい考え方をするようになる。
      • 例：「不注意なあいつが悪い」「自分の仕事のほうが重要なのだから、他人のミスに構っている時間はない」
  • 他人も箱に入れてしまうこと
    • 箱に入っていると、自分を正当化しようとするので、他人が間違っていなければならないことになる。
    • すると、本来なら問題の解決を目指さなければならないのに、他人が問題を起こすことを望んでしまう。
      • 例：「後々ミスが発覚して、あいつだけプロジェクトから外されればいい」


個人的な感想としては、「耳が痛い」ということですね。笑
自分よりも他者に注意を向けることを心がけていきたいです。


人間関係にお悩みのかた、チームのリーダーを務めているかたにはお薦めできる本だと思います。

イベントハンドラからrailsのAjaxアクションを呼び出す

JavaScript rails ajax

RTMの設定みたいに、ラジオボタンをポチポチ押したらrailsのAjaxアクションが実行されるコードを書いていて思ったこと。


イベントハンドラから、JavaScript関数ではなくrailsのAjaxアクションを呼び出したい場合には、remote_function メソッドを使います。
例えばこんな感じ。

<input type="radio" id="hoge" value="" 
 onclick="<%= remote_function(:update => "fuga", :url => {:action => "piyo"}) %>" />


でも個人的には、inputタグもrailsのヘルパで書きたくて、こうしました。

<%= radio_button_tag "hoge", "", false,
                     :onclick => "#{remote_function(:update => "fuga", :url => {:action => "piyo"})}" %>


ただ、railsのソースコード読んでも、RailsによるアジャイルWebアプリケーション開発（第2版）読んでも、サンプルは前者の書き方なんですね。
どちらの方がいい、とかあるんでしょうか。

Gitから学ぶ仕事のしかた

考え 仕事 git

現在railsのコーチングをして頂いている先生が、Gitを奨めて下さいました。
実際のバージョン管理も体験させて頂き、基本的な使い方は何となくわかってきたのですが、考え方の面で特に勉強になっています。

WEB+DB PRESS Vol.50　特集『はじめてのGit』 より


論理的に関係のない複数の変更は別々のコミットとして記録するのが、お行儀の良いバージョン管理のコツです（これはgitに限ったことではありません）。 〜 p.69 【git add -p を使う】


トピックブランチを使ったワークフローでは、1つのトピックは1つのテーマのみに徹した変更を行うのが基本で、最後にそのトピックを統合ブランチに併合したとき、そのテーマに関連しない変更が何一つ統合ブランチに現れないようにすることを一番の目標とすべきです。 〜 P.92 【トピックへの統合ブランチの併合】


これらの話は、開発に限らず、仕事のしかたそのものにも通ずるのではないでしょうか。


仕事を因数分解して明確なタスクまで落とし込む（＝仕事をアトミックな単位に分割する・1つのタスクには1つのテーマしか持たせない）のは、非常に重要なことだと思います。
なぜなら次のような効果が得られるからです。

    • ゴール達成に必要な要素を抜け漏れなく洗い出せる
    • 計画を立てやすい
    • 起こりうる問題を予測できる
    • 問題が起きたとき原因を発見しやすい
    • 問題の処理範囲が明瞭になる
    • 他者とプロセスを共有しやすい

      ⇒ 手際よく正確にゴールを達成でき、チームメンバーの時間を必要以上に奪うこともない


ここでGitの話題に戻りますが、もちろん「Gitでなければアトミックコミットができない」ということはありません。
ただ、どれだけ管理のことを考えずに済むかで、敷居の高さは変わってくると思うのです。


私自身、仕事ではSubversionとTracによるチケット駆動開発をしています。
（本来は1ブランチにつき1チケットが理想なのでしょうが、）重要度の低い小さな修正をいくつかまとめてFixすることもあるため、「せめてブランチへのコミットはアトミックに」と意識してはいるのですが・・・。
Subversionの場合、アトミックコミットを実現するには、コミットごとにどこを修正するか自分で管理しなければなりません。


その点Gitは、同一ファイル内でもコミットする変更を取捨選択できるなど、アトミックコミットに対して最適化されているなぁと感じます。
最適化されていれば、それだけアトミックコミットという作法を忠実に守れるようになるので、より正しい仕事のしかたが身につきやすいのではないかと。


とは言え大切なのは、ツールに頼るのではなく、ツールから学んだ仕事のしかたを自分でも心がけることですね。


と、Gitからの学びを簡単にまとめたところで、ひとまず自宅のWindowsにmsysgitを入れてみましたので、今後いじってみようと思います。

簡易アラーム（カウントダウン）

ツール ruby

rubyでカウントダウンアラームを作ってみました。

  • 実行時に「○○分」の数値を引数として渡す
  • 10分前に1回、5分前に3回、時間になったら10回ビープ音が鳴る
ビープ音を鳴らすには？

Windows環境のため、rubyプログラム中で echo ^G コマンド（バッチファイルにビープ音を鳴らしたいのですが、やり方を知っている人はぜ... - Yahoo!知恵袋より）を使おうとしたところ、上手くいきませんでした。
^G が Ctrl+G として認識されないようです。
最終的には、http://yakinikunotare.boo.jp/orebase/index.php?Ruby%2Fbeep%B2%BB%A4%F2%CC%C4%A4%E9%A4%B9より、rubyのまま print "\a" で行けることがわかりました。

def countdown(min)
  sleep(min*60)
end

def beep
  print "\a"   # ビープ音
end

def set_alarm(min, frequency=1)
  countdown(min)
  frequency.times{beep}
end



unless ARGV.empty?
  minutes = ARGV[0].to_i   # ARGV[0]はStringなので、数値に変換

  unless minutes.zero?
    if minutes > 10
      set_alarm(minutes-10)   # 10分前のアラーム
      minutes = 10
    end

    if minutes > 5
      set_alarm(minutes-5, 3)   # 5分前のアラーム
      minutes = 5
    end

    set_alarm(minutes, 10)   # 最終アラーム
  end
end


テキストボックスのテキストを全選択＆編集不可にする

html rails

テキストボックスの中身をコピペしやすくするためには、下記をオプションで指定するのがよいでしょう。
（サンプルを示したいのですが、はてダでは表示できないようです）

    • クリックするだけで全選択： onclick="this.select()"
    • 中身のテキストは編集不可： readonly="readonly"
  • HTMLで書く
<input id="hoge" name="hoge" type="text" value="コピペが楽チン！" onclick="this.select()" readonly="readonly" />


railsのフォームでも、そのまま書けます。

<%= text_field_tag('hoge', "コピペが楽チン！", :onclick => "this.select()", :readonly => true) %>
参考サイト