コードレビュー廃止の実例と開発フロー
今回はですね、ちょっと前回あの年間4から5回ぐらいこう登壇するためのネタの作り方を聞いたらですね、あの一番大事なのは一般化だというようなことだったんですけど
まあこれはの詰まるところちょっと自分の解釈的には自分に特化した話じゃなくて聞いた人、それを聞いた人にも使える話にするっていうことだと理解したんですが
これあのちょっと聞いてみてあの思ったんですけど、あのちょっとそのあのこう登壇のネタにするまとめ方が職人技すぎてですね
あの国明さんがなんかこうパッと思いつくみたいなことを中で言ってたので、じゃあちょっとこれ具体的にどうやるのみたいなところがふわっとしてしまったかなと思ったんですよね
なので今回は自分のネタを持ってきたので、それをどうやったらこう一般化して登壇ネタになるのかみたいなところを話していけたらなと思うんですけどどうでしょう?
はい、よろしくお願いします。そうですねあの聞いた人にも使える話っていうのがあってます。その通りで、ただちょっとやっぱり一般的すぎると話が分かりづらくなるんで具体例ベースで話すのがいいかなと思ってます。
何かhentekoさんって具体例とか題材ありますかね?
はいあります。これはあの仕事とか公開情報として全国会にも書いてるので、言っていい話かなと思って話しちゃうんですけど
仕事でチーム、開発チームで4人ぐらいでやってるんですけど、コードレビューをこの半年ぐらい
今年の2月ぐらいからかな2月3月ぐらいからなくしたんですよ全部。人間のコードレビュー、あのギタハブ上でのプルリクのコードレビューですね
を全部なくして全部AIによるコードレビューと、あとはテストで代替したんですね。
でちょっとその話をしていけたらなぁと思うんですけど具体的な。でその話をどうやったらこう一般化して
登壇のネタに持っていけるのかなっていうところを話して、もしこれうまくいったら何かのところで話したいなというような思惑で話を
できればなと思うんですけど、これいけそうですかね。いけそうです。じゃあちょっとあの話の具体的なところ
いっていけたらなと思うんですけど、まず前提としてさっきも言った通り開発チームは4人っていうちっちゃいチームですと。
でまぁあの他のチームにも人はいるんですけど開発携わっているのは4人だけっていう感じです。
で主にあのバックエンドのタスクが主ですね。レール図で使ってるんですけどあのバックエンド側のタスクです。
でさっきも言った通りなくした半年以上で今のところは大きな事故は今なしっていうような、インシデントとかもなしっていうような形です。
でこのコードレビューをなくしたフローをどうしたのかというとですね、もちろんコードレビューをなくしただけではないので
他にやってることがあるんですけど、コードレビューをなくす上で実装の前にですね、なんでこの変更をするのかっていうのを
タスク実行者が言語化してGitHubの一周に言語化した内容を登録するっていうようなことをまずするようなルールにしましたと。
でその上でその一周の内容をクロードコードにどのぐらいの影響範囲かというのを予測させた上で影響が大きい場合
レベル分けしてるんですけど具体的なところとしては、レベル分けしてざっくり言うとレベル4の場合は
レベル4以上の場合は影響が大きいのでその一周の内容を誰かに事前にレビューしてくださいって。
でそれがLGTMだったら実際に進めますよみたいな感じにしてますと。
で、もちろんそれで実装終わった後そのまんまでも問題ないかなと思うんですけど一応事前にこの一周にまとめた内容と実装結果っていうのを比べてですね
ギャップがあるかどうか。なんかギャップがあったら事前のレビューなんて意味ないじゃないですか単純に。
なのでギャップを洗い出してちゃんとギャップがないよねとか、あとはギャップがあった場合はじゃあどうしようかっていうのを話せるような
環境としてギャップを洗い出してそのギャップをスプリントレビューとかでチームに共有するみたいなことをしてます。
で、結果としてですね、もちろんレビューなくなったんで、このレビュー待ちっていうのは実装が終わってからは詰まることなくですねすぐリリースまで出せるようになったっていうのが結果としてはこの半年ぐらいで起きたことなんですけど。
素晴らしいですね。
どうですかね。
想定聴衆を増減させる一般化
まずこの話はもうすでに結構一般化されてるなと思ってて、会社特有の事情っていうのが少ないなっていうのは第一印象としてあって、例えば会社雇用の事情だと例えば
あるフレームワークのここを変更するのの影響度はなんちゃらとかっていうふうに会社雇用の事情が入り始めるとここはちょっとなるべく会社雇用の話を聞きたい人ってあんまりいないだろうから
どっちかっていうと、もうちょっと一般化して自分にも使える知識として教えてほしいっていうふうになっちゃうと思うんですけど、今の時点では結構いろんな人が使えるかなと思うんですけど、もうちょっとだけポイントがあるかなと思っていて
一つは今のこのコードレビューなくしてすぐリリース出せるようになりましたっていうプロセスが例えば金融系とか航空宇宙系とかで受け入れられるかって言われたら多分受け入れられない気がするんですね。
受け入れられないと思いますね絶対に。
コード見ないなんてことやっていいのかみたいなこと言われたら多分気がするんですよ。
絶対そうです。
やっぱりそのギャップがあると思ってて、この人たちは今のこの発表だとスコープ外の人たちになっているんですね。
一般化するってことはこういう人たちのどこかを切り取って想定聴取に入れるってことをしていくわけですね。
例えばどんな風にするかっていうと一つは例えばコードのその部分っていうのがすごくミッションクリティカルなお金に関わる部分とか命に関わる部分とかっていうところだったら人間のコードレビューを必須とするみたいなのを例えば入れてあげたとしたらそういう人たちはうまくカバーできるかもしれないわけですよ。
こういうところがまず検討の第一段階になります。
他にも例えばポイントがあって、これってすでにある程度コードベースがある人が前提になっている気もするんですよね。
なぜこの変更をするのかっていうふうな言葉になっていたわけですから、ある程度育ったコードベースがあってその中で一貫した規約が使われていて、そのコーディングエージェントがあんまり迷わずかけるっていう状態から出発していると思うんですけど、そうじゃない人たちもいるわけですよね、ゼロからプロダクト作るとか。
そういう人たちも例えばスコープに入れるかってなると、例えばその場合多分コーディング規約とかを作らなきゃいけなくなってくるわけですよ。
それをコーディング規約とかを作った上で、この今ヘントコさんのおっしゃったフローとかに乗っかるみたいなことをやる。
そういうふうな前提を足したりとか、想定聴取を増やしてあげるためにはどういう説明が必要かっていうのを考えるみたいなのが一般化なんですよね。
なるほど、自分が考えていないところの人たちにも届けられるようにするために、一般化するために考えられるだけのことを考える。
例えば金融業界の人が聞いたらどう思うかなだったりとか、金融業界の人たちにもちゃんと適応できるためにはどこを工夫したら、
どこをカスタマイズしたら良さそうかみたいなところを示唆として入れるみたいなイメージなんですかね。
そういうイメージです。
なので手順としてはすごく極端な人を何人か考えてあげる。想定聴取も考えてあげて、
その人たちがどういう感想を示すだろうか、その人たちは現実的なコストで拾えるだろうか、みたいなそういうことの選択の連続なんだと思うんですよ。
例えば私がもしヘンテコさんだったら、私は航空中とかの人はこの発表の連続で拾わないと思うんですね。
なぜかというと自信がないからです。
分からないからね。
分かんない。だからそれをある程度人様に発表できるレベルまで持っていくっていうのにすごいコストがかかるっていうふうに思ったので、
その人は取らないっていう選択したんですね。
一方で新規で始める人とかっていうのはなんとなく想像つくじゃないですか。
たぶんゴーディング規約とか、あとはこの参照実装をこんな感じのアーキテクチャで作ってみたいなことを指示すればうまくいくだろうなっていう予感があるんで、
これは入れてもいいかなって。そういうふうなコストと想定聴取を増やすのの選択の連続ですね。
が一般化だと思います。
金融業界だったりとかそういう業界を増やす、航空業界、あとは命扱う系の業界。
医療とかですね。
そういうところはわからないので、わからないことが多すぎるので、コスト的に対応するのがすごく高いので切り捨てると。
その上でゼロから始めるところを自分自身やったことありますし、そんなゼロから始めるみたいなことは。
そこは自分がわかるところだからサポート範囲内として、
じゃあゼロから始める際にはどこまでを、今回のこのコードレビューをなくした話だったら、
何を積み上げたらコードレビューなくせるところまでいけるのかみたいないう話を盛り込むみたいな。
盛り込む。そうするとそういったやつが広がる。
それが一般化ってことです。
確かにと思いました。
タイトルと発表場所で対象を絞る
ちょっと疑問に思ったのが、切り捨てるとこあるじゃないですか。
金融業界とか医療系とか、その切り捨てる時ってどうします?
タイトルで切り捨てるのか、概要で切り捨てるのか、内容で切り捨てるのか、いろいろあるのかなと思ったんですけど。
一番ベストなのは、タイトルとかってキャッチーで人目に突かせたいところじゃないですか。
そのキャッチーな人は聞いてほしい人だけに刺さるっていうのが一番ベストなんですよ。
この人に聞かせたい人にだけ刺さる。
航空宇宙の人とかはなるべく刺さらないでほしい。
刺さると何が起こるかっていうと炎上するんですよ。
お前エンジニアって言ってるけど、これウェブエンジニアのことだけじゃないかみたいなこと言われるわけですよ。
じゃあ果てまで書かれそうな。
よくあるやつ。
とか言われちゃうんで、それはなるべくタイトルで暗示できるんだったらそれが一番いいんですけど。
難しければやっぱり最初のトップ部分とかで話したりとか。
あとはもう一つあるのは、例えば勉強会とかそのカンファレンスとかによって来る人の層と違うじゃないですか。
例えばスタートアップみたいなところでとか発火層みたいなところに航空宇宙の人とかいるような人はあんま来ない気がするんですよね。
来なそうなイメージですよね。
あるとしてもそのアイディアを見に行ってそれを自分たちの品質水準で作り上げるみたいな感じで。
自分たちの作り方がすでにあってとかっていうところだと思うんで。
この想定聴取である程度絞られてるから前書きとか前置きしなくて大丈夫みたいなケースが結構あると思います。
確かに。
それでいうとコードレビューをなくした話っていうのを持っていく先として、例えばガチガチのテスト業界のカンファレンスではなさそうですよね。
そうですね。
いろんな業界の人いそうですもんね。
テストのカンファレンスになってしまうと。
どちらかというとウェブ系のエンジニアのレビューとか触ってるような人たちがいっぱいいるようなカンファレンスだったら会うかもしれないなと。
そういうところですね。
想定聴取というか、来てくれている人に合わせるというか、そこに対して出す、本当に適したものを出していくっていうのが必要ってことですね。
前回も確か楓も言ったと思うんですけど、なるべく場所に合わせるというよりかはネタに場所を合わせる方がいいと思ってて。
だから例えばヘントクさんのネタがあったんですけど、このネタはどこで発表できるかな。
どこで発表したら刺さる人にだけ刺さるかなみたいなのを考えるっていうのが私の中での順番ですね。
すごい納得感ありますね。
確かに前回も僕言ったんですけど、場所がありきのネタを探してたんですけど。
それが逆で、ネタありきのどこで発表できるかなって。それがさっき言った通り想定聴取の人がいっぱい居そうなところ。
9割ぐらいいる人、場所っていうのが適する場所だよねっていう。
その上でもうすでに想定聴取の中には業界とかでもバッチリ切られている部分があるというところですね。
さっきの話だとタイトルに刺さりやすい人を刺したいタイトルを頑張って入れるのがベストだけど、できない場合はあるよねっていうところだったんですけど。
3割伝達と発表の成功条件
そこはもうセンスの話になってきちゃいますね。
センスというか結構でも試行錯誤のどれだけコストをかけるかっていう話に近いなと思って。
今時そのAIとかだと壁打ちできるじゃないですか。
このタイトルだと誰に刺さると思う?この人から見たらどう思われると思う?みたいなことが壁打ちできるので、それにどれだけ時間をかけたいと思えるかだと思うんですね。
そこなんですね。やっぱりコストとの兼ね合いみたいな。
兼ね合いです。もちろんそれはちゃんと努力して検証もしてユーザイインタビューとかまでもしたらすごく質の高いものができるわけですよ。だけどどこまでやりますかって話ですよね。
確かに。そこまでやってたら仕事なんじゃない?みたいな話になりそうなのでそこまでやらないよね。
今だったら現時点だったらもうAIとの壁打ちができるからコスト安くできるからこそどこまでやるかっていう。
思うに仕事か仕事じゃないかの違いっていうかは私はどれだけその発表を成功させたいかっていうものだと思っていて。
仕事って成功が求められるじゃないですか。だけどホビーとかっていうのは成功の定義がそもそも違うことが多いし自分が楽しいとかっていうのは成功だったりしますからね。
なんだけどその発表、想定聴取を意図した状態に持っていくみたいなそういう目的を持っているんだとしたら私は仕事とやり方が同じになると思ってるんですよ。
確かに。それはその成果をどれだけの角度で出したいかみたいなそういう話だと思ってるので。
行動変容をどれだけさせたいかとかですよね。発表を通じてですよね。
今回の行動レビューをなくした話だったらどれだけ他の会社で行動レビューなくせるかみたいなことがKPIとしてあってそれの発表した後どのぐらいのチームが行動レビューなくしてくれたかな。
測れないとは思いますけどそういう行動できてくれたら嬉しいよねっていう。
そうですね。やるとしたらちょっとこの方法を取り入れてみようと思ったみたいなことをアンケートに書いてもらうのが一番ですね。
その結果うまくいくうまくいかないかわからないけどやってみようと思えたなら大成功だと思いますよ。
確かにそうだなと思いますね。どれだけ響いたかってこと。
私のこれは経験則なんですけど発表したった一つで誰かをなんとかできる状態みたいなのはならないんですよ。絶対ならない。
発表した時点で誰かをなんとかできる状態。
例えばなんとかできるようにする方法みたいなとか例えばテスト技法をマスターする方法みたいなスライドを作ったとします。
テスト技法をマスターする方法なるほどなと思ってこれを例えば30分とかで話したとしましょう。
マスターできた人はいったいどれくらいいるのかっていうとほとんどいないんですよ。
ほぼゼロじゃないかと。
なんでじゃあ発表する意味ないじゃんって話になっちゃうと思うんですけどそうじゃなくて発表の目的って興味を持ってもらうこと以上じゃないんですよ本当に。
あの30分間とか15分間の間でできることっていうのはそのことについて取っ手を作るぐらいのことしかできない。
そこの引き出しを引き出そうと思った時に初めてこういう知識が必要だっていうことに気づいてそれを調べるっていうことができるわけでその取っ手を作ることぐらいしか大体できないんですよね発表って。
だから今のヘンテコさんのこのネタコードレビューの話で言うと多分100%は絶対伝わらない。
コードレビューなくしたいなぁなんか上手く出てきた人がいるらしいなっていうところまでが伝わってその方法はこのスライド見れば分かるんだなぁまでいったらもう大成功ですね。
それが大体狙うべきポイントなのかな個人的な印象ですね。
覚えて帰ってもらうってことですよね。
そういうことです。
ちょっとでも覚えてもらって帰る。
ただ本当に個人的な体感だとスライドは大体30%ぐらいしか伝わらないです本当に。
だから30%ぐらいしか伝わらなかった7割っていうのを後でその発表資料を見ててもらうことで補完したりとかあるいはその人自身が失敗したりとか成功したりとかして補完してもらうっていうことが必要になってくるんでその3割をいかに作れるかっていうのがその私の発表の出来なんだと思ってます。
100あるうちの3割しか伝わらないよねっていう。
そのスライドの中で今用意した話が発表内容が3割しか伝わらないが故にその3割っていうのを角度高くちゃんと出していくみたいなことなんですね。
そう。だから次のアクションに繋がる何かを残すっていうのが一番私は大事だと思ってますよ。3割に伝えるんだったら。
もうマジでその10分20分30分の登壇の中でどれだけ爪痕残せるかみたいなことですね。
今のやつだと爪痕残せるポイントはいくつもあったと思っていて1つはなくして半年以上経って大きな事故なかったって話だと思うんですよ。これはすごくいいと思っててつまり私もそうできるんじゃないかって思わせるわけですね。
これすごくいい材料だと思ってて。そこがすごくいいポイントですよね。だから聴衆は聞く気になってくれる。自分が2役に立ちそうだから。
聞く意味を持たせるってことですね。一番最初の冒頭で。
そう。でその後にどうやってこれを実現したかのハウが来るわけですけどハウは本当に全然伝わらないです。だいたい伝わらないんで。
まあまあまあ聞き流してもらいつつ。
聞き流してもらいつつ。で後でこのハウを見に来るとこの人はこうやってやったんだっていうのを後で見返してもらうみたいな。
そういう風なのが私は理想的な発表だと個人的な定義してますね。
じゃあ伝えたいこととしてコードレビューの話だったらコードレビューなくしたら速度早くなって大きな事故は今のところ無しですよっていうところがとりあえず伝えたいところですと。
なのでコードレビューなくすことをちょっと検討してみてくださいみたいな話だとして発表の内容が。
でその中でハウとしてこういうフローでやっていってますよ。で私はこういう結果でしたあなたのところはちょっとわかんないですけど試してみてくださいみたいないうところが言えてたらいいってこと。
もうだいぶいいと思いますね。
でそれをもうちょっと詳しくだったりとかあとは内容補強しつつ数字も出せるとか出しつつみたいなところなんですかね。
数字で示す効果とイベント選び
そうですね。例えば出す数字だとしたらそのリリースが1年間に1回しかなくて大きな事故がないんだったらそれは開発量が少ないんじゃないかみたいなことをいろいろ招くわけなので。
半年以上っていうよりかは例えば何個プリクラ出荷したかとか何個バージョン上げたかとかそういうのがあるとよりその想像しやすいと。
確かに。1週間のうちに平均して10回ぐらいリリースしてるんだけど今のところ半年以上大きな事故ないですよとかだったらわかりやすい。
わかりやすい。すげーなると思うんですよ。
なるほどそのぐらいだったらできてるんだったらうちでもできそうっていう実感を持ってもらうと。
確かに今話しててこのネタだったらどっかで話せるなと思うようになってきました。ちょっとどっか探してみようかと思います。良い感じのイベントなのか。
イベント探す時ってなかなか難しくて個人的には最初はやっぱり小さめなイベントで話す方が発表自体のフィードバックをもらいやすいっていうのがあって距離が近いですよね。
そうですよね。
だんだん慣れてきたら大きなカンファレンスに出ていくと大きなカンファレンスってフィードバックが実はあんまりもらいにくいんですけどただ反響がすごくある。
つまり見て批判的な意見もいっぱい来るしその肯定的な意見もいっぱい来るっていうのがあってなので大きめなやつとかもだんだん徐々にチャレンジしてもらうってのが結構いいかなと思ってますね。
ただその大きなやつにいきなりルーキーワークみたいなのがあったりする時があるんでそれを使うってのも手ではないんですけど個人的にはルーキーワークでやるよりかはやっぱりもうちょっと近い聴衆に話をして率直な感想をもらっての方が調達は早い気がしますね。
発表を慣れっていうような。
発表を慣れっていう意味では。
確かになんかiOS DCとかルーキーLTとかそういう企画がありましたもんね。
ルーキーワークとか。
アンケート結果の読み方
iOS DCはどうだったかな。
カンファレンスとかによってはアンケートの結果を後でもらえるんですよ後日。
あなたの発表は5点満点中何点でしたかみたいなヒストグラムとかもらえたりするんですけどああいうのもらえるとすごく嬉しいですね。
ああいうのもらえるカンファレンスは私はすごく好きですね。
じゃあその後でもらえるデータ?フィードバックデータみたいなの結構使ってたりする?
使ってます使ってます。今回のやつは刺さらなかったなみたいな。
結構如実に出ます?
だいたい如実に出ます。
2つのパラメーターで私は見るんですけど1つはその評価の分布ですね。
一番評価が良かったとかっていう分布を見るんですけどそれと参加者に対する回答者数割合の2つで見ます。
そもそも回答してくれてないみたいなところだったり。
そもそも回答してくれてないっていうのはマジで何も伝わらなかったってことです。
爪痕残せてないってことですね。
回答数が多ければ多いほど分かったと思ってくれた。
本当に分かってるかどうかなんですよ。
分かったと感じてくれたって人が多いってことなので
まずはその回答者の割合が大事。
その次にその回答者の内訳ですね。
評価が高かったのか評価が低かったのかみたいなのを見るみたいな。
伝わった上で正しくないと思われたら
大体そのアンケートをもらった時に
その分布のピークが真ん中ら辺に行くんですよ。
真ん中に行ったりとか二方化するんですよ。
低い山と高い山が2つができるみたいな感じになったりするんで
それは悪いシグナルですね。
そんな感じです。
なるほど。でっかいところだったらそういうフィードバック方法として帰ってくるけど
ちっちゃいところでも話した後
LTとかで話した後の懇親会とかでフィードバックもらえたり
っていうところがあるから
どっちにしろ話してみるのがいいかもねっていう
そうですね。ただ大きいカンファレンスだとトラックがいくつもあるから
自分と会う人が発表を聞いてくることは限らないんですよね。
それが難しい。
裏番組がありますね。
確かにそれ考えるとかなり難しいですね。
裏にすごい著名な人が発表したりして
全然こっちの部屋誰もいないじゃんって感じになっちゃいますもんね。
それは悲しい。確かに。
そしたら普通にちっちゃいところの方が
よくちゃんと聞いてくれる人っていうのが多いかもしれないですよね。
属性として近しいから。
確かにそれ考えると別に大きいのを頑張る必要性あんまないかなって気がしてきちゃいますね。
何なら同じネタで発表してもいいと思ってるんですよ。
小さいところだったら。
大きいところで何個も同じネタで発表してたら新規性がないみたいになっちゃうと思うんですけど
小さいところだったら参加してる人も少ないし被ることないだろうって言って
出すのも全然構わないと思います。
ちょっとずつ新宿アップデートしながら同じネタ
基本は同じネタで話していくみたいなのもありっちゃう。
じゃあちょっとちっちゃいところを探してみようかなと思うんですけど
今回のこのコードレビューの話だったら
web系のエンジニアが集まるところで
パッと思いつくところは全くないんですけど
そういったところでコンパスとかで探してみるっていう感じになるかなと
そうですね。
昔はIT勉強会カレンダーとかがあって
ありましたね。
あれとかでコンパスに載ってないやつとかもいっぱい出てきてたんですけど
今って何が使えるんだろう?私あんまり詳しくないですね。
前回聞いたところだとXで流れてくるかしないとわからないって言ってましたけど
難しいですよね、この情報収集。
勉強会のプロモーション戦略
多分イベント側も告知超難しくないと思ってるんですけど
難しいっすよ。
難しいですよね。
私はその勉強会の主催もいくつか知ってたことがあるので
プロモーションどうやって打つかとかもだいたいわかるんですけど
コンパスのリンク付きでTwitterXとかに広告を出す
1クリックあたりの値段ってすげえ高いんですよ。
アド、広告枠として出すんですよね。
700円くらいかかるんじゃないかな。
安くても700円くらいかかるんですよ1クリックあたり。
1参加者700円とかかかるんで
すげえ高い。
これでも一番安い本なんですよ。
Facebookとかだと1500円とかかかったりしますけどね。
高っ。
無理じゃんってなるんで
なかなか費用対効果が難しい。
費用対効果というか700円な時点でほぼ赤字ですけどね。
主催側はそれくらいの覚悟を持ってプロモーションしてることが多いんですけど
なんで小さい勉強会とかでもプロモーションとか売ってもっと大きくできないのかみたいな話はあるんですけど
大体できないんですよ。
私がやってたリントナイトとかだとそんな有様だったんで
難しいんですよね。
主催者側も悩ましいところがかなりある。
難しいですね。
多分くにわけさんがやってたイベント主催してた頃って今よりか
今ってアルゴリズムによって人によって表示されるタイムラインが違っちゃってるじゃないですか。
それ故にリツイートしたとしても誰かがリツイートしたとしても現れるとは限らない。
フィードの中に。
これが悪さをしていて届けられないんじゃないのかなと思ってて。
前よりか。
今どうするんだろうなっていう気がすごくしますが。
そうですね。やっぱり方法は2つしかなくて。
1つは発表者の中にインフルエンサーを1人入れるっていうのはすごく効率が良い方法で。
それはそうだ。
インフルエンサーのイメージみたいな人がちょうど被ってるんだったらちょっとお金出してもいいから来てもらって発表してもらうとかっていうのはすごくあるんですね。
その人が例えば自分で発表をここでしてきますみたいにつぶやいてくれたらもうめちゃくちゃ1クリック700円分のやつがばらまかれたみたいな。
例えば1万人フォロワーがいれば1万人に向かって放流されるわけですから。
めちゃくちゃ費用対効果が良いんですよ。
やっぱりそれですね。
インフルエンサーがいるかみたいな。
普通に分かりやすくそれですね。
その次がやっぱりプロモーションになるんですけど。
プロモーションって例えばXとかだとフォローターゲットとかっていうのができて。
この人のフォローしてる人たちにそのプロモーションのツイートを見せるみたいなオプションがあるんですよ。
それとかをうまく設定してあげて例えば有名人のXさんがいたらそのXさんのフォロワーに流すみたいな。
それがうまくその被ってれば被ってるほどクリックしてくれる。
同じ額でクリックしてくれるんでっていう風な感じでしたね。
そうですよね。やっぱりオーディエンスの設定ですよね。Xなどの。
自分も技術書店で本を同人誌に出す時に。
当時はツイッターでしたけど。
ツイッターの広告でこのサークルで本出しますみたいな言う時に
技術書店のオーガナイザーの羊さんをフォローしている人に対してツイッターの広告を出すっていうのをやってたんで。
全く同じ発想なのかなって。
そうですね。でもこれ実は一番強いのが羊さん自身にツイートしてもらうんですよ。
それはそうですね。
そこをなんとかしてツイートしてもらうためのあれこれを考えるっていうのが主催者側の考えなわけですね。
そこをちょっと戦略練ってどうしたらつぶやいてもらえるのかみたいな。
ただそのつぶやきっていうのもその人の資産なんですよね。
だからフォロワーに向けてプロモーションばっかり受けてる人ってやっぱり信頼を失っていくわけじゃないですか。
この人金もらえば何でもツイートするなってなっちゃうわけですから。
だからそこは相手のツイートしてもいいなって思える内容にしなきゃいけないんですよ。
そこが難しいところで。
メリットを持たせる必要がある。
なので発表してもらうっていうのはちょうどいいんですよね。
自分自身の発表をなるべく広く知らしめたいっていうニーズが元からありますから
そのニーズに乗ってついでにイベントのこともツイートしてもらえるとってなるわけですね。
確かに。
コミュニティ告知と一般化のまとめ
ちょっとあと聞いてて思ったのがもう一個あるなと思うのが
既存のコミュニティに告知するっていうのなんですかね。
例えば国明さんの場合だとBMJPのコミュニティにも属してるかなと思うんですけど
BMJPに対して何か告知するみたいなのもあるのかなと。
もちろんありますね。
なんならこのクワラジも毎回BMJPの自分の文法に流してたりしますからね。
結構あります。効果がありますね。
スラックでも技術コミュニティでBMJPとかだと結構ギークな人たちが集まっていたりするし
テスティングコミュニティみたいなのがあるんですけど
テスティングコミュニティにはテスターの人たちがどっちかって集まってたりみたいなのがあって
そこらへんはうまく適切に選んであげると刺さらない刺さらないがやっぱり出てきますね。
やっぱり既存のコミュニティ
いわゆる今だとインターネットって言ってしまうと
ここ10年くらいX、ツイッター、フェイスブック
そういうSNSが大部分みたいな感じになっちゃってますけど
やっぱりそういうクローズドなコミュニティのところでも
自分が属していっぱい人がいるところに流していくっていうのは良いことではありません。
それなりに大事ですね。
そういう活動も続けていかないと難しそうだよねっていうと
ちょっと何故かいつの間にかイベント主催者側の話になって
確かにおかしい
謎の話になってきましたが
結構いい時間になったのでここらへんでまとめたいなと思うんですけど
今回みたいにですねコードレビューをなくした話みたいなところの一般化
するとしたら業界を切り捨てるというか
この業界の人たちには刺さるように
この業界の人たちは対象外にしてみたいなところと
あとは新規かどうか
新規でプロジェクトを始めるか
それとも既存のプロジェクトのまま
もう既に資産があるみたいなところ
コードベースの資産があるみたいなところをちゃんとサポートするのか
それとも新規もサポートするのか
そういうサポート度合いの範囲っていうのをちゃんと決めて
あとはそのネタに合わせたイベントをちゃんと探して
ちっちゃいところからちょっとずつ発表していくみたいないうのが
良さそうというところがまとまった感じなんですけど
じゃあちょっと今回ここまでにしたいなと思うんですけど
今回みたいにですねこういう感じで
コードレビューをなくした話を一般化するとどうなっていくのか
今後ちょっとずつやっていけたらなと思いつつ
もしこれをお聞きの人がですね
こういう例ってどうやったら登壇のネタになるのか
あとは一般化しやすいのかみたいなところ
もしネタがある人がいたら是非コメントとか
あとは別に僕自身に直接言ってくれるでもいいですし
栗上さん自身に言ってくれるでもいいんですけど
何かあったら是非教えていただければ
それをネタにエピソードとして一本撮りたいなと思うので
よろしくお願いします
ということで今回ここまでにしたいなと思います
もっと詳しく教えてください
ラジオ略してくわラジではスーパーエンジニアである
栗上さんに一般エンジニアであるヘントコが
技術的な質問をしていく番組です
今後もいろんなことさっき言った通り
聞いていけたらなと思いますので
お聞きのプラットフォームで高評価やフォローもお願いします
感想なども是非お待ちしております
それでは今回もありがとうございました