- ポッドキャスト収録について
- マネジメント失敗談やしゃべりすぎ問題
- 採用における対称性の重要性
- 他者への興味と理解と好奇心
- あるべき論・どこまで決めるか決めないか
- OSSやコミュニティ活動
- OSSに関わる中での葛藤
- 編み物とホラー小説
- Document Reliability Engineering
OSSやコミュニティ活動
OSSに関わる中での葛藤
編み物とホラー小説
Documentation Reliability Engineering
サマリー
このエピソードでは、マネジメントの失敗とそれに関する学びについて、ミッチーさんとともに語られています。特に、人間関係の信頼構築や面接での相手への配慮が重要であることが強調されています。また、好奇心の大切さやコミュニケーションにおける課題についても話し合われています。OSS活動やコミュニティ作りの経験を通して得た教訓とその重要性についても言及されています。OSS(オープンソースソフトウェア)におけるコミュニティの挑戦や制作プロセスで直面する困難についての話があり、最近の編み物の楽しみや自作の道具についても触れられています。さらに、電子書籍や子供向けの本についての困難に加え、ドキュメントの信頼性や更新性の重要性が語られています。また、ドキュメントシステムにおけるエンジニアリングの役割や技術ライティングの価値についても議論されています。AI技術の進化に伴い、文書作成の効率化が進む一方で創作の楽しさを失いたくないという思いが表現されています。
ポッドキャストの収録体験
はい、趣味でOSSをやっている者だ。引き続き、ミッチーさんをゲストにお話をしていこうと思います。よろしくお願いします。
よろしくお願いします。
なんかその、インターバルの時間で、このポッドキャスト収録みたいなものに、なんかいろいろこう、考え的なものを感じられてたみたいなんですけど、なんかご…どういったことを考えられてたんですか?
そうですね。私、このRiverside.fm、このツールがまず初めてなので、ああ、こうやってやるんだって思ったのと、あと、まあ進行がSongmuさん、かなりやっぱり慣れていらっしゃるので、ああ、これがラジオをやる人間の仕草かと思って見てました。
いや、全然慣れてないですけどね。なんか結構ちゃんとミッチーさんが、こうアウトラインを事前に書いてくださったから、もうそれを話してるっていう感じですけど。
いえいえいえ。ちゃんとそのアウトラインを汲み取って流していけるっていうのが、やっぱここはファシュリティ登録っていうんですか、すげえなと思って見てました。はい。
こう、今までポッドキャスト出たこととかは何、ありますか?
1回だけあります。
その時はなんかローカル録音方式みたいな感じだったんですかね。
そうですそうです。
そうなんですよね。ローカル録音方式いいんですけど、事故が怖いんで、こういう仕組みに頼るっていうか、こういうRiversideみたいなものに頼るって感じでやっております。
いやあ、いい仕組みだと思ってます。はい。
はい、ということで続きを話していければと思いますが、マネジメント的な話ですかね。結構マネジメントの失敗みたいなものがこれまであったみたいなことを書かれてますけど、でもそういった部分も結構糧になってるみたいなお話なんですかね。そういったところをお話しいただいていいですか。
そうなんですよ。いやあ、これでマネージメントというか、マネージャーになったりとか、マネージャーになる前に何人かとやってるチームでリーダーになってみたりとか、そういう立場を何度か経験してきていて、特に初期の頃とかは、自分自身がこうやってきました、このように努力をしてきましたみたいな自分のルーツがあったりするじゃないですか。
それが、そこが強すぎることによってですね、当然人って一人一人違うので、同じようにやるのが良しとは限らないじゃないですか。ただ、自分が思ってる結果が出て、相手が出ていないときに、なぜそういうことが起きてるのかとか、それは本当に結果として失敗なのかどうかとか、よく考えたほうがいいと思っていて、これって多分経長だと思うんですよね。
で、そこが割と時間がない中、押し進めてしまったりとか、良くない、相手にとっての身にならないフィードバックをしてしまうであったりとか、というのを数々やってきたかなと思っていて、そういったことで何回か、あなたちょっと人の心ないよねとか、人間に興味がなさそうですねみたいなことを、
言われたこととかがあったんですね。で、それを言われると、当然ながら自分自身もショックだったりはするんです。ショックだってことは、私は人に興味があり、人間の心がある、豊かな人間だって絶対思ってるからショックに感じてるはずで、じゃあ何でそう思うのかはちょっとわからないんですけれども、
でも大体、そういうふうに言われてしまう時とか、あと自分が誰かに対して、真のフィードバックではなくて、何かしら傷つけるようなことを言ってしまう時というのは、人と人の関係性、鏡合わせになってるなってことに気づいたんですね。
で、多分相手も自分に対してそのように思っているし、信頼関係がない、信頼関係がうまく築けていないっていうことなんだろうなというのが、だんだんわかってきて、数々の失敗の下、ひどいことを言われてしまった方には本当に申し訳ない気持ちもあり、
たまに飲みに行くと、あの時は本当にあんた鬼だったよねって言ってくれるのがむしろ嬉しいぐらいな感じなんですけれども、今は割と成功してるとは限らないですけれども、とにかく人が好きになる、まず自分から相手の好きなところを聞いた状態で、
だから、相手の話を引き出せるので、そこからうまくいってない事象があれば、真に向き合えるなっていうことをやっぱり気づかせてもらったっていうのが、自分のマネジメントの過去の失敗と今みたいな感じですかね。
面接とフィードバックの重要性
で、これ、この話の続きもあってですね。自分がどんどん年齢が上がっていくじゃないですか。誰かとわんわんをする、限られた30分間ですっていう時に、なんかこう年齢が自分が高くなってくると、私喋りすぎてないかなって思うんですよね。
で、毎週毎週気持ちが強くすぎてですね、なんかこう自分が喋ってる時間が長いことで、相手の時間を奪ってるみたいなことがあるなってことに気づいて、一旦、黙っていようみたいなふうに、ここ最近はなるようになりました。
なるほど。でも、ワンオンワンでたくさん話してくれるのは、関係性があればですけど、嬉しい感じもしますし、その辺が難しいですよね。結構ワンオンワンで話が続かなくなるときの気まずさみたいなのもあるし、
割とその、僕としては小無性的な部分もあるから、逆にその話が続かなくなるのが嫌だから喋りすぎてしまうみたいなのは、もともとすごくあったなあっていうのは、今もやっぱあるなあっていうのは思います。特にやっぱ初対面の人とか、なんかそういう人とかだとそういう側面すごい持ってしまうっていうのはありますね。
わかります。でも、なんだかやっぱり自分が7割ある方、口開いたなあみたいなときは、あ、コラーが閉まったなって思うことにしてて。なるべく、きっとおしゃべりが上手じゃない子も、きっと何かの思いがあったりとか、あと緊張してしゃべれないこともあるかもしれないので、
なんだろう、相手がしゃべりたいことをその場を使ってしゃべれる状態をたくさん作って、相手のことをまず知らないとどうにもならんなあって、最近は思ってます。
いや、それはめちゃくちゃありますよね。やっぱ相手のことを知るみたいなところが、やっぱりそういうのを会話の中でどう引き出すかみたいなのすごく難しいよなあっていうのは思いますね。
なので、僕も面接とか面談とかするときに、やっぱちゃんと相手の方がちゃんとアウトプットとか、そういうのがあるときにはすごい助かるというか、ちゃんとその方が書いてるブログとか、なんかそういう経歴、職務経歴とかを読んで、これが話題になりそうだ、こういったこと話そうみたいな、
そういうのを用意してから結構、面接とか面談に臨むんですよね。そういうのがないと全然、以前よりかはできますけど、結構困っちゃうみたいなのはあるなあって思ってます。
分かります。限られた時間の面談の中で、その方が取り組まれてきたこととかを、あのときのこのエピソードでこんなこと書かれてましたけれども、こうでしたよねとか、こういうこともちょっとどうですかって、なんか引き出し、いっぱいある、もともとある引き出しを自分から引き抜いてあげるのってとても大事ですよね。
そうですね、すごく大事だし、やっぱりそういったことしてると、向こうとしてもこっちに興味持ってくれてるんだなっていうふうに思ってくれるんだろうなと思うし、僕としても僕の発信とか、結構読んでくださる人とかとお話するとすごく嬉しいなっていうふうに思うので、じゃあなんか僕もなるべくそういったことをやろうかなっていうふうに思ってるっていうのはあります。
たしかに。ちょっとそのマネージメントの失敗の最初のきっかけではあったんですけど、この面接面談っていうのをどのようにやってるかとか、すごいやっぱり興味ありますね、他の人が。
そうですよね。僕って、それこそ就活に失敗したみたいなのもあるし、中途採用、中途採証っていうか採用の最初の多分転職でもかなり苦労したので、
とにかく、それこそ採用面接とかでは相手に嫌な思いはさせたくないなっていう気持ちがすごくあるんですよね。やっぱそれは僕がすごいそれが嫌だったから、そういうのはないようにしたいっていうふうに思ってる部分が採用面接についてはありますし、
面談とかではそうですね、お互い楽しめるようにとか、あとそうですね、やっぱフィードバックとかで言うと、やっぱり結局フィードバックみたいなもので、結局お互いの認識のすり合わせだと思うので、
あんまりポジティブかネガティブかみたいなものはなくて、逆にこういったところが、例えばネガティブフィードバックみたいな受け取られるようなものであっても、こういったところが多分こちらとしては、こちらの期待に届いてなかったように思うんだけど、そこはどう思いますかみたいな。
このままの聞き方をしちゃうと圧が強いんで、そういう聞き方はしないんだけど、結局どっちが間違ってるかわかんないじゃないですか。こっちとしては期待に届いてないっていうふうに思う。けど、実は別のところで、当人としてはそう思ってないかもしれないし、こっちの多分期待してることが間違ってたかもしれないしっていうところはあるから。
結構そういったところは、対象性みたいなのは気をつけるようにしていますね。そういう面接の場とかであっても、やっぱりこっちが選ぶ立場でもあるし、選んでいただく場でもあるっていうところは、そういう対象性みたいなのは結構大事にしたいなって思ってるところではあります。
たしかに。給食者、働きたい人と働きに来てほしい側の対象性の大事さみたいなのは、ずっと自分自身がわりとHRのサービスに関わってきてることが多かったので、すごく今いい話だなと思ってました。
平等であるべきだよなって思って、それでお互いの表現の努力によって作られてるものも結構あるなって思いました。
すごく人事とか特に採用みたいなものってすごい怖いことなので、どういうことかっていうと、やっぱりどうしても人を選別する選ぶみたいな側面が出てきてしまうものではあるので、そうすると知らず知らずのうちにすごい傲慢になってしまう部分とか思い上がってしまう部分ってすごく出てきてしまう
危険性があるなって思っているので、やっぱり基本的にお互いが選ぶであるとか、こちらが選んでいただく部分もあるっていうことを本当に強く意識しないと、やっぱりすごくそういう思い上がってしまうリスクがあるところだよなっていうのは思うし、
たまにSNSとかで人事の人とかが炎上してるのって、そういう自我の被害みたいなものに起因するんじゃないかなっていうのは感じたりすることがあります。
すごく狂いやすいというか、すごくそれをそうではないっていうところで軌道修正していくのがいかに大変かっていうのはすごく思いますよね。
いや本当そうだと思います。
あれってお互いにお互いを選び取ってるなっていう世界ですよね、あそこは。
特にエンジニアの採用とかだとかなり売り手市場みたいなところもありますし、他の採用も結構ちゃんと厳選採用みたいなのをしていると、やっぱり内定をお出しした方が2社3社ぐらい他社の内定を持ってるみたいなことが普通なので、
そうするとその中からどう選んでいただくかみたいなところがすごく大事になってくるので、そういう意味でもやっぱり最終的にはちゃんと選んでいただくっていうのが大事だなっていうのはすごい思っています。
いやでもそうなんですね、人に興味がないとか、人の心がないとか、なんかそういうこと言う方がどうなのかという気持ちもするんですけれども。
好奇心とコミュニケーションの課題
全部ですね、言ってくれてありがたいっていう、逆にありがたかったんですけれども、そっか、でもそう思われる感じのことをしたんだなというのはですね、思いますね。
僕は逆になんか人に興味がないみたいなスタンスだったので、それこそ学生の頃とかまではそうだったし、人の心がない的なことを仮に言われたとしてもまあそうでしょうねみたいに思う立ちだったと思うんですけど、
ただなんか最近思うのは、僕結構案外人のことが好きだなっていうのをすごく思って、やっぱりいろんな人がいていろんな考えがあるっていうのがすごくあるし、僕としても好奇心みたいなものがあるので、なんかあんまり自分の幅みたいなものを狭めたくないから、あんまり何かを嫌うみたいなことをしたくないみたいなのがあるんですよね。
なので、あんまり本当に嫌いな人とか本当に受け付けない人は関わらないことが大事だと思うんですけど、本当にそうじゃなくて考えがちょっと違う人とかは、逆に面白いっていうか、ちゃんとそれを理解したいなっていうふうに思うことは多いですね。
たしかに。ソムさん、好奇心えげつないですね。強い強い好奇心の強さがいつもすごいって思ってます。
まあでもどうなんだろう、もっと好奇心強いというか、まあそうですね、なんかやっぱりまだいろんな方向に好奇心は持てるなっていうのは思ってはいます。でもなんかもっといろんなとこ深掘りできる人とかもいるからすごいなとは思ったりはしますけどね。
幅を広げる人もいるし、深掘ってる人もいるし、すごいいろいろですよね、やっぱり。
そうですね。なんかこうあるべきが強すぎることによる失敗みたいなことをおっしゃってましたけど、なんか僕も最初のほうテックリード的なものを任されたときは結構そういうところがあって、なんかこういうふうにしないといけないとかコーディングルールみたいなのとか、
ファイル構成とかそういうの結構しっかり定めて、なんでそうしないんだみたいなのがあったんですけど、逆にもうそういうのがなくなって、その時の反省があるんですけれども、逆にこうあるべきみたいなものを、
もともとそういうの持ちたくないって思ってるのはあるんで、逆になんか決めなさすぎて、なんかもっとなんか決めてほしいみたいに思われることは逆に増えたなっていうのはありますね。なんか逆に、なんかそのもう情報揃ってるんだから、
考えてほしいとか、わかるよねみたいな、そういう言い方じゃないけど、たぶんそういったところを期待しすぎちゃって、もうちょっとしっかりとこうあるべきとか、そういったものを示すのを怠ってしまってた部分、時とかはあるなって思うし、でも逆にちゃんとそこを示しすぎずにそれぞれがちゃんと考えて動いてほしいっていうふうに思う部分もあったりするので、
なんかそこがやっぱ難しいなっていうのは、今でも思うところですね。
OSS活動の体験談
森 理想はみんなが考えて、みんなで理想の状態を作り上げて、実装していくっていうのが、状態を導くのが理想なんですよね。もういつもそうは思っているものの、なんか特に私が初期の頃のこうあるべきが激しすぎたときには、もう圧倒的な型とか、このときはこのやり方でやるべき、これを出したものはバツ。
バツではないですけど、このくらいの感じでガチガチでやって、あと人間それぞれの頑張り方みたいなとか、時間の使い方とか、もううるせえやつだったなあと思いますね。
しかも忙しかったりすると、本当に性格悪くなるから、人間みたいな。そこでちょっとそういうプロジェクトのレールから外れたことをする人がいると、結構なんでそんなことするのみたいな感じのコミュニケーションになっちゃうみたいなのはあるので、本当そうならないように心に余裕を持っておきたいよなっていうのは感じるところですね。
やはり人間はやはり生き物なので、余裕とかキャパシティっていうのは体力、体だけじゃなくて絶対的に心にもありますよね。本当に思いますね。
めちゃくちゃありますね、本当に。でも僕もいいチームで働いてるときとか、そういうチームをマネジメントしてるときとかって、みんなに考えてもらうことで自分が想像してたものを超えてくるとか、そういったことがすごくあったりとか、自分だったらこうするけどなあみたいなのを、
でもメンバーの人が提案してきた方法でやってもらうと、こっちの方が良かったんだみたいな、僕の直感の方が間違ってたんだなあみたいな経験が何度かあるので、やっぱりそういう意味でもちゃんと自分でこうあるべきって思いすぎない方がいいなって思ったのがありました。
ちょまど それはすごい嬉しい体験ですよね。
おだしょー OSSやコミュニティ活動についてっていう次の話題を挙げてくださってますが、OSS活動したことがないって書かれてますけど、どういう感じなんですか?
ちょまど 全然したことがなくて、いつもありがたいなあと思って利用させてもらってますね。ちょうど今日、2週に1回ぐらい、タイニーゴーの読書会をやっててですね。
それを、著者の佐藤さんっていう方も参加してくださってる、超贅沢な読書会なんですけど、ちょっとその本を読みながら、タイニーゴーのこのコマンドのこの結果って、実は期待通りじゃないんじゃねみたいな、たまたまその話が出て、
これはコントリビュートチャンスでは、みたいな話をしていてですね。ちょうど自分の手元でビルドできるようにして、実際動かしてみて、ちょっと中のコードを読んでみたら、これは別にバグではなく、こういう仕様だから、この結果だよねっていうことがわかったので、そこは触ることはなかったんですけれども。
なんかこういうふうに自分で普段から手元で触ってみたいなことって、ちょっとやったほうが絶対楽しいよなと思っていて、でもなんで自分やらないんだろうなってたまに思ってますっていうのがあって、逆になんか佐藤さんがOSS、自分でも運用してますし、
あともしくは他のOSSで何かコントリビュートするときのなんか良かったなーみたいなことありますかね。
そうですね。なんかこうしたことがないっていうのも結構意外だなっていうのは思っているのと、あとなんかトライしようとしてるっていうのはやっぱり素晴らしいことだなっていうのは思いました。
僕の場合はそれこそ作ったものを迂闊にOSSにしてしまうみたいな、そういうのがあるっていうところもあるし、
あとなんかそうですね、いろんなOSSを使わせてもらう中で、結構コントリビュートできるチャンスってそれなりにあるなっていうふうに思ってるのと、
たぶん、やっぱり慣れてきてそういうのを見つけるのが上手くなってきたっていうのはあるんだろうなっていうのは思っています。それこそなんかこの週末っていうかこの前の週末とかもちょっとやってたこととしては、
テキストリントってあるじゃないですか。テキストリントをGitHubアクション上で動かすみたいな、なんかそういうOSSがあるんですけれども、最近僕ちょっと本を書いてるみたいなのがあったりするので、
それのリポジトリの中でテキストリントを使ったりとか、アクションテキストリントみたいなのを使っていて、ただ僕、あとVibrioStyleっていうそういうCSS組み班のOSSを使ってるんですけれども、
そのあたり、ビルドとか依存の構築を早くしたいので、BANっていうノードとは別のJSの処理系を使ってるんですね、僕が。ただ、僕がアクションテキストリントっていうテキストリントをGitHubアクションで動かすものについてはBANに対応してなかったので、
僕としてはBANに対応してほしいなって思ったので、そのプルリクエストを送ったっていうのがありました。それで、ありがたく取り込んでいただいてありがとうみたいなのがつい最近ありました。
そういったところでも、気軽にこういうのどうですかみたいなプルリクエストを送ったりとか、自分のユースケースにちょっと沿わないところとか、ちょっと足りてないところをとりあえずプルリクエストだったり、Issueとかで相談したりみたいなことは結構やるようにしてるみたいなのがありますね。
コミュニティ作りの重要性
大した。そういうのを聞くと、そういう気持ちで使っていくのがやっぱりいいんだろうなと思いました。
なので、そうですね。これも書いてくださってますけど、逆にコミュニティ活動みたいなのがめちゃくちゃミッチーさんフットワーク軽くいろいろやられてるので、そこは本当すごいなっていうのは思っています。
その秘訣はどういったとこにあるんですかね。
あれはね、不思議ですよね。なんかこう、3人以上集まればもう始まるかなって思ってるので、なんだかこう、集まってやりそうな雰囲気、匂いがしてきたらやろうっていうのと、そのやり始めるまでのこれとこれが集まると始まるよねとか、
あと異常に盛り上げる変なノリみたいなだけで生きてきてるので、たぶんエネルギーがあるんでしょうね。たぶん頭あんま使ってないからかな。
パッションですね、パッション。
僕はコミュニティ作りとか、そういう勉強会とか関わったことはありますけれども、やっぱりなんか、僕としてはそこはあんまり得意ではないなっていうふうに思って感じてますね。
なんかそういったところに行って話をしたりとか、その登壇したりする方がよっぽど気楽にできて、そういう形で貢献させていただくっていうことはできるけど、逆にそういう場を作ったりとかできる人、ほんとすごいなってのは思います。
でも、ソムさんとか結構ファシリテーターとかも素晴らしいので、ああいうコミュニティであったりとか、なんかカンファレンスとかで、なんかいてくれないとねってなる人ですよね。ほんとに思いますよね。
そうですかね。ありがとうございます。
思います。
いやでもそう、ただちょっと僕コミュニティ始めようかなって思ってるアイデアが一個あるので、もしかしたらその時相談させてもらうかもしれないです。
いいですね。ぜひぜひ。
私やってるやつは、大小問わずはあるんですけれども、なんか小さくても、そこに人が集まってたら、なんかこう細々とコツコツと継続するのはめちゃめちゃ得意なんで、もうそういうのは結構、あとはあれですかね、やっている人がなんだか楽しんでいるみたいなのが良さそうですよね。
いやほんとそうなんですよね。そうやってる人はやっぱ楽しくないと続かないみたいなところもあるし、あとやっぱりこう、なんか運営とお客様みたいな感じになっちゃうと、なんかまあそれで続いてるカンファレンスとかもあるけど、それよりかはなんか参加者含めてみんなが作り手みたいになるコミュニティがいいですよね。
いやー絶対その方が続きやすいですし、誰も辛くなってないっていうのがやっぱいいですよね。
まあなんかそうだな、あと会社でやるかとか、コミュニティ、そういうところでやるかみたいなところでまたその難しさみたいなところが変わってくるなって思ったりはしています。
確かに、会社はまた一定責任がありますね、出てきますね。
そうなってくるとやっぱちゃんとおもてなししないといけないみたいな、そういう話になってきちゃったりしますよね。
会社の看板を背負ってやるので、それはそうなりますね。
OSSを触って良かったこととか苦しみありますかっていうふうに書いてくださってますけど、これはどういったことを聞きたいですか。
OSSの挑戦と対応
ちょうど苦しみ、ずっとやり続けることの良かったことは多分ですね、いろいろあると思うんですよ、体験であったりとか。
ただ苦しみとか、よく歴史が物語っているじゃないですか、続けられなくなっているOSSであったりとか、巨大化することでもうこれ以上開発し続けることができませんとか、そういうのがあったりとか。
多分そういう葛藤ってどこかにきっとあるだろうなーって思っていたりとか。
あと事件もあったりしますよね。最近の藤原さんの件とかですかね、とても辛い話ですよね。悪い人が入り込んでくるみたいな、圧倒的な悪意を持ってきてるやつですよね。
そういうのとかって正直完全には防げないでしょうし、それでもやっぱりOSS全くやめるってやっぱりしなかったりするじゃないですか。悪い者への立ち向かい方みたいな気持ち的なものを聞いてみたいなと思った次第でした。
そうですよね。僕はブログとかOSSとかそういったもので辛くなったことはなくて、そこはすごく大事にしたいところだなっていうのはまず思っているんですね。
仕事って好きでやってても辛くなることって絶対あるじゃないですか。僕はあるんですね。別にここ10年とかって僕は本当に好きな仕事しか選んでないしやってないけど、それでも辛くなることとかって絶対あるわけですよ。
それって当たり前の話で好きなことって辛くなることありますよね。パートナーのこと好きでも喧嘩することになるしみたいな、そういうことだと思うので、好きだけど辛くなることはあるなと思ってるんですけど。
幸いブログとかOSSとかはそういった経験があんまりなく、本当に自分の好きなときにやるみたいな形でできてるので、僕としてはなるべくそれが維持できるようにしたいなっていうふうに思っています。
多分それもあんまり締め切りだったりとかタイミングとかそういったものが急かされるようなことがなくて、自分がやりたいタイミングでやるみたいな形で活動できてるのがやっぱり良いなっていうふうに思っているので。
だから逆にもうちょっと社会的な責任が強い、もっといろんな人が使ってるOSSとかをメンテナンスするときに脆弱性とかがあったときに早く対応してくださいみたいな話だったりとか、いろんな意見がやってきてそれを取りまとめるのに苦労するとか、そういったことになってくると辛くなる可能性はあるなと思っているので。
そういったところになるべくそうなりたくないなって思ってるみたいなのはありますね。あとやっぱOSSで結構辛くなる人みたいなのはなるべく減らしたいなって思っているので、でもなかなかそれは難しいなって思いますね。
逆に責任感とか感じすぎないほうがいいというか、っていうのはすごく思っているので、そういう意味では僕としてはあんまり放置してるOSSもたくさんありますし、逆に自分が使いたいなっていうOSSでメンテナンスが止まってたらメンテナンスを引き継ぐみたいなこともありますし、みたいな感じでやってはいますね。
最近だと一つ、去年末とかにテキストマークダウンディスカウントっていう、これはパールのモジュールですけど、それのメンテナンスを引き継ぐみたいなことをやったりはしました。
なので、基本的に楽しくOSS活動はできてるんですけど、やっぱり今日藤原さんが公開してたような、マルウェアの偽物を作られたので、自分のOSSのマルウェア入り偽物を作られたので通報したみたいな、こういう話があったりすると困っちゃうなっていうのは思ってますね。
なんか、それこそサプライチェーンアタックみたいなのも、なかなか無視できないものになってきて、もともとすごく生前説前提でやって、コミュニティが広がる楽しさとか、より良いものが作れる良さみたいなのがOSSの世界にあったはずなのに、結構そこに悪意がいろいろ入ってくるみたいなところが増えてきてしまっていて、
割とそれでいろいろやりづらくなったりとか、ガチガチに固めなきゃいけなかったりとか、逆にそれこそ、やっぱりOSSの世界って信頼が大事っていうのがまずあるとは思うんですよ。
だから信頼があるメンテナーとか、信頼があるOSSデベロッパーみたいな人の影響力があるとか、そういった人のパッチが取り込みやすいみたいなところはあるので、ちゃんと信頼を積み重ねるのは大事っていうのはあると、やっぱり新しい人がゼロから始められるとか、そういう良さとか敷居の低さみたいなのがあると思うので、
ただ逆にこういう悪意のあるような話が続いてしまうと、例えばまだOSSの世界で信頼がない人はコミットできませんとか、そういう方に話が行き過ぎてしまう危険性がはらんでるなとも感じているので、やっぱりそういうことにはならないようになってほしいなっていうのは最近すごく思ってるところですね。
こういう犯罪の、前衣の集団に対するところに付け込んでくるってあるんですけど、だいたい歴史上はどうしてもそこに対して防御的な、コミュニティは防御的な姿勢をとらざるを得ないみたいなことになりがちではあるので、
なんかとはいえ、今後どのうまく左右するのか心配ではありますけれども、いい落とし所つくといいですよね、今後ね。OSSな。しかもOSSを使いましょうという側にも今度審査が入ったりとかしてまた大変になりそうですよね。
そうですよね、本当に。僕とかOSS発掘するみたいなの好きなので、結構GitHubとか検索して、こういうのないかなとか、今こういうライブラリ欲しいからないかなって言って、わりと見たりとかしてちょっと試しに使ったりみたいなことを結構しているので、
そういったときもちゃんとソースコード読み込んだりとか、なんか怪しいことしてないかっていうのを確かめてから使ったほうがいいなっていうのを今日改めて思ったのと、それ結構世知辛いなって思ったのと、その辺結構AIとかに診断させられないかなっていうふうに思ったみたいなのがありました。
そうですね。いい話としては、AIちゃんがだいぶ賢いので、結構そういう辛い作業を彼らやってくれますよね。
やってくれますね。
いい話だ。
なので、そこは結構AIに判断してほしいな。そういうの確か作れるかもしれないし、みたいなのを思ったりはしました。
チェック機構はAIがいい感じにしてくれるんじゃないかな、できそう。そんな気がします。そう考えると辛いことばかりではないですね。
そうですね。そう、期待したいなっていうところですね。
編み物の楽しみ
じゃあ、あとは最近ハマってること。編み物の話をしますか。
そうなんですよね。ちょっと最近、私結構パソコンに向かっている時間がやたら長いので、ちょっとそれ以外のこともするかって思っていて。
本当は運動をしたりとかね、すればいいのに、なかなかそこに意識が向かなくて、なぜか編み物をはかどってるって話ですね。
難しいことはあんまりできなくて、割と流れでやってることが多いんですよね。
YouTubeを聴きながらとか、そこでひたすらなぜかハンカチを量産してます、みたいなことをしていて。
編み物をするために道具が実は必要で、売ってるんですけど。
例えば今、段数を積み重ねていくんですね。1段、2段、3段。それが60段、70段ってなってくると、数えられなくなってくるじゃないですか。
なのでこれを、今自分が何段目ですっていうのをわかるアクセサリーみたいなものがあるんですけど、それも自分で作ろうかなと思っていて。
ペンチとか買ってきて。もともと電子工作が好きなので、ラジオっぽいペンチとか山ほどあるんですけど、そうではなくて、
アクセサリー用のペンチを買ってきて、ステンレスのちっちゃい丸いものをうまくねじ曲げて、自分でカウンターを作って楽しんではいるんですけども。
本当は肩こり防止のためにPCから離れようかなと思ってるのに、より肩がこるようなことをしてるっていう話です。ただ単にその話です。
おもしろい。目数カウンターを作ってるっていう、なんかあれガシャンガシャンってやるやつですよね。
ガシャンガシャンってやるやつだと重くて嫌なんですよ。なのでリングを連ねて、そこに数字のパーツみたいなのをつけて、それで今何段目かっていうのを棒に引っ掛けるんですね。
それを10段分、10連分つらねたものを、本来は多分おそらく何かしらのアクセサリーのパーツになってるものを、アクセサリーではないものに勝手に自分で置き換えて作ってるって感じです。
へー、おもしろい。そういうツールを自作するの面白いですよね。自分のためだけであってもみたいなの。
誰かのためではなく、ただ自分がひたすら使うだけみたいな感じののが楽しいですね。
僕もなんか、OSSも本当にそういう自分のために作ったものを別にソースコードを公開しても問題もないから公開してるだけみたいなのがたくさんありますね。
わかります。
ホラー小説の魅力
あと怖い話が好き。
これはですね、普通にただ単に怖い話、怖い小説とかをただただ読んでますっていうだけですね、本当に。
もともとホラー映画とか、あとホラー小説がめちゃめちゃ好きな絵、ずっと読み続けてる人で。
で、最近読んでるのはどちらかというともっとライトな感じで、
そんむじさんだとご存知だと思うんですけど、2チャンネルって昔あったじゃないですか、5チャンネルになる前の。
そこにオカルト板っていう怖い話ばっかり書かれている板があってですね、そこに載ってるようなネタが小説になってるっていう本が
昨年とかかな、流行っててですね、それを喜んで読んでます。
日本製の小説ですね。
何だっけな、作者の名前が瀬須寺さんっていう人とか、
瀬須寺さん。
はい、とか、あとなしっていう人、っていう方の割とライトな小説を夜中に読んで楽しんでます。
そうなんですね。なんかホラーとかだと、なんかどういうのが昔のやつとかだと好きなんですか。
昔の、本当に大昔のやつは、うげつ物語とか。
ああ、うげつ物語。古典の。古典だ。
そうじゃなければ、なんだろうな、スティーブンキングって小説家の方がいて、その方の書く短編小説とか長編もですけれども、好んで集めてますね。
ああそうか、スティーブンキングもそうか、それこそあれか、なんだっけ、シャイニングとかそういう。
映画も好きなんですけど、小説のなんだかとても長い、長いというか背景がしっかり書かれてる感じがすごく好きですね。
ホラー小説か、僕なんか全然読まないんですよね。
京国夏彦とかがすごく好きで、ミステリーとかぼちぼち読むんですけど、それこそ本当に純粋なホラーとかは、そうですね、あんまり読んだことがない気がしますね。
それこそ、僕がよく本読んでた時だと、小野冬美さんの四季とかが結構、多分結構読まれてたと思うんですけど、僕はそう、読んでなかったりします。
怖い、怖いなぁみたいなやつ、割と好きで、小野冬美さんも何回か読みましたね。
今自分の家の本棚をちょっと見てるんですけど、前はすごい本を買ってて、家が狭くなったので一回電子に移ったんですよ。
ところが、なんか目が、わかんないんですけど、老眼が辛くなってくると電子で読むのも辛くて、その後なぜか紙に戻ったんですね。
そうするとまた本棚が狭くなってきてますって感じですね。
電子書籍の課題
いや本ね、僕も本当、紙の本、そう実家にいる頃はすごいあったので、もう結婚する時にもうほとんど嘘を処分しましたね。
それこそ漫画は全部処分したしっていう感じで、そこから基本的にはそう、電子派で何とかやってて、
たまに紙で買ったやつもあるけど、ちょっと積まれちゃうけど、そんなに圧迫するような感じにはなってないっていう感じです。
ただちょっと最近子供の本とかが、子供が結構本読むので増えてきて、これがどうなるかっていうのは思ってるところですね。
でもお子さんが本読みたいのとかは止めたくないですもんね。
そう、あとやっぱり今の電子書籍とかのソリューションって全体的に商業のものとかってあんまりレンタルっていうか個人間レンタルみたいなのがやりづらかったりするから、
子供にそれを読ませるみたいなことができないのは本当困るなっていうのを思ってます。
そうですよね。この本買ったからこれ良いからあなた読んでみなさいよみたいなのができないんですよね。難しいですよね。
これは難しいとこだなと思ってます。最後にちょっと軽く、ドキュメントリライアビリティエンジニアリングっていうのの話をしたいんですけど、
なんか、これは今はてなで、多分マカレルのCREをやられてるMUTOさんっていう方が書かれたブログで、この方もともとかなり技術省の編集とかもされてた方なんで、
あとあれですね、そのリビューっていうものを作られた方なので、かなりそういうドキュメントシステムとかドキュメントに関する造形が深い方なんですけど、
その方がこういう、とにかくそういうプロダクトをよく理解しているライターとかエンジニア的な人がそういうのをしっかりやるといいんじゃないかみたいなことを書かれていて、
なんかこれすごいこう、そういうのあるよなっていうのは思ってますし、なんかそれこそ、メルカリさんとかはそういう技術ライティングするような人たちがいていたりするんじゃなかったんでしたっけっていうのを思ってるんですけど、そのあたりってどうなんですか。
ちょっと私ですね、今の現状のことは実は知らないんですけれども、技術ライティングのプロの方とかは、私がメルペイに在籍してたときはいらっしゃいましたね。結構ドキュメント、とても大事だと思いますね。
むとうさん、私結構レビュー使ってるので、お世話になってますっていう感じなんですが。
これ、今このブログで書かれてるのとかを見ると、本当に重要で、会社としてもこういった方がいるかいないかで、アウトプットの質そのものが変わっていきそうだとは思いますね。
私今、セールスの組織にいるので、エンジニアリングの世界で作られたプロダクトの仕様だったりとか、これはこういうルールで作られています。これはこう運用するものですとか、そういったドキュメントであったりとか、内部的にも外部的にも、信頼を受けるものであるべきでしょうし、かつ更新性みたいなの、とても大事ですよね。
ここの運用って、めちゃめちゃ難しくないですか。私、どこの組織にいても、いつもここ難しいなと思ってますね。
いや、めちゃくちゃ難しいですよね。そこにやっぱなかなか専任の人を当てられないっていうところもあるし、でも、専任の人を当てるにしても、ちゃんとソフトウェアエンジニアである必要があるというか、そういうところもあるので、
そういう意味では、ちゃんと開発チームの人がちゃんとドキュメントを書きつつ、全体の構成というかデザインというか統括する人がやっぱりいた方がいいよなっていうのは思いますね。
なんか結構バージョン管理みたいなのもちゃんとしないといけないし、ここをいじるんだったら、ここもいじんないといけないよねみたいな、それこそソフトウェア的な話とかもすごくあるし、あとなんか結構仕様みたいなのだけを書くんじゃなくて、これは何のための機能でどういうふうに使ってほしいのかみたいなところをしっかり書くの大事だと思うんですけど、
なんかそこをうまく書ける人ってなかなかいないよなっていうのは思ったりするところですね。
あのドキュメントのオーバービュー欲しいですよね。ファーストビューのところに、これは何のためのものなのかどういう位置づけなのかがあってこそのその下の章が来るみたいな。
あとは更新性と構成、みんなソフトウェアの開発をしていて、ソースコードの構成とかみんな大好きじゃないですか、そのところに関する議論。更新性とかドキュメントやって同じやんって思ったりはしますね。
ドキュメント管理の重要性
それはめちゃくちゃ思いますね。し、結局みんなかなり苦労している気がするし、そうですよね。やっぱり僕としては全部何らかのテキストファイルで管理してバージョン管理すべきだと思っているんですけど、
なかなか、それこそドキュメントを書く人とかがエンジニアじゃなかったりとか、ちょっと違うシステムみたいなものを使うときになかなかそれが実現しづらいみたいなところがあるので、
結構ちゃんとそこもエンジニアチームで開発で一体となって取り組んでいくべき課題ではあるけど、ついアウトソースされがちで困っちゃうねっていう話ではありますよね。
そうですね。ドキュメント、これ完璧だなって今までなったことなくて、私前職のカウシェで開発してたときは、大元のドキュメント、デザインドックはノーションで書きますが、
それは割と一家製のもの、マスターにはないので、必要な仕様をシーケンスみたいな形でMermaid.jsで書いてGitHubで管理したりとかしてたんですね。
ただもうないよりは全然良くて、ないよりは全然いいんですけど、まずシーケンス図を書いてGitHubで管理できる人はエンジニアのみになるので、今度方針できる人が限られてくるっていうのもあるので、良きとしては良きなんですけれども、ちょっと痛いし悔しいみたいな感じではありましたね。
そうなんですよね。なんかGitで管理したいっていうのも、かなりエンジニアのエゴだなって思う部分もあって、ただそうしたいよなっていうのはあるけど、やっぱバージョン管理みたいなものがかなり多くの人にとって難しいんだなっていうのはすごく思うところなのと、
確かに考えてみたら、そういういろんなブランチがあって、作業ブランチがあってメンテナンスしていくみたいなのってすごく難しいなっていうのは思うので、それこそ結局多くの人はファイルとかワードとかをいじるときは一旦コピーを作ってみたいな、そういう感じになりがちで、
そのあたり、あと差分の見方みたいなのもあんまり意識してない人も多いというか、そういうディフを見たいとかバージョン管理したいみたいなのがすごく特殊な人たちの、エンジニアっていう特殊な人たちのマインドセットだなっていうのをすごく思うけど、やっぱそうやりたいよなって思いますね。
だからノーションとかが履歴とかすごいいけてないと思うんだけど、実はあんまり多くの人はそこに課題意識を感じてないっていうか、たぶんあんまり結構ちゃんとした履歴管理機能みたいなのを作ったところで、たぶんあんまちゃんと使う人がいないんだろうなっていう、だからなかなか開発されないんだろうなっていう、ちょっと僕としては悲しい自己完結してるところがあります。
でも履歴、欲しい人やっぱり欲しいみたいで、例えばやっぱり今あるこのヒトセットのリリースの塊はどういう意思決定をされてきて、誰が何をどういう理由で変更して、今ここにあるみたいなやつって、やっぱ残したいんですよね。
それを本当は、たぶん非エンジニアの人も残したい種類の人たちって結構いて、ただいけてないツールだったりする。いけてるツールがあったとしても、それをいい感じで使いこなせないので、ひたすら履歴をスプレッドシートで書いてるみたいなケースもやっぱありますし。
でもとってもつらいんですよね、それって。なんか完璧になってない、なんかいいソリューションってどっかで出てこねえかなって思ってますね。でもそうなんだよな、コンフルエンスとかも結構多くの企業が導入してるドキュメントのツールだと思うんですけど、あれも健康履歴めっちゃ取ってくれますけど、だから何っていう感じの偏向履歴になっちゃうんですよね。
そうなんですよね。だからちゃんと塊で更新をちゃんと管理したいですよね。多くの人は理解できれば絶対それがいいって思うと思うんだけど、なかなかそこまでなんかにたどり着かないっていうのと、そういう体験が与えられるツールがないから、なかなかそういうところに行かないし、
ソフトウェアエンジニアはソフトウェアエンジニアのマインドセットで考えようとするし、みたいなのがあるなとは思ってます。ただなんかやっぱりGitHubとかでマークダウンとかをバージョン管理するのがやっぱいいんじゃないのかなっていうふうに僕はやっぱ思っちゃいますけどね。
そう、すぐ思っちゃいますね。たぶんGitHubでバージョン管理されたものがどこかでわかりやすく見れるであったりとか、なんかGitHub、Gitの仕組みからわかりやすいもの、Gitの仕組みからGitHubっていうのがあって、あれエンジニアが理解しやすいものであると思ってて、
あれがデザイナーであったりとか違う職種の人にわかりやすい何かで見られるUIとかがあると、もしかすると変わるかもしれないですよね。
そうですよね。そういうドキュメントシステム、欲しい。スフィンクスとか、やっぱり結構使ってる方結構いますけど、なかなか上手くいってるの見ないなって思いますし、それこそ僕、さっきリビューの話が出ましたけど、リビューとかってすごく技術書籍とか技術同人誌書くのにすごい使われてるツールだと思うんですけど、
ビブリオスタイルっていう、これはマークダウンで書けて、CSSで組み込んできるっていうやつなんで、機能的にはリビューのほうができることもまだ多いのかもしれないんですけど、かなり僕の中ではすごい気に入っていて、今使ってて、
これはそれこそウェブサイトにもできるし、EPUBにもできるし、PDFにもできるし、みたいな感じなので、そういったもので上手いこと、上手くドキュメントとかを見せられると嬉しいよなっていうのは思ったりはしています。
でも結局、どうしても古くなっちゃうものみたいなのがあるから、その文章って、いつ古くなるかみたいなのって難しいですよね。いつ古くなるかのトリガーがいくつかあるなっていうのを思っていて、一番わかりやすいのは時間なんだけど、半年後にこのドキュメントアウトデイティットになりますみたいなのがある。
逆にこの技術を使わなくなったとか、この人が退職したからとか、この人が移動したからとか、そういったところで変わるものってあるじゃないですか。そういうのをなるべく排除して書こうとは思うんだけど、排除しすぎると逆にめちゃくちゃわかりづらくなるみたいなのもあるから。
だから社内ドキュメントとかも、すごい今は使われてないツールを前提にしたドキュメントみたいなのがまだ残ってたりとか、そういうのっていつドキュメントが腐るのかみたいな、そのトリガーってすごいたくさんあってむずいなっていうのは思います。
AIと文書作成の未来
あかります。そんなのだらけだ。なんか、昨年の3月に作られたドキュメントだから新しいと思って読んでいたら、昨年の7月に作られたバージョンのドキュメントが実はあって、私が見ていたものはもう過去のものだったみたいなことはありますね。
その辺も、AIがいい感じにしてくれると嬉しいかもしれないな。でも文を書くっていうのは僕好きだから、そこの楽しみをAIに奪われすぎたくないなと思いつつも、やっぱめんどくさいことだるいことはAIがやってくれるといいなっていうのを思っています。
そうですね。でもAIちゃんは構成とかしてくれますしね。
そうですね。そんなとこかな、今日は。いろいろお話できてよかった。だいぶ長くお話できて楽しかったです。
ありがとうございます。私もめちゃめちゃ楽しかったです。
はい。ということで、趣味でOSSをやっているものだは、今回ミッチーさんをゲストにお迎えしていろいろお話しました。ありがとうございました。
ありがとうございました。
01:00:53
コメント
スクロール