NZ MoyaSystem

ニュージーランド在住のプログラマがあれこれ書くブログ

自分の失敗を完璧にフォローされて涙が出るレベルな件

おすすめ記事▼

いま勤めている会社ではアジャイル開発を取り入れており、2週間を1スプリントとして管理しています。

各スプリントの終わりにはチーム内での実績報告とレビューを行います。今日はそのレビューでの話。

超絶無能だった自分

そのスプリントでの自分のパフォーマンスは最悪でした。

とある一見単純なバグ修正を、鼻歌交じりで「ふふ〜ん」とコミットしたら、

「残念! こっちの機能が壊れてます。やり直し :)」

とリーダーからあっさりコードレビューで却下される始末。コードレビュー前に当然走らせておくべきユニットテストの結果確認を怠っていたので何も言い訳できませんごめんなさい……。

で、またコーディングのやり直しとなるわけですが、やればやるほどユニットテストが壊れていくんですよ……。

あちらを立てればこちらが立たず地獄。もともと様々な条件にうまーく対応するように書かれているデリケートな処理なので、ヘタにいじれない部分だったんです。

仕方なく隣の席のメンバーに助けを仰ぎ、既存のスパゲッティ化していたコードを維持するのではなく、これを機会にごっそりと処理を書き換え、単純化するように方向修正。

それでもリーダーが納得するレベルのコードがなかなか書けなかったり、ユニットテストを大量に増強する必要があったり、別のバグが見つかってそれを直すのに時間を取られたりと、想像以上に工数がかさんでいく。

結局、たったひとつのバグを直すのに2週間もかかってしまいました。泣きたい……。

フォローが完璧すぎて感動

レビューでは当然この件を報告しました。

「このスプリントでは主に○○のバグ修正を行ってました。最初は簡単に思えたんですけど、予想以上に時間がかかってしまって……。結局、2週間費やすことになっりました」

そこで、うちのリーダーが一言。

「はっしー、もう一度この仕事をやり直せるとしたら、どこに気をつけるべきだと思う?

「そうですね……。今回は、もともと複雑だった処理にあらたな条件を付け足したことで不具合を埋め込んでしまいました。次はなるべく処理を単純化することを考えるべきだと思います

「それも大事なことね。あとはバグ修正の前に必ずテストコードを書くこと。ゴールを決めて、それに向かって処理を修正していくのが大切だから」

するとほかのメンバーが、

はっしーは今回の仕事を通じてモジュールの処理内容に詳しくなったし、ユニットテストも随分増やしてくれたから、その実績は今後すごくみんなの役に立つよ。Nice work!」

とフォローを入れてくれました。

……この流れすごすぎないです?

まずは失敗経験のサマリー。

そして反省点を本人に考えさせる。

最後は失敗の中から得た内容を第三者から評価。

失敗した本人を自己嫌悪に陥らせるんじゃなくて、失敗経験そのものをチームの財産として共有する。

なんだこれ完璧か。ちょっと感動で涙が出てくるレベルなんですけど……。

失敗を誰かの責任にしても得るものは少ない

何か仕事でミスが出たときにありがちなのが、責任者に原因と対策を考えさせるってパターンですよね。

でも、それってあまり得るものが無いと思うんです。

まず、本人に知識や経験が不足しているからミスするんであって、そんな人に原因と対策を考えさせても、良い考えが出てくるとは思えません。ほんとうに対策を求めるのならば、より経験豊富な誰かの意見が必要なはずです。

また、投げっぱなしにしてしまうと、本人の自信を必要以上に削ぐ結果になりかねません。ミスした時点で、本人の自己評価は大きくマイナスになってます。対策を考えたところで、そのマイナスが小さいマイナスに戻るだけでしょう。対策をチームの資産として共有したり、失敗から得たものがあることを再評価するなどのフォローが必要です。

人間、誰でも失敗はつきもの。それを誰かひとりの責任にして押しつけるのではなく、メンバー同士でフォローしあって、チーム全体のレベルを上げていく。これが理想のあり方なんだなぁと感じました。

こういうチームで働いてると、もっとがんばろうって気持ちに自然となってきますよ。はやいとこ僕も誰かをフォローできる立場に回らなければ!