エンジニアの"有害な振る舞い"への対処法 - Qiita
本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz
【資料公開】 ”チームを「自己組織化」されたチームに導く方法”として、「POStudy プロダクトオーナー祭り 2018 Summer」にて登壇させていただきました。
【資料公開】 ”チームを「自己組織化」されたチームに導く方法”として、「POStudy プロダクトオーナー祭り 2018 Summer」にて登壇させていただきました。CTO Officeの梶原です。2018年7月7日に POStudy ～アジャイル・プロダクトマネジメント研究会～ 主催の「プロダクトオーナー祭り」にて登壇させていただきましたので、資料を公開させていただきます。 チームが、チームの問題をチーム自身で問題を解決する成功体験を積み重ねていくと、徐々にチームが自己組織化されていくことができた事例を紹介させていただきました。 自己組織化が進むと、チームの問題を自分ごととして捉えられることができるようになります。 何かの参考になれば幸いです。
リーダーであるための視野・視座・視点 - Tech Inside Drecom
はじめに 十名～数十名ぐらいのプロジェクトで開発することの多いドリコムだが， プロジェクトの中に「プロジェクトリード職」という役割を置いている。 プロジェクトの実現性と健全性を担保するのが仕事だ。 ディレクター，プロダクトデザイン，プランナー，アート，エンジニアリーダーという風に 職種別のリード職を設けていて，エンジニアリーダーの場合はアーキテクチャや安定稼働， (技術的な) ユーザビリティ等への専門性を持って責任を負うのと，エンジニアチームの チーム作りもミッションに加えている。 最近は開発ライン数が増えてきたこともあり，新卒 2，3 年目のリード職が増えてきた。 リード職になった人に「一メンバーだった頃と何が違う？」と聞くと， よく「視野が広くなった」と返ってくる。 視野が広くなるとは具体的にどういうことなのか，掘り下げてみようと思う。 主に 2 年目エンジニア向けのエントリです。 仕
スクラムマスターの仕事にはどんなものがあるか
みなさんこんにちは。@ryuzeeです。 スクラムのトレーニングをしている中でよく質問を受ける項目の1つに、スクラムマスターはどんなことをすればよいのか？というものがあります。 答えを一言で表すなら、「スクラムがうまく回るようにする」なのですが、実際にどんな仕事をするのか簡単にご紹介したいと思います。 なお雑多なリストなので網羅性はありません。 スクラムマスターの仕事の一例スクラムのフレームワークをうまく回せるように支援するスクラムチームにスクラムの価値やフレームワークを理解してもらうステークホルダーにスクラムの価値やフレームワークを理解してもらうスクラムチームが持続可能なペースで進められるように支援するスクラムチームが集中を維持できるように支援するスクラムチームが透明性を維持できるように支援するスクラムチームが規律を守れるように支援するスクラムチーム内外のお互いの協力を促すスクラムチーム
施策の質と職務能力を高めたい！ディレクター会の取り組み - クックパッド開発者ブログ
こんにちは。サービス開発部 ディレクターの五味です。 Android版クックパッドアプリのリリースマネージャーと、アプリ利用者に関わるいくつかのプロジェクトを担当しています。今回は私たちの部で実施している、ディレクターの定例会について紹介します。 サービス開発部 クックパッドの開発体制は、2年前に私が ディレクター知見共有会についてのエントリー *1 を書いた頃から少し変遷を経て、2017年からはサービス開発部が、レシピ検索・投稿などの基幹機能と、サービス全体のユーザー体験を一手に管轄するようになっています。 部のメンバーは現在40人ほどおり、部の注力指標からブレイクダウンしたKPIをベースに9つのプロジェクトチームに分かれています。チームの編成や人数は様々で、状況に合わせて入れ替わりもOK、KPI達成に向かっていれば、各チーム主体的に動くことが推奨される柔軟な組織を試みています。 プロジ
1人で始めた職場での改善活動1年間を振り返ってみたメモ - 全力で怠けたい
職場で勝手にやっている改善活動のメモを取り出してから1年たったので振り返ってみたメモ。 書くこと 実際にやったこと 変わったこと 一番大きく変わったこと まとめ 実際にやったこと メモはハッシュタグ #俺俺改善活動 を付けて Twitter へツイートしていました。*1 今月の #俺俺改善活動．構成管理のブランチポリシーを整理してドキュメント化した．普段は見ないものだけど，ブランチ開発経験のない人が入ってきたときは効果すごいある— えび🦐 (@ebc_2in2crc) 2016年7月28日 今月の #俺俺改善活動．高コストな上に誤りが混入しやすい機能をエンドツーエンドでテストできるようにした．テストは自動化されているから CI に組み込めるし，安心して修正できるようになった(*'▽'*)— えび🦐 (@ebc_2in2crc) 2016年7月28日 今月の #俺俺改善活動 ・テストの2
タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
これからの時代に求められるのは「T型ではなくH型の人材」
米国の名門ビジネススクールに通う人たちのあいだで、近年、「デザイン」の授業の人気が高まっています。世界中の企業が大きな変革を迫られるようになった今、組織が求める人材像にも変化が見られるからです。 イリノイ工科大学のデザインスクールで学び、現在はデザインファームbiotopeの代表を務める佐宗邦威氏は、これから必要とされるのはH型の人材だと言います。 H型の人材とはどんな能力を持つ人たちなのか──彼の著書『21世紀のビジネスにデザイン思考が必要な理由』からの抜粋をお届けします。 越境人材というキャリア イノベーションを語る上で、デザイン、エンジニアリング、ビジネス、という3種類の人材が交差する“地図”を描くことが重要です。 自分と違うスキルを持った人とチームを組むことをベースにしたとき、自分がどの領域をコアにして強みを発揮し、他の領域を得意とする人と組む必要があるのかが明確になります。 ちな
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
インフラチームと開発チームの垣根をなくすためにAWSのCI環境を構築した話 - CARTA TECH BLOG
こんにちは、VOYAGE GROUP システム本部の @s-tajima です。 PHPカンファレンス2016 の「老舗メディアが改善に取り組んでいる話」でもお話した通り、長年オンプレミス環境で稼働してきたECナビを、AWSに移転しようというプロジェクトが進行しています。 そしてなんと先日、約24時間のメンテナンスを経てECナビの本体(Webサーバ, 管理画面サーバの一部, データベースサーバ)がAWSに移転しました！ AWS移転において得た知見, 構築したシステム等は数多くありますが、今回はCloudFormationとTravis CIを用いて 生産的 で 安全 で 手軽 なAWSのCI環境を構築したお話です。 背景 ECナビは、500万人を超える会員を抱えたVOYAGE GROUPが運営している中でも特に大きなメディアの1つです。 今回、そんなECナビのインフラ調達期間の削減、検証環
複数のエンジニアと開発を円滑に進めるためのissueの立て方 - クックパッド開発者ブログ
こんにちは。クックパッド特売情報ディレクターの田中です。 前回ヘルスケア事業部の濱田くんのエントリーでエンジニア以外のGitHubの利用について紹介されていましたが、今回は私がチーム開発で実践しているissueの立て方についてご紹介したいと思います。 チームが大きくなってきてヒズミが生じてきた 本来、ディレクターが開発を伴わない価値検証を十分に行った上で仕様を考え、デザイナー・エンジニアに引き継ぐのが理想的だと思います。 私自身も当初はその開発の進め方を採用していましたが、チームが大きくなり、ディレクター１人で関わるエンジニアが増えてくると、状況は変わってきました。 マルチタスク的に仕様を考えていたために詰めが甘い部分が多く、手戻りが発生してしまったり、仕様の準備が追いつかず、エンジニアの手が空いてしまうことが増えてしまったのです。 当初は自分自身の頑張りが足りないからだと、徒に気合いと根
OKR：組織内のコミュニケーション効率化と重要なゴールへの集中を促すシステム - yaotti's diary
(Qiita:Teamで社内にて共有していた記事を公開) GoogleやZyngaで使われているOKRという仕組みが、「会社として何が大事なのか」「そのためにチームや自分は何に集中すべきか」を明確にするフレームワークとしてよさそうなので調べてまとめてみた。 OKR(Objectives and Key Results)とは OKRは会社やチーム及び個々のメンバーの目標(Objectives、達成すべき戦略目標)と主要な結果(Key Results、その目標の達成度を示す客観的指標)から成り立つ。 OKRを導入することのメリット Objectives and Key Results ( OKR )より 思考が統制される 大きな目標が明らかになる 日々のオペレーションにかかりっきりだと「実際のところ何が重要なのか」は見失いがち メンバーと正しいコミュニケーションをとることができる 各々が何を重
良いチームとは「何でないか」 - Yamotty Blog
2017 - 01 - 20 良いチームとは「何でないか」 プロダクト-プロダクトマネージャー 「良いチームとは何か？」 という質問を投げかけると、答えが多様にわたり、同じチームに所属していたとしても認識が全く揃わないことはザラである。 アメフトチームをコーチしていた時。この組織の目的は驚くほど明確で「全ての試合に勝つこと」以外に存在しない。と、僕は思っていたが、チーム全員（100名超）との1on1を行うと 「職場での評価が上がる」 「仲間との関係」 「〜に憧れている」 などの、「勝利」と直結しない所属動機が浮き彫りになった。また仕事におけるチームでも、同様の質問を投げかけると 「会社に来るのが楽しいこと」 「コミュニケーションがスムーズ」 「お互いが尊重し合える」 など、必ずしもチームが達成を目指す成果に結びついていない回答が殆どであったりする。このことから、 良いチームを定義するのは簡
開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
部下が全員働くママになったら、私の残業時間が減ったという話 | 自分の心を殺してはいけない| Gallup認定ストレングスコーチしずかみちこブログ
出勤の不安定さとその対策 働くママと一緒に仕事をする際に、まず頭に入れて置くべき点がある。 それは、出勤が不安定ということだ。 子供は常に体調を崩すと覚悟した 私自身には子供がいない。 なので、子供があんなにも熱を出すとは知らなかった。 子供が体調を崩す理由は山ほどある。 インフルエンザに食中毒。季節の変わり目。 溶連菌という言葉はこの時初めて聞いた。 メンバー2人ともが突然休み、一人でぽつんと呆然と始業時間を迎えたこともある。 対策は、スマホで この問題には対応方法があった。 メンバーが私たち3人のLINEのグループを作ってくれたのだ。 子供の具合が悪くなると、休日でも夜でもその段階で「長男、発熱中」などとLINEに書き込んでくれた。 朝になって突然子供の具合が悪くなったときは、朝の5時や6時の早い時点でそのことを知らせてくれた。 出社の状況が早い段階で分かると、仕事の調整が余裕を持って
1on1ミーティングに備えるアンケート - しるろぐ
最近は、大体月一ぐらいのペースでメンバーと1on1ミーティングをするようにしている。 一人あたり30分から60分ぐらいで、前回のミーティングからの振り返りとその他相談を話す感じ。相談は仕事のことが主だけれど、プライベートな内容もある。 1on1ミーティングにあたって今年から事前アンケートを用意するようにしたのだけれど、そこそこいい感じに回っているのでまとめてみる。 事前アンケートを用意するメリット 話すことが事前に想定できる アンケート自体がアジェンダになるので、ミーティングがコントロール可能になる。 どんな話をするか分かっていると安心感もあるし、話が横道に逸れることもない（雑談は雑談で良いものだけど）。 その場で回答が思いつかなくて適当な返しになることがなくなる（お互いに） 自分の体験談なんだけど、何か質問をされたときにその場では「うーん、今は特に思いつかないです」と答えたのに終わってか
バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
Job DescriptionをGitHub上に公開しました
こんにちは、yuku_tです。 タイトルのとおり、弊社の Job Description を GitHub で公開しました。 increments/job-descriptions 現在公開している Job Description は以下の通りです: Application EngineerNLP & Search EngineerProduct Managerこれまでエンジニア採用情報ページやWantedlyの各募集ページなどでも同様の情報を公開していましたが、GitHub 上ではよりシンプルに各職種の “責任” と “要件” のみを掲載しています。 ライセンスは CC0 1.0 Universal です。ご自由にご利用ください。 Job Description とはあるポストについて、責任と役割を記述した文書です。(Wikipediaでは「職務記述書」と訳されています。) フォーマット
スキルマップ作成のすすめ
チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果：スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
