真面目で優しいシステムエンジニアは損をする⑨~不整合~
どうも!ヒグッティ(ヒグッティ@システムエンジニア)です!
私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回は崩壊しながらもギリギリのプロ ジェクト状況の話について書きました。
今回は仕様書とソースの不整合についての話となります。ではお楽しみください。
不整合
システムテストを実施している中で、別の問題も発生していました。それは改修要件がわからないことでした。
システムテストで、シナリオを作成しているときに要件定義リストを見返している時のこと。要件定義リストの一番下の行に見覚えのない改修要件がありました。あれっ?こんな要件あったかな?分析機能に新しいサービスの追加対応としてその行がありました。すぐに優男さんに確認しました。
ヒグ∶こんな要件ありましたっけ?分析機能に機能を追加するようなんですけど。
優男∶覚えてないな…でもこの改修は1月から4月までの間にやることになってるよね。
ヒグ∶はい。しかし、要件定義リストに書いてある内容では何をすれば良いかわからなくて…
優男∶えーっと、何て書いてあるんだ?「新しいファイルの項目を分析処理できるようにDBに取り込んで分析できるようにすること」か…
ヒグ∶これは見積もりの時、どうやって作業時間とか見積もりしたんですか?
優男∶忘れた。基本的に納品物ベースでスケジュールとか見積もりとかしたからなー。納品物に要件定義リストの作業を一つ一つ細く見てない。
ヒグ∶そうですか…(見積もりってそれでいいのか?他にも見落としてることがあるんじゃ…)
優男∶とりあえずお客さんにも聞いてみて。
ヒグ∶了解です。
次はPMさんに話を聞くことにしました。
ヒグ∶要件定義リストのこの行なんですけど、何をやればよいかわからなくて…
PM∶私もわからないなぁ。実はこの要件定義作ったの私じゃないんだよ。
ヒグ∶えっ…そうなんですか?
PM∶うん。これを作った人はもういなくなっちゃったのよ。私は要件定義が終わったところからやってるだけ。
ヒグ∶えー。(このプロジェクト大丈夫か?やたら関わった人がいなくなってる気がするんだが…)
PM∶でもこの要件だけ見ると分析機能に新しいサービスで取得した項目を使えるようにするだけでしょ?
ヒグ:そうですね。それだけはわかるんですけど、具体的に何をすればよいか全くわからなくて。分析機能で現在使っている項目の資料などありませんか?
PM:ないなぁ…私は分析機能については全く分からないんだよねー(笑)そもそも、今回やることは、分析機能で新しいサービスに取り込むファイルをDBに取り込んで、それをWeb画面に表示するだけでしょ?ファイルの項目仕様書から分析機能に必要な項目を洗い出してエンドユーザにどの項目を分析機能で使いたいですかって聞くしかないかなー。
ヒグ:なるほど…(また、作る資料が増えたよ、、)。ファイル項目仕様書から洗い出してみます。分析機能の仕様書がなくて、ファイル項目仕様書とソースから調査してみます。また後でご報告します。
PM:お願いします。
その後、ファイル項目仕様書をもとにどのファイルのどの項目が分析機能で利用しているのかを資料にしました。ところが、ファイル項目仕様書の項目と分析機能で利用している項目が一致しないのです。ファイル項目仕様書が古いのか?分析機能のソースが古いのか?とにかくまずいことだけはわかりました。他の人にこの仕事を任せたいところでしたが、全員、手がいっぱいで仕事を振れず、、分析機能と新しいサービスの追加の両方の仕様を知らないと解決できない問題でした。ここにきて、メンバ交代をしまくった弊害が出てしまったのです。
ヒグ:PMさん、ファイル項目仕様書と分析機能のソースを見たんですけど、項目が一致しないんですよね。 ファイル項目仕様書か分析機能のソースのどっちかが古かったりしませんか?
PM:そうなの?俺は仕様書とかソースとか知らないな。既存保守メンバに聞いてみてよ。
ヒグ:了解です。(ほんとこの人何も知らないんだなぁ、、この先、大丈夫かな?)
この後すぐに既存保守メンバにこのことを聞きました。既存保守メンバの方を陽気さんとしてます。(チャット会議で声しか聴いたことがない。声が明るいから)
ヒグ:陽気さん、このファイル項目仕様書と分析機能のソースを見比べたんですが、不整合があるように思えます。ファイル項目仕様書にない項目がソースにあるんですよ…何か知りませんか?
陽気:いえ、こちらでも調査してみないとわかりません。しかしファイル項目仕様書は最新で間違いないです。ソースも最新で間違いないようです。少しお時間いただけませんか?
ヒグ:わかりました。お手数ですが、調査をお願いします。PMさん、この案件は1月~3月で設計から内部結合テストを完了させ、4月はシステムテストをします。最悪はリスケするかもしれません。今、1月上旬なので大丈夫と思いますが。
PM:了解。その時はスケジュール調整よろしく!
ヒグ:は、はい、、
それから2日ほどしてから陽気さんから連絡が来ました。ファイル項目仕様書もソースも問題ないとの回答でした。まじかー!!ありえない!!絶対、どっちかに間違いがあるはずなのに、、そんなことも言えず、、PMさんにも相談しましたが、取り合ってもらえず、誰にも相談できない状況になってしまいました。私の予想としてはファイル項目仕様書が古かったです!って回答が来ると思っていたのですが、、
私は他のチームメンバに相談しましたが、そもそも分析機能がわからないので判断ができないとあっさり逃げられてしまいました。若干孤立してしまった感じがしました。しかし、このままでは、問題は解決しません。私は今できることをやろうとしました。それは、「ソースからファイル項目仕様書を作成すること」でした。ソースから詳細設計書を作成したりはするのですが、ファイル項目仕様書まで作成するのはやったことがありませんでした。面倒くさい、、、項目数はざっと180個くらい。作れなくはないけど、システムテストもあるしなぁ。やるしかない。PMさんを説得し、この作業を開始しました。もちろんシステムテストが終わった19時以降からしか作業できないけど(笑)
ヒグ:PMさん、最新のファイル項目仕様書ができました。やはりファイル項目仕様書は古いです。ソースの改訂履歴で2年前に分析機能に大きな改修がありました。おそらくその時にファイルの項目が大きく変わったと思います。
PM:そうなんだ。私は2年前は別のプロジェクトやってたからなー。では、そのファイル項目仕様書をもとに分析機能で今回必要な項目を洗い出してエンドユーザへの資料を作成しましょうか。
ヒグ:了解です(この人、ファイル項目仕様書の確認はしないのか?)。既存項目と新しく追加になる項目を明記しますね。その中から、必要な項目をエンドユーザさんに選んでもらえれば何を作ればよいか見えてくると思います。
PM:そうだね。ぶっちゃけよくわからんけどよろしくお願い!
ヒグ:了解です。
この後、既存項目と新しく追加になった項目(新規項目)を1つの資料にまとめました。この資料を作成するのに1週間かかりました。資料自体は1日で完成したのですが、PMさんのレビュー→指摘を修正→PMさんのレビュー→指摘を修正→仲間さんのレビュー→指摘を修正といった具合に手厚いレビューをやってもらいました、、、エンドユーザに出す資料なのでチェックを厳しくやらないといけないらしい。結局、資料を作って修正するのは俺なんだよな~。しかも既存のファイル項目仕様書がメンテナンスされてないのを修正したのも私なんだけど、、もちろんこの工数はもらっていません。お客さんに聞いたら「必要な作業だからしょうがないよね」って言われてしまった。こんな感じで既存システムのドキュメント整理や確認をしながら本来の設計、開発作業もこなすことになってしまいました。もちろんシステムテストも並行しています。
1月も下旬になっていました。こんな調子で分析機能の追加は3月までに内部結合テストが終わるのか?不安は増すばかりです。既存システムのドキュメント不備に工数を持っていかれているにも関わらずPMさんは設計に必要な作業だからとしか言わないし。せめて何か作業をトレードオフしたい。ちなみにトレードオフの話をしたら怒られました。「そちらの会社に任せた作業なんだからやって当然でしょ!トレードオフするなんてありえない!」と。
この日も遅くまで作業。システムテストと分析機能の資料作成、、きついなぁ、、誰も理解してくれない状況って結構心にきますよね。帰宅後、東海オンエアを見て就寝。なんか久しぶりに東海オンエア見たな。やっぱり面白い!!
まとめ
簡単に書いてある1行が1番重い改修になったりする。
ソースと仕様書は不整合になりがち。メンテナンスされていないことも多い。
ソースに改訂履歴書きがち(個人的にあまりすきじゃない)。でもやっぱり役に立つ。
既存システムのドキュメントがひどいことがよくある。なぜか開発しているチームが既存システムの
ドキュメントを修正している。
工数の話になるとお客さんにあしらわれてしまう