レガシー度レイファスモデル。レガシー度を5段階に分類してみた
システムのレガシー度を大雑把に分類してまとめてみます。
細く語り出すとキリがないので、今回は
- システムの要件に関するドキュメントの有無
- テスト項目の整備状況
- 自動テストの有無
- プログラムの可読性・保守性
で分類します。
レガシー度のレベルはドレイファスモデルの用語を流用させていただきました。
レガシー度が高い（酷い状態）であるほど、達人に近づきます。
題してレガシー度レイファスモデル。
レガシーシステムとは？
古くなったシステムのこと。
システムの改善、リファクタリングなどの文脈においては
改修すべき点を多く持つシステムのことをさすことが多い。
そのため、新しいシステムでも置き換えるべきようなものであれば、これにあたる。
レガシー 達人
- システムの要件に関するドキュメントがない
- テスト項目が未整備
- 自動テストがない
- 可読性・保守性が低いプログラム
プログラムだけが拠り所なのに、可読性が低く品質も低い。
実装者以外が仕様を炙りだすのは非常に困難。
しばらくすると実装者も仕様を炙りだすのに苦労しだす。
挙句の果てに実装者が逃亡して更なる混沌を生み出したり。
テスト項目が未整備で、仕様も不明確な状態で運用されているため
あちこちにバグが発生し、バグ対して「何が正解か？」を
調べるところからスタートする。
自動テストがないことから、リファクタリングのリスクも高く
バグの修正や新規機能の追加時に新たなバグを仕込んだり
既存の機能を破壊しやすい状態。
レガシー 熟練者
- システムの要件に関するドキュメントがある
- テスト項目が未整備
- 自動テストがない
- 可読性・保守性が低いプログラム
レガシー 達人と比べると要件が分かるため、
「何が正解か？」について迷うことはない。
しかし、具体的な境界値などについてはテスト項目が未整備のために
改めて考える必要がある。
また、テスト項目 or 自動テストが整備されるまでの間は
開発者個人の裁量でテストを実行するため
どんなテストが行われているか不明瞭で、品質もまちまち。
レガシー 上級者
- システムの要件に関するドキュメントがある
- テスト項目が整備されている
- 自動テストがない
- 可読性・保守性が低いプログラム
テストの項目が整備してあるため、実装とその想定される正解が把握可能。
ただし、自動化されていないためテストの実施に対するコストが大きい。
コードベースのレベルが低いことから、バグの発生率やコードの改修などもが高く
繰り返しテストをする機会が多くなる上にテストのコストが大きいために
長期的にみると開発コストは高まり、開発期間も長くなりやすい。
この問題に厳しい納期と発注元 or 元請けの強硬姿勢が重なると、組織によっては回帰テストや一部のテストを
省略したまま運用フェーズに達してしまい、本番運用中にシステムが火を噴くことになりがち。
レガシー 中級者
- システムの要件に関するドキュメントがある
- テスト項目が整備されている
- 自動テストがある
- 可読性・保守性が低いプログラム
自動テストによって、テストの工数が大幅に下がり、
回帰テストが常に実行されるため追加開発時のデグレードの可能性が減る。
これにより、リファクタリングによってプログラムの可読性・保守性を高めることの
リスクが大幅に減る。
あとは、リファクタリング・設計スキルが高い人員を増やせば最後の
「可読性・保守性が低いプログラム」の問題を解決することができるが、
部分的にスキルが高い人を増やしても部分的に問題のあるプログラムを開発し続ける
メンバーがいるのであれば、それは全体の問題となって残る。
組織に属する全ての開発者が一定レベル以上の可読性・保守性のプログラムを書き、
リファクタリングテクニックを有する必要がある。
組織の文化や発注元によってはリファクタリングを禁止するケースもあり、
そういった現場の場合はそもそもここから先に進むのは難しいだろう。
レガシー 初心者の現場を生み出すには技術志向でスキルの高い開発者の採用が重要となる。
優秀な開発者を惹きつけ、継続的に在籍してもらうには
魅力的な現場であること、魅力的な同僚で構成された組織である必要があり難易度が高い。
教育・・・もあるかな？と思ったがそもそも魅力的な人材は自発的に学習をするので
人材さえ揃っていれば自ずと、と思ったりする。
レガシー 初心者
- システムの要件に関するドキュメントがある
- テスト項目が整備されている
- 自動テストがある
- 可読性・保守性が高いプログラム
要件は明確で、テストは網羅され、
自動で回帰テストを実行可能であり、
自動テスト、リファクタリングに習熟しているメンバーで構成され、
プログラムは可読性・保守性が高い。
結果として、障害は少なく開発のスピードは非常に早くなる。
ビジネスの要求に素早く応えることができ、優秀な現場と優秀な開発者が
新たに優秀な開発者を呼び込んでくる。
開発者のコストはレガシー度の高い現場より高いだろうが、
その何倍・何十倍、そもそもプロジェクトが崩壊することと比べたら
X倍では比較できないような差がある。
まとめ
全てのレベルの現場を体験した上での分類です。
レガシー度が高いほどバグの修正、機能の追加にかかるコストが高く、
実装期間も本来の難易度よりも大幅に長くなります。
例えばとあるWebシステム内で利用されている計算式のほんの一部を変更するだけ、といった変更の場合も
各モジュールの結合度が高く、自動テストも整備されていないようだと
ブラウザベースでテストする必要があります。場合によってはテストでその機能に到達するためには、
幾つもの前提知識を知る必要があるケースもありえるでしょう。
その場合、新規にその開発に参画したメンバーがその変更を担当した場合、
全ての作業が完了するのに丸1日かかるかもしれません。
しかし、要件が明確で自動テストが整備され、可読性が高く適切にモジュール化されたコードベースであれば
30分以内で修正できる、というケースもありえるでしょう。
このケースは、可読性の高いOSSのプロダクトに対してちょっとした修正パッチを送るケースににています。
この場合、 8時間(480分) : 30分 で16倍もの生産性の差がでます。
多分双方の現場を体験したことがある方なら、このくらいのケースは珍しくないということを同意いただけるのではないでしょうか？
レガシー度の高い現場をレガシー度の低い現場にすること、
また、レガシー度の低い現場を作りだし、その状態を継続する優秀な開発者を雇うこと、
この価値は非常に大きいということです。
