自己紹介

こんにちは、価格.comの自動車カテゴリでWebアプリケーション開発をしている野村です。本記事では、価格.comを構成するWebアプリケーションの実装で、従来であるClassic ASPから.NETへのリプレイスにあたっての各工程におけるドキュメントや開発サイクルの改善についてお話します。

.NET化開発の背景

Classic ASP運用の問題点

昔の価格.comのWebアプリケーションは、Classic ASPによって開発が続けられていましたが、以下のような問題点が挙がっていました。

IIS5.0及びVB Scriptを用いた古い技術
古い言語及び古いバージョンでの運用を続けているため、処理速度や安全性に対して時代遅れが起きている。また、マルチOSなどの対応にも限界が来ている。
ASPファイルを直接編集する開発手法
複数ASPファイル間で運用されるソースコードは直接編集する運用で進めており、複数人で同時更新などができていない状態となっている。
度重なる改修の結果による仕様書の不在
長年にわたって開発を続けてきたClassic ASPアプリケーションには、マスタとなる仕様書が存在せず、実装から仕様を調査する必要がある。

Classic ASPから.NET Frameworkへのリプレイス

価格.comのリニューアルを繰り返していく中、Classic ASPに変わる技術として、.NET Frameworkへのリプレイスが進んでいました。これに伴い管理手法もGit管理へと移行して、より容易に変更履歴や差分、複数人開発ができるようになり、仕様書も都度用意されていくことになりました。

しかし、レガシーであるClassic ASPのソースコードも未だ多く残っており、全てが.NET化できたわけでは無く、.NET Frameworkへの本格移行が活発化してきた頃、私がこの施策に加わることとなりました。

当時は本格化が始まったばかりで、.NET化にあたっての開発手法が曖昧だったため、チームリーダーと手法を定型化させながら、ドキュメントや仕様書の改善に注力することになりました。

.NET化にあたっての作業工程の改善

「リプレイス」ではあるが、新しいものを作る意識で

Classic ASPでの運用はVB Scriptを用いていましたが、.NET FrameworkではVB Scriptは使えません。また、Classic ASPと.NETの共存ではオーバーヘッド（付加的な処理）が大きい為、せっかくの処理速度の改善も台無しになってしまいます。

また、長年稼働し続けていたClassic ASPでの実装の中には不要なものや、.NETになるからには改善できる実装も含まれていました。そのため、Classic ASPのソースを見て.NETの設計を組むのではなく、まずClassic ASPのアプリケーション実装から画面仕様書を書き起こし、設計書を新たに作り出して開発することになりました。

加えて、.NET化するにあたっての必要な工程や作業も洗い出し、それらに対応したドキュメントの作成も行いました。

	設計	開発	テスト	リリース
本来あった工程	・プログラム設計の作成	・プログラム開発	・テスト仕様書作成・テスト実施・脆弱性チェック	・リリース手順作成・リリース
.NET化に伴って新たに増えた工程	・ASPの調査・画面仕様書の作成	セルフチェック

設計段階においては、既存のClassic ASPを読み解き、処理や条件分岐などをまとめたドキュメント「ASP調査書」と、マスタとなる仕様書として、画面の仕様を落とし込めるドキュメント「画面仕様書」を作る工程を新たに増やし、設計書を作る前に既存仕様が正しく認識できているかフィードバックを行えるようにしました。

.NET化におけるテストファースト

Classic ASPから.NETアプリケーションへの移行の際に、Classic ASPで満たしている仕様を保持しなければなりません。つまり、新たに.NETで書いたコードが従来の仕様通りに動くかどうかの再帰テストが必要不可欠となります。一般的にテストファーストは、開発フェーズ開始前に仕様書・設計書を基に客観的にテストケースを作る手法です。実装内容に引きずられることなく必要なテスト項目を洗い出すことが出来るため、仕様に対する漏れが許容されない.NET開発に向いています。

作業工程の定型化

調査とテストファーストによる作業方針の変更により、工程として新たに調査段階を設け、調査・設計・開発・テスト・リリースの5つの工程で開発を進めることになりました。

しかし、.NET化が必要なアプリケーションは数多くあり、恒常的に行っていくためにはサイクルを早める必要があり、各工程でレビューを行っていてはレビュワーのコストが高くなってしまいます。そのため、レビューを「調査書レビュー」「設計レビュー」「ソースレビュー」の3つに絞り込み、レビューコストのボトルネックを天秤にかけつつ、安全に施策を進められるよう、作業工程を定型化させました。

特にテストファーストによる開発のおかげで、設計レビューの段階で開発のイメージが付くため、ソースレビューでの負担も軽減できるようになり、リリースまでのスピードアップにも繋がるようになってきました。

更に、各フェーズでのスピードを意識した開発の施策として、設計書・調査書・仕様書といったドキュメントの改善を行いました。

.NET化にあたってのドキュメントの改善

設計工程を重んじる開発方針として、調査フェースおよび設計フェーズで用いるドキュメントは必須であり、運用・保守性に長けたもの新規で作成しました。

調査フェーズ：ASP調査書、画面仕様書の導入

問題となっていた仕様書・設計書の雛形を、チーム全体で運用できるよう新規で作成しました。今までASPの調査書や画面の仕様書を運用してこなかったため、チーム全体でフォーマットの改善案を練りだし、最適なドキュメントを組み立てていきました。

ASP調査書

既存のASPにどのような条件・処理がされているのか画面に対応したASPファイル全体を精査し、ドキュメントに落とし込みます。その際、リプレイスの際に改善すべき処理の洗い出しも行えて、設計の方針も固めることができるようになります。
画面仕様書

課題となっているマスタとなる仕様書の不在に対する施策で、画面仕様書を作ることで.NET化の副産物としてマスタとなる仕様書を定義しました。1つの画面に対して1つの画面仕様書を作っているため、最終的に全画面の仕様書が揃うことになります。

設計フェーズ：設計書、テスト仕様書の改善

元となるClassic ASPのコードを参照せずとも、調査フェーズにて要件定義がされているため、この時点で新規アプリケーションの開発として設計を行えるようになります。更に、テストファーストによる開発によって、設計書作成時点でテスト項目の洗い出しを行うため、これまでに作ったドキュメントの誤りを見つけ出し、開発前に不具合を摘出できるようになりました。

設計書

ASP仕様書と画面仕様書があれば、元のASPのコードを辿らずとも.NET Framework開発での設計を組み立てることができます。初期段階で実装の認識を合わせて安全に開発を進めるため、設計書の作成も徹底するようになりました。
テスト仕様書

テスト仕様書についても、.NET開発において新たに必要な機能が無いか模索しつつ、フォーマットを改善しました。Classic ASPで実装されている画面とのHTML差分取得など、.NET開発を支援する機能を用意しました。

開発フェーズ：セルフチェックによる時短

.NET開発サイクルの改善として.editorconfig及びセルフチェックシートの導入を行いました。

.editorconfigの導入
.editorconfigは、エディタ上で改行コードや文字コードがチームの方針と異なっている場合、機械的にチェックして統一してくれる役割を持ちます。導入によって、コーディングのスタイルをチームで統一することができました。
セルフチェックシートの導入

レビュワーのコストを下げる施策として、チームで決定している開発ルールやコーディングなどの標準的な部分に誤りが無いかを、自身で確認・修正できるドキュメントを作り、セルフチェックが行えるようになりました。