システム設計演習覚え書き④

 とりあえず必修課題は全て終わりました・・・!\(^o^)/

 とはいえ、試験の加点対象になるオマケの課題がまだ9個あって、そのうち3個はできたんだけど、残り6個は仮想マシンで動かさなきゃいけないやつで、この仮想マシンが私の家のネット環境だとオーバーテクノロジーで、まあ、止まる止まる。ぷーあらあら(どせいさん)。みたいな。
 で、調べてみたら、オマケを3問やってたった1点の加点ということで、まあ、諦めて(え)、今日の午後は、来月中旬のテスト勉強をしてました。
 でも、まあ、残りの6問も気持ちが悪いから、今度気が向いたらネットカフェとかに行ってやってみるかもしれない。

 それでは、今までのシステム設計の一ヶ月ちょいの軌跡を振り返ってみましょう。

クラスとインスタンス
クラス図とインスタンス図はデザインがそっくりなので、インスタンスの名前の部分には必ず下線をつけて区別する!
課題2-2ー2.jpg

継承
どちらが一般的で、どちらが特殊かを考える。
例えば、正方形は特殊な長方形なので、包含記号を使うと「長方形⊃正方形」となる。論理記号の矢印のデザインは⇒で、クラス図の矢印はチビ太のおでんのようなデザインなのに注意。
課題2-4.jpg

ポリモーフィズム
同じ呼び方(メッセージ)の操作で異なる動作をさせること。
例えば、一から作るのではなく、既存のシステムの操作をすこし修正=上書き(オーバーライド)すれば事足りそうな場合など。

抽象クラス
抽象クラスには実態がないため、例えば「図形」という抽象クラスがあった場合、その具体例であるインスタンスは作れない。
これが、「長方形」や「楕円」などの具体的な図形のクラスではいろいろなインスタンス(いろいろな形の長方形や楕円)が作れる。
課題6-2発展4.jpg

関連
多重度が重要。アスタリスクのマークは任意の数。
頻出する関連パターンは「モノ」-「コト」ー「コト」で、多重度は「1対*」「*対1」が多い。

特にこの問題が危険。
生徒にとっては、受講できる科目は最大10科目なので、0..10となる。
講義科目にとっては、受講する生徒の数は最大20人なので0..20となる。
課題3-4.jpg

依存
依存を示す矢印は点線で、さきっちょは^で、黒い三角形▲ではないのに注意。
依存するクラスは変更できるが、依存される側を変えると、そいつに依存している奴にも影響が及ぶ。
課題3-7.jpg

コンポジション関連
販売伝票の情報から、明細というクラスを作りデータを分ける。
販売伝票に共通するデータは「日時」「支店名」「合計金額」なので、これらは販売伝票のクラスに残す。
それ以外の何を何個買ったかのデータ「商品名」「単価」「数量」「金額」は、明細のクラスに送る。
課題3-8.jpg

実装
依存はさきっちょが^の点線の矢印だったが、実装はさきっちょが△の点線の矢印。
そういや、実習課題で実装の矢印ってあんまり使わなかった気がする。
課題3-9.jpg

パッケージ図
関連性の高いデータや操作は一つのパッケージに入れてしまう。
例えば、「マグロ」「カンパチ」「ヒラメ」などのデータは「寿司ネタ」というパッケージに入れるとわかりやすい。
また、パッケージ内のデータは可視性の設定によって、表示・非表示が可能。非表示設定にすると、そのデータは他のパッケージから見えなくなる。
表示は+のマーク、非表示は~なので注意。
課題4-1.jpg

シーケンス図
課題を進めるにつれ最終的にすごい複雑になった奴。
例えばこれ。
課題12ー4ー2.jpg
ちなみに、シーケンス図の作成には、まずクラス図(設計図)を作成しなければならない。
また、あるクラスの処理は、そのクラスを指すメッセージの矢印によって行われるのに注意(逆に言うとメッセージの矢印に書かれている操作内容は、矢印が刺さっているクラスが持っている!)。
さらに、同期メッセージの矢印の先っちょは▲、非同期メッセージの矢印の先っちょは^なのも注意する(これを混同すると実行仕様=活性区間を示す縦長の四角形が連動して勝手に大きくなっちゃう)。

要件定義
要件定義は、顧客と開発者の共同作業で考える。
まず現状を分析し、顧客からシステム要求を聞き、それを元に開発者が分析結果(要件定義書)を提示して、共通理解を図る。
顧客は、依頼者やエンドユーザのことで、これがステークホルダーになると、もう少し広く、開発側も含まれる。
要件定義のうち、必ず搭載すべき機能は機能要件と呼ばれるが、反応速度といったユーザビリティや、故障しにくいといった信頼性、セキュリティなど、顧客の要件にはない機能(性能)である非機能要件が昨今取りざたされている。これは要件定義書に明記されてはいないため、限られた時間と資金の中、顧客の気持ちをどれだけ忖度できるかが、顧客の満足度を高めるという。

ユースケース図
ユーザの要求に、どのようにシステムが対応するかを示す図のこと。
従って、まずアクターを抽出しなければならない。
例えば、コンビニのレジシステムの場合、それを扱うアクターはレジ係と店長(店長もレジは使えるから)であり、お客さんではない。

以下は、学生が図書館で本を借りる際のユースケース図。
なお、「氏名と本のタイトルを確認する」の手順のように、「本を借りる」ときにも「本を返す」ときにも行われるようなものは、〈〈include〉〉の矢印で指し示す。
課題8-1.jpg

ER図
マイクル・クライトン先生の緊急救命室ではない。
エンティティ・リレーションシップ・ダイアグラムの略。
エンティティとは実体とか概念のことで、複数の対象物を共通のカテゴリーでまとめた四角形と考えて良い。
これはUMLでいうクラスに相当するため、クラス図をER図に変換することができる。
課題10-4.jpg

クラス図との違いは、クラス名(エンティティ名)が四角形の外に追いやられ、1段目のマスにはRDBSのように主キーが入ること。
さらに、「学生」や「本」のように一意(ユニーク)に求められるものは親エンティティ、「貸出」のように様々なパターンがあるものは子エンティティと呼ばれる。

これら親子をつなぐ多重度のマークも覚えなければならない。
鳥の足(クロウズ・フット)のマークは複数という意味。
|は1つ、○は0つ、エンティティにつながっているという意味。
ちなみに|と○を合体させると0か1という意味。
また、子エンティティが親エンティティに依存している場合、子エンティティの四角形の角は丸くなる。
課題10-4.jpg

システム設計演習覚え書き③

 最近気が向いて順調に攻略中のシステム設計。残る必修課題は12個。なんとか今月中にいけそうだ!やれば出来る子!!

参考文献:内山俊郎著『わかりやすい情報システムの設計――UML/Javaを用いた演習』

開発プロセス
情報システムの開発プロセスには、大きく二つの方法がある。
順番に手順を完了させるウォーターフォール型と、部分的なリリースを繰り返して完成度を上げていく反復型である。
この二大派閥は、どちらが優れていて、どちらが劣っていると、決めつけることはできず、また、仮に反復型が優れていたとしても、明日から反復型にします!と簡単に切り替えられない現実的な問題もある。

ウォーターフォール型
要件定義→設計→実装と、滝が流れるように順次処理をする。
滝の水が逆流しないように、プロセスは後戻りしない。
そのため、事前に綿密な計画(いつまでに何を作るか、コストの見積はいくらか)を立てる。基本的に手順のルールがしっかりと決まっている。
開発期間は数ヶ月~数年で、もちろん最終目標(スコープ=何を作るか)は変わらない。

メリット
生産性が高い。要件定義を終えれば設計を一気に進められる(中断が少ない)。
全体的な予算見積もりが早期に出る。

デメリット
対応力が低い。プロセスの初期で要件定義を終えているので、その後変更が必要になっても路線変更が難しい。実際は手順を戻ることになるが、それもできずに手遅れになることもある。
工程によってメンバーが替わるため(バトンタッチする)、引き継ぎ業務(ドキュメント作成など)が必要。

反復(イテレーション)型
非ウォーターフォール型とも呼ばれる。
システムを機能面などで小分けにし、それぞれに開発期間(1~4週間ほどの短いもの)を設ける。つまり、各開発期間で分割されたシステムの開発(全アクティビティの実行)を行う。
全体の計画は概略的。開発規模の見積もりが固まり出すのは、プロジェクト期間の10~20%が終わるくらい。つまり、定額契約が難しい。
ルールよりもエンジニアの経験がものをいうため、開発の進め方は彼らの経験とともに変わり、常に向上していく。
2000年頃普及しだしたイメージがあるが、古くには、50年代のX15極超音速ジェット機の開発、60年代のNASAにおけるマーキュリー計画、72年のトライデント潜水艦命令制御システムの開発、77~80年のスペースシャトルの第1航空電子ソフトウェアシステムの開発などの例がある。
その後、アメリカ国防省はウォーターフォール型の開発を推奨したが、失敗事例(先端技術開発では開発要求がリアルタイムで進化していってしまうため)を見て、87年の勧告では早くも反復型の推奨に戻している。

メリット
対応力が高い。いつでも軌道修正が可能。
例えば、ある機能をせっかく開発したのに結局使わなかったというような開発の無駄をなくせる。
システムを小単位ごとに分割するため開発期間が短縮できる。
工程が変わってもメンバーが替わらないため引き継ぎが不要で、また前行程での経験がチームのノウハウとして蓄積していく。

デメリット
生産性が低い(作業を途中で中断することが容易なため)。
全体的な予算の見積もりが不明確な状態でスタートするため、請負型契約(完成した仕事に報酬を支払う契約)が困難。同様に、企業の規模が大きいと予算管理部門が反復開発を採用しない。

アジャイル開発
アジャイルとは俊敏という意味(・・・もしかしてアジャコングって俊敏なゴリラっていう意味!?)。
アジャイルソフトウェア開発宣言(01年にユタ州に集まった17人のプログラマーやエンジニアが行なった宣言)と、全12項目のアジャイル原則を指針とする、反復型開発プロセスである。

アジャイル宣言
プロセスやツールよりも・・・個人と相互作用
包括的なドキュメントよりも・・・動くソフトウェア
契約交渉よりも・・・顧客との協調
計画に従うよりも・・・変化に対応すること

これは、左側の言い分にも価値はあるが、それよりも右側を重視するということである。
「個人と相互作用」からは、まず開発者が満足することが持続可能な開発において必要であることが、「顧客との協調」「変化に対応すること」からは、顧客やエンドユーザからのフィードバックを受け入れることや、コミュニケーションを重視している(スクラム開発)ことがわかる。
また、アジャイル開発には上手くいく方法の中で最もシンプルなものを選べという考え方も盛り込まれている。

スクラム(Scrum)
人命に関わるシステムの設計にも用いられているアジャイル開発の中で最も有名な手法。
ラグビーのスクラムのように、開発チームのメンバー(なぜかブタと呼ばれる)同士がコミュニケーションをよく取り合い、足並みをそろえて開発を行なう。

例えば、毎朝立ちながら20分程度のミーティング(スクラムミーティング)をするなど、反復ごとに自分たちで立案した計画を自分たちで精査する。
そのため、チームの人数は3~10人くらいに抑える(人数が多いとコミュニケーションが難しくなり、チームとしての一体感も希薄化するため)。

ちなみに、反復の途中ではメンバー以外の利害関係者が作業を追加してはならない。つまり、部外者(なぜかニワトリと呼ばれる)は口をはさまない。チームの自律性を重んじるのである。

スクラムミーティングの内容としては以下のものがある。
①前回のスクラム以降何を行ったか?
②今から次のスクラムまでに何を行うか?
③反復の目的を達成する上での障害は何か?
④スプリントバックログ(チームが当たるタスクの待ち行列のこと)に追加するタスクはあるか?
⑤チームメンバーから刺激を得て、何か新しく学んだことはあったか?

エクストリーム・プログラミング(XP)
小規模プロジェクトを素早く成功させることに特化した方法(反復期間は1~2週間)。
開発途中の仕様変更や設定変更にも勇気をもって柔軟に対応する。
プログラマー中心主義と言ってもよく、バディムービーのようにタッグを組んでプログラミングをするペアプログラミングなど面白い考え方がある。
XPが独特な点は、プログラムコードとテスト以外には成果物を要求しない点である。
他のアジャイル開発では、目前の反復の計画くらいは立てるが、XPではドキュメント作成を極力減らすため、そういったものすら作らない(ただし、ホワイトボードにタスクリストくらいは書く)。

システム設計演習覚え書き②

 今月中に全ての課題をこなせるのか、いよいよ厳しくなってきました。C言語よりも必修課題の数が膨大なんだよな。唯一の救いは、講義の先生が優しくて手順を丁寧に教えてくれるところだね。
 でも、javaでプログラミングする第5講あたりから、まずもってjavaがやれる環境を準備するのが大変で、ソフトウェアとか3つくらい必要だし、そこでかなり労力を使っちまったよ。

シーケンス図
あるシステムの処理において、それぞれのオブジェクトがどのように協調・影響し合うかを、時間軸に沿って説明する図。
各オブジェクトの関係はコミュニケーション図という図でも表せるが、その場合時間経過は表現できない。
課題4-2シーケンス図.jpg

ステートマシン図
図書館にある本の状態(書架にある・貸し出し中)など、システムの振る舞いを記述するための図。開始状態を黒い丸、状態は角が丸い枠で表す。
課題4-3.jpg

アクティビティ図
動的な処理の流れを表現できる図で、フローチャートに似ている。
条件判断や並列処理を表現する際に用いられる。
処理全体の流れをおおまかに表現したい場合はアクティビティ図、もう少し個々の相互作用のディティールも表現したい場合はシーケンス図など、使い分けが大切らしい。

各ノードは次のとおり。
開始ノード:黒い丸。システムの開始を表す。
ディシジョンノード:菱形。分岐点を表す。
マージノード:菱形。集合点を表す。
フォークノード:太い横線。並列処理の開始を表す。
ジョインノード:太い横線。並列処理の終了を表す。
終了ノード:黒い二重丸。システムの終了を表す。

また、「顧客」「店員」「店長」のように、アクションをする人や組織ごとに、アクションのグループ分けをすることができる(アクティビティ・パーティション)。
課題4-5.jpg

javaプログラミング演習
事前にJDK(ジャヴァ・デベロップメント・キット)というソフトウェアをダウンロードしたあと、システムのプロパティのコーナーにある「環境変数の設定」の「path」にJDKがダウンロードされた所在地のアドレス(ただしセミコロン;とbinで挟む!!)を追加する。
さらにjEditというソフトウェアもダウンロードするのだが、拡張子がマックでしか通用しないタイプ(.dmg)で、開くのに結構手間がかかる(´;ω;`)
この準備が終わったら、どこでもいいので、ある任意のフォルダを作って、そのフォルダに課題のソースコードのファイルをぶち込む。
次に課題が入ったファイルをマウスポインタで選択したあと、シフトキーを押しながら右クリックをすると、コマンドウィンドウをここで開くという、通常出てこない選択肢が出てくる。
これを選ぶと、選択したフォルダ(ディレクトリ)のコマンド入力画面が出てくるので、ここで、jEdit ソースコード名 と半角で入力する。これで、ウィンドウズのソースコード入力ツールであるjEditの入力画面に飛んでくれる。
ちなみに、OSがリナックスだとgeditという別のエディタになる。

メソッド
javaの世界では操作はメソッドと呼ばれる。"main"というメソッドだけは、コマンドウィンドウから起動および実行できる。

astah* professionalとの関連
すごい便利なのが、クラス図などの描画ソフト「アスタープロフェッショナル」でjavaのソースコードが読み込めるという点。javaのコードをそのまま図に変換してくれる。
手順は、「ツール」→「java」→「javaソースコードの読み込み」→好きなファイルを選択→図にしたいデータを候補リストから選択リストに移す→「了解」

課題5-3.jpg

上のソースコードをこんな感じで自動的に描画してくれる。素敵。
課題5-3クラス図.jpg

リバースエンジニアリング
設計書からプログラムを作ることをフォワードエンジニアリングというが、それの逆。
つまりプログラムから設計書を作ること。

javaで作図をする
懐かしのプログラミング基礎が思い出されずにはいられない課題。
特に、楕円とか二等辺三角形の数式が激ムズ。
ただ思ったのは、C言語って汎用性が高いなというか、文法はほとんどCもjavaも変わらないのねっていう。

図形の設定コード(Figure)
abstract class Figure{
final double PAratio = 0.45; // 画素のアスペクト比
final String Pixel = "@"; // 図形は@の集合として描けという意味
abstract void draw();
abstract String getNote();
void draw_w_Note(){
draw(); // ←描画は文章の前に描き出させる
System.out.println("上記の図形は,"+getNote());
}
}

直角三角形の作図コード(TyokkakuTriangle)
class TyokkakuTriangle extends Figure{
private double width; // 直角三角形の幅
private double height; // 直角三角形の高さ
TyokkakuTriangle( double width, double height ){
this.width = width;
this.height = height;
}
void draw() {
for( double i = 0 ; i < height ; i++ ){
for( double j = 0 ; j < width/PAratio ; j++ ){
double x = (j + 0.5)*PAratio;
double y = height - 0.5 - i;
double equation = y + height/width*x - height;
if( equation <=0 ) System.out.print(Pixel);
else System.out.print(' ');

}
System.out.println();
}
}
String getNote(){
return "底辺、高さが(" + this.width + ", " + this.height+ ")の直角三角形"; }
}

二等辺三角形の作図コード(NitouhennTriangle)
class NitouhennTriangle extends Figure{
private double width; // 二等辺三角形の幅
private double height; // 二等辺三角形の高さ
NitouhennTriangle( double width, double height ){
this.width = width;
this.height = height;
}
void draw() {
for( double i = 0 ; i < height ; i++ ){
for( double j = 0 ; j < width/PAratio ;j++ ){
double x = (j + 0.5) * PAratio;
double y = height - 0.5 - i;
double equation1 = y + 2.0*height/width*x - 2.0*height;
double equation2 = y - 2.0*height/width*x;
if( equation1 <=0 && equation2 <=0 ) System.out.print(Pixel);
else System.out.print(' ');

}
System.out.println();
}
}
String getNote(){
return "底辺、高さが(" + this.width + ", " + this.height+ ")の二等辺三角形"; }
}

図形の呼び出しコード(FigureTester)
このソースをコマンドプロンプトでコンパイルすると全部引っ張り出される。
ちなみに、コンパイルの仕方は「javac FigureTester.java」→「java FigureTester」でOK。

class FigureTester{
public static void main(String[] args){
TyokkakuTriangle myTyokkakuTriangle = new TyokkakuTriangle(5,10);
myTyokkakuTriangle.draw_w_Note();
NitouhennTriangle myNitouhennTriangle = new NitouhennTriangle(19,15);
myNitouhennTriangle.draw_w_Note();
}
}

コンパイル例
課題6-2発展3.jpg

リバースエンジニアリング
課題6-2発展4.jpg

ヒトラーを欺いた黄色い星

 「面白い度☆☆☆ 好き度☆☆☆」

 ユダヤ人を嫌うことと、ユダヤ人をガス室で殺すことは違う。

 vicさんお勧め映画。
 ナチス政権下では、ドイツに住むユダヤ人は全員ゲシュタポに捕まって強制収容所送りになったイメージがあるけど、ベルリンとかに終戦までけっこう潜伏してたよっていう話。
 実際にベルリンに潜伏した四人のユダヤ人の証言がついていて、わりとドキュメンタリー映画だった。NHKスペシャル的な。
 当たり前だけど全てのドイツ人がユダヤ人を迫害したわけではない。市井の人々だけではなく、なんと高級官僚や、ドイツ軍の将校ですらユダヤ人を匿ってくれた人がたくさんいた、と。
 ドイツ人将校のお屋敷なんかパーティであんなに軍人がいるのに、そこで働く家政婦がユダヤ人だと気づかない!
 ドイツの軍人「黒い瞳だな、ユダヤ人かね?」ユダヤ人家政婦「ユダヤ人は絶滅したのでは?」一同爆笑「わっはっは!」おしまい(^_^;)わからねーのかっていうw
 実際、民族的とか人種的なレベルではユダヤ人ってのはいなくて、ユダヤ教信者=ユダヤ人なわけだろう。
 これは本当に、オタク狩りみたいなもんで、例えば、仮に第二次世界大戦でユダヤ人を物理的に根絶したとしても、その後、再びユダヤ教が評価されて、信者さんがついちゃったら、ユダヤ人は復活するってことになるわけだから、どだい無理がある計画ではあるんだよな。だからさ、もうどう考えても、当時の八つ当たりなわけで。
 でもさ、こういう、ユダヤ人を救ってくれたドイツ人がいたよっていう事実をユダヤの人たちの方から証言してくれるのは本当にありがたいよね。おのれドイツ人!みたいに憎悪だけになっちゃうと、こうはいかないし、そいで、ドイツ人の方から、ユダヤ人匿ったドイツ人だっていたんだぞ感謝しろ、みたいに言うのも、ちょっとまずいじゃない。

 そういえば、こういうユダヤ人迫害映画の邦題ってだいたい『ヒトラーのうんちゃら』って付けられることが多いけど、ヒトラーをかばうわけじゃないけどさ、これってちょっとどうなんだろうというか、すべてのドイツ人がユダヤ人を迫害したわけじゃないのと同様に、すべてのドイツ人がユダヤ人迫害に反対したわけじゃないわけであってさ。
 それをさもいい感じにヒトラーを悪のシンボルにしてスケープゴートというか、ナチスドイツの所業をこの人に全部押し付けちゃえ的なことにしちゃうと、また同じことが起きるぞというか、まあ、実際に起きつつあってさ、そういう懸念はあるよ。
 だから『ヒトラーの忘れもの』も、『ドイツの忘れもの』だとちょっと衝撃的すぎるなら、『ナチスの忘れもの』くらいでよかったんじゃないかとかね。
 というか、『ヒトラーの忘れもの』も『ヒトラーを欺いた黄色い星』も、原題はヒトラーってついてないしな。
 つまりヒトラーに全部押し付けちゃえっていうのは、日本の配給会社の思惑なのかもね。ドラえもんの映画じゃないんだからさって思うよな。『ヒトラーの大魔境』とか。『ヒトラーの鉄人兵団』とか。
 多分さ、今後こういう悪のシンボルにされそうなのが、トランプさんなんだろうけど、これもさ、トランプさんに投票したアメリカ人はたくさんいるわけでさ。
 内心(やべえ、投票する奴間違えた!)って思っても、まあいいや、全部トランプに騙されたってことにしようとかやってる限り、同じ過ちを繰り返すよね。

学習指導と学校図書館覚え書き

 最近一気に寒くなりましたよね。システム設計、スネークセンターに行った日からまったく進んでおりません。システム設計うつのようです。うかうかしてると、来月になって図書館の試験とバッティングしちゃうしな・・・いやはや。

 あ、あと近況報告ということで、この前、お酒が飲める友達と行きつけのタコス屋さんに夜中行ったんだけど、そこで友達がマニアックなスコッチウィスキーをオーダーしたら、ビンテージ酒マニアのオヤジさんのハートに火をつけたらしく、カウンター脇から出るわ出るわの骨董品。戦前のお酒とかも出てきて、なんでも蒸留酒は何百年経っても飲めるんだって。
 というか、コレクターなんだよな。ラベルの。確かにすごい昔のお酒のラベルって手書き感があって可愛くて、集めたくなるのも分かる。なんというか、ロートレックのポスターみたいなおしゃれさがある。だが、あの数は尋常じゃなく、変態性がある(^_^;)
 しかし、お酒って瓶だからね。大地震だと粉々になりそうだし、火事が起きたらアルコールなわけでファイアーしちゃうし・・・保管が大変そうだなあ。

学校図書館の変遷
学校図書館は戦前にすでに存在はしていたが(明治 35年に京都の生祥 尋常高等小学校に児童文庫が設置されている)、日本において学校図書館が法により制度化されたのは第二次大戦後のことである。

アメリカ占領下の48年に文部省から刊行された『学校図書館の手引き』によって学校図書館の重要性が啓蒙され、同時に日本十進分類法の採用も明記された。

50年には民間の団体である全国学校図書館協議会が結成、経費の公費支弁や専任司書の配置を掲げた。この運動目標はやがて司書任務を持つ教諭である司書教諭を配置するという内容に転換する。

そして53年、学校図書館法が成立したが、「当分の間、司書教諭を置かないことができる」という附則がつき、これが日本の学校図書館発展を妨げる元凶となった。
つまり、「人がいない本の倉庫」が学校図書館の現実となった。

これに対し、専任司書教諭を配置する先進的な自治体が登場したが、学校図書館運営の業務に専念する司書教諭に対する現場の理解不足もあり、70年代までに専任司書教諭の採用は高知県を除いて行われなくなった。

さらに戦後のベビーブームとそれに伴う受験競争の激化で、学校図書館は多くの子どもたちにとって受験勉強の場となる。

ただし、1997年になると学校図書館法の一部が改正され、政令により12学級以上の学校に司書教諭は必置となり、司書教諭の発令が飛躍的に進んだ。しかし小規模な学校では司書教諭は任意設置のままで現在に至っている。

さて、学校図書館をめぐっては、近年、社会の情報化の進展とともに、さまざまな措置が講じられ、その発展に向けた取り組みが進んでいる。
特に、児童生徒が自ら必要な情報を取捨選択し、活用する能力の育成が叫ばれると同時に、児童生徒の読書離れが指摘され、学校図書館に求められる役割は一層大きくなっている。
なら、専任の司書を採用すればいいのに。

学校図書館の機能
現在の学校図書館には3つの機能が期待されている。
まず、児童生徒の想像力を培い、学習に対する興味・関心等を呼び起こし、豊かな心や人間性、 教養、創造力等を育む自由な読書活動や読書指導の場である読書センターとしての機能である。

次に、児童生徒の自発的・主体的な学習活動を支援したり、授業の内容を豊かにしてその理解を深めたりする学習センターとしての機能である。

最後に、児童生徒や教員の情報ニーズに対応したり、児童生徒の情報の収集・選択・活用能力を育成したりする情報センターとしての機能である。

さらにチーム学校の一環として、学校図書館に求められる三つの機能を発揮することで、学校と家庭と地域を結びつけ、地域の児童生徒の読書活動を推進していく中心としての役割も期待されている。

学校図書館の教育的目標(人格陶冶と情報リテラシーおよび主体的な情報活用能力)は、児童生徒の「生きる力」の育成に直結するものであり、さらには生涯学習の基盤形成にもつながるものである。そのために、学校図書館の設備や機能を充実させる必要があるのである。

司書教諭の役割
現在の学校図書館は、主体的な学びの場、その学び方を提案する場であるとともに、教科の学習に対応した資料を収集・管理している場であり、その様々な資料とその使い方についての専門家が司書教諭である。

つまり、司書教諭は、学校図書館の専門的職務を司る有資格者として、学校図書館の経営に関する総括、学校経営方針・計画に基づいた学校図書館を活用した教育活動の企画・実施、年間読書指導計画・年間情報活用指導計画の立案をする。
また、学校図書館を活用した授業を実践し、その教育指導法や情報活用能力の育成などについて積極的にほかの教員にアドバイスをすることで、司書教諭が専門職であることを全教職員に認識してもらう。

重複するが、学校図書館には、大きくは「読書センター」「学習センター」「情報センター」 という3つの機能があり、司書教諭の役割や職務はこれらの機能が目指すべき目的に沿って行なわれる。

まず読書センターとしてであるが、これは学校図書館を、児童生徒が主体的かつ自由に楽しい読書を行う場とすることを目標とするため、児童生徒がリラックスして利用できる環境整備を行うとともに、学校における読書活動の推進と、読解力の育成のための取り組みを、学校図書館の担当職員と協力して行うことが求められる。

次に学習センターとしてである。
学校図書館は、学校における教育課程の展開に寄与することが求められるため、当該学校の教育課程の内容を理解することに努め、授業のねらいに沿った資料を教員と相談して決定することや、日常的に教員と学校図書館の利用や活用についての情報共有を行い、積極的にコミュニケーションをとることが求められる。
また、学校図書館を利用する授業ではティームティーチングの一員として学習を指導する。

最後に情報センターとしてである。
情報化社会を生きていくための情報活用能力を児童生徒に育成するため、図書館資料を活用して児童生徒や教員のニーズに対応するとともに、児童生徒に対する情報活用能力育成を目的とした指導が円滑に行われるように、必要な教材や機器、授業講師について教員と事前の打ち合わせを行うことも大切である。

このように、司書教諭は、児童生徒が適切に学校図書館を利用し、実りのある学習ができるようにするため、児童生徒の発達段階に応じて、さまざまな学習機会を提供し、指導していかなければならない。
また、その際に、学校図書館が「多様なメディアを媒介として先人の知識に触れることができる場であり、自分自身で学ぶ場、学び方を身につけていくための場」であることを児童生徒や教員に積極的に伝えていかなければならない。
Calendar
<< July 2020 >>
SunMonTueWedThuFriSat
   1234
567891011
12131415161718
19202122232425
262728293031
search this site.
tags
archives
recent comment
recent trackback
others
にほんブログ村 科学ブログへ にほんブログ村 科学ブログ 恐竜へ カウンター
admin
  • 管理者ページ
  • 記事を書く
  • ログアウト

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273