エンジニアからマネージャになったときにあるだろうなぁってことを想像して遊ぶ - Mitsuyuki.Shiiba
ソフトウェアエンジニアの話ね。想像して遊んでるだけね。 スキルは高い まず、マネージャになってほしいって言われる時点で「仕事を任せられる」というエンジニアなんだろうな。それは、つまりコードを書くことに加えて、プロダクトをなんとかしてリリースする力と責任感をもっていて、それが会社にとってプラスになっている。 だから、チームを任せて同じようなエンジニアを育てて欲しいと期待されている。自分自身も、自分のスキルをもっと会社の役に立てるぞー！とやる気になっている。 任せたい そういう人がマネージャになって、あるだろうなぁと思うのは「どう任せたらいいんだろう？」という悩み。 自分が手を動かせばプロジェクトがなんとかなるのは分かっている。でも、自分はマネージャの仕事があるし、そこは自分の役割ではないし、実際のところ手を動かす時間なんてない。それはメンバーにやってもらわないといけない。 ただ、だいたいの場
こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから
npm install と npm ci って結局どう使うの？2023年版 - Mitsuyuki.Shiiba
うりうりさんの↓のコメントを見て、そういえばnpm ciって見たことあるけどチェックしてないなぁ。というかnpm installも雰囲気で使ってるなぁ。と思ったので、うりうりさんに教えてもらったことを手がかりに、npm installとnpm ciについて調べた。 これ、node_modulesキャッシュしてたり npm install使ってるけど npmのグローバルキャッシュ(~/.npm)をキャッシュした上で npm ciで早くなったりしないんだろうか GitHub Actions上でテストを約3倍早くした話https://t.co/MpmFktGBxU— wreulicke (@wreulicke) March 14, 2023 ちょこっと検索して見てみたところ、新旧情報があって自分が混乱したのと、公式ドキュメントには概要は書かれているものの詳しい内容は書かれていないので（僕が見つけ
npm installとnpm ciの動作確認を簡単にやっておいた - Mitsuyuki.Shiiba
先週、npm installとnpm ciについて調べて考えたことを書いたのだけど、ドキュメントを読んで、頭の中で考えたことをまとめただけなので、これだけだとちょっと気持ち悪いなと思って。簡単ではあるけど実際の動作を確認することにした。 bufferings.hatenablog.com 結果 だいたい想像どおりだった。今回のサンプルプロジェクトで実験した結果は次のとおり。 (1)と(2)は、キャッシュがない場合のnpm ciとnpm installの速さ。想像では「npm ciの方が多少速いのかな？」と考えていたけどほぼ同じだった。node_modulesがない状態から始まるので、npm ciはnpm_modulesを削除する必要がない。一方で、npm installも既存のnode_modulesをチェックする必要がなくて、package.jsonとpackage-lock.jsonの
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
スクラムで開発するときに大変なところをぼやーっと - Mitsuyuki.Shiiba
ぼやーっと書いてみようと思ったら、ほんとにぼやーっとした感じになってしまった。まいっか。 いい感じのスクラム？ バックログアイテムが小さく作られてて内容が明確で スプリントの途中で差し込みもなくて開発者たちは開発に集中できて 他のチームとの依存はなくてすべての開発がチームの中だけで完結する。 そういう状況だと、まぁ、なんかいい感じに開発できるんだろうなぁと思ったりする。 実際は？ (1) バックログアイテムを準備するのがまず大変。 (2) それから、サービスを運用しているので突然の依頼や問い合わせみたいな差し込みはあるし。 (3) 他のチームとの依存もある。 (1) バックログアイテムの準備が大変 バックログアイテムの準備のときには、プロダクトマネージャーが色んなステークホルダーと調整したり、ビジネスチームやデザインチームと相談したりしつつ、もちろん開発者たちの意見を聞いたりもする。 「開
実験によってチームのやり方として定着してきたものを6個 - Mitsuyuki.Shiiba
この2ヶ月ぐらいサポートしてるチームで、実験を重ねる中でチームのやり方として定着してきたものがあるので、温かいうちに書いとく。6個ある。 背景 どういう背景かを簡単に： エンジニア4人とリーダー1人、プロデューサーが2人のチーム。全員家からリモートでつないでる。 サポートに入る前はチームは計画重視の指示型開発で全員別々の作業をアサインされて取り組んでいた そこに「自己組織化チームにしたいけどそういう経験者もいないしプロジェクトも忙しい中なのでサポートしてほしい」と声をかけてもらって参加 2週間くらい観察して色々周りを整えたあとにチームに入って、スクラムを導入して1週間スプリントを6回終えたところ 自分はリーダーの代わりに入らせてもらうことにした。まずはチームのやり方を色々変えてしまって、チームが落ち着いてきたら徐々にリーダーと一緒にそのリーダーならではの道を探して、最終的にはそのリーダーに
JMH(Java Microbenchmark Harness)のサンプルを動かしながら勉強 - Mitsuyuki.Shiiba
先月末に開催されたSpringOne Platform 2018の録画がもうアップされてて、ちょこっとずつ見てってるんだけど、何日か前にDaveのセッションを見た。面白かった。 How Fast is Spring? - YouTube Springアプリの起動スピードについてのセッション。で、その起動スピードを自分でも確認したいなーと思ったんだけど、DaveがベンチマークのツールとしてOpenJDKのJMHというものを使ってるので、まずはそれを知らなきゃなと思って触ってみた。 OpenJDK: jmh ## Hello JMH JMHのサイトに書いてある通り、プロジェクトを作って $ mvn archetype:generate \ -DinteractiveMode=false \ -DarchetypeGroupId=org.openjdk.jmh \ -DarchetypeArti
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
