GitHub is undergoing a full-blown overhaul as execs and employees depart — and we have the full inside story
Former GitHub CEO Tom Preston-Werner shows off the Scotch collection kept at the GitHub office in 2012. Owen Thomas, Business Insider Wanstrath became CEO in 2014 after GitHub was embroiled in a sexual-harassment scandal by a female employee who quit. GitHub's own internal investigation determined that no sexual harassment took place, but said there were other leadership issues going on. Ultimatel
サーバントリーダーシップが陥れる「良い兄貴問題」 - Noize
今回の記事ではエンジニアやIT業界ではすでに定着した感のあるポッドキャスト『rebuild.fm』の#123について触れてみたいと思う。 rebuild.fm いきなり横道にそれるが、podcastはランニング中や移動中に1.5倍速で流して聞けるのが便利。一方でメモがとれず終わった後にきちんと整理する時間を取らないと「要旨はなんだったのか」が曖昧になり自分に残らない感があるのが悩ましいですね。 今回のゲストである @naoya_itoさんが『エンジニアチームのリーダーシップ』というテーマについて『Fate/Zero』というアニメの11話「聖杯問答」になぞらえてうまく例えていた。 「聖杯問答」の内容について、超端的に言うと、世代を超えた3人の王が統治の仕方を論じ、民や臣に厚いタイプの王が大いなる野望を追いかけるタイプの王に負ける、という話。 趣旨：サーバントリーダーシップの是非 放送を通じた
2016年抱負 "三方良しマネジメント"で成果を残す | ATKブログ
あけまして、おめでとうございます。毎年抱負をブログに書くことにしているので、今年も書きます。 2016年 抱負 三方良しマネジメントで成果を残して、組織力と自分を成長させる。 もともと"三方良し"という言葉の由来は、 (1)売り手良し (2)買い手良し (3)世間良し の三方にとって"良し"を大事とする近江商人の思想・行動哲学が語源。（もともと、EC事業部の管理職者以上がサービスや組織の課題や方針について議論する場で、"三方良し"になっているか？で議論することが過去に何度かあったのでそれを抱負にした。） 自分にとっての"三方良しマネジメント"の三方の対象は以下です。 １．顧客（ショップオーナー、購入者）の利益 ２．仲間（チームメンバー、サービス運営に携わる社外の人も含む）の利益３．会社、事業、サービスの利益、成長 元々の言葉の由来とは異なってはいますが、上記３つの視点で、それぞれの立場の人
エンジニア社員「今月から週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」 僕「」 | maximum80のブログ
新田です。 最近渋谷区の条例で同性パートナーシップの証明書が発行が話題になったり、各所で 多様性 という言葉が注目を集めてますよね。 「指示待ち人間」はなぜ生まれるのか？ 有能な人たちが「働きたくない」と嫌がる会社の特徴。 また最近Facebookで上記のような記事をよくみかけまして、ダイバーシティ・マネジメントについて自分でも考えていることや、同じような壁にぶつかった経験があるので久しぶりに投稿してみようと思います。 エンジニア社員「これから週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」 僕「」 タイトルにしてみましたが、今からちょうど一年前ぐらいに実際に社内であった出来事です。弊社で働いているカナダ出身のエンジニアの社員から、或る日突然このような提案を受けました。 会社の業態、職種にもよるとおもうのですが、殆どの場合 「え、ちょっと何言ってるかわからないんですが。。」 となって
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
作り直し - hitode909の日記
ソフトウェアを作ってて、作り直したり、書き直したりするべきかどうかという話をすることがある。 大きな規模だと、ソフトウェアを作り直す、というところから、小さな規模だと、込み入った機能を書き直す、くらいまであるけど、作り直すとうまくいくのは、次の二つのうちどちらかではないか。 最初に作ったときより世の中の技術が発展したとき 昔のコンピュータでは収まらなかったとか、昔は良いライブラリがなかったけど、今はある、というとき。 単に今ありふれた技術で作り直すと、よいものができそう。 最初に作ったときよりはコンピュータのスペックが上がったので、そのつもりで、並列度倍に上げても止まらないし、より速く動かせる、とか。 昔はバッチで計算しないといけなかったけど、今ならリアルタイムに返せる、とか。 昔は依存管理のよいライブラリがなかったけど、今ならこれ入れたら簡単、とか。 最初に作ったときより人間の技術が発展
Pull Requestのレビューが辛くて会社をやめたい
私はプログラマに向いていないのかもしれない。 うちのチームではコミットをmasterブランチへマージする前に、Pull Requestを出してそれをリーダーや他の人がレビューすることになっている。（たぶんよくあるフロー？） そのPull Requestでもらうコメントを見ると死にたくなってくる。特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 レビューにおいてそういった強い言葉がときとして必要なことは理解している（そういえばこなものもあったなと思い出した http://cpplover.blogspot.jp/2013/07/linuxml.html ）。またそういったコメントを残す相手との仲が険悪なわけでもない。またよいと思ってくれたらしいところは褒めてくれたりLGTMしてくれたりもする。 だけどそれでも辛い。きつい言葉を向けられる
気が狂った設計 - hitode909の日記
大きめのこととか，自信のないところを触るときは，コード書く前に，こういう作戦考えてみたけどどうですかって聞いてみたり，こういうことやりたいんだけど一緒に考えませんかって，いっしょに話して設計考えたりするとよいと思う． 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので，未然に変な設計のままコード書いてしまうのを防げる． 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う．我が社にはそんな強い言葉でレビュー書く人はいない． 我が社には，普段から強い言葉を発する人もいなくて，みんな物腰柔らかな変な言葉を話している． 言葉使いや文体は，ずっと過ごしてると同僚から移ったりするので，普段からそういう言葉を話していると，全体の雰囲気も悪くなりそ
インフラで実践したチームビルディングそれはサバ天 : インフラエンジニアに成る
スクラムにあこがれて。 インフラで実践したチームビルディングそれはサバ天 from ume3_ カンバンをやってカイゼンをしたというお話です。 ここ1年ぐらいずーっとリーダーとして チームビルディングに勤しんでいた。 チームを強くするにはどうすればいいか？ チームでわいわいやるにはどうすればいいか？ 簡単な話、仕事ってどうやったら進むのか？ それをつきつめていった結果、なぜか特異な結果が生まれた。 なんだこれは。 社内に共有したものをせっかくなのでこちらへ公開という流れです。 モザイク多いのは勘弁。 これでも、けっこう内容けずったのです。 やっていることは、ホワイトボードの前で付箋紙はってわいわいやっているだけ。 スライドでは説明不足ですが、サイクルがちゃんとあって ぐるぐる回すことでチームが加速化するのが狙い。 見える化の力を今も実感しています。 こういったフレームワークの活用からの発展
より良い組織を作るために - クックパッド開発者ブログ
はじめに こんにちは、投稿推進部部長の勝間です。 突然ですが、皆さんは「組織における課題」について考えたこと、意識したことはあるでしょうか。 「組織における課題」なんて言葉を使うと、たとえば 事業戦略の方向性 人事評価制度 マネジメント層の育成 など、少し高いレイヤーの話が思いつくでしょうか。 ともすれば自分とは無関係な話のように思えるものかもしれません。 一方で、このようなものはどうでしょうか。 なんとなく、最近社内の空気変わった気がする なんとなく、隣の部署が何やってるかよくわからない このような、もやっとした感覚、は普段働いている中で感じたことがある人も少なくないかもしれません。 こういった「具体的な何か」というより「抽象的な違和感」を私たちが抱くことも組織における課題といってもいいかと思います。 このような組織における課題、違和感を認識したとき、私たちはどのように向かい合うべきでし
最近の開発フローの改善と、「スプリントおじさん」という取り組み - しるろぐ
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。 背景 簡単にプロジェクトの背景を説明する。 スクラムっぽい開発をしている スプリントの期間は2週間 スクラムマスターはいるが専任ではない すでにリリース済みで運用中のWebサービスである 基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。 スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。 課題 以下のような課題があった。 バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしま
第1回ペパボテックカンファレンスで見積りと計画づくりについて発表しました - けんちゃんくんさんのWeb日記
(当日の様子や、なぜこのようなイベントが開催されたのかはCTOのエントリ 第1回ペパボテックカンファレンスを開催しました #pbtech - delirious thoughts をご覧ください。) ペパボテックカンファレンスという企画が立ち上がったとき、最近ずっとスピリチュアルなことばっかりやってるし、テッキーなことはまだ発表できるほど成果だせてないし、という思いがあって登壇を保留していました。(普段外に出ない人に発表してほしいというコンセプトもあり) ただ、社内でも「見積りと計画づくり」について何度か説明しており、参考文献にあげたような書籍を全部読まなくても概要を理解できるような資料の必要性を感じていたので、自分の考えていることを技術という切り口で言語化してみるといいかもしれないと思い、今回発表させていただきました。 現実社会の厳しさと戦っている皆さんのヒントになれば幸いです。 さて、
雑な発想を活かすチーム作り - クックパッド開発者ブログ
インフラストラクチャー部の成田（@mirakui）です。インフラストラクチャー部は、クックパッドで扱っている全サービスのサーバを設計・構築し、運用しているチームです。2015年3月現在、6人のメンバーで運用をしています。 さて、この運用というのは外から見ていると保守的な仕事に思えるかもしれませんが、その実、とてもクリエイティブな仕事です。クックパッドのサービスは一日平均で10回以上デプロイされており、アクセスも日々増え続け、状況は刻一刻と変化しています。今日動いているサーバ構成が、一年後に通用するとは限らないわけです。そんな変化に追従するためには、サーバを常に改善していかなければなりませんし、チームにも柔軟な発想が求められます。 「さあブレストしよう」→アイデア出ない問題 さあ業務を改善しよう、と意気込んでブレインストーミングを開いても、なかなか十分なアイデアが出きらないのはよくある話です
コードレビューについて - (define -ayalog '())
普段お仕事している中で何故かコードレビューをしている時間がわりとあって、暇さえあれば(暇がなくても)コードレビューしている。 そんな中でどういうところを見たらいいのか、あるいは見るべきなのかというのが自分の中である程度蓄積された気がするので書いてみる。あと最後に普段考えていることを少し書いた。 前提 現在の僕の参加しているプロジェクトはこんな感じ Rails プロジェクト( AngularJS 使ったりしている) Git 使ってる( Pull Request ベースの開発で以下が merge 条件) 2 人以上に approve される テストが通ること(継続的インテグレーションの実施) 静的コード解析は導入している( Rubocop, jshint, pre-commit など ) テストのカバレッジは計測していない(月一くらいで測ってるらしいんだけど、だからどうっていう話はない) プ
エンジニアの評価観点について - @katzchang.gist
techass.md エンジニアの評価観点について こんにちは。 @katzchangです。 VOYAGE GROUPでは人事評価制度の一つとして技術力評価会というのが年に2回ほど開催されて、半年くらいの仕事から何かテーマをピックアップしつつ、別チームのエンジニア2名とお話をしつつ、なんと評価までされてしまうという、とても楽しい会があります。 評価する側のエンジニアも多様で、ある程度の評価軸はありつつも、それぞれの質問や評価はそれなりに個性が出るものだろうなーと眺めています。ということで、私なりの質問や評価のポイントをいくつか挙げてみます。 質問に対して明確に答えるための手段を知っているか？ 例えば「キャッシュの有効時間はどれくらいか？」みたいな質問をすることがあるとします。当然、「わかりません！」で終わると残念なのは皆知ってるので、頑張って答えようとします。しかし、その場で「xx分です！
サービス開発エンジニアからマネージャになった話 - クックパッド開発者ブログ
はじめに こんにちは、レシピ投稿推進室の勝間（@ryo_katsuma）です。 techlifeでの執筆は5年ぶり（！）になります。 さて、そんな私も今年2014年の5月にエンジニアからサービス開発の部署のマネージャに転身しました。 そこで今回のtechlifeブログは、いつもの技術ネタとは少し異なるテーマとして、「クックパッドにおいて、エンジニアからマネージャに転身する」ことが、どういうことなのかを自分自身で振り返り、まとめたいと思います。 エンジニアが自身のキャリアを考える上で、少しでも参考になれば幸いです。 現状 私は、2009年5月に中途入社し、今年で6年目になります。この年数は、エンジニア全体はもちろん、社内全体で見ても古い方になります。 これまで、技術部、HappyAuthor部（現在、私が所属している前身になった部）、新規事業部、プレミアム会員事業部...など、いろんな部署で
アプリのリリースに必要な「引き算担当」について - @hitoshi annex on hatena
起業してアプリを出す。 一言で言ってしまえば簡単なんですけど、最初のそのアプリリリースの時に失敗する人が少なくない気がします。 僕の観測範囲だけでも、独立してアプリを出そうとして開発に失敗、「作り直し→リリース延期」となるケースを定期的に目撃しますので、それなりにそういう失敗をする人はいるんじゃないでしょうか。これが20代の若手が失敗したというならまだ分かるんですが、経営者としてすでに十分な実績のある、僕自身も尊敬するような方がその陥穽に陥ったりしていますので、これはもう能力とか才能の問題でなくて、むしろ「知識」の問題なんじゃないかと思うんですね。 そういう僕も、kiznaというアプリを出そうとして落とし穴にはまってしまい、結局日の目を見なかったという苦い経験をしていますので、こういう経験はちゃんと共有して、無駄な犠牲者が出ないようにすべきだと思うわけです。 というわけで、初めてアプリを出
【エンジニアは神だと思う】エンジニアの「できる」と、非エンジニアの「できる」は違う | HRナビ by リクルート
とある機能の実装を相談して、エンジニアの人が「できます」と言ったとき、僕はまずは、こう返すようにしています。 「どのくらいの時間がかかりそう？ あと、どのくらい大変そうか、ちょっと調べてみて？」 これを聞くようになったのは、僕はこの「できます」の件で、何度も絶体絶命の危機に陥ったことがあるからです。 ……その前に、はじめまして。清田いちると申します。できることは、サービスやサイトのディレクションと、鼻を凹ませながら膨らませることです。 今まで、ココログ、ドーナッツ！（絵本）、ギズモード・ジャパン、Zenback、ShortNote、などの企画を立ち上げてきました。個人ブログは小鳥ピヨピヨといいます。 唐突ですが、僕は、エンジニアのことを「神」だと思っています。 崇め奉っている、という意味だけではなく（そういう意味もありますが）、西洋的な意味での「創造主」。 世界を作ったのはエンジニア。エン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.inouetakuya.info/entry/2014/12/08/214435
リモートワークの話
