テストとコーチングを学ぶことにした

学習の動機

研究不足の2020年 - How IT Worksという記事を昨年の年末に書きました。2020年は当たり前のことを当たり前にやる年で新しい蓄積がなく、個人的に消化不良だったので、今年は何か深く追ってみたいというような内容です。

手前味噌になりますが、社内の同僚達はみな優秀です。設計論であったり、プロジェクトの進め方であったり、果ては採用の方法についてもよく考えて改善しようという意思があります。

目に見えるものを全てよくしようという情熱に溢れ、目に見えて日を重ねるごとに良くなっているのがとても伝わってきます。

自分はどちらかというと物事を深く見て、本質は何か、もっといいものはないかと時間をかけながら、思索していく方が好きで、じっくり煮詰めて煮詰めてものにしていくのが好きです。

同僚達の動きは素早く、広くという感じなので、そこに関しては自分が追いつくのは難しいと思います。やっていることを理解し、実践はできますが、彼らより早く、より広く考えるのはきっと向いていないでしょう。

だから、より遅く、より狭く研究する方が、チームに貢献できるのではないかなと思ったりします。また、テーマも今のWeb業界の開発者の中で学ぶ人が少ない方がきっと競争優位はあるのかなとも感じます。

テーマ選定

まだ10年も働いていない若造ですが、テーマは10年、20年と深く追求できるものが良いと考えました。自分は継続することは得意なので、10年ぐらい研究すれば流石に卓越した知識と技量は身につくのではないでしょうか。

一方で自分は飽きっぽいところがあります。デザインを勉強したり、プログラミング言語を勉強したり、スクラムを勉強したり、テーマの興味は割と変わっています。

なので、テーマは全ての分野を包括するぐらい広いものがいいです。広いテーマをやるというよりは抽象度が高ければ高いほどよい。

テストを選んだ理由

その辺りを考えながら自分の得意分野を探していると、テストがいいのかなと思い始めました。テストや品質管理は、実質的に全ての分野を含みます。

ユーザビリティテスト、パフォーマンステスト、保守性テスト、セキュリティテスト、結合テスト、受け入れテストなど。

これなら知識を全て生かせるし、同じ分野を研究する同僚もそう多くないので、きっと専門性を発揮できる分野です。

テストや品質管理の道はとにかく地道です。仕様を洗い出し、推論して、システムを壊す方法をあらゆる角度から考え、仕様が変わればもう一度テストを設計し直します。必要ならバックエンドもフロントエンドのコードも読んで、パターンを全部出します。メモをひたすらとり、構成を図に書きます。アイデアも必要なので1日でテスト設計が終わることはないです。

自分でも開発しながら、最高の品質を目指して徹底的にテストするのは難しいと思います。だからこそ、社内でやる意味があるのではと感じました。

趣味で休日開発している人は社内にいますが、趣味で休日テストしている人は今のところ知りません。

また、テストの分野はE2Eの技術や開発者ツールなど新しく学ぶことも多いですが、視野自体はそこまで時間で変わらないものも多いです。新しい技術と比べて学べば学ぶほど深くできるのも良いです。

コーチングを選んだ理由

これは趣味が一番の理由です。趣味で高校生を教えたりしているのですが、その手段としてコーチングがいいと考えるようになりました。

コーチングというのは知っている人も多いと思いますが、「対話や承認を通じて相手の能力を引き出すコミュニケーション」です。いわゆる「知識を直接相手に伝える」ことを指すティーチングではありません。

率直な実感で言うと、スポーツの世界はコーチの知識、技量の深さがそのまま選手の技量になります。特に小中高の選手は指導者が変わればチームは全く変わります。

また、過去にコーチングをやってみた経験からして、数年しか経験していない選手が数十年やっているコーチと同じレベルの発想まで行くことは絶対にないと言うのが正直な感想でした。

なのですが、最近また本格的に教えるようになって選手は「自分で気づいた技術しか自由に使えない」という実感も出てくるようになりました。

こちらとしては最高のやり方を伝えているつもりでも、それが自由に使えるというか応用のある技術にはならないのです。どうしても劣化コピーになり、これだと競争に勝てるほどのものにはなりません。

また、そもそも強い選手は自我も強いですし、いろんなコーチ、OBなどの話も聞いていて、そもそものガードが硬いなと思うこともあります。聞いているふりをして聞き流されることも多いです。

なので、やはり「自分自身で気づいてもらう」というプロセスを踏まなければきっと卓越した選手に育てるのは難しいのだろうと最近は考え始めました。

社内の仕事に関しても自分はひねくれた人間なのでリーダーになって、プロジェクトを引っ張るということはきっとないでしょう。情熱があり、改善意欲に溢れたエネルギーのある人の方が良いものが作れるでしょう。

そういう時に「今この判断をしたら長期的にはどうなるか」「今考えられる最大のリスクはなにか」「どうして今スクラムをやっているのか」という視野を広げる質問をしたり、「今の改善はとてもいいと思う」と肯定したり、そういった面で気づきを与えれればいいのかなと思います。

社内にこういった役割がとても上手い人はたくさんいますが、意識的に立ち回ることでまた違う側面で価値ができるのかなと考えます。

また今の仕事だと面談・面接に出ることも多く、その時に評価者の立場で質問することが多いです。でも、良いか、悪いか判断するだけの時間は息苦しいので、そういう時に候補者の本質を一緒に考えて、いろんな角度で自分のやったことを見直す時間にできた方が楽しいんだろうなと。

評価するのは終わった後で、面接中は相手の言うことを素直に聞いて、どう感じたのか、なぜ感じたのか、他の視点から見るとどうか、考えの軸は何か、もし時間があれば何が変わるか、と言うようなことにフォーカスするのもありかなとか。

社内ではどちらかというとコーチング反対派も多く、自己開示を嫌ったり、ティーチングも大事ということもあるので、それを受け入れてその上でどういうコーチングだと良いのかを考えてみたいのもあります。

今の所感

テストを学んでみて

JSTQBの本を読んだり、テストの記事を見つけたら社内のSlackに挙げたり、Redditを適当にwatchしたり、本を読んだりしています。TDD、型システム、といった技術面のものもあれば、テスト設計だったり、そもそもテスターの役割とはという原則論まで当然のように広いです。

実務ではとにかくメモを取るようになりました。今の社内ではウォーターフォールと比べると仕様が明文化されていない場合があるので、とにかくメモをとって仕様の漏れはないか、懸念事項はないかを考えるようになりました。

要件定義のミーティングでは、関連する画面はないか、とりうる値のパターンはなにかなどを図に整理して考えるようになりました。

また、視点の切り替えがとても大事だと思っています。アクセシビリティについてテストしながら、コードの設計について見るのは難しいです。

なので最初にテストを設計して、最初は仕様が正しいかをみて、次にありうるパターンを洗い出して、終わればコード品質を見て、最後にアクセシビリティ、セキュリティをみるというように段階を分けています。

はっきりいって時間がとてもかかります。開発モードだとここら辺を納期を理由に少し手を抜くところですが、テストについて学ぶ以上、全身全霊でやる他ないです。テスターと開発者を分けている会社の意味がここにしてようやくわかりました。

当然学び始めたばかりで正直テスト漏れは頻繁にあります。それを他の開発者に指摘されることもあります。今はそれをメモして、テスト観点を増やしたり、チェックリストを増やしたりしています。

完璧とはいきませんが、それ自体が能動的な学びであるので、それはそれで良いのかなと思ったりします。

コーチングを学んでみて

学習方法は同じく本を読んで、要点をまとめて、何人か仮想のクライアントを想定して、質問を考えたりしています。

こちらは面談、面接でやっているぐらいで、候補者の考えはわからないので、実際の効果検証が難しいです。

どちらかというと今は自分自身で検証している感じです。本を読んで、挨拶をする、相手の言葉を言い換えるなどの技法があるのを見て、それをやっている人を探して、それが本当に良いのか自分の心で検証しています。

特に強い人たち、面接が上手い人と同席しながら観察をしていると確かにそういったことをやっていることが多いので、それを見ながら真似しています。

強いていうなら今の会社は振り返りが多いので、そこで気づいたことを率直に伝えたり、いくつか視点を変える質問を使ったりしています。その反応を見ながら、理解を深めている段階です。

というように効果検証は難しいのですが、自分がどういうコミュニケーションをとっているのか、自分はどんな角度で質問を指定いるのかが認識できるので、メタ認識は上手くなった気がします。

趣味でやっている料理、中国語、競技を勉強していて、課題にぶつかった時に自分で自分をコーチングをするのには長けてきました。

そんな段階ですが、全部を統合してみるなら、上手くいきそうな気配は感じているぐらいの感触です。

今後について

テストとコーチングを学び、少しだけ視点が変わって見れなかったものが見れるようにはなってきています。

一方で無限の深さを感じていて、もっと良い質問はないか、もっと考えられるパターンはないかというのに日々気づき、全然足りないというのも同時に感じます。よくよく考えると視野を広くして穴を探すのはテストもコーチングも似ている気はしますね。

そういう意味で10年、20年時間をかける価値はあるぐらいには楽しそうな印象です。

実際的な問題について言えば、自分はテスターでもなく、コーチでもなく、あくまで開発者なので100%コミットするわけにいかないというのは難しいです。テストの視点を持つ開発者であり、コーチの視点を持つメンバーなので。

それはそれで中間の色合いみたいなものがあって、極端に行けば良いというものでもないので、良い塩梅を見つけるしかないのでしょう。Googleもエンジニアとテスターの中間の役割がいると聞きました。

課題としては今は基本的なことしかできていなくて、例えば単体テスト、PRのレビューあたりで工夫しているところですが、全自動E2Eは導入すべきかというテーマになれば本格的に深く研究して、実験するしかないです。

そういう深さを求め始めた時にどうやって学んでいくかとか、テスト分野の中の優先順位みたいなものも出てきそうな気はします。

今後、どうなるのかはっきり言ってわからないですが、出てくる状況に直面した時に素直に悩んで、答えを出して行けたら良いなと思います。

最後に素晴らしい同僚と一緒に働けて、自分の足りないところがわかり、良い面を真似できる今の環境にはとても満足しています。自分もそう言われるように学びを深めて、共有していきたいです。