00:01
こんにちは、言語化.fmです。このポッドキャストでは、いろんなトピックを言語化していきます。
はい、というわけでですね、第0回目なんですけど、
始まりました。
始まりました。よろしくお願いします。
最初、自己紹介からやろうかなと思いますが、
ソフトウェアエンジニアのキリンです。
キリンと
ソフトウェアエンジニアの伊達です。
よろしくお願いします。
よろしくお願いします。
めちゃくちゃぬるっと始まったんですけれども、
言語化.fmって何やねんみたいな話を、
最初にしようかなと思うんですけど、
もともと僕がやろうみたいなことを、
ポッドキャストっていう形じゃなくてもいいかなと思ったんですけど、
ちょっと考えていて、何をやりたいかと思ったかっていうと、
僕たちソフトウェアエンジニアとして働いてきて、
多分、何年目だ?5、6年目?
そろそろ中堅と呼ばれてしまうところまで来て、
それなりに自分の仕事をしたいようにできるようになってきて、
その過程で結構、
自分が仕事しやすい人と仕事をできるようになってきたがゆえに、
言語化能力があまりなくても、
コミュニケーションが成り立ってしまう場面が増えたなと思っていて、
具体的に言うと、例えば、伊達と僕はまだ、
まだっていうか、職場は別に一緒じゃないんですけど、
多分このことどうしようみたいな話をした時とかに、
めちゃくちゃ詳細に説明しなくても、
ちょろちょろって話して、それで良さそう、分かるみたいなので、
多分成り立っちゃうみたいなのが結構よくも悪くも多いなと思っていて、
その中で自分の言語化能力の衰退を感じたわけなんですよね。
どうしようかなみたいな話を、
中野伊達君と一緒にドライブしながら話してて、
ポッドキャストで消化するといいかもねみたいな話になって、
やり始めたというのがこのFFの趣旨でございます。
もうめちゃめちゃ言語化されてんじゃん。
このポッドキャストに関してはね、
僕が風邪をひいたせいとかで、2ヶ月ぐらい温めすぎたみたいな、
ちょっとお待たせしすぎたものなんで、結構噛み砕いてこれてる感がある。
寝ながらアルセウスやりながら考えたらこんな話になったって感じだよね。
そうそう。ずっとアルセウス、ポケモン捕まえながら、
どんなポッドキャストにしようかなってきちんと思いを馳せながらね、
03:00
準備をしてきましたという感じですね。
でもいざ言語化しようってなると、何を言語化しようかみたいな感じになりそうだけど。
そうね。
なんかどういうトピックがいいんですか?
そうですね、いくつか仕事をしながらとか、人生を過ごしながら思いついたことはメモしたりしてるんですけど、
結構いろんな話があるかなと思ってて、
例えば仕事の話だったら、何でしょうね、最近考えてることだと、
いいチームって何なんだろうみたいな話をきちんと言語化できてないよなとか、
すごいディテールな話で言うなら、コーディングの話とかでも、
いろんなまさかに飛んできそうですけど、読みやすいことって何だっけとか、
いいソフトウェアエンジニアって結局どういうことなんだっけとか、
その辺りをきちんと言語化したりしたいよねとか、
あと仕事の話じゃなくても、何でしょうね、
人生の中で、例えば個人的には結構エンタメが好きなんですけど、
エンタメが楽しいのって何だっけみたいな話とか、
あと何ですかね、人生を過ごす上での命題?
分かんないけど、何だろう、分かんない、
多分共通、全員の共通的なものではないけど、
伊達さんは何のために生きてますかみたいな言語化するとかも、
もしかしたら、
面白いかもなとか、いろいろ話せればなと思ってる感じですね。
なるほど。
伊達さんはどうですか?
そうですね、
なんか冒頭にもあったけど、
我々中研エンジニアが抱える悩みって大体仕事の話と、
人生の話じゃないけど、生活の話とか、
割と似通ってくるよね、年も近いっていうのもあるけど。
そうね、
大体な、飲み会とかも、
なんか5年前とかは、
この言語が熱いとか、このライブラリが熱いとか、
このパラダイムが熱いみたいな話とかをめっちゃ熱心にしてた気がするけど、
最近なんか採用化、組織作り化、
資産運用の話しかしてないみたいな。
ちょっと偏ったコミュニティー説があるけど。
そうなんだね。
なんかそういう、駆け出しとまではいかないけど、
エンジニア始めて2,3年くらいとかに抱えていた、
技術がわからなくて、この先どうしていいかわからない問題みたいなのは、
割と遠に乗り越えているので、
06:01
次に打ち当たる壁としては、自分の所属する組織の、
組織の最適化とか今後のあるべき姿みたいな話みたいなのは、
どうしても打ち当たってくるというか、
みんな最近ずっと組織の話してるなっていうふうになりがちだよね。
なりがちだね。
それでいうと、今一つ自分の中で言語化したんですけど、
なんか扱う問題の抽象度が年々上がってる感めちゃくちゃ感じないっていう。
めっちゃわかる。
わかるし、事前に書いといたトピックでもあるけど。
書かれてた。
なんていうか、自分が解いたことがある問題、
それが今までは技術の問題が多かったんだけど、
技術の問題は今でも打ち当たるところはあるんだけど、
ある程度解き方わかってるし、解けちゃうともう、
それってあんまり意識して考えないんだよね。
割と僕は無意識化で解いてるとよく言うんだけど、
無意識化で解いてると問題が解いたことすらもそんなに気にならないというか、
問題にぶち当たったことすら認知しないのであんまり取り上げられないけど、
組織の話とか、そういう抽象度の高い話って、
自分の持ってる知識だけで解くことって結構難しくなってきて、
問題をうまく分析して分解していくと、
自分の持ってるスキルセットと合わないところが絶対に出てくるので、
そうするとそこに対して角度の高い解を持ってる人と一緒に考えていくみたいな作業が必要で、
それがまさにチームと呼んでいるところなのかなと思ったりするわけですよ。
なるほど。めちゃくちゃ分かるボタン連打してる。
そうね、問題の分析めちゃくちゃ肝だなっていうのは思う。
めちゃくちゃ抽象度高くてかつでっかいボールが振ってくることが多くて、
たぶんそのまま立ち向かうとどうにもならないというか、
なんだろうな、例えばキンキンだと仕事話になってしまうが、
会社とかで今やってるのとかだと、中長期を見据えた開発チーム、
内社システムの基盤を作るためのチームを作らなきゃいけないみたいな、
めちゃくちゃデカい抽象度の高いボールがあって、
これを多分素直に基盤チーム作るぞみたいにやっても何も前に進まなくて、
それってどういうことなんだっけみたいなのを考えなきゃいけなくて、
たぶん普通のエンジニアリングの問題と全然違うのは、
変数の多さが圧倒的に違う感を感じていて、
09:01
この組織でこのメンバーだったらこういうのがいいけど、
今の自分のチームで今のこのメンバーでこの規模感だったらこれがいいよねみたいなのとか、
またその事業自体も変数になるし、そこにたぶん時間軸も絡んできて、
3ヶ月後にこうなってたりみたいなのがどうなのかっていうのでも、
価値調べも違ってくるし、難しいなっていうか、
そうですね、課題のないの上がってるなっていう。
そうね、たぶん今までエンジニアとして解いてきた技術的な課題っていうのは、
もう問題がそもそも明確だし、
今の言語開発環境とかいろんなツールの状況とか、
解を当てはめやすいんだよね。
とりあえずこれが正解でしょ、今の現状ここがクソだからこうすればいいでしょっていう、
一問一答形式みたいな感じで問題解いてくれたんだけど、
組織とかそういうチームの人間の問題が絡んでくると、
一回これでいけそうだなと思って出した回が当たってるかどうかがまずわからないので、
とりあえずこれをやってみようって当てた回を経過観察する必要があるんだよね。
すぐに問題が解決されるもんじゃないから、
経過観察して解決されたかどうかっていうのを定期的に見なきゃいけないとか、
あとは問題の形が放置してるとだんだん変わっていくこともあるので、
前にこういう同じような問題があって、こういう玉を打って解決できたけど、
次回はそれもいかないみたいなことがあるので、
抽象度が上がって難しいっていうのは、
問題がそもそもシンプルじゃねえっていうところに気をつけるんだろうなと思ったりしますね。
おだしょー 確かに。おっしゃる通りですね。
経過観察大事だな。システムと一緒やな。リリースして終わりじゃないぞじゃないけど。
しばやん まあそうね。システムはログを入ってくれたりアラート上げてくれたりするけど、
やっぱ人間はそうじゃないので。
おだしょー なんか人間難しいに危険する気がするな。
今話を聞きながら思ったのは、システムはそもそも01の世界から成り立っているものだからっていうのもあるけど、
システムに限らずいろんな問題に対する解決策というか公式みたいなものって、
パッとは思いつかないけどいろいろ突き詰められてるなっていう気がする一方で、
組織とかチーム作りとか人が絡んできたところに対する、
12:04
人が絡む問題に対する公式みたいなものっていろんなモデルはあるじゃないですか。
アジャイル開発とかスクラム開発とか、
最近読んだ本だとユニコーン作り方みたいな本にはスクラムは古いみたいなのが書いてあったりして、
こういう形とかこういうマネジメントがいいみたいな、
いろんな抽象的な問題に対してある程度モデリングしてこういう解決策がいいみたいなのが転がってきて、
一定有用だなと思う一方で、
基本的にはそのまま当てはめて同じ結果になるってことはほぼなくて、
なんでかなーって考えると、
人はそれぞれみんな違うからみたいな気持ちになりました。
よくある話だけど、
他の会社でこれを使っているらしいという話で、
スクラムとかもまさにそうだけど、
他の会社でスクラムやってるからうちでもスクラムやってみようっていうフレームワーク先行型で取り入れてしまうと、
だいたいうまくいかないし、
なんでうまくいかないかをうまく分析できないっていうのは多分あって、
それは単純に順番が逆ってだけの話で、
何がチームで問題になってるんだっけからちゃんと拾い上げていかないと、
正しいフレームワークは選定できませんよっていうのは、
これは普段エンジニアやっててもそうだよね。
設定もまさに同じかなと思いますな。
確かに。
それで言うと整理するとあれやな、きっと。
抽象的な問題があったときに、
一定すでに転がってる事件とかをインプットするのは大事という話は、
基本的な話としてありつつ、
問題分解とか分析をきちんとしましょうね。
ただその精度は多分ほぼ100パー出せる人類が現状いないはずで、
基本的には何かしらがうまくいかないからうまくいかなかったときの原因を吸い上げて、
またその一瞬に対して打ち手を打ってっていうのを繰り返していこうねというような感じなのかな。
まあそうなるんだけど、
そんなことができてたら苦労しねえよって話があるね。
本当にな。そうだね。
そうだね。マジでな。
なんていうか、
個々の人間が抱える問題を根本的に解決するというのは多分無理で、
そういったフレームワークを導入することで、
15:04
そこに属する人々の意識を別のものに向けるということは多分可能で、
だからチームがギクシャクしていたとして、
それが本当は特定個人の振る舞いにすごく問題があったとして、
根本解決はその人に改善を促すか、組織から追放するとか、
まあそういう怪奇な選択肢も取れるわけなんだけど、
そういうことをやっていくと全く危機がないので、
そういうチームの状況を改善するために特定のフレームワークを導入して、
今JazzClubでうまくやっていって、
メトリクスを個人に向けるんじゃなくて、
チームのパフォーマンスに向けるみたいな問題の育ち方は多分取れるんだろうなと。
確かに。そうだね。
組織で働く以上はチームが全てとまでは言わないけど、
基本的にはチームの生産性が大事だからな。確かに。
そうね。その辺ひっくるめても経験値的には、経験則的には、
多分そういうのコミュニケーションに全部帰結していて、
本当は問題がある個人っていうのは存在しないんだけど、
なんで問題があるかってみなされるかっていうと、
組織のトップマネジメントをやってる人たちと、
意見なり方針が合わないっていうことだと思うんだよね。
だって別に絶対知的に正しいなんて別にないわけであって、
誰かから見たときに何かずれがあって、それが自分と向いてないから
意見が異なるとか、正しい正しくないっていう価値判断になるので、
それは多分組織の中で向いてるベクトルが違うって話になって、
その向きを揃えていくには、そのトップ層からきちんとメッセージを発信するとか、
ちゃんとワンオンしてお互い何を考えてるか払わるとか、
そうやって徐々にベクトルの向きを揃えていくって感じなので。
確かに。
いやー、究極一人で開発してたら別にその人自体何も問題はないもんな。
そうそうそう。
なるほどね。めっちゃ大人になったな、なんか。
そうなんだよ。やっぱ子供のさ、時のコミュニティと全然違ってさ、
小中高、大学もそうだけど、自分が好んでその人と同じ学校に入ったわけじゃないっていうコミュニティがあって、
18:03
全然会わない人とかもいるから、そういう時って基本、距離を取るあんまりできないけど、
嫌な人との付き合い方を嫌でも学ぶわけじゃん、コミュニティの中で。
で、会社に入った後とかこういうエンジニアのコミュニティとかもそうだけど、
嫌な人とは付き合わなくていいっていうような風に変わるじゃない。
変わるね。
それでも特にスタートアップなんてそうだけど、初期メンバーなんて人数少ないから、
もしね、俺はあんまりないけど、もし初期面の中で会わない人が出た時にどうするかっていうと、
小中高と同じように嫌な人と付き合うためのコミュニケーション術を発揮することもあるんだけど、
それだと組織的にはやっぱりパフォーマンスが出ないとかになっちゃうので、
それをどう解決するかっていうので、今みたいな話があるかなって感じかな。
なんかちょっとどこの組織で聞いたか忘れたけど、会社って家族じゃなくてチームみたいな話が多分あって、
まあ分かんない。会社によっては家族的にやってるところもあるかもしんないけど、
なんかその話に通ずるとこがあるのかなって気はしたわ。
別になんか一緒にバーベキュー行けない中でも仕事が一緒にできて、
1たす1が2以上になれば組織としては正解というか、そのためのアプローチは取るべきだよねって気はするわ。
そうね。まあでもこういうのはやっぱりエンジニアの持ってるソフトスキルとはやっぱり別なところがあって。
そうですね。
そうだね。
会社内調整と呼ばれるやつとかもまさに全部そうだけど、
人間同士のマネジメントが得意なわけではないと思うんだよね。
みんなどうやって身につけてるんだろうな。
なんかやって覚えてるのかな。
やって覚えてんじゃないかな。
私はこうやって身につけましたの。お便り募集したよ。ラジオじゃなくて。
ハッシュタグ言語界FMでツイートした。
いやーめっちゃ怖い。一見もなさそうやな。
シンプルに気になるな。まあなんか勉強したとか、いろんな場所で経験を積んだとかなんだろうなって気はするけど。
でもなんか一つの組織で経験積んだところで、超余ったある変数の組み合わせの一つを解いただけだから、
それを他の場所に活かすみたいなのがまた別の能力な気もするな。
そうね。なんかその組織における最適解って局所解でしかないから、
21:03
いやていうか局所解しか出しようがないので、
根本的に人間ってどうあるべきかみたいな話になっちゃうから、
人間とはこうするのが三大法則ですみたいなのはやっぱり難しいと思うんだけど、
それでも最悪の結末にならないように持っていくみたいなのは多分あると思うんだよね。
人間関係が完全に破綻してチームが機能不全に陥るとかは、
それは事前に防ぐ術がいろいろありそうだなっていう経験としてあるかな。
なるほど。知ってる落とし穴を回避する的な感じのか。
そうそうそうそう。
うんうんうん。なるほどね。確かにそれはあるな。
落とし穴を回避していく。いやー、なんか経験があるようなないような気がするわ。
なんかそういう体験であったかなと思ったけど、別にないんだよな。
本当に。俺はなくはないかな。
それこそあれだな、エンジニアを始めた頃は自分も人間的にも技術的にも未熟だから、
感情的にぶつかることもあったと思うけど、
最近は全てそういった問題が発生するとしたら、それはシステムの問題だから、
人間同士でいがみ合う必要はないという成人群衆みたいな考え方になった。
なるほどね。それはでもいい考え方な気がするのと、
その考え方ができる状況になっているのが多分一つ素晴らしい気がするね。
何かしらの人に対してとかチームに対してのフレームが動いている状態じゃないとそのコミュニケーションって取れないじゃん。
人間同士が例えば自分で頑張ってどうにかしてるみたいな時に、
でもそれもそれでシステムなのかな。それもそれでシステムなのかもしれないけど、
何か問題が起きた時に今の仕組みはこうで、この仕組みのこの部分が悪い結果こうなっちゃったから次こういう仕組みにしようみたいな。
コミュニケーションが取れるのはすごい生産的な気がする。
だしね、我々転職をいろいろと繰り返して、当然条件もいろいろ良くなってとかがあると思うんだけど、
そういうことを繰り返して自分のレベルが相対的にも主観的にも上がると、
一緒に働くメンバーのスキルも自分と同じかそれ以上かとかになってくるので、
そうするとそういう些細な問題ってお互い分かってるから起こらないんだよね。
そうっすね、それはそう。
ゆえの言語家.fmですよ。
24:02
タイトルの練習がすごい。
さっきのこれやったら終わるを防ぐことができるみたいなところですごい思って、
ちょっと一つ体験談としてあるのは、ある会社に行って、
僕の過去の経験上、このやり方を進んでいったらこういう落とし穴が待ってますみたいなのは、
僕は自信を持って言えたからその話をしたんだけど、
今伊達氏が言ったような自分よりスキルが高いとか、
あともう一つあるのはスキルだけじゃなくて文化とかもあると思うんだよね。
同じ文化圏で生きてきたかみたいなのもある気がしてて、
そういうのが近しいとこの先に落とし穴が待ってますって言った時に、
確かにそうかもってなって、それで完結できることがすごい多いんだけど、
僕がそれを言った時の環境はスキル的には別に何の差もなかったけど文化圏が多分違ってて、
何の落とし穴ですかみたいな、どうして起きるんですかみたいな説明を求められて、
理解できない以上は説明する責任はあるじゃないですか。
なんでやめるべきなのかみたいな。
その場面に迫られた時に、あ、言語ができないと思ったんですよね。
言語ができないと思ったっていうか、思ったことがあって、
そういう場面とかで言語がすごい大事だなっていうのは個人的にはめっちゃ思う。
なぜこれがこうなのかみたいなのを、
まあそうね、ふんわり説明して通じない相手と仕事しなきゃいけないことも、
別にヨシア氏とかではなくて絶対にこの先いっぱいあるし、
またなんか自分が、まあわかんないけど、
まあそうですね、人を育てるとか誰かをリードするみたいな立場になった時とかも、
そういう説明は多分できなきゃいけないよなみたいな気持ちはあるなというタイトル回収をした。
素晴らしいタイトル回収。
まあそうね、なんか僕も技術顧問をいろいろやってる関係で、
やっぱりその自分の持ってる経験値とかスキル水準より上とか下とかって言い方は良くないんだけど、
そういう経験値が自分と違う相手と話す機会がいろいろあって、
やっぱり自分の中ではこれは割と定説的で当たり前だと思ってることを言っても、
まあそうしない場面は多いしあるので、
説明を試みた時によく思うのは、
技術的なことでも組織的なことでもキャリア的なことでも、
説明がきちんとできないものっていうのはやっぱり理解が十分じゃないことが多いので、
27:00
説明をするために根拠となる言説とかいろんなリソースとかに当たって自分の理解を深めて、
それで80%ぐらい説明できたらまあ理解できてることになるかなっていう感じがあるかな。
確かに。
それをひたすら繰り返していると思う。
いや、そういう意味では、素晴らしい技術顧問やな。
いや、本当に難しいわ、でもあの仕事は。
僕も別に技術顧問って形じゃなくても、仕事じゃなくてもなんでもいいけど、
そういうことは定期的にしていきたいな。
なんかやっていかないと生まれると思うんだよな。
ゆえの、ゆえのポッドキャストですけれども。
そうね。
いや、いい感じですね。
なんか、第0回だから何を話すか雑に話そうって話をしようとしてたけど、
普通に、何の話をしたんだこれは。
抽象度の高い問題、動詞用問題とか言語感大事さとかを話しちゃいましたね。
そうね。
あと、酒あったらあと4時間いけるわ。
でも4時間話したらね、たぶん2、3回ぐらい同じ話題ループすると思うんだよ。
そうだね。
いやー、それはそうね。それはそうだわ。酒飲んだらなおさらね。
はい。ということで、こんな感じでいろんな話を定期的に提供する回ということらしいです。
はい。やっぱだてしを、これは何て言うんだ?パーソナリティ?ペアパーソナリティなのか?
ちょっと故障はわかんないですけど一緒にやられて選んでよかったかも。
ちょっとオンブに抱っこでやっていこうと思うので。
お互いにオンブに抱っこでやっていきましょう。
言語化でき、これ言語化したりしようかっていう感じでゆるくやっていこうと思うので、
次回もお楽しみにって感じですかね。
そうですね。
はい。ではでは、じゃあ次のテーマは未定ですが皆様お楽しみに。
お楽しみに。
バイバイ。
さよなら。
