はてなブックマーク

エンジニアの自己評価を見るとき、気になる言い回しがある。 『○○をやった』 『○○を達成した』 そう書きたくなる気持ちもわからなくはないが、そう書かれると『それで』と返したくなる（言わないが）。 同じように、中途採用のレジメを読んでいると、エントリいただく方々の多くも、やはり『やった系』の書きっぷりが多い。例えば、 『○○業務プロジェクトでプロジェクトリーダとして云々かんぬんをやった』 などと書かれる。そのあとに、適用技術を列挙されたりする。 果たしてこれで、エントリされている中途採用のご希望を持たれているエンジニアさんとして、どこをアピールされているのだろうか。少なくとも自分にとっては、魅力的に感じられない。 こちらでご応募願いたいエンジニアさんに一緒に解決していきたい業務課題をあげているわけだ。であれば、その課題を解決しれくれそうなエンジニアとまずはカジュアルに会話してみたいと思うので

身も蓋もない言い方をすれば、エンジニアの評価なんて必要ない。というか、できない。 できない理由は幾つかある。エンジニアに求められるスキルは広く深さがある。その人を形作る基礎スキルはもちろん、エンジニアが身につけている技術を適用してアウトプットする技術スキルの両方が評価対象となる。 評価対象は、所属する組織の事業により違いがある。事業領域が広ければ、事業として必要とする技術領域は広がる一方、そうした技術の幅は一人のエンジニアでは賄えないから複数のエンジニアでカバレッジをすることになる。結果、同じ事業を一翼を担うエンジニアの担当する技術は違うが、評価は同じ軸で行われる。 そこで持ち出すのが事業への貢献、役割になる。ビジネスでリーダーシップを発揮したか、などを問うようになる。 担当する業務もSI（新規開発）とSO（維持管理）で同等の評価をしない。SIでは新しいビジネス、サービス開発により事業貢献

ダメなエンジニアはとにかく手をつけてしまう。もちろん、周囲から『あれはやったか』『なる早で』『今日中に』と着手するような圧を受ける。 良いエンジニアであることの前に、『いい人と思われたい』という内面が先に立つと『わかりました」『この後やっておきます』と言うのだ。 今だっていくつかのタスクを抱えているのに割り込みされる。内心、次々とあれやこれやとお願いという丸投げされているのに。一体、いつやれるっていうんだ、と思っているのではないか。 心当たりばかりなのではないか。 そうした環境は、実はエンジニアであるあなた自身が作っていることに気づかなければならない。仕事を振ってくるプロジェクトマネージャやリーダがそうした環境を作っているのではない。仕事のWIPを考えもせずに振ってくるプロジェクトマネージャやリーダはあなたを便利に使っているにすぎない。例えれば、いくらでも入るspoolなのである。そこに入

若手エンジニアが配属されると中堅エンジニアに育成を任せることが多い。中堅エンジニアに育成の自覚を持たせたいというよりは、もう習慣的な反応になっている。若手エンジニアをいきなり現場に入れて相談相手でありメンター役になるエンジニアも決めずにプロジェクトに丸投げするよりはいいのかもしれない。 ところで、そのメンター役になるエンジニアは 『育成に関する知識を持っているのだろうか』 という根本的な疑問を持っている。学卒で教員免許を持っているエンジニアは教育に関する基礎知識を持っているだろう。では、それ以外のエンジニアはどうだろうか。 何を背景に若手エンジニアを育成できると思って育成役をアサイメントするのだろうか。多分、ほとんどのマネージャはそこまで考えていない。リーダ役を担える中堅エンジニアに育っているのだから、若手エンジニアを『中堅エンジニアと同じように』育てられると思っているのではないか。 何も

平成最後の年の暮れ、日経の中の人の退職エントリが頭の片隅に残っていたからか、TLで退職エントリは若手エンジニアよりは新卒の学生に伝えた方がいいんじゃないかというのを見たからか、考えもせず、2018年の退職エントリをまとめはじめてみたが失敗であった。 思ったより多かった。『退職エントリ』以外にも『転職エントリ』もあったが、辞めた後、仕事につくとは限らないので退職エントリにした。退職エントリも辞める側のエントリもあれば、辞めたあと、残された側のエントリも稀にあって、そっち側もあるよなと改めて別れは2つの立場があるものだと思わされた。 そんなことを感じつつ、タンポポ作業（URLのコピペ）をしている中で読んだ記憶のあるものは、実はとても少ない。その少ない中でも記憶に残っているのは、9月の60歳定年で退職されたエントリである。やはり、年齢が近いと気にかかるものである。あとは、NTTのエントリと日経だ

そう言えば、あるチームの意識を変えないとそのチームに組織（マネジメント）から期待された成果を出せないと思いチームの立ち上げから繰り返し言い続けたことがあった。 組織の中でチームを設立する際には何かしらビジネスニーズが存在する。そのニーズの実現こそ、チームの存在理由である。 しかし、そうしたチームの存在理由は得てしてそこに属するメンバの目には止まらない。メンバは自分がどこに属したか、ただそれだけに関心を持つ。だから、メンバは、チームが目指す方向性を知る機会を自ら失っているのだ。 そういった行動を責めることはできないのかもしれない。何より、それまでエンジニアを組織の都合で、今日まではここで、明日からは向こうの現場で、とアサイメントしてきたのだ。エンジニアは、何をやりたいとか、これをやっていこう、と考える習慣を持たない。今日使う技術を覚え、明日からはアサイメントされた現場で使う技術を覚えなければ

エンジニアに自己評価や、（エンジニアとして）何ができるかを尋ねると、概ね「○○やった」「○○した」と答えてくれるが、聞きたいのはやったことじゃない。 尋ねているのは、自己評価や出来ることを裏付け（具体的な案件でのエビデンス）である。そういった経験（話を聞かされると）すると、エンジニアはそのあたりのアピールをもう少し上手になった方がいいと思う。 自分の実績をポートフォリオと言う業界もあるが、何をやってきたかプロジェクトでの業務の成果を説明出来るエンジニアであることは、実はとても大事なことなのだと思う。 では、次の問いに回答して欲しい。 直近3年の案件の中から、専門分野のスキルを活用した事例を説明してください。 その案件での貢献を説明してください。 エンジニアとして心がけていることを説明してください。 今後に取り組みたいことを説明してください。 後進育成についての取り組みを説明してください。

若手エンジニア、大雑把に27歳くらいまでをそのゾーンだという前提で話を進めよう。 若手SEに対して最優先にしなければならないのは一人前になってもらうことだ。そうだろう、手が足りなくて若手を回してもらったのだろう。だったら、最優先事項も若手SEへの期待も全部引っくるめて一人前になってもらうことが当面のゴールだ。もちろん、仕事をやりながら、である。 若手SEが配属されると雑用をさせる 本来、一人前の仕事ができるようになって欲しいのだから、参画したタイミング以降に予定している作業を全て一通り経験してもらうことをOJTのプログラムとして番組を作らなければならない。 では実際はどうかと言えば、雑用ばかりさせている。本来、雑用なんてプロジェクトでは存在しないものなのだが、動機付けをしなかったり、教える側の先輩エンジニアが仕事の意味を理解していないばかりに自分がやりたくない仕事を押し付けてしまうからわざ

プロジェクトマネージャにも色々とリーダーシップのスタイルはあるが、所謂、トップダウン型のプロジェクトマネージャの例を挙げると、先日無くなった「フルメタル・ジャケット」ハートマン軍曹や「愛と青春の旅立ち」のエミール・フォーリー軍曹なのかもしれない。 役職的には、ちょっと下すぎるけどイメージとして。 news.yahoo.co.jp あるとき、まだ若手エンジニアがリードする会議の予定があって、その会議の準備状況を聞いてみたら、まあ、案の定、ほとんど無垢というか、そんなので大丈夫かレベルで。 この状況での選択肢は、問い掛けをして何が足らないとこちらが思っているかを考えさせながら会議の準備をしてもらう案とあれこれと指示をするマイクロマネジメント的な案の二つ。 若手エンジニアの勉強にもなるのでもちろん前者を選ぶわけですが。 やってというのは簡単 冒頭の軍曹スタイルのリーダシップは簡単だし、楽なんです

とあるゆるゆるな会合で相談を持ちかけられたというか、あなただったらどうする的な感じでネタを振られたんですね。 どうやら、おかしくなっているプロジェクトがあって第三者の立場で見てレポートするのがお仕事だったらしい。 あなただったらどうするとは、よく聞いてみると２つあって、 第三者の立場でレポートに何を書くか もし立て直すならどうするか それが上の２つ。 トラブルプロジェクトのレポート 必ず書かなければならないのは、依頼者が知りたいことですね。まず、大前提に第三者レポートが必要になるということは、組織の中で正確な情報がレポーティングされていない、という背景があるかもしれないということ。 正しい客観的で定量的なレポートが上がっていれば経営者はそれで判断できるものだし、それがあるべき姿です。 得てして、中間管理層だったり現場のPMが（根拠なく）まだ大丈夫だと思っていたり、そもそも（鈍感で）気づいて

どこの立ち位置でと言うのがキモになるかもしれませんが、プロマネやコンサルの立場に関わらず、いちエンジニアとまるっと括った上でお話をすると、 「（これ今やるのがいいのか、必要とする数日前にやらないともう1回更新することになるから無駄だろう）」 なんて思うことがままある。今のお仕事の役割は良くある。 でも、絶対に「無駄ですからやめましょう」とかは言わない。 何故いわないか。手戻りしたらやり直しで追加の費用を貰える契約ではない。手間を掛けたら掛けた分、リソースが目減りするから依頼元から見れば損失である。エンジニアの専門家としては行う期日をスライドさせるべきだ、と言うのが正しいのかもしれない。 正しいことを言うのが専門家ではない。正しいと思うこと自体がエンジニア目線である。専門家として助言を求められているなら、例えば、どのタイミングでやるのが最適かを尋ねられているなら必要とする数日前が合理的であれ

よく知られていることだけれど、現代のソフトウェア開発の主流となったウォーターフォールの元と言われる論文が存在のですよ。 MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS Dr. Winston W. Rovce 2つ目の図（Figure 2. Implementation steps to develop a large computer program for delivery to a customer. ）がウォーターフォールと呼ばれるきっかけとなった（らしい）。 確かに漏刻に似ている感じはあるよね。 引用　セイコーミュージアム　自然の力を利用した時計　水時計 ただ、冒頭の論文にはwaterという言葉が1回も出て来ない。 つまり、論文を書いたDr.RoVceではない後でこの論文を読んだり、引用した人の中にウォーターフォールと名付けた

「これまでの中で1人だけ良い上司の名前を挙げてください」 この質問に即座に名前を挙げられるとしたら、それはとても幸せだと思います。 もし1人も名前を挙げられなかったら、あなたが名前を挙げられるような上司になれるよう目指しましょう。いや、多分、そうであること＝その人にとって良い上司だということは直接は言ってもらえることはないかもしれないけれど、それを伝えてもらうことが目的ではないので。 幸いにもワタシには1人の良い「元」上司がおり、いまだに会いたいときにいつでも会っていただけることはとてもありがたいことです。 やりたいことを話すようになった 部下だったのはほんの数年で、それも20代のある時点くらいのことなので、そこから数えると20年を超えてお付き合いいただいていることになりますね。 ＃そりゃ白いものが増えたり薄くなったりするわけで… 20代の頃に部下から異動して他の組織に移されたときに会えば

仕事って、ここまではやっておかないと、という矜持というかismを持っていないとせっかく仕事をしていても「やっつけ仕事」にしか見えないんですよ。 そういうやり方をしている人の仕事は、作業の途中で必ず文句を言う割には自分の考えを周りに押し付ける一方で周りを全く見ていないんですよねぇ。 人は、エンジニアは特にオペレーションではなく、その人が持っている経験と知識に基づいて創作的な物作りをしなければならない作業が含まれています。そうした仕事は、1人では完結しないので必ず周囲を巻き込まないと仕事にならないんです。 こうした仕事のやり方をしている人がいると誰が困るかと言えば、巻き込まれた周囲です。もちろん、そんな仕事をしてれば、それを見ているマネージャはそう言う人は評価しないものです。 もし、次のような症状が現れていたら、困ったエンジニアなのかもしれません。 忙しい、時間がないと言う このフレーズを使う

「エンジニアの仕事は楽しいですか」 そう訊ねられたら楽しいと答えるかな。でも、何が楽しいかと問われると楽しい仕事もあり、忍耐力を鍛えるような仕事もあり、心中はスパッと楽しいとは言えないのですけれど仕事が１つだけということはエンジニアにはないので、全体からいえば、概ね良好なのではないかと思うのです。 とは言っても、どのような仕事だとしても共通的なことがあると言えばあるような。 新しいアイデアを探る 過去に担当した経緯からではあると思うけれど、いや、多分に他のメンバのスキルから消去法というか優先順位できにで同じ結果になると思うけれど、割と難しめのタスクが回ってきたのです。 いよいよ手をつける時期になった（自分で開始時期を宣言していた）ので、状況を整理してみたら獏とした印象しか残らないほど、現時点で掴みどころがないのである程度ロジックを作ろうとすると、多少の権威づけをしておきながら、ゴール設定を

「あ、お久しぶりです」 「ああ、こんにちは。久しぶりだね。今はどのプロジェクトをやっているの」 「顧客の役員がアジャイルをやってみて課題は何かを検証するプロジェクトなんですよ」 「アンチパターンそのものだね。上から手法を指定されたプロジェクトで成功した試しないよ」 「やることは決まっていて、アジャイルで開発することになってて」 「それであなたは何をするの」 「リーダです」 「へー、じゃあスクラムマスターなの（POではないのか。PMならPOな気もするけど。でも要件持っているのは顧客だよね）」 「ああ、スクラムマスターっていうんですね」 「ん、アジャイルって一括りに言っているけどどの開発手法でやるの。アジャイル開発は幾つかメジャーな手法があるから」 「スクラムでやろうと言われています」 「言われてって…大丈夫なんかな。心配になってきたよ」 「これから勉強したいので何か情報教えてもらえませんか」

もう、エンジニアが時間外に勉強するとかしないとかは終わったかと思えばこんなのが。 se-tenshokucenter.com あー、はいはいと思いつつ読んだら勉強するしないは好きにしたらいいとかぶん投げているのに、勉強しないと給料が上がらないという方向に持って行っているんだから、結局時間外に勉強しろよ、と言っているんじゃん。 ちょっとおさらいするよ。 使用者（経営者）労働者に技術を身につけさせる理由 使用者が労働者に技術を身につけさせたいと考えるのは、事業の業務遂行上に必要となるからです。業務上必要な技術を身につけさせることで、期待する成果を得られるように訓練するのです。職業訓練、です。 労働者（エンジニア）自身が技術を身につけたいと思う理由 労働者であるエンジニアは自身に業務上の職業訓練に置いて技術を身につけることは使用者が求めることで、これは同じ職種の労働者は基本的に同じように身につけ