日本的な視点で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

ということで

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

E2E Web テスト自動化ツールの TestCafe を調べて触った

Java のチームの同僚と「最近だと UI Testing にはどういうフレームワークを使うのかなぁ?」みたいな話をしてて、僕だったら

  • Selenium を直接。WebDriver は結構書きやすそうな印象。
  • Geb は好き。Groovy + Spock は良い。けど Groovy。
  • Selenide は使ったことはないけど Java で書くのに書きやすそう?
  • Cypress.io はちょっと違う種類だけど、サクサクで好き。

とかかなぁ?って言ってたら「 TestCafe ってのもあるよ?」「へー知らないー!」って教えてもらったので調べてみた。

## TestCafe?

devexpress.github.io

目に止まった特徴は、こういうところ。

npm install するだけですぐ始められる。実際にやってみたらほんとに簡単に始めることができた。良いね。Selenium ベースではないので各ブラウザー用のドライバーのインストールも不要。プロキシを使うアーキテクチャーになってるみたい。

サポートしてるプログラミング言語JavaScript と TypeScript。async/await が使える。

オフィシャルにサポートしてるブラウザーは( Browsers | TestCafe より)

Headless Chrome/Firefox も使えるみたい。良いね。

## vs Cypress.js

Cypress.js との比較記事。2018年の3月の記事。

www.yld.io

テストランナー

  • Cypress は Mocha, Chai, Sinon などの標準的なライブラリーを使うので JS 使う人ならスムーズに始められる
  • TestCafe は独自のテストランナーを使うので最初はちょっと戸惑うけど、async/await とか使えて良い

サポートブラウザー

  • TestCafe はプロキシを使うアーキテクチャーなので、色んなブラウザーで実行できる。
  • Cypress は(この記事の時点では)Chrome のみをサポート。(でも、今見てみたら Firefox と Edge もサポートされてた)

実行場所

  • Cypress はブラウザの中で実行されるから DOM を直接触ることができる
  • TestCafe は Node で実行されるので DOM を直接触ることはできない。でも、Node のコードを使ってセットアップとかできる

とかとか。この方は TestCafe を選んだみたいね。この時点でのサポートブラウザーを見て。

## vs Selenium

www.quora.com

Selenium WebDriver の方が歴史が長いしユーザーも多いし、柔軟だし色んな言語をサポートしてるから Selenium がおすすめ。

TestCafe は Angular, Vue.js, React をサポートするライブラリーがあるし、色んなアプリをサポートしてるけど、プロキシを使うアーキテクチャーまわりで色々課題がある。言語が JS/TS のみ。シングルタブのみしかテストできない。要素の取得が CSS セレクターのみ。Job opportunity が少なすぎる。Selenium を1年、TestCafe を半年使って、結局 Selenium のほうがおすすめ。

へー。そっかー。

## TestCafe が Selenium を採用しなかった背景

testcafe-discuss.devexpress.com

  • まず第一に、セットアップを簡単にしたかった
  • 次に、Selenium を採用しないことで以下のようなことが可能になった
    • TestCafe をインストールしていないリモートデバイスでもテストを実行できる
    • 実行環境の分離。毎回シークレットタブを開いているみたいな感じでテストを実行できる
  • 最後に、WebDriver は各ブラウザベンダーが開発しているけど、互換性の問題が出ている

これに対して「SeleniumSelenium 1 のプロキシのアーキテクチャーの課題を解決するために、WebDriver に切り替えたのに、 TestCafe は Selenium 1 のアーキテクチャを採用してるってことよね。面白いね」ってコメントがついて

  • プロキシの問題は、色々ごにょごにょやって解決してるよ!

みたいな感じ。プロキシ自体は Hammerhead という名前で、この仕様は公開されてないみたい。TestCafe と Hammerhead の連携モジュールがこれなのかな↓

GitHub - DevExpress/testcafe-hammerhead: A powerful web-proxy used as a core for the TestCafe testing framework.

## アーキテクチャー概要

TestCafe のエンジニアの Alexander さんが書いた記事: TestCafe: An e2e Testing Tool That Doesn’t Use Selenium

Selenium はセットアップが大変だし色々ライブラリーが必要になる。そこで、さくっとセットアップできる TestCafe ですよ。という感じ。やっぱり最初の導入の簡単さを推してるね。

(画像は記事から引用)

f:id:bufferings:20200718175103p:plain

あとは大体これまでで理解してきたことが書いてあった。

Getting Started

と、大体気になるとこはチェックしたので、触ってみる。

Getting Started | TestCafe

インストール:

❯ npm install -g testcafe

(省略)

+ testcafe@1.8.8
added 477 packages from 297 contributors in 55.379s

お。本当に1分でセットアップ終わったw

テストを書いて:

import { Selector } from 'testcafe';

fixture `Getting Started`
    .page `http://devexpress.github.io/testcafe/example`;

test('My first test', async t => {
    await t
        .typeText('#developer-name', 'John Smith')
        .click('#submit-button')

        // Use the assertion to check if the actual header text is equal to the expected one
        .expect(Selector('#article-header').innerText)
        .eql('Thank you, John Smith!');
});

実行:

❯ testcafe chrome test1.js
 Running tests in:
 - Chrome 83.0.4103.116 / Linux 0.0

 Getting Started
 ✓ My first test


 1 passed (4s)

5分かからんかったな。

失敗させてみたらこんな感じ。分かりやすそう。色付きの方がいいかなと思ってスクリーンショットで:

f:id:bufferings:20200718180118p:plain

感想:Selenium でいいかな

確かにセットアップが簡単ですぐ始められるのはとても良いけど、こういうの使うときってセットアップが終わってからの時間の方が長いし、セットアップが終わってしまえば Selenium の方が柔軟だから Selenium でいいかなと思いました。

もし、採用したら、最初は大丈夫だけど、しばらくすると難しい問題にぶつかって、Selenium だったらコミュニティが大きいのでそれを解決するアイデアやツールがありそうだけど、TestCafe だと自分たちで解決しないといけなさそうで、苦しむ未来が見える。

でも、面白かった!

知識創造企業とアジャイル開発とスクラムと自分

気づかされる日々

最近は、海外出身の人たちと近い距離で仕事をしてて、文化の違いを感じて面白い。そういうところを気にするのか、そこは気にしないのか、とか学びながら、というか、日本人はあの部分は気にしないけど、そこは気にするってことか、みたいに、海外出身の人たちの文化を感じると同時に、日本の文化、それが当たり前すぎて気づくことが難しい部分、に気づかされるような日々を過ごしてた。

そんな中で、自分の中にこういう気持ちがあることにも目を向けさせられた。

スクラムとは違う何か

この10年間、スクラムを勉強して、そこから得た学びを元に実践の中に取り入れたりしつつ開発をしてきたのだけど、自分の中では、そろそろいいんじゃないかという気がしているんだなって気づかされた。これまで、スクラムの考え方を基準にして、組織の形や自分の役割やチームのあり方を疑って、改善してこれたと思う。そして、もう十分「良い活動をできる組織」になってきたと思う。(「良い組織」になったということよりも、そのベクトルのことを「良いな」と思っている)

なので、次の一歩として、こういうことを考えてみたいなと思った。

組織にあった開発スタイル

正直に言うと、この10年間、スクラムをちゃんとやったことはない。というか、できたことはない。そこで悩んでいる部分もあったけど、常に考えていたのは「今のみんなの頑張りをつなげたい」ということで、そのチームや組織の状況や現在のステージに合わせて「スクラムを学ぶ中で得たもの」を活用して、改善をしてきた。

なので、スクラムできてないなぁ、って目をそらすんじゃなくて、僕らの組織の形で目指せる開発スタイルってどういうものだろう?ということを考えても良い時期なのかなと思ったのだ。

日本からのスクラム・海外からのスクラム

さて、スクラムを学ぶ中で、自分の中にずっとふわっと置いてあった気持ちがある。それは「スクラムは海外の人が日本のやり方を参考にしたことが発端の開発手法」なんだよなということ。海外の人から見たスクラムと日本の人から見たスクラムは、違うものなのではないかということ。僕らはもっと暗黙知よりで動くことができそう。

最初に触れたように、僕は、海外出身の人たちと仕事をする中で、文化の違いを感じていた。良いとか悪いとかではなく、単に「違う」というだけなのだけど、海外の人の方が「個」が強くて、役割や境界の明文化を求める。(ここで僕が想像している「海外」は欧米だなと書いてて思った。アジア出身の人たちはまた違う)。それに対して日本の人は「場」が強くて、役割や境界はふわっとしていても気にせずに仕事をする。

この違いが面白いなぁと思うのと同時に、ここにヒントがありそうだなと感じ、もう少しスクラムと日本のことを知りたくなって、この本を手にとった。先に言うと、すばらしい本だった。

知識創造企業

books.rakuten.co.jp

この本は、日本企業が意識的・無意識的に開発し実践してきたその経営原理を「組織的知識創造」というコンセプトで捉え「知識創造企業」というコンセプトを提言している。25年前の本で、製造業の新製品開発を中心としたものなので、そのまま現在の自分の業界に当てはめることはできないのだけど、日本と欧米との文化の違いについての分析や考察など、はっとさせられることや考えさせられることがたくさんあった。

読んでいく中で「現在のスクラムアジャイル開発を野中さんが見たらどう感じるんだろう?」と考えずにはいられず、以前に買ったこの本を読み直してみた。

アジャイル開発とスクラム

books.rakuten.co.jp

これまた、良かった。特に野中さんがアジャイルなソフトウェア開発についてお話されているのが「それ、聞きたかったところです!」という気持ち。以前に読んだときには、形式的な部分だけを言葉で捉えていたのが、今回はもっと深いところで共感することができたと思う。この数年間の自分の経験や、知識創造企業を読んだことによる学びからの実感があったのだよなぁ。とても良かった。

そして、僕が感じているようなことは、平鍋さんが既に言葉にしていた。「本書を作るにあたって考えたのは、危機的な状況下で日本の経営のあり方が問われる中、日本ならではのイノベーションを今一度発信していけないかということでした。」僕は正直、イノベーションまでは考えてないけど、日本の文化ならではの開発手法・組織のあり方を見つけられたらいいなぁと思っている。

新しい一歩

日本の伝統的な部分には、あまり好きではない部分もあるので、その辺りを見直しつつ、欧米の考え方の良い部分から学びつつ、日本の文化の良い部分を土台にして、何か自分にとって新しい一歩を踏み出せたらいいなと思った。折角、日本の文化の上で、色んな国の出身の人たちと仕事をしているのだから、その強みをみんなと探していけたらいいなと思っている。

まぁ、まわりまわって「スクラムに戻ってきた」ってなったりするかもなぁとか、何もしないうちに年を重ねてしまうかもなぁとか思いつつ、とりあえずこの2冊の本を読んで、今感じていることを書いてみた。

読み終わった。JavaScript: The Definitive Guide, 7th Edition

とても良かった。2ヶ月くらいかけて読んだのかな。

www.oreilly.com

最新の情報だけじゃなくて、歴史的経緯から順を追って説明してくれてるので、ちょっと前のスタイルのコードも読めそうだし。どういう背景で新しい仕様が導入されたのかとかも納得だし。とても良かった。

↓ let, const, var の違いや、Destructuring Assignment が面白かったなー。

↓ ES2020 の Conditional Property Access や First Defined で、ほほーってなったし、 === は真面目に読んだ。

↓ for/of やオブジェクトリテラル。ES2018 の Spread Operator は普通にたくさん出てきそう。

↓ Sparse Array って普段は使わなさそうだなーとか、map() や includes() は使いそうだなーとか。Array-like オブジェクトかーとか。

↓ Function と this と Closure はなんとなくでしか捉えてなかったので学べて良かった。昔のやり方から始まる class の説明は分かりやすくて良かった。

↓ Module の歴史。Closure Base から Node を経て、ES6 の Module への流れも分かりやすかった。ES2020 の Dynamic Imports は Node の require() を置き換えるために必要そうだなとか。

↓ Set や Map と。Iterable と Generator Function。

↓ からの Promise と aync/await。面白い。

メタプログラミングと Symbol。

この後に Web Browser の章と Node.js の章をさらっと読んで、最後にツールの紹介があった。

### JavaScript に入門できたかな

これで、一旦 JavaScript に入門できたかな。

なんとなくコードは読めそうだし、それが古いのか新しいのかも分かりそう。それに、分からないコードがでてきても、調べることはできそう。

Node.js のコードは CommonJS と ES の間で難しそうだなぁと思いつつ。

### 良い流れだった

JSPrimer と Promise の本で基本をなぞったあとに、JavaScript: The Definitive Guide, 7th Edition を読んで知識を深める、という流れだったのだけど、これはとても良かった。もういちど JSPrimer と Promise の本 を読み直して、一旦 JS 入門は終わりにしようと思う。

jsprimer.net

azu.github.io

### 次は

Vue.js でも触ってみようかなぁ?