(過去の記事にちょくちょく書いていたのをまとめてみる)
システム開発に限らず、製造工程や作業工程に設計書(指示書)類の書類は必要で、書類の元で行動するのが原則であると考えています。
(例外として、プログラム仕様書に関しては事後にツール経由で起こすこともありますが、これは性格上、許容されているケースでもあります。)
書類の目的は、
1.作業/開発を効率的に且つ、円満に遂行する
2.作業/開発の内容を書類で伝える。
3.保守/改修に必要な箇所/要点を伝える
4.製造物の構成の仕組みを伝える
5.コストの類の資料化
6.その他必要事項 (<=この言い方も曖昧だよね)
だと思うのです。
書類の受入審査やレビューを経て成果物となりますが、その内容よりも書式/デコレーションのほうを重要視して、内容が無くても、ページ数/活字が詰まっていて、見てくれがよければ、OKとなってしまうケースがあります。
大きめのプロジェクトになると専任のレビュアーがいてレビューするのですが、個々のシステムは知らずに書類のみでレビューすることもあるようです。
大仰に言えば,「省益あって国益なし」の精神の縮小版を感じたことがありました。
ソースにマジックナンバーを書くことを禁止する のは当然の規約ですが、上がってきたソースに以下の記述がありました。
Const case_One As Integer = 1
Const case_百 As Integer = 100
dim 判断値 as Integer = CInt(DB.Table.判断項目)
Select Case 判断値
Case case_One
'xxxxxxxxxxx
Case case_百
'xxxxxxxxxxx
End Select
レビュアーがOKにして納品物となって、本稼動されてます。
確かにマジックナンバーになっていないケレド.... PGもPGだけれど、レビュアーも形式に則っているかをチェックするだけでなく、目的を自覚して貰いたいものです。
これは、役所などでもよくみられます。書類の形式のみの審査だから,空出張や,空購入、チケットの金券屋流しなどが簡単にできてしまうのでしょう。
自分の仕事の役割を自覚してなくて、狭い範囲の実作業レベルが仕事だと考えているのでしょうかね?
一般的なサラリーマンの仕事もそうなんだろうか?