webエンジニアのお仕事【コード書くだけじゃないのよ】

webエンジニアのお仕事【コード書くだけじゃないのよ】

こんにちは、エンジニア大家です。

webエンジニアとアパートの大家をしています。

以前、イベントで知り合った大学生の方とお話していた際にこんな事を話されていました。

大学生

webエンジニアに興味あります!
営業とか事務作業とかやりたくないので、ソースコード書いてPCと向き合うだけの仕事がしたいと思ってます。

「PCと向き合うだけ」というのはある意味正しいです。

ですが、ソースコード書くだけが仕事じゃないのですよね^^;

というわけで今回はwebエンジニアの仕事を紹介したいと思います。

私の経験談なのでこれ以外にもあるようでしたらコメント下さい。

webエンジニアのお仕事

私は長いこと「実装もする人間」だったので、実装者の立場で以下記載したいと思います。

調査

自分が上流の要件定義をやるにせよ、実装者であるにせよ、必ず調査して裏付けをします。

観点としては今回担当するタスクそのものの要件定義が正しいのかをみるのはもちろんのことですが、

メインは現行仕様と照らし合わせた上での今回開発するタスクの仕様がそのまま使えるのか、データの保持が既存の仕組みと適合するのかを調査します。

なので、現行仕様の把握が大事です。現場に入ったばかりの頃は現行の把握だけで工数かかってしまいますので、詳しい人にある程度方針を決めて貰った方が良い(ていうかそれしかない^^;)です。

それがかなわない場合はしかたなく調査するしかありませんが、時間の制限もあるのである程度のところで調査を打ち切って見切り発車し、問題があれば相談して適宜修正するのが現状です。

調査の加減

上司によりますが、

上司

さっさと実装しやがれ

系と、

上司

ちゃんと調べてから実装しやがれ

系の人がいます。

前者は「実装しないと細かいところまでわからねーからやっちまえ」と言い、

後者は「よく調べずに実装に入った後で誤りに気がついたら時間の無駄だから最初にしっかり調べろ」と言います。

私はどっちも正しいと思います。

ある程度調べてそれ以上時間かけても成果なさそうな場合は着手してしまい、何か問題があれば適宜修正する」というのが効率が良いと私は思います。

それで私がときどきイラッと来るのは、

上司

調査に時間かけすぎ

とか

上司

調査不足だから実装やりなおすハメになってんだよ!

と文句言ってくる上役がいることです。

おそらく「自分だったらもっと早くできる」(実際にやってみたら時間かかると思い知るハズなんですが、、)とか、

とにかくストレス解消したい」(他人を口撃して自分が「悦」な気分に浸りたい)とかそういう想いで発言しているだけです。

なので、会社員の方は心の中で

(うるせえ!)

会社員

って言い返してください。

フリーランスの方は口に出して

うるせえ!

フリーランス

って言い返して他の現場に移ってくださいw。

意外に謎!?webエンジニアのフリーランスの求人情報はどうやって得るの?

ドキュメント作成

現場にもよりますが、実装者もドキュメントを求められます。

最初は「ソースコードだけでOK!」な現場でも、

サービスが成長していくに連れプロマネを外部から雇われて、

その人がドキュメント派だった場合はドキュメントを書くことになりそうです。

処理概要

画面仕様書に書くパターンもありますが、個人的には別物だと思っています。

読んで字のごとく、処理の概要を記載します。

  • 取得元DBのテーブル名や抽出条件
  • 取得したデータをどう使うか(処理内容)
  • 最終的なアウトプット(画面表示、DB登録・更新、メール送信など)

エンジニアと非エンジニアとの架け橋的な内容なので、言い回しはわかりやすくする必要があります。

仕様書(画面・API・バッチ等)

実装者が残す仕様書としては主に画面・API・バッチの3つです。

画面仕様書は他の職種の人が作成したものを引き継ぐパターンもあります。そして、一番メンドクサイのが画面仕様書です。画面をキャプチャした画像の上に番号や赤枠を入れたりする必要があるからです。

API・バッチ仕様書は画面仕様書と比べるとビジュアル(画像の挿入や番号のレイアウトなど)がないので書きやすいです。

起動方法(コマンドやリクエストURL)と処理内容と処理結果とエラーの種類を記載すればOKです。

現場で既にあるフォーマットがあればそれを踏襲すれば良いので楽にできると思います。

プロジェクト管理ツール(バックログとか)の対応

時が経つに連れだんだんと詳細を書かされるようになります。

特にバグ対応だと事象、再現手法、原因、対応内容、対象したgitブランチ名、テスト仕様書、テスト内容、リリース時期、先の全ての対応のレビュー(プロマネのチェック)などなど。

特に嫌なのはテスト仕様書にテスト内容が書いてあるのだけれど、プロジェクト管理ツール側にもテスト内容を書けと言われることがありました。

内容の重複ってソースコードだと悪しき行為なはずなのに、、、。

しかも「非エンジニアにもわかりやすく」と。。。

これには結構な時間を取られてしまいます。

あと記載した内容に対してプロマネが気に入らなければ修正・加筆を求められてしまいます。

この点で問題に思うのは、「タスクとしては完了して次のタスクを着手しているのに過去のタスクのチケット対応に時間を削がれてしまう」ことです。

あまり酷い場合は、「タスク完了後に修正を求められたチケット対応の時間」も記録して平均値を出してプロマネに「考慮しろ」と伝えてください。

私の場合

私はテスト仕様書の内容(非エンジニアにはわかりにくい文体)をチケットにコピペし「わからなければ聞いてください」と記載してましたw

大体は聞いてこないことが多かったですが、たぶん私に対するこの対応の評価は低かったと思います。

みなさんは手間でも是非しっかりと対応してください。

ソースレビュー

現場に2年も在籍すればソースレビューを行う側になります。(昇給はしませんでしたが。。

そして、私も実装者なのですが、ソースレビューをする時間は考慮されてませんでしたので、

ソースレビューを真面目にやればやるほど自分の実装時間は減っていきました。。

適当にソースレビューをすると後から問題が発覚し、私が対応せざるを得ない状況もありました。

なので、ソースレビューは手を抜かないほうが良かったと今は思います。

MEMO

ソースレビューは結構気を使うんですよね。

というのも、自分はその会社の社員ではないので立場は弱く、

社員の方のソースレビューだと理詰めでやっても最終的に力関係で負けたりすることがあります。

日報・月報

客先常駐だと月末に必ず提出すると思います。

本来の目的は「ギャラの請求をするためのモノ」なのですが、

現場によっては一日ごとに、

「対応したチケット番号」

「それぞれに使った時間」

「そのチケットはその月にリリースした・しなかった・ポシャった」

まで書くよう言われたことがありました。

正直なところ意味あるのか懐疑的だったため、とても苦痛な作業でした。

月末にまとめて書く場合で30分程度使うことになり、月末の最終日は憂鬱でした。

まとめ

  • タスク着手前の調査
  • ドキュメント(処理概要、画面・API・バッチ仕様書)を書く
  • プロジェクト管理ツール(バックログとか)の対応
  • 日報・月報を書く
  • ソースレビューをする

ソースコードを書く以外にやる仕事はこんなところです。

他にも本番リリース時の対応や開発環境絡みの対応もありますが、この辺はまたの機会に記事にしたいと思います。

webエンジニアやってみてよかったか???キャリア12年の私が語ります

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です