本当はすごいKPTで強いチームを作る for エンジニア - Qiita
この通り、KPTはみんなでやるデバッグ作業です Problem -> Try -> Keepと全てはつながっています 繋がっていないKeepは？ ナレッジ共有と捉えると良いと思います ただ、その場合もはじめに何かしらの問題があって〜からスタートすることが多いのではないでしょうか KPTすごい これで何となく伝わりますかね？ KPTが毎週上手く回っている ＝ 毎週バグを潰している １年続けると KPTが回っている → テスト53回、デバッグ53回行って、チケット消化しつづけ改善してる状態 KPTが回っていない → テスト0、デバッグ0、チケット消化数0 KPTを上手く回すには 伝わったとしたら幸いです それでは次にKPTを上手く回すことを目標にします そもそも上手く回ってる、良い状態ってどんな感じでしょうか？ 良いKPT＝良いデバッグ エンジニアならもう既にわかるはずです 良いProblem
企業には、スター人材の採用も必要だが、「有害人材」を雇わない努力も不可欠である | 人材採用・育成｜DIAMOND ハーバード・ビジネス・レビュー
有能な人材を雇えば5000ドル程度の価値がもたらされるが、「有害な人材」を雇うと1万2000ドル以上のコストになる――ＨＢＳからこんな報告書が発表された。 スーパースター人材は、企業にとって執心の的である。引く手あまたの彼らは、最大の関心を寄せられ、最高のチャンスを与えられ、高額な報酬を手にし、挫折した時には自信を回復できるようケアされる。 このような特別待遇が適切なのかという疑問の声もあるものの、スター人材の影響力が並み外れて大きいことは明らかだ。ベイン・アンド・カンパニーの調査によれば、最も有能な人材の生産性は平均的な人材の4倍も高いという。他の研究でも、彼らは事業の利益の80％を生み出すこと、そして、自社に他の有能人材を引き寄せることが示されている。そうしたスター人材は、会社の全従業員の上位3％～20％を占める。 だが、ハーバード・ビジネススクールから最近発行された研究報告書によると
ブルックスの法則 - Wikipedia
ブルックスの法則（ブルックスのほうそく）は、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。 これは1975年にフレデリック・ブルックスによって出版された著書『人月の神話』[1]に登場した。 根拠[編集] ブルックスによれば、この法則が成り立つ主な理由は以下の通りである。 新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる ソフトウェアプロジェクトは、複雑な作業である。また、新たにプロジェクトに参加した人は、仕事に取りかかる前に、まず開発の現状や設計の詳細などを理解しなければならない。つまり、新たに人員を追加するには、その人員を教育するために、リソースを割かなければならないのである。したがって、人員の増加がチームの生産性に与える効果は、短期的にはマイナスになる
WEBエンジニアがプロダクト開発を通じて学んだチームビルディングに関する5つのTIPS
インタ ーネットの世紀のプロダクト ・マネジャーの役割は 、最高のプロダクトの設計、エンジニアリング、開発を担う人々とともに働くことだ — 『How Google Works』 本記事は Livesenseその3 Advent Calendar 2016 の24日目の記事です。いきなり格好つけた言葉から入ってしまいましたが、クリスマスイブなので。同様に以下ポエミーかつエモ目の記事となります、ご容赦ください。 私は転職会議というWEBサービスの開発に携わっており、2年ほど前から開発チーム（エンジニア/デザイナ/ディレクタの混成チーム）のマネージャーとしてプロダクトオーナー（PLは持たない）兼エンジニアマネージャーのような仕事をしてきました（最近では二足のワラジに限界を感じてプロダクトマネージメントのみに集中していますが）。 本記事では、プロダクト開発に携わってきた中で、グロースに繋がったと思
開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
他人と自分を比べないこと - WETな備忘録
今にいたるまでずっと、他人と自分を比べて、そして自分が優れていたときの優越感と、自分が劣っていたときの劣等感を、そういう臆病な自尊心を、原動力に生きてきたように思う。 しかし今は、少しずつだが、他人と自分を比べない方法を見つけつつある気がする。 自分の原動力が自尊心であることに気づき始めたのは2年前の夏だったようだ。 まさにこの数日後、僕は当時所属していた会社から、今の会社に転職することになる。社員数は、1500人から、15人になり、エンジニアは5人に満たなかった。 win as a team, win as a result プログラミングに触れてからまだ3年経っていなかった僕は、スタートアップのエンジニアである彼らの高い技術力についていくのに必死だったし、居場所を自覚するために業務にいち早く貢献したかった。 そういうとき、自分の評価を気にするあまり能力を偽って（強がって？）大きく見せる
自分の仲間を探すなら能力や性格よりも、自分と同じだけコストを払ってくれる人を選んだ方がいいという話 - 僕のYak Shavingは終わらない
元後輩？から「どんな人を創業メンバーに選ぶべきですか？」質問をされたので、自分なりの回答をした。 正直今の会社の創業メンバーは、前職同期である社長の素晴らしすぎる人脈もあって、奇跡的な能力のゴールデンバランスと性格的相性の良さを兼ね備えた6人が手を上げ起業している。 なので、このこと自体は全然参考にならないよという前置きをおいたあとに、自分なりに思ったことを述べた。 コストを払わない人と一緒にやるとチームが自然解散する 起業前によくあったのは、エンジニア1人＋企画2人とかのパターン。 大抵が本職がある状態でのプライベートプロジェクトで、土日のどちらかで1, 2週に一回集まって企画を考えてプロダクトに落として行くということをやっていた。 で、よくあるのが企画中はみんなでかなり盛り上がって笑い合って、じゃあこれで行こう！絶対いける！みたいになるんだけど、はいじゃあ実装開始ってなるとエンジニアが
スクラムチームで属人化させずにiOSもAndroidもRailsもAWSも全部やっていく話 - ainameの日記
去年から「家族アルバムみてね」というスマホアプリの開発を担当している。（公にはそんなに言ってなかったので改めて宣言しておきます。） 子供の居る家庭向けのデジタルアルバムサービスで、お子さんが居る方はぜひ使ってみてください。 mitene.us 自分は子供どころか結婚もしていないのでターゲットユーザという感じではないけど、 社内の新規プロジェクトとして初期から関わらせていただくことが出来て、 スマホアプリ開発どころかAPIサーバーのRails以外に関しては経験がほとんどないままここまでやってきた。 開発者が（ほぼ）4人という割りと少人数チームでそれぞれのエキスパートのような人がチーム内に居ない中、 iOS版のためにObjective-C書いてAndroid版のためにJava書いてAPIなりWeb版のためにRuby書いて本番環境のために AWS一から学んで環境構築したりして改めて振り返るとやっ
共通化でモチベーションと効率が低下した話 - Qiita
自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二つの共通化です。 コードの共通化 今までのアプリでは元のアプリのソースからフォークするなどして別のプロジェクトとして独立させそれに対して各チームが開発を行うと言う感じでしたが、今回の共通化ではゲームのコアとなるロジック部分をサブモジュールとして分離し、各アプ
QiitaやKobitoを作る開発チームの文化 - Qiita Blog
こんにちは，yaottiです． 今日はQiitaやQiita:Team, Kobitoを開発するチームでぼくたちがどういう文化，価値観を大切にしているかをお話したいと思います． HRT, SPOF, LeanIncrements(あまり知られていませんが，Qiitaを作っている会社の社名です)の開発チームが特に大切にしているのは以下の3つです． HRTを大切にしたコミュニケーション属人性を極限まで排除する重要な価値に集中する以降でそれぞれ具体的に見ていきます． HRTを大切にしたコミュニケーションHRTとは HRTとはTeam Geek ―Googleのギークたちはいかにしてチームを作るのかという本にある考え方で(あらゆるチーム開発者に読んでほしい!)，Humility(謙遜), Respect(尊敬), Trust(信頼)の3つを意味しています． 「驕り高ぶらないようにしよう」「相手を尊
なぜ上司は「無能」なのか？ - 三つ数えろ
一般論として「上司は無能」である。 職場においてチームに課せられた目標に対し、部下の能力を適性に応じて配分させ、その目標達成に集中することができる環境を、政治的、予算的に整え、またその取り組みの中で部下の自発的な成長を促すことができる有能な上司の下で働けることは、いち労働者にとっては至福と言っていいだろう。しかし、それはかなわない。仕事におけるストレスの大半は無能な上司だ。 なぜ上司はかくも無能なのか。我々はその事実にどう対処すればよいのか。それには次のような答えがある。 ピーターの法則とは 組織におけるあるべき昇格制度とは ピーターの法則とは ピーターの法則をご存知だろうか。Wikipediaから引用してみよう。 ピーターの法則（ピーターのほうそく、英: Peter Principle）とは組織構成員の労働に関する社会学の法則。 能力主義の階層社会では、人間は能力の極限まで出世する。する
ザックジャパンの本当に深刻な問題
2連敗に終わった欧州遠征から3日が経ち、その間あちこちの言説を見て回っていたのだけど、ザックが無能だとか選手任せだとか、Jリーグで結果を出している選手を選んでないだとか、そんで更迭すれば万事解決みたいな短絡的な意見ばかりで本当にげんなりしてしまう。 ザックジャパンが直面している根本的な原因については、ベラルーシ戦の後に何となく思い浮かんでいたのだけど、書きだすと長くなる話なのであえてそこまで突っ込んではいなかった。でもその辺の言及をしている意見を今までほとんど見なかったので、ここらでちょっとまとめて書いてみる事にする。 端的に言うなら、今のザックジャパンは「太陽が見えなくなってしまっている状態」なのではないかと思っている。 太陽とは、これまで築き上げてきたザックジャパンのサッカーの根幹をなす部分である、遠藤-本田-香川のラインを意味する。遠藤の試合の流れを読む能力、本田のキープとキックのパ
「Lord of Knights の裏側見せます！～Unity + PHP + MySQL で作るスマートフォンゲーム開発～」の資料を公開しました｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
ホーム 技術ブログ 「Lord of Knights の裏側見せます！～Unity + PHP + MySQL で作るスマートフォンゲーム開発～」の資料を公開しました 「Lord of Knights の裏側見せます！～Unity + PHP + MySQL で作るスマートフォンゲーム開発～」の資料を公開しました 昨日2012年4月10日に行われたイベント 「Lord of Knights の裏側見せます！～Unity + PHP + MySQL で作るスマートフォンゲーム開発～」 の資料を公開しました。 イベントの詳細はこちらです。 → 【Lord of Knights の裏側見せます！】 ～Unity + PHP + MySQL で作るスマートフォンゲーム開発～ 前半のクライアント側の発表をAimingの細田さんが、後半のサーバサイドの発表を私（松井）が担当させていただきました。 細田
CEOが自ら語った「イノベーションを起こすためのGithubの哲学」 デザイン会社 ビートラックス: ブログ
人材の移動の激しいスタートアップ業界にいながらも殆どの従業員が辞めないことが話題となっている、ソーシャルコーディングサービスGithubのCEO、Tom Preston Werner氏が「イノベーションを起こすためのGithubの哲学」について先日のOpenCoSFというイベントで語った。 「イノベーションとは新しく何かをはじめることだ、たとえ他の人がそれをクレイジーだと思っていても」サンフランシスコはイノベーションを起こすには最高の場所だ。何か新しいことをすることはリスクだ。何が起こるかわからない。イノベーティブになるには勇気がいる。 他の人が「こんなもんクレイジーだ！」って言ったとしてもこれをやるぞという強い意思が必要だ。実際にスタートアップはとても高い確率で失敗する。でもサンフランシスコの文化ではたとえ失敗したとしてもまったく問題ないんだ。 実際にたくさんの起業家が失敗しているし、新
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
