ソフトウェアのリアーキテクチャリングと秩序回復
こんばんは、Yokohama North AM第77回です。
Yokohama North AMは、Web系エンジニアがテック系のキーワードをネタにして雑談をするポッドキャストです。
ホスト役は、自称PHPRのHANHA1978です。
本日のお相手は、ShinbaraさんとHisateruさんです。
よろしくお願いします。
よろしくお願いします。
やいのやいの。
やいのやいの。
放送の10分前ぐらいまで、ちょっとバタバタバタバタしてしまいましたから。
そんな人がね、放送に行って間違えてただなんて、バラさないでくださいよ。
いや、めちゃめちゃ面白かったんで、大丈夫です。
焦った。
なんでザワザワしてるんやろと思ったら、あれ、今日、あれって。
最初にお話を聞いた時から完全にね、明日だと思ってましたね。
何を間違えたか。
今朝、リマインドしようと思ったんですけど、今朝、ほんとちょうどよく、僕体調崩してまして。
ちょうどよくないじゃないですか、お大事に。
いやでも、夕方にかけて元気になってきたんで大丈夫です。
お二人のご紹介ですね。
しんばらさんとひさてるさん、お二人ともですね、カンファレンスとかでちょっとお知り合いで。
しんばらさんはあの、ポッドキャストでもよくお話しさせていただいたんですけど、ひさてるさんはほとんどツイッター上でのやり取りですかね。
ああ、はい。
だったんで、ちょっとちゃんとお話ししたいと思いまして、今回ポッドキャストにお呼びした次第ですと。
はい、呼ばれました。
お二人とも、お二人ともバックエンドエンジニアということでよろしいんでしょうか、しんばらさんとも。
そうですね、はい、大丈夫です。
まあ、僕はあの、ちょっとフロントにも噛んだり、なんせ人が少ないので全体的にやってます。
なるほど、ありがちなあれですね。
フルスタックエンジニアですね。
かっこ笑い。
言わないようにしとる。
で、今日ですね、お二人をお呼びしてどんな話しようかなって思った時に、
ちょっと自分が最近会社でソフトウェアのリアーキテクチャリングっていうことで、
レガシーなソフトウェアを秩序を回復させていくみたいなことを仕事としてやってますと。
で、僕から見るとしんばらさんもひさてるさんも、僕よりも設計とかその辺が登壇とかもされてたって、
なんかいいアイデア知ってるかなと思って、
どうやってサービスインした後のソフトウェアの秩序とかをみんな保ってんのかなみたいな話ができたらいいなと思って、
ちょっと今日開催させていただきました。
はい。
っていう感じです。
どの辺から話しますか?
コードの複雑度とボーイスカウトルール
ね、ちょっとお題を何か。
お題、この間ちょっとメトリクスをとにかくいろいろとってみようと思って、
会社のソースコードをメトリクスをとってみたんですね。
で、その中に最近循環複雑度とかっていうのが取れるんで、
それをちょっととってみたっていう。
そのランキング1位になったやつが、ちょっと口には言い出せないほどの複雑度で、
これはすげー大様だなって思ったんですけど、
ちょっと気づいたのが、複雑度が増えているファイルとコミット数と複雑度の具合がほぼほぼ線形に伸びてるんですよね。
運用保守されて、機能が追加される度に複雑度が線形に増えていった。
その結果として今この状態になってる。
で、よく言われるのが、ボーイスカウトルールだなんだっていう話があって、
複雑度が増えるように開発しないと。
ちゃんと直しながら来た時よりも美しくと。
で、多分そんなことはわかってるけど、結果こうなってると。
じゃあそれをどうやってみんな防いでって言うのかなとか、
どんな工夫してるのかなみたいなことは知りたいなって思いました。
この前たまたま見かけた記事で、
マイクロソフトがWindowsのVistaとか7とかあたりを作ったやつっていう時の話って読まれましたっけ?
読みました。僕も読みました。
読まれました。
割と最近ですよね。
最近ちょっと流れてきて、珍しくサイトの方に記事を見に行ったっていうのがあったんですけども、
タイトルだけで反応してるみたいな人になってる。
あれですね、関わった人数が多いほどバグが多いコンポーネントになるっていうようなまとめでしたね。
直感的にそれはそうだろうなっていうのが、数字で統計的に出せたっていうか、証明できたっていうような記事があったと。
単純にコミット回数が多いっていうよりも、無神経に手を入れる人が多いっていうのが結構一番でかい原因かなっていうのは思いましたね。
自分の仕事ができればいいっていう視点でいくと、他の人の思ってたことが伝わってないというか。
割と大きなコンポーネントだとそうなりやすいですよね。
コンポーネントの命名と異なる文脈での名前の衝突
コンポーネントは小さくて責務がある程度限定されてると、いろんな人がそこに手を入れるってことはやっぱり少なくなるけど、
いろんな役割をしてるコンポーネントに関しては、いろんな人がいろんな思惑で手を入れるから、そうなりそうだなっていうのはなんとなく直感的にもわかりますね。
そうですよね。実は名前付けっていうやつは、みんなが思う以上にめちゃくちゃ重要なんじゃないかっていうのは最近すごく思ってますね。
何たらヘルパーみたいなやつとか、何たらユーティルみたいなやつは、
抜群の吸着力があって、いろんなロジックが集まってるのを最近見かけまして。
これは、この名前は本当に良くないなと思って。
なんでもかんでも助けちゃうなみたいなところがあって。
そういうところからも考えなきゃいけないんだなとか。
名前付けはバッチリ、確かにそれは何とかマネージャーとしか呼べないねっていうのだったとしても、
いろんな異なる文脈で同じ名前が被るみたいなのあるじゃないですか。
何だろうな、画面用のところにも同じような名前のマネージャーがいて、
業務ロジックにも同じような名前のマネージャーがいて、
ソフトウェアの秩序を保つためのフォルダの切り方
確かにビューから見てそれはそうだし、業務から見てそれはそうなんだけど、
IDEでちょこちょこっと打つと、あれどっちっていうのが出るやつ。
そういうのがちょいちょいありますね。
まあまあ名前に気を付けたとしても。
そこは、僕割とパッケージ構成というか、フォルダの切り方。
こことここは別空間っていうのを重視したい気持ちが大きくて、
ここいじってるときはこっち見ない、こっちいじってるときはあっち見ないっていうような、
明確なモジュール分けがされてるのが理想だなって。
IDEさんもそこを明確に切って保管してくれたらいいのになってちょっと最近思ってる。
ライブラリーいっぱい入れてクライアントって打ったら何のクライアントかわからないのがいっぱい出てくるじゃないですか。
これやってるときはこれしかないじゃんっていうのがなんとかなってほしいなと。
その話でいうと、まさにクライアントとかだと、クライアントってクラス名だと今の出てきた話みたいなことが起こるんですけど、
じゃあhttpクライアントとかもうちょっと具体名をつけると、いやそれパッケージにhttpを示すようなことが入ってるから、
二重につけることにならないかっていう派と、いやでもクラス名見ただけである程度わかった方がいいんじゃないかっていう派がいて、
クラス名や命名のガイドラインの設定とチーム開発における課題
結構そこで意見が衝突するっていうか見解の違いみたいなのはよく起こるなと思いますね。
わかりますわかります。その日の体調によってもhttpでクライアントにするか。
いやいやいやいや、パッケージがhttpだからいらないでしょみたいな生意気感が入ってるんだから、冗長だよっていう時もありますね。
まあパッケージに説明が入っているときでも、クライアントがわかりづらいからエイリアス書けばいいっちゃいいんですけど、
インポートじゃないや、ユーズアズ。
そうそうそうそう。
いけないいけない。
これがタイプスクリプトとかいじってる病ですね。
いやーわかりますわかります。
あるある。
よくありますね。
語を書いた後はセミコロン入れられなくなっちゃうんで。
一時的に入れられなくなっちゃうんで。
あー忘れてる忘れてるってなるんで。
いけないいけない。
なんだっけ、そうだ。
ユーズアズであれですよね、ガゼルクライアントっていう名前にするとか。
そういうあれね。
まあそれでも防げるっちゃ防げるんですけど。
その辺ってどうしてます?特にチームで何か決めたりとかはしないですか?
命名規則っていうか命名のガイドライン的に。
ガイドラインは存在しています。
確実にそれが守られているかっていう保証まではできないっていう感じはあるかな。
過去に遡ってすべてがきちんと命名ガイドラインに沿っているかまでは確認できる。
今のうちの会社とかお話とかにするって感じですね。
レビュアーがそれをすべてチェックするっていうのは割と無理筋というか。
なのでCIとかもちろんPHP CS Fixerとかの辺は動いている前提として、
アーキテクチャ的な正しさとか意味的な正しさまではチェックできないんで。
そこは割とレビュアーの体調次第みたいなところはちょっとあるかもしれない。
あとはコミットの流度次第みたいなところがあるかもしれない。
ビッグバン来られたら多分通しちゃうっていう可能性はある。
そんな細かいところは見てられないっていう。
そうそう。
それも割とあるあるっちゃあるあるですよね。
それはさっきのクラス名の中にパッケージ名が入っているようなものはリジェクトするとか、
そういう辺も書いてあるんですか。
そこまでは書いてないですね。
そういったところまではこういう名前付けにしましょうとか、
こういう構成にしましょうっていうのがふんわり決まってるぐらいですね。
アーキテクチャ的な正しさと外部通信のルール付けのチェック
ただ結局そうすると秩序がなくなってしまうというか、
っていうところはあるので、
それをどうやって解決するかっていうとさっきヒサテルさんが言われたみたいに、
ボルダー構成とかディレクトリ構成で分けてしまうことで、
こっちの例えばチームの人、この機能いじる人はここの中しかいじれませんよみたいな状態を作ってしまった方がいいんじゃないかって思いつつ、
でも共通部分どうしようかとか、
外に対して通信を行う場合はどうしたらいいか、
そこらへんのルール付けをどうしようかっていうのが一つと、
じゃあそのルール守ってねっていうのを人間がチェックすることの限界みたいなものはちょっと感じていて、
なんで今いわゆるデプトラックみたいなアーキテクチャーのチェックツールとかは存在しているので、
それでどこまでできるのかみたいなところはちょっとよく見れるかななんてのはちょっと想像したりはしています。
そのチームっていうのはドメイン単位で分かれるっていう感じなんですか?
機能開発単位で分かれるっていう感じですかね。
特定のドメインですか?
いわゆるチートポで言うとこのサービスなんだっけ、
アイランドじゃなくてアラインのチームだっけ。
とかあんな感じのイメージですかね。
特定の機能を開発しているわけではないみたいなところがあるかもしれない。
リポジトリ自体は一つのリポジトリで複数のモノリポでなってるでしょうね。
はい、モノリポですね。
お互いのチームがマージしてもぶつからない場所をいじってるみたいな。
そうですね、もうその通りですね。
大規模ではあるがぶつからないところをある程度いじっている感じはある。
だから問題ない。
だったらもうディレクトリごと分けてしまったほうがきれいに分かれるだろうという感じを持っています。
ちなみにそれはチーム間で触るディレクトリ自体が依存するってことはないんですか。
それは共通部分だけ依存して、それ以外チーム間では依存することはないっていう。
モジュール化に関する考え方
ないっていう風にできたらいいなとは思うが、
そうはいってもいろんなパターンあるだろうなみたいなところはあるし、
つい最近メルカリさんが出してたのは、
ドメイン単位でモジュラーモノリスにするみたいな話を記事として出していて、
そういった考え方もあるなみたいな。
そうするとチームがいじる機能の一群みたいなものの他に
ドメイン単位での切り出しとかもあり得るのかなとか、
どういう風にするとうちの、
例えばそのソースコードにとって最適な状態になるかみたいなっていうのはもうずっと考えてますね。
なるほど。
じゃあチーム単位では分かれてるけど、
デプロイ自体はリポジトリ全体がどんとデプロイされるってイメージですかね。
割と世の中のサービス事業会社っていうのは多分モノリポで、
多分おそらくもともとスタートして、
というか分ける必要がないと思うんで、
そもそもサービスとして流行ってもいないものとかっていう気がするので。
でもどんどんどんどんでかくなっていって、
数年前とかにはマイクロサービスだっつって、
これを分割するのがいいんだっつって、
でも元々複雑なものを分割してどうするんだみたいな、
そんなドロー団子が分散するだけだっつって、
モジュラーを戻したみたいな話になって、
じゃあどうやってモジュラーに分けんだみたいな、
今ここみたいな感じですね。
僕としては。
なるほど。
それチーム間で依存するところって、
もうソースコードレベルで依存しちゃってる。
アーキテクチャに関する話題
要はAチームがBチームのコードの部分を普通に
ユーズして使うのか、
そこは何か疎結合に、
例えばHTTPで内部的に呼ぶとか、
そこまで切り出してるわけではない。
ない、ないですね。
ない。
そもそも今ディレクトリ分けをされているわけでもない。
これからどういうふうに分割していこうとか。
なるほど。
じゃあ機能が異なるから、
ぶつからないだろうっていうことで、
ディレクトリは実はクロスオーバーしてるかもっていう。
そうそうそうそう。
これをこれからそういうふうに分割していって、
平和が保たれるのだろうか。
それとも、なんだあのアーキテクトふざけやがってと。
こんな切り方するから開発しづらいじゃねえかと。
どういうふうになるのかみたいな。
そこは考えなきゃいけないな。
なるほどな。
うちの話じゃなくて、
珍しくちょっと予想をお手伝いした話があって、
本当に最初の1、2ヶ月、
キックオフレベルでちょっとお手伝いしたんですけど、
その時になるべくモデリングを、
モデリング?なんだろうな。
要はPHPユニットで理論上正しく動くっていうモデルをまず作って、
そっから画面を作ってっていう、
清く正しい依存順序を進めてみたんですね。
その時、ちょっとこれは伏線があって、
別の話にも波及するんだけどちょっと置いといて、
その時に僕がその後手を離れたら、
違う人が入ってきて、
依存方向がしっちゃかになったっていう話があって、
温度とってる人からしてみたら、
機能が動くから進捗が出て優秀だと見えるみたいなんですよね。
こんなディレクトリの分け方しやがって、
いちいち面倒くさいって思いながら多分やられてて、
ゴリゴリやっちゃう人はコントローラーに業務の名前の機能を作ったりとか、
しながら多分進めたらしいです。
噂によると全然その後の話は直接は知らないんですけど、
またぎきの噂でそんな流れになっちゃったらしくて、
リリースしたらしいんだけど大丈夫かなっていう心配があります。
一個これは伏線って言ったのが何かっていうと、
リーダーシップに関する話題
その時発注側というか、
一番クライアントのニーズに近いところにいるエンジニアさん、
ほぼほぼ身内な人がいたので、
その人にリーダーになってもらいたいと思って、
素朴に読める、Javaで言うとポジョみたいなやつを目立たせる感じで、
ソースこんなんですよ、ソースこんなんですよってどんどん出してたんだけど、
全然見てくれなくて、
興味を持ってもらえないというか、
モデリングに興味を持ってもらえない感じ。
画面が出てきて、やっとちゃんと作ってたんですね、みたいな。
うせえやんと。
というのがあって、
思ったんと違うなっていうのがあったんですけど、
何を言いたいかっていうと、
上手に作る人が必ずしもリーダーじゃないなっていうことを言いたくて、
決して自分、
その人はプログラムがすごく上手いとは思ってなかったんだけど、
ずっとそのプロジェクトにいてくれる人だと思ったので、
リーダーになってもらうべくいろいろ振る舞っていたつもりだった。
上手いことはいかなかったんだけど。
もしそれが上手いこと言ってたら、
その人がリーダーになってアーキテクチャを握ってくれたらよかったのにな、
という思いがあって、
自分の会社では、俺がアーキテクチャだ、みたいなところがあって、
ずっと張り付いてるんですよ。手を離したことがないというか。
常時、
うちの会社がやっているお仕事がプロジェクト数が少ないので、
常にこれかこれかこれだけ見てればいいっていう数の可能性はあるんだけど、
全部張り付いてます。
僕よりも大っていうプログラムを書くすごい人はいるので、
すごい人が必ずしもリーダーじゃなくて、
自分は下手側だけどこういう面倒を見続ける仕事?
と思ってやってる感じかな、というのが自分の今の感覚で。
それで彼、これ何年だ?
8年か9年ぐらいやってるのかな。
よく飽きもせずにですけどね。
全体的なソフトウェアの秩序維持の難しさ
それはでもすごいですね。
それと運用とか保守用意性とか、
そういったことを日立さんのほうでずっと張り付いて、
見ているみたいな感覚はあるんですか?
そうですね。
多分皆さんが思ってるよりももっとシンプルなので、
実際の仕事としては。
メルカリの分散システムみたいなそんな話じゃないので。
決して一人で見れない範囲ではないという前提なんだけど、
運用、UXからインフラまで、クラウドまで、
ザーッと全体的に自分はやっていますと。
やっぱりインフラとかミドルウェアも含めて、
アーキテクチャーがあってソフトウェアとして成り立っていくんで、
やっぱりどっかしら全体が見えてないと、
アプリケーションの形自体も見れないなっていう感じがちょっとあって、
大きくなっていくとやっぱり分割しなきゃいけないと言って、
マイクロサービスとか作るのかもしれないんですけど、
今の会社入ってもう2年近くになるんですけど、
やっぱり全体がようやく脳内に刷り込まれるようになってきて、
見えてくるところがやっぱりどうしてもあるっていうのはありますよね。
最初の頃は問題だって思ってたやつだけど、
実はそんな問題じゃなくて、
本当の問題はこっちじゃんみたいなところはやっぱり全体を見ないと分からないな。
2年経ってやっとの感覚は僕もよく分かって、
組織的な大きさがあると、
全業務の意味が理解できるのに年単位で時間がかかるというか、
かかります。
そうなると、ぶっちゃけあれですよね、
プログラム言語もう1個覚えるのの方がはるかに簡単っていうか、
簡単ですね。
この会社の業務全部理解しろと、
PHPのフレームワーク全部覚えろやったら、
フレームワークの方が簡単じゃね?って。
簡単だと思います。
時間も、その方が時間もかからないというか。
ってくらい、
エースとリーダーってそういう違いありますよねっていうのに結びつけたくて。
そうですね。
しんばらさんとかなんかあります?
そうですね。
僕はちょっと別の観点っていうか、
ネタ帳に書かれたソフトウェアの秩序をどうやって保つかっていうところで、
人間がこう、
正しい教えがあり、正しいアーキテクチャがあり、
ソフトウェアの正しさについての考察
正しい方法論があり、それをみんなが守って、
正しいものを作ろうっていうのは、
すごい良いとは思うんですけど、
それを全員に押しつけて、
そうじゃないとソフトエンジニアじゃないっていうのは、
相当無理があるというか、
それが本当にしかも正しい方法なのかすら分かってないのに、
っていう思いがあって、
もちろん教育とか知識をね、
みんなで共有していくってことはすごい大事なんですけど、
どっちかというとCIとかツールとか、さっきDevTrackとか出ましたけど、
できるだけ自動化して、
自動的に秩序を保ってるかっていうチェックができるだけできるような形に
持っていきたいなと僕は思っています。
やっぱりこう、
正しさってやっぱりその人によっても違うし、
コンテキストによっても違うし、
言うと体調によっても違うし、
すごく危ういもんなんですよね。
すごく揺らぐもんだから、
そこにあんまり軸を置きすぎると、
辛くなるんじゃないかなと。
それは自分自身も。
だからできるだけそのツールとか自動化しておいて、
ツール様が言うんだから、
それは人の気分とか関係なく、
エラーはエラーにしてくれるし。
だからそっちにできるだけ寄せたいなと思っています。
もちろん全部が全部そんなに万能なツールがあるわけじゃないんで、
レビューとかディスカッションで決めたりとか、
お互い指摘し合いながらっていうのはあるんですけど、
できるだけ機械的にチェックして、
エラーだったら直してください。
通るんだったら逆に言うと通るんだったら、
じゃあそれは自分の主張とは違っても、
通って機能的に問題ないんだったら、
じゃあそれは通したらいいんじゃないっていう風な考え方もありなのかな。
それでダメなんだったら、
それがダメとする何かしらのツールなり、
何かしらのメトリクスなり、
そういう客観的なものを用意する方向に
保守できる対象的なソフトウェアの秩序
行った方がいいんじゃないかなとは思います。
さっきのシャテルさんの例と一致するかわからないですけど、
言い方なんですけど、
言うと口うるさい人っていうか、
状態をちゃんとソースコードの健全性とかを、
ちゃんとチェックしてくれる人がいなくなると、
途端に荒れてしまうっていうことは往々にしてあるんで、
だからそれよりももうちょっとその人に寄らない方法で、
保てる方法を探った方がいいんじゃないかなと思っています。
でも本当に今まさに仕事でやってるのそれで、
今僕は改善をしてるわけなんですけど、
じゃあ改善前と改善後で改善されたっていう風に、
分かりますかっていうか言えますかと。
それがあなたの主観でないと言えますかみたいなところを
結構気にしないとダメだなと思って。
循環複雑なのがめちゃめちゃ簡単な指標なんで、
ただしやすいと。
さっき日立エルさんが言ってたみたいに依存方向。
これもPREPっていうツールで依存方向とか、
特定のファイルに対してグラフで表示できるみたいなのがあったんで、
それを使って見てみるとぐっちゃぐちゃになってたりするやつ。
でもそれは直すと線が見たまま綺麗になるんで、
そうすると明らかに分かるよねと。
上よりは下の方がいいよねみたいな話はできると。
ソフトウェア開発におけるメトリックスの重要性について
目に見させられないとか、数値にできないとかってなってくると、
やっぱ主観になって口うるさいおじさんで
言い続けないといけなくなっちゃって、
それだともしかしたら再現性がないかもななんてのは最近思ってます。
指標探してるんですけど、あんまり簡単に出せるのなくて困っとるって感じです。
なるほどね。
あれかな、やっぱ人によるのかな。
うちは人も少ないし、
依存グラフを絵に描かなくても、
これクロスしてるよねって、
こっち向きにしようよ、いいねって話が済んじゃうところはあります。
なので、メトリックスを数値化するっていうのが、
もうこんだけ長いことやってると、
全然ちょっと最近ピンとこなくなっちゃって、
なんかね、通じちゃうんですよね。
それよりも、見てこれいいやろ、めっちゃやりやすなってるやんっていうのが、
プログラマーの全員の主観でそうだよねって思う。
のに割と任せて、
無法地帯なんですけど、
秩序だってはいるなと。
で、それの根本って何かなっていうと、
みんな態度が同じ方向いてるからいいのかなっていうのは思っていて、
この仕事だけ早く終わったらいいっていうのがなくて、
みんなが同じようなポジション。
このサービスが長く続いて儲かったら、
会社が潤って自分も豊かになるっていう価値観に全員が立ってるので、
それが、
オレオレ技術哲学の自己主張みたいなのがない理由かなっていうのもちょっと思ったりしてるところです。
自分の話ばかりなんでね、
よそがどうっていうのも難しいけど。
でもチームとしてはすごくいい状態な感じが聞いているとしますね。
大人数でドーンと儲けるとかそういうのがないのでね。
でももしかすると、ゴールはみんな多分同じでも、
方法は人によって違うっていう可能性もあって、
今は日立さんのところは方法もある程度の方向性が多分合ってるんだと思うんですけど、
自分たちの仕事によって事業が儲かって、
自分たちも潤ってハッピーだよねっていうゴールは一緒でも、
アプローチが人によって違う場合もあると思うんで。
何かしらその辺が、
うまくすり合わせできるような材料があるといいんだろうなっていうのと、
僕の場合は日立さんがやられてるとはちょっと違うかもしれないんですけど、
自分がいなく、例えば自分が口うるさい役をやるとしても、
自分がずっとそこのサービスに携わるわけじゃないことがあって、
特に外部から行くとやっぱりある程度の期間での契約とかになるんで、
それは更新されたりはするんですけど、
そうなるとやっぱり自分はずっとここにいるわけじゃないっていう意識で動くと、
できるだけツールとかそういうメトリクスとか何かしらに落とし込んで、
去りたいじゃないけど、自分がいなくなった後も、
それがうまくワークするようにしたいなっていう思いはありますね。
わかる。そして自分がそれが失敗したやつだ。
いや、そんな簡単にいかないですけどね。
いい感じのアキテクチャ組んどいたらね、
いけるんちゃうかと思ったんですけどね。
いや、わかります。
簡単にダメだなって思いますよね。
もちろんね、CIだ、なんだ、これで自動化してメトリクスも自動で出ますよって、
この辺の数字見てくださいって言ったって全部切られたらもうアウトなんで、
CIうるさいから全部切ろうとかなったらもう終わりだから、
それやったところでっていう部分はあるんですけど、
でも機械…
テストがグッドプラクティスである理由について
わかるわかる。
TDDとかまさにそれで、テストファーストでせっかくやってても、
あ、そうか、うん、テスト書かないとダメなんだねって言って、
後からテスト書いたりするようになっちゃうんですよね。
なんかそのテストと実装を並行で頑張ってやろうってやってても、
その温度取れる人っていうかその意識がある人たちが全員抜けると、
儀式として、
自作自演みたいだね。
実装を先やっちゃって、
答えのわかってるテストを書いて、
意味があるのかみたいなテストコードが生まれて、
そのうちだんだん切られていくっていう。
だから本当はそういう儀式にも理由があり、
理由っていうか、一番はその人自身の内なる欲望っていうか、
欲求としてそういう行為ができるようになると、
たぶんスムーズに動くんだと思うんですよね。
やらなきゃいけないからやるっていうよりは、
テストを先に書くか後に書くかっていう問題もあるんですけども、
テストを書くっていうことで何かしら自分が救われた思いをしたりとか、
あーテストあってよかったみたいな経験があれば、
たぶん自然と書くと思うんですよね。
そうじゃなくて、ただ書けとか言われてやると、
そうなりがちっていうのはあるかもしれないですね。
めちゃくちゃ古いやつがあるんだよね、うち。
びっくりするぐらい古いのがあって、
テストなんて、
単体テストという概念すらPHP界になかったような時代からあるものがあって、
で、
単体テストできるようにしておいたからやっていいよって言ったら、
使うよ、使ってもらいました。
わかります?やれじゃなくて、
そこのロジック複雑だから部分的に単体テストしてやっていいよと、
DDDで進めていいよっていう風にすると、
テストが書かれると。
しかも割と緻密なテストがそこだけですけどね。
それが習慣づくと、
ややこしいロジックがあったら、
DDDやっていいっていうのが、
ややこしいロジックが出てくる状況で落ちた時に、
半分以上の確率でそれが進むと、
おんのじかなと。
儀式としてのプログラミング
っていう方が割と、
儀式的にやれと言われて書かされるテストよりも
いいテストになるなっていう感覚が、
実体験であります。
たぶんチームの方がテストの旨味を理解してるから、
自然とそうなるんですよね。
その旨味をどうやって理解してもらうかっていうのが、
結局さっきのアーキテクチャー云々の話も、
結局全部それにつながると思うんですよね。
こうしたら自分たちが楽できるとか、
上手いこと作れるとか、
後々困らへんよねとか、
ポカミスすぐ見つけてくれるよねとかっていう、
やっぱりメリットを肌で感じたら、
自然と動機が出てきて、
自然とそういう行為をやると思うんですよね。
そこでいけば、後は方法だけうまく伝えればいいんですけど。
うるさいおっさんが正しさをけんけんガクガク言うっていうのも、
長いこと秩序の保たれたプロダクトを続けるっていう、
人間的な目的があるんだけど、
そこと具体的なテストを書いて、
CIを回してとかの間がつながらない感じですよね。
そこの間を必然的にそうだよねと、
どうやってつなぐのかっていう。
そこはおじさんたちが背中を見せて、
毎日政権好きしてる姿を見せてあげるしかない。
やっぱおじさんがあれなんですよね、
やった単体テストだけで画面出さんでチェック済んだとかを喜んでる姿がいるのかなって。
あとはでも、特にリモートになって感じるのは、
作業してる風景を隣で見せてあげられないのはちょっと厳しいなっていうのはありますよね。
今だとPHPストームがあって、
UTなんかだとボタン一つで対象のテストだけを実行するみたいなこともできるし、
それをXデバッグで止めてステップ実行とかっていうのを、
僕はもう普通にやるけど、
それを隣で見てたら、めっちゃいいじゃないですかってなると思うけど、
そうじゃないとそれに気づかない可能性はあって。
そういうのライブ配信とかするじゃないか。
ペアプロできないですよね。
そうそうそうなんですよね。
パッと顔を見合わせてペアプロっていうのがサッとできないみたいな。
その辛さはちょっとあるな。
コードビズミーとかも面白いしいいんですけど。
オンラインになる時間を予定決めて、
いやさあやるぞで何時から何時までってやらないとできないっていうあの感じね。
会社にずっといたらちょっと暇そうやなって言って声かけるっていうあれ。
あの感じはないですよね。
最近難しいな思っています。
そうですよね。
なんかこう微妙思い立ての子がカーソルのキーをガーって連打してるのを見て、
君やめなさいみたいなことを言えないじゃないですか。
わかるわかる。
HPストームのショートカットを口で言いながら人に説明してたのがよくあります。
そこでコントロールスペースって言いながら。
3文字打ったらタブとか。
そうなんですよね。
でもそういうのかっこいいって思うような書作を近くで見せてあげられないっていうところに
知識伝承の難しさがちょっと今はあるなっていうところがありますね。
でもあのボブの新刊が出たんですけどご存知ですか?
クリーンクラフトマンシップっていう。
まだ読んでないです。
あれです。クリーンアジャイルを独立してなかったので、
読んでから読もうと思ってるところです。
ネタバラシっていうか、そんなネタバラシじゃないんですけど、
半分もうユニットテストなんですよ。TDDなんですよ。
半分TDDで残り半分に倫理が書かれていて、悪いことしないようにっていうふうに書いてあって、
ソフトウェアエンジニアは悪いことしちゃダメなんだよ、君たちはすごい損害を与えるから。
せめてTDDは覚えてくれみたいな内容になってて、
いい話だなと思いながら。
彼はきっと多分最小限に収めたソフトウェアエンジニアとしてのやり方を、
多分TDDと倫理に詰めたんだろうなと思って、すごい面白いなと思いました。
言い出したらキリがないから、最低限みんな知ってるやろっていう話がTDDでみたいな。
あとは悪いことすんなよみたいなところに収めてるところ。
でも倫理書いてある技術書、珍しいなと思って。
倫理は大事ですね。
昨年おととし、ペチパー会議の冊子がやたら分厚くなった時があったじゃないですか。
アンチパターンとケント・ベック
アンチパターンを漫画にした年です。
探してきますって離れていいの?
いいや、ラジオだから声さえ通ってればいい。
ペチパー会議の冊子にも載ってるんだけど、
アンチパターンを漫画にしたって、
アドベントカレンダーで一人で漫画にした時があったんですよね。
で、アンチパターンってデザインパターン…
あ、やったーってそれ映ってるんですか?
放送には映ってないです。
うちらだけで顔が見えてるっていうやつです。
はい、そうです。
どこまで言ったっけ?
アンチパターンってデザインパターンの逆版っていう名前からの印象で思う人が多いんだけど、
実はあれ倫理の本だっていうのを自分は思ってて。
なるほど。
あそこに書いてあるのの動機が全部、
要はビジネスエンジニアのズルをするなみたいなところが原因なんですよね。
アンチパターンの原因を掘り探っていくと。
その本が出たのが1998年ぐらいだったはずで。
その頃、要はコンピューターの仕事がビジネスライクビジネスライクになって、
やたら書類を欠かされたりとか、ネクタイ族が幅を利かせてみたいな90年代に嫌気がさせた人が声を集めたのがアンチパターン。
その後ぐらいから同時にケント・ベックがXPを主張しだして、
2000年超えるとアジャイルだって言い出して。
反倫理とアジャイル
っていう歴史の発端がアンチパターンっていう本に現れてるなっていうふうに僕は思ってる。倫理。
そのときのダメな漢字が反倫理だっていうのを知るとすごくいいなって思ってて。
アジャイル宣言も実はああしましょう、これでうまくいきますじゃなくて、
こうじゃないことをやめましょうって読むとすごい納得できるんですよ。
逆にアジャイルのマニフェストを読むと、動かない行動を前にけんけんがくがく書類とか会議とかでやるのやめろというふうに読めるんですよね。
ウィンウィンのメリットとか考えずに契約でこうだからここまでしかしませんとか、そういうことも、そういう態度取るなとか。
要件定義で決まった通りに作りましたで、作りましたでいいっていう態度をやめろっていうのが変化を受け入れろっていうやつにも出てたり。
なんかそういうふうな反倫理を理解、反倫理の視点で読むとすごいわかる。
それがね、倫理大事ですよねって語りたかった。
なるほど。
反倫理っていうのをポジティブに言い直したものがアジャイルソフトウェア宣言っていうふうに捉えられるかもしれないですね。
そんなふうにも感じるな。
よくよく考えたらね、趣味で友達で集まって、少年がガレージでプログラムを組むときにあんなんなくて、当たり前にやることばっかり書いてあるというか。
その当たり前をチーム内でいかに高い意識を。高い意識っていうとまたなんかちょっと語弊があるからよくないな。
そうですよね。ゼロなんですよね。高くなくて。
正しい仕事のあり方
自然な、ナチュラルなゼロなラインをキープする。
お仕事の大人の事情が入ってマイナスになっていくから、某ような人が意識低いって。
ゼロの人を意識高いって思っちゃってるみたいな。そんなふうな気がしますね。
良いとされるようなプラクティスとはの旨味をみんな知って、それが普通にできるようになるのはすごくいいことだとは思うんですけど、
そうじゃないとプログラム書いちゃいけないっていうふうになるのもちょっとしんどいかなと正直思っていて。
どちらかというと、そうじゃない人が仕事できないわけじゃなくて、その人もちゃんとソフトエンジニアとして普段仕事して、
ずっとシステムを作ったりしてる人がたくさんいるわけなんですね。
だから正しい道はこれしかないっていうものではなく、その人にはその人のやり方があり、考え方がありっていうのが、
チームとしてやるときはその辺の落としどころをうまく作りたいなとは思ってます。
もちろん僕は僕なりの正しさっていうのを考えてありますけど、
でもそれが唯一の方法じゃないし、それを採用したから全てがうまくいくなんてことはやっぱりなくて。
だから、なんていうんですかね、なんかその辺こううまくできないかなと思っていて、
そういう意味でも最初に話してたCIで自動化とか、自動化するっていうところで一旦線は引いといて、
それ以上のことはもう個人でのやり方でやりましょうっていうのでもいいのかなとは最近思ったりはしてます。
もちろんコンテキストがあるんで、じゃあみんな好き勝手書いていいんかって言ったらまたちょっと違う話にはなるんですけど。
ただ、なんていうんですかね、全部のプラクティス、この本も読んで、あの本も読んで、
その人が言った講演も全部聞いて、しかもその理解も正しく理解してみたいな。
それからじゃないとソフトウェアかけないじゃん。仕事進まないんで。
いやーもう本それですね。
あのね、そんなん言うてね、人材がいないとか言うなよ話ですね。
そうそうそうそう。
無茶を言うなっていう。
やっぱり抑えときたいというか、僕が大事にしたいなって思うのは、正しいことをすることが仕事じゃないと思うんですね。
そういうのをトレーニングしたりとか伝えたりする仕事の人はその正しさを伝えるのが大事だと思うんですけど、
実際現場で書くときは、それが正しい、それがちゃんとした仕事ってわけじゃなくて、
ソフトウェアをちゃんと作ることがやっぱり大事なわけで。
自由度と失敗
だからそこはあんまり偏った見方をしないほうがいいのかなとは個人的には思っています。
ちょっとそれは自分自身痛い目っていうか、なんかうまくいかないなとかっていう経験があったからっていうのも含めてですけどね。
現場ルールとかでガチガチになってるようなところに行ったこともあって、
自宅とかやってるときに、それってもうプログラマー側に自由度なさすぎちゃって、何もできないんですよね。
僕は今アーキテクチャを考える側の人間として思うのは、みんなにはある程度やっぱ自由に開発はしてほしいんですよね。
いろんな失敗をしてほしいんですよ。やれるような小爆発は推奨するんで。
そこら辺の落としどころを見つけながらルール作りみたいな。
どこまではCIでチェックできてみたいなことを考えるのがシニアの役なんだろうなとか。
カバーできる失敗は全然やってもらっていいですもんね。
むしろやらないとノーンの記憶に残らないみたいなところはあるんで。
僕1回ドロップデータベースでものすごいのやってるんで、もうD打った瞬間にノーンが全ての記憶をガッて注意しろと。
お前今何感じたの?みたいな。
それはでも失敗のおかげですよね。
僕もデリートにウェア付け忘れましたね。
そうするとデリート打つときにウェアを付け忘れてないかっていうのがノーレベルで完全に入れ積みされてるんで。
初期でよかった。
そうそうそう、そういうやつ。
なんかこれ消すと全部消えちゃうんですよねって言われてヒヤってしましたね。
そうですよね。
若い子にそういう失敗がしてもらえる程度には自由度がやっぱりないといけないなと思いつつ。
で、先ほど島原が言ってたみたいに自動化できるところは自動化して。
じゃあそのルール何なの?って言われると頭がおかしくなっちゃいそうなんですけど。
ソフトウェアの価値提供について
足切りみたいな最低基準でああしなさい、これができてないといけないっていう必要条件で考えるとしんどいんだけど、
失敗をしながらテストって便利じゃんとか自動化されててよかったなとかをいいことを取り込んで育ってもらえたらそれでいいかもしれないですね。
最初は、絶対これだけはないといけないなって思うところとしては、
うまくプログラムが動いて嬉しい。
で、その動いたプログラムが他人が使ってくれることで役に立つものだと思える。
ここだけは絶対外せないんだけど、これさえ満たしてれば、
正しいとされるいろいろな教えは、もう使えるものだけ吸収していってもらったらいいよっていうふうには、
なんかね、それぐらいでいいじゃんって感じですよね。
なるほどね。
こうじゃないといかんじゃなくて、誰でもいける、やっていい。
とにかく自分でプログラムを書き切って人に使ってもらったら嬉しいっていう人なら業界に入ってきて、
お仕事をしていける。
で、会ってほしい。
のはそうなんですよね。
僕はやっぱウェブ系のエンジニアとして、やっぱり誰か他の人が使ってくれていて、
あれいいですねって言われるとも、やっぱ天にも昇るような気持ちにはなるんですよね。
その現体験が割と初期の頃にあったんで、
それはやっぱすごい大事ですよね。
部分だけ担当とかってなっちゃうと結構厳しいから、やっぱりそういうのはやり切らせてあげたいみたいなところはちょっとありますね。
そういう視点もちょっと大事かもしれないですね。
アーキテクチャーのこととか、ソフトウェアの構造とか、書き方みたいなことにどんどんフォーカスしていって、
それでいろんな知見を貯めていって、より良くしていくっていうのはもちろんすごくいいことだし大事なことなんですけど、
あまりにもそこに注力しすぎると、引いて考えると、
いや、それって全体から見るとすごいちょっとのことじゃないっていうような場合もあるんですね。
だからいろんな視点でその辺が見れるっていうのはいいかもしれないですね。
実際そのシステムが使ってる人にデリバリーされて、何かしらのアクションを起こして使ってもらって、
初めて価値があるんだよっていうのをたまに引いてみると、
ソフトウェア活用の課題
あれ、それって大事なことなんだっけっていうのはたまに感じたりするときはあるので。
ただもちろん引いてみたから絶対からすると一部分だし、
じゃあどうでもいいかってなるとそれはちょっと極端すぎるんですけど。
その行ったり来たりっていうか、視点を変えながらちょっと考えてみるっていうのが一つかもしれないですね。
じゃあ結局。
そうっすよね。
パチッとこれさえ覚えておけばいけるよっていうことは本当になくって、
あっちこっちは行ったり来たりしながら、こっちから見たらどうかな、あっちから見たらどうなのかどうかなってしながら、
汗かかないとダメなんだなっていう、大変だなっていう感じ。
僕たちの仕事は割と大変だなって思いました。
これさえやればって、そんなん決まってたら仕事ないじゃないですか、そもそもっていう話で。
本当、本当ですね。
それがないから新しく開発するみたいな。
そうそう。
ないもの作ってるんだから、知ってる情報だけでできるわけがないっていう。
本当ですね。
すごい思うのは、僕らはソフトウェアを作って、いろんなサービス作ったり、価値を提供したりとかしてるわけじゃないですか。
でも自分たちの仕事はあんまりソフトウェア活用できてなくて、さっきからちょっと出てますけど、
人に依存する分がめっちゃ大きいんですよね、まだまだ。
人の理解とか考えとかにすごくもたれかかってやってるっていうのは、
それはそういう仕事だからっていうのはあるかもしれないんですけど、
もうちょっとソフトウェアでなんとかできるのかなっていうのはずっと思ってます。
確かに。
なるほど。
他人様の仕事。
もちろん便利なツーはたくさんあるんですけど、でもまだまだじゃないですか、それは。
まだまだ人がどうにかしなきゃいけない領域が多くて、
人様の仕事はね、それこそAI使って自動化してとか、
今はそのジャッジメントも自動化しようとかっていう話になってるのに、
ソフトウェアをコツコツと人間が考えて作るっていうのが、
ソフトウェアアーキテクチャとヒューマンスキル
なんかどうにかならんのかねっていうのはちょっと思ってます。
何だろうな、
より長く走るための機械とか、
より速く走るための機械とか、
そういうパワーで押してくれるものはいっぱいできてるんだけど、
手動で、じゃなくて自動でテストが回せるとか、
IDEが補完してくれるとかは、
言うたら頑張ってマニュアルを開いて調べればAPIは出てくるし、
時間さえかければ自動じゃなくて手動でもテストができるし、
なんだけど、それを超時短できるようになって、
パワーは押してくれてるんですよね。
プログラム言語がアーキテクチャを作るのに向いていってるのも、
パワーはもらえてるんだけど、
根本的に人間がやらないといけない仕事は、
ずっと人間がやってるって感じですよね。
そうそうですね。
それをね、やったね。
そうなんですよね。
結局人間か、そうだな、そうですね。
そうなんですよね。
結局そうなんですよね。
だから、ソフトウェアアーキテクチャの基礎とか、
最近アーキテクチャの本いくつか出てたと思うんですけど、
あれも結局ヒューマンスキルの話とかがやっぱり入るんですよね。
はい。
当たり前なんですけど。
だからソフトウェアの世界だけで完結しないんですよね。
だからどっちかというとそっちの方が重要っていうか、
そっちも重要なので。
いやもう両方重要ですね。
そう両方重要なんですよね。
ソフトウェアの秩序とは
言ったら、人間がいるからアーキテクチャがあるみたいなところがあって、
AIが全部やるようになっちゃったら、
アーキテクチャいらなくなるし、ネーミングもいらなくなるんですよね。
そうですね、ほんとそうです。
間違わないし。
そういうことか。
そうかそうかそうかそうか。
ほんとそういうことですね。
あーそうか、指き足す言語なんていうやつがまさにそのあれですよね。
そうですね。
結局人が改ざんして、人が理解して、人が書くから、そういうのが必要なんですよね。
そうだ。
まあそうだ、そうですね、ほんとだ、その通りですね。
そうですね。
そうか、作るところに人間がいなくなって、
使う人だけが何だかわからないけど役に立つって言ってるんやったら、
もうそんなのいらないですね。
ソフトウェア工学みたいな分野が。
そうですね、そうですね。
なんかでもすごい納得しました。
ADRの威力
最近、でもほんと会社でもめちゃくちゃ助かった例は、
ADRって割と流行ってるんですけど、アーキテクチャデシロンレコードっていう。
それこそ今さっきしんばらさん言われたソフトウェアアーキテクチャの基礎とかにも乗って、
で、うちの会社でもちょっとやってみてるんですけど、
やっぱりこの人間間での情報共有とか説得とか、
そういった面でやっぱりすごく威力があって、
やっぱソフトウェア開発はコミュニケーションだなってすごい思い知らされたというか。
確かに。
そうなんですよね。
なんかこないだADRって思い出したんですけど、
それは一人でやってるプロジェクトなんですけど、
なんか1日中ADR書いてましたね。
なんかあるADRを書き、それでデシジョンして、
じゃあもう少し実装レベルに落とそうと思ったら、
また判断しなきゃいけない材料が出てきて、またADR書いて。
っていうのを延々繰り返して、俺今日1日中ADR書いてたなっていう。
でもそれぐらい決断することがあるってことですね。
それぐらい実際のソフトウェアになってしまうと非言語化されてしまう情報があるっていう。
そうですね。
僕は割と自分で考えるフォーマットとしても使ってるんで、ADRは。
あとやっぱりどうやって決めたかっていうのは、
昨日の自分も他人だから、なんでそれを選んだかっていうのはやっぱり残しときたいんですよね。
それはなんかコミットメッセージとかコメントだけじゃやっぱりちょっと不足で。
確かに。
だからADRに書いとくと後々楽ですね。
見た時になんでそれを選んだんだっけっていうのは。
開発者の責任と反省
それは分かります。
誰だこれ書いたのって。
今日テストがかぶって落ちてたんですけど、
なんだこのかぶったテスト書いたやつだって。
Gitブレイムしたら富戸頃って出てきたんで。
俺じゃんって。
ありますあります。
何考えてこれ書いてんだよ畜生。
なんじゃこの仕様、俺じゃんっていうのありましたね最近僕も。
ありますよね。
ありますよね。
誰だよこのクラス名考えたやつ。
俺ですみたいな。
あります。
分かりにくいみたいな。
日々そんな感じですよね。
はい。
もう竹の跡がございます。
これ仕様あってんのって自分が突っ込んどいて、
よくよく考えた数年前に書いた自分のコードで。
全部自分に書いてきます。
ではそろそろ放送終了の準備に行きます。
今週も放送をお聞きいただきありがとうございます。
番組のフィードバックや要望は、
ハッシュタグ横浜農水Mをつけてツイートしてください。
ライブをお聞きの方は、高評価ボタンをクリックしてください。
次回もお聞きしたい方は、ぜひチャンネル登録をお願いします。
本日の相手は、しんばらさんとヒサテルさんでした。
ありがとうございました。
ありがとうございました。
ありがとうございました
