POTTIRI'S AUTOBIOGRAPHY

工作やダイエットやITで遊ぶアラフォーエンジニアの自伝ブログです。

【品質管理】ギリギリまで作りこまれたら直せとは言えない

f:id:pottiri:20200915184008j:plain

フシギダネとゼニガメのコードレビュー

 

 

お疲れさまです。POTTIRIです。
皆様の会社では品質管理はされてますか?
ITの世界では出来上がったプログラムをチェックするコードレビューという文化がありますが、恥ずかしながらこの文化が私の周りではうまく行っていないというお話です。

作り直せとは言えなかった駄目リーダー

大分前に大変恐ろしいバグを経験したお話をしました。

pottiri.tech

こういうとんでもないバグは、
当人の問題もありますが周りの教育や環境による問題が大きいです。

このバグを出したプログラムがメンバーから提出された時、
短時間ではありますが私もチェックしています。
その時出されたものがこんな感じだったため、私は頭を抱えました。

  1. 期限ギリギリに提出された。
  2. 技術力不足により非常に読みづらいプログラム
  3. 必死に作ったことが読み取れて直せとは言いづらい

正直なところゼロから作り直した方がいいと感じたのですが、
葛藤の末直せそうなところだけ直させて出したという経緯があります。

直した場合、その部分を再度試験せねばなりません。
多少直すぐらいならやり直しも許容できますが、
根本的に直せとは言える雰囲気ではありませんでした。
また、「非常に読みづらい」というのが私の主観でしかなく、
読みづらくても整合性が取れていればアリなのでは?と頭をよぎったのも作り直しを指示できなかった理由です。

振り返ってみるとチェック合否の判断基準が曖昧なため、
その時の耳障りのいい方に寄ってしまった感じですね。

結果的には直感が正しかったようで、
責任者として間違っていたなと思います。
期限を守ろうとするあまりより大きな損害を出してしまい大変反省しています。

早めに出すのが大事

今となって思うのは、
こういった事態を防ぐには早めに提出してもらい、
早めにチェックするのが大事だと言うことです。
当たり前ですね。
ただし、これには双方にスキルが必要です。

提出する側は、早めに全体像を見えるところまで持って行くスキルが必要です。
プログラムならば細かいところはさておき、プログラム構造が見えた時点で出すとか、
見積ならば見積項目を洗いだした時点で提出するとかですね。
完成させてからでは遅すぎるし、チェックする側も遠慮してしまいます。

最初は難しいと思います。
そもそもスキルがない人は段階を踏むということができません。
完成形でないと全体像が把握できないという人もいます。
段階が踏めないならメチャメチャ未完成でも思い切って提出する勇気も必要ですね。

チェックする側は当然未完成状態でも完成形を想像するスキルが必要です。
できてなくても定期的に無理やりチェックするルールにするとよさそうです。
また、出されたものを見て軌道修正し、時には前に進められるところまで土台作りを手伝ってあげる必要があります。

私の場合は土台作りを手伝ってあげることができなかったのと、
炎上していて当人が未完成状態でも見てもらおうという勇気が出せなかったのが敗因でした。

チェック体制を整えるのは大変

早めにチェックしろとは言いますが、
これって結構大変なことです。
頻繁にチェックするのも面倒だし、土台作りを手伝うのも大変です。
余裕のない現場だととても回せないでしょう。
今までできていたとしても、一度余裕がなくなると体制を立て直すのも大変です。
私の時もやりたくてもできなかったというのが現実です。

今にして思えば全てをチーム内で完結させようとしたのは間違いだった気がします。
外部の人間にもわかりやすくしないといけないという名目で、
チェックを別の部署の人にお願いするとかして悪いスパイラルを抜けるのも一つの手だったのかもしれません。

未完成でもいいから見せる!とか、誰を利用してもいい!とか
ある程度柔軟な考えを持つのが品質を維持する秘訣な気がします。
 

 

最後まで読んでいただきありがとうございました。

 アフィリエイト