shoota works
HomeBlogProfile

Findy2023下期MVPに選ばれたのはなぜだったのかを考える

Photo by Findy Inc.

Findy-day

2024年2月8日、自分が所属しているFindy株式会社の全社総会（Fine-day）があり、参加してきました。
半年に一度行われるこのFine-dayは、ビジョンや今後の会社方針発表などのいわゆる「全社総会パート」に加え、直前の下半期に活躍した社員の「表彰パート」もあります。
自分はフルリモートなのでリアル参加はいままでしていなかったのですが、いい感じに日程が合いそう＆表彰候補にノミネートされたので初めて参加してみました。

Fine-dayの詳しい様子は以下の会社ブログにまとめられています。

MVP受賞

社員の表彰はさまざまな観点でそれはそれはたくさんの賞があり、今回は2023年後半の半年間を対象とした表彰でした。
自分も候補者にノミネートされていたので候補者席に座り、近くに座っている人たちの名前が呼ばれていくのを「わぁ〜」と拍手をしていました。

だんだん残りの賞もすくなくなったあたりで、「ああ、自分は今回は選ばれなかったなぁ」などと諦めていました。
というのも、MVPは全社員を対象とした選出なのです。

お金を稼いでいたり、難しい局面を打破したり、みんなの仕事を繋いだり、お客さんにたくさん感謝されたり、わかりやすい成果が表彰されるんだろうなぁなんて思っていたので、ただただコードを書いていた、それもフロントエンドしか書いていない自分が選ばれるとは少しも思っておらず。

少しだけ残念な気持ちになり、心ここにあらず、その後の会食メニューのことを考えていたのですが、最優秀賞であるMVPの発表で自分の写真が バーーーンッッ とスクリーンに映し出された瞬間に「オロロロロ...」となるばかりでした。
「さすがエンジニアのためのプロダクトを作る会社、パフォーマンスが高ければMVPとれるのか！」などと思っていました。

が、果たして本当にそうなのか。

自分がやってきたことをもう少し客観的にみて、なにが役に立ったのか？を見つめておこうと思います。
なお、開発そのもののパフォーマンスは数字で振り返るFindyでの一年ですでに書いたのでその辺は割愛します。

自分の能力を分類して分析してみる

意外と自分のことを自分でよくわかっていない可能性があり、自己評価と他者評価のギャップがありそうです。
このままでは自分を見失っていそうな、そんな不安から夜しか眠れなくなってしまいそうなので、ちゃんと自分の得手不得手を見据えつつ分析をしてみようと思います。

余談ですが、最近「葬送のフリーレン」がNetflixに配信されるのを楽しみにしていています。
OPテーマが YOASOBI から ヨルシカ に変わった時はなにかこう、寂しさと嬉しさが混じった不思議な気持ちになりましたね。

プログラミング能力

まずは純粋なプログラミング能力について考えてみます。プログラミング能力は大きくわけていくつかの能力で分類できそうです。

開発能力

  • プログラムをどれだけ早く仕上げられるか。（開発スピード / 安定性）
  • どれだけ難易度の高いトピックに取り組む事ができるか。 （スキルレベル）
  • 出来上がったプログラムがどれだけ安定してるか、バグが少ないか。（開発品質）

運用能力

  • 既存のプログラムをどれだけ理解しているか（アプリケーション理解）
  • 作ったプログラムの他者利用のしやすさ、変更のしやすさ（設計）
  • 既存のプログラムをより使いやすくできるか（リファクタリング）

こんなところでしょうか。

この中で自分が得意に感じるのはスピードと設計かなと思います。逆にバグは人よりもたくさん出す方です。
リファクタリングや難度の高いものを作るのもすきですが、好きなだけで得意というほどではない。

ただバグはゼロにはならないので自分としては「Do is better than Perfect」な気持ちで書いていて、Findyのマインドも「許可を求めるな、謝罪せよ」の色が強いので、そこはマッチしているのだと思いました。
今回は難度がめちゃめちゃ高いリファクタリングを任せてもらえて、それはそれは楽しかったのと、楽しそうにしているところが傍から見ると「ピンチを楽しんでるポジティブ」に映ったのかもしれません。

あと単純に自分が書いていて「書きにくいなぁ」と思った部分をゴリゴリ自分好みに書き直していた結果、結局はリファクタしていたというパターンも結構合ったので、そこも良かったのかもしれません。

チーム貢献

つぎにチーム貢献もエンジニアリングには大切だと思うので、その辺も考えてみます。

個人でやれること、学べること、興味関心視点などはめちゃめちゃ小さく狭いので、刺激をくれたり疑問を投げかけてくれるひとは自分にとってとても重要です。
性格診断などをすると、探究心や好奇心が強いという結果が出がちな自分ですが、その自分の成長の肥やしになってくれるからです。

ただ自分の成長のそのために（悪く言うと利用して）、他者と関わろうとしていたので、ここも意外といろいろやっていました。

  • ペアプロ文化がなかったので、「設計共有」や「ツール解説」という名目でペアプロを道場破りのように突発で申し込んでいた
  • React周りの技術トークがしたくなったので輪読会を主催して、早口オタクぶりを発揮した
  • リファクタを長期間でちょっとずつ進めるために、近いドメインの変更が入りそうだったら勝手にPRレビューをした

振り返ってみると自分が思っていた以上にチームやメンバーのことに首を突っ込んだりしていたので、この辺がみんなに受け入れてもらえたのがよかったようです。
むしろ受け入れてくれた皆さんに感謝したほうがいい。

プロジェクト貢献

つぎは機能開発のなかで「プログラムを書く」以外の貢献について考えてみます。いわゆる「エンジニアリング」というか、そういう振る舞いです。
強く意識していたというほどではなく、以前にエンジニアリングマネージャーをしていたときに「こういうふうにしてもらえると楽なんだよなぁ」と思っていたことをやるようにしていただけです。

できるだけ質問ではなく提案をする

  • 仕様の判断に困った時に質問をすると、だいたいの場合は工数はどうか、リリースがずれるか、あとからこうできるか、などの質問が返ってくるだけなのでそれらを見越した提案をする。
  • 提案は、考えうる（到底選ばれないであろうものも含めた）選択肢を用意して説明する。
  • 1つの課題についてなんとか1往復の会話で結論らしいものにたどり着けるようにする。
  • 可能な限り技術視点ではなく、ユーザーやシステム視点でどういう体験になるかを説明する。

明日自分が死んでも大丈夫な状況をつくっておく

  • いわゆるバス係数。設計や手順を自分のなかに仕舞わない。
  • 自分じゃなくてもできることは自分以外でもできるようにドキュメントを書いたり説明会をしたりしておく。なぜかいつの間にかやらなきゃいけない仕事が減る。
  • 後続の作業を単純化することにコストをたくさん払う。払っている間は不安でいっぱいだが、だいたいの場合は払ったコスト以上に回収できる。

辛くなりそうなことは空気を読まずに言う

  • 「やりたいこと」と「実装コスト」が全然マッチしないのが開発というものなので、気軽に提案されたものが大変だったらちゃんと言う。
  • 作り始めてから方針転換するとサンクコストが生まれて空気が微妙になるので、空気を読まないほうがいい。
  • 仕様を折衝したり思想をすり合わせたりするのは対立構造ではなく協力構造なので、いちいち気にしない。

文字におこしてみると、普段は意識していなくても実はいろんな信念に基づいて働いていました。
意外とちゃんとしてるな自分。

おわりに

MVP表彰を機会に自分の働き方や特徴に思いを馳せてみました。

普段はうまくモノが動かなくてイライラするときもあるし、ハイ完全に理解した！ハイ天才！と思うときもありますが、改めて自分の仕事のしかたを見てみると自分なりのこだわりと信念がある事に気づきます。
たまにはやろう、自己分析。