タグ

チームに関するs_naganoのブックマーク (9)

  • NTT Com チームビルディングハンドブック

    チームビルディング ハンドブック #このサイトについて #NTTコミュニケーションズ(以降、NTT Com)社内で製作したチームビルディングハンドブックの内容を、より一般化して広く公開するものです。 ソースコード #書のソースコードは https://github.com/nttcom/teambuilding-handbook で公開しています。 ライセンス #NTT Communications Corporation 作『チームビルディング ハンドブック』は クリエイティブ・コモンズ 表示 - 非営利 - 継承 4.0 国際 ライセンス で提供されています。 関連ハンドブック #リモートワークの働き方に特化したハンドブックであるリモートワークハンドブック、オンボーディングに関する情報をまとめたオンボーディングハンドブックも参照ください。 読み始める #以下のボタンから編に進めます

    NTT Com チームビルディングハンドブック
  • ファインプレーやガッツ溢れるプレーは相手チームであっても称えよう! - 中学校野球部!絶対に強くなるヒント集

    相手チームがすばらしいプレーをしたときどのようにしていますか? 相手チームであってもすばらしいプレーは称えるチームを作りましょう! 両チームにいい影響がありますよ!! 〇礼儀を大切にするチーム作り。 私は以前からしつこいくらいに「部活動は人間形成」ということを訴えてきました。 選手にも当然それを伝えていて、選手たちも礼儀を意識した行動を自分たちから取るようになっていました。 この辺りの話は以下の記事を読んでいただければと思います。 www.taguchizu.net www.taguchizu.net 上記の記事にある「日一の礼儀への挑戦」に取り組む中で、私がこの子たちならできるんじゃないかなと思い、取り組み始めたのが「ファインプレーやガッツ溢れるプレーは相手チームであっても称える」ということです。 〇相手チームのすばらしいプレーを称えるチームを作る! 野球だけではなく、他のスポーツ、い

    ファインプレーやガッツ溢れるプレーは相手チームであっても称えよう! - 中学校野球部!絶対に強くなるヒント集
    s_nagano
    s_nagano 2017/01/31
    “相手チームであってもすばらしいプレーは称えるチームを作りましょう”
  • 「チームが機能するとはどういうことか」を読んでておもしろかったところ - hitode909の日記

    プロジェクトの終了後に省察する,という章に書かれてたことがおもしろかった.ピクサーのスタジオの創始者のエド・キャットムルが始めたことの話. ピクサーのスタジオでは,省察することが渋られて,みんなで振り返るより先に映画の成功を楽しみたがってしまっていた そこで, またやりたいと思うことを5つリストアップして話しあう 次に,もうやりたくないと思うこと5つについて話しあう それによって,ポジティブさとネガティブさのバランスが保たれて,安全な環境が生まれる この方式よさそうで,バランスよく振り返れそう. によると,信頼しあった上で率直な意見が言えるような関係を作って,チームとして学習を続けられるようにしましょう,ということだった. 飛行機の副操縦士が操縦士に向かって,操縦ミスってるのでは?エンジン燃えてるのでは?とか言うと怒られそうだけど,そこで対立を恐れて黙ってしまうと,自分の命よりも,上司

    「チームが機能するとはどういうことか」を読んでておもしろかったところ - hitode909の日記
  • 君のチームに「構造」はあるか? 伊藤直也が語る、学びが蓄積されるマネジメント

    2016年8月30日、これまで2社のCTOと5社の技術顧問を経験してきた一休の伊藤直也氏による「1人CTO Night」が開催されました。主催は転職サイト「DODA」を運営する、株式会社インテリジェンス。開発知識に加え、マネジメントスキルも求められるプロダクトマネージャーが最速・最高のアウトプットを生み出すにはどうすればいいのでしょうか。パートでは、伊藤氏が過去の実例から「学習結果が蓄積されるマネジメント」について語りました。 「CTO」と「VP of Engineering」 伊藤直也氏(以下、伊藤):「1人CTO Night」というちょっとキャッチーな名前のイベントですが(笑)、さっそく始めさせていただきます。一休の伊藤です。 今日は「一休の伊藤」というかたちで出ていますが、あまり自社の宣伝をしてもしょうがないので、過去に技術顧問をやってきた時の経験などを含めて「いろいろな会社でこう

    君のチームに「構造」はあるか? 伊藤直也が語る、学びが蓄積されるマネジメント
  • Educate.co.jp | タックマンモデル

    今日、企業では、大小さまざまなチームを編成して、仕事を進めることが多くありますが、ただ単にメンバーを集めただけでは、チームは有効に機能しません。 ドイツの心理学者であるリンゲルマンは、集団で作業をすると個人の努力がおろそかになって「社会的手抜き」と呼ばれる現象を発見しました。リンゲルマン効果とも呼ばれています。 1の綱を1人が引く場合には、その人は100%の力を出しますが、その人数を2人、3人、8人と増やしていくと、1人が引く強さは93%、85%、49%まで下がることを実験で証明しています。これは、人数が増えるほど責任感が拡散するために生じるといわれています。 このようにチーム・ビルディングとは非常に難しいものですが、なかでも、チームリーダーに求められる期待や責任は小さくありません。ではチームリーダーは、どのようなことを意識して、マネジメントを行っていくべきでしょうか。 チーム・ビルディ

    s_nagano
    s_nagano 2016/04/12
    タックマンモデル
  • 【資料公開】強いチームの作り方 | Ryuzee.com

    2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。

    【資料公開】強いチームの作り方 | Ryuzee.com
  • 【社内資料公開】構築担当者向け 運用チームに引き継ぐ時に気にしてほしい3つのポイント | DevelopersIO

    はじめに こんにちは植木和樹@上越妙高オフィスです。AWS上でのインフラ構築が終わり、アプリケーションがデプロイされるといよいよサービスローンチ。数日〜数週間様子をみて問題がなければ運用チームに業務を引き継ぐことが多いかと思います。 運用チームへの引き継ぎ資料を作って「あとはよろしくね」となるわけですが、その段階で「待て」がかかってしまうことがあります。(だいたい待てを言うのは私なんですが) 今回はスムーズに運用チームに業務引き継ぎができるように、私が注意しているポイントをまとめておきたいと思います。 3つのポイント 注意するポイントは3つです。 1. Input なにをトリガーに作業が始まるのか。どんな通知がくるのか。 2. Action 何をするのか。 3. Output 作業が終わったら誰に報告するのか。 1つずつ説明していきます。 1. Input 運用チームは基的に「イベント・

    【社内資料公開】構築担当者向け 運用チームに引き継ぐ時に気にしてほしい3つのポイント | DevelopersIO
  • エンジニアにとって良い組織とは何かを知りたい? - naoyaのはてなダイアリー

    エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが・・・」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下のを読むと良いかと思います。 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

    エンジニアにとって良い組織とは何かを知りたい? - naoyaのはてなダイアリー
  • 「自分でやったほうが早い」でチームは滅ぶ | サイボウズ式

    【サイボウズ式編集部より】 この「ブロガーズ・コラム」は、著名ブロガーをサイボウズの外部から招いて、チームワークに関するコラムを執筆いただいています。今回は、脱社畜ブログの日野瑛太郎さんによる「仕事の任せ方、頼み方」について。 「人に何か仕事を頼む」という行為は、とても面倒くさいものです。 誰かに仕事を頼む以上、最低限どんな仕事をやってほしいのか説明をしなければなりません。「アレやっておいて」で済む相手であればいいですが、相手がまったくその仕事に通じていない場合は、説明だけでかなりの時間が取られてしまいます。仕事を依頼した後も、質問に答えたり、仕事の結果をチェックしたり、やることは意外と多くあります。 このような状況から、人に任せるのではなく「もう自分でやったほうが早い」と思ってしまうのはある意味では当然です。この考え方は、短期的には正しいと言えるでしょう。納期がピンチだという時に、悠長に

    「自分でやったほうが早い」でチームは滅ぶ | サイボウズ式
  • 1