担当プロダクト・役割は変更なし。
前回のNext Action振り返り
コミュニケーション系の本を読み、アンガーマネージメントについて学ぶ カッとならないようにマネジメントの勉強してもいいかも。ITILとか
『考えない練習』をお薦めされたので読んだ。"いま"に集中する考えは参考になった。ただ、自分がイライラするのは非論理的な言動・品質が低い成果物ややるべきことをやらない人・理不尽で意味のないワークフロー的なものなのであまり参考にならなかった。
ITILは会社から補助を出してもらっているので勉強している。模擬試験は合格点が取れるようになってきたが、非現実的だなと思ってしまう。理想論はわかるけどじゃあどうすればいいのみたいな感じ。
どちらかというと、この記事で見た16 Personalitiesの方が自己理解に役立った。自分はINTJ-T（建築家/ Architect）だった。1
イライラするのは問題があることを放置することに関わることばかりで、それ以外のことは結構許せる。性格特性なのだとわかった。つまり、これ自体を変えるのは難しい。加えて理想主義的なところがあり、レベルが低い（この言い方自体が良くないが）人を軽視する傾向がある。 人間関係のトラブルについては自分が抱え込んで爆発した結果トラブルになることが多い。これは性格特性に記載の通りでゲーッ！と思った。
言われてみるとゼノブレイド1・2で主人公に近しい人がポンポン死んでも何も思わないしな…。敵が憎い！とかも思わないし…。世界観の雰囲気と話と冒険が面白いと思って遊んでおり、これは感情面に興味がないところからきているのではないか。それに職場の人と飲み会とかで雑談するのは苦手で（喋ることが本当に思い浮かばない）黙って聞く側になるけど課題に対する議論が必要なときは喋れるし。
悪役はこの性格タイプをモデルとすることが多いって…人権がない。
なるべく向いている環境や仕事に移ることを常に考えたほうが良いのと、性格特性を理解して傲慢にならないように強く意識するだけでも改善できる気はした。あと、文句をたれるだけでなく行動もセットにするところも意識したい。卑怯者にはなりたくない。
お金を出すともっと詳しい性格診断もできるらしい。自己の特性をよく理解することで改善につなげるのが良さそう。100点の人はいないが自覚がある/ないだけでだいぶ変わると思う。
複数の方法でTODOアプリを作る。同じものなら比較もしやすい
TODOアプリではないが、Reactハンズオンラーニング 第2版 ―Webアプリケーション開発のベストプラクティスの写経をやり始めた。2・3章にObject操作の話が出てくるので何回も読み直している。React.jsは関数型言語の思想でコードを書くのでその点も勉強になる。
仕事ではVue2.x + Class形式のコードを触っているが、Vue.jsの考え方や機能はReact.jsも結構共通点が多く、「現状付き合っている技術をきちんと理解する」のが重要だなあと思った。表面的な理解だと応用できないが、考えと概念が理解できれば応用して理解するのは簡単である。
やったこと・所感
引き続きフロントエンド + チームリーダー（という名のプロマネ）業務を担当した。チームメンバーフォロー70%、バグFIX・再設計業務30%と言う感じだった。コードがまともに書けたのは6月に入ってからだった。流石にちょっとどうなのと思っている。
特定機能のフロントエンド処理フロー再設計
FY21の4Qでは画面描画の効率化を目的にしていたが、今期はVuex StoreやAPIリクエストタイミングの練りが甘いことによる画面更新遅れバグ改善のため対応した。
また、リリース時にテストケースが不足し過ぎていたことがわかっている。機能全体の再試験を行い、出てきたバグも潰している。時間がないのは理解できるが、リリース前の機能試験くらいは業務フロー全部網羅しておいてほしい。あとそんな状態でリリースOKするなと思ってしまう。
尻拭いさせられている感よりも、品質が低いアプリをリリースしたメンバーが評価されることに理不尽を感じてしまう。他のプロジェクトに移ってまた同じことを繰り返す人よりもそのバグを直しコード品質を改善する人の方が評価されるべきなんじゃないだろうか。せめてリリース後は2年程度運用まで責任持ってやってほしい。
チームメンバーフォロー
チームメンバーが一人移動になり、フロントエンド・バックエンド1名ずつの体制になった。それ自体は問題ない。ただ、残ったメンバーは元々仕事のクオリティがそこそこで（まあそれは経験値とかあるのでしょうがないのもあるけど）、かつ仕事を先延ばしにしがち＆仕事は可能な限りやりたくないタイプだった。 2
4月・5月は1つのタスクだけやってもらい、あとは全て（バックエンドの領域も！）こちらで巻き取って対応した。マネージャーも変わり、引き継ぎが終わるまでは〜と言われてチームも放置気味にされていた。
流石に疲弊してしまった。特に何かあったとき・気になっていることがあるときに相談や議論できる相手がいないのがしんどすぎる。また、スケジュールを立てられず、立ててもコミットメントしてくれないのでいつまでもタスクが終わらない。空き時間にフロントエンドのコード改善をしたくても、溢れたタスクの巻き取りや問い合わせ対応で集中できない。だんだん実装の実力が落ちている感覚が強かった。 3
流石にこんなのが続くようだと精神的に持たないし、フロントエンドエンジニアとしてのキャリアもまともに積めない。元々フロントエンド領域に軸足をおく社員が他にいないのもあり、キャリアとしても限界を感じていた。
アプリケーションを長期保守しながら改善するのはやりたいことにあっているので続けたいが、キャリアに限界があるならどうしようもない。仕方がないので将来について考えることにした。最悪貯金があるので2・3ヶ月くらい穴が開いても平気だし。
幸運なことに（？）更に上のマネージャーに直談判する機会を得たので、現状の課題を説明し、マネージャーは元に戻してもらうことになった。放置気味だった点は進捗報告をマネージャーにさせることにして改善を図るようにした。
今はフレームワークEOL対応に向けて自学の時間が取れている。相変わらず仕事の進みは遅いので待ち時間は多いが、何かあったときに複数人で対応できると思うと空き時間に他の課題検討に集中できる。
キャリアの限界は判断保留というところで、次似たようなことがあればドライに対応するしかないかなと思っている。
直談判できたのは昨年チームリーダー業務を通じて色々な人から（そして相談相手からも）信頼を勝ち取っていたのが一番大きかったと思う。常にあるべき状態に向けて最大限努力する＆振り返りながら学び続けるのをやめてはいけない、と強く思い直した。
ただ、これを他者に（無意識に）そのまま押し付けてしまうところがあり、改善する必要がある。他人は変えることができない。4 言い方は良くないが、期待せず割り切って付き合うしかないのかもしれない。（調査が足りないなあと思ったら調べさせるのではなく自分で足りないところを調べるとか）会社全体では代替可能になっていないのであるべき姿ではないが、それで困るのは経営側なので知ったことではない。
良かった点
あまりない。どちらかというと性格面での課題を再認識させられる期だった。業務外でコードを書くのを習慣化できたのは良かった。また、4Qと比べるとブログやコード・原稿作成頻度が上がった点も良かった。潰れないように適度な休憩は必要だが、今までダラダラしていた部分が意味のある時間になって良かった。
Next Action
OJTトレーナーを頼まれてしまった。特に性格面の課題は手を打つ必要がある。しかし特性を考えるとトレーナーこそ適性がない気がするけどな。
- 有償のストレングステストを受けて自己理解を進める
- ITILを受ける
- 試験苦手だけど努力はしないとなあ
- React.jsでアプリケーションが書けるようになる
- CRUD操作を伴うアプリケーションの画面を作れる
- テストコードが書ける
- HTML&CSS&JavaScriptを学び直す
- 間違った指摘をするわけには行かないので…
