また今日もバグ対応

伸び悩んだ開発者が立て直しを図るためのブログ

テストシナリオ(というかほとんど要件定義レベルのこと)を洗い出して整理する工程をもっと大事にしようと思った

そもそもテスト仕様から漏れていたため、不具合を発見できなかった。

開発者が修正箇所だけを見たテストになっていたのでは?。

サービス面からの動作確認の視点が抜けていたのでは?  

という指摘を受けた。その通りだった。  

テスト仕様書の作成時点でバグを生んでいた言える。

そう正直に報告して謝罪した。

まあもっと正直いうとテスト仕様書も作成していなかったんだけど。。

一人に設計開発リリース保守まで任せることの功罪

また、今回の問題は私の案件への関わり方に問題がありました。

改善点の指摘と修正依頼だけして、既存機能への影響を詳しく検証させなかったこと、その後のフォローとリリース前の確認を怠ったことが大きな要因となっています。

本案件に限らず、問題把握から修正、リリース、その後の保守まで開発者一人で対応するケースが多く、このような体制が問題を起こしてしまうことを改めて痛感しました。 情報共有の範囲を改修のメインの担当者以外にも広げ、複数で確認し、開発者をフォローできるよう体制づくりを考えていきます。

 

そりゃ関係者が増えれば増えるほど面倒なことは増えるんだけど、一人はマズイ。

一人はまずかった。

とはいえ、体制体制って無駄に頭でっかちになることもあってスピード感なくなるし、結局他案件が忙しくなると元に戻ってしまったりするし、開発者自身が一人でやりたがるって面もあって難しいんだよね。

 

どうしようか。

 

チームがだした障害について、責任者である自分は何もレスポンスできなかったという話

 全体最適化を考えますので、そちらでもコメント、改善点があればドシドシお願いします。

大きな 障害後に開発パートナー会社のお偉いさんから飛んだメール。

 

反応できなかった。

自分は責任者でもある以上、何かしらコメントすべきだし、最低限メンバーの説明と対応が適切であるかを見届ける義務がある。メンバーの対応に関しても簡単に障害の内容と状況報告を聞いた程度に留まってしまった。

何をいってもその場しのぎの内容の薄いコメントになりそうな気がして、反応できなかった。

 

パートナー会社からは無関心なやつ、無責任なやつと思われるだろうし、不具合を出してしまった担当者にはいざというときに守ってくれないやつだと幻滅されたかもしれない。

 

すぐには気の利いたことが言えない場面でも、相手の感情を考えて何かしらレスポンスを返すべきだった。

 

チームのメンバーが目標を達成できるように手助けするということ

 

あるタスクを達成するために、どの時点では何が出来ていなければならないのかを明確にしてあげる。

見通しや段取りを、どこまで細かくするか その人の能力や性格に応じて変える。

細かく計画を立ててないと動けない、というタイプの人には細かく正確に。

細かく指示されるとやる気を失ってしまう、というタイプの人には重要なポイントだけ。

 

できない。そもそも自分自身の作業の段取りもできないのだ。

自分はほんとに人一倍時間をかけて、とにかくトライ・アンド・エラーで、ああだこうだやりながらゴールを目指すタイプのやり方でなんとかしてきた。

 

一人でやってる時は良かった。それなりに周りからも評価してもらえていた。

自分がチームでやるに向いていない人間だと気づいて軽くショックを受けている。

人の段取りを助けてあげることことなど到底できない。

 

人を使うのが苦手だとという烙印を押されてもがいている。

とにかく今の自分にできることだけでも何かやらなくてはいけない。