LIVESENSE made*

リブセンスのエンジニアやデザイナーの活動や注目していることをまとめたブログです。

MENU

事業を推進するために必要なエンジニアスキル

こんにちは、新卒2年目エンジニアの片岡です。 正社員転職メディア『ジョブセンスリンク』の開発を行っています。

job.j-sen.jp

リブセンスには職種の『越境』文化が根付いています。 セールスに必要なデータは営業担当者が自らSQLを書いて用意します。 エンジニアがディレクター的な働きをして機能設計に深く関わることはリブセンスにおいて自然です。

このような環境下で、私は『開発者の立場から事業を推進する』という指針を持って他職種の方たちと協働しながら開発を行ってきました。

『事業を推進するエンジニアに求められるスキル・姿勢とは?』という自らに課した問いに対して、新卒としてリブセンスで2年間を過ごした経験からたどり着いた自分なりの答えを共有させていただきます。

事業を推進するエンジニアに求められるスキル・姿勢とは

1.危機感を持って技術を学び続ける

入社当初、事業を推進するためには事業ドメインの理解やマネジメントなど「技術以外の総合力」が求められると私は思っていました。

しかし実務経験を経た今考え直すとむしろ逆で、事業を推進するエンジニアにこそ技術が求められるのだと感じています。 設計・コーディング・プロジェクト管理など様々な技術がなければ中長期的に見て効率的な開発を続けることができないからです。 変化の早い業界ですから、継続的に新技術のキャッチアップを行うことも必要です。

課題に対し、解決できる術をもたないエンジニアは等しく価値がありません。 事業を推進するエンジニアにとって、特定の技術スタックにこだわらず様々な技術領域に理解があることは必要不可欠だと思っています。

いま私は、「様々な技術領域に対して、広く、かつ浅くない理解を得る」という指針を持って継続的な技術的キャッチアップを心がけています。

2.自分の給与以上の価値を生み出すコードを書く

あなたが今日書いたコードは、今日もらった給与より価値を生みますか?

これは私が先輩からかけられた質問です。

エンジニアなら誰しも、技術的に正しいことをしたいと思っています。 メンテナブルで、再利用性が高く、完結で分かりやすいコーディングを誰しもが心がけています。 また、技術的にエキサイトしたいと思っています。

しかし、自分が書いたコードが自分の給与以上の価値を生み出しているか意識しながら開発している方はどれくらいいるでしょう?

例えば営業の方々は、個人として直接売上に責任を追っています。 それくらいの当事者意識を、私は持っていませんでした。 生み出す価値は、売上でなくとも社会への影響など異なるもので構いません。

if文のネストを気にするのと同じくらい自分の書くコードの価値を考えよう、と私は意識しています。

3.スピードvs品質の二項対立に囚われない

開発を行う中で、品質に関するトレードオフが発生します。 すなわち、品質を捨ててスピードを取るべきか速度を落として品質を高めるべきか、という議論です。

業務の中で、私はどちらの選択肢も見ました。 品質に倒したプロダクトは、事業的に求められる期限を守ることができないことがありました。 スピードに倒したプロダクトは、のちに破綻して『負債』と呼ばれています。

スピードvs品質のトレードオフでは、問題は解決しないことを私は学びました。

その上で、重要なのは「守るべき品質は何か」を見極めることだと思っています。裏を返せば「捨てる品質」の見極めです。

ミッションクリティカルであったりボトルネックになりやすいと思われるところは、エンジニアの職務として徹底的に品質に倒します。 逆に要件が変わりやすかったり、作り直すのが容易であるような部分については、容赦なく品質を落とすことも必要だと思っています。

4.他職種から信頼を得られる仕事をする

さきほど、「品質を見極めて容赦なく捨てることも必要」ということを書きました。 これは関係者の協力なしにはできません。

例えば、日時の入力フォームがあった場合、ファーストリリースに間に合わせることを優先して外部ライブラリのUIを使ったとします。 これは一般にデザイナーにとって面白くありません。 サイトカラーやUI設計があって、その中に外部ライブラリの違和感あるデザインが入り込むのはエンジニアにとっても好ましくはありません。

だとしても、必要なのは「入力フォームに日時が入力できる」ことであって、きれいで独自性が高く入力しやすい日時入力フォームを提供することではありません。(その入力フォームがUX上重要な役割を担うような場合は別ですが)

この場合、チームのデザイナーの職務ややりたいことを聞き、その上で自分たちが提供するものの本質的な価値について話し合い方針を決める必要があります。

私が担当した新規機能開発の事例では、ファーストリリースではデザインを妥協していただき、ABテストでデザインをいじるタイミングで1から綺麗に作り変えました。 このように、他職種の立場にたって対話することを心がけ、信頼を勝ち取ることも事業を推進するエンジニアになる上では重要なことだと思っています。

詳しくはDevLOVEというイベントの登壇資料にまとめてありますので、もしよければ読んでみてください。

speakerdeck.com

おわりに

『事業を推進するエンジニアに求められるスキル・姿勢とは』というテーマで4つの観点を紹介しました。

少しでもみなさんの開発の役に立てば幸いです。