00:01
こんにちは、ソフトウェアエンジニアの三長です。
こんにちは、エンジニアの博崎です。
ゆるテクは三長と博崎が緩く技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、というわけで、本日もよろしくお願いします。
今日はトピックとかに入る前に、あれ前回か前々回でしたっけ?
収録前に話している内容も入れてみたら面白いんじゃないかみたいな話してたんですけど
早速ちょっとお試しで、今日のアイスブレイク的な感じで話を差し込んでみようかなと思います。
これは博崎さんが用意してくれた感じですよね?
そうですね、なんかアイスブレイク的に世間話、なんかあったっけと思ったら
そうそう、これまた前々回ぐらいかな?の編集している時に
そろそろ1周年じゃね?みたいな話をしてたんですよね。
で、実際どうだったかなと思って振り返ったら、エピソード0の公開日
お、なんかスターウォーズみたいな感じですね。
一番最初の話の公開日が8月10日なんですよね。
で、収録している今日8月10日なんですけど。
ちょうど1年でした。おめでとうございます。
え、おめでとうございますって言う側?
しかもあれじゃないですか、公開日と収録日っていうなんか微妙に似ているようで似てない感じの
エピソード0の公開日は、0はお試しなんで、公開日が8月10日だったんですけど
1年前のこの日、2022年の8月10日にエピソード1の収録もやってるみたいですね。
おー、じゃあなんとなく1年ぐらいは間違いなく経ったっていう
経ったっぽい。
感覚を持っておけば良さそうですね。
そうですね、この1年前の完ペっていうかネタ帳を見るとすごい感想感があってすごいですね。
ポッドキャスト名を決めるから始まってますもんね。
すごいなこれ、デブ現場のあれこれとかありましたよ。
ね、技術ポッドキャストとかすごいなんか大きく出てるタイトルですよね。
これにしなくてよかったな。
ゆるテクでよかったなってなりますね。
ちゃんとメーディングリストとか考えてる偉いな。
私、博多家さんがゆるテクって声かけてくれてなんかポッドキャストしようよってなったんですけど
なんだろう、やるってなった時の段取りの良さに驚きましたもん。
自分はこれが3つ目かな、なんかそのぐらいなんですよ。
なんでこれとこれとこれはまあいるよねみたいなのは一応ありました。
なるほど、いやすごい参考になったというかやってよかったなってなってるんで
本当に誘ってくれてありがとうございます。
ありがとうございます。
自分一人とかで喋るとか、毎回ゲストを呼んで喋るとかはちょっと厳しいなって思ったんで
内田さんと喋ってるのはそういうところがまず運用が楽なんでいいですね。
そう言っていただけるとなんか一緒にやっててよかったなって思います。
じゃあアイスブレイクはこんなところでいいですかね。
なんか気抜くといくらでもアイスブレイクで話せそうな感じになりますね。
なりますね。
はいじゃあちょっと今日は本題移ろうかなと思ってます。
今日のホストは私なんですけどまたちょっとねなんかめんどくさい感じのトピックを
持ってきて博多家さんに何とかしてもらおうと思ってます。
いやーこれ無理ですよね。
今日のトピックというかちょっと2人で話したいなと思ってるのが
キャリア形成の難しさ
みんな自分のキャリアってどうやって見つけてるんだろうなっていう
また答えがなさそうな難しそうな話をしたいです。
なんかこういうのを考えたいなって思ったのが
ちょっと前に結構長い期間自分の振り返りをやったんですよね。
その数年単位の振り返りを時間かけて一人で粛々とやって
自分のこれまでの奇跡ってこうだったなあ
今後って何したいのかなっていうのを考える時間を取った時期があって
以前雑談で話してましたよね。
そうですそうです。
その時に思ったのがなんか私は結構それすごく考える時間
長くとって大変だったというかなかなか答えが出なかったんですけど
他のエンジニアの人たちってどんな感じでキャリア見つけてるんだろうなって
ちょっと素朴な疑問です。
で参考までに私の話をすると
あれ多分ゆるテクで話したことがあったかどうか覚えてないんですけど
多分初期の頃ってなんだっけSREをやってるとか
エンジニアリングマネージャーをやってるとか
何かしら何々やってる何々です自己紹介してたと思うんですけど
なんか基本的にでもその肩書きを目指して
何か努力した感じじゃなかったなって自分では振り返ってて思ったんですよ
みんなでプロダクト開発をしてて
こういう要素があるともっとプロダクト良くなるじゃん
かつその要素自分興味あるじゃんって思ったことに
学習してたと
でなんか学習してそういう立ち振る舞いをしてると
なんか後から調べてどうやらこれは
巷で言うとこのスクラムマスターってものらしいとか
どうやらこれは最近で言うとこのSREと呼ばれるものらしいみたいな
そのやったことに対して後から名前がついてきたというか
当てはめるならここかなっていう感じでついたんですよ
なんでこう何て言うんでしょうね
例えばSREとしてやっていきたいんですって
それから目指せてる人とかって
どういう切り口でどういう観点で考えて
そういう目指す方向を決めてるのかなっていうのは
いまいち私の中ではピンときてないというか
こうなんじゃないかっていう話があれば
ちょっと博多家さんと話してみたいなって思いました
先にその名前というか
役割がこういうのがあるよって示されてるパターンってことですかね
そうそうそう
それね
なんかでもほら
最近できた
最近っていうかここ数年でできたような職種がそうかもしれないですけど
SREとか
でもほら我々が例えば新卒とかの時とかでも
ソフトウェアエンジニアとかそれこそね
インフラエンジニアとかはあったわけじゃないですかきっと
会いましたね
システムエンジニアとか
それと同じ気持ちなんじゃないですか
そういうのがあればそれになるんだって漠然と考える人も
なるほど
もっと今はすごい細分化されてる感じはしますけどね
細分化されすぎててもう分かんないですよね
ペケペケエンジニアが多すぎて
しかもそのペケペケエンジニアが
こういうもんだよって書いてある
ネットの記事とかそういうのによって定義が違ったりしますよね
そうですね
そうなんですよね
特にペケペケエンジニアとか
エンジニアのロールとかキャリアとかって
やっぱ悩んでる
少なくとも自分は悩んでる時期が未だに続いてるんで
結構これまでそういう系の書籍とかも
インプットはしてたんですよ
有名なところで言うと多分青いカバーの
エンジニアのためのマネジメントキャリアパスとか
とか最近だとオライリーのエンジニアリングマネージャーの仕事
もっと直近だとまた新しくキーワード
新しくはないのかな書籍として出てるスタッフエンジニア
っていう本とか色々読んでるんですけど
なんか想じて思うのって
エンジニア自体の歴史って
言うてまだ数十年の歴史とかじゃないですか
管理職と違って
残ってたぶん数百年ぐらいの歴史がある中で
エンジニアって割とここ数十年
二三十年もっとあるかの歴史しかないから
まだまだこういうキャリアの名前とかも
現在進行形で構築中なんだなっていう印象すごく受けてて
というのも私の読解力の問題かもしれないんですけど
いまいちまだスタッフエンジニアと
エンジニアリングマネージャーの具体的な違いにピンときてないところが
そうなんですね
あったりしてます
スタッフエンジニアとエンジニアリングマネージャー
スタッフエンジニアって自分読んでないんですけど
ぼんやりとしたイメージだとスタッフエンジニアは
すごいエンジニアみたいな
よくプリンシパルとかシニアとか言われるような
他に日本でよく聞くテックリードとか
あんまりマネジメントしてないような
どちらかというとICよりのイメージがありましたけど
私もそのイメージです
スタッフエンジニアの書籍の中で書かれてたものとしては
エンジニアのキャリアの中で
どっかしらでシニアと呼ばれるレベルに到達した時に
その次がマネージャーになるのか
スタッフになるのかみたいな
そういう分岐なんですね
そういう分岐で
スタッフって進んだ場合に
その書籍の中だとスタッフ
その次がプリンシパル
その次が何だっけ
ディスティンクイッシュみたいな
いまいち何だそれってなったんですけど
っていう方向に進むらしくて
そこのカテゴライズを総称すると
スタッフプラスっていうらしいんですけど
不運ですよまずは
ラダーというかね
よくある階層の名前がそれなんでしょうね
読み進めていくと
確かに技術的要素に対して
例えばテックリードであったりとか
アーキテクトとか
あと何だっけな
ソルバー
問題を解決するみたいな
特定の複雑な問題を解決する人とか
右腕っていう表現が出てきてて
ナンバー2みたいな感じじゃないですか
感覚として
っていうことをやってたりっていうところで
一言にスタッフエンジニアって言っても
ピープルマネージメントの重要性
その人が貢献する形は結構違う
っていう印象を受けたし
じゃあスタッフエンジニアになったから
ピープルマネージメントとか
できなくていいかっていうと
そんなことはなさそうなんですよね
なるほど
結局はピープルマネージメントとか
組織のマネージメントって一定のレベルは
やっぱり必要なんだなっていうのは
すごく感じてて
私個人としても
それができないと
周りに影響を与える働き方も
結構難しいんじゃないかなって思いました
そこで言うピープルマネージメントは
いわゆる評価とか
給与のための査定とか
そういうのではなくて
そうですね
メンタリングとか
コーチング的な方が
強い側面がありますと
一文で書いてたのが
EMとの違いとした
人事権を持ってないところだ
っていうのが書かれていて
持ってないんだ
ただどうなんだろう
日本国内の会社で言うところの
そもそもEMって
みんな人事権持ってんのかなとか
逆に思ってしまって
そうですね
本当会社さんによるのかもしれないですけど
エンジニアリングマネージャーの上に
VP of Engineeringみたいな人がいませんかね
いますね
その人が人事権を持ってるぐらいのイメージを
ちょっと自分は持ってますけど
どうかな
そうですよね
もちろん会社の規模とかにも
よると思うんですけど
そんな感覚ありますよね
エンジニアリングマネージャーが
人事権持ってるイメージは
ちょっと確かに薄いかも
そこで述べてる人事権っていうのが
ファイヤーするとかって話なのか
こいつを移動させるからとか
そういう話なのか
どれぐらいの話なのかにも
よると思うんですけど
っていうのが
若干違いとして書かれてたんですけど
言うてでも国内だけで考えた場合って
そんなに違うかな
みたいな感覚がやっぱ
読み終えてもまだ残ってますね
スタッフエンジニアって
エンジニアリングマネージャーの仕事とキャリアの選択
そんな感じなんだ
なんだっけな
私が初めてスタッフエンジニア
っていう言葉を認識したのは
エンジニアリングマネージャーの
仕事を読んだ時に
その中に出てきてたなぐらいの
記憶ですね
さっき話戻るんですけど
ロールモデルとか
ロールモデルっていうか
キャリアの話になった時に
職能の話と
企業っていうか業界業種っていうか
二軸があるかと思ってて
私はこういう業界の経験がありますとか
っていうのと
私はプロダクトマネージャーを
やったことがありますみたいな
二軸あると思うんですよ
どっちのキャリアの話を
今しようとしていましたっけ
それで言うと後者業種業界ではなく
博多家さんの言葉で言うなら
私はプロダクトマネージャーを
やってますとか
そっちの方の話をしようとしてました
そっちで言うと
ロールって会社によって
求められてるのが違うでしょうから
やっぱりみんな自分のやりたいことから
探すんですかね
そうですよね
自分のやりたいことから探すのって
もちろん間違いじゃないだろうなっていうか
一番効率的に言うとちょっとあれですか
近道なんじゃないかなって思う反面
例えばその人がその場で働いてる
その環境で働いてる限り
どう足掻いてもなかなか
出会えないパターンってあるじゃないですか
そういうロールがあることを
知れないとかそういうことですか
そういうことです
知ってないあるいは知ってるんだけれども
近くにそういう例がいないとか
今自分がいる会社では
その役目がないというか
その仕事はできないみたいなことですか
とかであった時に
そのロールを知ってて
役目がないってなるなら
その場でそういう役目を作るのか
そういう役目がある場所に移るっていう
選択ができると思うんですけど
そもそもそのロールを知る術すらない
ってなった時って
めちゃめちゃ難しいじゃないですか
難しいですね
下手すると自分の今興味を持ってる
守備範囲の中には
それが少なくても入ってないってなると
余裕を持って
見つけられなくなっちゃうんだろうなって思ってて
他のエンジニアって
どうやって見つけてるのかなとか
あるいはあんまりそこを気にせずみんな
突き進んでるのかなとか
どうなんでしょうね
でもあんまり積極的に
自分が今知らないようなことを
やってる職業ってあるのかなって
探してるイメージはあんまりなくないですか
ないですよね
あんまりそういう探し方を
してる人いなさそうかな
博得さんはそういうのって探したりしましたか
それとも割と
自分のやりたいことを中心に考えて
どういうことができるかなって
探した感じですか
もう全然
新しいことを探したりとかはしてないですね
興味の中から探しましたね
なるほどな
そうなると本当にでも
漠然とか分かんないですけど
書籍とかカンファレンスとかに参加したときに
ビビッときた名前を
自分でどれだけ突っ込んで
調べられるかどうかとかになってくるんですかね
そうですね
あとは
業界とかが変わったら
役割が違うことをやってる人が
いたりするじゃないですか
ですね
そういうところから輸入するのも
ありかもしれないですけどね
いつだったかな
どっかで聞いた話で
リリースマネージャーっていうロールがあるのを
知ったときに
自分は業界というか業種が違えば
そういう職種があるんだなって
思った記憶があります
なるほど
どこだったかな
マイクロソフトかな
どっかにあるんですよね
確かリリースマネージャーって
リリースをコントロールする人が
同じ文脈で聞いたことあるかもしれないな
リリースをコントロールする人っていう
キーワードがすごく
頭に残ってる
でかいマイクロソフト
多分それはWindowsの話だったのか
ちょっと記憶自信ないですけど
多分Windowsの話だと思うんですよね
そんだけでかいソフトウェアになると
やっぱりそういう
それ専門の職の人がいるから
なるほど
でもそれでいくとあれか
今の博多家さんの話してくださった
輸入してくるっていうパターンだったとしても
詰まるところは
自分がそういうことをやりたいかどうかを
一回見定めて
それがマッチしてたら
やっぱり後から
役割名を目指すっていう
発言になりそうな感じしますね
しますよね
あとは我々がリリースマネージャーという
ロールを知った時のように
偶然ですよね
意図的にその出会いを
作るのはなかなか難しそう
難しいですね
難しいですね確かに
しかも多分技術の進歩とかに応じて
どんどんそういう名前も変わっていきそうですよね
変わっていきそうですね
それこそあれじゃないです
みんな半年くらい前は冗談で言ってた
プロンプトエンジニアですか
とかっていうのも
普通にこれからは出てきそうなのかな
っていう感じはしますよね
確かに出てきそうだし
なんならその時の市場の状態によって
そのスキルの高さ低さ関係なしに
やっぱ給料とかって
めちゃめちゃ変わりそうですよね
変わりそう
自分はそこも結構
2番目ぐらいの優先度っていうか
まずはやりたいことから探して
これ需要あるかなっていうのは
次に考えることかもしれないです
そうですね確かにその
やりたいことは決まってるけど
めちゃめちゃ需要がなくて
それで生活でできないとかになると
大問題ですもんね
そうですね
これ好きだけど
これじゃ食っていけないなみたいなの
たくさんありますよね
ありますあります
確かにな
ちなみに今そういうのがあるんですか
三田さん
今までやってきたのじゃない
何かとか
というよりは
自分が所属している組織で
私含めエンジニアの人たちって
今後どういう道を歩んでいくのかな
っていうのを考えた時に
ある程度プロトタイプレベルでもいいから
方針というか方向性は
見えてた方がみんな頑張れるのかな
とも思ったんですよ
自分が振り返った後に
そうなった時に
自分のこれまでのインプットとかでいくと
EMであったりとか
VPOEとか
そういう類の名前はいろいろ知ってるし
世の中的にも厳密には定義されてないけど
そこそこには定義されてるから
そこはいいとして
それ以外に何か知らないものって
何があるのかなみたいな感じですかね
そうか
選択肢を他にあるのかなって
悩んだわけですね
そうですね
なるほどな
そうかそうか
組織のキャリアの設計とかを
する人のあれか
大変そうだなそれ
個人的には正直細かく考えるのって
正直めんどくさいし
やることやってればみんな楽しいんじゃないかなとか
思ってしまうんですけど
でもそういうのがあった方が
頑張れる人は頑張れるしみたいな感じですよね
そうですよね
それがないと不安になる人っているんですよね
ですです
そういうのを考えて
マネジメントキャリアパスの青い方を何度も読み直すんですけど
大体あれですね
自分が体験したことがない
ロールあたりのページになると
ちょっと言ってる意味が分かんなくなってくるっていうのが
毎回のことですね
そうか
ふーんってなっちゃうんですね
そうなんですよふーんってなるんですよね
今話しててずっと思ってるんですけど
あんまりまともなこと言えないな
自分が考えたことないんですよね
キャリアらへんとか
全然ないんで
まともな話が言えない気がする
そんなの言ったら私も言えないですよ
まともな話なんて
まだ道半ばだし
ところでスタッフエンジニアの話変わっちゃうんですけど
どうでした?
面白いトピックってかありました?
そうですね
面白いトピックはいくつかありました
デザインドキュメントとエンジニアリング戦略
トピックっていうほど
あれじゃないかもしれないんですけど
一つ発見としてというか
印象的だったのが
エンジニアリング戦略
とかの話が少しあって
そもそもエンジニアリング戦略とか
エンジニアリングのビジョンとかって
急にポッと出てくるようなもんなのかなって
すごい不思議だったんですよ
それで一つ
定量っていうとちょっと極端なんですけれども
こういう考え方あるんだってなったのが
我々のエンジニアリングする仕事って
もちろんそいつのボリュームによって
期間って変わってくるじゃないですか
例えば具体的な機能を開発する場合の期間もそうですし
もうちょっと自分たちの組織に対するエンジニアリング
例えば自動化をCICDみんな入れましょうとか
分かんないけど
昔で言うとテストコードみんな入れましょうとか
今で言うとKubernetesにしましょうとか
クラウドネイティブどうこうしましょうみたいな話
物によっては長期間になる物ってどうしても出てくるじゃないですか
その時にスタッフエンジニアボーンが紹介してくれてたのが
目安一つの目安として
1ヶ月以上のエンジニアリング期間が必要な物に関しては
基本的にデザインドキュメント
デザインドックを残すことを推奨しますっていうのが書かれてました
規模として作る期間を規模の目安にしてるんですね
ですです
1ヶ月以上エンジニアリングする規模の物をやるってことは
必ず何かしらの問題とか背景があって
目指したいゴールとノンゴールがあって
もっと言うとその時におそらく何かしら比較して選定して
注意点を述べた物もあってっていう
一通りのストーリーが残ってないと
後で見直す時にも分からなくなって危険だし
そもそも1回そういうデザインドキュメントを書いてレビューすべきだみたいな
じゃないと引き継ぎの面でもそうですし
じゃあ1ヶ月後フタを開けてみたら
何か思ってたのと違うやんってなっちゃうのも悲しいしみたいな
ところもあってデザインドキュメントを残しましょうっていうのを
推奨してるのがまず興味深い点でしたと
納得ですね
おっしゃる通りだなって思いました
そこからもうちょっと面白かったのが
そういうデザインドキュメントが5つ集まると
それはその組織のエンジニアリング戦略なんだっていう話をされてて
確かに単純に考えてデザインドキュメント5つで
今の話で言うと最短でも1個1ヶ月だとすれば
5ヶ月かかる話じゃないですか直列に進んだら
確かに5ヶ月かかることって
何かしらの戦略を持って取り組まないと
いけないことだよねとも思ったんですよ
何も考えずに5ヶ月間自由にやりましょう
怠けないしみたいな
そうですね
さらにその戦略が5つ集まると
それがエンジニアリングビジョンなんだって
なるほど25ヶ月2年くらいか
2年くらい直列で入ったんで
っていうのが私としてはすごく印象的で
というのもケースバイケースだと思うんですけど
基本ビジョンからなのかなって思ってたんですよ
ですよね自分も思いました
これでいくとボトムアップだなって思いましたね
多分これって100ゼロの話じゃないなとも思っていまして
ビジョンから考えて徐々にドリルダウンさせて
具体的なものに落としていくっていうパターンもあるし
もしかするとそれがパッと出てこないときに
自分たちが今やりたいことというか課題だと感じていることに対して
デザインドキュメントをつらつらと書いて集めていくと
結果自分たちが目指したいのってこういうことだったんじゃない
見えてくるんだろうなとも思いました
なのでこの辺がもしかするとハイブリッドに
見えてるものに対してはまずはデザインドキュメントを書いちゃって
っていうことをやるとゼロイチを生み出さなきゃいけない
苦しみから少し解放されるんじゃないかとか
思っちゃったりします
スタッフエンジニアのインタビュー
スタッフエンジニア
日本で定着するのかなどうなのかなって感じしますよね
多分日本以外の国だとこのスタッフエンジニアっていう
ラダーっていうか肩書きは多分一般的なんでしょうね
そうですねそれでちょっと面白かったのは
スタッフエンジニアたちのインタビューショーがあってですね
インタビューショー
第2章がインタビューするショーが中心なんですけど
そこでやっぱりあんまり日本の会社って多くなくて
ちょっと待ってくださいねインタビューって海外で
インタビューって面接のあれとかもあったりすると思うんですけど
それではないですよね
それではないですね
各会社のスタッフエンジニアと呼ばれてる方々に対して
インタビューヒアリングしてるような感じ
なるほどですはいはい
その中だと国内だとなんだったっけな
サイボーズ株式会社とかは確かあった気がする
インタビューされてるんですか
そうなんですよ
すごい
ですですなんで一応国内でもちょこちょこ出てきていそうな気配
そうなんだ
その方々のインタビューでちょっと面白かったのは
皆さん全員ではないんですけど
スタッフエンジニアになった時どういうことやってきましたかっていうところで
スタッフプロジェクトと呼ばれるものを乗り越えてきた人たちがやっぱ多くてですね
スタッフプロジェクト
スタッフプロジェクト
そうなんだスタッフプロジェクトって思って
私の理解だと平たく言うとなんかその会社で結構大事だと言われてる大きめのプロジェクトを
中心人物というか中心メンバーのエンジニアとしてやりきった感じの人たちだと思いました
へーじゃああれなのかな自社サービスとかで言うと
その自社サービスをグロースした人とかなのかな
とか立ち上げてリリースまで持ってったとかそういう感じなんですかね
であとは我々でも真似できそうなやつで言うと
なんか皆さんやっぱ結構論文を読んでらっしゃる
論文かー
正直私論文なんて書籍のリファレンスで入ってたらたまに読むぐらいで
積極的に論文から探しに行くみたいなことをしたことあんまないんで
みんなやっぱ結構読んで確実的な理解を深めてるんだなっていうのが印象的でした
まあなんかちょっと読んでみようかなって気持ちにさせられましたね
なんかこの間webブラウザセキュリティって本を読んで
そこでそのリファレンスみたいな論文がいくつかあって
それで読んだところだとあれでしたね
なんか論文って言ってもあんまり長いとは限らないんですよね
そうですね
しかもそのリファレンスとして示されている場合って
別に全文読まなくてもよかったりするんで
結構その部分だけつまみ読みしているパターンがちょっと多くて
頭からみんな読んでるってことなんですかねこれ
いやそんなことはさすがにないんじゃないですかね
つまみ読みだとは思うんですけどね
もちろんその関心度が高いものに関しては
もしかするとしっかり読み込まれている可能性はあると思うんですけど
ということがいろいろ書かれている本だったので
別にそのスタッフエンジニアを目指す目指さないに関わらず
こういう考え方があってそうなった人たちって
こういうことをやってきたんだなっていうのを知れる
いいきっかけにはなると思うので
読んでみる分に私は結構お勧めしたいですね
なるほど良さそう
はい
なんかあくたけさんあれですか
クラウドフィンオープス
最近次これ読もうみたいなやつあるんですか
最近ですか
最近読んでまだそういえば感想を話してないやつだと
クラウドフィンオープスってやつを読んだんですけど
噂のフィンオープス
あんまり具体的な話はなくて
クラウドを使うに
クラウドに限った話じゃないかもしれないんですけど
システムの環境を運用するにあたって
かかる費用とかを
ちゃんとオペレーションしましょうみたいな話ですかね
感覚として
ざっくりもうそうです
クラウドだとそれまでのオンプレとかの
とコストのかかり方とか
計算とかそういうのも違う
ステークホルダーも変わってくるから
考え方も月額とかであれだったりとか
いろいろ今までのクラウド以前と
考え方が違うからみたいな
そんな感じでした
結構各クラウドベンダーとかが出してる
シミュレーションツールあるじゃないですか料金シミュレーション
とかで入れる前はシミュレーションして
入れてからは定点観測してとか
そういうことのティップスとかが
載ってんのかなって勝手に
それを自分は思ってたんですけど
このクラウドフィニオプスってやつはもうちょっと
広くて組織の話が
多めでした
ちゃんとエンジニアだけじゃなくて他部門とか
経理部門みたいなところと連携をしろとか
そこでどういう説明責任を果たさなければいけないかとか
そういう話が結構
いわゆるハウ的なところは
本当はちょこっとしかなかったですね
今の説明どういう説明責任を
果たさなきゃなのかって話とかがあったみたいに
対象としてはエンジニアなんですか
読者というか
一応エンジニアですね運用するエンジニア
ただこの本は一貫してフィニオプスは
組織全体でやるものですって書かれてましたね
そうですよね
私もそう思います
みんながちゃんとクラウドの課金モデルとかを理解して
それに合わせた行動をしなくちゃいけませんよ
っていう感じでしたね
なるほどなるほど
私聞ける日を楽しみにしてていいですか
今話したのでだいたい全部なんですけど
じゃあもしかするとゆるテクでは上がってこないかもしれないですが
上がってこないかもしれない
ご興味がある方はぜひ手に取って読んでみてくださいって感じですかね
そうですね
ちょうどキリも良くなってきたので
ぼちぼち閉めますかね
Twitter原Xですかね
ではハッシュタグゆるテクをつけて
ツイートお願いします
Googleフォームからもコメントをくれますのでよろしくお願いします
今日はありがとうございました
