2022年4月16日(土)のツイート履歴 - kbigwheel-twitter’s blog

西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
コードを書いていない仕事は不安だ。自分が本当に価値を生んでいるのか不安になる。ただ、書いてるコードが価値産んでいない時もあるので、コード書いてる時の安心は単に慣れに因るものだと気づいた。
22:02
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
めっちゃ良いゴールド出た https://twitter.com/k_bigwheel/status/1515292968852520962/photo/1
20:36
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
教訓1. [重要]の代わりに[要アクション]と嘘をつけてはいけない。それは顧客からの信頼を大きく失墜させる教訓2. 顧客にとって重要なのか、それとも新機能を実装したので使ったほしい自分自身にとって重要なのかは切り分けるべき。本当に前者であった場合のみタイトルに重要などつけること
13:25
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
@SalesforceJapan 拝啓セールスフォース様上記のご連絡ありがとうございました。ただ、なんのActionをRequiredされているのか読み取れず、また通知されている内容についてもRequiredされるほどの内容に… https://twitter.com/i/web/status/1515183161734418432
13:19
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
メールや連絡に[緊急] [重要] など、それほど重要じゃない場合も注意を煽り続けた結果だれも真剣に見なくなって本当に重要な通知も見逃される。これがいわゆるオオカミ少年現象。これJTC特有の現象かと思いきや、AWSやはてにはSal… https://twitter.com/i/web/status/1515182046154407939
13:15
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
相互扶助と犯罪幇助と補助がまざりあってふじょなんだかほうじょなんだかほじょなんだか。
10:32
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
相互補助 → 相互扶助
08:58
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
長々書いたが、まとめると以下のようになるかな。技術選定は (Who) → もっともそのサービスへ主体的に関わるチームが決定するべき (How) → 短期的成功や個人の嗜好ではなく、長期的な視点で最も成果を出す可能性の高い技術を選ぶべき
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
冷静に分析して選ぶべき。これがピタッと当たることは、特に最初のころは殆どないが、少なくともやらないより良い結果になる可能性が高いし、仮説を先に作ることで成長につながる。
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
また、挑戦と確率についても言及しておく必要がある。意思決定の場面というのは常に不確実性があり、特にサービス開発を始める前に決めることは見えてない部分が非常に大きい。この場合でも見えていないからと言う理由でよく考えず決めるのではなく、どれを選ぶと何がどのくらいの確率で発生しそうかを
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
それともすべてをBigQueryで賄うのかは考慮する余地はあるけども。また選択に伴うリスクも考える必要がある。BigQueryが最終的に必要なくなる可能性もあるし、平常時の運用コストもこれだけGCPなら高い。サービス開発が停止し… https://twitter.com/i/web/status/1515117127421685763
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
もしそのサービスにとってBigQueryが重要な意味を持っている場合、仮に会社の標準クラウドサービスがAWSやAzureだったとしてもそのチームがGCPを使うのは適正かもしれない。当然それによる種々のコスト増もあるためベースをAW… https://twitter.com/i/web/status/1515117126205333504
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
こう書くと技術を揃えていく例ばかりになってしまうので、逆に他と違う選択をしうるケースを挙げると、例えばBigQueryのためのGCP選択などがありうる。同種の技術としてAWS Athenaがあるが、これはBigQueryより応用… https://twitter.com/i/web/status/1515117125051949061
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
一方で開発組織がもうちょっとアーリーフェイズにあり、単一のインフラチームがインフラの主たる責任を持っている場合、そこが決めるべきという話になる。
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
インフラ技術はちょっとむずかしい。インフラの構築から開発運用までをサービス開発しているチームが一括してやっているならもちろんそのチームが決めていい。
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
社内でのノウハウの相互補助の観点でも同じ目的の技術なら使われている技術は無意味に増やすべきではないし、社内でエンジニアの回遊制度などがあるならなおさら。あとはサービスが縮小して担当チームが近隣チームと合流するなら、近隣チームともなるべく技術スタックは合わせたほうがよいはず。
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
例えばその1年後にチームのインフラエンジニアが入れ替わっておりその人はGCPのほうが得意な可能性などもあるからだ。だから、チームで決定するということはチームが外部状況を考慮せず独断で決めるということではない。
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
閑話休題。なので、そのプロダクトと最も長く付き合うことになるチームが最終決定を下す必要がある。ここで重要なのは個人ではなくチームであることで、例えば初期チームのただ一人のインフラエンジニアがawsに慣れているからといってawsを選択するのは良くない。
08:57
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
たしかビル・キャンベルの言葉だったと思うが、決定が正しいかどうかはそれほど問題ではなく、決定するプロセスの正しさのほうがよほど重要。
08:32
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
3についての例でいうと、例えばCTOの提案したソリューションが的はずれだった場合、それの再選定に時間がかかる可能性が高い。チーム内ほどコミュニケーションが頻繁ではなく、また肩書上の強制力もあるからだ。数ヶ月かかったり、最悪再選定… https://twitter.com/i/web/status/1515110238487162882
08:30
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
これは3つの点でよくない。 1. チーム(チームメンバー)の成長を抑制してしまう 2. 外部の人間はチームより解決したい課題の理解が浅いので提案されたソリューションが的はずれである可能性が高い 3. ストリームアラインドチーム外とのコミュニケーションはコストが高い
08:30
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
開発運用チームがそれを決定しないとチームの積み上げにならない。外部からの意見やパワーは一時的なものでチームのパワー増強にならないのだ。例えば言語選定やフレームワークの選定をテックリードが主導してしまった場合、また同様のケースでまたテックリードに頼る必要がある。
08:30
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
最近、これが良いんじゃないかと思っているのは、それについて責任を持っているチームが決める方法。言い換えるとCTOやテックリード、技術研究チームなどがある言語やフレームワークを強制するのは良くないという話。たとえそれがどんだけ正解だと思えても、そして実際に正解であったとしても、
08:30
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
一言でまとめると、技術選定をどうするかという話。
08:30
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
某社のように野放図にエンジニアが好きな技術を選んでしまうと引き継ぎ=システムの開発運用が非常に難しくなる。一方で画一的な言語・フレームワークは脳死でそれを使うようになってしまい、釘だけでなくネジもハンマーで打つような事態を引き起こしてしまう。
08:30
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
社内技術のどこまでを社内統一して、どこからをバラバラにするか難しいよなあ。言語やフレームワークについても多様性の利点と統一の利点はトレードオフと書かれていたし、たぶんインフラ技術も同じ。
08:30
西田和史(k.bigwheel) 開発基盤EM @ Speee ⌨️🖊️ @k_bigwheel
阪神タイガース - プロ野球 - スポーツナビ https://baseball.yahoo.co.jp/npb/teams/5/top 阪神2勝15敗とかやべーな。1年目楽天かよ。
06:54

ツイート	お気に入り	フォロー	フォロワー
17531(+34)	5288(0)	517(+1)	898(0)

delivered by Twieve