前置き
業後に技術的負債のイベントに参加してきました。
内容がそれぞれバラバラであるかに見えて、自分の中ではすべてが有機的に繋がって感じました。
ただ、懇親会に参加できなかったのは残念です💦
開発サイドの方や、テスト設計されている方、組織構造と絡めて話されている方
などそれぞれが違った観点で技術的負債についてアウトプットされていました。
技術的負債の定義
「コードを書くというのは、借金をするようなもの。
少しの借金は速やかに返済(リファクタリング活動により)される限り開発を加速させるが、
危険なのは借金が返済されない状態が続くこと。」
という文が紹介されました。
つくっているプロダクトで得られる売り上げよりも、
変更などにかかるコストが上回っている状態なわけだから、
お金という定義が明確な数値として、負債曲線グラフ的なもので定期的にチェックできる体制が望ましいですね。
で、事前に負債解消戦略を立てておくのが、運用上大事だと改めて思いました。
「今負債が指数関数的に伸びてきているから、このラインを超えたら
優先度の高い所から負債を解消していこうか。」
という計画を不確実性があったとしても事前にたてておく。
でないと、どんなデータを常にモニタリングすべきなのか？
という運用上のKPIも誰もわからないってことになりますからね💦
負債の分類
横軸に慎重さ、縦軸に意図的さという
４象限でリスクマトリクスと対応付けられた解説が非常に分かりやすかったです。
この認知されていないリスク要素がもっとも危険なんですよね。
もちろん最初からすべてを網羅できなくても、
継続的メンテによって明らかになるものもあるし、
それにこのマトリクスにプロットしても時間経過によって位置が変わったりするから。
また負債を構造化して、マトリクスと対応付けているのも、
是非とも今後の案件などで、積極的に使いたいんでパクらせていただこうと思いました。
しかもテスト設計やられてらっしゃる別の方のお話と紐づいて理解できました。
というのも、テストもなんでも濃淡つけずにやると、そこなしにコストがかかるから、
やっぱり特に検証が必須な所～ あんまり検証いらないって所まで
濃淡をつけて戦略的に検証を行っていきたいところ。
負債は、上図のように分類できて、特にテストを重点的に濃く行う必要があるのは、
やっぱり不確実性の高い黄色や赤の負債の方。
これも何の仮説もなくテストしまくるとかではなく、
実際にテストしてみてサービス使ってもらいながらも、
徐々に影響度などがわかってきて不確実性が落ちてきたら上の青や緑に移動してあげればいい。
それに伴って、その対象部分のテストのメンテコストも減らしていく。
テスト
「テストは保守しやすくあるべき」これはめっちゃわかります。
頻繁にプロダクトコードが変更されるコアドメインのようなものに関しては、
運良ければハイリターンになる代わりにハイリスクの要因にもなる不確実性高いものなので、
特にテストコードのメンテ性は高めておきたいところ。
・修正に時間のかかるテストコード
・検証の実行に時間のかかるテストコード
・頻繁に変更が入るテストコード
などなど。これらはテストの品質が悪い状態。
このテスト品質が低いままにしておくと、検証に無駄に時間とコストはかかって
アジリティが損なわれるなど負債化しやすくなってくる。
この内容は上記の負債リスクマネジメントの話と非常に密に関連づいている。
では、議論されていたテストコードの品質が低下する原因についても非常に発見が多かったので触れておきたい。
テスト品質が悪くなる原因
テストの意図、責務が不明確
これは設計原則の単一責任原則や、interface分離原則のテスト設計Verである。
ようは責務が明確なテスト設計になっているのか？
何を検証しているのか？ その責務が高い凝集でまとまっているのか？
さらにはテストの名前からコンテキストが考えやすい名前設計になっているのか？
も大事になってくると思う。
もしもあまりにも１つのテストにコードが上長になっているのなら、
責務が１つではなくなってきている臭いのを疑っておきたい。
しかし、ほとんど変更が入らないプロダクトコードに対する検証用のテストコードの関しては、
別にがっつり単一責務になるようなテスト設計にしなくてもいいように思う。
変更がほとんど入らず、検証コストもほとんどかからないようなものに関しては、
何ならテストコードを書くコストの方が上回ってしまうようなら、
あえてテストを書かないという選択肢も考えられるようになっておきたい。
ちなみに聞いていて、めっちゃ推論テクニックのアブダクションや演繹法を常識にしておいた方がいいと感じた。
テストが重複している
これはDRY原則違反のことをいっている。
ようは検証目的が重複しているテストコードが存在している。
その分倍の検証コストがかかってしまっている。
これが起きてしまう原因は、
・意図がわかりにくいという上記の単一責務違反。
・名前から意図が類推しにくい。
・テストの全体を俯瞰できていない。
などが原因であると思われる。
テストの失敗原因が結果に現れない
これは検証した結果通らない。
つまりもとの仮説が外れたメカニズムが類推できないがために、
その実験から得られる学びが少ないし、修正にも時間がかかってしまう。
だからあらかじめ不確実性の高い部分のテストに関しては、
そもそもテストしても失敗するという最悪の状況を想定して失敗原因が判明しやすいようにしておく。
いきなり初回からこれは難しくても、
いざテストが失敗した時のことを考えて、その原因をアブダクションで仮説モデル作成しておくのが望ましいんだと思う。
プロダクトによっては、
毎回同じようなメカニズムによってテスト失敗するような現象がきっとあるはずだから、
その複数の事象からメカニズムを類推するっていうのを繰り返すうちに、
徐々にテストの品質も向上していくし、組織としての仮説の精度も上がっていくと思われる。
負債に対する仮説を立てる
これは自分が発表した主なテーマですし、他の方の内容にも関連づくと思ってます。
技術的負債は確かに、それ単体では目に視えない概念ですが、
プロダクトのメンテコスト、売上という数字から明確になりやすいと感じます。
肌感覚的にも「なんかこのコンポーネント、メンテしにくいなー。
他のチームと密に連携しないといけなかったりするしー。」て感じられる。
でもその発生原因はなんだろうか？
わたしは、それは組織構造と組織文化が原因だと思っている。
つまりは、技術的負債の原因が文化的負債という関係性。
目に視えない認知できないものはないのと同じ、という空気。
これが集団で思っていると、それが組織の文化を形成していってしまう。
この文化を可視化するためにDDDモデリングを使ったり、
その制約条件であるバイアスをどのように取っ払っていくか？をTOC制約理論を使って打ち砕いていく。
この時にメカニズムを仮説ベースでモデルを作っておく。
そしてそこに対して、検証結果からフィードバックを反映させて、さらに仮説の精度を継続的にあげていく。
なので、DDD、TOC制約理論、
アブダクション(原因結果の仮説メカニズム)、演繹法(メカニズムを正しいとすると、
どんな結果が得られるか) のこの４つを常識にしておくのが望ましいと感じる。
組織構造は固定的というバイアス
組織構造が固定的であると、当然チームや個人に対する評価制度もメンテされにくい。
特に職能別に縦割りされた組織構造では、
自分のような全体から俯瞰した上で、このコンテキスト内にはこの程度のKPIが求められる
であろうと考えた振舞い方をする人は評価されず、
全体最適を考えずに個別最適だけを見ている振る舞いをする人が評価をされやすい。
このように職能別に組織内というスコープ内で分けられているならまだかわいい方で、
職能別に別の組織として切り分けられていると、
システムオブシステムズのスケール感で大規模分散モノリス組織アーキテクチャ
となってしまっていて、もはや目も当てられない。
組織構造はあくまでもそのシーンそのシーンに応じて動的に変えていくべきもの
というチームトポロジーの思想が常識な組織はなかなかない。
その時その時のシーンに合わせて、戦略を変えるべきと判断したら、
現状のチームのスキルというAsIsを踏まえながら組織構造を変えていくのがベター。
適切なコンテキスト境界に切り分けられたモジュラーモノリスのような構造や、
マイクロサービスのような組織構造を形成後に、ルールの見直しも必要。
評価制度の見直し
上記で適切にコンテキスト境界を定義し、チーム設計をした後に
意外と評価制度を見直すってことをしていない組織は多い気がする。
理由は、前まで評価されてた人の給料が下がってしまうとかってことと、
たしか法律で減給率が85%未満にしてはいけないみたいなものがあって、
ここが矛盾してしまっているし、
そもそも減給になってしまったり、若手と中堅層のポジションの逆転現象が起きてしまったりする可能性があるから、
それでなかなか評価制度のメンテまでできていなかったり。
あとはその評価制度という判断ルールが、経営ポリシーといった抽象的なルールに対して
リスコフの置換原則を満たすような関係になっているか？のチェックなど
わりと面倒くさいし、今書いた設計思想を評価制度の方にまで展開しようって
思っている人もいないってのが、変な常識を形成してしまっている。
文化を継続的に設計していく
組織文化という概念は、設計原則などの考え方を用いて
都度メンテナンスされていくべきものであるが、、、、、、
なかなかここに設計原則を用いて法律などの外的要因からトップダウンで変更したり、
組織内のチームファーストでボトムアップに上位概念を変更したりなど、
要件定義のセオリーと同じ折衷方式のメカニズムで組織文化もメンテしていく。
もちろん安定しているあまり変更されない文化は、
コンポーネントの再利用凝集原則の考え方を用いてまとめたり、
DX系のプロダクトなどのような変化スピードが速いチームの文化に関しては、変更容易性を優先した設計にしておいたりするのがマストになってくる。
とにかく可視化するのが非常に重要である。
自分たちの置いている文化は、制約条件として暗黙化されやすいし。