00:05
ぼく、こうか好きなんですけど。
こうかって、漢字で書くとどのこうかですか?
学校の歌です。
ああ、学校の歌。
僕、小学校はね、Ayakaさん何回か話したと思うんですけど、統合したんですよ。
ああ、言ってましたね。
もともとね、ちっちゃい4つ、もう1校では結構少なくなっちゃって、人数が。
で、成り立たなくなっちゃうぐらいのサイズの4つの小学校が、1つに合併したんですね、僕が在学中に。
6年の間にってことですか?
6年の間には結局、最後まで合併はしなくて。
4から2になったんです。
を経験した。
僕の妹は、4から2、2から1をすべて経験した。
すごい。
引っ越してないんだけど、3回小学校、2回変わるっていうことになってて、そういうさなかにいたんですよね。
なので、4つ、それぞれ効果があると。
別の歌があるわけですね。
で、統合するときに、最終的に1つにするわけですよ。
でも、途中で。
トーナメントみたいな。
そうそう、トーナメントみて勝ち残りではなくて、1個新しい効果を作ったんですね。
そもそも効果が新しく誕生するって珍しいじゃないですか。
学校はそのままに。
学校が新設されるっていうのは、たぶん、現代の日本でそんなにないから、新しく生まれる効果の数ってすごく少ないわけですね。
そうですね。でも、私が行ってた小学校、実は結構新しくて。
そうなんだ。
創立10年ぐらいのとこだったから。
あ、じゃあ結構新設校だったんですね。
でも、なんか全体的に減っていく一方だったんですね。
そうですね。
で、その中で1つ生まれたと。
てか問題は、4つを2つにして、2つを1つにするっていう。
だから、もう決まってる状態で効果を作らなきゃいけなかった。
そうなんですね。
で、その2つのうちの1つ、なんとか北小学校となんとか南小学校ができて、で、その2つを統合して、なんとか小学校にするみたいな感じ。
北VS南よ。
だったんですけど、その効果を3年しか存続しない学校なんですよ。北、南は。
え、作るのかと。
で、結局作らなかったらしくて、なんで効果かぶってるんですよね。
あ、そうなんだ。
この学校の効果は、なんとか北小学校だったんですけど、なんとか南も、なんか後から聞いたら同じだったっていうのを後から知ったんですよね。
まあ、そういうぐらいのデザインがあったんですね。
お前のとこも一緒じゃんみたいな。小学生にとってはそんな事情知らないから、自分の効果というアイデンティティ、学校のアイデンティティが同じみたいな。
そっか、せつないね。
お前もこれなの?っていう。
大人になればわかるけど、子供にとってはかなりせつない。
しかも、普通は、結構ご当地要素に盛り込むと思うんですね。
03:03
確かに。
川が、山が見守りとか、あと歴史とかね、偉い人、偉人が出たような学校だったら、その名前が入ってたりとか。
名前は入んないんじゃない?効果。
まあ、でもね、ご当地要素はやっぱありますよね。学校の立地とかを反映した歌詞になる気がします。
あと、東京の西の方とか、開拓の歴史とかが効果に入ってるらしくて、すごいと。
でも、うちの効果、すごいジェネリックなんですね。よく思い出した。
まあ、統合できるようにしてある。
なぜなら、ご当地ものを入れすぎてしまうと、その2つの番号に使えないからっていうのがね、後からわかってですね。
はっ!気づいた次に、せつなかったですね。
せつないね。大人の都合だね。
なんか、光を浴びて歌おうとか、生きる喜びとか、
そういう、ほんとにどの学校でもこれ使えるんじゃね?っていう歌詞しかなくて。
作詞家の人、がんばったんじゃないかな。
がんばったんですね。オーダーがまずすごいですからね。
まず2個に使って、その後1個になって、それもずっと使い続けられます。
そういうね。
え、でも、なんとか小学校ってだいたい効果入ってるじゃないですか。そこどうしたんですか?
あのね、それはね、小学校としか言ってないんですよね。
これもう気づいた時、正義名詞だよ。
なんとか分もなくて、小学校で終わります。
嘘だろ。
こういう名詞、たぶんゼロじゃないかな。
え、だって、その効果ってさ、なんとか小学校のなんとかが入って効果じゃん。
それが入ってないのは効果じゃないよ。
小学校ならなんでも使えますからね、その効果。
やば。
ジェネリック小学校じゃん。
ジェネリック高校なんですよ、うちの小学校。
確かにお金もぐらいあってもよかった気がする。
なんか晴れとかそういうのあったから、ちょっとお金もよさやや入ってる。
なるほどね、そういうこう地域に縛られない感じのキーワードは。
すごく抽象的な入れ方ですよね。
なんなら使いまわしてるんじゃないかなと思いますけどね。
え、どういうことですか?他の学校でも。
そういうオーダーあるじゃないですか。
なんか安く効果が欲しいんだよ。
やば。
多分、効果フリー素材とかで検索するんですよ、きっと。
いやいやいや、当時はそうでもなかったんじゃないですか?フリー素材、今ならもしかしたらあるかもしれない。
今ならあるかもしれない。
でも、小学校の数だけ効果があると、そういうざっくりした効果が生まれるんだなっていう。
ね、おもしろいですね。
というわけで、今回は何の話ですかね?
いや、これ何の話だ?
これはこう、枕なんですけど、今回のテーマは全然関係ない。
ね、今後悔じゃないですね。
何々ってできますかね?っていう話をしたいと思います。
06:01
プログラマーにそういうふうにできますかね?って質問したときの話ですね。
これきっかけとなったツイートがあって、なんかちょっと僕の周りではバズってたというか、話題になってたんですけど、あやかさんも見ました?
見ました、見ました。
もともとのツイートは、プログラマーにすごく気を使ってしまうと。
で、なぜかというと、何々ってできますかね?って質問したときに、しばらくして、実装しましたと。
実装してから返事が返ってくることが多いと。
で、こっちとしては、多分本人はプログラマーじゃないので、可能かどうかとか、実装するときの懸念点とか、コストどのくらいかかるの?みたいなのを確認してから、実際にお願いするか検討したり。
で、それから依頼したかったりするんで、質問のときに、いちいちまだ取り掛からないで大丈夫なんで、ひとまず音導管だけ今聞きたいんですと、入れる必要があるのが気を使うと。
で、よくある問題としては、なんかちょっと確認するだけのつもりだったのに、すぐさま実装されちゃうと、こっちの要望とか詳しい意図とかが伝わってない状態で作ることになっちゃうんで、結局やり直してもらう範囲になっちゃって、お互いに損ですよね。
っていうので、ちょっと困ったなみたいな話を書いていて、それに対していろんな意見があったんですね。
一番多かったのはエンジニアの人から、検討するのと実装するのがそんなにコストは変わらないと、その人にとっては。
っていう場合があるから、その人はそれが一番手っ取り早いと思って、試してみた。試しに作ってみた。
結果作れちゃったので、それを共有しただけだと思いますよみたいな話が一番多かったんですけど、結構考えされる話だなというか、どっちの気持ちも分かるなと思ったんですね。
そうですね。どっちの気持ちも分かります。
そういう単純な話だけではないだろうみたいなのもあるし、関係性とかも関与してくるなと思うし、
で、赤田さんもなんかベンチャー企業、ITのベンチャー企業で働いたこともあるし、
自分でプロダクトを、詳細マップをエンジニアの人と組んで、フリーランスの人と一緒に仕事したこともあるということで、
お互いちょっと違う立場から、この問題について、何々ってできますかね問題について言いたいのがあるんじゃないかなと思って。
そうですね。
例えば、この何々ってできますかねの例としては、ユーザーインターフェースの文脈で言うと、
この表示、例えばここをタップしたら、Aっていう機能が表示できるようにしてくれます。
これってできますかねみたいな。
今は押すとBが出てくるんだけど、Aにしてもいいかなと思っててみたいな。
で、別に今すぐ変えてほしいわけじゃないけど、ちょっとこれが可能か知りたいみたいな時ってありますよね。
09:04
そうですね。
で、それが多くはエンジニアにとっては、できるかどうかわかんないから、即答えられないわけですね。
即答えられる場合には当然この問題は発生しないわけですよ。
で、ちょっと持ち帰って検討しますみたいなのがきっかけになることが多いですね、この問題に。
確かに確かに。
で、おそらくはこの人が念頭に置いている例、もともとのツイートの人の例で言うと、
多分エンジニアの人は、何だろう、やって、これができるんだったらできるけど、
これ確かめるには実際ちょっとコードを書いてみるしかないなと思ってコードを書いたんですよね。
で、結局できたと。
で、できたらもう実装できたってことなので、じゃあ実装できましたってこんな感じですけどどうですかっていうのを一段飛ばして報告することになるわけですね。
で、その人にとって途中段階というか、本当はできてるのに可能ですみたいな、このぐらいコストはかかりますみたいな、
こうなった時に、それは不誠実だし、なんかもう作っちゃったのに、こんなにコストはかかるんだったらいらないですねって言われると、
単純にこうお互いにとって損じゃないですか、そういうコスト。
だから、できましたって検討してる途中にできちゃいましたっていう意味で言ってるんだと思うんですよ。
でもなんかこう難しいですね、その時の最前提はどうだったのか。
結局、検討しないとわからないので、検討と実装ほぼ同コストですよっていうのが正直な答えですよね。
ただ、そう言われると、依頼する側はどう依頼したらいいのかわからないというか、見積もれないからどれぐらい予算とか期間を用意したらいいのかがわからないっていう状態になってしまって、
なんか結構これはなんていうか、どっちが悪いとも言い切れないみたいなとこはありますよね。
なんかエンジニア側にどこまで任されているかっていうのに結構関係するかなと思っていて、
なんか言われたことをやる感じになってそうな雰囲気はそのツイートから伝わってきてはいるけど、
言われたことっていうよりは結構コースを見積もりたいっていうのをすごく感じた。
コースを見積もってから始めたいみたいな。
割とウォーターフォールというか、なんか事前にカチカチ決めて、死を切って、スキジを切ってから始めるみたいな。
そういう雰囲気を感じますよね。
なんか自分だったら、こういう人にどう言うかなっていうのを考えたんですけど、
結局、検討に1週間かかって、検討ができたら実装は1日だと思いますみたいな。
相手の求めていることに答えつつ、温度感を伝えるみたいなことにならざるを得ないかなという感じはしますね。
12:10
結局、今までやったことある幅のことしか、どれぐらいかかるって見積もりができないっていうのはありますね。
確かに、確かに。
で、なんかあんまりそういう、見積もりに時間が最もかかるっていうことがあんまり想定されない職種の人からだと、なんで?みたいな風になるのかもしれない。
じゃあ、私はどうしたらいいの?って思うのかなっていう気がします。
プランナー側としては、1週間検討にかかって、やるのは1日です。
じゃあ、その1週間の検討は、とりあえずもう考数として取らなきゃいけないんだみたいな感じになるのかな?
でも、なんかこう、なんだろう、実際にその機能が1週間の価値、検討してできないかもしれないけど、1週間かける価値があるのかどうかっていうのを、
結局その人が判断しきれなかったりもしますよね。
そうですね。
その企画側というか、プログラマーじゃない人の側が、そこまでのリスクは取れないみたいな。
で、結局、リスクをある週、できますかね?っていう質問で、やや押しつけてるようなところもありますよね。
確実性を100%の状態にしてから、企画をスケジュールを進めたいみたいな、
欲求があって、そのリスク部分を、なんだろう、ボールとしてそのまま渡しているっていう。
なるほど。結局、そこのバッファーを用意するのが企画側の仕事であるっていう。
企画側の仕事であるかどうかわからないけど、どっちかをやらなきゃいけない仕事で、
この人は、できてますかね?って即答してほしい、そのプランを即答してほしいっていうのは、
結果的にはそれを担う意思はないよっていうことを示してます。
いや、わからないです。できますかね?っていうのは、やったことありますかね?とか、
今までの経験からさっと見積もれますかね?っていうのが、たぶん、事前の最初の質問として本来入るべきで、
で、その答えとして、いや、なんかこれやったことないんで、検討して、検討と実装はほぼ同時になるんで、
アンサーできません。ある意味、今アンサーできませんっていう回答になるか、
これやったことあるんで、1週間ぐらいでできますよ。とか、そういう感じのどっちかが欲しいのかなっていう感じがしますかね。
そもそも、何人ってできますか?が、悪い問いっていうことですね。
そのだけで完結してない。
そうですね。
なんか、実装、これって前話したXY問題だなと思って、XY問題って、
15:05
Aをやりたいんですけど、って質問しちゃうけど、実際にはXをやるための手段としてAをやろうとしてる人が、
Aってどうやってできますか?って話しちゃう。
でも結局やりたいことはXで、XのためにはBっていう方法のほうがよかったりするけど、
Aについて聞いちゃうから、質問答える側からは、それについて一生懸命、なんでこれやろうとしてるんだろうって思いながら答えるけど、
実際には本当はXをやりたくてっていうことを教えてくれれば、それだったらAやる必要ないですよっていうことになってしまう。
そういう問題の、よくあるミスというか、問題のことだったんですけど、
Aってできますか?っていうのも、結局何のためにAってできるかどうかっていうことを知りたいのかってのはわかんないわけですね、それだけだと。
で、この人の場合は、実はAってできますか?って質問の裏には、Aをやるかどうか検討したいので、Aができるかどうかを聞いている。
けども、そのエンジニアの人は、なんか可能ならやりたい、みたいなことに解釈したんじゃないかなと思います。
そうですね。
で、その場合だったら、実装しましたっていうのはある一種最前提というか、Aが可能だったらAって言うんですけど、可能ですか?って聞かれたら、
いや、すぐできるんで、できちゃいましたみたいなのはもういいじゃないですか。
でも、そう、Xが実は共有できてなかったっていうことではありますね。
うん、確かに。
そうですね、そういう質問側の問題としては、最終目的みたいなのが伝わってないっていう、
なんか、できますかね?だけでは伝わらないっていうのは、それはそうかなっていう感じがしますね。
まず、今これが検討フェーズなのか、もうやることは決まっているフェーズなのかっていうのが、どれぐらい共有されているのかっていうのはありますよね。
ちなみに、今なんかエンジニアっていう、アプリとか作る会社が舞台という設定でしたけど、これは研究とかでもある話なんですかね?
まあ、ありますね。
まあ、でも、何々ってできるって聞かれて、結局やってみますか、結局やってうまくいくかはやってみないとわかんないからやってみますってなる。
で、答えるってことですね。
やってみるか、いや、それはやる必要がないんじゃないですか?の2択がアンサーする時点で比較的。
だからまあ、その時点で、そのしゃべってる会話が検討してる状態だっていうふうに、私が感じてるからそうなのかもしれない。
まあ、例えば、私がPIと何々ってできますかね?みたいな会話をしたとしたら、それはできるかできないか、やるべきかやるべきじゃないか、私が判断していいと思ってるから。
18:06
だから私は、やる必要があるならやってみます。
まあ、できるかわかんないですけど。
やる必要がないと思ったらやる必要はないと思います。の2択なんですよ。
目的を共有してて、自分がハンドルしてるからそこはあまり変にならないんだけど、
それがもうちょっと、まあ、ラボによっては複数人で同じプロジェクトをやってたり、オーナーが自分じゃない必ずしもそうじゃない場合の方が、まあ、もしかしたら多いかもしれないですね。
その研究テーマはこの人のものだけじゃないとかっていうことですね。
だからそのプロジェクトの方向性を決めるのが自分じゃない場合に、誰々に出てきますかねって言うと、なんか同じ問題は起こりうるなっていう感じはします。
そうですね。
なんか多分、エンジニアの会社でもこういうことが起こらない場合って多分あって、それはすごく少人数のベンチャーとかで、もう全員一心同体みたいな。
そのプロジェクトが成功すればみんな嬉しいし、そうじゃなければ、例えばアプリを作るとしてアプリが売れなければもう全員解散みたいな。
そういう場合ってあんまり起こらない問題。
自社プロダクトでこういうことは起こりづらいんじゃないかっていうことですかね。
あとは、結局その自社プロジェクトだったとしても、なんか実質的には時給に近い形というか、こう、何だろう、こう、コースをつけてやってればお金をもらえるし、そのプロジェクトは存続するし、みたいな状態も結構あるとは思ってて、
それはなんか自社かどうか、自社か自宅かみたいな話ではないとは思うんですね。
なんかすごく極端に言えば、時給で働いてる、なんかやってる感があれば別に、こう、何だろう、まあ、時給で働いてるイコールそうじゃないんですけど、こう、手を動かすことに報酬は比例するっていう働き方と、
なんかもう完全成果報酬みたいな、個人でアプリ作ってるとか、こう、ベンチャーやってるみたいな、そういうもう成果がイコール報酬みたいなものがあったとして、
じゃあ、なんか会社でやってるプロダクトみたいな、大企業でやってるプロダクトみたいのがどっちに近いかっていうのは、結構その報酬の体系とか、チームのあり方とかによりそうだなという気がしました。
やっぱりその最初に話した通り、目的がどれぐらい共有されてるかっていうところ次第なのかなっていうふうには思いましたね。
だから、もうその目的と自分の働いている、その、何だろう、働いてこれをやりたいっていうのがあまり一致しないような状態だったりとかすると、なんかこう、何だろう、まあ、できるかって聞かれて、まあ、こう、あ、それはつまりやってってことなのかなみたいに思ってしまうっていうのはすごいなんか納得できるかな。
21:08
まあ、実際そうの場合が多いですかね。なんか、それで事前分布としてその人の中にできちゃったっていうのは、どうせやらされるみたいな。
そうそうそうそう。できるか聞かれたってことは、つまりやらなきゃいけないんだ。なんでできるかわかんないから、とりあえずやってみるかできちゃったっていうパターンですよね。
だから、なんか、まあ、それはやっぱり質問の仕方が、別にどっちが悪いってもんでもないけど、質問の仕方でもちょっと改善できるところやっぱあるのかなって思いました。
あと思ったのは、関係性の問題ってちょろっと話したんですけど、なんかその信頼関係がどのぐらいあるかによって答え変わると思うんですね。
見積もり、どのぐらいかかりますかの見積もりも結構似たようなことは言えると思っていて、なんか、技術的背景とか目的とかを共有している人だと、より正確な見積もり。
例えばなんか、1週間かかることに対して、かかるなーって自分で思ってることに対して1週間って言えるんだけど、そうじゃないというか、
例えば、こういう外的要因とか、こういう予期しない問題で遅れちゃいましたみたいなことを分かってくれなさそうなとか、なんでこの人はこれやりたいのか分かってない相手に対しては結構その係数をかけるというか、長めに出しちゃうみたいな。
相手が自分の手の動かし方とか、どういうところで詰まる、どういうところにリスクがある、そのリスクの分布ってどういう形になっているのかっていうのは、分かってる人とそうじゃない人っていう、そういう感じで、それを信頼感って呼ぶのかどうかわかんないですけど、でも結構そういうのはあるんじゃないかなと思いました。
もともとのオリジナルの質問は何々言っていきますかねっていうことだったんですけど、なんか正直な答えとしては、例えば9割いけると思いますみたいなことだったら即レスできるわけですね。
でも結局9割じゃ困るって言われそうだから、結局100%にしないとこの人は求めている答えにならないんだって思って、10割にしてから、つまり実装できることを確認してから答えたっていうのがこのツイートの中の人の、エンジニア側の人の行動だったわけですけど、
なんかその9割感を共有できる相手だったら、その不幸は起こらなかったよなと思って、でもその9割感ってなかなか伝わりづらい様子ではありますよね、まあ実際には9割かどうか全然限らないし。
まあでもなんかその辺含めてコミュニケーションがしたいっていうのが、たぶんそのツイート元の人の考えでもあるのかなって思うんですよね、なんかこうまあそういう信頼関係を築く意味でも何とかってできるんだろうかっていうことに関して、こうなんだろう、まあ懸念点含め教えてほしいというか、別に100%できるかどうかを必ずしもたぶん聞きたいわけじゃないのかなと思っていて、
24:17
その何割ぐらいの感覚なのかとか、どういうことをじゃあその例えば1割、その9割いける時の1割の懸念点が何なのかとか、まあそういうことを本来は言ってくれると思ってるけど、でもそのなんだろう、実際には言ってくれないみたいな、まあそこはミスコミュニケーションって感じがしますけど。
まあその実際のリスク分布って結構複雑な形をしてますからね、その関数は。
なんかその1割感を伝えてもらえるような関係にみんななりたいっていうか、なんか例えば僕がデザイナーの人と働く時とか、で違う職能を持ってる人と働く時とかには、なんかいやなんかこれはできそうだけど、この1割あるっていう、その1割を教えてもらえる関係になりたいなと思うんですよね。
それはもうこの人も思ってるわけですよ、ツイートの人も。
なんかこうどういう条件なんだろうなっていうことをふと思いました。
まあでもやっぱりなんかどうなんですかね、基本的になんかお互い理不尽なことを言わないとか、まあその外的要因で色々そのうまくいかなかったりとか、
なんかそのリスク部分をお互い許容するみたいなことができてるとおそらくよくて、なんかその辺がもしかしたらこのそのツイート元の人の会社とかでは、まあ企画が結構その辺のコース管理とか全体的にマネジメント的な立場にいて、
管理される側としてプログラマーの人がいるとすると、まあなんかそこがこうなんだろう、まあなかなか対等な感じで話せなくて、そのリスク感を一緒に共有したりとか、風にならなかったのかなっていうふうにはちょっと思いました。
なんかそのできなかった時のリスクを追いますよっていう姿勢が大事っていうのはありますよね。
ミスをこっちでカバーしますよみたいな感じがないと、やっぱりなんかこうもう100%にしちゃうっていう風になっちゃうのかなっていう感じがします。
あとまあ9割、よくあるのは9割やれますを10割やれますと報告、上に報告する人とかがいると、その人にはもう信頼を失ってしまうというか。
約束を守んないとかとはまた別のタイプの信頼ですよね。
そうですね。
なんかこう、あ、そうだったらもう10割にしてから持ってくしかないわってなっちゃうんで、なんかそこもあるかな。
27:00
9割は9割のまま扱える人が結局じゃないとダメなんだなという感じもしますね。
まあそれはなんかその1割のリスク要因を自分側で処理できるというか、そういうなんだろう、そういう人っていうことなのかもしれないですけど。
でもやっぱりそれってなんか究極的には責任を取る気があるみたいなところ、責任感の問題なのかなっていう感じがしますよね。
あとなんかそれを見込んだ計画を立てるっていう意味での責任感というか、オーナーシップって言ったほうがいいかもしれない。
そうですね、確かに。
かなと思いますね。
なんか実際そのどういうふうにプロダクトを作っているのかって、大企業の中では職能がどんなふうに分かれているのかなっていうのを思ったんですけど、
エンジニアの人でも結構プロダクトマネージャーっぽく、自分のプロダクトとしてやってる人もいるし、
一方でどっちかというと、計画っぽい職の人がいて、手を動かして実際にコードを書く人がいるみたいな、そこは分かれている会社もあるし、結構いろいろあると思うんですけど。
そうですね。なんか大きな、例えばGoogle、FacebookとかAppleとかITの会社の事例で言うと、大体の場合はエンジニアっていう仕事とプロダクトマネージャーっていう仕事があって、
エンジニアは実際のプロダクトを作っていく。で、コードを書いていく。で、プロダクトマネージャーは何が必要なのか、何を作るのかっていう意思決定をしていくっていうふうに言われていて、
で、実際その能力を見て採用されるんですけど、結構その境界線はチームにもよるし、うちの僕が働いているチームとかプロダクトマネージャーが慢性的に不足しているので、
エンジニアが実際その役をやらなきゃいけなかったりして、結局型書きとこの役割、実際の役割っていうのは切り離して考えた方がいいんだなという気はだんだんわかってきました。
実際やっぱプロダクトマネージャーその意思決定、やるかやらないか決めるっていう役割を、もう普通に明示的に期待されるっていうことも結構ありますし、
エンジニアってことですね。
実際これやらなきゃいけないの、やったほうがいいのみたいなのって聞かれて、え、それはなんかもともとは全然違う人、そのプロダクトマネージャーみたいな人がやってきてそれを解決してくれるもんだと思ってたんですけど、
これもしかしたら俺に聞かれているってなって、でもなんかもうそういうもんなんだ。
てかこの問題を一番よくわかっていて、それに一番いい答えを出せるのは自分な場合が結構あるなって。
30:05
いやーでもやっぱりそれはエンジニアが多い会社だから起こってることで、逆に私は日本の典型的なSEの会社だと、むしろプロダクトマネージャーというか、その文系SEってよく言われるあれとしてありますけど、
全然コードを書かないけど仕様書を書く人たちが結構いっぱいいて、むしろエンジニアの方が不足してるみたいなイメージがあったんですけど、実際のところどうなんですかね。
いやーでもそれはあり得る話かなと思いました。僕は日系大企業の話っていうのは直接は知らないし、働いたことはなくて、
自分は経験したことあるのは日系のベンチャーと、日系のいわゆる文系の企業と一緒に働く業務委託みたいなのと、あと外資の大企業ってだけなんで、そこのパートについては知見はそんなないんですけど、
でもなんかイメージはそういう感じはありますね。
そうですね。
結構そのプロダクトマネージャーの方が足りないってことはあんまり起こってない、逆がすごく多いっていうふうなことは聞こえてはきますよね。
まあまあいずれにせよ、なんかこう肩書きと役割っていうのは結構切り離して考えるべきなんじゃないかなと思っていて、
なんかでも僕この考え方はある本を読んで結構影響されたところがあって、
なんて人だったかな、ビーニングギークっていう、ギークであり続けるための戦略、キャリア戦略っていう名前かな。
マイケルロップっていう人が書いたみたいです。
この本は結構なんか面白くて、キャリア戦略、エンジニアとして生き続けるために、例えばマネージャーとどうやっていけばいいかとか、
自分がマネージャーになるって聞かれたらどういうことを考えるんですか?
なんかよくね、話題になってますよね、ずっとコード書いてたい人と、マネージャーに上がらないと出世しない文化が合わないんじゃないかみたいな。
そういうのはやっぱ技術書とかには書いてないんで、リアルの話。
特にシリコンバレーの会社においてどうなのかっていう、ある種ローカルな話がある。
日系のソフトウェア系の会社で働いている人全てに適用できる話ではおそらくないとは思うんですけど、少なくとも僕にとっては。
日系の会社でもそういうやり方、シリコンバレーのやり方とか、例えばその仕事の肩書きの名前とかを取り入れてしている会社には、
で働いている人にはすごく良い本だなと思っていて、その中で結構肩書きと実際の役割は違うけど、
プロダクトマネージャーがプロダクトマネジメントをするし、その人たちがそのことをやってはいけないと思われているみたいなことが言われていて、
で、なんか全然違う名前で呼んだらいいんじゃないかみたいな提案をして、
33:04
で実際に彼がやった分類、役割の分類、肩書きじゃなくて役割の分類っていうのは、
ビット、フィーチャー、トゥルースっていう、
初めて聞いた。
ビットっていうのは、ビット、機能、真実っていうことですね、日本で言うと。
ビットっていうのは、1ビット、2ビットの。
で、ビットっていうのは実際の開発をする役割。
で、この役割を持っている人の特徴としては、真夜中になんか問題があった時に電話をかかってくるとか、
この人が3級とか4級とかで休むと開発は止まるとか、
で、一番典型的なのはエンジニアチームのリーダーだと。
でも、例えば名ばかりリーダーだったりして、実際に電話を受ける人は別のこともある。
ってなった時に、ビットの役割はエンジニアリーダーではなくてその人だよと言ってるわけですね。
で、その人の、もしかしたらその人の肩書きがエンジニアじゃない場合もあると。
その会社にいないとかね、下請けの人が実際やってるとか。
あれですね、これ逃げ恥の平政さんみたいなイメージ。
そうなんですか。
平政さんは夜中に電話かかってくるタイプ?
というか、彼が休むと開発が止まっちゃうみたいなタイプの人で、
実質的に、別に肩書きがすごい偉いとかではなかった気がするんですけど、
でも、開発のみんなが困ってるところを助けてあげたりとかして、
彼がいないと成り立たないというか、バグ取りとかもやってくれるみたいな感じの、
クオリティのゲートキーパーとかをやってる感じの人です。
なるほどね。
まあ、やっぱりエンジニアはみんな自分がビットだと思いたいっていう性質あるので、
そこは平政さんの語りを信じていいのかってわからない。
いや、まあそれは…
物語的にはね。
なんていうか、物語でそういう見せ方がされてたってだけで。
まあ、でもなんか非常に実感がある定義だなとは思いました。
いますよね、こういう人ね。
いるし、そんなに多くないというか、実はエンジニアが複数いるチームでも、
あの人だなって、なんとなく思い浮かぶような言い方ですね。
確かに。
この言い方は。
確かに。
で、次がフィーチャー、機能ですね。
この役割は、プロダクトの内容を決める役割で、
一番この作ってるもの、アプリだったりとか、
ウェブサイトだったりとか、事業だったりとか、
で、それへの要求が多くて、
で、それの要求を強固かつ優弁に語る人と。
で、これ結構プロダクトマネージャー、
プロダクトマネージャーってそもそも結構多分外資っぽい呼び方で、
僕が知ってる日本のIT企業だと、
プロジェクトマネージャーって人がいたりとか、
プロジェクトマネージャーと別に企画って人がいたりとか、
結構このフィーチャーって、
かなり誰がやってるのかって、
36:01
プロジェクトによってバラバラだと思うんですね。
あやかさんの見たことあるところは、
例えば、Cサインマップはあやかさんがフィーチャーだったわけですけど。
私と山下先生かな。
でも一番要求が具体的だったのは、あやかさんじゃないですかね。
私ですかね。
いや、私はどっちかというと、この3つだとトゥルースだったかなっていう感じがします。
フィーチャーとトゥルースの間みたいな感じかな。
他の経験してきた会社とかだと、
どういう名前の肩書きの人がやってました?
いや、でもやっぱりプロジェクト、
プロダクトマネージャーっていう職名に最終的にはなったんですけど、
でも結局エンジニアの人が移ってる場合が多かったかな。
エンジニアの人がコードを書くより、
よりプロダクトよりになってて、みたいな。
エンジニアリングマネージャーみたいな感じになってて、みたいな感じかな、そういう。
あとは、そのキュアアップにいたときとかは、
お医者さんがここに入ることが結構多かったですね。
ユーザーに近い人。
プロダクトの内容を決めるというか、
どういうものを表示するかとかは、
医学的なエビデンスに基づいて作るから、
そういう意味でそこを決められるのは、
逆に言うと医学的な専門を持ってる人しかいない。
例えばNBA持ってますみたいなプロダクトマネージャーが来ても、
そこに関しては要求はできないから、
そういう実際の現場に近い人がこの役割を持ってたってことですね。
名前としてはプロダクトマネージャーだけど、
プロダクトの内容に専門性を持ってる人とか、
それは結構特殊なケースですよね。
アプリの内容とかに専門性がある場合は、
そういうことになることもあるかもしれない。
なるほどね。
僕が知ってるというかイメージできる例で、
なんか結構あるなと思うのは、
この役割を知っている人はチームにいない場合って結構ある。
ありそう。
なんとか匿名チームみたいな。
ありそう。
トップダウンの誰とかさん案件みたいな感じで、
役員の名前が入るやつでしょ。
そういうやつが、ちょっと面白いことやりたいんだよね、
息のいい新人連れてきてみたいな、そういうパターン。
あるある。
心当たりがあるような、
てかその新人だったことがあるような気がしなくもなんですけど。
だったり、役員とかっていう結構のはよくある。
でもなんか最悪の場合は、
そもそもこれがいないっていう人。
まあそうですね。
これが一番最悪ってかなんか、
要するに舵取ってくれる人がいないというか、
みんななんか作らなきゃいけないけど、
こうなんだろう、
こういう要求、こういうプロダクションにすべきだっていう、
強い要求を持ってる人がいないというか、
39:00
結局それってなんかもう責任の押し付け合いみたいになってるみたいな。
予算があるからやりましょうっていうやつですね。
前年度この予算確保されてるからやりましょう。
いや、あるな。
ありますよね。
いや、なんか最悪ここいないんだよな、この人。
誰も欲しくないものを作ってるっていう場合にはいないってことなのか。
プロダクトのない。
そうですね。
だから少なくともこの人が絶対この機能が必要だと思ってやるような、
具体的な人がいない場合って結構ある気がしますね。
怖い話だ。
怖い話だ。
まだ3つのうち2つしか言ってないけど、結構無限に怖い話が出てくる。
出てくる、出てくる。
で、最後は真実、truthっていう役割で、
これは真実の管理について言ってるんですけど、
本の中では、今何が起こってるのかを一番知ってる人。
で、社内を流れる情報はどうしても減衰してしまうと。
特に複数のチームがいたりとか、たくさんチームが大きかったりすると、
減衰してしまって流れが淀んでしまうので、この役割が必要になると。
これは非常に定義が難しいと言っているんですけども、
例えば、これをやると締め切りのこれには間に合わないですよとか、
もうすぐこの人は休暇に入るので、
今週は例えばこれじゃなくてこっちをやる必要がありますよとか、
そういうことですね。
これはエンジニア側にいることも、プロダクトマネージャー側にいることもあるって感じですかね。
あとは、すごく大きな企業だと、プログラムマネージャーっていう、
またPM、略称PMになることが多いんですけど、
大体略称ではPGMって書いて、プロダクトマネージャーPDMと区別するんですけど、
日本では結構プロジェクトマネージャーって呼ばれてる人が、
ちょっとでも古い方かな、最近あんまりプロジェクトマネージャーって呼ばれる人がいる会社って、
特にITベンチャーだと少なくなってきたような気がするんですけど、
プロジェクトマネージャー自体はプロジェクトマネジメントの資格とかあるぐらいで、
結構すごく昔からある概念ではあります。
で、それが多分海外版はプログラムマネージャーと呼ばれてる、
進行管理だとか、進行管理は一番わかりやすい言い方だけど、
多分この本ではもっとより、今何が起こってるのか、何が問題になってるのか、
どこに問題あるのかってことを一番知ってる人っていう定義をしてるんだと思います。
この役割に本来なってほしいようなプロジェクトマネージャー的な人が偉すぎると、
結局この人が一番知ってる人にはならないんですよね。
偉すぎる人はここにいられないんですね、偉いから、権力があるからっていう意味でも難しいですね。
42:04
エンジニアチームの一番下っ端みたいな人が一番知ってたりして、
だから役割とは違うトゥルースっていう名前がついてる。
そうですね。
なかなかプロジェクトマネージャーとかプログラムマネージャーがいるチームで、
その人がトゥルースになってるかどうかは、その人次第っていう。
面白いな。
このビーングギーク書いた人は、あらゆる現場を見てきてますね。
そうだと思います。
いろんな会社でCTOやったりとか、エンジニア自身もやってるし、
エンジニアマネージャーもやってるし、みたいな、そういう感じの人だった気がします。
なんかネットスケープってすごい懐かしい文字が見えたんですけど、
マイケルさんが昔いた会社として。
そうやったんだ。
JavaScript界ですごく深く扱いましたよね。
はい、なのでちょっと気になる方はJavaScript界を聞いてもらって、
いろんなITベンチャーを渡り歩いてたんだなっていうのがわかる。
確かにこの3人がいないと成立しないけど、
でもその3人が、
Bitがエンジニアチームのリーダーである必要もないといえばない、
必ずしもそうであるとも限らず、
プロジェクトマネージャーがフィーチャーであるとも限らず、
プロジェクトマネージャーがトゥルースであるとも限らないっていう、
これはもう真相ですよね。
そうですね。
あとは必ずしもその3人が別の人であることが絶対に必要なことだとは、
この本では言ってないけれども、
でも例えばすごく大きい会社で、
潤沢にリソースがあるのに同じ人が全部やってるとか、
2つ兼ねているっていうのはあまりヘルシーな状況じゃない。
それはね、その人が本当に過労で倒れちゃう。
そうですね。
あとは何だろう、健全じゃないっていうのもあるとは思います。
実際のトレードオフがあって、緊張感がこの3つの間にないと、
例えば無限に機能が増えて、
で、全然リリースできないとかってのもあるだろうし、
技術的な詳細にこだわりまくって、
めっちゃロマンあふれるプロダクトができちゃうみたいなのもあるだろうし。
なるほど。
でも、なんかめっちゃ多いと思うな、これ3つ兼ねてる人がいるケース。
そうですね。
それはあるなとは思います。
でも、同じ役割の間にある緊張関係が大事なんであって、
つまり、ビットとフィーチャーどっちを優先するか、
どっちに傾いてみすぎてもよくないわけですね。
で、それがやっぱ1人にまとまっちゃってると、
その人の中で緊張関係をやらなきゃいけない、
トレードオフをやらなきゃいけないから、
結局アンバランスな決定をしちゃいがち。
安全側に倒しすぎてしまったりとかね、
45:01
要求をかなり下げてしまうみたいなのもあるだろうし、
多分そういうことを言いたいんじゃないかなと思います。
だから、かろうっていう話だけでもなく、
大変すぎるって話だけでもなくて、
いいプロダクトはできないよねっていう。
確かに。兼ねたことありますか?
多分あると思う。
個人開発してると絶対兼ねることにはなるし。
それはそうですね。
だから、私もCサインマップとかはほぼ個人というか、
本当に少人数のプロダクトだから、
自然的にいくつか兼ねることにはなるし、
別にそれは変なことではないんですけど、
確かにたくさんいるのに、
この人だけがすべてしてしまっているみたいな状況って、
結構あるんじゃないかなって思いますね。
ハッカソンとかね、やると参加すると、
すごくこの感じわかるなって感じします。
そういうスクズになりますよね。
ハッカソンはスクズですね。
実際のプロジェクトの。
ハッカソンっていうのは1日とか2日とかで、
1個プロダクトをアイデア出して作ってみようみたいな、
そういうイベントのことですけど。
ハッカソンとかでは、
結局チームによっては3つの役割全部1人でやっちゃって、
つよつよの人が自分で作ったものを発表するだけみたいなのも結構あるし、
ばらけてるチームもあるし、
でもやっぱばらけてるからといって、
いいものができるとも限らない。
結局、ハッカソンみたいに1日単位だったら、
むしろ1人で全部やっちゃったほうがいいものができたりするんですけど、
それってチーム組んだらいいみたいな感じなんですよね、わりかしね。
長期的にはあんまりヘルシーな状況ではないし、もちろん。
持続可能なことではないですね。
持続可能な開発っていう意味では、
やっぱりこれら3つがバランス取れていく必要があるのかなっていう。
面白い分類だと思いました。
まずは別の人がやるかつ、
それぞれがそれぞれに発言権がないと意味ないですね。
そうですね。
ルースをやってる人がすごく役割がした後、
本当は間に合わないことはみんなわかってるはずなのに、
進めてしまうのが起こってしまうとかね。
確かに、それはわかる。
それは本当にあり得ることだな。
あとフィーチャーの人はいるけど、
発言権がないというか、
予算がついたからやりましょうみたいなプロジェクトで、
これこんなことできそうなのにな、こんなことやりたいなって思ってる人とか、
結局発言権持ってなかったりすると、
できるかつできそうなことだけをやってしまう。
確かに。
のもあるし。
そこの力関係すごい難しいですよね。
48:00
最初のツイートの話に戻りますけど、
やっぱり、力関係をいい感じにしておかないと、
コミュニケーションって取れなくて、
そこをどう作るかっていうのが課題ですよね。
そうだね。
なんかあったときに言える関係にしておかないと、
っていうのは、
うまくいってないときに、
それを言える人がいなくなってしまう。
みたいなのはありますね。
それは、例えば、全然技術的な問題解決しないって場合もあるし、
誰が欲しいものを作ってるのか分かんないみたいなのもあるし、
実際間に合わないみたいなのもあるし、
いろんな問題あると思うんですけど。
割といい3分類だなとは思いましたね。
そうですね。
必ずしも、大企業でこれが文業が完璧にできてるってわけではなくて、
例えば、この人がこの本に書いたのは、
結局、大企業でもできてないことが多いよねっていう指摘だったわけで、
僕のチームでも、いや、果たしてっていう感じが。
やっぱり一番大事なメッセージは、
役割と肩書きっていうのが必ずしも一致してないことっていうのは多いし、
それは一時的にはそれでもいいんだと思うんですよね。
ただ、長い目で見て適材適所に人を動かしていくために、
ある程度、それぞれの肩書きによらない役割っていうのを
見極めていく必要があるよねっていうことなのかなと思います。
そうですね。
不謹慎な状態になったら、それをちょっと戻してあげるっていうのは、
大事かなとは思いますね。
はい。じゃあ、そんなところですかね。
今日は。
十分話せました?
はい、話せたと思う。
なんか、もっとエンジニア魂の叫びみたいなのあったら言ってください。
いやー、なんかどっちかというと、こう、悲痛なつらい話を思い出す回だったような気もします。
そうなの?
あんなことあったな、こんなこともあったな、みたいな。
そういう思いがあふれる回でしたね。
まあ、彩香さんもなんか心当たりがありそうな話が多かったですけど。
うん、ありますね、いろいろね。
いやー、やっぱり、なんだろう、チームで働いて、みんなで一個のものを作るって、
やっぱりね、それはどんな文脈でも難しいことですよね。
そうですね。
まあ、なんか、やっぱ1たす1たす1が3にならない世界というか、のはありますけどね。
うんうん、確かに。
あ、なんか、これとは別にちょっと話題になってたものとして、
はい。
なんだろう、もう、こう、IT企業で働く人は全員プログラミングできるべきみたいな、最低限みたいなのもちょっと話題になってたと思うんですけど、
うんうん。
なんか、それに関してはどう思いますか?
例えば、今後そのプログラミングがある程度必修化されることで、
51:03
まあ、得意ですごい好きじゃなくても、ある程度触れたことがあるっていう人は結構増えるのかなと思うんですよね。
うん。
あれでしたっけ、センター試験に情報が入る。
ああ、そうですね。
まあ、なんか、多分なんか、多少できる人の方がいいよねって言われたときに、
何をするのかって結構人によってイメージしてるものが違うと思うんですよ。
ああ。
なんか、例えばエンジニアの人が、こう、そうじゃない人に期待するものとして、
うん。
こう、一番理想的に思ってるのは、
うん。
なんだろう、さっき言った1割感、9割感が伝わるっていうことなんですね。
なんか、あるプロダクトを作ろうとしたことがあって、
そういうときにどういうところで詰まったり、どういうリスクがあったりとか、
どうしてできないことがあるのかっていうことがわかるぐらいに、こう、作る経験を知っててほしいみたいな場合があって、
で、逆にこう、教える側とか、学ぶ側としてわかりやすいのは、教科書があって、それが学べるようなことですね。
その、パイソンの文法とかって話ですね。
でも、実際それって結構違うことじゃないですか。
なるほど、なるほど。
その、パイソンを、例えば、カローワールドをやって、で、できました。
で、その後、関数を作れるようになって、こんな、じゃあ、フィボノス数列を出力できるようになりましたってなったときに、
じゃあ、その、なんだろう、その感覚を共有できているかっていうと、結構怪しくないですか。
確かに、確かに。
センター試験とかも、たぶん同じ話ですね。
うん。
で、まあ、それは、それとして、僕は必要だとは思いますけど、別の名前がついてるべきだとも思います。
うん、うん、うん、なるほどね。
エンジニア側が、いや、エンジニアの素養がある人とか、プログラミング勉強してる人と働きたいなっていうときにも、たぶん気をつけるべきでもあると思っていて、
なんか、その、なんだろう、求めている能力とか、こう、素養とかをもうちょっと定義して言わないと、なんかミスマッチしたまま、
うん、確かに。
なんか、新入社員教育とかで、こう、教えられて、で、わかってるつもりで話してるけど、全然うまくいかないみたいな、とか、こう、そういう不幸が生まれてしまうんじゃないかなという気は、非常にしていますね。
いやー、うん、いや、これすごいいい話言ってたんだけど、大事な話だなと思いました。
だから、情報の知識っていうよりは、やっぱりその、プロダクトを作った経験とか、いかにこう、なんていうか、どういう要素でうまくいかないことがあるのかとか、
その辺を知っててほしいとか、まあ、どういう要素が大変なのかっていうことが、まあ、イメージできることで、ある程度その、余裕を持ったコース組みができるとか、なんかその辺ですよね、わかるね。
たぶん、結局、ソフトウェアエンジニアリングって、ソフトウェア要素、プログラミング、純粋なプログラミングを使うっていうことと、
エンジニアリングというか、なんか物を作るときの、このぐらいの確率でこれはできて、次はこのぐらいにできて、最終的に、こういう仕様を満たした製品ができる確率はこのぐらいみたいな、
54:12
工学的な、工業的な話かなと、2つあると思っていて、でも、なんかこう、そうじゃないプログラミングが想像しにくいとか、そうじゃないエンジニアリングことを知らないとかで、結局その2つのものをこう、いっしょこたに扱っているってことは、結構ある話かなと。
え、情報と工業的な話が、どっちかというと、その情報のほうを今、教えようとしてるんだけど、そっちじゃなくて、もうちょっと工業的なところの感覚があるほうが嬉しいっていうことなんですかね。
まあ、このツイートではそうだと思う。このツイートであったほうがいいなって思ってる、素養的なものってのは工業的なもので、それって別に、これってそんなにソフトウェアじゃなくていい話じゃないですか。
たしかに、たしかに、そうですね。
例えば、なんか他で、その、まあ、分かんない、まあ、車とかだったらちょっと大きすぎるのかな、あのスケジュールとかが。
まあ、でも、うん。
まあ、でも、そういうものづくりにかかった人だったら、もしかしたら解決した話。
たしかに、たしかに。
でしたよね、きっとね。
まあ、そうですね、これは全然ソフトウェアに限った話ではないですし、研究開発とかでも全然ある話だなっては思いました。
その、なんなんてできますかね、感して言うと。
ただ、それがたぶん、その、いろんなリソースが必要で、許可とかが必要だから、なんとかってできますかねって、例えば、あの、車のエンジニアに聞いて、実装しましたってはならない。
たしかに。
こんなエンジンできますかねって言われて、うーん、まあ、こことここはできると思うけど、みたいな感じで、たぶん答えてくるだけで、まさか、あの、エアラボにあったものを適当に組みましたわ、みたいな感じにはならないはずで。
そこがソフトウェアだと、実際手を動かして考えたほうが早いから、じゃあ、やってみますわ、みたいな感じで書いちゃって、実装しましたってなっちゃうみたいな。
だから、なんか、うん、それは、なんていうか、まあ、ある意味ソフトウェアだからこそ起こり得ることなのかなとも思いました。
たしかに。
いや、じゃあ、どうすればいいんですかね、パイソンじゃなくて、何をすべきみたいな。
でも、難しいですね。だから、ハッカソン出ろみたいな話だと思うんですけど、それでもパイソンできないとやっぱできないわけで。
まあ、そうですね。
そもそも、こう、作りたいものがない人が、どう、その、ソフトエンジニアリングのエンジニアリング部分を勉強できるかっていう。
まあ、でも、なんか、ハッカソンやってみるは一番なんか近い気はする。
まあね、でも、やっぱハードルは、こう、うん、いや、なんか逆に、なんだろう、プラモデル作るみたいな、そういう、こう、もっと、なんだろう、こう、生産性、再現性が高いやり方を考えてるんです。
新入社員教育で使えるような。
ああ、いや、でも、結局、その、なんだろう、マニュアル通りに作れば全部うまくいくようなプラモデルだったらいいじゃないですか。
57:06
だから、やっぱり、1から、その、なんかしらのテーマに合わせて、まあ、半分アイディアソン、半分ハッカソンみたいな感じになると思うんですけど。
で、
やっぱ、マシュマロタワー作らせるしかないのかな。
いや、やっぱそうなっちゃうのかな。
いや、マシュマロタワーでは、だめだと思う、やっぱり。
マシュマロタワーでは、足りないものがやっぱりあると思っていて、やっぱりなんか、自分より詳しい人が、たとえばチームにいて、その人の力を借りるだとか、
っていう、やっぱなんか、うん、なんかハッカソンなんじゃないですか。
なるほどね。
まあ、完全にプロダクトを作らなくてもいいんだけど、なんか作るのがどう大変なのかとか、
そうですね。
なんか、こう、自分がどうやったら貢献できるのかとかを考える、その、チャンスにはなると思うから、
まあ、わかんないです。ハッカソンが適切かいかはわからないけど、まあ、でも、プラモよりはマシみたいな。
まあ、たしかに。マシュマロタワーよりはマシかもしれない。
うーん、かな。
まあ、あとなんか、本気でやっぱ勝ちたいハッカソンじゃないと、結局、
あ、そうですね。
なんか、オーナーシップを持つことはできないので、うん、色彩のものじゃないといいなっていう。
まあ、だから、これを聞いた役員の人は、とりあえずハッカソンやればいいのかって思うのは、ちょっと待ってください。
まあ、そんな感じでしょうか。
どんな感じでしょうね。
まあ、どうするべきかわかんないですけど、まあ、でもその、なんだろう、現場のエンジニーが求めているのは、情報の知識ではないっていうことはすごく、
ああ、なるほどってなって、学びだなと思います。
まあ、それはなんか話しながら、こう、気づいたような気がします。
それは、うん、たしかになんか、お偉いさんが気づいてない、いいポイントなんじゃないですか。
はい。
じゃあ、お偉いさんがもし聞いていたら参考にしてください。
はい。
現場の叫びです。
はい。
はい、ということで、今回は何々ってできますかという問題について語っていきました。
はい。
まあ、結構盛り上がりましたね。
盛り上がりましたね。
お互い思うところあるっていう感じでした。
はい、また次回も見てください。
それでは、さよなら。
さよなら。
