Ogi and Minokudo's Background
Yokohama North AM
こんばんは、Yokohama North AM第78回です。Yokohama North AMは、ウェブ系エンジニアがテック系のキーワードをネタにして雑談をするポッドキャストです。
ホスト役は、自称PHPRのHanhan1978です。本日のお相手は、OgiさんとMinokudoさんです。よろしくお願いします。
よろしくお願いします。
よろしくお願いします。大変光栄なことに、本日は良い行動、悪い行動のMinokudoさんに出ていただけるということで、大変緊張しております。
緊張しなくていいですよ。
特に直接のお知り合いとかではないんですけど、僕は一方的に本を読んでいます。
Ogiさんは、このポッドキャストが開催されるに至った原因を作った人で、
ポッドキャストにMinokudoさんが出ればいいのに、つぶやいたのをエゴさせてくださったということで。
実は、Minokudoさんは本では知っているんですけど、本業は何になられるんですかね。
本業はウェブエンジニアですね。
バックエンド系の、一応ちゃんと仕事はしております。
ありがとうございます。
普段のお仕事もウェブ系エンジニアで、アーキテクトみたいな感じですかね。
そうですね。アーキテクチャ全体の設計だったりとか、あとリファクタリング、どうリファクタリングを進めるかみたいなリファクタリング戦略を策定したりとか、
あと、拡張するための設計とか、いろんな設計の助言だったり支援だったりとか、設計全般の業務、その辺の業務を全般やっております。
なるほど。本日はよろしくお願いします。
よろしくお願いします。
もう一方のおぎさんが、何年目になるんですか。
僕ですか、僕は2年目ですかね、ウェブエンジニアとして。
2年目ということです。
Challenges of Software Planning and organization
そんなことはないです。どんな場所でも胸を張っているべきです。
頑張ります。
エンジニア2年生で、あれですよね、もともと多業種からエンジニアということですよね。
おそらくそのためか、かなり必死にいろんなところに食いついていこうという感じがたくさん。
なるべく構わず、強そうな人のいそうなところにどんどん首を突っ込んで、強そうな人が書いている本を読み漁っているという感じです。
大事ですね。
すごくめちゃくちゃ大事だと思います。
大事です。
僕もおぎさんを知ったのは、PHP界だとペチパールームというオビスの部屋があるんですけど、そこに普通にいつもいて、僕も暇なときはそこにいつも入り浸っていたので、そこでお知り合いになりましたという感じですね。
じゃあ本日は、もしかしたらつらいかもしれませんが、1時間設計の愚痴を聞くかもしれない。よろしくお願いします。
よろしくお願いします。
早速なんですけど、僕も仕事ではアキテクト的なことをやっているので、だいぶ気持ちがわかるというか。
アキテクトっていうか、ソフトウェアの方向、自分の思い描いた方向っていうのをちょっとおこがましいなって思うときあるんですけど、揃えていくのって大変ですねっていう。
超大変。
やっぱ超大変ですよね。
超大変なんだよな。
何が大変って、やっぱり政治をやらなきゃいけないっていうのが大変ですね。
自分一人でこういう設計をやって進めてくださいとかって言っても、それでエンジニアさんの皆さんがついてくるわけでもないですし。
Political considerations in Software organization
そう、そう。
だからあと、設計にその手小柄する部分どこだっていう、そういう戦略的なところも考えなきゃいけないので、それを選択してここにコストかけますとかっていうような交渉とかしなきゃいけないですし。
それから、あと何でしょうね、やっぱその辺の設計をうまく回すためには組織どうするのみたいな。
特に僕はDDDやってるんですけど、DDDっていうとやっぱりビジネスサイドの人とのコミュニケーションを三つに取らなきゃいけないんで。
コミュニケーション設計どうするんだよって、そこのコミュニケーションがどうしても素になると、やっぱりそれが品質にも非常に影響してくるので。
そこの取り計らいもしなきゃいけないしとかってなると、結局組織の話だとやっぱり政治家よみたいな。
全体的に政治をやらなきゃいけない。
いや、ほんとめちゃくちゃ気持ちがわかるなっていうのが、僕も普段やってることは何かっていうと、リモートなんで、うちはフルリモートなので、コミュニケーションは基本スラックになるんですよ。
これだけだとやっぱりアーキテクトとしてやっぱり組織と馴染んでいくの厳しいんで、ハドルが空いてれば必ず突っ込んでってとりあえず喋るみたいなのを常日頃からやって、
なるべく開発チームと離れないようにみたいな、なるべく親近感を持ってもらうみたいな。
僕はあなたたちに苦しめようなどと思ってはいませんと。
どちらかというと味方ですみたいな。
そうです、大事ですね。
ソフトウェアって必ずしも技術力を生むだけでそうなったのではなくて、CEOとかPDMとかがいて、
その組織の形がありつつ、なんとかかんとか世の中の何かを自動化するなりやんなりして、お金を稼ぐ装置になっていったっていう根的思想があるじゃないですか。
それを無視しちゃうと改善できないんですよね。
それすごい難しいなって本当に毎日頭悩ませてますね。
歴史的な経緯とかっていうところも調べなきゃいけなかったりとかして、
私は考古学者なんですか?みたいなところもありますよね。
考古学ですよね。スラックの過去ログとかを延々と漁って。
なるほど、こういう経緯でこうなったのかな?みたいな。
この人いるのかな?みたいな。
ああ、いないみたいな。
いないね、もういないね。
そうそう、だいたいいない。
そうか。
やっぱりじゃあ大体やることが一緒なんだな、きっとっていうのがすごく。
まあ多分そういう。
で、アーキテクトって僕そんな仕事やってないんですよとか言ってても、
必ず組織に押している課題っていうのは、
誰がそれを拾ってやるかとかっていうの関係なしに存在していて、
だから何かしらその賜り類とか、課題解決しにいってるんですよね。
だから、うちの会社アーキテクトなんていませんよとか言っても、
誰かしらそれに相当することは一人ないし誰かが多分やってるはずなんですよね。
やってる。
ただやっぱりそれを戦略的にコントロールしようと思ったら、
やっぱりちゃんと専門的な知識を持って、
ちゃんと組織立てて、ちゃんと系統立てて、
やっぱり解決しにいくっていうことが必要なので、
やっぱりそれはちゃんとアーキテクトっていう人を置いて、
ソフトウェア設計と組織
立ち向かった方がいいのかなって思いますね。
逆にそういうのがないと、うちは全然設計に対して無関心みたいな。
設計っていうものを系統立てて、
戦略的に解決するっていうところを内外に示せなくなるんじゃないかなと思うんですよね。
そういう課題が押してることすらもしかしたら気づけないかもしれない。
そういう明治的に設計とかアーキテクトとか、
いうのをちゃんと立てておかないと。
と思います。
いや、ほんとですね。
RailsとかNHPだとLaravelっていうRATのラピッドアプリケーション開発のフレームワークがあるんですけど、
あいつらで作っていって、
オールマッパーついていて簡単にVC作れますよみたいな。
ほとんどの必要となるような機能がありますっていう状態で作っていって、
たぶんある程度のところまでは人間の脳にうまく収まるぐらいのレベル感のソフトウェアのサイズになってるのかなって思っていて。
あるときすごい事業がうまくいって売れ出すと一気にやっぱ跳ねるんですよね。
機能も増えるし、人も増えるし。
データ量が一気に増えて、どんどん破綻していきますよみたいな。
それをどう戦略的に食い止めていくかみたいなところが腕伸びするところになるんだろうな。
ある何かしらの敷地を超えると、
なんかそうなっていくんですかね。
最初は十分コントロールできるレベルのシステムの規模だったり、データの規模だったのかもしれないんだけども、
なんかそれが一気にガッと大きくなってきて、
あれ?なんかだんだん集中がつかなくなってくるみたいな。
だんだん少しずつ手遅れになってくるみたいな。
そうなんですよね。
いやもう本当、本当だから、大変だな。
なんかあんまり詳細は言えないことが多いな。
あ、そうそう。
りのくぞさんとかって、メトリクスとかってなんか取ったりしてますか?アーキテクチャの改善のために何か。
取ってますね。
例えば何ですか?うちとかだと循環複雑度とか、
今最近入るだと4Kとか取って、なんとなく外形的にソフトウェアの良し悪しみたいなところを見てるんですけど。
うちはCodeClimate使ってますね。
なるほどなるほど。
CodeClimateってのはGitHubのリポジトリと連携して、
そのメトリクスを自動で計測してくれるオンラインのサービスなんですけど。
それ使うと自動で負債をスコアリングしてくれたりとか、
あと時系列で負債の増減をグラフ化してくれたりとか。
いう風にしてくれるんで、それで悪くなった部分を、
メインのブランチにコミットされるたびに、
自動で計測が走ってくれるんで、
だから何か品質が悪くてすぐに検知できるんですよね。
じゃあ負債になった部分を全部対処するかって言ったらそうでもない。
見た上でこれは対処しなきゃいけないなとか、
これはちょっとあまり、確かに負債ではあるけども、
ここやってもあんまり何か上手味が出ないよねみたいな感じで、
どれ全部やるんじゃなくて、
戦略的に取捨選択していくって感じですね。
やっぱりそういうリズメでできる部分もあるっていう感じですよね。
そうですね。
うちもMetrix撮り始めて、
ずっと最近は循環複雑を撮ってて、
結構面白いですよね。
この間マージされたやつで1位が入れ替わったみたいな、
悪い1位ですけど。
撮ってなかったらあんまりそういう話ができないんだけど。
撮ってるとリズメでそういう話ができる。
計測は制御の基本ですからね。
そうですね。
品質管理
やっぱ測って数字が出ないと、
なんていうか、
回転できないですよね。
計測できないものは制御できないって、
誰か偉い人が言ってたんで、
全くその通りです。
結局それが計測しないと、
うちの品質の中で何がどう悪くなったんですかっていうのも、
分かんないし嘘ぶふこともできるしみたいな。
そうそう。
なんとなく良くないみたいな。
そう、なんか。
でもやっぱり、
そういう流石不細のダメージってのは、
日々じわじわ、
ダメージになってくるんで、
首がだんだん締まってきて、
結局自分が何で苦しんでいるのか、
何で死んでいるのかも分からないような、
水が酸欠になって、
爪で口パクパクさせるような感じで、
最後死滅していくという、
ああいういやらしいダメージが蓄積していくので、
だからこそ、
今自分たちの作ってるものって、
やばいくなってないの?っていうのは、
やっぱり常に見える化していくことが大事ですよね。
そうですね。
あと、
三ノ子堂本とか読んでて思ったのは、
みんなに読んでほしいなって思った理由が、
言葉とか概念を覚えてほしいと思ってて、
定業種みたいな話とか、
そういう言葉を覚えないと、
一体このコードが何が悪いのかっていうのは、
なんとなくみたいな説明になっちゃうと困っちゃうから、
そここそこ言葉を覚えてほしいなと思って。
データはもちろん、
悪いっていうのを定量的に表すことができるけど、
それプラス、
自分の目の前にあるソースコードに対して、
言葉で説明できるようになってくれると嬉しいなみたいな。
で、やっぱ本はいいなって思って。
三ノ子堂本のテーマっていうのは、
見えないものの認知
見えないものを見えるようにしようっていうのは、
結構そのメイン、
主な趣旨な部分があって、
あの本って、
夫妻のことを悪魔って呼んでるじゃないですか。
はいはいはい。
で、まさしくそれが、
要は認知できないものっていうもののメタファーであって、
中には、
それを何かこう、
人の書いたコードを悪魔なんて、
何て言ってるんだろうね、工藤はみたいな風に。
言う人もいらないですけど、
いやそうじゃねえって、
本の中の序盤ちゃんと読んでねって。
それは見えないものの認知と、
メタファーとしてそれは悪魔って言ってる。
で、
だから、
お昔、
細菌っていう概念が、
人類に知れ渡ってなかった頃って、
病気になったりとかしたら、
ソフトウェア設計の重要性
それは悪魔の仕業だとかって言って、
お祈りしたりとか、
でもそんなことしたって、
病原菌に対しての有効な手段ではなくて、
後にコッホさんが、
細菌っていうのを発見したことによって、
劇的に対処方法が、
向上したっていう、
そういう歴史があるわけですよね。
その歴史になぞられて、
我々が苦しんでるのも、
実は悪魔みたいなもんで、
正しく物事を認知できないと、
そもそも正しく、
システム開発上の対処はできないんだっていう。
そういう意味込めて言ったんですよね。
だから、
その概念を知ってほしいっていうのが、
ものすごく大事で、
僕の魅力堂本の中で、
女子圧裂って、
女子圧裂の法則か、
女子圧裂の法則を出してたんですけども、
あれは、
名前を知って初めて、
その概念を認知できるっていう、
認知法則なんですけど。
だから、
設計っていうものを、
まだやったこともない、
エンジニアさんにとっては、
業種度とか、
結合度だったりとか、
っていうものの認知がないと、
結局、自分たちが何で苦しんでるのか、
どういうものが、
密結合なのかっていうことが、
苦しんでるのに、
それが何で苦しいのかって、
分からないんです。
分からないわけですよね。
すごく分かります。
僕がその設計に興味を持ったのは、
まさに、
目黒さんがおっしゃってたようなところで、
一番最初に、
ウェブエンジニアになった時に、
全くコードが読めなくて、
それこそ、
IFとFORだけで、
なんとか作ったみたいな、
アプリケーションがあって。
それがもう、
全く読めなかったんですよね。
変数もよく分からない命名だったし、
制御構造も、
これは何をしたくて、
こういう制御構造になってるのか、
全く読めなくて。
それでもう、
多分、
僕が元々エンジニアじゃないところから、
エンジニアに来たから、
単純に読めないのかなって、
最初は思ってたんですけど、
経験者の人に聞いたら、
いや、そういうわけではなくて、
これはコードベースの問題だ、
っていうふうに言われて、
じゃあ何がおかしいの?
っていうのが全然分からなくて、
その時に、
当時はまだミノクド本がなかったので、
マスダ本を勧められて、
で、読んで、
設計というものがどうやらあるらしくて、
それをちゃんと設計されたものは読める、
人が読めるっていうことを、
初めて知って、
そこからちょっともう、
いろいろ勉強し始めた感じだったんですよね。
うん。
そうそう。
この辺のコンテキストとか、
ホワイが書いてある本は、
割と少ないんですよね。
抽象的にそれが書かれているのが、
割と少ない。
僕の場合だと、
A Philosophy of Software Designってやつが、
まさにそれだったの。
あれ読むまでは、
何とも気持ち悪いんだよなと思って、
コードレビューで弾きたいんだけど、
日本語に書き起こせないから弾けないな、
みたいな、
なんかそういう時が結構あって、
そう、なんか、
そういったところはやっぱり、
言葉とか概念をきちんと、
いろんなところから吸収して覚えないと、
ダメだなっていうのがありますね。
だからやっぱ、
素晴らしいなと思いました。
だから特に若手には読んでほしいと思いました。
ありがとうございます。
そうそう。
コメントについて書いてある本、
割と少ないんで、
僕の知る限り、
Double CodeとこれとAPI OSDぐらいしか、
コメントについてちゃんと書いてあったりしない、
気がする。
ですね。
別に、
美濃駆動さん、
美濃駆動も宣伝したくて言ってるんじゃなくて、
ちゃんと読んでよかったっていうのと、
この概念が書いてある本がない。
あんまないんで。
この切り口で。
僕は個人的にすごい推したいのは、
副教材の方なんですけど、
あれはすごくわかりやすくて、
美濃駆動さんも宣伝してましたけど、
Bug Hunter Reboot 2っていう、
美濃駆動さんが作ったゲームがあって、
それが、
美濃駆動を読みながらプレイすると、
すごく概念がわかりやすいというか、
Bugが敵として出てきて、
それを倒すために、
いろいろスキルを使わなきゃいけないんだけど、
正しい設計スキルを使わないとうまく倒せないみたいな。
敵の反撃を抑えるために、
テスト系のスキルを使って、
反撃を抑え込まないと、
レガシーシステムに反撃食らって死ぬみたいな。
ゲーム設計がすごくよくできてるなって思って、
本を読むと、
なるほど、こういうことか、
すごくわかりやすくて。
その動機を生み出すものは、
設計スキルの獲得方法
きっとクソコードであるみたいな。
卵が先かニワトリが先か。
そうですね。
きれいなコードベースでCICDがきれいに整備されていて、
みたいなところでずっとやってたら、
わからないところなのかもしれないって、
最近は思うようになりました。
バグハンターによる訓練方法
あれは、
なんだろう、
バグハンターって、
バグ退治とかアレスとか、
レガシーコードを退治しに行くゲーム。
あれ3作目なんですよね。
あれは2のリメイク版として開発したものであって、
1があるわけですよ。
それ作ったっていうのは、
もともとそれに近しいゲームを、
RPGを誰かが作ってて、
開発現場が大変だみたいな感じの舞台で、
小さい単なる同人のRPGなんですけども、
敵としてドルエクセプションが現れたとかって、
とか出てくるわけですよ。
それに対して、
主人公側の技とかが、
ゲーム開発と設計技術
栄養ドリンク飲むとか、
残業するとかっていうので、
ひどい。
ちょっとそれ違うでしょみたいな。
違う違う違うって、
そういうものを倒すのは、
職場のドリンク飲んだりとか、
残業するとかそういう頃じゃなくて、
こういうやつは設計技術で倒すもんやろみたいな。
っていうところのひらめきから、
バグハンターを作ったんですよ。
僕のゲームでは、
いろんなスパゲッティコードだったりとか、
データクラスだったりとか、
いろんな敵がいっぱい出てくるんですけども、
普通に殴っただけで倒せなくて、
技としてバリューオブジェクトだったりとか、
MVCとかMVVMだったりとか、
あとユニットテストとかっていうものを、
駆使して初めてやっと倒せるような、
バトルデザインになってるんですよね。
何も考えずに通常攻撃で殴りかかると、
返り討ちでボロッコ化すんだるっていう。
いや、システム開発って確かにそうなんだろうなーみたいな。
ゲームとしてもすごく楽しかったですし、
勉強になったなーと思いました。
なるほど。
いやいいな、やっぱすごいですね。
素晴らしくいろいろ考えて作ってるんですね。
あれしかも4年かかりましたよ。
すごい。
そうそう、みのくどうこもも2年ぐらいずっと、
書いてたって話聞いて、
すごいですね、この持続力が半端ないというか。
いやなんかもう、
去年、ちょうど1年前とか僕は視線をさまよってましたよ、ちょうど。
なんか、さっき言ったバグハンターズリブートは、
本を書きながら制作してたっていう時期があって、
リリースしたのが去年の9月なんですけども、
夏のあたりとか本書きながらゲームとか作ってたんで、
1年前の俺からしても、お前バカかみたいになってた。
いやでもなんか、
作ったゲームは本と繋がりがあるし、
これはぜひやってほしいから、
本に載せるためにこれ何年も完成させないと、みたいな感じで、
意地でやってましたね。
意地と自己顕著欲と売名行為でやってましたからね。
売名行為。
いやすごいですよ、ほんとすごい。
売名行為でも、でもできたら勝ちですよ。
大変でしたけどね。
リリースしたもん勝ちだもん。
いやでもこれで、大木さんにもこれがちゃんと届いていたという、
駆け出しエンジニアにも届いていたというのは素晴らしい話。
そうなんですよね。
僕も最初の頃全然分かんなくて、
エンジニアになった頃、とりあえず僕の場合は、
師匠になってくれた人は良かったんですよ。
全然何も教えてくれなかったんですけど、
とりあえずリファクタリングっていう本をぶん殴られて、
これを読む。あとはテストを書けっていう、
その一言だけ言って、もうお前は大丈夫だって言っていなくなっちゃった。
すごい。
でもそれのおかげでなんとか生き残ってこれたのって感じがします。
やっぱテストを書くと構造にどうしても気をつけないといけなくなるので、
自然と良い方向を向けるプラクティスがつくみたいなところ。
リファクタリングはバイブルですね、僕にとっては。
職場での設計技術の浸透
僕も一番最初に良い本。
その後、一瞬テストマニアみたいな病気っぽいところを通過して、
全てテストが書かれなければならないみたいな感じで、
職場で浮いてる時期とかも経って、今ようやくバランスの良い本ができたかなって感じ。
なんか似てますね。
みんな中二病気みたいなところが通るのかな。
僕もプロジェクトが炎上した時に、
なんで自分が苦しんでるのか分からなくて、
これなんとかならないのかなと思って、
職場の本を読んだら明後日にリファクタリングに沿ってやって、
これだ!みたいな感じで、
仕事をやってる裏でこそこそリファクタリングに練習してみたいな。
そこからギャンギャン設計について職場でも吠えるようになって、
完全に職場でも浮いてましたね。
他の人は本当に仕様書があって、
仕様書通りに動くように実装すればいいだけなのに、
何あいつ騒いでんだみたいな。
なんかそんな扱いでしたね。
僕からしたら何言ってんだって、
こんだけボンボコボンボコ、
モグラ叩きのごとくすごいバグを生み出しときながら、
ちゃんと設計しないとバグだらけになって、
うちら苦しいでしょって、
作業いっぱいしてるでしょって、
持ち帰れなくて涙目立ってるでしょって、
だからちゃんと設計しようよって言ってるんですけども、
当時は誰も理解してくれなくてっていうのもあったりとかして、
僕も当時すごい浮いてましたね。
よかったよかった。
そうか、水野工藤さんも浮いた時期があったんだと。
でも浮きますよね。
浮いたのを経験しないと、
どうやったら職場できちんと取り入れられる、受け入れられるみたいな。
そうそうそうそう。
完全に、僕はもう完全に人手なし扱いだったんで。
なんかまたうるせぇ奴さわれてんなみたいな。
早く物を仕上げなきゃいけないのに、
何あいつ余計なこと言ってるんだみたいな。
おそらくそういうのはあったと思います。
僕も僕でそのろくに説得しないまま、
これやるのが正しいのになんでやらないんだみたいな感じで、
ある人と上から目線でがなり立ててるようなことをやってたので、
だからあれは僕としては非常に良くなかったなと。
だからそういうことしてたらはっきり言っていがみ合うだけですし、
全く品質向上に結びつかないので、
自分一人だったらそれいいかもしれないですけど、
チームでそれをやっていくためにはやっぱりこう、
ちゃんとそれが水平展開されるように、
丁寧に説明したりとか、説得したりとかっていうことがどうしても必要なので、
いいタイミングにやったけど、それが今は役に立てるなみたいな。
わかりますわかります。
プログラマの成長
僕本当に嫌な奴だったと思うんですよね。
先輩とかにね、これテスト書いてないですよって言って、
すごい。
すごい。
ドスレートですね、なんか。
そうそう。
何やってんすか?つって。
設計と興味関心
こないだカリバータを引っ張ってちゃうみたいな感じで、
すげー嫌な奴だったと思うんですよ。
あの頃の自分はちょっと引っ張っていきたいですけど。
僕もですね、お前何言ってんだお前って。
そうそうそうそう。
お前何言ってんだよ。
そんなんて話し取るわけがねぇだろみたいな。
そうそうそうそう。
いやいやいや。
まあ皆さん同じ苦労してるんですよね、みたいな。
そうそうそうそう。
職場の人もやっぱり聞くと、アーキテクトとか、
まあ設計周りに興味ある人はみんなやっぱりそういう時期をちょっと、
受けてるなっていう感じがありますね。
まあでも言うてその、アーキテクトっていうか設計に興味を持つ層っていうのは非常に少ないって言われてますからね。
うーん。
僕の以前勤めてた会社でずっとソフトウェア設計やってた人がいたんですけど、
今までずっとソフトウェアのエンジニアリングだってみんなそれぞれ色々層が違うじゃないですか。
フロントに興味ある人、バックエンドに興味ある人、インフラに興味ある人みたいな。
全然技術分野とかも全然違くてみたいな。
みんな興味が違うんですよね。
じゃあその中でその設計に興味を持って実際にその手を動かしてやっていく人ってどのくらいいるのっていう風な話になった時に、
その人曰く、まあそれ何十年もやってきた人なんですけども、
見てきた中では本当に1割か2割にも多分満たないだろうっていう風なことを言ってて。
うーん。
コードの品質
それはなんかやっぱり僕としてもやっぱり同じ感じで、やっぱりなり手がすごく少ない。
うーん。
そういうのもあって、周囲になかなかご理解してもらえないっていうのもあるんじゃないかなと。
普通に仕事やってるとやっぱり仕様を満たすようにソースコードを書くっていうので、
一番の近道はトランザクショナルスクリプトなんだなっていう気はちょっとやっぱすごかったですね。
目の前に一つ何気ない文献文記を置いて、循環的複雑の位置上げるっていう。
いやいやいや。
1コミットずつ繰り返すと、いつの間にか大きくなっているみたいな。
波動犬ができちゃうわけですね。
波動犬ができちゃうわけですね。
いやもう、これは言って大丈夫かな。
こないだみんなと設計話とかをしながら画面共有して見てた時にパッて開いたら、
息のいい波動犬。みんなまだ見たことない波動犬。
会社で発見したやつが大爆笑でした。こんな綺麗な波動犬があるんだ。
それはひどいな。
昔の本なんですけども、質の悪いコードは東風から見たらすぐわかると。
モニターを東風から見るとコードが左右にうねってるんだと。
左右にうねってるからそれすぐわかる。
だから品質が悪いかどうかを少し離れて見ろっていうのが何かの本に書いてありました。
なるほど。すごいですねそれは。
プログラミングトポロジーみたいな文字列の構造で。
エディターで折り返し設定しないと永遠に右スクロールが終わらないみたいなコードありますよね。
引数めっちゃ多いみたいなパズルがありますからね。
僕なんかもうトランザクションスクリプトパターンで書くのも気持ち悪くて。
もちろん設計っていうものを何も知らなかった頃っていうのは別にそれに対してあまり違和感を覚えなかったんですけど、
今それを書こうと思うとすごい無視図が走るんですよ。
普通にちゃんとデータの普遍条件とかオブジェクトの普遍条件とか考えて書くっていうのが普通に当たり前みたいな。
それで慣れちゃったらそっちで書く方が全然早くて、
逆にトランザクションスクリプトで書く方が気持ちは悪くて手が止まっちゃうんですよね。
僕もテストから書くんで、トランザクショナルスクリプト的な形だとテストしにくくてしょうがない。
やっぱ書けないですよね。どんなに簡易的に粗雑に一個目動くように作るんですけど、
それでもやっぱある程度もう形が分かれた状態になるようになる。
そうですよね。人の行動を受け継いで1メソッドが2000行くらいあったりするとやっぱこうきますよね。
2000行ってバケモンですね。クラスだったら分かるんですけど、メソッドが?みたいな。
そうそう。これは実に見事だみたいな。
僕も脳内メモリーがすごい貧弱なんで、200行とかエディターの縦の画面に収まらないと乗らないんですよね、メモリー。
脳内メモリーが少ないっていうのは、それは僕は良いことだと僕は思ってます。
むしろ、中にはそういうキャッシュメモリーがすごく多い人がいて、
いますよね。
こんな長いコードでも普通に乗りますけどっていう風に自慢してくる人がいますけども、
でもみんなあなたのような人なんじゃないですよって。
普通はマジカルナンバーフォーって言って、普通は人間が一度に同時に把握可能な個数っていうのは大体約4個だっていう風に言われてます。
だから僕はこれ身の黒本にも書いたんですけども、
一クラス内で取り扱う概念は大体4個以内に収めましょう。
そうすれば一クラスでは大体100行くらいあって、多くても200行くらいになったものなんですよっていう風なことを書いてて。
それ以上になると普通の人にとって認知負荷が爆発して、記憶に負荷がかかって、何書いてんのこのコードってわかんなくなっちゃうわけですよね。
やっぱりシステム開発っていうのはたった一人でやるんじゃなくて、
プログラムの構造化
複数のいろんな演じ者さんを交えて組織で開発していくものなんで、
たった一人の人だけがたくさん覚えられるシリーズなんてそんな生きられても困るんだと。
そうじゃなくて、普通のキャッシュメモリの容量を持った人たちが普通に開発生産性を発揮できるようになるために、
ちゃんとプログラムを構造化しましょうというところが僕は大事だと思います。
本当僕もそう思います。認知負荷が高すぎる人はむしろ問題になりがちっていう感じはすごくする。
本当にこれ?みたいなマニキュアが来たりする。
1回でこれ書くんだ、むしろすごい優秀なのかみたいな感じは。
でも他の人には読めないなみたいな。
何でしたっけ、ソフトウェア、フィロソフィー用ソフトウェアエンジニアに出てくる、タクティカルトルネード的な人ですね。
タクティカルトルネードはもっとひどいと思いますね。
その本読んだことないんですけど、何ですかそのタクティカルトルネードっていうのは。
ソフトウェアの品質属性とトレードオフ
要するに目の前の仕様を満たすために構造とかは無視して、仕様を満たすだけのコードを書く人ですね。
コメントが早く、開発スピードが早く、フロントって言ってるのはフロントエンドではなくて、
PDMとかPMとか、プロダクトオーナー側からは受けがいいと。
とにかく動くものをすごく早く作れるから、ビジネスサイドからするとあいつは天才だなんだけど、
エンジニアからしてみると技術不細の塊をドカンって残していく人だから、
エンジニアからは嫌われるみたいな人を、戦術的プログラミングのゴンゲっていう意味でタクティカルトルネードという風にその本を読んでる。
そういう風にして複雑性が増していくんですよ、みたいな。
でもすごい、その本の、書者の人がお知り合いなのかどうかわからないですけど、
Facebookで動くからリリースしようぜっていうのは、多分ベンチャーとかではすごく有効な指標だったと思うんですけど、
結果としてFacebookは複雑性に耐えられなくなって、今はすごくちゃんと設計するようになったと。
その結果、リアクトとか、PHP界隈でいうと、PHPの新しいものを、ヒップホップJS、
名前が出てこなくなっちゃった。
ヒップホップVM。
新しい。
ハック。
ハックを作ったりとかっていうことになったんで、やっぱりよく考えて書いた方がいいんだろうなっていうな。
その本でも耐性するにはどっちのやり方でも成功はするけども、
エンジニア的にはちゃんと設計した方が幸せになるよね、みたいなことが書いてあった気がします。
まあでも言うて、変更容易性を高めるような設計っていうのは、
長いスパンをかけて価値を発揮する、経時変化で発揮していくものなんで、
そういうスタートアップとか、序盤ではある種ちょっとコストってか、
最初にスピードを発揮できない重荷にしかどうしてもならないっていうのはどうしても厳しいところですよね。
そうなんですよね。
だからスピードも持ちつつ、変更容易性もある程度担保しながらみたいな、
トレードオフを上手にできるレベルのプログラマーってなるとやっぱり、
もう本当にやっぱ数が少ないっていう感じはしてしまいますね。
で、まあ悪口でもなんでもないですけど、やっぱりララベルでもレールズでも、
やっぱ酷いコードは大量に生み出されていくのが見えているので、
って感じがしますね。
いやーそりゃそうだよなと思ってリリースしたいもんだって。
しょうがないと思う。
やっぱりその辺、スタートアップ時はどうしてもやっぱりソフトウェアの品質属性っていろいろあって、
どれもトレードオフになるので、スタートアップの時はやっぱり機能性、
要は顧客にどんだけ利率するかっていう指標ですけども、
それを重視しつつも、でもそれだけだとまずいから、
最低限品質を保てるように変更用意性に少しだけコストかけて、
だんだんシステムのスケールに従って、
だんだん変更用意性の方に少しずつコストかけていくみたいな感じで、
そういう品質のコントロールできる人が必要なんですよね。
でも、あんまりいないですよね、たぶん。
いないですよね。
大抵がーって炎上してから誰か助けてくれーみたいな。
そうそうそうそう。
大抵その時は天越えしてるっていう感じですよね。
でも1回目の助けてくれーできちんとリプレイスできたら、たぶん。
その後10年くらいはきっと幸せになるみたいな。
やっぱすごいなぁ。
最初の話題でもう45分が過ぎてしまった。
本当だ、15分くらいで終わっちゃうよ。
すごくいい話ができたなと思って。
そうですね。だから概念は知ってもらいつつ、
あんまり中二にならないようにみんなと仲良くして。
目の前にある生きたコードが一番の材料だと思うんで、
それで改善していってもらうと一番いいですよね。
思考リファクタリング
未読読本で紹介されていた思考リファクタリングっていう概念を僕は知らなくて、
それを初めて知った時に、なるほど、そういうやり方があるのかと思って、
ここ半年、未読読本を読んでから何回もやったんですけど、
確かにあれはすごく、
未読読さんもそれで力がついたっておっしゃって。
そうです、あれでめっちゃスキップしました。
すごい勉強になりました、僕も。
なるほど、こうやって整理すればいいんだなっていうのが見えるのと同時に、
それをやることで新しくコードを書くときも、
これはもしかしたらこういうクラスにできるんじゃないかなみたいな。
見えやすくなるというか。
そうなんですよね。
でも本当、頭で考えてるだけじゃダメなんで、
やっぱこう、コードを書かないと。
コードを書いてみると、
あ、全然無理でしたみたいな。
すいません、全然無理でしたみたいなことでしたみたいな。
これぐらいリファクトリングできるだろうと思ってやってみたら、
全然歯が立たなくて、激伸したりとかもしれない。
そうそうそうそう。
僕もそれ日々やってますね。
でもやっぱその歯が立たないやつを何とかすると、
何とかできるとすごい脳汁がビュービュー出てきますよね。
変なシーンが出てきますよね。
こないだ脳汁出ましたね。
綺麗に言って、うわーって思って、これだーって思って。
大抵そういうのって風呂入ってるときにひらめくんですよね。
仕事してる仕事で、
なんだこれ、なんだこれ、なんだこんな難解なコード書いてる。
なんだこれーみたいな感じで。
ういしん坊の会話ユーザーのごとく、なんだこれーみたいな。
なんだこれ書いたなーみたいな。
これどうやって整理するんだろうなーって部分を考えてて、
仕事中は全然思いつかないってことが本当なんですけども、
どうなってんだろう、どうなってんだろうって思いながら
風呂入ったーってなってると、急にひらめくわけですよね。
あーって。
なんでしょうね、コード目の前にしてるとなかなか出てこないですよね。
僕の設計のいいアイディアとかって、
アイディアのひらめき
散歩してるときとか。
うちは庭があるんで、庭の芝刈りとかしてるときに、
あ、それかーみたいな。
あ、こういう風にすればいいのかみたいな。
そういう案はよく出てくる。
なんかやっぱりその、
認知科学と思考の重複波モデル
脳みそうまく働かせるには、やっぱりリラックスの方がすごい
大事みたいなやつね。
脳に余白を意識的に作らないといけないみたいなのを、
富永さんのこのラジオで
いつだかそんな話をされてたような気がします。
したかなー。覚えてねー。
なんだっけ、最近僕その
認知科学の本とかたぶんちょいちょい読んでるんですけど、
なんだっけな、
思考の
思考っていうのはいろんな
波としてどうも表現される、
することができるとかっていう話で。
だからなんだっけ、
ちょっと忘れちゃったんだけど。
ちょっと待ってくださいね。
どれだろう。
ちょっと本があったんですけど、
波で表現されるとかで、
なんかその思考の
なんか15、
波が重なってるとかっていうこと、
重なりでなんか表現することができるとかっていう話。
で、その波を
なんかそのうまく、
波の効果をうまく
出てきた。
思考の重複波モデルと呼ばれてるものですね。
重複波モデルとかっていうもので、
いろんな人間の知識っていうのは、
いろんな知識のことをリソースと呼んでるんですけど、
この本では。
そのリソースのいろんな波の
重なり合いなんだと。
人のひらめきが起こるときっていうのは、
その重複波がうまく
働いたときみたいな感じのことを書いてて、
そのためにはリラックスしそうだみたいな感じのことを書いてましたね。
ちなみにその本
なんてタイトルですか?
私たちはどう学んでいるのか。
これですね。
富岡さんが読んでたやつ。
めっちゃ面白いですよね。
これは最近読んだ中ではめちゃめちゃ面白いです。
みんな設計好きな人、
うちの会社の人もそうなんですけど、
認知化学大好きで。
思考にいてくるんだな。
結局我々がソフトウェアのシステム化の対象の概念って、
お前一体何なんだよっていうところを
噛み砕いていこうと思うと、
いろんな物事ってどう解釈すればいいんだろうって。
この今目の前に見えてる物って、
もうちょっと別な形として解釈できないですかね。
どうしてもそういうところに至るんで、
結局その考え方の考え方みたいなところを
アプローチしていかないと、
どうしてもその概念の解像度が上がっていかないんですよね。
だから別な見方をできるようにするためだったりとか、
別な解釈ができないかとかっていう、
そういう思考の幅を持たせるために、
物事の捉え方、
概念や違和感との向き合い方
哲学とか、
人ってどう物事を認知してるんだろうみたいな。
教科に付けられたコンテキストって
よく言われているやつですよね。
同じものを
見ているはずなんだけど、
コンテキストによって違うよね。
本来は別の概念だよねっていうもの。
データだけ見てると分からないけどもっていう。
そうなんですよね。
コンテキストめちゃくちゃ大事で、
くっついちゃってるやつが一番難しくて。
僕もこの間どうクラス設計してもどうしてもダメで、
一体何が悪いんだろうってずっと考えてたら、
あ、お前は別じゃんかみたいなやつが
ひっこりたことになる。
あ、そしたらうまくいくわみたいな。
そういうやつとか。
認知するまでがすごい大変で、
それをもうちょっとサイクルよくできるといいな
みたいな思うんですけど。
ちょいちょいお聞きするんですけど、
井上さんとかもビジネスサイドの人たちと話していて、
ビジネスサイドの人たちすら
認識していない概念みたいなものがやっぱりある
みたいな話をよくお聞きするんですけど、
そういうのって
どうやって名前を付けるんだろうって
ちょっと気になっているんですけど。
名前。
これはもしかしてこういう概念なのではあって、
ひらめいたとしてもそれをどう
ビジネスサイドの人たちと
言い引き出す言語に落としていくんだろう
っていうのがちょっと興味があります。
個人的に。
なんだろう。
最初の気づきとしてはやっぱり
違和感ですよね。
なんかその
エンジニアサイドが
例えばシステム上で扱っている
なんちゃらっていう概念があったとして
エンジニアサイドから
これって何ですかって聞いても
なんか歯切れが悪かったりとか
ビジネスサイドの人に来ても
何かどっかつかかりがある感じの
そういう違和感があったりとかして
当然その点で
それ関係のソースコードを見ても
すごく複雑で
すごく複雑なんですよ。
やっぱりそういう
違和感を覚えるときってのは必ず
何かしらその
本来あるべき違う
ものが隠れていてとか
例えば僕が今まで見てきたものの中には
なんちゃらって名前がついているものがあったんですけど
実は分解していったら
全く違う概念が4つ重ね合っているの
酷いやつだったんですよ
それを例えたら
商品ってついているのに
そこの中には
キャンペーンの広告みたいな
概念が入っていたりとか
キャンペーンは別やろみたいな
とか
商品を
紹介するための機能
なんでそんなことが入っているのって
その商品を本当に紹介するってのは別でしょ
っていう全く
今まで見えも隠れもしなかった
概念っていうのが
色んな話を聞いてみたりとか
それが実際
問題解決と問題発見
そこと関係するソースコードってどこなのとか分析をしていったら
実はそういうデカい
今まで誰にも何にも語られなかった概念が4つ重ね合っている
その結果
この概念って
これとこれとこれのことですよねって聞いたら
確かにそうですねみたいな感じで
確認取ったことがありますね
感じるのが違和感
違和感に説明がついたときは
僕はすごい脳汁出ますね
何なんだろうみたいな
別に隠れた概念の話じゃないですけど
よく
問題っていうのはその問題が何かっていうのを
言葉で表現することの重要性
言葉で説明できたら半分解決しような
あれと同じだと僕は思ってるんですよ
まずちゃんとその言葉にして表現する
人間って分かっているものだけを言葉にして表現できるものと
思ってるので
よくわかんないなっていうものは言葉にして表現できない
あれって何なんだろうすごく燃えついてるすごく気持ち悪い
だから
設計技術を高めるには
常日頃から自分が思っていることを
ちゃんと言葉にして表すっていう活動がすごく大事かなって思うんですよ
だから
例えば技術記事を書いて
聞いたり全とかに投稿してみたりとか
そういうのを万人が目につくところに文章を書こうと思うと
分かんないことがあったりとかって詰まるんですよね
だからこれ分かんないって何なんだろうって
だからそれって分かんない部分だから
分かるようにちゃんと調べたりとか
その結果分かったものをちゃんと
整地化した言葉でちゃんと明瞭に書いて説明したり
人に分かるようにちゃんと説明したりとか
そういう言葉一つ一つっていうのが
要は自分の設計の技術っていうのを着実に高めていく方向性だと思います
すみませんなんか偉そうなことを
プログラマーの仕事は名前を付けたら半分終わってるみたいな話も聞いたことがあって
なんかいい名前が付けばもう半分仕事は終わってるっていうか
そうですよね
エンジニア以外の仕事もそういうところあるのかなって個人的には思っていて
なんかゴールが見えて何やるかが明確になってればもう仕事半分終わってるよねみたいな
そうですね
そうすると意思の疎通とかもやっぱりすごく楽になるし
なんか認識をね合わせるのが
結構あるのがねビネスサイドとエンジニアが
微妙にこう違った言葉で喋ってる
微妙に概念が違って焦点がずれてるみたいな
それが焦点がずれてるっていうことに気づけるように
自分の中でこう解像度上げていくみたいなのが結構大切なのかな
データベースをめぐる話
エヴァンスボンにも書いてましたよね
なんかあのエンジニアはそのビジネスサイドが言った言葉を
勝手にその技術用語に翻訳して喋る
だからあれは良くないみたいな感じのことをエヴァンスボンに書いてて
そんなことをしてたらその
ビジネスでやることと
いわゆるソース構造上のテクニカルの部分っていうのはだんだんその
すいません
帰りが生じてくるからそれ良くないって
ドメインを一致させることができなくなるからちゃんと言葉揃えましょう
ちゃんと指揮多数の言語で話しましょうっていうことで
説明しますよねそこは
すごいわかります
僕はそういう時はすぐアホなフリをして
それって何何ですかねとか
ちょっとわかんないで教えてもらっていいですか
のはよくやりますね
僕はその逆にあれですよね
なんか
よくその特に僕
web 系に来たのが3年前だったんで
それまでずっと組み込みとかネイティブアプリ開発やってたんで
ある種そのデータベースとは無縁な世界で生きてきたんですけど
だからそのデータを保存する手段っていうのは
別にデータベースだけじゃなくてファイルだったりとか
外部のシステムに転送したりとかいろいろ方法があるわけですよ
ところがweb 系に来てびっくりしたのは
みんなデータベースドリブンで話すんですよね
こういう設計ってつまりそのテーブルの
テーブルのこのなんかこう構図にしたらどういう風な
どういう風な絡みを持たせるんですかって
僕データベースのことなんか一言も話してないですよって
なんでデータベースの話をするんですかみたいな
そういうのを僕web系にやってきてから何回もそういうのがあって
えってみんなそれデータベースベースで考えて
データベースがパーソで考えてるのみたいな
そういうカルチャーショックを受けたことがあります
それはそうですねずっとweb系で生きてきた私としては
身につまらない
そうだから結局その
保存手段どうするんだみたいな感じの話になったりすると
途端にその
あの結局技術駆動になってしまって
結局そのシステムでそのドメインの問題って
どうやって解決しないのっていうところがすぐボケて
わかんなくなってくるんですよね
だからもちろんそのそういう設計というのはやらなきゃいけないんですけども
ウェブ開発と技術設計
そこを第一に考えてしまうと
なんていうかちゃんとそのシステムとして達成したいものっていうのは
ちゃんと物事なんかずれてくる
保存手段はあとだと思う
そうですねまあでも
だいぶ年食ってきてアプリケーションの都合ばっかり考えたデータベース設計はしなくなってきてるんで
まあそれもまあそれなりにやっぱ経験とかを積まないことにはわかんないのかな
っていう気がしないでもないな
なんかでも結局ちょっと長期で運用して痛み見ないと
ちょっとありますね
そうだから例えばそのドメイン駆動設計では
データベースとか要は映像化に関する知識は
インフラストそのリポジトリの方に追いやっちゃいましょうと
だからそうすることによって
要はドメインとして表現するものを
ドメイン層に表現することができるんだという風な教えがあるんですけども
僕はそのなんだろうある種そういう設計っていうのは
ずっと組み込みとかネイティブやってたんで
要は保存の対象がファイルだったりとか
別のシステムへのデータの転送だったりとか
いうものを対象にしてたんで
それはすぐ分かったんですよね
どう隔離しなきゃいけないのか分かって
だからそのウェブ系にやってきて
データベースファースで話す人がいても
それは違うんですよっていう風な
そこはリポジトリで隔離して
別に考えるところなんですよっていうところが
すぐスッと入ってきましたねそこは
そこはなんかある種僕は
最近ウェブ系にやってきたんで
僕も今でもウェブ系の知識足んなくて
ハンデだなとかって思ってるんですけども
逆にある種そういうテクニカルな部分と
切り離したアプリケーションを設計する上で
リポジトリ問題と教育について
僕自身の経験としては有利に働いてるなという風に思います
ウェブ系でよくありがちなのは
リポジトリという名のリポジトリじゃない問題
君のシステムにはサービスというクラスと
リポジトリというクラスがあって
ほぼ同じことが書かれているから
あなたにとってのリポジトリとは何か
僕に説明していただきたいみたいな場面には
かなりよく遭遇していて
そうですね
その辺はどう教育していけばいいのかなみたいなところと
そもそも現状そういうのがいびびでありちゃってるのを
どういう風に解決していこうかなというところは
ちょっとすごいよく考えますね
そうなんですよね
ウェブ系の人たちはみんなデータベースはやっぱ大好きなんで
俺たちのやることは
ブラウザから受け取ったデータを
データベースにしこっと収めて
それをゲロって出したら
これがウェブシステムだみたいなところはちょっとある
いやデータベースだろうみたいなところね
セッションをレディスに入れたりはするぐらいかな
でもそうすると結局
全てがデータベースの構造に引きずられちゃうんですか
いやほんとねもうまさしくその通りですね
困った時にライトとリードを開けたいとかっていった時に
しこっと開けられないみたいな問題が
もうそこら中で頻発してしまうし
データストア変えたいとか
ここだけ文語にしたいみたいな
ここだけイベントドリブンにしたいみたいな
そういった切り返しがすごく辛くなります
もう横で繋がっちゃってるからもう開けられないみたいな
そういったパターンを本当によく見てますね
僕が過去に経験したシステム
開発したシステムでは
アプリケーション上のデータを
全く形式の異なる3つの方法で
映像を放題して転送するっていうような仕組みのものがあって
一つはデータベース
もう一つはXMLに変換してファイル保存する
もう一つは独自のデータ転送システムがあるんですけども
そのプロトコルにデータのフォーマットを変換して
外部と送信するっていうようなものがあったんで
結局それっていうのは何か一つのデータフォーマットで
アプリケーションを作り上げると
それに依存した構造になっちゃうんで
破綻しないですか
破綻しますね
だからそれは僕はその開発の途中から入ったんですけども
そこの部分だけちゃんと作られ
そこの境界だけちゃんと作られてたんですよね
アプリケーション上のデータの構造はこうですよと
外部に転送する3つの転送先は
そこの境界ごとにフォーマットを変換して
外6つの出し入れをするっていうようなこと
そこだけはちゃんと作られてましたね
いわゆるポート&アダプターみたいなやつですか
統合されたシステムの問題
まあだと思います
いやもう今ね
すごく嫌なコード例がもう頭の中に浮かんできた
確かに
みたいなところがある
あれかみたいな
あれなーこれはあれの悪い例だなーみたいな
ありますね
なんかあるんですよちょっとすいません
その神クラスのことをずっと考えてるもんで
すぐに頭に浮かんできちゃうんで
あいつどうしようかなみたいな
という感じでなんとあっという間に1時間が来てしまいまして
あっという間です
そろそろ終了の義に
いやもう大変楽しくてありがとうございました
こちらこそありがとうございました
すごく親近感が湧きました
やっぱり設計を志す人はみんな同じような
問題意識を持つんだなみたいなところ
終了の挨拶
はいそうですね
じゃあちょっと終了の義にですね
移ります
今週も放送を聞いただきありがとうございます
番組のフィードバックや要望は
次回も聞きたい方はぜひ
チャンネル登録お願いします
本日の相手は
ありがとうございました
ありがとうございました
