株式会社アンドパッドのアカウント基盤チームで認証基盤に関するエンジニアリングをしているid:shiba_yu36です。最近はチームのテックリードロールも担っています。 現在アンドパッドではFindy Teamsを導入し*1、生産性の可視化を行っています。自分は生産性向上のためのチーム改善に興味が強いため、2021/10に入社してからアカウント基盤チームのFindy Teams指標を観察し、チームのボトルネックを見極め、チームの生産性改善をしてきました。結果として、Findy Teamsの平均プルリク クローズ時間の指標が、チームに入った2021/10当時は120時間だったのが、現在は23時間ほどまで改善しました。今回はその様子について書きたいと思います。チーム改善の流れの一例として、参考にしてもらえればと思います。 チーム改善の全体的な流れ Findy Teamsで定量的にチームの生産性を
はじめに チームのメンバー皆に意見を出してもらいたいような会議をすることはよくあると思います。 本稿は、そういう時に積極的に発言してもらえるようにするための考え方とプラクティスの紹介です。 チームの皆に意見を出してもらいたい会議とは いろいろあると思いますが、以下に2つの例を挙げます。 UXレビュー 私のチームでは、開発中のプロダクトに対する改善点を皆で挙げるという活動を行っています。 チーム内では「UXレビュー」と呼んでいます。 具体的には、開発メンバーが開発中のプロダクトを実際にユーザーがよく使うユースケースでどんな体験をするのかをデモしながら説明し、それに対して他メンバーが気付いた改善点を挙げるという活動です。 人によって感じ方が異なるため、複数人で実施して、各自が感じたことを積極的に意見してもらった方が多様な観点での改善が期待できます。 設計レビュー 複数人で開発するプロダクトに対
ミラティブサーバチームで行っている障害振り返りを紹介します！！ - Mirrativ Tech Blog
こんにちは、サーバエンジニアの夏（なつ）です。今回はミラティブのサーバチームで行っている障害振り返りを紹介したいと思います。 ミラティブのサーバチームではサービスに障害が発生した場合、その後、担当者を決めて障害の振り返りのたたき台を作成し、チーム内で振り返りを行って、今後の改善に活かす努力を続けています。 今回はその振り返りの目的やフォーマット・注意点についてお話したいと思います。 目的 システムを運用していれば障害はつきものです。ましてや改善を続けるならば、その代償として不確実性が障害として表面化し、放置していけば徐々にユーザの信頼を失っていくことになります。かといって、障害の防止にコストをかければかけるほど、費用対効果は見合わなくなり、障害を絶対に起こしてはならないという心理的圧力はメンバーのメンタルを擦り減らしていきます。そのため障害の振り返りでは障害の詳細や原因をチームメンバーと共
「全ては会社の競争力を生み出すために」アーキテクチャを刷新し、ドメインモデリングも組織再編もエンジニア教育も一つ一つ丁寧に積み上げてモダナイズを進めた話｜CTOロングインタビュー - MonotaRO Tech Blog
独自のビジネスモデルを持ち、競争優位を獲得しているモノタロウ。事業拡大に合わせて、モノタロウの成長をテクノロジーで支えるTech組織も進化してきました。現在Tech組織は、より高度なビジネス価値を生み出せるようにするため、サプライチェーンの高度化、パーソナライゼーションでの商品検索に着目し、アーキテクチャの再構築とシステムのモダナイズに取り組んでいます。また、そこに向けて組織体制のアップデートやカルチャーの醸成にも力を入れています。 今回は、MonotaRO CTO 普川泰如氏のインタビューから、その実態に迫っていきます。まず第1章ではモノタロウが会社として掲げるビジョンとビジネスの特徴について説明します。それを踏まえて第2章では、そのビジョンやビジネスを実現するためのシステムとその課題、モダナイゼーションについて、第3章ではその技術的な取り組みを実行するためのTech組織の体制について紹
Engineering Managerをやっていた間の振り返りとまとめ - masartz->log(type=>'hatenablog')
TL;DR; Engineering Managerを降りることになりましたので、振り返りとまとめです。 ※会社は辞めませんので、退職エントリではございません（別チームへの異動です） 時系列 2017/10頃: SREのチーム内において会社のReport Line上にはプロットされないリーダー的なポジションをやりはじめる この時はまだManagerではない。採用や評価に対するResponsibilityがないのがマネージャとリーダーの簡単な違い 2018/04: SREのEngineering Managerに登用される 当時 Microservices PlatformはReport Line上はまだSRE内に包含されていた気がする どこかのタイミングで Report Lineとしても独立して、2チームを兼任する形で引き続き担当していた 2018/10: 2チーム兼任からMicroser
Penpot is the web-based open-source design tool that bridges the gap between designers and developers.
実践 Engineering Manager / practice engineering manager
Developers Summit 2019 Summer での発表資料です。
AWSにおけるアプリチームとインフラチームのコワーク設計 / Co-working Design about App and Infra on AWS
AWSにおけるアプリチームとインフラチームのコワーク設計 / Co-working Design about App and Infra on AWS
はじめに こんにちは。モノタロウで開発を担当している渡邉です。半年前に初めて開発チームのチームリーダーになり、スクラムを使った開発を行ってきました。今回はこれらの取り組みを振り返ってみようとおもいます。 はじめてのリーダー業って不安ですよね。どう行動すればよいのか、何を変えるべきなのか、うまくチームの目標を達成できるかなどなど・・・。私自身、そのような不安をかかえてチームリーダーになりました。 しかし、開発プロセスとしてスクラムを取り入れたことにより、想像していたよりスムーズにチーム運営を進めることができました。これから初めてリーダー職につく方や、スクラムをこれから取り入れてみようかなと思っている方の参考になれば嬉しいです。 アサインは突然に・・・ ある日のグループ連絡会で、当時のリーダーから突然の連絡がありました。 これまでのリーダーは経験豊富で、技術面でも行動面でもチームを率先してまと
※クラシル開発チーム向けの資料を外向けに公開した内容です これから開発メンバーが増えてくるので、カルチャーを言語化してみた。今できている文化もあると思うし、今後の考え方を言語化したモノもある。 これをクラシル開発チームのオンボーディング資料として、継続的にアップデートしていくことにする。 これは何に使うのか・新メンバー向けのカルチャー説明 ・メンバー同士で声を掛け合ってカルチャーを浸透させていく ・採用面接やリファラル採用時の文化説明 作った背景開発部もエンジニア、デザイナーが増えて組織が大きくなってきた。常にユーザーファーストであり続けられるよう今から言語化しておく事にする。 「成長痛」とも言われるが、ベンチャー企業の組織拡大に伴い30 / 50 / 100人の壁が存在していて、組織に歪が生じやすいし、個人で成果を出すのが難しくなってくるタイミングがある。 人が増えていく過程で様々なカル
エンジニア8人チームで"効果的に"タスクをアサインするために検討した8つの軸 - yigarashiのブログ
最近、締め切りのある大きめなプロジェクトでWebアプリケーションエンジニア兼プロジェクトマネージャーとして仕事をしました。一年目なので当然プロジェクト管理の経験はなく、本を読んで知識を得たり、チームメンバーに助けられたりと、だいぶ手探りでの挑戦となりました。その中でもっとも難しかった仕事の一つとして、タスクの効果的なアサインがあります。 エンジニアは最大8人おり、その技術力、ドメイン知識、勤務地などは多岐に渡ります。ウォーターフォール的な開発だったため、タスクは事前に洗い出されており、タスク管理ツール上に無数に登録されていました。適当に人とタスクを辞書順でソートしてアサインするだけなら簡単ですが、現実はそうもいきません。締め切りは厳しく、チームの生産性を少しでも高く維持しなければいけません。メンバーのモチベーションが下がったり、依存の多いタスクが遅れたりといったことはなんとしても避けたいも
スキ・キライ・得意・苦手を可視化したら、互いに成長を支え合うデザインチームができた話｜宇野雄 / note inc. CDO
クックパッド VP of Design／デザイン戦略本部長の宇野です。 みなさんは苦手なスキル、得意なスキルをどのように把握し成長につなげていますか？今日はそんなお題に向き合ったクックパッドでの取り組みをご紹介します。 僕が今年2月に入社したとき自身の自己紹介資料に入れた簡単なチャートがあります。それがコレ。 スキルマップって基本的には「得意」を可視化するためにあります。でも「得意」だから好きとは限らない。「苦手」だけど好きだってある。 それを可視化するために「得意／苦手」「スキ／キライ」の2軸で表したものです。 こうするとざっくりこの4分類にわかれます。 ・得意 × スキ ・得意 × キライ ・苦手 × スキ ・苦手 × キライ このチャートには絶対値が存在しないし、第三者評価もない。あくまで「自分では自分のことをこう考えていてこうしていきたい」という意思表示です。まさしく「私はこういう
Kyashの@konifarです。最近雑なアウトプットが減っているなと感じているので、自分が所属するチームでやった『チームラーニング』という催しについて書きます。 チームラーニングとは マッキンゼーでプロジェクト開始時に行っているチームビルディングイベントらしいです。 働く時間帯や環境、自分の不得手などを共有することで、チームで働きやすい状態を作ろうというものですね。 バズってた「チームラーニング」をやってみたら、チームの生産性上がりそう という記事がSlackチャネルに投げ込まれたのを見て、これはよさそうだと思い実施してみることにしたのでした。 あとで同僚の@ussyに教えてもらったのですが、マッキンゼーでのやり方や効果はMcKinsey Careers: Inside the team learning – one tool to create balance で紹介されています。もし
私がやっている、ティネクトという会社について少し話したい。 うちは、「オウンドメディアの運営」と「記事作成」を請け負う会社だ。 要は、自分たちがBooks&Appsでやってきたことや、得られた知見をクライアントに提供し、お客さんのサイトを盛り上げて、対価を頂いているわけである。 最近では特に「インターネット広告」以外の手段も広く用いて、webなどから顧客を発掘したい、という会社が間違いなく増えている。 オウンドメディア、すなわち自社で運営するメディアとSNS、そして従来の広告を併用して、相乗効果を出していこうということだ。 とはいえ、実際にやることは非常に泥臭い。 クライアントの事業を理解し、問い合わせの導線を考え、コンテンツの中身を考え、SNSでの拡散を目指す。 メディアのKPIを設定し、PDCAを回す。 それは本当に地味で、誰もやりたがらない仕事であることも多い。（だから事業として成立
これを読んだ。 medium.com とてもよかった。特にココ。 エンジニア出身ならわかると思いますが、企画はもちろんデザインナーエンジニアも、「なぜつくるのか」「今後どうするのか」ということはとても関心のあることで、そこの納得感はチームのパフォーマンスに直結するといっても過言でないです。 わかる。自分も納得した上で作りたい。納得感なくても素早く作ればええやんと思われるかもしれないが、ふとした時につらくなるし何か起きても提案する気も起きなくなる。特に小さい組織だと納得感重要。 自分でもちょっとしつこいなと思うくらい納得できるまで質問することがある。「この機能なんで最初のリリースに入れるんでしたっけ？」とか「これをつける目的は○○で合ってますか？」とか。相手を信用していないわけではなくて、納得して取り組みたいので気になったところを質問するのだ。聞き方をもっと工夫すればよかったと後で反省するこ
サクッとレビューができる 小さなPull Requestを作るには - LIVESENSE ENGINEER BLOG
大きなPull Requestのレビューがつらい 修正ファイル数が多いこと自体が問題なのではない 1つの内容に集中する 小さなPull Requestの作り方 リファクタリングの修正は気になっても別で出す Web API 1つに着目して実装を切り分ける 小さなPull Requestで作ったときのリリースの仕方 featureブランチを作って、そこから更にブランチを作っていく フィーチャートグルを使う 小さいPull Requestで小さくフィードバックをもらおう 大きなPull Requestのレビューがつらい 転職ドラフトでWebアプリケーションエンジニアをしている @iwtn です。 この記事ではチーム開発では当たり前になったレビューにおいて、修正されたファイルがたくさんあるとつらいよね、というお話と、その解決策を提示してみたいと思います。 昨今のWebアプリケーションなどのチーム開
優れたソフトウェア開発チームが持つ共通点とは？
メンバーが上司を恐れて意見を言えないチームや、業務の優先順位がはっきりせず何週間も時間を無駄にしてしまうチームなど、さまざまな理由からパフォーマンスが低下している開発チームが多く存在します。ソフトウェア開発者のデニス・ユー氏は、さまざまなソフトウェア開発チームと仕事をする中で「パフォーマンスの高いチームには共通点があった」と語っています。 Habits of High-Functioning Teams | deniseyu.io https://deniseyu.io/2020/05/23/habits-of-high-performing-teams.html ◆心理的安全性が高い 他者の反応に怯えたり羞恥心を感じたりすることなく、自然体の自分でいられる環境を指す心理的安全性が、パフォーマンスの高いチームで実現されていたとユー氏は述べています。心理的安全性をチーム内で実現するには、まず
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ システム統括本部の長谷部/渋谷/佐藤/榎本です。 前者の3人はヤフーの通知機能を担当するチームで開発をしています。 詳しくはこちら 新型コロナウイルスの影響で多くの方がリモートワークで仕事をされていると思います。 今まで同じ場所でチームとして仕事をしていたのにリモートワークになったら、個別作業になり、協力しての仕事がしづらくなったという話をよく聞きます。 僕らのチームも皆さんと同じように、突然全員のリモートワークが開始されました。 ただ、僕らはこのような状況下になる前からモブプログラミング（以下モブプロ）を導入していたため、生産性を落とさず、チームとしての協力体制を変えずに開発を続けることができています。 僕らがこの
Netflix Jobs
Netflix Culture MemoWork Life PhilosophyInclusion & DiversityVideoPodcastBlog 素晴らしいエンターテインメントは、心を躍らせ、人にインスピレーションをもたらします。エンターテインメントに触れることで、私たちは笑ったり泣いたり、息を呑んだりため息をもらしたり、さまざまな感情を呼び起こされ、心が豊かになります。人類が言葉を話すようになって以来、物語は、私たちの幸せにとって欠かすことのできないものです。 Netflixのミッションは、世界中にエンターテインメントを届けることです。世界のあらゆるところで素晴らしいストーリーを生み出し、世界の至るところで多様な作品を自由に楽しんでいただくことを目指しています。この目標を実現するために、私たちは一風変わった企業文化を育んできました。この文書はそのカルチャーについて、またNetf
成功する実践的モブプログラミング - Qiita
※ https://zenn.dev/erukiti/articles/mob-programming に移動しました。この記事はいずれ消す予定です。 モブプログラミング（以下モブプロ）とは、複数人で一つの成果物（プログラムコード）を生み出すという、チーム作業のテクニックです。似たテクニックにペアプログラミングがありますが、モブプロは3人以上（4〜5人を推奨）でやるものであり、また、目的や効果も全く違うものです。 モブプロのコンセプトは、チームでコミュニケーションをして問題を解決するというチーム戦 です。これ最重要なので、あとで何回も登場します！ この記事には「成功する実践的モブプログラミング」というタイトルを付けています。ここでいう成功の定義は、モブプロが実際に効率よく実践できることとします。モブプロに関する記事・情報は「イベントでお試ししてみた」とかが多い傾向があるため、ここでは実践に
SRE Doesn’t Scale
We encounter a lot of organizations talking about or attempting to implement SRE as part of our consulting at Real Kinetic. We’ve even discussed and debated ourselves, ad nauseam, how we can apply it at our own product company, Witful. There’s a brief, unassuming section in the SRE book tucked away towards the tail end of chapter 32, “The Evolving SRE Engagement Model.” Between the SLIs and SLOs,
デザイナーの高島です。 ベイジには2019年4月に入社しました。webサイトや業務システムのUIデザインを主に担当しています。『knowledge / baigie』でも、デザイン関連の情報を発信していきたいと思います。 デザインツールで制作したデザインデータをコーディングする時、「デザイン通りになっていない」「ルールに一貫性がなくてコーディングに余計な手間がかかった」といったトラブルが起こりがちです。 しかしこれらの大半は、デザイナー側の配慮である程度防げるとも思っています。そこで今回は、私がコーディングを依頼する際にデザイナーとして気を付けていることをまとめてみました。 なお、ベイジが使用しているメインのデザインツールはAdobe XDなため、この記事もXDの使用を前提としています。ただし、ツールに関わらない話も多いはずなので、皆様が使っているツールに置き換えながら、お読みいただけると
アジャイルとリーン・スタートアップを組み合わせた開発プロセス ~第１回 概要~ - selmertsxの素振り日記
2019年8月にAzitに入社して4ヶ月。 私はSREとしての役割を期待されてAzitに入社したけれども、気がつけばバックエンドエンジニア兼スクラムマスターをやっていました。 バックエンドエンジニアとしては、AWSインフラ環境の完全な作り直しとTerraformによるコード化、Railsの負債解消、監視設定のコード化などを行っていました。 スクラムマスターとしては、初期の3ヶ月はアジャイル開発(スクラム、XPを組み合わせたもの)、そして12月からの1ヶ月はリーン・スタートアップ開発の導入等を行いました。 ここでは、スクラムマスターとして考えた開発プロセスについて資料にまとめます。 なおこの文章は、0-1 の開発フェーズではなく、すでにリリースされたサービスに途中で加わったスクラムマスターの目線で書かれており、対象とする読者も私と同じような境遇にあるスクラムマスターとなっています。 この開発
はじめに エンジニアになって4年ほどになり、自分がチームを引っ張ることも多くなってきました。 最近ではいっちょマエにアドバイスなんかすることもありますが、自分だって右も左も分からないところからエンジニアとして仕事をしつつ成長してきて今ここにいます。 そんな中で、「こうするともっと仕事がうまくできるよ」というノウハウやマインドセット的なものを自分なりにアウトプットしておきたいなと思ったので、つらつらと書いていきます。 前提 私はエンジニアになってからずっとWeb業界の小規模スタートアップで開発をしてきた人間です。2社経験していますが、2社ともスクラムによる開発手法を取っていました。ここに記す内容もこの環境や手法に影響を受けたものが多いです。 おしながき 1.マインドセット 2.仕事の進め方 3.どうにもならないとき 1.マインドセット 大局を見渡す 自分が着手しているタスクについて、なぜこれ
はじめに COVID-19の影響によりリモート化が急速に進んだエンジニアの世界。 リモート化によって移動時間が減ったり、打ち合わせや仕事の切り替えがスムーズになったり、と多くの恩恵はあるものの、失ったものもあるはずです。 その一つが、雑談です。 リモート環境では、これまでのように、手を休めている人を見かけてから声をかけに行ったり、ランチの際に他愛もない話をしたり、ということがしにくくなっています。多くの現場で、完全になくなったわけではないものの、確実に減っているのが雑談です。 そんな雑談について、「エンジニアが雑談をすることによる効能」をNRI bitLabsのチームで雑談しながら考えてみました。 本記事は、以下の構成になっています。 雑談のフレームを使い分ける 雑談のチャネル 前半は雑談のパターンを紹介し、後半は実際に私が使っているチャネルを紹介しています。 何か、お役に立つ情報があれば
チームの心理的安全性を可視化するワークショップ「片思いマッピング」 / Kataomoi Mapping at furiconf2022
ふりかえりカンファレンス2022で登壇させていただいた際の資料です。 https://confengine.com/conferences/furiconf2022/proposals https://retrospective.connpass.com/event/239349/ 社内で自称ふりかえりエバンジェリストとして活動しています。 チームでのふりかえり経験も100回をこえ、別の開発チームから、ふりかえりの設計・ファシリテーションを頼まれたり、社内でふりかえりで大事なことについて発表した結果、他部署からもふりかえりの相談を持ちかけられるようになってきました。 「このチームのコミュニケーションをもっと良くしたい」 ふりかえりをやろうと思う人の多くが考えていると思います。 ただ厄介なのは、コミュニケーションの課題の多くを占める「遠慮」は「目に見えない」ということです。課題として捉えづら
こんにちは、コミューン株式会社でスクラムマスターを担っているヤマシタ（@yama_sitter）です。 前回「スプリントの属人性を減らしたらベロシティが安定した話」という記事を書きました。 この記事で紹介した取り組みに至るまでの過程に興味がある、という声を頂いたので、その過程、及び過程を振り返って得られた気付きを紹介させて頂きます。 ちなみに少し長いです。 ご了承下さい。 まずは結論から 取り組みの出会いから定着に至るまで 「WIP制限の導入」に至るまで 出会い 導入 定着 「タスクサイズの制限の導入」に至るまで 出会い 導入 定着 「死亡前死因分析（プレモーテム）の導入」に至るまで 出会い 提案 定着 改めて振り返ってみて まとめ 取り組みに出会えたのも上手くハマったのも正直偶然 「気付いてもらう」ことが大事。最後に決めるのはメンバー 「とりあえずやってみよう」くらいの気持ちで改善に取り
PHP Conference 2019でのサイボウズのスポンサーセッションです。 #phpcon #Track3 2019/12/6 追記 スライド76~77で、「伝統とは火を守ることであり、灰を崇めることではない」という言葉をGustav Mahler の言葉として引用していますが、Gustav Mahler の言葉である、という明確な出典はありませんでした。
この記事に関連する話題: プロダクト開発者に求められる、これからの「倫理」の話をしよう。 他人の仕事の難しさ・勘どころを正しく想像できる者に、私はなりたい。 もちろん専門外の話であればそれを100パーセント理解するのは難しいし、知った気になって軽々しく口を出すのも違う。でもその仕事に向き合う人の“気持ち“を知る努力はできるはずだ。その努力なくして「あのチームは仕事が遅い」「なんでこの程度のモノしか作れないのか」などと批判をするのは大変格好が悪い、と僕は思う。 社内外の様々な会話のハブとなるプロダクトマネージャーという仕事において、この点は特に重要だと思う。 ・・・という話は既に "Don't "Guess" How People in Other Roles Work" で書いた通りで、書籍 "Inspired: How to Create Tech Products Customers
XP祭り 2021 https://xpjug.com/xp2021/
身も蓋もないチームの現実 #devlove / The reality of a team with no MI and FUTA
2019年11月5日（火）DevLOVE「組織のリアル~私のチームの話をしよう~」にて。
こんにちは。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでフロントエンドエンジニアをしているkodai（@r34b26）です。 色んなアドベントカレンダーをみながら、もう2021年が終わるのか…という実感が湧いてきました。 今回は、約2ヶ月前から開発チームで取り入れた「10min勉強会」について、その運用と改善の道のりを振り返ってみたいと思います。 勉強会がなかなか続かなかったり、チーム間のコラボレーションを促したい方にかなりオススメなので、よければご参考ください！ 1. 10min勉強会を導入した背景 2. 運用のはじまり 3. つまずいたポイントと改善プロセス 3-1. 発表用の資料をつくらず、書記を立てる 3-2. ネタぎれ防止とkaizenをセットにする 4. 10min勉強会を運用してみての変化 5. さいごに 1. 10min勉強会を導入した背景 元
こんにちは！ SmartHRで開発したり、アジャイル推進したり、筋トレしたりしてるkouryouです。 SmartHRでは顧客の価値の最大化を目指し、日々開発プロセスの改善を行っています。 特に私の所属する基本機能のDチーム*1では、以前からクロスファンクショナルを強く推進しています。 本日はクロスファンクショナルとは何なのか？やってみてどんなメリットがあったのかをまとめました。 クロスファンクショナルとは スクラムガイドでは機能横断型と翻訳されています。 機能横断型というのは、エンジニアリング、デザイン、QAなど複数の職能（スキル）を持つことを表しています。 そして機能横断型という言葉は、チームに対して使われることが多いですが、個人に対しても使われます。(例: プロダクトエンジニアがデザインもできる、QAエンジニアがコードも書けるなど) SmartHRにおいてチームが機能横断型であること
crocos.jp
This domain may be for sale!
Shape Up: Stop Running in Circles and Ship Work that Matters
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/shapeup"> � !nkU � �nkU Shape Up Stop Running in Circles and Ship Work that Matters by Ryan Singer Buy the print edition Start reading →
日本XPユーザグループ（XPJUG）が主催になり、毎年秋に開催されている「XP祭り」。ここでKDDIアジャイル開発センター株式会社の小糸氏、三宅氏が登壇。続いて、チーム内で発言頻度に偏りがある問題、打ち合わせ中に謝罪が多い問題、フィードバックを素直に喜べない問題に対する対策と、その結果得られたことを紹介します。前回はこちらから。 関係の質を高めるための取り組み ②フラットな環境を作ろう 小糸悠平氏（以下、小糸）次がフラットな環境を作ろうということです。まずメンバー間の知識の偏りです。これはチームだったら必ず起こり得る話で、エンジニア歴が長くてチームにも長い人と、若手のメンバー（の偏り）ですね。 それからベテランメンバーの発言に従う風潮ですね。「この人が言うんだから信じるしかない」みたいなマインドが働いてしまうチームの傾向が見られた時に、なにをしたかという話です。 これも仮説を立ててみました
David Bernstein : Five Development Practices for Building Software with Scrum
まずは、傾聴。8割以上「聴く」ことを目標にする。 さくらインターネットES本部 人材支援グループでマネージャーをしている矢部です。 前回の「1on1ミーティングとは？ 人事マネージャーが伝える心得 準備編」に続いて、今回は実践編をお届けします。 1on1のベースは傾聴です。傾聴とは、耳を傾けて心で聴くという意味。 以前、当社で1on1のアンケートをとった際、「上司が9割話していて辛かった」というコメントがありました。そうならないためにも、まずはメンバーの話を聴くことからはじめましょう。 うなずく、あいづちを打つ メンバーの話や表現に対して、それを否定したり、批判したり、疑念を挟んだりせずに傾聴しましょう。そして傾聴していることをメンバーに伝えるために、うなずきやあいづち、そのほか言語的、非言語的な表現を繰り返すことが大事です。 まずはメンバーの話をありのままに受け止め、自然で落ち着いたタイ
組織のサイロ化を前提としたチーム構成、育成の仕組みとは？はてなとChatworkのエンジニアマネージャーがリモートワーク下のマネジメントを語る
組織のサイロ化を前提としたチーム構成、育成の仕組みとは？はてなとChatworkのエンジニアマネージャーがリモートワーク下のマネジメントを語る 近年、メガベンチャーの増加やスタートアップの大規模調達などによって、エンジニア組織の規模も増大、組織も複雑化するなか、エンジニアマネージャーやテックリードなどの重要性がますます高まっています。 2022年3月24日に開催した『onkさんとだいくしーさんに聞くエンジニア組織づくり最前線vol.5』では、株式会社はてなの大仲能史さん、Chatwork株式会社の粕谷大輔さんをお招きし、マネージャーとしてのミッションやリモートワークにおける「サイロ化」との向き合い方、マネジメントの面白さと難しさ、プレイヤーとの両立など多岐にわたるトピックを語っていただきました。 モデレーターはファインディの取締役CTO佐藤が務めます。 パネリスト 大仲 能史さん/ @on
経産省と本気でアジャイル開発をやってみた！制度ナビPJで見えたGovTechのリアルと未来 https://codeforjapan-govtech-20190514.peatix.com/ で話したこと。 このような取り組みと場作りを進めるCode for Japan、その代表の 関 治之 さん、一石を投じた経産省の皆さん、ともにつくるに臨んでくれた開発チームの皆を称えたいと思います。感謝。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Findy Teamsの指標を使ってチームの生産性を改善しよう - ANDPAD Tech Blog
会議中に発言してもらえない原因は、マネージャーの私にあった - Qiita
Penpot: The Design Tool for Design & Code Collaboration
アサインは突然に -チームリーダーになって気づいたこと- - MonotaRO Tech Blog
ユーザーファーストであり続けるために開発チームオンボーディング資料を作ってみた｜坪田 朋
チームラーニングでチームの共通認識を揃える - Kyash Product Blog
試してみたけど、Googleのいう「心理的安全性」だけでは、学習やチャレンジは誘発されないらしい。
プロダクト開発における納得感 - Konifar's ZATSU
モブプログラミングが当たり前になるまで 〜導入からフルリモート化までの課題と解決〜
コーディングを助けるためにデザイナーができること① | knowledge / baigie
新人エンジニアが意識すると良いなと思うことまとめ - Qiita
エンジニアの「雑談」の効能を考える - Qiita
スクラムは「気付いてもらう」とうまくいく、と気付いた話 - Commune Engineer Blog
改善失敗して学ぶ、
レガシープロダクトに立ち向かうチーム作り。
なぜUI/UXデザイナーの仕事は批判の的になるのか？その謎を解明すべく我々は（以下略）
Formula of Software Estimation
10min勉強会の導入と、運用改善をふり返る。 - Gaudiy Tech Blog
SmartHRにおけるクロスファンクショナル実践例 - SmartHR Tech Blog
打ち合わせで笑顔がない、フィードバックを喜べない、「なにを言ってもダメなんだろう」な雰囲気が蔓延… チームの問題を改善させた、“少人数で話す場”からの関係性づくり
アジャイル開発の時代 / Open Seminer Hiroshima 2020
1on1ミーティングとは？ 人事マネージャーが伝える心得 実践編 - さくマガ
アジャイル開発は2度失敗する。