タグ

チームに関するshogo0809のブックマーク (12)

  • 「儲からない」のは誰の責任?アジャイルにおける「責任問題」とその解決策【ryuzee|吉羽龍太郎】 レバテックラボ(レバテックLAB)

    「儲からない」のは誰の責任?アジャイルにおける「責任問題」とその解決策【ryuzee|吉羽龍太郎】 2024年6月17日 株式会社アトラクタFounder兼CTO アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』(翔泳社)、訳書に『チームトポロジー』(日能率協会マネジメントセンター)、『プロダクトマネージャーのしごと』『エンジニアリングマネージャーのしごと』『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』(オライリー・ジャパン)、『ジョイ

    「儲からない」のは誰の責任?アジャイルにおける「責任問題」とその解決策【ryuzee|吉羽龍太郎】 レバテックラボ(レバテックLAB)
  • 小城久美子推薦!プロダクトマネジメント成功のために読みたい参考書籍6選 - エンジニアtype | 転職type

    連載では、プロダクト開発に携わるエンジニア読者向けに「成功につながるプロダクト開発」を実現するためのプロダクトマネジメントの基の考え方や応用テクニックを、国内外の企業の優れたプロダクト開発の取組みを事例にとり、小城久美子さんがエンジニア向けに紹介・解説。明日からすぐに使える「いいプロダクト開発」をかなえるヒントを提供します。 小城久美子(@ozyozyo) ソフトウエアエンジニア出身のプロダクトマネジャー。ミクシィ、LINEでソフトウエアエンジニアスクラムマスターとして従事したのち、『LINE CLOVA』や『LUUP』などにプロダクトマネージャーとして携わる。そこでの学びを生かし、Tably社にてプロダクトマネジメント研修の講師、登壇などを実施。書籍『プロダクトマネジメントのすべて』(翔泳社)共著者 日頃、エンジニアやプロダクトマネージャーに就いている方々から、 「何ができていれば

    小城久美子推薦!プロダクトマネジメント成功のために読みたい参考書籍6選 - エンジニアtype | 転職type
  • ベロシティに対する誤解 | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは?まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』(Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29)の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような

    ベロシティに対する誤解 | Ryuzee.com
    shogo0809
    shogo0809 2022/07/16
    週明けにチームで復習しよう
  • スプリントの属人性を減らしたらベロシティが安定した話 - Commune Engineer Blog

    2022/07/04追記】 この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。 tech.commmune.jp はじめに これは何? 誰向けの記事? 自己紹介 前提:「ベロシティの安定」とは 取り組み導入の背景 属人性を減らす取り組みの一覧 ① WIP制限 どうやったか 得られた成果 補足 ② タスクサイズの制限 どうやったか 得られた成果 ③ 死亡前死因分析(プレモーテム) 死亡前死因分析とは? どうやったか 得られた成果 全ての取り組みの結果 得られた成果 何故この成果を得られたか? 注意点 まとめ 最後に はじめに これは何? スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事 WIP制限 タスクサイズの制限 死亡前死因分析 誰向けの記事? スクラム最初の壁であるベロシティの安定化

    スプリントの属人性を減らしたらベロシティが安定した話 - Commune Engineer Blog
    shogo0809
    shogo0809 2022/06/13
    プレモーテムやってみたいと思った
  • 入社して1ヶ月で意思決定の速さに驚いた話 - ANDPAD Tech Blog

    2021/10から株式会社アンドパッドで働いているid:shiba_yu36です。現在はセキュリティチームで認証基盤に関するエンジニアリングをしています。 アンドパッドは2021/10/01時点で従業員数が539名となっています。入社する以前は「この人数になってくると自分が何か提案したとしても中々意思決定が進まずヤキモキするのではないだろうか」と不安に思っていました。 しかし入社してから自分が開発プロセスや人員配置に関して提案してみたところ、この心配は杞憂だったどころか、逆に思った以上の意思決定のスピードに驚いてしまいました。そこで今回は自分が入社してから1ヶ月ほどの間に実際に提案・採用した内容を書きながら、どの程度意思決定がスピーディだったか伝えられればと思います。 ミーティングではesaで同時編集しながら議事録をみんなで作るスタイルへ -> その日から開始 フルリモートでの円滑なコミュ

    入社して1ヶ月で意思決定の速さに驚いた話 - ANDPAD Tech Blog
  • 一年半同じチームで色んなふりかえりをやったので手法と学び紹介していく

    Scrum Fest Mikawa 2021の登壇資料です。 以下は資料内で引用している参考リンクです DPA https://qiita.com/viva_tweet_x/items/97e819c626979b78947a KPT http://objectclub.jp/downlo…

    一年半同じチームで色んなふりかえりをやったので手法と学び紹介していく
  • エンジニアリングマネージャーになる前に知りたかった考え方 - Qiita

    Qiitaで期間限定開催中の、「エンジニアによるマネジメント」に関する記事を投稿するイベントへの参加記事です。 マネジメントを始めて悩んだこと 約1年前、アシスタントマネージャーという役職をいただき、エンジニアリングマネージャー(以下、EM)としての業務を開始しました。EMになると1on1やメンバーの目標設定、チームづくり、チームの代表として事業部リーダーズミーティングへの参加などの新しい業務をしながら、それまでのプレイヤーとしての業務も行い、目の前の業務をこなすのにいっぱいいっぱいでした。 そんな中で常に「自分がマネージャーとしてきちんとできているのかが分からない」という不安を持っていました。また、どんなスキルをつけて、どうなれたら正解なのかというイメージが見つからず悩んでいました。 ある時、先輩との1on1で、「(メンバーとの1on1やメンバーの育成を)どうしてそれをやるのか」と問われ

    エンジニアリングマネージャーになる前に知りたかった考え方 - Qiita
  • 1on1ミーティングとは?その意味と、効果的に行う方法 | Coral Capital

    連載はオープンソースライセンスの1つであるGPLの元に公開されている「The Eng Team Handbook」(エンジニアチーム・ハンドブック)を翻訳したものです。開発チームが効率的に仕事するために必要な「効果的な1on1の実施方法」「開発メンバーから開発マネージャーにポジションが変わるときの注意点」「パフォーマンス評価のテンプレート集」「360度評価のテンプレート」などが含まれます。 著者はStripeエンジニアであるrayleneさんです。これがStripeのやり方と明示されているわけではありませんが、急成長するシリコンバレーのスタートアップにおけるエンジニアチームの取りまとめ方という意味で、日のスタートアップでも参考にしていただけるのではないかと思います。オリジナルの英文の文書では、まだ未着手の項目もありますが、すでに書き終わってるものについて翻訳し、連載の形で5回に分けて

    1on1ミーティングとは?その意味と、効果的に行う方法 | Coral Capital
  • 良いテックリード、悪いテックリード - 小さなごちそう

    記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v

    良いテックリード、悪いテックリード - 小さなごちそう
  • テックリードという役割

    なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術エンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ

    テックリードという役割
  • エンジニアリングマネージャーはエンジニアリングがわからなくてもよいのか

    エンジニアリングマネージャー界隈でよく聞く話マネージャーは役割であって上下関係ではないマネージャー=エラいという不文律が存在している組織がまだまだ多い。そうではないと言ったところで給与体系が違ったり、組織上ツリー構造の上位に位置していたりする。マネージャーになることを「昇格」と呼んでたりするのは、こういう風習の表れだったりする。 それにしても「部活のマネージャー」と聞いて上下関係を思い浮かぶ人はいないのになんで「組織のマネージャー」になると話が変わるのだろうか。部活のマネージャーは仲間だけど、組織のマネージャーは仲間だと思えないのかもしれない。 ところが少し前からWorks Rulesの影響などもあって、徐々にマネージャーというものが見直され始めてきているように感じる。役職としてのマネージャーから役割としてのマネージャーへと目線が移ってきた。 自分もそういう考え方のほうが好きで、メンバーと

    エンジニアリングマネージャーはエンジニアリングがわからなくてもよいのか
  • 最強にクリエイティブなチームを作るのに必要な「5人の存在」 | ライフハッカー・ジャパン

    重要なポイントとは、チームに取り入れるべき「5つの存在」です。ただ与えられるだけの仕事をこなすのではなく、情熱をもって仕事に取り組むチームを築くのに欠かせない、その5つの存在を以下に紹介しましょう。 1.チアリーダー:チームの雰囲気を盛り上げる者 あなたのチームは団結していますか? やる気が満ちており、楽しんで仕事に取り組める環境ですか? 答えがノーであれば、必要なのは「チアリーダー」です。 「チアリーダー」はチームのやる気を高め、チームに積極的に関わり、士気を高めつつ、メンバー全員をよりクリエイティブにし、仕事に対する情熱を向上させる存在です。社交的であり、チームメンバーを会話と共同作業に引き込むことのできる、生まれながらの能力をもっています。「チアリーダー」はメンバー同士のコミュニケーションを活発にするため、社交的ではないメンバーは、最初は1歩引いたり、不快に感じることもあるかもしれま

    最強にクリエイティブなチームを作るのに必要な「5人の存在」 | ライフハッカー・ジャパン
    shogo0809
    shogo0809 2013/11/29
    これ真面目に考えたいな
  • 1