00:00
日本最大級のエンジニアコミュニティ Qiita プロダクトマネージャーの
清野 俊予です。この番組では、 日本で活躍するエンジニアをゲスト
に迎え、キャリアやモチベーション の話を深掘りしながら、エンジニア
の皆さんに役立つ話題を発信して いきます。前回に引き続きゲスト
は、ドメイン駆動設計入門 ボトム アップでわかるドメイン駆動設計
の基本の著者 成瀬 允宣さんです。よろしくお願いします。
成瀬 允宣さん よろしくお願いします。
おだしょー よろしくお願いします。成瀬 さんとお送りする2回目のテーマ
は、エンジニアの登壇者モチベーション です。今回はアウトプット、登壇
というところと設計についていろいろ お伺いできたらなと思っております。
成瀬 はい、分かりました。
おだしょー 今回はまずアウトプット のところのお話を伺う前に、本当に
成瀬 さんといえば設計というところ があるかなと思うので、設計について
そもそもいつ興味を持ち出した のかみたいなところをお伺いしたい
なと思うんですが。
成瀬 はい、分かりました。設計 についての興味はいつ頃だった
かな。結構初期の頃にこういった ところに興味が湧いた記憶があります
ね。
おだしょー そうなんですね。
成瀬 具体的なきっかけとしては 多分SIRにいたんで、ちょっと大げさ
に言いますよ。こんな金額で作って もらったのにコードこれなんですか
みたいな。そういう状況もある じゃないですか。ちょっと今大げさに
言いましたからね。そういった コードを作らないようにするためには
どうすればいいか。むしろ金額 に見えるコードってどんなもん
なんだろうっていうところから 入っていって、設計っていうところ
に少しそういった分野に興味が 湧いてきたんですかね。
おだしょー なるほど。その当時って 具体的にどういうことから勉強
し始めたとかありますか。
成瀬 当時勉強したのはオブジェクト 試行プログラミングですかね。まだ
当時はオブジェクト試行10年以上 前の話なんで、犬とか猫とかそれ
で説明する時代でしたね。今も そうなのかな。それを使ってどういう
ことができるのかっていうのを 自分なりに考えていったっていう
のが始まりですかね。
おだしょー うんうんうん。ありがとう ございまして。本当にオブジェクト
試行設計みたいなところから始ま っていって、僕の中の成瀬さんの
印象で言うとやっぱボトムアップ DDDの印象がすごい強くて、僕は
本当にあれを新卒ぐらいの時から ずっと読み込んでいたので、すごい
その印象があるんですけど、DDD みたいなところはいつ勉強始め
たというか。
成瀬 オブジェクト試行プログラミング から勉強を始めていって、独学
なんですけど、何でこのコードはこう 書くんだろうっていうのをまず自分
で掘っていくんですよね。そのうちに やっぱり本っていうものが少し
当たっていくわけなんですよね。オブジェクト 試行の本っていろいろ読んだん
ですけど、入門書はだいたい見たり 寄ったりで一つ読めばいいかな
って感じですよね。そこから先で 当時読んだのが、リーダブルコード
なんか本当に初期なんで一番最初で コードコンプリートか、あそこら
辺が初心者向けの中級者に上がる ときに読む本なんですよね。それ
03:01
読み終わってなんとなくイメージ ついてきたな。そこからさらに
いわゆる自分が中級者になったと思 ったんですよね。こっから先どう
すればいいんだろうっていうところ で本を探したのがエリック・イヴァンス
のドメインクローセッケーだったん ですよね。そこでドメインクロー
セッケーと出会ってしまって全然 何言ってるかわかんないんですよね
最初ね。エリック・イヴァンスの ドメインクローセッケーの本は
第1章から何の話をしてるか全然 わからないんですよ。僕前回お話
した通り完全にコンピュータサイエンス の知識がもともとなかったんで
バスとか言われても何の話みたいな 電子回路全然わかりませんっていう
世界でイヴァンスの本って最初電子 回路の話しか入るんですよ。モデル
リングするのに。そこで出会って 本を読んで10回ぐらい読んで何と
なく通して読めたな何回も寝落ち したなっていうところからDDDっていう
ものに触れ始めましたかね
そうなんですね。本当に本で座学 でどんどんどんどんインプット
をしてDDDっていうところは身につけて いったって感じですね
そうですね。オブジェクト思考プログラミング の延長でイメージしてます僕の中
には
そうなんですね。ありがとうございます そんな感じでDDDっていうところ
を勉強し始めたと思うんですけど 最終的なアウトプットとしては
本だったり先ほどお話ししたボトム アップDDDみたいなところにつなが
っていくわけじゃないですか なぜ その執筆をしようっていうモチベーション
に変わっていったんですか勉強 していたところから
そうですね。ドメインクラウド 設計自体は最初オブジェクト
思考プログラミングの延長線として 読んでたんですけどどうも読んで
いくとこれはソフトウェア開発 全般をテーマにしてるんだなっていう
ところが見えてきてなるほどそれ はこれ読みづらいわけだと僕は
プログラミングの本だと思ったら ソフトウェア開発の本だったということ
に気づいたんですよねそれする とかなりすんなり読めて皆さん
もし読むんだったらそれお勧め なんですけどそれ読んで自分なり
に習得しましたあとは実践しましょう って自分なりにいろんなプロダクト
でもうこそこそ勝手にやったんですけど 僕がモデリングするとこんな
感じでやったら人にも伝わるかな お客さんにも実際にプログラミング
が少し分かるお客さんって結構 SIRでいるんですねガス会社とか
その人と一緒にこういうモデリング とかしてみてこういうのがドメイン
駆動設計かみたいなところから 入ってかなり自分なりに習得でき
たと思ってたんですねある日DDDCG っていうドメイン駆動設計の日本
のコミュニティーがあるんですね ここに当時入ったんですよ当時
も何かの本を読んでいて4回目だった のかなふらっと僕入ったんですよ
ラジオ間隔で聞いたらみんなの 疑問に思ってるところあれ俺答え
れるなって気づいたんですよ ちょっとマイクつけて当時ゲーム
とかやってたんでオンラインゲーム も特にマイクあったんで質問に
答えてたらみんなの質問全部僕 答えれたんですね考えたのがあれ
これは土原化せんとあかんみたいな 感じになったんですよ何かっていう
ともう自分が知ってることなん だからみんなに教えてあげなきゃ
っていう気持ちですね当時僕が プログラマーの業界に入って一番
06:00
あったことで言うと何しろ改定 市場なんですよやりがい作詞みたいな
話でそう考えると僕みたいなもう ペーペーってどうなるかっていう
ともうほっとかれるわけですよね で勝手に這い上がってくるなら
這い上がってこいよというそういう 雰囲気が蔓延してましたそういった
人たちに対して手を差し伸べる 文句がなかったからじゃあ俺ぐらい
が差し伸べてやるかみたいなっていう 話じゃないですけど本当にそういう
のが嫌いなんで何かしらみなさん のその助けになればいいなっていう
ところから始まったのが本を書く という計画ですね
そうなんですねちなみに その計画をしてから一切ブログ
もそうですし本っていうところ にどんぐらいの年月で達成しているん
ですか
あれ自体は8ヶ月ぐらい ですかね
8ヶ月
ちなみに当時の計画で言う と本を出すには僕みたいな無名な
人が本を書くにはどうすればいい か本と同じぐらいの分量を書け
ばいいやろうって言ってだから ボトムアップDDDっていう記事を
書いたんですよ
そうなんですねあれ
なのであれは10万文字 ぐらいあるんですよ
ありますね開くたびにちょっと 重たいな
そうですね今時のホームページ にしては開くと2秒かかるっていう
ところなんですよねそのボトム アップDDDの記事を持って出版社
にこんなん書いたんですけど本 にしませんかって出すっていう
もうちょっとの作戦でした他に もう1個作戦があって有名になれば
本出せるだろうっていう感覚も ありましてやろうとしたのがイベント
ボトムアップDDDを書きました じゃあそれを実際にセミナー形式
でやってみましょうっていうの をやったんですねあれが全部で
3回やりましたけど150人120人100人 集まったのかな
1人で集めたんですか
そうです単独イベント でした今皆さんもしかしたらあん
まりそこら辺の感覚ないかもし れませんけど当時は結構オフライン
のイベント多かったんですよね まだコロナの前だったのでとはいえ
50人行けばいいところだったん ですけどコミュニティの力もあって
150人ぐらい集まってくれたっていう のが最初でしたね
そうなんですねすごいちなみに その子本を書こうっていうところ
動き始めてらっしゃったと思うん ですけどその前から登壇だったら
アウトプットはしていたんですか
いやないです
ないんですかそこが初めて でそこで始めていったんですね
本を書こうと決めた タイミングから登壇自体は始め
ましたね
そうなんですね
実際僕の記憶に残ってる ので言うと2018年の9月だかそん
くらいだっけなにプログラミング 生放送っていうグループがあって
そこでクリーンアーキテクチャー の話をしたのが多分外向けの初めて
の発表でしたねなんかクリーン アーキテクチャーの典型的な実装
を使って今までアーキテクチャー がなかったチームにもたらしました
そのやり方はツールで防衛するんだよ みたいなそういう話なんですよね
実際それをやって受けがよくて っていうのもあったり要するに
地道な活動をしてファンを増や していかないと本が出せないと思
ったんですね今思えばやらなくて も出せたなと思います
09:01
そうなんですねじゃあ本当に その本を出版するっていうところ
目標から逆算して計画的に登壇 だったらアウトプットをしてらっしゃ
るってことなんですね
そうですね
そうなんですね
やること自体は計画的 なんですけどその登壇自体は全然
計画的じゃないんでとにかくやる しかなかったんですけど
そうだったんですねいや お話聞いててやっぱり業界とか
に課題を持ってらっしゃるエンジニア 方とかプログラマーの方って絶対
いらっしゃると思うんですけど そこを実際行動に移すのってやっぱり
また別の話だと思っていてなんで そこの行動にコミットできたのかな
なんか結構な時間とかを使って らっしゃるじゃないですか使った
ことが
そうですねトラウマという ものは自分で何とかするしかなくて
結局自分がほっとかれる側だったん ですよねこの業界に入った時は
なのでなんでこんな簡単なことも 教えてあげないんだろうっていう
なんでこんな簡単なことも教えて くれないんだろうっていうレベル
なのかな分かってしまえば一言 言えば分かってしまうことって
いっぱいあるんですよねじゃあ そういったものを伝えてもう僕
みたいな立場の人がいたら助け てあげたいなっていう気持ちなんですよ
ねだから半分その業界全体に対する 怒りと自分と同じような立場に対する
同情みたいなトラウマを克服する 場面が近いですかね
そうだね自分自身もやっぱり そこを身をもってやっぱりトラウマ
というかこういろいろな思いは していてそれを同じ鉄を踏ませない
みたいなやっぱり気持ちが強かった 感じなんですか
そうですね全然トラウマ ってことには感じてないですけど
やっぱりそういう人たちかわい そうだよなっていうのが僕一番
嫌いなんでそこら辺は何とかして あげたいなっていうのが一番の
思いですかね
そうなんですよなんかその 気持ちがそれをやっていくことの
大変さとかを上回っているのが すごいなっていうふうに思いました
でも人ってそういうもん じゃないですかね人が協力できる
のってそこがあるからだと思うん ですよね例えば人との関係がない
とドブさらいなんてやんないんですよ 町内会でドブさらいができる理由
ってそのコミュニティが存続する からじゃないですか僕はこの業界
このコミュニティでやっていき たいだからこのコミュニティの
ために寄与したいっていう気持ち があるんですよねだから少し自分
が損をしたとしてもトータル良く なればいいじゃないかっていう
動きができるそれが強いコミュニティ だと思うんですよねなので誰でも
これはできると思うんですよね そこにどれだけ強い思いがあって
どれだけコミュニティに寄与したい コミュニティを続けたいのか自分
がそのコミュニティにどれだけ 所属したいのかっていう思い次第
かなと思いますね
本当にそういうふうに思って動 いてくださる方がいるからこそ
今の日本のプログラマーのコミュニティ エンジニアリングのコミュニティ
がここまで発展してこれたんだろう なっていうふうに改めて思いました
そうですねいろんな人の多分思い があって今この形はあると思う
ので僕もやっぱりそこら辺は結果 としてできたところ以外にもこれ
までどんな思いが渦巻いてここ まで来たのかっていうのやっぱり
興味がありますね
本当にすごい自分は今恵まれた 環境にいるんだろうなっていう
ふうに思いました
12:01
じゃあ今度は逆にコミュニティ エンジニアリングにコミュニティ
する側になればいいなと思いますね
そうですね僕はKiitaのプロダクト マネージャーでもあるのでKiita
を通してそういうのもやっていき たいなって気持ちはすごい思って
たりします
そうですねただ本当にこのPodcast TodayFamでもそういったことにコミュニティ
エンジニアリングできてるとは 思いますけどね
ありがとうございますそう言っていただける のすごい嬉しいです
素直にだってこれ自体はいろんな 人に参考になる情報を発信しよう
っていう気持ちがないとできない と思うのでそういった意味でも
やっぱりコミュニティエンジニアリング できてますよ
めちゃくちゃ嬉しいですそう言 っていただけてちょっと話題変え
させていただくんですけど今の お話だと本を出版するところまで
目標にいろいろ登壇とかアウトプット をしていたってお話だったじゃない
ですか
はい
今ある意味で1回本は出版していて ある程度その本を私も僕自身も
その1人なんですけど設計っていう ものがどういうのかっていうのは
そういう方はすごい増えてきてる かなと思うのでただ現地点でも
やっぱナルセさんといろんな活動 してらっしゃるじゃないですか今の
モチベーションって何なんですか
誰かが欲しい知識があってそれを 自分が持ってるならばさらけ出し
ましょうみたいなOSSの感覚でも いるんですけど
そうなんですよね
はい多分僕が持ってる知識なんて みんなが同じ時間かければとっくに
同じとこまで来れると思うんですよ ねじゃあそれで例えば10年かけて
俺と同じポジションに来ました っていったときにちょっと明け
付けには僕にメリットないんですよ じゃあ僕がそれを教えてあげて
10年かかるものを3年に減らしました いや感謝してくれるはずじゃない
ですか将来僕は追い抜かされる の確定しているのでそのときに
僕のことをちょっと覚えててくれたら 嬉しいなみたいなそのくらいの
感覚ではいますけどね
そうなんですね
だから普段小学校とかあと学生 の支援とかしてるんですけどそこ
ら辺もやってるのもそれが理由 でもちろん尊い言い方できます
けど自分なりのメリットで言う とお前を教えたのは俺だからって
言いたいみたいなそれを相手が そう思うかどうか知らないです
けど少なくともそんなことをして みたいなとは思っていますそれ
だけですね
そうなんですね僕も一時期小学校 とかに行ってプログラミングを教える
みたいな取り組みをやらせていただ いたんですけどやっぱ小学生とか
中学生って本当に吸収力が半端 ないというか
そうなんですよ
どこまでこの時間だけで理解できる のみたいなスピードでプログラミング
とかを理解していくので恐ろしい なと思う反面やっぱこういう子たち
が次のソフトウェアを作っていって くれるのはすごい明るい未来が
待っていそうだなという希望にも なるなと思ってます
そうですね本当に小学生たちと 一緒に何かしていると分かるんです
けどこの時代からパソコン与え られてこんなんやられたら絶対
勝てるわけないじゃんって思うん ですよね僕なんか25からですよ脳
ミソの脳細胞減っている段階から 始まってるんで絶対勝てないんですよ
ねそういった意味でいうと彼ら が成長するせざすけ少しでも
さらに前に行くの加速させてあげる のが僕の仕事の一つなのかなと
は思ってはいます
そうなんですねいや素晴らしい なと
ただ逆に今一個少し僕が懸念に 感じているのは小学校の現場に
15:02
いるから感じているのがちょっと そういったプログラミングとか
がもてはやされすぎているなという のは少し感じています
なるほど
プログラミングできるからそれ だけでいいっていう子がたまに
いるんですよねとはいえやっぱり もちろんテクノロジーの分野で
自分ですごいテクノロジーで何か を作りましたっていえば一生それで
いけると思うんですけどなかなか それって本当に一握りのうちの
一握りのうちの一握りぐらいなんですよ ね塩の一粒ぐらいなんですよね
そう考えるとプログラミングとか 自分の興味がある分野以外を捨てる
のは良くないよなっていうところ をどのように伝えていくべきかな
っていうのはすごく悩んでいます 特にそういったことを話している
と気づくのがすごく話を聞いて ほしがるんですよねなぜならば
僕がたまに行くとそういうこと が分かる人間だから親御さんに
話しても分からないんですよね そうなると家庭となのかっていう
と親御さんもすごいねって言う しかなくてどんどん好きなこと
をやらせるしかなくなってしまう っていう現状があって課題は感じ
ていますねちょっと話を逸れました けど
ありがとうございますでもそれって 大人になってからのエンジニア
としてもそこら辺の課題って発生 しやすい気はしていて
そうですね一つの大きなことを やろうとするとどうしてもチーム
プレイっていうのが必要になるん でもちろん誰でもすごいジェネラリスト
が必要かって言うとそうでもなくて スペシャリストが必要ではあるん
ですけどスペシャリストにも多少 のコミュニケーション能力だとか
多少のセッション能力とか多少 のネゴシエーション力があると
より強くなれるんでちょっとそこら 辺をばっさり切らないでほしい
なっていうのが僕の思いであります ね
そうですねやっぱり一人で作る ものよりそもそもみんなで作る
もののほうが大きいことはでき たりもしますし
そうですね
そこら辺をうまくやっていくこと 自体も需要としてはエンジニア
とかプログラマーには求められている ものだと思うので
そうですねただ最近だとAIがかなり サポートしてくれるからそれも
ちょっと変わってきてしまう未来 が来るかもなと思いながらも
どこまで一人で作りきれるようになる のかっていうのはちょっと楽しみ
でありながら少し怖いですね
ここまででアウトプット登壇っていう ところでいろいろお話伺いして
きたと思うんですけどまとめる とアウトプット登壇を通してナルセ
さんが手に入れることができた もので何になりますか
一番分かりやすいもので言うと 言語化能力ですかね
言語化能力
はいなぜそうするのかっていう のを全て理由付けしないと誰にも
伝わらないんですよねこれをこういう ふうにするのはこういう理由がある
からだよ簡単に言えばこのコード をこのクラスのこのメソッドに
書いたのはこういう理由がある からだよっていうことを一つ一つ
言語化していくっていうことを 鍛えた結果能力になりましたみたいな
誰でも言語化する能力はあると思 うんでそれがより人よりもちょっと
自分で言うのも悪いけどうまく できるようになったんじゃない
かなとは思います分かりやすい エピソードで言うと学生の前で
チャットGBT使ったんですよねその 時に僕のチャットGBTに対する打ち込み
のやり方が学生たちが見て思った のがナルセさんすごいですね言語化
能力って言ったんで多分そういう ところがかなり鍛えられてるん
じゃないかなと思いますやって ほしいことを伝えるってのも言語化
能力だと思うのでそこがうまく できるとここから先も生きていける
18:03
んじゃないかなちょっと分かんない けどみたいなノリですかねこれが
一つ目ですねあとは副次的なもの なんですけど仲間っていうものは
もちろん得られましたねある程度 の高みと自分で言うのも恥ずかしいん
ですが山の頂上に登ると隣の山の 頂上が見えるんですよそこにいる
人と話があうんですねそういった 意味で言うとやっぱり別の山の
頂上かもしれないですけど話する とすごい深い知識をお互いに共有
することができてより発展的な 話ができるっていうのが多いん
ですねどうしてもやっぱり教える 立場になることが多いんで同じ
レベルで会話できる人間って結構 少なかったりするのでそういった
意味で言うと仲間っていうもの がもちろんチームの仲間もいます
けどそういった方面の仲間ができました っていうのが一つありますかね
最後はもちろんアウトプットする と大体分かると思うんですけど
信頼っていうのはやっぱりもらえ ますよね外向けで何かをしている
ってことはそれなりの作法も求め られますし例えばどんだけいい
話したって駅の駅前でゴミを床 に捨ててたら幻滅するじゃない
ですかなので立ち振る舞いっていう のを気をつけながらそういった
信頼を得ることができたので逆 に仕事にもそれを使うことができる
みたいな一旦特にチームに求め られるのはこういうディスアグリ
アンドコミットっていうのがあるん ですけど拒否はするけど仕事は
ちゃんとコミットするっていう 考え方ですねそういったところ
でうまく動けるのは信頼関係が あるかなと思うんですよね自分
の考えとは違うけどでもリーダー がこう言っててチームとしては
リーダーのことを立てようリーダー の言うとおりに一回進もうじゃない
とチームが破壊しちゃうからっていう ところはやっぱり信頼を使って
いく使っていくのは違うのかな 信頼って多分使うものじゃない
と思うんですよね積み上げた信頼 を見てもらうっていうものだと思
うんですけどね仕事に優位に働き ますよねっていうのがあります
ね何かを成し遂げるってときに そんな3つですかね言語化能力と
仲間と信頼ですかねなんだこの 少年漫画だよな
ありがとうございます本当にアウトプット だったり登壇を通して本当に周り
に人が集まってくるしやっぱそれが 自分自身の資産にもなるしそこ
でやってきたこと自体が自分の 信頼にもつながっていくってこと
ですね
番組ではリスナーの皆さんにも 参加してより楽しんでいただける
ようゲストに質問したいことを 番組詳細欄にあるフォームにて
事前に募集しています採用された ご質問は番組内で紹介し直接ゲスト
の方にお答えいただきますでは 早速リスナーネームボウキチさん
からのご質問です今仕事でドメイン 駆動設計のプロジェクトに関
わっています現状あまり大きくない 規模のプロジェクトをドメイン
駆動設計で開発しているため各階層 の抽象化によってDTOデータ交換
オブジェクトや各階層での単体テスト が増えるなど一位開発者にとって
はあまりメリットを見出せなかった のですがどの程度の規模でメリット
を感じられるようになりますか っていうのが来てますこれちょっと
僕も気になりますね
この質問を聞いてまずいろいろ 前提を揃えなきゃ多分うまくい
21:02
かないなと思いました長くなります よまずドメイン駆動設計って言葉
が出ましたけどどれなんだろう って思いましたなのでそこをまず
考えましょういわゆる僕の感じ ているドメイン駆動設計でソフトウエア
開発全般を取り扱ったものなんですよ ねモデリングから含めたソフトウエア
開発っていうものなのかそれとも レイヤードアーキテクチャーとか
そういった方針に沿ったことを 言ってるのかっていう話ですおそらく
後者ではあると思うんですけど 一旦前者の話モデリングソフトウエア
開発全般という前提でまずお答え していくとやっぱりある程度の
規模は必要かなと思いますどういう ときに取り入れるといいかなっていう
ところで言うとプロダクトオーナー 側と開発者で意思疎通がうまく
いかなくなっているときとかあとは 開発チーム同士でもそこが生まれている
とかのときに使うとそれこそモデリング したら出来上がったモデルをコード
に落とし込みコードからフィードバック 得てモデルを洗練させてまたそれ
をコードに落とし込むっていう フィードバックループあとは開発
チーム同士がどうやってやり取り するかみたいなそういうドミニク
の設計で取り扱われるテーマに沿 ったやり方がうまく効いてくるん
じゃないかなとは思いますなので 多分課題取り分なんですよね規模
じゃないと思うんです明確にこういう 課題があってこれにどうもうまく
いきそうだなって思ったら採用 すべきだと思うんですよね逆に
言うと課題がないんだったらやめ たほうがいいんじゃないと思うん
ですけどその上でも規模で言うん だったら大抵人間が4 5人も集まる
と疎後起きるんですなので5名 ぐらいの開発チームメンバーでも
取り入れるメリットはあるかな と思いながらもなかなかこれを
やっていくのは全員がやりたい っていう気持ちがないとなかなか
難しかったりするのでそこの兼ね合い ですかねっていうのが一つ目の
ソフトウェア開発全般で考えた ときのドミニクの設計の取り入れる
タイミングですかね逆にレイヤー とかの話になってくるとレイヤード
アーキテクチャーとかそこら辺の 話かなともちょっと思ったんですよ
そういった意味で言うとLPサイト とかでもなければ常に入れとく
べきじゃないっていうのが僕の 持論ではありますおそらくこの
依存されたときにイメージされている のが書くときの面倒さなんですよ
ねクラスを作ること自体に僕は あまりデメリットは感じていないん
ですもちろん整理するとか管理 しなきゃいけないもの増えるんです
けど分かりやすく今回のお話で 言うとレイヤーで言うとコントローラー
層とアプリケーション層があります モデル層もありますインフラ層
もありますそれぞれのテストを 書かなきゃいけませんっていう
ところがなかなかメリットが感じ づらいっていうご質問がありました
けどおそらくテストを書くっていう まず前提から言うと分けないと
つらいんですよね一つ一つ分ける ことでテスト自体は単純になって
いくんですよね逆にこれを一つ に合わせてしまうとおそらく依存
24:04
オブジェクトコードが使うオブジェクト いろんなものをいっぱいディペンデンシー
インジェクションっていうんですか ねして依存オブジェクトの制御
をしてかつ本来だったらアプリケーション 層とかドメインモデル層かに分散
される条件分岐も一つのところ に書かれるんですよね分岐と分岐
と分岐が重なっておそらく分岐 の爆発が起きるんですよそうなる
と単体テストを書くのが非常に 難しくなってくるなので分けて
単純でそれぞれのクラス自体は 確認すべき条件向きはこれです
よねそれぞれを合わせたインテグレーション テストをすることでうまく動く
ことを保証していくっていうスタンス でいうことを分けちゃったほう
がいいよねっていうのが一つの考え方 もちろん人間って何かを理解する
ときにあまりに情報量が多いと 理解するの難しいので抽象的に
捉えていく必要があるので小さい 単位で抽象的に捉えていくっていう
行為をしやすいのは分けたほう がいいでしょうとは思いますなので
イメージとしてはクラスを定義 するのがめんどくさいとかそういう
話だと思うんですよねその意見 もすごく分かるんですシステム
って結局長く続くものなので書く ときよりも将来を見越して何年
続くかっていうことを見越しながら そのときにどういうことが起きる
かというのを想像しながらアーキテクチャー 方針を決めていくんですよねなので
単体テストただ僕それでめんど くさいって気持ちを否定したくなくて
じゃあめんどくさいならどうする かっていうと僕だったら多分スケルトン
を作るツールを作ります単体テスト を作るのはめんどくさいですじゃあ
単体テストをこうやってUIで選ん でポンと作るべきgiven when thenとか
自分で書くんだろうけどベース となるスケルトンクラス作って
あげたりgiven when thenも入力する とパッとメソッドが入るみたいな
単体テストのメソッドですねそんな 仕組みをよく仕入れたりはします
なので一応今のが回答かな何か しらの方針とか計画アーキテクチャー
とかいうものは1ヶ月以上続くシステム であれば取り入れたほうが優位
に働くみたいな意見もあった気 がしますただこれアンケートベース
だったんであんまり信憑性ないん ですけど感覚としては1ヶ月も
続くものだったら入れるべきじゃない っていうのが業界の意見ですかね
ありがとうございますまさにやっぱり アーキテクチャーって後から変更
するのがそもそも難しかったり とかコストが高かったりとか今
お話の中にもありましたけど大規模 になっていっても情報量をできる
だけ増やさない爆発させないっていう のがいわゆるレイヤードアーキテクチャー
とかそういうものを取り入れる ところメリットかなと思うので
逆に言うと今の始めたときのスピード 感で大きくなってもやり続ける
ことができるってこと自体がメリット になるのかなっていうのは僕は
思ってたりはします
そうですねなのでもちろん面倒 くさいっていう気持ちはちゃん
と受け止めるべきなんですよ僕ら はねだってエンジニアリングって
何したいかっていうとみんなの 面倒くさいを解決するんですよ
ねだから開発チームが面倒くさい と思うならそれを解決するのエンジニアリング
で解決するのが一番楽しいとこ なんで皆さんにもぜひやってほしい
なと思います
ありがとうございますナルセさん今日は ありがとうございましたまだまだ
27:05
お話ししたいないので次回もナルセ さんとお送りします今回はナルセ
さんにアウトプットだったり登壇 っていうところをやってらっしゃ
う理由みたいなところをいろいろ お伺いしてきました本当にお話し
聞いていて今のコミュニティー っていうのはやっぱりナルセさん
みたいな方が過去いろんなことを やってくださったおかげなのかな
って本当に感じました聞いたも エンジニアコミュニティーとして
いろいろやってる場ではあるので 本当にそういう先陣のところを
いろいろ学びながら僕もいろいろ やっていきたいなっていうふう
に思いましたさてこの番組では 感想や次回ゲストへの質問リクエスト
などお待ちしております番組詳細 欄にあるリンクよりお気軽にご
投稿くださいXではハッシュタグ 聞いたFMをつけてポストしてください
表記は番組名と一緒でQFMが大文字 残りは小文字ですそしてAppleポッドキャスト
やSpotifyのポッドキャストではレビュー もできますのでこちらにも感想
を書いてもらえると嬉しいです 聞いた株式会社はエンジニアを
最高に幸せにするというミッション のもとエンジニアに関する知識
を記録共有するためのサービス聞 いた社内向け情報共有サービス
聞いたチームを運営しています ぜひカタカナで聞いたと検索して
チェックしてみてください 来週も火曜日の朝6時に最新話
が更新されます番組のフォロー して最新話もお聞きください
お相手は聞いたプロダクトマネージャー のキヨノトシフミと
ナルセンマサノブでした
