この半年で変わったものと変わらないもの - SaaS開発の現場より / Developers Summit 2020 Summer
プロダクトを10年運用する チームをつくる / DevSumi2020
この半年で変わったものと変わらないもの - SaaS開発の現場より / Developers Summit 2020 Summer
Googleがたどりついた「効率の高いチームを作る5つの要素」とは - GIGAZINE
多くの人が力をあわせる「チーム」が仕事を進める上で重要なことは何か、Googleの社内チームを研究して見えてきた重要なポイント5つがまとめられています。 re:Work - Guide: Understand team effectiveness https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/introduction/ ◆何が「チーム」を定義づけているのか 「効率の高いチームを作るものは何か？」と問いかける際に重要なのが、そもそも「チームとは何か？」を認識することであるとのこと。メンバーであること、関係性、そして個々人の責任について明確にすることで、チームの効率性は大きく向上するといいます。 その中で意識すべきなのが、「ワークグループ」と「チーム」の違いを認識すると言うこと。この2つは
エンジニアの「チーム化」で何が変わる？成功体験を積み上げる、開発チームの作り方 | SELECK
〜エンジニアチームが、明らかに変わる。「 スクラム開発 」のエッセンスをうまく取り入れた、クラウドワークスのエンジニアマネジメントの取り組みとは〜 国内最大級のクラウドソーシングサービスを展開する、株式会社クラウドワークス。同社は事業の拡大に伴い、開発チームの組織化という課題に直面した。その課題に取り組んだのが、過去に100名規模の組織にスクラム開発を導入した経験を持つ、安西 剛さんだ。 安西さんは、ひとつの大きな開発チームを少人数のチームに分割し、スクラムのエッセンスを取り入れることでコミュニケーションを増やす工夫を行った。すると、チームが「同じ目標に向かう」ようになり、成功体験を積み上げていけるようになったそうだ。 アジャイルやスクラムに関わった経験の長い同氏だが、組織をチーム化していくために「スクラムをやろう」と呼びかけるのはアンチパターンだと語る。 あくまでもチームやコミュニケーシ
過去の賢人に学ぶ、インフラ運用チームのマネジメント失敗事例 - Qiita
gumiアドベントカレンダー9日目です。 今回はちょっと技術的なことを離れて、チームマネジメントまわりのことを書いてみようと思います。 1.チーム背景 私の所属しているチームは、主にAWS環境の運用を行っています。 チームメンバーは、ほぼ私が1人で対応していた時期から、数人規模のチームを推移してきました。 「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、残念ながら私は完全に前者になってしまいました。 改めて自分の失敗を振り返ると、良書と呼ばれる本には、失敗内容に関連した内容が記載されています。 特に、【Team Geek】の内容は、以前読んだ筈なのに全く実践できていなかったなあと。。。 【参考】『Team Geek』を読んだメモ 今回は、私のチームマネジメント失敗事例やそこから学んだことを徒然なるままに書いてみようと思います。 2.失敗したこと 2-1.メンバーの増加タイミング
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
マネージャのいない組織に進化する現実と幻想 - ワザノバ | wazanova
マネージャのいない組織へのチャレンジについては、一昨年から話題になっていますが、ここにきてかなり論点が絞られてきていると思います。 1) 非同期 & 可視化が進む GitHubなどのツールに親しむエンジニアが、進捗が可視化され、非同期で仕事を進めることに先に慣れてきたが、SlackのようなコミュニケーションツールやTrelloなどのタスク管理ツールの浸透で、非エンジニアにもじわじわその理解が進んでいく。 2) マネージャの役割が変わる 上記1) が進むことで、進捗を報告させて情報を集約、また逆に、全社 / 業界の情報をフィルタリングして伝えるという、情報操作ハブとしてのマネージャの役割はかなり減る。情報の透明性があがることで、情報を握っていることがマネージャのパワーの源泉である時代が終わる。 プロジェクトの進捗 / 開発のクオリティ / 売上 / 評価とフィードバック / メンバの士気の向
僕が鬱病になりかけた時の話、あるいは負のスパイラルについて：プロジェクトマジック：オルタナティブ・ブログ
今から考えると、軽い鬱病だったんだと思う。 僕は鬱病にならなさそうなタイプだ。いい加減だし、マイペースだし、自分で言うのもアレだがリーダーシップや困難な場面の打開力もある。 だからそういうのとは無縁だと思ってきた。僕と会ったことがある人や、本やブログの読者もだいたいは同じ意見だと思う。 そういう僕の10年以上前の経験を、いつか誰かの助けになるかも、と思って書いてみる。 コンサルタントに転職して1年くらい経った時だった。ある会社を抜本的に改革するプロジェクトの立ち上げメンバーとしてアサインされた。 業務も変える、システムも変える、組織も変える、それどころかビジネスモデル自体も見直そうという野心的なプロジェクト。コンサルタント冥利に尽きるようなプロジェクトだ。 難易度が高いプロジェクトだったから、会社は優秀な人材を何人も集め、豪華な布陣を引いた。僕もその一員としてやる気満々で臨んだわけだが、パ
じげんが1年越しでスクラム開発体制へ移行できた理由とは。「開発ワークフロー改革」担当者が明かす5つのポイント - エンジニアtype
トップページ > ノウハウ > じげんが1年越しでスクラム開発体制へ移行できた理由とは。「開発ワークフロー改革」担当者が明かす5つのポイント 開発スピードの向上や、さらなるサービスの成長を目指し、従来の開発体制や手法の見直しを検討する企業が増えている。 しかし、アジャイルやスクラムのような流行りの開発スタイルを取り入れようにも、現場にフィットさせるのには、さまざまな困難が伴うことが容易に想像がつく。サービスや組織が成熟していればいるほど、導入は一朝一夕にはいかないはずだ。 大手転職サイトをまとめて検索できる『転職EX』や賃貸物件情報ポータル『SMOCCA!-ex』などのライフメディアプラットフォームを運営する株式会社じげんは、「開発ワークフロー大改革プロジェクト」と銘打ち、2013年4月からの1年で、スクラム開発やテスト工程を順次導入。2006年の創業以来続く開発体制を、ハイスピードで刷新
自己組織型チームを組織化する
原文(投稿日：2010/04/17)へのリンク Rashina Hoda 氏は、アジャイルの研究者で、 New Zealand、 WellingtonのVictoria University で博士を目指しており、米国 Louisiana State Universityから学士を取得している。 氏は、 New Zealand と Indiaで３年余り、企業ベースの博士号の研究の一部として、アジャイルのチームを調査してきた。彼女の研究成果は、世界中で出版されたり、発表されており、彼女は、Agile2008, Agile2009, そして XP2009 で発表した。 最近、５月に南アフリカの Cape Townで開催されるInternational Conference on Software Engineering (ICSE2010) に彼女の論文が受理された。世界中から３８０の応募があ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Agile2016のオープニングキーノート：Managing for Happiness