真面目で優しいシステムエンジニアは損をする17~当事者意識~
どうも！ヒグッティ(ヒグッティ＠システムエンジニア)です！
私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回は会議と抱え込みについての話について書きました。
今回も引き続きデータ移行の話です。では、お楽しみください！
今回の記事で言いたいこと
- 会議5分前に会議のすべてを丸投げされることはよくある。
- 資料が見づらいと言う人に限って、見やすく直そうとしない。口だけの時が多い。
- 関係チームが多くなる会議はほとんどみんな内容を聞いていない。共有できていない。
- 別チームが開催してる作業は当事者意識が薄れがち。関係のある作業ですら話を聞いていないこともある。
- 突発的な作業が増え続けることはかなりメンタルに来る。終わりが見えないと気力も失う。
当事者意識
6月に入り、移行が更に忙しくなりました。
6月中旬の模擬移行テストに向け、準備が進められていました。この時期の勤怠状況は9時〜23時30分がデフォルトでした。その内、8割は会議やメンバとの会話、相談でした。私が作業できる時間は良くて1日2〜3時間くらいでした。
この時期になると模擬移行テストのため、様々なチームと連携をとりながら作業を進める必要がありました。どのタイミングでどのチームが何の作業をするのかを見える化しなければなりません。この作業は沖縄さんがやってくれました。連携を取る必要があるチームは大きく分けて5チームでした。
・PMチーム：仲間さん、PMさんのいる管理チーム
・インフラチーム：ノッポさんのいる環境構築チーム
・運用チーム：猪鼻さんのいるチーム。バッチの実行やリソース監視をする。
・既存保守チーム：現在稼働しているシステムを保守しているチーム。陽気さんがいる。
・アプリ開発チーム：ヒグ率いるアプリを開発するチーム。
この5チームで模擬移行テストで何をやるのか、どのようなタイムスケジュールなのかを決めていきました。ちなみに長時間の打ち合わせを何回もやりました。平均すると3時間の打ち合われを5回くらいはやりました。
以下、打ち合わせのやり取りなどを記載します。
最初の会議のちょっと前のこと。
PM：今日は模擬移行テストに向けての最初の会議です。今まで沖縄さんやヒグさんに用意してもらった資料を元に全体の流れを説明します。基本的には私が説明します。必要に応じてヒグさんに聞くこともありますが、その時はお願いしますね。
ヒグ：了解です。
その後、会議の5分前になって、、、
PM：ヒグさん！！ゴメン！前の打ち合わせが長引いて終わりそうにない！だから模擬移行テストの説明会はヒグさんやってくれない？
ヒグ：えー！！全然準備してないんですが…
PM：大丈夫！計画書に書いてある概要と模擬移行テストでこんなことする予定ですって言えば大丈夫！あと、他のチームの人に作業の過不足がないか確認しておいね！
ヒグ：はぁ…わかりました（まじかよ…この会議、PMさんに全部任せてたから何も資料とか見てないぞ…やばいな…沖縄さんは別プロジェクトの打ち合わせでいないし…しょうがないか…）。会議の時間をずらしたりとかはできないですか？
PM：無理だね！色々な人の時間を調整してもらってるから、できませんでしたなんて言えないよ！
ヒグ：了解です…
そして、模擬移行テストの最初の会議が始まりました。参加メンバは以下です。
・PMチーム：仲間さん
・インフラチーム：ノッポさん、ノッポさんの部下
・運用チーム：猪鼻さん
・既存保守チーム：陽気さん、ジャムおじさん（既存保守チームのPM的な存在）
・アプリ開発チーム：ヒグ、
ヒグ：本日はお集まりいただきありがとうございます。早速、模擬移行テストについて、説明していきたいと思います。作業に過不足などありましたら都度教えて下さい。では早速こちらの資料から〜
といった具合に説明していきます。
流れはこんな感じ
1.移行全体の概要や目的
2.本番での移行方法の説明
3.システム切替までの移行のスケジュール
4.模擬移行テストでやること
5.模擬移行テストでの作業の過不足の確認。
4までは問題なく説明していました。問題は5でした。
ヒグ：では模擬移行テストの作業について説明も終わったので、作業について足りないと思うことや順番を変えたほうがいいと思うことなどあれば教えてください。
ジャムおじ：そもそも既存保守チームって作業あるんですか？
ヒグ：えっ…はい。あります。この資料に書いてあります。
ジャムおじ：えっ…どこ？
ヒグ：この資料のこのセルに書いてありますよ。
ジャムおじ：そーゆーこと？資料が見ずらいからわからなかった。
ヒグ：申し訳ありません。作業としては問題ないですか？
ジャムおじ：いやいや、私に今聞かれてもわからないよ！陽気さんこれどう？
陽気：ちょっと確認しないとわかりません。
ジャムおじ：だよねー。ヒグさんちょっと確認します。ちなみに何でこの作業がここに入っているの？
ヒグ：（あっ面倒くさい展開になるやつだ。つか資料見とけよ…）…。それは、システムのデータを合わせるために一旦システムを停止する作業です。なので〜
（ここからのやり取りは私とジャムおじさんで15分くらい質問と説明の繰り返しでした）
ジャムおじ：なるほどね。わかった。陽気さん！今のも考慮して考えておいて！
陽気：はい。わかりました。
ヒグ：すみません。会議の途中ですが、時間になってしまいました。本日はひとまず解散とさせて下さい。ありがとうございました。
という感じで何とか会議を乗り切りました。結局、最後はジャムおじさんに説明して終わりましたが…ちなみにジャムおじさんはPMさんと同じ会社なので私から見たらお客さんですね。陽気さんは協力会社らしいです。なので陽気さんと私は同じような立場の人間です。そしてジャムおじさんもPMさん同様、あまり技術に詳しくなく、業務にも詳しくないのでした。結局は下に丸投げですね。でもPMさんよりは業務を理解している感じでした。
会議が終わったのもつかの間、仲間さんから呼ばれました。
仲間：さっきの説明会は何だったの？
ヒグ：何かおかしいところありました？
仲間：おかしいというか、説明会ではなかったよね？
ヒグ：説明会というか、みんなで作業の抜け漏れがないかの確認会みたいな感じでしたね。
仲間：そうだよね。私はてっきり説明会と思って聞いてたから違和感しかなかったよ！説明会って普通、移行の作業や順番が全て決まった状態でそれを説明するよね？正直、具体的には何も決まってなくて心配なんだけど？
ヒグ：申し訳ありません…PMさんとは会議の流れを確認していたのですが…
仲間：そうなの？ちょっとPMさんを呼んできます！
その後すぐ。
PM：そうですね。会議の内容としては私がヒグさんに指示した通りです。私が会議のテーマを説明会にしたのがまずかったな…申し訳ない！
仲間：テーマとかはどうでもいいんだけど…今のままで大丈夫？移行について全然決まってない方が問題じゃない？
PM：そうですか？これから各チームですり合わせていけば大丈夫ですよ。
仲間：正直、このまま模擬移行テストに入っても意味ないと思うの。だって作業内容とかみんなで共有できてないし、失敗は目に見えてるよ？
PM：それはこれから共有していきますよ。それに今日もみんなで作業を共有したんでしょ？ヒグさん？
ヒグ：はい。しかし、皆さんの反応を見ると理解してもらえたかは微妙なところでした。
PM：でもこっちは移行の資料とかは全部展開してるでしょ？
ヒグ：3日くらい前には展開してます。
PM：だよね。それで資料見てませんとか内容知りませんは許されないよ(笑)
ヒグ：まぁそうでよね。（正直、誰も資料見てないな…多分自分に関係するところくらいしか見てないと思う…）
仲間：とにかく、もっと詳細まで共有しておいてくだい。今日の内容では模擬移行テストを実施させませんよ。
PM：わかりました。
仕事は色々な人と進めるものですが、巻き込む人が多くなると当事者意識が薄れていくんですよね。今回みたいに、いくらうちの移行チームが色々説明しても他チームは別の作業があるし、本気で移行について考えてくれないんですよ。だって移行は本業じゃないから。みんな言われればやるけど、自分からこうしたい！など議論を深めたり作業を効率化しようとは思っていませんでした。
多分、移行については他のチームはお金や工数をもらってないんだろうなぁと思います。憶測ですけどね…体制が悪いと言えばそれまでですが、どうすれば良いか未だにわかりません。
私は仲間さん、PMさんと他の関係チームとの板挟みになっていました。正直、これが1番のストレスでした。お客さんからもっと共有して精度を上げてほしいと言われ、他のチームからは作業について聞いても特に反応がなく「見ときます！」としかいわれない…そしてまたお客さんに怒られる…負のスパイラルでした。しかし、沖縄さんが仲間さんと色々調整してくれたのでかなり助かりましたが、最終的には私に色々と降り掛かってきました。リーダだからしょうがないかもしれないけどね。自分の作業、他のメンバのフォロー、スケジュールの管理、お客さんとの調整、、、やる事がありすぎる…そしてゴールが見えない…ストレスで倒れそうでした。
こーゆー時によく「作業の優先順位をきめろ」とか「その日にやることを一覧化しろ」って言うと思います。私はよく言われてました。でもこの時、これらができていませんでした。理由はやる事が横槍的に増え続けていたからです。
会議の度に「資料の修正」、「各チームとの再調整」が発生し、チームメンバからは都度、問題の報告が上がってきたり方針について話し合ったりお客さんと共有したりと突発的な作業が止まりませんでした。そして、自分の作業は後回しになり、残業や休日でギリギリカバーしていました。
タスクをこなしても次から次へとタスクが増えていくことはかなりのストレスでした。延々と100m走を走り続ける感覚でした。いつになったら終わるのか？そしてさらに追加される100m走…でも止まれない…解決策もなくただひたすらタスクをこなす日々でした。
模擬移行テスト？
6月中旬になり、いよいよ模擬移行テスト直前となりました。しかし、状況は変わらず準備不足なままでした。それでもPMさんだけはやる気満々でした。PMさんのメンタルは尊敬します…
模擬移行テストは日曜日に実施予定でした。その3日前に仲間さん、PMさんと会議をしました。
仲間：模擬移行テストですが、このままでは実施できません。決まっていない事や調整できていないことが多すぎます。
PM：そうですか？わたしは問題ないと思っていますが。
仲間：じゃあ各チームに調整がついていますか？何をもってこのテストを実施可能と判定するのか決めていますか？何をもってテストが完了したと言えるのか基準は決めていますか？何も決まってないでしょ！！
PM：でも作業としては準備してますし、今更中止にはできないですよ！
仲間：今回の模擬移行テストはエンドユーザにも結果を報告しなきゃいけないんだよ？テストに向けての実施判定の資料を作ってエンドユーザに承認してもらわないといけないんだよ！？できてるの？
PM：いえ…できてないですが…エンドユーザには事後で承認してもらえるように調整するつもりです。
仲間：事後で承認なんてありえないでしょ！！今回の模擬移行テストは中止です。今回はヒグさんのアプリ開発チームの内部のみでテストを実施してください！！
この会議は模擬移行テストを延期するようにPMさんを説得するための会議でした。私の目から見てもテストの実施は厳しいと思っていましたが、PMさんの意向を組んで無理矢理、準備を進めていました。仲間さんも準備不足であるようにみえていたようです。
私は今回のテストはエンドユーザにも報告が必要とは聞いていませんでした。しかも、そのために資料を作成しなければいけないことなども知りませんでした。PMさんは資料を作るのを忘れていたのか知りませんが、資料はできていなかったようです。
正直、移行テストでここまで管理するのはどうなんだ？とは思いましたが、品質の担保が大事らしいです。私的には品質の担保をしているというよりかは何をやっているかの報告に見えました。いくらそんな資料を作っても、エンドユーザがその資料を見ても品質はあがりません。作業するための時間が報告資料を作成する時間に搾取されてしまうだけと思いました。
実際、ドキュメントを作成することはエンジニアを守ることになりますが、時として自分の首をしめることにもなります。ドキュメントの作成時間が取られることもそうですが、書いたことを担保しなければなりません。ドキュメントによっては日本語の受け取り方次第で意味が変わってしまうこともあり、トラブルの元になることもあります。今回はまさにこれですね。ドキュメントを大量に作ったのはいいが、結局指摘されることは日本語の使い方や表現についてのみです。ドキュメントの品質は上がるかもしれませんが、本当の作業の品質は置いてきぼりにされてしまっていました。
それでも、作業が失敗しました！作ったスクリプトが動きませんでした！とは言えないので、休日、残業でカバーしなくてはなりませんでした。
結局、日曜日は内部だけで模擬移行テストを実施しました。もちろんテストは失敗しました。初めて全体の作業を通しで流しました。予想外に時間のかかる作業があったり、そもそも作業が抜けていたり…散々な結果となりました。
特に良くなかったことは既存システムとの平行稼働させることでした。既存システムで処理したファイルなどを新システムにも持ってきて取り込み、既存と新で同じようにシステムを動かしました。模擬移行テストの初日に処理を動かしましたが、夜のバッチ処理で処理が失敗しました…この原因や解決方法は次のブログに書きたいと思います。
今考えると、関係チームとの調整や無理なスケジュールで私は自分の意見や考えを押し殺すようになっていました。何か言っても意見は通らないし、無理矢理でも作業を終わらせるような解決案しかお客さんは認めなくなっていました。無理な物は無理！！と大声で叫びたかったですね…それが言える人は仕事ができる人なのかもしれない。会社の上司や先輩に相談しても「あと少しだから頑張ろう」としか言われなくなっていました。私のアラートも弱かったのかもしれません。
それでも毎日夜0時20分頃に帰宅し、東海オンエアの動画を見てがんばれていました。