2024.01.18
Webシステムにおいて、ユーザーの期待通りに動作しない、サイトのレイアウトが崩れているなどの不具合は、ユーザー離れを招く可能性があります。リリース前にしっかりとテストをしておきたいところです。
しかし、開発現場では、納期が短い、仕様変更が頻繁に発生するなどの理由から、納期間近にテストを行うことがあり、画面の細かい調整やユーザビリティーの改善の確認に十分な時間をかけられないことがあります。
今回は、短納期や仕様変更など、Webシステム開発で起こりがちな問題と、それらの発生を防ぐための対策をご紹介していきます。
- もくじ
1．Webシステム開発でよく起こる5つの問題
Webシステムの開発現場で起こりがちな問題を5つご紹介します。その問題が発生することでどのようなリスクがあるのかも併せてみていきましょう。
(1) 短納期・仕様変更が多い
1つ目の問題としては、短納期・仕様変更が多いことです。
システム開発は、クライアントの稼働希望スケジュールやニーズに沿うために、システム開発会社の許容できる工数よりも少ないリソースで開発を遂行しなければならないケースがあります。また、クライアントにとっては、1つの改修や機能拡張にどれくらいのリソースが必要なのかイメージしづらいことも多いです。そのため、当初に合意していた仕様を後になって変更しても、通常よりも短い納期で対応するよう希望されることも少なくありません。
このように、顧客の要望するスケジュールを盲目的に受け入れたり、リスクを無視したタスクの差し込みを許容したりすると、現場の開発者に多大な負担がかかるだけでなく、バグの見逃しなど誰にとっても不利益な状況に陥ってしまいます。
(2) 修正・追加開発で工数が取れなくなる
2つ目の問題は、修正・追加開発が重なり、必要な工数が取れなくなってしまうことです。
システム納品後に致命的な不具合が発見されて早期に修正しなければならなかったり、要件定義漏れが開発プロセスの終盤で発覚したりして、予定していなかったシステムの改修・機能追加が必要になることも少なくありません。
このような状況に陥ると、「本来予定していた機能改修に十分な人員を割けない」「テスト工程を一部省略する」などで対応せざるを得ず、必然的にシステムの品質が落ちてしまいます。
(3) ドキュメント未整備によって開発コストが増える
3つ目はドキュメント未整備によって開発への負担が増えるという問題です。
既存のシステムの機能拡張・改修を重ねると、システムの構造は複雑化します。このとき、すでに開発されている機能や記載されているコードがどのような意図を持って実装されているのかを把握するため、仕様書や設計書といったドキュメントが必要不可欠です。
システム開発ではメンバーが変更されたり、チームで開発を行ったりすることも多いため、いつ誰が見ても当時の開発者の意図や構想が把握できるようにドキュメントを整備しておくことが欠かせません。しかし、機能の設計・実装・テストに工数を優先的にかけてしまい、ドキュメント作成に時間をとることができないことも少なからずあります。
この場合、仕様についての再度の認識のすり合わせや、認識のずれによる手戻りが発生するなどして開発負担が増大し、そのしわよせはシステムの品質低下として現れます。
(4) 追加/修正の繰り返しでデグレートが多発する
4つ目の問題は、追加・修正を繰り返すことでデグレードが多発してしまうことです。
デグレードとは、開発の中で不具合を修正した後に、それまで動作したものが動かなくなるなど、品質が低下してしまうトラブルのことです。システムを長期で運用し、改修・機能拡張を重ねていく中で、当初の実装意図が伝わらず、後から誤った修正・機能開発がなされてしまう可能性があります。
一定以上の規模のサービスの場合、開発メンバーがコーディングのルールを誤解して、システムの追加や修正を行うことで、深刻なデグレートが発生することも。
また、追加や修正を行った場合は影響範囲を特定することが大切ですが、工数の関係などでこのプロセスが十分に実施されないと、不具合の温床になりかねません。
(5) 開発者・設計者がテスト実施することで無駄な工数が増える
5つ目の問題が、開発者・設計者によるテスト実施で無駄な工数が増えてしまうことです。
内部構造を把握している開発者や設計者がテスト・検証すると、開発者目線に偏ったテスト・検証になりやすいです。ブラックボックステストを介していれば検知できた不具合に気づけない場合もあります。
結果として、テスト・検証に対する無駄な工数によりコストが発生してしまいます。
2．システム開発時のトラブルを防ぐ3つの対策
前章でご紹介したWebシステム開発でよくある問題にはあらかじめ対策しておくことが重要です。この章では、開発時のトラブルを防ぐ3つの対策をご紹介します。
① クライアント・PM・開発者間で仕様をすり合わせる
1つ目の対策としては、あらかじめ、関係者間(クライアント・PMなど)で使用をすり合わせておくことです。
関係者間でゴールが共有されていない場合、開発プロセスの実装・検証段階に入ってからの仕様変更や差し込みが発生することがあります。決められたスケジュールの中で、システムに求める仕様や要件を確実にすり合わせるために、以下のような工夫をしながら対応していきましょう。
- 文書やメールなどテキストでやりとりを残す
- 記載事項の漏れを見つけやすいように設計書や仕様書の書式を統一する
このような対策を行うことで、「短納期・仕様変更が多い」「修正・追加開発で工数が取れなくなる」といった問題発生を減らすことができるでしょう。
② テスト設計からドキュメントの整備を行う
2つ目の対策は、テスト設計からドキュメント整備を行っておくことです。
テスト設計者がテストの実施前に開発者から入念なヒアリングを行い、ドキュメントを整備しておくことはとても重要です。
例えば、テストケースのフォーマットに開発の背景や仕様・要件をまとめるような項目を設けることで、開発を行う理由とその開発内容、これに対する検証方針・結果が1枚の文書に集約されるため、後で文書を参照する必要があった際に確認しやすくなります。
「ドキュメント未整備によって開発コストが増える」という問題も解消されるでしょう。
③ 開発手法や判断基準をルール化する
3つ目は開発手法や判断基準をルール化しておくという対策です。
システムテストの段階では、そのシステムの内部構造や仕様を満たしているかに目がいきがちです。しかし、実装に取り掛かる前の問題として、開発手法や判断基準をいかに設けるかも重要な観点になります。
コーディング時の変数のネーミングルールやコメントの残し方、各開発プロセスでの差し込みタスクへの対応基準を、社内で統一しておくことが「追加/修正の繰り返しでデグレートが多発する」「開発者・設計者がテスト実施することで無駄な工数が増える」といった問題の予防策となるでしょう。
まとめ
今回はWebシステム開発において起こりやすい問題と、問題発生を防ぐための対策についてご紹介しました。
短納期や仕様変更などの問題に対しては、クライアントや担当者間の情報共有やドキュメント整備、テスト観点の統一が欠かせません。
記事で取り上げたポイントを押さえて、長期的な視野で見たシステムの品質向上を目指していきましょう。
