ドラッカー「プロフェッショナルの条件」を読んで

後でちゃんとまとめます．ひとまず，Togetter を貼り付ける．

ADDIE モデル

教育の世界では，ADDIE モデルというのがあります．どんなものかを紹介します．

1. 分析(Analysis)
   
   
   
   1. インストラクションが解決策となるようなニーズを決定する．
   2. コースが対象とする認知的，情意的，運動技能的なゴールを決定する教授分析を実施する．
   3. 学習者の前提スキルと，そのいずれがコースでの学習に影響を与えるかを決定する．
   4. 利用可能な時間や，その時間にどの程度を達成できるかを分析する．
2. 設計(Design)
   
   
   1. コースの目標を行動目標や主要なコース目標(単元目標)に変換する．
   2. 取り上げるトピックと単元と，それぞれにどれだけの時間をかけるかを決定する．
   3. コース目標を考慮して単元を系列化する．
   4. 単元を具体化し，それぞれの単元において達成すべき主要な目標を特定する．
   5. それぞれの単元に対するレッスンと学習活動を定義する．
   6. 学習者が何を学んだかを評価するための指標を開発する．
3. 開発(Development)
   
   
   1. 学習活動と教材の種類について意思決定する．
   2. 教材や活動の草案を準備する．
   3. 対象とする学習者に教材や活動の試用を依頼する．
   4. 教材と活動を改善，精緻化，あるいは作成する．
   5. 教師の研修を実施し，付属教材を開発する．
4. 実施(Implementation)
   
   
   1. 教師や学習者に教材を採用してもらうために市場に出す．
   2. 必要に応じて支援を提供する．
5. 評価(Evaluation)
   
   
   1. 学習者評価の計画を実施する．
   2. プログラム評価の計画を実施する．
   3. コースの保守や改訂の計画を実施する．

なんか，ソフトウェア開発ライフサイクルみたいですね．

ADDIE では，特に分析のところで，教材開発者が答えるべき問いがいくつか設定されており，それらに答えることで分析を進めていきます．

次回から OOP 演習に関して ADDIE にしたがって整理して進めていこうと思います．

日本の進む道(Twitter での議論)

「下士官が優秀なのに将官がそうでもない日本の現状」の話から，「高等教育のあり方」さらには「研究の進め方」に発展．

抽象化とは何か？

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 のコメント

教材アーキテクチャ: 原理原則・ケーススタディ レイヤーモデル

ブログは久しぶりですね．第1学期の授業もついに始まってしまいました．でも今日は時間が取れたので，OOP演習の教材開発を再開したいと思います．

以前，OOP演習にスパイラルカリキュラムを適用することを提案しましたが，1つ問題があります．1枚岩で作ってしまうと，用いるケーススタディを変更したときに教材全体を開発し直す必要があるからです．毎年毎年同じケーススタディを行うのは飽きてしまうし，時代や学生さんの関心にケーススタディを合わせる必要があると考えられます．

そこでソフトウェアアーキテクチャの1つであるレイヤーアーキテクチャを適用することを考えました．

レイヤーアーキテクチャ(layered architecture)とは階層アーキテクチャともいい，全体を階層構造にすることで変化に対応させるときの変更箇所を最小限にしようという考え方です．レイヤーアーキテクチャでは，各層のインターフェースをきちんと定義し，下の層を基礎として利用することで，上の層の機能やサービスを実現します．そうすると，インターフェースを守っている限り，1つ1つの階層を入れ替えることが可能になります．

OOP演習では次のような階層構造を考えました．

原理原則層は，教授項目をそれぞれ独立に教材として提供します．たとえば抽象化を学習する教材を，簡単な例題を用いながら説明します．

一方，ケーススタディ層は，大きめの例題を開発し，原理原則層で提供される教材を使いながら，スパイラルカリキュラムを実現します．ケーススタディを入れ替えたとしても，原理原則層は再利用できるというわけです．

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

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.

スパイラルカリキュラム: 鈴木先生との議論

教材設計マニュアルの鈴木先生にOOP演習を見てもらいました．議論は多岐に渡り，たくさんのアドバイスとヒントをいただきました．改めて感謝します．

今回の記事では，鈴木先生からいただいた，OOP演習の核となるアイデアを紹介します．それが，スパイラルカリキュラムという考え方です．

話の発端は，以前「OOP演習で学ばせたいこと(2)」で紹介した学習目標(上図)を見せて，僕が「でもこの学習目標は，そのまま順番通りに教えるのではなく，例題を演習していくうちに，順番が前後しながら重要な学習目標が繰り返し登場して『ほらね，この原則は重要でしょ？』と定着を図りながらすすめていきたい」と言ったことから始まります．すると鈴木先生は「それは良い．それをやるならスパイラルカリキュラムだ！」とおっしゃいました．

僕の理解では，スパイラルカリキュラムは文字通り，まず基礎的な学習目標を一通り習得させ，その後らせん状に発展的な学習目標を習得していくモデルです(上図)．ポイントは1回目の学習では基礎的な学習目標やシチュエーションを厳選し，かつ例題の中でそれらの基礎的な学習目標で完結するように構成することです．2回目以降は，それに発展的な学習目標や例外的なシチュエーションなどを追加してレベルアップしていき，だんだん大きな例題に取り組めるようにしていきます．

例題の設定のしかたはさまざまです．

1. 例題そのものが1つのテーマに沿っていて，最初の例題を部品の一部として発展的な学習を進める方法．学習効率はいいのですが，一貫した適切な例題を考えるのが難しいです．
2. レベルアップするごとに，より複雑な例題に取り組む方法．学習目標に合わせて適切な例題を設定することができますが，例題そのものを理解する時間がかかり効率が悪くなります．
3. 上記の折衷案もあり得ます．たとえば5段のレベルを設ける場合，2,3個の例題を用意して，複数のレベルで例題を共有するなど．

具体的な例として，GDM (Graded Direct Method) による語学の学習を挙げていました．例えば英語だったら，学習中に日本語を含むその他の言語を一切使いません．そして毎回の授業で習う英語とジェスチャーで全ての会話が完結するように構成します．なんでも最初は You と I から始めるそうです．そして第3者が登場して he や she を学ぶ，という具合に発展していきます．面白いのが一般的に中学英語で割と最初に学ぶ "This is a pen." よりも先に "This is my pen." を学習するんだそうです．「これは僕のペンだ」「あれは君のペンだ」と会話をして，そこへひょっこり新たなペンを登場させます．「これは君のペンか？」「いいや」「これは僕のペンではない」ときて，そこで "This is a pen." と来るわけです．こうすると，不定冠詞 a の意味が自然と体感できます．

もう1つのしかけとして鈴木先生が提案したのが，ソフトウェア工学の原理・原則のありがたみを体感させるような構成にしたらどうだ，ということでした．先ほどの GDM の例でも不定冠詞がなぜ必要かを体感する例題になっていましたが，同様のことをOOP演習でもやるべきだというのです．具体的には最初のレベルでは，とにかくグチャグチャで構造化されていないコードでも，とにかく気合いでできてしまうような形にします．そして高度なレベルの例題にトライさせて，何か手立てを打たないとやってられないという気分にさせておいて，構造化を教えるわけです．

この話を受けて1つ思いついたのが，派生開発をやらせるとありがたみを実感できるだろうというアイデアです．似たような製品を開発させてみて「なんか似たようなコードが複数現れるよね，これを何とかまとめたい」と思わせるわけです．

そういう教材設計をするにはどうしたらいいかというと，次の点がポイントです．

1. 教えるべきそれぞれの学習項目に対してどういうシチュエーションでありがたみがあるかを具体的に考える．
2. 学習項目にレベル付けをしてグルーピングする．
3. 上記を考慮して具体例を順番に並べて教材化する．

これらのアイデアがもし実現できたら，それはかなり面白い教材になるでしょう．そう思うとワクワクしてきました！ 問題は，うまくフィットする題材を思いつくかですが，案ずるよりも産む方がやさしいかもしれません．まずはいろいろ手を動かして考えてみたいと思います．

追記: Twitter 上の反応はこちらです．