最近考えていることを徒然なるままに
目標、そして現在
将来はやっぱりテックリードとか、技術力を駆使して世に価値を届けていくキャリアを選択したい。
そのために、ソフトウェアの品質について考え続ける今の期間は、無駄ではない。
ソフトウェア品質を考える
「品質が良い」とは？をかれこれ9ヶ月考えている。
思うことがたくさんある。
エンジニアなので、
綺麗なコード
仕様が伝わるテストコード
SOLID原則に則っている
循環的複雑度が低い
など、コードの品質にまずは目がいく。
チームの施策にも、「テストコードの実装」が常にある。品質改善に取り組むとした対象のチームのテストコードが皆無だったからだ。他にも、テストコードが書けない人がいたら教育したり、テストコードのレビューを常に行なっている。
でも、品質を良くするために必要な行動は、それだけじゃないのはわかっている。僕のドSな上司は、
「で、品質良くなったん？」
と、問いかけてくる。その度に思う。良くなっていない、と。バグの報告は減らない。
だから、今度はバグ報告を振り返る施策を実施した。
と同時に、バグをトラッキングする仕組みを作った。エンジニアから離れていく感じがした焦りから、少しでも技術に触れていなければいけないと感じ。
そしたら、最初にやるべきことは可視化だ、と思った。見える。そしてなんとなく伝わる。
少なくとも、品質が良くない、という状態はこうだ！と言える。
JIRAを可視化する、と意気込んでからは、たくさんのツールがあることに気づいた。
JIRAのダッシュボード機能、GSSとJIRAを連携するアドオン、 JQLを実行できるGitHub Actions。
エンジニアとしての幅はほんの少し広がった。
それでもバグ報告を振り返る施策は、何かテンションが上がらない。
こっちはもうトラッキングする仕組みがある。
お客様にとって、品質が良い、を考えることは、少し毛色が違った。いわゆる外部品質。
今までコード品質ばかり考えていたが、それは内部品質の一種。
外部品質だけが良くても品質が良いとは言えないし、内部品質だけが良くても品質が良いとは言えない。
両方良くしていく必要があり、それぞれどうしたら良い、と言えるのかを考える必要がある。
品質に関する気づきを得た
品質が良い、を考えていく上で大事なことは三つ。
品質が良い、の定義をあらゆる視点で考える
品質は分けて考える
品質は定量データで考える
こうなったら品質良いよね、という認識を揃えないと、良くなった、ということはできないと思う。だから定義付けが大事。
闇雲に「品質良くするには、、、、」を考えていた時は、沼にハマっていた。品質を分けて考えることで、自分の思考を整理することができる。
最後の「定量データで考える」は、良くなった、というための根拠みたいなもの。計測が目的にならないよう注意はしなければいけないが、それでも適切なデータを取得することは、マストだと思う。
正直真新しいことなど何もないし、すでに品質のことを考えてきている人にとっては、なんだこの気付きはってなるかもしれない。けど自分にとっては大事な気づき。
それともう一つ思ったことがある。
結局、品質が良いとは、を定義して、どの指標を追っていくかを設計して、実装する、というプロセスは、エンジニアリング以外の何者でもない。
向き合ってきたことは無駄ではない。
自信を取り戻しつつある
エンジニアとしてやっていけなくなるんじゃないか、という不安に駆られて、棚卸してみたけど、自信につながって良かった、という話。
何でも屋になるんじゃないか、という恐れがあったけど、以下の記事を見て、案外テックリードは何でも屋なのかも、とも思った。
でもアプリケーションを作る楽しさとか、感覚はなくならないので、こっちはこっちで日々時間を作って少しずつ進めていく。
いいなと思ったら応援しよう！
