Article 82 at 05/01/19 12:18:06 From: editors@objectclub.jp Subject: 【オブジェクト倶楽部： 2005-02号】

Date:  Wed, 19 Jan 2005 12:31:23 +0900
Subject:  【オブジェクト倶楽部： 2005-02号】

　　　　　　　┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
　　　　　　　┃　　　　　　　　　　　　　　　　　　　　　　　　　■┃
　　　　　　●┃●　●　オ　ブ　ジ　ェ　ク　ト　倶　楽　部　　　■　┃
　　　　　　　┃　　　　　　　　　　　　　　　　　　　　　　　■　　┃
　　　　　　　┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
　　　　　　　　　　　　　　　　　　　　　　　　　　No.77　2005/01/19

■　I　N　D　E　X
┃
┣【Topics】オブジェクト指向プログラミングテキストを公開しました
┣【Topics】お試しセミナー受講者を募集します
┣【ＰＭ】プロジェクトマネジメント入門[20]
┣【設計】ソフトウェアのお言葉[2]
┗【アンケート】気になるシステム業界 ホントのところ

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
　〇　 オブジェクト指向プログラミングテキストを公開しました
　　〇 〇━━━━━━━━━━━━━ ━━・　

株式会社OSKの小井土さんより、『プログラミングトレーニングテキスト』、
『C#の基礎』の2つの技術テキストをいただきました。オブジェクト倶楽部のサ
イトで公開します。2つとも、大変内容が濃く、初めて勉強される方にも、再度
勉強し直される方にも最適です。小井土さん、ありがとうございました！
http://www.ObjectClub.jp/technicaldoc/c/

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
  〇　 お試しセミナー受講者を募集します
 　 〇 〇━━━━━━━━━━━━━ ━━・　

1月26日(水)、28日(金)に開催する「Webアプリケーション開発のためのWeb基礎
知識」のお試しセミナーの参加者を募集いたします。
普段からWebアプリケーションの開発をしているけど、フレームワークに隠れて、
本来のWebの仕組みが分からないという方はそう少なくないでしょう。今回のセ
ミナーでは、Webを構成するプロトコルをはじめ、セキュリティを確保するため
にプログラミングで気をつけることなどをご説明します。
毎度のごとく、セミナー終了後のお楽しみ時間もあります。

詳細・申し込みはこちら：http://po2d.esm.co.jp/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【ＰＭ】プロジェクトマネジメント入門[20]

前回は、PMOの機能と役割の話しをしました。
今までのお話しは、プロジェクトを中心とした組織でのお話しでした。では、
PMOを中心としたプロジェクト運営組織とはどのようなものなのか、今回は、プ
ロジェクトを実施する組織について話をします。

多くの日本の会社組織は、機能別に分けた組織、いわば機能中心組織です。事
業部の下に企画部、営業部、開発部、検査部などいうように、その部の役割ご
とに分割して業務上の作業範囲を明確化しその範囲内の業務責任と、人的リソー
スはじめ各種リソースのマネジメント責任も負ってきました。

このような組織では、営業部は売上責任、開発部はスケジュール、コスト、品
質という開発責任、検査部は出荷責任をそれぞれが負いながらプロジェクトを
運営するため、どうしても、よく言われる縦割り的になってしまいます。この
ような縦割りをなくすためにプロジェクト毎にコーディネータをつけて、この
コーディネータが各部門間の調整しながらプロジェクトを進めていく方法もあ
ります。しかしながら、この方法では、このコーディネータに権限が与えらな
いことが多く、これでは各部門の利害調整に終始し、いい結果が得られないこ
とが多いようです。

PMOを中心としたプロジェクト中心の組織では、各部門のプロジェクト運営に必
要な権限をPMOに委譲した組織としています。この権限の委譲範囲で、プロジェ
クト中心の組織は2つに分けられます。

(1)作業分担型組織：PMOがプロジェクトのマネジメントし、各部署は役割に合っ
   た作業を担当しながら行う組織
(2)リソースプール型組織：PMOがプロジェクト運営に関する全ての権限を持ち
   各部署はリソースマネジメントのみを担当する組織

プロジェクト中心度から言えば、リソースプール型組織の方が高いでしょう。
我々が行うシステム開発プロジェクト、顧客とのプリセールスから始まり、開
発、検査、納品、その後のポストセールスという一連のプロジェクトは、この
プロジェクト中心の運営方法に近いと思っていますが、大半の会社では、機能
中心的な組織で運営されているように思います。

機能中心、プロジェクト中心、どちらがいいかはそれぞれ一長一短があり、賛
否両論あります。筆者の感覚では、プロジェクト中心は当然のことながらプロ
ジェクトを成功させるための組織です。よって、プロジェクトの成功、つまり、
利益や品質などに視点が移ります。一方、機能中心は、その組織の中で与えら
れた役割をきっちりこなすことを目的にしていますので、作業の質やリソース
の質（社員教育）を重点に考えるような組織になるのではと思っています。
筆者が所属している事業部では、未だ試行錯誤しながらですがソースプール型
の組織運営を行っています。

次回は、筆者のソースプール型の組織運営での課題などをお話しして行きたい
と思います。（事務局長）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?F001+19+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?F001+19+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?F001+19+2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【設計】ソフトウェアのお言葉[2]
           - クラス継承よりもオブジェクトコンポジションを多用すること

こんにちは、天野勝です。
今回のお言葉は「クラス継承よりもオブジェクトコンポジションを多用するこ
と。」[*1]です。前回に引き続きGoF本[*2]からお言葉を頂戴いたしました。

お言葉のとおり、クラスを拡張する場合は、実装を継承するクラス継承よりも、
機能を既存のクラスに委譲するオブジェクトコンポジションを使うことが推奨
されています。
クラス継承の例(InheritanceClass)と、オブジェクトコンポジションの例
(CompositionClass)を以下に示します。
それぞれ、FixedClassクラスのwantMethodメソッドだけを必要としており、
otherMethodメソッドは新しいクラスでは必要としていません。また新たな機能
を実現するために、newMethodメソッドを定義しています。

===================================================================
// 既存のクラス。wantMethodだけ使いたい
class FixedClass {
    public void wantMethod() {...}
    public void otherMethod() {...}
}

// クラス継承
class InheritanceClass extends FixedClass {
    public void newMethod() {...}
}

// オブジェクトコンポジション
class CompositionClass {
    private FixedClass fixedClass = new FixedClass();
    public void wantMethod() {
        fixedClass.wantMethod();
    }
    public void newMethod() {...}
}
===================================================================

筆者が、オブジェクト指向を勉強して初めて感動したのは、プログラミング言
語でサポートしているクラス継承の機能でした。元のクラスを継承して、必要
なところだけ追加したり、上書きしたりして、新しいクラスを定義するのです。
俗に「差分プログラミング」などと呼ばれている考え方です。しかし、なんと
GoF本ではこの強力な機能を否定し、面倒くさい方法を推奨しているのです。新
しいクラスを作るときに、元となるクラスの参照を持たせて、必要な処理は元
のクラスに委譲するのです。

では、その推奨理由を考えてみます。
注目すべきは、クラス継承の例であるInheritantanceClassクラスでは、不要に
もかかわらずFixedClassクラスで定義しているotherMethodメソッドが公開され
てしまうという点です。
これは、不要な結合を避けるためにもインタフェースは最小にするべきという、
「インタフェース分離の原則(ISP:Interface Segregation Principle)」[*3]に
違反していることになります。
また、FixedClassクラスの一部分しか使わないということは、正しい継承関係
(is-a)が構築されているとは考えにくいです。これは「リスコフの置換原則
(LSP:Likov Substitution Principe)」[*4]も満たしているとは考えにくいです。
オブジェクトコンポジションでは、インタフェース分離の原則も、リスコフの
置換原則も満たしています。これらの原則を守ることで、今後発生しうる修正
の影響を受けにくい構造になるのです。確かに、短期的な開発のスピードは落
ちるかもしれませんが、保守も含めた長期的な開発のスピードをあげることが
できるのです。
結合度の観点で見てみると、クラス継承は良くも悪くもスーパクラスとサブク
ラスの結合が強く、スーパクラスの変更の影響をもろにサブクラスが受けてし
まうのです。うまく使えれば良いのですが、クラス継承の階層が深くなってし
まうと、より下位のサブクラスに悪い影響が出てしまうことが少なくありませ
ん。このようなことからも、新たなクラスを作成する場合は、クラス継承より
も、オブジェクトコンポジションが推奨されるのです。
(天野勝)

[1]:「オブジェクト指向における再利用のためのデザインパターン」P.31
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/xpjp-22/

[2]:[1]で紹介した本は、4人の著者によって書かれています。ソフトウェア開
発に多大なインパクトを与えたということから、この著者たちは、文化大革命
の4人組になぞらえて、Gang of Four、略してGoFと呼ばれています。

[3]:週刊オブジェクト倶楽部26号参照
http://www.objectclub.jp/ml-arch/magazine/27.html
クライアントに、クライアントが利用しないメソッドに依存するように、強制
してはならない、という原則。

[4]:日経ソフトウエア 2004年11月号 「オブジェクト指向設計の考え方」参照
全てのサブクラスは、スーパクラスが期待されているメソッドに渡されても正
しく動作するように設計されければならない、という原則。
ちなみに、B.H.Liskovは、1970年代のMIT在籍中にCLUというプログラミング言
語の中で、「抽象データ型」という概念を具体化しました。この抽象データ型
というのは、オブジェクト指向でいうところの「クラス」に相当します。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?L001+1+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?L001+1+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?L001+1+2
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ

今週は「携帯電話はどこのキャリアですか？」のホントのところ。もはや、生
活必需品となった携帯電話。どこのキャリアをお使いですか？

  NTTドコモ
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+41+0
  KDDI
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+41+1
  ボーダフォン
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+41+2
  ツーカー
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+41+3
  PHSを使ってます。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+41+4
  携帯電話持ってません。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+41+5
  それは秘密です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+41+6
  ちょっと語らせて！
     editors@ObjectClub.jp まで詳細を！！

アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「今年のオブジェクト倶楽部に何を期待しますか」の結果は公開中。
是非ご覧下さい。⇒http://www.ObjectClub.jp/special/kininaru/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記

こんにちは、編集人です。先週号でお知らせした、XFDのページ。いろいろなと
ころで、XFDの案が挙がっているのを実は知っています。せっかくのアイデア、
日記等、たくさん紹介していけたらいいなと思ってます。そのうち、あなたの
ところに、個人的にお願いしに参上するかも？
http://www.objectclub.jp/community/xfd/

今週の強引な一言
*** 論より証拠（ことわざ）***
正しく設計したんだからちゃんと動くはずだ！と言い張ってみたところで、動
かないものは動きません。テストで確実に動作確認するのが早道です。
（さとみ）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は         ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は   ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋  健児
Copyright (c)2003-2005 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.