和田さんのキャリアと出会い
日本最大級のエンジニアコミュニティ、Qiita プロダクトマネージャーの木尾の俊生です。
この番組では、日本で活躍するエンジニアをゲストに迎え、キャリアやモチベーションの話を深掘りしながら、エンジニアを皆さんに役立つ話題を発信していきます。
今回からのゲストは、テスト駆動開発者で、TowersQuest株式会社取締役社長の和田拓哉さんです。
よろしくお願いします。
和田さんとお話しできるのがすごくワクワクしていたので、いろいろお話しできたらなと思っています。よろしくお願いします。
和田さんとお送りする1回目のテーマは、TDDとの出会いとキャリアの変化です。
最初は、和田さんのキャリア、今までやってきたことについていろいろお伺いしていきたいと思います。
まずは、TDDとの出会いとキャリアの変化、です。
話をしていきます。今やっている仕事ということなんですけど、今やっている仕事は、ざっくり言いますと、いわゆる技術顧問業、コンサルタントとしての仕事。
技術顧問業というのは、技術のコンサルタントとしての仕事で、技術のコンサルタントというのは、
技術のコンサルタントとしての仕事ということなんですけど、今やっている仕事は、ざっくり言いますと、いわゆる技術顧問業、コンサルタントとしての仕事。
技術顧問業がまず定期的なもの、いわゆるお客さま企業と契約して、一定の割合でいろいろお手伝いをさせていただくというものと、
あとは外部の講演者とか研修講師として、単発の社内講演ですとか、社内研修を行うというものに分けられます。
これがコンサルタントとしての仕事、技術顧問としての仕事ということですね。
あとは、住宅開発の開発者として、住宅開発も細々とやっています。
これは後々説明すると思うんですけど、技術顧問業をうまく生かすために現役の開発者である必要というのがあるなと感じていまして、
住宅開発、お客さまの問題を解決するシステムを作るという仕事と、あとは個人としてはオープンソフトウェアの開発者、GitHub上でOSS開発者として開発しているというようなところを主な仕事としてやっています。
あとは一種の、これも仕事の一部なんですけど、書籍の出版とか翻訳とか簡訳とかそういったところにも関わっていますというような形で、いろいろやっていることに今のところなりますね。
ありがとうございます。本当に一開発者としてからいわゆるコンサル的なお仕事まで本当にいろんなことをやっていらっしゃるなと思いますし、
僕も日々、和田さんのアウトプットされている記事だったりとか資料みたいなところをすごい読ませていただいているので、すごい参考にさせていただいているんですが、
今のお仕事というところから次、逆に最初からそういうお仕事をされていたわけではないと思うので、どういうふうに今のキャリアを築いてきたのかみたいなところをお伺いしていきたいなと思っています。
和田さんのエンジニアキャリアの始まりとTDDの興味
なので最初お伺いしたいのが、もともといわゆるエンジニアとしてキャリアを始めたスタートってどういうことをやっていらっしゃったんですか。
エンジニアとしてのキャリアのスタートということなんですけど、いわゆる自分が書いたコードでお金をいただくというような経験をしたのがエンジニアとしてのキャリアのスタートと考えると、
大学生のときのアルバイトですかね、ソフトエンジニアとしてのアルバイトでコードを書いてお金をもらったのが一番最初の経験です。
僕の同世代は小さい頃からパーソナルコンピューターを触っていましたみたいな人もそれなりにいる世代ではあるんですけど、
私は小さい頃は特にコンピューターに興味がなくて、大学に入ってからコンピューターとかコンピューターサイエンスとかを学び始めて、
それで大学3年ぐらいでコードを書いてアルバイトでお金をもらったというのがソフトエンジニアとしてのキャリアの一番最初になりますね。
そこから大学卒業して、住宅開発の世界に入って、住宅開発者としてのキャリアをまずは歩んでいくというような形になります。
そうなんですね。ありがとうございます。
もともと大学ではコンピューターサイエンスみたいなところを専攻されていた?
そうですね。大学の1年生の時に留学をしまして、アメリカに留学したんですけど、
そしたらアメリカの大学ではレポートの提出とか執筆とか全部コンピューターで行ってたんですね。
僕、世代もう40代後半なんですけど、それより前、大学1年生の高校3年。
高校3年の時って、まだレポート用紙にペンで書くというような時代だったんですよね。
それから大学に行って、大学で留学したらいきなりみんなコンピューター使ってて、なんだこれはみたいな感じになって、
世の中そういうことになってるのかっていう強いインパクトを受けて帰ってきて、
そこからコンピューターをいろいろ興味を持ったりとか、触り出したりとか、そういったキャリアを歩むことになりました。
そうなんですね。ありがとうございます。
本当に今、和田さんもおっしゃってましたけど、今までお話し聞いてきた方の中でも、
やっぱり幼少期からパソコンをずっと触ってたみたいな方が結構多かったりしたので、
そこで言うとまたちょっと違ったキャリアのスタートなんだろうなっていうのは今お話し聞いて感じました。
そうですね。だからちょっとしたコンプレックスっていうか、僕はだから大学に入ってからコンピューター触ってるから、
遅いんじゃないかっていうコンプレックスみたいな常々ずっとキャリアのどのくらいかな、途中までずっと感じてました。
同世代の中でできる人たちは小さい頃からコンピューターがすごいってことを知ってて触っていて、
それに対して僕は大学に入って海外に行って初めてショックを受けて帰ってきて、そこから勉強始めたっていうので、
常に割と高発だという意識は途中まではずっと感じてました。
そうなんですね。ありがとうございます。ちょっと僕の話にもなっちゃうんですけど、
僕も実は大学入ってからパソコンみたいなものに本格的に触り始めた人間なので、すごい今お話し聞いてて共感をしました。
今のお話に戻ると、そこからファースト社会人として働くタイミング、
住宅開発みたいなところをやり始めたってお話あったと思うんですけど、今の僕の和田さんのイメージだとやっぱりTDDテスト駆動開発みたいなところがすごいイメージとしてはあるんですけど、
TDDみたいなものに対して触れたきっかけというか興味を持ったタイミングっていつ頃なんですか?
興味を持ったタイミングは、たぶん2002年ぐらい。
2002年ですか。
2001年、2002年ぐらいでTDD、テスト駆動開発っていう言葉が出てきて、書籍が出てくるのが確か2003年のことなんですけど、
それより前はTDDって名前はついていなかったんですけど、自分が書いたコードに対して自分でテストコードを書いて開発していくってやり方自体は時代的には始まってたんですね。
で、エクストリームプログラミングという本がケント・ベッカーが書いたのが1999年で、そこでテストを書きながら開発しようみたいなことは書かれてましたし、
それより前にJUnit、Javaで自動テストを書く仕組み自体は何年だっけな、開発されていったので、
ちょっと前後するな。ほぼ同時期か。
テスト書きながら開発していこうっていう仕組みとそういうプラクティスやっていこうっていうの自体はあったんですけど、最初は僕はあんまりその辺は分かっていなくて、
普通にテストを書かないでコードを書いて納品していました。
だから自宅開発のキャリアの最初とかも別にテストコードはゼロ行ですね。
まだ存在自体知らないですからね、っていう形でした。
で、自宅開発のキャリアを始めたのが2000年ぐらいなんですけど、普通にテストを書かずにコードを書いて、最後に手動でテストを行って納品みたいな形をやってたんですけど、
やっぱりうまくいかなかったんですね。手戻りが多かった。
自分が書いたコードが自分が書いた通りに動いていたはずなんだけど、いつの間にか動かなくなっていたりとか、思わぬところに不具合が潜んでいたりとか、
そういったことがあって、やっぱりスケジュール通りに開発するにはすごい残業しなきゃいけないみたいな感じとか、
割とあるある話だと思うんですけど苦しんでいて。
自分が自信過剰になっていたところがまたたきのめされた感じになったんですよね。
自分はプログラミングうまいと思っていたら別にうまくはなかったみたいな感じの経験をしまして、
いろいろどうやったらうまく開発できるのかなというのを、テスト自体はあんまり好きではなかったし得意でもなかったので、
自分が書いたコードを自分で動かしながら試験をする、テストコードを書くやり方じゃなくて当時知らなかったので、
自分で確認するみたいなのはあまり得意じゃなかったし、あまり好きでもなかったので、
プログラミングが上手ではなかったんですね、結果的にね。
うまくいくやり方はないかなというので、
ウェブで調べたりとか、あとプログラミングの雑誌を読んだりとかとかは雑誌を取り寄せてくれるんですよね。
例えば大学の図書館って、その図書館に蔵書がなくても別の大学の図書館に蔵書があれば取り寄せてくれるので、
それでプログラミングの本とか雑誌とかそういうのをいろいろ読んでいくと、テストコードというものがあるらしいと。
自分が書いたコードに自分でテストを書きながら開発していくというやり方があるらしいということを、
やっぱり2000年代の初頭ぐらいに知ったんですね。
当時僕のキャリアは、大学の研究もJava周りのものをやってましたし、
自宅開発のキャリアでコードを書いてお金をもらったのもJavaのコードが多かったので他のものもあったんですけど、
テスト駆動開発に興味を持つきっかけ
Javaでテストを書きながら開発するのってどうやるのっていうのを調べたらJUnitってやつがあるらしいと。
JUnitの使い方を調べて使い始めると、テストコードってコードで書くので当たり前の話なんですけど、
僕自身はコードを書くのはすごい好きだったんですね。
割と喫水の性格的にはプログラマーで、だからコードを書くのが好きで、テストをするのはあんまり好きではなかった。
けどJUnitを使うと、自動テストのテスティングフレームワークを使うと、テストをコードでやっていいよっていうことになったんですよね。
嫌いなテストを大好きなプログラミングで行えるようになった。
突然ご褒美みたいな状態になったんですね。
テストはめんどくさいなと思ってたんだけど、テストがプログラミング対象になったら楽しみが2倍に増えたみたいな感じになったので、
それでコードを書くのがすごい好きだったので、テストもコードで書ける、嬉しい幸せみたいな感じでテストコードをガンガンもりもり書き始めて、
そうすると自分が書いたコードを自分でテストすると自信が深まるというか動いているっていう、
自分が書いたコードは動くぞ、そもそも動くぞというところがちゃんと自分が想定した通りに動いているみたいな形で自信が増えていくということに気がついて、
テストを書きながらコードを書くとうまくいくということをだんだん知り始めました。
そのあたりでエクストリームプログラミングというアジャイルソフトウェア開発の考え方とか、
後に出てくるテスト駆動開発とかそういうのを知るというきっかけにつながっていきましたという感じですね。
そうなんですね、ありがとうございます。
今の最初は和田さんもテストそんなに好きじゃなかったって話がすごいそうなんだって意外に思ったんですけど、
最初のきっかけは本当にテストっていうところよりも、やっぱり本当にコードの品質とかを確かめるためにどうやってやればいいのかって色々模索している中で一つ見つかったみたいな感じだったんですかね。
そうですね、割とだから出会いはそんなにそのあたりで後出しの議論で、
プログラミングのトピックを色々探していったら、テストをコードで書くってやり方もあるっていうことを偶然知ったみたいな感じなのだと思います。
その時にテストのことで悩んでたっていうか、自分が書いたコードが自分が思っていたほどにはうまく動かないっていうことに悩んでいたので、
それがきっかけになってシリオになったということだと思います。
今のお話の中でテストを書いていくってところを知ったきっかけみたいなところは色々わかったんですが、
実際そこを知った上ですぐ仕事にいわゆるTDDの走りみたいなところは活用できたんですかね、すぐに。
いや、その意味だと個人で活用するという段階とチームで活用するという段階にだんだん広がっていったんですけど、
個人の話だと最初はやっぱりうまく書けないので、書けないっていうのはそれまでテストコード全く書いてこなかったので、
じゃあテストコードのという世界があるって分かったので自分が書いているコードに対してテストを書いてみようっていうと、うまくいかないんですね。
うまくいかないのは何でかっていうとやっぱりテストのことを考えて書かれてこなかったコードというやつは後からテストを書くのも難しいんですよね。
今なら分かる話なんですけど、当時は初挑戦なんで全然分からなくって。
だから難しいなと思っていたんですけど、テストコードを書くやり方自体は偉く面白いので、自分にとって。
なのでテストコードを書きながら開発をするようになったら開発が楽になっていったんですね。
それはやっぱりテストを書くタイミングがテスト対象のコードを書くタイミングに近づいていくとテストを書きやすい設計をするようになるので、そうするとテストを書く負担が下がっていきます。
そうすると割と不思議なことにテスト書きやすい設計ってやつは結果的には結合度が低くて凝集度が高い傾向にあるので、
その設計自体も組み合わせやすいものになっていって、割とじわじわとうまく回るようになっていったという感じで、
キャリア初期の住宅開発って割と少人数でやってたので、多分するとプログラマーが私一人みたいな状況もあったんですよね。
キャリアの初期におけるテスト駆動開発の経験
そうすると全文コードを自分で書いて、思ったように動かないみたいな感じで苦しんでたのをテストコードを書きながら開発するってやり方があるってことを知って、
テストコードを書きながら開発してみたら結構うまくいくぞというような手応えを始めて、
だから自分一人での開発に自分一人でテストコードを書きながら開発していくというやり方をキャリア結構初期にやるように。
プログラマーのキャリアとしてはだから3年目ぐらいですかね、にやるようになりましたと。
その後、住宅開発の世界って割とプロジェクトを成功させると、だんだん大きいプロジェクトに呼ばれるようになってるんですよね。
なんか出世後みたいな感じで。なので、プロジェクト成功させたら中クライのプロジェクトに呼ばれて、
中クライのプロジェクトで何かやって成功させるともっと大きいプロジェクトに呼ばれてみたいな感じで、
だんだん参加するプロジェクトが大きくなっていって、僕のキャリアの中だと、
キャリアの割と前半期に僕のキャリアの中では最大のプロジェクト、
住宅開発の中では最大のプロジェクトのやつに参加しまして、
そこのプロジェクトで共通チームみたいな、いろいろなでかい巨大なプロジェクトの共通機能みたいなものを作るフレームワークとか、
インフラとか基盤とか、いろいろなものの共通的なものを引き受けるみたいなチームがあったんですけど、
そこのチームに参加することになって、そこで開発するときに自分自身は自動テスト書きながら開発するやり方に慣れてきていたので、
その自分一人ではなくて、そのチーム、共通チームに自動テストの書き方をちょっと一緒にやりながら、学んでもらいながら開発していくという段階に入って、
それも最初期からテスト書きながらやっていったので、それなりにうまくいったと、大規模プロジェクトでもいけるぞというような手応えをつかむに至ったという感じです。
大規模プロジェクトでのテスト駆動開発の導入
おだしょー ありがとうございます。本当に最初は一人から始めて、一人から始めたところからちょっとずつ規模を大きくしていって、最終的には大きなプロジェクトの中でテスト駆動開発みたいなところをやってらっしゃったんですね。
大きいプロジェクトでの巨大ないわゆるウォーターフォールのプロジェクトなので、全員がテスト駆動を書く、そのために全員が勉強してもらうっていうのはやっぱりうまくいかなくて、
うまくいかないというか、規模的にもうまくいかなくて、なのでたくさんの人がたくさんのそのプロジェクトのプログラマーが使う共通部品とか共通のライブラリーとかフレームワークとか、
そういったところはせめて自動テストが行われている状態にしようというのを目指してやって、それはそれなりにうまくいったという感じです。
今のお話だと、いわゆるTDDみたいなテストを書いていくっていうところの文化みたいなところを仕事の中で生かしていくってお話だったと思うんですけど、
今の和田さんは多分そこをメインにしてらっしゃるじゃないですか。そのキャリアのシフトが起こったタイミングとかきっかけってどういうところだったりするんですか。
和田 キャリアのシフトは、なのでその住宅開発の世界に行ったところから、巨大なウォータフォールプロセスの中でやっていたところから、
アジャイルソフトウェア開発をするチームに移りまして、そこがまず大きなキャリアチェンジになりました。
それが2004年のことなんですけど、巨大な数千人のウォータフォールのプロジェクトから、4人のアジャイルなチーム、エクストリームプログラミングをやっているチームに移りまして、
それが2004年の7月1日のことなんですけど、その時に僕以外のメンバーが全員技術ブログをやってたり、あるいは技術雑誌に書いてたり、みたいな感じで。
僕以外のメンバーのことを僕は知ってたんですよ、参加する前から。
大変だと思って、有名人ばっかりいるみたいな感じになってしまって、みんな当時普通にブログブームっていうのは始まってて、
いろいろな技術のブログを書く人っていうのもいっぱいいたんですよね。
あとは雑誌にもちろん記事書く人もいたりして、4人のアジャイルチームに入ったんですけど、4人中3人がそういったアウトプットしてて。
私はWaterfallのプロジェクトが、簡単に言うと公共系のプロジェクトだったので、
あまり技術的なアウトプットは推奨されてないというほどでもないんですけど、あまりアウトプットする文化なかったんですね。
ので、プロジェクトの中では技術情報は流通してたんですけど、ファブリックにアウトプットするっていう文化はなかったんですね。
そこから数千人のそういうチームから4人のアジャイルチームに行ったらみんなブログ書いてて、みんな有名人で大変なことになったなと思って、
その日のうちにハテナアカウントを取って、ハテナダイヤリーでブログを書き始めたんですね。
当時はだからその4人のチームでいろいろなアジャイルソフトウェア開発、エクストリームプログラミングをやっていて、
ペアプログラミングをやったり、テストファーストでテスト駆動開発やったり、プランニングゲームみたいなやったり、みたいな感じのことをやっていた。
で、僕自身はそういったアジャイルソフト開発の進め方は本ではよく読んで知っていたんですけど、
アウトプットの重要性に気づく
実際にやる本当に何ですかね、100%XPのやり方でやるみたいなのは初めてだったので、僕自身にとってもすごく新鮮な経験だったんですね。
その新鮮な経験をその新鮮なものにブログにガンガン書くみたいなことをやっていたら、
そのブログで書いていた内容とか、あるいはその勉強会、その業後にコミュニティの勉強会とか読書会に参加するっていうことも当時やっていたので、
でかいプロジェクトだとやっぱり残業続きで全然コミュニティに参加できなかったんですけど、
アジャイルチームに入ってからは普通に退勤後に読書会とかコミュニティに参加して、いろいろ議論したりするというのができるようになったので、
そこで議論したり読書会やったりみたいなときに雑誌の編集をやっている方とかの目にも止まって、
で雑誌にも書くようになりみたいな形で、アウトプットを呼ぶみたいな形で、ちょっとそれが結果的にはすごいキャリアチェンジになりました。
そうなんですね。じゃあ本当にブログを執筆しだしたところをきっかけに、そちらがメインになってくるというか啓蒙していく側にキャリアが変わっていくってことですね。
啓蒙までは全然考えてなかったですね。単に自分たちがやってることを、単にブログを書くのが楽しかったので、誰かに伝えるとかはあんまり考えてなかったし、
当時のブログブームっていうのもなんかファブリックに向けて述べるっていうよりは本当に日記だったんですね。
当時ブログっていうよりはてなはてなダイヤリーでしたし日記だったので、日記をなんかファブリックのところに書いてるみたいな感覚だったので、啓蒙とか誰かに考えを伝えようというのは結果的にはじわじわ育ってったって感じですかね。
あんまり自分のアウトプットが他の人にとって価値があるというか、他の人の何か疑問に答えるとか価値があるみたいなもんだとあんまり思ってなかったんですよね。
単に自分の知ってることとか自分がやってることを日記に書いてたんですけど、そういった日記に書いていったり勉強会に参加したりみたいなことをやっていくうちに、
なんか自分がそれまでやってきたこととか学んできたことって意外とニーズがあるっぽいぞということに気がついたんですね。
やっぱり自分だと普通のことだと思っていたとか、そこまで特殊なこととか大したことだと思っていないことが、実は他の人に喜ばれるしニーズもあるということに気づくっていう体験も結構大事だなと思っていて、
なのでちょいちょいコミュニティとかでアウトプットしたら割と反響があるので、自分がこれまで学んできたこととか、今実際にプロジェクトで実践してることっていうのは結構インパクトがあることなんだなというのが手応えとして分かってきて、
そこからだんだん自分が学んできたこととかやってきたことを整理整頓して、多くの人に伝えるというような機会がだんだん増え始めるというような形になりました。
キャリアの変化と今後への展望
ありがとうございます。じゃあもうそこから今の和田さんのキャリアが続いているということですね。
そうですね、そこから繋がっていきます。
ということで今日は和田さんの今までのキャリアについていろいろお伺いをしてきました。
僕の中ではTDDといえば和田さんみたいな印象が最初からあったんですが、やっぱり過去のお話をいろいろ聞いていると本当にいろんなことを経験して、一つ一つ自分の中でもいろいろ解を見つけながらここまでやってらっしゃるんだなというふうに思って、
今までの方もそうなんですけど、最初からすごいのではなくてやっぱりやり続けているからすごくなっているみたいな感じなんだろうなというのを改めて思いました。ありがとうございました。
さて、この番組では感想や次回決戦の質問、リクエストなどお待ちしております。
番組詳細欄にあるリンクより気軽にご投稿ください。
Nextではハッシュタグ、聞いたFMをつけて押すとしてください。
表記は番組名と一緒でQFMが大文字、残りは小文字です。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
聞いた株式会社は、エンジニアを最高に幸せにするというミッションのもと、エンジニアに関する知識を記録、共有するためのサービス聞いた、社内向け情報共有サービス聞いたチームを運営しています。
ぜひカタカナで聞いたと検索してチェックしてみてください。
来週も火曜日の朝6時に最新話が更新されます。番組のフォローをして最新話もお聞きください。
お相手は、聞いたプロダクトマネージャーの清野利恵美と、ハウスベスト株式会社の原田太郎でした。
