背景
エンジニアとして仕事を何年かやってみて思った幾つかやらかした事を
初心に立ち返って書こうと思っています。
とはいえ最近記事を書いていないので半分リハビリみたいなつもりで書いているので、気楽に見てください。
いままでやって失敗した事
- 細かい仕様を決める時間がないからという理由で他の人に任せてしまっていたこと
- 質の悪いTESTを書かないこと
- コミュニケーションの取り方を煩雑にしていたこと
- レビューをちゃんとやること
以下それの説明を書いていきます。
細かい仕様を決める時間がないからという理由で他の人に任せてしまっていたこと
自分自身が複数の案件を跨いで作業を行なっていると、やはり集中力が散漫になってしまうのはどうしても避けられないと思っています。
なのでマルチタスクになってしまうと、以下の問題が発生してしまいます。
- 複数の案件を並列で進めようとするとどうしても案件同士の仕様が混ざってしまう。
- 余裕がないので、他人のアイディアをちゃんと聞いてし取捨選択できない。
- 会社がピリつくので会社の雰囲気が悪くなる。
- 残業が増える。
仕方ないところもあると思うのですが、どうしてもこれだけはやっとけというのは
- 別案件の事をやる場合リラックスする時間を作る
- 詳細設計フェーズは意地でも時間を作る
この2点はどんなに忙しくてもMustでやるべきでした。。。
まとめ
時間がないとしても自分がPLポジだった場合、意地でも時間を作って仕様を決めること
もし決められないのであれば後から後悔します。。。。
質の悪いTESTを書かないこと
サービスが肥大化していけば行くほど、TESTの重要度の比重は大きくなっていきます。
というのも影響範囲がでかい修正を行うとそれに紐付いている機能にも影響を与えてしまう可能性があるからです。
逆に小規模なサービスであればテストはそこまで必要ない。
とはいえテストの質が低いと意味をなさないので、品質のいいテスト書く必要があります。
(書かないとQAの負担が増えます😇)
テストの観点とかは話長くなりそうなので別のタイミングで話します。
まとめ
大きなプロジェクトになっていけばいくほどテストの価値が増大する。
テストを書くのであればある程度の品質を担保する必要がある。
コミュニケーションの取り方を煩雑にしていたこと
これは前職の話になるのですがMTGをやる時、ずっとオンラインMTGをカメラOFFでやっていました。
一番の原因は自分の能力不足だと思いますが、そのせいもあってか、かなりピリついたことがありました。
あの時一緒に仕事をしてくれた先輩方には頭が上がらないとはいえ、やはりピリついているとストレスで体調も悪くなるし、仕事の進み具合もよろしくなかったです。
また、エンジニアではない人と話すのもとても大変です。
案件にもよりますが、PM的ポジションの人がいない場合直接エンジニアがお客さんや営業と話すことがあったりします。
そうなると本当に地獄です。
ITの話を噛み砕いて一般化して伝える必要があるので、それができない場合は要件が噛み合わなくてコミュニケーションが増えてしまいます。
おそらく周りに怒号を飛ばすつよつよエンジニアが一人いるより、能力がそこまで高くなくても、みんなで仲良く仕事を勧められる様な環境をつくれるエンジニアの方が費用対効果は高いのかなと思います。
非同期でコミュニケーションをするための文章を書くテクニックとかもありますが、それは一旦後回し。
まとめ
コミュニケーションをとるのはチームとしても、お客さんとの認識の齟齬を無くすためにもとても大事。
怒号を飛ばすつよつよエンジニア一人より、能力がそこまで高くなくても、ラポール形成できるエンジニアの方がいる方が費用対効果は高い。
レビューをちゃんとやること
コードのレビューはコードの品質を保つために必須ですが、一方でどこまでやるべきかとても難しい。
時間をかければ間違いなくクオリティは上がりますが、どこまで時間かけるべきなのか？？？
とはいえ絶対にやる必要はあると思っています。
持論ですがレビューはこの観点でやると品質を担保できると思います。
- レビュワーに対して自身が書いたコードを説明できるか？
- レビュワーの観点で明らかにこのコードは冗長な処理をしてしまっているか？
自分のなかではまだ完全には煮詰っていませんが現状はこちらの観点でレビューするのがいいと思っています。
まとめ
レビューを行う際エンジニアにソースコードの意図を説明させるようにする。
自信に知見がある場合は、このコードは冗長な処理をしているのかを判断してレビューする
総評
コードを書くことはそれなりにできるようになってきたが、もう少し仕事のやり方などは改善の余地があると思っています。
引き続き自己研鑽に励み、より良い仕事をしていこうと思います。