00:05
こんにちは、ながおかのプログラミングチャンネルです。
今回は、エンジニアとして働いていくときに、仕事を振られたとき、こういったものを開発してほしいと頼まれたときに、その後どういうふうに進めていくか、どういうふうに進められたらより成長できるのか、そして信頼してもらえるようなエンジニアになれるのかという話をしていきたいと思います。
よく仕事を開発現場で使われる方法として、チケットというものがあります。
チケットという、トゥードゥ管理、ジラだったり、あとレッドマインなどいろいろありますが、そのようなシステムでタスクが振られます。
振られたときに、まず最初に確認するものは、開発することがどれだけがっちり決まっているかということですね。
これは相手がどれくらいこれに関する時間が、仕事を振ってくれた方がどれくらいこれに時間を割けるかどうか、そもそも開発のステージなどにもよるのですが、
ノータンといいますか、どれくらいがっちり固まっているかというのは結構差があります。
例えばほとんど全てやることは決まっていて、1を1と決まっているデザインもがっちり、あとはもう完全にコードを書くだけという状況から、結構ふわっとした状況で投げられて、
だからそもそもこれは何のためかというところから確認する必要があるというので結構様々です。
これは結構自分で判断する必要があります。
だから要するに自分でわからない場合は必ず確認した方がいいです。
なのでここでこの機能の目的や背景だったり、完成イメージなどが少しでも不明な点があった場合は確認するというのが必要になります。
この確認するときに必ず重要なのが、ただオープンクエスチョンというか、これちょっと全然わからないんですけどどういうことですかと聞くのではなくて、
このチケットだったりこのタスクなんですが、自分なりに考えてみてこうこうこういう目的で、そのためにはこういうアウトプット、こういう完成イメージで開発していこうと思うんですがどうでしょうかというふうに聞くと、
そういうふうに聞くと相手もそうなんだよね、その通りであればうんそうだよで終わりますし、違った場合は違った場合でもそこから議論が始められるのでより効率的になるかと思います。
そこで次に目的であったり完成イメージがわかってきたときは、あとは次に実際に開発するステップ、細かい実装の方についてもさらに確認していくということになります。
03:00
これも例えばチームがどれくらい成熟しているか、チーム同士でエンジニア同士でどれだけお互いの例えば実装方法だったり実力だったりが理解しあえているかによるんですが、
もう長年一緒に働いていて通過アウンの呼吸であればもう細かい実装などはすべて任せるので、全部実装してあとプルリクエストをいきなりポンと投げてレビューしてもらった終わりというのもありますが、
例えばチームに入った最初のときは結構細かいタイミングで確認していったほうがいいと思います。
最後の最後まで実装して、はいお願いしますって言って、これちょっと大元のところから間違ってる、間違ってるというかチームの方針に合わないとかもっといい実装があるということになると、
それまでの作業が全部無駄になってしまうので、それは結構手戻りとしてもつらい、モチベーション的にもつらいですし、時間的にもつらくなってしまうので、
なのでそういったことを避けるべくかなり細かいタイミングで、だから理想的に言えば1日に半日に1回ぐらいのタイミングでできるといいのかなというふうに思います。
そこで最後に実際にプルリクエストだったり、マージリクエストと呼ばれたりもしますが、そういったものを出して、マージされれば完成となりまして、というふうに1つのサイクルが回っていくわけですね。
ここで会社の組織だったり特にスタートアップなどでは、そこまでがっちりとチケットで仕様を固められるということはほとんどありませんというのは、
そもそも会社自体だったりプロダクト自体がどんどんダイナミックに変化していく中で、開発を進めていかないといけないので、そういうときに求められる能力というのは自分なりに考えて、
たとえ別に間違っていてもいいですし、何が正解というフェーズでもないので、こういうふうに考えて、こういうふうにやってみようと思うんですがというコミュニケーションをどんどんしていく、
自分がどう考えているのかというのをどんどん発信して議論していくという姿勢が信頼されるのに必要かなと思います。
というわけで今回はこれぐらいで終わります。 レターやコメント、いいねもぜひお願いします。ありがとうございました。
