そう、偶然じゃないけど、2人とも最近そんなことを言ってたなと思って。
ちょうどいい。
前々から知ってはいましたね。
同じような言葉を使ってるなって。
そうなんだ。
遠目には見てました。
富野子さんがリアーキテクチャーの話をよく知ってるのは知ってて、
知ってるなと思ったけど、竹内さんの会社の記事が出てるじゃないですか。
あれを見て、すげえ似たことやってると思って。
そうそう。
で、じゃあ実際リアーキテクチャーって何?っていうのとか、
どういうタイミングでそれをやるべきタイミングになるのかとか、
どうやっていくのかとか、そのあたりが聞けるといいなって思ってるんですけど、
そのあたり、まず先輩から聞こうか。
え、先輩からの?
先輩から聞こうか。
これ会社でメインの仕事なんですかね?
これ会社でメインの仕事です。
そもそも入社するときがもう辛いんで、助けてくださいみたいな感じだったので。
もうそういうことをやってねっていう状態で入ったんですね。
そうなんだ。
最初入ったとき、今はCTオフィスって場所にいるけど、
最初もアーキテクチャーグループみたいなところに入ってきましたね。
そもそもそういうことやってねって言われてて、
そういうの興味あるんでっていうので入りましたね。
あとはそのまんまっすね。
そのまんまっていうのは?
いや、その役割のまんま。
ずっとそういうことをやってる。
就労しておりますね。
だけど会社っていうのは、こういう遊びのある舞台っていうのは許せないんだよね、きっとね。
すぐいろんな役割がある。
あっちで人が足りないとか、こっちで人が足りないとか。
あっちの橋が落ちたとか。
あっちのビルが壊れてるとか。
あっちで水を求めている人がいるとか。
リアーキテクチャーっていうと、
一チームの局所的な話ではなくて、
結構全体を見て横断的に考えなきゃいけないところとかあるはずじゃないですか。
そういうところをどうやってやってるんだろうなーとか、
そのあたりなんか話ありますか?
いやー、だから、
もうモノリスで、お金も儲かっててってなると、
チームもいっぱいあってパラで動いてるんですよ。
ってなってくると、
要は無停止で直すっていうのがめちゃくちゃむずいんですよ。
直す対象が毎日何がしかの回収が入っていくから。
そもそも計画できないみたいなところがあって、
じゃあそれをどう直しますか?みたいな。
そうはいつ、それをどういう風に良い流れに持ってきますか?
みたいなのをこの2年半くらいはずっと考えてきてて、
ある程度一定の位置が今見えて、
その方向に今邁進してるって感じです。
それが今回ネタ調にはいっぱい書いてます。
HRの話だったり、HRトークルの話だったり、
今そういうツール類というか、
やり方みたいなものを未来に何とかするために、
今の夢の島にはもうこれ横目は捨てないでねみたいな話になって、
こちらの別館の方によろしくお願いしますみたいな感じで。
わかりやすく話すとそんな感じですよ。
夢の島の改善をこれからしていくんだけど、
じゃあその中で何を一番メインの回収ポイントに持ってくるか、
みたいなところがまた新しい決断のポイントになって、
これもあんまり闇雲にはやりたくないので、
これをメトリクスとかを合わせていきたい。
なるべく数字で分かれる形でやっていきたいっていうのが
僕の思いではあって、
そこに出てくるのが福岡のペチコンで言ってたけど、
GQMっていって目的指向のアーキテクチャーというか、
ゴール設定みたいなメトリクスの収集みたいな話があって、
それとあと最近だとリンとデブオープスの科学の書かれた博士の人が
ちょっと前に日本向けに登壇されてたんですけど、
そこでも紹介されてたんですけど、
ドーラとかスペースとかっていう話があって、
それもメトリクスの取り方とか、
どういうふうにキーメトリクスを決めていくかみたいな話になる。
どういう目的に対してみたいなところを
両方ともすごい大事にしてるので、
そのメトリクスをいかに収集して、
それがどういうふうに会社のミッションとかに合うのかと。
あとはカスタマーサクセスにおいて一番主要となるキーメトリクスは何かとか。
そのシステム改善だけじゃなくて、
今のシステム開発上で
自分たちを一番抑え込んでやってるボトルネックの支払いは一体何なんだろうみたいなところ。
それは多分リファクタリングだけの話じゃなくて、
デプロイメントの話とかCIとかビルドの話もあれば、
開発のやり方とか、
あとはオンボーディングみたいな話もあるじゃないですか。
それぞれのチームがどういう戦略を立てるのかとか、
どういうチーム構成してるのかとかっていうのまで含めて、
全体的にどういうふうにしたら
うまいこと僕たちはやっていけるのか。
みたいなことをすごい大きく大きく考えていくところですかね。
なんで、いつになくつなぎめFMで真面目なことを話していますが。
本当ですね。
こんなふざけてない。
こんなにふざけてない僕は多分。
珍しいですよ。
珍しいですけど、
本当にやってることはそれで、
最近はその取り組みの一つとして、
CT用質頼りみたいなものを強く作ろうと思っていて、
それはドラとかスペースみたいな、GQMみたいなところから、
目的指向でメトリックス収集をするときの、
収集したデータっていうのを月次で発表していって、
みんなに注意喚起とかをしながら、
自分たちもこういう改善をしていくんだよ。
これは多分開発者にも向けるし、
経営人にも向けるし、
フロントエンドじゃない意味でのフロントの人たちね。
営業の人だったりとか、カスタムサクセスとか、
その辺の人たちにも向けて使えるデータとか、
そういったものっていうのを用意できると、
いいなとは思ってる。
そういったことをすごい詳しくやってますね。
リアーキテクチャーをしようぜってなったときに、
じゃあどこから手をつけるのかってなったときの、
どこからっていう根拠みたいなのが必要じゃないですか。
でもそれがちょっとフワッとしてるんで、
そういうときに指標とかがもちろんあったほうがいいなと思うんだけど、
その指標じゃあどう数値化するのっていうのが非常に難しくて、
やんなきゃいけないのはフワッと分かるんだけど、
説得材料を自分の中に持ってなくてですね、
改善はしたいんだけど、
どう手をつけていいものかみたいなのって、
それぞれの現場でもあると思うんですよね。
そこに根拠をどう持たせるかって考えてもらえるんですか。
根拠ってもう考えちゃダメだと思ってて、
うちの会社結構スクラムマスター研修とか受けた人たちが多いんですけど、
その彼らのノートの中にすごい発動することが書いてあって、
現場が改善したいって言ったときに、
すごいトップダウンな言い方になっちゃうけど、
上から方針がある程度来て、
そこでそういう課題をもらって、
そこでそういう課題をもらって、
実際、
運用上どういう課題があるかとか、
実際、運用上どういう課題があるかとか、
ビジネスサイドでこういうことしたいとか、
ビジネスサイドでこういうことしたいとか、
機器の用件とかいろいろあるんですけど、
そういうものを全部洗ったりして、
別のサービスとして、
基本的には、
コアのモノリスのほうから、
一つのサービス、
切り出していくっていう形で、
やってますね。
なので、
課題を見つけて、
そこの何でそれをやるのか、
何解決したいのか、
みたいなところから全てを洗っていって、
いろんな設計をして、
泥臭くものを進めていく、
ような感じですね。
だから、
雑に具体的に、
どういう業務をやっているのか、
というと、
いわゆる他のシステムに、
使われたりするような、
システムが使うようなシステム、
みたいなものとかを、
作ってたりする、
システム基盤みたいなものを、
開発している、
っていうのは結構特徴的かな、
できるべきかなと思いますね
おだしょー 他のチームが開発で 使うものとか そういう感じですか
りなたむ 他のチームが呼び出す ようなAPIだったり 機能だったり
いったいのを作っていくような チームですね 認証だったり まだ
やってない これからやるんですけど 通知の仕組みだったりとかっていう
ものを提供しているようなチーム ですね
おだしょー なるほど このメモに 書いてくれてる リファクタリング
ではないっていうところは そうですね リアーキテクティング
であって リファクタリングではなくて 富所さんも上のほうに構造の話を
書いてるんですけど もしかしたら 近いかもしれないんですけど もちろん
リアーキテクティングする対象 が決まって 何かシステムを設計
して作っていくってなったとき の段階で まず一旦こっちを直して
から 新しく構造として切り出そう みたいなことはするんで その過程
の中でリファクターするんですけど 別にリファクタリングすること
自体が目的のチームではないので ただ何かをアップデートするだ
とか ただ切り出すだけとかっていう わけではなくて もうちょっと大きな
仕組みとかを作って解決していく っていうところのほうが近いチーム
ではありますね
いや 会社 違うと やっぱ 何だろう やる内容も変わってきますよね
今の泥団子の状態によって取れる 手段が変わってくるんで
うん 当然 やることは変わってきますけど でもリアーキテクチャー 難しくないですか
こんなもんあれですよ トライアンド エラーですよ
それしかないんですかね
そうですね 泥団子ってあんまり 言いたくはないですけど 泥団子
から 泥団子を崩すんですよね 基本的には 基本的には崩すんですよ
でも崩し方 分け方は結構いろいろ あるというか 考えないといけない
ことは結構あるんですよね 実際 どういうふうに 基本的にはデータが
一番大事ですけど データどういう ふうに切り出すとか あるんですけど
変な崩し方をして分けたりすると 結局 その大きな泥団子からもう一個
別の泥団子ができちゃうっていう
そこはなんだよな それをどう作らない
分けるんだけど 分けたらそこは 金の泥団子みたいな
金の泥団子は護衛があるかもしれない けど うまく分けないといけない
固い泥団子にはしたいよね 攻めて
そうですね 崩れないツルツルした やつ
ツルツルして引っ掛ける場所が1個 しかないみたいな
泥団子を再構築したいわけではないん だが
でも取り得るべき手段はたくさん あるんだけど みたいなところかな
僕も会社入ったときはマイクロ サービスみたいな話がものすごい
いっぱいあって これはまずいと思 って すぐ取り掛かったのはマイクロ
サービスっていう言葉をぶつぶす ところから
待って 待って 待って 待って って
君たちモノリスちゃんと作れないん だよねって言って
分散システム無理よって言って 無理 無理って言って
身の程を知ろうぜ みたいな感じ
分かります 胃が痛くなるところ はありますね
胃を痛めても問題ないぐらい グループ の構成とかもちゃんと考えてる
のがいいし 切り出したマイクロサービス 側のグループがちゃんとコミュニケーション
取ってくれるんだったら それでも かまわないって感じ
マイクロサービスとか モノリス もそうなんですけど 結局のところ
チーム同士がきちんとコミュニケーション 取れてないことで 共通化とかが
促進されずに 結局泥団子っていうか カオスなスクリプティングが生まれて
いくと思っていて じゃあコミュニケーション が問題だったんだとしたら 分けたら
もっとひどくなると思っていて 対話するから そこが対話で解決
できてないのに ソースコードだけ 分けて遠方から殴り合うんですか
君たちみたいな 今リモート全盛 だからはかどりそうだねみたいな
話になっちゃうんで そういうの だけはやめたいっていうのは
すごい思ってる
そうですね
いや でもすげえむずい もうずっと 転がってたから 分かんねえつって
どうしようこれつって
いろんな人にずっと相談してました どうしようか
みたいな話になるじゃないですか 違う 反省しないじゃんみたいな
ところから始めなきゃいけない
耳にしみる言葉ですね
そうそう
誰が聞いてるか分かんないんで あんまり強い言葉は言えないんですけど
僕は
いや こういう話すると みんな会社 の人に聞かれて大丈夫ですか
とか 福岡の発表もしたやつも これ 会社の人に見られて大丈夫ですか
って言って 一点の曇りもなく 大丈夫ですってずっと答えて
本当でもあれなんですよね 汎用的 というか 切り出しやすいものって
あるんですよね 切り出しやすい ものとか 切り出したほうが結構
楽にメンテできそうなものとか って多分あるんですけど それを
切り出すサイズとかもちゃんと やって いろいろな工夫をすれば
ある程度 運用しやすいものって 作れるんですけど そこはまだ
切り出せるならまだいいんですよ 切り出しづらいものとか 切り出して
いいのとか わからないもの あとは ある程度 何年か授業が進んで
いくと コアの授業というか 結構 いろいろ授業は固まってくるんで
ドメインって分かりやすくなって くると思うんですけど 分かりやすく
なってきてはいるはずだけど やっぱり 半年半年と
半年半年経って システムの変わる ところもあれば 組織の構造も
開発組織だけじゃなくて ビジネス サイド側も変わることもあるんですよね
組織全体を見たときに いろんな ものが変わっていくと 半年半年
と時間が経っていくたびに 当初は こういうふうに分けるっていう
戦略でいけそうだったけど よく考えた アーキテクチャ全体を考えたら
これは今 まだ分けないほうがいい なとか そういうのは結構いろいろ
出てくるんですよね 先にシステム を分けるか 先に組織を分けるか
とか いろいろあるかもしれない ですけど 先に組織を分けると
結構大変でしたね いや 何でもないです でしたねというか
分け合ってもらう 分けないけど 組織のチームの仕組みとか いろいろ
本当にそこのサイズ感をまず小さ くしたほうがうまく回るだろう
と思っても 結局横軸でいろんな 連携をしないといけないとか
お伺いを立てないといけないとか かなりそういうバッファが大ヘタ
に乗ってくると すごいめんどくさい ことになって システムを分け
れないし 組織もやっぱりもう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両方に入ってる人がいると 両方のコミュニケーションパス
持ってるから うまくいくことがある よみたいなことが書いてあって
マネジメントとしてあえてそういう 構造作るのもありだねみたいな
こと書いてあったから それは確かに 面白く考えたなと思ったり
しました 逆に言うと そんなことまで考えない
とうまくいかねえんだなっていう 感じ
おだしょー 結局取り持ってくれる すごい間のいいやつがいてくれない
とうまく回らないっていう証拠 なんだろうなと思って
おだしょー グルコサミン
おだしょー すぐ人のことグルコサミン とか言って
おだしょー グルコサミン
おだしょー 場合によってグルコサミン になる人がやっぱりきつい
おだしょー そうだね
おだしょー 橋渡しができる人は 大事ですね
おだしょー 大事ですよ 例えば上下 間とか横とかの間を取り持って
くれる人がいると とたんにコミュニケーション
が円滑になって物事がうまく進ん でいくみたいなことは間はある
おだしょー 間はあるんですけど これは面白い話で 橋渡しをする
人は結構リードのエンジニアとか そうしたら結構多いのかなと思
うんですけど マネージメントの エンジニアとかなんだけど 橋を
掛けるんですけど 掛けたつもり だけど掛かってなかったり 掛けて
るけど壊れちゃったりってこと って やっぱりコミュニケーション
の世界だとそういうことあるんですよ ね
おだしょー あるでしょうね あるある
橋渡し ネットワークの世界でも ありますけど 人のコミュニケーション
の世界でもそういうことがあって
おだしょー あると思う
橋渡し それはしんどいですね 大変です
おだしょー そうだ そういう役割 をやってくれる人にあまりに頼り
切ってると 疲れちゃったりする 人もいるので
橋渡し いますよね
おだしょー その辺は難しいですよね 当然
橋渡し でもそこが結構うまくちゃんと コミュニケーションをうまいこと
できるかどうかみたいな 適正という か能力というか そういう意味で
コミュニケーションも結構すごく 大事だと思いますね めっちゃ好き
なのですけど
おだしょー 好きなみだけど 大事なんだよね 本当に
おだしょー 長く仕事をやってると そういうことを思いますよね
橋渡し 技術力なんか別に何も解決しないなってよく思う
おだしょー 思うときある 何かちょっと話したらさ 解決することがあって
びっくりしますよね そんなことで 詰まってたんだったら言ってくれたら
いいのにみたいなこともあって その橋渡しをするだけで物事が
ガッと進むみたいな
おだしょー 人がボトルネックになってるんですよね
おだしょー 人もボトルネックになるし その人の中の思い込みとかも
ボトルネックになるし 恐れとか恐怖みたいなものも全然
満身も安心もボトルネックになるから 安定してるチームがいいかっていうと
そんなこともなくて 若干不安定なぐらいのほうが 多分うまく回ると思うし
おだしょー 結局人なの なんかやだな
橋渡し はい 一生我々は辛いというところですね
我々は辛いということが多分本質
おだしょー 本質なのか ちょっと嫌な結論だな
橋渡し 違うんですよ よく考えてください 辛くて大変だからお金がもらえる
おだしょー 金の話
おだしょー コミュニケーションももちろん大事だけどね
橋渡し でも楽しいですよ やっぱり
おだしょー 楽しいね
橋渡し そんなことももちろんいっぱい考えないといけないところありますけど
システムと組織 両方考えないといけなかったり
いろんなコミュニケーションだったり いろんなこと考えないといけないんで
本当に総合格闘技みたいな感じで いろんなことやらないといけないんで
めちゃくちゃ そういうのは結構難しいけど
大変だしめんどくさいこともあるけど 面白いですね
面白いと感じない人もいるかもしれないですけど
でももう全然読めないですよね
すごいみたいな 不安だったけど上手いことやってくれたわみたいな
全然ダメかと思ったら突然成長したねみたいなこと 全然あった
人ってやっぱ面白いですよね
おだしょー 人面白いなって思ってる
今竹内さんを見ながらそう思ってるっていうのがあって
あんな技術技術言ってた人がこうなるんだって思って
感動すら覚えてる
俺も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人でやってバラバラに
作ると結構違ったりするんで ドキュメントもらったときに
レビューして ここも書いてとか ここ足りないとか
っていうやり取りとか結構発生しちゃうんで そういう意味でも
フォーマットをちゃんと決めて どういう感じで書くかっていうことを
大事だと思うし あと人が入ってきたときとか
プロジェクト進む度にそういうものの価値が結構出るなと思っているんで
取り入れたいなっていうふうには思ってますね
そうですね 確かにドキュメントの流度が違うと
結構きついものはあるかもしれないですね
みんなまちまちだからね
パーソナルスペースとかになると困るじゃんみたいな
意外と個人メモみたいなディレクトを見ると
これ知りたかったことがあるみたいな
これを交代しといてくれみたいなの結構あるんですよね
それスラック検索するのとあんまり変わらないつらみみたいな
ストックされてるからまだいいんですけど
それはまだ残されてるからまだいいですよね
ただフォーマット揃えるっていうのは
確かに手というか横断的に見れるっていう面ではいいかもですよね
あとちょっと太字で書いてあるのが気になったんだけど
インセプションデッキってなんだっけ