仕事で親切と言われ始めたら注意 - Konifar's ZATSU
仕事において親切と言われ始めたらちょっと注意したほうがいいと思っていて、その話を雑にまとめておきたい。 親切と言われるともちろん悪い気はしないんだけど、同時にやばいなと感じることがある。親切と言われる背景には、「本来その人がやるべきでないタスクを拾っている」場合があるからである。 誰かがやらなければいけないのだけれど、毎回同じ人がやることになってたりすると属人化するしあまりよくない。チームで捌けるように工夫できないか検討したほうがいい。 実は突き詰めると意味のない仕事だったと気づいたり、自動化で解決したり、他の人でもできるようにドキュメントにまとめて共有したり、そういうことができてないから毎回手を動かしてしまう。結果、親切に映って感謝はされるんだけれど、本当は効率よく仕事ができてないことを反省しなければならなかったりするのだ。 もちろん状況による。あと信頼関係を築くためにあえて親切な動きを
スタートアップに向いてる人の特徴 - @kyanny's blog
会社がスタートアップだった頃に「この人いざってときに頼りになるなぁ…」と思った人たちには、共通する特徴があると思う。 プロフェッショナルだけど、サラリーマンではないのだ。 仕事に対する責任感が人一倍強く、締め切りを守る。そのためならオーバーワークを厭わない。基本的に物事を他責にせず、周りがどうだろうが自分の責任として仕事を完遂する。無茶な要求にはきっぱりノーと言うが、現実的な代案を提示して着地させるし、そもそも「無茶」と判断する基準が高すぎるので、並の人ならとっくにサジを投げるような仕事も涼しい顔で片付ける。 それほど自分の仕事を終わらせることにこだわるのに、「仕事だから」を逃げる理由にしない。自分の仕事はここまで、とか、この仕事は他の人・チーム・部署の仕事だろう、とか、残業することになってしまうので、とか、基本的にそういう言い訳をしない。また休出しちゃったよ、などと軽口を叩くこともあるが
コードを書くには連続した2時間が必要 - hitode909の日記
ある日の午後のスケジュールは、30分ミーティングx2→30分自由時間→そして1.5時間ミーティング、その後は30分自由時間と30分ミーティングを繰り返して定時を迎える…みたいな様子だった。案の定、自由時間で意味ある仕事を進めることはできなかった。 自由な時間が30分あれば、チャットを読んだり、コードレビューしたり、グループウェアを見て回ったり、とかはできる。コードを書くにしても、ここをこう変えれば良いことがわかっていて、書くだけ、とか、ライブラリのバージョンアップ、くらいなら30分で書いてpushしておいて、次の30分でテストが落ちたら直したりして、と進められる。 しかし、そういうことより難しいことをしようとすると、30分だと、さて、問題がどういうものかは分かってきたので、どうしようかな、というあたりで時間切れになってしまう。1時間あれば、ようやくコードを書き始められるかな、というところで
「マネージャーへの期待値上がりすぎ」問題について｜とくさん｜MYCOPING
最近よく思うのは、経営陣からもメンバーからも、マネージャー（中間管理職）への期待値が上がりすぎてるのではということ。経営陣からは事業を現場でリードする責任者として、メンバーからは頼れる相談者・メンターとして、というのを「同時に」期待されるようところがあって、これはとても難しい。私も日々の仕事でマネージャー達を眺めながら、苦戦している人が多いなという印象を持っている。 まず、事業の責任者としての役割。この点については、この記事で書いたように、マネージャーの仕事は「意思決定」である、というところでつまづく人が多い。 マネージャーになる人は、多くの場合は現場の仕事で優れた実績を上げてきたことが前提となっているので、いざ管理職になったあともその強みで勝負しようとしてしまう。 けれど、組織がマネージャーに期待しているのは意思決定だ。限られたリソースを前提に、それをどこにどうやって割り振り、メンバーた
プログラミングを目的にしてもいいと思う | κeenのHappy Hacκing Blog
文系でプログラマーになったけど色々失敗して３年半で会社を辞めた話｜denkigai｜noteという記事を読みました。 この記事に書かれていることが私の身にも覚えがあります。特に私と同い年の方のようなので自分に重ねてしまうところもあります。 ですが多少似たところはあってもやっぱり他人なので全然違う体験もしています。そういう体験を書いてみようと思います。もし該当記事を読んで絶望した人がいるなら別の例もあるよということで参考にしてください。 私は「パソコンの中身が知りたい。多分プログラミングとかいうやつを勉強したら分かる気がする。」くらいのモチベーションでプログラミングをはじめました。 ゴールがあやふやですし、結局のところ「プログラミングをする」が目標になってるので迷子になるのは必至ですね。実際そういう時期がありました。 そんな私でも今はプログラマとして生きています。以下に、私が遭遇した課題とそ
転職します | skyplace
4年ほど勤めていた株式会社ドワンゴを8月末で退職し, 転職することしました. 実のところ2ヵ月前には決まっていて, 1ヵ月前には実務的には全て終えて有休消化中だったりします. 退職日は大分先なのに書いてもな, ということで退職日が今週末に控えたので, ブログの形でご報告させて頂きます. 今までどういう仕事をやってきたか 配信バックエンドの新規開発 最初の2年ほどは, ニコニコ動画/生放送の配信バックエンドの新規開発に携わっていました. 新配信, DMCといった単語で露出している箇所になります. 非エンジニアの方に説明すると結構大変なのですが, 動画の例で言うと, 各デバイス向けに動画をエンコードし, 各デバイス向けの配信プロトコルやコンテナに詰め替えて視聴できるようにし, 実際に配信するところまでがシステムの範疇です. 説明下手ですね. デブサミ2017の資料が参考になると思うので, 興味
採用基準における「地頭のよさ」とは何か - Konifar's ZATSU
どんな人を採用するかという会話の中で、地頭がいい人がいいよねという話になった。 なんとなく言いたいことはわかるが、同時に「地頭がいいって何だろうな」という話にもなり、結局結論は出なかった。 出なかったんだけど、やはり採用を強化する上で採用基準が明確じゃないのはよくないので、「地頭のよさとは何なのか」について雑に書きなぐって整理しておきたい。ちなみにこれを書いてる今も「何なんだろうな？」と思っているのでうまくまとまるかはわからない。 問題解決能力なのかなと思ったが、地頭のよさというのはその一部な気がする。問題を解決するためには色々なプロセスが求められるが、地頭のよさはそのうちのひとつでしかない。 じゃあもう少し分解して「問題定義」と「問題解決」にしてみると、なんだか問題定義の能力の方が地頭のよさに近いんじゃないかと思えてきた。思い返してみると、地頭がいいなーと感じる人って、会議中の発言でも何
就職して 6 年過ぎた
新卒のソフトウェアエンジニアとして Google に入社して丸 6 年が過ぎました。「若者は 3 年で辞める」という話があるけど、その二倍も働いていることになります。当時の気持ちを忘れないうちに今までの振り返りをしてみようと思います。 (2019/04/04 追記) 入社までの話を「新卒のソフトウェアエンジニアになるまで」という記事に書きました。 なお、すべて個人的な体験談であって会社の見解等を表しているわけではありません。 きっかけ Google を意識したきっかけは大学一年生の頃に読んだ梅田望夫さんの『ウェブ進化論』でした。多分同世代の多くの人がこの本に影響を受けたんじゃないかと思います。私も「これからネットの世界はどんどん変わっていくんだ！」と興奮し、その中心的な会社だった Google に憧れを持ったことを覚えています1 。 直接的なきっかけは修士一年生の頃。そろそろ就活に向けて動
リモートワークと感情に依存した働き方について - 表道具
気がついたら「リモートワーク」と名の付いた記事が3本目になってしまった。 まとめ 普段感情を出すなって言われてるのに，相手の感情を読み取ることが仕事に必要だという状況がおかしいので，感情を表に出せる環境のほうがいい 対面でのコミュニケーションでは，無駄に感情が必要になる。いろいろな方法を使って相手の感情を読み取ったりする場面を減らした方がいい。その方が安心して感情を出せる リモートで感情がわかりすぎても困る。プライベートは大事にした方がいい speakerdeck.com 何日か前に id:daiksy さんのこのスライドを見てから調子が悪く，何かモニョっとした感情が頭の中を渦巻いている。 というのも，このスライドで言われているリモートワークの難しさは，人が組織でやっていっていることがどれだけ感情という基盤に乗っているかということを浮き彫りにしているからだ。 スライドの方を見てくださればわ
信用できる社内 Wiki をつくるために守ってほしい、たったひとつのルール - 無印吉澤
このページについて この記事は、以前書いた「社内Wikiに情報を書くときに守ってほしい、たったひとつのルール」の続編です。前回は、個々のページをどう書くべきかという話をしましたが、今回は社内 Wiki 全体を信用できるものにする方法について考えます。 muziyoshiz.hatenablog.com 想定する環境 この記事は、ソフトウェア開発プロジェクトに関する Wiki が社内にあって、そこに各人がドキュメント（仕様書や手順書など）を書けるようになっている環境を想定しています。 私自身、ソフトウェア開発のときしか Wiki を使わないので、具体例もそのような環境に寄っています。ただ、ある程度は社内 Wiki 全般に通じる話かと思います。 ルール：「更新され続ける」ページと「更新されない」ページをはっきり分ける ここ1年ほど社内プロジェクトをいくつか渡り歩いていたのですが、個人的には、こ
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
採用プロセスを真剣に考えろという話
人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか？」期待値を明文化している
あるエンジニアの緩慢な死、あるいはエンジニア35歳定年説。 - Qiita
「エンジニア35歳定年説」が許されるのは小学生までだよねーとか思っていたら、実際にはそんな感じになってしまったあるエンジニアの半生を振り返ります。ご参考まで。 第一期 サービスリリース前 自分でサービスをガリガリ作っている というかサービスを作ることしかしていない １日１６時間くらい仕事をしても、プログラミングしかしていないので疲れない 仕様の検討をしながら作るので、基本全ての時間は開発をしているという認識 フルスタックエンジニアというある種の全能感を満喫する 第二期 サービスリリース後 運用（ユーザーサポートなども含む）が入ってくるのでサービス開発のスピードが落ちる エンジニアを採用（業務委託含む）する 仕様の調整やコードレビューなど、開発以外の仕事が少しずつ増えてくる でもまだまだ自分が圧倒的にメイン開発者 コードレビューやマージ、リリースは自分が全てやる システムの全体からディテール
おまえらの履歴書はつまらん - arimoつくったメモ
新卒・中途どちらも就職活動をしているとどうしても会社から履歴書をかけとか言われる。 この履歴書こそが会社に自分を見てもらえる第一歩なのである。 だいじなことは最初に言うよ お前の履歴書はつまらん！ かの有名ジョブホッパー@kwappa先生もやっぱり言ってる※1 引用： #CROSS2013 アンカンファレンスで喋る | Kwappa研究開発室 それでは突然ですが1社目から転職するときに使った履歴書を見てみましょう（※文章は適当） 本記事のタイトルは完全に煽ってますが、1社目から転職するときも、自分にはこれといってすごいスキルがあるわけじゃないし、なんだかどの技術も中途半端だし、しゃべりも超どもっちゃうし、あの白黒の履歴書と白黒の職務経歴書だけで全然いいところを見せられる気がしなかった。 もうこれは履歴書インパクトでいって面接までぜひともこぎつけたいという思いが強かった。そしたらこうなったわ
グッドパッチに入って1年ちょっと経ちました。 - it's an endless world.
嫁がブログを始めたのに触発されて、ブログの更新を復活させようかと。 ここ一年ちょっとやっていたこと 昨年の7月に(倒産のニュースが先日なぜかほってんとり入りしていた)アプリカというソーシャルゲーム開発会社を退社して、そのままグッドパッチにフロントエンドエンジニアとしてジョインしました。 Goodpatch, Inc. - Designing the WOW! グッドパッチどんな感じ？ かなり良い感じです。良い会社。 ブランドイメージが強いこともあって、楽しそうな案件が次々と舞い込んでくるのはかなり嬉しい。 そのおかげか、html5j界隈で有名なid:sadahや、去年ポートフォリオサイトが話題になったid:yoshiko_pg、前にmixiのJavaScript研修資料がバズった重田さんなどなど素敵なエンジニアさんたちがどんどん入社してきてるのも面白い。 もちろんエンジニアだけでなく、元グ
エンジニアとしての落としどころを作る | こえむの編集後記
コンピュータのエンジニアをやっていると、技術を高めたい、最新の技術を得たい、そして尖ったエンジニアになりたいと一度は思うものです。ただ、僕はそれらは諦めて、今年からは自分なりの落としどころを作ってやってみることにしました。 では、落としどころとは何なのか、です。のんびり考えていた中で、方針を決めてみました。 問題解決に関わる立場であり続けることを念頭に置く 最も効率よく開発・改善し続けられる技術を選択する 泥臭く・人懐っこくやる 仕組みを作る立場であり続けることを念頭に置く 僕はソフトウェアエンジニアとして転職を何度かしています。仕事をする中で、現在いる・過去にいた組織のどの上長も評価して頂いていたのは、人・お金・情報のバランスを取りながら、ソフトウェアを基盤にした仕組みを作って結果を出している点でした。 ソフトウェアエンジニアでありながら、最高の技術を導入したとか、最新の技術を普及させた
クックパッド×はてな×nanapi開発トップが見てきた「伸びるエンジニア」ってこんな人 - エンジニアtype
クラウド技術の進化や開発ツールの充実などを背景に、Webエンジニアに求められる開発知識は日々更新され、右肩上がりに高度化していっている。常に成長し続けることなしに、エンジニアが理想的なキャリアを描くことはできないと言っていいだろう。 そんな状況下、柔軟に知識と経験を増やしながら伸びていくエンジニアと、そうでないエンジニアとでは何が違うのか。弊誌姉妹サイト『＠type』が主催する『エンジニア適職フェア』（東京ドームシティ）でこのほど、優秀なエンジニアを輩出することで名高いIT企業3社の開発トップを招き、「エンジニアが成長する職場の条件とは？」をテーマにトークセッションを開催した。 《登壇者》 ■クックパッド株式会社 執行役 最高技術責任者 舘野祐一氏 ■株式会社はてな 執行役員 サービス開発本部長 大西康裕氏 ■株式会社nanapi 取締役 執行役員 CTO 和田修一氏 エンジニア育成の取り
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
wikihub.io
webディレクターの転職