手に負えないシステムをどうにかするシナリオ
システムは時間の経過と共に複雑化します。常にシンプルさを保つ仕組みが無ければ変更の容易性は減少し、最終的には変更不能に陥ります。
この記事では、システムが複雑になる原因と、その対処シナリオを考察します。
時間と複雑性の関係
上はよく見かける時間と複雑性のモデルです。初回リリース時点では低かった複雑性も、その後の度重なる変更を経て、指数関数的に複雑性が上昇します。下げる努力をしなければ、1回の変更に要する労力は増え続け、最終的には変更不能に陥ります。
「運用しやすく作る」という原則は、システム開発に関わる人なら全員知っています。しかし、それを実現するためのマインドセットやプラクティスを実践している人は極めて少ないように感じます。
放っておけば複雑性は増加する
システムを作ったまま完全に放置すれば複雑性は上昇しないかもしれませんが、現実にはそんなケースはありえないでしょう。次のような変更は必ず起きます。
- ミドルウェアのバージョンアップ
- インフラの変更 (ネットワーク構成、クラウド化等)
- 連携先システムの仕様変更
- バグの発見による修正
- 組織内ルールの変更 (セキュリティポリシーや運用ルール等)
- 機能追加要望
常に複雑性を低く保ち、変更可能な状態にしておかなければ、こうしたイベントが起きるたびに大きなコストと苦痛が生じます。
「どうにかする」のパターン
手に負えないシステムの面倒を見ることになってしまったらどうすればいいでしょうか？ここでは以下の4つシナリオを考えてみます。
- 耐え続ける
- 捨てる
- 変更可能になるよう直す
- 逃げる
耐え続ける
どんな変更イベントが発生しても力づくで何とかすることです。あなたが無限の体力と折れない心の持ち主ならば、このシナリオが有効でしょう。
リスクとしては、このパターンだと変更を重ねるごとに苦痛が増え続けます。また、レガシーなままのシステムをレガシーな技術で運用し続けることは、あなたの技術レベルを向上させません。市場価値は相対的に下がっていくでしょう。
…避けた方がいいでしょう。
捨てる
システムを捨てて、コスト発生源を根本から排除するシナリオです。以下のような場合に有効です。
- システムを誰も使っていない (連携先が無い)
- 関係者の許可が得られる
まずい組織はこのアクションが全くとれません。KPI や ROI を評価すれば判断できるかもしれませんが、典型的なサイロ型組織 (経営/企画/運用/開発がそれぞれ分割されている) では複数部署にコスト分配などを行い、全体的なコストが見えづらくなっています。また、そのような組織では意思の決定自体が非常に難しいため、対処されないままになっていることが多いです。
逆に言えば、廃棄するのに十分な根拠を用意でき、関係者全員と調整が可能ならば、このシナリオは非常に有効でしょう。これを可能にするためには日頃から以下のアクションを行っておく必要があります。
- マトリクス (利益、コスト、リスクなど) を可視化する
- 定期的にマトリクスを評価する
- 関係者を把握し、説得可能な状態にする
(悪魔のささやき: わざと深刻な障害を発生させ、関係者全員に「このシステムは手に負えない」という印象を与えられたら…？おっと！)
変更可能になるよう直す
複雑性を下げ、少ないコストで変更可能な状態にするシナリオ。具体的には以下のアクションを行います。
- 自動テストを導入する
- 環境構築を自動化する
- 不要なコンポーネントを削除してスリム化する
これについては私自身も経験があるので、別の記事で詳しく書く予定です。また、『レガシーコード改善ガイド』が素晴らしいアイディアを与えてくれるでしょう。
逃げる
巨大すぎて変更できず、協力者も得られず、考えうるアクションが全てダメだとわかれば、このシナリオが唯一の救いとなるでしょう。転職や部署変更で逃げましょう。
私は過去に「耐え続ける」シナリオを採り続けてボロボロになった人を何人も見ています。組織に労働力を売っても、人生まで売り飛ばす必要はありません。ダメだとわかったら次に行きましょう。
まとめ
アジャイルやリーンの手法を実践できていれば、複雑性に対処しやすいシステムを作れているでしょう。現状がそうでないならば、上述したアクションによって改善を行うといいでしょう。
価値の無いシステムと関わり続けて市場価値を失い続けるのは賢明ではありません。命を大切に。