自己紹介と現在の状況
こんにちは。
地方中小IT企業で働いて6年目になりました。
題名でわかる通り、2022年から大変レガシーなシステムを運用担当することになりました。
そのせいで残業がとても増えてしまって辛いので少しでも残業を減らせるように改善したことを書いていきます。
ちゃんとしたIT企業で働いている方からすれば何を今さら…なことも多いかと思いますが、
同じような境遇にいる方もいらっしゃると思うので少しでも助けになれれば幸いです。
何が辛いのかをリストアップしてみる
まずは問題を具体的にとらえるために何が問題だと思っているのかを書き出します。
- 画面の仕様がわからない
- 全体的なテスト仕様書がない（細かいのはある）
- どんな画面があるのかわからない
- どんな帳票があるのかわからない
- マジックナンバー多すぎ
- 手作業で管理するマスタ多い
- テストがない
- テストを書く文化がない
- ソースしか信じるものがないというのがデフォ
- でもバグもある
- 保守契約してない
- ミスると客から怒鳴られる
- 業務改善の時間がない
- 例月、例年の作業が自動化されていない
- 深夜作業多い
- 自動化のノウハウがない
- 自動化する気力もない
- コードが汚い
- 自動テストできる状態のコードじゃない
- 仕様変更でコード修正してもコピペが大量だから漏れる
- 警告多いままコミット、リリースされてる
- 本番とステージング環境でソースが違う
- 原因のわからないバグがあって都度データパッチが必要
- 先輩の見積もりが雑すぎて納期に間に合わせるための長時間残業が発生する
- フレームワークがEOL
- Java古すぎ
分類してみる
改めて書き出すと泣きたくなるような惨状ですが、これを少しづつでもいいから改善しないと辛いので改善案を考えます。
主に以下のように分類できると思います。
- コードに関すること
- コードが汚い
- テストが無い
- マジックナンバー など
- 仕様把握に関すること
- 各種ドキュメントがないことなど
- 運用体制に関すること
- 例月作業なのに自動になっていない
- 保守費用0円 など
- その他
- 見積に関するノウハウが共有されていない
まずはひとりでできることから始める
「カイゼン・ジャーニー」を読んだのでまずは一人でもいいから始めることが大事だとわかっています。
自分が今すぐ始められることといえばコードを書くことなので自動テストを導入することから始めたいと思います。
自動テストの導入
軽く検索したところ、eclipseにすでにJUnitプラグインが入っていることがわかりました。
想像していたよりもずっと簡単に自動テストをすることができました。
「JUnit実践入門」も追加で購入し、読み進めつつテストを書いていきました。
後々チームメンバーに共有できるようにドキュメントも整備しつつ進めていきます。
自動テストがあることによって、今後の仕様変更に強くなりますし、現状の仕様も把握しやすいため優先順位を高めに進めています。
リファクタリング
現状のコードではテストが書けない状況にあることがわかりました。
テストできない状態とは主に以下のようなものがあげられると思います。
- 一つのメソッドでいろいろやりすぎている
- WEBサーバーと同時に実行しないといけない（できなくないが、面倒）
- 実行順番に依存している
特に2つ目の原因がかなり要因としては多くありました。
MVCモデルで設計している場合、ビジネスロジックはModelかもしくはサービスクラスへ持たせるべきところなのですが、担当しているシステム（どころか自部署が開発したほぼすべて）ではControllerでビジネスロジックの実装を行っていました。
そのため、単純にJUnitでテストを書いただけではテストできず、まずビジネスロジックをModelへ移管するところから始めることになりました。
リファクタリングとテストコードの作成を始めておおよそ1か月くらい経ちましたが、まだカバレッジは４～５％程度です。
それだけ巨大なコード量（重複も多い）ですが、この調子で2年も進めていけばカバレッジは100％を超える試算です。
書籍から知識を得る
リファクタリングを行うにあたって、まずは自分の知識のみでは太刀打ちできるような規模のシステムではないと思ったので以下の書籍を買いました。
- レガシーコード改善ガイド
- レガシーソフトウェア改善ガイド
中古とKindleセールで費用は半額程度で収まりました。
書籍を読みつつリファクタリングをすすめ、ある程度ノウハウがたまったらドキュメントとして書き起こし、チームで共有しました。
ただ、実際にリファクタリングをする余裕がある人員が自分しかいなかったため未だノウハウの共有はできているとは思いません。これからはテストとリファクタリングを積極的に行える人員を増やしていくことが重要だと思います。
ドキュメントの整備
コードの改善に着手しただけでは自分がチームを抜けたあと同じ状況に陥ることは免れないため、今後どのように運用していくか、運用のための知識の共有を行いたいのでドキュメントを作成しました。
開発ルール
システムの開発を行う際にメンバーに遵守してもらいたい事項を一覧にし、その理由も添えてまとめました。
これ以上コードを汚くしないための規則がほとんどで、それ以外は扱うシステムに対しての前提知識や、いま行えていないこと、これから行いたいこと、未解決のバグなどです。
これは次回の機能改修が始まるころにメンバーに共有する予定です。
画面遷移図作成
ちょうどIEが終わるころで全画面をすべてチェックする機会があったのでそれに合わせて画面の遷移図を作成しました。
遷移図の中には、画面名、Class名、出力帳票、特殊処理（ログインした権限により画面表示が変わる、など）をオブジェクト内に記入し、それぞれを遷移条件を記入した矢印で結びました。
画面名とClass名を記入したのは、画面名とClass名が必ずしも一致していないことが多かったからです。
運用手順書の整備
一応前担当から引き継いだ運用手順はありましたが、それだけではカバーできていなかったので担当してから頻度が高かった運用を追加し、よくある問い合わせについては自分に回ってくる前に問い合わせを受けた人が返答できるようなQA集を作成しました。
もちろんこれは一度作って完了ではなく継続して更新していきます。
メンバーにも必要な場合は更新するようにルールを守っていただいています。
Jenkinsによるリリース自動化
やっぱりリリースも面倒なので↓を参考に自動化しました。
参考記事ではリリース先がLinux機なのでWindowsサーバーにリリースする部分が手まどいました。
net useでマウントしてからファイルリリース、↓に記事を参考にtomcatのサービスを再起動するようにしました。
これでいつでもボタンひとつでリリースができる手順が作成できました。
あとは横展開するだけです。
また、これも手順を作成して部に共有しました。
ドキュメントはNotionで作成してPDFエクスポート機能を使いました。
保守契約の提案をする
まず保守とは何か、というところから知る必要があると思ったのでソフトウェア工学の本を買いました。
kindleで半額だし、今後も使うので自費でOK…と言い聞かせて買いました。
そして最終的に↓にたどり着きました。
参考文献的には開発終わってリリースしたらそれ以降は全て保守ということになるようです。
なので、不具合対応だけではなく、仕様変更やテスト環境、開発環境の保守、さらにはドキュメントの整備、テストコードの整備も保守費用として請求しても構わないということになります。
ただ、例月の契約としては制限なしの仕様変更なんて来たら捌き切れないので、せめて3人日くらいの範囲で保守契約を結ぶのはどうだろうか？それに加えてテストコードの作成やテスト仕様書の整備についても保守契約に含めたらどうか？という旨を上司に提案したら少しでも仕様変更の文言を入れたら3人日で収まるわけない要望が無限にくるに決まってるからということで却下されました。テストに関してはスルーされました。本当に悲しい…。
ということで次に起こそうとしているアクションはせめてテスト関連の整備を保守に含めるべきだという提案を続けることです。
テストに関してはメリットデメリット何もわからない状態の上司なので、そこの知識から入れ込めばテストを整備しないわけにはいかないと思います。
さらに、保守契約に入れ込んでしまえば部のメンバーはテストコードを書かないわけにはいかないという状況になります。
強制的に部のコードの品質をあげてしまおうという野望です。
今後行いたいこと
自分ができる範囲
今後もやりたいことはたくさんあります。まずEOLのフレームワークを別のものに切り替えるか、言語を変えて作り直すかを行いたいです。
一括リプレースというよりは細かい単位で分割して少しずつ進めていくのが良いと思っていますが、そこは発注者次第です。
いっそパッケージソフトに乗り換えるといわれたらそれはそれですっきりします。
組織内で行う改善
まずはSVNからGitに移行したいです。
現状様々な制約があって開発スピードはかなり遅いし、運用に時間が持ってかれているのでそこは組織全体として何とかしていきたいところです。
あとは社員それぞれの脳内に残っている特殊仕様をすべて吐き出させたいというのは野望としてあります。NotionかQiita Teamかそういうのでナレッジ共有することが当たり前の組織になっていけたらと思います。
顧客との関係性も見直したいところではありますが、それはまだまだかかりそうです。
書いといてなんですが、今やりたいことを書き連ねてもしょうがないのでやった後にまた記事を書きたいと思います。
終わりに
ここまで読んでくださった方がいればありがとうございます。
いろいろ書きましたが、一休.comの改善のスライドにほとんど書いてありました。ワハハ。