この記事は、前職(スタートアップのWebエンジニア職)で報連相しない問題とかがあって若手向けと称して社内LTをした内容を記事にしたものです。
誰かの参考になるかもしれないと思い記事にして公開しました。
いろんな問題に無理やり焦点を当ててるため、体験談っぽい感じになってますが、無理やり体験を当てているところもあります。
自身が職場の問題を解決できるような、業務向上や社内管理の向上などを行える役職者ではなかった為、自分ができる方法で若手やその周囲の方々、また管理者に何か働きかけを行う方法（考えるきっかけにならないかと）LTを行いました。
自己紹介
元下請けSIer(6-7年ほど) -> Webエンジニア(1年半ほど)です。
詳しい経歴はこちらの記事に書いてあります。
ちょっとひょんなことから製造工程を6年ほど担当していました。
実装担当の時に自分がしていること
一般的なやり方として私はこうしている、て話です。
個人のやり方です。
ミスは少ないと称されますが、速さとかの勝負はできないタイプの人間のやり方です
1. 理解するまで作らない
🔸 まず、実装の担当を振られたら...
- 何のアプリ
- 画面上のどの部分
- 何の機能を作るのか
(設計者かタスク振った人に) 必ず話聞きに行ってます。
コード上の実装でなくどういう機能かを聞きに行ってます。
基本的に実装だろうが、他の作業だろうがタスク振られたら口頭で必ず話聞きに行ってます。
WBSに名前書かれたら、設計書自分で探して、何も聞かず実装してとかはやったことないです。
多分他の人の、3-4倍いろんなことを設計担当者やPM等に質問したり、話をしていると思います。
🔸 SEは会社固有の業務をシステム化するから、クライアントの会社によって知識が違うけど、Webは一般的に「アクセス解析てどういう機能」、「マッチングてどういう機能」などの知識でいけるから、比較的自分はやりやすいです。
プログラミング知識より、「一般的にこの機能はどういう機能」て業務知識の方が実装する上で大事だと思います。
その上で、
- 「一般的な〇〇の機能」と思い浮かべる機能から、知らない処理をしていて要件定義にも書いてないことが設計書にある、とか
- 考慮が足りない、あってない気がするとか
- いろんな設計書の情報を統合すると不整合があるとか
は、自分で調べて、迷惑だろうが勘違いだろうが、納得するまで調べたり、設計担当者やPMに聞いたりしています。
🔸 設計書のミスはよくあるし、ほぼいつもだと思っています。
「ケアレスミスかな」的なのもあれば、「設計者の人すごい忙しいのかな、疲れてるのかな」的なミスのものもあります。
私も設計したことあるが、基本的に机上だからいくら完璧に作った、完璧にレビューまで終わったと思っていても結構間違ってることが多いです。
実装者が「動くものにします」て責任を持ってるので潰すしかないです。割と基本疑ってかかってます。
🔸 実装担当なら、設計書の疑問は言うけど、「○○て言葉追記してください」とか、「設計書こっちで直しました」とかやらないです。
誤字脱字くらいは直していいか聞くけど、基本、設計は設計者に任せてます。
🔸 別の話で、設計ミスは「設計でレビューもしたけど漏れた」ならいいけれど、「当たり前にあるから実装者が言って、指摘ありきでお願い」は、こっちも正直分からないし、割と困るので「設計レビューで拾ってもらいたい」旨はより偉い人に伝えたりして、役割に集中させてもらったりしています。
結局、設計担当と実装担当では持ってる情報の性質が違うと思っています。
設計担当者はお客さんと話すし、その上位工程の内容も知ってるから実装の人が設計について何かは言えないから、設計担当に判断してもらうしかないし、作業量を溢れさせないためにも担当が分かれてるならちゃんと分業した方がいいと私は思っています。
2.一番最初にすることは、設計の理解、自分の工数の見積もり
🔸 新人の頃から「作業振られたら、まず自分のかかる日数見積もれ！」と言われています。
見積もって足りなそう、期限を超えそうなら、（作業開始前の）その時点でリーダーに相談します。
自分の標準的な作業日数が分からないなら、作業時間を計ります（大まかにでOKです）。
今、無料のトラッカーとか色々あるし自分でメモする程度いいと思うので適当に測ってます。
定時退社での勤務時間が7.5hなら、大体、1日の作業時間を6.5hとか少し少なめにして、調査する時間とか、試行錯誤する時間もたくさん取った時間で見積もっています。
一個一個潰してどこで時間食ったとか出せれば、作業が増えても交渉できると思ってやっています。
遅れる かもしれない 。て時点から相談してしまっています。
間に合わないなら「間に合わない」と言えば、誰か他の人がタスクをやるかリスケされます。
リスケができないなら会社全体でデスマーチするしかないと思っています。
できないのにやって「品質ばろぼろです」だと、関わっちゃった手前、全部の修正が自分に来て持ち切れなくなるから、やらないようにしています。
エンジニアは仕事を抱え込んだ人間から潰れてくから、スキルアップはしたいけど抱え込まないようにはしています。
3. 自分で戦略を立てて作業をする
🔸 慣れない作業、やったことない作業は、確認多めでちょこちょこ見てもらったり、質問をしてます。
やれ、て言われてる手順だけでなく、自分で考えてどうするか方針立てて、好きに動いてます（勝手に確認とか人の作業増やしてます）。
🔸 ウォータフォールは上流工程でやらなかったこと、理解が甘くて放置した部分が下流工程で倍になって負荷になります。他の人の負担にもなるので、疑問や分からないことは早めに潰すようにしています。
🔸 「結構、思ったより面倒なやり方をしなくちゃいけない」だとか、「一から勉強しなきゃいけなくて、時間食いそう」なら、タスクを降った人にその旨雑談程度に軽く話して、「こう言うやり方するので、時間くいます」とか話してから努力しています。
タスクを振った人も私が何やってるのか何に困ってるのが聞かれなくても知ってもらうように話はしています。
「自分でどれだけ考えても作業の手順が立てられないので、一緒に内容見てもらってアドバイスいただいてもいいですか」とか完全にどうしたらいいのか分からないんです的な感じのことも結構言ってます。
4. 伝わる言葉を言う・書く
🔸 伝わらない言葉や文章は結局、混乱にしかならないです。
どうあっても戻りや確認作業が必要になります。
どう考えてもマイナスになったり意味をなさないなら、初めっから面倒だけど丁寧に伝わる文章を書いたり言うようにしています。ただの効率化です。
🔸 下記の内容を注意してます。
- やること、その理由、背景などを伝える
- 誤字脱字に気を付ける
- 主語、述語、目的語を省略しない
- オフショアの方が相手の場合、翻訳しても分かりそうな文を心がけてる
言わないことは、伝わるわけないと思っています。
5. 仕事としてコミュニケーションをする
🔸 複数人で作業してるので、俯瞰して考えてみて意思疎通や話の調整が必要ならしています。
エンジニアの仕事は、設計も実装も結局、成果物に現れない考慮事、検討事を沢山、調査したり行なっています。
勝手に判断するとバグになるから作った人に聞いたり、話をするようにしています。
🔸 単純にコミットが衝突すると処理の理屈が合わない結果になる場合もあります。
🔸 聞くことはその人の仕事や考えを尊重する的なことだと思ってるので、勝手に自分で人の担当のとこまで判断して、作業はしないようにしています。
🔸 報告、連絡、相談とか必要ならする程度の意識でいます。
結局、情報でしかないし、意思疎通でしかないと思っています。
個人の性格、個性とか置いといて、仕事に必要なコミュニケーションだけしています。
6. 面倒臭いけど、やる
🔸 自己レビューで、
- 命名規則とか
- コメントの誤字とか
確実に指摘されるものとか、多分指摘されるんだろうな、と言うのは面倒だけど直してレビューの依頼を出しています。
コードを少しでも修正したら、必ず動作確認して問題ないか、退行してないか確認しています。
設計担当の場合、設計書の書式とか絶対レビューで指摘されるから直しています。
すごい面倒です、でもやらないと、確実に戻りになってもっと面倒なのでやっています。
7. 見える化する、言語化（明確化）する、俯瞰する
🔸 知識の見える化、進捗の見える化、作業の見える化、問題の見える化をしています。
人にも分かるよう、「WBS」とか「クライアントとのFB経過内容のファイル」とか随時ちょこちょこ更新しています。
複数人で作業しているし、PMとか全体を見なきゃ正しい判断や方向性はわからないからちゃんと見える化はするように気をつけています。
🔸 作業で、自分のしてることをノートに言語化して、「今自分はまってんだ、これだけ試行錯誤して分からないから人に聞こう」とか「まだ全然自分でやっていないからこのくらいまでは自分でやろう」の目安にしています。
基本、連絡、相談、報告ができないのは、「頑張ってるのに、自分がどれだけ頑張っていて、今ここが問題でこう言う理由で止まってる」がきちんと整理（明確化、言語化）できてないから、自分で負い目に思って報告できないんだろうなと思ってます。
8. 合理性、疑問にこだわる
🔸 「こんな作業頼むわけない」、「こんな改修になるわけない」と思ったら疑問が解消されるまで調べたり聞きます。
解決できないのに、完成や次の工程にはしないです。
🔸 やりたいこととか意思疎通があってなければ、どれだけ急いだり頑張ったりしても、作業を振った人とか上司に普通に怒られると思います。
相手の「完成のイメージ」とか「何がしたいのか」とか「期限」とか、必ず聞いています。
9.分からないものは聞く
🔸 疑問があるのにレビューに進むとかにはしないです。
設計の考えとか自分でも調べるけど、所詮人の考えだから、分からないものはどれだけ考えたところで分からないです。
聞くしかないと思っています。
コミュニケーションなんて一方的なものでしかないから、互いの努力で言葉や伝え方を重ね意思疎通をするのが大事だと思っています。
🔸レビューで、「設計内容がわからない」や、「指摘内容もわからない」のにとりあえず作って、再レビュー出して、同じ指摘をもらって修正するのはやらないようにしています。
修正する前に話を聞いたり、「こう言う修正のイメージで合ってるか」聞いて進めてます。
🔸 担当のコード実装に関しては自分の仕事、自分の責任、と言う感じで「自分の担当の箇所は自分がやる」て気持ちは新人の頃から気をつけて持つようにしています。
10. 工程を省略しない
🔸 自己レビューとか他者レビューとか、単体テストとか省略すると当たり前にバグります。
商用稼働時にバグったりして、後で怒られたりすごい面倒になります。
工程がなくて、省略しろとのお触れが出てても自分でこっそりやっています。
🔸 ちなみにWebエンジニアで工程が少ない場合も、SEだとこのくらい工程があったりします。
個人の経験で多少過大な内容になっています
まとめ
- こんなこと話していいのかな
- あんまりタスク間に合わないと自分は足を引っ張ってないか
- もっとスキルアップしたい
いろんなことを思います。
でも、1人で仕事してるのではないし、組織で仕事しています。
時間は有限でプロジェクトも永遠とやることはできないし、自分も人生を仕事だけしてるやってるわけにはいきません。
仕事は溢れてしまったら人に任せるものは任せる、自分の作業量は調整してもらって管理する、
もしそれで、「スキルアップができてない」とか感じるなそれはそれで上司に相談してアドバイスもらっています。
いますぐとか、いつも役に立とうとするのでなく、長期的に役に立てばいいかと思っています。
「もっと面白い仕事したいんです」とか、「もっと難しい仕事したいです」とか現在の自分の仕事の不安や不満も結構相談しています。
手を煩わせることもあると思いますが、言わなければ自分がどう言う人間で何を目指しているのか、周りに伝わりません。何も解決しない可能性があっても言ってみるのも一つの手かもしれません。
多少、前職の職場にスコープを当ててたので、極端な話や極端な表現になっている箇所もあります。
ご不快に思われた箇所がありましたら、申し訳ありません。
個人の一例であって異なる仕事の仕方をされる方も多いと思います。
読んでいただいてありがとうございます。