睦ちゃん（モーティス）に怒られそう。

仕事が忙しくなって残業が増えると、食事が疎かになるということを実感しました。

まず、朝起きてもご飯を作る気力が無いので、どうしても簡単な食事になってしまう。

お昼は普通に簡単な食事。

夕食は、仕事の合間に食べることになるので、どうしても簡単なメニューになってしまう。

具体的にはコンビニ弁当、カップラーメン、レトルト食品、冷凍食品。

野菜という物はまともに食べることが出来ません。

さらに在宅勤務（特に冬の雪国）だと、外出も億劫になるので、デリバリーに頼りがち。

コンビニのデリバリーって、店舗で買うより高い価格設定なので、デリバリーに頼り過ぎるとあっという間にお金が無くなってしまう。

でも忙しすぎて買い出しに行く時間も無い、という悪循環。

いや、忙しいときこそ休憩は重要ってことはきちんと頭の中に入れておいて欲しい。

きちんと休憩を取らないと、普段やらないようなミスをしてしまう可能性が高くなり、余計に仕事を増やすことになりかねない。

休憩を取れるほどの余力が無いと、完全に仕事量がキャパを超えてる状態。

リリース前は稼働が上がると聞いていたけど、ここまでとは思わなかった。

もう新卒会社員時代の働き方じゃん。

で、今日は夢の中でも嫌な仕事をしていたので、寝起きの時点で疲れてしまっている状態。

少し悩みましたが、今日はお休みを取りました。

また今週、画面1ページ完成させたオイラ。

しかし、今週、とあるバックエンド処理の進捗が思わしくなく、ヒアリングを行ったところ、

まぁその場でも色々トラブルが起きまして、

担当者はあの若手君と入れ替わりで加入したメンバー（お爺ちゃん）なんですが、

これまでもフロントエンド周りの現場を経験しており、即戦力として期待していました。

そういうこともあり、一番難しい画面をお願いしていたのですが、その画面のバックエンド処理に苦戦していて、画面デザインの実装がほとんど出来上がっていないことが発覚。

このままでは間に合わない！ということで、

自分が画面デザインに入ることになりました。

いやーいつになったら平和な時間が来るのかなー？

年が明けて3週間経過しましたが、

その間、仕事がとんでもなく忙しくなりまして、

フェーズとしては単体試験なのですが、フロントエンドとバックエンドの試験項目があり、

フロントエンドは項目数が多いものの、大部分が見た目の確認項目なので項目消化は早いけど、

バックエンドは項目数が少ないものの、AWSにAPI＋Lambda＋DynamoDBを構築して確認する必要があり、

思ったように数字が稼げない。

毎日の様に消化項目数を記入して、その数字をみてあーだこーだ言われるのですが、

こういう進捗管理って本当にひつようなんですか？

しかも、まだコーディングが完了していない部分もあり、コードを書いてすぐに単体試験という所もありまして。

そして、比較的進捗が進んでいる人にサポートに入って貰ったりしてスケジュールに間に合わせなくちゃいけない。

こういうとき、比較的順調に進んでいる人に負担がかかる。

自分なんですが。

というようなことがなんやかんやあって、人材追加して対応するのも当然の判断尚ですが、

彼らに仕事を教えるのがまた負担。

いや、これは仕方が無いことなんですが。

そんな感じで、休出などで対応して頑張って、今に至るのですが、

この時点で、画面が一つ完成しておらず、その画面を作って、と仕事を振られた。

あの若手君の担当画面じゃん！

まだ実装がおわらん・・・。

本来、去年中に供養しなければならなかった話。

度々話題にしていた若手君が去年中をもってチームを離れることになりました。

とにかくチーム加入当初から何でも聞くを徹底していた彼ですが、

とにかく聞くことを最優先にしていたため、自分で調べることも、お客さんの意図も読み取ることも分からずにとにかく「聞く」ことを最優先にする。

それが明らかにお客様にとっても「どうでも良いこと（実装依存）」の事も聞こうとするのを全力で阻止したのは思い出です。

そもそも間近のプロジェクトではお客さんの許可無く自分の判断で実装することを禁止していたため、そういう考えになってしまうのは仕方が無いのだけれど、

その現場の方が、むしろ特殊と言うべきなのだろうか。

そう思わざるを得ないエピソードもありまして、

仕様が決まってないと許さないということ。

画面に表示される各パーツのサイズなどのスタイルが統一されておらず、「これではシステムで統一されていないので、お客様からクレームが入る！」と言い出たのである。

さらには、「これでは製造できない！」まで言いだして。

（はて？製造できないというのなら、それが決まるまで何をしているんだい？そういうこと言い出すんだったら自分で仕様を決めるためのたたき台などを作るべきでは？？？）

ちなみに、開発チーム構成として、お客様「某官庁」と、直接案件を受注してお客様対応や進捗管理や要件定義をメインとする「A社」、そして実際に開発を担当する「B社」「C社」があり、自分はC社のチームに所属している。

彼の言い分は画面パーツをB社とC社で共通化しないとダメということ。

結局仕様統一の為の資料を3日かけて作成し、それを全体のミーティングの議題に出したんだけど、それ以来何も進展がないまま現在に至ってます。

おそらく、「とりあえずリリースを優先して、何か言われたらリリース後の追加開発で対応」というスタンスだと思う。

結局何のための3日だったのかよくわからんかった。

だいたい、画面サイズに関しても当時の時点でB社とC社ですでに大きな差分があり、これから統一させるのは工数的に無理なので、そういう流れになるだろうというのは、なんとなく感じていた。

そして、最終的には自分の作業範囲を勝手に設定していることである。

例えば、製造を行うために、前提知識としてDB仕様を理解しないといけないんだけど、

DB関連の設計書を読んでないようにしか思えなくって、

とにかく、分からないからオイラに聞いてくるのである。

DB設計は詳細設計に含まれるので、製造時に必須の資料なのだが、資料の存在を知らないのか、そもそも見る気が無いのか、

資料を探そうとしないのか？と聞いたら、「それは自分の仕事じゃない」と言い出したので後者なのだろう。

で、この直後から荒れ出し、このプロジェクトから抜けたいと言い出したのである。

彼、ちょっと怪しいと思い出したのは、仕様に関して話したところ、最終的にA社に課題表を書いて確認しよう！という流れになったのですが、「課題表、自分が書くんですか？？」と言い出したので、

ああ、彼の中では仕様周りは自分の仕事じゃないと考えていたんだろうと思う。

そもそもの話、自分の契約ではこのプロジェクトに従事するという内容なので、メンバー全員同じ契約内容だったら、仕様は自分の作業範囲ではない、という考えにはならないと思うのだが・・・。

こういう契約内容だったら、メンバーはプロジェクトを完結させるためにベストムーブを考えて行動する、もしくはタスクを振られるのだが、

そういう風に自分の仕事ではないと言われると、仕事を振る方も扱いづらい存在になるのではないかね？

そして、最終的にマネージャーと直接会話したけれども、彼の認識を変えることはできなかった。

結局、彼は彼の開発スタイルに合ってないと仕事が出来ないと言うことらしいので、マネージャー判断でチームを去ることになりました。

まぁ、これは仕方が無いよね。

ということで、去年最大をモヤモヤを供養させていただきました。

まず、これを書いているのは事件が起こった翌日なのだが、そのモヤモヤが解消されないためなのか、昨日は一睡も出来なかった。

今日せっかく休み取ったのに台無しだよ。

モヤモヤを回収するには文字起こしすれば良いので、なるべく身バレしないように気をつけて、内容を整理して吐き出したいと思う。

事の発端は例の若手君である。

あれからというもの、相変わらず質問が多い。

若手君にはある画面の実装のタスクを担当しているのだが、

基本設計書を書いたのはオイラなので、その設計書の内容に関する質問ならば全然問題無いのだが、

問題はオイラ達が作成に携わっていないドキュメントである。

例えば、一部の機能は同じプロジェクトに参画しているけど別チームとして動いている会社の方々が担当している。

もちろんその内容の一部は我々にも関わることも在るので、そういったドキュメントは共有して使用している。

というか、最終的に一つの成果物として納品する必要があるので、一部のドキュメントは記載内容をマージする事もある。

という前提条件がありまして、

若手君の話を聞く限りでは、基本設計書はオイラが書いたので、若手君の担当範囲外と考えているように見えた。

これはおそらく的中していて、

「そちらでドキュメントを調べたりしないんですか？」

と聞いたら、

「それは私の作業ではありません。」

「調べるなら別途工数が必要です。」

と言いだした。

これ以降、若手君はお怒りモードに突入し、一方的に怒りのメッセージが大量に送られてきた。

その内容はあまり見ていない。

自分も少しお怒りモードに入っていたのだが、自分が口論に参戦したところで、自分はこういう口論に弱いので、しばしクールダウンに徹していたのだが、

若手君はその勢いのままプロジェクトマネージャーに現場を抜けたいと言い出した。

その結果どうなったかは知らないっす。

定時になって、自分のメンタルもボロボロなので、速攻退勤しました。

と言うのが昨日起きたこと。

さらに追加情報としては、この前日にも若手君はチームリーダーに噛みついていたらしい、ということと、

問い合わせが来る度に自分も正しい情報提供をするために資料を漁っていることをやっているので、問い合わせ対応に結構時間を消費している。

まぁ、この状況をよくよく考えたら、

若手君のわがままを通して、勝手にお怒りモードになって現場をかき乱し、最終的にチームを抜けたいと言い出した、ということになるのだが、

これって彼一人の問題なのでは？

作成済みの設計書類はすべて製造のインプット資料になるはずなのだが、その内容を調べることも拒否するって、それで製造できるのだろうか？

オイラがすべて手ほどきして実装方法を教えなくちゃいけないのか？

で、今後の事なんだけど、

オイラは正直もう彼とは関わりたくない。

すでにオイラに対してキレ散らかしてくれたので、体制見直してくれないかなーって思ってます。

と、ここまで書いて、ようやくモヤモヤがスッキリしてきたような気がします。

あーあ、今日の予定見直ししなくちゃ・・・

前回の投稿で、基本仕様書がFixしていないという話をしましたが、

そのあと進捗会議で一悶着あった様で、

別会社のチームが進捗遅れを叩かれていたらしい。

話を聞いた限りでは、その場に自分がいなくて良かったと思った・・・。

というのは、すでに基本設計書のFixが大元のスケジュールから大幅に遅れており、

そのせいでその後の行程も遅れるのが当然となるので、

進捗遅れが発生するのは当然のことであり、メンバー全員周知の事実だと思うんですが。

報告の仕方が悪かったんですかね？

そして、もう一つ問題が。

このような状態でも、大元のスケジュール厳守というのが開発の方針のようで、

どこからその工数を出すのかといったら、

機能を一部削ったんだからその分スケジュールを圧縮できるでしょ？というスタンスらしい。

うーん、なんかモヤッとするなぁ。

我々のチームは今のところ何も言われていないけど（でも明らかに遅れている）

矛先が我々に向けられる可能性もゼロではないので、

そうならないようにいろいろ対策を講じるらしい。

ちょっとリーダー達に負荷がかかるかもしれないけど、

要件定義から参加しているメンバーとしてできるだけ負担を軽減させてあげたい。

さて、どうなるかな・・・。

5月は不覚にも体調的にダウンしてしまい、工数の下限を1日分下回ってしまったのですが、

6月はなんとか1日分余裕がある状態でフィニッシュ。

今の現場は7.5時間が定時になるので、

これにプラスして0.5時間残業を重ねれば、1~2日ぐらいの余裕が生まれたりします。

そして、7月からまともな報酬が振り込まれます。

6月は、4月分の報酬を5月に受け取る「早払い」を申請していたので、報酬は振り込まれず、障害年金のお金で生活していました。

もう一つ、6月の生活を苦しめていたのが、

公共料金の支払いが6月から発生していたこと。

具体的には、住民税と国民健康保険料です。

大きな金額で、マジでびっくりしました。

これまでは会社の給与支払いの時点で引かれていたんだよなぁ。

改めて自分で支払うと、結構な負担に感じるぜ。

そして、7月は計算上、お休みが1日確実に作れそうです。

この日はキャンプを計画していて、サイト利用料、レンタカー、キャンプ用品のレンタル、すでに抑えております。

今年、一度はバーベキューやりたかったけど、天候や病院などでなかなかできなかったので、

キャンプが楽しみ。

そして、6月からお客様の方針で、出社日を増やそうとしているみたいです。

でも、正直なことを言うと、みんな出社するには席数が足りないという事態が発生しており、

それに出社しても、打ち合わせは結局オンラインでのミーティングが多いという現実もあり、

出社する意味🤔

という意見もありました。

とりあえず現場からは以上です。