大規模案件で経験したこと

4/1から、東京某所の現場から横浜某所へ移動になりました。

Javaの業務システムを1年半程度触ってきて、思った事を備忘録的に書いておこうと思います。

ぶつかった問題と課題

ドキュメント腐る問題

設計検討などのデザイン資料をエクセルやパワポで作成していました。

それらが乱立した結果、設計完了後にその資料案が残った事でどんどん陳腐化していく現象が発生。

管理がファイルサーバだった事も相まって、どのドキュメントが最新なのかが分かりづらい現象となった。

考えられる対策

  1. ファイル管理をファイルサーバからSVNなどのバージョン管理に変更する
  2. ディレクトリ構成を徹底し、どの資料がどこに格納されているのかを明確化する。
  3. 適切なタイミングで資料を更新、または破棄する
  4. 設計思想などの経緯は記載しても良いが、設計については決定事項のみをドキュメント化する

DRY原則

ソースコードでのDRY原則も規律が弱い上、設計検討などの参考資料も乱立した。

ドキュメント腐る問題と合わせると、作った資料が複数存在することで片方の資料は即死する現象も発生した。

考えられる対策

  1. ソースコードに関しては、共通化するリファクタリングを適切なタイミングで行う
  2. 資料については、格納先ディレクトリを先に決めておき重複を避ける
  3. 適切なタイミングで不要な資材、資料は削除する

雑談ミーティング

設計時の課題や、バグが発生した際の「対応会議」が勃発。

各位が意見や解決策を持ち寄るわけではなく、その場で解決策を考える手法が蔓延した。

特に、モジュール影響の大きいバグに関しては参加者が増加した。

バグなどの周知は100歩譲って打ち合わせ形式で事象をバラまいても良いと思うが、根本解決はその場で起きないことが多いのでいったん解散すべき。

考えられる対策

  1. 意見・提案のない参加者は会議に参加させない。
  2. ゴールが明確な状態で、提案→承認のみを会議で行い、提案ができない会議であれば解散する

テスター駆動開発

システムテスト以降で上がったバグで仕様が決まっていった。

wiki:テスター駆動開発(英語版)

考えられる対策

  1. 仕様の確定

良かった気づき

アンチパターンを体感できたは良かったかなと思いました。

また、下記の参考記事の項目はほぼすべて体験できたのではないかと思います。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする