オズビジョンの組織開発について - 組織を極める
今日のエントリーは、ozvision Advent Calendar 2017の19日目の記事です。今年からエンジニアの慣習であるアドベントカレンダーの取り組みを自社でも実施しようということで、エンジニアではない私も枠を1日頂きました。 ちなみに前職のはてなでも同様のタイトルで記事を書いたことがありますので、よろしければご参照下さい。今回はオズビジョンに転職して9か月で実施した施策やその背景、成果についてまとめたいと思います。 組織開発とは 2年前のエントリーにも書きましたが、改めて組織開発とは何かです。人事以外の職種の方には聞きなれない言葉と思いますが、私は「組織をチームとして活性化するためのあらゆる打ち手」と解釈しています。2年前の定義から変化したことは「チームとして」を加えたことです。そのほうが人材開発との違いの観点でより明確になると思っています。また、組織開発という言葉を使っていま
テックリードという役割
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
さくらインターネット田中氏とKaizen Platform渡部氏が語る「エンジニア職と非エンジニア職のちょうど良い関係」の築き方【キャリアごはんVol.6レポ】 - エンジニアtype | 転職type
エンジニアと非エンジニアの間に立ちはだかる壁の正体 「エンジニアの言っていることは専門的で非エンジニア職には理解できない」「ビジネスサイドは開発工程を無視した無理なスケジュールを求めてくる」など、IT業界ではエンジニア職とそうでない人たちとの間で、コミュニケーションにおいて少なからず隔たりがあるというのはよく言われることだ。しかし、この日登壇した田中氏と渡部氏が在籍する企業では、そういった壁はほとんどないという。そもそもエンジニア職と非エンジニア職の間に境界線を引いているのは一体何なのだろうか？ 2人はまず隔たりの原因を「ゴールの不一致」だと分析する。その共通の「ゴール」がないままだと、エンジニアと非エンジニアの間でさまざまな衝突が起きるという。 「例えばサイト1つ作るにしても、エンジニアは納期に間に合わせることを目標としている。その一方で、デザイナーはいつまでも色にこだわっていて制作が進
エンジニアが知っておきたい工数見積もり術！ " 無理ゲー進行 "から脱するために大切なコト - エンジニアHub｜若手Webエンジニアのキャリアを考える！
エンジニアが知っておきたい工数見積もり術！ 無理ゲー進行 から脱するために大切なコト エンジニアの仕事に欠かすことのできない、工数見積もり。実際の現場でいくどとなく見積もりを行ってきた筆者が、「健全な進行」にするための工数見積もりのテクニックを伝えます。 アプリエンジニアの池田 惇（ @jun_ikd）です。今回は、エンジニアならば避けられない「工数見積もり」について考えてみたいと思います。若手エンジニアでも自分の作業は自分で見積もるようにするべきです。なぜなら、より正確に計画を立てられるようになれば、自分の時間をコントロールして学びや家族・友人との時間を確保できるからです。また、期日内に完了をさせることは周囲の信頼獲得に繋がります。工数の見極めはエンジニアとして、とても重要なスキルなのです。 なお、本稿での「見積もり」とは開発に必要な期間を予測することとし、見積もりが失敗する原因や対策
優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～/Concise Guide to Finding the Best Technical Talent
CEDEC2017「優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～」講演資料です。
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
Kaizen Platform という会社について
Qiita:Team エントリのレベルが高い CEO や CTO 、プロダクトマネージャーの書く Qiita Entry のレベルが高く、 Qiita:Team のタイムラインがはてブのホッテントリのようだった。ブックマークできるもんならしたいという感じ。お金を儲ける仕組みってこうやって作り出されていくんだなぁと思いながら眺めてた。技術顧問の伊藤直也さんが残していった名エントリも結構あった。 Kaizen エンジニア行動指針とか。 SRE （インフラチーム）のレベルが高い インフラが盤石だった。 SRE は二人しかいなかったがとても仕事が速く、困ったことがあって Slack のインフラ相談チャンネルで相談したらたいてい 3 分くらいで問題が解決してた。 yosudo さんは問題解決能力が高すぎていまは SRE ながら VP of GA （総務部門のドン）やってるし、 glidenote さ
タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
社内横断の技術組織を終わらせました - nottegra’s blog
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
ドラッカー風エクササイズをチームで試してみました - tjinjin's blog
この記事は feedforce Advent Calendar 2016の5日目です。前日は人事のなべはるさんの記事でした。技術をすごい活用されててすごいですねー！ www.adventar.org 今年は技術縛り要素があまりないので、普段書かないマネジメント話をしてみます！ 背景 今年の9月くらいから開発リーダーに任命され（その前は前任のリーダーが抜けたあと全員がリーダーみたいな仕組みだった）、やっていった中でいろいろ課題を感じていました。 自分は細かいことが気になるたちなので、その方向性本当に正しいの？この開発プロセスはこのままでいいの？などなどどんどん気になるポイントが頭によぎってました。それを自分で決めて・実行して・振り返るってスタンスでやっていったわけですが、どんどん範囲が広がりすぎて死にそうになってきました。もっとメンバーにも求めたい気持ちも正直ありました。が、暗黙の期待ってい
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
事業成長にコミットするエンジニア組織への道のり
4. Agenda • リクルートライフスタイルの紹介 • エンジニア組織黎明期の話 • 急拡⼤とその先に待っていたもの • 社員エンジニアの価値とは • チャレンジをする組織へ • ⽂化を作るための⽇々 • エンジニアドリヴンで組織を変える • まとめ 4 5. ⾃⼰紹介 ＜略歴＞ • 〜2012年 – 受託系開発会社でCS -> PG -> SE -> MGRとして勤務 • 2012年5⽉〜 – 株式会社リクルートに転職 – 新規⽴ち上げ、サービス運⽤改善に携わる • 2015年4⽉〜 – ネットビジネス本部 グループマネジャー就任 – 新規開発、スマホアプリ開発、ホットペッパービューティー開発の部署を担当 5 ⼩川 健太郎 ネットビジネス本部 ディベロップメントデザインユニット プロダクト開発3G グループマネジャー 6. リクルートでの時系列6 20
衝撃的な効率性～最高の DevOps チームは「知っている事」で構成されていた～ - メソッド屋のブログ
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog;
半年前から会社でシニアエンジニアという役職で、エンジニアのメンターの役割を担っている。その役割を出来るだけうまく演じられるように、半年間はコーチングの学習を進めてきた。 目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog; なぜ最近コーチングや人間の学習モデルの勉強をしているのか - $shibayu36->blog; 「コーチングのすべて」読んだ - $shibayu36->blog; また、半年間、目標・1on1・評価と一通りの業務をこなし、コーチングの実践が出来た。 そこで今回はコーチングの学習と一通りの実践を通して学んだことで、特に役に立ったと思うことについて一旦まとめてみる。特に役に立ったと思った知識は以下の二つである。 ゴールを決め、現在位置とのギャップを考え、目標を決める 解決案を与えるのではなく質問する ゴールを決め、現在位置とのギャップを
1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
マネジメントの秘伝のタレ - Flicker's Style++
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Codetree vs TaskTub vs ZenHub | What are the differences?
http://blog.youchan.org/2017-12-18
Taiga.io
Google：マネージャはやはり重要な存在である
