Naoさんの自己紹介とチームの構成
ken
リスナーの皆さん、こんにちは。London Tech TalkのKen Wagatsumaです。
本日もブッククラブの第6章を読んだ感想を、ゲストの方をお呼びして話していこうと思います。
今日はゲストにNaoさんをお呼びしています。今日はよろしくお願いします。
Nao
よろしくお願いします。
ken
ということで、Naoさんは今回の2回目のブッククラブの方から参加してくれていて、
今回のLondon Tech Talkのゲスト出演は最初になると思うので、
簡単に自己紹介をお願いしてもよろしいですか。
Nao
はじめまして、Naoと申します。
今、Octopus Energyという会社でフロントエンドのエンジニアをしています。
エンジニア歴自体は4年ちょっとぐらいという感じで、
Octopus Energyは2社目という感じになります。
海外の会社で働くのも初めてという感じです。
今のチーム自体は割とバックエンドの人と一緒に機能を開発することが多くて、
API周りの相談というか話とかしながらとかそういう感じで、
UX、UIの実装をしているという感じになります。
よろしくお願いします。
ken
ありがとうございます。
これ社名を聞いて気づいた方もいると思うんですけど、
昔テッペイさんの転職成功会をしていたんですけど、
テッペイさんが転職した先がOctopus Energyということで、
これ同じ会社だったんですよね。
Nao
その会を聞いて、え、Octopusはテッペイさんなの?みたいな感じで。
もともとこちらのポッドキャストも聞かせてもらってて、
ロンドンテックトークのテッペイさんがいることは分かってたんですけど、
それが自分の会社とテッペイさんというのは分かってなかった。
同一人物なのか。
まさかの同一人物。びっくりみたいな。
チームが全然違くて、
Octopusってもう95%ぐらいがバックエンドエンジニアの会社なんですよ。
フロントエンドとバックエンドのコラボレーション
Nao
なのでバックエンドはものすごいたくさんチームがありますし、
人数もすごい多くて、フロントエンドはもうめちゃめちゃ少ないんですね。
だからいろんなバックエンドの人と仕事上で関わるんですけれども、
もう本当にたくさんいるのでっていう感じで。
テッペイさんリモートでっていうところもあったりしてっていう感じで。
はい、びっくりでした。
ken
そうなんですね。
河野さんはフロントエンジニアとしてコブッククラブに参加してくれて、
これめちゃくちゃ嬉しかったのが、
多分今回2回目フロントエンジニアほぼいなかったので、
SREとかね、あとはオブザーブビリティの会社で働いてる人とかだったので、
結構フロントエンドの観点を持ち込んでくれるのがすごい斬新だったんですけど、
現場では今どういうテックスタックと技術を使ってるとかって簡単に話せたりしますか。
Nao
はい、了解です。
リアクトのアプリケーションですね。
ものすごく大きいプロダクトで言うと、
PythonでDjangoで、
フロントもDjangoViewで書かれてるようなダッシュボードっぽい大きいプロダクトの中に、
1つコミュニケーションアプリというか、
お客さんとカスタマーサポートの人が会話をするっていう、
メッセージのダッシュボードみたいな部分のアプリケーションの実装をしてるんですけど、
そこだけリアクトタイプスクリプトで書かれてるっていう感じです。
で、バックエンドとのやり取りはグラフQLでやってるみたいな。
そんな感じですね。
ken
これバックエンドのコードを、
例えば時々直しに行くようなこともあるんですか。
もう完全に分離しているチーム体制。
Nao
そこまでここをしないでほしいとかは逆に言われないですし、
やりたいって言ったらやらせてくれる感じの会社なので、
私今のチームに来てからはやったことないんですけど、
前もう1個別のチームにいたときとかは、
クエリに新しくフィールドを追加して、
それに対してテストを書くっていうところの、
バックエンド側の実装をやらせてもらったこととかはありますね。
ken
なるほど。じゃあタスクベースは別に、
Nao
バックエンドのことをちょっと触ったりすることもあるんですね。
そうですね。で、コード自体はめちゃめちゃ見に行きますね。
どういう実装になってるのかっていうのは。
ken
そこの境界線はグラフQLがあるということで、
グラフQLのエクスプローラーとかである程度分かると思うんですけど、
なんか結構頻繁にバックエンドチームとはコミュニケーションを普段したりするんですか。
Nao
しますね。もう普通に毎日しますね。
特に新しい機能を実装するときとかは、
一緒にデザインワークスルーとかして、
どういうUXが求められてるのかっていうこととか、
あとは、私たちのアプリケーション以外の部分は、
DjangoViewでフロントが作られてたりっていうこともあったりして、
ちょっと特殊なんですけれども、
もうすでにその実装がDjangoViewで、
別の私たちのプロダクトの外に存在している場合は、
iFrameで呼ぶだけだったりして、
バックエンドの人の仕事がいらないとかそういうこともあったりとか、
そういったあたりも、いらないも踏まえて話したりとかですね。
あとはデザインだけ見ても、
やっぱりバックエンドの人ってどういう挙動が期待されてるか分からなかったりとかするんで、
基本的に私がデザイナーの人とがっつり話をして、
一緒にフロントエンド、私、もしくはもう一人ぐらいと、
あとバックエンドの何人かの人と一緒にやって、
ただ私たちの会社はそんなにこう、
チームの国際的な構成とビジネスインパクト
Nao
バックエンドとフロントエンド、開発の足並み揃えてってことはあんまないので、
それぞれのチームにそれぞれのプライオリティがあるんで、
そこは一緒にセッションはするんですけれども、
バックエンドがすぐにそれに取り掛かれて、
フロントエンドは違うのがパイプライに入ってきたりすると、
もう全然バックエンドの方が先に開発進めてくれてたり、
逆もあるみたいな感じで、
両方が揃ったタイミングでリリース。
デッドラインが厳しければそこはお互いのチームでハイプライオリティのタスクになるんで、
同じぐらいのタイミングでみたいな、なんかそんな感じです。
ken
コミュニケーションのコンポーネントを作ってるってことだったんですけど、
それはコミュニケーションという機能分割で同じチームのバックエンドエンジニアがいるって感じですか?
マネージャーとかプロダクトリーダーが一緒。
レポートラインとかも一緒なんですね。
Nao
レポートラインは違いますね。
フロントエンドのリーダー、バックエンドのリーダーみたいな感じがいて、
私自体はフロントエンドのリーダーがレポートラインって感じですし、
どんどんたどっていけばインターフェイスとかヘッドフロントエンドとか
そういう感じの人たちになっていくって感じで、
バックエンドは全然また別のっていう感じ。
そこはばっきり分かれてますね。
ただスタンドアップとかは一緒にやったりとかしますし、
全部じゃないですけど、フロントエンドだけでもありますけど。
ken
というのもフロントエンドとバックエンドの協業とかコミュニケーションとか、
結構いろんな会社で話題になってるかなと思ってて、
そこの問題とかどういうふうに解決してるかって結構組織体制とか、
リードのフィロソフィーというか哲学とかに影響されるというか、
チームの形によって結構コミュニケーションフォーム変わってくるじゃないですか。
今日いろいろちょっと話ししていく前提として、
naoさんがどういうチームにいるのかなというのが興味があったのと。
今はnaoさんはAPACチームで、
オクトパ・セナギチはIMIAタイムゾーンにもいるんですよね。
フロントエンドは確かAPACに多めみたいなことをちょっと。
Nao
今はAPACに多めですね、はい。
ken
それはたまたま?
Nao
たまたまですね。
一番最初はUKでスタートして、
UKしかほぼ人がいなくてって感じだったんですけど、
APACでババって人が増えて一緒ぐらいになって、
APACでフロントエンドがもっと増えてみたいな感じになって、
そこは決まってるというよりは、
必要に応じて増えてるみたいな感じで。
またそこもちょっと複雑っちゃ複雑なんですけど、
プロダクトのチームにいながらも、
APACのフロントエンドチームの一員でもあるので、
ken
別のチームとしてちゃんと存在してる?
Nao
存在してますね。
そこにリーダーがいるって、
そこがAPACのフロントエンドのトップのリーダーで、
その中にプロダクトのチームにいる人とか、
3つぐらいチームがあってっていう感じなんですけれども、
その中での行き来もあったりして、
私最初別のチームにいたんですが、
ken
今のチームに来て、
Nao
最初のチームは日本のマーケット向けの、
インシューマー向けのサイトを作ってるっていうあれだったんで、
その先自体は日本のお客さんって感じだったんですけれども、
プロダクト自体はユーザーが全世界にいるので、
なのでグローバルチームっていう感じになってて、
そのリージョン区切りの製品というかサービスではないので、
全国というか全世界にデベロッパーがいてっていう感じで、
週に1回だけグローバルのスタンドアップがあってっていう感じでやってますね。
ken
それじゃあユーザーのボリュームというかユーザーのリージョンも違うから、
開発のカルチャーというかチーム雰囲気も結構違う感じですか?
前のチームと今のグローバルにいたしてる。
Nao
違いますね。
ken
例えば求められるデッドラインの納期とか。
Nao
違いますね。
というよりはなんとなくそのビジネスが置かれている環境に左右されているというか、
例えばコンシューマー向けだとやっぱりマーケティングとかが結構近くなってくるので、
ビジネスインパクト本当に費用だけの話とかじゃなかったりするじゃないですか。
マーケティングだとタイムセンシティブっていうか、
なんかこの時までこのキャンペーンとかだったりとかするので、
そういう意味でのデッドラインがあったりとかしたり、
機能的にすごいからとか、
機能性というよりはどっちかというとそういうタイムラインの方が結構色が強いかなっていう気がしてて、
私は今そのプロダクトのチームにいるので、
そこの方がやっぱりそのビジネスインパクトとかユーザーの数とか、
あとはそのバグとかにしてもパフォーマンスとか、
そういった機能的なことでの優先順位の入れ替えっていうのがあったりするかなって感じですね。
ken
そうですよね。やっぱりキャンペーンに結構左右されますよね。
Nao
されますよね。
なかなか個別なんでね、それも難しいところが、
できれば共通化してっていうところがある程度ソフトウェアの基本的な考え方の部分あると思うんですけど、
もちろん共通化もできるんですけど、キャンペーンってやっぱりクライアントさんごとに表示を変えたいとか、
やっぱりそういうそっちの広がりとこっちがやろうとしているその、
なんていうんですか、
なんていうのかな、そのシェアしていくっていうところがどうしてもコンフリットする部分もあったりとかするんで、
Simplicity vs. cost of maintenance for your APIについて
Nao
それをどうやってテックの技術でカバーしていくかみたいな、
そういうところの面白さっていうのもあるのかなって。
ken
技術力が試されるところですね。
昔クックパッドにいた頃広告事業でいて、広告事業なんで結構キャンペーンとかってあるんですよね。
例えばシーズンに合わせて、秋の味覚に合わせてとあるクライアントさんと、
これを出したいからみたいな、たぶん全く同じような状況ですごい、
Nao
昔を生み出した気もしますね。
ken
はい、じゃあ、
そもそもこの輪読会に参加しようと思ってくれたきっかけって何かありますか?
Nao
この本をもともと読もうと思っていた。
本の存在は知らなかったんですけど、
バックエンドの話もちょっと分かるようになりたいっていうところと、
あともう一つはやっぱり結構コードが難しいというか問題もあったりしたり、
あとモノリスなんで、そのあたりのフレキシブルさも少なかったり、
いろいろそういうのがあって、
フロントエンドにのというよりかは、
もうちょっとソフトウェアエンジニアリングに対しての知識をもうちょっと身につけたいなって思ったところと、
あとはやっぱり職場に全然日本の人とかがいなくて、
テペさんとかいらっしゃるんですけど、やっぱり仕事上で関わり合うこととかもないんで、
やっぱりそういうみんないろんなところで働いている、
全然別の会社の人たちと一つのことを会話していくってなった時に、
そういういろんな意見が聞けて面白いっていうのもあったり、
あとは自分がうまく言語化して自分の分からないことをそもそも伝えるっていうこと自体も難しいっていうか、
一つのスキルになってくると思うので、やっぱりそういうところも練習したいなっていうのもありました。
会社自体もグローバルなんで、知らない人と会ってビジネスの話をするっていう場面とかも増えてきているので、
やっぱり気遅れしちゃうことがないようにしたいなっていうのがあって、
英語わからないしとか、車歴とかもそんなに長くないしとか、
もちろん戦うわけじゃないので、わからないことは聞けばみんな教えてくれるって言われて優しいフードなんですけれども、
自滅する要素をできるだけ減らしたいなって思ってて、
自分で勝手に気遅れしちゃうみたいな、
そういった意味でもやっぱり安心感を持って、まずこういうところでできるっていうのはすごい良いかなっていうのと、
フォトキャストで雰囲気がなんとなく優しい感じ。
フォトキャストはずっと聞いてたんで、絶対なんか優しい感じだなって感じでお願いします。
ken
ありがとうございます。
そこで今触れてくれた会社でのソフトスキルの話とかめちゃくちゃ僕わかるね。
これ話し始めるとまた1時間めっちゃ使っちゃいそうですけど、本当にわかる。
別連また収録したいぐらいですね。
ですよね。
じゃあ今日は、あくまでね。
僕本当に脱線しがちなので、
絞らないと。
Nao
絞りましょう。
ken
ごめんなさい。
Nao
いやいや全然、でも私もすごくこうなんだろう、
ものすごく具体的にすべてが理解できるっていう感じではないですし、
そこまでは多分できないから、しようっていうのもそこまでもなくて、
大体みたいな感じなので、
トピックも1個とか2個とかぐらいで、
ちょうどそんなに深掘りできない。
そこまでのあれがないから。
ken
それでもいいです。
てか本を読んで完全に理解するか無理じゃないですか。
完全に理解したら著者になれますよねって。
読み方も人によって違うと思うんですよね。
今回のブッククラブに参加してくれる人も多分読み方違ってて、
なんか事前に読むところに価値を感じてくれてる人もいれば、
参加して議論するところに一番楽しんでくれる人もいれば、
他の人の記事録というか読書ノートを読んで勉強になってる人もいれば、
読み方もそうで、
ソースコードがすごい勉強になるっていう人もいれば、
議論する中で自分のアイデアを紹介させていくみたいなところにも、
価値を感じてる人もいるから、
むしろ読んで全部分かったら読む必要がないというか、
分からないから振り返られるような、
やっぱ難しいところを選んでいきたいなと思うので、
ここはすごい僕も同じ気持ちですね。
今回あれですよね、第6章ということで、
タイトルがSimplicity vs. Cost of Maintenance for your APIということで、
まさにフロントエンドとかバックエンドで機能開発してる人にとって、
面白いトピックだったんじゃないかなと思うんですね。
多分普段コードを書く中で、
それこそさっきのマーケティングのキャンペーンみたいな話で、
来週までにこれを書いてくれみたいな感じで、
本当はもっときれいにアーキテクトして書きたいけれども、
脳機があるからちょっとSimplicityとかを犠牲にして書いたりとか、
メンテナンスのコストを増やしていることを分かりつつ、
どうしても機能を明日までに出したいから書いたりとかっていう、
日々トレードオフの攻め合いとかだったりするんじゃないかなとは想像するんですよね。
だから結構その議論も今回盛り上がったと思うんですけど、
まず第6章のざっくりとした感想をなおさんに聞いてみたいんですけど、
僕はSREなので、今は機能開発するっていうところほとんどないんですよね。
なのでこれ、今年、去年かな出た本ですけど、
今現場でプロダクト開発するなおさんにとって、
この章のざっくりとしたまず全体的な感想っていうのをお聞きしてもいいですか。
Nao
はい、そうですね。
この本のタイトルにもある通りやっぱりこのトレードオフだなって、
すごい短くまとめると、トレードオフだなっていうのが本当にあって、
こうすればすごくその実装だけに関してはスムーズだったり早かったり、
わかりやすかったりとかいろんなメリットがあるけれども、
結局ビジネスが大きくなっていったり、クライアントが発生してきたりとかってなってくると、
その後々メンテナンスをするってなったタイミングでのダメージが結構、
自分のところなのか相手先なのか、どこかにはボーカルが少なから発生してしまうっていうのがあって、
そうだよなってすごい思いながらですね、読めた章だったなっていう感じですね。
ユーザー体験の価値提供
ken
めちゃくちゃわかる。そして僕思うんですけど、
フロントエンジニアとかモバイルエンジニアってプロダクトの要だと思うんですよね。
なおさんも読書のノートに書いてくれているコメントをちょっと読み上げると、
フロントでフォールバックの実装を必ずしておくことも結構大事だと、
少なくともプロード破壊は阻止って書いてあって、
これまさに同じような状況先日あったんですよね。
ちょっと詳細は話せないんですけど、
バックエンドでとある外部サービスにコールしてますと、
その外部サービスが壊れたときにどうしますかみたいな話なんですよね。
外部、サードパーティーなんで僕らは基本的に何もできないけど、
ユーザーは使ってくれてるから、外部サービス壊れました、ごめんねっていうのはちょっと、
なんていうんですか、技術力がないというか、
無体なのでこれを何かするかっていうときは最後の要が、
ユーザーが日々接しているフロントエンドなんですよね。
で、結局そこで何をしたかというとフロントエンド側で、
もちろんサードパーティーのコアのフィーチャーが壊れてるから、
コアの機能は使えないんだけどユーザーがフリクションレスというか、
ストレスを感じないようなユーザー体験になるように動線を書いたりとか、
ポップアップを見せたりだとか、
あとは見せられる別の静的なコンテンツ、ステティックなコンテンツを見せたりだとか、
やれることってすごいたくさんあって、
そこでユーザーのプロダクトへの信頼感というか、
心をつかむかなんで、
ここすごい何だろう、結構大事な章でもあったし、
コストブメンテナンスも大事なんだけど、
ユーザーにどれだけの価値を届けられるかみたいなのが重要なんだなっていうのを
結構皆さんの話を聞いて思ってたんですよね。
フロントエンジニアとモバイルエンジニアの役割
Nao
そうですね、なんか404のページを結構可愛くしたり、
面白くしたりするっていうのは結構いろんな会社さんがやってるかなって思います。
ken
確かに確かに。
オクトパスさんも何かやってます?
Nao
オクトパスもやってます。
なんかリージョンによってもしかしたら違うかもしれないんですけど、
ジャパンはオクトパスってあのタコ、あの子の名前コンスタンティンって言うんですけど、
なんか結構3D立体的に見えるコンスタンティンがなんかポーンっていっぱい、
なんかコンスタンティンが破裂していっぱいのコンスタンティンになって、
なんかウォーみたいな感じで埋もれていくUFOキャッチャーの中身みたいな感じになって。
ken
おー楽しそう、ちょっと後でやってみよう。
Nao
やってみてください。
でなんかマウスで動かせれるんでそのパンパンって。
めっちゃいいじゃないですか。
マウスにインタラクトな感じで。
ジャパンのコンシューマー、コンシューマーサイトの方ですね。
ken
あー楽しそう。
なんかそういうイースターエッグとかちょっとファンな機能入れられるのも楽しいとこですよね。
Nao
確かに確かにそういうのもやってますね。
なんかあの旬分の日に桜が舞うようにとか、
当時の日に雪が舞うようにするとか、
あのそういうのはやってますね。
ken
めちゃくちゃ面白いな。
この章を絡めて言うと、
例えばでもそういったアニメーションとかそういったもので、
プロダクト側の価値ってどうやって提供していくのか。
ただ単純にそれをイースターエッグを増やしちゃうと、
メンテナンスコストというか増えていくじゃないですか。
例えばアニメーションを使うにしても、
CSSとかJavaScriptどのAPIを使うかによって、
もしかしたらすぐリプリケートになってエラーになってしまうかもしれない。
ユーザーにアディショナルの、
ちょっと楽しんでもらいたいからと思って書いたコードがゆえに、
他のコアが壊れてしまうみたいなリスクもなくはないじゃないですか。
Nao
そうですね。
それはそこだけ、
ここで隠蔽って話になるかもですけど、
Encapsulateというか、
それだけ用のコンポーネントを使って、
バックエンドとやり取りすることはこの場合は、
例えばそういうアニメーションとかの場合だと特にないので、
例えば4.4とかだったら、
4.4になったらこれを表示するっていう風にしたりしますし、
あとは日付とかに関しては、
Next.jsっていうのを使ってるんですけれども、
あそこがすごいダッシュボードが充実してて、
環境変数をダッシュボードに入れれるんですけど、
それをいつからいつの間トゥルーにするとか、
そういったこともあったりとかできたりするので。
ken
Next.jsのダッシュボード?
Nao
ダッシュボード、どっち言ったらいいんですかね。
そこに環境変数があって、
そこに環境変数を登録しとけれるんで、
フィーチャーフラグのメンテナンスコスト
Nao
タイマー機能はごめんなさい、ついてなかったですね。
嘘ですね。
だからそこでターンオンしたい日にそこに行って、
ポチって押して、
でターンオフするってなったらポチって押す。
そしたらもうそのコードの中には、
フィーチャーフラグですね。
フィーチャーフラグ自体が入ってるんで、
こうだったらこれ、そうじゃなかったらこれっていう、
ただのIf Elseになってるんで、
で、そこ、ただ通料になってたから雪が降るみたいなとか、
なんかそんな感じ。
CSSだとそういう感じですね。
だからそれは確かに少しだけ複雑性は増しますけれども、
メンテナンスコストで言うと、
インフラでカバーしてるって感じになりますね。
ExoJSのダッシュボードの方で簡単に操作できるから。
でもそれを全てコードベースでハードコードで管理してると、
確かにメンテナンスコストってすごい増えちゃうと思うんですけど、
結構そのあたりは充実してて、
フロントエンドの方で。
なるほど。
ken
うまくやってるんですね。
フィーチャーフラグも話出てきたので、
これぜひちょっと最近僕が個人的に気になってるトピックであるので、
ちょっと聞いてみたいんですけど、
フィーチャーフラグは外部のサービス使ってますか?
それとも内製の?
Nao
うちは内製ですね。
なるほど。
ken
フィーチャーフラグって、
例えば何%ロールアウトみたいなところとかも結構フレキシブルに
カスタマイズできるんですか?
それともオンオフみたいなシンプルなブーリアンな感じ?
Nao
シンプルなブーリアンですね。
ただクライアントごとに操作できるようにはしてるので、
世界のパーセントでいうと、
プロダクト全体で見たらパーセントっていう考え方にはなったりするんですけど、
クライアントごとって言うとちょっと言葉があれなんですが、
正確に言うとそのドメインごと、
なのでなんとかかんとかドット、
ゴムとかあると思うんですけれども、
そのドメインごとに設定できるようにとかなってるんで。
ken
なるほど。
ちなみにそのメンテナンスコストという、
今回のショーのトピックでもある、
そのコストのメンテナンスの観点で言うと
フィーチャーフラグってぶっちゃけどうですか?
よくあるのが、
例えば2,3年前の、
例えばそのAdHocのマーケティングのキャンペーン向けに
作ったフィーチャーフラグなんだけど、
それが結局ずっと使われることになったりとか。
で、SREの観点で言うと、
昔の誰かのアプリケーションエンジニアが作ったフィーチャーフラグが
ずっとそのままオンになってて、
それを説明できる人もいなくて、
オフにしたらそれがエラーレート的に
どういう影響を与えるか分からなくて、
で、それがメンテナンスコストになってしまったりだとか、
っていう課題が結構あったりするんですけど。
Nao
確かにそうですね。
なんかそれはコードのクオリティって言うと
ちょっと言葉があれなんですけど、
コード自体のコードとかデプロイのやりやすさとの
トレードオフかなって思ってて、
結構やっぱりフィーチャーフラグ、
例えばうちとかであるのはAPACでは大丈夫だったけど、
EUとかヨーロッパの中の1個のクライアントさんとかでは
違う設定があったりして壊れちゃうとかっていうことが
実はあったり過去にあったりとかしたことがあって、
そういう時に、そうなんですよ。
特にセンシティブな機能の変更であったり、
実装の場合は最初やっぱりフィーチャーフラグでやっといて、
オンにすることのコストとか、
その後々のコストとかいうよりも、
やっぱりプロダクションが壊れないっていうと
壊れるリスクっていうのは最小限にできて、
壊れちゃった時にすぐにターンオンできる、
オフできるっていうのが一番やっぱりメリットとしては大きいかなと思ってて、
だからこそのメンテナンスコストはやっぱりかかるかなと思うんですけど、
そうですね、ただあとはもう全部がオンになっちゃってるのを見つけたら消しますね。
もうそれはお掃除するっていう感じで、
どこのクライアントでオンになってる、オフになってるっていうのは
コマンドを叩いて分かるようになってたりとか、
するので、
なんでそれもそうですね、
メンテナンスは確かにしないといけないんですけれども、
やっぱりプロダクト破壊と転弁にかけた時に、
ブレイクするよりいいかみたいな感じだったり、
リリースする側も安心してリリースできたりとか、
ken
確かに。
Nao
ありますね、でこっちがやっぱり寝ちゃう、
こっちの昼過ぎとか夕方とかにリリースして、
APACでは大丈夫なんだけどとかってなって、
でそのUKとか他のヨーロッパの人たちがなんか、
ってなっちゃった時とかでも、
このフィーチャーフラグだから一応APACでは問題ないんだけど、
っていう形でのリリースだと、
コミュニケーション自体もやりやすかったり、
OK、OKってなるんで。
ken
確かに確かに。
はい。
そっか、その形でロールアウトできるのは、
オクトパスエナジーさんのビジネスとかプロダクトの特性かもしれないですよね。
全世界でやっていてクライアントごとに違う設定もありえるみたいなところで。
Nao
そうですね。
ken
やっぱりこう行動出す側としてはプロの破壊したくないので、もちろん。
セーフな感じでロールアウトできるのは確かに大きいですよね。
Nao
そうですね。
ken
フロントチームもオンコールみたいなのあるんですか。
Nao
ないですね。
ken
じゃあ基本的にデプロイするときは、
自分の業務時間に監視できる時間帯にするとか、
金曜日はなるべく早めにデプロイするとか、
デプロイ体制ってそんな感じ?
Nao
そうですね、あんまり細かく言われてないですね。
ていうかどちらかというと、
そういうのを気にせずにデプロイできる状態にしておくのが目指すべきところだから、
どちらかというとデプロイしろみたいな感じですね。
金曜日だからって気にするなみたいな。
ヨーロラってよく言われますけど。
ken
めっちゃいいじゃないですか。
そういう雰囲気好きですね。
Nao
リーダーがそういう雰囲気の人たちが多いので、
それはすごい明るくていいなって思いますね。
ken
めっちゃいいな。
いやでもそれ、オクトパスエナジオなんかポッドキャストかなんかで言ってた気がする。
スタートアップ的な雰囲気があるというか、
スタートアップなのかな。
わかんないけど。
Nao
でも8年とか経ってるんで、
インベスターの方たちからすると、
おそらくスタートアップっていう枠ではもうないのかなと思うんですけれども、
なんか若い感じがありますね。
ken
ヨーロラってこう全部。
めっちゃいい。
Nao
とりあえずできる、全部じゃなくてもいいから、
なんか20%のクオリティでもいいけど、
これめっちゃクールやからとりあえず出そうぜみたいな。
ken
それめっちゃいいな。
Nao
そういうのとかはあって、
それでできたら、見た目とかいけてないんですけど、
フロントからしたらめっちゃ簡単な、
ごめん、ほんまこんなんやけどいいの?みたいな感じ。
いやでもこれ機能できたからイエーイ!みたいな感じで、
みんなで盛り上がるみたいな。
それはすごい楽しいですね。
ken
めちゃくちゃいい雰囲気ですね。
雰囲気いいですね。
確かにどれだけ価値を提供できるかなんですけど、
意外と行動の行数が少なかったり、
難しくなくても喜ばれるみたいなところもあるんだよね。
Nao
それは本当に、
はい。むしろそういうことはすごい褒められますね。
難しいことをしろって言ってるわけじゃないから、
インパクトがあるっていうことをやっぱり、
自分たちのクライアントに対して、
クライアントってかそうですね、
自分たちに対してどれだけインパクトがあるかやから、
行動が簡単、むしろ簡単の方がいいやろうみたいな。
ken
確かに。
Nao
そんな感じ。
ken
そうですよね。
シンプルなソリューションの嬉しさ
ken
この章もね、シンプリシティについて丸々一緒に語ってる章ですけど、
やっぱりエンジニアとしてはシンプルなソリューションを考えたときって、
なんかすっごい嬉しいというか、
Nao
ですね。
ken
シンプルなアーキテクチャとかシンプルなスクリプトとか、
それってやっぱり気にしなくちゃいけない、
エッジケースとかエラーケースも少ないはずなので、
バグも少ないんですよね、基本的には。
Nao
確かに。
私たちがシンプルに実装できたりやりたい、
もしくはまたはシンプルとは逆かもですけど、
自由度高くできたりするのってやっぱりバックエンドの人たちの考慮してもらった、
あれなんだなっていうのはこの章を読んで結構、
なるほどなと。
もちろん会話はしますけれども、
そういったどういうところまで考えてやってくれてるかとかっていう細かい話は、
なかなかする機会がないので、
そういうのはすごい、
バックエンドの人たちありがとうみたいな感じの気持ちにはなりましたね。
そうですよね。
ken
さっきもコメントしてくれたけど、
どこに複雑性を持っておくか、
フロント側なのか、バックエンドのグラフケールのリゾルバーなのか、
インフラ側に持っていくのか、
それともサードパーティーのツールを買って、
そこに複雑性を持っていくのかによって、
どこに複雑性を持っていくかによって、
開発者のスタイルとか開発速度も変わってくるんですよね。
Nao
そうですね。
やっぱり具体的なことに対するソリューションであれば、
1対1みたいな関係で、
すごいパパって分かって早くできたりとかするかもしれないですけれども、
それはもう少し抽象化して考えてっていう、
そういう頭が結構必要になるのかなって思った回でもあったので、
そこに多分面白みもあったりすると思うんですけれども、
設計の。
なので、そうですね。
ken
なんかその具体的なものは1対1みたいな話があって、
そうだこれぜひ、
具体的な問題と抽象化解決
ken
今日直さんに聞いてみたかったのが、
これ読書メモですごいまた他に面白い位置を書いてくれて、
その具体的な問題と、
それを抽象化して解決する頭が必要っていうコメントを書いてくれて、
ここでどういう思いを持って書いてくれたのかなって聞きました。
これリンクも貼ってくれて、
なんか具体と抽象、世界が変わって見える知性の仕組みみたいな方のリンクを貼ってくれて、
これ僕読んだことはないんですけど、
ずっとウィッシュリストに入っている本で、
Nao
そうですね、有名ですよね結構ね。
ken
多分有名だと思う。
これをこの本とこの章のインターセクションというか、
どんな思いでこのコメントを書いたのかなっていうのを、
もし覚えていたら聞いてください。
具体的な問題と抽象的な問題の解決
Nao
そうですね、この章の中だとバッジサービス、
ちょっと具体的にやりすぎちゃうんであれなんですけれども、
隠蔽するかしないかみたいなものの例として、
直接的、ちょっと言葉があんま分からないんですけど、
直接的な処理をするのか、隠蔽して処理をするのかっていう話になって、
そこから何か思い出したような気がするんですけれども、
結局やっぱり実際のプロダクトってなったら、
ほぼ隠蔽一択なのかなっていうのがあって、
それは最初に書いたコードがそのままなことっていうことはほぼなかったり、
それからコードを書いてる人にとっては、
どういうビジネスリクワイアメントが来るかっていうのは全く未知なので、
そういったいろんなことに対して、
ある程度対応できるようにしとかなきゃなっていう気持ちは常にあって、
ただそうすると複雑性も増していくことになったりするので、
そこのトレードオフを常に考えておかなきゃいけないと思うんですけど、
自分の中でだと、具体的だと質問に対して答えるみたいな印象があって、
抽象化ってなってくると、問題自体も一つではないんだけれども、
もう一枠大きいスコープで考えると、
コアとなってるイシューっていうのは同じものだったりとかすることがあって、
それは別々のプロブレムなんだけれども、
一つのことで解消できたりするよねとかっていうことってよくあることかなと思っていて、
そういった考え方って結構抽象度高い考え方かなと思ってて、
でもどちらが大事っていうわけでもないというか、
どちらも起こるし、どちらもできないといけないし、
そこをどっちかっていうよりかは、
行き来ができるっていうことがすごく大事なんだろうなっていうふうに思って、
具体レベルと抽象レイヤーの行き来ができるということですね。
実際コード書くってなったら、そのパーツもそのラインに自分自体もしばらくいたりとかするわけですし、
それはすごく具体的な行為なんですけれども、
でも頭の中で考えていることっていうのは、もう少し抽象度の高いことを考えてたりするわけなので、
そこの中での最適解を自分の中で考えて、
今これだなって自分で決断するっていうのもやっぱりそういう思考回路なのかなっていうふうに思ったりして、
この本を思い出した感じでしたね。
ken
その話めちゃくちゃ面白いですね。
なんか結構その具体的というか目の前の問題に、
こう、なんていうんですか、
注力しすぎてしまうと、
木を見て森を見ずな状態になってしまうけれども、
かといって抽象レイヤーで語りすぎると、
なんていうんですかね、
本当に解きたかった考えが解決できない。
その行き来するっていうのを本当にいいキーワードだなと思ってて、
具体から抽象に行くためのマインドセットとスキルと、
抽象から具体に行くときのマインドセットスキル、またそれぞれ別なイメージなんですよね、僕は。
例えば、具体的から抽象化するときには、
一歩こう、ステップアウェイ、距離を置くというか、
距離を置いて客観的に解きたかった問題を見れるような距離の置き方っていうマインドセットとか、
あとはそのフレームワークみたいなもので、
自分の解きたかった問題をロジカルに説明できる。
で、抽象化から具体的に行くっていうのは、
なんていうんですかね、
たぶん考え方とかフレームワークとか、
たぶんツールはあると。
で、それを目の前の問題をたぶん真に理解しないといけないんですよ。
たぶん課題理解というか、課題発見というか、
たくさんのイメージを持って聞いていたんですけど、
ここらへんに関しては尚更どうですか、
その具体と抽象を行き来できるようになるためには、
何が必要かというか、何を鍛えたらいいかとか、
Nao
そうですね。
たぶんどちらにも共通で言うと、
けんさんもおっしゃっていた通り、その理解ですね。
それに対する理解度というのと、
あとそれを整理する力みたいなのもいるのかなと思っていて、
課題だけ発見しても、アイディアとしてはバババってアイディアはたくさんあっても、
それをどういうふうにパターン化するか、
どういうふうにグループ分けするか、
もしくはどう並べるかっていう整理の仕方でたぶん変わってくると思うので、
そういった思考の力が必要かなという気がしていて、
具体と抽象という話自体がすごい抽象的じゃないですか。
なのでそれを例えば具体的に話しするとしたら、
依存先というか関わっている人とかで考えると、
私としては捉えやすいんですけど、
例えば一人で行動を書いているというのがものすごく具体的な行動だとすると、
そこからチームってなると少し抽象度が高くなって、
他のステークホルダーも交えた会話ってなるとそうなってきて、
クライアントも交えてくるとってどんどんそういうふうに、
もちろん一つ一つの会話は全て具体的ではあったりするんですけれども、
そこのレイヤーで考えているっていう頭としては、
とはいえ自分はそのチームに属しているわけなので、
そこのレイヤーにいながら自分の課題を考えるということは、
割と抽象度っていうとおそらくちょっと間違ってはいるとは思うんですけれども、
やっぱり依存先が増えれば増えるほど、
具体的な話というよりも少し抽象度の高い話にしていかないと、
そのみんなのインターフェイスを擦り合わせられないって感じになってくると思うので、
本当にコードに落とし込めばそれはトゥルーかフォルスかっていうルーリアンの話になるけれども、
ビジネスインパクト、クライアントとかまでの話になっていったら、
カスタマーを300万人増やすとかそういう話になったりするわけじゃないですか。
なのでそこらへんの行き来っていうのをしようと思うと、
もちろん行動の話もそうなんですけれども、
会社とか社会のこととか結構いろんなことを知っておく必要があったり、
そういうのが増えていくなみたいな。
それが広がっていく方向で落とし込んでいくってなると、
多分整理して何をするっていう、
例えば最終的にコードとかを見ていった結果、
このルーリアンに落とし込まれるみたいな、
なんかそんなイメージを持ってますね。
なんか考え抜いたがゆえのシンプルなルーリアンフラグみたいな。
コードで書くとそれになるみたいな。
ken
いやそれめちゃくちゃ面白いな。
チーム開発における具体性と抽象性
ken
途中ですごいキーワード言ってたのは、
みんなのインターフェースを揃えるみたいな言い方もしていて、
結局こういうのってチームで開発していくから、
チーム開発するぞってなった時に、
入ってきたメンバーのその時点でのスキルセットも違うし、
どれだけ具体的に課題を解けるかとか、
どれだけ抽象的に考えられるかのスキルもレベルも違うし、
でもその中で最後のルーリアンフラグみたいな解決策に
持っていくためにみんなを説得したり、
同じマインドセットとか同じインターフェースを揃えていかなきゃいけないっていうところの
チーム開発の面白さかつ難しさみたいなのもあるし、
やっぱりこのブッククラブを通じてても、
言ってることは理解できるけど、
チーム開発というか現場で考えるとやっぱり
もうちょっと考えなきゃいけないことが多いよねっていう
プラクティカルなアドバイスとか議論とかになったりするところが、
なんだろう、この本のいいところでもあったりすると思うんですね。
綺麗事言って終わらないというか、
トレードオフって言ってる時点で綺麗事ではないというか、
綺麗なシンプルな理論で全てを解決するシルバーバレットがあるわけではもちろんないので、
Nao
そうですね。
ken
すごい本当に議論向きだと思ってて、
今日もこの収録前に別の章の議論したんですけど、
単純に知識を取るためだけの本じゃないっていうところが、
確証が面白いところかなと思ってます。
Nao
確かにそうですね。
皆さんの実際の職場というか、
興味持ってる技術の話とか出てきたりとかして、
なるほどなぁみたいな感じだし、
やっぱりトレードオフなので、
決めをどうするかっていうのって、
会社、個人、チームとかによって本当に変わってきて、
どれも分かり身があったりとかするんですけれども、
それでそこに落とし込んだ背景とかって必ずあったりするので、
いろんな話が聞けて面白いっていう感じだなって思います。
ken
多分だからこれの本の一つの読み方としては、
ブッククラブで他の人の考えとか議論の持ってき方を学んで、
自分の説得の仕方の引き出しとか武器を増やして、
会社に持ち帰って同じような議論がなった時に、
彼はこういう言い方をしてたから、
こういう説得できるかなとか、
こういう話の持ってき方できるかな、
みたいな読み方はできるなと思って、
僕は読んでたんですけど、
今まで2回、3回くらいかな、
輪読会をやってみて、
現時点なおさん的にはどうですか?
テイクアウェイは結構ありそうですか?
Nao
結構ありますね。
やっぱり実際自分の会社のコードだってわけではもちろんないんですけれども、
でも自分が普段書いてるコードとは全然違うエリアの本だし、
集まってる方々もフロントエンドの方いらっしゃらなかったりとかあるので、
だけれども実際自分が関わってる開発にも必ずやっぱり起きてるトピックだったりするので、
100%わからなかったとしても、
大枠はどこなのかとか、
外しちゃいけないポイントってどこなのかとか、
あと、これはこの事例での話であって一般的じゃないとか、
あとはこれはソフトウェアのエンジニアリングの世界ではよくあることなんだとか、
そういうことを知る、経験値というか情報ですかね、
それが自分の中に溜まっていくっていうのは、
私も当然フロントエンド以外の人と話をすることもたくさんあるので、
そういったことへの一気にパーンって解像度は上がらないんですが、
徐々に徐々にっていう感じで上がっていく感じがあったりして、
すごいありがたいなっていう感じで。
ken
ちょうどショーも半分折り返すか折り返さないかぐらいのところなんで、
トレードオフと経験値の重要性
ken
今後が楽しみですよね。
Nao
そうですね、結構答えの出ない話、
トレードオフだし、
いつまでも話せちゃうみたいな感じのトピックではあると思います。
あといろんなバックグラウンドの方がいらっしゃるっていうのも、
すごいやっぱりいいのかな。
人によって、どの人が参加するかによって、
なんかディスカッションも変わるんだろうなっていう感じがあって、
ken
めっちゃわかる。
そうですよね。
じゃあこの収録のクロージングの代わりとして、
お互い今後の倫徳会後半の展望を話す感じにしてみましょうか。
じゃあ僕からいこうかなと思うんですけど、
今日ね、倫徳会参加して、
やっぱりプロのフロントエンドとかバックエンドエッジの方々と比べて、
コード書いてないなって思ったんですよ、僕はSREなんで。
一応コードを書くこともあるんだけど、
アーキテクチャとトレードオフ
ken
やっぱりアーキテクチャを脳が解けるぐらいまで考えてるかっていうと、
あんま考えてないというか、
障害が起こった時にそれを解けるようなアドホックな調査コードとか、
あとはその修正を入れるために、
調査の段階ではめちゃくちゃ考えるんだけど、
アーキテクチャとかトレードオフとかを日々のように考えてるかって多分考えてない、
別のトレードオフを考えてるんだけどっていうところがあって、
すごい、やっぱり他のソフトウェアエンジニアと同じレベルでちょっと後半語っていけるように
コードをもっと書いていかなきゃなっていうのに思ったのが一つと、
あと他の参加者の方がすごい良いことを言ってくれてて、
分かったことを書くのもいいんだけど、分からないことを書くのもいい。
分からないことを書くことで他の人から意見をもらえたりとか、
自分の間違ったところを修正できるみたいな、
これすごい良いことを言ってくれたなと思っていて、
その場でも言ったけど、
リンドク会をもともとリードしてくれたアサイくんのゴールとしては、
失敗してもいい場を作る、コミュニティを作るみたいなことを言ってくれたから、
今はアサイさんが育休して、後半僕が一応ファシリテーターを
引き継ぎみたいな感じにしたので、そういう場を作っていけたらいいかなという感じで
思いましたね、僕は。
Nao
ありがとうございます。
私はですね、私も分からないところをシェアするっていうのは
すごい良いなって思いましたし、
そこからディスカッションもすごい進んでたので良かったなと思ったので、
私ももう一歩具体的に踏み込んで、
単純に本当に全然分からないんだけどっていう感じで聞いてみるとか、
皆さんすごい優しく教えてくれる雰囲気とか土壌もしっかりあるって感じなので、
皆さんと何度か顔を合わせてっていう感じもあったりするから、
本当にここ全然チンプンカンプンでしたっていうポイって
そういうトピックとか聞いてみたりするっていうのも、
私としてもとても実りが多いですし、
一人説明するっていうこと自体も、やっぱり感想を言うとは別の角度のアウトプットかなと思うので、
そういうことが一個できたらいいかなっていう風に思ったっていうのが一つと、
今後の展望ですね。
あとはソフトウェアの設計自体の本だったりとかして、
私はやっぱりチームとかに属して機能とかを書いたりするっていうような、
どっちかっていうとそういうことの方が比重が大きかったりはするんですけれども、
でもやっぱりフロントエンドって割と技術の入れ替わりも激しかったりとかするので、
次のレベルになるためにはもう少し高いレイヤーで、
要は設計のレイヤーでっていうか、そういったところで考えられるようになる。
フロントエンドはもうバックエンドなしではやっぱり特に大きいプロダクトに関しては成立しないので、
そういったビジョンを描けるところまでいきなりはあれなんですけれども、
足掛かりっていうかなんとなくふわっと、ちょっと世界見えたかなみたいな、
なんかそういう感じになれたらいいなっていうふうに思います。
ken
いやーめちゃくちゃいいじゃないですか。
Nao
なんかこれを聞いてもっと頑張ろうと。
頑張りましょう。
ken
お互いみんなバーをあげ合えるのもいいですよね。
Nao
そうですね。
なんかなんかやっぱり、
読んだ感想を書いてから行くっていうのもすごい良いですし、
皆さん本当にやっぱりちゃんと読んでらっしゃったりとか、
こういうところが分からなかったとかっていうのがあって、
なんだろうすごいこうサラッととりあえずそこにだけ来てるっていうよりかは、
やっぱりモチベーションもなんか静かなる。
なんていうか、ギャーギャーしてる人は全然いらっしゃらないんですけど、
すごいこう、皆さんいい感じの炎があるなって思ってます。
ken
炎いいですね。
Nao
内なる情熱を感じる。
ken
感じますね。
僕もやっぱりファシリーとかだと肩肘張って、
なんかいろんなこう提供できるコンテンツを準備しなきゃとかってなっちゃうんだけど、
分からないところを認める強さっていうのはすごいあると思うから、
そこもね、やっぱりブッククラブによっても結構どのメンバーが参加してくれてるかによって、
雰囲気も全然違ってくるし、
やっぱりこれはすごい今のところ2回目あって、
僕もすごい好きな雰囲気でできてるから、
今後もちょっと頑張っていきましょう、お互い。
Nao
はい、ありがとうございます。
ken
ということで、じゃあ今回は第6章の
Simplicity vs. Cost of Maintenance for your APIのまとめを
なおさんと一緒に話していきました。
なおさん、今日はありがとうございました。
Nao
ありがとうございます。
