HCの原です。
ソーシャル系の開発現場では、意外なことに、テスト駆動開発やペアプログラミングなどのアジャイル開発で一般的に取り組まれているプラクティスが採用されていないケースが有ります。
つまり、コーディング段階における品質に対する意識が薄いというのが実態としてあるようです。プラクティスを採用せずに開発を進めると、プログラムの品質はプログラマーのスキルに大きく左右されてしまいます。また、几帳面なプログラマー、そうでないプログラマーでも原因の特定のプロセスにおいて違いが生まれます。
例えば、開発環境の進歩と共に、ローカルのシミュレータで見た目の確認が可能で、あたかも正常に動作しているように見えてしまい、記述した判定文や変数の中身など、殆どチェックせず、本番環境にBildしてしまうケースです。アジャイル開発では、設計工程もメモ程度で済ましてしまう事が多々あります。仕様はソースコードにしか無いため、一旦問題が発生すると原因の確認は常にプログラムのソースをチェックする必要が出てきます。また、正しく動いていると思い込んでいますから、後工程になって不具合が見つかると原因が特定できずに、問題解決に時間がかかるケースも多くなります。
また、テスト担当者が考えるテストケースも内部の処理が仕様として定義されていないため、ストーリーに基づく正常系のチェックにとどまり、限界値や境界値のチェックが漏れてしまう場合も多くなる事が考えられます。
対策としては、プログラミングの基準や変数の一覧、共通関数の仕様書、作成するモジュールの機能の概要等、最低限のドキュメントを作成し簡単な仕様レビューを実施することです。レビュー実施によって開発者の思い込みやケアレスミスの発生を早く見つけることができるようになります。また、テストケース作成の参考となり、限界値や境界値のチェックを追加することも可能になります。スタンドアップミーティングの後など、ちょっとした時間を有効に使って実施してみてはいかがでしょうか。
Tweet