Compartir a través de

【コラム】ソフトウェア開発における対症療法と原因療法（４）

  • Artículo

こんにちは。いやーしかし Spam コメントが多くなってきました。年末だからでしょうか？？このブログはコメントもトラックバックも何も制限をかけない方針です。それは今までもこれからも変えないつもりでいますが、 Spam のターゲットにされてしまった投稿については、泣く泣くコメントを制限または、コメントできないようにしてしまっています。あらかじめご了承ください。

さて、無計画連載の第四回目です。

ソフトウェア開発における対症療法と原因療法（１）

ソフトウェア開発における対症療法と原因療法（２）

ソフトウェア開発における対症療法と原因療法（３）

前回に、原因療法の失敗原因として主なのものとして二つあると書きました。新しい試みを行うと必ず、何かを犠牲にする必要があります。それが生産性です。

どんなにすばらしい試み（プロセスにせよ、ツールにせよ、人員増強にせよ）でも、導入当初は一時的に開発生産性が落ち込みます。これはまず認識していただきたい事実です。これを無視すると手っ取り早く、誰かにとって不幸な事態を招いてしまいます。

問題はこの事実を受け入れ、どう対処して、いかに本来望まれる状況へ早く持っていくかにかかっています。そのためには、二つのポイントがあると考えられます：

  • フォロー/サポート
  • 落ち込みを軽減する施策

フォロー/サポートとは、現実的に落ち込む開発生産性をサポートするということです。具体的には、落ち込みが見込まれる期間に対して、工数を多めに見積もる（要するに導入も見込んだ適切な工数を見積もるということですね）、パイロットプロジェクトと認定し、ある程度のバッファや予算の余力を準備する、などですね。間違っても、現スケジュールで、現人員で、実施することだけを増やすようなことは極力さけるべきです（現実的には、これが多いわけですし、避けられない事実もあります）。

落ち込みを軽減する施策とは、仮に大きな改善効果が見込める試みであっても、一度に急に導入するのではなく、達成可能な部分にとどめ、生産性の低減の落ち込みを少なくし、負担の軽減と効果の体感をしつつ、次のステップに進む方が得策であるということです。

大きな落ち込みがあると、這い上がるのに、それ相応の負担を現場に強いることになります。それをよしとするプロジェクトはいいのですが、そうでないならば、それらの負担は開発の現場に襲い掛かってきます。

這い上がるまでの負担に押しつぶされて断念するケースと、這い上がり効果を得るまでの時間が許されないケースがありますが、どちらも現場にとっては不幸な結果になりかねません。

ながさわ

Comments