スクラム実践入門を読みました

最新自分のチームでスクラムをやっていることもあり、興味津々だったスクラム実践入門を読了しました。とても読みやすく、色々勉強になる本でしたので、読書メモ的なことを書いていきたいと思います。

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

ざっくりとした感想

大きな構成として

• 前半は「スクラムとは」みたいな感じで、スクラムのロール／イベント／作成物というようなスクラム開発の内容説明
• 後半は実際にスクラムを導入した事例やあるある話

という印象です

前半のスクラムの説明は、普段からスクラム開発をやっていることもあり、復習的な要素が強かったです。ただ、すごく丁寧に書かれている印象でしたので、これからスクラム始める方とかには、まさに「実践入門」という感じで役に立つ内容ではないかなと思います。

後半は猛者だらけそうな会社さんたちの導入事例でありながらも、最初は失敗したり、思考錯誤している様子が読めて、とても親近感を覚える内容でした。前半とは逆に、ある程度スクラムを始めてから読むと身に沁みる内容ではないかなと思います。

印象に残った内容を列挙していきます

やっぱりレトロスペクティブ大事ですよね

実際にスクラムをやっていて強く感じますが、ふりかえりを繰り返すことでチームが強くなっていくというのが、スクラムの大きな魅力の1つではないかと思います。

スプリントの期間を最初1ヶ月にしていたけど、長いから1週間にした、というような話も載っていましたが、スプリントの期間が1ヶ月になった時、プランニングが大変というのもあると思いますが、ふりかえりの回数が減ってしまうのが、一番のデメリットな気がしています。

完全に主観ですが、スクラムチームが鍛錬される前は1週間とか2週間の期間の方が、失敗しにくい（失敗してもふりかえりで立ち直っていける）気がしています。

スクラムに詳しい人が必要

「最初、本などで知識を得た後にスクラムをしたけど、失敗した」というような話もいくつかあった思います。失敗した後、認定スクラムマスター研修を受けたり、スクラムコーチを呼ぶことで、うまく回るようになった、という話が多いので、支えとなる人がいる状態で始める方が良いのだろうと思います。

私のチームの場合は、最初から認定スクラムマスター研修を受けた方がスクラムマスターをしていたので、導入がすごくスムーズだったな、と事例と比較して感じました。一方で、最初は「これ本当に必要なの？」とか「なぜこれをするの？」と戸惑うことも何度かありましたので、そういうときに、しっかりスクラムに詳しい人にスクラムとしての考えを聞いた上で、チームとしての結論を出せる、という状態にしておくことが大事だと思います。

プロダクトオーナーが難しい

各社の状況とか体制にも影響するとは思いますが、プロダクトオーナーのタスクが難しいなとつくづく感じます。

プロダクトオーナーはその先にステークホルダーがいますが、スクラムの外にいることが多いと思うので、一緒にふりかえりとかは出来ないことが多いのではないかと思っています（体制次第ですが）。しかも開発チームと違って、プロダクトオーナーは1人なので、知恵を寄せ合うことも出来ません。

プロダクトオーナーチームを作るとか、開発チームが支援するとか、いろいろやり方はあるかとは思いますが、今のところの個人的な印象として、開発チームと比べるとプロダクトオーナーやステークホルダーが成長していく速度の方が遅いと感じています。

プロダクトオーナーも、しっかりと認定プロダクトオーナー研修を受けて知識を持った状態で行えると違うのかもしれません。（身近にプロダクトオーナー研修を受けた人がいないので分からないのですが）

自分たちのチームとは違う

後半パートの失敗談や、あるある話の嵌まりやすい点を読んで、参考にはなるのですが、実際、自分たちのチームで経験したことはほとんどなかったです。それぐらいスクラムチームでやることはチームごとに違うのだろうと思います。（もちろんスクラムの奴隷にならない、とか共通して気をつけた方が良いことはあると思いますので、こうした失敗談は知っておくべきだとは思います）

個々人が集まって、話し合って、それぞれの考えとか意見を昇華していった先にスクラムチームの強さがあるとして、出来上がるものはチームごとに全然違うんだな、という印象を持っています。よそのチームのホワイトボードを見るのは、よそのお家の晩ご飯を見るような、大体同じだけど全然違う感じがあります。

本書でも少し触れられていましたが、私はまだスクラムチームのメンバーが入れ替わることを経験していないのですが、同じチームでも中の人が変わるとまた少し形が変わるんだろうな、と考えています。（同時に、元々のメンバーの文化でごり押ししないように注意も必要）

最後に

スクラムは人間心理みたいなところも考えて作られている、という話を聞いたことがあります。（嘘だったらすみません）

スクラムをやっていると、メンバー間の対話も増えて、すごく人間味のある開発をしているな、と思うことが多いです。人月とかみたいなドライな開発じゃなくて、人間らしい開発というか。なので、スクラムすごく楽しいです。

プロジェクトによって向き・不向きはあるのかもしれないですが、個人的にはスクラムがもっと広まって、楽しい開発が増えていけば良いなーという気持ちが強いです。

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

アジャイル宣言の12の原則に対する振り返りをやってみました

以前、Regional Scrum Gathering® Tokyo 2015で参加したワークショップからヒントを得て、アジャイル宣言の背後にある原則に対する振り返りを会社のチームで実施しましたので、その内容を簡単に記録したいと思います。

やったこと

12の原則を1つ1つ扱って、自分たちの行っていること(フローであったり、プラクティスであったり）の何が該当するのか、もしくは矛盾していないか、をチームメンバーでブレストしました

ちなみに、思っていたより大変で、1時間やって話せたのも4つだけでした。改めて真剣に考えると、自分たちの未熟さを痛感して、なかなか辛かったのですが、その分学びも多く、大変有意義でした。

話した内容

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

• 顧客ってプロダクトオーナーなのか？エンドユーザーなのか？
• ソフトウェアの価値って何なのか？（品質？MVP的なもの？）

顧客をエンドユーザーとした場合、顧客満足を最優先にするということは、プロダクトバックログの内容や優先度に対して、それを鵜呑みにするのではなく、それが顧客に対して価値のあるものなのか、という説明（証明）を開発チームとして求めていく、ということではないか

というような議論をしていました。

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

• スプリントの後期に要求が変更されたら、どうしてもイラッとしませんか？
• なぜ変更する必要があるのか、がちゃんと理解出来れば、歓迎できるかも

ここで言う「要求の変更」は、きっと、仕様がふわふわしてる、みたいな話ではなく、競合の動きとかで商品戦略が変わった上での仕様変更、のような、ちゃんとした理由のある要求の変更なんだろう、と解釈しました。

スプリントプランニングでがっつり計画を作っていたり、しっかり設計をやった後とかに要求が変わると、ついイラッとしてしまうのですが、なぜそのストーリーを実施するのか（=WHY)を忘れてはいけない、ということだろう、という議論をしていました。実装者が満足するために実装するのではなくて、顧客に対して価値を提供するために実装しているのですよ、ということかな、と。

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

• プランニングを通じて、大きすぎるタスクは着手前に対処できている
• できるだけ不透明なものを無くした状態でスプリントを開始すると良い

こちらは、生産性という点ではまだまだ改善はしていきたいものの、スプリントで決めたタスクを実施することで、達成出来ているな、という感想でした。とはいえ、SCRUMを開始した直後は、プランニングが甘くて辛い思いをしたことがあったので、プランニングをこれからも頑張りましょう、という感じで話をしていました

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

• 開発チームとしては、一緒に働けていると思っている
• プロダクトオーナーとしては、まだステークフォルダーを巻き込めていない

ここの内容は、社内体制にかなり影響を受けてしまっているのですが、現在、プロダクトオーナーが実際の最終ジャッジをする人の代理のような形で動いていることがあり、ここは改善していかなくては、という話をしていました。ただ、開発チームからするとインターフェースとしてのプロダクトオーナーはSCRUMにしっかりコミット出来ているので、仕事はしやすい、ということでした。

最後に

KPTや5Whysのような振り返りも大好きですが、この振り返りもかなりお薦めです。

アジャイルマニフェストの深さ、先人の偉大さを痛感しつつ、自分たちの行動を見直す良いきっかけになりましたので、残りの原則についても今後振り返りを実施していく予定です。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

Ruby技術者認定試験Goldに合格しました

この度、無事にゴールド聖闘士ことRuby Association Certified Ruby Programmer Gold version 2.1になることが出来ましたので、その記録を書きたいと思います。

今回書くこと

受験前の説明によりますと、問題の内容等々は秘密にしなくてはいけないようですので、具体的な試験内容については書けないのですが、その代わりに、どのような学習を行ったかを書いておきたいと思います。

参考書籍

メタプログラミングRuby

何度かこちらのBlogでも取り上げさせて頂いていますが、一番大きかったのは、「メタプログラミングRuby」でした

メタプログラミングRuby

クラスの継承とか、メソッド探索といった内容は、これを読めば大丈夫ではないかと思います。「selfが何か」みたいな話もこの本では手厚く説明されています。

Ruby公式資格教科書

Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応 (EXPERT EXPASS)

こちらの本も読みました。この本は、試験向けの内容で書かれてはいますが、分かりやすくて、単純にRubyを学ぶにも役に立つ本だなと感じました。（Rubyの資格自体がそういう目的なのだとは思いますが）

あと、模擬試験も付いているので、試験前に実力を測るのに役立ちました。（結局、問題演習はこの模擬試験しかやらなかったです）

Rubyアソシエーションビジネスセミナー試験案内講演資料(2014/10/8)

試験ページにリンクが貼られているこの資料です。

「メタプログラミングRuby」も「Ruby公式資格教科書」も試験対象となっている、Ruby2.1.x系には対応出来ていないため、こちらの資料で内容の補足をしました。

ただ、あまり、この資料自体は詳しい説明をしているものではないので、知らないものがあったら、irbだったり、るりまだったりで、掘り下げておくと良いと思います

---

改まってブログ記事にはしてみたものの、特別な情報にはあまりなっていないですね・・・

個人的な感想として、Silverに比べると、ひっかけや丸暗記と感じるような問題はあまり多くなく、メタプログラミングRubyとその他基本的な文法をしっかり理解しておけば、その場で解いて回答出来るような問題が多かったと思います。

なので、変に試験対策する必要はなく、上記の資料を通じてRubyを楽しむことで、自然と合格出来るのではないかと思います！（偉そうですみません）

メタプログラミングは念能力みたいに思えた

冬休みのシュクダイ

年末年始のお休みに突入するに際しまして、よちよち.rbの冬休みのシュクダイとして、メタプログラミングRubyを最後まで読んで当ブログに感想文を書くことを設定しました。

最初は、何日も休みがあるので余裕かなと思ってたんですが、結果、年末年始はイベント盛りだくさんで、もはや通常の土日の方が時間あるんじゃないのか、というレベルだったのですが、お休み最後の今日に何とか読み進めまして、ブログ記事を書く段階に至ることが出来ました。宣言するって大事ですね。機会を与えて頂いた、よちよち.rbに感謝です。

ただ、残念ながらまだ全部は読めておらず、第1部を読了しているだけなのですが、この時点でも充分内容は濃いので、良しとしています

メタプログラミングRuby

書くこと

メタプログラミングRubyの第1部は、第1章〜第6章で構成されていて（第6章はエピローグの1ページだけですが）、第1章の月曜日から始まって、第5章の金曜日まで、職場で先輩プログラマと初心者プログラマがメタプログラミングしていく物語になっています

これまで、月曜日（オブジェクトモデル）と火曜日（メソッド）は何回か読んでいたのですが、先に進めていませんでした。今回水曜日以降を読み進めてみて、月曜と火曜の話をさらに掘り下げるような話が繰り広げられて、大変ワクワクしました！

メタプログラミングというよりは、Rubyの仕組みなのかもしれないですが、驚きと凄さの連続に、たとえハンター試験に合格しても、これを知らないと本当のハンターにはなれないような気持ちになりました。改めて素晴らしい本ですね

各曜日それぞれに纏めていきたい気持ちもありますが、ボリュームがひどいことになるので、今回はその中でも木曜日（クラス定義）に書かれていた 特異クラス、特異メソッド について記述したいと思います

「特異クラス」という言葉の意味が分からない

「特異クラス」という言葉は聞いたことがあったのですが、特異？ってどんな状態なのか、全く想像出来てませんでした。正直、未だになぜ「特異」という日本語なのか良く分かっていません

「特異」を国語辞典で調べると

• 特別に他とちがっていること。また、そのさま。

普通のクラスとは違うよって意味ですかね・・・

原文ではどう書かれているのか

• （日本語）4.4.2 特異クラスの出現
• （英語）Singleton Classes

Singletonって「1個の」ってことですよね・・・

特異･･････なんだって？

こういうタイトルのコラムが書かれていました。英語はsingletonだったりeigenclassという表現だったりするようです。eigenclassは「オブジェクトそれ固有のクラス」という意味らしいです

自分なりの解釈

特異という言葉にはあまり深い意味はないのかな、と解釈しています

Class.ancestorsとかでは値として取得出来ないので、ちょっと違う、特異なクラスとして名付けられているだけで、実際の働きを教えてくれるような名前ではないのかなと思います

結構、「シングルトンクラス」と呼ばれていることも多い気もします

特異クラスとは

オブジェクトが裏に持っているクラス。意図的に表示させない限り、姿を現さないですが、オブジェクトの裏に出来てるみたいです

姿を確認するためには

obj = Object.new

eigenclass = class << obj
  self
end

とすれば良いと書いてありました。eigenclass.class => Classなので、特異クラスもクラスです

特異クラスの使い方

それで、特異クラスってどうやって使うのか、ということを理解するには、先に特異メソッドを定義してみるが良いと思います

特異メソッドの定義

これは、衝撃だったのですが、Rubyでは、

def (オブジェクト).(メソッド名)
  #  中身
end

という形で、そのオブジェクト固有のメソッドを定義出来ます

例えば、

greeting = 'hello'

def greeting.new_year
  'A Happy New Year'
end

greeting.new_year => "A Happy New Year"

というような形で、greetingの元々のクラスであるStringとは関係のないgreetingが固有に持つメソッドが定義出来るのです

月曜日の話との矛盾？

この特異メソッドの話を聞いて真っ先に思うのは、月曜日に学んだ

• オブジェクトは複数のインスタンス変数とクラスへのリンクで構成されている
• オブジェクトのメソッドはオブジェクトのクラスに住んでいる

という内容です。オブジェクトはメソッドを持たないって言ってたのに、オブジェクト固有でメソッドを定義出来るってどういうことなのか、と憤りました

特異クラスの登場

メタプログラミングRubyでは先に特異メソッドが出てきて、後から特異クラスが出てきたのですが、結局のところ、この特異メソッドを定義する場所が特異クラスだ、ということみたいですね

オブジェクトと常にセットで特異クラスがいるので、特異メソッドは特異クラスに定義されます。オブジェクトでメソッドを実行するときには、まず自分の特異クラスを見て、その後、自分のクラス、親クラスと継承チェーンを昇っていきます

先ほどの例でいけば、まず、greetingの特異クラスを見たあと、Stringクラス、Comparableモジュールと継承チェーンを昇っていくので、new_yearメソッドが実行できます

特異クラスの親クラス

もう1つ疑問があって、特異クラスの親クラスは何なのか、ということです。

答えは、メタプログラミングRubyに記載されていて、先ほどのgreetingの例でいけば、Stringクラスが親クラスになります。

これは分かるような分からないような。。。

月曜日の継承チェーンではオブジェクトから自分のクラスへは右に進んで、そこからsuperclassに向かって上に昇っていたので、特異クラスを考慮する場合には、右下に行ってから上に昇る形なんですかね・・・

メタプログラミングRubyでは、特異クラスを追加した後のメソッド探索の図も追加されていましたが、そこでは、すぐ右にオブジェクトの特異クラスがあって、そこからsuperclassに上がっていました。（右下には行ってなかったです）

オブジェクトの高さが所属しているクラスよりも低くなっているので、ちょっと月曜日の話と違ってくる気もするのですが、まあこれはこのまま理解すれば良いかなと思います。

※この部分、図が書けなくて、分かりにくい話になっている気がします

クラスメソッドについての理解が深まる

特異クラス、特異メソッドの基本的な定義方法が分かった後、クラスメソッドの話に突入すると、なるほどの連続でした

クラスメソッドはそのクラスの特異クラスが持つ

これもメタプログラミングRubyの序盤に話があった気がしますが

• クラスはClassクラスのオブジェクト（例えば、String.class => Class）

ということを思い出すと、クラスもオブジェクトなので、特異クラスが存在することが分かります。

さらに、何となく丸暗記していたクラスメソッドの定義方法を思い出すと

class Hoge
  def self.fuga
    # 中身
  end
end

だったり、

class Hoge
  class << self
    def fuga
      # 中身
    end
  end
end

だったりして、「あ、これHogeクラスのスコープの中で特異メソッド定義してる！」と気付きます。

クラスメソッドってクラスの特異メソッド（特異クラスが持つメソッド）だったんだな、と感涙します。Classクラスに定義するではなく、各オブジェクトごとに固有で使うメソッドなわけですよね。

クラスの特異クラスの親クラス

先ほどと同じ形で考えると、Hogeクラスの特異クラスの親クラスはClassクラスかな、と思ったのですが、そうではないようです（じゅげむじゅげむ）

Hogeクラスの特異クラスの親クラスは、Hogeクラスの親クラスの特異クラスになります

これも、継承チェーンを考えれば理解は出来ます。いきなりClassとか行かれたら不便ですし、親クラスの特異クラスが持つメソッドが継承出来るので。なんというか、そりゃそうですよね、という感じです。

モジュールのメソッドをクラスメソッドに

これも丸暗記していた部類ですが、モジュールで定義したメソッドをincludeするかextendするか、という違いも特異クラスが分かると理解が捗ります

例えば

module Fugafuga
  def fuga
    'Fuga'
  end
end

があったとして、何となく「クラスメソッドにするなら、extend」ぐらいに覚えてました

実際には、includeを使ってもクラスメソッドには出来て、

class Hoge
  class << self
    include Fugafuga
  end
end

というように、特異クラスを開いてそこにincludeすれば特異メソッドになります。

この作業を簡略にするために用意されているのがextendメソッドで、

class Hoge
  extend Fugafuga
end

Hoge.fuga => "Fuga"

と書くことが出来ます。includeはそのクラスに、extendはそのクラスの特異クラスに取り込むだと理解しました。なんとなく呪文のように覚えていたことが、腹落ちする瞬間でした。

年末年始の心残り

メタプログラミングRubyを最後まで読めなかったこともそうなのですが、メタプログラミングRubyの後にはRubyのしくみ -Ruby Under a Microscope-を読みたいと思っていて、年末年始で読むところまで行けなかったのが、大変残念です

メタプログラミングRubyを読んで、Rubyの仕組みには大変興味が強くなっていますので、出来るだけ早く取りかかりたいと思います（そしてその感想を当ブログに！）

Rubyのしくみ -Ruby Under a Microscope-

Seleniumで明示的に要素検索の待ち時間を設定する

この記事は　よちよち.rb Advent Calendar 2014　10日目の記事です。 9日目は5t111111さんによる審判の雷 Lightning Pickerでした。

自分の妄想を思わずアプリにしてしまうような人に私も成りたいです！

　今回書くこと

社内でSeleniumおじさんになることを目指して日々格闘していますので、その内容を記録したいと思います。

テーマとしては、「要素を探しにいく待ち時間について」です。

具体的には、データの入力を繰り返す処理をしている中で、データによって確認アラートが出るときと出ないときがあり、出るときは閉じたいのですが、出ているかの確認で要素（確認アラート）を探している時間がいちいち長かったので短くしたい、という内容になります。伝わりますかね・・・

ただ、短くしたいというのは、イレギュラーケースな気がしていまして（というかその目的の実現はあまり綺麗には出来ていないと反省中なので）、特定の処理だけ長く待ちたいとかに使うのが多いみたいです。そういう例が多かったです。画像重たいので、長めに待ちたい、とかですね。

ちなみに、Rubyはcapybaraを使うことが多いためなのか、selenium webdriverを使っているサンプルがあまり見つけられない気がします。Javaとかの例が多い気がします。私もcapybaraを使えば良い、ということかもしれません。

参考にしたもの

• APIリファレンス：Class: Selenium::WebDriver::Wait

• Selenium WebDriverのwaitを活用しよう

• 実践 Selenium WebDriver

実践 Selenium WebDriver

動作環境

• ruby 2.1.3
• selenium-webdriver 2.43.0

やり方

Selenium::WebDriver::Waitというクラスがあり、このクラスが持つuntilメソッドを使いました。 untilメソッドは引数にブロックを取り、ブロックの返り値がtrueになるまでブロックの処理を繰り返すようです。

Selenium::WebDriver::Waitのnewで待ち時間を設定出来るので、この待ち時間だけブロック処理を繰り返して、falseが続く場合には最後はタイムアウトエラーが発生します。

例えば、

wait = Selenium::WebDriver::Wait.new({timeout: 10})
wait.until do
  false
end

上記例では、ずっとfalseが返るので、10秒経過するとタイムアウトエラーになります。

APIリファレンスで、untilのソースを見てみると、

# File 'rb/lib/selenium/webdriver/common/wait.rb', line 33
def until(&blk)
  end_time = Time.now + @timeout
  last_error = nil

  until Time.now > end_time
    begin
      result = yield
      return result if result
    rescue *@ignored => last_error
      # swallowed
    end

    sleep @interval
  end
# 以下略

となってました。return result if resultとありますので、とにかくブロックの結果がtrue(truthy)ならそのまま結果を返してしまうみたいですね。逆に、繰り返すためには、ブロックの結果がfalseにならないといけないみたいです。

なので、私は、

wait = Selenium::WebDriver::Wait.new({timeout: 0.5})
begin
  wait.until do
    begin
      # 要素があったら実行するよという処理
    rescue
      false
    end
  end
rescue
  # タイムアウトは揉み消す
end

のような形で、処理短縮を目指しました。（この場合、最初の処理の時間が長かったら意味がないと思いますが） ちょっとゴリゴリ感が否めないので、きっともっと良い書き方があるのではと模索中です。

---

明日のよちよち.rb Advent Calendar 2014は、waterlow さんの「私のよちよち.rb活用法」です！気になるタイトルですね～

実際にクロアゲハを育てる時に役立つ情報を書きます

ブログタイトルにふさわしい記事を書きたい

久しぶりに記事を書いたのをきっかけに、当ブログの管理ページを見ていたところ、ブログを更新出来ていない間も多少なりとも流入があったことが分かりました。Google先生のお力ですね。

その観点で考えると、当ブログの名前は「クロアゲハの育て方」なので、Google検索で「クロアゲハ　育て方」と調べるとやはり1ページ目に出てきてしまうのですが、書いている内容は主にRuby関連になっていますので、そうしたキーワードからの流入に対しては、必要と思われる情報を掲載出来ていないと思います。

一方で、実際にクロアゲハを飼ってはいましたので、1つぐらい本当にクロアゲハを育てるときに役立つ情報も書いてみようと思います。

前置き

注意事項（大事）

特に専門家というわけではなく、クロアゲハを飼ったことがある、という経験だけによる内容になりますので、正確性に欠ける部分があるかもしれません。ただ、飼うときには、情報が見つけられなかったり、色々心配になると思うので、そういう時の参考になれば幸いです。

何故クロアゲハを飼育したのか

元々我が家では（というよりは私の妻が）、ナミアゲハを中心に、「卵を保護し→羽化させて→外に放つ」サイクルをよく行っているのですが、このクロアゲハは羽化した状態ではちゃんと飛ぶことが出来なかったのと、おそらくタイミングとして外が寒くなってしまったことが重なったために、まったく外に飛んで行ってくれなかったため、家で飼育することにしました。

ちなみに、ネットで見ると羽化してから大体2週間ぐらいが寿命みたいなのですが、我が家のクロアゲハは10月頃に羽化してから翌年の3月まで生きていました。

クロアゲハとナミアゲハは飼い方が違うのか

「クロアゲハ」と限定はしていますが、「ナミアゲハ」と違いはあるのか、というのが最初に出てくる疑問かと思います。

種類が違うので、もちろん違いはあるのですが、大きくは違いはないと思います。ただ、青虫のときに食べられる葉っぱに違いがあるなど、注意が必要なところもあります。

具体的な内容

卵が孵るまで

卵は蜜柑や檸檬、柚などの柑橘系の樹木の葉っぱ、特に茎付近に産み付けられていることが多いみたいです。我が家の場合は蜜柑でした。

卵は容器に入れて待っていれば、（2〜3日ぐらい？で）孵るのですが、誰かに食べられてしまったり、孵った後に動いてどこかに行ってしまったりする心配があるので、蓋が不織布になっているケースがお薦めです。

我が家ではこのシリーズを使っています。（サイズが色々あるので、好みのものを）

コバエシャッター【小】フタ・本体 ［シーラケース］

たくさん飼う場合には、他の幼虫とも一緒にしない方が良いです。

黒虫時代

卵から孵ると黒い3〜4ミリぐらいの幼虫になります。鳥のフンに擬態して身を守っているみたいで、鳥のフンみたいにも見えます。クロアゲハはナミアゲハと違って、ちょっと濡れた感じがするのが特徴です。

この時は、餌としては柑橘類の葉っぱ（我が家は蜜柑でした）を食べるのですが、硬いと食べられないので、新芽など、出来るだけ柔らかいものを与えると良いと思います。

なお、 今後葉っぱを与える時に共通する注意事項なのですが、葉っぱにはヤドリバエなどの寄生昆虫の卵が付いていることがあり、それを食べてしまうと大変な悲劇を招くことになってしまいますので、葉っぱを与える前には、濡れたティッシュやコットンなどで葉っぱを1枚1枚丁寧に拭くようにしましょう。（ヤドリバエに寄生された時の悲劇については、悲しくなるのでここでは割愛します）

この期間に何度も脱皮して、自分の皮を食べつつ、青虫になっていきます。脱皮する前には動きが鈍くなりますが、元気が無くなったわけではないので、心配しないようにしましょう。

青虫時代

青虫になると、だいぶ大きくなって、黒虫のときよりは硬い葉っぱも食べられるようになります。

ただ、食べる量がめちゃくちゃ増えるので、食料の確保が大変です。動く範囲も広がるので、あまり小さい容器だとかわいそうかもしれません。

我が家では、葉っぱ単位で与えるのでなく、葉っぱがたくさんついた枝ごと入れて、枯れないように水を含んだコットンを枝に付けて、それをアルミホイルで巻いて固定していました。葉っぱが増えても、ちゃんと葉っぱを拭くのは怠らないようにしましょう。

ちなみに、この時期は一番触りやすくて、餌をモリモリ食べるところも見れるので、かわいい盛りです。

あとは、食べる分、排泄物も激増するので、清潔な状態を保てるように掃除も行いましょう。

蛹になる直前時期

ある日急に便が水っぽくなるときがあります。これは、蛹になる準備を始めている段階で、体の中の水分を抜いているために起こっているようです。

そうなると、蛹になる場所を探して、かなり動き回るようになります。それをサポートするために、容器の中に、割り箸などで足場を作ってあげると良いでしょう。容器だけでも蛹になったりはするのですが、（思った以上に無茶な場所で蛹になったりします）安定しないで落ちたりしてしまうこともあるので、そういう悲劇を産まないようにちゃんとした足場を作りましょう。

蛹は、最終的には、自力で生み出す糸によって、お尻と頭（肩あたり）が枝と固定された状態になります。容器の中に斜めに割り箸などを立てかけておくと良いでしょう。

なお、蛹になろうとしているときは、非常にデリケートなタイミングなので、 絶対に触ったりはしないようにしましょう。 （少なくとも蛹になって2〜3日経過するまでは触らないようにしましょう）

もし蛹になろうとして落ちてしまった場合には、この時にも基本的には触らず、弾力を持たせたティッシュなど柔らかなところに、出来るだけそっと置いて、あとは蛹になるのを待つようにしてください。実は我が家も蛹になるタイミングで失敗してしまい、この対応を行いました。枝に付けるのは後で出来るので、ちゃんと蛹になるまで4〜5日待ってから、動かすようにしましょう。

ちゃんと蛹になったら、枝に付けてあげます。蛹を横にして、最終的なポーズを意識する感じで、木工用ボンド（瞬間接着剤などはNG）で枝に付けてあげます。貼り付けてすぐに持ち上げても重力に負けてしまうので、しばらくは横にしておいて、しっかり固定されるのを待ちましょう。この時、蛹のお腹側には呼吸用に穴がいくつか空いているので、それを塞がないように貼り付けることが大事です。

蛹時代

蛹になって、ちゃんとポーズがとれたら、あとは羽化を待つのみです。ちなみに、クロアゲハはナミアゲハよりは蛹の期間が長いです。

幼虫時代にヤドリバエに寄生されていると、蛹時代にやられてしまうので、無事に羽化するかはかなりドキドキしながら待つことになります。（この時にちゃんと自信を持てるように、幼虫時代にはしっかり葉っぱを拭いておきましょう！！）

羽化するのは、日の光に合わせて朝が多いみたいですが、我が家は部屋で飼育していたので、夜中に羽化しました。

蝶になってから

羽化を世話するのも自然の摂理から考えればあまり良くないかもしれませんが、我が家の場合には基本的には蝶になったら、外に飛び立ってもらってます。（このタイミングを面倒を見る分岐点にしています）

なので、この後はあまり説明するべきではないかもしれませんが、飼育する必要が発生した場合の参考情報として記載していきます。

餌は、ポカリを水で1：1ぐらいに薄めたものをコットンに付けて与えていました。コットンの上に乗せると飲んでくれることがあります。平和に飲んでくれれば、それが一番なのですが、飲んでくれないことも多々あるので、その時には、爪楊枝などで、口を伸ばしてあげて、コットンにつけると最終的には飲んでくれます。飲んでくれるまでは結構時間がかかるので、餌を与えるのは大変です。

餌を与えた後は、完全に我が家の場合はですが、軽く運動して、排泄をさせていました。ちゃんと飛べないまでも多少は飛ぶことが出来たので、羽をバタバタさせる感じです。照明とか制御出来ないところに行かないように注意が必要かと思います。

飼育ケースは、段ボールを改造して、多少広さのあるスペースを作っていました。（天井がネットになっている箱を作りました）

あとは、明るいと羽を動かし続けてしまい羽を痛めたりしてしまうので、暗いところに連れていくと大人しくなってくれます。（この辺りは室内だと制御出来てしまうことが、逆にかわいそうな気持ちにもなるので、やはり自然で暮らす方が良いなと思います）

最後に飼育しようと思っている方へ

生き物を飼うこと全般の話かとは思いますが、蝶を飼うことは結構大変です。ある程度羽化を経験していても、何が起きているか分からなかったり、羽化させてあげられないこともしばしばあります。それなりの覚悟を持って飼育を始めて頂ければと思います。

2014年に読んだり積んだりした本とその思い出を振り返ります

この記事は　よちよち.rb Advent Calendar 2014　7日目の記事です。 6日目はドアラ将軍こと@ohtsuka_tさんによる俺のよちよちrbヒストリーでした。

ドアラ将軍はよちよち.rbにおいて本家に負けないぐらいのマスコット性を発揮されている一方で、私のvim師匠でして、第22.5回のもくもく会でunite.vim等々のプラグインの使い方を教えて頂いたのが思い出深いです。

今回書くこと

@5t111111さん、@ohtsuka_tさんと、おもしろい力作が続いているので、プレッシャーは感じつつ、上がったハードルを下げるべく、あまり捻らず、2014年読んだ本や増やした積読（=これから読みたい本）を徒然と書いていきたいと思います。

Ruby/Rails関連

パーフェクトRuby

パーフェクトRuby (PERFECT SERIES 6)

序盤の言語仕様的な内容も大変参考になるのですが、Rubyを書いていて分からないことや深堀したい内容のリファレンスとして大変お世話になっています。この本のおかげで初めてgemを作ったりも出来ました。電子書籍版も買おうかな。。

メタプログラミングRuby

メタプログラミングRuby

今年はRuby技術者認定試験Silverが取得でき、何とか今年中にGoldの受験もしたいと思っているのですが、そのためにも読みたい本です。まだ途中までしか読めていないのですが、すでにめちゃくちゃ勉強になっています。「メタプログラミング」という名前がいかつくて警戒されがちですが、説明も丁寧だと思いますし、Rubyを勉強し始めた方には強くお薦めする1冊です。（そういえば、前によちよちbeerで2冊目にお薦めの本ですよね、みたいな話もしていました）

Rails3レシピブック 190の技

Rails3レシピブック 190の技

よちよち.rbでは毎週日曜朝8時という大変ストイックな時間からオンライン読書会を行っていまして、そちらで扱っている本です。私はRubyに比べるとRailsの知識・経験が浅いため、この本の内容は（レシピブックだけに）とても具体的で、体系的な学習を補う、経験に近いような学習が出来て良いです。Rails3なので、バージョンとしては古いのですが、そのために「え、こんなよく使いそうな内容もRails4では変わってるの？？」みたいな、Railsの歴史疑似体験みたいなことが出来るのも個人的には楽しい要素です。

パーフェクトRuby on Rails

パーフェクト Ruby on Rails

発売後すぐ買ったものの、ちょっと読んだ後止まってしまっています。2015年には必ず読みます・・・

チーム開発関連

普段の仕事はマネージメントが中心なので、今年は、開発フローやチーム作りみたいなことも良く考えていました。

Team Geek

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

QiitaやKobitoを作る開発チームの文化というBlogを読んで、「HRT」を学びたくて読みました。この本の内容も大変参考になったのに加えて、幸いにもこのBlogを書かれたyaottiさんとお話する機会があり、とても勉強になりました。

WHYから始めよ！

ＷＨＹから始めよ！―インスパイア型リーダーはここが違う

常々、何か行動をするのにモチベーションはとても大切な要素だと思っているのですが、モチベーションアップにとても参考になる本です。機能とかメリットといった「what」ではなく、なぜそれが必要なのかという「why」が大事という話です。「サービスとは」とか「仕事とは」のような大きな話から、ちょっとした会話や説明にも役立つような、基礎的で大事な話を学べて、個人的にかなりのヒットでした。

その他

Webを支える技術

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

こちらもよちよち.rbでオンライン読書会の教材として使用させて頂いている本です。一度は読んでいるのですが、理解が浅いので改めて読み直したいと思っています。

また、よちよち.rbのつながりで、同じくこの本を教材とするRESTful#とは勉強会に参加した際、ゲストとして著者の@yoheiさんがいらっしゃっていて、その後の懇親会でお話させて頂きました。

その時に勢いで、持っていたWebを支える技術に、サインを頂いたのですが、コードがあまり書けていない体たらくな私に「コード書けよ」というメッセージを頂いた時が、今年最もやる気が出た瞬間でした。ありがたい限りです。

最後に

気付けば、かなり有名な本ばかりを紹介してしまいましたが、それはそれで悪くないということにしたいと思います。

振り返ってみると、よちよちの影響はかなり大きく、また、単に本の内容だけではなく、本がきっかけとなった、いろんな人との思い出要素が強いなと気付きました。今までは本当に読むだけだったので、この違いが一番大きいのかもしれないです。

よちよち.rb Advent Calendar 2014、明日は、トミーこと@ta1kt0meさんによる「rspec3におけるexpectとallowの違い」の記事です！