00:06
こんばんは、Yokohama North AM第86回です。
Yokohama North AMは、ウェブ系エンジニアがテック系のキーワードをネタにして、雑談をするポッドキャストです。
ホスト役の紹介
ホスト役は、自称PHパーのハンハン1978です。
本日の相手は、金城さんです。よろしくお願いします。
金城です。よろしくお願いします。
この1ヶ月大変でして、とあるハヤリ病にかかってしまいまして、
ようやく復活してきたので、金城さんを相手にダラダラとウェブ系の話ができたらなと思います。
まずは金城さんのご紹介からですが、
毎回このツイッターのハッシュタグの読み方が、
o0h__でお馴染みの、
o0h__です。
のシャケイクラドンのアイコンでお馴染みの金城さんで、
ご自身から何か自己紹介というか、お願いしてもよろしいでしょうか。
そうですね、小田原にある会社で勤めていて、
マネジメントをやっていたりしています。
ずっとPHPをやっている人間ですね。
そんなところでございます。
何となく、マネジメントロールをしているというときの、
声質というか声色を聞く限りは、
何か近しいことをやられているなという気が、ブンブンとする。
なるほど。
なんとなく。
技術不細の話
今日はテーマとしては色々雑談をしながら、
技術不細ってあるよねみたいな、
なかなか減らないよねみたいな口を、
長々と垂れ流していこうという。
なるほど、愚痴って言っちゃうんですね。
愚痴というか、難しいなと思って。
一口に不細と言ってもみたいなところがあります。
金城さん体調は大丈夫ですか?
体調ですか、体調は僕はここ数年崩してない。
すごいですね。
体力だけが売りなので。
素晴らしいことですね。
僕も体力が売りだったんですけど。
確かに。
例の早入り病のワクチンは一応全部打ってるんですよね。
なるほど。
打ってたんですが、妻も打ってて、
妻が外からもらってきたんですよ。
隔離生活とかしてたんですけど、
5日間で決壊しまして、
前も話したかもしれないんですけど、
WebDBプレスのお別れパーティーみたいなやつ。
ちょうどその日の夕方に、
喉が怪しいなって。
行きたかったんですけど、
涙の諦めを。
タイミングが。
タイミングがちょっと。
でも会場でパンデミックを起こすわけにはいかないなと。
そうですね、だいぶ東京界隈のウェブ系エンジニアが。
各種CTOがやられちゃう感じがするんで、
あそこでパンデミックなの。
翌日、ちゃんと抗原検査したら陽性が出たんで、
俺の判断は間違ってなかったんです。
いいぞって。
危なかったですね。
いいことしたっつって。
季節の変わり目だからとかっていうノリで行っちゃったら、
大事故でしたね、じゃあ。
そうですね。
治った後にまた季節の変わり目で、
しばらく体調が悪くなり、
めちゃくちゃになりました。
でも笑い事じゃないですからね。
インフルエンザも流行ってきてますし。
そうなんですよね。
そうですよね、まだマネージメントで考えると、
これからインフルエンザとかで、
お子さんとかいらっしゃる方は特に。
学級閉鎖とかもあるし、
メンバーが離脱するってことを考えて、
ある程度計画していかないと。
それはどうしようもないので、
バッファーを積んどくとか、
ベロシティーを0.8掛けで考えておくとかしか、
ないんじゃないですかね。
本当ですよね、厳しいな。
かくゆう私も9月の末にリリースが、
無事終わったんですけど、
鼻歌歌ってたら、
まさかこんなことになるとは。
鼻歌歌ってたら。
鼻歌歌ってたら結構苦しくなりました。
皆さんも、
プロジェクトの計画にはお気を付けください。
ギリギリでやってると、
思わぬプラスアルファが出るかもしれない。
そうですね。
これ忘れないうちに話しておかなきゃと思ったんですけど、
おだわらといえば。
BHP緩和です、おだわら。
そうですね。
どこまで話されてるんだ。
ただ僕、勘でないんですよ。
勘でないんですか。
勘でないです。
本当だ、スタッフには勘でないんだ。
一切勘でない。
ミーティングとかにも出てないですし。
大変ですよね、勘じゃったら。
大変でしょうね。
ちょっとソウルジェムがだいぶ濁るぐらいには大変。
そうなんですよね。
イベントスタッフとか、コアスタッフとかに興味がないわけではないんですけど、
ただスタッフ場やったこともないし、おだわらもよくわからないし。
確かにそうか、おだわらにいるわけじゃないんだ。
僕に何ができるのかっていうところもあり。
でもそうですね、結構社内の、
ホッキニというかイイダシペの社内の人ですし、
だいぶ頑張ってる様子は感じてますね。
そうですね、かまぼこ柄のかわいいロゴが。
ロゴかわいいですよね。
すごいセンスいいなと思って、まさにおだわらって感じですね。
おだわらはかまぼこが美味しいらしいぐらいしか僕はおだわらを知らないので。
うちがちょうど東名高速近いんで、たまにおだわら行くんですけど、
おだわら方面行くとどんどんかまぼこの看板がドカーンドカーンと打っとるなみたいな。
新幹線で会社に行くんですけど、駅のホームから降りる階段のところに、
階段の上というかあそこに広告スペースあるじゃないですか。
あそこに天然プロテインみたいなかまぼこみたいなのが出てて、
なるほどっていう気持ちで毎回なってますね。
低糖質食品としてのすり身みたいなのもありますよね。
そうですね。栄養価が高いので。
なるほど。これが2024年の春。
とにかく来年はPHP、もうPHP爆発試算してなくなるんじゃないかっていうぐらいカンファレンスがいっぱいありますね。
確かに。あれですね、漫画とかだったら本当に最後の今までの見方が全部集まってきてみたいな。
地球爆発するやつですね。
本当にこれで終わってしまうのでは?って言ってビクビクしてるんです。
なるほど。
小田原は春ですね。
小田原は春ですね。
桜の季節と言いつつ4月の13だからもう散っちゃってる。
ちょっと散っちゃってそうな感じはしますね。
気候的にはきっと穏やかで良いと思いますので、ぜひ皆様きっとCFPがそのうち出るのでしょうという気がします。
そうですね。たくさん出していただいて。
というPHPカンファレンス、小田原に実は絡んでなかったけど若干関係がありそうな近所さんの宣伝をしつつ、
じゃあ技術不細。
技術不細。
なんでなかなか減らんのかなというのが今日のテーマですね。
技術不細というと富戸頃さんが福岡のペチコンで話を出してますもんね。
あれって、こうやれば減るぜみたいな話ではないか?
直接的に減るっていう話よりかは、その技術的不細がたまるような形でビジネスが構築されてるんだと、
全体の仕組みをいじっていかないと減らないよねみたいな。
そこの認識を改めていかないと減らないんだよね。
要は技術だけ頑張ったところで減らせるものではないからみたいなところがメインテーマといえばメインテーマかなと思います。
確かに。
あと、これが一番言いたかったのはラストで置き換えるとかすぐ言うなよみたいなジョークでも言わないでくれと。
そうですね。ラスト、マイクロサービス、あと何があるんですかね今。
何ですかね。でも流行りはやっぱりモジュラーモノリスじゃないですか。銀の弾丸っぽくなってますよね。
マイクロサービスが一段落して、モジュラーモノリスばやりって感じで。
テストとネジ締めの比喩
そうですね。ノーエスチュエルが落ち着いて、マイクロサービスが落ち着いてみたいな。
はい。なのでモジュラーモノリスもそのうち死ぬんだろうって。
そうですね。でもそれこそモジュラーモノリスとかチームないし、境界づけられたコンテキストみたいな本当に直結で組織構造をどうするんだっけ、コミュニケーションパスをどうするんだっけみたいな話になってくる。
あ、そっか。つまり人間がソフトウェア作ってる限りはもう無理なのではっていう気持ちになりますね。
なるほど。つまり俺たちのせいでフサイが生まれるということですね。
俺たちはトレードオフという名のもとに毎日フサイをせっせと貯めていくので、その中で貯めていい。だからフサイってやっぱり借り入れ的な話になる。
ですね。
借りがちで。だからフサイっていうのはやっぱりあんまり良いメタファーじゃないのかもしれないなと思ってはいます。
ローンが通れば家が作れるぞみたいな感じですもんね、フサイだと。
そうするとじゃあローンした方が良くないみたいな。経営者なんか絶対ローンした方がいいっていう方向性に考えちゃいそうなんで。
フサイってそういうイメージがあるな。だからそれよりも最近ちょっと老朽化した水道管とか、壊れて落ちそうな橋とか、次の地震でこの高速道路は倒れますみたいな、なんかそっちの方が例えとしては正しいのかもしれないなという気はしてますね。
老朽化みたいな感じなんですかね、イメージとして。
そうイメージとしてはそっちの方がいいんじゃないかなと思って、技術的フサイっていうと借り入れて先に進もうようにしかならない気がしていて、国も借金がどんどん増えてますので。
でもそうですよね、本来的にはそういうポジティブなニュアンスも込めて技術的フサイって呼んでたんでしたっけ、ちょっと出どころの。
出どころはね、僕も何度も何度も見たんですよね。
技術的フサイ、すごく偉い教授の方が言われていたような気がする。
誰だっけ、言った人。誰が言ったのかっていうのがメモリーさんの本に書いてあった気がするけど、さっと本が出てこないのでわからない。
ウォードカニンガム氏ですか。
そうですね、ウォードカニンガムさんだった。
技術的な複雑さとフサイの比較を始めとなったと。
最初のコードを出荷することは借金をするようなものだ。
少々の借金は書き換えによって速やかに返済される限り開発を加速させる。
危険なのはそのフサイが返済されないときだ。
正しいとは言えないコードのために費やされた1分1秒はそのフサイの利削としてカウントされるのである。
オブジェクト志向であろうとなかろうと統合されていない実装のフサイの負荷によってエンジニアリング組織全体が停止してしまう可能性があるのだ。
1992年、ウォードカニンガムということですね。
そうですね、そうですよね。
どんなコードを書いたとて、多分書き換えは発生するので、書き換えなきゃいけないコードを作ってるという意味では我々はもう技術的フサイしか作れない感じがしますよね。
基本的には技術的フサイだなとは思うんですよね。
安定したドメインになるまでって時の試練が必要だなとは思っていて、
そうするとある程度なんとなくいい感じ。
このニュアンスがもうめちゃくちゃ難しいなと思ってて。
うちで働いてくれている業務委託の人なんですけど、ちょうど福岡でテストの話をしていて、
最初は彼はすごいユニットテストを何でも書くぞみたいな、全部テストを書くんだみたいな感じだったんですけど、
最近社内発表してくれたやつで、いいじゃんコントローラーだけでみたいな、雑に作ってとりあえず入り口だけ書いとこうぜみたいな。
安定するにしたがってリファクタリングしてきれいにしていけばいいじゃんっていうふうになってて、素晴らしい成長を見せていると。
組み立て中の家具とかを考えると最初からネジギチギチに締めないだろみたいな。
そうそうそう。
だいたい緩く締めて位置とか調整して、よしこれでってなったらギュって締めるよねみたいな感じがありますもんね、テストも。
単体テストもガチガチにやるとなかなか。
スクラムやリーンのプロセスと改善の過程
緩やかな改善のプロセスっていうのが、スクラムとかリーンとかでもそうだと思うんですけど、
最初はちょっと形になってないような、でもとりあえず動くよみたいな状態から。
それがいわゆる検証可能なインクリメントみたいなことを多分言われると思うんですけど、スクラムなんか。
っていうのと、綺麗に作りたいみたいな、自動車工場みたいなメタファーから来る設計して製造してテストして直してっていうところと、
シフトレフト勢の、もう全部一生懸命やろうぜみたいな、ダサくてもいいからとりあえずごくんにしようぜみたいなのがぐちゃぐちゃっとしてるなって気がする。
あとあれですね、我々はアットトゥードゥ後で直すみたいなのが回収されないのは、もう身体に染み付いて知っていることなので、
今しっかりしとかないと、後のエンジン、未来の若者に呪われるだけだみたいな、重負感みたいなのもありますね。
ここにNプラス1を残しておきましたみたいな。
残しておきましたって言われるといいですね、宝の地図感があって。
データ量的にはそんなに成長しない部分なんで、動くは多分大丈夫みたいな、余裕があったら直してねみたいな、これはでも余裕がないなみたいな。
でもそれこそあれですもんね、スケールしてきたときにどうなるんだっけっていうのを見越してコードを書いてきっとオーバーエンジニアリングっぽくなってっていうのもよくある技術差ですもんね。
そうですね。だからそこってやっぱり経験値も必要になっちゃうよなみたいな。
そうですね。
なぜかともアプリが流行るかどうかみたいな、元も子もないみたいな。
そうですね、そうですね。
そうするとやっぱり不採用借り入れをして、とりあえず1ヶ月以内に出して、ちゃんと触ってみてもらわないとみたいな。
そうですよね。笑い話なんですけど、すごいだいぶ前の話なんですけど。
とある一覧ページがあって、できてリリースして、2ヶ月ぐらい経ったときからえらい遅くなってきて。
何言うと、全てのページで全権取得していたみたいな。
なるほど。
そういう笑い話がありましたけど。
まあでも、リリース前にロードテストできるかみたいな余裕の話と。
いや、難しいですよね。
そもそも機能がある程度受けたから2ヶ月でそこまでデータ量が育ったってなると、受けなかったらそれでも良かったって話になると思うんですよね。
そうなんですよね。
全てがそこに集約するんで、結果論じゃんって言われたら、結果論だなと思って。だからコードレビューでも指摘しづらいなと思って。
今ならこれでも動くからいいかなみたいな。
モニタリングと監視の重要性
そうですね。それで言うと、モニタリングちゃんとやっておいてみたいな。危険水域に達したらちゃんとブーンって警報が鳴るようにしとかないと安心して暮らせないよね、この街はってなっちゃうんで。
そうですよね。そうすると監視の話とか、監視でカバーできてればいいかみたいな。
そうですね。
監視の話が出てくる。それも全てされてない場合は、そりゃヤベェぜみたいな話になるかもしれない。
そうですね。
という感じで、技術的負債の話はトレードオフっていう視点に立つと、一向に返さない感じになっちゃいますよね。
そうですね。取り立てが来ないなら借金返さないですもんね。
そうなんですよね。でも実際は取り立て来てるんだよなみたいな。
でもさっきのアラートと同じで、取り立て屋も自分らで設計しないといけないので。
でもそうですね。それすごくいい言葉かもしれない。取り立て屋を自分たちで設計しない。
今まさにネタ帳にも書いたんですけど、フォーキーズの話をネタ帳に書いたと思うんですけど。
リーンとDevOpsの話にも書かれてたんですけど、
安定した計測仕様としていろんな会社で採用できるっていう意味で、かなり結果に近い指標を取られてる。
だけど現場で実際に生の改善していこうと思ったら、フォーキーズだとやっぱりちょっと改善量が低いなって思ってて。
それが今金城さんが言われてた、気づくところも自分たちでみたいなところに繋がりそうな気がする。
あれですよね。フォーキーズ、あの本の元になってる研究はあくまでいろんな会社を仕掛けできるように。
割と仕方なくこの指標を選んでますみたいなニュアンスも本文読むとちゃんと触れられてますもんね。
DevOpsの定量化できるところしか我々は測ってませんみたいなニュアンスだと思うので。
そうですよね。
お前DevOpsで100点取ればビジネス成功するって誰が言ってるんやみたいな話がそもそもあると思うので。
そうなんですよ。
そうすると結局フォーキーズでは全然足りなくて、自分の会社それぞれの事業サービスでテーラーメイドされた指標みたいなものを取って、
その中で今マジでこれ直さないとみたいな。
明日は橋が落ちてビジネスが完全に停止しますみたいな。
そういうものにちゃんと優先順位をつけられるかっていうところがアーキテクトが解像度を高めさせなきゃいけないみたいなところなんだなって思うが、
その指標って何ですかみたいなところに戻ってくるんです。
なんか今話しながら富所さんの表情がだんだんなくもっていってたんで。
ただちょっとずつにじり寄るようにいろんな本とかを買っていろんなことを調べて。
リーンとデブオフソンの科学の著者の方がこの間開発生産性カンファレンスかなんかで登壇されていて、
その時にスペースとかドーラの話が出たんですよね。
あれ聞いててスペースってやっぱり前僕が調べたGQMっていうボールクワンティティなんだっけ。
メジャー面とか。
メジャー面とか、はい。
に割と近いなと思ってて。
メトリクスの選び方と型の重要性
それをまた横から見るか縦から見るかみたいな、そんな話かな。
そのスペースの考え方に沿って縦軸にS、P、何のレカだったか忘れました。
S、P、A、C、Eか。
に沿っていろんな仕様、測れそうな仕様をポンポコンと置いたんですよ。
とにかく会社で。
これは測れるのみたいな。
デプロイ速度とか例外の数とか。
対応したチケットの数とかコミット数とか。
関わっている数とかメンバー数とか。
頑張れば計測できそうだなみたいなやつをとにかく置いていって。
発表の中で言われたスペースの中の3つの項目。
要はSばっかりじゃなくて、SとPとAみたいな。
少なくとも3つにまたがるような感じで一緒を選ぶとバランスが良くなるって言ってて。
バランスが良くなるって何のバランスが良くなるんだろうっていうのはすごい疑問に思ったんですけど。
でも先生がバランス良くなるって言ってるんだったらバランス良くなるのかなと思って。
ちょっとそんな感じで今。
指標探しをしてます。
バランスはそうですね。
例えばリリース回数だけに着目して障害がめっちゃ増えてたらダメじゃんみたいな。
多分そういう意味はバランスですよね。
健全指標みたいなやつですよね。
要はそこをやったらこっち側が悪化してないことは確認しないとねみたいな。
多分そういう選び方をしなきゃいけないんだと思うんですよね。
何かありましたか?良さげなメトリクスは。
いやこれはもう完全に守秘義務に入ってきたのでもはやこの先は言えないなみたいな。
なるほど。
手応えはあったってことですか?
手応えは何か出せそうだなと思いました。
少しマシなものが。
あと危機感が持てそうなメトリクスは作れそうだなとは思いましたね。
危機感ってめちゃくちゃ良いですね。
っていうのはこれはダメだよねみたいな。
これは情けないよねみたいなものだったりとか。
これは良くないよねみたいなところかな。
作れるんじゃないかなっていうのと、これもアジャイルと一緒でとりあえずやってみないと分かんないしな。
そうですね。
近所さんも結構孤独感じません?こういうの会社でやってると。
でもですね僕マネジメントが割と組織、ピープル寄りになってるのでコードはあんま触ってないんですよね。
たまに1万秒くらいのリフを自動修正しましたとか言ってプロティック投げつけたりはするんですけど。
PHPスタンを強引に入れてたりもして。
PHPスタン強引に入れてますね。邪魔見ろと思って入れたんですけど。
これね、最近本当真面目にリファクターしてるんで本当に大事ですね。
PHPスタンめちゃくちゃ良くて、強引に入れましたけどPHPスタンをある程度のレベルで回せていったらそもそもPHPのバージョンアップって何も苦しくないっていう感じがするはするので。
全然それだけで必ずバグが起きませんとは言わないんですけど、実際組んだことはあるんで。
ただとはいえ、例えばPHP昔のバージョンだとイコールイコールの判定が変わりましたみたいなのはそもそもストリクトな比較しか許さないイコールを書いていれば何も困ったことなかったはずだし。
定義されてないオブジェクトのプロパティに突っ込むみたいなやつもちゃんと静的解析回していれば何もダメージなかったんですけどみたいな話はあると思うので。
そうですね。本当身に染みてます。
要はレガシー高度改善ガイドとか、基本的に不具合というかリファクタリングのやり方って、手法はいろいろ書いてあるけど、
基本としてはテストハーネスで囲ってテスタブルにして、破壊せずに修正していくっていうのは基本になると思うんですけど、そもそも型がついてないとテスタブルでないみたいな。
そうなんですよね。どこまでテストをすればいいんだっていう。
無限の入力に対して無限の出力がありますみたいな。無限をテストしてくださいみたいな。
そうなんですよね。CPUが足りませんみたいな。
無限の可能性がございますみたいな。このIDはたまにIntでたまにStringですみたいなことが起きえるなみたいな。ぬるもありでよみたいな。
それでいて、ビジネスロジックのif文の中にemptyとか使われてると、可能性をもっと真面目に否定してくださいみたいな気持ちになってくるんですね。
エンプティは確か何かで弾いてた気がする。アラートが出たはず。
エンプティと新しいファイルのStrictType="1")はチェックされます。
いいですね。いいですね。
CIが落ちます。
素晴らしい。
本当に大事です。
このポッドキャストを聞いている人たちに伝えたいのは型をつけてくれと。
できればプリミティブではない型をつけてくれと。
あんまり無理する必要はないから、全部のIDをID型にしろと言ってるわけではないんです。
そこは誤解してほしくないんです。
みんな急激に舵を切ってすべてが型になると、そらこそ困るんで。
そうですね。でもそうすると、どこから始めればいいですかっていうピュアな質問を受けることになるので、
おじさんたちはバランスだよって答えるしかないみたいな。
バランスでなんだって打たれるじゃないですか。
パターンは言いながらにしておけ。それがバランスだ。
恐ろしい。
でもバランスは教えられないですよね。
バランスはバランスですからね。
経験とか、あとそれこそPHPってものを知ってるか知ってないかみたいなところに寄ってきてしまうんで。
なんかでもそうですね。
最低限守らなきゃいけない水準みたいな、
例えばユニットテストどこまで書かなきゃいけないんですかとか、
ユニットテスト省略していいパターンというかケースってありますかとか、
そこら辺はしっかり言語化していくのは大事なんだろうなみたいな気もしますよね。
でもそうですね。それはそうだと思います。
バランスをうまく説明したり、ルールとかマニュアルとか作った上で判断が揺れそうなところがあったら、
僕だと割と安全側に倒すというか、ちょっと冗長になってしまったりとか、
技術負債とテクニカルレビュー
テストをいい感じに省略される職人の判断を許すよりかは、機械的にちょっと脳死で書いちゃってくださいみたいな感じの運用に、僕だとしがちなんですけど。
難しいんですよね。なんでこんな不満なことやってるんだろうみたいな気持ちになるのはとても分かるので。
何て言うんですかね。組織全体の意思としてそのバランスみたいなものが浸透していくと、多分統一感とかが生まれてくるとは思うんですけど、
組織全体でそのバランス感を醸成するっていうのは大変ですよね。
大変だと思いますし、組織全体の意志としてそのバランスみたいなものが浸透していくと、
大変ですよね。
大変だと思いますし、組織は生き物ですからね。変わってきますからね。
それで言うと押し付けもすごい嫌だなと思ってるんですよ。
それって視野を狭くしちゃってるじゃないですか、組織として。テストはこう書きましょうって言って、その書き方以外認めませんっていうのは可能性の破壊だと思っていて。
それはそれでしたくないんですよね。じゃあどうしたらいいんですかみたいに言われて、いつも空を眺めるしかないみたいな感じになっちゃうんだけど。
そうなんですよね。聞かないでほしい。聞かれると辛いみたいな。
そうなんですよ。
それこそさっきスタのところで言ったエンプティーとかも厳密に言えば多分使っていいところはあるはずなんですけど、こういう状態にすると多分疫病が流行りますみたいな時ってもう汚しくしかないので、
公衆衛生を保つためにはちょっと犠牲はいるかみたいな、行動の制限をしますみたいな。どうしても出てきちゃうんですよね。
そうですね。エンプティーはやめてくれと。
イズセットとかイズヌルで吉田に頼むみたいな。あれだったらイズアレした後、カウントでチェックしてくれみたいな。
なんかそれこそベチパーだけが染み付いてる諸差だったりしぶさだったりするそう。
そうですよね、確かに。
そうですよね、そんなの知らんよっていう話にしかない。ってなると、やっぱり型をつけてくれって話になるかもしれない。
そうですね、型やっぱ人間に優しいですね。シューマンフレンドリーな感じが。
シグネチャーに型さえついてれば、中でのロジックが多少おかしかろうが、インとアウトは保証されてるから、まあいいかな。それも限度があると思うんですけど。
っていう気がする。そうか、それはでも確かにあるな。シグネチャーつけてくれって。
PHPさんのレクターかな?作ってる人が、タイプカバレッジみたいなのを出してみようぜみたいな活動してますよね、確か。
タイプカバレッジ?
型がどれくらいついてるかみたいな。
それめちゃめちゃ面白いですね。
何をもって型がついてるというのかなみたいなのがあんまりわかってないんですが。
あれですかね、クラスのメソッドにちゃんとリターンタイプついてるみたいなのをやるのかな。
あーって感じですかね。
PestPHPタイプカバレッジ、PestPluginタイプカバレッジ。
今ですね、確かこのブログ記事だなーっていうのをURL送ったんですが。
何しろ今日はですね、生じゃなくて収録なので、後でちゃんとショーノートにつけよう。
そうですね。Twitterでつめたほうがいいのかなと思ったんですけど、生じゃないかな。
そうなんですよ、生じゃないと無理しなくていいんだなと思って、今すごく心が晴れやくです。
なるほど、50%タイプから。
クラスのメンバー変数とか、メソッドの引数の型と戻り値の型でカバレッジ出すみたいですね。
面白い。
面白いですね。
これ何で出してんだろう。
パッケージがあって、この人のレポジトリでタイプカバレッジっていうパッケージがある気がする。
どこにある?リンクはどこだ?
メトリクスの取り方
あった。tomaspotrooperさん、タイプカバレッジパッケージ。
EasyCodingStandardとか、レクターでおなじみの。
Standard、タイプカバレッジ、コンポーザーリクワイヤーして実行できるのかな。
面白そう。
指揮位置とか決められるのかな。
リターンタイプだと50点みたいな。
マダムタイプは30点。
プロパティタイプ70点みたいな。
別にそこはあんまりこだわりがない。
でも面白いですね、これ。
そうな気はしますよね。
やっぱりなるべくフォーキーズではないけど、取得できる不吉な匂いを感じられるための指標みたいなものを、いかにテーラーメイドで持っておくかみたいなところが大事なのかな、最近思っているところでありますね。
これいいですね。これ早速使わせてもらおう。
マジですか?
指標なんて脳死でCIで溜め続ければいいんで、ガンガンジェンソーで溜めていってますね。
割と面白くて、Gitだと日付でその状態に戻せるじゃないですか。
確かに。
そうすると後からでも指標取れるんですよね、いくらでも。
そうですね。
それはすごい良いなと思って、それをやり直して、すごい永遠に時間がかかるんですけど、CIでどれくらい型がついているとか型がついてきたとかが分かるといいかもしれない。
そこら辺がソフトウェア品質とかアーキテクチャー品質みたいなものを何かいい感じにしようって考えた時のフィットネスファンクションみたいなのがイメージになってくるわけですよね。
どうしてもPHPスタンとか今言われてた型のカバレッジ、タイプカバレッジとかってどうしてもちょっとテック寄りなんですよね。
それがなぜ顧客の不満足とかビジネスへの悪影響につながるのかっていったところの間がない。
そこを強引にでも結びつけていかないことには、やっぱり全体のコミュニケーションにはつながらないなと思って。
そうですね。僕が仕事でマネジメントとかやってるんで、マネージャーミーティングみたいなものに出た時に、
脆弱性対応の分明でこれこれこういうことしましたみたいな、チームは絶対に成果出してるんですけど、どう伝えればいいんだろうみたいな悩むことがありますね。
タイプカバレッジの向上を今月は20%進捗出しましたみたいなことを他の職能のマネージャーさんの貴重な時間を奪って伝えたいことかって言われると、
そうなんですよ。
違うよなーって。
そこなんですよ。
本当?
僕らがセールス系の部署の人たちが電話かける回数が1人当たり10回上がりましたとか言われても、エンジニアは多分興味持たなくていいと思ってて。
考えたらこれもそうですよね。外向けには興味持って欲しく、持たなくてもいいよねみたいな話かな。
内部実装みたいな気がしますね。
やってて当たり前ってところかもしれない。自分たちが危機感を持つためにはいいかもしれないけど、外に対して分かりやすいものではない。セキュリティとかはね、割と分かりやすい。
そうですね。セキュリティは分からんと言われても、やらないとダメっていうのを頑張ろうとなると思うんで。
そうなんですよね。そこすごい分かります。よかった、金城さんも同じ思いですよね。
伝えられる物語をこちら側でも作っていかなきゃいけない。改善は絶対やらなきゃいけない。ここのベースはもう動かさなくていいと思っていて。
うちの近所の土手も雑草のしばかりが2ヶ月放置されるともうすごいんで。
散歩の人とランナーがすれ違えないくらいのジャングルになるんですよ、すぐ。
それはすごいですね。
結局だから改善というかメンテナンスはしなきゃいけない。常に見ておかないといけない。網とかフェンスが張ってあるけど、それも錆びてたりするから。
こないだ交換してましたけど、工事の人。やっぱりここもちゃんとこうやって税金を使って計画的に改善していかないといけないものだねって思って。
いいことしてるなみたいな思ったんですけど。これのソフトウェア版ってなんだろうなと思って。
常にソフトウェアにしちゃうんですけど。
技術不細を解消したいのって何年なんですか?
技術不細を解消したいの。なんかね、分かんないけど状況が悪化しているっていう感じは避けたいっていうのが一番かな。
技術不細が増えてるか減ってるかっていうのは多分暗黙的にエンジニアは増えてるって思ってるはずなんですよ。
で多分それは合ってると思うんだけど、この笛が良い笛なのか問題ない笛なのかっていうのが何がしか指標化できてるとか。
あと多分開発してて効率悪いなとかって多分思ってる人いると思うんですよね。
そういったところをなるべく拾い上げて改善しないといけないなみたいなのを思ってます。
可視化しとかないと、人によって感覚とか基準がぶれるみたいなのがあるんですよね。
今週は頑張って2回リリースデプロイしましたとか言われても、1週間に2回かみたいに感じるかどうかは。
そうですね。
どういうところで育ってきたかによっちゃうと思うので。
全然変わりますね。
それこそあれですよね。貯めて貯めて月1リリースみたいな会社さんは多分まだいっぱいあると思うんで。
そうなんだよな。どっちを自分たちの会社の文化にするかみたいなところは。
そうですね。
全体方針がなきゃいけない。全体方針も必要って感じかな。
頑張ってる人を無限にしたいつもりでももちろんないので。
そうそう。
そういう意味でも、いやここまで目指しましょう。で、今立っているとこはここだよねみたいな。ちゃんと。
チームの全体感と個々の責任のバランス
そう。だからそれをビジネスの目標と絡めながら増やした方がいいのか。それともこのままでいいのか。減らしても問題ない。悪化しても問題ないのか。
みたいなところに対して会社として技術のチームとして解像度を高めるみたいなところがポイントなんだなと思って。
やっぱりそうするとやっぱりあれですね。無駄でもいいからとにかく資料を集めっていうのが一番なんだなっていう感じはしてきたな。
やっぱりいっぱい本読むとか。
いっぱい本読むあるんですけど。
なんかちょっと聞いてみたいなと思ってもちろん言える範囲で構わないんですけど、なんかエンジニアとか技術組織の中だとどのくらいそういう話してるんですか。
なんか富所さんがいつもあの人またメトリクス集めてるよ。何あのおじさんみたいな。あり得るかなと思って。
僕はそうですね、おしゃべるおじさんなんでとかで、なんかこの仕様わかりづらかったんでブログ記事にしてみましたみたいな。
まあ社内のコンフルでの話ですけど。
とかこういうメトリクス取ってみたよみたいな興味のある人見てみてねとかそういうのはよく言いますね。
ただここはすごいニュアンスが難しいんですけど、アーキテクチャーの基礎だっけ。いっぱい本があるから。
ソフトウェアアーキテクチャーの基礎ですかね。
そうですね。とか違うなどの本だったかな。どの本だったか忘れたんですけど、全員開発者全員がアーキテクト的な視点を持つ必要はあるよね。
っていうような記述がどっかに書いてあって、いやそうなんだよなーみたいな。それはまあ贅沢な話かもしれないけど。
がらんとバザールじゃないですか。
そうですね。
絶対違うけど。でもそういう話いいですよね。
全体感とかこれが何を意味している仕事なのかっていうのを意識できていると少し変わるよねみたいな。
自分たちに閉じないでサイロ化はやめてくれと。かといって独立性を奪いたいわけではないんだみたいなところがちょっとバランスとしてあって。
そうするとチームの中には全体感を見る人もいて、自分たちの具合を見る人もいてっていうこうちょっと遠い目、鷹の目みたいな。
俯瞰した目と自分たちのチームを見る目っていう2つを持ってほしいなと思うんですね。そうすると多分バランスよくなるんで。
チームが増えるとダメなんですよやっぱ。チーム増えると大変なんですよ。
そうですね。さっき話した技術的不才のシャークの根源は人間なので。
人間ですね。
人間が増えるとダメですね。
でも分割統治をしようみたいな話がそもそもマイクロサービスとかに人々が飛びついてく理由ではありますもんね。
マイクロサービスの危険性
だからこそこれまでプレイングマネージャーみたいなこともよくやってたし、マネージャーだけっていうのもやってたんですけど、
マイクロサービスすげえ危険だなと思ってて、マネージャーやってた時思うのがあんまりコミュニケーション取らないチームってやばいんですけど、
マイクロサービスって下手したらコミュニケーション取らなくなるなと思って、それが一番怖いなと思ったんですよ。
使用書公開してますとか言われて、いいじゃんみたいな、使用書公開してるんだからみたいな。
そんなサイロ化がすごい発生しそうだなと思って。
マイクロサービスの一番の売りってそこじゃないですか。
そうですね。
リリースも独立してるし、自分たちの好きな技術で作っていいし、Goが得意だったらGoで作ればいい。
それこそラストで作ってもいいし、インとアウトが合ってればいいみたいな。
それって著しく危険だなと思って。
僕は警戒してましたね、最初から。最初からすごい警戒感でした、僕はマイクロサービス。
それはあれですか、巨大な泥団子だったらそこら辺の問題はないんですか。
巨大な泥団子でも同じ問題は発生。
巨大な泥団子ではないですけど、モノリスというかチーム分割されてなければいける。
モノリスでも多分同じ問題発生するんだけど、少なくとも言語は一緒っていうのと、フレームワークとかは一緒。
なので、なんとかなるみたいな状態にはなると思うんですよね。
例えばマイクロサービスで作られて、そこのチーム解散しましたって言って、マイクロサービスだけが離島に残されたときに、
誰がそのマイクロサービスの面倒を見るのかって言ったときに、ボールを拾うやつが多分見るんですよね。
マイクロサービスのメリットとデメリット
そうですね。
ボールを拾うやつは多分いろんなところのエースをやってたり聞けしをやってるんで、多分忙しいんですよ。
そうですね。
だからマイクロサービスを作って、それを作り置きすると、ダメージが当たるのは自分のチームの一番大事なポイントにダメージが当たるなと思ってて、
それだけは避けたいみたいなのが僕の現体験としてはあるんだ。
そうですね。
だからデータベース分かれてる分かれてないは、僕の中であんまり興味がなくて、データベース分かれてた方が特立性が高いんだけどみたいな。
あれですね。オーディエンス無視して分かりづらい例えすると、レヴロンにセンタープレイやらせるみたいなことですね。
そうですね。NBAの大スターですね。
多分できるんですけど。
やってましたしね。
できるっていうのと、しばらく…近所さんは知ってると思いますけど、プレイオフで何でもかんでもやらせすぎて、第4クォーターにレヴロン・ジェームスが肩で息をして、もうさすがに無理みたいな。
いやー、年ですもんね。
年もあるのにそんなに意地はさせるなよみたいな、監督みたいな。
いやー、異心でしたね。
そうなんです。
今、自分でどうなんですかねっていう質問をしながら思ったのが、自分がやったことで他のチームが影響を良い意味でも悪い意味でも受けてしまうという状況があると、必然的にコミュニケーションが発生すると思うので、
マイクロサービスをうまくやっちゃうと、そこも本当に疎結合になってくるから、知らない世界が確かに出てきちゃいますね。
そうなんですよね。マイクロサービスにするのは多分コミュニケーションを疎にすることで生産性を上げましょうなんですけど、そもそもコミュニケーションがないと一番大事なところが疎になっちゃいませんかみたいなところがあって。
大切なところを残してくれませんかみたいな。
なるほど。
気はしないでもない。モノリスだったらもうみんな同じ船に乗ってるんで、爆発させると爆発しちゃうんで、コミュニケーション取らざるを得ないみたいな縛りがある。
そうするとサイロ化できないから、サイロ化できないっていう縛りがモノリスには多分あると思ってて。
だからその欠点は実は欠点ではなくて、実はいいことなんじゃないかなって思ったりもするんですよね。
いや、要はバランスっていうのがまた。
そうそうそうそう。そうするとまた要は、僕もうバランスって言葉使いたくないからもうずっとトレードオフ、トレードオフって言ってます。
すごいアーキテクトっぽい。
そう、アーキテクトっぽい。ただ中身は一緒なんであんまり意味はないんですけど。
いい。
でですね、ちょっと一旦この収録の編集点をここに作ろうと思うので、一旦ここで前半戦終了。
はい。
