リーダー(管理者)ではなくエンジニア(実務者)でありたいと願う人々へ - おうさまのみみはロバのみみ
「お前は向いていないんじゃない、やってないだけだ」 この一文を読んでほんの少しでもなにかを感じた人は是非とも↓の本を今すぐに読むべきだ。 エラスティックリーダーシップ ―自己組織化チームの育て方 作者: Roy Osherove,島田浩二出版社/メーカー: オライリージャパン発売日: 2017/05/13メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 本著はみんなが考え、感じているリーダーシップという曖昧模糊な概念に対して具体性をもたらせてくれる。 それは「チームリーダーの役割は優れた人材が育つのを助けること」と定義付けていることだ。 このシンプルである意味で本質をついている定義付けが本著を名書たらしめているとぼくは思う。 この本の構成は1部〜4部(おおよそ本書の半分ほどを占めている)までが著者によるリーダーシップとはなにか？3つのフェーズの分類とそのときに期待さ
Quipper に入社して丸4年が経った - @kyanny's blog
blog.kyanny.me 一年経ってしまった。いろいろあった。一年前はオフィスのことしか書かなかったので、今年は自分のことだけ書く。 Engineering Manager 今年の1月に会社の組織変更があり、 Engineering Manager というポジションができた。国単位・技術分野単位などで開発者をいくつかのチームに分け、それぞれに Engineering Manager がいるという、いわゆるふつうのピラミッド型の組織になった。で、俺が東京オフィスの Web Developer チームの Engineering Manager になった。 上司（CTO）から話があったのは去年の11月頃だった。プロダクト開発チームがグローバル全体で50名くらいになってきて、そろそろ CTO 一人で見るのは無理がでてきた、そこでローカルに Manager をつくり各種の業務や権限を委譲していき
「チームでプロダクト開発するための取り組み」の補足 - maru source
昨日、Cookpad TechConf 2017にて「チームでプロダクト開発するための取り組み」というタイトルで登壇しました。 speakerdeck.com www.youtube.com 発表後にTwitterをエゴサーチしてると、評判が良かったようで一安心していました。 しかしその評判が想像以上に良くて、ちょっと自分の中でギャップを感じました。 で、よくよく考えてみると、一つ前提が抜けていたなと思い、今ブログを書いています。 その前提とは チームメンバーはすごく技術力も実装力もあるエキスパート 僕などよりも全然高いレベル 対象とするプロダクトを現時点で作れるレベルの能力を持っている もしくは作れるレベルのポテンシャルを持っている かつ、自分自身で成長・自走していくことができる というものです。 この前提があると何が良いのかを少し説明します。 一つ。チームメンバーには作ろうとしているプ
Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”（後編）。Developers Summit 2016
Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”（後編）。Developers Summit 2016 変化の速いビジネス環境に対応するために、多くの企業がアジャイル開発の採用を進めています。 本記事では、2月18日に行われたDevelopers Summit 2016のセッション「現場から変えた”サービスの作り方” ～何を作るのかではなくなぜ作るのか～」で紹介された、Yahoo! Japanにおけるアジャイル開発の導入と実践、そして改善がどのように行われたのかについての内容を記事にしました。 （本記事は「Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”（前編）。Developers Summit 2016」の続きです） SCRUMを導入するときにサポートすること 私たちがアジャイル開発をサポートするときに気を
脱・読みづらいコード！今日から一段上のプログラマーになる方法 5 選 - xin9le.net
「ソースコードを綺麗に書く」というのは、プログラマーであれば誰しもが心掛けたいと思っている極めて重要な事柄です。そもそも「綺麗なコードってなんぞ？」という感じですが、いくつかあると思います。 改行位置/空行の数/インデントなどに一貫性があり整っていて、パッと見が綺麗 「こんな難しいことがこんなに簡単に書けるなんて！」というエレガントさ 理解しやすい etc... ひとつ目は美的感覚の問題なので、基本的には人それぞれということで今回は言及しないことにします。チーム開発の場合はソースコード整形ツールで一定のクオリティを維持するのがお手軽ですね。ふたつ目もさておき、今回は「理解しやすさ」について考えてみようと思います。主にプログラミングの勉強を始めた人向け。 ※ 画像を借りているだけで、この本のオススメをする記事ではありません！ 1. そのコードを誰が読むのかを考える 「理解しやすいコード」は「
日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ
私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この２つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか？いくつかの事例を通じてだんだん見えてきたことは１つのことをこなすための「物量」が違うということです。
一休.comでサービス開発をやるということ - zimathon blog
ちょっとタイトルの主語が大きい（笑） 概要 昨日、今日でマネジメントメンバー（社長や各チームのリーダー等、全員で30人ぐらい）で合宿をしました。（その時に感じたことや得たものは別途） その時に今のエンジニアリングチームがこの2年をかけてどういった変化をしてきたか、その中で自分の中でどういった変化があったかを話す機会がありました。 今のこの思いはまとめておいたほうがよいかなと思ったので、ざっとまとめておきます。 過去と今 2年前 お世辞にも一休のエンジニアリング力は高いと言えなかったと思います。 情報共有はメール、アプリケーションのデプロイは手動ビルド、手動モジュール配置と世の中的には遅れていました。 そういった環境にストレスを感じていて、何とかこの現状を変えたいとアクションをしていきました。 技術顧問に伊藤直也さんさんを迎えたのはこの頃です。 （詳しくは以下のスライドにまとめられていますの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外注が主な企業でどのように内製開発を立ち上げ・進化させているのか？
【資料公開】強いチームの作り方(デブサミ2016版)