皆さんこんばんは。
本日はSE(システムエンジニア)向けの内容ですが、SEでない方にとっても有益だと思いますので、
是非最後までご覧ください。
内容はドキュメント（記録と捉えてもよいです。）の重要性についてです。
何かシステムを導入しようと思ったときに必ずドキュメントは必要になります。
ＲＦＰ（提案依頼書）から始まり要件定義書やテスト仕様書、議事録や操作マニュアルに至るまですべてドキュメントになります。
これらのドキュメントがいつどんな時に必要になるのか、説明します。
責任逃れができる
プロジェクトも後半になると実際に運用する方々が使い始めます。（運用テストってやつです。）
残念なことに多くのプロジェクトでは、この運用テスト時に仕様変更がよく発生します。
でも、ドキュメントがしっかり作成されていれば、仕様変更時にかかる負担を請求が可能になったります。本当に軽微な修正は除いて、本来は請求すべきだと思うんですよねー。
ちゃんと設計書があって、承認されており、その通り作成されていれば、堂々と交渉することが可能になります。
そもそもドキュメントがしっかり作成されているプロジェクトはまともなプロジェクトが多いです。
他人に説明することができる
ドキュメントがあれば、他人に説明しやすくなります。究極的には説明が不要になります。
例えば、とある部署で使用している○○システムについて考えます。
他部署から異動してきたＡさんは○○システムの使い方が全く知りません。もともとその部署にいるＢさんは当然使いこなせます。
Ａさんはわからないことがあれば、都度Ｂさんに確認することになります。
これはどこにでもよくある光景に見えます。
でも、これはっきり言って無駄ですよね。
だって、時間がたってＡさんがシステムを使いこなせるようになったとしきその時に新人のＣさんが入ってきたらまた同じことの繰り返しになります。
ちゃんと運用マニュアルや操作マニュアルを作っておけば、基本的にはそのマニュアルを見てもらえればよいわけです。
見てわからないことが不足があれば、そこだけを質問することができるのです。また、ドキュメントに追加するなりしておけばその質問もなくなっていくわけです。
システムに関する話題がなくなってコミュニケーションがなくなるけれど、効率化ってそういうもんですよね。
変更履歴がわかる
ドキュメントをちゃんと残しておけば、いつ、どこを、何のためにシステム変更したのかわかるようになります。
システムに何らかの異常が起きた時、変化点や影響範囲などを早く判断することができます。
トラブルは大体は人のミスによるものです。
例えば、「ネットワーク構成を変更した」「夜間処理の順番を入れ替えた」「新しいパソコンに更新した」等何らかの変更点があるものです。
当然、こういった記録を残しておけば原因調査は早くなりますよね。
変更内容を説明しやすい
上記２つの内容をミックスさせたような内容になりますが、システムを変更することは、実際結構あります。
でも変更内容を上司など決裁権を持っている方に説明し承認してもらう必要があります。
説明は口頭でもできなくはないですが、絶対ドキュメントでおこなったほうがよいです。
むしろドキュメントに記載してあることを変更するときには上司に申請するルールになっているほうがよいくらい重要だと思います。
だって、ほとんどのドキュメントは承認されているわけで、その内容を変更するわけですから、再度承認いただく必要がありますよね。
システム更新がしやすい
しっかりとしたドキュメントがあれば、はっきりと違いがわかるくらいシステム更新がしやすいです。
だって、既存のシステムの仕様がシステムを見なくてもわかるから。
システムがどう動くのか、実際にシステムを見ないとわからないなんて状態になるといろんな工数がかかってきます。
システムを確認するためには誰も使用していない定時後に行う必要性が出てくるかもしれません。
この工数はあくまでも更新のための既存システムの調査であり、縮小したほうが良いに決まっています。それよりは新しいシステムについて工数をかけたほうがよっぽど良いのは明らかですよね。
いかがだったろうか。
ドキュメント(記録)は形式問わず、絶対にあったほうがよい理由を説明しました。
残念ながら一部のエンジニアはドキュメントを適当に考えています。
システムが顧客の言った通り動けばよい。言った通り修正すればよい。と思っている方が少なからずいます。
でも残念ながらドキュメントを適当に扱うと、将来のトータルの費用が数倍に膨れ上がります。
ドキュメントは組織の重要な資産なのである。
では、また。
コメントを残す