昨年までは年末に一年分をまとめて振り返っていた。今年から四半期に一度振り返ることにした。理由は年末だと年初の仕事内容がうろ覚えになってしまうため。加えて、振り返り回数を上げることで改善サイクルをきちんと回せるのではないかと考えたため。
社会人7年目になってしまったのもあり、仕事のやり方が硬直すると「下がる」しかなくなってしまう。それは避けたい。Front-End Lounge #2 1で「世の中は変化し続けるため、現状維持は下降と同義」って言ってたし。
今担当しているアプリケーションはリリース後2年半ほど運用しているもので、いわゆる「プロダクト・ポートフォリオ・マネジメント」だと「負け犬」に近い。2
やったこと・所感
画面描画用APIインターフェース・フロントエンド再設計
特定機能の設計見直しが必要になったため対応した。自分はフロントエンド担当だが、APIのレスポンスパラメータの再設計を行い改善点を提案した。理由は画面描画を効率よく実施するため。
わざわざAPIを作るなら画面描画に不必要なパラメータを返すべきではない。また、フロントエンド側で扱いにくいインターフェースも避けたい。これらはフロントエンド実装担当者しかわからない。よって、画面描画用APIのインターフェース設計はフロント側が主体でするべきと思った。
フロント側はVuexが乱立していたため、可能な限り1画面に1Storeの状態になるようにした。同じ画面に複数Storeを参照すると、Store更新もれがおこりやすい。getterとかも乱立してくると保守が辛いため、可能な限りStore利用は避けるべき。
UI表記や見た目・テキストの改善など
特筆すべき事項なし。上がってきた改善点を取りまとめ、関係者にネゴって実装＆リリースまで担当した。もう息を吸って吐くように進められる。UI/UXは色々な人の意見を取りまとめるのが大変だが、機能に矛盾がない限りデザイナーさんの意見を信用することにしている。やはり「餅は餅屋だよ」3である。
プロジェクトマネージメント
FY21 3Qに引き続きチームリーダーという名のプロマネをやっていた。引き続き、トラブル時に速攻で飛びついて旗を振るのを意識して行った。3Qに比べるとトラブル少なめだったのでよかった。ただ、やはり開発者業務と両立するのはキツい。
他チームの困りごとサポート
ビジネスチームより「DBのデータを使って分析したい」と言われた。データはBigQueryに連携している。最初は「Viewを準備する必要があるのか…？」という雰囲気になったがスプレッドシートのデータコネクタ機能を見つけた。テーブルコネクトと用途に応じたサンプルSQLをスプレッドシートにセットして渡した。
SQLはコメントアウトで「ここで〇〇条件に絞り込む」など、やっていることをクエリに記載した。また、カラムの意味や詳細も別シートに記載した。こうすることで、ビジネスチームは自分の欲しい情報を自分でクエリできるようになる。こちらには問い合わせが来なくなるし、ビジネスチームも開発側の対応を待つ必要なくデータ集計できる。何事もちょっとしたフォローアップをしておくのが重要かも。
別チームのフロントエンドフレームワーク移行支援
Riot.jsをVue.jsにしたい。退職済みのメンバーがある程度作ってくれたんだけど、完成度はわからないという状態だった。「じゃあテストを書いて完成度見てみましょう、それで考えるのが良さげでは」と提案し、チマチマCypressテストを整備着手した。都合等もあり、あまり進まなかった。
会社全体でフロントエンドエンジニアが少なめなので4、一人でできることには限界があるなと思った。また、支援先にフロントエンドメンバーはおらず「できる人に任せたい」という感じだったのも進まない要因だったと思う。もう少し「事業に影響が出るから本気でなんとかしたい」となるまで待ってもよかった。駆け引きするのは本質じゃないので好きではない。
反省点・課題
理不尽なこと・非効率なことがあるとすぐ怒り駆動になってしまう。カッとなってパッチを投げるのはいいことかもしれないが、正しさでぶん殴られると人は死ぬ。正しくても交渉しづらくなってしまうし。
もう少しカッとならないように気をつける必要がある。アンガーマネージメントを学んだ方が良さそう。
手を動かす時間が減った。だからマネジメント系は敬遠されるんだよな。
Object操作・配列操作は本当に苦手で時間がかかる。書かないと上手くならないので言語を変えて練習する必要がありそう。
関わっているアプリの特性上、DNS・HTTPヘッダー・証明書などWeb周りの技術総合選手権で生き残る必要がある。証明書はなんとなく理解できてきたが、DNS・ドメイン周りはもうちょっと理解する必要がありそう。
社の実装はVue2.xだが、正直今後先が暗い。かといってVue3.xやReact.jsの経験はないので素振りが必要。素振りしないでぶっつけ本番だとアンチパターンを踏みやすい。余裕があるうちにやっておきたい。
良かった点
進捗が悪くても信じて任せる、というのができた。誰だってやらないとできるようにならない。
チーム全体を通し、タスクの手戻り・差し戻しがなかった。しっかり時間をとって関係者に筋を通しておく、というのが効果的だった。今後も継続。
メンバーの行動に良いと思った時、すぐフィードバックするようにした。自分は悲観的な性格だが、「いいですね」「助かりました」と言ってると少し前向きな気分になれる。船頭が大事なので。これも継続。
CypressでE2Eテストを書く方法を覚えた。要素探索するにはテンプレート部分の設計を「壊れにくい」ようにしておく必要がある。やはり後から書くよりテスト駆動チックに進める方が良い。
Next Action
- コミュニケーション系の本を読み、アンガーマネージメントについて学ぶ
- カッとならないようにマネジメントの勉強してもいいかも。ITILとか
- 複数の方法でTODOアプリを作る。同じものなら比較もしやすい
- Object操作・配列操作をする
- テストの書き方
- 設計方法
