強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016
強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016 業務で行われるソフトウェア開発プロジェクトのほとんどすべては、何らかのチームによって行われています。そしてそのプロジェクトが成功するか失敗するかを左右する大きな要因が、技術力よりも人間系にあることはよく指摘されることです。 では、その人間系に注目して強いチームを作るにはどうすればよいのか、そのヒントを多数紹介したセッション「強いチームのつくり方」が、2月19日に行われたイベントDeveloper Summit 2016（通称デブサミ）で行われました。この記事では、そのセッションの内容を前編、中編、後編の3本の記事で紹介します。 いまお読みの記事は前編です。 プロジェクトの多くは技術ではなく人間系で失敗している 吉羽 龍太郎氏（Ryuzee.com）。 吉羽と申します。いままで野村総
優れたエンジニアを採用できないワケ | POSTD
あなたは技術者採用の面接が苦手ですね。そう、あなたですよ。間違ったスキルを探し求め、適正の無い人たちを採用して、自分自身と会社に悪い影響を与えているのです。応募者リストを見直さなくとも、今までとは違う人材を採用し、会社の業績を上げ、あなた自身も仕事をもっと楽しめるようになりますよ。 いささか大胆な物言いだということは承知しています。仕事での経験を積み面接を担当するようになってから10年、大小の企業の様々な部署で、技術者を雇うための数多くの面接をしてきました。採用する人材が会社に及ぼす影響についても見てきました。完璧な採用を目指せというつもりはありません。私自身がこれまで何度もしてきたあらゆる失敗をあなたが犯さなくても済むよう、お伝えしたいのです。私がこれまで学んできたことは次のようなことです。 誤った判断基準 1. 応募者の現時点の知識に基づいて採用しない 面接で犯しがちな最初の間違いは、
優れたリーダーに学歴は関係ない。Googleが自社社員をデータ分析して得られた意外な知見 | ライフハッカー・ジャパン
Inc.：シリコンバレーで成功を収めている人は、スタンフォード、MIT、ハーバード出身の天才ばかりだと思っていませんか？ 冴えわたる技術力を武器に、ビジョンに突き動かされ、急場をしのぐ。そんな典型像を持っている人は多いでしょう。Googleに就職するには、スタンフォードまたはMITを出ていなければならないと言われていた時期もありました。2012年ごろまでは、大学を出て10年以上たっていても、大学時代や高校時代の成績を聞かれるのが常だったのです。 しかしGoogleは、仕事での成功と学歴はまったく無関係であることを発見しました。従業員がリーダーとして成功を収める条件を知るためにデータを分析したところ、驚くべき結果が出たのです。 結論から言うと、典型的なイメージはまったくの間違いでした。 リーダーとしてもっとも重要な資質は、卒業した学校でもIQでもありません。むしろ、もっと退屈な人物を連想する
社内ベンチャーの経験から学んだ新規事業の失敗を防ぐための５つのポイント | Social Change!
企業が新規事業を創り出す為にはどうすれば良いでしょうか。それまでの延長上にない事業を創り出すためには、それまでの延長上でない形が必要なはずです。その一つの取り組みが「社内ベンチャー」でしょう。 社内ベンチャーとは、既に事業をもっている大企業の中で、新規事業創造を目的に独立した事業部隊として作られる組織のことです。法人登記をしていないため、法人格をもった会社ではありません。 「Soup Stock Tokyo」が、三菱商事の社内ベンチャーから始まったことをご存知の方も多いでしょう。以下の本に詳しく書かれており、私も読みましたが、とても興味深い内容でした。 私たちの会社ソニックガーデンも、元々は大企業の社内ベンチャーとしてスタートして、今は買い取って完全に独立した会社にさせてもらっています。社内ベンチャーをしていた期間は２年間でしたが、そこでは非常に沢山のことを学ばせてもらいました。 ただ、私
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
サーバントリーダーシップ
職場やプロジェクトのメンバーを支援して、目標達成に導く、奉仕型のリーダーシップ。ビジョンを提示したうえで、コミュニケーションや信頼関係の構築を重視する。 経済環境が悪化するなか、政治にも経営にも「強いリーダーシップが必要」という論調が高まっています。強いリーダーシップというと、自ら先頭に立って事業をけん引したり、部下への指示命令を徹底させたりするリーダー像が思い浮かびますが、部下の自主性を阻害して、継続的に成長させられない弊害を生むこともあります。 これとは逆に、リーダーが組織のメンバーを支援することによって、組織の潜在的な力を発揮させるのが「サーバント（奉仕する）リーダーシップ」です。米AT＆Tでマネジメント研究センター所長を務めたロバート・グリーンリーフ氏が定義し、1977年に同名の著書を出版しました。2008年末に出版された邦訳*は、リーダーシップ関連の書籍のべストセラーになっていま
レビュアーとレビュイーの関係に関して - 職質アンチパターン
感じていた違和感の正体がわかった． レビューにおいて，レビュアーとレビュイーの関係には上も下もない． レビューという場では，両者の立場は対等でなければならない．さもなければ，「このレビューおかしい気がするけれど，あの人は立場が上だから指摘しにくい」だとか，「相手は格下だから適当にレビューしても良い」だとか，そういう良くない雰囲気が形成されてしまう． 確かに，レビュアーというポジションはチームの技術力が高い人やそれに伴ってパワーのある人が担うケースが多いと思う．レビュイーはそれに萎縮してしまいがちというか，僕もその1人なんだけれど，そういうのは実際のところ保身でしかなくて，下手に意見言うとレビュアーとの関係悪くなりそう，みたいな卑屈な理屈に基づく駄目な萎縮な感じがする．こういう良くないところはちゃんと直して，健全化していかなければまずい． あとレビューされた内容は素直に受け入れるべきだと思う
メーカー復活で浮き彫りになる「潰しの利かない人」は、これから何をすべきか？【対談:New Order-松井 博×竹内 健】 - エンジニアtype | 転職type
創刊2年を迎えた『エンジニアtype』が送る特別企画。スマートフォンの普及、メーカームーブメントの到来、スタートアップの台頭……。さまざまな文脈が重なり「オリジナルなモノづくり」が隆盛する今、イノベーションはどのように生まれるか？毎週更新される業界を超えた大物たちによる4つの対談を通して、未来の価値創造について考えよう 日本のメーカーが危ない――。そんな言葉を耳にするようになってから、どれほど時間が経っただろう。ソニー、シャープ、パナソニック……かつては世界で大きな存在感を放っていた企業の凋落は、どうすれば止められるのだろうか？日本メーカーが再起をかけるためには、何が必要なのか。元・アップルのシニアマネージャー松井博氏と、かつて栄華を誇った東芝のフラッシュメモリ全盛時代を知る竹内健氏が対談を行い、今求められる組織の力、個人の力について語り合った。 元・米アップル社シニアマネージャー 松井
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
