見出し画像

デザイナーがエンジニアの評価を任されて感じたこと

こんにちは、おしょうです。ナビタイムジャパンでデザイナーをやりながらユニットリーダーをしています。
今回は今期から行われた体制変更の話と、それによってデザイナーである私がエンジニアの評価を任されて感じたことについてお話しようと思います。自分の職域と異なる職域のメンバーを評価することがある方や、職域の違いに課題を感じている方は、何か参考になることがあるかもしれませんので、是非最後までご覧ください。

体制変更について

事業/研究開発部門とユニット

ナビタイムジャパンでは事業/研究開発部門と、ユニットが縦軸横軸で交わるような体制になっています。
事業/研究開発部門はサービス開発やデータ/技術開発など、実際にユーザーに届けるサービスやビジネスを作っている組織で、ユニットはメンバーの勤怠管理、評価、育成などを行う組織です。このユニットのメンバーが、それぞれ様々な事業/研究開発部門に配属されるような関係性になっています。

事業/研究開発部門とユニット

ユニットの体制変更

ユニットにはいくつか種類があり、開発者やQMなどが集まる「開発ユニット」、デザイナーが集まる「デザインユニット」、セールスなどが集まる「ビジネス開発ユニット」などがあり、職域の大きな枠組みでユニットが分かれていますが、今回の体制変更で、今まで「デザインユニット」として集まっていたデザイナーが、「開発ユニット」「ビジネスプロフェッショナルユニット(旧ビジネス開発ユニット)」に配属されることになりました。

体制変更の経緯

近年デザイナーの仕事は、Web/アプリ等のUIや営業資料、プロモーションクリエイティブなどはもちろん、マーケティングなどのビジネス面や、より開発を意識したデザインなど、考える領域が多岐に広がっています。

その一方でまだ「デザイナーは絵を作るだけ」という認識を持ってる人がいるのも事実で、絵作りの段階でアサインされるということもたまにある状況です。
そもそも「デザイン」とはデザイナーだけで考えることではなく、モノづくりに関わる人全員で考えることだと思いますが、まだまだデザインそのものや、デザイナーという職業に大きな垣根を感じる方が多いように感じます。

このようにデザイナーに求められていることと、デザイナーとの関わり方のギャップがある状況を改善したいということも踏まえ、デザイナーという職域の垣根を無くすことで、さらに良いモノづくりが出来るような相乗効果を生めないか、という背景から、体制変更の流れになりました。

エンジニアの評価をする準備の中で感じた、今まで関わっていた領域の狭さ

今まで自分はデザインユニットのユニットリーダーをやらせていただいていましたが、体制変更後も引き続き、開発ユニットのユニットリーダーをやらせていただけることになったため、同職のデザイナーだけでなく、エンジニアの評価もしていくことになりました。
開発ユニットにはiOS/Androidなどのアプリ開発、Web開発(フロントエンド、バックエンド)、サーバー開発、QM、インフラ、データ開発、経路探索エンジン開発などの技術開発…などなど様々なスキル、役割のエンジニアの方がメンバーとして配属されています。
普段仕事で関わるような方であれば、何となくやっていることは分かりますが、今まで関わりが無かった方もたくさんおり、具体的にどんな仕事をしているのか分からない方もいらっしゃいました。

そんな状況で正しい評価ができるはずも無いので、まず他の開発ユニットリーダーの皆様へどんな風に評価判断をしているのか、などについてヒアリングを行いました。
すると、社内動向の色んな情報を集めることで判断に活かしていたり、社内の有識者にヒアリングを行っていたり、自分の知識/経験だけを頼りにするというよりは、社内情報やメンバーをうまく活用して多面的に評価を行っていることが分かりました。
社内の色々なお話を聞けたことで、自分もある程度長くナビタイムジャパンで働かせていただいていますが、今まで自分が関わっていた領域はとても狭かったという気づきがありました。ある意味これも「職域の垣根」だったのかなとも感じました。

職域が異なることで「差がある」ことと「差がない」こと

また、職域が同じメンバーを評価することと、職域が異なるメンバーを評価することには「差がある」ことはもちろん認識していましたが、「差がない」ことがあることも分かりました。

差があること

  • 扱うスキルや知識

  • アウトプット

  • 関わる社内の領域/人

  • 興味関心の領域 など

差がないこと

  • 目標の立て方

    • 事業/研究開発部門の数値目標に向けてどう貢献するか

    • コミュニケーションの活性化/改善

    • スケジュール通りのリリース

    • 運用改善

    • 自己研鑽 など

  • 抱えている悩み/課題

    • コミュニケーション

    • キャリアプラン/成長

  • 仕事をする上で大事にしていること

    • チームワーク

    • エンドユーザーの体験

    • 自分自身の価値向上(スキルアップ)

    • 売上やDL数などの具体的な成果

    • サービスの品質 など

職域が異なることで「差がある」ことと「差がない」こと

もちろん差がないことにも、専門の知識やスキルが必要な所もありますが、大枠としては理解できそうだったので、自分なりの判断をすることはできると感じました。

「差があること」のギャップを埋める

「差がないこと」が思ったより多くあるという気づきが得られたのは大きかったのですが、「差があること」のギャップを埋めていかなければなりません。
上記気づきから未知の職域でも入り込んでいくハードルはそこまで高くなく、それぞれの職域の皆さんも受け入れてくれることも分かったので、その後もこのギャップを埋めていくために様々な方へヒアリング・調査を行いました。

  • メンバーが所属している事業のドキュメントを見たり、Slackのチャンネルを覗いてみたり、どんな業務をしているのかを追う

  • 各分野の有識者が誰なのかを調査。必要がありそうな方にはヒアリング

  • 昨年度のユニットリーダーやプロジェクトマネージャーへのヒアリング

  • メンバー自身との面談

などなどです。
差があることとないことの区別ができていたので、差があると感じたことについて、メンバー本人や、メンバーが所属している事業/研究開発部門、専門スキルの有識者へのヒアリングを行うことで、どこに伸び悩んでいるのか、どういったことに長けているのかについても、理解することができました。

これらを行ったことで、最初は不安がたくさんありましたが、開発ユニットでもユニットリーダーとして役割を果たせそうだと感じることができました。

エンジニアの評価を任されて感じた良かったこと

上でも書いていますが、働いている方の多様性を改めて知ることができたことは良かったです。存在としては知っていても、細かいところまで知るのは普段の仕事だけではなかなか難しかったと思います。

職域が異なっても評価を検討できる実感があったことも良かったです。深く知っていないからこそフラットに物事を見れる、というメリットも感じることができました。

その他にも開発をする上で大事にしていることなど、一緒に仕事をするだけでは見えづらかったことが多少なりとも見えるようになったので、普段のデザイン業務でもエンジニアの方との関わり方がより柔軟になったと感じます。

また、逆にデザイナーを見るようになった開発ユニットリーダーも多くいらっしゃるので、自分と同じようにデザイナーについてより深く知るきっかけになっているのではと思います。
事業の責任者やプロジェクトマネージャーも開発ユニットリーダーからヒアリングを受けた際に成果を伝える必要があるため、今まで以上にデザイナーの理解を深めないといけない状況になっていると思います。

まだ体制変更が行われてから半年と経っていない状況ではありますが、自分としては新しい発見があったり、職域の垣根が今までより低く感じることがあったので、他の開発ユニット、事業/研究開発部門側でも同じようなきっかけが生まれ、徐々にデザイナーの垣根が無くなっていくといいなと思っています。

課題とこれから

良い影響を感じる一方で、検討が必要なことも出てきています。
上述の通り、ユニットリーダーやマネージャーレイヤーの人には影響が出てきたとしても、各メンバー一人ひとりの意識を変えるには、何か他にも働きかける必要があります。
また、今までデザインユニットに直接きていた依頼や、デザインリソースの最適化、デザイナーの横の繋がりなど、体勢の変化に合わせてうまく移管できていないことはまだまだたくさんあります。
その辺りもどう整えていくのか考えていかなければなりません。

職域の垣根を無くしていきながらも、その環境の中、同じ職域同士横の繋がりをどう作っていくのか、職域特有のスキルアップやキャリア形成はどう行うのが最適なのか、などについては今後も試行錯誤しながら、社内で協力しあって、より良い方向に進めていければと考えています。

最後までご覧いただきありがとうございました。