ツナギメエフエムの始まり
始まりました、ツナギメエフエムの第56回です。
ツナギメエフエムは、IT勉強会コミュニティ繋がりの方々をゲストに迎えて、
雑談するボットギャストです。
なんか笑わせてるでしょ。
まずは、x旧Twitterのハッシュタグについてお知らせです。
ハッシュタグはカタカナで、ツナギメエフエムです。
投稿お待ちしています。
今回で第56回目です。
今日のゲストは、tomidokoroさんとtakeuchiさんです。
それでは自己紹介をお願いします。
まずは、tomidokoroさんからお願いします。
tomidokoroです。
Twitterは、hanhan1978です。
つい7日前ぐらいにコロナになりまして、
今はようやく元気が戻ってきたタイミングです。
ペチパーでリアキテクチャリングとかをよくやっていて、
最近は電動アシスト自転車で近所を走り回ってます。
よろしくお願いします。
はい、よろしくお願いします。
続いて、takeuchiさんお願いします。
腰が痛いtakeuchiです。
よろしくお願いします。
それだけ?よろしくお願いします。
腰どうしたの?
腰が痛くて、ここ3日前ぐらいから。
何かあったの?
うち、水を買い溜めするんですよ。
2リットルのやつ、6本入ってるやつを、
1回に10パックぐらい買ったかな。
結構いっぱい買って車に乗っけて、
お、切れた。
家に持って帰るんですけど。
一瞬切れた。
一瞬いなくなった。
一瞬いなくなりました。
今、ちょっとVPN切ったからですね。
こっそり。こっそりVPN切ったから。
全然こっそりじゃなかった。
どこまで聞こえてます?
水魚10箱買って。
水10箱ですね。
tomidokoroさんとtakeuchiさんの自己紹介
1個ずつ運んだんですよ。
その次の日ぐらいから腰痛くて、
今、ロキソニンテープ貼ってます。
やばいやつじゃん。
なんか変な違和感あるんですよね。
それ、やっちゃってるんじゃないの?
多分まだ大丈夫です。
大丈夫ですか。
怖いな、腰とか大事にしてね。
いや、俺、首が痛いからさ。
その腰の痛みとかすごく心配になる。
富所さんは?
大丈夫なの?体調。
全然。
全然。
めっちゃ元気ですよ。
Xで見てますよ。
大変そうだなって思って。
最初の3日ぐらい辛かったけど、
その後はそんなに。
今日何日目ぐらい?
今6日目かな。
6日目。
でもまだ1週間か。
5日目で会社に仕事に戻ったら、
逃げ切りたいな。
コロナだけはなりたくないな。
辛いからこればっかりはさすがに、
いかに僕でも赤瀬さんに早くなれよとかいうのは、
冗談でも言いたくないなっていう感じ。
疑わしい時は何回かあったんですけど、
熱なかったし、
多分逃げ切ってるんだろうなと思うんだけど、
分かんない。
うちの嫁さんとも言ってたんですけど、
明らかに辛いから。
あれはコロナだったのかなみたいな、
そういう生優しいもんじゃないって話を言いまして。
極端に違うんですね。
そう、全然違う。
なるほど。
だったら分かりますね、多分。
しぶといよ。
長い。
なりたくない。
なりたくないよ、これ。
はい、じゃあ、
富野子さんと竹内さんを迎えて、
リアアーキテクチャーの話をちょっと今日は、
していきたいなと思うんだけど、
その前にちょっと近況を聞きたいですね。
久しぶりなんで。
確かに。
いつの日ですかね。
あれあれ、
あの、ほら、
富野子さんのやってるポッドキャストに
呼ばれたのが去年の、
あれ去年のか。
去年何月だったっけ。
5月だそうです。
えー。
多分あれ以来じゃないかな。
1年以上だ。
1年以上経ってます。
そんな経ってるんですね。
そうそう、そんな経ってる。
えー。
で、なんかその間なんかあったんでしょ。
いろいろ変わりましたね。
人生が変わりました。
お、人生変わった。
何があった。
子供が。
子供が終わりました。
おめでとうございます。
おめでとうございます。
おめでとうございます。
無事デプロイされました。
デプロイされましたか。
はい。
無事が一番。
で、お休みもらってたんですね。
そうですね。
僕、3月かな。
3月から今月の頭ぐらいまで6ヶ月取ったんで。
だいぶ仕事してなかったです。
大変だった。
労働から離れました。
いや、最初はめっちゃ大変でしたね。
1ヶ月2ヶ月。
大変でした。
そっからはだいぶ慣れたんで。
なるほど。
久しぶり仕事してどうなんですか。
今月から。
今月からです。
なるほど。
仕事して思ったよりすんなり戻れましたね。
よかったよかった。
初日からいろいろやりました。
そうなんだ。がっつり。
で、じゃあリアーキテクチャーの話やっていきますか。
リアーキテクチャーとメトリクスについての話
そう、偶然じゃないけど、2人とも最近そんなことを言ってたなと思って。
ちょうどいい。
前々から知ってはいましたね。
同じような言葉を使ってるなって。
そうなんだ。
遠目には見てました。
富野子さんがリアーキテクチャーの話をよく知ってるのは知ってて、
知ってるなと思ったけど、竹内さんの会社の記事が出てるじゃないですか。
あれを見て、すげえ似たことやってると思って。
そうそう。
で、じゃあ実際リアーキテクチャーって何?っていうのとか、
どういうタイミングでそれをやるべきタイミングになるのかとか、
どうやっていくのかとか、そのあたりが聞けるといいなって思ってるんですけど、
そのあたり、まず先輩から聞こうか。
え、先輩からの?
先輩から聞こうか。
これ会社でメインの仕事なんですかね?
これ会社でメインの仕事です。
そもそも入社するときがもう辛いんで、助けてくださいみたいな感じだったので。
もうそういうことをやってねっていう状態で入ったんですね。
そうなんだ。
最初入ったとき、今はCTオフィスって場所にいるけど、
最初もアーキテクチャーグループみたいなところに入ってきましたね。
そもそもそういうことやってねって言われてて、
そういうの興味あるんでっていうので入りましたね。
あとはそのまんまっすね。
そのまんまっていうのは?
いや、その役割のまんま。
ずっとそういうことをやってる。
就労しておりますね。
だけど会社っていうのは、こういう遊びのある舞台っていうのは許せないんだよね、きっとね。
すぐいろんな役割がある。
あっちで人が足りないとか、こっちで人が足りないとか。
あっちの橋が落ちたとか。
あっちのビルが壊れてるとか。
あっちで水を求めている人がいるとか。
リアーキテクチャーっていうと、
一チームの局所的な話ではなくて、
結構全体を見て横断的に考えなきゃいけないところとかあるはずじゃないですか。
そういうところをどうやってやってるんだろうなーとか、
そのあたりなんか話ありますか?
いやー、だから、
もうモノリスで、お金も儲かっててってなると、
チームもいっぱいあってパラで動いてるんですよ。
ってなってくると、
要は無停止で直すっていうのがめちゃくちゃむずいんですよ。
直す対象が毎日何がしかの回収が入っていくから。
そもそも計画できないみたいなところがあって、
じゃあそれをどう直しますか?みたいな。
そうはいつ、それをどういう風に良い流れに持ってきますか?
みたいなのをこの2年半くらいはずっと考えてきてて、
ある程度一定の位置が今見えて、
その方向に今邁進してるって感じです。
それが今回ネタ調にはいっぱい書いてます。
HRの話だったり、HRトークルの話だったり、
今そういうツール類というか、
やり方みたいなものを未来に何とかするために、
今の夢の島にはもうこれ横目は捨てないでねみたいな話になって、
こちらの別館の方によろしくお願いしますみたいな感じで。
わかりやすく話すとそんな感じですよ。
夢の島の改善をこれからしていくんだけど、
じゃあその中で何を一番メインの回収ポイントに持ってくるか、
みたいなところがまた新しい決断のポイントになって、
これもあんまり闇雲にはやりたくないので、
これをメトリクスとかを合わせていきたい。
なるべく数字で分かれる形でやっていきたいっていうのが
僕の思いではあって、
そこに出てくるのが福岡のペチコンで言ってたけど、
GQMっていって目的指向のアーキテクチャーというか、
ゴール設定みたいなメトリクスの収集みたいな話があって、
それとあと最近だとリンとデブオープスの科学の書かれた博士の人が
ちょっと前に日本向けに登壇されてたんですけど、
そこでも紹介されてたんですけど、
ドーラとかスペースとかっていう話があって、
それもメトリクスの取り方とか、
どういうふうにキーメトリクスを決めていくかみたいな話になる。
どういう目的に対してみたいなところを
両方ともすごい大事にしてるので、
そのメトリクスをいかに収集して、
それがどういうふうに会社のミッションとかに合うのかと。
あとはカスタマーサクセスにおいて一番主要となるキーメトリクスは何かとか。
そのシステム改善だけじゃなくて、
今のシステム開発上で
自分たちを一番抑え込んでやってるボトルネックの支払いは一体何なんだろうみたいなところ。
それは多分リファクタリングだけの話じゃなくて、
デプロイメントの話とかCIとかビルドの話もあれば、
開発のやり方とか、
あとはオンボーディングみたいな話もあるじゃないですか。
それぞれのチームがどういう戦略を立てるのかとか、
どういうチーム構成してるのかとかっていうのまで含めて、
全体的にどういうふうにしたら
うまいこと僕たちはやっていけるのか。
みたいなことをすごい大きく大きく考えていくところですかね。
なんで、いつになくつなぎめFMで真面目なことを話していますが。
本当ですね。
こんなふざけてない。
こんなにふざけてない僕は多分。
珍しいですよ。
珍しいですけど、
本当にやってることはそれで、
最近はその取り組みの一つとして、
CT用質頼りみたいなものを強く作ろうと思っていて、
それはドラとかスペースみたいな、GQMみたいなところから、
目的指向でメトリックス収集をするときの、
収集したデータっていうのを月次で発表していって、
みんなに注意喚起とかをしながら、
自分たちもこういう改善をしていくんだよ。
これは多分開発者にも向けるし、
経営人にも向けるし、
フロントエンドじゃない意味でのフロントの人たちね。
営業の人だったりとか、カスタムサクセスとか、
その辺の人たちにも向けて使えるデータとか、
そういったものっていうのを用意できると、
いいなとは思ってる。
そういったことをすごい詳しくやってますね。
リアーキテクチャーをしようぜってなったときに、
じゃあどこから手をつけるのかってなったときの、
どこからっていう根拠みたいなのが必要じゃないですか。
でもそれがちょっとフワッとしてるんで、
そういうときに指標とかがもちろんあったほうがいいなと思うんだけど、
その指標じゃあどう数値化するのっていうのが非常に難しくて、
やんなきゃいけないのはフワッと分かるんだけど、
説得材料を自分の中に持ってなくてですね、
改善はしたいんだけど、
どう手をつけていいものかみたいなのって、
それぞれの現場でもあると思うんですよね。
そこに根拠をどう持たせるかって考えてもらえるんですか。
根拠ってもう考えちゃダメだと思ってて、
うちの会社結構スクラムマスター研修とか受けた人たちが多いんですけど、
その彼らのノートの中にすごい発動することが書いてあって、
現場が改善したいって言ったときに、
改善の必要性
意味があるのかどうなのか証明できなければ改善はさせないみたいなのっていうのが、
いわゆる普通の現場で行われてくるコミュニケーションだと思うんですけど、
これ逆で、改善するって言ったときに意味があるのって聞いてきて、
改善しない根拠が逆にあるのっていうふうに、
僕たちは聞かなきゃいけないと思って。
お前勝手に抵抗してきて、
現場の実装のこともツライソースコードのことも知らないのに、
意味あるのとかって言ってるけど、お前何様なんだよみたいなことを、
僕らは言わなきゃいけないと思って。
立場として?
そう、立場としては。
お前このクソコードこのまま放っといてどうすんだよみたいな、
PHP5.2でずっといく期間みたいな、
小期間みたいなことはずっと言っていかなきゃいけないと思って。
なるほどな。
それは多分だから、改善は絶対しなきゃいけないんですよ。
だってソフトウェアはどんどんバージョン上がっていくし、
OSも書き換わっていくし、
不具合は見つかるし、
絶対状況はどんどん悪くなるから、
データはどんどん増えるしね。
だから改善は絶対必要なのよ。
だから改善をさせないで、
他のことをやらせようとした場合、
そこには君たちは逆に根拠がなきゃダメだよねって。
そう言われるんだったらね。
そうそう。
確かに確かに。
そう、だから改善はするんだよって。
しないはないんだよっていうのが、
多分ベースラインだと思って。
ここが握れないんだったら、
ここはもうダメだなと思ってて。
でもそれは会社としてそういう仕事を
任せてくれるんだったら、
そこはやっぱり防波堤として。
そう、防波堤ではあるし、
でもこれもだから結局会社の中で
僕はある程度信頼関係を持ってきてるから、
そういう風に強く言えるようになってるだけだからね。
はいはいはいはい。
ここに至る道のりには
それなりに成果を出してきましたみたいなところもあるし。
なるほどね。
そう、対外的にちゃんと登壇もしてみたいな
パブリックイメージを守り、
ツイッターでも変な発言をしないようにしており、
みたいな。
そういう全てが一応
つながってきてはいるみたいな。
結構でも強い力を持ってやってる気がする。
でも強くやっぱりいかないと、
だって竹内さんも赤井さんも分かると思うんですけど、
絶対壊れるじゃん、修正したら。
そうですね。
絶対壊れて、
どっかから液体が漏れてきたりするじゃん。
ソフトウェアのやつは。
もう全然想定しないやつが漏れてくるじゃん。
えーみたいな。
そんなことやってましたの?みたいな。
あるじゃん。
ありますね。
そんなバカな?みたいな。
このフラグそこで見てんだ?みたいな。
あるある。
それは無理だなっていうのがあって、
リアーキテクチャーの進め方
結局そういうのは出つつ、
それをいかに安全に抑え込んでやっていくかみたいなことを
用意しながらどうやって前に進めていくかみたいな話。
なるほどなるほど。
そのための必要なことを全部ここに書きましたが、
割と僕はこれですかね。
なるほど。
大きな声で話すとか、
吐き吐き挨拶をするとか、
フィードバックをするとか。
大事ですよ、こういうのは。
そう。
分かる。
はいはいはい。
竹内さん竹内さんで、
またやり方というか状況がいろいろ違うと思うんだけど、
会社の中でどうやって進めてるとか、
そのあたりの話を聞かせてもらえると。
うちのとこは多分、
富野コロさんのところは
やってるようなこととかとは
ちょっと多分少し違うかなと思っていて、
富野コロさんがやってるところ、
どちらかというと結構、
技術ドリブンにやってる感じですよね。
ちょっと違う。
うーん、そうとも言えないかな。
あんまり技術はやってないかな。
そうなんですね。
でも、今のその、
なんだろうな、
リアーキテクティングしたい部分の
システムを分割したり、
何か別の構成にしたりするための
準備だったり、
計測だったり、
そこの手筈を整えてたり、
治安を維持してたりとかするんですよね。
そうですね。
まず手を付けないと、
これ以上崩壊するとまずいみたいなところは、
まず何とか技術的にカバーしとかなきゃいけない。
発言権がある程度得られるまでは、
政治的な活動はできなかったりもするし、
そこら辺は、
あれを見つつ、
周りを見ながら、
こんな状況かっていうのを見ながら、
うちはもうCTOも含めて、
僕もですけど、
歴が同じぐらいなんですよ。
そこまで深い信頼関係を得られていない状態から来て、
一個ずつ、
一つずつ、
石積んでいってるみたいな感じ。
会社に入られてからってことですか?
そういうことです。
の歴がってこと。
僕と半年ぐらいしか変わらないんで。
そうなんだ。
1年ぐらいか。
でもそんなに変わらないです。
うちはどっちかっていうと、
新しいサービス開発してるっていう方が近くて、
もちろん、
コアのプロダクト、コアのサービスの方の
ライブラリのアップデートだったり、
フレームワークのアップデートだったりっていうことも、
うちではやらないですね。
リアーキではやらないんですけど、
別のサイドプロジェクトでそういうものをやったりしますね。
僕はリアーキやりながら、
別のPHPのバージョンアップやったりとか、
そういうことをしたりするんですけど、
そういう感じでやってるんでちょっと違ってて、
うちの場合は、
僕の場合は、
僕の場合は、
事業戦略とか開発組織として、
システムの方向性を、
方向性というかスタンスというか、
マイクロサービスをやっていくんだっていう方針を
打ち出しているので、
事業の戦略上とか、
開発組織のそういう方針にのっとって、
ここのドメインというか、
こういう機能とかは分割したほうが、
分割しやすいというか、
分割しやすいというか、
分割しやすいというか、
分割しやすいというか、
分割しやすいというか、
分割したほうが、
分割して可用性なり、
スケラビリティなり、
担保していったほうがいいんじゃないか、
みたいなものが、
マイクロサービスの構築
すごいトップダウンな言い方になっちゃうけど、
上から方針がある程度来て、
そこでそういう課題をもらって、
そこでそういう課題をもらって、
実際、
運用上どういう課題があるかとか、
実際、運用上どういう課題があるかとか、
ビジネスサイドでこういうことしたいとか、
ビジネスサイドでこういうことしたいとか、
機器の用件とかいろいろあるんですけど、
そういうものを全部洗ったりして、
別のサービスとして、
基本的には、
コアのモノリスのほうから、
一つのサービス、
切り出していくっていう形で、
やってますね。
なので、
課題を見つけて、
そこの何でそれをやるのか、
何解決したいのか、
みたいなところから全てを洗っていって、
いろんな設計をして、
泥臭くものを進めていく、
ような感じですね。
だから、
雑に具体的に、
どういう業務をやっているのか、
というと、
いわゆる他のシステムに、
使われたりするような、
システムが使うようなシステム、
みたいなものとかを、
作ってたりする、
システム基盤みたいなものを、
開発している、
っていうのは結構特徴的かな、
できるべきかなと思いますね
おだしょー 他のチームが開発で 使うものとか そういう感じですか
りなたむ 他のチームが呼び出す ようなAPIだったり 機能だったり
いったいのを作っていくような チームですね 認証だったり まだ
やってない これからやるんですけど 通知の仕組みだったりとかっていう
ものを提供しているようなチーム ですね
おだしょー なるほど このメモに 書いてくれてる リファクタリング
ではないっていうところは そうですね リアーキテクティング
であって リファクタリングではなくて 富所さんも上のほうに構造の話を
書いてるんですけど もしかしたら 近いかもしれないんですけど もちろん
リアーキテクティングする対象 が決まって 何かシステムを設計
して作っていくってなったとき の段階で まず一旦こっちを直して
から 新しく構造として切り出そう みたいなことはするんで その過程
の中でリファクターするんですけど 別にリファクタリングすること
自体が目的のチームではないので ただ何かをアップデートするだ
とか ただ切り出すだけとかっていう わけではなくて もうちょっと大きな
仕組みとかを作って解決していく っていうところのほうが近いチーム
ではありますね
いや 会社 違うと やっぱ 何だろう やる内容も変わってきますよね
今の泥団子の状態によって取れる 手段が変わってくるんで
うん 当然 やることは変わってきますけど でもリアーキテクチャー 難しくないですか
こんなもんあれですよ トライアンド エラーですよ
それしかないんですかね
そうですね 泥団子ってあんまり 言いたくはないですけど 泥団子
から 泥団子を崩すんですよね 基本的には 基本的には崩すんですよ
でも崩し方 分け方は結構いろいろ あるというか 考えないといけない
ことは結構あるんですよね 実際 どういうふうに 基本的にはデータが
一番大事ですけど データどういう ふうに切り出すとか あるんですけど
変な崩し方をして分けたりすると 結局 その大きな泥団子からもう一個
別の泥団子ができちゃうっていう
そこはなんだよな それをどう作らない
分けるんだけど 分けたらそこは 金の泥団子みたいな
金の泥団子は護衛があるかもしれない けど うまく分けないといけない
固い泥団子にはしたいよね 攻めて
そうですね 崩れないツルツルした やつ
ツルツルして引っ掛ける場所が1個 しかないみたいな
泥団子を再構築したいわけではないん だが
でも取り得るべき手段はたくさん あるんだけど みたいなところかな
僕も会社入ったときはマイクロ サービスみたいな話がものすごい
いっぱいあって これはまずいと思 って すぐ取り掛かったのはマイクロ
サービスっていう言葉をぶつぶす ところから
待って 待って 待って 待って って
君たちモノリスちゃんと作れないん だよねって言って
分散システム無理よって言って 無理 無理って言って
身の程を知ろうぜ みたいな感じ
分かります 胃が痛くなるところ はありますね
胃を痛めても問題ないぐらい グループ の構成とかもちゃんと考えてる
のがいいし 切り出したマイクロサービス 側のグループがちゃんとコミュニケーション
取ってくれるんだったら それでも かまわないって感じ
マイクロサービスとか モノリス もそうなんですけど 結局のところ
チーム同士がきちんとコミュニケーション 取れてないことで 共通化とかが
促進されずに 結局泥団子っていうか カオスなスクリプティングが生まれて
いくと思っていて じゃあコミュニケーション が問題だったんだとしたら 分けたら
もっとひどくなると思っていて 対話するから そこが対話で解決
できてないのに ソースコードだけ 分けて遠方から殴り合うんですか
君たちみたいな 今リモート全盛 だからはかどりそうだねみたいな
話になっちゃうんで そういうの だけはやめたいっていうのは
すごい思ってる
そうですね
いや でもすげえむずい もうずっと 転がってたから 分かんねえつって
どうしようこれつって
いろんな人にずっと相談してました どうしようか
マイクロサービスの導入における組織の課題
いや アーキテクチャーっていう ほどでもないけど ちょっと下作り
変えを今やってはいて どう作り 変えていこうかなって 日々悩み
ながらやってはいるんですよ だ からヒントをくれないから 二人
とって
いや だから 僕はもうマイクロ サービスやりたいって言ってる
人に何度も言うけど 取り外したい ところはすぐできるよつって 通知
とか認証とか でもそれってAWSでも できることじゃんつって マネージド
使ってもできることでしょ マネージド を使ってできそうなことは 多分
すぐマイクロサービス切り出せる よつって そうじゃないところが
多分コアドメインだから そこは 多分切り出せないよっていう話
はしてて 結局そうすると 目の前の 複雑な問題からやっぱり逃げちゃ
だめ 何がそれを生み出してるのか っていうことを反省するのはエンジニア
だけじゃなくて ディレクターも そうだし カスタマーサクセスも
そうだし それを作り出している 組織全体の活動が それとして
結果 結実してるんだから それは 全員が反省しなきゃいけないはず
で それが生まれてないのに エンジニア だけ頑張って直しなさい
は多分ないと
まき込みながらやるってことですか ね
そう まき込まなきゃ絶対だめよ というところはあって
大きな改善をしたいんだったら ってことですよね
そうそう それこそエンジニア ドリブンで何か直すとかっていう
と さっきみたいな話で そういう 意味あるのみたいな 金儲かんの
持ち物の決定とディレクターやチームの関わり
みたいな話になるじゃないですか 違う 反省しないじゃんみたいな
ところから始めなきゃいけない
耳にしみる言葉ですね
そうそう
誰が聞いてるか分かんないんで あんまり強い言葉は言えないんですけど
僕は
いや こういう話すると みんな会社 の人に聞かれて大丈夫ですか
とか 福岡の発表もしたやつも これ 会社の人に見られて大丈夫ですか
って言って 一点の曇りもなく 大丈夫ですってずっと答えて
本当でもあれなんですよね 汎用的 というか 切り出しやすいものって
あるんですよね 切り出しやすい ものとか 切り出したほうが結構
楽にメンテできそうなものとか って多分あるんですけど それを
切り出すサイズとかもちゃんと やって いろいろな工夫をすれば
ある程度 運用しやすいものって 作れるんですけど そこはまだ
切り出せるならまだいいんですよ 切り出しづらいものとか 切り出して
いいのとか わからないもの あとは ある程度 何年か授業が進んで
いくと コアの授業というか 結構 いろいろ授業は固まってくるんで
ドメインって分かりやすくなって くると思うんですけど 分かりやすく
なってきてはいるはずだけど やっぱり 半年半年と
半年半年経って システムの変わる ところもあれば 組織の構造も
開発組織だけじゃなくて ビジネス サイド側も変わることもあるんですよね
組織全体を見たときに いろんな ものが変わっていくと 半年半年
と時間が経っていくたびに 当初は こういうふうに分けるっていう
戦略でいけそうだったけど よく考えた アーキテクチャ全体を考えたら
これは今 まだ分けないほうがいい なとか そういうのは結構いろいろ
出てくるんですよね 先にシステム を分けるか 先に組織を分けるか
とか いろいろあるかもしれない ですけど 先に組織を分けると
結構大変でしたね いや 何でもないです でしたねというか
チームの分裂とチーム間の連携
分け合ってもらう 分けないけど 組織のチームの仕組みとか いろいろ
本当にそこのサイズ感をまず小さ くしたほうがうまく回るだろう
と思っても 結局横軸でいろんな 連携をしないといけないとか
お伺いを立てないといけないとか かなりそういうバッファが大ヘタ
に乗ってくると すごいめんどくさい ことになって システムを分け
れないし 組織もやっぱりもう1回 チームを考え直して編成しない
といけないし みたいなことって 結構あるなって
おだしょー いや これもう本当 嫌だもんだからさ このシステム
1個あったとして チームAとチーム Bに分けましょう そうすると
こいつらの責任でこっちとこっち をやるんだけど こっちに必要な
回収がこっちに必要ですってな ったときに こっちは多分あんま
やんないんです やる気ないんですよ だってそんなことやったって
評価されないからってなるのよ これ絶対なんのよ 腐るのよ 絶対
サイロ化すんのよ エンジニアの 誰かはやってあげなきゃって思う
かもしれないけど ディレクター からしてみたら 機能Bで我々は
評価されてるわけだから 無事に その優先度低くていいじゃんみたいな
話になるんですよ それこそ 害虫してるのか 俺たちみたいな
形になってくるんですね チケット 上げてくださいよみたいな そしたら
優先度決めてやりますよとかって 話になると チームAからしてみたら
もう何これみたいな 俺たちは 外部とやってんのかみたいな話
になるじゃないですか これもう マジでどうしようもなくて これ
仲良くしろよって話でしかないん ですけど
おだしょー そういう時はめっちゃ 強いですけど 分かりますね これ
分かれるじゃないですか AとBで これ綺麗に分かれたわけじゃないんですよ
きれいに分かれたわけじゃない こことここ AとBの間は問題があるけど
これもう1個あって AとBって分かれた けど これは人が分かれただけで
システムはここにあるけど システム も一部分かれたりとかあるけど
いろんなものが繋がってたりする じゃないですか API送ったりしたり
だとか アプリ用のAPI切ったりとか いろいろあると思うんですけど
ここに別のなんちゃらAPIとかあ ったらあれ これAの持ち物なのか
Bの持ち物なのか DBはみんなが使 っている 共有してるもの シングル
でDBが1個あるから DBはここでリードライト してて でもアプリはこっちで
これAの持ち物 Bの持ち物 誰の 持ち物でもないみたいなことは
不毛ですね 怯えに
そこで結構そういうものに対峙 したときは 草の音っていうか 本当
俺がやったるぜみたいな人がいない とうまく回らない でも 俺がやったる
ぜみたいな人ばっかりではない から 結局組織の課題になる
しばやん 野球でいうとレフトと センターの間にボールが転がって
て センターはこれはレフトだろう っつって レフトはこれはセンター
だろうっつって すげえ相手のバッター 走りまくってて ランニングホームラン
みたいな
おだしょー ガイアまで転がっちゃ って ガイアが拾うのが
しばやん おだしょー 早く拾えよ っつって ナイアシュが拾いに来る
みたいな
おだしょー すげえ生々しい話だな
しばやん 生々しいけどチーム分ける とこうなるのよ 絶対に人間の
本能というか これは意図的にシステム B いわゆる遅れて出てくる熟考
した思考とかを使って これは僕ら の範囲としては微妙かもしれない
が これを拾うことがチーム全体 を利益することになるんだ だから
仲良くやろうぜみたいな感じで いい子だね君たちはみたいな
おだしょー 2個2個みたいなそういう 開発をしていかないといけない
けど そんな余裕のあるやついかない じゃないんで
しばやん 誰のか分からないもの っていうのは 結局誰のものかって
決めればすぐ解決することじゃない かなって思わなくもないと思うん
ですけど これを決めることができないん ですよね 結局っていうのは 要は
泥に向き合っていると泥の中に 何が入っているか分からないんです
よね 何が入っているか分からなくて これとこれはどこの持ち物か分から
なくて 結局泥を1つ抱えるような ことになると こっちを持たなきゃ
いけないし これを持ったらスコープ が広すぎて何もできない俺たちは
みたいな感じになってしまうと やっぱりここは持てないとか そう
いうことが多々にして発生すると 大変です 大変だと思います
大平 じゃあ葬式 どっちから分け たらいいんだよっていう話になった
んですよ
しばやん 分ける分ける問題じゃない の ここで必要なのはスローガン
みたいな
大平 スローガンと対話だと思います ね
しばやん そうそう
大平 結局話すことが大事になって くるのかな
しばやん このときにチームの中に すごい熱いリーダーがいて おい
拾ってこうぜ みんなでつって
大平 はいはいはい 大事ですね 大事ですね
しばやん 分かるよつって センター 足疲れてるの分かる さっきもボール
拾ってたのは分かるけどつって そこは拾いに行こうぜとか
大平 スポコンが必要ですね
しばやん スポコンが やっぱりここは 立たせたら必要な
大平 そうです
しばやん そう これは理屈じゃない のよこれ
大平 泥臭いな
しばやん 泥臭い
大平 泥臭いですね
しばやん どう考えてもシステム の話をしてるようには聞こえない
んですけど
大平 確かに 確かに 全然システム の話じゃないですよね
しばやん そう だから必要なのは 根性です
大平 本当に
しばやん 本当ですよ マイクロ サービスがいろいろ進んで 一つの
チームでいろんなサービスを持って きれいに運用できるような状態
になったら それはそれでまた新しい 組織の問題とか 技術的な問題とか
いろいろ出てくるかもしれない んですけど われわれはまだ移行
していく段階 向かっていく段階 だから その形になってないんですよ
ある程度チームが分かれて ピザ が1枚を何個食えるぐらいのサイズ
でうまく分かれて システムをうまく 分散させて連携してできてる感じ
ではないから そのステップにいって れば別にある程度 もうちょっと
コミュニケーションのパスとか うまくなるかもしれないですけど
その前の前の段階の状態だと やっぱ 本当に対話は結構必要で われ
われたちはこういうものを作った から クライアント組み込んでくれ
とか われわれはこういうものを 作ったから これやっといてくれ
とかじゃなくて 本当にどっちの持ち物 だろうと歩み寄るような感じで
ものを進めていかないといけない シーンって結構タタにしてあって
そこがどっちかだけに主体性を持つ ような形になってしまうと 結構
物事がうまく進まない まだそういう ことが本当に分かれては チーム
も組織もチームもアーキテクチャ も分かれてはいても まだそういう
ことが完璧に分かれてうまく分散 してみんなが動ける状態に 満足
になってるわけではないけど 満足 になってるような感じで認識して
しまって 何かみんながそれぞれ 動くようになると大変です いろんな
ところに圧力が生じたりして なんか スポコンどころじゃなくなって
格闘技になりました
おだしょー 本当 本当 それをうまく 活かせるマネジメントとかを上の
人たちも考えたりするし 今日ちょうど ハイアウトプットマネジメント
って随分前の本だけど 読んだんですよ じゃらって読んでたら 面白かった
というのが 兼務いいよみたいな 話があって
おだしょー 兼務いいよ
おだしょー 俺は兼務大っ嫌い なんだけど
おだしょー ですよね
おだしょー 二重所属はいいよ みたいな話があって 要は組織Aと
組織B両方に入ってる人がいると 両方のコミュニケーションパス
持ってるから うまくいくことがある よみたいなことが書いてあって
マネジメントとしてあえてそういう 構造作るのもありだねみたいな
こと書いてあったから それは確かに 面白く考えたなと思ったり
しました 逆に言うと そんなことまで考えない
とうまくいかねえんだなっていう 感じ
おだしょー 結局取り持ってくれる すごい間のいいやつがいてくれない
とうまく回らないっていう証拠 なんだろうなと思って
おだしょー グルコサミン
おだしょー すぐ人のことグルコサミン とか言って
おだしょー グルコサミン
おだしょー 場合によってグルコサミン になる人がやっぱりきつい
おだしょー そうだね
おだしょー 橋渡しができる人は 大事ですね
ADRの導入と活用
おだしょー 大事ですよ 例えば上下 間とか横とかの間を取り持って
くれる人がいると とたんにコミュニケーション
が円滑になって物事がうまく進ん でいくみたいなことは間はある
おだしょー 間はあるんですけど これは面白い話で 橋渡しをする
人は結構リードのエンジニアとか そうしたら結構多いのかなと思
うんですけど マネージメントの エンジニアとかなんだけど 橋を
掛けるんですけど 掛けたつもり だけど掛かってなかったり 掛けて
るけど壊れちゃったりってこと って やっぱりコミュニケーション
の世界だとそういうことあるんですよ ね
おだしょー あるでしょうね あるある
橋渡し ネットワークの世界でも ありますけど 人のコミュニケーション
の世界でもそういうことがあって
おだしょー あると思う
橋渡し それはしんどいですね 大変です
おだしょー そうだ そういう役割 をやってくれる人にあまりに頼り
切ってると 疲れちゃったりする 人もいるので
橋渡し いますよね
おだしょー その辺は難しいですよね 当然
橋渡し でもそこが結構うまくちゃんと コミュニケーションをうまいこと
できるかどうかみたいな 適正という か能力というか そういう意味で
コミュニケーションも結構すごく 大事だと思いますね めっちゃ好き
なのですけど
おだしょー 好きなみだけど 大事なんだよね 本当に
おだしょー 長く仕事をやってると そういうことを思いますよね
橋渡し 技術力なんか別に何も解決しないなってよく思う
おだしょー 思うときある 何かちょっと話したらさ 解決することがあって
びっくりしますよね そんなことで 詰まってたんだったら言ってくれたら
いいのにみたいなこともあって その橋渡しをするだけで物事が
ガッと進むみたいな
おだしょー 人がボトルネックになってるんですよね
おだしょー 人もボトルネックになるし その人の中の思い込みとかも
ボトルネックになるし 恐れとか恐怖みたいなものも全然
満身も安心もボトルネックになるから 安定してるチームがいいかっていうと
そんなこともなくて 若干不安定なぐらいのほうが 多分うまく回ると思うし
おだしょー 結局人なの なんかやだな
橋渡し はい 一生我々は辛いというところですね
我々は辛いということが多分本質
おだしょー 本質なのか ちょっと嫌な結論だな
橋渡し 違うんですよ よく考えてください 辛くて大変だからお金がもらえる
おだしょー 金の話
おだしょー コミュニケーションももちろん大事だけどね
橋渡し でも楽しいですよ やっぱり
おだしょー 楽しいね
橋渡し そんなことももちろんいっぱい考えないといけないところありますけど
システムと組織 両方考えないといけなかったり
いろんなコミュニケーションだったり いろんなこと考えないといけないんで
本当に総合格闘技みたいな感じで いろんなことやらないといけないんで
めちゃくちゃ そういうのは結構難しいけど
大変だしめんどくさいこともあるけど 面白いですね
面白いと感じない人もいるかもしれないですけど
でももう全然読めないですよね
すごいみたいな 不安だったけど上手いことやってくれたわみたいな
全然ダメかと思ったら突然成長したねみたいなこと 全然あった
人ってやっぱ面白いですよね
おだしょー 人面白いなって思ってる
今竹内さんを見ながらそう思ってるっていうのがあって
あんな技術技術言ってた人がこうなるんだって思って
感動すら覚えてる
俺もBMFとこんなことを話すとは思ってなかった
すごくないですか
めっちゃプログラム書き大マンだったのが こんなこと言ってるからさ
そうですね でも本当は今の会社入ってからですね
人間的に強制されたのは
強制された
強制された
言い方が悪かった 成長しました
大事なものを得た気がします
成長感じる 素晴らしいな
素晴らしい
リアーキテクチャーのテクニックの話とかも
思うんだけど 富野コロさんが書いてる
ADRいいですか
どういいですか
ADRって名前がついてるからあれですけど ただの掲示板です
ただの掲示板
ご相談ごと簡単に書ける掲示板みたいな
どういうふうな運用にしてます
リアーキテクチャーの基礎をかなり忠実に
体現しました なんであそこに書かれている
項目とかを基本的には採用したし あそこで
僕が一番かんめい受けたのはGitはやめろって言われてたんですよ
リポジトリにGitでADRをマークラウンで突っ込む
っていうのはもうやめたほうがいいよって言われて なんでかっていうと
やっぱアクセスが悪いですよね
し 履歴読めるけど読まないじゃん
Gitの履歴なんか ウィキとかで
履歴は読むし ウィキだとやっぱコメントとかも入れられるんで
Confとか なんでそっちのほうが全然
体験はいいですね ADRの
ツール的にはどういうのを使ってますか
うちのコンフル
なんでもよかったんですけど うちはコンフル使ってるから
そこに連番で作ってもらってますね
設計困ってたらADR立てるみたいな流れに
今なってきてて 60を超えたんで
それすごい助かってます
やるほうは設計初めてみたいな人とか
設計に不安があるって言った人たちにとってはコメントがもらえるんで
良い体験になってるみたいで
それでいて 残るじゃないですか 消息が
これはやってよかったなって思うけど 今60まで増えてきて
これ100とか200とかに増えたら これウィキで見るんかいな
僕たちと思って ちょっとそれは不安になってる 流行ったはいいが
寝づいてる感ありますね
寝づいてる感はあるし ドキュメントとしてちゃんと残るんで
みんながレビューしているんで 内容はそれなりにいいですよね
僕はもっとスリム化するっていうか
項目を減らしてて 解決したい課題と
解決案だけ書いてるんですよ
それに対して これドックスでやってて
それに対してコメントをいくつか書いてもらって そのコメントに対して回答する
フォーマットの統一とドキュメント作成
みたいなやり方を今やり始めたばっかりで まだ全然手探りではあるんだけど
で ステータスを
下書き提案中 承認みたいな感じにして
ブラウザで簡単にアクセスできるの
で その解決したい課題に対して これは進める進めないみたいなことを決めて
やっていくみたいなやり方をやってるんだけど まだ本当
始めたばっかりで 真似事みたいな感じだけど
やってみるかっていう感じでやっている
でも やってみて馴染んだら馴染んだでいいし 馴染まなかったら うちには合わないんだなでいいと思うんですよね
まだ分かんないからね
設計で内容変わったところとかの更新ってどうしてるんですか
責任持ってやる人が拾ってるんですか
そうですね
第一 ADR書く人ってその設計が必要な人 つまり実装するチームなんで
自分たちのドキュメントになるんで
せっせと更新しますよね だってチーム内の共有ドキュメントとしても
使うはずなんで
コミットログとかでもURLを貼ったりするんで ADRに沿って
作りましたとか
コミットログにこれ出てるとラッキーですよね ADR見に行ったら
なんでこの機能が作られたかっていうのと どういう議論がされてたのかっていうのは全部見れるんで
そこに議論が載ってるんだな 一番知りたいのはそれじゃないですか
なんでこれやんねんみたいな話
そうかそうかそうか 確かに
そういう形で使ってんだな 勉強になった
でもこのADRも結局この大きな流れの中で
パッケージワイフィーチャーとか フィーチャートグルみたいなものを
うちの会社に導入していくには どういうコミュニケーションスタイルがいいかな
っていう一つとしてADRを使ってみた なんで関連してます
そう なんかその設計だったり
そういう機能を作るときに 何か残したいなと思って
そういえば最近ADRって聞いたなと思って
やり始めてみるか みたいな雰囲気で
やってはいるんだけど これがない場合はスラックを検索する
ということになりますね そうなんだよね 結局そうなるじゃないですか
その打ち合わせとかでも
話はしてるんだけど 州にまたがってたりして
先週 先々週 その前みたいな履歴を
追うのも大変だし それだったら1個の機能に対して
その1個のADRがあって それを全部乗ってるみたいな方が楽じゃないですか
で 議論のやり手も乗ってるし
そうなると 今の形は
いいのかなと思って ちょっとやってみてはいい
武井さんはそういう感じで ADRみたいな
テクニックみたいなのって 取り入れたりとかしてますか
一応 ADRは
新しいプロジェクトとかでは 採用検討したいなと思ってるんですけど
今のところはまだ手を付けてなくて
会社の他のチームとか やってたりするんですけど
うちだと コンフルとエサ両方使ってたりするんですけど
基本的には開発者は
エサの方にいろいろ書いてたりするんですけど
エサの方にいろいろ検討したこととか 技術検証したこととかっていうのを
都度まとめてアウトプットにして 必要なときに更新したりとか
っていうふうにやってますね なんで ADRみたいな
特定のフォーマット決めて 承認のフローみたいなものを
用意してやってはいないけど ある程度設計したものの
どういうふうに仮定決めてやったみたいなところを
必要にはしてはいますね そういうドキュメントベースで
他のチームに相談をしたりだとか アーキテクチャのレビュー
もらったりとかっていうふうに やったりしてますね
これはフォーマットをちゃんと作って
乗っかるのはすごい大事だと思っていて
人によってドキュメントを作るときの
流度感とか 書き方の
感じが結構違うんで 1人の人がずっと
やってるとその流度で 大体同じような感じの
ドキュメントが上がるけど これを3人4人でやってバラバラに
作ると結構違ったりするんで ドキュメントもらったときに
レビューして ここも書いてとか ここ足りないとか
っていうやり取りとか結構発生しちゃうんで そういう意味でも
フォーマットをちゃんと決めて どういう感じで書くかっていうことを
大事だと思うし あと人が入ってきたときとか
プロジェクト進む度にそういうものの価値が結構出るなと思っているんで
取り入れたいなっていうふうには思ってますね
そうですね 確かにドキュメントの流度が違うと
結構きついものはあるかもしれないですね
みんなまちまちだからね
パーソナルスペースとかになると困るじゃんみたいな
意外と個人メモみたいなディレクトを見ると
これ知りたかったことがあるみたいな
これを交代しといてくれみたいなの結構あるんですよね
それスラック検索するのとあんまり変わらないつらみみたいな
ストックされてるからまだいいんですけど
それはまだ残されてるからまだいいですよね
ただフォーマット揃えるっていうのは
確かに手というか横断的に見れるっていう面ではいいかもですよね
あとちょっと太字で書いてあるのが気になったんだけど
インセプションデッキってなんだっけ
インセプションデッキの活用
インセプションデッキ これアジャイルサムライに確か出てきてる話だと思うんですけど
インセプションデッキっていうものをプロジェクト始めるときに作っていて
これ何書いてるかっていうと
このプロジェクトは何ですか 何を目的にやるんですか
どういうところにリスクがあるんですかとか
何を優先するプロジェクトなんですかみたいなことを
簡単なスライドにして文章をちゃんと 言葉もちゃんと洗練させて書くみたいなことをやってるんですよね
これやると何が嬉しいかっていうと
何のためにやってるかっていうと
チームのメンバー間で共通の認識を持たせるためですね
設計するときの方針だったりとかプロジェクトの進め方だったりとかっていうときに
みんなが考えてる 価値観とまでは言わないですけど
考えてる方針だとか
フィーチャートグルの利用方法と影響範囲の調査
そういうズレをなくしてプロジェクトを円滑に進めるため
あるいはプロジェクトを進めていく上で
ビジネス的なことでも技術的なことでも
何か迷ったときの判断指針になるようなものを作って運用してるって感じですね
あとはこれチーム内だけじゃなくて
対外的なところでもチームの外とか社内向けのドキュメントとしても結構いい感じのもので
チームの外とか社内で何か伝えるときに分かりやすい1枚の資料というか
スライドとして結構いいものだったりしますね
これ読んだら大体このプロジェクトの概要というか
雰囲気というか掴めますよみたいなものだったりしますね
新規プロダクトとかサービス作るときとかにも使ったりするやつですね
急に思い出したこれ何だったかなと思って
そういうやつだな
あとは富所さんも竹内さんもフィーチャートグループはやっていると
ビッグバンリリースしないためかな
今リアーキテクチャリングからちょっと離れてて
プロジェクト持っちゃってるんで機能開発ちょっとしてるんですけど
そうなんですね
めちゃめちゃフィーチャートグル使ってますね
バンバンマスターにマージしまくってるんで
めちゃくちゃいいですよ
みんな真似してねって言いながら
ビッグバンマージを防ぎたいなと思って
これ仕組みかツールかなんか使ってます?
すごい単純なもんですか?
内製しました
うちはちょっと都合上ツールがちょっと使えなかったんです
要件が満たせないみたいな問題があったんで
内製ツールを作って
結局やることは一部分なんですけど
それ実際にいざリリースってなったらどういう風にやるんですか?
僕よく分かってないんですけどフィーチャートグル
要はグローバルif文みたいな
それをオンにするためにはどういう動きをさせるんですか?
データベースのとあるデータをソースを更新して
それが1になったらそのトグルがオンになって
そっち側にソースコードが流れるようになるっていう
そういう流れになる
そういう感じ
だからこれもなるべく楽できるように
DIの結節線とかで使えば
一箇所変えれば全部ちゃんと挙動が変わるとかっていう風にするのか
それともいろんなとこにif文をバーって巻くのかみたいなのは
チームごとのやり方によるんだとか
うちも単純に塩分作ってそれを切り替えるだけにしてますね
だから必要な箇所だけif文を入れて
そこで塩分変えたら切り替わるみたいな感じにしてます
あんまり複雑なものを入れてないですね
なんかif文たくさん巻き散らかすようなイメージがあって
なんでいろいろそれもADRでルール化されてる
そうなんですね
やっぱ影響の大きいfeatureトグルはそうなりがちになるのかなと思って
だからそのfeatureトグルのif文を書く場所に
コメントのルールが決まっているので
要はグリップすれば全部一発で
なるほど
そういうルールが決まってます
何も考えずにすごいでかい関数の一部だけに
こういう細かいものいっぱい差し込むみたいなことすると爆発するんで
結構大きな単位で切り替えられるようにするっていうのを
ちゃんと影響範囲とかも結構調査してやってますね
リアーキテクチャの話とサイドストーリー
基本的には
とはいえまだそんなに馴染んでない感じ
実装サンプルをこないだ置いたんですよ
こんな感じで使ってねとかってやって
これからどれくらい普及するかなみたいなのを見たいな
すごいリアーキテクチャの話だけで1時間経ってしまった
大丈夫真面目すぎるよ大丈夫
もうちょっとたくさん書いてもらってたんで
ほっこりする話
サイドストーリーも話したかったのに全然時間足らなかった
真面目に話しすぎましたね
ちょっと次回で撮っておきましょうかもったいないな
いやちょっと次回は鮮度が落ちてる
落ちてるかなまた別の話したらいいじゃん
そうそう新しいなんかいいのが
そうだね今日はもうめっちゃ時間経ったんでこのあたりにしましょうかね
はい
では第56回はこの辺で締めさせてもらおうと思います
最後にもう一度XQツイッターのハッシュタグについてお知らせです
ハッシュタグはカタカナでつなぎめFMです
投稿お待ちしています
はいということで今回のつなぎめFM第56回は
富所さんと竹内さんをお迎えしてお話しさせてもらいました
お二人とも今日はどうもありがとうございました
ありがとうございました
ありがとうございました
