トラブルをマネージャに伝えるコツ


トラブルは起きるもの
仕事をしていれば、作成したプログラムが動かなくなったとか、想定外の振る舞いをしたとか、所謂システムトラブルは付き物だ。その原因を聞けば、単なるプログラムのコーティングミスの場合もあるし、設計の仕様誤りの場合もあるし、顧客の要件の曖昧さによるケースもある。いづれにしても、人が手作業で関わる物には誤りを完全に除去することは現実的に難しい。
だからと言って、トラブルを許容しているわけではない。顧客の要件は、具体的に引き出したいし、設計は要件を満たすように網羅したいし、プログラムは要件で求められるフィーチャーを実装したい。それを実現するためのアクティビティをした上ではじめてトラブルが起きたときに許容されるものだ。


初動を押さえろ
なぜか、トラブルが起きるとこんなタイプのエンジニアを見かけることがある。本番で運用中のシステムがトラブルを生じたら、利用している顧客は困惑する。場合によっては業務が止まるからだ。そのシステムが基幹システムであったなら、そのシステムが停止している時間に利用者の分だけ損失することになる。そんな顧客の利用業務は、設計や実装をしたエンジニアなら容易に想像が付くはずだ。ところが、海の向こうで起きたように他人事のように受身で振舞う。
受身で振舞うから、自分の関心のあることしか調べない。事象も断片的にしかわからない。トラブルを必要以上に悪化させる原因に初動を誤りがある。初動の振る舞いを間違えると、報告で終わるものも顧客離れを起こす原因になりかねない。
実際、トラブルがあったときは、次のことを意識、無意識に問わず行動しているだろう。

  • スピード感
  • 時間を区切る
  • 事象を把握する
  • 情報共有者を特定する
  • 情報を共有する
  • 段階を追って事実を突き止める
  • 対処方法を判断できる情報を整理する

このほか、事実と推測は区別することも大切だ。


誰がどうした?を意識する
事実を押さえ、情報を必要な人と共有すると言うことは、日常でやっているハズなのに、このようなトラブルが起きたときに同じように動けないもの不思議なことだ。例えば、結合テストをしていれば、フィーチャーとおりに動作しない不良を炙り出すための作業だから、不良を検出したらバグ票かバグのチケットを切るだろう。そのバグ票に何を書いて、そのあとどのように行動するだろうか。
どこでも、バグ票ならこんな内容を記録するだろう。

事象 いつ、どこで、誰が、何をしようとして、何が起きた
事実 どこに、どんな記録(ログ)があるか
推定 事実から推測できる原因の特定
究明 事実からの原因の究明、原因箇所の特定
対処 誰が、いつまでに、何を、どう(暫定対処か、恒久対処か)するか

さらに、不良を埋め込んだ原因を遡り、元の作業工程の改善や品質の作り込みへのフィードバックをするなら、事象と原因の細分化まで特定するだろう。

上記の記録する内容を見直せば、本番でトラブルが起きたときの初動で行う動作と押さえる情報そのままであることに改めて気付くだろう。つまり、普段していることがそのまま変わらないのだ。
一つ配慮が必要なことは、バグ票はその場面によって、参照する人が変わってくるということだ。結合テストならプロジェクトチーム内、若しくは、結合テストに関与するチーム間で共有する。本番でのトラブルならマネージャや顧客まで共有することさえある。そのままのバグ票で見なくても、サマリで情報は共有される元の情報であることは変わらない。そのときに、必要な事項は押さえて記載するのはもちろんのこと、殊更、“誰がどうした”を意識して記載することだ。誰とは、個人名ではく、ロールでよい。誰も個人を責めるつもりはない。誰が主体的に動き、どのように解決していくのかを見通したいだけなのだ。





  • 道具室(アプリとか)

ストーリーポイントと理想日の違いが、中々腹に落ちず。頭でわかっているつもりでも、胸がすっきりしない感じ。自分の言葉でうまく言い替えられなければ本質的に理解しているといえないとわかっているから、ちょっと歯がゆい日を何日か過ごした後、ふと「あぁ、それでいいじゃん」と思うときが間々あるもので。大げさに言えばブレークスルーした、みたいな。実際適用するなら経験のないチームには理想日のほうがWBSの展開で経験をしているから取っ付きやすいだろう。理想日でボトムアップで積み上げるか、仮定か一般的な画面などチームで作業のプロセスとボリュームの共通認識を作ってそれを基軸にほかの作業を計るか。積み上げは抜け漏れの恐れや仔細な仕様の有無に無駄な時間をとられるから、短時間に“大体の”見積もりをするというプライオリティなら必然とストーリーポイントになるだろう。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

  • 音楽室(PCからリンクをクリックするとき、PCにiTunesが入っているとアプリケーションが起動します)
  • 視聴覚室
  • 調達室