みなさん1on1のときくらいカメラオンにしてますか？そうでもない？ - hitode909の日記
身の回りではチームのMTGとかは普段カメラオフでも、1on1のときくらいはオンにしている人が多い気がする。たぶん1年以上顔見てない人もいるけどとくに困ってないので、僕はどちらでもいいのだけどみなさんはどうだろう。 僕はある日、手荒れ対策でMacをクラムシェルモードにしたらカメラが畳まれてしまい使えなくなってしまった、という事情である日カメラオフにして過ごしていた。 さっき一念発起してMacのフタをあけてカメラオンにしてみたけど、ケーブル（高額なケーブルなので長さにゆとりのあるものは買えない）が短いので、ひきちぎれそう。 普段はカメラオフだけど、1on1のときくらいはカメラを— 趣味はマリンスポーツです (@hitode909) 2023年8月21日 この日記が、カメラオンにするのが当然、みたいな押し付けを推し進める記事にはならないようにしたい。 むしろ、1on1だからといってMacのフタ開
アジャイル開発のコードレビューで、建設的なコミュニケーションを行うための心構え
チームでのアジャイル開発において、コードレビューは最も重要な工程の1つです。『アジャイルプラクティスガイドブック』（翔泳社）では、その目的が「ソースコードを書いた人の持ち物から、チームの共同所有物にする」ことだとされていますが、メンバーの考え方が違ったり責任の所在が曖昧になったりと、トラブルの種となることも少なくありません。今回は本書から、コードレビューで建設的なコミュニケーションを行うための心構えを紹介します。 本記事は『アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知』（著者：常松祐一、監修：川口恭伸／松元健）の「第2章 「実装」で活用できるプラクティス」から一部を抜粋したものです。掲載にあたって編集しています。 コードレビューの目的 【プラクティス】ソースコードの共同所有 筆者はコードレビューの一番の目的を「ソースコードを書いた人の持ち物から、チームの共同
追加の依存パッケージなしでプロジェクトごとのGitコミットフックを設定する方法
Git 2.9以降はcore.hooksPathというオプションでグローバルまたはローカルのGitフックのディレクトリを指定できるようになっています。 Gitのcore.hooksPathオプションを利用するとhusky、simple-git-hooksのような追加の依存がなくても、Gitの機能だけでGitフックのコードをバージョン管理して、プロジェクトのセットアップ時にプロジェクトごとのGitフックを設定できます。 📝 類似するGitフックを管理するツールとしてpre-commitやLefthookもあります。これらのツールはGitフックの管理だけではなく、ファイルの種類ごとに実行するコマンドをわけて書けるようになっています。 つまり、lint-stagedのような機能も含むので、この記事で紹介するアプローチ以上の機能も同梱されています。 Node.jsプロジェクトの例 ここでは具体例
「ちょうぜつソフトウェア設計入門」でSOLID勉強会＋実践会をやってみた
みなさん、勉強会やってますか〜！ こんにちは〜！お昼時の天気の良さが気持ちいい季節になりましたね🌞 あすみ(@asumikam)です！ みなさんは勉強会やってますか？ 今日は、社内で企画した勉強会について書いていきたいとおもいます🖋 勉強会＋実践会をするに至るまで 私が所属しているPJではスクラムという開発手法を用いて日々開発をしています。 そのスクラムのイベントの中に「スプリントレトロスペクティブ」、つまりふりかえりをやっているのですが、何回もやっていくうちに「メンバー間の技術力の差」に関してのお悩みが目立っているな〜と感じ始めました。 「設計に関して、言われればわかるのだが自分で一から書くのは難しいかも・・・。」 DDDをベースとした設計方針で開発をしており、基本的な設計概念は共有されています。もちろん個人でDDDの本も読むこともしています。ただ、いざコードに落とし込む時にどこに何
小城久美子推薦！プロダクトマネジメント成功のために読みたい参考書籍6選 - エンジニアtype | 転職type
本連載では、プロダクト開発に携わるエンジニア読者向けに「成功につながるプロダクト開発」を実現するためのプロダクトマネジメントの基本の考え方や応用テクニックを、国内外の企業の優れたプロダクト開発の取組みを事例にとり、小城久美子さんがエンジニア向けに紹介・解説。明日からすぐに使える「いいプロダクト開発」をかなえるヒントを提供します。 小城久美子（@ozyozyo） ソフトウエアエンジニア出身のプロダクトマネジャー。ミクシィ、LINEでソフトウエアエンジニア、スクラムマスターとして従事したのち、『LINE CLOVA』や『LUUP』などにプロダクトマネージャーとして携わる。そこでの学びを生かし、Tably社にてプロダクトマネジメント研修の講師、登壇などを実施。書籍『プロダクトマネジメントのすべて』（翔泳社）共著者 日頃、エンジニアやプロダクトマネージャーに就いている方々から、 「何ができていれば
ももいろクローバーZ結成15周年特集 百田夏菜子×松岡茉優｜高校の同級生が語り合う青春時代と“今” - 音楽ナタリー 特集・インタビュー
ナタリー 音楽 特集・インタビュー ももいろクローバーZ結成15周年特集 百田夏菜子×松岡茉優｜高校の同級生が語り合う青春時代と“今” ももいろクローバーZ PR 2023年7月12日 今年5月17日に結成15周年を迎えたももいろクローバーZ。これを記念し、音楽ナタリーではももクロのメンバーがそれぞれ異なる相手と対談する連載企画を展開してきた。この連載のラストを締めくくるのは、ももクロのリーダー百田夏菜子と、彼女の高校の同級生である松岡茉優。過去にもテレビやラジオ番組での共演経験はあるものの、今回のように対談という形で2人が語り合うのは初めてだという。学生時代からの親友だからこそ、写真撮影では少し気恥ずかしそうな様子を見せていた彼女たちだが、対談の席に着くなり、松岡が百田に12年越しに聞きたかったこと、新しいももクロ像の話など会話がとめどなく続き、取材時間が足りないほどに盛り上がった。大人
僕が考える「良いコード」 - give IT a try
こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
2023年にエンジニアな私がマネジメントに目覚めてから読んでよかった3冊 - Lean Baseball
タイトルそのままのエントリーです. 気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています. マネジメントをする・しないを含めてキャリアパスどうする? マネジメントをやるとして何を教科書にしたら? 今どきの開発スタンス・マネジメントってどうしたら? みたいな悩みや迷い（&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1）は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました. スタッフエンジニア エンジニアのためのマネジメント入門 人が増えても速くならない 以上の3冊です. この3冊です（結論） スタッフエンジニア マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon エンジニアのためのマネジメント入門 作者:佐藤 大典技術評論社Amazon 人が増えても速くならない ～変化を抱擁せよ
漫画『ドリフターズ』5年ぶりの新刊 平野耕太による人気作最新7巻が発売
平野耕太さんによる漫画『ドリフターズ』最新7巻の予約受付が、Amazonや楽天ブックスなどで開始された。 8月10日（木）が発売日となっており、2018年11月に刊行された6巻以来約5年ぶり、待望の新刊発売となる。 平野耕太による人気漫画『ドリフターズ』 漫画『ドリフターズ』は、平野耕太さんが少年画報社の漫画誌『ヤングキングアワーズ』で不定期連載している作品。 異世界を舞台に、古今東西あらゆる時代から流れ着いた偉人たちが2つの陣営に分かれ、国盗り合戦を行う様を描いている。 登場するのは島津豊久、織田信長、那須与一、ハンニバル・バルカ、スキピオ・アフリカヌス、ジャンヌ・ダルク、ラスプーチンなど、世界の歴史に名を残す武将や戦略家、英雄、政治家たち。彼らはそれぞれ、平野耕太さんの手によって一癖も二癖もあるキャラクターに仕上げられている。 本作の魅力は、独特の陰影がはっきりとした絵柄、小気味よい台
どんよりマンネリした振り返りが、皆が主体的に発言してマンネリ化しないようになったプラクティス - Qiita
1. はじめに 私のチームでは2～4週間ごとに、チームの皆で良かった点や改善点を挙げてチームを少しずつ改善していく「振り返り」をしています。 ただ、チームの振り返りにて、経験の多いメンバーが多く発言し、若いメンバーがあまり発言しないという事はないでしょうか？ 過去の私のチームはそうでした。 それを改善し、全員が発言しまくる振り返りができるようになっても、だんだん振り返りがマンネリ化してしまう事はないでしょうか？ 過去の私のチームはそうでした。 また、チームに問題がなく順調すぎて、振り返りで挙がる改善アクションが些細なものになってしまう事はないでしょうか？ 過去の私のチームはそうでした。 本稿は、その状態から脱却し、皆が主体的に発言するマンネリ化しない振り返りを実施し、新しいチャレンジをたくさんするようになったプラクティスを紹介します。 なお、前提として以降で紹介する振り返りはすべてリモート
Panda CSS - Chakra UI の Zero Runtime CSS フレームワーク
🐼 パンダが来た / Panda CSS Chakra UI から、新しい CSS フレームワークである Panda CSS がリリースされました。 2023 年 3 月に公開された Chakra UI の今後のロードマップに関するブログ内でもすでに言及されていましたが、今回それが正式にリリースされた形となります。 Panda CSS の特徴 リポジトリ内 README からの抜粋となりますが、次のような特徴があります。 ⚡️ Write style objects or style props, extract them at build time → Style 用のオブジェクトや Props を定義してビルドで抽出 ✨ Modern CSS output — cascade layers @layer, css variables and more → Cascade Layers
なぜ、スクラムが上手くいかない・しっくりこないと感じるのか考えてみよう | IIJ Engineers Blog
なぜ、スクラムが上手くいかない・しっくりこないと感じるのか考えてみよう 2023年06月20日 火曜日 どうも名古屋支社の北河です。 今回はスクラムの “ちょっと” した感じ方について取り上げていきたいと思います。 スクラムを実践している方はスクラムガイドを一度は読んだことがあるかと思います。読んでみると、軽量級やシンプルといったキーワードが目に入ってきます。 そしていざスクラムを実践し始めるとこんな声を聴きます。 「う～ん、難しい。上手くいかない」「なんかしっくりこない」「これで良いのかな？」と。 ということで、なぜ上手くいかないと感じるのか、しっくりこないと感じるのか、を自分の解釈を交えて考えてみたいと思います。 スクラムとは アジャイルの価値や原則を満たすプラクティスを組み合わせたフレームワークの一つです。 アジャイルとスクラムを混同していたり、違いって何？というケースを見かけますが
スクラムでの見積もり - Qiita
はじめに スクラムでの見積もりは意外とさらっと書かれている事が多く、作業見積もりと規模見積もりがごちゃごちゃの状態でスクラムを進めていた結果、チームの中で見積もりに対する不信感が強くなり「このままではいけない」と感じたため、まとめました。 また、似たような記事があまりネット上で見かけなかったため、ここにざっくりと分かるように集約しました。ぜひ、自分のようにごちゃごちゃになってしまっている方に届けば嬉しいです。 まず何のために見積もるか アジャイルのチームにとって、作業を見積もることは、良い予測を追求しようとするだけではありません。チームが要求を深く理解し、開始する前に何を構築しようとしているのかをより深く考え、一定時間内にチームで協調して取り組むことで、構築しているものに対して大きな価値を生み出すことを促します。 (アジャイルメトリクス p40より) 見積もりによってプロジェクトの状態が見
プロダクトオーナーの考えるべきところ - kawaguti’s diary
プロダクトオーナー(PO)の考えるべきところ、もしくは「はまりがちな罠」について、いくつかのトピックを思いつくまま書き出してみました。悩めるPOさんの手助けになれば幸いです。 序盤戦、中盤戦、終盤戦の戦略 一番美味しいアイデアがでる可能性に備えるために 引き継ぎにはコストがかかるので人を追加すると遅くなる システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない あ、よければアギレルゴの認定スクラムプロダクトオーナー研修もご検討ください。著名な講師が通訳付きで教えてくれます。 1. 序盤戦、中盤戦、終盤戦の戦略 「序盤で基礎を作って、作るスピードが上がってきたら、重要なところを作り、最後はウリになるものを作りこんでリリースする。」一見、良さそうに見える戦略ですが、これは結構危うい計画になりがちです。ユ
「終わらなかったから次のスプリントにまわそう」なんてありえない
イテレーション・スプリントを使ってはじめて開発するチームがよく直面するのが、スプリントで仕事が終わらない問題です。はじめはそういう時期があってもいいですが、慢性的にこれが続くとなると、注意が必要です。 仕事を終わらせるために 仕事というものは、はじめるときに終わりを定義するものです。しかし、ソフトウェア開発の場合、予想外のことが結構起こります。 予想以上に仕様が複雑になった 予想以上に調査に時間がかかった 予想以上にはまってしまった これはどうしようもない要素なので、アジャイル開発において仕事が終わらない場合は、 予想以上に時間がかかりそうだから、スコープを減らして期限内で終わらせられるようにする 予想以上に時間がかかりそうだから、リリースから外して次のリリースに回す 予想以上に時間がかかりそうだから、チームメンバーに手伝ってもらってかたずける というように、終わらないと気がついた時点で調
意識の問題にしない
みなさんこんにちは。@ryuzeeです。 今日はTwitter経由で頂いた質問に回答したいと思います。 質問は以下になります。 スプリントで『自分が最初に取り組むプロダクトバックログアイテム（PBI）を終わらせば自分の仕事は終わり』という意識のメンバーが多いです。そのため、PBI每に担当を決めて複数のPBIを並列で進めているのですが、インクリメントが0になる可能性があるのでできればやめたいと思っています。スプリントプランニングで決まったPBIすべてをチームで協力して終わらせるという意識に変えるためにはどうしたらよいでしょうか？ 例えば、AさんとBさんとCさんが最初にPBI-1をやる場合、スプリントでPBI-1を終わらせればよい、PBI-2とPBI-3は自分たちのタスクではないという意識になってしまっているという感じです。 ということで考えていきましょう。 スプリントでの開発者の仕事は何か？
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node.jsやめる(Rustにする？) · Issue #11078 · misskey-dev/misskey
TypeScriptの「Result型」のすゝめ
フロントエンドリアーキテクトの話
User Story Mapping - Scrum Niigata
