概要
自分の開発経験を元にシステム開発現場のアンチパターンを挙げてみる。
この兆候があると危険。
★1〜3 まぁよくあるよね
★4〜7 若干危険。急いで業務改善を!
★8〜10 自主的に仮病で倒れる準備を
荒れた学校
割れた窓が放置してある様相。
割れ窓=好ましくないコードがあるのは分かっているが
修正することをリスクと捉えて直そうとしない。
直さないこともリスクですよ。しかも積み重なっていく。
能力の高い開発者ほど品質の高いコードを書けないことにストレスを感じ、
現場を去っていく。
烏合の衆
派遣エンジニアで構成されたプロジェクト。
お互い協力する意識が低かったり、自社の懐具合にあわせて
ズル休みしたりと様々な弊害がある。
また、技術力を向上させても常駐先での契約単価が上がることは
あまりないため向上心のないエンジニアは最低限の業務しかしなくなる。
貢献度と利益の逆相関
元請けと下請けの請負と言う名の派遣の契約形態が固定単価である場合に生じる現象。
業界的に残業皆無な現場はほとんどない。
ここで2つのパターンがある。
1.自社から残業代が出る場合
→働けば働くほど自社の利益が減るので適度にズル休みするように業務命令が出る
2.自社から残業代が出ない場合
→労働者のモチベーションが下がり、ほどほどの業務しかこなさなくなる
モラルの低い技術者は上記のようにサボりがちになる。
目先の単価よりも自分の技術力向上のために力をそそぐことを厭わない
実力のある技術者に業務が集中。業務の大半が出来る技術者に集中するが
時間単価に直すと一番損をしているのがプロジェクトに一番貢献した人物になる。
悪魔の囁き
「見なかったことにしよう」というセリフが聞こえたら要注意
リズミカル
一定のリズムでリズミカルに長時間キーを叩き続けている人がいたら注意。
自動化出来る作業を手動でやっている可能性大。
カコカコカコカコ♪エンター!!カコカコカコカコ♪エンター!!
カコカコカコカコ♪エンター!!カコカコカコカコ♪エンター!!
Excel方眼紙
DRY原則の敵。ソースとドキュメントの二重管理になる上に、
ちょっとした修正のためにドキュメントを直す手間が大幅に増す。
リファクタリングの敷居を高くする悪習慣。
最終的にはメンテナンス不能に陥り嘘だらけのドキュメントに。
変化を嫌う
XPやアジャイルの変化を許容するのとは反対。
既存の非効率な業務フローやプログラムが元からそうなっているから、
という理由だけで変えようとしない。
結果、冗長な作業に時間をかけ技術力も上がらず技術的負債が蓄積していく。
お水系
ウォーターフォール開発信者が根強い現場。
スピード感、柔軟性にかける。システム開発に仕様追加・変更はつきものだが
変更に強い開発手法でないため破綻をきたす。
苦し紛れに大量人員投入をして、管理工数が増えてさらに進捗は遅れ・・・
究極系が特許庁のシステムか。
http://www.asahi.com/business/update/0124/TKY201201240616.html
瞬間湯沸かし器
過剰にキレやすい上司のいる現場。
ほうれん草が滞る原因になり、開発のリスクとなる情報や
障害の隠蔽などが増加する。