強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016 業務で行われるソフトウェア開発プロジェクトのほとんどすべては、何らかのチームによって行われています。そしてそのプロジェクトが成功するか失敗するかを左右する大きな要因が、技術力よりも人間系にあることはよく指摘されることです。 では、その人間系に注目して強いチームを作るにはどうすればよいのか、そのヒントを多数紹介したセッション「強いチームのつくり方」が、2月19日に行われたイベントDeveloper Summit 2016（通称デブサミ）で行われました。この記事では、そのセッションの内容を前編、中編、後編の3本の記事で紹介します。 いまお読みの記事は前編です。 プロジェクトの多くは技術ではなく人間系で失敗している 吉羽 龍太郎氏（Ryuzee.com）。 吉羽と申します。いままで野村総
先月8月末に所属しているビッグバンドのライブが無事？終了し、演奏を振り返ると反省点が多すぎて凹むので、あまり振り返らないことにしている代表の国本です。 みなさんは社内のノウハウや各種情報の共有をどのように行っていますか？ MMMでは、社内のドキュメント共有基盤として2014年10月末からQiita:Teamを導入しており、 各自が溜め込んだ各種情報の共有を活性化し暗黙知を無くすという目的のもとに、全社員がせっせと様々な情報をドキュメント化してきました。 その後今年に入ってから、とあるプロジェクト単体でesa.ioを利用し始めたことをキッカケに、しばらくQiita:Teamとesa.ioで並行運用をして検討を進めた結果、来月から10月からesa.ioでドキュメント基盤を一本化することを決めました。 そこで今回のエントリーではQiita:Teamとesa.ioを並行運用し、esa.ioの採用を
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
EMC連合の企業としてPivotalといえばCloud FoundryというPaaSの開発元として有名なのかもしれないが、実際にはエクストリームプログラミングやペアプログラミング、そしてDevOpsを実践している企業なのはソフトウェア開発を行っているエンジニアには有名なことだろう。Pivotal LabはPivotalの中でアジャイル開発、ペアプログラミングを啓蒙するトレーニングの場として広く企業に門戸を開けている。そんなPivotal Labのサンフランシスコオフィスを訪問して、DevOpsを実践するコツをきいてみた。 今回、対応してくれたのはアソシエイトディレクターオブエンジニアリングのジェーアール・ボイエンス（JR Boyens、Associate Director of Engineering）氏だ。 まず最初にPivotal Labのオフィススペースをツアーして一番驚いたのが、ソ
こんにちは、ライターの岡田大です。 お待たせしました。特別編「トップエンジニアたちの夜」のPart4をお届けします。 ※Part1～3未読の方＆内容を忘れてしまった方は、Part1・Part2・Part3を一読してからお楽しみください！ リモートワークを成功させるために必要なモノとコトについては前回お伝えした通り。ルールとマナーなくして成り立たないことは言うまでもなく、そのことをメンバー（とくに新人）に徹底させるために、リモートワークを積極的に導入している伊藤氏は、ガイドラインをドキュメント化することにより意識の共有を図っているという。その際に活用しているのが、技術情報共有サービスQiita:Teamである。堀木氏の口から「Qiita:Team」という言葉が発せられるやいなや、参加メンバー一同がこれに食いつき、座談会はチーム内における情報共有に関する話題で持ち切りになっていった……。なお、
別にWEB屋に限らず、誰かとチームを組んで作業する時、いかにしてコミュニケーションの質を上げるかと考える人は多いと思うんですね。 かくいう僕なんかは、たかが数人のチームコミュニケーションでも相当大変な思いをしているので、これが数十人と規模が拡大した時のことを考えると憂鬱なので、ぼちぼち対策を考えないといけないなと思うんですね。 そこで今日は、とりあえず手っ取り早くコミュニケーションの質を上げる為になんか良いツールが無いか探してみる事にしたので、ちょっと共有してみようと思います。EvernoteとかDropboxとかBasecampとかはとりあえず省いて、ここ数ヶ月の間に使い出した／知った物を中心にご紹介させて貰えればと思います！ もちろん、コミュニケーションの質をあげようという考え方自体人によってまちまちでしょうし、必要なのはツールでは無く意識の問題であることが多いのは承知の上なのですが、
エンジニアの森田です。 チームでKPTをやってみました。その時に考えたことなどを書きたいと思います。 社内発表資料です。 KPTとは アジャイル開発や反復型開発ではイテレーション（繰り返しの単位）ごとに作業の振り返りが推奨されるが、そのためのチーム反省会などでよく用いられるフォーマットである。 http://www.itmedia.co.jp/im/articles/0905/19/news143.html KはKeep、PはProblem、TはTryをそれぞれ表します。イテレーションの単位でチームで振り返りを行い、良い点（Keep）、問題点（Problem）、具体的な改善項目（Try）を軸にミーティングをします。基本的な流れは、Problemが具体的なTryになり、Tryが解消したら、消える。またはKeepに昇華します。KeepはProblemやTryに関係なく、上げていくこのが良いと思
あなたのチームの「いい人」は機能していますか？Minoru Yokomichi169.5K views•56 slides 凡庸なSEが、大規模SIerの集団でできること - DevLOVE甲子園 2013Minoru Yokomichi13.8K views•35 slides
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
「エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが･･･」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下の本を読むと良いかと思います。 How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメントposted with amazlet at 14.10.18エリック・シュミット ジョナサン・ローゼンバーグ アラン・イーグル 日本経済新聞出版社 売り上げランキング: 19 Amazon.co.jpで詳細を見る 小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則posted with amazlet at 14.10.18ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン 早川書房 売り上げランキング: 7,579 Amazon.co.jpで詳細を見る Tea
http://rubyrogues.com/176-rr-rails-as-an-soa-client-with-pete-hodgson/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 「システムの設計は、その組織のコミュニケーション構造を反映したものになる。」というコンウェイの法則について、ThoughtWorksのPete Hodgsonは、それを逆のかたちで、つまり、採用すべきアーキテクチャの特性を活かすために人と人とのコミュニケーションをどう改善するかということに、かなり時間をとっていると語っています。 コンウェイの法則は、重力のように不可避なもの。うまく活かせるように変わるか、対応できずにダメになるかの二者択一だ。 各サービスの担当チームが細分化されている大企業の顧客において、SOA（
2014/9/26に行われたBASE技術勉強会の発表資料
DevLOVEさんの「進め、現場のチーム開発 〜チーム開発実践入門〜」で講演した時の資料 http://devlove.doorkeeper.jp/events/12229Read less
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央出版社/メーカー: 日経BP社発売日: 2013/12/18メディア: 単行本（ソフトカバー）この商品を含むブログ (6件) を見る この本は、作者のトム・デマルコさんとティモシー・リスターさんが10年に及んだ調査と、自身のソフトウェア開発の経験をもとに、ソフトウェア開発における人に関する問題をたくさんのコラムを通じて教えてくれる。冒頭には以下のようにある。 実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。 いろんなレイヤにおける人の問題についてそれぞれ章がわかれていて、個人からオフィスやチーム、さらには会社組織のはなしへと続く。結構マネージャー視点ぽいコ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く