今年の夏くらいから、新規サービスの開発メンバーにジョインして、
この一人アドベントカレンダーで書いてきたような技術を用いた開発をしていました。
今まで働いてきた環境から大きく変わり、自分のエンジニアとしてのスタンス・考え方も大きく変わりました。
アドベントカレンダー最終日
ということで、自分のスタンス・考え方がどのように変わっていったのかツラツラと語っていこうと思います。
この記事のまとめ
- エンジニアにはサービスの健康状態を管理する責任がある
- 事業会社のエンジニアは、高い技術力だけじゃなく全体視点で物事を判断できると強い
- 事業会社のエンジニアは、話す相手の視点に合わせてコミュニケーションができると良い
開発メンバーにアサインされるまで
軽く自己紹介
どうも、ちーずです。
25歳の女の子で、何事も根性でどうにかしようとするタイプの人間です。
2019年に株式会社エイチームにデザイナーとして入社しました。新卒3年目です。
もともとは、既存サービスの改善施策の企画や、施策の実装をしていました。
実装といっても、主にマークアップやスタイリングをしており、たまにJavaScript(jQuery)やVueを書く程度でした。
毎日サービスの数値を真っ先に見にいくような、ビジネス寄ったタイプのエンジニア？デザイナー？でした。(よくマーケ脳だよねって言われていた...笑)
フロントエンドエンジニアになりたかった
フロント寄りの業務をしていましたが、自分自身をフロントエンドエンジニアとして名乗れるほどの技術がなく(※ 自己評価です)、課題に感じていました。
フロントエンド領域の技術を用いて何かを作ってみることが好きだし、フロントエンドエンジニアに憧れていたため、
自分の出来る限りの学習をプライベートで進めていたものの、正直伸び悩んでました。。。
ただ、フロントエンドエンジニアになりたかったので、周りに「フロントエンドエンジニアに俺はなる！！」とよく言ってましたし、それなりのアウトプットもしていたかなと思います。
夢が叶った
その努力が実ったのか、React(Next.js)で開発する新規サービスの開発メンバーとしてアサインされました。
自分が初期メンバーとして参加できると思っていなかったので、とても嬉しかったです。
超苦労した
しかし、今までデザイナーの組織で働いてきたのもあって、考え方やスタンスの違いを埋めるのにとても苦労しました。
技術レベルも周りに比べて劣っていると感じてしまい、心が何度も折れかけていました...
ただ、仕事はとても楽しく、充実感がありましたし、なによりも今まで以上の成長欲がありました。
毎日仕事終わってからもコードのリーディングをしてインプットしたり、分からないことがあればその日のうちに解決するために勉強したり、、、できる限り追いつけるよう頑張ってました。
ちゃんと成長した
この半年間振り返ってみると、できるようになったことが自然と増えていました。
そして、その「できるようになったこと」をちゃんとアウトプットしよう！！と思ったことが、この一人アドベントカレンダーやるきっかけです。
新規プロジェクトの開発メンバーにアサインされて変わった「考え方」
長々と自分のことを書いてきましたが、本題です。
今までの自分は「超よしな人間」で、目先の利益を最大化するためには、
多少無理してでも、とにかく沢山の施策を、とにかく早く施策を実施しよう！！というスタンスで働いており、
周りから依頼があった時は、わりとどんなことでも「できます、やりましょう！！」と言うタイプの人間でした。
そんな自分は、エンジニア組織で働くようになって、「エンジニアとしての自覚が足りない」という健全な危機感を抱くようになりました。
エンジニアの責任ってなんだろう？
自分はエンジニアとしてどんな貢献ができるんだっけ？
そんなことを悶々と考えながら、開発をしていました。
そんな中、このプロジェクトに社内の超つよつよフロントエンドエンジニアがジョインしました。自分にとって憧れのエンジニア象でした。
その人と働いていく中で、自分なりに「エンジニアの責任とは？」のアンサーにたどり着いたの気がするので、この記事にまとめてみます。あくまで持論です。
エンジニアはサービスを守る責任がある
「サービスの健康状態を正しく管理できるのは、サービスを作った人しかいない。」
わりと当たり前だけど、そのことにちゃんと気づいたのはこのチームにジョインしてからでした。
人為的にサービスをテストして質を担保することももちろんできますが、
どのようなロジックで動いているのか、そのロジックにはリスクがどれだけあるのかなどは、エンジニアにしか正しく把握できません。
そのため、エンジニアには「サービスが正しく動き続けることを担保する」責任があります。
今までの自分は、事業を加速させることを最優先にしてしまい、バンドエードだらけのサービスを作りがちでした。
もちろん事業スピードも大事ですが、それで大きな不具合を発生させてしまい利益損失を生んでしまったら本末転倒です。
サービスの健康状態を周りに正しく伝えること、
そして事業のスピードと保守の塩梅を見極め判断していくことが、事業会社のエンジニアには求められます。
サービスを守るためのアクション 3点
1. エンジニアはなるべく無理をしない選択をする
人間の管理能力ら一定であるため、管理できる状態＝サービスを守れる状態 を維持するために、無理をしない工夫をする必要があります。
例えば、、、
- 正しい工数見積もりをする
- 元あるロジック、ライブラリに頼る
- そもそもその機能が必要なのか、代替が効くものはないか考える
多少無理が必要なケースもあると思いますが、このマインドを持つことが大事かなと思います。
2. エンジニア視点を伝えることをサボらない
これは各職能に言えることですが、同じサービスを作っていても発揮すべき能力は異なるため、見えている視点も異なります。もちろん共通する部分もありますが。
そのような部分が別の職種の人にも正しく伝わるように説明する責任があります。
意見が衝突するときは、まずはヒアリング
各職能が求める事が異なれば、意見が衝突することももちろんあります。
そのような時は、まずは相手の求める事をちゃんと理解し、材料を揃えた上で事業目線で一緒に判断することが大事です。
ときには会話の強弱も大事
重要度によって発言の強弱をつけることで、
「あの人がこんだけ強く言うってことは、相当大事なんだろうな」と感じさせることができます。
事業視点・相手視点での言葉で会話する
専門職は特に言えることですが、自分の知っている言葉で会話しがちです。
その言葉が必ずしも相手が知っているとは限らないため、正しく意見を伝えるために一度自分の考えを相手視点でどう受け取れられるかを考えた上で発言すると良いでしょう。
ただ、共通用語にしていきたいものに関しては積極的に使っていきましょう。
3. 高い技術力を身につけて、その時々で正しい判断をする
一番当たり前のことではありますが、
エンジニアは常に新しい技術をキャッチアップ(正しく理解)して、選択肢を増やして正しい選択できるようにしていくことが大事です。
このプロジェクトにジョインしてから、より強く感じるようになりました。
長々と語ってしまいましたが、
このプロジェクトにジョインして、
1人アドベントカレンダーやってみて、
良いチャレンジができたかなーって思っています。
ただ、1人アドベントカレンダー思った以上に大変。
来年はやりません！！！