7
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

#前書き
2021年11月末日。弊社の人事部門が企画する社内講演に、t_wadaさんがやってきた。
当日、私はライブで参加出来なかったが、大盛況だったようである。
私も遅れて録画を観たのですが、たくさんの気づきを得た。
そこで今回は公開されているスライドには書かれていない、当日の講演で私が感銘した一節を紹介することにする。
本題の講演内容の方も、とても良い気づきを得る講演だったのですがそちらについては割愛します。
t_wadaさんのtwitterを参照いただき、気になる方は本人へ講演依頼をされたし。

#当社社員とのQAセッションでの、良い話

t_wadaさんの講演の後、当社の技術者数名からt_wadaさんへの質問タイムがありました。
その中で私が印象に残った、t_wadaさんの回答をご紹介します。
先ず、質問は以下のような内容でした。

image.png

#t_wadaさんのアンサー

事前にリハーサルがあったのか、無かったのかは分かりませんが、上記の質問に対してt_wadaさんは以下のように回答されました。
私は、この講演を二日後に録画で拝聴した訳ですが、t_wadaさんのこのコトバは、
1エンジニアが成長するために、或いは、1エンジニアを成長させるために、有効な一つの手法、考え方である
と、共感を覚え、周りにも教えたいと印象に残ったコトバでした。いや、エンジニアに限らず、あらゆる人の成長に役立つメソッドかも知れないと思いました。

思わず、録画を聴きながら写経してしまいましたので、以下に紹介させていただきます。
//2021/12/3修正:写経部分について読みやすくするため筆者で体裁を修正しました。

「体験」を得るためには、案件の前に「自分でやる」のが良くてですね、チュートリアルをやってみてください。
「理解できるようになる」あるいは「わかるようになる」前に「手を動かす」というステップが、実は大事です。
「テスト」の書き方がわからないという事が、その「テスト」を書かない理由の大半を占めるんですね。
で、わからないというのは、わからないから書けないという順番になるんですけど、エンジニアの理解の仕組みとしては、
書いているうちにだんだんわかってくるようになるっていう順番のほうが遥かに多いんですよね。
新たな概念とか、新たな技術を学ぶためには、「わからないけど手が動く」って事がとても大事なんですよ。
で、手を動かしていくうちにだんだんだんだんわかってくるんです。

だから、「わかる」ってのは「手が動く」の後にやってきます
なぞれるやつをなぞってるうちに、だんだんわかってきて「なるほど、そういうことね、こいつは、お得だ」とか、「これの方が、なるほど、確かに早くなりそう」、また、手を動かして、ある程度自分の中で、「型」とか、或いは、「これまで書いたコード」とか増えてくと、それを真似したり、コピーアンドペーストしてそれをベースにしたりしてすることも出来るようになってくる。
ゼロから勝負しないってことがとっても大事。

なので、テスティングフレームワークのチュートリアルでもいいし、様々なところに、チュートリアルがありますので、テスティングフレームワークのチュートリアルとか、テストコードのチュートリアルとか、或いは、学習リソースとか、なぞって、動かして、理解する系のものを、先ず一通り、騙されたと思ってなぞってみるというのが、これが一番おススメです。

アタマで理解してから手を動かすんじゃなくて、手を動かしながらアタマで理解していくっていう学習の順番がオススメです!
そういう意味だと酷い我田引水ですが、この「テスト駆動開発」という本もそうなっているので、是非是非というところもあるんですが、なんか、わからないなりに手を動かしていくと、だんだんわかってくるようになると腹落ちしていくという順番が体験できるという形だと思います。
そうすると、案件の中で、一部だけここはテスト書きやすそうだからテスト書いてみよう、というと、そこは明らかに早くて楽だったみたいな体験がだんだん出来るようになってくると思います。

皆さん、どう感じましたか? t_wadaさんのこの講義を聴かれた方は質問者の質問の意図が分かるかも知れませんが、私がt_wadaさんの回答が凄いと感じたところは、

質問者の質問の意図を超越した、つまり、「テストを書いて開発して、質とスピードがトレードオフでなかった」という今回の講演テーマに基づく特定の事象へ事例ではなく、「体験を得る」ためのメソッド、手法という、高い視座での回答となっている点

そして、だからこそその回答は

エンジニアだけではなく、あらゆる職種の、人間の、「成長のためのメソッド」の一例となっている点

に感銘を受けました。

事前にリハーサルしてないのであれば、こんなことをスラスラ回答できる t_wadaさんって、凄いなあ、そして、いい話を聴けたなあ、と思った訳です。

自分自身の今後の参考にも活かしたく、そして、皆さんにもシェアしたく筆を取りました。

以上、皆さんのお役に立てば幸いです。

7
1
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?