自分の心理的安全性を、自分で高める - Link and Motivation Developers' Blog
エンジニアの梅原です。 少し前から「心理的安全性」というキーワードについて、疑問に思うところがあって色々と考えていて、 なんとなく考えがまとまったので、自戒も込めて文章として書き起こしてみました。 もともと社内向けに書いたものでしたが、思いのほか反響があったためこちらでも書いてみようと思います。 めちゃくちゃなこと言ってんな、って思う人もいるかもしれませんが、際に振ったときの思考実験だと思って読んでもらえると。 心理的安全性とは何か？ 一般的に「心理的安全性」とは、以下の定義で語られます。 "A shared belief held by members of a team that the team is safe for interpersonal risk taking." （このチーム内では、対人関係上のリスクをとったとしても安心できるという共通の思い） Edmondson (19
ハッカーの呪いと共に生きる ~ The hacker is dead, long live the hacker! - An Epicurean
私がWeb業界に入ったのは、ハッカーに対する憧れからです。その原体験を大事にしたいという気持ちを今でも強く持っています。 もう20年近く前になりますが、Web2.0の時代、私は傍観者でした。世界ではGoogleを筆頭として、日本でも、はてな社などが、エンジニアドリブンで個性的なサービスを生み出していました。他にもmiyagawaさんなど、個人で世界的に使われるようなOSSを開発している人もいました。書籍「ハッカーと画家」で描かれるような、ハッカーが個人技で大企業を出し抜く痛快さがありました。 そのように、WebサービスにせよOSSにせよ、同年代のハッカーが自分の技術でイノベーションを起こし、世の中に影響を及ぼしていることに羨望の眼差しを向けていたのです。 サブカル的な空気感も好ましく思っていました。西海岸のコンピュータ文化はヒッピーカルチャーの影響を受けていたのは間違いないでしょう。当時の
ビッグバンリリース対策でFeature Toggleを導入したら、開発チームが「デプロイできる状態」をより深く考えるようになった - はてなニュース
ソフトウェア開発において注目されるパフォーマンス指標には、デプロイに関係するものがあります。GoogleがDevOpsの取り組みから発表したFour Keysも、デプロイ頻度のほか、コミットからデプロイできるまでのリードタイム、デプロイにともなう障害発生率とその回復時間と説明されています。 そのためデプロイできるブランチへのマージは小さく、回数を重ねることが推奨されるようになっています。一方で、ビジネス用途のSaaSなどでは顧客との関係から、新機能は適したタイミングで完成度を上げてからリリースしたいという要求もあります。 タレントマネジメントシステム「カオナビ」の開発チームでも同様の課題感を抱えており、その解決のためFeature Toggle（機能トグル）を導入してデプロイとリリースの分離を図りました。その経緯や成果について、導入を主導したCTO室の富所亮さん、サービス開発部で実際にFe
DDDでプロダクト開発をしたので振り返ってみた - JMDC TECH BLOG
みなさん、こんにちは！プロダクト開発部の吉川（@yoshiyu0922）です。 現在、JMDCが保有している医療ビッグデータを活用して生活者や医療に新しい価値を提供する新規プロダクト開発チームのバックエンドを担当しております。 以前に新規プロダクト開発で採用している技術や設計についてこちらの記事で紹介しましたが、Go x GraphQL x DDDでプロダクト開発をしています。今回はプロダクトの開発が一区切りしてこれからリリースするということで、開発してみて良かったことやこうすれば良かったことを振り返りをしました。振り返りの内容は主にDDDに関することです。 DDDとは DDDとは「Domain-Driven Design」の略語でドメイン駆動設計と呼ばれるソフトウェア開発手法の一つです。問題を解決しようとする領域（ドメイン）をモデリングによってソフトウェアの設計や実装に反映させることで、
エンジニアリングマネージャーの最初の学び - このロールは何なのか - yigarashiのブログ
2023/6/16付の人事異動で正式にエンジニアリングマネージャー（以下EM）になりました。2021/8に「エンジニアリングマネージャーを目指す若者の戦略」という記事を書いて明確にEMを目指し始め、2022/12には「EMキャリアを切り拓く「最強の現場リーダー」という働き方」という記事でEMに近づく様子を書きました。さらにそこから半年余り、ついに会社からも正式にEMと呼ばれることになりました。実際には3ヶ月ほど前から強くEMを志向した動きにはなっていましたが、やはり正式な職位は特別なもので、キャリアにおける重要な実績をひとつ解除したと感じています。 これほどEMというロールを志向し色々とやってきたのですから、EMとしての振る舞いもさぞスムーズに立ち上がるかと思いきや、実際にEMとして動くのは非常に難しいことでした。書籍やブログ記事を読んで頭で理解したEMという働き方と、自分がチームでEMと
なめらかなナレッジシェアリング文化を創る | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の9日目の記事です。 はじめに こんにちは。メルペイのバックエンドエンジニアの@tanaka0325です。 この記事では、私が最近サイドプロジェクトとして取り組んでいる「なめらかなナレッジシェアリング文化を創る」ための活動について紹介したいと思います。 事前に断っておきたいこととして、このプロジェクトはまだ始まったばかりです。プロジェクトメンバー全員がサイドプロジェクトとして参加しているので、これから少しずつ進めていくものになります。 今回は私たちがどのような活動を行っているのか、現状の状況や今後の方針についてお話できればと思います。 ※この記事では表記ゆれを避けるため、資料やコンテンツ、知見などをまとめて「ナレッジ」と表現することとします。 きっかけ まずは、この活動を始めたきっかけについてお話したいと思います。
サポートを明らかにすることを通して、助け合い上手なチームに爆速でなるぞ/clarifying_support_fukuoka_2023
「助け合おう」とよく耳にします。ところが、助けるとは何なのか、助け合えているとはどのような状態なのか、意外と雰囲気でやっていたりしませんか。このセッションは「サポート」という側面から助けるという行為を分類し、解説します。そして仕事の中で、サポートの偏りを発見し、組織的にサポートを育む仕組みを作り、「助けること」と「助けられること」にうまくなるセッションです。 https://confengine.com/conferences/scrum-fest-fukuoka-2023/proposal/18080 発表者 https://twitter.com/_N_A_ ブログ:https://note.com/mryy/ もっと学ぶ:『1on1大全』https://wizard.booth.pm/items/1938803
コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
マネジメントをはじめて1年経っての所感 - STORES Product Blog
山陰の日本酒がすきな内立（@b1a9idps）です。2023年1月から STORES 決済 の開発部門のシニアマネジャーを担うことになりました。 マネジメント業務をはじめて1年が経ったので、やってきたことや自分自身の心情について思い出せるように書き残しておこうと思います。はじめたての頃に思っていたことはこちらにあります。 note.com 経歴 かんたんに自分の経歴を説明します。現在、STORESではマネジメント業務が中心ですが、副業ではがっつりJavaを書いています。 入社して4年7ヶ月 入社~3年半：STORES 決済 のバックエンドエンジニアとして開発業務を行う 3年半~4年半：バックエンドチームのプレイングマネジャーを担う マネジメントをはじめて1年経っての所感 マネジメントをはじめて1年の間の、チームの課題の洗い出しから解決に向けて実行したことや自分がマネジャー・シニアマネジャー
万葉のチーム観、そのはじまり｜万葉
こんにちは、nay3です。今日からは、万葉の文化の根本であるチーム観について書きはじめたいと思います。より分かりやすくお伝えできるように、創業以来、私たちがどんなふうに変わってきたのかという切り口でご紹介してみたいと思います。 創業当初は、「チーム」に強い関心はなかった 万葉を立ち上げたときは、開発をチームで行うことが一般的になっており、万葉も自然な流れとしてチームで開発することを前提としてはいました。しかし、私個人は「チーム」について特段の関心があったわけではありません。振り返ってみると、私はプログラミングは中学時代から一人でやっていたし、スポーツに苦手感があったのでバスケ等のスポーツを通じてチームについて学んだこともありません。部活動などでリーダーシップを伸ばす経験は積んでいましたが、今思えば、それはあくまでもリーダーシップの経験であって、チーム作りというジャンルとは少し違っていました
開発チームの責務を「エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する」としてみた話 - $shibayu36->blog;
最近開発チームの改善を行う時に、どういう目的で開発チーム改善を行うのかや、開発チームの責務は何なのかについて悩んでいた。色々本を参考にしながら、自分の中でしっくり来た責務があったので、ブログにまとめておく。 まず自分の中で、開発チームの責務は次のものであると言語化した。 エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する なぜこの責務としたか まず現代のソフトウェア開発においては、非常に不確実な状況で、顧客にとって価値があるものが何かを探索しながら、高速に価値を創出・提供しなければならない。これを満たすためには、「正しいものをつくる」ということと、「正しくつくる」ということの両輪を回す必要がある。 この時、プロダクトオーナー側と開発チーム側で分業するとすれば、やはり開発チームは「正しくつくる」ことに焦点を当てて責務を持つと良いと考えた。つまり開発速度(価
Google re:Work - マネージャー
イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
無能な同僚と働くということ。 - WETな備忘録
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
LJL最悪の日 Dara選手引退について｜Jini｜note
それでも、Dara選手は新たにLJL2部リーグのSCARZ Burning CoreにSupport兼コーチとして所属し、2部では破竹の快進撃を遂げ、昇格戦では遂にRascal Jesterに勝利し、1部リーグへの昇格を決めた。 これで、ようやくまたプロシーンでDara選手の活躍が見られると、ファンの誰もが安心して約1ヶ月。Dara選手が衝撃的なツイートをした。 「私はプロを引退します。理由はLJLに失望しました。1部でRPGの人と会うのは心がどうしても無理でした。RPGを考えたら怖い記憶が戻って頭が痛い、薬が必要。ゲロでプレイが出来ない。心が壊れてしまった。私は韓国に帰ります。」 「在留カードを渡さないと韓国に帰さないって言われて、私はそうするしかなかった。外に出ようとしたら追いかけてくる。大きな怒った声でプレッシャーを私にあげる外国で一人の私に力はなかった。本当に怖かった。」 「RPG
全然わからない。俺たちは雰囲気でマネージャーをやっている。 - アルパカログ
自分は今、コード書かずにマネジメントしかしてなくて、そんなポジションの人にそれほど価値ないでしょ、とか思ってしまうけれど、こういうポジションの人がいないチームの話とか聞くと、やっぱりいたほうがいいんじゃないか、と思うし、ほとぼりが冷めるとまた自分は無価値のように思えてしまう。 こんな心境の吐露を「エンジニアリングマネージャのキャリアについての悩み」で拝見して、私も何か発信しなければと思ったのがこの記事のきっかけである。筆者のdaiksyさんは、 エンジニアマネージャってなんか実績を示しづらいので、世の中の数多のマネージャ職に埋もれて、自分にスポットが当たりづらい、結果、キャリアに不安が拭えない、みたいなとこないです？ とも述べていて、これら2つのメッセージに込められた心の葛藤は、全てのエンジニアリングマネージャー(以下EM)が感じていることではないかと私は思う。少なくともEMの一人として私
ISUCON8予選突破した | おそらくはそれさえも平凡な日々
今年も予選から素晴らしい運営、問題で堪能させてもらいました。 去年本戦3位で終わり、思うところがあり、今年は一人で出るか、もしくは出るの見送ろうと思ってたんだけど、TwitterのTL上でnajeiraさんが、メンバー募集していたのを見て、急に出たくなってしまって一緒に参加させてもらうことにした。 興味あります。 去年3位 優勝経験有り Go書けます — songmu (@songmu) 2018年8月28日 これまで、同僚か元同僚かとしかチームを組んでこなかったので、あまり馴染みがない人と組むのは楽しそうだし、そういう新しいチャレンジも面白そうに思ったのだ。 ということで「死闘の果てに」と言うチーム名で、najeiraさんとbluerabbitさんと参加することにした。チーム命名はnajeiraさん。 事前の顔合わせでも、fabricでdeployしましょう、解析には github.co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームにノリをもたらした時にいた「二人目に踊る人」の共通点
SRE不在のチームに入って2ヶ月でやったこと - 負荷試験ツールからはじめるSREプラクティスの導入
礼節から育てるチームの健康と信頼性 / Improve team health and reliability starting with civility
戦略(Strategy)、作戦(Operation)、戦術(Tactics)、そして兵站(Logistics) - UEI/ARC shi3zの日記.