HEAVEN INSITE's Blog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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


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

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

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



上のソースコードをこんな感じで自動的に描画してくれる。素敵。


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

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();
}
}

コンパイル例


リバースエンジニアリング

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このように、司書教諭は、児童生徒が適切に学校図書館を利用し、実りのある学習ができるようにするため、児童生徒の発達段階に応じて、さまざまな学習機会を提供し、指導していかなければならない。
また、その際に、学校図書館が「多様なメディアを媒介として先人の知識に触れることができる場であり、自分自身で学ぶ場、学び方を身につけていくための場」であることを児童生徒や教員に積極的に伝えていかなければならない。

　今月中にやらなければならないシステム設計の課題が20％くらいしか終わっていないのに、何を血迷ったかヘビと戯れに行きました。


　ヘビのヘビによるヘビのための施設。


　しかし、このアオダイショウは可愛すぎるだろ！20年ぶりくらいにアオダイショウくんに触ったけど、相変わらずこのヘビは大人しいよね。これが同じく毒のないシマヘビとかだと力いっぱい抗ってくるもん。


　有料（￥1000）で首に巻いて記念撮影ができるボアコンストリクター。


　温室の二階に何故か存在する（そして長らく放置されている気がする）昭和の図鑑感漂う生き物の歴史コーナー。恐竜が鳥類ではなく冷血の爬虫類代表というイメージがあった頃、ヘビとセットでぶち込んだれって感じで作ったのだろうか。模型の痛みが非常に激しくトリケラトプス角とれてます。作り直す際は私に是非連絡をください。


　あっあそこにチュー太郎がいるぞ！ってチャットの友達みたいに言ってるけど、多分チュー太郎の運命はあまり芳しくないだろう。


　昔の研究で使ってたらしい旧型のオートクレーブ。ほかにもヘビ毒に含まれるタンパク質を大きさ別に分別する分光光度計などもありました。


　キングコブラってこんなにでかいのか！さすが王者！でかいのに毒って怖すぎる。毒って基本的に弱小の動物が最後の切り札的に持っているイメージあるからね。ハサミを持つ巨大なサソリには毒がないらしいし。


　ちょっと入浴感のあるニシキヘビの標本。


　ヘビ料理が食べられるというレストランの不穏な注意書。


　なかがわ水遊園のピラルクー料理の時と同じく、ドナルドのダブルバーガーを中途半端な時間に食べてしまったためにお腹一杯で断念・゜・(つД｀)・゜・わりと値が張るし、万全のコンディションの時に賞味してみたい。


　ヤマカガシの特別展。ヤマカガシは地域ごとにカラーバリエーションが豊富なために素人がうかつに判断してさわると危険だという内容。私も知らずに触っていたのかも…
　特に顔がシマヘビと似てるので、無毒なシマヘビだと思って触ってた可能性あるぞ、怖～（また昔の図鑑ではヤマカガシは毒ヘビと書かれていなかった）。


　ヤマカガシは珍しいタイプの毒ヘビで、頭の後ろの首からも、餌のヒキガエル由来の毒液を噴射するという。これは怖い。というのも、ヘビって首と頭の付け根を掴んじゃえば無力化するというイメージがあるからね。それを見越した上でのエボリューションということか。まったく侮れねえ。


　定時に行われるハブの採毒ショー。ショーなのかわからないけど(^_^;)イケメンのお兄さんが華麗なヘビさばきでワイングラスのような容器に毒を採取。
　というか、ハブって二本の牙のうち一本でも欠けると毒液って出せないのね。知らなかった・・・


　毒ヘビは基本的に大人しく臆病だが、好奇心の強い人間（ちびっこ）などがよせばいいのに触りにいってしまうために毎年ひどい目にあっているらしい（特にヘビは頭を触られると機嫌が悪くなる）。
　あとは、キノコ採りの時にヘビがいるのを知らずに手を伸ばしちゃって噛まれるってのも多いらしいよね。これはネイチャージモンが言ってたんだけど。
　いずれにせよ、小さい頃から野生のヘビにバンバン手を出していた私。己の無知を反省せねばならぬ。