『JSJ 358: Pickle.js, Tooling, and Developer Happiness with Anatoliy Zaslavskiy』を聴いて
僕のお気に入りのPodcastの一つにJavaScript Jabberというものがあります。
「JavaScript」とPodcastのタイトルには書いてありますが、ゴリッとJavaScriptのテクニカルな話をするわけではないです(昔はそうだったかも)。 どちらかと言うとJavaScript界隈に何かしら関わりのある人物をゲストに呼んで、その人と一つのテーマについて1時間ほどトークをするという流れです。 ホストは Charles Max Wood氏 です。Ruby Rogues, Adventures in Angularなど様々なPodcastを配信している方です。
なんとなーくジョギングなりしながら聴いているのですが、先日聴いたエピソードが結構面白かったので紹介したいと思います。英語ですが、トピックに興味がある方はぜひ聴いてください!
Pickle.js, Tooling, and Developer Happiness
今回のゲストはAnatoliy Zaslavskiy氏というHover Inc.所属のSenior JavaScript R&D Developerでした。
当初のテーマはきっとAnatoliy氏が作ったPickle.jsと自動テストに関する話だったと思うのですが、途中からDeveloper Happinessに話が逸れ(?)ます。
このDeveloper Happinessに関する議論が特に興味深かったです。
目次
- [00:00] イントロ(Pickle.jsの紹介)
- [11:38] テスト文化にまつわるよくある問題
- [17:30] 自動テストの意義
- [28:24] Employee Retention(従業員をどう定着させるか)
- [38:24] なぜSeniorよりJunior Developerを雇うほうがスケールするのか
- [47:10] ツールやライブラリを作っていく上で注意すること
- [54:15] Picks
時間は、Podcast内でトピックが話されているだいたいの時間を示してます。Picksとは、毎回Podcastの最後に参加者が全員何かしら記事だったり技術ネタだったり、視聴者にシェアしたい内容を紹介するコーナーです。
Pickle.js
ゲストのAnatoliy氏が作っているPickle.jsというのはe2eテストフレームワークです。
僕もまだ触れていないので、このPodcastと公式サイトから得た情報をまとめると
- Cucumber っぽく(Gherkin Syntaxで)ノンプログラマーでもテストを書ける
- 既存のテストフレームワーク(執筆時点ではCypressだけ)を拡張して実装しているので、理論上はテストフレームワークを変えてもテストが動く
- ページ内の要素を選択するためのセレクターは一箇所にKey Valueで定義し、そのKeyをテストの文章内で使用できる
ポイントは以下のスライドでも簡潔に紹介されています。
僕の中ではpython製の Robot Framework に似てるのかなという印象があります。
自動テストがなぜ必要か?
なぜ自動テストが必要なのかというトピックについて、「自動テストの無い大企業でのプロジェクトの問題」が例に出されています。
- プロジェクトに多数のエンジニア(数100)が関わっている
- ある機能を開発者が実装する
- QAがその機能をテストして、1週間後にバグなどフィードバックする
- 開発者はバグを修正してQAに再び渡す
- また1週間後に、今度はさらに発生したバグなどフィードバックする
ここでの大きな問題としては開発者が、自分の実装した範囲が他にどのような影響を及ぼすのかということを知る術が無い(コード全体を熟知しない限り)。
そして、何かを壊してしまった場合に即座にフィードバックを得ることができないという点です。
流れが悪いために時間はどんどん過ぎていき、エンジニアとしてはほとんどバグを直していることしかしていないという負のスパイラルに陥ります。
自動テストを導入することで、フィードバックのスピードが劇的に早くなるため、上の問題の改善に大きく貢献するというトークをしています。
自分が行った変更が 既存の機能を壊していない ということが 一定のレベル保証される ことで、開発者も変更を加えるときに心理的安全性を保つことができるようになります。
トーク内でも「Eliminate the fear of change(変更することへの恐怖を排除する)」することで「Innovative(革新的)」になれると言っています。
この意見には僕もとても賛同しているのですが、「一定のレベル保証される」というところが、「良いテスト」を書いていることが前提になっていることを忘れちゃいけないのかなとは思います。
「良いテスト」の定義がまた難しいのと、トーク内にも特に触れられていない部分なのですが、以下の書籍の内容が僕は好きです。
The Way of the Web Tester: A Beginner's Guide to Automating Tests
- 作者: Jonathan Rasmusson
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2016/10/02
- メディア: ペーパーバック
- この商品を含むブログを見る
日本語版はこちら
- 意味のあるテストになっているか
- 壊れやすいテストを書いていないか
- 本当に意図したテストを行っているか(テスト自体がバグってないか)
などいろいろな観点がありますが、「ただテストをたくさん書けばいい」というわけではないという点がポイントです。
Developer HappinessとEmployee Retention
後半はDeveloper HappinessとEmployee Retentionに関する話題になります。ここが結構ヒートアップして前半の内容が薄れちゃいます(笑)
なぜエンジニアは会社を辞めるのか?
エンジニアが会社を辞める理由としてCharles氏は2つの観点を述べています。
- 人(People)
- プロジェクトそのもの(Project)
自分と「合わない」人と毎日仕事を続けるのはしんどいですし、そもそもプロジェクトが解決しようとしている問題に興味が無ければモチベーションも上がりません。 これには僕も同意見です。これに加えて「給料」も結構大きな理由なのではないかと思います。
同じ仕事条件で、より給料の高いオファーがあったとしたら会社を変えるのは結構自然だと思います。
ただし、「仕事条件」は僕の中では「仕事場の環境(人)」も含まれていると思うので、 単純な比較にはならない とも思います。
Anatoliy氏は「辞める」のは「Unhappy」だからであり、「Unhappiness」は「Cognitive dissonance(認知的不協和)」から来ると述べています。
- 自分がやるべきこと
- 自分が実際にやっていること
のギャップに苦しんでいるが、その「現状の状態」に慣れ過ぎちゃっているがために、どうしたら改善できるか 想像ができない状況に陥ってしまう と。
この状況に陥ったときにどうすべきかの意見がCharles氏とAnatoliy氏で異なった点が面白いです。
IT業界は今のところ人手不足なので、転職してしまうのが一番シンプルだとCharles氏は述べています。
それに対してAnatoliy氏は恋愛を例に出します。
「好きだと思った女性と付き合うが、付き合ってみたらなんか違ったので別れてまた違う女性と付き合う。」
ということを繰り返して良いのかどうかという点に注目します。
「問題は付き合っている女性側にあるのではなく、自分にあるのではないか。」
という視点の切り替えが必要なのではないかと問います。
この視点の切り替えとは「課題の分離」を行うということなのかなと僕は感じました。
- 自分の課題
- 他者の課題
を整理することで、自分の課題に気づいたり、他者の課題に踏み込んでしまっていることに気づいたりできると思います。
「課題の分離」について以下2つの書籍を最近読んで僕も「なるほどー」とうなづく点が多かったので合わせて載せておきます!
- 作者: 岸見一郎,古賀史健
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2013/12/13
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (113件) を見る
「課題の分離」を行うことで、「現状」を改善する道筋が見えてくるかもしれないというのは確かにその通りだなと感じました。
ただし、それでも尚道筋が見えない環境、抜け出した方が良い環境(Toxic Environment)もあるというのは双方で一致している意見でしたし、僕もそう思います。
補足:僕は付き合う相手を変えることについて否定的ではないです。自分に本当に合う人をそうやって見つけられるとも思います!
エンジニアのRetentionを上げる
エンジニアのRetentionを上げるポイントとして述べられているのは「エンジニアは多種多様であると理解すること」と言っています。
- いろんな感情を持っている
- 興味の対象は人それぞれ
- ワークスタイルも人それぞれ
人それぞれで異なるものをうまく組み合わせて活用(utilize)できるようにする、と述べていますがこれはとても難しいと思います。
人・組織・リーダーシップに関わってくる話だと僕は捉えていますが、まだまだ僕はこの点について勉強中で、特に以下の書籍を読んで整理したいと思っています。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (3件) を見る
スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー
- 作者: 和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2017/09/11
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2013/12/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (10件) を見る
また、 僕のブログメンターでもある カックさん の以下記事も参考になる情報満載なので要チェックです!
まとめ
Developer Happinessの議論がとても勉強になりました。「これだ!」という単純な答えが無いのが難しいんですけど、様々な人のこう言った話を聴きながら、自分の生き方も改善していきたいと強く感じました。
後半のトークが濃すぎてPickle.jsの話がだいぶ薄れた印象があります(笑)Pickle.jsのコンセプトは面白いので試してみたいです。
参考
- Testabilityという観点で画面(View)の状態をカタログのように可視化して管理できるStorybookが紹介されました
- Picksで紹介されたDevOpsの本。物語になっていて読みやすくて面白い本です。
- 作者: ジーン・キム,ケビン・ベア,ジョージ・スパッフォード,榊原彰,長尾高弘
- 出版社/メーカー: 日経BP社
- 発売日: 2014/08/12
- メディア: 単行本
- この商品を含むブログ (2件) を見る