買い物リストはTrello、家族会議はSlackで。ママエンジニアの無理しすぎない育児プロジェクト - ぐるなびをちょっと良くするエンジニアブログ
こんにちは。エンジニアの小川です。約1年の産休育休を経て2016年に復帰し、ワーキングマザーとしての日々を送っています。主な役割は「ぐるなびまとめ」というコンテンツの開発チームリーダー。仕事内容は、チーム運営や案件管理などです。 ぐるなびのエンジニア職では産後に復帰する人が100％（2017年1月現在）*1。復職者向けの支援制度があり、妊娠・出産するママを会社がバックアップしてくれます。 今回は私の産休育休から復職までの体験や子育て・家事の経験から得たマインド、家庭での情報収集・共有方法などを紹介していきたいと思います。 妊娠発覚から産休引き継ぎまで 2014年の4月にレストラン検索のチームリーダーになった私は4月中旬に妊娠が発覚。一部上長には早め（4月下旬）に報告し、8、9月あたりから後任者（同じチームの後輩）への引き継ぎをはじめました。 引き継ぎ内容は、実務的なことよりチーム運営的な業
CTOがチームマネージメントじゃない方向に向かう時に何をするべきなのか - トレタにおけるmasuidriveの役割 2017年版 - トレタ開発者ブログ
トレタ CTOの増井です。 トレタは創業して3年半、エンジニアも2名から13名に増え、私の役割も変わってきました。 当初は一人目のエンジニアとしてアプリの設計やサーバサイドのコードを書いたり運用全般を行っていました。 人数も増え、2年を過ぎたあたりからエンジニアリングの中で私が率先してやる必要のあることがほぼなくなってきました。むしろ海外展開で出張が増え、連続した時間がとれずに進捗を遅らせる原因になってしまうこともありました。 最近の論調では、メンバーが増えるとCTOはマネージメントや組織作りに移行して行くみたいですが、私はそっちに興味が全然なく、向いているとも思えませんでした。そもそも私は上司を持ったこともないし、決められた環境の中で働くのがとても苦手なので。 私が「組織を作って管理して行く」のは無理というのはトレタ設立当初から分かっていたことなので、メンバーを増やす時は「自分で目標を作
エンジニアリングや研究開発について思うこと - 人間とウェブの未来
エンジニアリングや研究開発について思うことをこれまで色々とツイートしたりしてきたが、それを改めて短編エッセイ集のようにまとめて整理し、自分の行動原理や思考を言語化して振り返っていた。以下目次。 基礎を学び古典を知る サーベイと評価の重要性 論文という学習と貢献を両立する手法 企業でのスペシャリストに求められるさらなるスキル 技術への深入りの効能 インフラエンジニアのキャリア再び 技術という真にフェアな領域 エンジニアへの動機付けと教育 知識をコードで表現する専門職としてのエンジニア 技術に対する思考 技術力の醸成による先行報酬 エンジニアのアウトプットと個人の実績 アカデミアか企業か家族か 楽しいことと貢献とその評価を重ねる 技術と自由 技術が目的 基礎を学び古典を知る 技術力を高めたい、成長したいという前提において、基礎を学ばずに発想で勝負などと、勉強もせずに過去の天才達とに渡り合うほど
戦略家としてのリードエンジニア - 八発白中
先日THE PREDATORSのライブのためにZepp DiverCityに行った。 軽い気持ちで来たのだがチケットは完売。来場者は想像以上に多く3500人くらいはいたのではないかというほどの盛況だった。 入場してからまだ始まらないステージを眺めている間にも一同、テンションはやや高め。ガヤガヤとした空間で、後ろから一緒にきた仲間と楽しげに話す女性たちの声が聞こえてくる。 彼らは近隣の県から来たのか、昼に巡ったのであろう東京の名所について話をしていた。 「初めてちゃんと東京を観光したー」 「靖国神社とか近くまで行くことはあっても入ることなんてなかったもんねー」 「なんか銅像あった！」 「うん、なんか銅像あった。誰の像だっけ？」 「銅像あったしその像の名前も見たけど、なんて名前だったか思い出せない（笑）」 それを聞きながら僕は、それは幕末の長州の兵学者の大村益次郎ですね、と声をかけたい衝動に駆
ソリューションアーキテクトという仕事について - 工場長のブログ
ex-mixi Advent Calander 2017の12/12分のポストです。みんなエモいことを書いているのでわたしもエモいことを書くことにします。 ちなみに今日はわたしの結婚記念日で、嫁とはmixiで出会いました（物理/社内）。 で、テーマはソリューションアーキテクト（以下、SAと略します）という仕事について。もっとみんなにSAって何なのかというのを知ってもらいたいなと思ってます。SAってめっちゃ面白いよ！ってのを叫びたいのです。なお、本ポストではわたしがAWSでSAをやっていたときの話をしますが、あくまで経験や「わたしはこうやっていた」という話であって、AWSを代表する見解ではないことをご理解ください。 mixiには2010/2から2012/7までの約2.5年在籍していて、ずっと広告関連のアプリケーション開発をやっていました。自分のなかではものすごく体感時間長かったんですが、振り
エンジニアの英語力 - 怠惰を求めて勤勉に行き着く
TL; DR どれだけ努力しても"ネイティブ並"は無理なので諦めが肝心 エンジニアは英語ができなくても話を聞いてもらえるので「伝える意思」と「分かったか分かってないかを絶対に曖昧にしない」こと 謝辞 このエントリは弊Android Projectのビルド待ち時間を使って書かれています。Android Studioさんに感謝します。 ビルド待ち時間にブログを書かれたくない場合は弊社は僕に全部盛りiMacを買ってください。 前口上 英語力に関するエントリは盛り上がりやすく荒れやすい気がするんだけど、それはやっぱりみんな英語は出来たほうがいいに決まってるしさりとて英語を身につけるのは難しいよねってことが分かってるからだと思う。 僕はエンジニアの中では比較的英語が得意な部類に入ると思うけど、それでも全然充分だとは思わない。ただ、これでやっていけないか？というと全然そんなことはないので、一番重要なの
エンジニアが転職する時のチェックリスト - とりあえずやってみればいいじゃん
この記事は退職者その2 Advent Calendar 2017の17日目の記事です。 今年に入ってこれからの生き方を考えた結果、某社を退職しました、転職して3ヶ月。現在の話と勉強会復活のお知らせ。という2つの転職系記事を書いており、こっち方向のネタは尽きたので転職活動を焦点にした記事にしようと思います。 エンジニアが転職する時、いろいろな軸で会社の良し悪しを決めていくと思います。ただ、「自分では○○が重要だと思ってそればっかり見てたけど今にして思えば△△もちゃんと見ておけば良かった」となってしまう時もあります。なのでとりあえず会社を見る上でチェックポイントになりそうな項目をひたすら並べていこうと思います。この中で「これは重要だな」と思う項目があったら、転職活動する時に確かめてみてください。 ※ちなみにもちろんですが私は転職する時に以下に挙げる全ての項目をチェックしたわけではありません。単
新卒から12年エンジニアとして勤めた某外資証券会社を辞めてスタートアップにジョインした話 - itohiro73’s blog
本記事は退職者その2 Advent Calendar 2017の25日目の記事です。 adventar.org 僭越ながら最終日を担当させていただきます、@itohiro73 と申します、よろしくお願いします。 半年前ちょっと前にすでに入社エントリーは書いているので順序が大幅に逆になってしまっていますが、今回は退職者アドベントカレンダーということで、せっかくの機会なので新卒から12年も勤めた前の会社のことを振り返ってみようと思います。 前の会社について 世界的にもかなり大きい外資系証券会社でエンジニアとして新卒から入社して12年と1ヶ月半くらい勤めました。会社名に関しては、自分がかなり大々的にOSS活動等もしていたこともあり公開情報からちょっと調べればわかるところではありますし、本記事を読んで明らかにわかる部分もあります。とくに隠しているわけではないのですが、一応大人の事情としてあえて言及
日本のITエンジニアがイノベーティブでないのは暇じゃないからかもしれない - メソッド屋のブログ
ここ１ヶ月ぐらいは、海外のメンバーと仕事をしているが、Serverless Hackfest というイベントと、Serverless Conf やワークショップに関わっているので仕事量が増えていった。日本にいることだし、久々に「日本流」のハードワークをしてしまったのだが、一つ気づいたことがあった。それは、ここしばらくの謎だった、日本人のIT エンジニアはなぜイノベーティブな感じがしないのか？ということに対する問いだった。 Microsoft Hack week 日本人はイノベーティブ Rochelle Kopp さんとの仕事で知ったことで、一つとても意外だったことは、アメリカ人から見ると日本人は相当にイノベーティブに感じるらしい。 自分的には、少なくともIT 分野に関しては、向こうの真似ばかりしていて、後追いのイメージがある。私たちも向こうで生まれたツールやサービスばかり使っていて、全然日
業務メール書き方チートシート - tkm2261's blog
お久しぶりです。 今日は技術的な話題では無いですが、社外・社内にメールを出す時のテンプレ的なものを紹介したいと思います。 初めに言いますが、クッッソどうでも良い話題です。面接のスーツに何を着るかぐらいどうでも良い話です。 ただ、学生だと志望会社にメールを出すときに変に文面悩んだり、エンジニアだと社外にメール出す経験があまり無くて変に文面悩んだりとか、ここで悩むのは更に無駄なので、 ニートという身軽な身分のうちに、日本の会社で大体OKっぽいメールの書き方を適当に紹介します。 アホらしいですがメールの行間から仕事慣れてない感がでるとマイナス印象になったりもするので、それっぽいメールの書き方は知っておいて良いかもしれません。 自分もコンサルの新卒の時にいきなりクライアントにメールするのは怖かった記憶があるので、自分が学生の時に知りたかった内容的なのを書いておきます 業務メール書き方チートシート
なぜ grooves はフレックスでの深夜勤務を認めることができなかったか？ - Grooves開発ブログ
昨日 2月末に株式会社groovesを退職します を発表したエンジニアのマネージャーを務めている（2018年1月時点）赤川です。 本記事の前半では、なぜ彼が望む「フレックスでの深夜勤務」を用意できなかったかを紹介し、後半では彼と共にプロダクト開発に携わってきた立場から、彼の推薦文を書きます。 なぜこの記事を書くのか？ フレックス制度の導入を検討している会社の参考にしてほしい エンジニアの成長・キャリアアップを応援する Forkwell を運営している会社が、自社のエンジニアのキャリアアップや転職を応援しないのは嘘になるので、感謝をこめて送り出したい 今回の経緯 まず、今回の件について、彼とどのように会話を進めてきたかを紹介します。 2017年8月 1on1 MTG で、自身の生産性をあげるためにフレックスを導入したいと伝えられる。フレックスについて調査開始。 10月 エンジニアチームに、深
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
ソフトウェアエンジニアが当たり前にやるべき事 - そーだいなるらくがき帳
manabusakai さんの下記の記事を読んだ感想。 blog.manabusakai.com Twitterにも書いたけど僕は信頼されるエンジニアをずっと目指してきたし、そのために僕に必要なことがここには詰まっていた。 ほんとみんなに読んでほしい。 このエントリーの中の信頼を得ているエンジニアの姿を引用する。 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い方向に導いてくれる etc... まさに。 ではソフトウェアエンジニアとしてこの他に当たり前にやるべき事って何があるだろう？ ソフトウェアエンジニアとしてやるべき事 僕らは技術で問題を解決することで価値を高めたり、対価を頂いている。 例えば使っているOSSにバグがあったらどうだろう？ これは自戒をかなり含むが不満をSN
キャリアが気になる、35歳以降が気になるエンジニアのみなさんに43歳現役エンジニアからたったひとつのアドバイス - かっぱラクガキ帳
健康は命より大事。 repeat after me. 「健康は命より大事。」 以下蛇足。 ここでいう「健康」は、身体的なものと精神的なもの、両方を含みます。いずれも健康であれば、キャリア的分岐点も、人生の節目も、35歳を越えても、なんとかなる可能性があります。 どちらかの「健康」に不安がある状態で新たなる敵が出現すると、戦う前から打ちのめされた気分になってしまうものです。 まずは心身の健康にとって有害であるものから、少しずつ距離を取ることを考えてみましょう。自分を守れるのは自分だけ。自分の健康を守れるのも自分だけなのです。 ここ数日、キャリアの棚卸しや35歳以降のエンジニアライフについて言及しているテキストを多く目にしたので書いてみました。健康は命より大事。これだけ覚えて帰ってください。
50歳おっさんになるまでわたしがIT業界で２７年も生き残これた方法。 - 攻めは飛車角銀桂守りは金銀三枚
先日ふと思い立って50歳を前に「転職」を考えてみる・・・？という記事を書きました。 書いたあとで「あぁ、そういえばIT業界でなんだかんだと言いながら２７年ばかり働いてるのか・・・よく生き残ったなぁ」と。 IT業界は昔は（今も言うのだろうか）「35歳定年説」というのがあって、だいたい一線で活躍するのは35歳までで、技術者としてはそこまでで終わりと言われてました。 理由は日進月歩いやドックイヤーと言われる世界。その世界では若いもんには年寄りは勝てないと。それが35歳という年齢。 ちなみにドッグイヤーとは 俗に、IT業界の技術進化の早さを、犬の成長が人と比べて速いことに例えた俗語である。 1990代後半頃から用いられていた。 犬の1年は、人間の7年に相当すると言われている。 という意味。 実際は確かに集中力は衰えてくるが若者に技術的に負けるのではなく、上記に出した記事で書いた「技術者の単価」の話
【雑記】メンター業務をがんばってたら最強の後輩が産まれてしまった - 歩いたら休め
今年、いわゆるデータサイエンティスト的なスキルの後輩が入ってきて、私がメンターの役割を任されました（正確にはメンターになるはずのメンバーが抜けてしまい、早いタイミングで私が引き継ぎました）。 彼は、今時珍しく(?)、数学的な能力と、その手法を実世界に結びつけるセンスを兼ね備えて持っています。 ただし、プログラミングやエンジニアとしてのスキルは、入社時にはあまり持っていませんでした。 せっかくメンターになったので、ナントカっていう分析手法の話を「わかんねえなあ」って思いながら聞いてたり、「こういうこと勉強したらいいんじゃない？」とか唆したり、自分や同期がつらいと思っていたところを取り除いてたりしてました。その甲斐あったのかは分かりませんが、割と楽しんで仕事しているようだし、エンジニアとしてのスキルも順調につけていっています。 そこで、メンターの立場で心がけたことや、スムーズに業務できている要
初めての技術力評価会を終えたので感想を書いた - CARTA TECH BLOG
こんにちは、fluct SSP開発本部の@saxsirです。 今年の4月に入社した新人ですが、職場ではgolangとかAWSとかを使って社内向けのプロダクトをゴリゴリと開発しています。 さて、VOYAGE GROUPでは人事評価制度の一つとして技術力評価会という相互評価の仕組みがあります。 これは年に2回ほど開催されており、直近半年くらいの仕事から何かテーマをピックアップし、別チームのエンジニア2名（評価者）に「私はこんなすごいことをやったんだよ、どやっ」とお話しながら自分の技術力を評価してもらうという場になります。 もちろん、新卒も例外なく技術力評価会を行います。 今回は初めての技術力評価会を終えて私が学んだこと、を社外の方向けに書こうと思います。（言うまでもなく、私は被評価者です） ※以下、「技術力評価会」を「評価会」と略して表記する場合があります TL;DR 「なぜやったのか」を説明
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
4ヶ月の間に一休.comで起きた変化 - zimathon blog
概要 最近いろいろな方（社内、社外含め）に、エンジニアチームどうですか？良くなってますか？という質問を頂きます naoya さんってどうなんですか？やっぱりすごいですか？とも その度に「良くなってますよー」と返事をするのですが、肌感としてはあるもののしっかり言語化できていない そこで、naoya さんがCTOとして今年の春に一休に来てからをちょっと振り返ってみた 振り返ってみるとたった4ヶ月ということに驚いています :eyes: 良くなったと感じていること サービス開発の体制 技術基盤への投資 採用活動 情シスの整備 エンジニアの働く環境 それぞれについて サービス開発の体制 抱えていた課題 マーケティングとエンジニアとの間のコミュニケーションが上手くいかず、開発速度やサービスの意思決定のボトルネックになっていることがあった みんなで話して決める等、それぞれの役割が曖昧なままで開発を進める
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログイン - はてな
