ITコンサルの日常

ITコンサル会社に勤務する普通のITエンジニアの日常です。

引継ぎ満載

今年いっぱいで撤退する予定なので、今引き継ぎ真っ盛りです。にしても、引継ぎするのに新しく資料を起こしているのは、ちょっと疑問。。もちろんドキュメント整備が出来てないってのが一番の原因ですけど。じゃあドキュメントを作るにしても、分かりやすい資料ってどうやれば作れるのか、未だに分かってないのが現状。そもそも、短い引継ぎ時間の間にどれだけのことが引き継げているのか。漏れはないのかが大変不安です。
最近よく聞かれる言葉で、トレーサビリティってのがありますが、要は要件→設計→実装っていう風にたどれること。つまり、どの要件がどの設計書に該当して、それがソースコードのどこに該当するかっていうのが、すぐに判明するようにリンクしておくことだと理解しています。昔、Rational Unified Process(RUP)の勉強をしたときに、やっぱりトレーサビリティの重要性って説かれていたような気がするなぁ。ただ、RequisiteProとかいうそれ用のツールはあんまり使えなさそうでしたが。。
話は元に戻って、トレーサビリティ。結局稼動後のシステムの「正」はソースコードなわけだから、逆トレーサビリティを作ってあげれば、漏れなく設計および要件を洗い出すことが出来ると。テスト的に言えばC2カバレッジを取ればいいんですかね?(よく分かってない)
と、理想を言ったところで、いまさらソースコードと設計書がつじつま合っているかなんてチェックしてる時間がない!の一言で、まあ概要が分かればいいよね。という妥協点に落ち着くという。。なんとなく世の中の平均点以下に落ち着いてる気分。んーどうすりゃいいの?

  1. やっぱりドキュメントは適当。メンテナンスはおざなり。引継ぎで帳尻あわせ
  2. そもそもちゃんとドキュメントを書く!メンテナンスも必死でやる!
  3. ソースコードがドキュメント。ソースコードが雄弁に語りだす(のか?)