はじめに
フロントエンドエンジニアとして、これまで数多くのコーディング案件やシステム開発に携わってきました。
完璧な仕様書が来てその通りの実装ができることは滅多にありません。
こちらで要件を整理したり提案したりすることも多く、バックエンド・デザインチームとの折衝など、「コミュニケーション」も仕事をする上でとても重要です。
今回は、私が実務を通じて気づいた、エンジニアとして成果を出し、信頼を勝ち取るために大切にしているポイントをまとめたいと思います。
1. 「言われた通り」ではなく「真の要望」に応える
クライアントからの要望は、必ずしも「正解」であるとは限りません。
クライアントの要望の裏側を見る
「この改修をしてほしい」と言われた時、何も考えず言われた通り実装しても業務的には問題ありません。しかし、なぜそこを改修してほしいのか？その裏側には「ユーザーの離脱を防ぎたい」「お問い合わせを増やしたい」「セキュリティを向上させたい」などの真の課題が隠れています。
業務では裏の課題までは伝えてくれないことも多いので、タイミングを見つけて聞き出してみるとその課題を解決するにはプラスでやらなくてはいけないことが実はあったりします。
もしくはその方法では解決できない可能性もあります。
「要望」の裏にある「課題」を見抜くことが、プロの仕事の第一歩です。
もちろん言われた内容はこなせる状態であることは大前提というのは言うまでもありません。
そして裏の課題を見抜いたからと言って指摘しても「そんなことこっちも分かってるが、あえてやるんだよ」となるかもしれないです。
裏の裏にまた目的があるかもしれないので、ツッコミ過ぎないバランス感覚も大事かもしれません・・・！
「できること」と「やるべきこと」を区別する
技術的に実装可能であっても、予算や納期、あるいは将来の保守性を考えた時に、いまそれをやるべきかどうかは別問題です。
「パターンAは技術的には可能ですが、この方法だと〇〇なため、今回はパターンBの方法で進めるのはいかがでしょうか？」といった提案ができるかどうかが、単なる作業者とパートナーを分ける境界線です。
実装したはいいものの、将来メンテナンスで困るのは自分だったりします。
（過去の「負の遺産」に苦しめられた経験、皆さんもありますよね？笑）
双方が納得する方法を見つけ出すこともエンジニアとして大事です。
2. 相手に合わせた翻訳者になる
開発プロジェクトには、非エンジニアのクライアント、PM、デザイナー、バックエンドエンジニアなど、多くのステークホルダーが存在します。
伝えるべきことを相手によって変える
専門用語を使って正確に話すことが、必ずしも正しいとは限りません。
本来は技術的に正確に伝えるべきですが、そのすべてを伝えることが、かえって良くないケースも多くあります。
誰がどこまで知っておくべきかは担当範囲によって変えるべきです。
（だいたいのシステムにはユーザーロールと権限設定がありますよね）
- 対クライアント(非エンジニアの場合)： 要望や課題ベースでの会話が基本。システム用語で圧倒するのではなく、非エンジニアの人でもわかる言葉で説明する。（もちろん突っ込まれたら深い話をする）
- 対デザイナー： そのUIを実現するための実装難易度や実装しやすいデザインのすり合わせ、「ユーザー体験やパフォーマンスへの影響」など実装面での視点、画面遷移やアニメーション、各パターンでのデザインのヌケモレなどの伝達。（ディレクションをデザイナーがやることが多い）
- 自社メンバー： 技術面やクライアントやデザイナーへ伝える内容、各人の立場などを整理してこちらの行う役割を明確にする。（実装フェーズでは各ステークホルダーの情報をとりまとめたり、全員がうまく動けるようにさりげなく導くことも）
これは一例です。
各担当者の知識レベルや立場に合わせて言葉を選ぶことで、合意形成のスピードは劇的に上がります。
柔らかく、かつ言うべきことは言う
心理的安全性を保つために、物腰を柔らかくすることは大切です。しかし、それは「No」と言わないことではありません。
無理なスケジュールや仕様矛盾に対して何も言わないのはリスキーです。あくまでもいいシステムやサイトを予定通り作ることがこちらの仕事なので、目的達成のために柔らかくかつ明確に事実を伝える姿勢が信頼を生みます。
（それでもどうしてもやらないといけない場合は頑張るとか、どうするかは状況次第）
3. 全体最適の視点を持つ
自分の担当範囲を守ることは大切ですが、そこに固執しすぎると良いプロダクトは生まれません。
課題解決の「隙間」を埋める提案をする
仕様書やデザインには、必ずと言っていいほど「考慮漏れ」があります。
エラー時の挙動、読み込み中の表示、データが空の場合の表示など。これらを見つけ「ここが抜けていますが、こういう挙動にするのはいかがでしょう？」と先回りして提案することで、手戻りを防ぎ、チーム全体の助けになります。
管理者とユーザー、両方の視点を持つ
フロントエンドはエンドユーザーのためのものと思われがちですが、その後ろにはシステムを運用する管理者がいます。
ユーザーにとって使いやすいUIであることは大前提ですが、同時に「運用者が更新しやすいか」「管理画面は複雑すぎないか」という視点も不可欠です。使いづらいシステムの末路は情報更新されないサービスとなり、ユーザーにも使われないシステムになってしまうからです。
ただ良いUI・UXを作ることは実際難しいので日々磨いていかないといけないですね。
自らの責任範囲を明確にする
ここまでは依頼されているけど、これ以上は依頼されていないという判断。
また、「この作業はデザイナー担当、この作業はサーバー管理者担当なのでこちらはやらない」
など、作業の担当をはっきりさせることが、健全な開発体制を維持するために必要なスキルです。
こちらで判断できないことは判断・実行しない、などいろいろ実務上ではリスク管理が大切になってきます。
これまでの話と矛盾しているように聞こえるかもしれませんが、仕事ってそういうものですよね。
おわりに
技術はあくまでも手段です。
私たちエンジニアの価値は、美しいコードを書くこと以上に、クライアントやユーザーの課題を、技術とコミュニケーションを用いて解決することにあります。
- 要望の裏側を読み解く洞察力
- 相手に合わせた伝達力
- 全体を見渡す俯瞰力
これらを意識して行うことで、仕事の質が向上しクライアントからの良い評価をいただく機会が多いような気がします。
若手エンジニアの方や、これからキャリアアップを目指す方は、ぜひこれを意識して仕事を進めてみてください👍
Discussion