SIerの組織レベルについて
プロジェクトが破綻する原因にトラックナンバー問題がある。知識が個人に独り占めされ様々なトラブルがおきるという問題だ。その人が事故や病気になれば破綻するし、或いはその人に問い合わせが集中して多忙になればチームは破綻する。これは個人が知識伝播しないことが悪いのではない。組織が知識伝播を支援しないことが悪いのだ。
では組織は知識伝播の支援をどのように実現すべきなのだろうか。それをSECIモデルで説明しよう。
知識というのは最初は人の頭の中にある。これを暗黙知という。
変換された形式知は伝播することができる。これにより知識は様々な人に広められる。
この流れをSECIモデルという。
SECIモデルを支援するのは組織の役目である。文書の間違いや曖昧さ、読みにくさを改修し管理することなどがそれである。組織は知識経路を追跡し技術者の知識レベルを分析する。組織により知識は適材適所にデリバリーされる。知識伝播はこうした組織の支援の元に達成される。
SIerは然しこうした支援に無頓着である。その姿勢を改めない限り彼等は今後も破綻プロジェクトを量産することになるだろう。
DIへの賛否
1.DIへの賛否
10年ほど前、DIはソフトウェア産業の問題を解決する銀の弾丸として喧伝され、それを実現するDIフレームワークのspringやseasarが登場した。DIはとても流行し最終的にはEJB3.0に取り込まれるまでになった。ではDIとは一体何者なのだろうか。
ここではDIの正体とDIがソフトウェア産業にもたらした功罪について考察する。
1.1.DIとは何か
DIとはDependency Injectionの略で直訳すれば依存性注入となる。そしてその正体は「オブジェクトの組み合わせをコントロールする仕組み」である。
〈図1〉
…
図1はUserがCoffeeImplを生成しないという意味だ。
次のソースコードを見て欲しい。
〈コード1〉
class User{
private Coffee coffee=new CoffeeImpl(); //①
public void drink(){
coffee.drink(); //②
}
}
coffeeにnew CoffeeImpl()を設定しているが、もしこのCoffeeImplがDBに依存しているならUserクラスの開発環境にもDBMSをインストールしなければならない。またテストする度にCoffeeImplが利用するテーブルのデータも再ロードする必要がある。
他に値をセットするメソッドもない。となればこのクラスは②で確実にNullPointerExceptionが起きてしまう。つまりバグである。
〈コード2〉
<component class="User">
<property name="coffee">
CoffeeImpl
</property>
</component>
意味はこうだ。
「Userロード時、coffeeにCoffeeImplのインスタンスをセットする」
もし設定ファイルがなければ①は
private Coffee coffee=new CoffeeImpl();
としなければならない。これではCoffeeImplに依存してしまう。
例えばCoffeeImplの内部でDBアクセスしている場合
ロード出来ない環境では動作確認出来ない。スタブとしてCoffeeImpl4TestをCoffeeImplの代わりに使いたい時にもUserクラスを修正し、動作確認が終わればまた元に戻さなければならない。
所がそのためには
上の設定ファイルの例ではCoffeeImplを設定しているが、
これによりUserクラスはCoffeeImplクラスへの「依存性」をソースコードに記述しないですむ。
設定ファイルにより「注入」できるため様々なメリットがあるのである。
ソフトウェアの再利用について
ソフトウェア再利用は開発効率と品質を向上させるための方法論の中でも最も重要なもののひとつである。だが、多くの組織はこの方法論の適用に対し積極的とは云えない。それはなぜだろうか。
ヨードンは、その理由は４つあると説明している。
・ソフトウェア工学の教科書は読者に「初めて習った原理」でシステムを作ることを教えている。再利用するようには教えていない。或いは再利用そのものを教えていない。
・自分の作ったもの以外を使わない。他人が作ったものを信じない。
・過去の失敗が再利用は実践的ではないと思わせている。
・再利用を高めた者に対する表彰を組織はしていない。生産性評価は新規開発者が対象で、再利用をした者はその半分以下の評価しか得られない。
ソフトウェアの再利用について
ソフトウェア再利用は開発効率と品質を向上させるための方法論の中でも最も重要なもののひとつである。だが、多くの組織はこの方法論の適用に対し積極的とは云えない。それはなぜだろうか。
ヨードンは、その理由は４つあると説明している。
・ソフトウェア工学の教科書は読者に「初めて習った原理」でシステムを作ることを教えている。再利用するようには教えていない。或いは再利用そのものを教えていない。
・自分の作ったもの以外を使わない。他人が作ったものを信じない。
・過去の失敗が再利用は実践的ではないと思わせている。
・再利用を高めた者に対する表彰を組織はしていない。生産性評価は新規開発者が対象で、再利用をした者はその半分以下の評価しか得られない。
仕様変更における対応
システム開発で仕様変更が発生した時に開発者たちは通常どうするのだろいか。ある開発者はこんな云い方をした。
