「エンジニア35歳定年説」が許されるのは小学生までだよねーとか思っていたら、実際にはそんな感じになってしまったあるエンジニアの半生を振り返ります。ご参考まで。 第一期 サービスリリース前 自分でサービスをガリガリ作っている というかサービスを作ることしかしていない １日１６時間くらい仕事をしても、プログラミングしかしていないので疲れない 仕様の検討をしながら作るので、基本全ての時間は開発をしているという認識 フルスタックエンジニアというある種の全能感を満喫する 第二期 サービスリリース後 運用（ユーザーサポートなども含む）が入ってくるのでサービス開発のスピードが落ちる エンジニアを採用（業務委託含む）する 仕様の調整やコードレビューなど、開発以外の仕事が少しずつ増えてくる でもまだまだ自分が圧倒的にメイン開発者 コードレビューやマージ、リリースは自分が全てやる システムの全体からディテール
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
今年に入ってから毎日の開発時間を去年の半分にしてみた。 すると、毎日凄く集中できて、空いた時間に頭にスペースが出来てアイデアもわきやすく、効率もよくなったのでこれはいいかも。 タレブとDHHの話がきっかけ 最初のきっかけは、Rails作ったDHHが「開発なんて長時間やっても逆効果だから毎日の仕事時間を減らせ。8時間じゃなくて5時間、4時間だけにしろ。それだけ短かったらSNSなんて見てる暇はない。」とスタートアップスクールで話してたこと。 あと、去年タレブのAntifragileという本を読んで、短い仕事時間を毎日やるのが長期に渡っていいパフォーマンスを出す秘訣だというような事を言ってた。 アップストアでアプリを出すのは、結果が出なければ開発時間をいくらかけても価値が０となる世知辛い世界。でもこれは完全成果主義でなかなか面白い。 毎日の開発時間の成果をいかに上げるかっていうのを考えていると、
【サイボウズ式編集部より】この「ブロガーズ・コラム」は、著名ブロガーをサイボウズ外部から招いて、チームワークに関するコラムを執筆いただいています。今回は「My Favorite, Addict and Rhetoric Lovers Only」のファーレンハイトさんが考える理想的なリーダーについてです。 暴君のようなリーダーというのが存在する。彼らは横暴だ。人を人とも思わない態度で部下に接し、反論しようものなら烈火のごとく怒り出す。チームメンバーの感情は汲まれない。自分の意見でゴリ押しして進めようとする。 われわれは人間的に彼らを軽蔑しながらも、彼らを尊重する必要がある。なぜなら彼らこそがリーダーで、彼らこそが決定権をもっているから。逆らうと通るものも通らなくなってしまうのを経験上、知っているから。 今日はそんな横暴なリーダーこそが会社にとって貴重な存在だという話をする。 横暴なリーダーと
http://www.developingsales.com/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約6時間前 Jeff SzczepanskiはStack Overflowのマネタイゼーションの責任者。エンジニア転じて、営業の組織の長になった人物。 「営業というのは科学というよりは芸術。コンピュータ相手じゃなくて、人間を相手にしているからね。」 「営業が結果を重視するのは、計測しやすく公平な指標だから。どうなるか予想したりプロセスをうまく管理するのは難しいんだよ。」 という話しに違和感を抱き、「誰かが決めた営業戦略に従って営業マンは盲目的に数字の達成だけを求めてひたすら実行する。」という従来の営業手法は、 自分で手を汚してコーディングしない「アーキテクト」と呼ばれる人が仕様書をまとめ、下々のエンジニ
on_working_remotely_ja.md This is Japanese version of On working remotely - wonko.com by @rgrove. リモートで働くということ 昨日、Yahoo!は今後リモート環境での業務をやめるという新しい方針を社内で発表しました。 […] Beginning in June, we’re asking all employees with work-from-home arrangements to work in Yahoo! offices. If this impacts you, your management has already been in touch with next steps. And, for the rest of us who occasionally have to stay
gistfile1.md 入社から退職に至るまでの経緯 この記事は退職 Advent Calendar 13 日目の記事です。 本日が最終出社となりましたので、入社から退社までを振り返り整理しようと思い、この文章を書いています。 はじめに 自分語りなので興味ない人はさっさと戻ったほうが良いです。 簡単にまとめると、元々あまり執着ないしやることない、なんか最近クソみたいな社内ポリシーがいっぱい出来て萎える、話の合う人がやめることにしたから会社にいる意味を感じないため辞めるということです。 そもそも正社員希望じゃなかった まず、今の会社は自分の経歴の中で2社目になります。 新卒で入った会社を色々あって辞めたあと、しばらく気ままに開発ニートをしていました。 JavaScript を本格的に使い出したのがこの頃です。 お絵かきツールやPNGエンコーダ、zlib.js などはこの時に最初のバージョン
多くの仕事をこなしたにも拘わらず、目の前にはまだ片付けていない仕事が山積み状態。どうすればよいか？ 「深夜まで働き、週末も返上して仕事をすればよい」と考えたとしたら、それは間違っています。逆にさらに問題が生じるだけです。 一番最近関わっていたスタートアップ企業では、7日間で120時間も仕事をすることがありました。しかし、今思えば、あのとき誰かに「ちょっと休め」と言ってもらいたかった。なので、今回は「この仕事をすぐに片付けなければならないんだ」と言うのが口癖になっている方々のために、私の経験から学んだことをお伝えします。 「会社の英雄」になることの危険性 重要な締め切りの直前、プロジェクトの立ち上げ時、緊急のトラブル対応。初めての深夜残業や週末労働には、こうした理由があったことでしょう。自分がやらねばならない、という思いに突き動かされて仕事をし、目的を達成したときに得るものは「自分は会社の英
銀行系列の中規模SIerを退職し、 受託と自社サービスの開発を行っている小規模Web系に転職することになりました。 7/30が最終出社日でした。8/1からは新しい勤め先へ向かいます。 １．これまでやったこと ２．これからやりたいこと ３．なぜ転職しようと思ったのか なお、３はいわいる自分語りを含む上に長いのでご注意ください。 読ませる知り合いもいないのに何故書いた。 １．これまでにやってきたこと。 オープン系の基幹システムの保守開発に携わり4年ほど。 Java、COBOL、ExcelVBAをメインにやっていました。 もちろんSQLも普通に書いたりしつつ、触ったことのあるDBはOracle、PostgresSQL、SQLServer。 業務知識は主に流通系。Web開発とかもやりました。Javaでstruts1.Xとか、ASP.NETとC#とVBとか。 それと個人的欲求に基づき、Android
mediologic my thoughts on media/communication/marketing and everyday life. Search Primary menu 以前にいた会社の、自分がいた組織の離職者率が増えているのを聞いていると、それまで「働きたい会社」だったのが「辞めたくなる会社」になってきているということなのだろう、ということに悲しくなる。 ベンチャー的な気質をもった会社だと、「この会社、このプロダクトを使って何かをしてやろう」というチャレンジャーが集まり、その“志”がエンジンとなって前進していくものだが、あるタイミングからその会社がメジャーになってしまうと「入りたい会社」となってしまい、学歴だけよかったり、対して仕事ができないのに過去の会社での経歴を“華麗に言う”人間が増えてしまう。つまり実力者が入ってこない。またそういう傾向になると、「マネージャー」
現場のオペレーションを改善するために、最初に着手するなら何か？と聞かれたら、いつも「ふりかえり」から始めましょう、と答えています。かつてトラブルの起きているプロジェクトに入ったときも、まず始めたのは「ふりかえり」からでした。 「ふりかえり」とは、文字通り現場の活動を振り返って、改善のアクションを考えることです。反省会のようにも思えますが、すべてが終わってから反省する訳ではなく、現状分析を行って、うまく続けていくための未来を向いた活動です。 この記事では「ふりかえり」という習慣について、そして、ふりかえりを実践するにあたって、進め方とポイントについて紹介します。 ふりかえりの進め方”KPT”とは 上の写真は、私たちソニックガーデンで「ふりかえり」をしている様子です。ソニックガーデンでは弟子を採用していて、その弟子と師匠とのふりかえり風景です。このように、特別な道具はなにも必要ありません。必要
1. アイデアを 塩漬けにしない 世界中の人に手伝ってもらう方法 サイボウズ・ラボ 西尾泰和(@nishio) 2012-04-28 ニコニコ超会議 超エンジニアミーティングにて発表 1
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
