サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
新型コロナウイルスの影響下で、食の宅配などO2O（Online to Offline）サービスが好調です。なかでも有名漫才師を起用したテレビCMも話題となった出前館は、2020年8月期の連結決算で利用者数が前期比で31％増、売上高も前期比で54.6％増となりました（ただし広告展開やシステム投資などの先行投資により営業利益は赤字となっています）。 この背景に、株式会社出前館とLINE株式会社が2020年3月に締結した資本業務提携があります。LINEが出前館の経営に参画し、広告だけでなくサービスの提携も進んでいます。2020年11月には「出前館」アプリがLINEアカウントと連携し、出前館のOEMだったLINEデリマは12月にサービス統合されました。 ただしLINEでは、出前館を「LINE」アプリの関連サービスではなく、独立したO2O事業として継続的に成長させたい。そのためLINEのエンジニアを
[2020.12.8 追記] ブコメでEMが何かわからないと書かれていたので補足。EM = Engineering Managerです。EM菌ではありません！！！ [追記ここまで] 今の会社でお世話になったEMの人たちのマネジメントがとてもよかったので育休で全てを忘れる前にメモを残す。EMの話題はよく見かけるけれど、マネジメントされる側の視点で語られることがあまりなかった気がするのでいい記録になるかもしれない。 前提 自分: メンバー（マネジメントされる側）。Androidエンジニア。ある程度放置されても自走できる。EM: 一人ではなく複数。（歴代という意味。同時に複数人のEMにマネジメントされたという意味ではない。）彼らはみなAndroidエンジニアではないがモバイルもしくはフロントエンドのエンジニア。なので技術の相談はしないが、開発業務そのものについてはとても詳しい。 組織: エンジ
こんにちは。粕谷大輔（@daiksy）です。インターネット上では「だいくしーさん」と呼ばれることが多いです。現在は株式会社はてなで、Mackerel開発チームのディレクターを務めています。Twitterなどで使っている、地獄のミサワ風のアイコンをご覧になった方もいらっしゃるかもしれませんね。このアイコンは、前職のフロントエンドエンジニアに描いてもらったものです。 今の自分の仕事は、エンジニアとデザイナーで構成される開発チームを指揮し、プロダクトの安定稼働と、定常的なデリバリーに責任を持つことです。「エンジニアリングマネージャー」という言い方をすると、分かりやすいかもしれません。 自分のこれまでのキャリア選択を振り返ると、もちろん結果論のようなところもありますが、ある程度狙いを定めてキャリアを歩んでこられたのではないかと思います。本記事では自分のこれまでのキャリアについて、「どのように狙いを
【CTO・エンジニアマネージャーに聞いた】企業成長フェーズ5段階別に発生するエンジニア組織の課題と取り組み事例まとめ 2020.02.13 Findyの石川（@HRBizDev1）と申します。 2019年3月にFindyへジョインし、昨年まではFindy Freelanceの立ち上げ、今年からは先日、事前登録を開始したFindy Teamsの事業開発を担当しています。 （前職ではエムスリーグループの企業で医療機関の採用支援や新規事業を担当していました） Findy Teamsではβ版リリースに向けて、上場企業から創業初期のスタートアップまで、様々なフェーズの企業数十社へヒアリングを進めている段階ですが、その過程でエンジニア組織において発生する組織課題は事業成長フェーズによって、異なることが段々と見えてきました。 そこで、今回はヒアリングを通じて見えてきた課題と取り組み事例をまとめてみました
こんにちは Mirrativ CTOの夏です。 現在、ミラティブでは事業部単位でチームや目標を管理しており、エンジニアが所属するチームとして以下の6つがあります。今回はこのうち、エンジニアチームについて、2019年度に行ってきた取り組みの振り返りをしたいと思います。 ライブプラットフォームチーム ユーザの定着を追う マーケ連携チーム ユーザの新規獲得を追う エモモチーム 3Dアバターであるエモモを使った新体験の創出・基礎体験の向上を追う ストリーミング改善チーム モバイル端末でのライブストリーミングの配信・視聴の品質改善を追う インフラチーム クラウド上での安定したインフラ基盤の設計・構築を追うエンジニアチーム お問い合わせ調査、不具合・障害の再発防止、開発体験の向上を追うAI技術部 コミュニティやストリーミングとAI活用の可能性を追う 毎週定例で振り返りを行っており、Confluen
by Glen Noble 多くのエンジニアが自分では解決方法がわからないプログラミングコードの書き方やエラーをStack Overflowで調べますが、そのStack Overflowで高校時代から10年間モデレーターとして書き込みを続けたMatt Biernerさんが、これまでの経験から学んだ「Stack Overflowを使う上で覚えておくべきこと」をリストアップしています。 What I've learned over 10 years on Stack Overflow – UWTB https://blog.mattbierner.com/10-years-stack-overflow-learnings/ ◆01：質問することもスキルの一つ 質問をすることは簡単に思えますが、回答を得られる質問をするには単語を選ぶことが重要となります。Stack Overflowにも公式の質問
今日で仕事が納まった。それと同時にチームメンバーが一人チームを去ることになった。送別会もしたのでお別れはまあそれなりにしたんだけど、結構自分に影響を与えたのでなんとなくブログとして残しておくことにした。 うちの部署は複数のスクラムチームで構成されているスクラムオブスクラムという形を取っている。僕がこのチームに配属されたのは二ヶ月前くらいのことだ。部署内の別のチームからこのチームに異動したのがきっかけだ。チームメンバーの一人であり、今回お別れした人は認定スクラムマスターを持つエンジニアであり、このチームはちゃんとアジャイルなチームになろうとしているという話を事前に聞いていた。(以降、この人を彼と呼ぶ) 前職でもスクラム開発はやっていたつもりだったし、以前のチームでもスクラムを行なっていたのでなるほどなるほどという感じでチームのやり方に乗っかっていくことにした。見積もりをして、計画で洗い出し、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめにRettyでVPoEをやっています。最近エンジニアのキャリアパスについて相談を受けたり考えたりする機会が多かったので、整理を試みてみようとおもいます。 基本WEB系ベンチャーでの話になります。 35歳定年説 最近言及されることが減った35歳定年説ですが、実のところ一つの壁として存在していると思っています。 いろいろな要因がありますが、今回は知の高速道路と賃金カーブの関係にしぼります。 賃金カーブ [引用元](https://www.jil.go.jp/kokunai/statistics/timeseries/html/g04
原文 Engineering Career Development at Etsy - Code as Craft (English) 原文著者 Ryan Bateman 原文公開日 2019-10-02 原文ライセンス CC BY-NC-ND 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 2109日前 原文へのコメントで報告済み 編集 2018年の5月の終わり頃、Etsyは社内でエンジニアリングのキャリアラダー (Career Ladder) を発表しました。 現在では、広く一般にこのラダーを公開しており、私たちがなぜこのようなものを作ったのか、なぜこの内容になったのか、そして発表以降どのように活用されてきたのかを詳細化しています。 こちらをご覧ください。 キャリアラダーの定義 キャリアラダーは、企業内におけるエンジニアの成長パスを描くのを助
エンジニアの評価制度について、公開されている情報を中心に傾向をまとめてみようと思う。エンジニアの評価制度 「評価はマネージャの大切な仕事であり責任である」と誰かが言っていたけど、今の時代だと人材がある程度流動的になったので、従来の「評価怖い！」という「権威的」なものというより、「あなたはこうだ」という「正確性」が求められているような気がする。 また、僕個人としては、エンジニアの評価は、軸や観点が総合職とかとは全然違うので、一般的な評価制度とは別で考えたほうがいいという派であり、評価の正確性を追い求めるのはつかれるし大変だから、コンサルの給与体系みたいに新卒X万！ 一人前ぐらいでX万！ トップレベルでX万！ みたいな3段階ぐらいの評価になってほしいと願う限りである。 あと、書き始めようと思った矢先、エンジニアの評価制度、他社は一体どうやってるの！？まとめて紹介！ というすばらしい記事を発見
This slide is for Product Managers who want to write specs that can get buy-in from engineers and that is well stated that a team can start working on i…
エンジニアリングマネージャーの常松です。 最近のRettyは定期的に新しいメンバーが入ってくる状況にあります。 新メンバーに能力を少しでも早く発揮してもらえるよう、オンボーディングの改善に取り組んでいます。 上記は6/13に開催されたEngineer Onboarding Meetup #1で、VPoEの小迫が登壇した際の資料です。 オンボーディングとは 企業が新たに採用した人材を職場に配置し、組織の一員として定着させ、戦力化させるまでの一連の受け入れプロセス を意味します。 誰に聞いたら良いのかという「人の課題」、前提とするべき知識が揃っていない「情報の課題」、会社・部門からの期待値とずれがある「カルチャーの課題」に対し、全社・部門・個人で行っている具体的な施策を勉強会では紹介しました。本記事では2019年6月に入社した自分が実際に体験したオンボーディングプロセスの紹介と、その後に始め
今の職場にいる何人か日本人のエンジニアや、外資系他社の日本人エンジニアなんかの話を聞いていて思ったことをまとめてみます。 いまどきのテック企業では、Individual Contributor(IC)として、マネージメント要素は一切含まない形でエンジニアやその他の職種で高位のポジションを目指すことができます。最近では日本の一部企業でもマネージメントに行かなくても出世する道を用意してくれているところが増えているようですが、ICとしての活躍するキャリアパスや待遇などについては欧米圏のテック企業のほうが制度面・機能面で先を行っている印象があります。しかし、外資系テック企業において周りを見る限りでは、日本人のソフトウェアエンジニアはシニアレベルまでは頑張ってリーチできても、その上のレベルに行っている日本人は見たことがないなー、というのがこの記事を書こうと思ったモチベーションです。 平均的に言って、
はじめに この記事には、Googleのオンサイト面接に向けて勉強した内容が記載されていますが、それらはすべて面接を受ける直前に書いておいたものです。このエントリを読むことで面接で聞かれた内容が予測されてしまわないようにそのようにさせていただきました。ご了承お願いします。 この記事について 令和元年に医師を退職し、ソフトウェアエンジニアに転職します。 自分にとって大きな転機であったのと、とても大変な道のりであったので、私という人間が辿った道筋を最初から最後までちゃんとまとめておきたいと思いこの記事を書くことにしました。 私のような他業種から未経験での転職を目指されている方にとっても、何らかの参考になる内容であれば幸いです。 私の生い立ち 私は小さい頃からテレビゲームが大好きで、学校から帰るとずっと家でゲームをしている子でした。あまりにもゲームが好きだったので、遊ぶだけではなく自分で作ってみた
昨日完全独立コミュニティのイベントと、会社が関係するコミュニティのイベントの connpass が両方空いたのは良いけど、同じことを外向けにも会社向けにも両方書く必要はないよなと思ったのでメモ。 思い出したら随時追記するかも。自明なこととかお金の話は書いてません。 登壇者系 接続端子の共有 基本的に最近だと HDMI / Type C をカバーしておけばトラブルが起こることはない 上記が揃っているならその旨を、その上でほかもカバーしている場合や、不足している場合はその情報も添えて共有しておくと良い セッション後の質疑応答の有無の共有・確認 質問タイムがあるかないかで実質登壇時間が変わってくるため セッションの間に 5 分休憩などがある場合、それが休憩なのか質問用バッファなのかがわからないので明確にする そもそも人によって質疑応答の有無は選択できたほうが良いので確認すると良い 自分が登壇者と
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こさまりです。普段はGoogleChromeのweb developer ecosystemチームというところに所属してウェブエンジニアをしています。東京出張中に「web系でコード書く系」の人と晩ごはん会を開催したので、準備したことと収支報告を記録します。 はじまり InsideFrontendの懇親会であまり話ができなかった人たち＋Google I/Oの日本語タグで存在は認識してたけど会って挨拶できなかった人に声をかけて、５人くらいでご飯に行こうかと思っていました。せっかくだからエンジニアの友達とか会社の同僚とかも連れてきて欲しいなー
この前の評価の時期に整理した内容。少し遅くなってしまったが書いてみた。 評価について、特にメルカリでは360度評価的に近いPeer Reviewも実施している。その際にもValueに基づいてFeedBackするのがベースになっており、Valueについて改めて考える機会と言える。 というわけで自分なりのValueの考え方を整理してみた。 3つのValue おさらいだけど、メルカリのValueは以下の3つGo Bold(大胆にやろう) All for One(全ては成功のために) Be Professional(プロフェッショナルであれ） 実はこれ以上の説明はない。各Valueについて敢えて細かく具体的な整理をしないのは経営の意図したものだ。 各人が各Valueはどういうものなのか考え・議論し、体現していくことによって会社のアウトプットに繋がる。 というわけで自分なりに考えてみるが、自分の中
Photo by Wonderlane こんにちは。倉内です。ITエンジニアを対象にしたアンケート調査で、今の職場環境や仕事内容に不満を感じていると答えた人が挙げた理由でもっとも多かったのが「仕事上の評価が正当でないと感じるから（給料が安い）」という結果が出ています。 でも正直なところエンジニアの評価って難しいですよね…。技術力で測るといっても、「そもそも技術力とは？」に対して簡単に答えを出せるなら苦労しません。エンジニアの仕事は短期間で結果が出ないものも多いですし、コードが書ければ業績や経営課題への貢献度を一切考慮しなくていいのかという悩みもあります。ましてや頑張り度なんかで測れるものでもありません。 ただ、最近はさまざまな企業が評価制度を公開していて、技術力をどういった定義で評価しているか、制度としてどのような工夫がされているか…などを知ることができます。 そこで今回は評価制度を公
春休みに3週間ほどインターンシップに参加してきました. いろいろと思うところがあったので, 参加した感想を書いていきます. 経緯 近年ではインターンシップ(以下インターン)が盛んに行われています. 就職活動には関係ないという建前で行われているのがほとんどですが, 実際には就活の選考に有利に働くことが多いようです. 就活に出遅れるのも得策ではないと思い, インターンに参加してみました. 具体的なインターン先は述べませんが,ITベンチャーとかではなく, いわゆるJapanese Traditional Big Company です. 多分, 日本人なら誰でも知っている企業だとは思います. 応募したきっかけは, そこに就職する先輩がいたことと, 大学OBが学内でそこのインターンの紹介をしていたからです. 非IT系の企業ですが, 配属先はICTでソリューションするような所でした. インターンの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
