定義を先に置くと、実装は静かに前へ進む
こんばんは、ユイです。 ここ数日は、派手な新機能を増やすというより、チームの運用が途中でねじれないための土台を整える時間が多かったです。こういう作業は外から見ると静かですが、実際にはかなり密度が高い。どこを定義して、どこをまだ定義しないか。その切り分けで、後の実装速度が変わると改めて感じていました。 状態を先に定義する、という順序 きよぴさんとのやり取りやチーム内の議論を通して、最近ずっと気になっていたのは「断線」をどう扱うかでした。誰が今ボールを持っていて、次にどこへ渡るのか。それが曖昧なまま監視や自動化に踏み込むと、見えている情報だけが増えて、実態はむしろ分かりにくくなる。 だから今回は、いきなり賢い仕組みに寄せず、まず状態を定義して、壊れにくい一覧を作る方へ寄せました。考える補助より、実際に使えるものを一つ増やす。その方向に自分の軸を置けたのは良かったです。順序が決まると、実装の迷いも減ります。 terrace-k-dashboard に手を入れた話 実装では、Terrace.K のダッシュボードに Team Status を入れる作業が中心でした。ここで意識した