タグ

エンジニアと仕事に関するd_akatsukaのブックマーク (15)

  • ScaleOut | Supership

    2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 件に関する詳細は、プレスリリースをご確認ください。

    ScaleOut | Supership
  • ssig33.com - ダンピングをするな

    これの話。 次のような二つの職場があったとしたら、優秀なプログラマの大部分は前者を選ぶのではないでしょうか。 テスト・CI をきちんとやっていて、ソースコード管理は Git & GitHub、もちろんデプロイもほぼ自動化されていて、過去のバージョンに戻すことも簡単にできるため実験がやりやすい。リファクタリングの価値が認識されている。タスク管理ツールや連絡ツールも新しいものを積極的に採用している。権威的な人間がおらず、設計やコードの良し悪しを率直に話し合える。年収 400万。 テストもろくにない Java のコードを手元の Eclipse でコンパイルして、その .class ファイルを WinSCP でコピーしてデプロイしている。バージョン管理システムはろくに活用されておらず、間違えたらおしまいなので PukiWiki の手順書に「~を厳守する」という心構えが出てくる。ファイルを zip

  • ScaleOut | Supership

    2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 件に関する詳細は、プレスリリースをご確認ください。

    ScaleOut | Supership
  • エンジニアとして「頑張る」ということ - 銀の人のメモ帳

    プロジェクトにアサインされた段階で、これはデスマになりそうだな、と感じることがある。 そういう時、僕は、プロジェクトを管理している人に「デスマは絶対にしない」ということと「残業もしない」という旨を伝えている。 これは、決して「頑張らない」という事ではなくて、スケジュールや予算の調整は、エンジニアより上のレイヤーの人間が「頑張る」べきことだと考えているから、そう言っている。 エンジニアとして僕が「頑張る」べきことは、例えば自分を含めたプロジェクトメンバーのスキルアップであったり、開発効率向上等によって工数を短縮出来ないかを考え、実行することであったり、プロジェクトで得たノウハウを次に活かせるような形で保存・共有することだと思っている。 実際は、様々な状況でデスマや残業をせざるを得ない事が多々ある。会社として頑張らなければならなかったり、金銭的なものであったり、色々な事情がある。 そうなったら

    エンジニアとして「頑張る」ということ - 銀の人のメモ帳
  • ソフトウェアエンジニアの成長カーブ(再掲載):柴田 芳樹 (Yoshiki Shibata):So-netブログ

    「ソフトウェアエンジニアの成長カーブ」 最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事

    ソフトウェアエンジニアの成長カーブ(再掲載):柴田 芳樹 (Yoshiki Shibata):So-netブログ
  • エンジニアならウェブサーバーのひとつでも自腹で立てて運用すべき理由と、サーバー環境の選び方 : akiyan.com

    エンジニアならウェブサーバーのひとつでも自腹で立てて運用すべき理由と、サーバー環境の選び方 2013-08-26 なんかスイッチが入ったので書いてみる。 目次 技術的なレイヤーは掘り下げるべきなので、ソフトウェア・エンジニアだってサーバー運用は経験すべき ウェブ系のソフトウェアエンジニアを職業としているのであれば、ウェブサーバーのひとつやふたつは自腹で立てて、実際に運用したほうがいい。 なぜかというと、技術的な仕事にはなんでもあてはまることなんだけど、技術的なレイヤーを掘り下げることには大きな意味がある。他にもやったほうがいいことは多々あるにせよ、レイヤーの掘り下げは特に重要だ。 ウェブ系ソフトウェアエンジニアであれば、仕事で使っているサーバーや言語を支えているOSレイヤーやミドルウェアのレイヤーが、どうセットアップされて、どう管理されているのか、知っているのと知っていないのでは、ソフトウ

  • エンジニアの評価が4以上にならないワケ

    エンジニア仕事は原則として「できて100点」、できなければ減点。 一般的な社員評価の基準に照らし合わせると、「できて100点」だと、4以上の得点はつきにくい。 大体、どこの会社でもこんなイメージの評価じゃないだろうか?! 4以上 ・・・ エクセレント(スーパーな貢献をしたレアケース) 4  ・・・ よくできました。(普通に優秀) 3  ・・・ 可もなく不可もなく。(でもちょっとネガティブ) 1〜2 ・・・ 何か問題があった時。(基的につけたくない点) 絶対的な評価をされると「できて100点」の仕事の人は、4以上の評価がつくケースは稀だ。逆に毎回4以上の評価になるのも少しおかしい。毎日株価が上がってる銘柄みたいなもんだ。 例えばサーバ管理の仕事が典型例で、「動いて当たり前」、大きな障害が起きれば「減点」になってしまう。当は、いつ壊れるかわからないというサーバを守っているという部分に対し

  • エンジニアの成長と「快適な職場」について : 小野和俊のブログ

    「時間あれば軽く飲んでいきます?」 一年前のちょうど今くらいの季節に、Diablo3のオフ会の後に伊藤直也さんと2人で新宿三丁目のバーに向かった。 伊藤さん曰く、 「グリーにいたとき、すごく優秀な人がいて。お願いしたいことを短い言葉で伝えるだけで、行間を読んでこちらがやりたいことを全部理解して、必要な指示を出して自分も動いてあっという間に成果を出しちゃう。」 一般に、エンジニアの楽園のような職場 - 快適で自由闊達に意見が言えて、技術力があり、それぞれが自主性を持ってのびのびと仕事をしている職場の方が、エンジニアは良いアウトプットを出せるし、類は友を呼んで優秀なエンジニアが集まってきやすい。これは確かなことだろう。ただ、エンジニアの成長を考える時、そういう職場は当に理想的なのか、という点については、少し立ち止まって考える必要がある。 人の成長には、明るく楽しく周囲も優秀でコミュニケーショ

    エンジニアの成長と「快適な職場」について : 小野和俊のブログ
  • エンジニアを頑張ったで評価する会社は衰退する | rake enjoy

    この前飲み会でこんな話をしていたのでまとめてみます。 終身雇用が崩壊し、昨今では会社の評価制度では成果主義というのが普通になりつつあります。ただ成果主義とは言いつつ何を持って成果とするかは議論の余地があると思います。 例えば営業職であれば分かりやすく売上目標というものがあります。企画職の場合でも売上やその他のKPIを目標設定することで分かりやすく評価出来ると思います。ではエンジニアの場合はどうでしょうか。 開発したシステムが実際に軌道に乗って数字を出し始めるまでには相当時間がかかります。(最近のゲームなどは除く)またその数字が出るか出ないかは実際営業や企画側の問題が多分にある為、こういったケースでエンジニアを数字で評価するとシステムの良し悪しとは関係なく単純に運がいいか悪いかだけになってしまいます。もちろん企画に意見が反映出来る環境であったり営業に指示できる環境であればエンジニアでも数字を

    エンジニアを頑張ったで評価する会社は衰退する | rake enjoy
  • 週に1日、エンジニアが開発に集中できる日を作ろう

    毎週決められた曜日には、会議も電話もメールもチャットもなく、上司から話しかけられもせず、エンジニアが開発に集中できる日が確保される。クラウド上でRuby on RailsなどのPaaSを提供しているHerokuでは、エンジニアが開発に集中できる日「Maker's Day」が毎週設定されているそうです。 Publickeyが月曜日に公開した記事「アジャイル開発手法でクラウドを作るHerokuのやり方とは」で、HerokuエンジニアCraig Kerstiens氏のブログ」を基に、Herokuでの開発の様子を紹介しました。Kerstiens氏はその続きとして「How Heroku Works - Maker's Day」をポストし、Maker's Dayを紹介しています。 トム・デマルコ氏とティモシー・リスター氏による有名な書籍「ピープルウェア」でも、エンジニアにとって集中できるオフィス環境

    週に1日、エンジニアが開発に集中できる日を作ろう
  • Twitter 社採用面接受験記 - elm200 の日記(旧はてなダイアリー)

    1ヶ月ほどまえに、私はシリコンバレーを訪れたのだが、そのときサンフランシスコの社で Twitter の採用面接を受けてきた。結果は残念、ということだったのだが、その経緯について書いてみようと思う。 なぜ Twitter 社の面接を受けたのか。7月の終わりころ、私はシリコンバレーで働くにはどうすべきなのか、ということについて頭を悩ませていた。考えながらぼうっと Twitter のタイムラインを眺めていたのだが、Twitter が日エンジニアを求人しているという情報が飛び込んできた。おお〜、と思って軽い気持ちで職務経歴書を Twitter に送ってみたのだ。 相当数の人たちが職務経歴書を送ったはずだし、私は書類選考で落とされると高をくくっていた。ところが、数日してTwitter の人事担当者からメールがあり、電話面接をやるからいつがいいか?という。まさかの展開に私はやや慌てた。電話面接を

    Twitter 社採用面接受験記 - elm200 の日記(旧はてなダイアリー)
    d_akatsuka
    d_akatsuka 2011/09/26
    おもしろい
  • hash.bz

    This domain may be for sale!

    hash.bz
  • 35歳を超えたエンジニアの5つの働き方

    おおいしつかさ 旅行とバイクとドライブと料理と宇宙が好き。 Ubie Discoveryのプログラマ。 ぼくは36歳です。けっこう大きなサイトで、RailsJavascriptを書いたり、パフォーマンス改善したり、iPhoneアプリの開発でObjective-Cを書いたりしています。マネージメントはしていなくて、今でも普通にエンジニアとして働いています。 35歳定年説の35歳を超えてから1年以上が過ぎたところですが、昔のようにはいかなくなってきたところ、昔と変わらないところ、昔よりよくなってきたところなどがいろいろあります。年を取ってもエンジニアを続けたい人の参考になるかどうかわかりませんが、そういう人たちのためにぼく個人の体験をここに書いておこうと思います。 1.理解できるまで聞き返す 特に若い人たちとの会話で痛感するのですが、相手の言いたいことを一度で理解することが難しくなってきまし

  • これはマネしたい!スーパーエンジニア達の習慣 | Act as Professional

    いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしているエンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への対

    これはマネしたい!スーパーエンジニア達の習慣 | Act as Professional
    d_akatsuka
    d_akatsuka 2011/01/16
    良い習慣。出来るところから実践していこう
  • エンジニアのこだわりと、継続的開発、チャレンジについて。

    前職の頃からよく言うフレーズなのだが、受託をずっとやってきたエンジニアが面接に来た時に、「誤解を恐れずに言えば」という前置きとともにこういうことを言うことがある。 「サービスの開発は退屈ですよ?」 Facebookやtwitterや、若年層向けの携帯SNSや、それに従属するソーシャルアプリのような鬼のような成長をするサービスはよくわからないが、それ以外の従来からある、数多くのWebサービスにおいてエンジニアに求められるものは、如何に目の前の日々レガシーになっていくコードを安定的にメンテナンスしていくか?というサイクルになる。 安定成長するネットビジネスは「ストック型」である。お客様がそのサービスを使い始めて、使い終えるまでの期間を生涯価値として、今まで開発したコードで「サービス」を利用する。 その生涯価値がマルチスレッドのように重なることで、毎月安定的にユーザーが増えて行く仕組みである。と

    d_akatsuka
    d_akatsuka 2011/01/14
    "我々はサービスを提供しているのであって、プログラムを提供しているのではない。"
  • 1