「チームの生産性を高めていくためには何が必要なのか？」――あらゆる日本企業が今、この問いを突きつけられている。人手不足や労働時間が社会問題化する中で、日本でも、生産性向上のための抜本的な改革を目指す企業が日々増加中だ。 しかしながら、「どこから手を付ければいいか分からない」と感じている経営者・マネジャーも多いだろう。リーダー育成、社内コストの削減、定例会議の見直しなど、目に付く問題は無尽蔵にある。 では、それらを貫く本質的な課題、そして改善ポイントはいったいどこにあるのだろうか。プロジェクト管理や情報共有ツールを全世界に提供するアトラシアン日本法人のスチュアート・ハリントン社長、そしてモルガン・スタンレーやGoogleで人材開発に携わり、最新の著書「NEW ELITE」でも注目を集めているピョートル・フェリクス・グジバチ氏の2人に話を聞いた。 日本企業には「オープンさ」が足りない――日本企

Engineering Manager の @ohbarye です。 このたび"Quipper Web Engineer 東京オフィス採用面接ガイド"を Quipper Handbook*1 の一部として公開しました。 Quipper Web Engineer 東京オフィス採用面接ガイド (2019-10-09 追記: Quipper iOS Engineer 東京オフィス採用面接ガイド も公開しました！) (2020-01-16 追記: Quipper Android Engineer 東京オフィス採用面接ガイド も公開しました！) 本記事では同ガイドについてご紹介させてください。 採用面接ガイドとは？ Quipper東京オフィスで行っている採用プロセスについてより多くの方に知っていただくためのドキュメントです。とりわけ面接に訪れる方を読者として想定しており、候補者には面接の日程調整時に

Amazonでは、新しいプロジェクトのアイデアを議論する場合でも、問題解決に最善の方法を決定する場合でも、リーダーシッププリンシプルを日々使用しています。これも、Amazonがユニークである理由の1つです。

今自分が働いている会社ではエンジニアリングマネージャーという肩書で仕事をしています。「ああ、エンジニアのマネジメントをする人ね」ってことなんですが、具体的にどういうことを考えてどういう仕事をやってるかを実際にやってみて分かったこともあるのでまとめておこうと思います。 一応注意としては、「自分はこう考えて仕事してるよ」っていうだけの話で、会社や組織によっては全然違うことを考えたり実行してる人も一杯いると思います。自分の仕事はピープルマネジメントがメインです。 ミッションは「エンジニアチームの生産性を最大化すること」 そもそもエンジニアリングマネージャーって何のために存在してるかというと、エンジニアチームの生産性を最大化するために存在してると思ってます。生産性を上げるためには、各メンバーのモチベーションを高く維持しないといけないし、メンバーのキャリアアップをサポートしないといけないし、メンバー

この1年ほど、プロジェクトのリードを任せてもらえるようになりました。2017年の夏くらいから「プロジェクト推進役」→「PJO」→「Tech Lead」, 「Project Lead」など、正式ではないものの「肩書」のようなものがついていますが、実際にやっていることは「プロダクトの成功に向かってプロジェクトを行動で引っ張っていくこと」で統一されています。 これは別に偉くなったとかではなくて、そういう責任を持ってPJに関わる役割だと思って臨んでいますし、実際マネージャーからもそのように言われています。 自分なりに試行錯誤をして時には成功し、時には失敗しながらなんとかかんとかやってきていているのですが、「あー、この本に救われた」とか「ちょっと前にこの本読んでおけばよかった...」という本があったので何冊か紹介したいと思います。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリフ

ゲーム開発マネジメント勉強会 vol.1にて発表した資料です。 https://management-for-game-development.connpass.com/event/94604/

僕は自分と自分のチームが幸せに仕事が出来るようにしようと思っています。そしてあなたの給与と市場価値を上げるのが僕の仕事です。 僕はあなたが楽しく仕事が出来るようにしています。そのためにはエンジニアとしてもキャリアとしても成長が必要だし、それに対する納得も必要だと思っています。たんに甘やかすとかではなく、一緒にエキサイティングに仕事を楽しみたいと思っています。 あなたとあなたのチームがどの方向に向うのかを考え伝えます。全体として進む先を考えそのために何をすべきかを一緒に考えていきます。 他のチームとの交渉が難航した時はすぐに動きます。僕に頼らなきゃいけなくなった時点で問題がややこしくなっていると認識し、情報を集め適切に動きます。また、必ず結果を報告するようにします。 コードを書く事をやめません。自分自身で触ってみないとわからない事が多いので手を動かす事はやめません。ただし立場上スケジュールの

サーバレスで挑む IoT プロジェクトの現実解 / Real solutions for the IoT project using serverless service

テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 – Testing & Engineering By Hiroyuki Ito | 2018.07.09 2021.01.08LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。 2018年6月27日（水）に、電気通信大学の西 康晴さん（以下「にしさん」と表記）をお招きして、「

起業家や「勝ち組」のコミュニティは、障害者やマイノリティなどの社会的弱者には非常に優しい。 彼らはリベラルなので、そういった「生まれつきの属性」に対しては非常に寛容である。 だが「仕事ができない」「変化に対応できない」といった、「努力でなんとかなりそうな」弱者には、非常に厳しい人がゴロゴロいる。 「社会の役に立ちたい」と起業家や「勝ち組」たちは口を揃えて言う。 だが、彼らのいう「社会」に、「仕事のできない人」は含まれていない。 「動かないやつはほっときゃいいんだよ。落ちてくだけ。」と平然と述べる人は、特に珍しいわけではない。 確かに、健康で、大学を出ており、読み書きも普通にできるけれども、仕事が全くできない、という人を「社会的弱者」と認識するのは、通常の感覚ではないだろう。 でも、真実を言えば、実は彼らは現代では「弱者」に含まれる可能性がある。 彼らは単純な反復作業はできる。マニュアルがあ

融子 @kinyuuchan 青田努さんがまとめたもので、私自身が後輩指導の際に意識したいとともに上司からもこのように指示をあおぎたいなという思いでツイートしました。まわしもんでもなんでもないんですが、こんなに拡散されているのは同じ思いの方がそれなりにいる証拠だなと思いました🌸 リンク www.wantedly.com 【図表】教え方がうまい人は何をしているか（ヘタな場合はこの8つのどれかができていない） | 株式会社アイ・キュー 「教える」というのは業界や職種を問わず大事なスキル。でもその行動品質はさまざまですよね。教え方がうまい人たちに共通するのって、多分この8つなんじゃないかと思っています。いかがでしょうか。 6 users 76

サイボウズで発表したエンジニア採用の話です。

ソフトウェア販売のお役立ち情報！AI inside「AI inside Cube」、スターティアレイズ「JENKA」をご紹介

＼閉鎖予定のサイトも売れるかも？／ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう

コミュニケーション Advent Calendar 2016の19日目です。 コミュニケーションコストってなんだ？ この言葉に行き当たったのはサイボウズの記事で、ちょうどそのときに考えていたことが書かれていたので、もう参照してよ。以上！　とはいかないので、自分なりの何かを見いだしていこうと思います。 2つの側面 コミュニケーションコストには、大きく分けて2種類あります。 タイムコスト コミュニケーションには時間がかかる＝人件費がかかる　⇒　短いほどいい！ という発想のビジネススキルとして言及されることが多いでしょう。 関係者のコンテキストが異なると、問題のピントを合わせるのにも一苦労します。 お互いに必要な情報を交換し、ゴールに向かっていくためにどういうことが必要なのかということは、ファシリテーションやホウレンソウと呼んだりしてビジネススキルとして多くの組織から求められているのが現状です。

Kaizen PlatformでSRE Group Managerをしている前田 (@glidenote)です。4月ということで転職や部署異動など新しい環境で働いている人が多そうなので、今回はKaizen PlatformのEngineering GroupとSRE Groupが行っているOnboardingプロセスを紹介したいと思います。 TL;DR Kaizen Platformに入社してくれた人に最速でPerformanceを出してもらうためにOnboardingプロセスを策定し、運用、日々改善している 入社してくれた人が自身のOnboarding Planを自分で作成し、CTO、メンターとで定期的に期待値の調整、振り返りを実施し、齟齬が発生しないようにする ランチスケジュールを組み毎日別々の人と、別々の場所にランチに行き、一緒に働く人たちとオフィス周辺の情報を知ってもらう 入社した

・VP of Engineering とは成果を出し続けられるエンジニア組織を作っていくこと ・成果を出し続けるエンジニア組織を目指してやってること →問題に当たったら、先人の知恵をお借りして物事を進めてます。

こんにちは、らくからちゃです。ぶらっとTwitterサーフィンしておりますとこんなツイートが目に留まりました。 「なんでもポジティブに考えれば幸せになれる」っての、まるっきりウソだから。現実のネガティブな側面を直視して受け入れることで、不安がなくなり、的確に現実に対処できるようになり、成功確率がぐっと高まり、はるかに幸せになれることなんて、いくらでもある。 — ふろむだ⭐️若い頃知りたかったこと書く (@fromdusktildawn) 2018年2月17日 すげーわかる。 確かに『すごーい』『たーのしー』と言いながらお仕事をしていても、ヤバめな何かを『あれ大丈夫なのかな・・・』『もしかしてヤバくない...？』と不安を抱えながらだと、全く楽しめません。 で、こうした不安を綺麗さっぱりしてお仕事を楽しむため、弊チームでは定期的に『怒らないからヤバいと思っていること全部言う会』を開催しているの

はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一

YWTという振り返り手法について 今回はYWTという振り返りの手法についてご紹介してみたいと思います。前、メール版で書いてた記事ですが、ブログでもアップしときます。 さて。 振り返り、その手法はいくつかあるのですが、大御所の手法はやはりKPT（ケプト）と言われる手法でしょう。 KPTとは、その名の通り K：Keep P：Problem T：Try の頭文字を取った手法のことで、（やってみて）Keepしたいこと、Problemだと思うこと、次にTryしてみたいことを、分野別にまとめることができます。 KPTはシンプルながらかなり使える方法でして、以前僕もこんな記事をまとめていました。 YWTとは何か？ KPTは最近知っている方も多くなってきたのですが、YWTという手法はまだあまり知られていないようです。 かくいう僕も、昨年くらいにどっかで見かけて、「これ面白いなー」と教えてもらった手法です。