天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

アジャイルザムライ矢田のペアプロ100人斬り【aki.mさんとTDD対決】のふりかえり

creationline.connpass.com

こちらのイベントでコードを書いてきたので、そのふりかえりです。

イベント前

一度だけ簡単に打ち合わせをしましたが、何もしていませんでした笑

今回は、「ライブ感をすごく大切にしたい」「その場でお題に向かって対決形式でコードをペアプロして欲しい」というオーダーをいただいていたので、事前にこんな風にやるとうまくいきそうとかはまるで考えないようにしてほしいという話もあったので、本当に何もしていませんでした。

イベント中

開始直後

会が始まってTDDというコンセプトの説明があったとき、「あれ、そういえばそうなんだっけ?」と思いました。
また、勝敗の観点説明があったときにドライバー/ナビゲーターの観点があって、「普段ペアプロしているときの様子を見せるイベントなんだっけ?」となり、どういう風にやればいいんだっけ?と混乱しだしました。

そこで、矢田さんとどういう風にやるのかのイメージがズレていると嫌だな、イベントのゴールみたいなものを設定したほうが良さそうだな、と思いとりあえずUIやコンソールなどで動くようなものを作るところを目指しましょう、と提案したのを覚えています。

いよいよ始まるんだな、ということでワクワクしていました。

1サイクル目

矢田さんが「先攻で」といったとき、個人的に先攻はナビゲーターのイメージがあったのですが、ドライバーを選択されていて、少しだけ驚きました。
その後、ドライバーの矢田さんが結構がんがん主導して実装されていたので、もともとのコンセプト通り対決を意識してガンガン実装しているのかな?という気持ちと、「先攻で」の発言で少し驚いたことをトリガーに、もしかしてドライバーとナビゲーターを逆にイメージしている?でもそんなことを声に出したらもし違った場合失礼だよな...?*1と思って、コードにはあんまり集中できず、どんな感じで振る舞うといいのかを悩んでいました。

2サイクル目

1サイクル目で自分がイメージしていたところの半分くらいの進捗だったので、時間的にガンガンいかないとまずいよなーという思いが出ていました。
また、自分がドライバーになって久しぶりにコードを人前で書くのでかなり緊張していたのと、Javaを全然書いていなかったこともあってIDEのショートカットを全然覚えていなかったので矢田さんに比べると操作が大分遅くなってしまいそうな気がして心配していました。

ただ、実際コードをIDEに入力してみると、なんともいえない幸せな感覚があったのと自分が初めて触った言語がJavaでそれを久しぶりに書いていることがすごく楽しくなって、イベントであることを忘れるくらい没頭した感覚がありました。

時間も一番あっという間に過ぎました。

3サイクル目

時間を見て、これはもともとイメージしていた動くものに行くまでには距離がありそうだと思ったのと、このまま行くと普通に負けそうだとなんとなく思ったのと、どうも目の前の実装と自分が頭に描いていた実装の乖離が激しそうだと思ったのとで、ガンガン実装をしていきました。

自分の中では割と変更の仕方に自信があったのですが、目の前の実装と自分が頭に描いていた実装の乖離が激しかったこともあってうまくナビゲートができず、矢田さんに申し訳なかったなあと思いました。

4サイクル目

3サイクル目の反省を踏まえたのと、時間的にUIやコンソールで動くものを作るのは無理だなあという想いが出たのとで、歩幅を狭めました。
一番教科書的にまともなサイクルだったのかな、とは思った一方で、もし業務で同じ状況だったらもっと歩幅を広げるなあと思ったこともあって、ちょっとイベント感を出しすぎたな、とは思っていました。

イベント後

現地参加者とふりかえり

みんなコメントを見て面白がっていたそうで、コメント欄を盛り上げてくださった皆さんには感謝しかないです。
また、あのまま実装するとどうなったか?もっといいモデルがあるんじゃないか?というのをみんなで議論していました。

その後は懇親会に行って、色々感想を聞きました。以下、出ていた印象的な感想を挙げていきます。

  • イベントのコンセプト通り本当の意味でのライブ感がすごかった
  • TDDをしたかったんだっけ?というのがあった。実際TDDしていなかった
  • コードを書くイベントは本当に尊いと思った。それもリアルに書いているからすごいよかった
  • 自分ならどうするんだろう?と考えながら見れて面白かった
  • よくあるお題とかではないのに、ぶっつけ本番で当事者としてコードを書いていたのがよかった
  • 対決する必要ないのでは?と思った。ペアプロなのに対決って変な感じでは?
  • お題が1時間にしてはあまりにも難しすぎたように感じた
  • もうちょいモデリングとかしてから望んだほうが良かったのでは?と思った

帰宅

久しぶりにコードを緊張感が適度にある場面でかけて良かったなあと思いましたし、帰りの電車の中でも改めて最初から自分一人ならどういうコードを書くかな?と考えながら実際にコードを書いたりしていました。

もっと良いコードを書きたいな、もっと上手にプログラミングとか設計をしたいな、あの人ならどうしていたんだろう?とかがすごい頭を巡っていて、すごい久々に心に火がついたような感覚がありました。
最近は実はもうエンジニアとしての仕事は無理なのかなあとか思う場面があったり、コードを毎日書く習慣がやや惰性気味になっていて、技術的な自習はコンフォートゾーンに閉じこもった学習が増えていたのですが、エンジニアとして仕事をしていたときの感覚がすごい思い出されたし、大変なことはたくさんあったけれどあのときは楽しかったな、という記憶もすごい鮮明に蘇ってきたので、個人的には一番このイベントで収穫が得られたポイントでした。

*1:実際勘違いはしていなくて、普段業務でやっている、守破離の離によっているペアプロスタイルを実践されていたそうです

Ask Me Anything! t-wadaさんに何でも聞いてみよう!に参加してきた

Ask Me Anything! t-wadaさんに何でも聞いてみよう! - connpass

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

タイトルの通り、t-wadaさんが視聴者から寄せられる質問に対して何でも答えてくれるというイベントです。

会の様子

タイトルの通りひたすら質問に答えてくれるイベントだったので、以下に質問と回答を箇条書きで記載していきます。

仕事関連の情報を仕入れるときどのメディアを利用しているか?情報収集にどれくらいの時間をかけているのか?

Web、本、Podcast、Xのリストなど。隙間時間で情報収集することが多い。本屋に行って背表紙を見ることが多い。Misreading ChatのPodcastは必ずチェックする。

misreading.chat

20代、30代にやっておけばよかったと後悔していることは?

運動習慣がつけられなかったこと

テストが過剰かのジャッジはどうしているのか?書かないほうがいいケースはあるか?

直感は大切にしている。また、個人的研究として、テストケースごとにカバレッジ機械的に見るようにしている。
テストケースは増やすのは簡単で減らすのは難しいので、テストに付帯情報をつけておくことが大切。

最近読んだ技術書で面白かったのは?

普段と違うトップダウンでの学びを経験できたので以下の書籍は面白かった。

www.oreilly.co.jp

上長や経営層に自動テストやリファクタリングなど外から見えにくい施策をどう提案するか?

開発速度という「時間」で表現する。

テスト周りで一番解くのが難しいと思っているテスト周りの課題は?

AI全盛の時代となり、AIをテストする難しさを実感している。

テストコードの書き方や品質に対する考え方に関して開発メンバー内で出ている差は勉強や経験以外だとどう解消するのか?

ドキュメント整備や手本となるテストコードの充実。「真似をしてください」を作り出す。

引用文献はどう選んでいるのか?引用文献を覚えているのか?

コンサルタントとして仕事していることもあり、印象をなんとなく覚えている。ただ、今後年齢を重ねると難しくなってくるような気もしており、対策は練らなくてはと思っている。

コーディング前のフェーズとしての設計書はどの粒度のものが最適だと思うか?

WhyやWhatに関する設計書が最適。
CSの歴史として、コーディングをしなくていいような何かをやることは失敗し続けているので、その点は注意。

テストが如何に大事なのかをどう伝えていくのか?

変更は何度もやる時代だという話をして、そのために何回もテストするしかないなら自動化したテストを作っていきましょうね、という話をする。

仕事がつまらなかったり腐りかけたときにどう克服したのか?

つまらないとかやりがいがないとかはない。ただ、打ちのめされた経験はあって、リーマンショックで案件が全部なくなったとかはあった。
その後は、自社製品を作ったり自分で根付けをするようにした。

また、いい肉をゆっくり焼いてゆっくり食べることを良くしている。

今課金しているAIサービスは?

Gemini, GitHub Copilot, Copilot Chat, ChatGPT

自動テストを導入する際にまずどこから着手するとよいか?アクション単位の結合テストを考えている

テストコードがないと想定しているなら、動作が安定していて不確実さがないところからテストしていくのがおすすめなので、中の実装に強く依存していないことを考えると良い案だと思う。

テストカバレッジの計測は基本的にやったほうがいいのか?

基本的にやったほうがいい。ただ、評価に使うのだけはやめてほしい。マネジメントにもし使うなら、傾きを見る。

子育てで忙しかったときにキャッチアップの工夫としてやっていたことは?

子育てのときは諦めていた。キャッチアップは致命的に遅れることはないので、割り切っていた。あとは時々早起きしたり耳だけのキャッチアップをしていた。

テストを書かない人を前にしたらどうなってしまうのか?

そういう人のために自分がいると思っているので、テストの書き方を教えたりペアプロする。

発表会形式の輪読会はつらいのだがどういう方法が読書会としては良いのか?

負荷が重いので、3色コメント(引用、質問、コメント)でその場で読むような形式にしている。あとは定時中にやる。

テストを書かない人間に喝を入れて欲しい

喝をいれるキャラでは実はない。テストって楽をしたいから書くものなので、テストもさぼるために書きたいと思えるか。

保守性の高いコードを書くためにクラスは必須なのか?

違う。クラス指向に合わせてコードを書こうとするとどうしてもそういう発想になってしまうので注意。

GitHubでコードを探してみるといい。

技術的登壇で大事にしていることは?

聞いている人の明日を変えること。こんなことしたんですよ、だけを話さないようにしている。
実は登壇支援もすることが多いのだが、一番多くそこでする指摘が聞いている人の行動を変えるような内容にしよう、だったりもする。

会全体を通した感想

個人的には講演よりもQ&Aのほうが面白いなあと多くのイベントで思っているので、ひたすらQ&Aするイベントは最高でした。

テスト以外の質問も多くあって、その点でも良い意味で期待を裏切られたのでよかったです。

yr-learning Vol43に参加してきた

https://yr-camp.connpass.com/event/337996/

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
今日はたまたま矢田さんと二人だったので、昨日のイベントの感想戦をしていきました。

good

もともとイベントで一番でやりたいと思っていた、本当にその場でコードを書くみたいなところは達成できたよね、という話をしました。
また、シンプルにペアプロ*1ができて楽しかったし、勉強不足なところが見つかったりもっとプログラミングが上手になりたいなという刺激をもらえたりして、すごく良かったという話をしました。

bad

まず、イベントのお題目としてTDDを打ち出してしまったのは良くなかったという話をしました。もともとTDDをすることにはこだわりが全くなくて、前回リファクタリングという副題をつけたから今回はTDDみたいな副題つけとけばいいのかな?みたいなかなり雑な感じでつけてしまっていたので、それは良くなかったなという話をしました。
また、派生として、ペアプロに関しても人によって心地よいペアプロのイメージが違う可能性があるうえに皆が興味関心を持ちやすいテーマなので、参加者の人達が「ペアプロが上手くいっているのか?」「TDDができているのか?」みたいな観点に目がいってしまうと、求めていた「自分ならこういう実装するな」みたいな意見が出てきにくいんだろうなあというのを思いました。

次やるならどうするか?

次やるなら、もう少しテーマ設定とお題設定は考慮が必要そうだという話をしました。
難しすぎるお題は避けておいたほうが良さそうだという部分や、TDDみたいなところはタイトルなどであんまり押し出さない方がいいんだろうな、という話がありました。

recapイベント

recapイベントやる?という話をしました。
個人的には、きょんさんや葛飾の住人の方々に色々話が聞けたので熱が下がり気味になっているのですが、やっとむさんとKiroさんには是非話を聞いてみたいな、というモチベーションが二人ともあるので、やり方を考えたうえで検討はしていこうという話をしました。

*1:後述しますが人によってはあれはペアプロとして成立していないという人がいるであろうことは理解していますがそのうえでの話です

スクラム祭りの打ち合わせ(13回目)をしてきた

aki-m.hatenadiary.com

こちらの打ち合わせをしてきたので、会の様子と感想を書いていこうと思います。
今日はひたすらブログを作っていました。

バックログを作る

HPは前回仮で作ったものの、暫定的にざっくりと作ったものなので、修正したほうが良さそうな箇所を今日集まった人で20箇所くらい挙げました。
ただ、あんまり細かいところにこだわりすぎても良くないので、ここは直さないと公開した後に誤解などが生まれそう、というところを10個くらいに絞りました。

実行委員会を追加

今日参加していた正義さんと松下さんとkenzzzzzyさんを実行委員会メンバーに追加しました。
当初、実行委員のメンバーがほとんどいないんじゃないか?という懸念も挙がっていましたが、たくさんの方が協力してくれるということで、安心しました。
HPを直すついでに、開催趣意書も実行委員会の欄を修正しました。

スポンサー欄を追加

スポンサー欄を追加し、スポンサー募集Formsへの動線を作成しました。
また、スポンサーは開催趣意書を見たいよね、という話があり、開催趣意書へのリンクも(冒頭にはありますが)追加しました。

スケジュール最新化

keynoteをどこにするんだという話があるのでそこがまだ難しいのですが、一旦何時開始で何時終わりか?というのは決まっているので、スケジュールに反映させました。

keynote speakerのセクションを追加

keynote Speakerはスケジュールに反映させればいいんじゃないか?という話も出ていたのですが、どこでkeynoteをするのか?XP祭りkeynoteと被せるのか?という問題があるので、一旦セクションを追加することにしました。

(オンライン読書会) How People Learn Ⅱ 人はいかに学ぶのかに参加してきた

(オンライン読書会) How People Learn Ⅱ 人はいかに学ぶのか - connpass

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。(ただし後半(ジグソー活動以降)だけの参加でした)
書籍の内容の要約などにあたる部分は記録を省きます。

桃太郎電鉄の学習版ゲーム

www.nippon-foundation.or.jp

テクノロジーを活用した学習教材の一例として、桃太郎電鉄を学習版にアレンジしたものが紹介されていました。
貧乏神やスリの銀次というのが出てこないといった調整がされているそうですが、各地域に対して興味を持つという意味ではうってつけの教材なのかもしれないという話がありました。

生成AI

残念ながら今回の書籍では生成AIのupdateが間に合っていないのですが、対話型エージェントの話は生成AIが出てきた今だとだいぶ置き換えられているだろうな、という話が出ていました。
他にも、8章にあったライティングの評価システムの話に関しても、まさに生成AIが活用できるような領域だよね、という意見が出ていたり、インフォーマルな学習に関する研究の発展にも貢献できるんじゃないか?という話が出ていたりしました。

反転授業

反転授業に関しては効果があるとはいえ、会社で言えば残業が前提となってしまっているので、あまり個人的には好きではないという話がありました。

教育現場の変化

大学の話が途端に増えてきたのは、教育工学系の人が適切なサンプルを用意してテクノロジーを活用できるからこそなのではないか?という話が出ていました。

学習障害の定義

心的プロセスに閉じられた整理がされていましたが、ディスレクシアなどは学習障害としては定義されないのか?という話や、障害が個人の能力の問題として読み取られかねない介入方法が記載されていることが疑問として挙げられていました。

テレビと学習

テレビなどを小さい子供に見せすぎてしまうのは良くないという話が出ていましたが、これはなんでなのか?という話が挙がっていました。
ソースは不明ですが、小さすぎる画面を見ると学習能力に影響が出るという話が出ていたという話を教えてもらいました。

全体を通した感想

後半だけの参加になってしまいましたが、それだけでも今回の書籍の全体的な話の流れだったり、書かれていた研究の内容がざっとわかるので、議論とかを目的とせずに書籍がどんな感じなのかを大まかに把握したいという目的であれば、こういった参加の仕方もありなのかなあと感じました。

スクラムフェス金沢2025の打ち合わせ(2回目)に参加してきた

aki-m.hatenadiary.com

スクラムフェス金沢2025に向けた準備をしてきたので、会の様子と感想を書いていこうと思います。

keynote候補を考える

前回に引き続きまずはkeynoteの候補を考えていきました。

まずは、誰かを具体的にきめるというよりは、特集記事や著書の要約だったり、金沢とどういうゆかりがあるのか?アジャイル開発やソフトウェア開発とどのような形で結びつくのか?みたいな話をしたりしながら、keynoteに呼ばせてもらうとしたらどんな雰囲気になるのかをイメージしたり議論をしたりしていきました。

次に、前回話した合計6人くらいの候補の方々と合わせて、どの方に話を聞けると面白そうか?というのを今日いるメンバーで投票しました。
ただし、今日いないメンバーもいますし、投票で決めていきなり「keynoteをお願いします!」というのもあれなので、一旦どんな話をしてもらえそうかを簡単にふりかえってそれがスクラムフェス金沢とマッチするか?みたいなところももう一度話してから決めたほうが良いのかな?という話をしていきました。

今後の日程確認

一応まだプレ実行委員という段階なので、年内はもう一回だけやりつつ、そこでkeynoteとかの目線合わせとかをしながら、年が明けてからは曜日を固定して基本的には毎週集まって色々と議論をしていくというのがいいんじゃないか?という話をしました。

全体を通した感想

基本的には金沢にゆかりのある方を選んでいったのですが、どの方の話も聞きたくなるような話ばかりで、これだけ地元にゆかりがある方が多いというのは面白いなあと思いながら話をしていました。

会場が抑えられてから本格的に動き出せると思いますが、当日が楽しみです。

実践DevOps! 〜KAGとkubellの取り組み〜に参加してきた

chatwork.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

実践DevOpsというタイトルにちなんで、開発運用の実践事例にまつわる発表を聞いていくイベントです。

会の様子

Self-hosted runnersでAWSコスト削減?

まずは古屋さんから話がありました。
Github ActionsをCIに組み込んでいるKubellさんですが、Push/Pullそれぞれで料金が課金されてしまうが故にAmazon ECRが高いことに課題を抱えているそうで、ワークロードに近いところで動かす(=EKSのpodとしてrunnersをActions Runner Controllerを活用して動かす)ようにしたということでした。

結果的に、ECRの通信費用とGitHub Actionsの料金が減ってEC2の料金が増え、コストは削減できたということでした。

スクラムチームのDevOpsを支えるプラットフォームエンジニアリング

続いてShimokawaさんから発表がありました。

KAGさんではGHESの管理やクラウド環境のコスト最適化やIdP運用管理、セキュリティ改善、スクラムチームへのヒアリングなどに取り組んでいるそうで、プラットフォームとしてはGitHub Enterprise Organizationを活用しているということです。

具体的なサービスとしては、

  • GuardDutyの検出結果をBedrockでわかりやすく通知
  • GHEのSelf-hosted Runnerをマネージドで展開
  • NAT Gatewayを定期的に作成/削除してコスト削減
  • Security Hubからの通知をSlackへ自動送信

といったサービスを展開しているそうです。
サービス展開の際にはインナーソースを活用することで社内全体でツールやナレッジを共有して蓄積しているということで、今後は効果測定や自発的参加を促すコミュニティ作りを目指しているというお話でした。

EKSとArgoRolloutで実現するChatworksの新リリースプロセス

続いて桝谷さんから話がありました。

Chatworksでは数百台のPodが起動しているため、すべてのPodが入れ替わるまでにかなり時間がかかってしまうということで、カナリアリリースをする気軽にするためにArgo Rolloutsを導入することにしたそうです。

具体的なステップとしては、

  • Argo Rolloutsのinstall
  • Deployment -> Rolloutに移行(Rolloutリソースを作ってからDeploymentのHPAを停止)
  • 開発者に対してチャットや定例で周知&デモの実施

という流れで進めたということです。

今後はさらなる進化として、StepのOn/offをArgoCDのダッシュボード上でできるようにするとともに、Datadogと連携させることを検討しているということでした。

運用監視設計をするときに考えること

最後にKitauraさんから話がありました。

システム開発は、

  • 何もしなければ壊れてしまう(OSSのコードがサポート終了したり脆弱性が見つかったりする)
  • なんとかしても壊れてしまう(本番環境でバグを0とすることは不可能)
  • 壊さないように努力しすぎると何もできないが努力を怠ると使ってもらえない

という特性があるため運用監視を継続的にし続けることが重要ですが、その際にはMTTRをより短くしてMTBFをより長くしていくという視点で取り組みをすることが大切だということでした。

こうした取り組みをするうえでのアンチパターンとして、

が特に多く見受けられるということで、こうした状態に陥らないために

  • 被監視対象の見直し
  • アラーティング最適化
  • オンコールシフト見直し(全員集合も意外とおすすめ)
  • オンコール対応があった次の日は打ち上げ
  • オンコール対応最適化
  • プレイブック整備
  • ダッシュボード整備
  • APM導入
  • ポストモーテムの再発防止策の実施
  • ポストモーテム輪読会
  • アーキテクチャ見直し
  • リリース分割
  • デプロイ方式最適化

といったプラクティスを実践することが重要だということです。

会全体を通した感想

実践をしている話が多かったので、具体的かつ生々しい課題とその課題に対する技術的なアプローチの話を多く聞くことができて非常に良かったです。

個人的には、こういったイベントだとよく聞く当たり前の課題の一歩先に踏み込んだ課題に対応されているような印象があり、満足度が高い内容でした。