チームに適したプレイを見つける プレイを利用して、プロジェクトで良いスタートを切り、チームのダイナミクスを改善しましょう。これらの無料のワークショップ リソースは、ワークフローに統合するように設計されており、あらゆるレベルのチーム メンバーに容易にご利用いただけます。
![自分のチームのプレイを検索する | Atlassian](https://cdn-ak-scissors.b.st-hatena.com/image/square/e4b26c5890b5ba3291c2980ea2f9d105abfcdb5a/height=288;version=1;width=512/https%3A%2F%2Fwac-cdn.atlassian.com%2Fdam%2Fjcr%3Aaa96a07b-a298-4135-a59b-ae588e202b8e%2FIndex_hero_metadata%402x.png)
チームに適したプレイを見つける プレイを利用して、プロジェクトで良いスタートを切り、チームのダイナミクスを改善しましょう。これらの無料のワークショップ リソースは、ワークフローに統合するように設計されており、あらゆるレベルのチーム メンバーに容易にご利用いただけます。
高校1年の時にパソコン通信を始めて、知らない人とコミュニケーションをし始めてから、もうかれこれ25年以上経ってます。はじめてパソコン通信でチャットをした時の感動、情景、相手のハンドルネーム、話した内容の一部は今でも鮮明に覚えています。 その後、いろんな人とネットを通じて出会っては去って行くのを見てきました。中には僕がコミュニケーションを通じて傷つけた人もいるでしょうし、問題を起こして自滅して去っていった人もいました。僕自身は、インターネットの時代になってからも、淡々とTwitterもFacebookもブログも書き続けているわけですが、情報発信をどう続けていくか?については、なんとなく感覚としては板についてる気がしています。 ただ最近、会社のSlackでも、過去に見てきた「非対面が故の期待と現実の差異」に戸惑ったり、ミスコミュニケーションが増えた気がしています。もし、それが仕事の生産性を阻害
強いチームを作るには時間がかかる~強いチームのつくり方(前編)。Developers Summit 2016 業務で行われるソフトウェア開発プロジェクトのほとんどすべては、何らかのチームによって行われています。そしてそのプロジェクトが成功するか失敗するかを左右する大きな要因が、技術力よりも人間系にあることはよく指摘されることです。 では、その人間系に注目して強いチームを作るにはどうすればよいのか、そのヒントを多数紹介したセッション「強いチームのつくり方」が、2月19日に行われたイベントDeveloper Summit 2016(通称デブサミ)で行われました。この記事では、そのセッションの内容を前編、中編、後編の3本の記事で紹介します。 いまお読みの記事は前編です。 プロジェクトの多くは技術ではなく人間系で失敗している 吉羽 龍太郎氏(Ryuzee.com)。 吉羽と申します。いままで野村総
こんにちは。@ryuzeeです。 支援をしている際に、こういう兆候があったら注意して見る、というポイントがいくつかあるので共有します。 あくまで課題発見用のツールなので、マルバツ表を作ってどうこうする、という類のものでもないですし、そうすべきでもありません。 スクラムマスターの人、外部から支援する人は、自分用の確認ポイントを整理しておくと良いと思います。 なお、スクラムを実践すること自体は目的足り得ないので改めて言っておきます。 全体なんでもアジャイルでやろうとするそもそもアジャイルを採用することが目的化しているプロジェクト初期にマイルストーンやスケジュールを決めていない十分にトレーニングを受けていない認定資格をとればそれで十分だと思っている全体の要件やアーキテクチャを考えずいきなりコードを書く予定できることなのに、「アジャイルだから」と予定しないドキュメントを書かない文化や考え方を変える
Rohini Vibhaさんは、IDEOのビジネスデザイナーです。Twitter アカウントは、@rohinivibha。本記事は、Mediumへの投稿記事をRohiniさんから許可を得て翻訳したものです。元の英語記事もどうぞ。 世の中にプロダクトマネージャーを目指す人が増えていると思うのは、私だけだろうか。私自身がプロダクトマネージャーを務めているから、そう感じるのかもしれない。それにしても、最近はコンサルタント、MBA候補生、エンジニア、誰もかれもがプロダクトマネージャーを目指している気がする。 もしこれが事実で、もし本当に、”誰も”がプロダクトマネージャーになりたいと望んでいたとしても驚くには至らない。確たる技術を極めることなく務まる役割なのだから。プロダクトマネージャーになるためにデータモデルの作り方を知っている必要はないし、コーディングができる必要もなければ、Webサイトをデザイ
これは、「ドリコム Advent Calendar 2015 その2」の、8日目の記事になる。 7日目は、middlemanとGitHub Pagesでブログを5分で開設!ほか盛りだくさん! | いくら寝ても眠たい だった。 私は、ドリコムでエンジニアをしている matsusaki (@misoobu) という者だ。 ここでは、最近考えることの多い、組織におけるエンジニアの情報共有と、そのあるべき姿について書く。 また、それに関連して、コードレビューや設計についても触れる。 内容は、エンジニア視点のものになる。 情報共有は、組織にとって極めて重要だが、簡単なことではない。 本記事が、再考するきっかけとなれば、幸いである。 情報共有とは 情報共有を失敗するとどうなるのか 様々な情報共有 プロジェクトの状況や方針 作業内容とその状況 プログラムの設計やコード レビューの目的 レビューをするとき
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
スタートアップの企業文化 (Startup Culture) についてのスライドです。 企業文化やビジョンをスタートアップの初期から気にするべきかどうかは悩ましいところですが、Y Combinator の Jessica Livingston のいうとおり、企業文化はその設立当初から自然と育っていってしまうものだなと 2, 3 人のスタートアップを見てても思います。であれば、初期から考えるためのある程度の情報はあっても良いのかなと思い、今回スライドをまとめました。 企業文化はかなりソフトな概念なので、そもそも把握しづらい上に何が良くて何が悪いのかも分かりにくく、さらに簡単に変えたり作り上げたりできるものではありません。それに加えて、良い(望ましい、心地の良い)企業文化があるからといって、その企業の成功が約束されるわけではありません。 ただ様々な研究を見てみても、良い企業文化は生産性向上や採
「エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが・・・」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下の本を読むと良いかと思います。 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
朝会(デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く