うれしかった。ので、メモ。 僕のいるチームのプロジェクトで、複数のチームにサポートしてもらいながら進める必要がある、ちょっと大きなものが始まりそうだったから、キックオフ前のキックオフやっとこかーってなって司会をした。オンラインミーティングね。 最初にこの会の目的を説明 今日のアジェンダのページのリンクは事前に共有もしていましたけど、いまSlackにもポストしておきましたー。 まだプロジェクトは始まってないんだけど、事前に調査とかをしたいから質問や相談をさせてもらいたいなと思っていて、そのときに「え？これなんの話？」って戸惑わせることがないように、プロジェクトの概要を共有しとこうと思ったー！だから、この会がうまくいったら、僕らが質問してもみなさんが戸惑わないようになっている！ Bさん、Slackにメモ残してってください。お願いしまーす！ からの、会の流れを説明 最初にPdMから10分くらいで

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

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

TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている

を書いてみる気分 今日の時点での自分のやり方なので、またしばらくすると変わってるかもしれない 僕には、最初に考えたとおりに実装できるようなスキルがないので コードを書きながら形にしていく感じ サイズ だいたい、チケット一枚が、5,6時間で実装できるくらいのサイズになってる 2,3日くらいでレビューまで終わって本番にデプロイすることが多いかな （基本的にはそれくらいってだけで、1,2週間くらいかかるような長いやつもある） 技術的なフィージビリティチェックとかはこの前に終わってる 実装を頭に思い浮かべる こんなふうにすれば良さそうかなぁ このあたりは何パターンか考えられるけどどっちがいいかなぁ とか頭の中に思い浮かべる とりあえず動くものを実装 まずは思い浮かべたものが全部つながって動くかをサクッと確認したいので雑に実装する そして、気づくことがいくつかある あれ？この場合どうなるんだろう？っ

ちょっと前にツイッターで見かけた、ゆめみのフロントエンドコーディング試験 フロントエンドコーディング試験 「RESAS API を使用して、都道府県別の総人口推移グラフを表示するSPAを作る」っていうお題 React の勉強をするのにちょうどいい題材だなぁって思ったのでやってみた。課題を公開してるってことは「やってみてもいいよ」ってことかなと思ってるんだけど、もし違ったら GitHub のリポジトリーを private にするので連絡ください 1週間でやらないといけないところを2ヶ月近くやってるし、コミットログも特に何も考えずにポイポイ書いたから、全然だめなんだけど、でも、色々勉強になったので、とてもよかった。楽しかったー！ つくったもの こんな感じ これでおわりにするー pic.twitter.com/K8zhrRUp54— Mitsuyuki Shiiba (@bufferings)

「スクラムフレームワークを使用する具体的な方法。僕の場合。」というタイトルでスクラムフェス大阪で発表してきました。楽しかった。今回のは説明がある方がいいかなーと思ったので、スライドをアップロードするんじゃなくてここで紹介してみることにする。長くなりそうなので、今日は前編。 ## TL;DR 計画を持った開発のサイクルと、それとは異なる周波数の様々なイベントを、どううまく組み合わせて開発を進めるか。それを、自分の現場で自分の仲間と探していく道のり。 ## 全体像 左上が「1. チーム」、左下が「2. スプリントの内側」、右半分が「3. スプリントの外側」。この3つを紹介。正解やオススメというわけではなくて、自分たちの現場ではこういうやり方をしている、という紹介。 ## 1. チーム ビジネス・デザイン・開発の3つの組織に分かれている。そんな中で、どんな風に協力しながら開発を進めているか。 #

## 去年の夏ぐらいからサポートしているチーム で、それまでもちょこちょこモブプログラミングを試してはいたんだけど、3月からは思い切ってそれを基本として開発をするようにした。つまり、3月からは1日中モブプログラミングをするのを毎日やってる。 プログラミングだけじゃなくて、設計も、運用も、テストも、全部モブでやってるので、僕らはそれをモブワークと呼んでる。 ## やっていく中で学んだのは モブプログラミング（モブワーク）は「全員でプログラミングをする」ということではなくて「全員で考えて取り組む」というだけのことだった。 サービスにとってどう動くのが良いかを全員で考える。 目の前のプロジェクトのことだけではなく、少し先を見据えてメンバー間の知識やスキルの共有や、チームがまだ詳しくない分野の学習をすることも含めて、どこにトレードオフスライダーをセットするのが良いかを全員で考える。 ## 全員でプ

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

## 今週は全員同席モブワーク 先週はこういうことを大阪からのリモートでやってた： bufferings.hatenablog.com 今週は東京に出張だったので、僕も入れて4人で全員同席のモブワークを実験してみた。そしたら、沢山の学びがあった。 ## 実験：モブワークが日常な場 今回のモブワークで実験してみたかったのは、モブワークが日常な場。つまり、チームにとってモブワークをすることが普通で、それ以外が非日常な場。 これまでもモブワークはしたことがあったのだけど、モブワークをすることは非日常なことだった。普通はペアで仕事をしていて、たまに「ちょっとモブワークしてみようか？」って言って、特別に集まってたのだ。 そうじゃなくて、モブワークを自然な状態にして、たまに「ちょっと別々に動いてみようか」みたいにすることができたら、ちょっと感じ方が違うんじゃないか？という気がしていた。なので、チームに