疲れた案件で学んだこと
2008年7月21日
それが望んだものでは無かったにしろ、結果として勉強にはなった。
まぁ、まだ完全には終わってないので、
「やったッ! 第3部完ッ!!」とか余裕こいているとアブないけども。
(1) 無駄に火種を広げない配慮 – その1
ある小さい問題が起こったときの対処の話で、
問題に対する説明が不十分なために、より大きい問題だと勘違いされて
その対応で無駄にコストを消費したことがあった。
問題を隠すのはダメだけど、小さい問題ならその小ささはちゃんと伝えることは必要。
この場合、言い訳がましいとかは考えない方が吉。
(2) 無駄に火種を広げない配慮 – その2
クリティカルな、またはクリティカルだと受け取られ易い問題が発生した際は
出来れば直で決裁権者に報告するか、無理ならそれに出来るだけ近い人に報告する。
現場担当者→現場リーダー→決済権者 とかの伝言ゲームを経ると
報告内容がどんどん不正確に、そして大きくなってしまって大変なことになる。
そのためには、こちら側の偉い人を使うのもアリ。
(3) 集中出来ない時の作業は失敗する可能性を計算に入れる
とりあえず、手元の作業には集中するように努める。
対応状況で集中するのが難しそうなら、作業をミスったときの影響を先に考えて
万が一失敗してもダメージが少ないなら続行、
ダメージが大きいなら、どんなに急ぎの作業でも一旦は停止した方がいい。
人間は失敗する生き物だなぁ、と、ひしひし感じた・・・。
他は一般的な話（要件はちゃんと趣旨まで把握しろよ、とか）を
実感したという話で、特に書く必要も無さそうなので割愛ing
(1) 「火消し」という役割の危険性
火消しで唯一楽な点は「選択肢が限られていること」だと思う。
問題点を洗い出すのも、それをまとめるのも、優先順位をネゴって実装するのも、
能力の良し悪しで解決する速度こそ変わるものの、
誰がやっても成すことにさして変わりは無い。
基本的には、カツカツの状況に放り込まれるので、
やるべきことを絞り込まざるを得ない＝選択肢が限られている、ということ。
「楽なんだからいいじゃん」というとそうでもなくて、
そうすると、企画力というか創造性というか、
0から何かを作り出す能力というか意志というか、
問題解決能力に対するそもそもの問題「創出」能力というか、
上手く説明できないすけど、
Web系エンジニアで一番美味しい部分の能力が育たなくなるんじゃ？ と思う。
一般的にプロジェクトの火消しという役割は、「難易度が高くて重要な役割」、
・・・ということになっている思われますが（実際そうですが）、
個人的には、こういう仕事ばかりやってると、
「大事な点が成長しない」という点で、すげー危険だと思います。
(2) 体調管理は重要
しかしながら、これ程自分の健康さが恨めしいと思ったことは無い。
・・・多分！！