住所正規化の話
こんばんは、Yokohama North AM第83回です。
Yokohama North AMは、ウェブ系エンジニアがテック系のキーワードをネタにして雑談をするポッドキャストです。
本日の相手は、げんえいさんです。
よろしくお願いします。
いや、よろしくお願いいたします。
そうですね、やっぱり2回やるとちょっと嘘臭いでしょ。
そうですね、今さっき事故ったばっかだと。
なんでですかね、僕は録音ボタンどうしても押し忘れちゃうっていう癖があります。
リハビリ期間中なんで、まだ。
リハビリ期間中ですね。
でも、すごくゲストアサインをしないっていうことで気が楽になりました。
でも、それはそれで直前まで誰も来なかったら不安にならないですか?
いや、ならないです。何にも感じないです。
強い心で生きていこうと思って。
誰もゲストが来なかったら、一人で俺は今週のPHPの作業を黙々とやるっていう配信にしようっていう。
どっちに転んでも僕は得だっていう感じになるので。
大丈夫です。
いいですね。
そうなんですね。
今日はせっかくげんえいさん来ていただいたんですが、本の話はもうそろそろ封印しようと。
どうせ会社でも話するし。
そうですね。本の話を聞きたい人は直接話しかけてください。
いくらでもするんで。
いくらでも出ますね。止め戸もないですからね。
なんで今日はちゃんとテックの話をしようということで。
ホストは何の準備もしてないんですけど、ゲストがちゃんとトピックを持ってきてくれたので。
それを一個ずつ適当に話すと面白いかもしれないという感じですね。
そうですね。
何かあった?何がいいかな?一番最初。
どれからしゃべります?私はどれからでもいいんですけど。
どれがいいかな?急に。
触れてもなっていう気持ちもありながら。
一番最初に住所正規化の話があるんですけど。
これは多分割と歴の長いエンジニアの人はですね。
だいたいあのkenall.csvってやつをダウンロードしてデータベースに叩き込んだ後、
俺はなんてものに手を出してしまったんだみたいな感じに。
そうですね。あれはマジでやばいですね。
kenall.csvはcsvと書いてあるが、俺の知ってるcsvとまず違うという気持ちになり。
そして日本の住所っていうのはこんなにもイレギュラーなものがたくさんあるんだっていうことを
あそこで勉強して、ああという気持ちになり。
これを金を払ってでも解決したいという気持ちにきっとなりますね、多くは。
そうなんですよ。住所系の話が出た時に、
もうめちゃくちゃ会社の中の人にはもうサービスがあると。
やる必要はないと。
強い心でこう言っていくというのをやってましたね。
もうサービスがあるから。
そうですね。kenall.csvっていうサービスがあるからこれを契約して後はAPIを叩くだけです。
終了みたいな。
もうできてます。制作は完了しております。
それでいいかなっていう話ですね。
歴史を知りたい方は自分でやってみるといいかなと思いますね。
kenall.csvは更新がかかるんですね。
その時に君は僕たちの気持ちがわかるようになるみたいな。
そういうのがありますね。
そうですね。
でもこれ、kenallっていうサービスがまさにあるんですけど、
そこがテックブログを書いていて、こういう面白いイレギュラーケースがあったよみたいなのを結構紹介してくれたりとかしているんで、
そのテックブログを読むだけでも、多分これは難しいんだなっていう気持ちがすぐわかるというか。
一番びっくりしたのは、郵便番号を入れたら都道府県とかなんとか市ぐらいまでは多分結構通販のサイトでサポートがされると思うんですけど、
自動で保管してくれると思うんですけど、
だからそこって一対一対応というか、少なくとも郵便番号を入れたら都道府県ぐらいは決まるだろうって僕はずっと思ってたんですよね。
細かいところまでは絶対無理だろうと思ってたんですけど、
でもブログを読んでると、郵便番号から帰ってくる住所は配列で帰ってきていて、2県帰ってくる場合もありますっていうことがブログで見たことがあって、
しかも都道府県が違うっていうふうにやっていて、
そういうものもあるのかっていうことが分かり、もうこれ無理じゃんみたいな気持ちにしかならなかったので、やっぱり難しいんだなっていう気持ちになりましたね。
なんかそうですよね、僕もデータベースにユニークキーで郵便番号を入れたとき、データをインサートしている途中にユニークキー制約で落ちるみたいな話があって、あれ?みたいな。
これは、でももう時間がないから一旦こいつは無視して、大体動く形にするかみたいな、その場での良くない最適化が行われてサービスをするみたいなのも経験しているので、すごく分かります。
という感じですね。
この話は多分、ただ辛い話なので、しっかりやれやと言われてもみたいな感じがありますね。
なんかあれだな、今日ATMが不安定だな、なんか怖いな、たまにちこちこ点滅しててちょっと怖いな。
まあ気にせず行きましょう。
なんとかなるでしょうね。
ローカル録音が残っているはずなんで。
そうですね。
で、次ですね。
カラー配列についての議論
カラー配列。
カラー配列。
カラー配列。
これはあれですね、社内でも雑談のトピックでカラー配列の話もする?みたいなことが言っている人がいましたけど。
これは何かっていうと、配列の全ての要素が条件を満たすなら、トゥルーを返すと。
で、そういう感想を定義するとき、じゃあカラーの配列を渡したらフォルスを返すかトゥルーを返すかどっちがいいの?っていう話が出てきて、
これはトゥルーを返すのがいいでしょうっていう人と、なんで一個も条件を満たしているものはないんだからフォルスでしょっていう話をしている人がいて、
そこで論争が大きい。
みんな自分はこう考えたっていうことをいろいろ言って、すごく話題になってたってやつですね。
そうなんですよね。
チーム開発についての話
で、この話、本当に面白くて。
空配列に関する論争
何が面白いかっていうと、どっちも正解になり得るというか、
ソフトウェアとして、アプリケーションとして関数的に何かを作ったときに、
関数型言語とかやった人は多分初期状態は空で、でトゥルーでみたいな書き方をするから、
空のときもトゥルーが当たり前だろうみたいなので燃えてたと思うんですよね。
で、じゃあそれをうまく説明できるかっていうと僕は説明できないなと思ったんですけど、
とある方が名台を満たさない、
何だっけ、否定っていうのはAではないこと。
何だっけ、論理学の話ですけど。
配備法の話ですかね。
ちょっと待ってね、論理学の否定を使ってある人なんだよね。
逆と対偶の話か。
ちょっと待って、あんまり嘘をつきたくないので、
ちゃんと、何だっけな、自然言語の否定じゃなくて名台論理の否定の話。
何が言いたいかっていうと、それで僕はある程度納得してたんですよ。
岸田さんのブログをその後読んで、
マックスは何を返すのっていう話があって、空のハイルティに対するマックスは何を返すかっていう話があって、
そのパターンだと、初期値がサムだったらゼロでいいとか、オールイーブンだったら、
全てが偶数かどうかっていうのを期待する場合はトゥルーでいいよね。
でもマックスは?みたいな。
マックスの場合はそもそも2個ないとダメだよね、みたいな。
これゼロなの?みたいな。
そういう話で。
チーム開発についての考察
それについては理算数学の話とWebDBプレスの135号を読んでねっていうふうに書いてあったんで、
それを待つしかないという形なんですけど、
いろんな考え方があるんだなと思って、やっぱ面白いなと思って。
これとかはやっぱあれですよね、
具体的に自分たちが解きたい問題の時はやっぱどうなのかっていうことと、
一般的にこう、一般的にって言うとちょっとあれですけど、
述語論理だったりとか明大論理だったりとか、
カラ集合に対する云々観音はどうなるの?みたいな話がされている歴史はあるので、
歴史はこうなっておりますっていうことを認識するのと、
じゃあ自分たちが解きたい問題ってカラ配列の時どうなるの?っていうことをちゃんと定義して動作を決めればきっと問題はないはずだが、
なかなかこの時はどうなんですか、あの時はどうなんですか?みたいなことをいっぱい出てくると、
それはそれ、これはこれ、みたいな話しかできなくなり、
そうですね、燃えますね、みたいな感じですね。
これかつプログラミング言語の実装にもきっとよるんですよね、何が返ってくるみたいなのっていうのは。
だからそこも考慮した話になるんだとすると、本当場合によっちゃうんだろうなと思って、
なんかみんな仲良くすればいいのにとしか思わなかったわけなんですけど、
そうですね。
世の中は結構大変だねみたいな話になって、みんなで勉強になってよかったねになればいいなと。
だからやっぱ直感的にこうって決めつけてその話を持っていくんじゃなくて、
やっぱりこう直感的にこうだけど、でも本当にそうなんだっけっていうシステム1、システム2じゃないけど、
ああいう思考のトレーニングとしてすごくいいお題なのではないかなってちょっと思ったりもしましたね。
そうですね、だから考えるっていうことが大事なんですよみたいな、
なんですかね、月並みな大人の意見になってしまうんですよ。
そんな感じ。
ここら辺が割と真面目なテックの話で、もう残るやつはだいたいチーム系の話になってるの?
そうですね、これは私が最近やっぱこの1年ぐらいチーム開発についていろいろ考えたり実践したり、
あちこち話を聞いたりしてるからっていうところで、テックの人たちがチームの話をしてるので、
これもテックの話だろうと、大広くは。
いや、全然テックの話だと思いますよ。
っていうか、僕もチーム開発の話はすごいしたいですね。
好きだし。
そうなんですよね。
だからこう、上手くいくと上手くいくんだけどなみたいな。
そうですね、上手くいかないと、頑張って立て直さないと負のサイクリに入ってしまうというか、
そしてチームはバラバラにっていう世界が終わっていく感じですからね。
今ちょうど福岡のカンファレンスで、レガシー回避のソフトウェア開発熟通みたいなのを、
人月の新話に対する感想
ネタをずっと文章にして書いてるんですけど、
なんでレガシー溜まるのっていうと、ダメなチームがいっぱいできるからだっていう話が途中で入るんですけど、
上手くいった開発チームが1個できた後に、
やっぱりそれを分解して新しいチームが3つぐらいできるじゃないですか。通常。
そうですね。
もうこの時点で終わってんだなと思って。
もう。
多分人が増えても早くならないのあたりには、本はきっとそんな感じのことも書かれてるんだろうなと思いながら、
まだうちに届いてないんで、読めてないんですよ。
いいな。
これですね。ちょっと今日本の話ししないって言ったけど。
そうそうそうそう。
読みました。帰りの電車の中で読みました今日出かけて。
2023年版人月の新話というのは噂の。
そうなんです。本当に130ページぐらいしかなくて、
エンジニアだったら一度も聞いたことあるような話がいっぱい書いてあって、
まさに人を増やしても早くなるわけではないが、
じゃあ早くするためにはどうしたらいいかって言ったら、早く作るチームを作ればいいんだよっていう話があったりとかして、
本当にまさに今の現代のソフトウェア開発の話を、
綺麗に無駄なくっていうか、無理やり引き伸ばして分厚い本にせずに書いてる本で、
ものすごいいいですね。手に取りやすいしっていうところがあります。
そうですね。それを読んでほしい人に読んでほしいですけどね。
そうなんですよね。
ここ20年ぐらいそんな話を人月の新話に対してしてるってことは、読んでくんでんだろうなと思って。
チーム開発の困難さ
人月の新話が手に入りづらい。大きい書店に行けば売ってますけど、
どこでも売ってる本ではなかったりとか、ちょっと上下二段組で読みづらいとか、
分厚いしみたいな、そういう気持ちは私も分かります。
実際読むのちょっと面倒くさかったなって思ってますからね、読んでて。
面白いけど。
やっぱり、じゃあそのチームをどうやって作ったらいいのって聞かれると、
ものすごい難しいなと思うんですよね。
実際難しい問題だと思うし、じゃあいいチームができたぞって言うけど、
それをいいチームを維持するとか、さらに良くするっていうこともまた難しいなっていうのを、
この1年ぐらいずっと思ってますね。
いいチームって何なんですかね。
僕が見てきた例だとNイコール1なんで、そんなに信憑性があるかとか、
そんな全体に適応できる話ではないんだけど、
例えばプロジェクトが小さくて会社も小さいってなると、
チームメンバーの中にはプロダクトオーナーである、それこそCEOだったりとか、
会社の中核にいる人間と関係性が濃いんですよね。
その濃い関係性で、かつかなりフランクにものが言えるっていう状態のチームなんですよね。
だから開発としてはスクラムみたいな形、理想的なスクラムに近いような形に自然になってるっていうところから、
そのチームを分解して3つにしたところにして、
同じコミュニケーションが取れる人間がいないチームが発生すると、
そこは多分同じ開発はできないんですよね。
ちょっとお伺い立てるような形になると、
なんでもっと言ってくれないんだみたいな感じで、
PO側はストレスが溜まるし、
こちらはこっち側でなんか上からメテオフォールが降ってきたみたいな話になって、
なんてひどいチームなんだこれはみたいな話にしかならなくて、
でもそれはきっとその間のコミュニケーションとか、
関係性がうまく構築されてないっていうのが根本にはきっとあるんだろうなと思っていて、
その辺を解消していないのに同じ成果を出すチームは、
そう簡単には作れないんですよねっていうところがあるんじゃないかなと思ってるんですよね。
開発者に求められる広いスキルセット
かなり見てきたんで、その例は割と。
そうですね。
それを頑張って作っていきましょうっていうと、
いろんなスキルが求められそうじゃないですか。
例えばエンジニア側に要求されることって、
コード書いてるだけでいいとか、きれいに設計するだけでいいだけじゃないことになっていくじゃないですか。
それは確かにできることが増えていけばどんどん、
一人でできることが増えればコミュニケーションパスも減り、
良いことではあるものの、
それやっていくと新しく入ってくる人たちは、
俺はまずスクールに通ってプログラミングを学んで、
よし、一枚のプログラマーになるって頑張るぞって入った瞬間に、
ララベルやレールズを勉強してきたんだが、いきなりじゃあ、
今日からリアクトも書き、データベースの設計もさせられるみたいになったら、
かわいそうだなと思いながら、
プロダクトもちゃんと理解もしてくださいと言われ、
ドメイン知識がすごい頑張って勉強しろと言われ、
ユーザーのインタビューっていうのもやってくださいみたいなこと言われると、
そんないきなり最初から全部振られることはないと思うんですけど、
現代のソフトウェア開発ってすごい、
ソフトウェアっていうかプロダクト開発って求められること広いなっていうのを思っていて、
じゃあこれをどうやって協力するかっていうのは、
また協力するってこと自体がそもそも難しいのに、
全てが難しいなっていう気持ちにどんどんどんどんなってて、
ビジネスとチーム開発の衝突
この1年ぐらいはそれに、
みんなに頑張れって背中を押しながら、
すまんなっていう気持ちにもなっているって気持ちはありますね。
いや、もうほんと、
いいチームとかいいメンバーっていうのは再現性が基本的にあんまなくって、
で、作るのはめちゃめちゃ大変で、
で、ぶっ壊すのはめちゃくちゃ簡単っていうこの、
逆進、逆進っていうか逆は無理みたいな、その方向。
作るのが簡単だったらね、誰もこんな苦労してないと思うんですけど、
作るの大変なんですよね。
関係性ってあるじゃないですか。
この人のことを僕は好きですとか、
恋愛感情とかではなくて、人間としてこの人は気が合うなとか、
この人と開発やってるとストレスがないなっていう関係性。
で、再現性ないじゃないですか。
新しく来た人とまた同じ関係性まで至れるかっていうと、
そんなこともなかったりするし。
場合によっては家が近いとかっていうすごく特殊な条件で仲がいいとか、
同居ですとか、同じ大学の出身でしたとかで、
そのコミュニケーションの仕方が変わっていたおかげで、
チームが円滑に進んでいたっていうことは全然あり得るかなと。
いやはや難しいですねとしか基本的には僕も言えないですね。
だからうまくいってるチームを解散するんじゃねえしか言えないですね。
少なくともみたいな。
プラスが増えてるんだからせめてマイナスにはならないようにっていう。
マイナスは簡単に生み出せるんだからさっていう。
そうなんですよね。そのチームがうまくいってるからといって、
もうばらしたらプラスが全然生み出せないチームになる可能性が高いんで、
そこから生み出されるほんの薄い利益を貯めて貯めて、
ようやく新しいチームの核を作りみたいな。
それを1年ぐらいかけて培養して、
同じぐらい強いチームができましたみたいな。
それぐらいチームって大変ですねって思います。
ただしビジネスは1年も待ってくれないみたいな。
早く顧客に価値を届けて、早く物を売りたいし、
機能を追加してくれたら契約が増えますっていうことが分かってるタイミングとかだと、
なかなかチームを作ってる余裕がないみたいな。
チーム開発についての話
じゃあ一体チームはいつ作れるんだみたいな。
すべてが筆とスピードの話になっていくみたいな感じがありますよね。
そうですね。
そういう状態でもチームを作りながら頑張って成果も出すんやみたいな。
それが一番早いんだが。
やっぱり急ぐんだったらスピードは緩めなさいみたいな。
なんかそこはすごく感じますね。
せめて残業はしないとか。
甘いこと言ってんじゃねえとかそういう話では全然なくって、
人間っていうのが関係性を築きながら一つのものを作り上げていくっていうのはやっぱりものすごく感動的な、
難しいことでしてみたいな。
そこにプラスしてみんなおのおのそれぞれのプライベートが存在するんで、
そのすべてがうまいこともあってないとプロダクトにその良さが反映されていかないなという気がしますね。
プロだから頑張るよみたいな話は別件であるとは言え。
大体の場合において手を抜いてるわけじゃないと思うんですよね。
人々は。きっとなんかいいかとかってやってるってよりは、
頑張ってるんだけどなんかうまくいってないんだよねっていう方が多分当たってるような気がしていて。
なんかスピード遅いねとかって言われたときは。
頑張ってないんじゃなくてそもそも何か見えない、
なんていうんですかね、衝撃があるというか。
それがもしかしたらコミュニケーションの、チームメンバーとのコミュニケーションがうまく取れてないかもしれないし。
だからそこはなんか、
人が悪いだけだったらサボってるだけだったら頑張って作れっていう話で終わるんだけど、
まあちょっとそうじゃないんだよなっていうのは常々思いますね。
ChatGPTとプロダクト開発のゲームチェンジ
まあまた複雑ですからね。
作るものが。
そうなんですよね。なんか簡単なものってもうみんな作れるようになっちゃったから。
だんだん複雑で複雑だからみんなやらないからこそここにはまだ競合が少ないとか競合がいないとか、
ブルーオーシャンに見える場所があってそこに飛び込んで、
成果がだんだん出てくるとあそこは金になるらしいぞって言って、
いろんな人たちがこう参入してきて、競合が増えていき、
パイの取り合いになり最後はこう血の海になっていくみたいな、まあそういう感じですよね。
まあもう全くその通りですね。今まですごいなこの機能みたいになってたのが、
まあライブラリとか使って普通じゃんみたいな話になって、
そうするとこうやっぱこう週刊少年ジャンプのこう戦闘系漫画と一緒でどんどんインフレしていくというか、
なんかこのボスは実は大したことなかったみたいな話になっていって、
あれみたいなこの戦いに終わりはないみたいな、
誰も得していないみたいな話になりかねない。
しかもなんかこれからまたもう1回ゲームチェンジというか、
ここからそのプロダクト開発のゲームチェンジみたいなのが来るかなと思っていて、
やっぱそれはチャットGPTがあるおかげで、
多分個人のできることの幅だったり深さだったりとかっていうのが、
多分ガッとできる人はもっとできるみたいなことが起きるっていうか、
多分もう実際起きてるでしょうけどと思っているので、
なんかあの十数年前のAPIというものが出てきて、
みんなそれでマッシュアップでいろんなものを作っていた時代が、
なんかまた蘇ってくるんじゃないかなっていうのはちょっと思ったりとか、
実際にそういう話を他のポッドキャストとかでされてる方がたくさんいて、
実際なんか作りましたとか、
こんなのやってチャットGPTとペアプローチして作ったんですよねみたいな話が出てて、
もうやっぱりなんというか早い人はもうそこまで来てるんだなって思うと、
多分簡単なプロトタイプとかMVP仮設検証したいものをちっちゃく作って、
誰かに触ってもらって、
じゃあこれって売れるの?売れないの?みんな欲しいと思ってるの?みたいなのは、
今までなんか10人だったのが2,3人でできますとか、
5人だったら1人でもできちゃいますみたいな風になってるから、
より複雑なものが何というか求められるというか、
この単機能だけじゃ売れないんだけど、
これとこれとこれとこれとこれとこれ、
なんか10個ぐらい機能が全部揃ってると売れるみたいな世界が、
さらにさらに来るんだろうなっていう気持ちはちょっとありますね。
ChatGPTについての話
やだなーって思って。
楽しそうなんだけどね。楽しそうなんだけど。
楽しいし、そのインフレを加速させる側の人間の一人であることは自覚してるんですけど、
まあめんどくさいなーみたいな話はちょっと感じますよね。
そうですね。
そうだよな、よろこびさんでChatGPTに課金してますからね。
うおーすげーとかって言って。
まあ簡単なスクリプトだったらもう全然書いてくれるし、
このシェル書いてよって言ったら書いてくれるし、SQL書いてよって言ったら書いてくれるし。
いやでもChatGPTのAPIのドキュメントにPHPのサンプルなかったんですよ。
うん。
なんでPHPでサンプル書いてよって言ったら書いてくれるんですよね。
いやーすごいねー。
いやーすごいよね。
あの時、それをやった時に、おーこいつすごいなーと思って。
これはやっぱすごく面白いもんだなーと思って。
AIでないことはまあ分かってるんですけど。
彼ら考えて出してるわけではなくて、
それっぽい文字列を出力するということに彼らは長けているっていう原理は分かった上で、
それでもこんだけ近しい何かを書いてくれるっていうのはやっぱすごいなーって思いますね。
いいですね。
楽しい。楽しい。
楽しいけどこのゲームチェンジをどれだけ楽しめるかは人によるんだろうってせっかく頑張ってこんなに覚えてきたけど、
なんか自分が5年かけたプログラミング大体AIでできるんかって思っちゃう人もいれば、
AIによる出力やJATGPTについての話
あ、なるほどそこがやってくれるんだったら俺もっと別なこと考えられるじゃんって思う人とか多分いると思うんですけど。
でもどっちにしろ人間として価値を出すんであればやっぱり深くて正しい知識みたいなところを愚直に目指すしかないかなみたいな。
まあソケットプログラミングをJATGPTに書いてもらったけどやっぱり結構間違ってるんですよね。
結構間違ってるし、あ、これはバージョンが多分7.4だなみたいなのを訓練された人間はまあ分かるって。
そういったところに価値を生み出すしかないかなっていう気はする。
まあそこにまだ人間の価値はすごくいっぱいあるし、それを使ってリーンで新しいものを作って仮説検証していくみたいなところはやっぱり人間がやることだと思うんで。
まあその辺でこうぶいぶい言わせるしかないですね。
あれ?チームの話をしてると思ったらいつの間にかまたJATGPTの話になる。
今日本と健康の話は禁止だったけど、AIの話は禁止になってなかった。
そうですね、この間はAIにいろいろ出力してもらってたんですけど。
まあでもそれはちょっと禁止にしようかなと思ってます。
そうですね、そうですね。
最近でも考えて、そろそろ日本にアジャイル開発は馴染んだんですかね。
馴染んだ。どうなんですかね、あんまり外の世界を知らないもので。
やってるぞとかアジャイルとかスクラムみたいな考え方をうちは取り入れてやってるぞっていう話は多分もういっぱい転がってるんで。
うまくいった例もいっぱいあると思うんですけど、
まあ世の中の表に出てこない氷山の一角より下に埋まっているあまり露出がない部分に関してはどうなんですかねっていうのは思ったりしますけど。
まあでもこれの話ってもしかしたらなんか競争相手がいない場合は別にアジャイルとかリーンとかあまり関係なく作ったら物が売れますだったらあまりそんなことを考える必要がなかったりして。
そんな世界中もあるのかな。
それは多分こう長いスパンで見るとやばいぞってことかもしれないが、やっぱ5年ぐらいだったらそもそも競合を入れないように河川状態にするとかっていうものがあるものも今頭の中にいくつか思い浮かびましたがあるので。
そうですねみたいな。
アジャイル開発に関する話
まあそういうところは多分こうあんまり世の中アジャイルって言ってるらしいねって言ってなんかいいらしいねって言って。
まあでも我々は特殊なんでって言いながら仕事していくってことはありそうだよなって思ったりしますね。
でもきっとスタートアップがボンボン出ていて、逆に向き合うっていうことを多分みんないろんなところで話を聞いたりとか価値を届けるとか、今までアウトプットを見てたけどアウトカムを見ましょうっていう話があったりとかっていう建設がもうすごい広まってるので、
新しく出てくるプレイヤーたちはきっともうちょっとアジャイルの考え方だったりスクラムの考え方だったりするようなことにすごく親近感を覚えてる人たちは多いんじゃないかなと勝手に希望も兼ねて思ったりしてますね。
あれなんですね、きっとスソノみたいな話があるんですよね。この10年ぐらいずっと、僕が新卒の頃にJユニットでテストを書くみたいなのっていうのが、リファクタリングっていう本がマーティン・ファウラさんの本があって、その中でJユニットを書いてみたいな話も出てて。
やってる人が少なかったし、現場でやろうとすると、なんでそんなことするのみたいな。開発が遅くなるじゃんみたいな。うわ、テンプリ来たみたいな。食らう感じだったけど、今言われないですよね。そんなに言われないというか、テスト書きますよねみたいな感じになっていて。
それって世の中がちょっとずつ変わってきてるんだろうなっていう気がするんですよね。
コードを書く人が増えたっていうのは多分一個あるし、あと、やっぱり地の高速道路は出来上がってるはずで、スクールみたいなところってよしよしあると思うんですけど、あそこでじゃあチームでものを作るってことを教えられたりとか、そのGitってものがあるとか、Railsってものがあるとか、テストってものがあるとか、きっと多分その教材の中に入ってたりとかをするってことを考えたときに、
それは全然テストっていうものを知りませんっていう人と聞いたことはあります、ちょっとだけやったことはありますっていうのは多分大きな差があると思うので、ああいうものだったりとかでどんどんどんどん外に広がってるんだろうなっていう気はすごいしてますね。
失敗経験の重要性についての話
もちろんじゃあそれが上手にできますっていうのはまた別の話ではあるんだけども、テスト、いやカバリッジ100%ですみたいな、そういうことは多分きっとあるんだろうけど、でもそれはまあそっからまた次勉強していこうねっていうことでいいんじゃないのかなっていうのは思っているので、誰しも通る道というか。
なんかこう、エンジニアのハシカの話みたいなのがなんか今日そういえばTwitterで上がってたみたいな。
上がってましたね。
あれは結局全員かかんないといけないものなのかなと思って。
それはそれで気が遠くなるなと思って。
まあそうですね。
みんな同じ道を通って、同じ罠にかかり、同じダメージを受けてるみたいな。
それをしないとこれはやっぱり分かるのか、分からないものなのかみたいなのはちょっとまあ少し面白かったっていう。
今日でもなんかちょっと似たような話でTwitterで見たのは、普通の人は自分が失敗をして、その経験から学ぶと。
優秀な人は他人が失敗してるのを見て学んで、同じ失敗をしてないみたいな話があったんですけど、
世の中みんなそんな優秀な人ばっかりじゃないんで、っていうか優秀な人以外でも参入できないとやっぱ辛いと思うので。
いやーそうですね。
そう考えると、まあ一回はこうみんながハマるやつにハマって、そういう経験をした結果、
あ、だからダメなんだっていうことを認識しないとやっぱ前に進めないかなっていうのは、
自分が実際にこう仕事をしていてもアンチパターンを踏んで、あ、やっぱりこれダメなんだみたいな、そういう気持ちにならないと。
頭でわかってるつもりであっても、実際に体現しないと全然わかんないなっていうことはありますね。
ソフトウェアテストの正常性の証明についての考察
なのでしょうがないかなって思ってますね。
じゃあ今からソースコードにコメントアウトしてこの日付を書いて変更者を書いておくみたいな、
ものすごい昔に見たようなやつとかはもう多分そもそもそれは知られてないとかいうことになったりとか。
いやでもスクリーンショットを撮ってエクセルに貼り付けてる仕事はきっとまだあるだろうからなとかいう気持ちもありながら。
あるでしょうね。僕もやった口なんで。
まあそれが悪いとは言わんけども、もうちょっといい方法はあるんじゃないかって思っちゃう。
そうですね。
ソフトウェアテストを学んだ人ならわかると思うけど、99.9%ぐらいは正常で終わるじゃないですか。
ほとんど不具合は出ないから、その99.9%の正常性を写真で残す必要あるのかみたいな。
スキルと職人精神の進化に関する考察
というか誰か見るのかみたいな話はあるじゃないですか。
そうです。テストしたっていうことが証拠として必要だっていうこと以外にはあんまり活用がされない早速なものですよね。
最初の自宅開発の現場にいたときにこのバインダーが大事なんだよって言って、でっかいバインダーに印刷したスクショの画面の紙を画面1Aとか1Bとかって書いて。
それをファイルして、それを納品っていう形にするとすごく喜ばれるんだみたいな。この形式が大事なんだよみたいなことを言って。
大人の世界だなと思って。
まあそうですね、それは結局印鑑を押すのが大事みたいな話と似てるよねって思いながら。
儀式が必要だみたいな。
でもまあいきなりはやっぱり変わらないんで徐々に徐々に変わっていって、新しいプレイヤーはみんなそれを知らないことはきっと幸せなんだろうし。
いや、そうそうそう。それでその新しい人が入ってくるって話の文脈の中で、クリーンクラフトマンシップってボブおじさんの割と一番新しい本の中で、5年ぐらい経つと半分ぐらいのエンジニアはもう新人なんですよみたいな。
それぐらいの速度で今エンジニアの人口が増加してるんですよみたいな話があって。
で、その人たちが全員エンジニアはしかにかかるみたいなのはやっぱり効率が悪いじゃないですか。
で、すごく嫌な心配というか思うのは職人さんの世界ってあったじゃないですか、大工さんとかの。
で、僕は大工さんとかのYouTubeとかはよく見るんですけど、職人さん好きなんで、今は全然スキルがいらないんだよっていう話をやっぱ盛んにするんですよね。
もう規格が決まっていて、その部品化されていて、あとはそれを組み立てるだけっていう組み立て工に近い。
で、ちょっと隅っこのとことか削れてなかったらちょっと削るとか、そんな程度しか大工としての能力を使うところがないみたいな。
で、なってくると、要は新規参入者には嬉しいじゃないですか。
スキルがなくても大工として成立するっていう世界ができてるんですね、そこはオートメーションとかその規格化とかが進んだ結果。
ただその代わり、その大工はスキルを失うわけじゃないですか、その代償を出して。
それは競争力のある大工なのかみたいな。
っていうのをなんとなく思って、ソフトウェアにそれがそのまんま適用されるわけではないと思うんだけど、
どう考えても生でHTTPリクエストとかをいじくり回してたりとか、ケルネットとかそんなのやっていたおじさんたちと、
ソフトウェア開発のアウトカム志向についての考察
今の若者の世代ではやっぱりそこら辺がもうちょっと異なってきてますよね。
もうちょっと中小化したレイヤーから作業するようなイメージがある。
良いけど良くないみたいな。
僕たちもそこから昔のエンジニアはパンチカードでプログラム読めたとかっていうのとあんま変わらないのか。
バイナリー読んでここにフラグ当たってるとかって分かっちゃう人がいるみたいな。
僕はもう絶対それはできないなと思いながら。
確かに。
CPUの構造、周りでCPU好きな人とかで話をしてるっていうのを見るけど、
何のごっちゃか全く分かんないんですよね。
僕はCPU全然詳しくないから。
それは要は綺麗に隠蔽されてるわけですよね、その詳細が。
もちろんです。
それでいいことでもあり、でもあるタイミングではバグを踏んだりとか、
そこの構造が分かっていることによってパフォーマンスのチューニングができるみたいな、
職人間はまだまだ生き残っているといえば生き残っているが、
みんなが知る必要はないよねって言えばそうだよねっていう気持ちにもなるんで。
新しい道具がいっぱい出てくるんで、その道具をやっぱり上手に使いこなすとか、
それで価値を出すっていうことの方にみんな注目するのかなっていう気はしますね。
その通りだ。アウトカムの方向性はそっちですね、完全にそっち。
そうですね。
興味があるやつだけ細けっこの調べでいいんだ。
そうそうそうそう。
PHPってどうやって実装されてるのかなって新言語を読みに行くとか。
そうですよね。
いや俺は別にPHPの詳細は知らなくていいんだ。
PHPを書いてお金をもらうんだ、アウトカムを出してお金をもらうんだっていう人と、
多分二分されるだろうし。
二分といってももちろんグラデーションはあると思いますけど。
そうだな。
だから寄与でした。
一番大事なのは価値を提供するっていうこと。
でも逆に言うと価値を提供しないと何をしてる人なのっていうことにされたりとか、
間接部門っぽくなるわけじゃないですか。
そうですね。
そこはものすごい、そこで生き延びるのは今度また難しくなっていきますよね。
生きていこうと、それで食っていこうと思ったときに、
直接のアウトカムを出してないが、しかしこの人はPHPに行くらしい。
そしてこの人がいると会社の売り上げが一応上がってるらしいみたいなことになっているが、
トップからしたらこいつは一体何をやってるんだみたいなことを言われ、
いやこの人はすごい人なんですよってみんなが言うみたいな。
怖いよー。
怖いよー。怖い世界だな。
チャットGPTとコーパイロットの役割
でもそれは多分チャットGPTが出てきても全く同じようなことを今みんなアウトカムが。
コードは別にプログラマーが書いてくれるんだったら、
もうちょっとユーザーインタビューに行けばいいんじゃないとかって言われて、
みたいな気持ちになる人はいっぱいいると思うんですよね。
そうですね。
チャットGPTにいちいち聞くのはめんどくさいから、
コーパイロットみたいな形になっているのが一番楽なんだろうなって思うし、
それがいいかなって思いますよね。
じゃあコーパイロットとかチャットGPTとか上手に使えるのかお前はっていう話もきっとあるはずだし、
そんなすぐに劇的に変わる世界は来ないと思うが、
じゃあ自分たちが30年後どうなってるか、
20年30年先は全然違うゲームしてるんだろうなっていう気持ちはありますね。
ほんまですね。
面白い、面白い、楽しいけど、
それを楽観的に生きていけると思ってるから楽しいと思ってるんだろうなっていう気持ちをずっと抱えながら、
キャリアパスとかで悩むとまあなんとかなるやろうみたいな、
最終的になんとかなるやろうみたいな気持ちにずっと思ってますね。
IT業界の将来性や技術力よりも重視されるもの
だからやっぱり大事なのは健康な体と、
健康な体と元気みたいな、
健康の話に行ってしまった。
知的好奇心とかそういうのは結構大事かなと思ってますね。
Googleのやつとかにも、
ラーニングアニマルみたいな話とかあったりしますけど、
そこがあればきっと生きていけるはずって思いながら、
はず。
好奇心は猫を殺すというから、果たして生きていけるかどうかは分からないが、
きっと大丈夫なはずと思ってますね。
そうですね。
なんとか自分が稼ぐ間、
世の中の投資がIT系にちゃんと続いてくれたら、
僕は嬉しいなみたいな、そういう気分。
ずっとこの状態が続くわけではないなと思う。
エンジニアバブル終わったとかってこの間も言ってたけど、
そんなこと言ったら、一番最初のITバブルの時になってもっとすごかったんだからと思って。
まだまだバブルでしょって思っちゃう。
他の業界から見たらめっちゃバブルだろうなと思って。
そうだと思いますよ。
一体、お前ユニコーンって珍しいはずだったのでは?みたいな気持ちにずっとなりますもん。
こんだけ。
言うてでも、じゃあユニコーンがゼロになりましたかって言ったら、
そんなことないはずで、アメリカとかでも。
考えると、ピークよりはちょっと下がったかもしれないけど、
どうせまた上がるんでしょっていう気持ちも半分あり、
上がらなくても周りから見たら上がった分の高いところにいるんだから、
だいぶラッキーなところにいるなっていう気持ちはありますね。
面白いのが今二人が話してるのは、トップを伸ばす話じゃないですか。
技術力みたいな話をしてて、
さっきのチーム開発の最初の頃の話だと、実はコミュニケーションとかの話をしてるんですよね。
実際に現場で求められてるのはその話じゃないですか。
そうですね。
トップを伸ばしながら、でも一方で周りの背中を押しながらみたいな、
二重にやることは実は。
そうそう。
そうなんですよね。
僕自身だから会社でエキスパートとかって呼ばれてるけど、
一番大事なのはニコニコしてハキハキ喋るみたいなところが多分大事なんだろうなと思っていて、
そこは意識してるんですよね。
技術力があるっていうか、会社で強いとされてる人がちゃんとコミュニケーション取るんだよみたいな。
じゃあみんなも取らなきゃねみたいな雰囲気になってくれたらいいなみたいなところは。
いや、もしかしたらでも周りからはエキスパートっていうものの中にはそのコミュニケーションを上手に取るって言われて、
がんゆされていてエキスパートじゃない人はそれが上手くできなくてもいいと思われてる可能性は、
ゼロではないとは思うが、きっとみんなあれをお手本にきっと見てくれているとは思いますけど。
単純になんだ明るいおじさんだなって思われてる可能性はありますね。
良いチームは解体してはいけない
そうですね。
僕のテックリードってついてますけど、とにかく気にしてるのはカジュアルに相談ができそうって思われることはすごい大事だと思ってるんで、
基本的にはニコニコしてイライラしたところを見せないようには努力してます。
実際は難しいですけどイライラすることもあるので。
そうですよね。いや偉いですよね。僕は結構イライラしてますからね。
これ以上言うとなんか危ないという雰囲気を感じましたね。
いやいやいや。
これはレコーディングがされてないところで喋ったほうがいいですね。
そうですね。この間飲み会でだいぶ危ない話をじゃんじゃくしてたんで、
あれでだいぶ僕の中では半年分ぐらいは出たんで大丈夫かな。
ガス抜きが。
ガス抜き。
いやまあでも本当奥さんとうまくやるのも大変だからな。
まあ誰かとうまくやっていくっていうのは難しいですよね。
本当に人と人は分かんないし他人が何考えてるかは。
いや本当その通りなんですよね。
だからこそさっきの話にやっぱ戻っちゃうんだけど、
よくできたチームは解体しちゃいけない。
そうなんですよ。本当にそうなんですよ。
だいたいみんなが得意不得意も分かってるし、
こういう趣向性があるとかってことが分かってるっていうのは、
すごくチームっていうものを考えたときにいいことなんですよ。
それを知らない中でいきなりもう1回人を寄せ集めて、
はいじゃあ今日からこれ作ってって言われたときも、
本当にそうなんですよ。
1回人を寄せ集めて、はいじゃあ今日からこれ作ってって言われたときも、
すごい難しいんですよね。
あなたたちは期待の新チームですと。
かっこ寄せ集めって書いてあるんですけど。
でもまあジョークでもなんでもなく、
ソフトウェア開発における人材配置の難しさ
多分いろんな場所で起きていることがそれ。
でも多分マネジメントの人たちも別にそんなにバカじゃないというか、
考えてはいるんだがしょうがないんだよみたいなところもありつつ、
そうなってしまって、
関係性が多分構築できない状態で、
マネジメントをしなきゃいけないという非常に難しいミッションを彼らはするわけですよね。
いやーそれは難しいなって思って。
しかも成果が出るかどうかは、
実際にある種手を動かす人たちに委ねられてるわけだったりするわけですよね。
そうですよね。
いや、まあそしたらやっぱり、
スクラムよりタスクを割り当てるみたいな形のリソース効率を見るほうに。
再転換して。
いくだろうなー。
リソース効率は下がるなーみたいな。
誰かが何もやってないっていう状態を、
強い気持ちで我慢できるっていうのはやっぱり能力が必要ですよね。
そうですね。
まあでもわかりやすいですからね。
やっぱり直感的にはリソース効率を上げたほうが、
成果が出そうな気がするじゃないですか。
確かに。
うーん、そうね。
簡単なモデルでいくと多分そうなっていくんだけど、
たぶん工場的な考え方とか、
機械を2つ並べてこいつをリソース効率をどんどんどんどん上げていけば、
成果物がガーッとベルトコンビネーターに運ばれて出来上がっていく。
実際はたぶん工場の現場は私は知らないので、
今すごく雑にモデリングをして喋ったけど、
実際現場に行ったらそんなことはないんだよっていうことが絶対あるんですよね。
それと同じことがソフトウェア開発の現場でもきっと起きてるはずなんだけども、
それはやっぱり目に見えなかったりとか、
数値化されてないと把握もできないし、
結果なんか暇そうにしてるんだったら、
じゃあこれやってよっていうことがどんどんどんどん割り当ててしまうみたいな。
僕のでも現体験っていうか、
一番最初僕がリーダーとかやったときは、
すごく割り当てるんですよね。
それがやっぱり人間としての自然な管理っていうものを考えたときに、
タスクA、B、Cを作り出して、
AさんはA、BさんはB、CさんはCみたいな。
で、パラで進むとみたいな。
3日で終わるみたいな。よしみたいな。
終わんねえみたいな。
どうしてだ。俺の考えた最強の支えが合ってるはずなのにみたいな。
なぜだみたいな。
ところをやっぱり自分も経験した後、
その後にもっとでっかい開発現場に行って、
明らかに案件に対して人間がバブってたんですよ、その現場。
僕はその頃にはだいぶ能力というか現場力がついてきて、
3年目とか4年目くらいだったんで、あれって思って、
この要件はたぶん3人ぐらいでやったら一番うまくいくんじゃないかなっていうところに。
これは例えの話ですけど、100人とかいましたってなると、
97人いらないわけじゃないですか。
いらないですね。
でもその97人に仕事を割り当てようとしちゃうんですよね、現場やっぱり。
それはそこにお金が発生してるし、
なんだあの97人はみたいなこと言われちゃうわけじゃないですか。
そうするとなんかよくわかんないけど調査みたいなことをしてたりとか、
本当は3人で固まってやった方が良いことを無理やり分割して、
これまさに僕が現体験で見たゴンウェイの法則は、
もう無理やり仕事が分割されてるんですよ。
人間が多いからっていう理由で。
これは厳しいみたいな。
その時に無理に人間を投入するのは極めて間違った考えだなっていうのを、
現場力と人材投入の関係
本当心の底から理解したんですよ。
しかもその現場は炎上したんですよ。
人が多いのに。
正しくは人が多いから炎上したんだけど、
直感的には人が多いのに炎上したってなるんですよね。
そうそう。
それを見た時にこれがリアルだって思って、
めっちゃ残業してたんですけど、
僕もその炎上の中にいたんで、
これでもすごい良い勉強だなと思って感動してたんですよね。
こんなにも送れるんだと思って。
でも人間を投入した方が儲かりますからね、人欠のシーン。
人欠観察すると。
そうそう。
住宅開発が社長さんかなと以前話した時があって、
その時に人売りになり果てたらもう終わりなんでって言って、
SESは麻薬なんでものすごく気をつけてますって言って、
本当に真面目な顔して言ってたんで、
難しいですよね。
本当に難しいですよね。
分かんないから人に頼るわけじゃないですか。
自分たちで作れないからどうにか人を連れてきてやるのに、
人をいっぱい連れてきたら、
これは10人で必要ですって言われて10人連れてきたら、
実は3人ぐらいで良かったみたいなことがどこかで気づいた時にも、
10人分のお金を払いながらひたすらものを作りやがって、
なかなか納品されずみたいなことがきっといろんなところで起きてると思うんですけど、
難しすぎるのではみたいな。
そうですよね。
みんながみんなが高い授業料払って失敗をして、
それは間違ってるんだよっていうところを根本から理解できてるのかっていうと、
テック業界の現状についての意見
多分そうではない。
何で失敗したんだろうなって多分それを振り返ると、
お願いした会社がダメだったのかな、現場にいた時点で、
エンジニアがレベルが低かったのかなとか、
そういうわからないことをわからないなりに考えて、
結果、完全に理解したか、完全に理解してないみたいな、
そういうオチしか待ってないような気がして。
いやー。
何で失敗したのかっていうと、
なんで今日もテック絶賛と言いながら、
ソフトウェア開発って難しいですねって言って、
バカみたいなこと言ってごめんねみたいな。
そういう。
テックの部分と物の作り方
いやー、そうなんですよ。
テックの部分は難しいにはもちろん難しいんだけども、
そこよりも重要なところは実はテックの部分だと思うんですよ。
どういうふうに物を作るかっていうことだったりとか、
我々が一体なぜこれを作ってて、誰が使う人で、
それに対してどうやってアプローチをして、
この物を売っていくのかとか、
結局そこの部分の方がだんだん作れるようになっちゃったんで、
多分そっちからシフトが出てくるかどうかっていうのが、
テックの部分の方がだんだん作れるようになっちゃったんで、
多分そっちからシフトしてるんじゃないかなみたいな気持ちは結構ありますね。
もちろんAIとかそういう難しい部分は、
本当にテックの最先端を追いかけながらじゃないとできないと思うんですけど。
むずいね。
本当に難しい。
本当に難しい。
これをじゃあ何百人とか何千人の企業はみんな同じようなことをインプットさせて、
同じ方向を向きながらこうやってソフトウェアっていうのを作っていくんだよっていうことを意識させるなんてもう無理じゃないですか。
無理無理。
そういう会社のお金の稼ぎ方っていうのは多分またやり方が絶対違うなって思いますよね。
アジャイルスクラムとかっていう、要は少数性のやり方とは多分異なるんだろうなと。
あ、しまった。もう1時間経ってしまった。
EMについて
EMの話したかったんだよなちょっと。
昔は名前がついてなかった仕事にEMという名前がつきました。
EMことで有名なEMですから。
そうだな。今度はEMの話したいな誰か。
どっかで。
EMの人来週出ますって言うと出られる感じですかね。
そうですね。来週俺とEMのこと。EM詳しくないんで教えてくださいって言って。
多分俺はEMのことをグルコサミンだと思ってるんで。
グルコサミン。EMとはグルコサミンであるという。
グルコサミンである。
来週への謎を残して。
そうですね。どっかで土曜日の9時半から暇なEMの人を見つけて。
ライブができたらいいな。来週はまだ福岡の1週間前なんで。
多分できると思いますライブ。
なんでそんなとこっすかね今日は。
楽しかった。
YouTubeライブで聞いてる人はですね。
どうもうちのネットワークが今日よくないらしくてですね。
ATEM miniがずっとピカピカピカピカ光ってて。
僕はめちゃめちゃプレッシャーがあってですね。
げんえさんに内緒でランケーブルがちゃんと刺さってるかっていうのを見に行ったりとかしてたんですけど。
そうさっき突然画面から消えたなと思いながら
俺はこれずっと喋らないとマイクの前にいないから喋り続けなきゃって思いながら喋ってましたね。
いやー流石同僚だなと思って。
素晴らしいと。何も気にせず喋り続けるこの弾力が素晴らしいと。
感心してました。
褒められてる中褒められてない中よく分からないですね。
ちょっと締めに行きますね。
今週も放送いただきありがとうございました。
なんだっけ。お便りや感想は。
噛んだけどもう一回やるだけで大丈夫ですか。
大丈夫です。お便りや感想はシャープ横浜の声援をつけてツイートしてください。
本日の相手はげんえさんでした。ありがとうございました。
ありがとうございました。
横浜の声援。
