いただきましたー！わーい。脳に収めるぞー！ @haradakiro @ryuzee pic.twitter.com/3Qd6EvPioU— SHIIBA Mitsuyuki (@bufferings) June 13, 2024 明日（2024年6月18日）発売！ www.oreilly.co.jp どう書くのがいいんだろうなぁ？ 複雑なコードと向き合うときは「あー、これはメモを取りながら読まないと迷子になるやつだ」ってなる。最初はわりとキレイに作られていたとしても、機能追加を重ねていくとだんだん読めなくなっていく。 だから「時間が経っても読みやすいコードってどう書くのがいいんだろうなぁ？何かヒントがあるかなぁ？」って思いながらこの本を開いた。先に書いておくと、ヒントはあった。 アウトサイドインのTDD 全然予想してなかったから、おー！と思ったのが、説明をTDDで進めていくってところ。好き

最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから

昨日、ゆのんさん（ https://twitter.com/yunon_phys ）が社内の勉強会で「エンジニアリングマネージャとは？」って話をしてくれて、面白いなぁって思いながら聞いてた。 今日は @yunon_phys が社内勉強会で、エンジニアリングマネージャについてお話をしてくれてとてもよかった。こんな話が社内で聞けるのって福利厚生だなぁと思いながら聞いてた。— SHIIBA Mitsuyuki (@bufferings) October 13, 2023 その中で「エンジニアリングマネージャが見ることのできる範囲はめちゃ広いから、すべてを完璧にしようとするんじゃなくて、その場に応じてスキマを埋めるような動きができるといい。組織の成長とともにその動きも変わっていく」ってことを言っていて、これって自分のソフトウェアエンジニアとしての動きにも似たところがあるなぁと思ったので雑にメモ。

コードを書く仕事をしてると、読むことも多い。読んでる時間のほうが多いかもしれない。いま書かれてるコードを読むことも、もちろん多いし、何年も前に書かれたコードを読む機会も割とよくある。 コードを読むと、そのコードを書いた人の考えや、そのときの状況が感じられて、おもしろい。特に、何年も前に書かれたコードを読むときは、コーヒーを片手に（そのときはこんな感じだったんだろうなぁ）って想像しながら読んで楽しい。 ふと、どういうコードから、自分がどういうことを想像するのかを書いてみようと思った。 前提 今、目の前で書かれているコードを読んでレビューしてるときの話じゃなくて、何年も前に書かれたコードを読むときの話をしようと思う。だから、そのコードが良いとか良くないとか、こうするべき「だった」とかは考えない。今後の自分がどう書きたいかなぁ？くらい。 また、そのコードを書いた人が良いとか良くないとかでもない。

株式会社カケハシに入社しました https://www.kakehashi.life/

しばらくしたら次のことを考えたいなと思ってるので、よい仕事や空いてるポジションがあったら教えてください！— Mitz Shiiba@フルスタックエンジニア (@bufferings) December 8, 2022 突然ですが CircleCI を辞めることになりました。そのことについてあまり話すつもりはないのですが、今の気持ちだけ書いておくと、びっくりはしたけど特にネガティブな感情はなく、面白い経験だなぁという気持ちです。 この一年間、色々とあまりできない体験をしてきた締めくくりにピッタリです。この状況を受け入れて、流れに身をまかせて楽しもうと思います。 ということで、こんな機会はあまりないので、次をどうするか、折角だから色々な会社のお話を聞いてから考えたいなぁと思ってつぶやいたら、たくさんのご連絡をいただき、とても嬉しく思っています。ひとつひとつのお誘いや励ましが、とてもありがたいで

観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは

1年 CircleCI に入って来月で1年になる。あっというまだなぁ。 色々と面白いことが転がってるので全然飽きないし、スキルが高ければ高いほどその面白いものをもっと拾えるので、どんどんスキルアップしていきたい気持ち。 仕事のやり方を忘れようとしてる その一方で、いま僕は仕事のやり方を忘れようとしてる。これまでずっとやってきた自分の仕事のやり方をいちど忘れてみようと思っているのだ。もっと肩の力を抜いて、リラックスした気持ちで仕事をしてみたい。がんばらないように。 のだけど、これが思ってたより難しい。 つい、がんばってしまう。がんばる方がラクだと思ってしまう。そっちの方がラクならがんばったらいいやん。って思うかもしれないけど。せっかくなので違う働き方に挑戦してみたい。どんな景色が見えるんだろう？ということに興味がある。 過程より結果 今のチームでは、いちばん大切なこととして「プライベートを第

とても雑記 個人の成長は必須かなぁ？ よーはつのツイートを見て、古川さんのスライドを見て、「グループや会社は成長して欲しいなぁって思うけど、個人の成長はどうなんだろう？僕は『今、自分が持ってるチカラで会社の成長を支える』ぐらいがいいなぁ」みたいなことをぼやーっと考えた ここ数年、こういう組織の支援もやっているけど、ほんとに難しい… 開発組織の持続可能性について https://t.co/8HpulzqngQ pic.twitter.com/Jx9LFuH0p2— yoh nakamura (@yohhatu) July 12, 2022 意識低い 最近の自分は「成長しなきゃ！」「そして自分の成長で会社の成長を支えなきゃ！」みたいなのはあんまりなくて、意識は低い方かなぁと思う。「それはそれ、これはこれ」な気持ち 単純に、新しいことを学ぶのは楽しいし、昨日できなかったことが今日できるようになる

こんばんは。しーばです。この記事は Calendar for CircleCI Advent Calendar 2021 | Advent Calendar 2021 - Qiita の17日目の記事です。ほんとは明日に書くつもりだったけど、空いてたから今日書くことにした。 16日目は、ふなっきーの 緑(Succeed)と赤(Failed)を区別する - よりinclusiveなCircleCIを目指して - Qiita でした。なんか Failed の色が変わったなぁって思ってたら、カラーユニバーサルデザインに対する取り組みで、僕は全然詳しくなかったんですけど、そういう取り組みをしてるのって良いなって思いました。 さて、今日は CircleCI の Year End Party で東京に来てました。 オフィスに来たらヒューガルデンが無限に出てくる pic.twitter.com/k7OO

そんむーさんのこの記事を読んで、すごいなぁかっこいいなぁって思って、そういえば僕も41歳だーって思ったので、書くことにした。軽い気持ちで書き始めたら思っていたよりもとても考え込んでしまった。 songmu.jp CircleCI に入社しました 11年勤めた楽天を離れて CircleCI に入社しました。先週の月曜日の10月18日から Senior Full Stack Engineer として仕事をしてます。大阪の自宅からフルリモートです。 寒くなってきたからちょうど良かったー！ https://t.co/td9lks2qVS pic.twitter.com/9AW6X8CPgH— Mitsuyuki Shiiba (@bufferings) October 20, 2021 次の挑戦をするのに、ちょうどいい時期かなぁ ここ数年は、色んなチームのサポートをするエンジニアをやってました。テ

社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて

Gitの基本的な使い方のおさらいをチームのLearning Sessionでやろうかなと思ってドキュメントを眺めてたら、あれ？こんなんあったっけ？と思うコマンドがあった。 git restore と git switch Git 2.23で導入されたみたい。去年の夏か。 https://github.blog/2019-08-16-highlights-from-git-2-23/ まだExperimentalみたいだけど、面白そうなので触ってみた。今日は git restore の話。git switch はまた気が向いたら。 https://git-scm.com/docs/git-restore ## リストアの前にWorking Treeとかの話をざっくり GitにはWorking TreeとStaging AreaとGit Directoryという3つの場所がある。 file.t

AよりB、CよりD 今後の方向性を決める判断の中で「Aという技術ではなくBを採用する方がが良さそうです」とか「既存システムのCは良くないからやめてDを使うようにしましょう」とか。最近、何人か全然別の人からそういう話を聞く機会があった。 AよりBが良さそう？ 「僕はAの方が良いと思うんですけど、Bの方が良さそうだと思う理由を知りたいです」って聞くと「Aはこういう部分に問題があると思います」って言われて話が噛み合わなくて、しばらく話をして気づいた。 この人、Aを触らずに想像だけで喋ってるんだ。ってことに。なので、実際に動かして見せてあげると「あぁ、それならAの方が良いですね」ってなった。 「興味があるだけなんですけど、僕も知らない技術だったので少しドキュメントを読んで実際に触ってみて機能を確認してからAの方が良いなと思ったのですが、どうして触らずに想像だけでAは問題があるって断言したんですか？

最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは

開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの

最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク

今日は娘たちとコログ探しして楽しかった。 この数年間、頭の中にTDDを入れた状態で開発をしてきたんだけど。タイトルに書いた風に思う。 良い所がいっぱいある 見失わずに済む 僕にとってTDDの良さは、まず、自分が何をしようとしているかを見失わずに済むところ。一歩先にゴールを立てて、そこに向かって一歩進む、たどり着いたら、次の一歩を進める。その繰り返し。だから、遠く離れたゴールに対して、急いで走って、途中で道に迷ってどこに向かってるか分かんなくなったりしないで済む。 余計なものを作らなくて済む 「必要なものはこれだよね？」という確認から入って、それを実現するための実装に集中するから余計なものを作らなくて済む。実装を先に作ると「こういう機能もあるといいかもだから入れとこうかな」ってついつい入れてしまう。 リファクタリングできる まず最初に動くものを作ってから、その状態をキープしたまま、実装の改善

先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ

僕はWebサービス開発会社のエンジニアなんだけども。 雑用は新人にお願いするんじゃなくて、上司がやると良さそう。だよなって思ってる。 会議の設定とか、飲み会の幹事とか、会議の資料作りとか、そういうの。 そうすると、良さそうのは。 上司は新人より組織に関して色んなことができるので、無駄なものをなくしたり、効率化したりできそう。 本当に必要なものだけが残って、で「それを自分がやるのは時間がもったいない！誰かを雇ったとしても結局その方が得だ！」ってなるとプログラムを書くために入社した人じゃなくて、誰かそういうことをやる人を雇うことができそう。 「出世したら雑用は部下にやらせよう！」じゃなくて「遂に雑用ができるまで偉くなったか！」ってなると雑用が尊いものになりそう。 雑用から学ぶ？ よく「雑用から学ぶのだ！」って話を聞くんだけど、そんな遠回しなことせずに「こういう場合はこうするんだよ」って仕事の中