3年間のオンボーディングで培われた、リモートでも効果的な7+3のプラクティス
現場主導で始まったHRMOSの開発組織のオンボーディングは、ほぼ毎月、地道に運用と改善を続けてきました。2018年に開始してから3年近くになりますが、エンジニアを対象に始まり他職種のメンバーを巻き込みながら、効率と効果の両面を少しずつ洗練させてきました。この記事では、私たちのオンボーディングを定義や効果を俯瞰しながら紹介し、その中で徐々に確立されてきたプラクティスをご紹介します。 変化の時代に不可欠なオンボーディング オンボーディングとは採用や異動によって組織に加わった人材の早期戦力化のための施策であり、 組織に新しく加わった人材を1日も早く戦力化し、組織全体との調和を図ることを目的とした育成プログラムのことを指します。『機内』や『乗船』という意味を持つon-boardから派生して生まれた造語であり、直訳すると『飛行機や船に乗り込んでいる』という意味です。 〜 BizHint などと定義さ
エンジニアが事業に寄り添うことで、結果的に技術的負債が減る話 - エス・エム・エス エンジニア テックブログ
高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている三田淳一です。2020年1月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。 今回、エス・エム・エスの開発体制がどうなっているのか。開発体制が変わることによって、どのような変化が生まれているのかについて紹介していきたいと思います。 エンジニアと事業がフラットではない環境で生じる課題 ソフトウェアシステムの開発組織は、事業やサービスの企画・運営などを担う事業側からリクエストがエンジニアに下りてきて、エンジニアはそれに沿って開発するという、トップダウンのような構造になっていることがほとんどです。事業側とエンジニア側で、優劣がある状態ですね。 こうした環境では、自分のチームのメリット効率を優先して行動し、他のチームに対して非協力的になることも起こりやすくなります。例えば、事業側
KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP
2020年1月から1年ほどKyashでEMをやっています。 今までチームをリードしてきたことは何度かありましたが、いわゆるマネジメントという役割は初めてでした。EMについて抽象化した話ができるほど自分の中で咀嚼できているわけではありませんが、思考整理を兼ねてやってきたこととやっていくことをまとめておこうと思います。 ここに書く内容は当然自分だけでやってきたわけではありません。他のメンバーによって支えられてきたことの方が多いです。文章量の都合で端折ることもありますが、自分だけで色々やってきたみたいに捉えられるとなんだかむず痒い気持ちになるので一応前提として書いておきます。 1~6月 : Android/iOSチームのEM 1月にiOSエンジニアが1名入社したタイミングで、Android/iOSチームのEMをやることになりました。 それまではTechチーム全体を@ymzkmctが見ていましたが
失敗LT大会。ルーキーエンジニアが「あるある」失敗をライトニングトークで10連発イベント【前編】
event 失敗LT大会。ルーキーエンジニアが「あるある」失敗をライトニングトークで10連発イベント【前編】 2019年7月10日、東京・渋谷のTECH PLAY SHIBUYAにおいて、「ルーキーエンジニアが吠える！失敗LT大会」という珍しいイベントが開催された。主催はTECH PLAY、アイスタイルが協賛した。 エンジニアが成功例を披露するイベントは山ほどある。「イベント登壇するような人はやっぱりすごいエンジニアなんだな」と思っている人も多いだろう。そんなことはありません。成功するエンジニアほどたくさんの小さな失敗をしているものなのだ。 このイベントは、10人のルーキーエンジニアが、自分の失敗を６分間のLT（ライトニングトーク）で発表して、失敗経験をシェアしようというもの。学べるところは多く、なにより、過去の失敗は、心置きなく笑える。経験と笑いの両方を同時に共有できるというイベントだ。
SPEEDA開発チームをブーストするふりかえりのカルチャー - Uzabase for Engineers
こんにちは！SPEEDA開発チームの岩見です。 この記事では私たちSPEEDA開発チームの中でも特徴的な文化のひとつとなっている、ふりかえりについてご紹介します。 以下のような方々のお役に立つことを願っています。 自分たちのチームでもふりかえりをやってみたい方 ふりかえりはやってるけどなんだかマンネリ化している方 色々なふりかえりの運用、実例が知りたい方 SPEEDA開発チームにおけるふりかえり SPEEDA開発チームのふりかえりの特徴 SPEEDA開発チームにおけるファシリテーターの役割 議論しやすい場の設定 アクティビティの選定を含めた全体の進行 ファシリテーターを置くメリット ファシリテーターが他のチームへの理解を深めることができる ファシリテーターが問題を構造的・俯瞰的にとらえる能力が高まる チームのメンバーが議論に集中することができる さいごに SPEEDA開発チームにおけるふり
crowdworks.jpのエンジニアリング戦略(2019年6月現在) - クラウドワークス エンジニアブログ
最近は人事のほうにも片足突っ込んでおりエキサイティングな日々を送っております飯田です。 今回は現在のcrowdworks.jpのエンジニアリング戦略についてお伝えできればと思います。 状況の整理 これまでの中長期戦略の反省 中長期の技術的投資のための専任チームの発足 フロントエンドチーム(チーム名: トリュフ) リファクタリングチーム(チーム名: バグハンター) 継続的バーションアップの浸透 今後の組織戦略 エンジニアの役割定義 今期エンジニアリング部の目標 個人的なこと We Are Hiring 状況の整理 crowdworks.jpはサービスインから7年が経過し、モノリシックなRailsアプリケーションのコードは30万行を超える規模感に成長しています。 一方で、コード行数の増加量はここ最近の傾向としては鈍化しており、ファイル変更数の推移も低下の傾向となっています。以前から巨大なクラス
異動のおともにスキルマップ - スタディサプリ Product Team Blog
こんにちは、Web Engineer の @wozaki です。 今回は、スキルマップを私が所属する開発チーム*1に導入した事例をご紹介します。 スキルマップとは、業務で必要なスキル(技術力、業務知識)と、チームメンバーのスキルレベルを一覧にした表です。 スキルマップの例 引用 スキルマップ作成のすすめ | Ryuzee.com 目次 概要 スキルマップ導入の背景 他社の事例とカスタマイズした点 スキルマップ詳細と運用方針 運用結果 まとめ 概要 チームで必要なスキル、メンバーのスキルレベル、志向性が不明だった 個人の志向性を表現できるようにカスタマイズしたスキルマップを導入した 結果 新メンバーにとって、スキル全体が明確になり、チームの役割の理解にも役立った スキル喪失リスクがあるものが明確になり、勉強会などスキル伝承のアクションにつながった 個人の志向性は、スキル伝承時の期待値調整にも
スマートニュースにおける技術勉強会と寿司。そして「模擬面接寿司」の実施レポート - スマQ（スマキュー）｜スマートニュースの「はたらく」をみつける
こんにちは、スマートニュースでSoftware Engineerとして働いている真幡（まはた）です。普段はニュース記事を素早く安定してアプリに届けるための仕組みづくりをしています。 スマートニュースではさまざまな勉強会が行われており、なかには「寿司を食べながら技術について学ぶ」勉強会もあります。およそ1年ほど前に、エンジニアリングブログで「お寿司を食べながらDocker, R, Tensorflowなどに関して学ぶ勉強会を開催している」と紹介させていただいたことがありますが、今回のスマQではこの勉強会がどう進化してきたかについてご説明します。 2018年末の寿司勉強会の様子。リラックスして話を聞いています なぜ、毎月「寿司勉強会」を開くのか？ スマートニュースには「チームビルディング費」名目で各チームに月次の予算がついています。わたしが所属するニュース配信チームでは、新入社員がチームに配属
エンジニアアルバイト振る舞いテクニック - ぱすたけ日記
今、Notaとはてなの2社でアルバイトしている中で学生パートタイムエンジニアとしてやっていく際の振る舞いについて最近意識的にやっていることがあるので書いてみます。はてなでマンガチームにおいて一応メンターという設定になっている*1ひとでくんさんの次の記事を読んでのアンサーソングのつもりですが、何年もNotaでアルバイトをし、はてなのエンジニアの人々とも長く交流があるからこそ出来る振る舞いなのではとも思っているので、真似してくれとかそういうの一切ないです。偶然参考になる人がいればと思って書きます。 とにかく何でもSlackとかGitHubとかグループウェアとかに書く 困りごとはもちろん、設計のこと、コードのこと、サービスのことで気になってることとか何でも遠慮せずに書くようにしている 自分の作業ペースや理解度とかを素早く把握してもらうため 週に1日〜2日とかで出来ること知れることは多くないので、
エンジニアアルバイト氏受け入れテクニック - hitode909の日記
いま社員エンジニアが何人かに加えてエンジニアアルバイト2人、くらいのチームで働いていて、その中でアルバイト氏のメンターもやっている。 前のチームでも何年かアルバイトの面倒を見たり、何回かインターンのメンターをやったりしていた。 手癖でいろんなことをやってしまっていて、属人性が高まってしまっていると感じたので、どんなことをやっているか書いておく。 1日に何回か口頭で会話する 実装ができててから方針がまずかった、となると時間がもったいない 方針書いたくらいでレビュー依頼に出してね、とお願いしてもやってもらうの難しいので、こちらから聞きに行くほうがうまくいきやすい レビュー依頼になったらすぐに見る 社員は明日も要るけど、アルバイト氏は週に数回しか来ないので、その日帰るまでにレビュー完了して打ち返しもしてもらえるように動けると良い レビュー依頼になってなくてもPull Request見に行く 方針
社内技術ブログのはじめかた - Gunosyデータ分析ブログ
はじめに きっかけ 執筆計画を立てる 1. 分析に興味がある人のペルソナを書く 2. 1が検索するであろうクェリの一覧をつくる 3. 検索ボリュームしらべる 4. カテゴリ分け 5. 作るべき記事のリスト（記事タイトルまでだいたいきめちゃう）をつくる 6. 記事を書く担当者とスケジュール引く おまけ おわりに はじめに こんにちは。グノシー事業部の大曽根です。好きな曲はザ・ディランⅡの「男らしいってわかるかい」です。 この記事はGunosy Advent Calendar 2018の12日目の記事です。 昨日はhongmhoonさんのiOSでNotificationを非同期で送ろうでした。 最近、プライベートや採用面談などで「会社で技術ブログなどを書きたいけど始められない (or 始めたけど続かない)」という相談を受けるので、弊ブログが如何にして立ち上がったかをまとめたいと思います。 ※本
マネジメントは「役割」。CTO・VPoE・VPoPが3頭分立する、Gunosyのエンジニア組織 | SELECK [セレック]
〜マネジメントを分離し、組織を立て直す！「ミドルマネジメントの擁立」「1on1の導入」「現場の小さな意思決定」など、Gunosyのエンジニア組織運営を公開〜 情報キュレーションサービス「グノシー」「ニュースパス」「LUCRA（ルクラ）」などの多角的なメディア展開で急成長を続け、ブロックチェーンなどの新技術系R&Dにも取り組んでいる株式会社Gunosy。 同社は、2015年4月に東証マザーズへの株式上場（※その後、2017年12月に東証一部へと市場変更）を果たしたが、当時上場に向けて組織が突き進む中で、マネジメントを強化できず、組織全体が疲弊してしまう状態にあったそうだ。 そこで組織を立て直すべく、CTOによる1頭体制を変更。 マネジメントとプロダクトオーナーの役割を切り離し、CTO（技術責任者）・VP of Engineering（マネジメント責任者）・VP of Product（プロダク
![マネジメントは「役割」。CTO・VPoE・VPoPが3頭分立する、Gunosyのエンジニア組織 | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/8e4d12f3ddcac23c199152ce641e5d7bbbecceff/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2018%2F06%2F07010726%2Fc03b1c24-b897-4398-bea4-c2f18884437d.png)
開発の“無理ゲー進行”はこう回避せよ！ 若手エンジニアが締め切りを健全に守るためのストラテジー - エンジニアHub｜Webエンジニアのキャリアを考える！
エンジニアHub > 記事一覧 > 開発の“無理ゲー進行”はこう回避せよ！ 若手エンジニアが締め切りを健全に守るためのストラテジー エンジニアにとっての永遠のテーマ、「締め切りはどうしたら守れるか」。上司に言われるままにタイトなスケジュールを押し付けられた経験があるエンジニアは少なくないはずです。 「無理ゲー進行」を生み出す要因はいくつもあります。「完全版をリリースしなけばいけない」という固定観念や、期日だけを厳密に管理して現場へプレッシャーをかけるプロジェクト進行、無理なプロジェクト進行を経営課題と認識せず、現場の「頑張り」に甘えて放置している経営者（意志決定者）など。顧客（クライアント）や上司から押し付けられる「無理ゲー進行」に、工数見積もりに慣れていない若手エンジニアはどう対処していけば良いのだろうか――。 無理ゲー進行の原因をひも解いていくのは、かつて株式会社ミクシィにて最年少で執
社内で機械学習ハッカソンを開催しました - Hatena Developer Blog
こんにちは、アプリケーションエンジニアの id:alpicola です。先日社内で機械学習を題材としたハッカソンを開催しました。サービスに蓄積されたデータを使って、何か面白いことができないか気軽に試してみる場を設けるのが開催の趣旨です。このハッカソンの成果をいくつか紹介します。 この記事ははてなエンジニアAdvent Calendar 2017の24日目の記事です。昨日は id:wtatsuru さんによる「エンジニア新人研修で障害対応を行いました 」でした。明日は id:motemen さんです。 id:Windymelt 「おすすめブログのレコメンド」 はてなブログにはブログの購読機能があるのですが、ユーザーの購読情報を元にブログのレコメンドを行なっていて、いい度合いに動いてそうでした。協調フィルタリングという手法を使っていて、どんなブログを購読しているかによってユーザーの類似度を計算
エンジニア組織がない会社でエンジニア組織を立ち上げるためにやった3つのこと - Qiita
LITALICO CTOの岸田崇志(@takish)です。 2017年のアドベントカレンダーもついに最終日となりました。 入社して2年経ち、エンジニアも順調に人数が増え、新卒採用からの育成、そして新規事業ラインへのエンジニアラインがスケールアウトできるようになってきました。 特に前職ではインターネット事業の急激な成長を経験したので、エンジニア育成サイクルの礎を築いて置くことの重要性は身にしみて感じていたので、最初からそれを念頭に組織を組み立てています。 はじめに 筆者はエンジニア組織の立ち上げは3回目なので「デジャヴ？！」と感じる事も多々あり（笑）、既視感ありまくりの2年でした。 一方で既視感があるということは、どこも成長のフェーズにおいて同じ課題に直面するということでもあるという事でもあります。 そのため、そのような経験を基に過去失敗した轍をもう一度踏まないことを心がけました。 成長フェ
エンジニアリング・マネージャの技術との関わりかた、あるいは折り合いのつけかた - Qiita
(この記事は Livesense - 関 Advent Calendar 2017 掲載のために書かれています) 2017年の春からリブセンスのエンジニア組織改善に関わり、同年夏頃からエンジニア職能の全社リーダを任されることになった能登と申します。社内的には Livesense Engineer Leader という名前の役割なのですが、実質 VP of Engineering の仕事をしており、社内にエンジニアリング・マネージャを増やすことも重要な「おしごと」になっています。 エンジニアリング・マネージャは、主にエンジニアの評価・育成・メンタリングや組織面の問題解決を行う役割ですが、正直言って目指そうとする人は少ないです。エンジニアになろうとする人は技術が大好きか、人とのコミュニケーションをわずらわしいと思うことが多いので、自然なことだと思います。自分も昔はそういう人間でしたし、いまだに
「北欧、暮らしの道具店」のエンジニアチームが2年間スクラムを実践して学んだこと | Kurashicom Tech Blog
こんにちは、エンジニアの濱崎です。 クラシコムのエンジニアチームでは、2015年からスクラムでチームを運営してきました。 最近ではスクラムを取り入れている会社も増えてきましたが、やり方は会社やチームによってまちまちで、ベストプラクティス的なものは無いんじゃないかと思います。 クラシコムでも、最初はゆるくスクラムを始めて、いろいろと試行錯誤しながら今のやり方にたどり着きました。 このエントリでは、僕らなりに2年間スクラムを実践してきた中で、うまくいったことや失敗したこと、それらを通して学んだことをお伝えします。 これからスクラムをやろうとしている方や、すでにスクラムを実践しているチームにとって、少しでも参考になれば嬉しいです。 「スクラムって何？」という方は、以下のスライドを読んでいただけると概要をつかめると思います。 ゆるいスクラムから始まったエンジニアが1人しかいないときはスクラムはやっ
エンジニアのモチベーションについて - Web Developer's Struggle Memories
はじめに 2016年11月8日現在、自分がアサインされた案件がかなり大炎上している。 燃えている要因を数えだしたらキリがないが、大きなものでも5つはある。 それはお客さんにもあるが、チーム内（というか上司がデカい）にもやはりある。 そんな中（自分も含めて）エンジニアのメンバーが意識やモチベーション高く仕事をしているかと言えば、 もちろんそんなことはなく、かなりストレスや不満を溜めた状態で仕事をしている。 意識の変革のために、ある記事が凄く参考になった 本当の本当にデッドライン（これを超えたら出るとこ出てましょうか）に差し迫っていて、チーム内も切羽詰まって来ている中、 自分の意識が変わるようなエントリがあった。それが以下。 logmi.jp この記事を読んだ上でいったん置いておくw 自分の書きたいことを先に書いて、最後にこの記事の内容を引用して終わろうかなと思っているので。 上下関係なんかな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニア組織のスケールに伴う社内勉強会のTry&Error #infrapre / 20170805
事業成長にコミットするエンジニア組織への道のり
