タグ

ブックマーク / medium.com/@t2y1979 (5)

  • 良いプログラマーを採用するには

    ここで言う「良い」とは、優秀なとか、プログラミングスキルに長けたという意味。プログラマーと一口に言ってもいろんなタイプがいると思うし、お仕事だったら実務をチームでこなせることが第一条件になる。私なら以下の条件を全て満たせば良いプログラマーだと思う。採用やってるわけじゃないから当にそうかどうかは知らない。 リーダブルコードが書ける継続的な学習習慣が身についている客観的に理解できるドキュメントが書ける英語の読み書きができるプログラミングが好き先日、管理部が上長に新卒採用で未経験であっても、どうやったらプログラマー適性のある新人を採用できるかといった話をしていた。中途採用を待っていても採れないから新卒採用に注力するらしい。そんな中で性格に多少の問題があってもプログラミングスキルの高い人を採用すれば、あとは開発側で何とかするといったことを話したところ、管理部もそれ自体は理解しているが、会社の方針

  • エンジニアとして歳をとっていく

    普段はプログラマーとしてお仕事をしている。過去に SIerプロジェクトマネジメントにも携わっていた経験があるため、状況によって顧客との折衝を行ったり、開発のマネジメントも行ったりはする。 エンジニアの中には、自分は技術のみでキャリアを築き、マネジメントは一切しないと固く決めている人もいるが、私はそういうタイプではない。技術は好きだが、業務で必要に迫られたり状況次第で臨機応変にマネジメントもしていくといった考え方で働いている。 最近マネジメントに関して話す機会があった。私がマネージャーとしてお仕事をするとしても唯一諦めている人たちがいる。 スキルもやる気もない年配の方はマネジメントできない。 こんな話をして聞いている人はだいたい苦笑いをしているし、説得力のある反論をこれまで聞いたこともない。もちろんこんな年配の方は滅多にいない。もし私がマネージャーだったらそういった人は絶対に自分のチーム

    エンジニアとして歳をとっていく
  • なぜ優秀なエンジニアを低待遇で採用してはいけないか

    この記事は技術そのものやエンジニア採用のことがよく分からない経営者へ向けて書いています。エンジニアが読めば当たり前のことが書いてあります。また優秀なエンジニアならこう考えるのではないかというところは、私見によるものなので当にそうかどうかは分かりません。 募集要項を書く募集要項で最も重要なのは待遇に関するところだと私は思います。具体的に言えば、だいたいの年収です。もちろん業務内容や組織の雰囲気なども重要ですが、業務内容や組織の雰囲気が良ければ年収が低くても働こうと思ってくれるのではないかと考えるのは経営者の奢りであって、そんなエンジニアはほとんどいません。優秀なエンジニアにとってはそのどちらも満たす求人が他にたくさんあるために候補にすらなりません。 逆に業務内容に魅力がなくても年収さえ高ければ良いという優秀なエンジニアも一定数いるはずです。待遇を具体的に書くことはそういった層に響くのではな

    なぜ優秀なエンジニアを低待遇で採用してはいけないか
  • 失敗の活かし方

    愚者は経験に学び、賢者は歴史に学ぶ。 有名な言葉なので聞いたことがある人は多いと思う。きっと頭の良い人は書を読んでたくさん学んで失敗を未然に防ぐのだと想像する。昔は私もそうあろうと、というかそうありたいと憧れていたけれど、最近はもう諦めてしまった。 そのため、稿は経験から学ぶことを受け入れた人が書いたものだ。 失敗の仕方人間なので必ず失敗をする。 失敗そのものは防ぎようがないけれど、失敗の仕方は予防線を張れるかもしれない。やや抽象的な表現だけど、昔働いていた職場で上司から聞いた言葉が私の失敗に対する心構えの原点になっている。 自転車で車道と歩道の間を走行しているとき、どう転んでも車道側に倒れないこと。それが失敗の仕方。 私の場合、未知のことに取り組むとき、基は楽観的になんとなくうまくいけばいいなと話しつつ、あまり言わないが最悪の場合も頭の中では考えていたりする。 例えば、勤めている会社

    失敗の活かし方
  • コミュニケーションは枯渇する

    昔、働いていた職場で新たに昇格したばかりの社長がいきなりこんなようなことを言い始めた。 社内のコミュニケーションを活発にすれば業績が上がります。うまくいっていないのはコミュニケーションの問題です。 当時の私はなんか違和感を感じながら聞いていた。それから社員旅行や全社飲み会が企画され、半強制参加が義務付けられ、欠席者はその理由を社長宛にメールするという制度となった。そして、社内に組織横断的にいくつものタスクチームが設置された。個々のタスクそのものは業務とはあまり関係なく、目的はコミュニケーションを活性化させることにあった。 私が入ったタスクチームの課題は、全社員だったか全開発者だったかに「デュアルディスプレイ環境を導入する」といったタスクだった。当時、その会社ではモニターを持ち込みしてデュアルディスプレイ環境を整えている社員が数人いた。そういった環境を会社が全員へ支給してはどうか?ということ

    コミュニケーションは枯渇する
  • 1