00:00
日本最大級のエンジニアコミュニティ Qiita プロダクトマネージャーの
木尾の俊生です。この番組では、 日本で活躍するエンジニアをゲスト
に迎え、キャリアやモチベーション の話を深掘りしながら、エンジニア
の皆さんに役立つ話題を発信して いきます。前回に引き続き、ゲスト
はテスト駆動開発者で、TowersQuest 株式会社取締役社長の和田
拓人さんです。よろしくお願いします 和田さんとお送りする2回目のテーマ
は、テストの意味とTDDの役割です。 僕も結構仕事の中で悩みとかも
あるので、いろいろお伺いしていける とありがたいです。前回もTDDに
触れたきっかけみたいなところは いろいろお伺いしてきたかなと思
うんですが、改めてなぜTDDに着目 したのかというところについて
お伺いできたらなと思うんですが
和田 前回話をしたことと関わって くるんですけど、プログラミング
が好きで、自分のプログラミング に対して自信を持ちたかったん
ですね。自分が書いたコードを自信 がある状態というのに保ち続け
たかったというのと、テスト駆動開発 というのがうまく噛み合ったということ
だと思ってます。それまでTDDというか 自動テストの話なんですけど、自動テスト
を書きながら開発をしていくより 前って、自分が書いたコードを最初
の頃は自分で把握できているし、 いいコードを書いているっていう
自信を持っているものなんですけど、 だんだん書いた内容を忘れていって
しまうし、思ったように動かな くなっていくし、ある不具合に慣
ったら別の不具合が出てくるし みたいな感じで、だんだんボロボロ
になっていって、急ぎの回収とか 入れなきゃいけなくなって、本当
はもうちょっと綺麗にやらなきゃ いけないだろうなと思ってる
けど、コピーアンドペーストで始末 してしまったりみたいな。後から
直そうと思ったけど、その後から っていうのはやってこなかった
りみたいな形で、だんだん自分が 書いたコードをだんだん好きじゃ
なくなっていくんですよね。自信 が持てなくなっていくし、誇り
も持てなくなっていくというのを 自動テストを書く前はずっと経験
していたので、だんだんフライド がすり減っていくとか、あるいは
自信がすり減っていくみたいな 感覚をプログラミングに対して
抱いていました。それに対して自動 テストを書きながら開発していく
特にテストをちょっと前に書いて すぐ実装してリファクタリング
して、テストまた書いてみたいな 感じで、テストと実装とリファクタリング
を繰り返していくテスト駆動開発 のやり方をやっていると、自分が
書いたコードが今も自分が思った とおりに動いているし、それは
03:00
瞬時に確認できるし、直そうと思 ったらすぐに手を入れて直すことが
できて、直している途中で動きが 変わって壊してしまったらすぐに
気づくことができるから、安心して 手を入れていくことができる
というようなテスト駆動開発のやり方 を手に入れたら、静かな自信という
か平穏、心の平穏みたいなのが生まれる ようになったんですね。いつどんな
変化がやってきても、大体何とか できるし、今自分は自分が書いている
駆動の状況をコントロールできて いると。細部までは把握できてない
し忘れちゃってるんだけど、テスト を動かせば、当時の自分が考えた
とおりに今も動いているかどうか っていうのをすぐに教えてくれる
ので、当時の自分が良しとしたので あれば、今もそのとおり動いている
のであれば、少なくとも当時の自分 を信頼することができれば、今の
目の前のコードも信頼することが できるというような、静かな自信
を手に入れた結果、自分が書いている コードを嫌いにならないで済む
ようになったんですよね。気に入らない ところがあったらいつでも直せる
ようになったし、自分のレベルが 上がってもやっぱり既存のコード
って書き直したくなっちゃうん ですよね。自分のレベルが上がったら
自分の上がったレベルにふさわしい コードに書き直すのもできるという
ような地盤を手に入れたので、それが 自分が書いているコードを自信
がある状態で開発をし続ける。かつ 開発のスピードも落とさずに走り
抜けることができると。普段開発 やってるとだんだん後のほうになれば
なるほど状況が把握できなくなって きたり、あるいはいじると不具合
生まれたりして、だんだん同じこと をやるにも余計な時間がかかる
ようになってくるんですけど、バージョン 管理とかテスト自動化とかリファクター
リングっていうのを常に行える ようになっていると、結果的には
そっちのほうが早いということを 経験して、これがうまいやり方だな
と思ってゴリゴリ進めるようになった というのが、テスト駆動化開発を
知ってからの私の率直な感想でした。
まさにテスト駆動というかテスト を書いていくところのうまみっていう
のは、過去を書いてきたところから の地点をスタートにしてまた新しい
ものを追加し続けられるっていう 状態を担保することができるって
ところがメリットなのかなっていう のは蜘蛛を持ってたりするので
今のお話はすごいなるほどなという ふうに思いました。ちなみになんですけ
ど、今TDDのところについていろいろ お伺いしてきたと思うんですけど、
逆にTDD以外に品質を担保するために 当時取り組んでいたこととか勉強
していたこととかってあったり するんですか。
おだしょー 品質の話で言うと別途 勉強したりというのはありました。
ちなみにテスト駆動開発は品質 のためにやってないんですよね
僕は。プログラミングを自信のある 状態に維持するためにやってい
06:02
るので、テスト駆動開発のよくある 誤解というかイメージに品質補償
のために行うやり方であるという ものがあるんですけど、結果的には
その不具合は少なくなるだろう し補修性は向上するので、率直に
言うと品質は上がっている。だから テスト駆動開発は品質補償のため
やり方であると言っても間違い ではないんですけど、じゃあ品質
補償のためにテスト駆動開発やってる かっていうと別にそういうもの
ではないんですよね。ということは 表現を変えるとテスト駆動開発
をやっていたとしても品質が上がっている とか補償できているとは限らないん
ですね。目的が違うからね。という のでテストを書きながら開発する
のにうまくなると、今度はテスト を書きながら開発することの効果
を高めたくなると。効果を高め たくなるっていうのはただ単に
雑然とテストコードを書くよりも 割と意図を持ってテストコード
を書いたほうが、同じテストコード を書いたり、同じテストケース
の数であっても効果が高いということ を知るようになって、なので別途
品質補償のやり方ですね。いわゆる ソフトウェアテストのソフトウェア
テスト技法と呼ばれるものという のはテスト駆動開発に出会って
からもっと後のことですけど、別途 勉強して、結果的にはそこで学んだ
ソフトウェアの品質補償のやり方 をテスト駆動開発のテストに還元
することで、同じテスト書きながら 開発するにしても、なんとなくテスト
を書くっていうよりも意図を持って テストを書くとか、自信を持って
テストを書くとか、自信を持って テストを減らすとか、そういうことが
だんだんできるようになってきました。
なるほど。じゃあ、テスト駆動開発
っていうのは、それをやるだけで 品質上がっていくというよりも、
それはあくまで型であって、その 型を回しながら、新しい他の知識
とかを組み込んでいくことで、より コード自体のブラッシュアップ
が効率よくされていく。結果的に そのコードの品質が良くなって
いくっていうような感じなんですかね。
平岡 そういうことだと思います。品質
を上げるきっかけにはなるんですけど、 テスト駆動開発は。結果的には
品質が上がっていくんですけど、 品質が高いっていうのは何っていう
のを分かってないと、そっちに近づいて いけないんですよね。でもテスト
駆動開発をやってると、そっちが 分かってなくても近づいていける
っていうのがいいことで、例えば 品質が高いっていうのは何っていう
のを、例えば保守性が高いという のが品質が高いという言葉の中の
一つを占めているとしましょうと。 でも保守性が高いっていうのは
どういうことかっていうのはよく 分かっていない。だけどテスト
を書きながら開発すると、保守性 が高くないとテストを書きながら
開発できないんですよね。なので 結果的にはテストを書きながら
開発すると、テスト書きやすいコード を書くようになると、それって結合度
09:05
が低く、凝集度が高いことになる。 それはいわゆる内部品質の中の
保守性の中の理解容易性とか変更 容易性、これを高める。つまり品質
を高めてるっていうことになる。 だけどそれは分かっててやってる
わけじゃなくて、テストを書きやすい 設計を追い求めていくと、テスト
を書きやすいほうに設計が吸い 寄せられていくと、結果的には品質
が高まってるというような、だから 強制ギブスみたいな効果はある
とは思います。
おだしょー ありがとうございます。今の お話はすごい目から鱗だった
というか、イメージやっぱり品質 を高めるってなると、どうやって
品質を上げるのかってところについて 誰でもやっぱり最初勉強しだし
ちゃうと思うんですけど、やはり アーキテクチャだ、設計だっていう
ところいろいろ勉強しだしちゃう と思うんですけど、逆にTDDをやる
と、そこを知らなくても結果的に そっちのほうにコードが前進して
いくというか、より書きやすい、 テスト書きやすいコードっていう
のを極めていくと結果的にいい コードになっているみたいなアプローチ
が、実はTDDっていうものは若干考え方 というかアプローチの仕方自体
も違うんだろうなってお話して すごい目から鱗でした。
おだしょー 結構そこは皆さんに経験 してもらいたいところで、ちゃんとした
設計をしようみたいなことを考える とトップダウンな設計をしがち
なんですよね。全体があって、全体 には部分があって、部分にはさらに
部分が分かれて、さらにそこから 細分化されてみたいな形で綺麗な
アーキテクチャーっていうやつを 考えて、そのアーキテクチャーを
段々段々段階的に詳細にしていけば 品質の高いコードが生まれるみたい
なことを考えがちなんですけど、 だいたいそう思ったようにはうまく
いかないし、そもそも対象が動いて いくの、ゴールが動いていくので、
つまり最初正しいと思ったものが 出来上がる頃に同じように正しい
かどうかっていうと、もっと新しい ものを発見して、新しいゴールに
向かって動いているのであれば、 一番最初に考えた、自分が考えた
最強の設計みたいなやつはもう 最強じゃないんですよね。という
ときにどうやって日々刻々変わっていく 状況に配用しながら、それでも全部
作り直しみたいな状況に陥らずに 柔軟に形を変えながら、その変化
に、世の中の変化についていける かって、全体をちゃんと考える
というより、うまく動く部分を組み 合わせて、その都度最適な状況に組み
直すみたいな感覚があると有利 なんですよね。それってなかなか
言うは易しいっていうか、難しいん ですよね。その感覚をテスト駆動
開発をやると、結構身につきやすい という手応えがあるんですね。そういう
12:04
やり方のことをボトムアッププログラミング と言われることが多いと思うん
ですけど、ボトムアッププログラミング ってどうやるのって、動く部分
一つのことをうまくやる小さい部分 部分を組み合わせて複雑な全体
を組み上げる。複雑な全体をトップダウン に分解していくんじゃなくて、ボトム
アップに再構築するみたいな感覚 でなかなか伝わりにくいところ
をテスト駆動開発はやっていく うちに、その感覚がだんだん身に
ついてくるんじゃないかなという ようなことを考えています。
今のお話聞いていて、TDDっていう のはかなり実践的というか、プラクティカル
な手法なんだなというのをお話 聞いていて、改めて感じました。
おだしょー ありがとうございます。 ここでもう一個聞いてみたいな
っていうのが、TDD実際やっていこう ってなったときに、大体の人は仕事
でエンジニアをやっているって なると、チームで開発ってとこ
に取り組んでると思います。そういう チームで開発をしているときも、
一人でTDDやるだけでいいのか、それとも チームとしてTDDみたいなところ
に対して取り組んでいったほうが いいのかというと、そこに対して
何かアイディアとかありますか。
おだしょー これはもう一人でやるのがいい
です。なんでかっていうと、テスト 駆動開発っていうのは個人プラクティス
だから個人の、極論すると個人の コードの書き方の話だからです。
だからチームでやらないとTDDできない なんてことはないんですよね。例えば
ペアプロ、モープロっていうのは 2人、3人いないとできないんですけど、
テスト駆動開発っていうのは一人 でできる。ある個人のコードとか
設計との向かい合い方の話なので、 つまり自分一人の話なんですよね。
だからソフトウェア開発のプロセス も関係なくって、Azureじゃないと
TDDできないとか相性がいいとか そういうのもなくて、Waterfallでも
Azureでも同じくテスト駆動開発は できます。個人のコードの書き方
の話だからですね。最初のうちに チームに押し付けるっていうのは
あんまりやらないほうがいいと思 っていて、自分でまずできるという
段階に手応え持ってからファンの 人に広め始める、伝え始めるという
のが良いと思います。
なるほど。ありがとうございます。 じゃあそもそもみんなで取り組む
必要もそんなにすごく強くあるん じゃないってことですね。
いい質問で、最終的にはチーム みんなテストコードを書く状態
にはなってほしいですけど、ここ まであまり細かい話をしてこな
かったんですけど、自動テストを 書くやり方がテスト駆動開発だけ
とは限らないんですよね。なので テスト駆動開発っていうのは自動
テストを書きながら開発していく やり方の中の一つです。先にテスト
15:01
コードを書いて、後から実装して リファクタリングしてみたいな
サイクルをくるくる回すのがテスト 駆動開発で、そのやり方にチーム
でこだわる必要はないんですね。 それは個人のコードの書き方の話
だから。チームにとっては、例えば そのプルリクエストがマージされる
頃とか、そのブランチがデプロイ される頃には自動テストが備わって
てほしい。だけどその自動テスト は別に先に書かなくてもいいです。
後から書くでもいい。ただ後から 書くのでもなるべく近いタイミング
に書いてほしいから、だからその日 のうちに書くとか、あるいはその
ブランチがマージされるまでに書く とか、そういったことは最終的には
チームでできるようになってほしい けど、テスト駆動開発というプログラミング
のスタイル、プログラミングの ワークフローの共生まではチーム
レベルではやらないほうがいいと思います。 それは個人の好みの話だからです。
ありがとうございます。すごい今の お話、興味深いなと思ってもうちょっと
そこについて僕も聞きたいなという ところがあったんですけど、やっぱり
今この現代においてソフトウェア を作ってるってなったら、大体テスト
大事だよねって思ってる人が多い と思っていて、何かしらの形でテスト
を書いてる組織とかは多いとは 思ってます。その一方で書いてはいる
けどカバレッジが下がっていっちゃ ってるとか、書いてはいるけど信頼性
がちゃんと担保できてるか不安 みたいな状態に陥っている組織
も同じぐらい多くあるのかなと思 っていて、そういう組織に対して
和田さんの観点からどういうアプローチ でまた改善を、その信頼性っていう
ところを担保できる状態にして いくかみたいなところのアクション
みたいなところのアイディアとか ってあったりしますか。
そうですよね。わかります。今おっしゃ ったのは、今の現状の例えば日本
におけるよくある光景として、テスト がないっていうのもあるかと思えば
テスト書いてるけど効果的ではない みたいな現場もあるんですよね。
テストを書いてるけど何かうまく いっていないというところに対して
入るときは何がどううまくいって ないのかみたいなところを分析
するとか明らかにするとか、そこ から改善していくみたいなやり方
を取るんですけど、大体テストコード を書いているけどうまくいって
いないところって、テストコード を書くっていうことは義務化されてる
んですけど、なんでテストコード を書くのかとか、どういったやり方
が効果的なのかとか、そういった ことがあまりみんな腹落ち感あるいは
理解とかチームでの理解とかがない 状態でテストを書くっていうこと
だけがルール化されて進んでしま った結果、テストコードはあるんです
けど、開発の助けになっていない どころか開発の足手まといになってる
みたいな企業、これも結構あります ね。これはこの20年でだいぶ増え
18:02
ました。20年前ってみんなあんまり テスト自動テスト書いてない時代
だったから、テストは書けば書く だけ偉いみたいな、そんな時代
だったんですけど、今はテストコード っていうのは普通に書く時代になった
んですよね。だいたい普通は書きます と。普通は書きますってなるとや
っぱり全体の位置としては落ちて しまうっていうか、なんで書くか
っていうのが忘れ去られちゃってる ことが多くて、もうそういう決まり
だから書きますみたいな感じにな っちゃうんですよね。そうすると
変化を支えないテストになりがち ですね。いろんな現場で変化を支えない
テストってどういうことかっていう と、機能追加をするとか、バグ修正
をするとか、あるいはアーキテクチャー の変化をさせるというときに既存
のテストが助けにならない、邪魔に しかならないみたいな感じになっちゃ
って、これ邪魔だなみたいなテスト がいっぱいあるみたいなところ。
それを蓋を開けてみると、なんで こんなテストが増えたんだ。こんな
テストっていうのは具体的には 書かれてるけど役に立たないテスト
って、一つは不安定なテストで、動かしても すごい遅いし、しょっちゅう失敗
するし、だけど別に高度が悪いわけ じゃないみたいなフレーキーテスト
と呼ばれるやつらですね。そういう のもあったかと思えば、ユニット
テスト、ものすごい粒度の細かい ユニットテストで、実装の詳細に対して
びっしり書かれてる、網羅的に書かれてる ので、カバレッジは100%近いんですけど、
でも実装に対してものすごく構造 的な結合度が高いので、実装のほう
を変えたらしょっちゅうテスト が壊れるし、でも壊れてるテスト
を見てみると、実装の内部に深く プライベートメソッドのテスト
をしてたりとか、内部変数を見て たりとかで、外部から見た振る舞い
は変わらないはずなのに、内部の 実装をちょっと変えただけですぐ
失敗しちゃうテスト。こういうの が脆いテストって言うんですけど、
脆いテストがいっぱいできてしまって、 結果的には身動きが取れない。設計
の稼働域が狭すぎる。遊びが少な すぎて、設計っていうのはどんどん
どんどん外の変化に合わせて変えて いかなきゃいけないのに、設計
変化を支えるテストになってない というような現場、これもいっぱい
見てきました。この2つがとても多い ですね。テストを書けって言われてる
からいっぱい書いてるけど、全然 現場の助けになってないテスト
たち大きくはこの2つがすごく多い です。
そういう状態になっちゃってる ときに、チームの1メンバーとして
でもそうですし、組織全体として 取り組めることとか、考えていく
べきことってどういうことだった りするんですかね。
そうですね。なので、これはテスト の信頼性というやつを取り戻して
いかなければならなくて、信頼性 っていうのは何かっていうと、まず
テストの成功と失敗がどっちも 信じられるってことですね。テスト
21:00
が成功してるなら、デプロイできる リリースできる。テストが失敗
してるならば、コードのどこかを コードに原因がある、コードのどこか
を直さなきゃいけないという形 にはっきりと分かる。この二択の
状態に判断が収束するのがテスト 自動テストの理想状態です。信頼
がある状態。なんだけどうまくい っていない企業においては、テスト
は失敗してるけど、これは不安定 だからもう1回リトライしよう
みたいな感じで、テストが不安定 であるっていうことが状態化している
とか、あるいはいじってテストが すぐ壊れる。だからあんまり設計
変更をしないようにしよう。既存 のテストを生かしながら開発して
いこうとか、あるいは新しく開発 したときでも、今ある自動テスト
のやり方を基本的に真似してしまう ので、設計変更の役に立たない
ビッシリとモーラ的に書かれた 構造的結合度の高いユニットテスト
が書かれていて、開発の邪魔になっている にもかかわらず、新たに書かれた
コードに対しても、やっぱり同じ ような構造的結合度の高いテスト
を書いてしまう。これもすごくよく あることです。基本、コードの内部
品質ってやつは、あるタイミング で上げるぞと決意しないと、基本
的に上がらない。じわじわ下がって いくものなんですよね。基本的に
コードの編集って、だいたい既存 のコードを真似してコピーアンド
ペーストして、で、ちょっと直して みたいな形のことが続いていくん
ですね。しかもこれが良かれと思 って行われていて、それは、例えば
本当はもうちょっと中くらいの修正 をしたほうが、全体としては良い
状態になるとか、重複が少ない状態 になるんだけど、GitHub上で、ブラウザ
上でコードレビューをするときの コードレビューをやりやすくする
ために、diffを小さくしたい。diff を小さくするために、小さなif分
の追加だけでとどめるようにしよう みたいな感じの、良かれと思って
小さな変更を行うというのが、ちょっと 視点を引いてみると、全体の複雑性
をじわじわ上げ続けている。つまり 補修性を下げ続けているという
ような現場がたくさんあって、良かれ と思って、新しく追加された小さな
if分に、びっちりと密着したテスト を書いちゃう。そうするとその設計
が固着化してしまって、本当はもっと リファクターして、そのif分自体
をなくすべきなのに、if分をなくす とテストが壊れるみたいな感じ
になってしまって、だんだん良かれ と思って小さな変更をして、良かれ
と思ってびっしりユニットテスト を書いて、その補修性、よく引いて
みると補修性の低い状態っていう のがずっと維持されてしまうっていう
のが、いろんな現場がテストを書く ようになってさえ良かれと思って
補修性を下げ続けてしまうみたいな 結論になっている、結果になっている
24:02
っていうのをコンサルタントとして はたくさんの現場で見ています。
じゃあその品質をまずはやっぱり 上げていこうという意思を持つ
で、やっぱりそのちっちゃい変更 っていうところ自体が結果的に
品質を下げているってところを認識 して持つってところがまずアクション
としては大事って感じですかね。
なので結論として述べると、自動テスト って変化を支えるためにある、ソフトウェア
は変化をしなきゃいけない。変化 を安全に素早く行うために自動テスト
で支えるという順番のロジック なんですけど、変化を支えない変化
の邪魔になる自動テストがたくさん 書かれていることが多くて本末
伝統になっているというのをたくさん 見ています。
ありがとうございます。結構最近の エンジニアリング取り組んでいる
エンジニアプログラマーであれば テスト書くってところ意識は持って
やってはいると思うんですけど、 そこに対して今そういう取り組み
をしている中で何となくやっぱり さっきのお話みたいな感じでうまく
いってないなっていうふうに思 ってたりする方も多いと思うので
そういう方たちに対して何か最後 アドバイス的なメッセージがあれば
お伺いできたらなと思います。
ちょっとだけ繰り返しになるんですけど ソフトウェアってソフトだから
ソフトウェアなんですよ。ソフト 柔らかいからソフトウェアなんです。
柔らかいっていうのは変更に対して 柔らかいっていうことです。ソフトウェア
エンジニアとして開発していく っていうことは不確実なものと
ひたすら戦うってことなんですよね。 自分が思ったものと違うとかもっと
良いこと思いついちゃったとか 世の中変わってしまったとかそう
いったいろんな変化によって 自分が書いたソフトウェアって
どんどんどんどんそれに合わせて 形を変えていかなきゃいけない。
だから良いものを作れば形を変え なくて済むってんじゃなくって
形を変えられるやつが良いやつ なんですよね。良いやつって形
を変えるっていうのを支える自動テスト を書いていけるようになりましょう
と。形を変えられる自動テスト を書いていきましょうってなる
と実装に対して結合度が低い つまりインテグレーションテスト
とかエンドツエンドテストを書いて 開発をすればいいんだなって思う
人がいるんですけど、それはそう ではないんですよね。その辺り
は詳しくは私の別の講演を渡って いただいたりこの後話をいろいろ
していければと思うんですけど そんな甘いもんじゃないんですよ。
つまりE2Eテストなら実装の変更 し放題じゃないって思うけど、実装
の変更を支えるテストにE2Eテスト がなれるかっていうとそうでもないん
ですよね。だからいろんなテスト があります。テストスコープでとって
もE2Eテストがあったりインテグレーション テストがあったりユニットテスト
があったりするんですけど、そうい ったテストをバランスよく配分
することで初めて素早く自信のある 変化を支える開発ができるので
自分はこれだけ覚えれば大丈夫 だみたいなやり方は残念ながら
27:03
ないんですね。ないんですけど だからないっていうのを認識した
上でじゃあどういったテストを どのくらいの割合で入っていけ
ばいいのかなっていうのを認識 したら学び始める入り口になる
ので結構難しいことを言っています がソフトウェア開発ってちゃんと
やっていこうとすると変化について いこうとすると結構いろいろ
考えなきゃいけないんですよね。 っていうのでいろいろ考えなきゃ
いけないっていうのをきっかけ として自動テストもその一つとして
認識してもらえればと思います。
ありがとうございます。本当に今の 話は僕のチームに持って帰って
やっていこうっていうふうに言いた くなりました。
和田さん今日はありがとうございました。 まだまだお話ししたりないので
次回も和田さんとお送りします。 今日は和田さんとTDDについていろいろ
お話をしてきました。本当にすごい 僕自身も開発の現場で
チームマネジメントしてたりもしますし 僕もコード書く機会があったり
するので本当にすごいなるほど なって思うシーンがすごく多かった
です。特にTDDっていうものはそれを やるだけで品質が上がるっていう
よりもやっぱりそれは開発のあり方 というか一個の型でしかないっていう
話がすごい印象に残りました。 逆に言うと今本当に今この瞬間
から始められるっていうところ もやっぱTDDの良さなのかなとは
思ったので僕も今日をきっかけに ちょっとまたトライをしていこう
かなと思います。ありがとうございます。
さてこの番組では感想や次回 ゲストへの質問リクエストなど
お待ちしております。番組詳細欄 にあるリンクよりお気軽にご投稿
ください。XではハッシュタグKita FM をつけてポストしてください。表記
は番組名と一緒でQFMが大文字 残りは小文字です。そしてApple Podcast
やSpotifyのPodcastではレビューも できますのでこちらにも感想を
書いてもらえるとうれしいです。 Kita株式会社はエンジニアを最高に
幸せにするというミッションの もとエンジニアに関する知識を
記録共有するためのサービスKita 社内向け情報共有サービスKitaチーム
を運営しています。ぜひカタカナ でKitaと検索してチェックして
みてください。来週も火曜日の朝 6時に最新話が更新されます。番組
のフォローをして最新話もお聞き ください。お相手はKitaプロダクト
マネージャーの清野俊文と ワールドスペースト株式会社の
原拓とでした。
