タグ

チームに関するryu39のブックマーク (6)

  • 重大事故の時にどうするか?|miyasaka

    ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか?」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって(若干訂正してますが)ここに残して

    重大事故の時にどうするか?|miyasaka
  • 心理的安全性ガイドライン(あるいは権威勾配に関する一考察) - Qiita

    はじめに 「心理的安全性」とは、「対人リスクを取っても問題ないという信念がチームで共有されている状態」であるとか、「自分のキャリアやステータス、セルフイメージにネガティブな影響を与える恐れのなく、自分を表現し働くことができること」というような定義がなされています。 心理的安全性という言葉はともすれば、ただ快適で居心地のよい職場という意味にも聞こえます。そのため、ぬるま湯で緊張感のない関係性のことを「心理的安全性が高い」と言うのではないかと考えても不思議はありません。 そのため、友人関係のようにプライベートの時間を長く共有する関係になることが、心理的安全性が高いのだろうと考え、飲み会やバーベキュー、慰安旅行などを企画してみたりとプライベートでも遊ぶ機会を増やそうと考える人もいるでしょう。 いわゆる「アットホームな会社です」とアルバイトの求人記事に書かれているような状態です。こういった求人内容

    心理的安全性ガイドライン(あるいは権威勾配に関する一考察) - Qiita
  • 人間らしくコードレビューするには(パート1) | Yakst

    自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithub

  • 「雰囲気がいい=いいチーム」ではない! “仲良しグループ化”が優秀人材を逃す罠

    開発知識に加え、マネジメントスキルも求められるプロダクトマネージャーが最速・最高のアウトプットを生み出すにはどうすればいいのでしょうか。そこで、これまで2社のCTOと5社の技術顧問を経験してきた一休の伊藤直也氏による「1人CTO Night」を開催。主催は転職サイト「DODA」を運営する、株式会社インテリジェンス。パートでは、参加者から寄せられたお悩み「エンジニアの採用問題」「メンバーの責任感問題」などについて、伊藤氏とソラコム・玉川憲氏が回答しています。 工数管理とメンバーの責任感問題 質問者6:(1)ビジネスサイドとの調整に関する問題についてです。 ビジネスサイドのスタッフが、なにを開発するにしても工数を最小化しようとしてきます。現状、エンジニアが工数の根拠や、その施策の効果見込みを可能な限り数値化して説明していますが、説明にエネルギーがかかっており、エンジニアが疲弊してしまっていま

    「雰囲気がいい=いいチーム」ではない! “仲良しグループ化”が優秀人材を逃す罠
  • スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で

    サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして

    スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で
    ryu39
    ryu39 2017/06/02
    品質を落としてスピードを上げる場合のトレードオフは、個人やチームの成長の他にメンテナンス性があると思う。スキルが低い人の場合に顕著。謎な名前の変数、if文だらけの巨大なクラス、テストコードのない実装、等
  • あなたが所属する開発チームのランクを決める、12の質問「ジョエル・テスト」 - paiza times

    Photo by shaz wildcat こんにちは、吉岡(@yoshiokatsuneo)です。 動きの速いIT業界において、良い製品やサービスをどれだけ素早く生み出せるかは大変重要なことです。 そのためには、エンジニアにとって質が高く、成長できる開発環境が欠かせません。 では、開発チームの質はどうすればわかるのでしょうか? 開発チームの質を調べる方法の一つとして、Stack Overflowの創業者であるジョエル・スポルスキーさんが提案する、 「ジョエル・テスト」と呼ばれる方法があります。 (ジョエルさんは、その他Microsoft Excelの元プログラムマネージャ、Trelloの作者、著名ブロガーとして知られています。) http://japanese.joelonsoftware.com/Articles/TheJoelTest.html 「ジョエル・テスト」では、プログラムの

    あなたが所属する開発チームのランクを決める、12の質問「ジョエル・テスト」 - paiza times
  • 1