目標、そして現在

将来はやっぱりテックリードとか、技術力を駆使して世に価値を届けていくキャリアを選択したい。
そのために、ソフトウェアの品質について考え続ける今の期間は、無駄ではない。

ソフトウェア品質を考える

「品質が良い」とは？をかれこれ9ヶ月考えている。
思うことがたくさんある。
エンジニアなので、

• 綺麗なコード

• 仕様が伝わるテストコード

• SOLID原則に則っている

• 循環的複雑度が低い

など、コードの品質にまずは目がいく。

チームの施策にも、「テストコードの実装」が常にある。品質改善に取り組むとした対象のチームのテストコードが皆無だったからだ。他にも、テストコードが書けない人がいたら教育したり、テストコードのレビューを常に行なっている。

でも、品質を良くするために必要な行動は、それだけじゃないのはわかっている。僕のドSな上司は、

「で、品質良くなったん？」

と、問いかけてくる。その度に思う。良くなっていない、と。バグの報告は減らない。

だから、今度はバグ報告を振り返る施策を実施した。

と同時に、バグをトラッキングする仕組みを作った。エンジニアから離れていく感じがした焦りから、少しでも技術に触れていなければいけないと感じ。
そしたら、最初にやるべきことは可視化だ、と思った。見える。そしてなんとなく伝わる。
少なくとも、品質が良くない、という状態はこうだ！と言える。

JIRAを可視化する、と意気込んでからは、たくさんのツールがあることに気づいた。
JIRAのダッシュボード機能、GSSとJIRAを連携するアドオン、 JQLを実行できるGitHub Actions。
エンジニアとしての幅はほんの少し広がった。

それでもバグ報告を振り返る施策は、何かテンションが上がらない。
こっちはもうトラッキングする仕組みがある。

お客様にとって、品質が良い、を考えることは、少し毛色が違った。いわゆる外部品質。
今までコード品質ばかり考えていたが、それは内部品質の一種。
外部品質だけが良くても品質が良いとは言えないし、内部品質だけが良くても品質が良いとは言えない。
両方良くしていく必要があり、それぞれどうしたら良い、と言えるのかを考える必要がある。

品質に関する気づきを得た

品質が良い、を考えていく上で大事なことは三つ。

• 品質が良い、の定義をあらゆる視点で考える

• 品質は分けて考える

• 品質は定量データで考える

こうなったら品質良いよね、という認識を揃えないと、良くなった、ということはできないと思う。だから定義付けが大事。

闇雲に「品質良くするには、、、、」を考えていた時は、沼にハマっていた。品質を分けて考えることで、自分の思考を整理することができる。

最後の「定量データで考える」は、良くなった、というための根拠みたいなもの。計測が目的にならないよう注意はしなければいけないが、それでも適切なデータを取得することは、マストだと思う。

正直真新しいことなど何もないし、すでに品質のことを考えてきている人にとっては、なんだこの気付きはってなるかもしれない。けど自分にとっては大事な気づき。

それともう一つ思ったことがある。

結局、品質が良いとは、を定義して、どの指標を追っていくかを設計して、実装する、というプロセスは、エンジニアリング以外の何者でもない。
向き合ってきたことは無駄ではない。

自信を取り戻しつつある

エンジニアとしてやっていけなくなるんじゃないか、という不安に駆られて、棚卸してみたけど、自信につながって良かった、という話。
何でも屋になるんじゃないか、という恐れがあったけど、以下の記事を見て、案外テックリードは何でも屋なのかも、とも思った。

でもアプリケーションを作る楽しさとか、感覚はなくならないので、こっちはこっちで日々時間を作って少しずつ進めていく。