で、これ、この話の続きもあってですね。自分がどんどん年齢が上がっていくじゃないですか。誰かとわんわんをする、限られた30分間ですっていう時に、なんかこう年齢が自分が高くなってくると、私喋りすぎてないかなって思うんですよね。
で、毎週毎週気持ちが強くすぎてですね、なんかこう自分が喋ってる時間が長いことで、相手の時間を奪ってるみたいなことがあるなってことに気づいて、一旦、黙っていようみたいなふうに、ここ最近はなるようになりました。
なるほど。でも、ワンオンワンでたくさん話してくれるのは、関係性があればですけど、嬉しい感じもしますし、その辺が難しいですよね。結構ワンオンワンで話が続かなくなるときの気まずさみたいなのもあるし、
割とその、僕としては小無性的な部分もあるから、逆にその話が続かなくなるのが嫌だから喋りすぎてしまうみたいなのは、もともとすごくあったなあっていうのは、今もやっぱあるなあっていうのは思います。特にやっぱ初対面の人とか、なんかそういう人とかだとそういう側面すごい持ってしまうっていうのはありますね。
わかります。でも、なんだかやっぱり自分が7割ある方、口開いたなあみたいなときは、あ、コラーが閉まったなって思うことにしてて。なるべく、きっとおしゃべりが上手じゃない子も、きっと何かの思いがあったりとか、あと緊張してしゃべれないこともあるかもしれないので、
なんだろう、相手がしゃべりたいことをその場を使ってしゃべれる状態をたくさん作って、相手のことをまず知らないとどうにもならんなあって、最近は思ってます。
いや、それはめちゃくちゃありますよね。やっぱ相手のことを知るみたいなところが、やっぱりそういうのを会話の中でどう引き出すかみたいなのすごく難しいよなあっていうのは思いますね。
なので、僕も面接とか面談とかするときに、やっぱちゃんと相手の方がちゃんとアウトプットとか、そういうのがあるときにはすごい助かるというか、ちゃんとその方が書いてるブログとか、なんかそういう経歴、職務経歴とかを読んで、これが話題になりそうだ、こういったこと話そうみたいな、
そういうのを用意してから結構、面接とか面談に臨むんですよね。そういうのがないと全然、以前よりかはできますけど、結構困っちゃうみたいなのはあるなあって思ってます。
分かります。限られた時間の面談の中で、その方が取り組まれてきたこととかを、あのときのこのエピソードでこんなこと書かれてましたけれども、こうでしたよねとか、こういうこともちょっとどうですかって、なんか引き出し、いっぱいある、もともとある引き出しを自分から引き抜いてあげるのってとても大事ですよね。
そうですね、すごく大事だし、やっぱりそういったことしてると、向こうとしてもこっちに興味持ってくれてるんだなっていうふうに思ってくれるんだろうなと思うし、僕としても僕の発信とか、結構読んでくださる人とかとお話するとすごく嬉しいなっていうふうに思うので、じゃあなんか僕もなるべくそういったことをやろうかなっていうふうに思ってるっていうのはあります。
たしかに。ちょっとそのマネージメントの失敗の最初のきっかけではあったんですけど、この面接面談っていうのをどのようにやってるかとか、すごいやっぱり興味ありますね、他の人が。
そうですよね。僕って、それこそ就活に失敗したみたいなのもあるし、中途採用、中途採証っていうか採用の最初の多分転職でもかなり苦労したので、
とにかく、それこそ採用面接とかでは相手に嫌な思いはさせたくないなっていう気持ちがすごくあるんですよね。やっぱそれは僕がすごいそれが嫌だったから、そういうのはないようにしたいっていうふうに思ってる部分が採用面接についてはありますし、
面談とかではそうですね、お互い楽しめるようにとか、あとそうですね、やっぱフィードバックとかで言うと、やっぱり結局フィードバックみたいなもので、結局お互いの認識のすり合わせだと思うので、
あんまりポジティブかネガティブかみたいなものはなくて、逆にこういったところが、例えばネガティブフィードバックみたいな受け取られるようなものであっても、こういったところが多分こちらとしては、こちらの期待に届いてなかったように思うんだけど、そこはどう思いますかみたいな。
このままの聞き方をしちゃうと圧が強いんで、そういう聞き方はしないんだけど、結局どっちが間違ってるかわかんないじゃないですか。こっちとしては期待に届いてないっていうふうに思う。けど、実は別のところで、当人としてはそう思ってないかもしれないし、こっちの多分期待してることが間違ってたかもしれないしっていうところはあるから。
結構そういったところは、対象性みたいなのは気をつけるようにしていますね。そういう面接の場とかであっても、やっぱりこっちが選ぶ立場でもあるし、選んでいただく場でもあるっていうところは、そういう対象性みたいなのは結構大事にしたいなって思ってるところではあります。
たしかに。給食者、働きたい人と働きに来てほしい側の対象性の大事さみたいなのは、ずっと自分自身がわりとHRのサービスに関わってきてることが多かったので、すごく今いい話だなと思ってました。
平等であるべきだよなって思って、それでお互いの表現の努力によって作られてるものも結構あるなって思いました。
すごく人事とか特に採用みたいなものってすごい怖いことなので、どういうことかっていうと、やっぱりどうしても人を選別する選ぶみたいな側面が出てきてしまうものではあるので、そうすると知らず知らずのうちにすごい傲慢になってしまう部分とか思い上がってしまう部分ってすごく出てきてしまう
危険性があるなって思っているので、やっぱり基本的にお互いが選ぶであるとか、こちらが選んでいただく部分もあるっていうことを本当に強く意識しないと、やっぱりすごくそういう思い上がってしまうリスクがあるところだよなっていうのは思うし、
たまにSNSとかで人事の人とかが炎上してるのって、そういう自我の被害みたいなものに起因するんじゃないかなっていうのは感じたりすることがあります。
すごく狂いやすいというか、すごくそれをそうではないっていうところで軌道修正していくのがいかに大変かっていうのはすごく思いますよね。
いや本当そうだと思います。
あれってお互いにお互いを選び取ってるなっていう世界ですよね、あそこは。
特にエンジニアの採用とかだとかなり売り手市場みたいなところもありますし、他の採用も結構ちゃんと厳選採用みたいなのをしていると、やっぱり内定をお出しした方が2社3社ぐらい他社の内定を持ってるみたいなことが普通なので、
そうするとその中からどう選んでいただくかみたいなところがすごく大事になってくるので、そういう意味でもやっぱり最終的にはちゃんと選んでいただくっていうのが大事だなっていうのはすごい思っています。
いやでもそうなんですね、人に興味がないとか、人の心がないとか、なんかそういうこと言う方がどうなのかという気持ちもするんですけれども。
森 理想はみんなが考えて、みんなで理想の状態を作り上げて、実装していくっていうのが、状態を導くのが理想なんですよね。もういつもそうは思っているものの、なんか特に私が初期の頃のこうあるべきが激しすぎたときには、もう圧倒的な型とか、このときはこのやり方でやるべき、これを出したものはバツ。
バツではないですけど、このくらいの感じでガチガチでやって、あと人間それぞれの頑張り方みたいなとか、時間の使い方とか、もううるせえやつだったなあと思いますね。
しかも忙しかったりすると、本当に性格悪くなるから、人間みたいな。そこでちょっとそういうプロジェクトのレールから外れたことをする人がいると、結構なんでそんなことするのみたいな感じのコミュニケーションになっちゃうみたいなのはあるので、本当そうならないように心に余裕を持っておきたいよなっていうのは感じるところですね。
やはり人間はやはり生き物なので、余裕とかキャパシティっていうのは体力、体だけじゃなくて絶対的に心にもありますよね。本当に思いますね。
めちゃくちゃありますね、本当に。でも僕もいいチームで働いてるときとか、そういうチームをマネジメントしてるときとかって、みんなに考えてもらうことで自分が想像してたものを超えてくるとか、そういったことがすごくあったりとか、自分だったらこうするけどなあみたいなのを、
でもメンバーの人が提案してきた方法でやってもらうと、こっちの方が良かったんだみたいな、僕の直感の方が間違ってたんだなあみたいな経験が何度かあるので、やっぱりそういう意味でもちゃんと自分でこうあるべきって思いすぎない方がいいなって思ったのがありました。
ちょまど それはすごい嬉しい体験ですよね。
おだしょー OSSやコミュニティ活動についてっていう次の話題を挙げてくださってますが、OSS活動したことがないって書かれてますけど、どういう感じなんですか?
ちょまど 全然したことがなくて、いつもありがたいなあと思って利用させてもらってますね。ちょうど今日、2週に1回ぐらい、タイニーゴーの読書会をやっててですね。
それを、著者の佐藤さんっていう方も参加してくださってる、超贅沢な読書会なんですけど、ちょっとその本を読みながら、タイニーゴーのこのコマンドのこの結果って、実は期待通りじゃないんじゃねみたいな、たまたまその話が出て、
これはコントリビュートチャンスでは、みたいな話をしていてですね。ちょうど自分の手元でビルドできるようにして、実際動かしてみて、ちょっと中のコードを読んでみたら、これは別にバグではなく、こういう仕様だから、この結果だよねっていうことがわかったので、そこは触ることはなかったんですけれども。
なんかこういうふうに自分で普段から手元で触ってみたいなことって、ちょっとやったほうが絶対楽しいよなと思っていて、でもなんで自分やらないんだろうなってたまに思ってますっていうのがあって、逆になんか佐藤さんがOSS、自分でも運用してますし、
あともしくは他のOSSで何かコントリビュートするときのなんか良かったなーみたいなことありますかね。
そうですね。なんかこうしたことがないっていうのも結構意外だなっていうのは思っているのと、あとなんかトライしようとしてるっていうのはやっぱり素晴らしいことだなっていうのは思いました。
僕の場合はそれこそ作ったものを迂闊にOSSにしてしまうみたいな、そういうのがあるっていうところもあるし、
あとなんかそうですね、いろんなOSSを使わせてもらう中で、結構コントリビュートできるチャンスってそれなりにあるなっていうふうに思ってるのと、
たぶん、やっぱり慣れてきてそういうのを見つけるのが上手くなってきたっていうのはあるんだろうなっていうのは思っています。それこそなんかこの週末っていうかこの前の週末とかもちょっとやってたこととしては、
テキストリントってあるじゃないですか。テキストリントをGitHubアクション上で動かすみたいな、なんかそういうOSSがあるんですけれども、最近僕ちょっと本を書いてるみたいなのがあったりするので、
それのリポジトリの中でテキストリントを使ったりとか、アクションテキストリントみたいなのを使っていて、ただ僕、あとVibrioStyleっていうそういうCSS組み班のOSSを使ってるんですけれども、
そのあたり、ビルドとか依存の構築を早くしたいので、BANっていうノードとは別のJSの処理系を使ってるんですね、僕が。ただ、僕がアクションテキストリントっていうテキストリントをGitHubアクションで動かすものについてはBANに対応してなかったので、
僕としてはBANに対応してほしいなって思ったので、そのプルリクエストを送ったっていうのがありました。それで、ありがたく取り込んでいただいてありがとうみたいなのがつい最近ありました。
そういったところでも、気軽にこういうのどうですかみたいなプルリクエストを送ったりとか、自分のユースケースにちょっと沿わないところとか、ちょっと足りてないところをとりあえずプルリクエストだったり、Issueとかで相談したりみたいなことは結構やるようにしてるみたいなのがありますね。
ちょうど苦しみ、ずっとやり続けることの良かったことは多分ですね、いろいろあると思うんですよ、体験であったりとか。
ただ苦しみとか、よく歴史が物語っているじゃないですか、続けられなくなっているOSSであったりとか、巨大化することでもうこれ以上開発し続けることができませんとか、そういうのがあったりとか。
多分そういう葛藤ってどこかにきっとあるだろうなーって思っていたりとか。
あと事件もあったりしますよね。最近の藤原さんの件とかですかね、とても辛い話ですよね。悪い人が入り込んでくるみたいな、圧倒的な悪意を持ってきてるやつですよね。
そういうのとかって正直完全には防げないでしょうし、それでもやっぱりOSS全くやめるってやっぱりしなかったりするじゃないですか。悪い者への立ち向かい方みたいな気持ち的なものを聞いてみたいなと思った次第でした。
そうですよね。僕はブログとかOSSとかそういったもので辛くなったことはなくて、そこはすごく大事にしたいところだなっていうのはまず思っているんですね。
仕事って好きでやってても辛くなることって絶対あるじゃないですか。僕はあるんですね。別にここ10年とかって僕は本当に好きな仕事しか選んでないしやってないけど、それでも辛くなることとかって絶対あるわけですよ。
それって当たり前の話で好きなことって辛くなることありますよね。パートナーのこと好きでも喧嘩することになるしみたいな、そういうことだと思うので、好きだけど辛くなることはあるなと思ってるんですけど。
幸いブログとかOSSとかはそういった経験があんまりなく、本当に自分の好きなときにやるみたいな形でできてるので、僕としてはなるべくそれが維持できるようにしたいなっていうふうに思っています。
多分それもあんまり締め切りだったりとかタイミングとかそういったものが急かされるようなことがなくて、自分がやりたいタイミングでやるみたいな形で活動できてるのがやっぱり良いなっていうふうに思っているので。
だから逆にもうちょっと社会的な責任が強い、もっといろんな人が使ってるOSSとかをメンテナンスするときに脆弱性とかがあったときに早く対応してくださいみたいな話だったりとか、いろんな意見がやってきてそれを取りまとめるのに苦労するとか、そういったことになってくると辛くなる可能性はあるなと思っているので。
そういったところになるべくそうなりたくないなって思ってるみたいなのはありますね。あとやっぱOSSで結構辛くなる人みたいなのはなるべく減らしたいなって思っているので、でもなかなかそれは難しいなって思いますね。
逆に責任感とか感じすぎないほうがいいというか、っていうのはすごく思っているので、そういう意味では僕としてはあんまり放置してるOSSもたくさんありますし、逆に自分が使いたいなっていうOSSでメンテナンスが止まってたらメンテナンスを引き継ぐみたいなこともありますし、みたいな感じでやってはいますね。
最近だと一つ、去年末とかにテキストマークダウンディスカウントっていう、これはパールのモジュールですけど、それのメンテナンスを引き継ぐみたいなことをやったりはしました。
なので、基本的に楽しくOSS活動はできてるんですけど、やっぱり今日藤原さんが公開してたような、マルウェアの偽物を作られたので、自分のOSSのマルウェア入り偽物を作られたので通報したみたいな、こういう話があったりすると困っちゃうなっていうのは思ってますね。
なんか、それこそサプライチェーンアタックみたいなのも、なかなか無視できないものになってきて、もともとすごく生前説前提でやって、コミュニティが広がる楽しさとか、より良いものが作れる良さみたいなのがOSSの世界にあったはずなのに、結構そこに悪意がいろいろ入ってくるみたいなところが増えてきてしまっていて、
割とそれでいろいろやりづらくなったりとか、ガチガチに固めなきゃいけなかったりとか、逆にそれこそ、やっぱりOSSの世界って信頼が大事っていうのがまずあるとは思うんですよ。
だから信頼があるメンテナーとか、信頼があるOSSデベロッパーみたいな人の影響力があるとか、そういった人のパッチが取り込みやすいみたいなところはあるので、ちゃんと信頼を積み重ねるのは大事っていうのはあると、やっぱり新しい人がゼロから始められるとか、そういう良さとか敷居の低さみたいなのがあると思うので、
ただ逆にこういう悪意のあるような話が続いてしまうと、例えばまだOSSの世界で信頼がない人はコミットできませんとか、そういう方に話が行き過ぎてしまう危険性がはらんでるなとも感じているので、やっぱりそういうことにはならないようになってほしいなっていうのは最近すごく思ってるところですね。
こういう犯罪の、前衣の集団に対するところに付け込んでくるってあるんですけど、だいたい歴史上はどうしてもそこに対して防御的な、コミュニティは防御的な姿勢をとらざるを得ないみたいなことになりがちではあるので、
なんかとはいえ、今後どのうまく左右するのか心配ではありますけれども、いい落とし所つくといいですよね、今後ね。OSSな。しかもOSSを使いましょうという側にも今度審査が入ったりとかしてまた大変になりそうですよね。
そうですよね、本当に。僕とかOSS発掘するみたいなの好きなので、結構GitHubとか検索して、こういうのないかなとか、今こういうライブラリ欲しいからないかなって言って、わりと見たりとかしてちょっと試しに使ったりみたいなことを結構しているので、
そういったときもちゃんとソースコード読み込んだりとか、なんか怪しいことしてないかっていうのを確かめてから使ったほうがいいなっていうのを今日改めて思ったのと、それ結構世知辛いなって思ったのと、その辺結構AIとかに診断させられないかなっていうふうに思ったみたいなのがありました。
そうですね。いい話としては、AIちゃんがだいぶ賢いので、結構そういう辛い作業を彼らやってくれますよね。
やってくれますね。
いい話だ。
なので、そこは結構AIに判断してほしいな。そういうの確か作れるかもしれないし、みたいなのを思ったりはしました。
チェック機構はAIがいい感じにしてくれるんじゃないかな、できそう。そんな気がします。そう考えると辛いことばかりではないですね。
そうですね。そう、期待したいなっていうところですね。
それはめちゃくちゃ思いますね。し、結局みんなかなり苦労している気がするし、そうですよね。やっぱり僕としては全部何らかのテキストファイルで管理してバージョン管理すべきだと思っているんですけど、
なかなか、それこそドキュメントを書く人とかがエンジニアじゃなかったりとか、ちょっと違うシステムみたいなものを使うときになかなかそれが実現しづらいみたいなところがあるので、
結構ちゃんとそこもエンジニアチームで開発で一体となって取り組んでいくべき課題ではあるけど、ついアウトソースされがちで困っちゃうねっていう話ではありますよね。
そうですね。ドキュメント、これ完璧だなって今までなったことなくて、私前職のカウシェで開発してたときは、大元のドキュメント、デザインドックはノーションで書きますが、
それは割と一家製のもの、マスターにはないので、必要な仕様をシーケンスみたいな形でMermaid.jsで書いてGitHubで管理したりとかしてたんですね。
ただもうないよりは全然良くて、ないよりは全然いいんですけど、まずシーケンス図を書いてGitHubで管理できる人はエンジニアのみになるので、今度方針できる人が限られてくるっていうのもあるので、良きとしては良きなんですけれども、ちょっと痛いし悔しいみたいな感じではありましたね。
そうなんですよね。なんかGitで管理したいっていうのも、かなりエンジニアのエゴだなって思う部分もあって、ただそうしたいよなっていうのはあるけど、やっぱバージョン管理みたいなものがかなり多くの人にとって難しいんだなっていうのはすごく思うところなのと、
確かに考えてみたら、そういういろんなブランチがあって、作業ブランチがあってメンテナンスしていくみたいなのってすごく難しいなっていうのは思うので、それこそ結局多くの人はファイルとかワードとかをいじるときは一旦コピーを作ってみたいな、そういう感じになりがちで、
そのあたり、あと差分の見方みたいなのもあんまり意識してない人も多いというか、そういうディフを見たいとかバージョン管理したいみたいなのがすごく特殊な人たちの、エンジニアっていう特殊な人たちのマインドセットだなっていうのをすごく思うけど、やっぱそうやりたいよなって思いますね。
だからノーションとかが履歴とかすごいいけてないと思うんだけど、実はあんまり多くの人はそこに課題意識を感じてないっていうか、たぶんあんまり結構ちゃんとした履歴管理機能みたいなのを作ったところで、たぶんあんまちゃんと使う人がいないんだろうなっていう、だからなかなか開発されないんだろうなっていう、ちょっと僕としては悲しい自己完結してるところがあります。
でも履歴、欲しい人やっぱり欲しいみたいで、例えばやっぱり今あるこのヒトセットのリリースの塊はどういう意思決定をされてきて、誰が何をどういう理由で変更して、今ここにあるみたいなやつって、やっぱ残したいんですよね。
それを本当は、たぶん非エンジニアの人も残したい種類の人たちって結構いて、ただいけてないツールだったりする。いけてるツールがあったとしても、それをいい感じで使いこなせないので、ひたすら履歴をスプレッドシートで書いてるみたいなケースもやっぱありますし。
でもとってもつらいんですよね、それって。なんか完璧になってない、なんかいいソリューションってどっかで出てこねえかなって思ってますね。でもそうなんだよな、コンフルエンスとかも結構多くの企業が導入してるドキュメントのツールだと思うんですけど、あれも健康履歴めっちゃ取ってくれますけど、だから何っていう感じの偏向履歴になっちゃうんですよね。
そうなんですよね。だからちゃんと塊で更新をちゃんと管理したいですよね。多くの人は理解できれば絶対それがいいって思うと思うんだけど、なかなかそこまでなんかにたどり着かないっていうのと、そういう体験が与えられるツールがないから、なかなかそういうところに行かないし、
ソフトウェアエンジニアはソフトウェアエンジニアのマインドセットで考えようとするし、みたいなのがあるなとは思ってます。ただなんかやっぱりGitHubとかでマークダウンとかをバージョン管理するのがやっぱいいんじゃないのかなっていうふうに僕はやっぱ思っちゃいますけどね。
そう、すぐ思っちゃいますね。たぶんGitHubでバージョン管理されたものがどこかでわかりやすく見れるであったりとか、なんかGitHub、Gitの仕組みからわかりやすいもの、Gitの仕組みからGitHubっていうのがあって、あれエンジニアが理解しやすいものであると思ってて、
あれがデザイナーであったりとか違う職種の人にわかりやすい何かで見られるUIとかがあると、もしかすると変わるかもしれないですよね。
そうですよね。そういうドキュメントシステム、欲しい。スフィンクスとか、やっぱり結構使ってる方結構いますけど、なかなか上手くいってるの見ないなって思いますし、それこそ僕、さっきリビューの話が出ましたけど、リビューとかってすごく技術書籍とか技術同人誌書くのにすごい使われてるツールだと思うんですけど、
ビブリオスタイルっていう、これはマークダウンで書けて、CSSで組み込んできるっていうやつなんで、機能的にはリビューのほうができることもまだ多いのかもしれないんですけど、かなり僕の中ではすごい気に入っていて、今使ってて、
これはそれこそウェブサイトにもできるし、EPUBにもできるし、PDFにもできるし、みたいな感じなので、そういったもので上手いこと、上手くドキュメントとかを見せられると嬉しいよなっていうのは思ったりはしています。
でも結局、どうしても古くなっちゃうものみたいなのがあるから、その文章って、いつ古くなるかみたいなのって難しいですよね。いつ古くなるかのトリガーがいくつかあるなっていうのを思っていて、一番わかりやすいのは時間なんだけど、半年後にこのドキュメントアウトデイティットになりますみたいなのがある。
逆にこの技術を使わなくなったとか、この人が退職したからとか、この人が移動したからとか、そういったところで変わるものってあるじゃないですか。そういうのをなるべく排除して書こうとは思うんだけど、排除しすぎると逆にめちゃくちゃわかりづらくなるみたいなのもあるから。
だから社内ドキュメントとかも、すごい今は使われてないツールを前提にしたドキュメントみたいなのがまだ残ってたりとか、そういうのっていつドキュメントが腐るのかみたいな、そのトリガーってすごいたくさんあってむずいなっていうのは思います。