00:00
お疲れ様です
お疲れ様です
はい じゃあ 今日のゆるテクのポッドキャスト 始めていきます
よろしくお願いします
お願いします
はい えっと ちょっと今日を博多家さんとお話をしたいなって思ってる内容がですね
ちょっとリンクは共有したんですけど
採用担当者向けのエンジニアを採用する上での基礎知識っていうスライドを
最近何度かどころか何度も読み直しているんですが
その中でちょっと私 最近採用に携わってて
かつ自分のバックボーンじゃないところで なかなか不明点が出てきたので
ぜひ博多家さんの意見も聞いてみたいなっていうところです
でもなんか自分はあんまりここあれじゃない気がしますね
あの得意分野というか専門分野というか
得意分野じゃない2人が話したらどうなっちゃうんだろうっていうところですね
まじあれですよね 想像だけですよね
はい 想像だけで全然いいと思います
ここで話した想像を持って帰って
俺はこう思うって偉そうに言ってこようと思います
素晴らしいですね
はい で エンジニアを採用する上での基礎知識っていうスライドを読んでいく中で
すごく興味深いそのTipsであったりとか発見はたくさんあったんですけど
その中でも特に私がイメージできてないし
言語化もできてないししっくりきてない
自分の中でしっくりきてないところがあって
それがそのフロントエンドエンジニアと呼ばれる職種と
そのデザイナーと呼ばれる職種の
なんだろう 隅分けの部分が
あんまり私の中でまだできていないんですよ
あの 自分もそうですね
はい 多分私たちの通ってきたバックボーン
培ってきたバックボーンって
結構多分サーバーサイドとかインフラの方にかかってると思ってて
そうです このスライドを見ると4つに分類されていて
ユーザーに近いところから分割されていて
デザイン フロントエンド サーバーサイド インフラと4つに分類されていますね
はい ありがとうございます
そうですね 私たちのキャリアでいうと
割とユーザーから遠いサーバーサイドとインフラのところを
03:04
これまで割と強みとしてやってきた経験があるのかなって思っていて
ただ 現在だとフロントエンドエンジニアという人たちも採用をかけていて
フロントエンドの開発を強化していく必要が出てきました
そうなった時にフロントエンドエンジニアって
どこまで分かると
どこまで分かっちゃうとデザイナーってなっちゃうのか
あるいは私の中だと社内のデザイナーの人と話すと
こういうことまで分かっていると
その人はフロントエンドエンジニアっていうよりはデザイナー寄りだみたいなお話を聞いたんですよ
こういうことっていうのはデザイナーが作ったデザインを
ただ作るだけじゃなくて
そのデザインの意図をちゃんと本質を理解して
本当はよりどうやるとユーザーが使いやすくなるのか
っていうところまでを考えて作れる人は
それはもうデザイナーだっていう表現だったんですよ
なるほど
それを聞いた時に私は
それってシンプルにまた抽象的な言葉になっちゃうんですけど
同じエンジニアなんだけど
視座とか視野が割と広めの上級なエンジニアなんじゃないのかなって
思ってしまって
それって結局サーバーサイドだろうがインフラだろうが
こう作ってくださいって言われたものをただ作るんじゃなくて
本質を理解して
それをより効率よく作るにはとか
より効果を高めるにはどう作るかを考えて作るって部分だと
割と似たような観点があるんじゃないかなって思ったんですよね
はいはいそうですね
それを考えてるとますます
じゃあデザイナーって
デザイナーとフロントエンジニアってどうすり分けるんだろうって
なんかぐるぐる頭の中で回って解決しなくなってますね
なるほどこれあれですよね前提として
なんだろうおそらく各社によって定義が違うもので
今回は三長さんが採用するにあたってジョブディスクリプションを書くときに
06:00
フロントエンドエンジニアっていう職種の人を募集したいときに
なんて書けばいいのかっていう話ですかね
おっしゃる通りです
あまり書きすぎるともはやそれはデザイナーなんじゃないかとか
デザインができるフロントエンドエンジニアなのか
フロントエンドのコーディングもできるデザイナーなのかとか
難しいなって思ってて
難しいですよねだからでもあれじゃないですか
自分が思うのはフロントエンドエンジニアを募集しますで
弊社ではこういう人をフロントエンドエンジニアとしていて
そういう人を募集していますって書けばいいだけなので
なんかあんまり見た人がここまでできてたらそれはデザイナーだよって
思うかもしれないですけどそれはでもなんだろうな
この会社ではこういう人をフロントエンドエンジニアと呼ぶので
済む話なのであんまり区切りにはあんまり気にしなくても良いかもですけど
なるほどなるほど
そうかそうかちなみになんか博太家さんはこれまで
なんだろうもうこれこの人フロントエンドエンジニアやなーみたいな人と
仕事されたことってあります?
ありますねはい
そうなんだそういった方々の場合って
その時の組織構造とかってどんな感じだったんですか?
組織構造はですね
現職でもフロントエンドエンジニアっていう人はいますけど
そうですね組織構造は自分がやっぱりそのサーバーサイドインフラあたりを主軸にしていることもあって
フロントエンドのエンジニアの人とは一緒にやることが多いというか
自分が前提として大規模なチームにいたことがないので
バックエンドとフロントエンドが分かれて作業をしている別チームでやっているっていう開発をしたことがないんですよ
うんうんうんうん
なんか一つのプロダクトとかそういった単位で職能横断的なチームで動くっていう経験しかないので
うんうんうん
ということはあれですね自分と違う職能の人はもうほぼ一緒のチームで働いた経験しかないですね
あーそうなんですねじゃあちょっとなぜ今の質問したかというと
じゃあその職能が違うに、違う職能に応じて
例えばジュニアの人が入ってきた場合って
その育成とかも考えていくフェーズが出てくるじゃないですか
あーはいはい
でそうなると例えばサーバーサイドインフラサイドのエンジニアの育成だったら
ここの組織、こういうチームのこういう人たちと一緒にやるんじゃないのかとか
09:03
フロントエンドだったらこの組織にいてこのチームのこの人たちとやるんじゃないかなって
まあ多分育成の方針によって所属する場所ってちょっと変わってきそうだなと思っていて
はい
でそうなった時になんだろうな
ちょっとうまく表現できないんですけど
うーんと
もう大きく枠、大きな枠で見た時に
まあ言ってみんなそれはエンジニアだから
なんかそのエンジニアの組織だっていうでかい枠に入れちゃって考えるものなのか
はいはい
エンジニアって言ってもやっぱそのフロントエンドサーバーサイドで結構特性が違うから
なんていうんだろう、その感性を磨きやすい組織とかにおいて育成をすべきなのか
した方がいいのか
なるほど
っていうところもちょっとそれは多分その企業の組織の形の形によっていろいろ違いが出てくると思うんですけども
少なくとも今私が所属している組織ってそういうなんだろうな
サーバーサイド寄りのエンジニアが結構集まってる
エンジニアの部門とデザインとかフロントエンドのコードが書ける人もいる部門っていう風に分かれているので
どっちに所属させて
どういう基準で考えて所属させていくのがベターなのかなって悩んじゃいますね
なるほど難しいですね、それ
所属だとな
プロジェクトとかね、実際に開発する現場はもちろん職能横断になっていくので
そこはどっちに所属しようがそんなに差はないと思ってるんですけど
多分その所属する組織のミッションであったりとか育成の方針
あとはその技術スタックっていうところもあると思うんですけど
ちょっと変わってくるので
そうですね
自分の感覚で言うと
デザイン系の組織とサーバーサイドインフラ的なチームの2つという前提で考えるなら
フロントエンドはデザインの方に入れるべきかなと思ってますね
やっぱり切りやすいのが、逆を考えてみるとわかると思いますけど
12:03
インフラサーバーサイドフロントエンドとデザインだと
フロントエンドの人がこう、なんだろうな
やりにくいというか
フロントエンドとデザインの間で切るよりはフロントエンドとバックエンドの間で切る方が
システムの構造として自然かなっていう気がするんですよね
なるほどなるほど
別にあのコンベの法則じゃないですけど
フロントエンドエンジニアとデザイナーを分けてしまうと
なんかそこでその隔たりができてしまう方が厳しい気がしてるんですよね
なるほど確かに
フロントエンドエンジニアってデザインシステムとか触りますよね
触りますね
でも今デザイナーさんがデザイン組織にいる人がデザインシステム作ってますよね確か
そうですね
ですよね、なのでちょっとそこにフロントエンドエンジニアが
サーバーサイドとかインフラの方の組織に入っちゃうとちょっとやりにくい気がしますね
なるほどなるほど
あとモバイルやってるじゃないですか
はいやってます
モバイルのチームはなんか完全独立なんですか
独立っていうと
今のチームわけで言うならデザイン系の組織とエンジニア系の組織と
ネイティブのアプリをやってるエンジニアはどっちに入ってるんですかそれとも第三のチーム
こっちに入ってますそういう意味だと
ああそうですね
ですです
そうなのか
ただプロジェクトの中でそこに対して徐々に徐々にあのはっきり区分けをするんじゃなくて
もうちょっと職能横断的にやっていきましょうっていう風に今融合させている最中でもありますね
なるほど
それでいうとさっきあの2つに分かれているという前提ならって言ったんですけど
うん
なんか一緒のことの方が多い気がするんですよね世のなんか発表されている事例を見てると
そうですね仕事するときはうん
なんかだから
ああでも今の博多家さんの話を聞いた時に
デザイナーとフロントエンドエンジニアを切っあの距離を取ってしまうと
すごくやりづらくなるっていうのは
あって思ってしまってあんまり私そこのデザイナーとフロントエンドエンジニアのやり取りっていうところを深く考えてなかったので
確かにまずはそこを優先させて
考えた方が良さそうだなって思いましたねそのまずそこの連携がうまくいくようになって
でその先じゃあそのフロントエンドエンジニアの方の方が自分のキャリアを考えた時に
15:00
よりデザイナー寄りになっていきたいのかそれともまあ
もう少しサーバーサイドについても理解をしていきたいのか
によってそのタイミングでまた次の何だろうな組織構造というか
を考え直せばいいかなって今なりましたね
そうですねうん
どちらと強く
連携したいかって言ったらデザイン組織の方だと思うので
まずはねうん
なるほどね
という感じかなだからえっとジョブディスクリプションとしては
なんかわかんないですけどサーバーサイドの技術を求めるよりは
なんかマークアップとかCSSかけるとかデザインシステム今で運用してきたことがあるとか
そういう方を書く方がまだ自然な気がしますね
そうですね確かに確かになちょっとスッキリしたな
そうですね逆にデザイナーの人でちょっとコード書いて
スクリプト書いてみたいとかっていう人もいるんじゃないですかね
どうなんだろういそうはいそうかなあんまり私交流持ったことがないので
実ははいはい
いるのかなどうなっていてほしいですね
そうですねなんかそのサーバーサイドの人がインフラもやるようになったりとか
インフラの人がサーバーサイドやるようになったりとかも結構聞くのと同じぐらい
自分はデザイナーとフロントエンドはそれぞれに侵食するというか影響するというか
グラデーションもあってって感じですよね
そういう雰囲気しますね
確かに確かにそれはおっしゃる通りだな
ありがとうございますなんか一人でもやもや考えてたところが人に話せたおかげで
そうですねなんか壁打ちぐらいになりましたか
はい助かりました
はいありがとうございます
あと2つぐらいトピックがありますね
そうですねもう片方はまだ手に入ってないので
本の話ですね
そうですねじゃあもう1個のトピックですかね
多分少し前に深掘りFMの内容で論理削除とは何なのか
それに対してはどのような解法があるのかっていうすごく興味深いテーマで
T和田さんが話してくださっていて
博多家さんこれって聞きました聞いたことあります
18:00
はい一応深掘りは1から全部聞いているのでこの話もあった覚えはありますけど
詳しくは覚えてないな
なんかなんでこの話取り上げたかっていうと
ちょうどここ最近でシステムのハウスキープについてもうちょっと考えようっていうことを出したんですよ
データの
データのっていうと
ハウスキープするにあたってどういうデータが対象になっていくんだろうかって考えた時に
真っ先にこの論理削除しているデータっていう言葉を思い出して
そういえば論理削除ってなんか深掘りFMで言ってたな
っていうところまで繋がって
これやりたいなって今なってて
ハウスキープはそのなんか話せる範囲でいいですけどどういうことをしたいんですかね
簡単に言うと定期的に不要となったデータを削除したい
なるほど
ですと
それに関して
じゃあ何て言うんですかね
例えば
普通に使っているデータベースのテーブルにバシッて削除
クエリ投げて削除するっていうのも全然手段だと思うんですけど
それ以外になんかもうちょっと削除するまで
例えばテーブルのデータがずっと減らないとか
そういう状況もなるべくなくしたいなって思って
それをずっと考えてた時に
そもそもなんで自分たちはデータ量が多いんだろうなって考えると
多分一部で論理削除っていうことを使ってるからなんじゃないかなって思ったんですよね
なるほど
ってなったので
じゃあその論理削除を使うときって深掘りFMの中でおっしゃってたのが
論理削除を使わざるを得ないような制約があるときって使いますよねみたいな
例えば
例えば顧客のデータを消したとしても
別のデータがその顧客を参照していて
名前だけは表示させなきゃまずいとか
っていう風になった時にデータを完全に消してしまうと
じゃあその名前すら引けなくなってしまうので
その状態として削除された状態にしましょうっていうのが
その論理削除の使い方みたいな話が確かあったんですよね
自分たちのシステムを振り返った時に確かに
21:02
戦略的にステイトパターンというか状態管理パターンとして
論理削除を使ってるケースもありましたと
ただ全てがそういう風なケースではなくて
一部はなんとなくデリート投げるの怖くないから来てるところもありそうだなっていうのが
なるほど
うん見えてきて
じゃあそこに対して怖くないっていう理由だけだったら
もう投げちゃおうよって今モチベーションとして来てて
そうそうそう
そういうことができれば
ハウスキープでデータをきれいにするっていうのもそうなんですけど
ハウスキープが定期的に回ってくる前に
ある程度データを整理できるんじゃないかなって思った
なるほど
つまりアーカイブしたいってことですよねデータを
そうですそうです
多分この論理削除の話をする時に
同時に物理削除っていう概念が語られると思って
普通のデリートなんですけど
多分確かこの深掘りの話でもされてると思うんですけど
そもそも削除っていうのは現実世界に即してないって
そういう話多分あるんですよ
ありましたね
ありました
だからそもそも削除するのではなくて
このデータは無効になりましたってイベントをインサートするとか
っていう風にやっていくという解決策も多分あって
それをやるとデータ量が増えるんですよ
そうですね
なので前提として三長さんが言ってるシステム
自分が知ってるんで言うんですけど
業務系じゃないですか
そうですね
でもウェブ系並みにデータが増えていくっていう特性があるから
うん
ちょっと難しいですね
そうなんですよ
うーんって感じですね
うん
だからやっぱ第一の対策としてやっぱりアーカイブというか別テーブルの
そうですね
もう不要になったテーブルに移すみたいな
うんそうそうそうそう
対策があるけどでもそれをやるとさっき言ったような
名前だけはちゃんとしておきたいみたいな時が辛くなって
リレーションが切れるから
うんうん
諸々の整合性の面でちょっと問題が出てきそうですね
素朴にやると
そうですね
なのでそこってなんとなくだけど
多分そのデータに対してしっかりドメインを設計し直すとか見直して
24:02
どのデータはそういうアーカイブで良くて
どのデータはそうじゃないのかっていうところは
見つめ直さないといけないですよねきっと
そうですね
うん
なんか博多家さんはこれまでそういうなんだろうな
データ制御するようなハウスキープするような仕組みとかあるいは
設計とかって経験されたことあるんですか
そんなにガチガチの業務システムは
一応携わったことはあるんですけど自分でがっつり根本から設計したっていうことはなくて
ウェブ系ならいくつかあるのはあります
例えば今回の論理削除が関わるような話でいうと
記事メディアのシステムを作っていたので
はいはい
記事ってその下書きとか公開済みとか
多分深堀の中でも例として挙げられてたと思うんですけど
そういうのがあると思うんですよね
そこでのステートパターンみたいなことはしていましたね
まさしくステータスっていうカラーもあったと思います
なるほどなるほど
まずはそのステータスに状態として今削除されている状態
削除状態とかアクティブな状態とか色々持ってたって感じなんですか
そうですね色々持ってましたが
ただそのシステムは削除は普通に多分削除してたと思いますね
あそうなんだ
はい
色々考えて別テーブルに移すと
関連する記事って色んな付属する情報があるんですよ
タグとかカテゴリーとか
はいはいはい
書いた人とか
なのでその一件をアーカイブしようと思って別テーブルにすると
さっき言ったようなこのいもづる式に色んなデータもアーカイブしなきゃいけない
みたいな感じになってくるんですよね
そうですよね
リレーションをどうするか問題があるんですよね
うんうん
ここが単に自分の好みというか
あれが現れちゃってて良くないと思ってるんですけど
自分はデータベースのトリガーを使いたくないんですよ
あああれでしたね
深堀FMの中だと開放の一つとして
トリガーを使って自動的にアーカイブしようというのがありましたね
ありましたか
別テーブルにやるんだったらトリガー必須のはずなんですよ
うんうんうん
アプリケーションでやったら同一トランジャクションの中でやれば
ちょっと安全かもしれないですけど確実ではないし
そうですね
なのでデータベースの機能でやってしまうのが良いはずなんですが
トリガーってアプリケーションのエンジニアから認識しづらいんですよね
ちょっと分かります
遠いというか
なので簡単に不細と化す気がしたんですよね
27:02
化石化しますよね
そんなことやってるのしかもトリガーで分かんないよみたいな感じになりそうな気がしたんですよ
うんうんうん
なのでちょっと採用したくないなっていうのがあって
物理削除っていう風に結局なりましたね
ああ確かにそれはありますよね
トリガーとかを使えばおそらく割とスマートに
そのタイミングでは実現ができるんだろうなって思うんですけど
じゃあそこに対して
継続的に保守をしたりとか
まあその
オンボーディング時にもそこまでちゃんと伝えてとか
その後の諸々の流れを考えた時に
多分割とコスト増なところって
見えてきますもんね
そうなんですよね
ただそこにそのなんだろうな
そのコストっていってもやっぱり色々あって
うん
それをその時の
他に何かいい解決策はあったかっていうとまだ
その時の自分には思いつけないんですけど
うん
そのコストをアプリケーションの特にサーバーサイトのエンジニアの面からしか見てなかったっていうのはダメだったかもしれないですね
ああ
なんかすごくわかる
今の発言すごくわかる
そのコストは誰にとってのコストなのかっていうのまでちゃんと考えてなかった気がします
確かにね
全体として見た時にじゃあそれってどうだったのっていうところもありますからね
そうですね
結局やっぱりそのそういう風な
トリガー使ってアーカイブしての設計の方が良かったんじゃないか説も
なくもない
そうそう
今そのシステム自分も触ってないので
うんうん
今それを保証している人はそうやってこう下打ちしてるかもしれない
それちょっと持って帰っとこう
そのコストってアプリのエンジニアからしか見てないですよねってわが者顔で言ってみよう
はいそれであれですよ
逆に何か言われても責任取らないんで
大丈夫です
どうするかは自分で決めるんで大丈夫です
いやーそういうのありますよね
ですです
振り返ってあれはっていうこと結構ありますねやっぱり
ありますねありますけどすごく一つなんだっけな
ちょっと前にツイッターで書かれてたと思う
ツイッターかなんかでつぶやきを見たのが
過去の行動に経緯を示さないのは良くないんじゃないかみたいな話があって
でなぜならばそれはその時のその人たちの最適解を導き出したものなんだからみたいなことを書いてた人がいたんですよ
30:03
で今博多家さんと話をしていて思ったのは
その時点の自分ではきっと一生懸命考えてこれが一番最良の方法なんじゃないかって思って選択をしてるわけだから
確かにそういう経緯というか努力に対してはちゃんと経緯を示さなきゃ示した方がいいなって思いましたね
そうですねやっぱみんな常に成長途中ですからね
そうそうそうそうたまたま自分たちが見た時にその世の中でベストプラクティスって呼ばれるものが
発表されてるだけかもしれないしっていうのはなんか今話してちょっと繋がりました確かに確かに
そうですねただちょっと今その成長っていう意味で思ったんですけど
振り返りみたいなのしてもいいかもしれないですね
確かにね
それこそ三沢さんのところでは多分デザインドック書いてるじゃないですか
あれって重要なアーキテクチャの変更とかそういう導入とかの時に書いてると思うんですけど
なんか定期的にというかこれあの時のデザインドックだけどどうだったかな今ならどういう判断するかなとか振り返ると面白いかもしれませんね
確かにね成長してると仮定して成長してると仮定した時に
成長した自分が振り返ってあの頃の自分が頭をひねって出したこの回はどうなのかってところですよね
そうですね
やっぱすげーいいこと書いてるなーってなるのかこの視点足りないよなーとかって色々気づきがあるのか
っていうのは確かに面白そう
この視点足りないよなーがその時点では何だろうな確立されてなかったベストプラクティスに基づくものとかだったら
なんかしょうがないじゃないですかもう
うんうん
けどその時でもこれは気づけたなーとかがあったらじゃあどうしたら気づけてたんだろうとかって
ちょっと学びつながるかなっていう気がしますね
あーなんかその振り返り楽しそうですねいいですね
その書いた時にいた人とかがいるとさらにいいですよね何人かで
その時はこうだったんだよとかね背景もわかるし
ありますね
いいですねなんか設計の設計思想に対して振り返って自分たちにフィードバックをもらうっていうのは
面白い振り返りになりそうだから早速今度やってみよう
そうですねいいと思いますね結構その何かを決めた時とか
うん
そういうこの歴史とか経緯とかっていうのはあんまり残ってない会社多い中
うんうん
大沢さんとか結構残ってるんで
うん
なんかやりやすくていいなぁと思いますけどね
あっありがとうございます
やりたくてもできない会社多そう
33:00
なんでこうしたんだっけみたいなね
そうそうそうそう
あのさっき自分が言った
はい
あのシステムのやつ多分
うん
そんなに残ってないかも
ふふふふ
なので
なるほどね
はい
はい
そんなところであれか論理削除の話も
うん
まあ論理削除はともかくとして自分たちが設計したものに対して振り返りましょうっていうのはすごくいい発見だったなって思いますね
うん
あっ最初ハウスキープの話だった
そうそうそうそう
脱税してしまったはい
でもなんか正直ハウスキープに関して言うと自分の中でいくつか選択肢が見えてるのでそれをやってみてフィードバックしてやればいいかなぐらいだったんですけど
うん
今やっぱ話して白丈さんと話して大きい発見だなって思ったのはそういう決定したことに対しての振り返り
うんうん
は今まであんまりやったことなくもないけど意識してやったことがないのでこれはすごく面白そうだなって思ったので早速メンバーとやってみようかなと思いますね
そうですねすぐできますねその半年ぐらい前の
そうそう引っ張り出してきたら
そう引っ張り出してきたら
これなんでこれ考えたんだっけとかね
なりそうっすね
うん
あのミロのあのゴールデントライアングルとか見ながら
そうそうそうそう
はい
最後これちょっと話します
あーじゃあちょっとだけ話しましょうか
はい
えっとあのエンジニアリングマネージャーの仕事っていう書籍がオライリーからもう発売されたかな確か
どこ見ると26日だから
まだか
もうちょっとですね明日明日
週末か
発売されますねっていうところで
まあ私はシンプルに興味があるから読んでみようかなって思うんですけど
はい
博多家さんこれってなんか読もうかなとかって考えてました?
えっとはいもちろん積んであって
これはあの例によってあのリュウジーさんとかアトラクトの方々が翻訳されてる本で
そうですね
自分はこういう翻訳本で良さそうなのが発表されたら
あのオライリーのサブスクやってるので
はいはい
あれで原本ないかなって探すんですよね
でこれオライリーだからもちろんあって
うんうん
であのちょっと助手帳だけ読んでみたらむちゃくちゃ良さそうなんで
おー
これは読みます
なんかえっとざっくりあれですね
あの急にエンジニアリングマネージャーになった人のために
毎日やるようなその実作業に基づいたすごい話をしてやるぜみたいな感じの内容なんで
そっかそれもっと早く出会いたかったな
36:00
(笑)
すごい良さそうと思ってます
うーんこういう本ってあんまり
まあ私が読んできた中であんまりなかっただけかもしれないんですけど
今までで言うとなんだろう似た本で言うと
あのエンジニアリング
エンジニアのキャリアマネジメントパスでしたっけ
名前ちょっとロゴで
あの青いやつ
青いやつですね
あですよねはいはい
うんであったりとかエンジニア組織論への招待とか
うんうんうん
とかがまあ若干そのエンジニアのリーダーがこういうことを
考えていくとかっていうことを書かれてた書籍だと思うんですけど
なんかこんなにはっきりとエンジニアリングマネージャーの仕事ってタイトルって
今でなかったと思うので結構楽しみだなっていう
そうですねなんかそのエンジニアリング組織論への招待とか
その青い本もそうですけど
なんか割と抽象的なこともが中心な気がしていて
そうですねうん
これかなり具体によった話な雰囲気がしています
あなるほどそれはちょっといいな
うん
早く読みたいなそういう意味だと
まあどうなんだろうなもう
週末来るでしょ
週末来ますね
読みましょう
読みましょう読みましょう
自分は多分でもこれよりも先に読む本があるから
多分そっちから読んでいくんですけど
あそうなんですか
いやなんか何だろう積み本がしてあって
はい
その先頭から読んでいってるんで
あー
これもうちょっと後だな
そう積まれるとね
そうなんだよね
そうなんですよ
なかなか次の本が
でも結構割り込んでくる本とかあるんですけどね
うんわかります
最近割り込んできた本は
オブザーバビリティエンジニアリングっていうやつがあって
キツネの拍子のやつ
オブザー
あそっかちょっとリンク貼ってみようかな
これがなんか良さそうだったんで
この間の5月に発売されたやつですね
えーっと
オブザーバビリティエンジニアリング
もうタイトルからして
三田さんも好きそうなやつじゃないですか
多分好きですね
そして今白竹さんが紹介してきちゃったから
39:00
多分割り込まれちゃいますよこれ
いやあの
エンジニアリングマネージャーの仕事から読みましょう
ほうほうほうなるほどね
面白そう
もう読んでるんですか
あいやこれは多分この週末ぐらいから読めればいいなって思ってます
そうなりますよね
そんなとこですか
そんなとこですかね
はい
じゃあ今日はここまでですかね
いつもどんな感じで締めてましたっけ
どうやって締めましょうか
まだ1回目なんで決めていっていいですけど
はいじゃあ今日は私の話に付き合ってくれてありがとうございます
そうですねこれ持ち回りでそれぞれちょっと
メインの回をやろうってことにしたので次は私ですね
はいよろしくお願いします
なんか考えよう
はい
じゃあありがとうございました
ありがとうございました
ありがとうございました。
