真面目で優しいシステムエンジニアは損をする16~会議と抱え込み~
どうも！ヒグッティ(ヒグッティ＠システムエンジニア)です！
私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回は データ移行についての話について書きました。
今回も引き続きデータ移行の話です。では、お楽しみください！
今回の記事で言いたいこと
- 会議の多いプロジェクトは要注意。会議のために資料を用意したり、議事録を作成するだけで時間が取られる。
- 拒否権のない会議がある。
- 作業は抱え込まない方が良いが、作業を振れる人が物理的にいないこともある。
- 作業を増やさないようにするには、お客さんからの依頼を断るが正解だと思う。私はできなかった。
- 作業をふりたくてもふれない状況がある。システム特有の仕様だったり、仕様を知らないとできない。
- 会議が長い時は、早めに終わらせた方がよい。理由は社内で別会議があるからと言えば大体通る。
会議多すぎない？
5月も中旬になりました。移行はまだまだ終わりません。というか始まったばかりです。6月中旬の移行模擬テストに向けて必死に作業を進めていました。
移行の中で作業分担をしていました。
茶髪：DB周りの移行手順書作成、処理のインプット、アウトプットを一覧にした資料の作成
沖縄：タイムテーブルの作成(タイムテーブルはいつ誰がなんの作業をするか時系列でまとめた資料)
ヒグ：その他(ファイル周りの移行手順書作成、モジュールデプロイ手順書作成、構成管理手順作成、バッチ実行定義書作成など)
茶髪さんの作業はとてもじゃないですが、終わりそうにありませんでした。システム全体で機能毎にインプット、アウトプットを一覧にする資料を作る必要がありました。全機能は250程ありました。当然一人じゃ終わらないですよね。なので他のプロジェクトの人にも手伝ってもらいました。この資料はお客さんが、「必要なので作ってください」と言われた資料でした。今思えば、お客さんは資料が完成しても中身すら見てなかったな…何のために作ったのか(笑)
私も日々会議に追われ作業ができない状況でした。私の1日の流れはこんな感じでした。
9時~10時：出社、その日のスケジュール確認。メールチェック。
10時~12時：会議（移行の進捗や問題点の共有）
13時〜15時：会議（別作業の進捗確認や問題の共有）
15時〜16時：チームメンバと会議の内容を共有、進捗の確認、サポート
16時〜17時：自分の作業
17時〜19時：お客さんやチームメンバと会議、または相談
19時〜23時：次の日の会議の資料準備、自分の作業、お客さんやチームメンバから突然呼ばれたり
私はプロジェクトリーダだったのもありますが、とにかく会議が多かったです。PMさんが会議をやる時は必ず私が同席するようになっていました。突然、エンドユーザとの会議に呼ばれたりもしました(笑)いきなり呼ばれて「この作業いつまでにできる？」みたいなことを聞かれたりしました(笑)その作業は全然聞いてないんですけどー！！もはや拒否権のない会議も珍しくありませんでした。また、別作業の会議もありました。他システムとのテスト支援やユーザ運用テストなどで上手くいかない時に呼び出しがかかりました。他システムとのテストはトレードオフで最初はやることがないと言われていたのに、いつの間にかうちが作業してるし…問題が発生した時はしょうがないですが…
会議して共有して自分の作業しての繰り返しでした。
また、会議が多いことも問題でしたが、会議が長いことも問題でした。1つの会議は大体1時間くらいでハードストップでしたが、エンドレスな会議は2〜3時間余裕でやってました。
なぜ会議が長くなるのか？それは深堀です。良く言えば深堀。悪く言えば忘れているです。こんな会議がありました。それはシステムテストのテストシナリオをレビューしている時の会議です。
ヒグ：テストシナリオはこれで行こうと思っています。資料にもシナリオを記載し、先程、説明したとおりです。
PM：了解です。テストシナリオはわかりました。あとはシナリオテストで何でそのパターンをテストするのかの説明がないですよ。
ヒグ：？
PM：私が何を言いたいかわからないのね…じゃあ説明しますね。テストって積み上げじゃないですか？単体テストでここまでを確認して、内部結合テストでここまで確認して、って感じで積み上げた上でシステムテストは何をすれば良いか考えますよね？
ヒグ：まぁ…確かにそうですね。
PM：ヒグさんの説明だと単体テストや内部結合テストで何をやってきたかが伝わりません。
ヒグ：はい…申し訳ありません。（えー、今更かよー！！内部結合テストでもPMさんからOKもらってるんだけどなぁ）
PM：なのでシステムテストのシナリオが正しいか今から確認しましょう。
ヒグ：えっ…今からですか？
PM：はい。単体テストのエビデンスやテストシナリオを見せてください。
ヒグ：はぁ…しかし、単体テストは弊社で担保することになってますし、PMさんが見てわかるような形式になっていないと思いますよ？
PM：それはまずくないですか？誰が見てもわかるようなエビデンスや資料にしておかないと！
ヒグ：はぁ…確かにそうですね。（やべっ、変なこと言っちゃった…）
PM：早く単体テストのシナリオ見せてください。
ヒグ：わかりました。こちらです。
ここから単体テストのエビデンスやシナリオを30分かけて説明。案の定、何が書いてあるかわからないと言われ。次は内部結合テストのシナリオやエビデンスを30分かけて説明…この流れを何回繰り返したことか…分かりづらいエビデンスや資料を用意したうちも悪いけどね…
PM：エビデンスやシナリオを見てもよくわかりません…このシステムテストのシナリオが正しいか判断するために別の資料を作ったほうがいいなぁ。
ヒグ：えっ…
PM：だって説明できないなら別の観点からアプローチするしかないでしょ？とりあえず全部の機能を一覧にして、今回のテストで対象になった機能を洗い出して下さい。で、その機能に少しでも関連する機能も洗い出してください。関連する機能を全てテストすることにすれば、説明としては筋が通ってるでしょ！
ヒグ：はぁ…しかし、今回のシステムテストは他システムとの連携テストも含んでいるので、ほぼ全ての機能を動かすことになります。そうなるととてもではないですけど終わらないです。
PM：そこは終わるようにスケジュールしてください。何回も同じ機能を動かさないように効率的にテストのスケジュールをするとか！マネジメントの基本でしょ(笑)
ヒグ：はぁ…わかりました…
こんな感じで会議が長くなっていました。会議の度に、過去に作ったエビデンスを再確認したり、指摘したりしてたら終わらないよね…私は会議を止めようとしましたが、お客さんはエビデンスを確認しないと次にいけないと一点張り。いつまでも終わりませんでした。これは移行作業でも例外ではありませんでした。作った手順書の元になった根拠や理由、エビデンスを確認し、説明していました。
今になって思えば、社内の会議があるのでー！！と言ってハードストップすればよかった。社内の会議って言えばなぜか許してくれるんですよね(笑)
作業を抱え込む人は無能？
よく上司から、「リーダは作業を抱えずに下にふれ！！」って言われます。ビジネス書とかにも書いてあるので当たり前だとは思います。私も同感ですが、実際は違いました。作業をふれる人がいないのです。移行で精一杯の茶髪さん、4月に入ったばかりで他の作業の開発中のクロさん、、、そう、振りたくてもふれない…未だにこんな時どうすれば良いかわかりません。お客さんからの仕事を断る！が正解だと思うのですが、私は押し切られていました。
また、ふりたくてもふれない作業がありました。特に振れない作業としてはシステム特有の作業です。システムの仕様や業務を理解していないと作業できないからです。
具体的にはバッチ処理の実行計画でした。このバッチ処理は何時に実行してとか、このバッチが終わったら、このバッチ処理を実行してなど、バッチ処理の時間やタイミングを決めなければなりませんでした。この実行計画をお客さん先の申請書に記載して専門の部署に申請しなければなりませんでした。PMさんはやり方がわからないので、私がやる羽目に…私も申請書の書き方がわからなかったため、専門部署の人に聞きながら作成しました。
作業をふれる人がいない。システムの仕様を理解している人がいない。どんな作業か指示できない。これでは作業がふれないよね…
よく仕事をふれない人は仕事ができないとか言われますが、私はそうは思いません。プロジェクトの背景でどうしても作業がふれない状況もあります。なので私は仕事ができるできないはプロジェクトの背景を理解した上で判断するようにしています。
結局、このバッチ処理の実行計画の作業は私がやりました。できる人がいないんだもーん！！あと移行や開発のスケジュールは組まれてるのに、実行計画の作業みたいな細かい作業はスケジュールに組み込まれてないんですよね…なので作業が完了したところで実績を書くところも無いからお客さんとしては「何でおわってないの？すぐ終わる作業でしょ？」くらいにしか考えていなかったと思います。私の感想ですが(笑)
こんな調子でも作業は進めていました。茶髪さんやクロさんは極力、会議に出席させず作業に集中してもらっていました。本当は会議に出席してもらい巻き込んだ方が良かったんですが。あまりに、時間の長い会議が多かったので私や沖縄さんだけで参加し後でチームにフィードバックしていました。
そして6月になろうとしていました。模擬移行テストを実施すべく、関係チームと連携をとり作業を明確にしていきました。この関係チームとの連携の話は次回にしたいと思います。
この頃になると私の体も異変だらけでした。朝が起きれなくなっていました。さらに起きれたとしても会社に行けなくなったりしました。朝、30分くらい休まないと出社できなかったり。体が重いのもありますが、メンタル的なところが大きかったですね。本当に会社に行きたくないって気持ちが心と体に出てしまったんだと思います。それでも目標に向かって、作業を止めることはできませんでした。納期は日々決められており、遅れたらさらにリカバリを考えたり、資料を作ったりしなければならない…まさに自転車操業でした！！止まったら死ぬみたいに考えていました。実際はそんなことないのに。それでも帰宅後は東海オンエアの動画を見てモチベーションを保っていました。