Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
少人数チームでの部下の褒め方
10年近く5～6人のチームで回してきて、いくつか自分で学んできたことの中で、 今でも心がけているものを紹介する。 異動により今の環境が大きく変わるため、自分自身の整理の意味も込めてまとめてみた。 優秀な部下は大勢の前ではなく、一対一のときに褒める。優秀な部下は嫌でも目立つ上に、誰の目から見ても明白な成果を継続して上げていることが多い。 そんな部下を例え大きな成果を上げたからといって、 その部下と同列の者の前で大きく褒めると、他の部下の向上心が下がりやすい。 これは対象の部下本人のためというより周りのためだ。 普段優秀でない部下の大きな手柄は、大勢の前で褒める。本人の自信にも繋がる上に、周りから能力を認められているという肯定感が強くなる。 いい意味での周りからのプレッシャーとなり、仕事に対する姿勢も変わってくる。 結果が出ない者は姿勢や努力を褒める。結果として大きな成果に繋がらなくとも、そこ
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。 アジャイルコーチングやトレーニングを提供しています株
複数のエンジニアと開発を円滑に進めるためのissueの立て方 - クックパッド開発者ブログ
こんにちは。クックパッド特売情報ディレクターの田中です。 前回ヘルスケア事業部の濱田くんのエントリーでエンジニア以外のGitHubの利用について紹介されていましたが、今回は私がチーム開発で実践しているissueの立て方についてご紹介したいと思います。 チームが大きくなってきてヒズミが生じてきた 本来、ディレクターが開発を伴わない価値検証を十分に行った上で仕様を考え、デザイナー・エンジニアに引き継ぐのが理想的だと思います。 私自身も当初はその開発の進め方を採用していましたが、チームが大きくなり、ディレクター１人で関わるエンジニアが増えてくると、状況は変わってきました。 マルチタスク的に仕様を考えていたために詰めが甘い部分が多く、手戻りが発生してしまったり、仕様の準備が追いつかず、エンジニアの手が空いてしまうことが増えてしまったのです。 当初は自分自身の頑張りが足りないからだと、徒に気合いと根
朝Lint活動で細かな技術的負債を返済する - クックパッド開発者ブログ
買物情報事業部の八木です。クックパッド特売情報のAndroid部分を担当しています。普段はクックパッドのAndroid版（以後、本体アプリとします）の開発プロセスの中で特売情報の機能を開発しています。 本エントリでは細かな技術的負債を解消する為に本体アプリの開発チームが行っている朝Lint活動を紹介します。 2年近く経つ本体アプリのコードベース 私が買物情報事業部に所属する前は本体アプリを1から書き直すチームで働いていました。書き直し始めたのは2013年10月からなのでそろそろ2年が経とうとしています。2年前に設計された本体アプリは現在ではおよそ17万行を越え、日々どんどん変更が加えられています。 それらの変更の中には残念ながら悪いコードが含まれている場合があります。テストしづらいコードやテストがないコード、レビューに対する場当たりな対応や緊急のbug fixのために追加された汚いコード、
チームについての10の驚くべき科学的事実 | ライフハッカー・ジャパン
Inc.：ご存じのとおり、仕事において、「チームワーク」は成功するために重要なものですが、何が本当にチームを成功に導くのか、科学者がその「暗号を解読」したのは、ごく最近だといいます。 『Team Genius: The New Science of High-Performing Organizations』の著者、Rich Karlgaard氏とMichael S. Malone氏の研究によって、以下のことが明らかになりました。 1. 理想的なチームの人員は5～9人 経営者は、問題があると人員を投入して解決を図りますが、それとは裏腹に、上記の人数を上回るチームメンバーになると、成功の可能性が下がります。 2. 「相性の良さ」はチームの性能を下げる 衝突が生まれるくらいの多様性がないと、組織はマンネリ化する傾向があります。ここで重要なのは、人員配置などで見かけの多様性をつくることではなく、
朝会のこと - @m_seki の
朝会は毎朝やるミーティングです。一般的には、立ってやるとか、こんな話するとか、スタイルの説明がありますが、それでは私たちの朝会の実態を表している感じがしないんですよね。今日はスタイルだけではわからない、私たちの朝会の実態を説明したいと思います。ちなみに私たちのチームの規模感は 十数年 x 小学校1クラスより少ないくらいのイメージです。チケット数は数万くらい。 朝会の流れ 私たちの朝会では、現在のイテレーションに配置されたチケットを全部さらいます。メンバーが順に話すのではなく、チケットをひとつずつ見ていきます。（その結果、ほとんどのメンバーにパスが回ります。） メンバーの負荷の方に興味があるチームの場合はなにかしら変化の起きる可能性の高い「メンバーが手をつけているチケット」について聞いて回る方が効率もいいかもしれませんね。 私たちは、各メンバーが昨日やったこと／今日やること、ではなく、チーム
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
大きな業績を上げている部下が、職場で決められたルールを守らないとしたらどうするべき - ICHIROYAのブログ
もう30年以上前のことになる。 マネージャー向けのある研修で、こんな質問が出された。 「たとえば自部門の売上の3分の1を占めるような大きな業績を上げている部下が、職場で決められたルールを守らないとしたらどうするか」 ざっくりとしか覚えていないがそういう質問だった。 ああ、そういう部下を抱えながら、どうすべきか悩むのが管理職というものなんだなと、その時、管理職の仕事の難しさに震えた。 選択肢がふたつしかないとする。 A. その部下を叱責しルールを守らないなら他部への放出も辞さない構えで対応する B. その部下の業績に注目し、ルールを守らないことには目をつぶる その時の講師の答えは、いくつかの付帯条件がついていたが、基本的にBであった。 いや、しかし、ほんとうにそうなのかな、とも僕は思った。 たしかに、その部下を放出すれば、売上は3割下がる。 だけど、その部下が評価されて昇進していくにしても、
1回1冊30分「超高速！技術チーム読書会」 #とは - アニメイトラボ開発者ブログ
はい、"古きよき時代から来ました、真面目なSE、真面目にSE" CTO @bash0C7 です。 最近、アニメイトラボの技術陣ではじめた「超高速！技術チーム読書会」についてご紹介します。 進め方 20分という制限時間の中で1人1冊本を読みつつ付箋にメモ書きを残し、10分で互いのメモ書きを共有するというスタイルの読書会です。 これをデイリーで回しています。 1回の読書会では別の本を読みますが、その次の会は互いの本をメモ書きとともに交換して読むようにしていて、共通の知識の習得と問題意識の共有に務めています。 例え1冊全部読めなくても、毎回ごとに違う本を読むようにしています。1回1冊完結でリズムよく進めるためです。 タイトルの由来 歴史ものの作品が好きなのですが、先頃超高速！参勤交代という小説を読みました。映画化もされたのでご存知の方も多いかと思います。 https://www.amazon.c
突撃！隣の開発環境 パート7【永和システムマネジメント編】 ｜ DevelopersIO
こんにちは！おおはしりきたけです。パート7の今回は、アジャイル開発で受託開発を行ったり、アジャイルのコーチングやidobataというグループチャットアプリなどの開発も行っている永和システムマネジメントのアジャイル事業部にお邪魔しました。インタビューに答えてくださったのは、Idobataエンジニアの寺田さんと、受託開発でエンジニアをやられている松島さんです。 突撃！隣の開発環境とは 技術事例やノウハウなどは、ブログや勉強会などで共有されることが多いと思います。しかし、各社の開発環境や開発体制などは意外と共有されていないこと多いと思います。ノウハウの流出になるかもしれませんが、それ以上に、より良い開発を目指している会社さん同士で情報交換を行い、良いチーム、良いプロダクトを作っていくという志の会社さんの為の情報共有のための企画になります。開発環境や開発体制なども技術領域によっても変わってくると思
Mackerelチームのリモートワーク体制における日報とデイリースクラム - Hatena Developer Blog
日報を継続する方法があったら教えて欲しい、id:Songmu です。最近はMackerelチームのディレクター兼デベロッパーをやっています。 リモートワークと情報共有 Mackerelは、8名程度で開発しており、開発メンバーは京都・東京・愛知の3拠点に散らばっており、リモート勤務も各自の裁量で行えるようになっています。 リモートワークにおいては細かい情報共有をなるべく労力をかけずに行うことが必要になりますが、そのために以下のようなツールを利用しています。 開発手法としてスクラムを採用 Hatena::Groupによる情報共有 Github/Zenhubを用いたプロジェクト管理 Slackでのチャットコミュニケーション Zoomによるオンラインミーティング Mackerelチームでは、Hatena::Group上で日報を書くことを推奨しており、今回はその話です。 Mackerelチームの一日
チームの生産性を上げるために必要なこと | サイボウズ式
【サイボウズ式編集部より】「ブロガーズ・コラム」は、サイボウズの外部から招いた著名ブロガーによるチームワークコラムです。今回は日野瑛太郎さんによる「チームとして生産性を上げるには何に気をつければよいのか」について。 自分が所属しているチームが「いいチーム」であることの条件のひとつに「生産性が高い」ことが挙げられます。 生産性が高いチームで働くのは気持ちがいいものです。自分がしっかり価値を生み出していることを実感しながら日々の仕事に打ち込むことで自己肯定感が得られますし、ムダ残業やムダ会議に巻き込まれて疲弊することも少なくなります。プロジェクトが成功する可能性もきっと高くなるでしょう。 一方で、生産性が低いチームで働くのは苦しいものです。いくら働いてもそれがきちんと成果につながっているのかよくわからない状態は精神的につらいものがありますし、ダラダラと続く会議や、常態化した残業は人を疲弊させま
新米リーダーが必ずやらなければいけないこと。
働いてある程度経つと、リーダースキルを求められる。もちろんリーダーは天才でなくては務まらないものではなく、だれでもできる仕事だ。 しかし、リーダーと一般社員は、いわば別の仕事であって、作業者の延長にリーダーがいないのは周知のとおりである。 そのため、リーダーになりたての頃は求められる成果を勘違いしたり、スタイルを変えることができず苦労する人が多い。 前職では企業に向けて多くの研修を行っていたが、最も人気なのは年間を通じて管理職研修であった。リーダーとしてのスキル、マネジメントの手法を学びたいということで数多くの方が学びに来た。 だが、セミナーで得たノウハウやや本を読んで得た知識は実践しなければ身につかない。それは、どんな技術も同じである。 数学は自分で手を動かして問題を解かなければならない。 英語は実際に人と話さなくてはいつまでたっても身につかない。 プログラミングは、実際にソフトを作る必
最近の開発フローの改善と、「スプリントおじさん」という取り組み - しるろぐ
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。 背景 簡単にプロジェクトの背景を説明する。 スクラムっぽい開発をしている スプリントの期間は2週間 スクラムマスターはいるが専任ではない すでにリリース済みで運用中のWebサービスである 基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。 スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。 課題 以下のような課題があった。 バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしま
情報共有ができないチームの人間関係は破綻する | サイボウズ式
【サイボウズ式編集部より】「ブロガーズ・コラム」は、著名ブロガーをサイボウズの外部から招いて、チームワークに関するコラムを執筆いただいています。今回は日野瑛太郎さんによる「情報共有ができないチームのもろさ」について。 チームで働く場合、情報共有はとても重要です。仮に情報共有を一切しないのだとしたら、それは一人で働いていることとほとんど何も変わりません。チームで情報が共有されることではじめて、他人を手伝ったり意見を言ったりすることができるようになります。情報共有はチームワークの基本中の基本だと言ってもよいでしょう。 しかし、そんな基本中の基本であるはずの情報共有が、あまりうまくできていないというチームを結構よく見かけます。人数が少ないうちはある程度うまくまわっていても、チームの人数が増えるにつれて情報共有がいい加減になってしまうということも少なくありません。 僕がまだ会社員をしていたころに一
リモートチームのメンバーが気をつけている常識ではありえない４つの習慣 | Social Change!
リモートチームとは、物理的に離れた場所で働きつつもチームワークを発揮して、チームで助け合って成果を出していく働きかたです。私たちソニックガーデンでは、リモートチームを５年以上続けてきました。 この記事では、私たちが経験から学んできたリモートチームを実現するときにメンバーが気をつけておくと良いだろうと思う４つの習慣について書きました。 １）仕事に関する「雑談」をして連帯感を出す習慣 チームビルディングの第１歩は、チームを構成するメンバーをお互いに仲間だと認識することから始まります。それはたとえリモートチームであっても同じことです。 もしオフィスにいれば、飲み会や食事の機会があったりして、お互いのことをなんとなく認識することが出来るのかもしれませんが、リモートではそうはいきません。 そこでリモートチームでは、互いに認識しあう機会として、あえて仕事の合間に雑談をするよう気をつけています。雑談とい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CEDEC2015講演 チーム開発をスムーズにするために
捨てて開発できるチームづくり
