エンジニアの呼吸を支える技術 - pixiv inside [archive]
こちらは ピクシブ株式会社 Advent Calendar 2014 の12/24の記事です。 エンジニアは知識労働がメインとは言え、身体が資本であることに違いはありません。 そこで今回は、私 @Moyashipan が鼻の手術を受けた体験を通して、エンジニアの呼吸を支える技術についてお話ししたいと思います。 いつからか仕事中に頭痛を感じるように 2012年の春。仕事中に鼻が詰まりやすくなり、それにより頭痛を感じることが多くなっていました。 そしてある日、出社後に自分が風邪気味であることに気づいた時、鼻呼吸ができないほど鼻が詰まっていることにも気づきました。 短期的な解決が長期的には悪化を招く可能性 鼻詰まりがあまりにも辛かったので、薬局に行って鼻詰まり用のスプレーを買って使用してみました。 すると、これまでの人生で体感したことが無いくらいに鼻が通るではありませんか。 それまでの「普通」に
![エンジニアの呼吸を支える技術 - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/6d0d62bbcf654a9494a9c6ea527d4cfdcb50f9bf/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fm%2Fmoyashipan%2F20141222%2F20141222215454.jpg)
サービス開発エンジニアからマネージャになった話 - クックパッド開発者ブログ
はじめに こんにちは、レシピ投稿推進室の勝間（@ryo_katsuma）です。 techlifeでの執筆は5年ぶり（！）になります。 さて、そんな私も今年2014年の5月にエンジニアからサービス開発の部署のマネージャに転身しました。 そこで今回のtechlifeブログは、いつもの技術ネタとは少し異なるテーマとして、「クックパッドにおいて、エンジニアからマネージャに転身する」ことが、どういうことなのかを自分自身で振り返り、まとめたいと思います。 エンジニアが自身のキャリアを考える上で、少しでも参考になれば幸いです。 現状 私は、2009年5月に中途入社し、今年で6年目になります。この年数は、エンジニア全体はもちろん、社内全体で見ても古い方になります。 これまで、技術部、HappyAuthor部（現在、私が所属している前身になった部）、新規事業部、プレミアム会員事業部...など、いろんな部署で
エンジニアリングのマネージメント | GREE Engineers' Blog
こんにちは、岡崎です。最近はグリーのインフラチームにおける開発のマネージメントを担当しています。 このエントリーは「GREE Advent Calendar 2014」2日目の記事です。昨日は岸田さんによる「イノベーションが失われた組織から脱却する10のルール」でした。 さて、気がつけばここに書くのも昨年のAdvent Calendar 2013「開発ワークフローを、いつどう変えるか」以来です。去年は開発プロセスについてやってきた事の振り返り記事でしたが、今年も同じようにこれまでのプロジェクトを振り返りながら今回はエンジニアリングのマネージメントについて考えてみます。 エンジニアリングマネージャーとはどのような責任を持っているか エンジニアリングマネージャーとはどのような責任を持った役割でしょうか。本題に入る前にまずは「責任」という言葉の定義について確認しておきます。 「責任」と一言で言う
在宅勤務始めました - Line 1: Error: Invalid Blog('by Esehara' )
この記事について この記事はHeartRails Advent Calendar3日目の筈でした。 趣旨 HeartRailsに入社した。そこで、リモートを通じて受託開発などを行っている。ちょうど1ヶ月ほど経ったので、リモートワークに関しての所感をメモしておこうというのが今回の記事の趣旨。 なぜリモートワークをやろうと考えたの? 割と働き方で体調を崩すことが多くあったので、「これは自分の働き方を見直さないとマズイな」と思い、あまり一般的な働き方に囚われず、自分にあった働き方を見つけようと思ったのがきっかけ。そうなると、現状として二つの働き方があって、「リモートワーク」か、あるいは「短時間勤務」になるかなと考えたので、そのあたりを中心に見直した結果、HeartRailsの働き方がマッチしているかなと思ったので、そういう経路で働き始めたという経路。 リモートワークを中心にすることに関して不安は
若者と転職 - seri::diary
このエントリーはしょぼちむ Advent Calendar 2014 の21日目の記事です。 前日は @fukai_yasu さんの記事でした（まだ未登録？）。その前は@setoazusaさんのしょぼちむにテストファーストについて説明してみるでした。 しょぼちむご本人とは東京で働いていた頃に３回ぐらいプライベートでお酒の席でご一緒させて頂いたぐらい？の関わりでしょうか。何となくjava一派ということで仲良くさせて頂いていました。 お酒の席ではしょぼちむ氏に「いつ辞めるの？」と転職を持ちかけるネタでいじるのが一部界隈では定番なようなので、「若者と転職」というタイトルで駄文を書かせて頂きます。 しょぼちむ氏の参考になれば幸いです。 概要 私は2014年12月現在で28歳になります。 23歳で社会人になったので社会人としては丸５年半やってきたことになりますが、この5年半で3回転職をしています。
25歳定年説によせて - ✘╹◡╹✘
今日で無事25歳になりました。 去年とあるアドベントカレンダーの記事で25歳定年説について触れたけれど、いざ自分がその歳になってみると「確かに」と言った感じ。実際、周りのコンテキストを見てると、疲弊感、厭世感、アガりたい気持ち、結局一発あてられない風潮、その他もろもろが綯い交ぜになった茫漠とした不安が感じられることが多くなってきた。 その内、精神的な意味で体力というものが薄れ、週末にこういった活動に割く気力が無くなったとき、 ハッカーとしてはそこで死んでしまうのだと思う。そのことがただ悲しい。 何となくそういう予兆は感じられているし、あと2年もすればそのときは訪れると思う。 若者の界隈で、25歳定年説と呼んで震えている。 特にこの事実について何か主張があるわけではないが、ただこの社会は厳しいということに尽きる。 社会は厳しいの一言で思考停止するのをやめたい。 社会の斥力に負けて、心の弾力を
いつも受け入れられるとは限らない改善提案: 柴田 芳樹 (Yoshiki Shibata)
社会人となって30年間、様々なソフトウェア開発従事していた経験から言うと、改善提案は上位のマネージャや部門長に受け入れられる場合とそうでない場合があります。その中でも、問題が発生してから、その問題を解決するという改善提案は受け入れられることが多いです。しかし、発生するであろう問題を予測して、それに対して事前に対策を打つという改善提案は、理解されなくて、受け入れらないことがあります。 問題が発生してからの改善としては、ソースコード管理用のリポジトリは用意していたが、開発の終盤までビルドは、一人の開発者のPCでしかできなくて、ビルドを間違いなく行う必要がでてきて、やっとサーバで自動ビルドが一日一回行われるとかです。さらに、コードの品質が悪くてバグがたくさん出るので、FindBugsなどの静的解析ツールを導入して改善しますと言った提案です。しかし、静的解析ツールを導入した時点ではすでに遅く、すべ
ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり
35歳がプログラマとしてきのこるためには（あるいはきのこらないためには） - 亀岡的プログラマ日記
スタッフ兼、一参加者として参加してきました。 プログラマ35歳定年説勉強会 - DevLOVE関西 | Doorkeeper 仙石さん、谷口さんのお話、かなり刺激を受けました。 エンジニアの心を持ちながら、ごくごく自然と、会社ではプログラミング一筋から徐々に離れていったお二人の経験談。でもそこに後ろ向きなところは一切なくて、「（詳細はぜんぜん違うとしても）こういうキャリアを積みたいなぁ」と、心から感じるものでした。 んで、まぁ個人的な感想です。 「35歳定年説」に思ったこと 最初に「35歳定年説」におもうことをざっくばらんに付箋に書いて、という流れだったので、そのとき書いたのは以下の様な話でした。 35にもなってただコードを書いているだけじゃダメだよ、という意味じゃないかな その年くらいには「+α」を探しておかないときっとだめなんだろうな、と。 最近ぼんやり考えていることを素直に言葉にした
Javaエンジニア養成読本 - L'eclat des jours(2014-11-11)
_ Javaエンジニア養成読本 どこの誰かは知らないけれどJavaエンジニア養成読本をくださったので読んだ。 うまい。特に構成が。網羅性も。そして読みやすさだ。 こんな人に勧める。 普通にJavaを知っているが、Java8のストリームAPIについてはまだ知らない人。おれおれ。3部が簡潔にうまくまとまっていて、これ読むだけで十分だ（もしかするとおれはC#のLINQを知っているからかも知れないが、それでも問題ないんじゃないかな）。 これからJavaでコードをまじめに書く人。おれは2部を書いた人と意見が合わない点がたくさんあるが、それでもスタンダードに悪くない。やはり簡潔に必要だと思えることが網羅されていた。 Javaでしばらく食おうと思っている人。1部にきしださんがまじめなんだかふまじめなんだかよくわからないJavaの周辺情報（歴史とかカルチャーとか）を書いているのでこれの最後のところが役に立
組織も人も最適化の果てにあるのは緩やかな死
なんか会社のチャットネタが続きますが、先月、会社のチャットでマクドナルドの衰退と吉野家のリンクから最適化の話しになり、「もしトレタが最適化しすぎると、どういう風に発展の妨げになるんでしょう」って話しが出てちょっと面白かったのでブログにまとめて見ることにしました。 私がアプリ開発で一番怖いと思うのは、既存ユーザへの最適化です。 既存ユーザはある程度使いこなした上で「あの機能が欲しい」と要望を出してきます。確かにその機能があると便利ですし、他のユーザでも喜ぶ人が大勢います。 実際、その機能実装すると多くのユーザが便利になり満足度があがります。画面にボタンは増えましたが使わないユーザが不便に思うほどではありません。 誰も困らないし、この機能追加はとても正しいことに見えます。 でもその機能があることで、初めて触るユーザはどう感じるでしょうか？画面にボタンが多いほど、マニュアルが厚いほど初めてのユー
エンジニアリングとして考える株式投資 | fladdict
デザイナとかエンジニアたるもの、「人生において確実にあがる方法」をデザイン／開発して、自ら実験台となって証明することは神聖な義務であると思うなど。 社長になると、将来のことまぁ色々考えなければならないわけです。メンドクせえ。 投資や資産運用という概念を、自分なりに咀嚼してみた結果、以下のような結論になった。やはり専門の人に聞くと、色々と用語とか計算とか間違ってるとこもあるので、要修正。 投資とは何か？ ざっくり言うと、下記のような期待値の式を満たすギャンブルを投資という。式を満たさないものは金をドブに捨てるのと同義である。 勝率 * 利益率 + 敗率 * 損失率 > 1.0 例えば「100万円を投資すると50%の確率で200万円になり、50%の確率で50万円に減るというギャンブル」がある場合、上記式に当てはめると 0.5 * 2.0 + 0.5 * 0.5 = 1.25 となり期待値が1.
エンジニア/エンジニアリングのビッグピクチャ - Kentaro Kuribayashi's blog
社外のある技術者たちと「会社のエンジニア、あるいは、エンジニアリングがどうなっていくべきかというビッグピクチャみたいなものがあるか？」という話になった。その場ではいろいろな内容が出てきたわけだが、不詳わたくし、技術責任者という役職を務めている者としてどう思うかというと、そんなにかっこいいことを考えているわけではなかったりする。実際にかねがねいっていることがあるとすれば: 変化に対応できるよう、エンジニアとして成長しつづけよう 他のひとにない、何か自分が一番の得意分野を作ろう というぐらいである。このフレーズだけでいえば、なんのことはない、いってみれば当たり前、というか、誰でも思いつくような話だ。しかし、ことはそう簡単ではないと思っている。 ひとくちに「成長」といったところで、どれぐらい成長すればいいのかという問題がある。一番わかりやすい基準は、我々は上場企業であるということからいうと、市場
KPTで粘り強く品質改善に取り組んだ話 - クックパッド開発者ブログ
はじめに こんにちは、モバイルファースト室の@y_310です。 部署名からもお分かりの通りクックパッドでは今年からスマートフォンアプリの開発に特に力を入れて取り組んできました。 実際に昨年と比べて開発体制が大きく変化しています。以前はアプリ開発専門のエンジニアのみで開発していたものを、サーバサイドエンジニアもアプリ開発を学び、自分が所属する部署に必要な機能をアプリに実装するようになりました。 そのため、以前は2、3人のチームでの開発だったものが、現在は多い時には複数の部署にまたがって10人ほどのエンジニアが1つのアプリにコミットする状況になりました。 そのような環境の変化によりアプリの品質維持が大きな課題となり、この半年間継続的に品質改善に取り組んできました。今回はその改善プロセスについてご紹介したいと思います。 課題 取り組みを始める前は、様々な部分で課題がありました。 具体例を上げると
2015年問題と3年後のIT業界について - novtan別館
問題の本丸みたいなところにいるとひしひしと感じるいろんなこと。 とにかく人が足りない。いや、ぶっちゃけ人は足りてる。人材が足りない。半分はいない方がマシ。いなくてもアレやらコレやらがあればできるし品質は上がる。偉い人にはそれはわからない。なぜなら100点を目指しているから。95点を取ることは割と簡単なんだけど、100点を目指すと95点の10倍の労力が掛かった上に85点くらいにとどまってしまうリスクが物凄い高い。残り15点をどうするって？ひたすらやるだけさ。 人手不足というのは幻想なので、エンジニア不足の現状においてもクズエンジニアは雇わない。新人でもいいからかき集めろみたいな記事が出たことがあったけど、新人の方がまだクズでない可能性が高いというくらいは人材は不足している。クソみたいなエンジニアのおもりをしなければならないせいで。 問題は、システムの開発ヒエラルキー（これは単に契約関係でしか
アプリのリリースに必要な「引き算担当」について - @hitoshi annex on hatena
起業してアプリを出す。 一言で言ってしまえば簡単なんですけど、最初のそのアプリリリースの時に失敗する人が少なくない気がします。 僕の観測範囲だけでも、独立してアプリを出そうとして開発に失敗、「作り直し→リリース延期」となるケースを定期的に目撃しますので、それなりにそういう失敗をする人はいるんじゃないでしょうか。これが20代の若手が失敗したというならまだ分かるんですが、経営者としてすでに十分な実績のある、僕自身も尊敬するような方がその陥穽に陥ったりしていますので、これはもう能力とか才能の問題でなくて、むしろ「知識」の問題なんじゃないかと思うんですね。 そういう僕も、kiznaというアプリを出そうとして落とし穴にはまってしまい、結局日の目を見なかったという苦い経験をしていますので、こういう経験はちゃんと共有して、無駄な犠牲者が出ないようにすべきだと思うわけです。 というわけで、初めてアプリを出
スマートフォンは知的生産ツールとしての存在できるのか - FutureInsight.info
POBoxなどの画期的な入力方法の開発などで著名な増井さんの講演をまとめたエントリーを読んで、スマートフォンは知的生産ツールとしての存在できるのかについて考えた。 http://headlines.yahoo.co.jp/hl?a=20141012-00010002-etype-sci スマホも同じで、今流行っているのはジョブズに騙されているだけです（笑）。 昔はPalmなどで知的生産をしていましたが、今のスマホはメモも書きづらいし、絵も自由に描けるとは言い難い。つまり、知的生産に向いていません。 多くのスマホユーザーがやっているのは、流れてきたものを見るだけ。パチンコと何ら変わらない時間潰しのツールになっています。知的活動にも使えないし、受動的な人たちにとってもやりたいことがすぐにできないという、非常に中途半端なものになってしまっている。 僕の認識では、スマートフォンに知的生産機能を要求
SIer系エンジニアがベンチャーで働き始めるとぶつかる壁のリスト - IDEA and Players
元ド底辺SIerの私が心機一転、スタートアップに参加して約1年半が立ちました。 今後の自分の仕事を占う意味でも、ここらで自分がこれまでに感じたこと、悩んだこと、考えたことを整理しておこうかと思います。 もしも現在、SIer系の仕事をされていて、いずれはベンチャーで働いてみたいという人の参考になればもちろん嬉しいのだけど、ベンチャーってのは本当に千差万別で、ここで書いたことがそのまま他のベンチャー企業に当てはまるとは限らない、ということだけはご了承を。 「仕様」って言うな！ 最初の問題はこれ。 SIerにとって「仕様」って言葉は絶対的な意味があるわけですよ。 お客様から要求を聞いて、要件を定義して、「はい、コレコレこういうもの作りますよ。この製品ではこういうことができます。逆にこういうことはできません。よろしいですか？」と約束した結果が仕様だから当然と言えば当然。だからこそ、仕様を定めること
エンジニアにとって良い組織とは何かを知りたい? - naoyaのはてなダイアリー
「エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが･･･」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下の本を読むと良いかと思います。 How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメントposted with amazlet at 14.10.18エリック・シュミット ジョナサン・ローゼンバーグ アラン・イーグル 日本経済新聞出版社 売り上げランキング: 19 Amazon.co.jpで詳細を見る 小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則posted with amazlet at 14.10.18ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン 早川書房 売り上げランキング: 7,579 Amazon.co.jpで詳細を見る Tea
アイデアを出すことが企画だと思ってる奴は100万回死んでいい 島国大和のド畜生
・2023年03月 (1) ・2023年02月 (1) ・2023年01月 (2) ・2022年12月 (1) ・2022年11月 (3) ・2022年10月 (1) ・2022年09月 (1) ・2022年08月 (1) ・2022年07月 (1) ・2022年05月 (2) ・2022年04月 (1) ・2022年03月 (1) ・2022年02月 (1) ・2022年01月 (1) ・2021年10月 (1) ・2021年08月 (1) ・2021年07月 (2) ・2021年05月 (1) ・2021年04月 (1) ・2021年03月 (1) ・2021年02月 (1) ・2021年01月 (1) ・2020年12月 (1) ・2020年11月 (1) ・2020年10月 (1) ・2020年09月 (1) ・2020年08月 (2) ・2020年06月 (2) ・2020年04
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
