突然ですが、仕事をしていて怒りを感じたことはありますか？
私はITエンジニアの仕事をやっているのですが、無能でできないダメ系なので、他人に怒りを感じさせてしまっているかと思います。
チームで仕事をやっているメンバーの方々にはご迷惑をおかけして本当に申し訳ございません。
そんな無能な私でもチーム開発をしていると他のメンバーに怒りを感じてしまうこともあります。
無能なお前ごときが何言ってるんだ？
ということになってしまうのですが、この記事ではITエンジニアがチーム開発で怒りを感じたことを5選紹介します。
私が怒りを感じてしまった人が無能ということではありませんので、その点はご留意して記事を読んで頂けましたら幸いです。
ITエンジニアがチーム開発で怒りを感じたこと5選
1. Gitで上書きpushされた
プログラミングを使ってチーム開発を行う場合は、ソースコードや変更履歴を管理するためにGitを使うことが多いと思います。
私がITエンジニアとして参画している案件でも多くはGitを使用してバージョン管理しておりますので、チーム開発で同じソースコードを修正する場合は、事前に修正する旨を伝えるなど声をかけあったり、他の人がpush済みであった場合はコンフリクトを解消したりすることは日常茶飯事の出来事だと思います。
そんなある日、事前に周知していたのに私がpushしたソースコードのファイルが完全に先祖返りしてしまって私の修正がなかったことになっていたことがあります。
なぜそれに気づいたかというと、チームメンバーのプログラミング実装が完了して、さてテストをするぞ！といったときに、私の実装した機能が全く機能していなかったので、最新のバージョンを確認すると、私の修正した箇所が広範囲に渡ってほぼ上書きされて、ソースコードが私の修正する前のバージョンになってしまっていたのです。
メンバーに確認すると私の修正したファイルを誤って上書きしまったということなのですが、私がpush済みなのでpushする前にコンフリクトが起きたり、上書きしてしまった人のローカル環境では最新バージョンではないため、普通にはpushできないようになっているはずですが、よくわからないけどpushして上書きしてしまったということです。
恐らくは、差分を確認することなく強制pushでもしたのでしょう？
その人は元に戻し方がわからないということでしたので、Gitのバージョンを戻すなどして最終的には正しい形にpushすることで事なきを得ましたが、自分がpushした内容が完全に上書きされてなかったことにされてしまったら誰でも怒りを覚えるのではないでしょうか？
その時はGitに履歴が残っていたし、私のローカルにも修正したソースファイルが残っていましたので、いくらでもなんとかなったので怒りをぶつけるようなことはありませんでしたし、
ダメ系ま～そういうことってあるよね。（いやいや、普通にやってたらそういうことはないけど）
で済ませることができました。
でもリモートブランチを完全削除されて私のローカルブランチにも修正したソースファイルが残っていなかったり、私の修正した履歴を完全削除されてしまっていたら、激昂という名の鉄拳が飛んでいたかもしれません………。
2. 仕事中に隣で居眠りされた
仕事中に隣の椅子に座っている人に居眠りをされたことはありますか？
私はされたことがよくあって、居眠りされると
ダメ系なんでアイツは居眠りして楽をしているのに自分は居眠りできないんだ？
とモチベーションが下がってしまったり、居眠りなのでクビがコクリコクリ…と動くので、視界に入って集中できないので怒りを感じてしまうことがあります。
怒りを感じてしまうなら直接言えばいいじゃん？ということですが、客先常駐エンジニアなので直接他社に人に注意するというのはなかなか言いづらいですし、PMに言うのも告げ口をしているみたいで言いにくかったりするので怒りを抑えて我慢することが多いかもしれません。
学生時代は居眠りしている友人になんで居眠りしているのか理由を聞いたことがあったのですが、そのときは
朝までオンラインゲームをやっているから
と話されていたので、そういった持っても他の理由だったら怒り心頭だったでしょう。
ただし、居眠りしている人に限って仕事ができたり、管理職で会議が多くて忙しかったり、ナルコレプシーは睡眠障害の病を患っていたりしている場合もあるので、居眠りに対してそこまで大きい怒りを感じることはありませんが。
3. バックレされたメンバーの責任を押し付けられた
PLがメンバーに厳しくしたせいでメンバーがバックレしたときに、そのPLでなくチームメンバーの私に責任を押し付けられてバックレしたメンバーのタスクも私に全振りされたときは怒りを覚えてしまいました。
最終的にはバックレしたメンバーのタスクを含めて期限内に消化することはできたのですが、想定外の残業が発生してしまったことで炎上プロジェクトになりかけましたので…。
4. 設計書を印刷したのに中身を見ないで突き返された
まず私が嫌いな文化なのは設計書を紙で印刷するということです。
クライアント先に出向してみんなで確認するために印刷して持っていくということならまだ分かりますが（セキュリティの問題でこのご時世、それもないか）、自社でみんなで確認するなら大きなモニターに映してすればいいし、個別でレビューするなら自分のPCでファイルを開いて確認すればいいじゃんって話です。
ですが、過去に上司だった人は
俺が設計書をレビューするから紙で印刷して机に置いておけ
と言われて毎回10枚ぐらいの設計書を印刷する必要がありました。
もうこの時点で印刷する時間が無駄だし、紙が無駄です。どうせレビューが終わったらシュレッダーにかけることになるんですから…。
そして、一番怒りを覚えたのは、設計書の中身を見ないで表紙や1ページ目を開いて
この文字のフォントがおかしい
ここのインデントがずれている
接続詞が適切ではない
などの体裁のレビューだけみて肝心な内容をレビューしないで突き返されて、また修正して10枚以上の印刷をし直すという、無駄な作業をその人のレビューで毎回やらされるということです。
本当に無駄でした。紙も時間も何もかも…。
体裁が悪いというのは私にも原因はあったとは思いますが、他の人にはその程度のことは指摘されたことはありません。
結局、印刷した設計書は最後までまともに設計書の内容を見てもらえることは少なく、レビューで指摘を受けるべきことが修正されないことで下流工程で問題が続出するということが多く、自分にもその設計書をレビューしてもらった人にも怒りを感じてストレスでした。
5. 他人が作成した間違いだらけのテスト仕様書で実施を依頼された
ITエンジニアをやっていると様々な業務を担当することがあります。
ウォーターフォール開発では、要件定義、設計、プログラミング製造、単体テスト、結合テスト、総合テストというような流れが一般的だと思いますので、ITエンジニアはプログラミングだけでなく、完成したものに対してテストを行うことも多いです。
そのテストは、仕様を理解した人が要件定義書や設計書を元にテスト手順や正しい結果が記載されたテスト仕様書でテストを実施することになります。
そのため、テスト仕様書を作成する人とテストを実施する人が別であることも多いので、テスト仕様書に書いてある手順や期待する結果が間違っていると、実装したプログラミングが間違っているのか？実装したプログラミングは正しいけど、テスト仕様書が間違っているのか？テストをする人は何が正しいのか判断できないので、テスト仕様書を作成した人にいちいち聞かなくてはなりません。
基本的にはテスト仕様書の内容が正しい前提でテストを実施するので、間違いだらけのテスト仕様書だと1項目のテストを実施するごとに
ダメ系あれ？結果がおかしいな？
と仕様書を作成した人に聞きに行って
すみません。テスト仕様書の間違いでした。
となって、また次の項目で
ダメ系あれ？この結果もおかしいな？
ダメ系仕様書のテスト手順の通りの操作ができないだけど
ダメ系っていうか、時間をかけて作成した大量のテストデータなのに仕様書が間違って実施できねえじゃねえか (ﾟДﾟ)ｺﾞﾙｧ!!
というテスト仕様書を作成した人に対して怒りを感じてしまうことになります。
これは他人事ではなく、テスト仕様書を作成する際に他人には分かりづらかったり、間違えていることに気づかずに作成してしまうことは多々あるので気を付けたいところではあります。
まとめ
この記事では、ITエンジニアがチーム開発で怒りを感じたこと5選を紹介しました。
人間なのだからチームで開発していれば自分と異なる考え方を持った人もいるし、人間なのだからミスをすることもありますので、怒りを感じてしまうこと誰しも避けられないことだと思います。
この記事に書いたことは一例ではありますが、他人に怒りを感じされてしまうようなことはなるべくしないように意識して仕事をするように心がけた方がチームでみんなで開発する上で良いでしょう。
私なら自分がレビューするからという理由で設計書を紙で印刷させるという苦行は他人にさせたくないですね…。
また、怒りを感じてしまっても感情をコントロールして激昂はしないようにしましょう。
このご時世、激昂してしまったらパワハラ判定されてしまうことになりかねませんので…。
