真面目で優しいシステムエンジニアは損をする⑥~総動員~

2022-03-19

どうも!ヒグッティ(ヒグッティ@システムエンジニア)です!
私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回はプロジェクトでの決断について書きました。

真面目で優しいシステムエンジニアは損をする⑤~誰も知らない~

今回は人を大量に投入する話となります。ではお楽しみください。

最初が肝心

私がミドルウェアの移行をやっている間も様々なことがありました。
plsqlを別のプログラムに変換する作業の進捗が良くないのです。原因は様々ですが以下です。
○原因
1.plsqlが読めない。
2.新しく変換するプログラム用に用意したフレームワークや単体テストフレームワークの使い方が分かりづらい。
3.スキル不足。
4.やる気がない。

1番の問題は4でした。9月いっぱいでウーバさんと美容師さんの交代が決まっており、明らかに2人のやる気が無いことが感じ取れていました。こんな時リーダとしてどうしたら良いか未だに答えは見つかっていません。2人に振っている作業は全く終わっていませんでした。1日1機能を開発から単体テストを終わらせなければならないのでかなり厳しいスケジュールでしたが、最終的には10日かけて1機能を終わらせるペースとなっていました。10日は時間かかりすぎだろ…せめて3日くらいで1機能を終わらせてほしかった…また交代が決まっているせいか、もはや逃げるが勝ち状態でした。ヤバいプロジェクトに入ったら良くある現象です。早めに逃げるが正解だと思いますが…

美容師∶全然プログラミングがわからないんですよー(笑)
ウーバ∶俺もー元々あんまプログラミング得意じゃないんだよねー(笑)
美容師∶あと今日飲み会行くんですよ!なんか会社の関係でどっかの社長が来るらしくて!マジで楽しみっす!
ウーバ∶へー!いいねー!

こんな会話がちらほら聞こえてくる始末。私も進捗が進まない焦りからイライラしていました。進捗遅れてるのに毎日定時で帰るし、挙句の果ては人前で飲み会に行くなどを大声で話していました。私はかける声もなく、ウーバさん、美容師さんの契約終了を待つしかありませんでした。

10月始めのこと。ウーバさん、美容師さんの代わりを補充し、これからplsqlの変換をしていこうというときでした。代わりに補充した人はヘビさん、茶髪さんです。

PM∶plsql変換の件はどうですか?
ヒグ∶作業は進めていますが、まだメンバの生産性が上がってこないですね。メンバの入れ替えもしたばかりで、思うように進んでしません。スケジュール的にも遅延しています。
PM∶そうですか…変換作業を始めてから2週間ほど経ちましたが、何で生産性が上がらないのですか?それとこの遅延はどこで取り返すんですか?
ヒグ∶はい。生産性が上がらない理由はメンバがplsqlの知識がなかったり、変換したあとのプログラムをテストする時の単体テストコードの書き方がわからなかったりと言うのが理由です。
PM∶それは理由になってないですよね?プログラムが読めてかける人をメンバに入れているんじゃないんですか?
ヒグ∶そうなんですが…新しいプログラムで書き直すために、フレームワーク的な物を作ったはかりだったり、単体テストのフレームワークを作ったばかりでみんな使い方などを模索している状況です。
PM∶なるほど。今日の時点で20機能ほど変換が完了予定ですが、まだ5機能しかできていないですよね?こんな調子で大丈夫ですか?
ヒグ∶やはり1人1日1機能を完成させるのに無理があると思います。やはり2日ほどはどうしてもかかります…
PM∶いやいや、この前の会議でテストケース数を調整して、できるって言ってたじゃないですか?
ヒグ∶まぁそうですけど…(無理矢理テストケース数を減らしてきたのはPMさんだろー!)
PM∶とにかく今の遅延をどうやって取り戻すか資料を作って説明してください。
ヒグ∶はい。わかりました。
PM∶その資料はいつまでにできます?
ヒグ∶明日までには説明できるように準備します。
PM∶了解です。

こんなやり取りがほぼ毎日続きました。流石に進捗が上がらないことを心配した私は優男さんに相談しました。

ヒグ∶plsqlの変換で進捗が思うようにでなくて…
優男∶そっかー…人の交代とかあったし、進捗出すのは難しいか…
ヒグ∶はい…今のままでは予定通りの日までにplsqlの変換はできないと思います。
優男∶そうだね。そしたらリスケしよう!今回、新しいサービス追加あったよね?それに関連する機能を優先的に変換して、残りは来年2月くらいまでに変換を完了させれば十分間に合うんじゃない?
ヒグ∶そうですね。サービスの追加に関連する機能は20機能くらいなので、まずはそこを優先するようにします。
優男∶了解。リスケしたらオンスケ(オンスケジュール∶スケジュール通り)になるからね!スケジュールは俺が作るよ!ヒグはミドルウェアの設定とかで色々大変でしょ?機能一覧とか優先して変換しなきゃいけない機能を教えてくださいな。
ヒグ∶ありがとうございます!助かります!あとで機能一覧などを共有しますね!
優男∶おー!頼む!

さすがは優男さん。経験が違いました。プロジェクトの進め方とかマネジメント力がすごいです。優男さんにスケジュールを作ってもらい、優先して変換する機能とそうでない機能を分けてスケジュールを組みました。このスケジュールをお客さんに説明し、なんとか納得してもらいました。お客さんには最初と言ってることが違うじゃん!など散々言われましたが…こっちのチームメンバの実力不足を遅延の理由にできるわけもなく、もう少しでみんなの理解が深まりますからと苦しい言い訳で乗り切っていました。お客さんも多分薄々勘付いて、深く突っ込まなくなっていたようにも思えますが…
ひとまずスケジュールも作り直し、余裕のある状態になったかと思ったのですが…まだ不安材料がありました。それはメガネさんの事でした。

ヒグ∶メガネさん、ちょっといいですか?まだこの機能が終わってないみたいですけど、大丈夫ですか?明日までに単体テスト完了になっていますが、まだコーディングが終わってないみたいですけど…
メガネ∶いや、この機能がめちゃくちゃ複雑で…でも大丈夫です。ボウズさんとも相談してなんとか進めています。
ヒグ∶そうですか。ならいいですけど。ボウズさんもフォローよろしくお願いしますね。
ボウズ∶わかりました。ヒグさん、この後、ちょっと話せます?
ヒグ∶いいですよ!

ボウズさんと二人で話すことに。

ボウズ∶メガネさんのフォローはしているんですけど、正直きついです。メガネさんはプログラミングがほぼできない人です。フォローに時間を取られていて私の作業にも影響がでています。何とかなりませんか?
ヒグ∶そうだったんですか!了解です。面接した時はプログラミングが得意だって言ってたんですけどねー
ボウズ∶そうですか。私の作業は優先して変換しなきゃいけない機能ばかりです。難易度も高いし納期も厳しい。ちょっと作業に集中したいです。
ヒグ∶わかりました。ちょっと考えさせて下さい。
ボウズ∶お願いします。

確認してみると、メガネさんの担当している機能はたしかに難易度が高いものでした。メガネさんの会社の人にも相談をし、休日にメガネさんの会社の先輩などにフォローをしてもらうことになりました。しかし、平日分の遅れを休日に取り戻せるはずもなくスケジュールはどんどん遅延していきました。そして、メガネさんは10月いっぱいで入れ替えることになりました。プロジェクトが始まってから2ヶ月ちょっとで6人中3人を入れ替えるという事態。この時点でチームのノウハウや知識はほぼ0に近い状態でした。今思うと、プロジェクトの最初で、しっかり調査をして、方向性を決めるべきでした。DBの変換がツールを使えば簡単にできるのか?別のプログラムに変換する場合でも、変換する時のルールを決めるべきでした。このパターンはこれに変換して、などと決めれば少しは結果が変わったのかなと思います。この時、私が選択した方針は一番大変なものだったかもしれません。
その中でも唯一順調だったのが、パーマさんでした。パーマさんには新しいサービスの追加をお願いしていました。本当は新しいサービスの追加作業は二人でやってもらう予定でしたが、plsqlの変換に人が取られ、パーマさん1人にやってもらうことになってしまいました。しかし、パーマさんは設計や開発をバリバリこなしており、常にオンスケ、前倒しで作業を進めていました。いつしか私の心の支えになっていました。
11月に入り、新しい人をメンバに加えて再スタートをきりました。新しく入った人をマッチョさんとしましょうかね。

総動員

11月に入った時、私はリーダとしてスケジュール管理すらもできない状態となっていました。スケジュールのリスケや新しい人への作業割当をしたり、お客さんに報告したりと日々、調整に追われていました。
そんな中、活躍してくれたのが茶髪さんでした。技術に強く、他のメンバの相談にも乗ってくれたり、スケジュール表を更新してくれたりと大変助かりました。
しかし、plsqlの変換で大量の人員を投入することになりました。その理由は、新しく変換したプログラムに潜在的なバグがあったためです。

茶髪∶ヒグさん、スケジュール表を更新しておきました。
ヒグ∶ありがとうございます!いつも助かります!どうですか?
茶髪∶やる事は多いけど、まぁ大丈夫ですよ。マッチョさんと一緒にゴリゴリ作ってます!
ヒグ∶そうですか!スケジュールもオンスケですね。変換作業もやっと半分くらいまで来ましたね!
茶髪∶はい。でもちょっと相談したいことがあります。変換して新しく作ったアプリですけど、バグがあります。特に性能面がまずいと思います。
ヒグ∶マジすか…直せます?
茶髪∶いやーこのままじゃ無理かな!アプリ自体を作り直さないと厳しいな…
ヒグ∶作り直すって全部?
茶髪∶はい。今のままだと、処理が終わるまでに何時間もかかる可能性があるよ。既存のシステムだと5分で終わる処理が1時間くらいかかるかもしれない。まずいよ…
ヒグ∶そんな…作り直すにしても、もう半分くらい作っちゃったしなー、時間あるかなー
茶髪∶ちょっと他の人とも相談してるけど、大丈夫そう。作り直すアプリのイメージはできてるし手伝ってくれる人も、技術に詳しいから大丈夫。
ヒグ∶そうですか!(手伝ってくれる人って誰(笑)?)じゃあ作り直しますか!
茶髪∶了解です。作り直しのスケジュールも作りますね!
ヒグ∶ありがとうございます!本当に助かる!
茶髪∶あともう一つ問題が…
ヒグ∶何ですか?
茶髪∶DBの型に問題があるよ。
ヒグ∶型?
茶髪∶うん。今のままだと、更新すべきデータが登録されちゃう。同じデータが2行できちゃうね。主キーにスペースが入っている場合、上手くいかないみたい。
ヒグ∶マジすか…これは何か対策あります?
茶髪∶わかんないなー。全部のテーブルを調査して型を変換しなきゃいけないかも…
ヒグ∶テーブルの型を変更するのも影響がでかいな…
茶髪∶うん…まぁ単体テストは自動化してあるから何回でも実行できるよ。テーブルの型を変えて単体テストを全部実行すればエラー箇所もわかると思いますよ!
ヒグ∶そうですか。テーブルを変更しないでも済む方法あります?
茶髪∶いやープログラムを全部変えなきゃいけないから逆に時間かかるなー
ヒグ∶そうか…この作業って茶髪さんできます?
茶髪∶できますよ!他の作業止まっちゃうけど…
ヒグ∶ですよね…でもこれは早めに解決しないとまずいな…この作業を優先してお願いします!
茶髪∶了解です!

この後、茶髪さんはテーブルの型の問題とplsql変換作業を両方ともオンスケでこなしてくれました。本当に助かる。
プロジェクトではよくあることかもしれないですが、性能ってけっこう見落としがちなんですよね。色々作って、いざ性能テストしたら全然駄目で最初から作り直しなんてこともたまにあります。プログラミングが得意な人でも単体テストで機能面は想定の結果になっても性能まで気にして作れる人はあまりいないです。なので茶髪さんが気づいてくれて本当によかった。
このアプリの作り直しは、既存のチームメンバだけでは足りず他のプロジェクトからも人を借りて作業してもらうようになりました。支援してくれる人も別の仕事を抱えながらなので、定時後や空き時間に作業をやってくれました。5人くらい支援してくれました。ちなみに優男さんが調整してくれたようです。本当に感謝です。最初は余裕が出るように組んだスケジュールもアプリの作り直しやテーブルの型の問題でギリギリのスケジュールとなっていました。それでもチームメンバや支援メンバのおかげでなんとかオンスケを保つことができていました。
11月も終わりにさしかかっていましたが、この時はまだ暖かかったです。この日も帰って東海オンエアを見て元気をもらい就寝しました。

まとめ

遅延が発生した時は理由とかリカバリとか色々考えてお客さんに報告。資料を用意して説明したりして結構めんどくさい。
リスケしたらオンスケになる。
最初の方針決めでプロジェクトは何倍も楽に、何倍も苦しくなる。
性能は見落としがち。

スポンサーリンク

Uncategorized

Posted by user