タグ

チームに関するSWIMATH2のブックマーク (5)

  • 人が集まっただけ、ではチームになれない。強いチームを作るための「自己組織化」とは | SELECK [セレック]

    〜「指示待ち」「課題の抱え込み」「不要な衝突」etc.…。スピーディーな課題解決を妨げる原因を解消する、チームビルディングのノウハウとは〜 仕事を進める中で、次々と発生する課題。その課題を放置せずに、現場で素早く解決を進める「自己組織化されたチーム」を作るにはどうすればよいだろうか。 恋愛婚活マッチングサービス「Pairs(ペアーズ)」を運営する株式会社エウレカ。 同社CTO室の室長を務める梶原 成親さんは、そのようなチームを作るには、メンバーのパーソナリティやプロジェクトの進め方に対する共通認識を持つことが重要だと話す。 また、日々発生する課題を、自分たちで解決できるものとできないものに分け、それぞれに適切に対処するための「振り返り会」「妨害リスト」の運用を行っている。 今回は梶原さんに、チームビルディングを進める上で行ったワークショップや、日々の課題解決プロセスについて、お話を伺った

    人が集まっただけ、ではチームになれない。強いチームを作るための「自己組織化」とは | SELECK [セレック]
  • 開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog

    Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従

    開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
  • 自律的なチームを作るために —組織心理学・臨床心理学の応用—

    Japan Product Manager Conference 2016 の アンカンファレンスで発表させて頂いた内容です。 http://pmconf.jp/

    自律的なチームを作るために —組織心理学・臨床心理学の応用—
    SWIMATH2
    SWIMATH2 2018/06/21
    短いけどとてもいいスライド。
  • 「SmartHR使い物にならない問題」をどう解決したのか? VPoEが語る、ピンチを乗り越える開発チームの作り方

    2018年4月17日、明日の開発カンファレンス実行委員会が主催する、開発リーダーのためのイベント「明日の開発カンファレンス 2018」が開催されました。開発の効率化に取り組むリーダーたちが一堂に会して、現場で学んだ知見を共有するイベント。第2回となる今回も、さまざまな経験を積んだエキスパート達がプレゼンテーションを行いました。トークセッション「クラウド労務サービス『SmartHR』を支える開発チームの作り方」では、株式会社SmartHRのVP of Engineeringである芹澤雅人氏が登場。急成長を続けるSmartHRの開発の舞台裏を語ります。 面倒な労務管理の現状 芹澤雅人氏:あらためまして、私は芹澤雅人と申します。SmartHRという会社で「SmartHR」というサービスを作っております。前職で社会人になって以来、ずっとWebエンジニアとしてのキャリアを歩んでおります。 2015

    「SmartHR使い物にならない問題」をどう解決したのか? VPoEが語る、ピンチを乗り越える開発チームの作り方
    SWIMATH2
    SWIMATH2 2018/06/13
    スケールにつれて崩壊するの難しいし対応できたのすごいけど、スケールする前は崩壊してなかったのがまずすごいんだよなあ
  • 良かったことは良かったとはっきりフィードバックする - $shibayu36->blog;

    最近心がけていることとして、「良かったことは良かったとはっきりフィードバックする」ということがある。 自分がリーダーやマネージャのポジションになった時に、方針やメッセージを打ち出す、チームの開発フローを改善するなどを行うことがあった。この時、何もフィードバックが返ってこなくて、結局良かったのか、それともあまり興味がないのか、実は不満に思っているのか、どれなのかわからず、非常に不安に思ったという経験がある。 逆に自分が伝えられる立場になった時を考えてみると、何かが行われた時、気になることはよくフィードバックするけど、良かったなと思うことは心の中で思うだけでフィードバックしないことが多いと感じた。 そこで最近は、「良かったことは良かったとはっきりフィードバックする」ように心がけている。はっきりフィードバックするというのは、どこが良かったかを出来る限り具体的に相手に伝えるということである。伝える

    良かったことは良かったとはっきりフィードバックする - $shibayu36->blog;
    SWIMATH2
    SWIMATH2 2018/03/23
    めちゃめちゃ良い話
  • 1