真面目で優しいシステムエンジニアは損をする⑦～崩壊～
どうも！ヒグッティ(ヒグッティ＠システムエンジニア)です！
私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回は人を大量に投入する話 について書きました。
今回は崩壊しながらもギリギリのプロジェクト状況の話となります。ではお楽しみください。
崩壊
12月に入りスケジュール通りに作業をこなしチームメンバもだいぶ作業になれてきたかと思っていた頃。
ヒグ∶今日もパーマさん休みかー。最近、パーマさん休み多いな…なんかあったのかな？
茶髪∶そうですね。心配ですね。週1~2日は休んでるね。体調悪いのかな？
ヒグ∶まぁ、パーマさんはスケジュール通りに作業してもらってるから問題はないんだけど…優男さんにも聞いてみるか！
ヒグ∶優男さん、パーマさんが最近休みがちなんですけど、何か知ってますか？
優男∶知らないなー。ちょっと心配だねーちょっと確認してみるわ。パーマさんのことは沖縄さんが色々と知ってると思うから聞いておく！
ヒグ∶ありがとうございます！
沖縄さんはうちの会社に派遣として来てくれている人。人との交渉がうまく、人望があつい。
パーマさんはそれからも休むことが多くなりました。沖縄さんも確認してくれましたが、パーマさんからは連絡が返ってこなくなってしまいました。
沖縄∶パーマさん、実は前の現場でメンタルをやられていまして…もしかしたら今回のこともそれが関係しているかもしれないです。
ヒグ∶えっ！そうだったんですか？
優男∶そうか…ヒグ、そしたらパーマさんの作業進捗を確認して！今からパーマさんの作業を引き継ぐしかないな。多分、もうパーマさんは厳しいかもしれないな…
ヒグ∶了解です。すぐに確認します。
すぐにパーマさんの作業を確認することにしました。パーマさんには新しいサービスの追加をお願いしていました。本来であれば内部結合テストが終わりかけている時期でした。急いで確認したところ、内部結合テストはほとんど終わっていませんでした。しかも一部の機能はコーディングすら終わっていない状況でした。12月いっぱいで終わらせなければいけない作業がこの時点でほとんど終わっていませんでした。パーマさんは優秀だし大丈夫だと思い込んで、私もあまり進捗確認をしていなかったのです。
さらに追い打ちをかけることがプロジェクトを襲います。それはボウズさんです。ボウズさんも12月に入ると休みがちになりました。
沖縄∶ボウズさんの所属している会社とボウズさんの間で問題が発生していようです。給料が未払いらしいです。その問題で、ボウズさんがストライキをしているようで、仕事に来なくなってしまったようです。
ヒグ∶そんな…
優男∶ボウズさんも駄目か…ヒグ、ボウズさんの作業進捗も確認して引き継ぎの準備をしよう。あと来年1月から2人新しく人を入れないといけないな。また面接するけど、ヒグは来なくてもいいよ。忙しいだろうから。
ヒグ∶はい…とりあえず2人の作業を確認して、引き継げるようにしておきます。
この後、ボウズさんの作業進捗を確認しましたが、オンスケでした。しかし、実際にできたソースやエビデンスを見ると中身が散々なことになっていました。ある特定のデータしかテストしていなかったり、コードの中に明らかにエラーとなるような書き方をしているにもかかわらず、その箇所をテストしていなかったりとひどいものが出来上がっていました。この時、コードレビューがあまりできていなかったことが裏目にでてきました。テストのエビデンスだけ見ると問題なさそうだったのでコードまで見れていなかったのです。日々、数機能もレビュー依頼が来ましたが、とても見れる時間がありませんでした。今、思うとコードレビューを他プロジェクトの人を借りてでも徹底的に実施すべきでした。
とは言え、考えている時間もなかったため、すぐにパーマさんとボウズさんの遅れを何とかすべく、対応を考えました。
ヒグ∶というわけで、パーマさんとボウズさんですが、12月はもう仕事に来れないことがわかりました。
茶髪∶そうですか…パーマさんとボウズさんの作業はどうしますか？
ヒグ∶パーマさんの作業はコーディングと単体テスト、内部結合テストが残っています。まずは、内部結合テストまでは今月中に終わらせて、お客さんにエビデンスを見せる必要があるため、最優先です。この作業は私とヘビさんでやります。またコーディングが終わっていない箇所については茶髪さん、お願いできますか？
ヘビ∶わかりました。今の作業と並行してできると思います。
茶髪∶了解です。やる事多いけど、しょうがないな！
ヒグ∶二人ともありがとうございます！ボウズさんの作業ですが、これは内部結合テストをしながら私が都度、対応していきます。ボウズさんの作業は新しく追加になった機能に関連した機能を変換することだったので、内部結合テストをしながら直していくしかないですね。
茶髪∶間に合うかなー？来年1月からシステムテストも始まりますよね？
ヒグ∶そうですね…かなりギリギリです…休日出勤も必要になってくると思いますが、皆さんお願いします！
こうして作業を割り振り、何とか12月までに諸々終わるようにスケジュールも更新しました。お客さんにも説明しました。さすがに、お客さんにも言われましたね。プロジェクト始まって4ヶ月で5人も入れ替えるなんて、どんな管理しているんですか？っと。まぁ当然ですね。正直、ボロボロでした。チームメンバの頑張りもあり、12月に終わらせなければいけないことはなんとか終わりました。残業、休日出勤のオンパレードでしたが。その間にも来年1月からのシステムテストに向けての準備も始まっていました。
自転車操業
パーマさんとボウズさんの件もありプロジェクトはかなりの忙しさでした。その中、PMさんから相談を受けました。
PM∶忙しいところ、申し訳ないんだけどいい？
ヒグ∶はい。大丈夫です。
PM∶来年1月から始まるシステムテストについて相談させて。
ヒグ∶了解です。
PM∶システムテストでやる事は考えてる？
ヒグ∶いえ、まだほとんど考えられてないですね…
PM∶それはまずいな(笑)まずはシステムテストと性能テストは2つをまとめて実証テストって呼んでるんだよ。で、まずは実証テストの計画書を作らないといけないのね。この実証テスト計画書は私が書くんだけど、その後、システムテスト計画書と性能テスト計画書はヒグさんの方で作ってもらうから！
ヒグ∶了解です。しかし、今、プロジェクトは人がいなくて、内部結合テストを実施するだけで精一杯なんですが…
PM∶それもわかるけど、人がいなくなったのはそっちの責任だからね。プロジェクト管理ができてないからだよ。だから計画書を作らなくてよい理由にはならないよね？
ヒグ∶確かに、仰る通りです…
PM∶ヒグさんが作業を持ち過ぎなんだよー(笑)他の人にやってもらってください！
ヒグ∶そうしたいのは山々何ですが…
PM∶とにかく計画書の件、お願いしますね。以前のプロジェクトで作ったやつをあげるんで参考にしてください。
ヒグ∶了解です。
PM∶計画書が終わったらテストシナリオも忘れずにね。テストシナリオは大事だから！私も細くチェックします！
ヒグ∶了解です…いつまででしたっけ？
PM∶12月末までにはテストシナリオまでほしいな！
ヒグ∶了解です。(まじか…チームメンバはみんな手一杯だし、俺がやるしかないか…)
この時から、私はスケジュールの異変に気づき始めました。最初からスケジュールがキツキツのため、ほぼ全ての工程で準備期間がなかったのです。しかし、準備しないわけにもいかず、今の作業と並行して次の作業の準備も進めなければなりませんでした。私は内部結合テストを実施しつつ、残業や休日で来年の準備も進めていきました。
ヒグ∶PMさんシステムテスト計画書ができました。レビューをお願いします。
PM∶はーい。どれどれ、まぁいいんじゃない。
ヒグ∶ありがとうございます。
PM∶テストシナリオは？
ヒグ∶こちらになります。
PM∶どれどれ、えーっとねー…ヒグさん、このテストシナリオじゃ何もわからないよ。たしかにこの機能をテストして、想定結果とかも書いてあるけどよくわからないよ。このテストシナリオはこのシステムやプロジェクトがわからない人にも伝わるように書かないと！基本だよ！
ヒグ∶申し訳ありません…具体的にわからないところってどこでしょう？
PM∶例えば…この機能のテストで使うファイルデータの中身とか何も記載がないよね？テストする人はデータの中身を知ってるかもしれないけど、私が見たら何をやっているのか全くわからないよ。このデータの中身をExcelに書いて、この項目がこれに設定しいてるから、結果がこれになるはず！って書くのが普通じゃないの？
ヒグ∶なるほど…確かに仰る通りです。(複雑なロジックが含まれている場合、書くのが面倒くさいなぁ、ファイルの中身の項目も全部書いてデータパターンを見える化しないといけないなぁ…)
PM∶あと、根本的にテスト対象が本当にこれで全部なの？
ヒグ∶はい。要件定義から確認しました。テスト対象はこれで全部です。
PM∶いや、そうじゃなくて…これがテストの全部であることをどうやって証明してるの？これでテスト対象は全部ですって言えるような資料を作らないと。テストシナリオだけじゃ判断できないよ。私は技術とか業務のことよくわかってないから、私にもわかるようなものをお願いします！
ヒグ∶わかりました…作るようにします。
PM∶あとシステムテストですけど、エンドユーザさんも参加することになったから！スケジュールはわからないけど、うちの主導でテストできるわけじゃないよ。なのでいつでもどのテストが実施できるように準備しておいて下さい。
ヒグ∶えっ…システムテストはうち内部で実施する予定だったはずです。ちなみにテスト対象も変わりますか？
PM∶そうだね。予定が変わってエンドユーザが早めにテストしたいって言うからさー。対象機能の開発も終わってそうだったからエンドユーザにはできますって返事しといた。テスト対象はうちが今やり取りしている他システム全てが対象になると思う。あー、一部対象外の機能もあるけど、とりあえずエンドユーザからもらった資料を展開しますね。
ヒグ∶了解です…
こうして、計画書やら追加の資料を作っていきました。テスト対象が問題ないかの資料は、これまた大変でした。機能一覧と要件定義を見比べて、新しいサービスが追加となる機能を洗い出し、機能一覧にその機能をマークします。さらにその機能に影響する機能や処理に関連する機能、画面を洗い出しました。機能一覧はCRUD図を元にどの機能が影響するのか、テーブルはどこを登録、更新、検索しているのかを洗い出し、資料としてまとめていきました。
文字で書くと淡白な書き方になるけど、マジで大変でした。200を超える機能をほぼすべて見ないといけなかったです。追加した新しい機能→新しい機能によって登録されたデータを利用する機能や画面→さらにそのデータを利用した機能、というように機能の前後関係も考慮しなければなりませんでした。お客さんと話す時点で、このくらいの資料を用意すべきだったのかもしれませんが、ミドルウェアの設定移行やメンバが会社に出勤しなくなってしまったりと余裕がまったくない状況でした。
何とか12月にシステムテストのテスト対象の資料は作成できました。また、他のメンバの頑張りで内部結合テストも完了できそうな目処が立っていました。6人の作業量を4人でこなしている時点でかなりすごいことだと思っていましたが、お客さんには中々言えず、なんとかスケジュール通りに進めてます！と回答していました。変な話、12月にチームメンバが2人ほどほとんど出社してませんっていうと、お客さんからじゃあお金返して下さいって言われたりするんですよね…あとは、来月以降も2人減った状態でもできますね！最初の見積もりは何だったんですか？的なことを突っ込まれたりします。なので騙し騙しやるしかありませんでした。12月はお正月休みもあり稼働が少なく厳しいかったですが、何とか目標のところまで終わりました。
なんだかんだで作業は予定通り終わっていました。チーム全員の力とは言えないですが、最低限のラインを何とか保っている状態てした。逆に誰一人欠けても今の仕事をこなせない状況でした。誰かがインフルエンザになったらどうなるんだろ(笑)この時点でカツカツのプロジェクトって(笑)
今年最後の出勤が終わり内部結合テストも終わり、システムテストのシナリオも完成していました。達成感と不安感の両方が混じったような何とも言えない感じでした。予定通り作業は終わっているのに、予定通りの感じがしない、常にすぐ後ろに何かいて、気を抜くとすぐに飲み込まれてしまうのではないか、そんな気持ちでした。
この日も東海オンエアの動画をみました。この人達も苦しいこととかいっぱいあるんだろうなーと思いながら就寝しました。
まとめ
コードレビューは必ず実施すること。当たり前だけど。
各工程には準備期間も工数に入れよう。
システムエンジニアは精神疾患になりがち。
誰にでもわかる資料を作るのは大変。
会議の度に作成しなきゃいけない資料が増えがち。