最近髪型を変えました。スマートキャンプの今川(@ug23_)です。
4月です。新卒の時期ですね。やがて令和の新卒と呼ばれる時期がくるでしょう。
自然と自分が新卒の頃に想いを馳せてしまいますね。
新卒の頃って雑用みたいな結構技術的には軽いタスクを振られて俺ももっと技術的に難しい開発アイテムやりたい!!!とか、面白くない、もっとコード書きたいという想いを持つ人もいるかもしれません。
でも、楽しい開発ばかりではないんですね。例えば サービス名変えるからこっからここまで直しといて! 的な、文言変更のような見方によっては雑用かもしれないと思うようなタスクをやることになったりします。
※ 会社によっては、エンジニアに依頼しなくても直したい人が自分でプルリクエストを送って反映できるというところもあるようですね。すごい。
でも「文字列変えるだけじゃん??」と思うかもしれませんが、文言修正はエンジニアとして仕事を進めていく上での大切なことを学ぶチャンスにもとれます。技術的な困難抜きに、仕事の進め方、チームメンバーとしての動き方を学べます。
この記事では「技術的には易しい」が「いろんな人と協力する」必要のあるタスクをやるときに覚えておくとスムーズなことを新卒の自分に聞かせたい気持ちでまとめました。
例として前述の文言修正を挙げます。
前提としてWeb系企業での開発をイメージしており、「エンジニア」は主にWeb系ITエンジニアのことを指しています。
なぜやるのかを聞こう
軽い修正ならまだしも「こことこことここと…ここまで直してね!」と言われると気が滅入りますね。
- 「その規則性だったらここも直すんじゃないのかな…?指示漏れじゃないのかな?
- 「でも敢えて指摘されなかったんだし直さなくていいか」と思ってそのままにしておくと「指示漏れてたからここも直して!」とあとでやり直す
- 何度も修正を追加されて疲れてきたところで大事なところをミスる
みたいな事になりそうです。どうせなら一発で終わらせたいですよね。二度手間は辛いです。
このタスクが発生した理由をちゃんと聞く ことをしましょう。 想像や推測ではなく、相手から聞いた理由なら確実です。
- それだったらこうしたほうが楽だ、と気付ける
- ここの修正するのは難しいからこうしたい、と議論できる
- それが理由なら支持されていないけどここも直しておいたほうがいい/直さなくていいなどの判断ができる
というメリットがあります。 迷ったときはやってしまって、ダメだったらあとでごめんなさいしてもとに戻すのも手です。「許可より謝罪を」です。3Mの社訓らしいです。うっかりやってみたら「ここも直してくれたんだ!ありがとう!」となるかも。
言われた指示を聞くだけでなく、その背景まで聞くと先回りして質問したり、リテイクも減ったりするんじゃないかと思います。
エンジニアなら迷ったときは安全側に倒して、お願いした人を捕まえて聞き出しましょう。わからなかったら捕まえた人を連れてさらに上の人に聞きにいきましょう。
文言変更する理由を聞いてそれでも納得できないときには「エンジニアも変数名で議論するしそれと同じことだ」と思うことにしましょう。
関係者に早めに話そう
たとえば、文言修正なら、こんなひとたちが絡んでくるでしょう。
- エンジニア
- 依頼者
- デザイナー
- 役員陣・事業責任者(場合による)
これら全員が一斉に同時に関わることはまれだとは思いますが、考えるだけでもこれだけいます。
依頼者とは何度かすり合わせをすると思います。デザイナーさんにはロゴやクリエイティブ等素材の修正依頼をするかもしれません。
文言修正が利用規約やプライバシーポリシーまで範囲を含んだり、文言変更が外部に影響する場合はバックオフィス・経営陣に伺いを立てる必要もあるかもしれません。
前の項でも似たような話でしたが、コミュニケーションの回数が多くなったり手戻りになったりすると時間もかかるしめんどくさい度が上がります。めんどくさいのはつらい。
そして作業依頼・レビュー依頼という形になってくると相手側のボールになってしまうので、忘れられたり、遅れたり…。
「こないだのあれいつできます?」というやりとり、やる方もやられる方もつらいですね。
つらい上に我々の完了が遅れていきます。出荷されない製品は価値を生まないのではやく世に出したい。
さっさと終わらせたいという立場に立つなら、早め早めに
- こういう作業をお願いすることになりそうです。余裕ありますか?
- このように修正しようと思っているけど問題ないかすり合わせしたいです
- なんてことを後々聞くことになるから時間をとると思います。たぶん。
というお願いを先回りして言っておきましょう。言っておくだけでもマシだと思います。
相手のためにも自分のためにも先に先に動いておきましょう。
どこが変わったのかお知らせしよう
道路の工事してる人が頻繁に写真を撮っているところをみたことがありませんか?
作業の前後でどうなったか、エビデンスが必要なんですね。
ITの世界の工事をする我々の作業にもエビデンスが必要です。
どこがどう変わったかがわかるように伝えておきましょう。
共有会等があり口頭で伝えられる場合でも変更箇所を伝えられるようにまとめておきましょう。
Gitの変更履歴だけだとエンジニアですらわからないし、他の人に伝えるなら見た目でわかりやすくしたいです。
スクリーンショットだけとってもいいですが、わかりやすくマークアップしていると変更点を伝えやすいです。
自分はSkitchを使うことが多いです。
デザインツールやPowerPointなどを使ってBefore/Afterを載せるのもいいですね。
Excelにエビデンスを貼り付けていく まで必要ではないと思っていますが、わかりやすくする工夫はしたいです。
ついでにきれいにしちゃおう
文言変更とか、1年に1回しかいじらない部分の変更、とか直すのは簡単だけど変更が怖いとか「この作り、突貫工事で作ったんだろうな」というような雑さだったりして気が滅入ったりするかもしれません。
頻繁に変更されるところだと周りの人も「絶対直したほうがいい」などと、我慢できなくなった人が手をつけますが、たまにしか使われないところだと手付かずだったり。
ボーイスカウトルール というのがあります。
原義は「キャンプ場を離れる時は、来たときよりも綺麗にする」ということを指しますが、そこから転じてプログラマの世界では「チェックアウトしたときよりもコードをきれいにしよう」という意味になっています。ボブおじさんのことばが有名です。
時間が許すなら、汚いと感じた部分を直すことをやってもいいと思います。汚い部分をリファクタリングするのはコードについて深く知れるチャンスなのでおトクです。
もちろん、必要のないリファクタリングをやってバグを仕込んだり、締切に間に合わないとせっかくのチャンスが無駄になってしまうのでバランスをとってください。諦めも大事です。
まとめ
伝えたいことをまとめるとこんな感じです。
- 自分でコントロールできない部分は早め早めに動きましょう
- 待ってても進まないので先んじて動いたり連絡したりしましょう
- やったことを伝えられるようにしておきましょう
- 余裕があったらきれいにしておきましょう
「サーバのコードをもっとゴリゴリ書きてえ」とか「画面のUIをもっといい感じに良い設計で書きたいんだ」とか、想いはあるかもしれませんがサービス運用してくるとどうしてもこうしたタスクは発生しがちです。
でも、こうしたタスクをうまく回せると周りからの「あいつめっちゃ仕事できる」感はどんどん増していくと思います。3年前の自分に教えてあげたい…。
新卒のみなさんも、とっくに新入の時期を超えたみなさんも参考になったら嬉しいです。
また、弊社でインターンをしていた学生が、Webエンジニアとして成長した話を書いてくれているので合わせて読んでいただくと、今後のエンジニアライフをイメージする手助けになるかと思います! ぜひ読んでみてください! tech.smartcamp.co.jp