00:00
こんばんは、Yokohama North AM 第70回です。
Yokohama North AMは、ウェブ系エンジニアがテック系のキーワードをネタにして雑談をするポッドキャストです。
ホスト役は、自称フルサイクルエンジニアのHanhan1978です。
本日の相手は、GotoさんとKawashimaさんです。
よろしくお願いします。
よろしくお願いします。
よろしくお願いします。
でですね、今日実はめちゃくちゃ緊張してるんですけど、
GotoさんもKawashimaさんも緊張してるんですけど、
お二人はですね、ペチパー会議の時にですね、強引に突撃していきましてですね、
ちょっとポッドキャストやってるんで出てくださいっていうブシつけなお願いをしたら、
二人とも来ていただいたということで、今日は本当にありがとうございます。
こちらこそありがとうございます。
そう言っていただけるとめちゃくちゃ助かります。
なんでこんなの出なきゃいけないんだよって思われてるのやだな。
そんなことはないと思うんですけど。
ちょっと被害妄想がひどい。
で、二人のご紹介をすると、Gotoさんは現在は歌舞伎スタイルの方で働かれていまして、
役職とかあるんですかね、役割とかって何をやってられると。
そうですね、歌舞伎スタイルという会社で、今ちょっと不思議な感じに聞こえるかもしれないんですけれども、
COO兼CTOっていう、簡単に言うと何でもやる人ですよっていうような感じの役職に就いております。
なるほどなるほど。
じゃあ本日はよろしくお願いいたします。
よろしくお願いします。
川島さんはですね、ペチパー会議で素晴らしいアーキテクチャの話をしていただいて、
この方はぜひポッドキャストに来てもらわなきゃって思った感じで、
現在ベース。
何チームとかってあるんですかね、所属されて。
普通に技術基盤チームの1エンジニアっていう感じですね。
なるほど、基盤って感じなんですね、基盤チーム。
基盤ですね、はい。
というわけで今日はこの2人をお迎えして、
アーキテクチャっていう言葉を使っちゃうと固くなりそうだねっていうのを事前に話していたので、
ソフトウェア開発は難しいねっていう愚痴みたいなのを1時間喋るといいのかなみたいなところをちょっと思いました。
なのでそうですね、1時間ほどお付き合いいただければと思いますと。
早速なんですけど、本当に実に難しいなって毎日思ってます。
なんでこんなに難しいんでしょうね、ソフトウェア開発って。
03:00
本当ですよ、なんなんでしょうね。
最近歌舞伎スタイルのエンジニアたちで読書会始めようぜって言って、
何の本にするかいろいろ相談した結果、クリーンアーキテクチャを読み始めたんですよ。
まだ2回ぐらいしかやってないんですけど、
クリーンアーキテクチャの初めの方にアンクルボブがいろいろ格闘してきた話が書いてあるんですけど、
なんていうんですかね、1960年代ぐらいにプログラミングのパラダイムが構造化、
構造化プログラミング、オブジェクト指向、それから関数型になるみたいなのが生まれて、
それから新しいパラダイムは生まれていないみたいなこととか、
その頃からやってることって変わってないよねとか、そういうことがいろいろ書いてあって、
結局そのプログラミングの仕方っていうのは、
良くなっているけれども劇的な進化はしていないとか、そういうことが書いてあって、
まあ確かにね、だからアーキテクチャの本質は一緒だよねみたいなのが書いてあるんだけど、
一方で、なんかそうか俺たちそんなに上手くやれるようになってないんだみたいな、
ある種の絶望というか、そういうふうに思っちゃったなって。
ありますね。そうなんですよね。
エンジニアしてるとどうしてもソリューションレイヤーというか、
実際にコードを書いたりとかフレームワークいじったりとか、
ライブラリー書いたりみたいなとこはいいんですけど、
じゃあそれを全部まとめ上げて事業と統合したソフトウェアっていうものになっていくと、
なんかたまにありますね。
なんかこうやべえどうしようもねえなみたいな時が結構。
どうしようもねえな。
どうすればいいんだこれみたいな時が結構。
なのでやりがいはあるんですけど。
1960年ぐらいからずっとやってるんですよね、これねみんな。
そうっすよね。
昔の人のが上手くやってたのかもしれないなぐらいのことを思いますね。
そうですね。今ってやることが異常に大増殖していくじゃないですか。
僕が新人の頃ってウェブ開発ってもっとシンプルで、
マルチルーティングだし、今の見えたらSPAみたいな考え方はなかったから、
ページ遷移するし、そこでステートレスだし、
みたいな感じで実に分かりやすくって、
ソフトウェア開発っていうのはそれを設計していけばいいんだよみたいな。
だから画面設計みたいなのが割としやすかったんですけど、
今はこれ設計書どう書くのよみたいな、
そんなアプリケーションがやっぱり多くて。
06:03
設計書書くぐらいだったらとりあえずプロトタイピングしてみて、
動かした方が設計が進むかもしれないみたいなことが割とあるなみたいな気になりますね。
そうなんすよね。
後藤さんはよく勉強会で中小のハシゴの話とか、
設計の中小化とかそういう話をされていて、
設計得意なんだろうな、勝手なイメージです。
勝手なイメージでこの人は設計得意なんだろうなって思ってて、
だから上手な設計ができるっていうのは、
中小的な思想ができることかななんて思ってたんですけど、
この間のペチファ会議で川島さんの発表を聞いて、
松原さんのドメインが僕に、
日本語の上までは判別できないという、
もし何でもしてくれるものであるフェア会を作るという風に、
名前をつけて書かれるのもたいんだなって思ってたんですけれども、
でも本当にその岡田さんの発表を受けてみた時以降は、
たった今の経験は上のほうが大きくなるかなと NFTは思ってたんですけど、
もっと広めて欲しいなっていう意味合いのあれなんで
そうそうそうそう あれ実に素晴らしいなと思ってて
何回でも聞きたいなあれと思って 僕も4回は見てるんであれ
いやさすがにそれは嘘でしょ いや見てる見てる見てる
まあありがとうございますたくさん参考にしていただくのは嬉しいことなんですけど ちょっと理論的すぎて実践するにあたって結構壁っていうのがいくつかあってなかなかこう
参考にしていただくのは嬉しいですけどなんか全然 実践できて先に進めているのかっていうとなかなかそういう期待には応えられていない
という正直な現状はあるっていうのが正直なところですね はい
実行していくのはねなんか組織の話みたいになっちゃうから あの今日避けたい話題ですね
まさにそこの部分で苦戦しているところではあるのですがちょっとそこは 話が広がりすぎちゃうので一旦横に置いておきましょうか
そうでそこを置いとくとして僕川島さんのあのフェチパー会議での話を あの見せていただいて一つ思ったのはそのまあいろいろその
何でしょうねこうもちろんまだ実践していないみたいなものもあるかもしれないんです けれども
いろんな情報を引っ張ってきてで川島さんなりのそのベースにあった結論みたいな出されているものが なんかすごく地に足についているなと思ったんですよ
09:04
いきなりなんかあのぶっ飛んだことをやろうとかじゃなくて この組織での今のチームとかいろいろなバランスを考えるとこういうやり方がいいはず
だみたいなところに落ち着いていてで それってまあ僕その時あの全職の
M社にいたんですけれどもまあ言ってもいいんですけどあの そこでもなんかまぁそこだと逆に最初はもうちょっとぶっ飛んだやり方を選択してやってみて
だいぶ回り道をした結果そのもうちょっと地に足つけようぜみたいになっているところがあって まあそれは別にその会社の何でしょうね文化というか
まあそういうものによって 選択するやり方は違うでしょうから当然
違ってていいんでしょうけれどもまあいろいろやってみた結果あの そこに落ち着いているというのがあって
でまぁそれってまぁでも最初からそうできたかもしれないなというのはやっぱり思うわけですよ そういう反省があった僕の目から見た時に川島さんのあの発表はすごい発表だけじゃなくて
ああいう結論に至ってるっていうのはものすごいよく考えられてるなっていうかその ただ自分の頭の中だけで考えたとかじゃなくってあの現実をよく見てるなって思いましたよ
どうもありがとうございますなるほどそういうふうに僕のあれを見てくださっていたんですよ ありがとうございますそうですねあの
まあ地に足つけるっていうのはまあかなり 気をつけたポイントではあっ
でその えっと
どういう経緯がそこに立ったんだけどあの僕だってが書籍読め たくさん読んじゃうまんみたいな感じの人間なんですけどあの
結構 えっと
世の中のマイクロサービス実践企業でたくさんある中で は行われているのは結構 cto だったり上の人たちのこれで行くぞ
ローっていうなんていうかこう 合案で
一気に進めようぜっていう 理想的な状態に向かっていくぞっていう動き方
があって でえっとそれでうまくいってるのがうまくいってないのかわからないけど少なくとも自分
にはできる気がしなかったっていうところがあって僕 cto とか何の立場もない人間なんで はい
で えっとで
なんてこう なんでマイクロサービスとか日的負荷下げたいんだっけっていう目的っていうか本質って
何なんだろうって本質っていうこう と方法ない重たい言葉
だが従事を承知してるんですけどなぜ分けたくなるんだっけっていうところを まあたくさんいろんな角度から本読んで見つけようと思ったらああいう結論に至ったんですよね
12:10
はい なんて学校
地に足つけた で聞くとなんか実際に実践を通して獲得した知識を経験をもとに
ああいう結論に出したみたいなニュアンスに聞こえてしまいそうだなって思うけど実際の ところは
えっとまぁ実践もあるんですけどどっちかという理論をひたすら集めに集めた結果その中に 本質めいたものを見つけてそれに向かってあの
順番に一歩ずつ進めていくにはこういうやり方なのかなぁっていうところですね 主なパーツとしてはマイクロサービスの文脈だったり
ドメイン駆動設計の境界的なコンテキストっていうパースだったり あとデブをプス的に
5 生産性の高いビジネス組織の姿って何なんだろうねっていうところだったり
あとクリーンアーキテクチャー的な要素があってそれら4つのパーツをかき集めてみたらああ いう
形になりましたよっていうそんな感じで作られたものなんですよね実は
でもそうですよね周りを見た時のこのなんていうか マイクロサービスやってるっていうところのかなりオールスター集めてる感があって
それは自分がいいその時所属してた組織でもできながら今の組織でも多分できないんですよね その方向で行くことはではトップダウンから地に足つけたところまで落ち
その 行き着くというのは多分無理っぽいなぁと思ってなんで僕もあの
あの m 社さんもそうですけどいろんな会社の事例とかこう漏れ聞こえてくることをこう 耳どしまっていっぱい集めてきて
一体何ができるかなぁみたいなどうどういう改善したらいいかなっていうのもあるし 自分の経験上もなんか新しいソリューションがソリューションとかテクノロジー
1のが出てきてそれで一部を切り離した時に起きることって実は複雑性が増えちゃって たりとか運用が辛くなっちゃったりとかっていうことのが割と多いんですよね
なんかマネージドとかで完全にあの なんかもう管理さえしなくてもいいっていう状態まで行けるトラックなんですけどそうじゃない場合
はむしろ不採用を増やしている男になっちゃう それそれをもう1回この年で繰り返したくないなっていうのはあってもうめちゃくちゃ考え
たんですよね なんでその結果うちも高校学ずっとやってるんですけどあのとにかくドキュメント書いて
調べてソースコードを少しずつ綺麗にしてっていうその中 めちゃくちゃ地味だなみたいなことをやってる
15:00
高校学はもうその m 社時代にも本当に 高校学の社内ウィキがあるぐらいの感じだったんで
まず最初に身につけなければならないスキルが高校 もうそういう感じだったんですね
いやうちも何であのオンボーディングの資料がどんどん膨らみつつあるというかその 広告で調べられた知見がどんどん並んでいく
面白い感じでしたよ高校学は もともと前者の話になっちゃうんですけど
最初 php のシングルリポジトリで開発してたんですよね でそれが
まあ uk とか us とかにも展開していこうという時にでも最初はシングルリポジトリで まあ
リージョンごとにこういうふうみたいな形式でちょっとこう ロジックをかき分けるみたいなので最初はやってましたと
ただどっかの段階でちょっとその方式ではもうやれんぞみたいになってきて 例えばもう us だと配送会社が jp と全然違うのでもうかなり違う
実装しなきゃいけないとかなってくるんでとかとか まあとまあその今シングルリポジトリだとなんかいろいろもスピードが詰まってくるので
みたいな話が出た時にフォークしてやりましょうみたいになったんですよね でそうすると一番最初になったリポジトリはまあちょっとその時僕はいないからわかんないんですけど
何らかの経緯で uk が元のやつを引き継いで jp と us は何かフォークしたみたいになっていると
まあまあなんかそういう風になっていると そこからまあそれぞれの歴史が始まるという感じなのでそのフォークするように前にあった
プルリクとかはなんかその uk のリポジトリの方に行かないと見れないんですよね
なるほどだからなんかこうコミットログとか辿ってプルリクみたいに出てきたんだけどそいつは 実は jp のリポジトリではなくてリポジトリのその一番最後の
サフィックスを uk に変えてみろとかなんかそういうあの考古学の手法がありました
考古学でもやり方がある
ノウハウがある ノウハウというか何だろう前向きなノウハウというよりかこうやらないといけないんだよみたいな
後ろ向きなノウハウって感じでしょ 出てこない奴はそうやってみろとかさらにその古い時代になるともうなんか1週間システムが
昔のレッドマインでやってた時代とかになってて そのアーカイブを見に行けとかなんかそういう感じになったりします
すげーわかりますよね 面白かったです
元からいる人たちはね そんなの当たり前だろって顔してこう見てくるやつがあるんですよね
18:01
そんなの普通に人はわからないよって
今の会社でも気をつけているのはそれが当たり前って感じられちゃうはないようにし ないといけないっていうのは結構常々に気をつけないといけないなといつもは染まって
いっちゃうんですけどだんだん 情報格差みたいなのはどんどんできちゃうし
だから常になんかどうやって情報にアクセスするんだよとかそういうのを教えていかないといけないですよね そうですよね
むずいなぁ いやソフトウェア開発なんで難しいんですかね
いやだから なんででしょうね
いや この先に要はソフトウェア開発を例えばこう一生懸命皆さんも高校学やってきれいにしていって
まあ仮にとても良い状態までソフトウェアを持ってたとしたらそこは高校学がいらない なんかこう
なんですかね 桃源郷みたい なんかこうみんなが何を開発するかわかってるみたいな
仕様がソースコードから明白に理解できるみたいな そういった状態になるのかな
そうなんだけど時間という概念がない世界じゃないと無理じゃないですか 無理ですよね
クリーンアーキテクチャーのアンクルボブを知って 結構クリーンアーキテクチャーの結構序章のところで
私は今約束の地にいるみたいなかっこいいことを 確かに書いてた 書いてない
その約束の地が一体何なのかわかんないですけど こう僕らが今話し合っているような環境に近いものなのではないでしょうか
面白さがめちゃくちゃ 自分がずっとそこのリポジトリに対して仕事していて
なんかやりきったらそういう状態かもしれないですね 自分は全部したみたいな
ああなるほど それはもしかしたらあんま良くない状態かもしれない
新しく入ってきた人に対しても桃源郷かどうかは ある程度コードはなんか綺麗と言える状態かもしれないですけど
それに対するドメイン知識とかね いろいろあるでしょうし
でもちょっと見てみたいですね アンクルボブが言う約束の地っていう状態が
どの程度の約束感があるのかっていうのは 一回参考にしてみたいなっていうのはちょっとある
そうですよね どうしても汚くなると思うんですよ
その事業っていうものをドライブしていくっていう流れと やっぱ現実世界の複雑さみたいなものがどうしてもあって
いやそうですよね
その現実世界の複雑さがやっぱり一つの要因ですよね
21:03
いかにソフトウェア ソースコード自体を綺麗に書く手法を僕らが身につけたとしても
現実世界というかビジネスのありをみたいなところ
これをソフトウェアでどう表現するみたいなのが どうにも綺麗に表せないみたいなやつが
よく出てくるってことですよね
ほとんどがそれなんじゃないですかね
そうですね
すごく使い古されたっていうか歴史のあるドメインとかだったら
いろんな人がいろんな工夫してきて
大体こういう帳簿があればいいよねとかいうのができてればいいんでしょうけど
そうじゃない新しいことをやろうとしてるところとかって
全然洗練されてないだろうから
みんながいろんな工夫してやってるみたいな感じですよね
そのものが事業として成り立つようになった時には
多分そこはもう試行錯誤の塊になってるから
やっぱりどうしても考古学が必要な状態にはなるんですよねきっと
そうですね
それ多分悪いことじゃないんですよね
悪いことではなさそうには思いますね
その考古学だけじゃないと思うんですけれども
そういうビジネスってのは複雑なものであって
それを支えるソフトウェアもある程度の複雑性があるというか
それはあるがままに受け入れる僕らの覚悟が必要という話なのかなと思うんですよ
なんかこのソフトウェアというか
人間の知識を何かしらの記憶媒体に出力して
これインストールすれば必要な知識を覚えられるよみたいなことできないですかね
やりたいですよねそれやりたい
すごくわかります
人類って自然言語という発明品を作ったわけじゃないですか
日本語だったり
外界をどうグルーピングするのか
そしてそれを何と呼ぶのかっていう
各物理的に分かれた各個人の脳の知識でいうか
抽象概念の共有っていうのを自然言語を通して始めたのが
ホモサピエンスっていう生き物で
自然言語でやり取りしていた情報を
活字というか文字に起こして
24:01
時間を超えて知識を継承できるようになったっていうのが
人類史上のすごい偉大な発明だったりするわけで
それに近いニュアンスを感じるんですよね
このソフトウェアの難しさ
人と人との間だったり
時間を超えて知識を継承するっていう問題みたいだなって
僕は思っていて
それと自然言語だったり活字が解決していたものが
何かどこか似てて
そこになってくると
自然言語
ユビキタス言語
ハッて思うところが最近あったり
それを言っちゃうと
ユビキタス言語というか
ドメインモデリングして
DDD的な開発を愚直にやっていけば
このようなソフトウェアの開発の問題って解決できるのかって言ったら
それは言い過ぎだよなとは思いつつも
何かヒントを感じちゃうっていう
その程度ではあるんですけど
そうですね
おっしゃりたいことはすごいわかる
ただその言葉みたいなものも
なんていうのかな
すごい抽象化された
数学的な世界で表現されてるやつ
もうなんか証明できるみたいな
これもクリーンアーキテクチャに出てくる話なんだけど
証明できるタイプの種類の知識や問題と
あとそうじゃない
なんか証明はできないけど
間違っているということが言える
科学のアプローチで
正しさを保証するようなタイプの問題っていうか
2者があって
アンクルボブはソフトウェアは科学の方だって言ってるんですよね
それ自体で矛盾がないみたいなことは言えませんみたいな
だから間違ってはいないらしいっていうことだけを
ひたすらたくさん集めて
恐らく正しいでしょうっていう
クリーンアーキテクチャもう一回呼びたくなってきた
言ってた確かに
確かにそうだよねっていうのもあって
それってどういうことかっていうと
なんかそういうソフトウェアの知識みたいなのっていうのは
完全に正しいみたいなことは言えないと
だから完全な正しさみたいなのを表現できないものであるし
そういう手段を持って僕らも
それでこういうものですよねって表現してるもんだから
それをまた受け取る僕らの脳みたいなものは
100%の完全性を持った正しさで理解できないというか
ある程度正しいんだろうみたいな理解しかできないっていう
感じになっちゃうのかなっていう解釈をしてますけど
どんどん劣化していくというか
おっしゃられてることを何となく分かりつつも
何とか返事ができるほど
27:00
ちゃんと理解できてるわけではなくて
妄想みたいなことを言ってました
さすがというかしさぎ飛んでるというか
ひたすらすげえという感想
小学生並みの感想だけ述べさせていただこうかと思います
すいません 気の利いた返答ができるほど
僕はちゃんと処理できていませんでした
妄想すぎましたがね
でもなんかすごい
もう一回呼びて
何となくだけどよく分かるなと思って
集合体なんですよね
正しさを表現する何かの集合体
であれはできていて
人間の脳みそっていうのが実に誤解するじゃないですか
だから正しく書かれていたとして
それを正しく受け止められないみたいな
ところでもうすでにそこが起きていて
この間も実にくだらない話で
セットがゲットしてるっていうコードがあったんですよ
セットの中でゲットしてて
実はリターンチが戻っていて
しかも副作用があるから
引数に渡しているやつの中身が変わってるみたいなのがあって
僕はそれをメインのスレッドの方から追っていくと
その関数の中身まで見ないんですよ
明らかにこれはこういうことしてるんだろう
っていうふうに誤解して進むんですよ
でも結果全く違うことが起こっていて
不具合が出てるんだけど
なんなんだろうこれって言って
しょうがないから
デバッグ実行して1個ずつ見てると
あれ?なんかここで書き変わってるぞみたいになって
ようやくわかると
そうですね
僕は論理学でいうところの間違った前提
っていうものを関数に対して行って
読み進めていた結果も間違っていたと
それまでは前提が間違ってたけど
なんとなく合ってたのが不具合が出るようになった
みたいな話でもあり
これが積み重なって
なんとなく動いているものがソフトウェアだとすると
こいつを綺麗に改善するっていうのは
とても大変なことだな
なんていうことをこの間も思ってました
本当ね
名前付けみたいなやつが
諸刃の剣っていうか
人間はやっぱり名前を付けて
情報隠蔽して
なんかその抽象な使い方も楽だから
一回名前を見るとそれでこうだなって思っちゃうけど
じゃあ名前が正しくない時っていうのがあるわけ
そうそう
なるほど
名前も人間が付けるものだしみたいなところですね
人間ですからね
つまりソフトウェアの難しさを解決するには
人間を辞めるしかないっていう
その名前の妥当さとか
その名前に対してイメージを持っている自分っていうのは
30:01
そのイメージも人生の中で培ってきたイメージっていうものが
それを表現していて
そうすると全く違う人生を歩んできた人が付けたその名前と
僕がその名前から受ける印象っていうのはやっぱりちょっとずれるんですよね
そういったところから合わせていくみたいなところ
一元さんが見てそれを間違いなく僕と同じイメージを掴んでもらうように
コードを書くことはきっと無理がありますよね
ソースコードだけで表現するのはやっぱり無理があるなとか
だからオブジェクト思考とか名前みたいなのを使うことによって
人間にとってメンテナンスしやすい方向に進化してるはずなんだけれども
たぶん本来プログラムにはあんまり人間的要素が
マシンゴで書いてないあんまり入る要素がなかった
アルゴリズムだけだったみたいなところに
人間のための何かがいろいろ入ってきて
それが悪さをしている説だって
なくはないですよね
なるほど
なるほど
まあ確かに
いつから人間っぽい話になってきたんだろうな
そうそうそう
誰のために書いてあるんですよね
本来はアルゴリズムがあってそれでお客様に価値を届けられればいいんだけど
俺たちのための名前付けだとか
そういうものがたくさん必要で
どっちかというとそいつらのために大変になっている可能性がある
ちょっと裏覚えなんですけど
プログラミングの現象はほぼほぼマシンゴを書いてましたみたいな世界で
そこからマシンゴだとさすがに人間には解釈難しいから
人間のためにアセンブリっていうものが開発された
最終的にマシンゴに置き換えられるんだから
実行するCPUにとっては何で書かれているか
CPUはもうどうだっていいっていう立場なんですけど
あくまで人間が書きやすくするため
生産性を上げるっていうためにプログラミング言語が生まれて
より人間に近いような形で
CPUに対する命令を構造化できるように
プログラミング言語というのは徐々に進化して
プログラミング言語そのものの性能ではなく
プログラミング言語の機能を使って
ソフトウェアで解決
ソフトウェアの命令をより構造化するっていう名目で
オブジェクト思考プログラミングだったり
何かしら構造化の流派って呼んじゃっていいのかな
OOPだったり関数型だったり
何かしらCPUに与える命令を人間にとって
書きやすい、読みやすい、理解しやすい
理解できるからこそ修正しやすい
そういう世界観を目指していったんですよね
あくまで何もかも全部人間のためだけに
CPUにとってはどうでもいいという領域なのに
すべてプログラミング言語が生まれた時から
もう人間のための何かしらっていう
33:00
言語だったり設計っていう技能だったりが
生まれてきた影響があるんですよね、確か
そこ自体がだから
もう少し人間的すぎない
何か厳密性のある何かが生まれると
もうちょっと僕らは楽になるんでしょうかね
いや、だから
Understanding Computationっていう本があって
そこでプログラミング言語を作っていくんですけど
意味論みたいなものが出てきて
プログラミングに意味を割り当てていく
この意味論のアプローチって
何かちょっとずつ足していくんですよね
スモールステップで足していったりとか
操作的意味論とかプログラミングは何をするのか
みたいなところから機能を追加していく
PHPとかJavaScriptとか
仕様から考えたのではなくて
こういうことをしたいっていうところから
作り上げていって
今そういう動きをしてますっていうプログラミング言語です
それとは別に今
形式意味論みたいなやつで
意味自体がもう定義されていて
もう厳密にその動きをするみたいな
プログラミング言語が出てきたとして
そういったもので作ったら
きっと楽になれるんだろうかとかっていうのを
うっすら思ったことがあって
今そんなのを思い出しました
なるほど
GRPCとかのあるじゃないですか
定義によって
データのやり取りとかが厳密に定義できますみたいな
それとに
あれはAPIでちょっとデータをやり取りするとかっていう
そういう形だけど
それよりももっと複雑な
意味とかデータのやり取りっていうものを
厳密に定義できるようになってくると
もしかしたらもう少し楽になるのかもしんない
フロントエンド以外はって感じがする
一つの世界ではあるかもしれないですよね
人間に使えますかね
そうそうそう人間がない
その厳密性を文法的にチェックできるみたいな
世界観があるのかもしれないな
やっぱり一番問題のあるコンポーネントは
人間っていうことでいいんですかね
そうですね人間は早く帰りたいと
雑なプログラミングをするっていう
よくないですね
人間に大きなアウトプットを書いてほしくないですね
インプットからアウトプットが
36:01
一位決定してほしいですね
リリースBが決まってると
雑なプログラミングをする生き物
そうなんですよね
なのでこの気持ちはきっと
みんな一緒なんじゃないかなっていうのを
今日確認できたらいいかなって思って
みんな難しそうな顔してるんできっと
きっと合ってるなって
そんな気しますね
仮に川島さんの会社って
これからいろいろ実例を挙げてって
解決ができたとして
それはその組織とそのプログラミング
っていうかそのソフトウェアのための
解決方法であって
多分他の会社には
適用できないんですよねそのまま
無理だと思いますよ
全体的に一品ものになるんだよな
っていうのはちょっと最近思ってて
だから難しいんだろうなと思って
僕は何というか
こう画一的なプロセス
画一的な開発方法を
みんなにやってほしいわけではなくて
ビジネスの環境が常に大きく変わる中で
ビジネスとしてのPDCAと
そのビジネスのPDCAを支えるための
テクノロジーだったり
プロセスのPDCAをみんなに回してほしくて
やり方を決めてほしいんじゃなくて
メンツが決まってる中で
君らのそのメンツの中で
俺の考えた最強のやり方を探してくれ
っていうことをひたすら言いたいだけで
それじゃあ本当に一品ものです
この環境
こういう組織環境と
こういうビジネスと
こういうシステムの中での
中でしか通用しない
その環境固有の何かでしかないと思います
そこにいる人間が
目の前の課題に対して本気で取り組んで
改善していくっていう
その行動自体がきっと
設計とかリアーキテクチャリングの活動そのものなんだな
そうですね
トップダウンで何かもかも決めたいわけじゃなくて
みんなに失敗してもいい環境を用意してあげたかったっていう気持ちなんですよね
この範囲で試行錯誤してくれ
失敗してもいいよみたいな
そういう枠組みを作ってあげたかったわけ
その枠組みの内側までを踏み込みたくなかったんですよね
なんかあれですよね
システム改善において
もう少しTDDでいうテストハーネスみたいな形で
この範囲だったら思いっきり失敗できるみたいな
そういう制度設計というか
ソフトウェアを作っていくやり方の設計みたいな感じがあって
39:03
みたいな感じなのかな
少なくとも僕が受けた印象はそうだったので
ちなみに今日の会の前に
僕は設計が嫌いなんですよ
という話を笑いながら言ってたんですけど
そもそも新卒1年目ぐらいの時
最初からウェブ開発やってたんですけど
ウェブ開発最初終わった後に
なんだこの設計書作るのめちゃめちゃ面倒くさいなと思って
だから俺の考えた最強の設計書を作って
それを埋めればウェブシステムができるっていうものが作れるだろうって言って
半年ぐらいずっと考えてやったんですよ
全然無理じゃんと思って
なんだこれめちゃくちゃ複雑だなって思って
似たような動きをするウェブシステムでさえ
もう全然設計違うじゃんかって思って
これを画一的な
その頃はExcel使ってたんで
Excelの設計書で描けるもんじゃないなって思って
なんて難しいものなんだって
その後僕はずっとTDDで作るようになってたんで
とにかく作ってプロトタイピングして
形整えて
全体的な設計がある程度いい感じになればいいかなみたいな
だから設計なんてできないよみたいな
その方向に行っちゃったんです
無理じゃんと思って
特に新規開発は無理だなと思って
最初から作れないから
とりあえず形作ってプロトタイピングして
ものが出来上がって動いてみないことには
何とも言えないんだなソフトウェアは
みたいなところはその時に覚えました
なるほど
その何とも言えなさっていうのは何でしょう
自分自身の学びのプロセスなのか
自分自身ではなくて
ソフトウェアとしての世に出して
フィードバックをもらわないと分からないみたいな
それも両方かなと思いますね
自分自身もだんだんやってくうちに
認知が上がってくるじゃないですか
そのやろうとしているものに対して
最初はこんな感じかなって曖昧なのが
どんどんどんどん知識が深まっていく
っていうプロセスが一個あって
そこで出来るものは傲慢なものなんですね
僕が考えたものになってしまうので
やっぱりフィードバックを
いち早く受けなきゃいけない
なるとやっぱりプロトタイピングが良くて
見せる
その評判を聞くと
なるほど世の中の人はこういうイメージを持つ
じゃあこの設計は良くないからこう変えようとか
こういう形に変えよう
こういう処理に変えようみたいな
そういった感じになってきて
その評判なんていうか期待値
お互いの持つ期待値っていうのが
それほどずれなくなってきたところが
42:01
ソフトウェア自体の落とし所になるんだな
みたいなのが
特に受託で新規開発が多かったので自分は
そんなイメージなんですよね
今までの
だから設計してからみたいなのが割と嫌いで
ポンチ絵描いたらもう作ろうぜみたいなのが多かった
TDDが導いてくれる構造を信じた
そうそう
ただ約束としてテストは書こうみたいな
そうそう
どうにもならんくなるからみたいな
事前に設計するときより
自然発生的に生まれる構造みたいなものですよね
ただそれさえももともと作ったことがあるから
ある程度型が自分の中ではあるから
それなりのものがそもそも作れるっていう状態になってから
やってるから
いきなりその状態になったかって言われると
ちょっと違うんですよね
でした
なんで
なんか抽象の話とか設計の話してる人見ると
みんなすごいなと思って
審判さんとかすごいなと思って
俺こんな話できねえなと思って
いろいろですよね
自分の経験ベースだけ語るっていうのも
それはそれで一つの設計を語るアプローチだと思うし
っていう感じです
設計ってなんなんだろうな
設計ってなんなんですか
僕もよくわかってないんですけど
デザインとは
設計の話するときも何でしょう
さっきのまた人間の話に戻るかもしれないですけど
我々のための設計と
ソリューションとしての設計と
なんか2種類ある気がしますよね
なるほどなるほど
どんなアルゴリズムを使うのかとか
そもそも全体こういうソリューションでいこうみたいな
大枠とかは
お客様に提供するための設計だと思うんですけど
あと細かいいろんな設計もあると思うんですけど
一方でよく話題に上がってるのはどっちかっていうと
我々のための設計っていうか
コードの設計っていうか
そっちの話に行きがちだったりしますよね
だからどっちが本当の設計なんだっけ
どっちも本当かもしれないですけど
どっちの話してるのかは区別してもいいのかなって思ったりしますね
45:00
みんなが設計のことを考え始めて
無言の時間が生まれていますか
みなさんは安心してお楽しみください
設計とはって今考えてる時間ですね
設計とは
少なくともソフトウェア設計なんか考えなくても
ビジネス要件を満たす
そういう振る舞いをするシステムっていうのを作ることは可能で
ウェブサービス例明期
2000年前後くらいかな
フレームワークに従って作れば動くものできるんでしょう
みたいな時代があったかなと思ってて
そこにはあまり
自分たちが主導的にソフトウェア設計を掌握しようみたいな考え方を
持つ人はそんなにいなかった
ただし邪魔会話は結構思ってたわごめん
邪魔会話は思ってた
少なくとも作ってしまう以上何かしら構造ができてしまうんですよね
ソフトウェアって不可視で構造なんて読み解けねえよって
思う人も多いけどただ
構造を持つがいわゆるやりやすいことやりにくいことっていうのが
徐々に出来上がってきて
それをやりやすいことやりにくいことを
何かしら自分たちのメリットになるような構造へ持っていこうとする活動が
少なくとも僕にとってのソフトウェア設計のおぼろげな像なんですよね
そういうとプロダクターデザインとかではなくて
自分たちに向けた構造なんですよね
と雑な話をしつつ
それは正しいっていうか必要なんですよねきっとね
自分たちがいかに早く動けるのかっていうのを
ちゃんと考えとかないと
いい動き取れなくなってしまうっていうのが
いろんなところで起きてるっていうことだと思うし
それにどう対処するのかっていうのが大きなテーマです
まあその通りだと思うんで
決して無視していいわけではない
昔はもっとそっち側だったなっていう気は何となくしますね
ソフトウェアさえある程度きれいに構造化されてれば
あんまり問題というか
こんなに今ほどユーザー体験とか
どうやって価値をお届けようとか
そういうことは考えてなかったなという気がしますね
なんか使うユーザーも限られてたでしょうし
リッチなデバイスもなかったでしょうし
そうそうそう
どうやってデータ入れとくもんだよね
ぐらいの感じですよね
48:00
そうそう
今よりもあれですよね
データベースとのインターフェースみたいな感じが
ちょっと強かったかもしれない
確かに確かに
そうですね
データベースの入出力を扱うっていうのが
アプリケーションでみたいな
今でいうレールズアドミンみたいなものに
ちょっと若干近い
だからデータさえしっかり設計すれば
システムとして長生きするよねっていう考えが
最初に育てられたと思うんですよね
それも大事な上に
今はもうやっぱ下等競争って感じなんですかね
ソフトウェア自体がそもそも
そういった条件を満たすのは当たり前で
その上でさらに使いやすくなければいけないし
スマホ展開もできなきゃいけないし
アプリもないとつらいよねとか
なんかこう
共有もしやすいように
なんか僕がソフトウェア開発に対して
難しさみたいな話に戻るかもしれないですけど
ちょっと危機感を感じるのは
ソフトウェアって変に
物理的制約がないというか
例えば建築物を建てるんだったら資材の量だったり
コストだったり重さだったり
いろんな制約の中で作らなきゃいけない
っていう世界があるんだけど
ソフトウェアはなんか
今だったらメモリが無限にあるような感じの中で
作れちゃうと
なので
やれること何でもやれみたいになるわけじゃないですか
人間がいれば何でもできるみたいな考え方になりがちというか
どこにも制約がなくて
その制約の中でやろうみたいな考え方になりづらい
っていうのはあるのかなと思ってます
だからやることがどんどん増えていく
再現がないっていう
それがより問題を
問題というかやらなきゃいけないことを大きくして
結果的に複雑になるよね
そうですね確かに
そうですね
やることがどんどん無限に増え続ける
物理的な重力があるとか
そういう世界観ではないわけですよね
もうソフトウェアのサイズここまでしか作れないんですみたいなのが
世の中的にあったらどれだけ僕ら楽だったことかっていう
楽じゃないかもしれないんだけど
建築物の高さとか
何百メートルだと物理的に限界ですみたいなそういうのなくて
51:02
その気になれば宇宙まですごく建物建てられますがみたいな
そう
それぐらいの感じで僕ら多分やってると思うんですよね
確かに
通信もどんどん良くなりますしね
インフラ環境っていうか
通信環境社会的なインフラもそうだし
ユーザーを取り巻く環境っていうのはこんなもん
こんなもんって言ったらみんな見えないのかな
スマートフォンと名乗るパーソナルコンピューターというか
を持っていて
ユーザーを取り巻く環境とかも含めて
社会上で期待される
ウェブシステムっていう姿もどんどん変わっていって
ウェブ例明記の頃は
掲示板とかアンケートフォームとか
PHPでHTMLに組み込みでなんかちょろっと書いた程度の物でも
価値があった
掲示板すげーってなってたのが今では全然
そういうのが当たり前
データ保存してそれをウェブを通して遠隔地が保存したものを
遠隔地にいる人が同じように見れるっていうのはそれだけじゃないですか
そういう距離を超えるっていうだけのユーザー体験では
もう価値がなくなっていって
それをできる前提のもとコンピューターでどれだけみんなの
幸せだったら社会的な摩擦を解消できますかっていう
対決してほしい
期待値っていうのがどんどん高まっていってるなっていうのも
期待値は高まってますね
高まってるなソリューションも増えるしな
JSでほらみんなフロントエンドフロントエンドつって
どんどんリアクトでバンドルしてつって
何十メガバイトつってそんなのダウンロードできないよってところから
今度はCDNなるものがどんどん発展して
今度はエッジコンピューティングだつって
最近中国の方が作られたリポジトリのやつで
PHPがエンジンX上で動くっていう
エンジンXの組み込みのPHPとかで出て
そいつはSQLiteも使えるんですよ
だからエッジコンピューティングでPHP動くって
恐ろしい世界観だなこれと思って
なんかこれは前進してるのか後退してるのかよく分かんないな
あと4G回線ってめちゃくちゃ早いじゃないですか
僕はすごい満足してるんですけど
うちの妻のiPhoneが割と新しいんで5Gをつかむんですよたまに
使わせてもらうとやっぱり5Gはいいんですよね
1回あれ体験したら多分もう買える
54:06
それなんですごいの早いぞって思いながら
なんかまたやること増えるんだなこれでって
ちょっと思うところはありましたね
社会的な通信インフラがどんどん進化して
ユーザーの手元のデバイスも進化してっていうお話ですよね
そのうちストレージは全てクラウドで
データは手元に保存するものではなく
リアルタイムに手元に落とすもんだみたいな
世界観になっていったりとか
そうですよね今もだいたい近いですよね
新クライアントみたいなもの
そんな時代かもうとっくにそうか
よくできてますもんね一瞬でクラウドに保存するからな
そこにストレスが全くないんですよね
裏で何やってるのか全然分かんないですもんね
そうきちんと非同期処理されていて
ってことは1960年頃からあんまり変わってないと言いつつ
実は我々が作ろうとしているものは
めちゃくちゃどんどん複雑になっていってるので
我々は頑張って追いつきましょう
頑張る
今のが指名でよろしいですか
ちょっともう頑張れない感じになってるんで
そろそろなんか新しいの出てくれないと困る
ブレイクするの欲しいですね
不思議ですよね
20年前から比べるといろいろ開発のために便利なツールがどんどん増えていって
その頃はオンプレミスのシステム管理してたはずなのに
クラウドクラウドみたいなのが当たり前で
開発環境は便利になってるはずなんですよ僕ら
僕らの開発を支えるツールはどんどん便利になってるはずなんですよ
でも俺たちの仕事は一向に楽にならないんだよ
そうですね
だから今の川島さんの言葉に全てが詰まっていて
新しいブレイクスルーが起きて
さらに今やってることを今の10分の1ぐらいの負荷でできるようになると
さらに良いものを出さなきゃいけなくなる
どんどん難しくなっていきますね
そして今度はこう
一昔前はウェブシステムっていうのは数人で作るもんだったものが
いつの間にか何十人も人を集めないと
ウェブシステムってそもそも作れないのが当たり前みたいな時代になっていって
そこで組織的な問題が出てきて
複数人で作業する以上
ツボロチームだ
トゥーピットチームだ
変数はたくさんありますよね
57:05
結局ウェブシステムって何かしら構造を持たなきゃいけない中でも
その構造を決定する要素っていうのはもちろん
プログラミング言語だったり
テクノロジーの側縁もありつつ
ビジネスからの要求っていうのも日々
時々刻々と変わるっていうのもありつつ
それをメンテナンスする人
人の人数だったり保有してるスキルっていうのも
時間の経過とともに変わり続けていく中で
システム構造っていうのは
システム構造を決定するいろんな要素ビジネステクノロジー組織
変わり続ける変数の中で
常にバランスを取り続けていく
変わり続けていくものでなくちゃいけないんだろうな
っていうのを進化的アーキテクチャっていう本を読みながら
うっすらと思ってうっきつわかんねぇ
っていう
どっか
進化的アーキテクチャの書いてあることとか
アーキテクチャの本質なんだろうな固定的なものではなく
たくさんの変数の中でバランスを取り続けていくっていう
本質的な課題なんだろうな
解決策はよくわかんねぇけどっていう風に
僕は今アーキテクチャについて
思っております
僕もその本読んでそんな気持ちになりました
ダメじゃんっつって
これ解決策じゃなかったっつって
大変って書いてあるぞっつって
適応度関数とか
言いつつも
なんかよくわかんないっすよね
進化的アーキテクチャ
うまく締めらんないな
1時間経ったんだけど
僕が締めの言葉を
どうしたらいいかな
またみんなで集まりますか
1年後ぐらいに
また新しい何かが出てきて
これで全てが解決できる
っていう怪しい人間になってる可能性がありますか
大丈夫かなそれ
共振者っぽい
今はもう無理だなと思って
とにかく今目の前にある複雑さっていうのは
どんどん減らしていって
片付けていくしかないなっていう感じで
今はやってるんで
その先の何かの世界が見えたら
ご報告します
教えてください
僕もベースさんの約束の違う話が聞きたい
えー
ベースの約束の違う
むしろたどり着くのかな
1:00:00
そうですね
今日は本当にありがとうございました
でも僕は勇気が湧きました
やっていきですね
やっていきですね
やっていきましょうっていう
ひとそら愚痴を共有して
そういう気持ちだけ共有してっていう
今日はそういう時間でしたよね
また文字場に戻って
よし愚直に頑張るか
じゃあ締めの方に入ります
今週も放送を聞いただきありがとうございます
番組のフィードバックや要望は
ハッシュタグ横浜の声援をつけてツイートしてください
ライブをお聞きの方は高評価ボタンをクリックお願いします
次回も聞きたい方はぜひチャンネル登録お願いします
本日のお相手は後藤さんと川島さんでした
ありがとうございました
