VOYAGEのエンジニア評価制度の全貌。「技術力評価会」による、人が育つ組織の作り方 | SELECK [セレック]
〜「技術力評価会」を中心とした、VOYAGE GROUPのエンジニア評価制度。被評価者だけでなく、評価者も育てる仕組みとは〜 売り手市場が続く、エンジニア採用。その中で、優秀なエンジニアを採るためには、何をするべきなのか。 その問題への1つの解として、人が育つ「評価制度」を綿密に構築しているのが、株式会社VOYAGE GROUPだ。同社では、半期の取り組みを評価する「技術力評価会」を中心とした評価制度を、CTOの小賀 昌法さんを中心に、6年という歳月をかけて作り上げた。 「なぜそのように実装したのか」を90分間ディスカッションする「技術力評価会」、それをサポートするための「サポーター制度」、その評価資料の「GitHub（ギットハブ）」での全公開など、随所に工夫が施されている。 （※技術力評価会の詳細は、新入社員目線で書かれたこちらの記事もどうぞ） そして、それらの評価制度を運用していくため
![VOYAGEのエンジニア評価制度の全貌。「技術力評価会」による、人が育つ組織の作り方 | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/df4cc9b63f665154aa599ddedb8b7c6460e9ec11/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2018%2F03%2F09103449%2F8f7b9e1d-7d4c-411d-894b-132b5137171c.jpg)
フルスタックエンジニアよりデュアルスタックエンジニア | F's Garage
（言葉遊びみたいな記事を書きますね。その上、用語の使い方が間違ってたらごめんなさい。） 一時期、フルスタックエンジニアって言葉流行りましたよね。ふと、要件どこまでだっけ？と思って調べようと思ったんですが、日本語で調べると、妄想が暴走してロクな話が出てこなそうなので、英語の方で調べてみるとわかりやすい。 What is a Full Stack developer? Server, Network, and Hosting Environment. Data Modeling Business Logic API layer / Action Layer / MVC User Interface User Experience Understanding what the customer and the business need. 個人的には、ネットワーク監視やデプロイなどのインフラ運用
スマートフォンアプリ開発における共創的な開発チーム
複雑かつリッチな体験を提供するスマートフォンアプリを開発するためのチームワーク、その中でのエンジニアの役割について
大規模イベントに関わる人達のよもやま話 (11:20- ＠C会場) | CROSS Party 2019
法林浩之 日本UNIXユーザ会 Twitter 大阪大学在学中に日本UNIXユーザ会に参加し、1992年より幹事。2003年から2年間は会長も歴任。職歴としてはソニー、インターネット総合研究所を経て、2008年に独立。現在はフリーランスエンジニアとしての活動と並行して、多彩なITイベントの企画・運営を行っている。特にトークセッションの司会に定評があり、これまでに1000人以上の講演者の相手を務めている。 櫛井優介 LINE株式会社 Twitter LINE株式会社 Developer Success Team / Culture Evangelist。技術系イベントやエンジニアBlogなどを担当。LINEが主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY」や、延べ6500人が参加したパフォーマンス・チューニングコンテスト「ISUCON」などを運営しています。
Webオペレーションエンジニアのアウトプットと開発力 - 人間とウェブの未来
という話を、社内のインフラチーム向けにしました。 Webオペレーションエンジニアの大体のイメージについてはこちらを御覧ください。書評なのですが、とてもイメージしやすいエントリになっていると思います。 blog.riywo.com スライドの中でも一応定義していて、３行にまとめると Webサービスの運用 OS・ミドルウェアの運用 運用技術の調査・開発 を主な業務として行っているエンジニアを指すことにします。 入社して間もないので、僕の人格の好き嫌いや人間関係みたいなものがまだできていない頃の発表ということで、素直に内容を聞くことができる、という意味でいい機会だったと思います。 この内容は、社内だけでなく社外のWebオペレーションエンジニアや、所謂、インフラエンジニアと呼ばれている人でも同じような悩みを抱えている人がいるかもしれないと思っていて、内容的にも公開しても良い話なので公開しようと思い
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
良いディフェンダーはタックルをしないし、良いエンジニアは障害対応をしない · takus's blog
Amazon のオススメ本に出てきた「 サッカー データ革命 ロングボールは時代遅れか 」を読んでみました。 この本は、野球界における「 マネーボール 」のように、 サッカーを様々なデータを元に見つめ直すような内容になっていて、 例えば、チームが負けているときに交代によって最大の効果を得るためには、 1 人目の交代を後半 13 分、2 人目を後半 28 分、3 人目を後半 34 分までに行うべきとか、 極端に能力の高い選手を獲得するのと弱点となる選手の穴を埋める補強はどちらがいいのかとか、 統計を元にしたサッカーに関する興味深い考察が多かったのですが、その中に 1 つ引っかかる話があったのでそれについて書いてみます。 良いディフェンダーはタックルをしない 本書の中で、 四半世紀に渡ってマンチェスター・ユナイテッドを率いた名将ファーガソンが、 オランダ代表のディフェンダー、ヤープ・スタムを放
バグをドラゴンと呼ぶ運用を始めて1ヶ月くらいたった - Konifar's WIP
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました！」「Aクラスのドラゴンを相手にしてる最中だってのに！」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野（しっぽ） (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
エンジニアに必要な説明能力 - Konifar's WIP
最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、
「秀丸」の秀まるおさん、そろそろMac版はいかがでしょう？ 気になることを全部聞いてみた。 | HRナビ by リクルート
Windowsでテキストエディタといえば、ほとんどの人が同じものを思い浮かべるのではないだろうか。もちろん「秀丸」である。いまも多くの人がPCをセットアップするときにまずインストールするソフトウェアの1つだ。 1990年代半ばに生まれ、20年以上にわたって使われてきている。開発者の斉藤秀夫さんは秀丸があまりに売れたため、当時勤めていた大企業を退職して独立した。元祖ソフトウェアスタートアップともいうべき存在である。 そんな斉藤さんにいろいろ聞いてみた。Mac版は出ないのか？ 秀丸御殿がたったのは本当？ いまはスタートアップが成功しやすい？ 自然体で答えてくれた斉藤さんのお話をどうぞ。 秀丸が好調で、「フェラーリに乗ってる」という噂も –「秀丸」シリーズの売上はピーク時で1億円を超え、「秀丸御殿」が建ったとか。 斉藤：Windows 95が出てきて世の中みんながWindowsを使うようになった
%25E6%258A%2580%25E8%25A1%2593)
Treasure Dataを支える(中の人に必要な)技術 - myui's memo
Treasure Data（以下、TD）に入社して早2週間が経ちました。 入社してから、平成14年度IPA未踏ユース第1期で同期でスーパークリエイタであった西田さんがTDで働いているのを知りました。MapReduceやHadoopが登場した頃、「Googleを支える技術」という技術書*1でお世話になったのですが、いつの間にかTreasure Dataを支える人になっていたんですね*2。 Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ) 作者: 西田圭介出版社/メーカー: 技術評論社発売日: 2008/03/28メディア: 単行本（ソフトカバー）購入: 47人 クリック: 1,166回この商品を含むブログ (374件) を見る TDではおかげさまで結構なペースでお客さんが増えていて事業規模拡大に備えて幅広い職種で人材募集中です。今回はTDのバッ
「整った開発環境」「優秀な仲間」「5時からビール」 会社に来るのが楽しくなるエンジニア天国・Indeedとは？ - はてなニュース
求人情報に特化した検索サービスを世界55ヶ国以上で運営するIndeedは、リクルートによる2012年の買収後も、開発者にとって仕事がしやすい環境をとことん追求するエンジニア文化を守っています。恵比寿ガーデンプレイスに移転したばかりの東京オフィスで働く同社のソフトウェアエンジニア5人に集まってもらい、はてなチーフエンジニアの大西康裕が開発スタイルや社風などについて聞きました。Indeed独自のワークスタイルに、はてな側も興味津々。知られざるエンジニア天国の実態とは？ 記事の最後には、デルの27型4Kディスプレイ「P2715Q」が当たるプレゼントのお知らせもあります。 座談会出席者（上写真、左より）：はてな 大西康裕、Indeedの村下瑛さん、濱田卓さん、山口有理さん、杉原啓太さん、落合徹さん （※この記事は、株式会社リクルートホールディングス提供によるPR記事です） ■ 開発スピードを生かす
詳解 フェンリル採用面接 - 意識高い系エンジニアのベストプラクティス | フェンリル
フェンリルは、Software meets Design というミッションの実現に取り組んでくれる意識の高い仲間を募集しています。実際に応募されたみなさんには、通常、書類選考および面接を受けていただきます。 フェンリルの面接でまず問われるのは、みなさんの意識の高さです。何よりも、高い意識こそがプロダクトに価値を与え、ユーザーにハピネスを届け、ひいては世界の意識を高めていくことになるからです。 本書ではエンジニアの方を対象に、フェンリルの面接を通過するために必要となる高い意識の持ち方について紹介しています。本書を参考に、実際の面接にはこれ以上ないくらい意識を高めて臨んでください。ひとりでも多くの方の意識が高まり、ともに働く仲間となれることを願ってやみません。 謝辞 フェンリルのプロダクトを使ってくれる意識の高いユーザーのみなさんに感謝します。フェンリルはより多くのユーザーにハピネスを届けるた
面接におけるギークの言葉:tks(高須 正和)のブロマガ - ブロマガ
僕が今いるチームラボでは、多くのテクノロジー会社がやってるように、インタラクティブエンジニアはインタラクティブエンジニア、WebデザイナーはWebデザイナーというように、その後一緒に働く人たちが面接する。（最終面接は、給料を払う人である役員がやるかも。あんまり詳しくない。なお、社長は一切の選考過程に関わっていない。たまに推薦が来るが、社長推薦の合格率は低い気がする） エンジニアの人は、面接ですごく重たい（重要な）感想や意見を言うときがある。僕より全然重く感じる。印象に残った言葉を書いてみる。 なお、就職してからいくつかの会社でずっとエンジニアたちと一緒にいた僕が昔いた会社の人の言葉や他社の言葉も入っている。（そのほうがおおいかも。誰から聞いたかもう忘れちゃったのもある） また、彼らは採用時は黙って○をつけることが多く、言葉にするのはNGの時が多くなる気がする 「'授業や研究で作った'みたい
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
GMOペパボ株式会社の執行役員CTOに就任しました - Kentaro Kuribayashi's blog
昨日(3/21)、GMOペパボ株式会社の執行役員CTO*1に就任しました。昨年8月に技術責任者に就任したのですが、今後はより一層、経営に近い立場で「技術」という切り口において会社の成長に貢献していきたいと思います。 今後やっていくこと 今後やっていきたいことを整理すると、以下の3つになります。 成長のための技術戦略の策定・実行 1.を実現するための技術基盤づくり 1.を実現するための組織づくり これまでも「GMOペパボ攻勢の裏側にあった「技術的負債を抱えない開発体制づくり」3つの布石 - エンジニアtype」にある通り、あれこれやってきましたが、より踏み込んだ戦略を立て、実行していくつもりです。また、それぞれにおいて各論的にいろいろ考えていることはあるのですが、細かいことをここで述べてもしかたないでしょう。このブログでもこの1年あまり、上記についてあれこれと書いてきたので、是非そちらをご覧
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
エンジニア単価情報 | ニアショア機構
スキル体系について 経済産業省（IPA）が制定したITスキル標準（以下「ITSS」）と、 株式会社パソナテックが、ITSS、SFIA（Skills Framework for the Information Age : 英国）、SWEBOK（SoftWare Engineering Body Of Knowledge : 米国）を参考に体系化し、人材ビジネスで 豊富な運用実績のあるPT-ITSSをベースに使用しております。 ※役割全体図(pdf:2.1MB) ニアショア開発活用に関するお問い合わせはこちら 首都圏単価より割安で高いパフォーマンスが期待できるニアショア開発に注目が 高まっています。 ニアショアベンダー紹介依頼、開発コスト最適化、リソース確保のご相談等、 お気軽にお問い合わせください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
焼きそば - hiroki-uemuraのブログ
エンジニアの芸能事務所