株式会社MIXIのTIPSTARサーバーチームの若松（X：@Jaksho500）です。
本記事はMIXI DEVELOPERS Advent Calendar 2023 シリーズ1 の13日目の記事になります。
（1日遅刻しました。ごめんなさい）
https://qiita.com/advent-calendar/2023/mixi
概要
今年就職し、会社に属するようになりました。これにより、学生の頃とは異なり、特定の組織に長時間コミットメントするようになりました。その結果、必要性を感じたスキルがいくつかあります。今回は、それらのスキルについて紹介します。
年度末に目にすることが多い「新卒エンジニアの振り返り」「成長する秘訣は？」といったニュアンスの内容です。
モチベーション
先日、チームメンバーと「技術力とは何か」「エンジニアとしてどのように価値を提供するか」といったテーマについて話す機会がありました。
自分の考えを話しているうちに、学生時代の認識と比較して、意見が変わっていることに気づきました。それが面白く感じられたので、この体験を記事にまとめてみることにしました。
バリューとは
ここでは、エンジニアとしての成果を「バリュー」と表現します。
エンジニアの成果は、単に開発活動からだけではなく、様々な側面（例えば、開発した機能、後輩の育成、組織課題の解決、チームへの影響など）から生まれると考えています。
そのため、「バリュー」という表現が最も適切だと思いました。
バリューを発揮するために必要だと思う要素
学生時代、エンジニアとしてバリューを発揮するには、主にハードスキル（技術力とも言えます。技術力は技術的な知識や経験を指します）が重要だと考えていました。
ハードスキル* その他要因＝バリュー
しかし、現在では、技術力だけでは十分であると感じています。技術力をパフォーマンスに変換するためには、ソフトスキルも同じくらい重要だと考えています。
ハードスキル* ソフトスキル* その他要因＝バリュー
※その他要因には、事業やチームの状況、担当したタスクなどさまざま要因が含まれます。
変化
自分の中で、ソフトスキルの重要性が大きく増してきました。
この変化の主な理由は、ハードスキルの重要性は以前から理解しており、常に向上を意識していたのに対し、ソフトスキルの重要性には気づいていましたが、それを向上させる必要性にはあまり意識を向けていなかったからです。
ソフトスキルについて
ソフトスキルと聞くと抽象的に感じますが、具体的には以下の点に重要性を感じ意識するようになりました
- 思考の言語化
- 思考を伝える努力
- アクションへの移行
思考の言語化
この必要性を感じたのは、複雑な機能の設計をチームメンバーに相談する際でした。以下の問題に直面しました
- 自分が何を聞きたいのか明確に説明できない
- 複雑なコードの部分を正確に言語化できない。
といった課題を感じました。
ある程度の基本的な状況説明はできると思います。
+で、以下のような点を言語化できれば、効率的に適切な人に相談できると思います。
- 本当に聞きたいこと
- 自分が何に困っているのか
- その他の要点
- etc...
自分の考えが不明瞭に感じる時は、些細なことまでNotionに書き出しています。
この習慣を始めてから、自分が相談しそうとしていた内容は１つに見えていたが、実は２つだった。しかも１つはエンジニアではなくビジネスサイドの方に確認すべきものだった。
みたいなことがありました。
自分自身の考えを明確に把握できていない場面はあると思います。その状態で他の人に相談しても、自分の考えを支えられるはずもなく、課題の解決は難しいでしょう。
思考を言語化することで、新たな視点や効率的な問題解決につながると感じています。
思考を伝える努力
内定者アルバイト時代、複雑な機能の設計・実装を担当しました。
この機能はユーザーへの影響は小さかったものの、仕様やロジックは複雑でした。私は可能な限りの懸念点やシーケンス図をIssueに書き起こしましたが、文量は膨大になりました。設計完了後のチームレビューは困難を極め、当時は辛かったです（苦笑）。
以来、「レビューしやすいアウトプット（設計・PR）とは？」という視点で自分のアウトプットを出すように心がけ始めました。
そのためのアプローチとして、他のチームメンバーのアウトプットを確認し、個人的にわかりやすいなと思うものはバイブルとしてまとめており、参考にしています。
過去のものがおすすめで、「この機能の開発は大変だった」みたいな話をメンバーから聞くことがあると思います。そういった機能の設計・PRを見るとだいたい大きなIssueになっているので、進め方、見やすさなどの違いが顕著に現れていました。
プロジェクトごとにIssue、PRのテンプレートは用意されているものの、それに添えばOKというわけではなくタスクごとに最適な形を模索していくことを今後も意識していきたいと思います。
余談
コミュニケーションをとる相手が同じエンジニアか、QAか、デザイナーかによって、どのラインから説明すべき内容が変わってきます。相手のコンテキストを理解した上でコミュニケーションをとる。ということも「思考を伝える努力」では意図しています。
アクションへの移行
ここまで述べた２点は、他の人に相談する前の準備ですが、逆に「すぐにアクションに移せ」というものです。
「15分ルール」はこの文脈でよく耳にすると思います。
一方で、「15分ルール」にも難しさがあり、
- 考えが浅い状態で相談
- 時間的指標なので忘れてしまう
などが個人的にあります。
他にも心理的ハードルとして、以下のような心配事がありそうです。（どちらも以前の僕に当てあはります）
- こんな質問をしてもいいのかな？
- この程度のこともわからないのかって思われたりしないかな？
心配事を乗り越えアクションに移すための自分への言い訳として
- 思考の言語化
- 思考を伝える努力
が使えます。
「自分はこれだけ考えたんだ」「ここまで頭を働かせたんだ」という自分への言い訳になります。しかも、言語化が進んでいるので、相談内容を明確にし、タイミングを適切に定めることができます。
これによって、相談を円滑に行える + 自分の考えを言語化できる + 相談のタイミングを明確に定義できる といったメリットを感じています。
まとめ
社会人になり、特定の組織に長期間コミットするようになって、必要性を感じたスキルについて紹介しました。
「すごいエンジニア＝技術力めっちゃ高い」
ではない(なれない)ということを感じています。
「エンジニアとしての能力＝周りの人が自分のエンジニアとしての能力に対して置いている信頼」
とも見れると思っており、その信頼を向上させるためにはもちろん技術力も大切ですが、それだけでは不十分でソフトスキルにも意識を置いていこうという内容です。
ソフトスキルにも意識を向け始めて半年ほどですが、さらなる課題も見えてきています。
また機会があれば、そこに向けたアプローチも記事にしようと思います。
ありがとうございました。