Katsuyaのひとりごと。

怠惰で短気で傲慢なつぶやきを

TDDyyχ参加記〜その36〜

概要

東京ガーデンテラス紀尾井町のLODGEにて、第36回TDDyyχが行われました! TDDyyχとは、モブプロでTDD(テスト駆動開発)を行い、わいわいする会です。(意訳)

参加した人がブログ書かない問題について

当イベントの(主に運営に携わる人の)疑問の一つとして、「参加者がブログを書いてくれない」ことが挙げられます。(そんなこと思ってるのは一部だけかもしれませんが。) 非常に楽しいイベントですし、どの参加者からも好意的な感想が出てくるので、甚だ謎ではあります。

個人的には、TDDの楽しさ、モブプロの楽しさ、ワイワイする楽しさなど、楽しさの要因が複合的なので参加者がおすすめしようにもわかりやすく面白さを言語化するのが難しいのでは…と思っています。

自分が今日得た学び

今回組んだチームでは「JavaFizzBuzz」、「Javaで自販機」の課題を解きました。 その中で、JavaRecordクラスValueSourceアノテーションを新しく学びました。

また、メンバーの雰囲気を感じ取りながらどこまでを“三角測量”し、どこからを“明白な実装”をするかを意思決定できたのが良かったと思います!

次やること

自社のメンバーを連れて来たい。。。 この楽しさをぜひとも分かち合いたい。。。

Agile PBL祭り2023参加記〜〜

Agile PBL祭り2023に参加&登壇させてもらいました!

学生社会人を問わず、アジャイルプロジェクト実践者の相互学習と交流を目的」とした1-dayイベントが名古屋のツドイコで行われました。 (イベント詳細はリンクから)

confengine.com

プロダクト開発においてチームで工夫した点について発表された方が7割、それ以外のテーマで発表された方が3割というイメージです。

私は3回目の参加になります。 縦のつながり(出身大学の先輩、後輩、先生方)と横のつながり(企業、他大学)を広げ交流ができる、とても楽しく有意義なイベントだなと改めて感じました。

発表を聴いたり色んな人と話して思ったこと

まずチーム開発の発表を聴いて、チームによって独自の視点を持って困難を乗り越えようとしているのが面白いと思いました。 「自分が学生の時enPiTでチーム開発したときも同じような困難に遭遇したなぁ」と感じると同時に、似たようなシチュエーションに遭遇しているにも関わらず、自分だと思いつきもしない視点で物事を考えられていると思いました。 チームの数だけ工夫がある、ということを頭では分かってるつもりでしたが、改めて心に響くものがありました。。。 (この記事書いていて上手く言語化ができないなぁと思ってはいるのですが...)

どの発表も素晴らしかったのですが、いくつか考えさせられたことがあるので書き留めます。

登壇して思ったこと

(登壇資料はこちら) speakerdeck.com

ざっくり言うと「PBL型授業を受けたあとの私は常日頃身の回りの困りごとにアンテナを張り、それを解決するための仮説を持って行動してるよ」という話を実際のエピソードを交えてお話しました。

正直この話に一体どれだけの人が興味を持っていただけるのか非常に不安でした。。。 が、聴いてくださった方から想像以上に称賛の声をいただき、大変嬉しかったです...!!

実を言うとあまりに緊張して参加者の反応を見ながら冷静に話すということができず、10分という時間枠に収めることで頭の中はいっぱいでした。。。 終わったあとに「発表上手だったよ」とたくさんの方からお褒めの言葉を頂いて嬉しかったのですが、自分としては発表中の記憶があんまりないです。(笑) Discordに書かれた実況チャットを見るからに、ちゃんと発表できてたのかなとは推察できるので、安心しています。

(無事発表を終えた安心感からか、発表後から昼食の時間にかけて胃がキリキリしており、ご飯がスムーズに喉を通りませんでした笑) (お弁当がとても美味しかったのははっきり覚えております!フードスポンサーのデロイト トーマツ コンサルティング様ありがとうございました🙇)

個人的な反省をいくつか挙げると、

  • もっと事前に資料を作成する。
    • 発表スライドの作成に関してもっともっと余裕を持ったほうが良かったなと痛感してます。。。
    • 当日までスケジュール的に忙しくなることは分かっていたので1ヶ月以上前から準備していたのですが、結局行きの新幹線で作り上げるという見事な締め切り駆動資料作成をしてしまいました。
  • 事前レビューを受けてブラッシュアップを重ねる。
    • 資料作成が遅れたがゆえに事前レビューをもらう時間が十分に確保できませんでした。
  • 尺を考慮して話の構成を組む。
    • 話のスケールとして10分には到底収まらない構成になってしまったので、この辺は改善の余地があるかなと。

とはいえ、スライドの作り方については過去3年間くらいのノウハウが遺憾なく発揮されたので、及第点ではあるかなと思ってます。(自分に甘い。)

次にどうするか

今回個人で登壇するのは初めてだったのですが、とても良い経験になったと思います。 こうした機会をいただけるように、またそのときは違ったお話ができるように、焦らず自分のペースで経験を積みます...!!

読書記録 - 『単体テストの考え方/使い方』

読んだ本

www.amazon.co.jp

動機 - 単体・結合テストについての網羅的な知識が欲しかった

単体テストがどういうテストでどういった観点があるのかは雰囲気でなんとなく知っているけれど、効果的な単体テストとはとか、結合テストとの棲み分けをどうするかみたいな知識が全然なかったのでそのへんを補完したかったです。 また、インターネット上でテストについて調べても結合テストについて書かれているサイトは驚くほど少なく、これは書籍を当たるしかないという思いもありました。

構成 - 第2部で単体テスト、第3部で結合テストとしてそれぞれ何をどう書けば良いのかわかる

  • 第1部(1〜3章)は単体テストの定義やテストに対する学派などについて書かれています。
    • 主にモックの取り扱いで分かれている学派については絶対に念頭に置いておくべき内容だと思いました。
  • 第2部(4〜6章)は良い単体テストを書くための4本柱、手法、モックの扱い方、リファクタリングについて書かれています。
  • 第3部(7〜10章)は結合テストのスコープ、テストする際のモックとDBの扱いについて書かれています。
  • 第4部(11章のみ)は単体テストアンチパターンについて書かれていて、中でもプライベートメソッドに対するテストは不要であることに言及しています。

要点 - 観察可能な振る舞いに対して単体テストを書く

  • 単体テストとは下記3つを満たすもの。それ以外はすべて結合テスト
    • 1単位の振る舞いを検証する
    • 実行時間が短い
    • 他のテスト・ケースから隔離された状態で実行される
  • 良い単体テストを構成する4本の柱
  • 観察可能な振る舞いに対してテストを書く(↔実装の詳細)
  • 副作用とコントローラを排除する
    • MVCとかで言うコントローラのこと
  • 結合テストはシステムが「プロセス外依存」と統合した状態での機能をテストするのが役割

自分の中での本書の立ち位置・感想

タイトルに単体テストって書いてあるからてっきり単体テストがメインで結合テストについてはさらっとだけ触れるのかと思ってましたが、そんなことはありませんでした。 むしろ単体テストの位置づけや目的を理解することは自ずから結合テストのそれらを理解することに繋がるのだということがはっきり理解できました。

テストに関する思想からプラクティス、アンチパターンに至るまで網羅的に書かれているので、読書会があったら真っ先に取り上げたい本だなと思いました。

テストについて学びたかったらまず読むべき1冊として挙げたいです。 ただそれなりに内容が濃いので、初学者の入門書としてはちょっとだけ重いかも。

次のアクション

  • テスト戦略についての書籍を当たる
  • 現場で結合テストやE2Eテストの量が肥大化してる原因を探る
  • 積極的に単体テストを書き、同時に何を結合テストで書くべきかを論理的に説明できるようにしておく

読書記録 - 『レガシーコード改善ガイド』

読んだ本

www.amazon.co.jp

動機 - 既存のコードを改修する際のヒントが欲しくて読もうと思った

本書を読む動機は以下のような感じです。

  • 『レガシーコードからの脱却』が比較的チームレベルでの取り組みとかマインドセット的なレイヤを扱ってた覚えがあり、1人からでもできる範囲のプラクティス系の本を読みたくて本書にたどり着きました。
  • あとは今自分が既存のコードをベースに新機能追加や改修をする状況に置かれているので、きっとすぐに役に立つ情報が書かれているに違いないって思ったのもあります。

ぶっちゃけタイトルに釣られて買った部分が大きいですね...笑

www.amazon.co.jp

構成 - 第2部のFAQ形式の問題解決事例集がメイン

本書は3部構成です。

第1部(1-5章)は導入が書かれていて、ソフトウェアを変更する理由、変更手順、変更する上で覚えておくべき重要な概念やツールが紹介されています。

第2部(6-24章)が本書のメインパートです。 コードを変更しようとする際によく遭遇する具体的な問題を起点としてFAQ形式で書かれています。 全部の章ではないですがだいたい以下のような構成だったかと。

  1. 問題点の整理
  2. テストコードの書き方
  3. リファクタリングの適用

第3部(25章のみ)はリファクタリングレシピが列挙されています。 多くはファウラーの『リファクタリング』で書かれていたのと似たようなレシピだったと思います。

www.amazon.co.jp

要点 - 挙動理解にも改修作業にもまずテストを書くことから

印象に残ったことをいくつか書きます。

  • 影響調査のために処理を図に起こすこと
    • 図にするのは至極当たり前のことだとは思うけど、圧倒的に自分には足りないところだと感じました。
  • 試行リファクタリング
    • 自分はコードリーディングする際に後で破棄するリファクタリングをよくしていて、それと同じことが挙動理解のためのプラクティスとして紹介されていました。
  • 第2部ではどうやってテストを書くかに着眼点を置いてること
  • タイトルに「改善ガイド」って書かれてるからてっきり改善それ自体のプラクティスが多く書かれていると思っていたけど、どちらかというと改善のためにいかにしてテストコードを書くかって方に著者の熱意を感じました。

自分の中での本書の立ち位置・感想

コードの改修作業に取り掛かる前に本書の第2部のFAQから似たような事例を参考にして、問題点の洗い出し・整理をするのが良いかもと思いました。 それ以降リファクタリングが必要な場合は第3部を読むか『リファクタリング』のレシピを参考にするとか。

第2部の各章のタイトルはどれも「〇〇ができません」とか「〇〇をするにはどうしたらいいですか?」って感じなんですが、全部「うわ...心当たりある...」ってものばかりでした。 日頃の抱いてるモヤモヤや誰かにぶつけたい疑念をまさに本書が払拭してくれるかもと期待できるような章タイトルになっているなぁと。

どの章も具体例としてコードが書かれていて、何にどう困っていてどうすればもっと良い構造になるのかが細かく書かれているので、読んでいて理解できないって点は無いと思います。

次のアクション

ファウラーの『リファクタリング』は大学の研究室で読んだきりだったので、買って手元に置いておきたいと思いました。

改修タスクやるときにユニットテストが書かれていない長大サービスクラスとかに手を入れる必要とかが往々にしてあるので、本書に書かれてるようなテストコードの書き方を1つ実践してみたいです。

RSGT2023参加記〜1年間の行動指針が決まった〜

1/11〜1/13に御茶ノ水ソラシティにて国内最大級のスクラム実践者の集まりであるRSGT2023が行われました!

私は去年に引き続きオンサイトで参加させていただきました。 大学が同じ友達がたくさん参加していたり、知り合いが増えたこともあって、今年は一段と楽しかったなぁ…

今年は会場での行動の仕方を変えた

初参加だった去年、私はこんな感じで参加してました。

  • 朝からずーっと興味あるセッションを聴き続ける
  • ひたすらにテキストチャンネルにコメントしたり、リアクションしたりする
  • 大学の友達と感想を言い合う

どのセッションも様々な学びがありました。 また、聴いた直後に大学の友達が壁打ち相手になってくれたおかげで、より一層学びが深くなったなぁと。

去年もRSGT参加記を書いたわけですが、他の参加者のブログと自分のを比べてみるとどうもテイストが違うのです。 書きぶりがーじゃなくて、内容が。

何が違かったのかというと、他の方は聴講したセッションの感想や登壇した感想だけでなく、「あんな人やこんな人とお会いしてワイワイお話ができた」ことを書いていたのです。。。

たしかに、イベント名にGatheringって付いてるのにオンサイトで集まっていることを活かしきれていなかったなぁ...と心残りがありました。 そこで、今年は参加者と話すことを目標の1つに加えました!

Day0に参加して本当に良かった!!

知り合いを増やしてRSGTへのドキドキをワクワクにする会というのがRSGTが始まる前日の夜に開催されていたので、参加しました。 Zoomのブレークアウトルームを用いて行われ、何人か知り合いを増やすことができました。 もちろんDay0自体も楽しかったのですが、ここで知り合いができたのは自分にとってかなり大きかったです。 全く見ず知らずの人に声をかけるのは私にとってハードルが高かったのですが、「Day0で知り合った仲間に声をかける」というステップのおかげでRSGT当日に声をかけるハードルがだいぶ下がったと感じました。 本当に参加して良かった。。。

得意でないことを一人で克服しようとするのはいかんせん難しいので、こうした機会はありがたかったです。

他にも、友達と一緒に行動して声をかけることで誰かしら話題を繋げられるようにしたり、miholoveさんに紹介していただいたりと、小さな一歩をたくさん踏み出しました。 頑張ったよ。。。

ギャザリングによって得た話や機会

いくつかピックアップすると、

  • 発信することや信頼貯金の大切さ w/ Arisaさん、iwashiさん、びばさん
  • 顧客の要求 w/ あいきんさん
  • キャリアについての悩み w/ 安田さん
  • 地方の勉強会 w/ tomioさん
  • スクラムの本質 w/ きくりんさん

もちろんenPiT繋がりの友達とありったけの感想や議論を交わしました。

他にもたくさんの方といろいろなお話をさせていただきました! ありがとうございます...!!

去年の私からは考えられない経験です。 プチ後悔が原動力になり、周りの方々の支えがこれを駆動し、今年の経験になったのだと思います。 マジ感謝。。。

2023年はどう行動していくか

去年とは違った一歩を踏み出す、このきっかけをRSGTによって得られました。 これを踏まえての今年の抱負は、ずばり「行動を起こす」です。 具体的に書き下すと、

  • 社内で発信する
    • RSGTの同時試聴会を開催する
    • 気になった記事や本などをテキストチャンネルで共有する
  • 社外で発信する
    • 自分が興味あることをブログに書く
    • どこかにプロポーザルを出す

「学びを得た」で終わらさず、次に繋げていきます!!

(当日聴いたセッションの感想は別の記事に書こうと思います!)

2022年の振り返り

Fun Done Learnで今年を振り返ります!

(事実整理からしたいのでDoneから)

Done

  • 大学院を卒業した。
    • 6年間、サークルと研究とバイトと...たくさんの経験をした大学・大学院をついに卒業して新生活へ。
    • M1の頃は研究が嫌すぎて卒業できるか怪しかったけど、なんとか頑張った。
  • 大企業にエンジニアとして就職した。
  • 東京に引っ越した。
  • 自宅の開発環境を整えた。
  • 大きい家電をいくつか買った。
  • 長い長い研修期間を経て初めてのプロジェクトに参画した。
    • 全社基礎研修とプログラミング系の研修とを合わせると一体いつまで研修するんだ??って感じだった。
    • 自分から話すのが苦手なタイプだけど、最大限の社会性を発揮してなんとか同期の友達を増やすことができた。
  • 先輩との輪読会(3ヶ月)
    • 配属先の1つ上の先輩とエリック・エヴァンスの『ドメイン駆動設計』を一緒に読んで、設計・開発やキャリアパスについての議論をたくさんした。
  • React, Nest.jsを使っていくつかWebアプリを開発した。
    • 筋トレ的な感じで小さなアプリを作った。
  • 本をたくさん買った。
  • Kindleを買った。
    • 10月に発売された6インチディスプレイのモデル。
    • 寝る前に読むように買った。

Fun

  • 無事に就活を終えて大学院を卒業して社会人になったのが一番嬉しい。
  • 自宅の開発環境が整ったのはめっちゃ良き。
  • 社内のギーク寄りな人に出会えた。
    • 少なくとも新卒社員だと肌感で5%程度しかギークな話を好む人がいなかったので、研修で同じグループになった人やプロジェクトの先輩にそういう人がいて良かった。
  • 社会人のお金の使い方をした。
    • 読みたい本、試したい機器をいくつも買えるようになったのは自分の中では大きい変化だった。
    • お金がないと積読すらできない。。。
  • 家事の手間が省けた。
    • 学生の頃は否が応でも自炊をしないとやっていけなかったが、時間がないときに気兼ねなく外で済ませれるようになったので、負担がだいぶ減った。
    • ドラム式洗濯機を買ったのも同じ。負担がちょーーー減った。

Learn

  • お金は大事。
    • 無駄遣いをするほうでは無いと思うけど、それでも友好関係を維持しつつ現代的な生活をするには学生のアルバイトの給料だけでは足りないと実感した。
    • 心の余裕ができるようになったのが何よりも大きい。
  • 学び続けることの難しさ改めて自覚した。
    • 自分は興味駆動で勉強することができないタイプなので、勉強するやる気を保つのが本当に大変。
    • ある特定の技術について勉強する、とかではなくて、自分のキャリアパスを考えてーとか、共通言語・基礎教養としての知識を身につけるには自分一人では限界がある。
    • 熱心に勉強してる人が近くにいるとその影響を多分に受けるタイプでもあるので、やはり学びやすい環境を見つけるのが最善かも。
  • 自分は設計・開発の道を目指したい。
    • プログラマとして活躍したいのか、コンサルティングもしたいのか。
    • いわゆる上流工程に携わりたいのか、コーディングができれば良いのか。
    • あれだけ楽しいと感じたアジャイル開発は...?
    • っていう問いを重ねていくうちに、今の会社で描きたいキャリアパスが見えてきた気がする。
    • 現時点での解としては自分はやっぱり一ソフトウェアエンジニアとして設計・開発をしたいってのが一番かな。

総括

卒業・就職・引っ越しによって生活環境がガラリと変わったので、行き着くまもなく駆け抜けた感がある。

来年はもっと具体的な目標設定をして、もう少し着実に自分にとっての学びを増やしていきたい。