シェア
はてブ
「Ask Me Anything」（AMA）をご存じでしょうか？
いわば、日本の技術カンファレンスの登壇後に行われる質疑応答をメインに据えたイベント形式で、海外のエンジニアコミュニティで人気を集めています。それを日本でもやってみよう！ というt-wadaさん発案のもと、Findyでは2024年11月6日、オンラインイベント「Ask Me Anything! t-wadaさんに何でも聞いてみよう」を開催しました。
ライブ投票やQ&A、アンケートなどの機能を持つコミュニケーションツール「Slido」を使ってイベント参加者からフリーテーマで質問を募り、「いいね」が多く関心度の高い質問から順に答えていくという方式で、t-wadaさんに直接ご回答いただきました。本記事では、当日行われた質疑応答の概要をテキストで掲載。なお、イベント本編のもようはYouTubeから視聴可能です。
Q: 仕事関連の情報を仕入れるとき、どんなメディアを利用していますか？ 1日のスケジュールに情報収集をどう組み込んでいるかも教えてください。
t-wada: Web、本、ポッドキャストなどを使い分けて、隙間時間に情報収集しています。スケジュールとして決まったルーティンはありません。
XやBlueskyなどのSNSで情報をチェックすることもありますし、ソフトウェアエンジニアの方々がシェアする海外情報をリストでまとめて閲覧することもあります。本屋で背表紙を見て全体のトレンドを確認することもあります。
移動や家事の最中で、耳しか使えないときはポッドキャストを聞きます。個人的に必ずチェックしている番組は「Misreading Chat」です。森田さんと向井さんが論文を読んで解説する内容で、とても参考になっています。
Q: 「20、30代のときにやっておけばよかった」と後悔していることはありますか。
t-wada: 運動する習慣をちゃんと身につけておけばよかったと感じています。
40代、50代に近づくと体にガタが出てくることがあり、運動を日常に組み込む心がけが必要だったなと思っています。私は「運動しないと気持ち悪い」くらいの状態まで持っていくことができませんでした。
Q: テスト（ケース）を書きすぎると逆に今後の足かせになることがあると聞きました。書きすぎか否かは、どのように判断していますか。
t-wada: 難しい問題です。判断の仕方としては、まず直感を大事にしてください。「このテストは、別のテストと重複しているのでは」といったモヤモヤ感を覚えたら、調べて確認します。また、チームで作業する際にはレビューやモブプロ、ペアプロを活用して、気付きを共有することも有効です。
ひとつ付け加えると、テストは不安から増えていくもので、減らすのは難しいものです。増やす際にはどういう文脈で増えたのかわかるように、背景情報のメモや関連するプルリクエストのURLを記録しておくと、あとで消しやすくなります。
Q: 和書洋書問わず、最近面白かった技術書を教えてください。
t-wada: 最近読んで印象的だったのは『プログラミングRust 第2版』です。Rustという言語が何のために作られたのか、言語の裏側にある価値観を明確に伝えてくれます。私は手を動かして試行錯誤するところからボトムアップで学んでいくタイプなのですが、Rustではそれが上手くいかず、トップダウンで学ぶことも有効だと気付かされました。この本を読んでからRustの全体像が掴めたので、とても印象深いです。
Q: エンジニア出身でない上長や経営層に対して、自動テストやリファクタリングなど成果が見えにくい施策をどのように提案しますか。
t-wada: 非常に難しい課題です。エンジニア出身でない場合、プログラミングの観点を伝えるのは苦戦することが多いです。重要なのは、相手に伝わる単位で説明すること。それはお金と時間です。
自動テストやリファクタリングは、開発速度を維持し、プロジェクトの予測可能性を高める施策として提案します。時間を短縮し、その結果としてお金につながるという形で説明することが多いです。
Q: テストまわりで今もっとも解決が難しい課題は何ですか。
t-wada: AI全盛の時代を迎え、AIでテストする取り組みはとても増えている一方、AIをテストする分野に関してはハルシネーションが多く、出力が安定していません。
後者では人間でなければテストできない領域が再び増えていて、これが今もっとも課題になっているところです。「LLM as a Judge」のようなAIにAIをテストさせる研究も進んでいますが、「これでいける！」という感じには至っていません。
Q: 最近、手動での動作確認から、テストコードを実装し、そこから自動テストの整備ができるようになりました。現在の課題は、テストコードの書き方や品質の考え方などについて、開発メンバー内で大きなレベル差があります。勉強・経験以外の解決策として、何かできることはありますか？
t-wada: 勉強・経験以外なら、「チームの施策として何ができるか」という話になりますかね。
コードレビューのほかに、「こういうときはこういうテストを書きましょう」というチームレベルでのドキュメント整備や、お手本となるテストコードを充実させましょう。そして、お手本を真似してもらえるような状況を作りましょう。例えば、機能を新たに作るとき、既存の類似機能にはテストコードがあってそれを真似すればいい、といった状況を作ります。
こういったコードの質は模倣によって伝播していくので、最初に良いお手本を作ることがとても大事です。
Q: t-wadaさんは書籍やブログ、X（旧Twitter）の投稿でいつも的確に引用しています。どのように文献を選んでるのですか。全て覚えてるのでしょうか。
t-wada: 本を読みながら「このフレーズは説明に適している / 自分の考えを補強するのに役立つ」と思った箇所を記録し、どの本のどのあたりにどのような内容が書かれていたかをなんとなく覚えておいて、必要なときに探しています。
「記憶は場所に紐づく」と言われていますが、私の場合は紙の本のページや背表紙、本棚の位置などが記憶のトリガーになっています。
Q: コーディング前の設計書の粒度についてどう考えるべきですか。自社では最近、ソースコードに近いクラス設計書を作成しています。アウトソースには効果的ですが、「その時間をコーディングにあてるべきではないか」「文書が陳腐化しやすい」という懸念があります。
t-wada: コードに近いHowのドキュメントは必要なのか、不要なのか。この質問のケースではあまりいらないかなと思います。それより「どうしてこういう設計になっているのか」「なぜこの判断をしたのか」など、WhyやWhatのドキュメントを残しておくことが重要だと思います。実装前だと、より効果的ですね。
しかし、Howのドキュメントについては「コードを書けばいいから、いらない」「AIにコードを書かせるために、いる」など、状況に応じて答えが変わってくるところがあります。
コンピュータサイエンスの歴史には「コードを書かなくてもいい」というツールや考え方に投資しては失敗しつづけてきた流れがあり、今後もその傾向は続くと思います。コーディングから逃れようとしても、コーディングからは逃れられない。コーディングでなくとも、コーディングに等しい詳細な何かを書かなくてはいけません。
とはいえ、現在はAIがコーディングのアシスタントをしてくれるようになり、コーディングから逃げる必要がなくなりました。AIと協業しやすいようにドキュメントやコメント、テストコードを使っていきましょうね、という時代になってきています。
Q: 変更が当たり前のシステム開発において、テストの重要性をメンバーにどのように伝えるべきでしょうか。
t-wada: 「変更したら再テストしなきゃいけないですよね。再テストってつらいですよね。なので自動テストをなるべく書いていくことで、テストを楽にしましょう」という形で伝えることが多いです。
競争を勝ち抜くためには、何度も変更していくことが当たり前の時代になりました。「テストがつらいから変更しないようにしよう」ではなく、「テストで楽することによって変更しやすくしよう」と前向きになれるようにすることが大事です。
Q: 仕事がつまらないと感じたり、やりがいを見いだせず腐りかけたりした経験はありますか。克服した方法も含め、エピソードを聞きたいです。
t-wada: 仕事がうまくいかず打ちのめされた経験はあります。リーマン・ショックの影響で案件をすべて失い、大きな挫折を味わいました。そのとき、自分の価値を自分で決められるようにならなければいけないと強く感じ、それをきっかけに自社製品を作るなど、自分で価格を設定できる形を目指しました。こうした取り組みを通じて、状況を乗り越えることができました。
より小さなスケールでは、なんとなくうまくいかない日、やる気が出ない日もあります。そういうときには、自分の心をリセットするために良い肉をゆっくり焼いてゆっくり食べるというのが、自分の心をリブートする儀式になっています。
Q: t-wadaさんが現在、課金しているAIサービスを知りたいです。
t-wada: いろいろ試しながら「これは良いな」と思ったものを継続するスタイルで、基本的にはGitHub Copilot、ChatGPTのほかに、ウェイティングリストに並んでいるサービスもいくつかある、という感じです。一番よく使っているのはGitHub Copilotです。特にコードを書くときに非常に役立ちますね。
Q: 自動テストを導入したいですが、どんなテストから着手するといいか指針があれば教えてください。アクション単位の結合テストを考えています。
t-wada: アクションが具体的に何を指すのか気になりますが、安定したバックエンドに対する結合テストを指しているのではないかと想像します。この案自体は悪くないと思います。
自動テストがない状況からスタートする場合、最初にテストコードを書くこと自体を難しく感じることが多いですよね。いわゆる「レガシーコードのジレンマ」に直面している場合は、インプットとアウトプットが明確で、動作が安定している部分から始めるのがおすすめです。
例えば、バックエンドのREST APIやGraphQLのAPIのように、HTTPSレベルでインプットとアウトプットが確認できるものが適しています。この方法の良い点は、中の実装に依存せずテストを書けることです。たとえ実行速度が多少遅くても、安定した動作を見込めるため、その間に内部コードをリファクタリングする余裕を生み出せます。リファクタリング後のコードにはユニットテストが書きやすくなり、効率的に品質向上を図れます。
Q: テストカバレッジの計測や可視化は基本的にやった方がいいでしょうか？（計測するにしてもどの指標を使うのか、何％を使うのか）
t-wada: コードカバレッジの計測は基本的にやった方が良いです。しかし、評価指標として使うのは避けるべきです。カバレッジは、チームが自分たちの状況を把握しコントロールできているかを確認するためのメトリクスであり、目標値ではありません。
100％を目指すと不必要なテストが増えたり、メンテナンスコストが上がったりするリスクがあります。また、仕様カバレッジが不足していると、コードカバレッジが高くても安心はできません。カバレッジの数値は、健全に開発が進んでいるかを確認するツールとして利用するべきです。
私は、絶対値ではなくカバレッジの増減に注目しています。増加していればテストに注力している証拠ですし、減少していれば新規コードのテストが不足している可能性があります。
また、テストコードレシオなど他の指標を併用し、牽制しあうメトリクスを組み合わせることで、より健全な開発環境を実現できます。例えば、テストコードとプロダクトコードの比率が1対20のように大きく偏っていれば不健全です。1対3から1対5の範囲に収めることで、テストの質を保ちつつムダを防ぐことができます。
Q: 自分には未就学の子どもが3人いて、技術のキャッチアップに時間を取れる気がしません。t-wadaさんが子育てで忙しかったころ、工夫されていたことはありますか。
t-wada: 子どもが小さかったころは、技術のキャッチアップをほぼ諦めていました。人生にはそういう時期も必要だと思っています。キャッチアップは後で追いつけます。遅れることを心配しすぎる必要はありません。しかし、大きくなった子どもをもう一度小さくすることはできません。子どもが子どもでいられる、短い時間を大切にしましょう。
育児の空き時間にできることもあり、私の場合は耳を使った学びが役立ちました。子どもが小さいうちは両手がふさがってしまうことが多いので、ポッドキャストを片耳で聞いたり、スマートスピーカーを活用したりしていました。
Q: 「テスト書いてないとかそれt-wadaの前でも同じことを言えんの？」で有名なt-wadaさんを、テストを書いていないエンジニアの前に立たせると一体どうなりますか。
t-wada: 実際のt-wadaさんは優しいのですが、相手はビビっているので、まずは誤解を解くところから始まります。
テストを書いていない人は書き方がわからない、苦手意識があるといった理由があることが多いですね。一緒にペアプロやモブプロをして最初のテストを一緒に書くなどしています。
Q: 社内で発表会形式の輪講会を行っているのですが、いまいち全体の理解度が上がりません。輪講会、読書会を行うにあたりおすすめの形式はありますか。
t-wada: おそらく章ごとにまとめて発表するスタイルですね。私はこの形式をやめました。負荷が特定の人に集中しやすいこと、発表しない人の理解が曖昧になりやすいことからです。
代わりに、Google Docsなどの共有ドキュメントを活用し、参加者全員が自由にコメントを書き込む形式を採用しています。「質問は赤、感想は青、引用は黒で書く」といったルールを設け、最後の10〜15分で議論する時間を確保します。
この方法は事前準備が不要で、参加しやすいのが利点です。また、業務時間内に実施することも重要です。例えば、毎週水曜日の11時～12時の1時間を割り当てるなど、仕事の一環として勉強時間を設けることで継続的な参加を促せます。
Q: テストをさぼってしまいます。喝を入れてください。
t-wada: 私は喝を入れるキャラだと思い込まれているのですが、さぼる気持ちもわかります。
ただ、テストというのは意識の高さや義務感から書くものではなく、楽をしたいから書くものです。自動テストは、再確認の手間やミスを減らして楽をするための手段です。
楽をしたい、得をしたいという気持ちは人間として自然なことで、テストを書くことはその延長線上にあります。そこに気づけるかどうか。テストを書くのも、さぼりです。
Q: 保守性の高いコードを書くためにクラスは必須でしょうか？オブジェクト指向の本ではクラスベースの設計を多く感じるのですが、TypeScriptなどでフロントエンドを実装する際にも参考にしてクラスを使った設計をするべきでしょうか？
t-wada: NOです。クラスは保守性の高いコードを書くための道具のひとつですが、必須ではありません。言語やパラダイムによって最適な構造は変わり、TypeScriptならオブジェクトなどの型付き構造体で十分です。
『Clean Architecture』や『エリック・エヴァンスのドメイン駆動設計』などJavaベースの本の内容をそのままTypeScriptやGoに適用すると、言語の流儀に沿わない実装になりがちです。例えばDDD本は過去の技術を前提に書かれているため、現代の技術やエコシステムに合わせて“翻訳”する必要があります。GitHubで「Design Patterns in TypeScript」や「Domain-Driven Design in Golang」などを探すと、現代の言語に合わせた実装例が見つかり、参考になると思います。
Q: 技術系の発表や登壇をするときに一番大事にしてることを教えてください。
t-wada: エモいことを言うと、「聞いてくださっている皆さんの明日を変えること」です。発表や登壇は、自分のやったことや成果を語る場になりがちで、それだけでは踏み込みが浅いと思っています。
私が大事にしているのは、聞いている人にとって自分の話がどんな意味を持つのかを考えることです。自分の話から何を持ち帰ってもらえるのか、どんな影響を与えられるのか。そこを意識することで、ただの発表から講演に進化します。
