コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
ChatGPTのヤバさは、論理処理が必要と思ったことが確率処理でできるとわかったこと - きしだのHatena
ChatGPTのヤバいところは、論理処理が必要だと思っていたことが、じつは多数のデータを学習させた確率処理で解決可能だと示したことだと思います。 たとえば、このように正規表現にマッチする文字列を生成するには、特別に専用の論理処理が必要だと思っていました。 前のブログのときには特殊処理が必要だと考えてましたね。 ウソはウソと見抜ける人じゃないとChatGPTを使うのは難しい - きしだのHatena けど、123_45678world.mdはマッチするのにマッチしないと言っているので、そのような誤りが入ることを考えると、どうも確率処理だけでやっているようです。 考えてみると、3層以上のニューラルネットであれば論理素子を再現できるので、ディープラーニングで論理処理を模倣することは可能なんですよね。 バックプロパゲーションでニューラルネットの学習 - きしだのHatena そもそも論理は、多数の
ChatGPT でゲーム作ってみた｜EIKI`
前置き省略。ChatGPT がゲーム作ってくれるならもうプログラムしなくていいじゃん！ヤッター！ ＊以後、Q：入力文 A：AI からの回答です。長いので飛ばし飛ばし読んでください。 セットアップ～移動までQ. Unity で 2D アクションゲームを作りたいと思います。空のプロジェクトをセットアップしましたが、何を配置すれば良いですか？ A. まず、2D キャラクター用のスプライトを配置します。次に、キャラクターを動かすためのスクリプトを作成し、キャラクターにアタッチします。さらに、背景や障害物などのスプライトを配置し、それらを動かすためのスクリプトを作成します。また、ゲームのルールやポイントなどを表示する UI エレメントも配置します。最後に、ゲームのシーンやゲームオーバーやクリアなどの状態を切り替えるためのスクリプトを作成します。 つくりました。素材は全部アセットストアです。Q. プレ
システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
成長の早いジュニア・ソフトウェアエンジニアの特徴 - junebox
こちらが伝えた内容から不要なことを邪推しないというか、文字通りに「真っ直ぐ」である人は、望ましい行動に最短経路で向かっていくので効率的な行動を選択していくな、と感じます。「なにかわからないことがあったら、すぐに質問してくださいね」と言われたときに、実際にすぐに質問できる人はどんどん前に進んでいきます。余計なことを考えない分、リソース効率がよいのでしょう。 ぼく個人は、人間はもともと素直な生き物なんじゃないかと思っています。それが、イヤな体験を重ねるたびに少しずつ防衛的になって、だんだんと素直さに蓋をしてしまうケースがあるイメージです。「それくらい自分で調べろ、いちいち質問するな」と怒鳴られるようなことがあったら「すぐに質問してね」と言われてもなかなか実行に移せなくなりそうですよね。そういう人は「自分は、そういう状況である」というのを自覚することから始めるとよいでしょう。「質問してよかった」
モブプログラミングに向いてない私の話 - 誰かの役に立てばいいブログ
新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・
GAFAコーディング面接こんな感じでした - yambe2002’s diary
このあいだ、GAFA数社のコーディング面接を受けて全落ちしました。後続のため、オンサイト面接がこんな感じだったよ、というのをストーリー風に仕立てて公開します。問題と会話はダミーですが、雰囲気はかなり近くできたと思います。なお実際の会話はすべて英語で、バーチャルでの実施でした。 メイン問題はLeetCodeのNo.1472をもとに作成。 https://leetcode.com/contest/weekly-contest-192/problems/design-browser-history/ ちなみに「ぼく」はIQ+30くらいの設定です。それではどうぞ。 入室と自己紹介 面接官「やあ！わたしはシンディ。会えて嬉しいよ！」 ぼく「こんにちは、シンディ。ぼくはyambe2002。調子はどう？」 面「超いい感じだよ。きみは？」 ぼ「ぼくも超いい感じさ」 面「それはよかった。わたしは部署Aのソフ
タチの悪い凄腕エンジニア｜水屋亜次郎(みずやあじろう)
この文章の翻訳です 参照1、参照2 原題「Brilliant Jerks in Engineering」 我々のうちの多くが、彼ら(やること成すこと素晴らしいが他人をゴミの様に扱うタチの悪いエンジニア)と働いている。いくつかの企業は彼らを雇わないポリシーを掲げている。例えばNetflixの「タチの悪い凄腕をゼロにしよう(No Brilliant Jerks)」など。それは僕がNetflixにジョインした数多くの理由の内の一つだ。あるいは「馬鹿げたルールを作るな(No Asshole Rule)」という話題となった本もある。wikiから2つの判断材料を引用してみよう。 1.その人と会った後に、圧力や侮辱を感じたりもっと悪い状態になっていないか？ 2.その人は、その人自身より力のない人たちをターゲットにしているか？あなたやあなたの会社への問いかけたい。あなたは、どうしようもなくクソな凄腕エンジ
エンジニアのコーチング by Kent Beck
以下は、Kent Beckによる「Coaching Engineers」の翻訳です。本人の許可を得て掲載します。tl;dr 有償でエンジニアのコーチをします。詳細と待ち時間についてはお問い合わせください。 物語の結末2018年2月にFacebookを退職する直前に、トップ1%のエンジニア（現在および過去にレベルE7以上だったエンジニア）のオフサイトミーティングに参加しました。海辺のリゾートでバスを降りると、私がコーチをしていた生徒が複数いることに気づきました。そのうち何人かは昇進したことを知っていましたが、その他の生徒には驚かされました。 私にとって、胸がはちきれるほどの誇り高き瞬間でした。私は、生徒たちと関係を築き、彼らの成功のために心の底から尽力してきました。多くの生徒らが成功を収めたことを目の当たりにして、私は大いに驚き、嬉しくなりました。物語はさらに続きます。 Facebookの上
"クソコード"は人格攻撃ではないのか｜qsona
これは仮説というか自分がこうだという話なのだが、自分のアイデンティティを侵食されると怒りが湧く。たとえば、自分が非常に大事にしている価値観に対して、同僚から「君のその価値観は間違っている」と言われたり、あるいは、作品とか、経歴とか、家族とか、そういう自分自身と非常に密になっていて同一視されるようなものをけなされたら、腹が立つということだ。 プログラマーにとって、ソースコードというのは一つの作品だ。仮に経験が浅い開発者であっても、あるいは経験が浅いからこそ、1行1行に時間をかけて考えながら作りあげる。それに対してこれはクソコードだと言われたらどうだろうか。考えてみる。 よく、クソコードというのはコードがクソだと言っているのであって、お前がクソだと言ってるわけではないから切り離して考えるべきだという言説がある。僕はこれには微妙に賛同できない。その人が生み出したコードは、少なくともその人のいくぶ
リモートワークの設計と運用 / または Discord + VSCode LiveShare がいいぞという話 - mizchi's blog
この記事読んで自分のリモートワーク経験からどうやるのが今一番良いだろうか、という話をずっと考えていたので、書き出してみました。 リモートワークをする人必読。組織パフォーマンスを左右する「デジタル心理的安全」とは？ | 未来を変えるプロジェクト by iX（アイエックス） 自分自身はフルタイムリモートとフリーランスでのリモートの2つの経験があります。 次の会社が申請すればリモート可というスタイルなのですが、自分がリモートワークする場合、働く環境に期待しているのはこういうことだ、というのを事前に宣言しておく目的もあります。 フルリモートではなく、部分的なリモートを想定しています。 リモートワークに期待すること リモートワークは、基本的には「うまく運用すれば効率が下がらない」というものです。リモートワークで効率が上がることもありますが、基本的にはある種の福利厚生、雇用競争力のためと割り切ったほう
Code for Kobe
ITで神戸をもっと素敵な街にするため活動するコミュニティです。 View My GitHub Profile Code for Kobe は、「ITで神戸をもっと素敵な街にするため活動するコミュニティ」です。 Code for Japan の Brigade に登録されていて、神戸を中心に活動している任意団体です。 Code for Kobe : イベント告知などが掲載される Facebook page です。参加はこちらからどうぞ。 Code for Kobe Connect 上記の Facebook page とは別にコミュニティメンバ同士の情報交換用のグループがあります。 こちらは定例会に参加した人が参加できます。 Code of Conduct : 一般的に「行動規範」と呼ばれる文書ですが、 そんなに堅苦しいものではなく、当たり前のことが当たり前であるように、との思いで書いてありま
コードレビューは「コードの欠点を指摘する行為」ではない - id:anatooのブログ
コードレビューを「コードの欠点を指摘する行為」だと無意識に思っている人を見かけるけども、そういうふうに認識しないほうがチームにとって良いですよ、という話。理由は以下。 レビュワーの方がレビュイーよりも実力が無いといけない、という認識と結びつきがち チームの若いメンバーがレビュワーになりづらくなる 古株のメンバーやリーダーの書いたコードがレビューされなくなる レビューで指摘された項目がない = (指摘された欠点が無いということなので)良いコードという図式になりやすい レビュワーが欠点を指摘するあまり攻撃的なレビューをしてしまうことがある 逆にレビュワーがレビュイーに遠慮してあまりレビューしなかったりする レビュワーが誰でもわかる間違いしか指摘できなくなり、建設的な議論が起こらなくなる コードレビューが機能不全に陥る原因の一つが、コードレビューに対する基本的な認識がずれていることだと思う。 じ
新人プログラマをレビューで傷つけないために - Qiita
はじめに この半年くらいで初めて本格的にチーム開発を行い、今では日常的に GitHub の Pull Request を使っています。 チームの方々には、基本的なことから応用的な部分まで様々な観点からレビューをしてもらって、大いに勉強になりました。 ただ、時には「新人にとっては厳しいレビュー」をいただき、1 人で傷つきモチベーションを落とすこともありました。 もちろんそれは悪意のあるものではなくて、新人とレビュワーのスキルのギャップによって意図せず生み出されてしまうものです。 そのような不幸なレビューによって苦しむ新人が減ることを願って、新人を不用意に傷つけてしまう恐れのあるレビューをまとめていきたいと思います。 新人教育の場に少しでも役に立てていただけると嬉しいです。 前提条件 今回の対象とする「新人」は、本格的な開発経験が1年未満の方を想定しています。 個人で少しプログラミングはしてき
優秀な面接者に共通するものとは？ 数千の実例を調べてみました。- 前編 | POSTD
interviewing.ioでは以前、応募者の視点から、良い面接には何が役に立つのかについて分析し、多少掘り下げた記事を書きました。しかし、本質的に両者の力関係は不均衡ではあるものの、面接は双方向のやりとりなのです。私は少し前に、この市場では 人材採用は身元調査ではなくて販売のようなもので 、1時間も話をしている間に応募者の心を掴むことができなければ甚大な機会の損失になるという記事を書きました。しかし、面接の問題を解くことが時間と練習を必要とする習得されたスキルであるのと同じように、机を挟んだこちら側でもスキルを習得しなければなりません。良い面接者になるには、時間と努力、そして、オートパイロット任せを脱して相手と有意義に係わり合うのだという根本的な意志が必要です。 もちろん、ほとんどの人には、どうすれば良い面接者になれるかについて各自の揺るぎない意見があるので、ここでは理論や哲学の話は避
コードレビューのレビューはマネージャーの仕事 | POSTD
経営に関する名著「 High Output Management （邦題：ハイアウトプット・マネジメント（＝高い成果を可能にするマネジメント））」の中でAndy Groveは、”トレーニング（訓練・教育）はマネージャーの仕事”であり、組織の成果を向上させるためにマネージャー（経営者・管理者）が実践できる最高のレバレッジ活動だと述べています。 多くの組織のマネージャーにとって、この言葉は現在においても参考にできる素晴らしいアドバイスでしょう。しかし、現代のソフトウェア開発チームのマネージャーに関して言うと、その中心となる考え方はシフトしています。 > エンジニアリングチームの成果向上にとっては、GitHubのプルリクエストなどで実行するコードレビューが、今では最大のレバレッジポイント（レバレッジの作用点）である。 品質管理以上の役割 従来、コードレビューのプロセスは品質管理のツールと見なされ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/yuroyoro/status/1598538264126050304
ペアプロの心得
小さなチーム、大きな仕事を実装するモブプログラミング / Mobprogramming as Change The Way Your Work Forever
