凡人が品質のために気をつけるべき事
ご無沙汰しております。
仕事とイベントが忙しい時期が重なって放置しておりました。
その間にいろいろと気づきがありましたので、ブログにまとめてみたいと思います。
何が起こったか
自分の作ったコードとテストの品質低下です。
結合テストで単体レベルでの障害が見つかりました。
しかも、私は他の案件や別のシステム担当に向けた引き継ぎなどがあり案件を外れているため、後始末は私ではなく別の人がやっています。
この状況だけでもかなり恥ずべき事です。
しかも、初めてじゃないのでより恥ずかしいです。
前提
- スケジュール＜ボリューム
- スケジュールは押し気味
- 初めてのフレームワーク
- PGは多少ブランク
- 設計者と実装は別の人(実装は私)
- 設計の落とし込みは少し足りていない
そもそも、私はスーパープログラマでもないですし人並みはずれて生産性が高いわけでもありません。つまりは凡人です。
皆さんにも経験があるかと思いますが、上記のような前提でスケジュールに間に合わせることを最優先に作業をすると、品質が犠牲になってしまいます。
特に私の場合、スケジュールに追われると途端に生産性や品質に影響がでる悪癖があります。皆さん、スケジュールに追われる中で生産性や品質をどう保っているのでしょうか？
そういう意味ではこの結果は必然といえば必然なのですが、それではお仕事になりません。
で、今になって事前にやっておけば良かったと思うことがいくつかあります。
以下ではそのことについて触れていきたいと思います。
設計者から実装者への仕様の説明
設計の落とし込みが足りないので、設計書には曖昧なところが残っています。
それに加えて設計者と実装者が違うため、設計書を渡して「はい、よろしく」では曖昧な部分に関する認識がないまま実装に取りかかってしまうことになります。内容とお互いよって立つべきところに対する共有は、その後の作業効率に大きな影響を与えます。
実装作業を依頼する前に顔を突合せて仕様を一通り説明することで、落とし込めていない部分と設計のあるべき姿を共有すべきだと思います。
ソースレビューは設計書を確認しながら
本来なら当然ですが、今回はやれていなかったです。
ソースの品質ももちろんですが、仕様を満たしていないのは問題外なのです。
仕様はどうあるべきか、それを満たすための良い実装はどういうものか、という観点でソースレビューは行われるべきです。
作業割り振りの変更打診
今回の場合、品質の低下はスケジュールとボリュームのバランスがあっていないというのが一番大きな原因です。そもそも見積りやスケジューリングの段階で甘かったというのもあります。
そのような中で品質の低下を避けるために有効な方法は「落ち着いて取り組む時間を確保する」事だと思います。
例えば単体テスト項目の作成を他の人に割り当てなおして、品質や生産性を下げないための時間を確保するようにヒューマンリソースのやりくりを依頼するなどです。
PMによっては「ガンバレ」と言われるだけの可能性もありますが。
仕様確認の履歴をちゃんと残す
スケジュールが厳しくなる→仕様不明点が見つかる→急いで口頭で確認→実装→履歴なしという流れになってしまったため、仕様確認の履歴がほとんどのこせていませんでした。
絵に描いたような後手の対応ですね。基本的な部分のコミュニケーションの質があまり高くなかったように思います。
PGとテスト項目の技量をもっと上げる
短いプロジェクト期間ではまず結果を残すことはできませんが、恒久的に取り組んでいくのは必須です。
スケジュール的に厳しい状況の中で、生産性や品質の低下をどれだけ防げるか。常に取り組んでいかなければならないことですね。
これだけやってもできなければ
もう正直に、「無理です、ごめんなさい」して、スケジュール調整してもらうしかないですね。
