この国では犬が

本と芝居とソフトウェア

チームフロー

この記事は、Uzabase Advent Calendar 2021の25日目の記事です。
昨日は、sefwgweoさんの「Androidアプリのログが正しく送信されていることを担保する」でした!


私たちは、ソフトウェアエンジニアとして、日々チームで成果を届けている。そこには、「(個人の)フロー」ならぬ、「チームフロー」とも呼べるものがあるように思える。
その生活の様子を覗いてみよう。

〜〜〜

朝9:30。チームの4人が集まってきた。

みんな「おはようございま〜す」

いわゆる朝会をやる。

4人それぞれがなにか一言二言喋ってから、共有事項があれば共有する。
ここで質問したり、助けを求めたりすることは少ない。そういう事案が生じたら、いつもその場で解決しているからだ。
だから、朝会はたいてい5分以内、短いときは2分くらいで終わる。

チームのタスクボードに、今やっている仕事と、これからやる仕事が並んでいる。
さっそく、それぞれのペアで何をやるかを決めよう。私たちはいつもペアで仕事をしているので、2つの仕事を選ぶことになる。*1

Aさん「あ、僕このWIP*2のやつやりたいです。Clojure触りたいんで」
Cさん「Bさんどうします?」
Bさん「じゃあ私がそっち入ろうかな」

Aさんがやりたいというので、あとの3人はその意志を尊重することにする。
昨日その仕事に仕掛っていたBさん、Cさんの2人のうち、Bさんがそちらの仕事に残ることにした。

Cさん「おっけ〜」
Dさん「じゃ、僕らはこっちですかね」

ちょうど昨日帰る前に1つの仕事を終えたところだったので、WIPは1つしか残っていなかった。
残されたCさん、Dさんの2人は、次の仕事に取り掛かることにしたのだ。

f:id:enk_enk:20211225124023p:plain
AさんとBさんが仕掛中の仕事、CさんとDさんは新しい仕事

Cさん「なるほどこれね〜」
Dさん「じゃE2E書いてきますか」
Cさん「ほいー」

仕事は常にテスト駆動開発、アウトサイドインで進めているので、新しい仕事はE2Eテストから始まる。*3
事前の仕事の洗い出しと見積もりはチームでやっているので、だいたいの内容は既に把握できている。

Bさん「今ハンドラからユースケース呼ぶとこまでできてて、ユースケースのテストからって感じです。書いていきますね」
Aさん「了解でっす」

こちらも始まった。
個々のモジュールもやはりテスト駆動開発、アウトサイドインなので、仕事を再開するときはだいたいこういう会話になる。

【10分後】

Bさん「あれ。ネストしたmapの値置き換えたいときってどうするんだっけ? assoc-in? update-in?」
Aさん「update-inじゃないですか? でも自信ないんでClojureDocs見ますか」
Bさん「(見る)んー、この例の(update-in p [:age] inc)ってどういうことなんだっけ……」
Aさん「Cさんに聞いてみますか。Cさ〜ん」

CさんはClojureが得意なので、Cさんに聞けばすぐにわかると思ったのだ。

こんなしょうもないことを聞くのか? ClojureDocsをちゃんと読めばわかるようなことを。
こんなしょうもないことでも聞く。それがチームの学習とフローを最大化させる、最善の選択肢だと信じているからだ。

Cさん「何?」
Aさん「ネストしたmapの値置き換えるのってupdate-inでしたっけ」
Cさん「そうだよ」

話の内容を耳で半分だけ聞きながら、この間もDさんはE2Eを書き続けている。
ClojureのことならCさんに任せておけば安心だし、DさんもClojureは苦手ではないので、しっかり手を止めてまで聞くほどの内容ではなさそうだと判断したのだ。

Aさん「置き換えたいだけなんですけど、最後の引数がよくわかんなくて」
Cさん「最後の引数は関数だから。元の値を受け取る関数。どういう値で置き換えたいの?」
Aさん「別のmapから取ってきた値で」
Cさん「関数だから、無名関数書けばいいよ。あ、でも、元の値使わないならassoc-inでいいんじゃない」
Aさん「! あ〜。そういうこと。そっか。完全理解。ありがとうございます」
Bさん「ありがとうございまーす」

この間30秒。
一方のDさんの仕事は少しだけ進んだみたいだ。

Dさん「さっきのアサーション書いてみたんですけど、ちょっと迷ってて……」
Cさん「お〜それね。そうなるよねえ」

Dさんは2人の(Cさんと、Dさんの)仕事のコンテキストを保持し続けているので、Cさんは瞬時に元の仕事に戻ることができた。

こうして、2つのペアの仕事は淀みなく続いていく。

【50分後】

Aさん「っしゃ通った〜い」
Bさん「通りましたね〜」

テスト駆動開発なので、テストが通ったら完了だ*4。CI/CDパイプラインを流して、通ればリリースできる。

終わった仕事の付箋を、タスクボードのDoneのレーンに移動する。

Aさん「休憩しましょう!」
Cさん「おっけ〜」
Dさん「はいー」
Bさん「パイプライン流しときました」
Aさん「では10分後」

だいたい1時間くらいで休憩を入れる。都合よく今やっている仕事が片付いたので、みんな休憩することにした。
Cさん、Dさんの仕事は完全に仕掛り中だが、常にペアはローテーションしていくため休憩後はペアを交代したいので、仕掛り中でも構わず休憩に入る。どちらかは同じ仕事に残れるし、離れた方も近くに座っているからわからないことがあれば聞けばいいので、あまり気にしない。

【10分後】

休憩が終わって、みんなが集まってきた。

Aさん「じゃ、やりますか」
Bさん「次これですかね」
Cさん「そうだね」
Dさん「どうします?」

Aさん、Bさんがフリーになるので、どちらかが新しい仕事に取り掛かり、どちらかはCさん、Dさんがやっていた仕事を引き継ぐことになる。

Cさん「うーん、残りたいかな」

Cさんは仕掛りの仕事を続けたいようだ。

Dさん「いいですよ、じゃあ新しい方やります」
Bさん「お。じゃあ私もそっち行きますね」

Bさんは新しい方の仕事を選んだ。
仕事の内容というよりは、昨日Dさんとペアにならなかったので、Dさんとペアになれる機会を選んだのかもしれない。

Aさん「おっけー。さっきのやつそっちでリリースしてもらえます?」
Bさん「了解です」

先ほどDoneにした仕事のリリースはBさんのペアで担当することにした。
流しておいたパイプライン*5が通ればリリースできるので、パイプラインを確認して、通っていればリリースしてから次の仕事に取り掛かることになる。

f:id:enk_enk:20211225130031p:plain
AさんとCさんが仕掛中の仕事、BさんとDさんはリリースしてから新しい仕事

こうして2コマ目が始まった。

【20分後】

Eさん「Dさんちょっといいですか?」

別のチームのEさんがやってきた。

Eさん「Kotlinのlistを連続してmapしたときって、都度新しいリストのオブジェクト作られるんでしたっけ」
Dさん「そうですね」
Eさん「あれ、作られないようにするやり方なかったですか?」
Dさん「それやりたかったらasSequence呼びますね。ただ件数がそんなになければ気にしなくていいかなと」
Eさん「あ〜、あったなそういうの。うーんなるほど。件数ってどれくらいかわかります?」
Dさん「昔パフォーマンス見てみたことあって、〇〇件とかなら誤差のレベルだったと思います」
Eさん「なるほど、じゃあ大丈夫ですね。ありがとうございます〜」

この間やはり30秒。

EさんはDさんがKotlinに詳しいことを知っていて、別のチームから聞きにきた。
この間も、Bさんは2人の(Dさんと、Bさんの)仕事を進めている。

最初にチームの4人と言ったが、実は、他のチームのメンバーも同じチームという意識で仕事をしている。
だから、当然のようにちょっとしたことを聞きに来たり、聞きに行ったりする。それがチームの学習とフローを最大化させる、最善の選択肢だと信じているからだ。

【同じ頃】

Aさん「あれ、この値ってそもそもどういう範囲を取るんですっけ」
Cさん「んーわかんないですねえ。たしかXXXチームが前やってましたよね。FさんかGさんいるかな」
Aさん「いってみますか。あ、いた。Fさ〜ん」

AさんとCさんは、データの仕様でわからないところが出てきたので、2人でFさんのところへ聞きに行った。
このように、2人で行動することもある。今やっている仕事についての情報を得たいときは、そうすることが多い。

...

そうこうしているうちに、お昼になった。

Cさん「昼行きますか」
Aさん、Bさん「はーい」
Dさん「いってらっしゃ〜い」

お昼はチームで一緒に行くことが多い。日によっては、それぞれ自由に他のチームの人と行くこともある。
Dさんはお昼を食べないタイプなので、いつも席で本を読んだりしている。そのあたりはもちろん自由だ。

...

そして午後も開発は続く。
今は再びAさんとBさん、CさんとDさんのペアで開発しているようだ。そんな折。

Bさん「あれ。ちょっと思ったんですけど、この持ち方だと市場変更のケースで困りません?」
Aさん「おお……? 確かに。更新すると古いほうが消えちゃうし。まいったな」
Bさん「そのケース想定できてなかったんですかねえ」
Aさん「ですかねえ。変更したほうがいいかなあ」
Bさん「相談してみますか。CさんDさん、ちょっと相談したいことが……」

ちょっと大きめの設計の議論が必要になった。(今回は、DBのスキーマの設計だ)

仕事の細部はペアで決めてどんどん進むことの方がずっと多いが、今取り組んでいる仕事の全体に関わるような設計の議論は、4人集まってすることが多い*6
そういうときも、こういう風に気軽に声をかけてその場で議論を始める。

Cさん「はい」
Bさん「今って、(おもむろに立ち上がって、ホワイトボードに書く)こういうスキーマになってるじゃないですか(みんなも立ち上がってホワイトボードに集まる)。で、この持ち方だと市場変更のときうまく対応できないんですよね」
Cさん「おお〜。確かに」
Dさん「ふむふむ」
Aさん「そもそも市場変更したときってどうなるのがいいんですかね」
Dさん「戻ってくることがあるのかとかも気になりますね」
Bさん「ていうか、そもそも企業と証券って1対1なんですっけ?」

スキーマの設計というよりは、ドメインの理解に話が波及していきそうだ。
そういうときは、エンジニアに限らず、そのドメインに詳しい他職種の人を呼んでくることも多い。

【30分後】

Cさん「お〜。完璧じゃん」
Dさん「やりましたね〜」
Aさん「Bさんのアイデアが完全に天才でしたね」

議論に30分かけて、ドメインの理解が進み、発展に耐えられそうなDBスキーマの再設計を行うことができた。

その間開発は止まってしまったが、チーム全員のドメイン理解が深まり、今後不安なく開発を進められることを思えば安い代償だ。
ときには、このように勇気を持って立ち止まることも重要だ。

Bさん「いったん休憩入れましょうか」
みんな「ですね!」

...

このあとも何度かペアを交代しながら、開発を進めていく。やがて18:30になった。

Aさん「時間ですねえ」
Dさん「これ通ったら勝ちなんだけどな〜!」
Aさん「5分だけやります?」
Dさん「そうしましょう」

AさんとDさんのペアは、もう少しで今やっている仕事が終わるようだ。

この働き方は体力を使うので、いつも8時間働いたら終わりにしている。
とはいえ、このように5分程度は融通をきかせることもある。

Bさん、Cさんも2人の会話を聞いていて、あわせてあと5分だけ続けることにした。

【5分後】

Dさん「ぐわー! こっちのポートが未実装だった」
Aさん「でしたね〜」
Dさん「まあでもキリはいいかな」
Aさん「終わりますか」

これで終わりだと思っていたら、もう一箇所開発が必要な箇所が残っていたようだ。残念。
とはいえ定時を回っているので、これ以上の深追いはせず今日は潔く終わりにする。明日もまた一日、元気に働くためだ。

Bさん「はいー」
Cさん「おつかれ〜」

もう一つのペアもあわせて終業。
今日もいい汗書いた*7。解散、また明日。

〜〜〜

こんな感じで日々仕事をしている。

4人のチームで、常にコミュニケーションを取りながら淀みなく成果を届けていくイメージだ。*8

さらに、他の多数のチームとも常にゆるくつながっていて、いつでも気軽に連絡を取り合う。
Eさんが来たときや、Fさんのところへ行ったときのように。

だから、結局のところ「4人のチーム」というよりは、むしろそういったチーム、「の集まり」がチーム、といったイメージのほうが適切かもしれない。その「チーム全体」で、フローを生み出し続けている。

ここでは描かなかったが、もちろん、チームでビジネスサイドの人たちと話したり、ふりかえりをしたり、時にはユーザと直接話したりといった時間もある。開発だけでなく、サービスの運用も行っている。
言われたものを作る開発チームではなく、ビジネスに直結したプロダクトチームになろうと日々努力している。

この働き方は、楽しい。

たぶん、自然で、無理がなく、かつ連続的に小さな成功を繰り返していけるからだ。

この働き方は、持続性が高い。

ドメイン知識も技術力もある1人のエンジニアがヘッドフォンをつけてひたすらコードを書き続けたほうが、もしかしたらデリバリーのスピードは早いかもしれない。
しかし、そのエンジニアもいつかはいなくなる。そのエンジニアが長期休暇を取れば、その間仕事は止まる。そのエンジニアはドメイン知識と技術力をさらに深めていくかもしれないが、その知識が他のエンジニアに(少なくとも自然に)広がることはない。そのエンジニアが他のエンジニアから学ぶこともない。

私たちのやり方は、日々を楽しく過ごし、個人としても組織としても持続可能なかたちで成果を届け続けるやり方だ。
このやり方は、XP(Extreme Programming)と呼ばれている。*9


こういうチームで仕事をしてみたい! という方、もしいたらぜひ一緒に働きましょう。

apply.workable.com

いきなり応募するのはハードルが高い、まずは気軽に話を聞いてみたい……ということであれば、Twitterでメンションいただけると幸いです。

twitter.com

最近出たこの記事で紹介している「組織のカオスエンジニアリング」が支障なく行えているのも、こうした働き方に負うところが大きいと思います。

hatenanews.com

*1:ここで「仕事」と呼んでいるものは、実際にはユーザーストーリーだ(タスクではない)。ただし、かなり細かく分割していて、1つのユーザーストーリーをだいたい半日〜一日でリリースすることが多い

*2:Work In Progress。仕掛り中、ということ。タスクボードにそういうレーンがある

*3:実践テスト駆動開発』で示されているようなワークフローに近い

*4:テストが通ったあとにリファクタすることもある。ただ、リファクタ自体もこまめに行なっているので、最後の最後はテストが通ったら本当に終わりというケースも少なくはない

*5:ビルド、ユニットテスト、E2Eテスト、イメージのタグ付けという一連の流れを自動的にやってくれる。ちなみにこれもチームで作ってメンテしている

*6:よくあるのは、APIのリソースのパス、DBのスキーマ、コードのドメインオブジェクトの集約の切り分け方、マイクロサービス間での責務分担等

*7:残念ながらあまり身体は動かさないので、頭に汗かいた、という感じ

*8:4人というのは平均的な数で、実際には3人の場合もあれば、5人の場合もある

*9:もちろん、この1日にXPのすべてを表現し尽くせたわけではなく、コミュニケーションの価値を中心にごく一部を表現したにすぎないので、その旨ご了承ください