一緒に仕事していて、チャットのやりとりを見てちょっとモヤッとしていたことがありまして、

なんというか、その、

細かい所まで、「ここの動きはどうなるんですか？」と質問してくることでした。

最初は、少しは自分で考える事が出来ないのか、とか、

お客さんの意向をくみ取ることが出来ないのか、などなど考えていたのですが、

（その一方で何も聞かずに突っ走るよりはマシなのかな、とも思ったけども。）

こないだその若手君とプロジェクトマネージャーと衝突することがありまして、

その理由は、質問内容がお客様にとって「どうでもいいこと」の動きについてなので、突然オンライン通話に呼び出され、お説教に巻き込まれました。

定時で上がって焼肉に行きたかったのに・・・

まぁ、若手君は直前のプロジェクトで、何でもお客さんの言うとおりに実装することを求められ、勝手な判断で実装するのは許されない現場だったようで、

お気の毒に・・・。

以前の近況報告でも書いたように、お客さんに質問するときは「こういう形にしようと思いますが問題ありませんか？」というような提案型で行うようにすると書いた覚えがありますが、

大抵、お客さんにお伺いを立てる場合は、考えられる対応策をいくつか提示して、それぞれのメリット、デメリットをまとめるという資料作成が必要だったりします。

これが結構めんどくさい。

まぁ、今回のケースだと「お任せします」で終わりそうな気もしますが、

で、マネージャーからは「お客さんにとってどうでもいいところはこちらで判断して良い」「こんな所に時間をかけるべきでは無い」という指摘。

これを聞いて、「ああ、自分が彼に対して感じていたモヤモヤはこれだったんだ。」と思いました。

まぁ、頑張れ、若者よ。

と言うことを、仕事をしていて思いました。

大元のお客さん（官庁）と、そこから仕事を受注したお客さん（大手企業）の間で、定期的にミーティングを行っていて、

で、現在でも要件定義が話し合われています（？）

いや、大まかな部分はある程度決まっていて、いまは（多分）細かい所について話当ているのだと思います。

で、ミーティングする度に説明資料を作成していて、

その内容は我々にも展開されているのですが、

最終的にどう決まったのか、というのが未だに分かっていない。

今のところ基本設計は画面イメージが展開されていたので、そこから理解できるところをドキュメントに落とし込んで、聞かないとわからない所は質問票を作って回答を貰うというやり方をやっています。

ミーティングの内容を録画しているので（オンラインミーティングなので）それを後で確認するということも出来るのですが、

会議に使った分の時間をそのまま消費するので、これは効率が悪い。

結局、展開された資料を見るしか無い。（とは言っても資料がありますというアナウンスが無いので、定期的に存在を確認するしか無い）

こういった資料が要件定義として1つにまとまっていないのは、お客さん（大手企業）の人達が忙しすぎる、というのもありまして、

そのせいか、お客さん（大手企業）に提出した基本設計書のレビューも全く進んでいない。

お客さんの人員不足？

まぁ、こういうことはこれまでの現場でもよくある話で、

むしろまだまともな方かもしれない。

過去の現場では、たたき台の資料が提出されるも、

チケットの中で議論が発生し、

その議論の内容をくみ取って作れ、というもの。

よくわかんない議論の内容なんて全部読みたくないよ。

最終形の資料をくれよ。

結局、作業側と指示側の認識違いが発生してしまう。

実際、認識違いを埋めるために直接話し合いしましたし。

そのときに「最終形の資料が欲しい」って思いましたね。

今のお仕事では、官庁のWebシステムの開発をやっているのですが、

今回開発しているのは主にフロントエンドの開発を行っています。

これまで自分はバックエンドの開発をメインにやっていたので、

ドキュメントの作成がめんどくさい。

しかも官庁の案件だから、ガッチガチのウォーターフォール開発である。

システムのリリースとは別にドキュメント類を納品しなければならないので、

とにかく基本設計書だけでもドキュメント本体の他にレビュー記録などのドキュメントを作成して納品しなければならない。

そして、フロントエンドの基本設計書もヤバイ。

インプット資料として画面イメージが降りてくるのだが、

これといって説明は無く、

画面イメージからいろいろ動きを推測して作成しなければならない。

一応、上流工程の人に質問できるけど、別会社なのでリアルタイムに質問することが出来なくて、しかもかなり忙しい方々なので、

手間をかけさせるような質問をしないように配慮しないといけない。

（まぁ最終的には適当に推測して、間違ってたらレビューで指摘貰おうという魂胆でいます。いや、そうしないと終わらんよ。。。）

なので、「聞かないと設計書書けない」ところだけ質問して、それ以外はある程度推測して書いています。

そして、もう一つやっかいなところは基本的に在宅ワークであること。

これまでの在宅ワークでもいろいろな方法で実現させていましたが、

一般的には、会社に開発PCがあり、VPNで社内LANに接続してリモートデスクトップで接続するパターン。

他には開発用ノートPCを貸与されていたので、それを自宅で使用するパターン。

これは主な作業スペースとしてGoogle Workspaceを使用していたため、ミーティングもドキュメント作成もWeb乗で行っていました。

で、今回は専用ソフトを使って開発用PCにリモート接続して使用しています。

そのソフトがVPNとリモートデスクトップ機能を用意してくれているタイプですね。

このソフト、マウス操作とレスポンスが若干遅いし、緻密な操作をするような作業があまり得意で無いような気がする。

特に夕方の時間帯は、ネットワークの問題なのか、ちょっと遅延が大きくなっている気がする。人によってはストレス感じるかも。

とは言っても文句ばかりでは何も解決しないので、慣れていくしか無いです。

みんなよく使いこなせてるなー。

自分は食事の一部に発芽玄米パックごはんを食べていました。

この商品、そろそろ追加購入のタイミングってところで、現在「取り扱い無し」となっていまして、

急遽代替品を探さないと、という状態になっていました。

で、マルちゃんの玄米ご飯をとりあえず購入。

もっと良い商品があればそれに乗り換えたい。

で、ここファンケルに限った話では無く、

これまでパックご飯を製造していた会社が製造終了になるケースが多いようです。

その理由は、8月～9月に起きた米不足問題による影響。

企業側も減量の米の確保が出来なくなり、泣く泣く製造中止となるケースが増えているという新聞記事を見ました。

買い占めしても、大量の在庫を抱えて消費しきれないという問題はこれまでも何度も経験しているのに、

人間って学ばないなぁ。

はい、

今週からお仕事開始しました。

1週間経過してみた感想としては、

まず、季節が夏から秋に切り替わるタイミングだったので、朝と日中の寒暖差が激しくなり、

朝起きたときの体調が悪かった。

鬱特有の辛さでは無かったのが幸いだったけど、それでも結構辛かった。

仕事の状況は、官庁関連のプロジェクトなので、納品日（締め切り）が決まっているけど、まだ要件定義が決まっていないという状況。

もしかしたら、納品直前に何ると忙しくなる可能性が高い。

あと、久しぶりにVue.jsが出てきたので、Vue.jsも学び直ししてます。

まぁ、まずはドキュメント読みがメインの先週でした。

そして、メンタル維持のために、仕事が終わった後ウォーキングしたいと思っていたけど、

もうすぐ秋分の日ということで、仕事終わりには空がすでに暗くなっている、と言う状態であり、

その空を見てしまうと、これから運動する気持ちがそがれてしまう。

どうすればいいですかね？

あと、仕事終了後、ウォーキング、晩飯、お風呂、どの順で実行するべきか？というのも悩みどころです。

どうするのが正解なんですかね？

まぁ、今のところメンタル的には問題無いので、この調子で来週も頑張ります。

うーん、まだまだ勉強が足りなかったようだ。

何が起こったかというと、

だいたこの時期になると、投資したお金に対して分配金が発生する、

はずなのですが、

いつまでたっても分配金が発生した気配がない。

なので、調べてみると、

過去これまでも分配金が発生していない商品だった。

これまでの経験で分配金が発生していたのは、

たまたま分配金が発生する商品に対して投資していたということだったんですね。

ここらへんもきちんとチェックしなくちゃいけない。

という事に気がつき、

これまで保有していた投資信託を全て売却。

たまたま購入時より値上がりしていたため、

約10万円の売却益が確定。

NISA枠だから非課税。

でももうちょっと早く気がついてたらもう少し売却益が大きくなったんですが、

ここは悔やんでもしょうがない。

しかし、自分の投資計画は売却益で稼ぐことでは無く、分配金を受け取ることで稼ぐのを目的としているので、

今度はちゃんと分配金が発生する商品を探し、

その商品をNISA枠で購入。

これで間違いないだろう。

はい、まだ案件決まってません。

早く決めてくれないと他の案件行っちゃうかもしれないぞ？

これはエージェントの人から聞いた話。

ITエンジニアの求職の現場では、Javaのエンジニアで溢れているらしい。

供給過多の状態ですね。

なので、Javaの案件はあるにはあるけれど、「Javaできる」だけでは使って貰えないという状態。

例えば、フレームワークSpringbootの経験が無いとダメとか、

クラウドでの開発経験が無いとダメとか。

少し条件が厳しいような感じがします。

その反面、最近はGo言語の需要があるらしい。

案件はあるけど、使用できるエンジニアが足りないという状態。

みんな、Go言語を学べ。

最近気がついたことなんだけど、お酒のおつまみをお肉からお魚に変えると、痩せやすくなるぞ！

今週から新しい現場に入りました。

とはいっても、まだ支給PCをセットアップして、業務ツールのアカウントを設定して、動作環境を立ち上げて、までの段階なので、まだソースコードを見ていません。

開発しているプロダクトの話は出来ませんが、どんな環境で動かしているのか。

AWS上にDockerコンテナを稼働させて運用しているようです。

あまりAWS独自のサービスは使用していないみたいで、

使用しているデータベースなどもDockerコンテナで稼働させているみたいです。

AWSの独自サービスを使用していないので、ローカル環境でも動作確認できるっぽい。

以前AWS関連の開発をしていた頃は、ガリガリにAWS独自サービスを使用していたので、動作確認もAWS上に用意しなければならない、と言うのがあったので。

今回は動作を確認しながらコードを書くというやり方が出来そうです。

Windows上でDockerを使用する場合はDocker Desktopを使うのですが、

今の職場ではWSL2上にサービスを稼働させてDockerを動かしているようです。

どちらかと言えばLinux上でDockerを動かすイメージに近いやり方だと思います。

すげぇ。

そして、API仕様書もすでに用意されています。

何故英語なのかは不明です。

ただ理解しなければならない国際標準の仕様がベースにあり、その内容もいずれ理解しないと行けないので、英語の世界は避けられないようです。

まぁ、今年中は開発環境構築とシステムの理解とかが中心になりそう。

そして、年末年始は11連休。

稼働時間は大丈夫か？