気まぐれ上司

金曜日の夜は、娘の習い事のお迎えに行って、二人で自転車で帰ってくる。いつも決まった道を通って帰ってる。

 

でも、昨日は少し違った。お迎えに行った帰り道、娘がいつもの道を行こうとするので、とめた。「今日は、そっちじゃなくてこっちの道で帰るよ」

 

「あ、そうなんだ」というので「うん」って言って二人でそっちの道を帰る。しばらくぼーっとしたあとに「なんでだと思う?」と聞いてみる「なぞなぞ?」「ううん」

 

娘は少し考えてみて「んー、なんで?気分?」「ううん、今日は習い事短くて帰ってくるの早かったでしょう?」「うん」「だからだよ」

 

「あーあっちの道は今の時間はまだ人がたくさんいるからか」「そうそう、あっちの方が近いんだけどね」「そっか、なるほどね」

 

といいつつ、もう別のことを考えてそうだったので、今日にはもう忘れてるだろうな。

 

しばらくぼーっとしてるときに考えたのは、これって上司が気まぐれに見えてしまうのと似てるかもなぁということ。

 

「帰り道はこっちの道を行く」というルールだと捉えていると、今日は気まぐれで違う道を選んだように見えたかもしれないな。と。

 

僕の中では当然のことだったので、言葉にして伝えてなかったけど「道が混んでいなくて自転車でも安全に帰れるときは近い方の道で帰りたい」という自分の考えを伝えておくと良さそうだなと思ったので話をしておいた。

 

逆に、自分が誰かの指示に従うときは、その理由を理解しておきたいよな、とも思いながらコーラを買ってあげて帰った。

 

毎朝15分以上のデイリースクラムをしてる

15分以上のデイリースクラム

今一緒に仕事をしているチームでは、毎朝みんなで集まって話をしてる。みんな家から仕事してるからZoomで。

デイリースクラムみたいなものではあるのだけど、15分以内におさめる、ということはあまり考えていない。

だいたい15分は超えていて、長いときは30分ぐらいかかる。でも、それでいいと思っている。それだけ話すことがあるというだけ。

どうして?

理由は、開発チームだけじゃなくて、プロデューサーも含めて全員で「現状を確認する」「同じ方を向く」「不安を共有する」ということをやっているから。実際のところ、開発チームだけの話だと5分もかからない。

プロデューサーはチームの外側で起こった色んなことをフィルタリングして開発チームに必要な情報を届けてくれる。とても助かる。お互いに情報を共有して、現状の認識合わせをする。そのうえで、今日何をやるべきかを再確認している。

そんな感じなので、毎朝プランニングをしている気持ち。

どうして?その2

どうしてこういうことが必要かというと、僕らは、特定の開発プロジェクトだけを担当しているわけじゃなくて、サービスの運用も担当しているから。

なので、問い合わせや調査の依頼、突発の対応が入ったりする。そうなると昨日までとは状況が変わるから「チームとして今日どのように動くべきか」というのをみんなでプランニングする必要がある。

「これは今の作業を止めてでもやったほうがサービスにとって良いんですよね?」

という話や

「今の作業の方がサービスにとっての優先度が高いから、その対応は次のスプリントに入れましょうか?」

という話がとびかう。

サービス運用も?

という風に僕らは開発だけじゃなくてサービスの運用も見てる。このことは、上記のように開発チームに不安定さをもたらすのだけど、僕自身はそれはそれで良いかなと思ってる。開発をしているときに運用視点の話がでてくるから。

「この設計だと問題があったときに気づくのが遅れるから、すぐに気付けるようにしたいな」とか「このログだとシステムに何が起こったのかは分かるけど、じゃあそれでユーザーがどう困るかが分からないから、そっちが分かるようにしたいな」とかそういうの。サービスの運用を実際に体験して、実感してないとなかなか伝わらない。

そんな感じ

なので、デイリースクラムというかデイリープランニングみたいなものをやっていて、それには15分以上かかってる。

プロデューサーには、こういう質問をしてるかな:

  • 今日、開発チームに伝えておきたいことはありますか?
  • 困っていることや、開発チームに相談したいことはありますか?

ところで

僕が初めてスクラムを勉強したときは、デイリースクラムの3つの質問はこんな感じだったと思う:

  • 昨日何をやったか?
  • 今日何をやるか?
  • 困っていることは?

だけど、2013年のスクラムガイドの改定で、こんな風に変わった:

  • 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か?
  • 開発チームがスプリントゴールを達成するために、私が今日やることは何か?
  • 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか?

こっちの方がチーム感があって好きな感じ。さらに、3つの質問自体が「必須ではなく、一つの例」になったけど、それも良いなと思う。

参考: スクラムで削除された5つのトピック | Ryuzee.com

頑張ってる人の力になりたい

なぁと思う。そして、そう思える人が周りにたくさんいるのは、良い。

最近涼しくなってきて、今日は久しぶりにぼけーっとゴロゴロしてるので適当に書いてみる。

 

どちらの力にもなりたい

頑張っているのになんかあんまりうまくいかなくて悩んでる、のは、期待と現実にギャップがあるからだということが多い。

これくらいできなきゃいけないけどできてない…。みたいなの。

って話をすると、現場のメンバーを想像するかもだけど、マネージャーもそう。

どっちも頑張ってるし、より良くしたいと思ってるし、どっちも悩んでる。ので僕はどちらの力にもなりたい。

この辺は「自分の娘たちがその立場だったら自分はどう思うか」を考えると優しい気持ちになれる。

 

今のままでいい

「期待通りにいかないのは頑張りが足りないからだ」と思ってる人が多い。でも、そんなことはない。

今のままで良くて、明日それよりもうちょっと上手にできるようになったら、明日が今日よりも良くなる。ただそれだけ。

 

ギャップが見えない

難しいだろうなと思うのは、期待と現実をどう埋めていけばいいか、そのギャップが見えていない場合が多いということ。

ギャップが見えていないと、なんかうまくいかないんだけど、どうすればいいのかが分からないなぁって、不安の中を手探りで進むしかない。

 

ギャップを見せる

だから、僕が手っ取り早く手伝えるのは、そのギャップを見えるようにする、ということなのかなと思ってる。

期待と現実をつなぐための動きを、できる範囲で僕がやって見せる。その一部はエンジニアの動きだし、一部はスクラムマスター的な動き、他の部分では、マネージャーの組織づくりの動き。

こういう動きが組織としてできると、自分たちの期待に近づけるよ、みたいなの。

もちろん全部ができるわけではなくて、その触りを見せるくらいしかできないけど、そんなやり方があるんだ!ってのを1つだけでも見せられると役に立つかなと。

 

そういう感じ。

 

頑張る?

そういえば、頑張る、というのは、無理をする、というのとは違う。残業はしない。休憩もしっかりとる。生活を1番に考える。がいい。

その上で仕事に向き合って、限られた時間の中で自分のスキルを伸ばしながら、サービスに対して昨日よりも今日は少しだけ多く貢献できるように考えて行動をする。

 

そういうのを頑張ってる、と言いたい。

 

娘たち

には、まだできないことがたくさんあるけど、できないことを悲しむより、できてることを喜びつつ、明日も無理せず頑張って、できることが増えたらまたパーティーしようね。なのがいいなぁ。というのが根底にある。

 

適当に思い浮かんだことを書いてみた。そろそろお昼ごはんでもつくろっかなー。

 

日本的な視点でScrumを再考してみたい #RSGT2021

と思って RSGT2021 にプロポーザルを出しました。ちょっとでも面白そう、と感じてもらえた方はぜひ投票をお願いします!9月末でしめきりなので早めにポチッとタイトル下のハートマークを押していただけると嬉しいです。

confengine.com

この10年弱くらいスクラムやってて、良いところたくさんあって好きなんだけども、なんかちょっと気になるところもあって、なんだろうなぁ?って思ってて。

スクラムの起源には The New New Product Development Game という論文があって、これは1980年ごろの日本の製造業の新しい新製品開発を取り上げたものなのだけど、この論文に影響を受けて1990年ごろにスクラムが考案されて、それが逆に最近日本に入ってきて、色んなところで導入されてる。

この10年で、スクラムによって自分の周りの色んな考え方が変わってきて、日本的なあまり良くない部分も減ってきて良いなぁと思う。そうなってくると今度は、日本的な良い部分をもう一度見つめ直してみたい気持ちになった。

僕は、英語化をした企業で仕事をしているのだけど、そこでは日本の文化を土台にして、海外の文化の人たちもたくさん一緒に仕事をしていて、お互いの違いを尊重しながら仕事をしている。そんな風に他の文化に触れると、逆に自分の土台になっている文化について気付かされることが多い。

The New New... を元に考案されたスクラムだけど、日本の文化という土台の上では、もう少し別の見方もできるのではないか、もしかしたらそういう日本の文化の中で育ってきた自分だから気づくことができる視点があるのではないか、という気持ち。

ハイコンテキスト、場、絆、暗黙知、リーダーシップ、開発リーダー、プロダクトオーナー、スクラムマスター、マネージャー、その辺りをキーワードにしてもう一度自分の中の言葉で考えてみたい。

英語で発表しようと思います。当日は通訳があるかもしれないから、その場合は日本語でも聞くことができると思います。ぜひ投票をお願いします!

実験によってチームのやり方として定着してきたものを6個

この2ヶ月ぐらいサポートしてるチームで、実験を重ねる中でチームのやり方として定着してきたものがあるので、温かいうちに書いとく。6個ある。

背景

どういう背景かを簡単に:

  • エンジニア4人とリーダー1人、プロデューサーが2人のチーム。全員家からリモートでつないでる。
  • サポートに入る前はチームは計画重視の指示型開発で全員別々の作業をアサインされて取り組んでいた
  • そこに「自己組織化チームにしたいけどそういう経験者もいないしプロジェクトも忙しい中なのでサポートしてほしい」と声をかけてもらって参加
  • 2週間くらい観察して色々周りを整えたあとにチームに入って、スクラムを導入して1週間スプリントを6回終えたところ
  • 自分はリーダーの代わりに入らせてもらうことにした。まずはチームのやり方を色々変えてしまって、チームが落ち着いてきたら徐々にリーダーと一緒にそのリーダーならではの道を探して、最終的にはそのリーダーに渡す予定。

スクラムをどんな風に導入したかは今日は触れない。そして、いつものことだけど、ちゃんとスクラムやってるわけじゃない。

定着してきたチームのやり方

ということで、チームのやり方として、実験して定着してきたものたちを紹介する。

(1) Mobbing by default / 基本はモブ

全員が集まることを基本とする。特に以下の場合はペア作業中だとしても全員を集める。

  • 大きな設計判断、または難しい設計判断をする場合
  • ペアの二人共が悩んでしまった場合
  • 他のペアの意見も聞いてみたい場合

基本をモブにする背景

  • 基本がペアだと、全員で集まるハードルがあがってしまうため、基本はモブとする
  • 基本がモブで、そこからペアに分かれるのは簡単

これを実現させるためにまず最初に「チームとしてタスクを受け取る」ということに取り組んだ。個人やペアでタスクを受け取るという認識だと、助け合うときに足枷になってしまうから。自分の今担当しているタスクの手を止めても、別のペアのタスクの相談にのることがチームとして優先することだ、という認識を持てる場にすることが大切。

(2) Pair as Atomic Unit / 最小単位はペア

作業担当の最小単位はペアとする。一人ではタスクを担当しないこと。

  • 設計・実装・テスト、それぞれに対してクオリティがあがる
  • イージーミスが減る
  • 別の視点の意見が入る
  • コードレビューの負担が下がる
  • 一人だと焦ってとばしてしまいたくなることも、二人だと止めてもらえる
  • 名前づけを真剣に考えやすくなる
  • ときには途中で見切りをつけてまず動くところまで持っていくという判断をしやすくなる
  • 一人だと悩んでハマってしまう場合があるが、ペアに相談できるし、ペアでも悩む場合に他のペアに相談するという判断がすばやくできる
  • ペアのもう一人がお休みの場合は、別のペアに合流して3人で作業することを第一に考える

これは「効率上げるために一人で作業してみる」という実験をしたときに「やっぱりつらい」「結局時間がかかる」ってなって「最小単位はペア」にすることになった。

(3) Separate Work in a Pair / ペア内別作業

ペアワークだからといって常に一緒に作業をしないといけないわけではない。

  • 必要に応じてペアで別々に作業をしても問題ない

ただし、あくまでも担当の最小単位はペア

  • 一日の終わりには、そのペアのどちらに話を聞いても状況が分かるように認識を同期しておくこと
  • そのため、ペアで頻繁に認識合わせをしておく

実際にうまくいった方法

  • 時間を区切って「1時間後に共有しましょう」というようにしたらうまく同期できた。

(4) Frequent Breaks / 頻繁な休憩

モブやペアは想像以上に疲れるので、頻繁に休憩を取ることを忘れないようにする。

  • 特にペアは気を抜くことができないので疲れる。

長くても1時間に1回は休憩を取ること。

  • 例:45分作業したら15分休憩
  • 例:25分作業したら10分休憩

休憩といってもずっと休んでるわけじゃないよ

  • 気になってたことを調べたり
  • メールの確認みたいな開発以外の作業をしたり
  • チャットに返事をしたり、チケットを見てたりするから

(5) Engineer Evening Huddle / エンジニア夕会

毎日夕方にエンジニアだけで集まって共有や相談をする場を設ける

  • 「話すことがあれば開催」ではなく一旦集まって「話すことがなければ解散」というスタイル。開催のハードルをあげないため。どうでもいい話もできるようにするため。
  • 朝会のようにエンジニア以外が参加している場だと気を遣ってしまうような細かいコードの話やどうでもいいような話題が中心
  • もちろんエンジニア以外の参加も歓迎する

具体的によくやるのはこんな感じ↓

プルリクエストの事前説明

  • プルリクエストで「書き終わったコード」だけを見てレビューするよりも過程も共有したい
  • なので、そのプルリクエストで何を考えてどんな風に修正をしたのか
  • 主にどの辺りを見てほしいか、どの辺りが心配か、気にしなくても大丈夫な部分はどこか
  • 動作確認やテストについての共有

など。これでプルリクエストのレビューの負担がだいぶ下がった。

設計判断の共有

  • コードを書いてる途中でも、書く前でも、早い段階で設計判断を共有しておくと色んな意見がその時点でもらえるので、より良いコードがかける

悩み・不安の共有

  • 何か悩んでたり不安に思っていたり困っていたりすることがあれば共有する
  • エンジニアの不安はあたってることが多い

って感じなんだけど、これは、それまでモブでやっていたのをペアでも作業し始めて、情報が分断され始めたとチームが感じたときに、TRYとして始まったもの。

一日中モブをやってる場合は常に情報が同期されているのでこの会をスキップすることができる。実際に何度かスキップしている。

(6) Morning Huddle over 15 mins / 15分以上の朝会

朝会は15分以上かかることが多いけど気にしない。

実際のところエンジニアのタスクの状況共有は10分もかからないのだけど、その前に、プロデューサーからエンジニアへの同期というのをやってる。

プロデューサーからはこういう共有がある:

  • 他部署との調整
  • サービス運用に関わる共有や調査依頼
  • ステークホルダーからの情報の共有
  • 他の案件の準備のためのエンジニアの協力依頼
  • などなど

チームの外側の状況は日々めまぐるしく変わっているのだけど、それをフィルタリングして大切なものだけを伝えてくれる。そのおかげでチームが開発に集中できるようになってきている。

そして、チームは「現在の状況の中でチームとして今日最優先にするべきことは何だろう?」って考えて取り組むことができる。

そんな感じ

自分が大切にしてるのは「気持ちの自然な流れ」。別々作業を基本にしてると「モブやってもいいですよ!」ってしててもなかなかそちらに流れない。モブの方が気持ちの位置エネルギーが高い感じ。

だから「モブを基本にします!でも別々に作業してもいいですよ!」ってしとくとエネルギーが低い方には自然と流れることができるので両方をうまく使い分けることができる。そういう仕組みづくりが好き。

全員が前向きに取り組んでくれてるし意見を出してくれるのでとても助かる。定着したものもチームの成長や周りの状況に応じて変化するので、定期的に見直していきたい。

スクラムマスターの次のステップって何だろう?

SCRUMMASTER THE BOOK を読んだ。

books.rakuten.co.jp

もっと大きな物語

最初は(ほうほう。。。)って読んでて途中で(んー???)ってなってその後(あぁそういうことか・・・まじかwww)ってなった。面白い。スクラムの中のスクラムマスターという話よりも、もっと大きな物語だった。だけど、ページ数も多くなくて読みやすくて楽しかった。

悩むだろうなぁ

スクラムマスターとして動いてる人であるかなぁと思うのが、雑用係みたいになってるとか、自分がいらなくなることを目指すけどその後どうしよう?とか。

特に後者の、チームとしてある程度うまく回り始めて、このチームが良くなったらこの後自分はどうするんだろう?別のチームでまた同じことをやるのかな?ってどっかで感じ始めてる人は手にとってみると良さそう。

目指すもの

重点を置いてるのは「スクラムマスターとして何をすべきか」よりも「スクラムマスターとして何を目指すべきか」について。で、そこに近づいていくために、どんなことを考えて・どんな道具を選んで・何をすべきか、ということについて書いてある。僕はそういう風に感じた。

スクラムマスター道

そして、彼女が提唱するのが「スクラムマスター道」。スクラムマスター道の3つのレベルを一歩ずつ進むことで、グレートスクラムマスターに近づいていく。

本全体を通して良いなと思うのは、「こうあるべき」って最終的な場所を最初から投げつけてくるんじゃなくて、「まずはここだよ」「そしたら次はここ」「で、ここだよ!」って一歩ずつで良いんだよって言ってくれてるところ。

うちのマネージャーたち

このレベル3の部分を読みながら(これってうちの部署のマネージャーたちだなぁ)って思った。うちの部署のマネージャーたちはサーバントリーダーな感じで、メンバーである僕たちのことを支えてくれながら、より良いサービスを提供するための、より良い組織づくりをしてくれてる。

なので、この本の定義でいくと、彼らもスクラムマスターなんだなぁ。ちなみに、うちのボスはRSGTにロシェルさんとのプロポーザルを出してるので、聴いてみたいなって思った方はぜひ投票お願いします!

confengine.com

道すがら

話の軸はそういう感じで、それだけでも面白いんだけど、その道すがら色んな道具やマインドセットやアドバイスに触れてくれてたり、「こういう人いるよね?」みたいな事例の紹介をしてくれてたりで、あー分かるわーとか、ギクッ・・・みたいなこともある。

毒とかポジティブさとか、自分が感覚的に理解しているところも、明示的で分かりやすい文字にしてくれてて(あー、自分があれなんとなく避けてるのってこういうデメリットがあるからかー、そう言われてみたらそうだな)みたいに納得しながら読んだりした。

とはいえ、そういう道すがら教えてくれてるものたちは、簡単な紹介に留まっているので、気になったものや目に止まったものがあったら、そこは別途深堀りすると良さそう。そういうインデックスとしても良い。

僕もスクラムマスターかも

本を読み終わった後に感じたのは、僕もスクラムマスターなのかもなぁ、ということ。エンジニアとして動いてはいるんだけど、色んなチームに入っていって内側から手を動かしながらサポートすることで組織をより良くしていこうとしてるから。

目の前にあるなぁ

スクラムマスターがスクラムマスターチームを組んで協力しながら、より広い視野で世界を変えていく。ってのを見て、それって、目の前にあるなぁって思った。RSGTやスクラムフェス、DevLOVEなど、コミュニティの中で色々な人たちが支え合いながら、一歩ずつ現場を良くしていってるもんね。

色々感想が発散してしまったけど

スクラムマスターとして、広い視点で自分の役割を考えたい」って人や「組織をより良くしていこうとしているサーバントリーダー」な人におすすめの一冊でした。楽しかった。

神コントローラーにテスト駆動開発で機能追加

TDDBC オンラインの基調講演の録画を見た。とても面白かった。和田さんのセッションやスライドは何度も見て勉強してるので、それをひとつずつ再確認しながら見ることができて、とても良かった。話の流れが分かりやすくてすごいなー。

最近実際にやったテスト駆動開発

その録画を見ながら、最近自分がテスト駆動開発で機能追加をしたことを思い出してた。今日は、それをだらだらと書いてみようと思う。プライベートメソッドに対してテストを書いてたりするのが、なんか泥臭くて面白いかなと思って。

背景

  • 自動テストが全くないプロダクト
  • God コントローラー(1000行以上ある)
  • 既にあるアクションに1つ機能を付け加える

こんな感じ

f:id:bufferings:20200809142428p:plain

ほえー

色々やる前に

さすがに神アクションに対して「Code & Fix (コードを書いてみて、動作を確認して修正すること)」はつらいので、PHPUnit を入れたいなと思った。

そう、対象のプロダクトは PHP で書かれてるんだけど、僕自身 PHP はあまり詳しくないので、PHP 自体やそのプロダクトが採用してるフレームワークの動きを確認しながら進めたいという気持ちもある。

実は、ちょっと前から PHPUnit の導入を企んでいて、ある程度調査してたから、ちょうどいいタイミングだし投入してみることにした。

なので、まずは PHPUnit をプロジェクトに追加して、Hello World 的なテストが動くことを確認しといた。ちなみにここが一番苦労した。既存のコードやデプロイフローに影響を与えない形で導入しておいた。

あとは楽しいだけ。

集中

さて、機能追加をどんな風に実装しようかな。やりたいことを考えてみる。いくつかの変数の値を元に(入力)、ごにょごにょ処理をして、結果として次の処理に渡す配列を生成すること(出力)ができれば良さそう。

本来なら、ビジネスロジックとしてコントローラーから切り離したいところだけど、そこまでやっちゃうと変化としてちょっと大きそう。だから、今回は「PHPUnit の導入」だけに集中する。これだけでも十分大きな変化だろう。

だから、新たにビジネスロジックに切り出すのではなくて、これまでのやり方に合わせて GodController の中のプライベートメソッドとして実装することにしよう。

プライベートメソッドA

じゃ、そのプライベートメソッドAに対するテストを考えてみる。ちなみに、アクションに対するテストは、現時点では難しそうだから今回は考えない。

んー。メソッドAに対するテストかぁ・・・。でかいな。Aの中には、B・C・D・Eみたいなロジックが入りそう。それぞれ別のメソッドに切り出したいな。メソッドEが一番簡単だし重要だから、そこから始めるとシンプルで良さそう。

f:id:bufferings:20200809153049p:plain:w300

機能に対するテストクラス

メソッドEのテストを書いてみよう。渡したオブジェクト2つの特定のフィールドが同じ値を持ってたら true を返すメソッドを作りたい。

GodControllerTest を作って・・・いや、ちょっとこれ名前がでかいな。んー、普通はテスト対象のクラスと1対1でテストクラスを作るところだけど・・・テスト対象のクラスがでかいからな・・・今回は機能を表すクラスにしとこ。GodControllerFeatureATest クラスを作った。よし、テストメソッドを書こ。

プライベートメソッドのテスト

んだけども、メソッドEってコントローラーの中のプライベートメソッドだから、どうしようかな。

リフレクションで呼び出すのも一つの手だけど。。。ちょっと本質的なところから遠いから、とりあえずもっと簡単な方法ないかな?

コントローラーにパブリックメソッドとして実装するのもいいけど、もっと気楽に、まずはこのテストクラスの中に実装を書いてしまおっと。こんなイメージ↓

f:id:bufferings:20200809153533p:plain:w300

動作するテスト

やっと最初のテストを書けそう。2つのオブジェクトを渡すと false が返される。。。と。

で、まだ実装がなくてエラーが出るから、クイックフィックスからメソッドを生成して。

とりあえず true を返すようにして、実行。よし。 予定通りレッド。

次は false を返すようにしてグリーンになった。

テストはちゃんと動いてるみたいだな。良かった。

ここまでで「テストが動く」ことが確認できた。

f:id:bufferings:20200809153924p:plain:w300

実装

特定のフィールドが同じ値を持ってるオブジェクト2つを渡すと true が返される。。。と。実行してレッド。

じゃ、比較の実装を入れよっと。はい、グリーン。

不安をなくす

特定のフィールドの中で1つでも異なる値を持つオブジェクトを渡すと false が返される。。。と。実行してグリーン。

ふむ。ちょっと順調すぎるけど、シンプルだからそんなもんかな。いくつかパターンを書いて全部グリーン。

え?ちょっとレッドになるか、フィールドの値を変えてみよっと。お、よかった。レッドになった。

じゃ、メソッドEには不安はもうないな。

f:id:bufferings:20200809155159p:plain:w300

他のメソッド

他のメソッドB・C・Dもそんな風にテストと実装を書いた。まだメソッドAのテストと実装は書いてない。ここでB・C・Dの実装はイケてないなぁ、もっと良い実装方法がありそうだよなぁ、と思いつつ、ただ動きはするから、まずはキレイにするよりは前に進めることに集中することにする。

リフレクションユーティリティの導入

じゃ、今テストクラスに実装したメソッドB・C・D・Eをコントローラー側に移動しよっと。

まずはリフレクション用のユーティリティメソッドを作って・・・と。で、コントローラー側にメソッドEを置いて、リフレクションユーティリティ経由で呼び出して、テスト実行・・・OK全部グリーンだ。

念の為、ちょっとメソッドEの中身を変えてみよっと。お、良かった。テストがレッドになったや。

他のメソッドも移動して、テスト実行。全部グリーンね。安心。

f:id:bufferings:20200809155845p:plain

メソッドAを作成

メソッドAのテストについて考える。全然関係ないけどここでペアプロを始めた。

メソッドAはその中でB-Eを呼び出して、結果を返す。

メソッドAは、いくつかの変数の値を元に(入力)、ごにょごにょ処理をして、結果として次の処理に渡す配列を生成する(出力)

じゃ、まずは空の配列を返すテストを書いてレッド→仮実装(単に空の配列を返す)→グリーン。で、メソッドAの実装を書く。単にB-Eを呼び出すだけだから簡単。はい、グリーンのまま。

メソッドAの他のテストを書く

既にあんまり不安はないけど、メソッドAに対するパターンを考えて、テストを一個ずつ実行しながらペアと交互に書いていく。

全部グリーンになったや。これで動作する実装は終わりだなー。

f:id:bufferings:20200809160631p:plain

メソッドAのテストをリファクタリング

メソッドAのテストは、パターンとしては大体網羅されてるけど、まずは実装することを重視したから、テストコードをキレイにして、意図が伝わるようにしよう。重複を取り除いたり、テストメソッドの名前を変えたり。都度グリーンをキープしながら。

よし。終わった。・・・ん?俯瞰して見ると、こういうパターンもあった方がいいな。足しとこ。逆に、このケースは冗長だな。消しとこ。

これでメソッドAのテストは「動作するキレイなテストコード」になった。良い感じ。

f:id:bufferings:20200809160925p:plain

要らないテストを削除

ここまで、メソッドEから始めて、一歩ずつテストを書いて、動作を確認しながらだったから、安心して最終的にメソッドAを実装することができた。

でも、メソッドAのテストがあれば、メソッドB-Eのテストって、要らないし、あると逆に邪魔になる。だから、削除しよっと。

ただ、その中でも、メソッドEのパターンは、メソッドAのテストだけだとカバーしづらいから、キレイに書き直して残しておこう。

最終的に、メソッドAのテストと、メソッドEのテストが残った。3ヶ月後の自分に意図が伝わる最小限のテストになったかな。これで安心して忘れられる。どっちもプライベートメソッドに対するテストだけどね。

f:id:bufferings:20200809161254p:plain

本実装のリファクタリング

さて、メソッドAのテストが揃ったから、本実装をリファクタリングしちゃおう。

B・C・Dの実装がイマイチだとずーっと気になってたから、メソッドFを作ってそっちにまとめてしまおっと。やっぱりこの方が読みやすいな。

メソッドAとEのテストはグリーンのままだから大丈夫。

f:id:bufferings:20200809161756p:plain

ということで

楽しかったー。安心して眠れる。みたいな気持ち。