研究紹介 2014 年版

2014年6月11日(水)の研究紹介で用いるスライドを公開します。

研究紹介 2014年版 from Susumu Yamazaki

ドラッカーについて語る～齋藤貞之先生退官記念講義

この3月はめまぐるしく様々なことがあり，貴重な体験をしました．3月11日に東日本を襲った大震災もあり，その痛ましい危機的状況の中で Twitter をはじめとするネットワークが目覚ましい働きをしました．翌3月12日にはプライベートワークショップを開催しました．幸い参加者は震災の影響を受けていませんでした．さらに3月19日には教育システム情報学会研究会で初めて発表をしました．これらについても，いずれは語っていこうと思っています．

そんな中，3月20日に私が尊敬する齋藤貞之先生が退官記念講義を行ないました．ちょうど私自身が研究の方向性について思い悩んでいた中で，齋藤先生の講義は，一筋の，いやまばゆい光明に思えました．今回はそれについて語っていきたいと思います．

まず最初に，齋藤先生が自身の研究テーマであるドラッカー(Peter Drucker)に強い関心を持つに至った経緯から，講義は始まりました．齋藤先生は大学生1年生のときに，当時の流行だったマルクスに関心を持ちます．先輩に勧められてマルクスを読んでみて「目からウロコが落ちた」そうです．しかしそれ以上に関心を持ったのが，マルクスが批判しているヘーゲル，カントなどの思想でした．その話を先輩にすると「なぜマルクスが批判する考え方を支持するのだ」となじられ，後に当時の社会がマルクスを賞賛することについて疑念を持つようになります．「私はヘーゲルやカントを純粋に面白いと思う．なのに，なぜみんなはそれらを拒絶するのだろうか」と．だからこそマルクス以外を精力的に読むようになっていきます．そんな中，出会ったのがドラッカーの著書でした．ドラッカーの著書には，マルクスを超えた「未来の社会のあり方」が書かれていると齋藤先生は直感したのだそうです．

ドラッカーはユダヤ人系のドイツ人でした．ドラッカーの最初の著書は1939年の「経済人の終わり (The End of Economic Man)」，次が1942年の「変貌する産業社会 (The Future of Industrial Man)」です．当時のドラッカーの問題意識は，本質的にはその後の書籍にも一貫して受け継がれているそうです．齋藤先生が感銘を受けたのはこの時代の書籍でした．

ドラッカーの問題意識は「このままでは社会が崩壊する」という危機感でした．当時はソ連，ナチス，ファシストといった全体主義が盛んでした．ドラッカーがユダヤ人だということもあったのでしょうが，それ以上に彼は自由主義の危機だと考えたのでしょう．

ドラッカーの仮説は，このような全体主義は，レーニンやヒトラー，ムッソリーニといった人物が登場したことによって生まれたのではなく，社会構造そのものが原因となって生まれたのではないか？ということでした．

この仮説がどういうことか，齋藤先生は当時の社会状況を背景に解説しました．

1. 20世紀以前は，経済活動の中心は個人でした．また，地域のコミュニティも盛んでした．個人は，地域のコミュニティの中で一定の役割を果たして地域に貢献していました．このことで，地域社会は成り立っていました．
2. しかし19世紀末から20世紀初頭にかけて，巨大企業という組織が急速に発達しました．個人はコミュニティから引きはがされ，組織の中に組込まれていきます．こうなると個人は「根無し草」になってしまいます．つまり，自らが果たすべき役割を見失い，いずれは企業から使い捨てられてしまう状況に陥ってしまったのです．
3. 民衆がそのような不安にさらされる中，登場したのが全体主義でした．全体主義では個人が自分の役割を考える必要はなく，与えられた一定の義務を果たせば済む社会でした．自由がない代わりに，役割について悩む必要がない，そんな全体主義の方が快いと民衆は錯覚したのです．

ドラッカーは個人の役割を表す表現として function という言葉を用いました．技術者にとっては function といえば機能とか関数とかいった訳語を連想すると思います．個人が社会に対して持つ機能というのは，まさに個人の社会における役割と言えるのではないでしょうか．

だからこそ，ドラッカーは巨大企業の経営のあり方を研究対象としたのだと，齋藤先生は言います．コミュニティにおける個人と同様に，巨大企業も社会に対して役割(function)を明確に定義すべきだというのが，ドラッカーの一貫した主張なのです．

個人が集まった存在である組織を意味する organization という言葉の語源は，生物の器官を意味する organ です．器官と組織には次のような相似性があります．

• 役割: 生物が生命を維持できるのは，それぞれの器官がそれぞれの役割あるいは機能を果たしているからです．同様に，社会を一種の有機体としてみたときに，社会が社会として機能するためには，それぞれの組織がそれぞれの社会的役割(function)を果たす必要があります．
• 不可分性: 器官は生物本体と不可分であり，生物から切り離してしまうと意味を持ちません．これはどういうことかというと，器官は生物の他の器官と相互作用することによって役割を果たすことを意味します．同様に，組織は社会と不可分であり，社会的役割を果たすには社会の他の組織との相互作用が必要不可欠です．

このように捉えたときに，ドラッカーが「組織のトップマネジメントの仕事は何か？」という問いを発し続けていることの背景が理解できます．ドラッカーの枠組みから類推すると，組織の中の構成員も，組織に対して役割を持つことが求められます．トップマネジメントも組織の構成員の1人ですから，当然，組織に対する役割を持つ必要があります．組織のトップマネジメントが果たすべき最重要の役割の1つは，その組織の社会に対する役割を明確に定義することだと，ドラッカーは主張しているのです．

では，巨大企業は社会に対してどのような役割を果たせばいいのでしょうか？ ドラッカーは3つのことを挙げています．

1. 社会制度(institution)を守ること．社会制度は必ずしも法制化されたものだけではなく，文化的なものも含みます．コミュニティにおいて，個人は制度を無視することはできますが，無視するとその個人は村八分にあいます．同様に，巨大企業も社会制度を無視することはできません．この原則により，組織は社会に有用なものを生み出すことが求められます．
2. 巨大企業の構成員それぞれに適切な役割(function)を与えること．個人が生きていくにあたって function は不可欠です．巨大企業がコミュニティから個人を切り離している以上，コミュニティに代わって function を与えてやる必要があります．
3. 巨大企業の経営者が経営権を持つことについて，正当化できるよう自浄作用を持つこと．巨大企業は構成員の生殺与奪権を持っています．これはかつてコミュニティが個人に対して持った生殺与奪権をはるかに上回るものです．したがって，経営者に据える人は，そのような権利を行使するにふさわしい正当な資質を備えている必要があります．

齋藤先生は最後にリーダーの資質について触れました．経営には，science の側面と art の側面があります．経営学における典型的な science の例は MBA です．一方で，経営には理屈を超えた感性，つまり art の側面が必要であるという説も根強いです．ドラッカーはこの問いに対して「感性は不可欠である．しかし，最後に決め手になるのは integrity である」と述べています．Integrity は辞書を引くと正直，高潔といった意味がまず挙りますが，ここでは「統合」という意味が適切だそうです．ソフトウェアの世界で integration は統合と訳しますが，integrity は integration と関連が深いのです．

では integrity に必要なのはどのようなことでしょうか．ドラッカーは次の5つを挙げています．

1. 部下の短所ではなく長所を見ること．
2. 意思決定をするときに，意見の発言主が誰かによって判断するのではなく，発言内容そのものによって判断すること．
3. 知性の高い人よりも，integrity のある人を重視すること．
4. 自分より能力の高い部下を退けないこと．
5. 自らの業績目標を高く設定すること．

以上が齋藤先生の講義内容でした．

私がこの講義を受けて真っ先に思ったのは，ドラッカーの問題意識は，現代の日本における課題の核心を突いているということです．ドラッカーが当初抱いた「根無し草」の仮説は，まさに現代日本で問題になっている無縁社会そのものです．現代日本でドラッカーが注目を集めている理由の1つは，この仮説にあるのかもしれません．

と同時に，当然のことながらドラッカーの生きた20世紀初頭と，現代日本の21世紀初頭では前提条件が異なるので，結論が変化する可能性があるとも思いました．特に現代ではネットワーク技術の発達が著しく，ネットワークを介した新たなコミュニティが生まれています．そういう新たな時代背景をドラッカーが見たとしたならば，どのような理論を構築していくのだろうのかと，興味深く思います．

他に私が疑問を抱いたのは，「役割を果たすには何をすべきか」の議論です．主体を個人に置き換えて考えてみたときに，確かに社会が個人に求める役割を果たすべきだというのは理にかなっているとは思います．しかし，個人には個性があり，社会が求める役割には収まらない部分があると思います．私自身に置き換えれば，私個人の関心事の広がりは，社会が私に求める「大学教員」あるいは「研究者」としての役割では収まらないと実感しています．

ドラッカーは「集中せよ」と説いていますが，集中して切り捨てられる部分がどうしてももったいなく感じるのです．これは企業が選択と集中ではなく多角化を進める傾向があるのにも通じることだと思います．この問題に対するドラッカーあるいは齋藤先生の意見が聞きたいです．

抽象化とは何か？

SWEBOK 2004 に挙がっている Software Design Enabling Techniques の1つ，Abstraction (抽象化) について考察してみました．

僕が考えた抽象化の定義は次の通りです．

抽象化は，(1)複数の具体的な概念や現象の共通性を見いだして，(2)不要な枝葉の情報をそぎ落として一般化し，(3)それに適切な名前をつける行為である．

これら3つの要素が備わらないと抽象化とは呼ばないような気がしました．まず第1に，抽象化の対象は複数あること．もし対象が1つしかなかったら，抽象化する必要はなく，具体的なまま扱えばよろしい．なおかつそれらを共通化して扱いたいという動機がある．第2に，複雑なまま扱うのではなく，ある観点にしたがって不要な情報をそぎ落とすプロセス(捨象)が大事です．そして第3に，あとで再利用できるように適切な名前をつけることが重要です．

そう思って SWEBOK 2004 を読むと， Liskov と Guttag の書籍[Lis01]を引用して次のように書かれています．

Abstraction is "the process of forgetting information so that things that are different can be treated as if they were the same." [Lis01]

僕の訳文は次の通り． 

抽象化とは，複数の異なるものを，あたかも同じものであるかのように扱うために，捨象するプロセスである．

やはり抽象化の対象は複数あり，それらを共通化して扱いたい動機があります．forgetting information を捨象すると訳しましたが，不要な情報をそぎ落とすことですね．ただし，名前をつけることは含まれていないようです．

SWEBOK 2004 によると，抽象化の道具立ては下記の通りです．

In the context of software design, two key abstraction mechanisms are parameterization and specification. Abstraction by specification leads to three major kinds of abstraction: procedural abstraction, data abstraction, and control (iteration) abstraction. [Bas98:c6; Jal97:c5,c6; Lis01:c1,c2,c5,c6; Pre04:c1]

 箇条書きで書くと次のように整理できます．

• 抽象化(abstraction)
• パラメーター化(parameterization)
• 仕様化(specification)
• 手続き抽象(procedural abstraction)
• データ抽象(data abstraction)
• 制御(繰り返し)抽象(control (iteration) abstraction)

これらをそれぞれ教材化すればいいわけですね．さっそく参考書籍をそろえましょう！

SWEBOK 2004

Chapter 3 Section 1.4.1 Abstraction

http://www.computer.org/portal/web/swebok/html/ch3#Ref11

[Lis01] B. Liskov and J. Guttag, Program Development in Java: Abstraction, Specification, and Object-Oriented Design, Addison-Wesley, 2001.

[Bas98] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998.

[Jal97] P. Jalote, An Integrated Approach to Software Engineering, second ed., Springer-Verlag, 1997.

[Pre04] R.S. Pressman, Software Engineering: A Practitioner's Approach, sixth ed., McGraw-Hill, 2004.

Twitter のコメント

十分性，完全性，プリミティブ性

SWEBOK 2004 の設計の章で次の基本原理が挙がっていました．

• 抽象化(Abstraction)
• 相互結合と凝集強度(Coupling and cohesion)
• 分割とモジュール化(Decomposition and modularization)
• カプセル化・情報隠蔽(Encapsulation/information hiding)
• インタフェースと実現の分離(Separation of interface and implementation)
• 十分性，完全性，および基本性(Sufficiency, completeness and primitiveness) 

このうち，最後の十分性，完全性，基本性(プリミティブ性)について原典をあたってみました．SWEBOK 2004 によると [Bus96] 第6章と [Lis01] 第5章でした．このうち [Bus96]は既に持っていたので参照しましたが，[Booch90] を引用していました．


[Booch90] には十分性，完全性，プリミティブ性について下記のように書いていました(改段落は僕が入れました)．

By sufficient, we mean that the class or module captures enough characteristics of the abstraction to permit meaningful and efficient interaction. To do otherwise renders the component useless. For example, if we are designing the class Set, it is wise to include an operation that removes an item from the set, but our wisdom is futile if we neglect an operation that adds an item. In practice, violations of this characteristic are detected very early; such shortcomings rise up almost every time we build a client that must use this abstraction.

By complete, we mean that the interface of the class or module captures all of the meaningful characteristics of the abstraction. Whereas sufficiency implies a minimal interface, a complete interface is one that covers all aspects of the abstraction. A complete class or module is thus one whose interface is general enough to be commonly usable to any client. Completeness is a subjective matter, and it can be overdone.

Providing all meaningful operations for a particular abstraction overwhelms the user and is generally unnecessary, since many high-level operations can be composed from low-level ones. For this reason, we also suggest that classes and modules be primitive. Primitive operations are those that can be efficiently implemented only if given access to the underlying representation of the abstraction. Thus, adding an item to a set is primitive, because to implement this operation Add, the underlying representation must be visible. On the other hand, an operation adding four items to a set is not primitive, since this operation can be implemented just as efficiently upon the more primitive Add operation, without having access to the underlying representation. Of course, efficiency is also a subjective measure. An operation is indisputably primitive if we can implement it only through access to the underlying representation. An operation that could be implemented on top of existing primitive operations, but at the cost of significantly more computational resources, is also a candidate for inclusion as a primitive operation.

--- Grady Booch: Object Oriented Design with Application

僕が訳してみました．突っ込み歓迎．

十分であるとは，そのクラスやモジュールが意味のある効率的な相互作用をするのに十分な抽象化の特性を捉えていることを意味する．十分でなければ部品が役に立たなくなる．たとえばもし Set (集合)クラスを設計しているときに，集合から要素を削除する操作を加えることは賢明であるが，もし要素を追加する操作を無視してしまうと役に立たなくなる．実際には十分性に反することは早期に検出できる．そのような欠点はたいていこの抽象化を使う顧客から指摘される．

完全であるとは，そのクラスやモジュールのインタフェースがその抽象化の全ての意味のある特性を捉えていることを意味する．十分性が最小のインタフェースを意味するのに対し，完全なインタフェースはその抽象化の全ての観点をカバーする．その結果，完全なクラスやモジュールのインタフェースはあらゆる顧客が共通的に利用できるくらい十分一般的である．完全性は主観的な事柄であり，やりすぎになることもある．

多くのハイレベルな操作はローレベルな操作から構成することができるので， ある特定の抽象化に対して全ての意味のある操作を提供することは，ユーザーを困惑させ，一般には不必要である．この理由からクラスやモジュールがプリミティブであるということが導かれる．プリミティブな操作とは，その抽象化の基礎となる表現形式へのアクセスが与えられたときのみに，その操作が効率的に実装できることを意味する．その結果，集合に要素を加えることはプリミティブである．なぜならば，この操作 Add (追加)を実装することにより，その基礎となる操作は明らかになるからである．一方，集合に4つの要素を加える操作はプリミティブではない．なぜならば，この操作はよりプリミティブな操作 Add によって，基礎となる表現形式に対するアクセスをすることなく，効率的に実装できるからである．もちろん，効率性も主観的な尺度である．ある操作を基礎となる表現形式へのアクセスを通してのみ実装できるとき，その操作は議論の余地なくプリミティブである．あらゆる操作は，既存の最上位のプリミティブな操作で実装できるが，より多くの計算資源を犠牲にしてプリミティブな操作として包含する候補にもなる．

[Booch90] Grady Booch. Object Oriented Analysis and Design with Applications. Benjamin-Cummings Publishing Company, Subs of Addison Wesley Longman, Inc.
  

[SWEBOK2004]  英語版 

[Bus96] F. Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996. 

[Lis01] B. Liskov and J. Guttag, Program Development in Java: Abstraction, Specification, and Object-Oriented Design, Addison-Wesley, 2001.