「問題から目を背けず取り組む」 �一休の開発チームが6年間で学んだことDeveloper Summit 2020 発表資料 #devsumi
改善提案の議論をテキストで非同期に行う - リモートワークに合わせた提案方法を探る - $shibayu36->blog;
最近はリモートワークが主体で、みんなで集まっての同期的コミュニケーションがやりづらくなり、他の人の非言語情報を受け取ることも困難になった。その結果として、自分がチームで改善提案をした時に、周りの人からコメントを受け取る、提案に対する温度感を探るということが難しくなった。 改善提案にこのような課題があったので、リモートワークに合わせた方法を探り、まず改善提案の議論をテキストで非同期に行うというやり方を行ったので紹介する。その過程で自分が作った提案のテンプレートも共有するので、参考にしてもらえると嬉しい。 課題: 現在の働き方でも改善提案に対するフィードバックをもらいやすくしたい もう一度課題をまとめる。 自分がチームの改善提案をした時は、チーム内の意見や反応を見ながら、より改善提案をブラッシュアップして実施したいと考えている。つまり開発フローなどチームの改善提案でもコードレビューと同様、コメ
モブプログラミングを導入し、チーム一丸となってタスクに取り組むようになった話 | メルカリエンジニアリング
はじめに メルペイ ML Platformチームの@ysk24okです。この記事は、 Merpay Advent Calendar の4日目の記事です。 本記事では自チームにモブプログラミングを導入し、チーム一丸となってタスクに取り組むようになった話を共有します。 モブプログラミングとは モブプログラミング（以下モブプロ）とは、モブプログラミング・ベストプラクティスでは「3人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決していくこと」と定義されています。Hunter Industries社のWoody Zuill氏が2015年頃からカンファレンスなどで発信しはじめたことで世の中に広まっていったと言われています。 モブプロでは1人のタイピストとその他のモブに分かれ、10分でタイピストを交代します。その他のモブは基本的にコードは書かず、問題解決のためのアイデアをタイピストを
視座の可視化｜kgmyshin
視座が高いってそもそもなんやねん問題 1on1で「視座を上げてほしい」って言われたり、マネージャー陣の集まりで「視座高い人がいいよね」って会話をしたりするけど、じゃぁ「視座の高いってなんぞ？」「どう見極めればええのん？」ってなりますよね。 自分も前職でエンジニアリングマネージャーしてた頃から、現職にて横断組織の一環として採用にかかわるようになって良くそれらのセリフを聞いております。 で、これが正解ってわけじゃないんですけど、自分はいつもこんな感じで可視化してますよってのを紹介してみます。 「視座が高い」を端的に言うと 自分は「視座」ってのは一言でいうと「どのレベルの課題まで、当事者でいられるか」っていうスタンスの度合いだと解釈しています。 ここで言っているレベルというのは難易度ではなく対象のスコープのことです。個人の課題なのか、チームの課題なのか、はたまた所属する会社の課題なのか。 で、「
体制を考えるときに意識していること - id:onk のはてなブログ
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
NTT Com オンボーディングハンドブック
オンボーディング ハンドブック #このサイトについて #NTTコミュニケーションズ(以降、NTT Com)社内で製作したオンボーディングハンドブックの内容を、より一般化して広く公開するものです。 ソースコード #本書のソースコードは https://github.com/nttcom/onboarding-handbook で公開しています。 ライセンス #NTT Communications Corporation 作『オンボーディング ハンドブック』は クリエイティブ・コモンズ 表示 - 非営利 - 継承 4.0 国際 ライセンス で提供されています。 関連ハンドブック #リモートワークの働き方に特化したリモートワークハンドブックや、チームビルディングのプラクティスをまとめたチームビルディングハンドブックも参照ください。 読み始める #こちらから本編に進めます。 はじめに
若手から見たリモートワーク時代のチームビルディング | BLOG - DeNA Engineering
2020 年 4 月にコロナの影響による緊急事態宣言が発令されて久しい今日この頃ですが、多くの会社でリモートワークが余儀なくされ働き方が大きく変わりました。 DeNA がリモートワーク可能な体制へと迅速に切り替えていく中で、私自身リモートワークによる業務が9割以上を占めました。私や私の所属するチームだけでなく日本中でも働くことに対する考え方が大きく変わるタイミングだったのではないでしょうか。（DeNAでは緊急事態宣言が発令される前には全社的にリモートワークがすでに可能なレベルにまで整備され、とてもスピーディーにリモートワークへと移行できました。制度や勤務体制など様々な整備をしてくださったことにとても感謝しています。） その中で、私たちがチームのコミュニケーションや課題を改善するためにどう工夫したのかをお伝えすることで読んでくださる方のチームのチームビルディングの一助にして欲しいと願っていま
振り返りで積み上げた開発プラクティス（2020年総まとめ） - BASEプロダクトチームブログ
こんにちは。BASE BANK 株式会社 Dev Division にて Manager をしている東口（@hgsgtk）です。 昨年 2020 年は本ブログにて個人の足し算ではなく掛け算で成果が出せるようなチームを目指したアジャイル開発の取り組みを継続して紹介してきました。 チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方） | 詳説 | July Tech Festa 2020 登壇レポート アジャイル開発におけるユーザーストーリー分割実践 〜画面リニューアルの裏側〜 これらの考え方やプラクティスは全体の一部で、開発チームとしての組織ローカルなプラクティスを『BANK DEV 白書』として整理しています。『BANK DEV 白書』では次のような内容を整理しています。 一般的なアジャイ
チームの症状と処方の考察｜Megumi Kaneko
はじめに自己紹介を少しさせてください。 私はクライアントワークで約30名規模の開発チームに1年間ほどジョインしていました。役割は5〜10名のエンジニアで構成されるチームのプロダクトオーナーとしてだったり、UIデザイナーとPMのチームのスクラムマスターとしてだったり、色んな形でチームに接してきました。 その中で経験したことが、広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」を読んで色々整理されたので、チームが陥りがちな問題について稚拙ながら考察を書きたいと思います。 チームの健康状態とはチームの状態を表す指標として心理的安全性はよく聞きますよね。 広木大地さんの著書である「エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング」には心理的安全性について下記のように書かれていました。 「問題点の指摘」や「自分の弱
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
リーダー(管理者)ではなくエンジニア(実務者)でありたいと願う人々へ - おうさまのみみはロバのみみ
「お前は向いていないんじゃない、やってないだけだ」 この一文を読んでほんの少しでもなにかを感じた人は是非とも↓の本を今すぐに読むべきだ。 エラスティックリーダーシップ ―自己組織化チームの育て方 作者: Roy Osherove,島田浩二出版社/メーカー: オライリージャパン発売日: 2017/05/13メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 本著はみんなが考え、感じているリーダーシップという曖昧模糊な概念に対して具体性をもたらせてくれる。 それは「チームリーダーの役割は優れた人材が育つのを助けること」と定義付けていることだ。 このシンプルである意味で本質をついている定義付けが本著を名書たらしめているとぼくは思う。 この本の構成は1部〜4部(おおよそ本書の半分ほどを占めている)までが著者によるリーダーシップとはなにか？3つのフェーズの分類とそのときに期待さ
生産性を向上させるためには、日本人エンジニアに英語での会話力は必須だと思った - メソッド屋のブログ
私はマイクロソフトのインターナショナルチームで働いています。特に私は以前からUSのエンジニアの生産性の高さの秘密を学びたいと思っています。今回は同僚からの何気ない一言からの気づきをシェアしたいと思います。 David からの何気ない一言 私は無宗教で葬式の時は曹洞宗なのですが、以前から聖書には興味がありました。私の叔父はドイツ、アメリカに長年住んで仕事 をしていました。そんなガチに海外で生活していた彼が言っていました。 彼らの文化を理解したかったら聖書を読むのがいいよ 確かにイギリスにいた時もあらゆる場面で、日本に帰っても海外の映画を見ても様々な場面で、聖書の影響を感じます。 私は自分の仲間をより理解したいし、明るさ、生産性の高さ、芸術性などを本当に尊敬しているので、是非ともその考えを学んでみたいと思っていました。 私の尊敬する同僚の David もクリスチャンなので、彼にどの聖書を読んだ
他のチームに｢技術的支援｣をする時に気をつけていること - Masteries
自分が働いているGaiaxのように, 社内に複数の事業があり, それぞれにエンジニアが所属して働いている場合, ｢ねえ, ○○のチームの××って仕組み, どうやってるの? うちのチームでもやってみたい!｣といったコミュニケーションから, 他のチームに対して｢技術的支援｣をする機会が生まれる事が多々あります. 最近の例だと, 社内の新規事業の立ち上げや, オンプレからクラウドへの移管のタイミングで, Infrastructure as Codeやデプロイ施策, ChatOpsなど整えたいので, 相談に乗って欲しい! という声を何度か頂いた事がありますし, よくよく考えると今やっているPhotosynthへの留学も, 見方を変えれば｢Photosynthへの技術支援｣と言えるかもしれません. そういった｢技術的支援｣をする時に気をつけている事についてFacebookにつぶやいた所, 思ったより
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報共有から始めるチーム開発とキャリア戦略