タグ

エンジニアに関するd_akatsukaのブックマーク (60)

  • エンジニアとしていかに成長するかについて、GMOグループの新卒エンジニア・クリエータの皆さんにお話した - Kentaro Kuribayashi's blog

    GMOグループにはGMOテクノロジーブートキャンプという新卒エンジニア・クリエータ向けの研修メニューがあって、そこでなんか話してくれという要請があったので、「エンジニアになる」というタイトルで、エンジニアとしての成長について、少しお話をしてきました。 自分自身がエンジニアとしていままでどうしてきたかみたいな話は、まとまった形ではこれまでしたことがなかったわけですが、立場上とか年齢的にも「僕ごときが……」とかいってもいられないので、恥を忍んでスピリチュアルな話をしてみました。以下、ご笑覧くださいませ。 いいたいことはだいたいスライドに書きこんだのですが、以下、ちょっとだけ補足。 このスライドを作っていた時に、ちょうど「現場ロックイン」についてのエントリが話題になったり、また、このエントリを書く直前にも似たような話題のエントリを見たりしました。 現場ロックインが技術力さげてるのかもしれない -

    エンジニアとしていかに成長するかについて、GMOグループの新卒エンジニア・クリエータの皆さんにお話した - Kentaro Kuribayashi's blog
  • エンジニアスタートアップは1人でいいから通訳を雇ってくれ - マーケティング日和

    2015-03-19 エンジニアスタートアップは1人でいいから通訳を雇ってくれ 「エンジニアの言葉を通訳する人間が必要」 前の会社でよく言われていた言葉であり、「通訳」が必要なくらいエンジニアとビジネス側には隔たりがあるのだ。 私はマーケティングやファイナンスの人間だ。何をやっていくら儲けるかを考えるのが仕事。なので、無駄なコストをカットして、注力すべきところに投資したり上手にヘッジすることがミッションだ。 だが、その仕事の中でやっかいな存在にあたるがエンジニアだ。 彼らは何をしているのかよくわからない。外注のデザイナーやコーダーは何を作っているのかがよくわかるけど、正社員メンバーの、システム基盤?だのアルゴリズム?だのやっている人たちについてはまったくパフォーマンスがわからない。 部署横断のミーティングなんかやると温度差に驚く。 営業「営業の仕組みを変え、売上をキープしつつコストをダウン

    エンジニアスタートアップは1人でいいから通訳を雇ってくれ - マーケティング日和
  • エンジニアの呼吸を支える技術 - pixiv inside [archive]

    こちらは ピクシブ株式会社 Advent Calendar 2014 の12/24の記事です。 エンジニアは知識労働がメインとは言え、身体が資であることに違いはありません。 そこで今回は、私 @Moyashipan が鼻の手術を受けた体験を通して、エンジニアの呼吸を支える技術についてお話ししたいと思います。 いつからか仕事中に頭痛を感じるように 2012年の春。仕事中に鼻が詰まりやすくなり、それにより頭痛を感じることが多くなっていました。 そしてある日、出社後に自分が風邪気味であることに気づいた時、鼻呼吸ができないほど鼻が詰まっていることにも気づきました。 短期的な解決が長期的には悪化を招く可能性 鼻詰まりがあまりにも辛かったので、薬局に行って鼻詰まり用のスプレーを買って使用してみました。 すると、これまでの人生で体感したことが無いくらいに鼻が通るではありませんか。 それまでの「普通」に

    エンジニアの呼吸を支える技術 - pixiv inside [archive]
  • http://blog.inouetakuya.info/entry/2014/12/08/214435

    http://blog.inouetakuya.info/entry/2014/12/08/214435
  • サービス開発エンジニアからマネージャになった話 - クックパッド開発者ブログ

    はじめに こんにちは、レシピ投稿推進室の勝間(@ryo_katsuma)です。 techlifeでの執筆は5年ぶり(!)になります。 さて、そんな私も今年2014年の5月にエンジニアからサービス開発の部署のマネージャに転身しました。 そこで今回のtechlifeブログは、いつもの技術ネタとは少し異なるテーマとして、「クックパッドにおいて、エンジニアからマネージャに転身する」ことが、どういうことなのかを自分自身で振り返り、まとめたいと思います。 エンジニアが自身のキャリアを考える上で、少しでも参考になれば幸いです。 現状 私は、2009年5月に中途入社し、今年で6年目になります。この年数は、エンジニア全体はもちろん、社内全体で見ても古い方になります。 これまで、技術部、HappyAuthor部(現在、私が所属している前身になった部)、新規事業部、プレミアム会員事業部...など、いろんな部署で

    サービス開発エンジニアからマネージャになった話 - クックパッド開発者ブログ
  • KPTで粘り強く品質改善に取り組んだ話 - クックパッド開発者ブログ

    はじめに こんにちは、モバイルファースト室の@y_310です。 部署名からもお分かりの通りクックパッドでは今年からスマートフォンアプリの開発に特に力を入れて取り組んできました。 実際に昨年と比べて開発体制が大きく変化しています。以前はアプリ開発専門のエンジニアのみで開発していたものを、サーバサイドエンジニアもアプリ開発を学び、自分が所属する部署に必要な機能をアプリに実装するようになりました。 そのため、以前は2、3人のチームでの開発だったものが、現在は多い時には複数の部署にまたがって10人ほどのエンジニアが1つのアプリにコミットする状況になりました。 そのような環境の変化によりアプリの品質維持が大きな課題となり、この半年間継続的に品質改善に取り組んできました。今回はその改善プロセスについてご紹介したいと思います。 課題 取り組みを始める前は、様々な部分で課題がありました。 具体例を上げると

    KPTで粘り強く品質改善に取り組んだ話 - クックパッド開発者ブログ
  • 「プロダクトマネジャー」と「職人的開発者」という2つのキャリアパス【連載:えふしん】 - エンジニアtype | 転職type

    Twitterクライアント『モバツイ』開発者であり、2012年11月に想創社(version2)を設立した有名エンジニア・えふしん氏が、変化の激しいネットベンチャーやWeb業界の中で生き残っていくエンジニアの特徴を独自の視点で分析 えふしんのWebサービスサバイバル術 藤川真一(えふしん)氏 FA装置メーカー、Web制作のベンチャーを経て、2006年にpaperboy&co.へ。ショッピングモールサービスにプロデューサーとして携わるかたわら、2007年からモバイル端末向けのTwitterウェブサービス型クライアント『モバツイ』の開発・運営を個人で開始。2010年、想創社(現・マインドスコープ)を設立し、2012年4月30日まで代表取締役社長を務める。その後しばらくフリーランスエンジニアとして活躍し、2012年11月6日に想創社(version2)設立 BASEでエンジニア、デザイナーを募集

    「プロダクトマネジャー」と「職人的開発者」という2つのキャリアパス【連載:えふしん】 - エンジニアtype | 転職type
  • 仕様の決まる速度で実装する - mizchi's blog

    最近プロトタイピングの仕事が多くて、とにかく雑に実装して、これでいいかデザイナかディレクターに確認とって、そこでリファクタみたいな過程をとることが多い。技術的にどこまで可能か未検証で、かつ仕様もはっきり決まっていないので、手戻りを最小にするためにとにかく早い段階でデモをみせる。 技術的にどこまで可能なので、どうすると開発が楽で、どこから先が大変で、どこから先が不可能かを説明しながら、その場で仕様の隙間を埋めたり、時には仕様を変更することがある。プロトタイピングの段階で勝手に一部の仕様を決めちゃって、事後追認してもらってるときもある。そこで、説明しながらその場でコードを書いてる。 エンジニア同士のペアプロは、コードを書く過程そのもの意味があるから、すべての過程をみせることに意味があるんだけど、非エンジニアに自分の席の隣に来てもらって、説明しながらの作業だとエディタを長い時間みせるわけにはいか

    仕様の決まる速度で実装する - mizchi's blog
  • 「技術的負債」の返済ルールを作る 株式会社ドワンゴ 清水俊博 氏 | ギークアカデミー | dodaエンジニア IT

    中堅SIerを経て2009年にドワンゴに中途入社。複数のシステムの開発に携わった後、エンジニアの生産性を高めることをミッションとする部署の立ちあげに参加する。趣味はプログラミングとネトゲ。 ドワンゴ清水俊博氏にドワンゴのエンジニア文化について聞いた。2012年4月の第1回「ニコニコ超会議」の後、ドワンゴのエンジニアが大量退職するという危機的な時期があった。エンジニア文化を立て直す社内組織に参加した経緯を聞く。 ──転職のきっかけはコミュニティ活動とのことですが、当時参加していたコミュニティjava-jaの雰囲気をお聞かせください。 java-jaでは、スキルがある人たち、技術力がある人たちに囲まれていました。ヨシオリ(java-jaを立ち上げた庄司嘉織氏、清水氏の元同僚)も当時はSI業界にいて、互いに話をして共感しあい、友人になりました。 java-jaは、ヨシオリが「勉強会」という呼び名

    「技術的負債」の返済ルールを作る 株式会社ドワンゴ 清水俊博 氏 | ギークアカデミー | dodaエンジニア IT
  • プログラミングに特化した日本語Q&Aサイト「teratail」公開 

  • 新卒1,2年目に自己投資してQoL上がったもの - mizchi's blog

    この記事みた。 給料全部使う - yulily100's blog 自分はIT業界3年目のエンジニアで、2年間ぐらい、口座残高尽きるまでいろいろ買いまくっててたので、そのログ兼ねてQoL向上に貢献したものを載せておく。 注意点として、自分は大学生時代はほとんどバイトせずに月5万の仕送りで生きてて、何かと安物買いの銭失いしてた反省もあり、多少無理してでも良い物を買う傾向がある。 常飲用炭酸飲料:月2000円 目も覚める。おすすめ。 ジュースがぶ飲みしてたらめっちゃ太ったので無糖の炭酸水がいい。 アサヒ ウィルキンソン タンサン 500ml×24 出版社/メーカー: アサヒ飲料メディア: 品&飲料購入: 27人 クリック: 84回この商品を含むブログ (2件) を見る 自分の周囲はペリエ派とウィルキンソン派がいるけど、自分は炭酸が強いウィルキンソン派。 キーボード: 1万~3万 IT系に限

    新卒1,2年目に自己投資してQoL上がったもの - mizchi's blog
  • ITエンジニアの地位を落とす、日本企業の大きな誤解:日経ビジネスオンライン

    現代の企業においては、IT(情報技術)、そしてウェブをどう使っていくかが企業の成長のカギを握っている――。このことに異論がある方はいないだろう。 少し前までは、既存の業務を一部IT化し「わが社はITを活用している」などと生ぬるいことを言っていられる時代だったが、今ではIT、ウェブをベースにビジネスモデルを組み立てていないと勝ち目の無い世界になりつつある。 グーグル、フェイスブック、マイクロソフトなどは言うまでもなく、今やITと全く無縁そうな回転寿司屋でさえ、ビッグデータを活用し廃棄量75%削減を達成している時代である(「スシロー、ビッグデータ分析し寿司流す 廃棄量75%減」:日経新聞電子版1月27日)。 しかし、これだけビジネスの中心にIT、ウェブが入り込んできている現在でさえ、IT、ウェブの中心を担うITエンジニア仕事について「製造業と同じようなもの」と勘違いしている人が非常に多い。

    ITエンジニアの地位を落とす、日本企業の大きな誤解:日経ビジネスオンライン
  • ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習

    最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識がになりました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない!vs. 現場に任せてくれない!の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン(あるいは権威勾配に関する一

    ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
  • CTO募集とかフルスタックエンジニア募集とか都合の良いこと言っちゃだめ - UNIX的なアレ

    若干釣り気味のタイトルです。CTO募集すること自体は悪くないんだけど、その内容についていろいろ思うことがあったのでちょっと書いてみます。 やたら見かけるCTO募集 wantedlyとかみるとですね、とにかくCTO募集している会社が多いわけですよ。そりゃITな会社つくるとしたらCTOはいた方がいい。 でもね、多くの社長が話すCTO像って別にCTOを求めてる訳じゃないんですよね。要するに、なんでもできるエンジニアが欲しいというだけのパターンが多い。 とくに募集要件みてもピンと来ないんですよ。別にそれってCTOである必要ないでしょ?と思ってしまう。例えば、 アーキテクチャの設計ができて スマホアプリできて サーバサイド開発もできて インフラもひと通りできて マネージメントできて イケてる提案もしてくれる あと、言うことは聞いてね みたいなことを考えてる人が多い。すごく多い。まずね、いないよそんな

    CTO募集とかフルスタックエンジニア募集とか都合の良いこと言っちゃだめ - UNIX的なアレ
  • ペパボのエンジニア評価制度をパワーアップした - Kentaro Kuribayashi's blog

    mizzyさんのエントリ(paperboy is hiring - Gosuke Miyashita)にある通り、ペパボでは、エンジニアに関しては一般のラインとは別に、専門職としてのキャリアアップをしていくラインがあって、ここ2年ほど運用され、よく機能しているところです。そんな折、技術基盤チームも陣容が充実し、社内にもその存在や成果が充分に浸透してきただろうというわけで、半年ほど前からあたためてきた新しい制度を、先日から運用開始しました。 今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。エンジニアであろうがなかろうが、一般に、事業目標をブレークダウンしたものが個々人の目標 → 成果になっていくわけですが、そうしたプロセスにおいて、より多様な観点からアウトプットの生産性を向上させて

    ペパボのエンジニア評価制度をパワーアップした - Kentaro Kuribayashi's blog
  • ScaleOut | Supership

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

    ScaleOut | Supership
  • スタートアップの人材獲得戦略とは何か - laiso

    スライド 以下は下書き http://www.zusaar.com/event/4557003 これで話す内容について書いた。 どんどん長くなってきて、2・3回草稿を破棄してしまったんだけどだんだん書ききることを飽きらめムードになってきたので先に文章で投稿することにした。 はじめに 最近いろんな会社の採用に携わっている人の話を聞いたり、を読んだりして感じていた「大企業に対するスタートアップはこんな感じで人を採用していってるんだなー」という話をします。 特定の会社の話ではなく、とくに新しい手法でもなくてリーン・スタートアップのエリック・リース的な最近こういうのが流行っているらしいねという自分の意見で構成し直したものです。 コンテキスト ソフトウェアエンジニアの話です 東京のウェブ界隈の話です 経験者採用についてです ここでいうスタートアップは新興のビジネスを行うベンチャー企業ぐらいの意味で

    スタートアップの人材獲得戦略とは何か - laiso
  • 新しいことをやる為の負荷と学習コストと迷子であることの自覚 - mizchi's blog

    読みにくい日記です。 一応今の会社はRubyRailsの会社ってことで通ってると思うんだけど、自分はほとんどRails触ったことなかったので、何かと色々やる必要が出てくる。 今はJavaScriptのフロントのタスクがあんまりなくてRailsやった方がいい感じで、じゃあ勉強がてらやるかって突っ込んだらちょっとウゥムって感じになった。 問題 勉強側に振ってしまいすぎたのもあるんだけど、かなり生産性低かった自覚がある。結局1週間やって出せたのがやりかけのPullRequest一件で、しかもwork in progress で残りお願いします… みたいな感じになってしまった。 で、今回新しいことをやるにあたって問題になったのは、次の点だと思った。 新しい登場人物の多さによる認知負荷の高さ パフォーマンス要件の厳しさ 最初からプロダクション前提の品質要求 ペアプロしてくれる人の確保 実は今の会社

    新しいことをやる為の負荷と学習コストと迷子であることの自覚 - mizchi's blog
  • ssig33.com - ダンピングをするな

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

  • チーム開発とクソコード - tototoshi の日記

    今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく

    チーム開発とクソコード - tototoshi の日記