エンジニア単価表の記事はこちら！
はじめに
社会人になってから数年。数々の失敗を目撃 & 体験をしてきました。
その教訓で、改善すればより仕事も人間関係も円滑に進み、エンジニアとしても成長できるだろうなというネガティブな点をまとめてみました。
僕も過去できていなかったり、今もできていないところはありますが、反面教師として伝えられたらと思います。
特徴
1.納期に間に合わない時、自分から報告してこない
明確に期日が共有できているのにも関わらず、直前もしくは遅れる旨を報告してこないパターンです。
責任感がない人に多い気がします。実力不足であったり、実装していくうちにタスクの見積もりがずれることもあるので勇気を持って報告しましょう！
2.タスク分解しないで、仕事し始める
機能実装のような中規模以上のタスクは、DB変更など下のレイヤーが間違っているとその上位の実装も全て修正しなくてはいけなくなります。まずは、タスクをいくつかに分割しレビューなどをもらってから進めると戻りが少ないと思います。
3.進捗の見える化をしない
タスク分解と似ていますが、PRを全て出来上がった状態でやっとオープンにするなどが挙げられます。
一気に全て実装してしまうと方向性が間違っているときに、切り戻しが大変です。
見えるかの一例としては
- タスク分解したチェックボックスを作っておく
- 最初にPRは[WIP]で作成して、適度にpushする
- issueやPRに作業コメントを残しておく
4.Noと言えない
Noと言えず開発の質を下げてしまうパターンがあります。
例えば、Biz側の要望に全て応えようとした結果PRのスコープが広がりすぎるなどです。
この辺りは、慣れだと思いますがスコープの違う開発は別タスクとして切り出すようにBiz側に提案しましょう。
5.仕様でわからないところを適度に質問できない
仕様はわからないが「できない」というレッテルを貼られたくないために質問できない場合です。
その時点でわからないのには自分の実力不足か、システムの説明資料が足りない・わからないなどの原因が必ずあります。
寧ろ次に触るエンジニアがすぐ理解できるように、あなたがドキュメントを新しく作成する気概でいきましょう。
ただ、あなたがコード上や指定されているドキュメントを探し切れていない場合もあります。
どこまで調べてから聞けばいいかわからない方は質問前に下記資料は見ておくといいと思います。
- 関連issue
- 関連PR
- ドキュメント管理ツールのキーワード検索結果(confluenceやNotion, GitHub, Slack...)
6.工数に休日や残業を含めている人
創業初期のスタートアップなど例外はありますが、基本的に残業や休日を実装工数として計算することはやめましょう。
業務時間内でいかに、タスクを遂行するかが重要だと思います。時間外を工数に当ててしまうのが当たり前になると役職が上がった際も、部下に長時間労働を強いてしまう負の文化ができてしまいます。
7.客観的に自分の位置付けができない
例えば、自分の実力を適当に判断できない方です。実力差を認めてその人たちと自分とでは具体的に何が足りないのかを判断できず、成長の機会を逃してしまいます。あくまでその時点での判断です。プログラミングの世界では年下でも自分よりスキルを持っていることはありますし、リスペクトする気持ちを忘れないように私も心がけています。
8.仕組み化して効率化を図らない
繰り返し業務の効率化のためのドキュメントの作成やワークフローによる自動化です。例えば新規で参加したエンジニアから毎回同じ質問がくるというような場合ドキュメント作成、またドキュメントを探す手間を省くためにそのドキュメントの所在を統一しておくなどがあげられます。
9.反論=ケンカだと思っている人
物事を深掘りして改善ができなくなってしまいます。日々の業務で問題は必ず起きます。その際はメンバーと意見を交換しあい改善できるようにしなければなりません。
事業アイデアの壁打ちのように、話し合っていくうちに無駄な要素が削ぎ落とされて研磨されたアイデアができる要領です。
まとめ
ここに書いたものは意識すれば全て改善できるものだと思います。僕は気づくまでに時間がかかってしまいましたが、これからエンジニアとして社会人として活躍されていく皆さんの助けになればと思います。
私自身も肝に銘じてこれから頑張ります。
以上です！読んでいただきありがとうございました！
エンジニアの副業やフリーランス、スキルアップについての情報発信してるのでフォローしていただけると励みになります！
@twinsdevelopper