【コラム】ソフトウェア開発における対症療法と原因療法（２）
こんにちは。無計画連載の第二回目です（＾＾
前回は、対症療法と原因療法というのがあり、それはソフトウェア開発の現場、とりわけ開発現場の業務の改善、プロセスの改善で考えてみるといいですよという話しをしました。
何か が起きたときにそれを短期的に解決する手段として対症療法が効果を発揮します。そのときには、ツールを活用することで非常に効率よく、対応することができます。
たとえば、ソースコードの保守性があまり好ましくなく、何らかの方法で、現状を把握しないと収拾がつかない・・・といった場合には、静的なコード分析がそれを解決する一つの手段となります（コード分析だけしたら解決するということではないのですが）。
規約に即しているか、複雑度がどれくらいかを把握できれば、好ましくない点が見えてきます。そこに対してピンポイントで対処すれば、問題は解決できるかもしれません。ということです。
しかし、どうしてそのような保守性が好ましくない状況になってしまったのかは、まだ未解決です。要するに同じようなことがこれから先、別のプロジェクトも含めて、起こりえる可能性が高い状態のままだということです。
起こったときにまた対症療法で解決すればいいではないか。そのためのツールだ。という考え方もあります。しかし、ことが起こった後に対処するにはそれ相応のコストがかかります。起こる可能性が高いとわかっているのに、毎回、毎回、計画外のコストをかけていくこと、それ自体もリスクであり、課題であるととらえることができます。
そこで意識する必要があるのが、原因療法という発想になります。
なぜ、問題が起きるのか、問題が起きないようにするには何を改善すればいいのかを見極め、根気よく実践していくことが必要になってきます。原因療法は対症療法のように簡単にスパッとツールを使えば解決！なんてことにならないケースが多いです。
先の例だと保守性の好ましくないソースコードになってしまったのは、開発者のモラルやスキルのばらつきが原因かもしれません。はたまた、多忙すぎにより、保守性までケアする余裕がないのかもしれませんし、そもそも設計が好ましくないため素直にコーディングしたら保守性が好ましくないのかもしれません。
いずれにせよ、原因を明確化することは大切になります。仮説をもとにしてもいいんです。重要なのは原因療法としてこれからどうしていくか、それに伴うリスクとケアするポイントを考えて、実践していくことです。
実践していくにあたっては、プロセスの改善やそれに伴う周知・教育/トレーニングも必要になってきます。また、ここでもツールは強力に効果を発揮します。定型的な作業やつい忘れてしまう作業、凡ミス、オペミスが発生してしまう作業を自動化や省力化できれば、それだけ本来の作業（頭を使う作業）に注力できるようになり、かつ課題も改善されているという状況を作り出すこともできます。
この場合のツールは、単にツールを使うということより、どのタイミングでどうそのツールを活かすかがポイントになってくるわけですね。
ながさわ
Comments
Anonymous
November 29, 2007
こんにちは。無計画連載の第二回目です（＾＾ ソフトウェア開発における対症療法と原因療法（１） 前回は、対症療法と原因療法というのがあり、それはソフトウェア開発の現場、とりわけ開発現場の業務の改善、プロセスの改善で考えてみるといいですよという話しをしましたAnonymous
December 17, 2007
こんにちは。無計画連載の第三回目です（^^; だいぶ間が開いてしまいました。。。 ソフトウェア開発における対症療法と原因療法（１） ソフトウェア開発における対症療法と原因療法（２） 原因療法なのですが、実はなかなか成果が出ていないということをよく耳にします。途中で頓挫してしまうんですね。なぜなのでしょうか。主な要因のひとつに、Anonymous
December 25, 2007
The comment has been removedAnonymous
February 19, 2008
こんにちは。無計画連載の第三回目です（^^; だいぶ間が開いてしまいました。。。 ソフトウェア開発における対症療法と原因療法（１） ソフトウェア開発における対症療法と原因療法（２） 原因療法なのですが、実はなかなか成果が出ていないということをよく耳にします。途中で頓挫してしまうんですね。なぜなのでしょうか。主な要因のひとつに、