TDDなぁって

f:id:bufferings:20171127230403p:plain

ぼーっとしながら思ったのは。バグが認識のズレの中に隠れてることって多いよなぁって。ビジネスの人の頭の中と、デザイナーさんの頭の中と、デベロッパーの頭の中で、それぞれ違うものを思い描いてたりする。だから、ユーザーストーリーマッピングとか、プロトタイプとか、あとはユビキタス言語とかで、認識の違いに早い段階で気づけるといいんだろうなぁって。

もうひとつある

f:id:bufferings:20171127230902p:plain

認識のズレって言うと、もうひとつあるなぁって思った。デベロッパーの頭の中とコードの間。TDDの「動くコード」というのは、このデベロッパーの頭の中とコードの間の認識のズレをチェックしてくれるよなぁって。思った。でも、それだけじゃなくて。

きれいなコード

TDDだと、その動くコードをキープしたまま、きれいなコードにしていけるなぁって。テストからじゃなくて、設計から始めると「きれいなコード」から始めてしまうだろうから、使われることのない機能をきれいに作ってたりするよなぁって。だから「動作する」が先で、それに必要な分だけ「きれいに」していく、ってのはいいなぁって。

とは言いながらも

TDDに関しては、自分の中でちょっとふんわりしてる。どうなんだろうなぁって。今日はもう寝ようかな。

広告を非表示にする

新訳版『テスト駆動開発』読んだ。良かった。

books.rakuten.co.jp

和田さんによる新訳

t-wada.hatenablog.jp

結論から言うと、てか、もうタイトルに書いちゃったけど、すごく良かった。

前の翻訳本を10年以上前に読んだことがあるんだけど、自分がこの10年間で色々学んだり経験してきたりしたこともあって、たぶんその時とは全然読み方が違うんだろうなと思う。「あぁ、分かる」とか「あぁ、それ悩んでたけど、そういう風に考えるのかぁ」とかため息をつきながら読んでた。最近そういうのばっかりだなw

すごく読みやすかった

タイトルが分かりやすかったり、画像が現在のツールに差し替えられていたり、原書にはないコードまとめがあったりで、すごく読みやすかった。きっと、僕が気づいていないようなところも色々と読みやすくしてくれてるんだろうなぁって感じた。

写経

第1部はKentとペアプロしている気分で実際にコードを書きながら読んだんだけど「えー、それだと副作用があるよ?」とか「その判断を後回しにするの?」とか「なんで、そこでその発想が出てくるの?」とか「実際のところ、あのコード書いた時にこうなること分かってたでしょ!」とか楽しかった。

github.com

過去から現在へ

翻訳者の和田さんから「テスト駆動開発の現在」というタイトルで、原書出版後の15年間の出来事と現在の状況についてのお話が最後にあって、これがすごく良かった。それまでは15年前の話だったのが、一気に現在まで連れて来てくれた感じ。

もう何度か読んでみたり、Spockで書いたりしてみようかな。

あ、あと、写経してて気づいたんだけど、一箇所だけ本に書いてある通りに書いても、その通りにならない部分があったから、これから読む人は探してみて!(2017-11-27 追記: 和田さんから教えていただきました。原書で使用していたJUnit3と、新訳版で使用しているJUnit5ではその通りになるけど、JUnit4だとその通りにならないそうです。納得感。ありがとうございます!「第3版では変更しようと思います」とのことです。)

#jjug_ccc 僕がDDDを勉強したりDomain Event使ってみたいと思ったりKafkaでCQRSの素振りをしている背景と現状

11/18(SAT)にJJUG CCCという、日本のJavaコミュニティの最大規模のカンファレンスで発表してきましたー。1000人を超える申し込みがあるような感じです。そんな場で登壇させていただいて幸せです。

www.java-users.jp

僕のセッションにも

沢山の人が来てくれました。ありがとうございます(∩´∀`)∩ワーイ

f:id:bufferings:20171120215259j:plain

お話しした内容は

この記事のタイトルの通り、僕がDDDを勉強したりDomain Event使ってみたいと思ったりKafkaでCQRSの素振りをしている背景と現状についてです。スライドはこちら。

speakerdeck.com

セッションに参加してない方にも喋った雰囲気が伝わるといいなと思って、コメントを加えたりしてみました。スライド内のリンクをクリックしたい方はSpeaker DeckからPDFでダウンロードができるのでそちらをどうぞ。

デモプロジェクト

もアップロードしておきました。

github.com

みんなやさしかったー

嬉しくてトゥギャっといた。

togetter.com

一番うれしかったのは

あこがれてたのでした。幸せ。ありがとうございました!


次のJJUG CCCは

お客さんで来るぞー!やっぱり発表するってなると他のセッション聞く心の余裕が全然なくて。見たかったセッションがいっぱいあったのだけど無理だったや。

次発表するときは

実践の話ができるようにがんばりたいな。

緊張してたら

みんなが優しく「がんばれ」って応援してくれたのが幸せでした。

チームリーダーをやるときに気をつけてた「4つの混ぜない」

開発チームのチームリーダーやってたときってどんなこと考えながらやってた?って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。

4つの混ぜない

やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。

帽子を混ぜない

エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな:

  • 組織マネージャの帽子で
    • 後輩の育成や組織としての成長を考えたり
  • 開発リードの帽子で
    • クオリティの最後の砦みたいな役割や、チームの外との調整をやったり
  • プロジェクトマネージャの帽子で
    • プロジェクトをどうやってうまく回していくかを考えたり

なので「今の自分の気持ちはどの立場の帽子から来てるっけ?」ってのをよく考えた方が良くて。混ぜると良くないなって思った。

例えば組織マネージャとして「メンバーにはプロジェクトの中でスキルアップして欲しいな」って思ったあとに、プロジェクトマネージャとしてプロジェクトのことを考えてるときに「メンバーが育つ」ってのが残ったまま考えると「メンバーが育つことでプロジェクトを成功させなきゃ!」みたいになって良くない。

プロジェクトを成功させるために考えるのは「今のチームが持っている力を最大限発揮して、うまくプロジェクトを回すにはどうすればいいか?」よね。メンバーの成長はそれとは切り離して「このプロジェクトを通してこういうことを学んでいこうね」って1on1で伝えてあげなきゃ。そんな感じで考えてたかな。

それぞれの帽子でモチベーションと目的が違うからね。混ぜると良くない。

チームの目標と現状を混ぜない

チームとしてここを目指したい!という目標やビジョンを立てるのは大切で。なんだけど、それと同時に現状を認識しなきゃいけない。現状を受け入れずにいると「どうしてこのチームはそこにいないんだ!」ってイライラしてしまうから。そういうの良くない。イライラしてもチームは良くならないもんね。

目標は目標で持っといて。それとは別で「じゃあ、今の僕らはどこにいるんだっけ?」って現状を受け入れて。そこから一歩進むことを考える。んで、一歩進んだら、そのことを喜ぶのが良いなって思う。

「まだまだ目標に対しては全然マイナスだ!」って全然ほめない人たまにいるたりするんだけど、そういうのは家でひとりでやっといたらいいのにって思うよね。

チームとメンバーの目標を混ぜない

チームとして進む道を考えたとして。それをメンバーに押し付けるの良くない。押し付けるんじゃなくて、その道を進むことでメンバー個人個人にとっては、どんないいことがあるのか、を伝える。チームがこうなっていく中で、こんなスキルを身につけていけるよね。とか。

だから、自分が思っているのと違う行動をメンバーが取ったときは「こっちに進んでよ!」って指示するんじゃなくて「そのメンバーの目標をどこに設定したら同じ方向に進めるか」みたいなのを考えるのがいいかなって。

相手と自分を混ぜない

最後はこれ。

僕だったら自分で調べるのに。とか。僕だったらこう言われたら少なくともここまでやるのに。とか。僕が5人いたらもっと速く開発できるのに。とか思ってもしょうがないね。

あ、新大阪ついた。じゃノシ

開発者とテスターの間にある本「初めての自動テスト」を読んだ

「初めての自動テスト」を玉川紘子さんからいただいて読みました。色んな気づきがあって面白かった!僕は今ちょうど部署全体の自動テストへの取り組みについて考えてるところだったので、頭の中の情報整理になりました。

books.rakuten.co.jp

原著の著者は、アジャイルサムライの著者のジョナサン。絵がかわいいし、会話形式で進んだりするしで、楽しみながらあっという間に読めました。あと、ジョナサンが優しい。ちょっと難しそう?ってところとかはちゃんと「今は全部分かってなくても大丈夫」とか言ってくれるの。

でも正直なところ、彼がWebシステムの自動テストを始めたい人を対象にして書いたってのは、ちょっと意外でした。アジャイル関係の本とか、その周りのプラクティスの話だったら分かるんだけど、どうしてテスター向けの自動テストの入門本なんて書いたんだろう?って。でも、読み終わってみて、なんとなくこういうことなのかなって思いました。

あ、その前に

この本は「自動テストについて全く知らないテスター」に自動テストについて教えていく物語です。僕の中のテスターは「開発者よりも自動テストに詳しい人たち」なんだけど。そういう人たちは対象じゃない。ま、タイトルからしてそりゃそうかw

開発者とテスターの間にある本

んで、なんで書いたんだろう?って話ですが、最近は僕の周りでも普通にアジャイルとかスクラムとか聞くようになってきて、自動テストも普通に取り組むようになってます。そうなると、テスターに求められるものも変わってきてるんだろうな。と思いました。

開発者とテスターは自動テストを中心にお互い協力して、より良いサービスを開発・運用していかなきゃいけない。ってなったときに、自動テストについて全然知らないんだけど勉強したいな!と思ったテスターに渡してあげるための本。という感じ。

アジャイルが普通になってきたから、次のステップとしてテスターも開発チームに巻き込みながら自動テストに取り組んでいこう、という流れは自然だなって思いました。そんな本書を、僕がオススメしたいなと思うのはこういう人たちです。

自動テストについて学びたいテスター

これはこの本のメインのターゲットですね。UIテスト、IT、UTからなる自動テストのピラミッドを、開発者とテスターでどう協力して進めていけばいいか。そもそもそれぞれがどういったテストなのか。を、実際の例やコードを交えながら丁寧に教えてくれます。

自動テストの知識の整理をしたい開発者

テスターを中心にして話が進んでいきますが、結局のところ土台にあるのは「開発者とテスターがどのように協力して自動テストを作っていくか」ということなので、自動テストについてまだあまり良く知らない、UT、IT、UIテストをどんなことに気をつけながら書いていかなければならないかがまだ良く分かっていない、という開発者にとっても得るものが沢山あります。特に1章・8章・第二部。

組織として自動テストに取り組みたいマネージャ

組織としてアジャイルに取り組みたい、自動テストに取り組んでいきたい、という中で、特に、プロデューサーからマネージャになった人や、エンジニアとして一昔前に活躍していたけど今はマネージャをやってる人など、これまで自動テストを悩みながら書いた経験のない人は読んでおくと良いなって思いました。

開発者やテスターがどんな風に自動テストへ取り組もうとしているかを理解し、それを組織としてどのようにサポートしていくべきかなどの決断をしていく際に、自動テストの良い点や難しい点について知っているととても役に立つだろうなと思います。

チームにテスターを受け入れたいチームリーダー

自分のチームにテストロールのメンバーを迎え入れたいチームリーダーは、そのテスターにとってどういう情報が必要なのか、何をどのような順番で伝えてあげればいいのか、を知ることができます。たぶん、チームリーダーやってる人は自動テストとか自分の中で自然すぎて、何から伝えればいいかが悩むだろうなって思うから。

あ、本の内容について触れてなかった

本書では、UIテスト・IT・UTそれぞれの自動テストについて、どのような目的のために、どのような方向性で実施していくか、という「考え方に重点を置いて」テストのピラミッドを中心にしてお話してくれます。具体的な実装方法や技術の詳細については対象外となっています。

第一部では、簡単な例やコードを示しながら、基礎的な部分から丁寧にひと通り説明してくれます。開発者としてはHTTPの説明やRESTの説明など「それは今更いいかな」というのもあるのでその辺は流し読みで良さそうです。

第二部では、「あぁ確かに、自動テスト書き始めたら次はこの辺で悩むよねー」って話に触れてくれてます。テストのコードも読みやすく書くとか、そのためにリファクタリングするとか、モックの使い方とか。TDDとか。

全体的に広く浅く書いてあるので、入門書としては読みやすくて良いですね。

個人的に好きなところ

  • 訳注: 確かにそれ説明してくれてたら分かりやすいなー。みたいなのがちゃんと書いてある。
  • 戦いのストーリー: ジョナサンの失敗談とかが書いてある。あるあるwwって思いながら読んでた。
  • 「自動テストの存在しない巨大なレガシーシステムを扱うときには逆ピラミッドでやってみる価値があるかもしれません」って書いてあって良かった。僕の感覚もそう。通過点なんよなってのもそう。

修了証

げっとー(∩´∀`)∩ワーイ

f:id:bufferings:20171106000216j:plain

おもしろかったー!

読みやすいコード(僕にとって)

最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。

話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。

色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。

なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。

そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。

JavaでWebのアプリを開発してる。基盤とかフレームワーク側じゃなくて、それを使う方のコード。

適切な・統一的な名前がついていること(Ubiquitous Language)

変数とかクラス名とかメソッド名とかそういうのに適切な名前がついてると読みやすくて嬉しい。3,4行の処理に名前をつけてメソッド化したりしてるとすごく読みやすい。欲を言えば、それが仕様書でも同じ名前が使われてて、さらに喋るときもその名前で会話ができてると、隠された概念にもすぐ気づけていい。

ひとつのことだけをやってる(SRP)

僕が混乱し始めるしきい値がある。それは「3」。3つ以上のことを同時に考え始めると。ぷしゅーってなる。

ひとつ、というのは心が落ち着く。コントローラーは入力値のチェックだけを。ユースケースは機能を実現することだけを。プレゼンターは結果をビューに返すことだけを。やってくれていると幸せ。2つ以上のことをやると、片方の処理には関係ないものもまざってきて、それがこの処理に必要だからあるのか、もう一つの処理のためのものなのか。3つ以上になると、最初におぼえていたものが、溢れて消えていく。ので、ひとつのことだけをやってるクラスやメソッドが好きです。

イミュータブルである

イミュータブルだと心が落ち着く。だって、もう変更されることがないんだもの。最初に完璧な形になってるとか幸せ。setterがあると混乱する。い、いったい、いつこのsetterは呼び出されるんだ!?ってドキドキしながら読むことになってつらい。LocalDateやBigDecimalは好き。Value Objectの集まりは、いくつあっても安心していられる。

使いまわされない(final)

ひとつの変数が使いまわされて、色んな役割を担っていると、つらい。しっかりその都度ちゃんと適切な名前がついた変数が使われていると嬉しい。

必要かもしれないからってコードは必要ない(YAGNI)

使われていなさそうなコードがあると、誰がどんな風に使っているのかを探して回ってしまう。そのせいで、読みにくくなっていたり、余分な処理をしていたり、余分なテストをしていたりする。「将来的に必要になると思うから今入れておく」ってのは、使われないことが多いし、むしろ、そのときやりたいことの邪魔になったりするし、全然いいことない。「将来的に必要になる機能に備えて拡張ポイントを用意しておく」くらいまでで僕のキャパは限界である。

継承よりも実装や委譲

フレームワークとかで、継承を上手に使ってるなぁって思うときはあるんだけど。そのフレームワーク上で業務をコードに表すときに、継承ってつらい。抽象クラスも苦手。なんだろう?処理が飛び飛びになることとか。クラスの完全性みたいなものが壊れそうで怖いとか。そういうの。

継承じゃなくて、インターフェイスを実装する、って感じなら、全然気持ちが楽。インターフェイスで他のコンポーネントと話をするのがいいな。でも、複数のクラスで共通の処理を持ちたいときとかあって、そういうときは委譲を使うと読みやすくて好き。

処理の共通化じゃなくて意味の共通化

オブジェクト指向を勉強し始めると、似たようなコードは全て共通化し始めてしまうもんなのかな。意味とかコンテキストが全然違うのに「やってる処理が同じだから!」ってまとめてしまうと、ここを変更したいんだけど・・・影響範囲がが・・・。とかなって、結局他に影響しないようにって、ifを書いてしまうようになったりしてつらい。

共通化は、意味の塊での共通化がいいな。インターフェイスを経由して話ができる感じ。その向こうの実装を気にしなくていいような感じ。

関係のあるクラスを近くに

たまに、ひとつの処理をレイヤー分けしてるコードを見る。横に切ってる感じ。ビジネスロジックレイヤーが複数あったりするとだいぶつらい。一つの処理を理解するのにレイヤーを行き来しないといけない。それよりも、ひとつの機能を実現するためのクラス群が同じパッケージ内にあると嬉しい。

今日思いつくのはこんなところかな

適切な名前がついていて、ひとつの役割だけを担っていて、イミュータブルにできるものはイミュータブルになっていて、変数はfinalで、継承よりインターフェイスに対してコードを書いていて、処理じゃなくて意味が閉じ込められていて、関係のあるクラスが近くにまとまっていると、僕にとって読みやすいコードなので、みんなにとってはもっと読みやすいのかなー。

って思った。

あ、あと、型安全になっている。もだな。

RTCN2017・1時間スプリント・手触り・知識の共有

今年初開催となる名古屋支社の楽天テクノロジーカンファレンスに行ってきた!面白かったー!今、帰りの新幹線。僕は何かあったときに助けてねってくらいでいたんだけど、何もすることなかったし、みんな楽しんでたし、ピザとチョコとビールとチョコおいしかったし最高だったなー!スタッフのみんなも、来てくださったみなさんも、素敵でした!お疲れ様でした!

さて。そんな中、「名古屋に行くよー!」って言ってたら、なんと、きょんさんが遊びに来てくれて。しかも僕の相談に乗ってくれたのでした。幸せすぎた。ので、そのおすそ分け。

僕の相談?

こんな話:

  • どんな風に開発してる?
  • どこまで自動化してる?
  • TDDやってる?
  • 知識の共有をどんな風にしてる?
  • ドキュメントは書いてる?

どんな風に開発してる?

スクラムって最大30日で1スプリントとかいうよね。僕のチームはそれよりは短くて10営業日で1スプリントが多いかな。でも、まだ慣れてないときは1週間で1スプリントにしたりする。でも、1週間だと結構短くて大変。だよね。

そんな中。きょんさんのチームは、1日スプリントをやってたんだって!短っ!だけど、しばらく前にそれもやめて、1時間スプリントになったそうな。1日の始まりにDaily Planningがあって。1時間ごとにスプリントプランニング・開発・スプリントレビュー・レトロスペクティブ。1日の最後に、Daily ReviewとDaily Retrospective。

・・・エクストリームだな!

面白いなーって思ったのは、非同期のコードレビューがないこと。ペアでリアルタイムレビューしてそれでOK。んで、それをDaily Reviewで簡潔に説明してお終い。なるほどなぁ。非同期のレビューほど時間を食いつぶすもんはないもんなぁ。

このやり方の良いところは、1時間単位でピボットできるところ。1日で完結してしまうところ(夜頑張るとかできない)。1日単位で開発チーム内の知識が共有されること。らへんだよな。確かに、理にかなってるなー!って思った。

どこまで自動化してる?

ってのも聞いてみた。

「全然自動化してなくて、マニュアルテストですよ」って言うので「ほほー」って話を聞いてたら、UTは95%くらいを自動化、ITは30%、System Testは5%くらい。んー。結構自動化してるぞ。。。

というのは置いといて、自動化に頼るんじゃなくて最終的には「どれくらいシステムを手になじませるか」ってのを大切にしてるんだって。開発チームはずっとその対象のサービスを触り続けていて、それで手触りを感覚として身につけることを大切にしてる。

それ分かる気がする。結局、システム触ってて「あれ?聞いてると大丈夫そうなんだけど、なんか違和感あるぞ?」みたいな「感覚」で問題に気づくことが多いもんね。コードを読んでてもそういうところあるね。

それを「誰にでも分かるように形式知化しよう」とするんじゃなくて「みんながその感覚を持てるようにシステムをたくさん触ろう」というのは良いな。咳さんとみわさんのところにも近い雰囲気ある。

UTとITとかの定義って何?

きょんさんのとこでの、UTとITとかの定義って何?って聞いたら、

  • UTはデプロイ前
  • ITはデプロイ後
  • SystemTestは自分たちの管理外のシステムとの連携をするテスト

ふむふむ「UTの中でも仕様に対するテストとコンポーネントに対するテストとあるよね?」って質問したら。

  • 仕様に対するテストは、サービスレイヤに対するテストになり、それには5,6個以上のクラスが絡んでくる
  • その「仕様に対するテスト」では細かく見きれない部分として、「ログ」「例外」「並列処理」のテストを1,2個のクラスに対して実施してる

なるほどなぁ。確かに。「TDD的に進めると、あとで要らなくなるテストもあると思うけどどうしてる?」って聞いたら。

  • テストのリファクタリングを毎日の作業の中でやってる
  • その中で、不要なテストを削除したりもしてる

だって。いいね。

TDDやってる?

僕は最近あんまりTDD的に開発をしてないから、きょんさんとこはどんなんなんだろう?って聞いてみたら。「やってる」って。

というのもスプリントが1時間なので、彼らのタスクの粒度は分単位で。途中でペアの交代をしても「何をしようとしていたのか?」がテストとして先に表現されているようにする。んむー。良いな。

面白かったのは、個人個人がリモートリポジトリを持っていて、そこにpushしたコミットがCIを通ったらセントラルリポジトリに反映されるようにしてるってこと。だから、UTを通ってないコードはセントラルには反映されない。

知識の共有をどんな風にしてる?

ここまでの話でも分かるように、まずペアで作業をしてるのでその間で知識が共有されて、さらにスプリントが1時間単位なので1時間単位で作業の内容が共有されて、1日の終りには全員でコード共有が実施される。だから、少なくとも1日単位で知識の共有は行われる仕組になってるのだった。んー。面白い。

それに加えて、お客さんに成果を見せて信頼を得ることで、少しずつ「自分たちのスキルが上がる分だけより良いものができる」というのをお客さんや自社の上の方の人たちに理解してもらって、チーム内のスキルアップのための勉強に時間を費やすことができるようにしてる。

全てに明確なゴールを

徹底してるなぁと思ったのは、プロダクトオーナーとしての要望も、開発チームの作り上げるものも、スキルアップのための勉強会も、全て「目的、達成しようとしていること、そのためにやること」などを明文化して、共有してから始めているってところ。

自動化ひとつにしても「自動化したほうが便利だから」じゃなくて「今回かかる時間」「それによって具体的に何がどのくらい短縮されるのか」などを具体的な数字として表現するようにしてるところ。

バグチケット

これも面白かった。バグはもちろん、コードへの指摘も全部、バグチケットとして起票するんだって。んで、それを修正したらクローズするんだけど。このバグチケットを毎朝読み合わせるんだって。んで、ずっとやっていったら全部読み終わるから、そしたらまた最初から読み直すんだって。んで、これだけは定量的にではなくて、定性的にタグ付けをしてる。「なんかやばそう」「変だった」「重要そう」みたいな。

そういう風にしておいて、読みあわせをすることで「過去に僕らはどんなバグを作ってしまったか」「どんな指摘をコードに対して受けたか」みたいなのをチームの中で共通認識として得るんだって。確かにこれはいいなー。過去のバグを知っているかどうか、で気づけることもたくさんあるもんね。これも「手触り」の部分につながるね。

ドキュメントは書いてる?

基本的にはチケットはタスクの管理にだけ使ってて情報はそこには書かない。後に残しておきたい情報は必ずWikiにまとめる。んだって。これは僕も同じだなー。僕の場合は、タスクの管理は付箋でやってたりもする。チケットやチャットは流れていくもんだもんね。

ただ、バグチケットだけは上記の通り、別扱い。

んで、ドキュメントはめちゃくちゃ書いてるんだって。ふむふむー。

面白かったー!

まだ今は「きょんさんはそういう風にやってるのか!いいなー!」なので、それを「自分の環境だとどういう風に活かせるか」にしていきたいな。ありがとー!

f:id:bufferings:20171028222330j:plain

来年は

仙台の半谷さんや、東京の及部さんとかを呼んで、みんなでわいわいやるのもいいなぁ。