196
161

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

お題は不問!Qiita Engineer Festa 2023で記事投稿!

私の3年で得た経験から学ぶ!業務委託先で成果を上げる秘訣9!SES、フリーランスの最速戦略!

Posted at

背景

友人のエンジニアと会話をした際、自社 or クライアント先のどちらで働く方が良いのかという議論になりました。その時に友人曰く「クライアント先で開発するのは気が引ける。成果を出さないと切られそうで怖い
と言っていました。その言葉が頭に残り自分は成果を出すために何をしてきたかを振り返ってみたので、彼と同じように 「委託先での開発に苦手意識がある方」のお力添えが出来ればと思い書いてみました。
私はエンジニア3年目でこれまで並行していたこともあり11案件に携わった経験からの内容になります。

業務委託先で最速で成果を上げる秘訣9

本記事では技術に関してではなく成果を出していく上での考え方の視点で書いておりますのでご了承ください。

1.コミュニケーション★★★★★

クライアント先のプロジェクトに参加する際、事業やサービスの規模によりますが、フロントエンド、バックエンド、インフラ、デザインなどの各チームが分かれていることがあります。チームはさらに細かく分かれていることもあり、タスクを進める上で別チームを巻き込むことがあります。
関わりがないメンバーに連絡を取ることは、誰しも気が引けるものです。なので、積極的に空き時間を利用して他のチームメンバーに話しかけることで後々タスクで協力を求める際(問題が発生した際など)に気軽になったり、コミュニケーション不足による認識の齟齬を防ぐ事にも繋がるはずです。
長く働く上で心理的負担をいかになくしていけるかは重要になりますので、クライアント先に入った際は認知されるように挨拶や会話をしていきましょう。
一見、メッセージ上では冷たいから苦手意識があったが直接話したりするとめちゃくちゃ話しやすいし、優しかったということはよくあります。

2.考えて行動し価値を提供する ★★★★

エンジニアとして働く中で、プロジェクトマネージャーやリーダーが忙しすぎて新しいタスクを振る時間がない、という状況に遭遇することがあります。そういった時にどう考えて行動するかが重要です。単にタスクがないからと言って休むのか、それとも新たな知識を吸収するためにドキュメントを読んだりコードを調査するのか。また、状況によっては、PMやリーダーが次にどのようなタスクを振る可能性があるのかを予想して、準備を進めることも選択肢の一つです。
例えば、リーダーがどういったタスクを振るのか予測がつく場合、それが直ぐに対応可能か調査します。事前に調査することでデザイナーや他のメンバーに確認が必要か知ることができます。確認が必要であれば振られた際に伝えることができ、別の直ぐに対応可能なタスクに取り掛かかれて効率的に作業を進めることができます。
このように自分が置かれている状況において「今」何ができるのかを常に考えることは重要です。
ただし、どのタスクが割り当てられるのかが明確でないときは、空回りする可能性もあるため、臨機応変に適用することが求められます。

3.できないことを伝える勇気★★★★

エンジニアの仕事では、難易度(高)な実装やバグ調査に直面することがあります。何度考え、試しても解決できない場合、プライドを捨て、正直にできないと伝える勇気が必要です。
私たちはクライアントから限られた時間を与えられ、その中で仕事を行っています。なので、解決の糸口が見えないタスクを長々取り組んでいても、クライアントは喜びません。
もし私がクライアントなら解決可能なタスクに取り組んで欲しいと思います。
ただし、重要なのはできなかった理由を言語化することです。この理由をクライアントに明確に伝えることで、タスクの優先度を再評価したり、アドバイスを得ることができます。結果的に、このフィードバックにより問題が解決することもあります。
私自身、アサインされたフロントエンドのタスクで「ロジック的にバックエンドが原因では?」というようなタスクがあり、伝えたことがあります。脳裏で「もしかしたらバックエンドではなかったらどうしよう」と思いながらも理由を説明したところ、バックエンド対応が必要でフロントエンドでの対応だけでは永遠と終わらないようなタスクを振られた経験が幾度とありました。振り返ると伝えておいてよかったと思います。

4.質問戦略〜効率的かつ有意義に〜★★★

多忙な業務中に質問をされると、受ける側は思考を切り替えたり、集中力を切らすことがあります。そのため、頻繁に質問されることを好まない方もいます。しかし、必要な質問をしなければならない状況もありますので、その際には質問をまとめて、簡潔に伝えるようにしましょう。
可能であれば仕様やタスクが振られた際に、必要な情報が得られるような質問しましょう。
例えば、初回のタスクが割り当てられた場合、最終的にはそのタスクの実装がリリースされるはずです。この情報からさまざまなイメージを膨らませてみましょう。
「GitHubのブランチ運用はどのように行われているのか?」
「Slackを使っているなら、レビューは誰に依頼すれば良いのか?」
「どのような形式でPRを作成すれば良いのか?」
「リリース対応は誰が行うのか?また、自分がリリース対応をする場合、何をすべきなのか?」
このように、タスクの一連の流れを想定し、それに基づいて質問することも大切です。タスクを受け取ったら、「よし、実装しよう」と思い立つかもしれませんが、どのブランチから始めるべきか分からないとなると、再度質問をしなければならなくなり、お互いの業務効率が悪くなってしまいます。このような細かい点に注意し、効率的な業務運営を心掛けましょう。

5.ドメイン知識の習得★★★★

クライアント先に入るとどんなコードを書いているのか気になりがちになりますが、スタートダッシュを成功させるにはどんなサービスでどんな機能があるのかなどを確認する方が大事かと思います。
ドメイン知識を持つことで、コードを読んで機能を理解するというアプローチを逆転させることができます。つまり、「このような機能があるから、こんなコードが書かれているのだ」という理解へと導かれます。これは答え合わせを行うような感覚に近く、知識がより深く頭に刻まれるはずですし、振られたタスクを達成するイメージ力も変わってくるかと思います。

6.過去のPRを分析する★★★

プロジェクトに参画するとその企業やチームには独自のコーディングスタイルや運用ルールが存在します。ですので、過去のPull Request (PR) を確認し、チームメイトがどのようなコメントを残しているのかを確認することが必要です。これにより、自分のPRに対する指摘を減らし、レビュワーの負担を下げると共に、過去にどんなissueがありどのように解決したかなどの知見が高まります。

7.技術的な質問をする場合は答えを聞くな提案をする★★★

プロジェクトに参加している以上、技術的に理解できないことが生じることは避けられません。そんな時に、単純に「これがわからないので教えてください」と聞くのか、それとも「私は〜と考えているのですが、いかがでしょうか」と提案形式で質問するのとでは全然印象がかわります
何がわからないのかを一つずつ言語化することが大切です。
まずはゴールのイメージを掴み、それを達成するためには何が必要かを掘り下げていきましょう。
仮に「これがわからないので教えてください」と質問をして教えてくれるような案件先もありますが、自分で考えない癖が付き成長を阻害する事になりかねないです。
分析すれば、必ず何かヒントが見つかるはずです。これは特にバグの調査などで重要な思考法です。

8.サービスを停止しないことが最優先!★★★★★

クライアント先で開発する以上、サービスを停止しないことが何よりも重要であると思います。もちろん、人間である以上、ミスが起こる可能性があります。それがサービス停止につながったとしても、焦らず、冷静に対処していきましょう。
クライアント先で働き始めると、早く成果を出したいという気持ちが強くなります。そのため、スピードを重視しすぎてしまうことがありますね。確かに、高速でタスクを終わらせる人材はクライアントから見れば魅力的かもしれません。
しかし、クライアント先の考えとしては如何にサービスを止めずに継続的にアップデートを行うかであると思います。
速く作業を進めることで思いがけない箇所でバグが生じ、そちらを調査、対応となると無駄な時間&信頼を失ってしまう可能性があるため、スピード勝負という考え方は避けるべきです。
タスクの完了が遅くなる場合でも、その理由を適切に説明すれば問題ありません。ただし、遅れが生じるのであれば事前に報告するのがベストです。報連相を自ら定期的にするだけで信頼も上がるので、意識してみましょう。

9.期待値を適切に調整しましょう!★★★

タスクが予想よりも早く終わることがあります。その際には、すぐにプルリクエストを出してタスクを次々にこなしたいという気持ちが湧きますが、私はすぐには提出しません。その理由は、タスクが早く終わるほど過度な期待が生まれ、ドメイン知識や影響範囲の理解が十分でない状態で、更に難易度の高いタスクが割り当てられる可能性があるからです。
新しいプロジェクトに参加したばかりの段階では、過度な期待により自身の能力を超えたタスクが与えられ、それを早く終えようと残業をして問題をごまかすような状況になると、自身に大きなストレスがかかる可能性があります。
そのため、タスクが早く終わった場合でも、自分が書いたコードに対して責任を持つために、影響範囲にデグレードがないか、自分が書いたコードを十分に理解して書いているかを再確認することが重要です。この際、関連するドキュメントを読むなどして全体的なドメイン知識を深めることが大切です。
タスクの解決速度に取りつかれてしまい、信頼を失うことのないよう注意が必要です。

まとめ

  • コミュニケーション
  • 考えて行動し価値を提供する
  • できないことを伝える勇気
  • 質問戦略〜効率的かつ有意義に〜
  • ドメイン知識の習得
  • 過去のPRを分析する
  • 技術的な質問をする場合は答えを聞くな提案しよう
  • サービスを停止しないことが最優先
  • 期待値を適切に調整しましょう

成果をあげる上で重要なことはクライアントの立場になり考えて行動することで、その結果として信頼関係が構築され、重要なタスクが任されるようになると考えています。
2~3年経験を積んだエンジニアの技術力はそこまで大きく変わらないと思います。上記9つを意識することでクライアントの評価は更に高くなると考えています。

長文となりましたが、最後まで読んでいただきありがとうございました!皆さんにとって良いエンジニアLIFEになりますように!!

196
161
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
196
161

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?