はじめに
Springを使用したWeb開発案件で、既存画面の改修を担当しました。
当初は新規画面・Controller・Serviceなどを追加する想定で、ざっくり10人日程度の見積もりでした。
しかし、既存処理を調査した結果、JavaScript側に約10行程度の修正を加えるだけで要件を満たせることが分かり、最終的に1.5人日程度で対応できました。
この記事では、どのように既存処理を読み、なぜ新規画面を作らずに済んだのかを整理しました。
改修フローと担当範囲
実際の内容に入る前に今回の作業フローと担当範囲を整理します。
今回の作業は、要件・ざっくり設計の確認からスタートしました。
その後、設計内容を確認し、必要に応じて設計書を修正してからコーディング・単体テストに進む流れです。
当初の要件と設計方針📚
既存の処理
既存画面では画面に遷移したタイミングでバックエンドに対して非同期通信を行い、取得したデータを一覧表示していました。
要件
今回の要件は画面遷移時には非同期通信を行わず、ユーザーが条件を指定してボタンをクリックしたタイミングでデータを取得する、というものでした。
当初の設計方針
当初の設計では、既存画面に遷移する前に新規画面を追加する方針でした。
新規画面で条件を入力しボタンをクリックした後に既存画面へ遷移することで、既存画面の初期表示時に非同期処理が実行されることを避ける想定です。
そのため、以下のような作業が必要になる見込みでした。
- 新規画面の作成
- JavaScriptの追加
- Controllerの追加
- Serviceの追加
- 設計書の修正
- 単体テストの追加
なぜ作業工数を削減できたのか
作業工数を削減できた一番のポイントは、当初の設計で想定されていた「新規画面」にありました。
この新規画面は、既存画面とほぼ同じ構成でした。
新規画面を作成する理由は、既存画面の遷移時に非同期処理を実行させないためだけでした。
そこで、要件を読み直したうえで、次のように考えました。
画面遷移時に非同期処理を実行させなければ、既存画面のままでも要件を満たせるのではないか
この仮説を確認するために、既存のJavaScriptとDataTables周辺の処理を調査しました。
調査して分かったこと💡
調査の結果、JavaScriptに約10行程度のコードを追加するだけで、要件を満たせることが分かりました。
主な修正内容は以下の2点です。
- DataTables（jQueryプラグイン）に対して、初回画面表示時に非同期通信を行わないオプションを設定する
- 既存処理で初回の非同期通信完了を前提としていた箇所に対して、初回表示かどうかを判定するフラグと分岐処理を追加する
これにより、新規画面やバックエンド側のクラスを追加せず、既存画面のまま要件を満たせる形にできました。
工数の比較👬
当初のざっくり設計では、以下のような見積もりでした。
| 内容 | 工数 |
|---|---|
| コーディング | 7人日 |
| テスト | 3人日 |
| 合計 | 10人日 |
調査後の方針では、以下の工数で対応できました。
| 内容 | 工数 |
|---|---|
| コーディング | 1人日 |
| テスト | 0.5人日 |
| 合計 | 1.5人日 |
結果として、約8.5人日程度の工数を削減できました。
UX面でも改善できたこと💻
当初の設計方針では新規画面から既存画面へ遷移する構成になるため、ブラウザの戻るボタンを押した際にほぼ同じ見た目の新規画面を経由する必要がありました。
ユーザーから見ると、改修前には存在しなかった中間画面を挟むことになり、画面遷移が分かりづらくなる可能性がありました。
ブラウザの戻るボタンに対して任意の画面へ遷移させる方法も考えられますが、ブラウザ履歴の仕様を考慮するとすべての遷移パターンで自然な挙動にするのは難しい状態でした。
今回の修正方針では新規画面を追加しないため、既存の画面遷移を維持できます。
その結果、改修前と同じ操作感を保ったまま要件を満たすことができました。
今回の学び☕
今回の改修を通して既存処理を調査することの重要性を改めて感じました。
要件だけを見ると新規画面を追加する方針でも実現できます。
しかし、既存処理を理解したうえで考えるとより少ない修正で同じ要件を満たせる場合があります。
また、単に工数を削減するだけでなく画面遷移を増やさないことでUXを維持できた点も大きなメリットでした。
まとめ🌱
今回の改修では、既存処理を調査することで当初10人日程度と見積もられていた作業を1.5人日程度に削減できました。
特に重要だと感じたのは、以下の3点です。
- 要件と設計方針をそのまま受け取るだけでなく目的を確認する
- 既存処理を調査し最小限の修正で実現できないか考える
- 工数だけでなくUXへの影響も考慮する
最近は、技術書で学んだことを実務の設計や実装にどう活かすかを考える機会が増えてきました。
今後も保守性・UXのバランスを意識しながらより良い実装を考えていきたいと思います。
また、処理量やアルゴリズムを学習する必要性も実感してきています。