コンピュータやソフトウェアのあれこれ＠道民（＆元道民）
workshop
第11回北海道情報セキュリティ勉強会に参加しました
5月 21st
5月18日（土）に開催された、第11回北海道情報セキュリティ勉強会（せきゅぽろ）に参加しました。
今回のテーマは「クラウドのセキュリティ」。
当日朝まで参加を迷っていたのですが（寝だめしたくて…）、セキュリティについての根本的なところの話が聞け、参加して良かったと思えました。
セキュリティとは科学である
株式会社ディアイティの河野省⼆さんがいらっしゃり、3部構成でセキュリティのお話を聞きました。
- 情報セキュリティの現場力・使えるスキルと⼈材像
- クラウドサービスにおけるセキュリティ
- 最近のいろいろなセキュリティの話題
「情報セキュリティは目的ではなく手段である」「ISMSを取得するための情報セキュリティ対策ではなく、真に会社に必要な対策を考えるべき」「利用者の意識を向上させるのではなく、システムで何ができるかを考えるべき」・・・などなど、出てくることが目から鱗の言葉ばかりでした。
特に今まで勘違いしていた（というかそういうもんだと思っていた）ことで、ハッとなったのは次の3つ。
- 社で許可されたUSB以外の外部メディアをPCに接続するのを禁止するのはウィルスが入り込まないようにするため？
→ 否。ウィルスからの保護はウィルスソフトがやればいい。本来の目的は残存データが漏れないようにするため
（USB上のデータは初期化しても消しきれない、復元できる可能性がある） - 大事な書類をメールに添付する危うさ
→ 上司があるファイルに必要事項を入力して返信するよう、5人の部下に書類を添付してメールを出したとする。
この場合最終的に、マスタファイル（1）、上司の送信フォルダ(1)、各部下の受信フォルダ（5）、各部下のマシン（5）、各部下の送信フォルダ（5）、上司の受信フォルダ（5）、上司のマシン（5）合計27ファイル、つまり26ファイルものデータコピーができる。
データコピーができればできるほど、漏洩のリスクが高まるわけなので、共有サーバーやクラウドの利用などで適切に管理するべき。 - メールで重要書類を送る時は、ファイルを圧縮して暗号化し、送信メールとは別便でパスワードを送りましょう
→ 別便でパスワードを送ることに何の意味もない。だって同じNW上じゃない？POPメールなら1つのデータになることもあるよ。（金庫を盗まれた道を鍵を持って歩くようなもの。泥棒は待ち伏せしているだけでよい。）
この場合、パスワードはメール以外の手段で伝えたり、送り先と共通の認識（相手先の会社の電話番号など）をパスワードにするよう取り決めておく方が有効。
どれもやっていることだなあと。しかも何も疑問に思っていなかった。
特に2番目。クラウドなど外部にデータを預けることは危険・禁止となる風潮が多いけれど、ファイルが大量にコピーされるという脆弱性がメールにはあるのだということを恥ずかしながら意識したことがなかったなあ。
適切にログが取れて、管理権限も調整できる共有サーバーやクラウドの方が脆弱性は少ないのですね。
禁止は何も生み出さない
「○○してはいけない」というルールを生み出すことが情報セキュリティではない。これも目から鱗。
どうしても「あれもできない」「これもできない」「これも禁止された」「セキュリティって面倒」となってしまう事が多いので…。
これは「情報活用のための情報セキュリティ」について考えられていないから。
ISMS取得のためであれば、禁止を増やし続ければよいのだろうけれど、新しい事をはじめる・次の時代の事を考えるときに禁止は足かせにしかならない（「一つでも禁止事項があればそれに足を引っ張られて新しい事が導入できない」）。
「してはいけない からの脱却」のために、正しい知識を持った情報セキュリティマネジメントができる人が必要なのですね。（SSCPという資格があるよ！）
クラウドのセキュリティ
「クラウドを利用してリスクがないわけがないじゃないか、でも、リスクがあるからと言って利用を禁止するのはもっと馬鹿」
という最初の言葉が印象的でした。
大事な事は「免疫力を高める」こと（風邪をひくからどこへも行かない？体力つけてどこかへ出かける方がよくない？）。
そのためにはクラウドの特徴を知って、メリットデメリットをきちんと把握する事が大切。
どのようなリスクマネジメントをするかは、その会社・組織に応じた適切な方法や範囲を選択する事になる。
だから資料を参考にしてどーんとは決めきれない事も多い。
そのために中小企業向けのチェックリストなどを作って配布しているようです。
また、ガイドラインは参考程度にとどめておく事も重要。ガイドラインを丸写ししてもリスク対策はできない（「知識を集約するだけではよいものは作れない」）、現場に合わせて息を吹き込む事が大事。
この辺りはプロジェクトマネジメントなどとも似ているなあと思いました。
どちらも人間が関わる、組織によって文化的背景が違う、生のもの。
最近のセキュリティ色々
興味深かったことを箇条書きに。（3部は力尽きていてメモも少なかった・・・）
- アンチウイルスソリューション
クラウド型(ソーシャル型)であれば、ゼロデイ攻撃にも対応できる可能性があるかも？！集合知。 - 標的型攻撃の判定にクラウドを使う
クラウド型(ソーシャル型)であれば、自社が狙われているのか皆狙われているかわかる。 - 結局スマートフォンもガラパゴス化している
Androidのバージョンだけじゃなく、各機種にデフォルトアプリが色々入ってるー。 - スマートフォン対策が大変だけど重要になる
クラウド系のアプリってブラウザだけじゃなくAPIもあるよね？つまりAPIやアプリのレベルでの対策を講じる必要がある。
技術が高度になった分、その辺りの対策は大事になる。
—-
自分のメモ＋当日配布いただいた資料で思い出しながら書いてみました。
こうやって、まとめてみると濃いですね。
冒頭に書いたセキュリティについての意識、これが変わったのが一番大きいです。
普段の行動の目的を考える事ができるようになった。
例示がわかりやすい
全体を通して、途中途中で出てくる例示がとてもわかりやすかったです。
例えば
「今財布の中に入っているお金が1円／10円／100円／1000円単位でわかる人？」（それぞれに手を挙げる）
「お財布の中身を1000円単位でしか把握できていない人は10円、100円がなくなってもたぶん気がつきません」
「＝セキュリティを高めるには、きちんと管理できている事が重要になります。」
という例。なるほどー！！と思いました。
おやつ
和菓子、和菓子たっぷり。
お団子も柔らかくて素敵でしたが、ここの豆大福、美味！
IT勉強会スタンプラリー
全国規模で行われている勉強会のスタンプラリー、IT勉強会スタンプラリーにせきゅぽろが参加している、ということで、記念すべき1つ目のスタンプを押しました。
北海道では、せきゅぽろ、CLR/H、LOCAL PHP部がスタンプ対象の勉強会です。
「違う勉強会に3回」か「同じ勉強会に3回」で何かもらえるみたいです。
行ったことのない勉強会ばかりだけど、スタンプを押すために参加してみようかなぁ。
面白そうな内容の勉強会があったら飛び込んでみよう、と思いました。
2012年3月31日から1年間で始まっているこの試み、次回はもっと北海道でも参加する勉強会が増えたら上位を狙えて楽しいですね！
実践アジャイルテスト読書会06 に参加しました
5月 21st
5月15日（火）に行われた、実践アジャイルテスト読書会06 に参加しました。
あっという間に2回お休みしていてびっくりした。
前々回は業務多忙で参加できず、前回はゴールデンウィーク中の開催だったため札幌にいませんでした。
（このブログを書く前になんとか休みの範囲も読み終えました。読書会があって良かった。）
気を取り直しての参加です。
今回からいよいよテストについての章に入りました。
テストの目的ごとに分類した「アジャイルテストの4象限」についての話がメインです。
アジャイルテストの4象限
テストの目的を
- チームを支援する⇔製品を批評する
- 技術面⇔ビジネス面
という2つの側面から分類し、4つに分けた物がアジャイルテストの4象限になります。
それぞれの特徴が書かれていたのをざくっとまとめてみる。
第1象限
（チームを支援する・技術面）
単体テスト。主にTDDなどで作ることになるテスト。コードに対するテスト。
コードの品質を高める、プログラマのためのテスト。
基本的にテスト実行は自動化されてなければいけない。
第2象限
（チームを支援する・ビジネス面）
機能テスト。ストーリーに対するテスト。第1象限より粒度が大きくなり、1つ1つがビジネス的な意味のかたまりになる。
ストーリーの開発が完了することを保証する、開発チームのためのテスト。
継続的ビルドの対象として自動化されているべき。
第3象限
（製品を批評する・ビジネス面）
ソフトウェアが顧客の求めるものになっているかをテストする。
ユーザー受け入れテスト、ユーザビリティテスト、探索的テスト。
創造能力と直感力が必要になる、基本的に手動で行われるテスト。
※これは実際にテストの質を（数値的に）保証するのが難しいテストだね、という話が出ました。
第4象限
（製品を批評する・技術面）
パフォーマンス、堅牢性、セキュリティなどの評価を行うテスト。
非機能要求テスト。専用のツールを使用してテストする。
アジャイルテストの4象限をチームにどのように適用するか
もちろん、全ての象限のテストを十分に実行できることが望ましいのですが、それが叶わない場合もある（時間や予算）。
その時に、何を選んでいくべきかという話。
大事なことは
「ストーリーごとに検討する前にやらないという選択をするのではなく、
全ての象限のテストについて検討した後にやらないことを決める」
こと。そのためには全象限のテストに関するスキルは必要。
また、ここで「（必要なのはわかっているけれど）やらない」という選択をするということは、技術的な負債を積み上げることになるわけです。
実際に負債が積上っていった経験談などを交えて、どうするのがよいのかなあという話をしました。
製品を長期にわたって開発、メンテナンスするかなどとの兼ね合いも考えないといけない。
コンテキストのテスト
「それぞれの組織、製品、そしてチームはそれぞれの状況があり、それぞれ必要なことがある」ということを忘れてはいけない。
コンテキスト（組織、製品、チームの流れや空気、慣習のようなもの？）意識したテスト設計が必要。
この章はなるほどなあと思いました。
製品に対するテストを機械的に行うだけではなく、プロジェクトやチームメンバーのことを考えたテストを作っていこう、とする気持ちも大事なのですね。
導入部分の読書会に参加できて良かったです。
次回からはそれぞれの象限のテストを掘り下げていきます。参加できますように！
第20回アジャイルサムライ読書会 @札幌道場 開催
5月 10th
5月8日（火）、第20回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は6名。14章 TDD（テスト駆動開発）がテーマです。
ページ数が少ないので15章に入れるかなーなんて思ったけれど、関連することを話し合っていたらあっという間に時間は過ぎるものですね。
充実した時間となりました。
今回の範囲で「グっときた」ところ
意図を伝えるためにテストを書く
勉強会として
TDDはTDDBCが札幌で何度も開催されているのもあり、プラクティスとしてはかなり浸透していると思います（業務で実践できているかはともかく）。
実際に実践している人も多く、ディスカッションではTDDを実践する時の悩みや壁など具体的な問題についての話がたくさん出てきました。
特に繰り返し出てきた話題としては
- テストコードの品質を上げたい
- TDDを適用しづらい部分がある
- テストコードを書く技術がないとTDDは難しい
このあたりでした。
TDDは設計手法かどうか
本書では「TDDは設計手法として実にうまい方法じゃないか」と書かれていますが、TDDは「設計手法」として本当に有用なのかどうかという話も盛り上がりました。
- TDDを実践すれば良い設計のコードが書ける
ではなく
- TDDを実践し続けることで良い設計の仕方が身に付く・設計力が上がる
ではないかという話になりました。
TDDを実践すればすぐにうまい設計ができるわけではなく、TDDは設計の力を上げるのによい訓練方法であるという考えは忘れないようにしたいです。繰り返し身につけていくことが大事ですね。
実際に体験してみて感じるのは、ちょっとTDDをやらなくなると一気に力が落ちること。
継続していかないとすぐに衰えてしまう気がします。
TDDとBDD
「TDDとBDDの根本的な違いって何？」という話も出てきました。
色々な解釈はあるのですが
- TDD: テストコードを書くタイミングと設計するタイミングが同じ => インターフェースを決めないとテストが書けない
- BDD: 最初に振る舞い（ストーリー）だけを考え、その後コードを書く => ソースコードを書くまでにワンクッションある
という区別の仕方がしっくり来ました。
そしてその分類で考えると、RSpecはどちらかというとTDD寄りのテスティングフレームワークなのかなーという話になりました。
BDDとしても使うことができるけど（テストが自然な文章になっているから）、検証したい目的からするとTDD用のフレームワークなのかなぁと。
RSpecのサイトには以下のように書いてありました。
—–
RSpec is testing tool for the Ruby programming language. Born under the banner of Behaviour-Driven Development, it is designed to make Test-Driven Development a productive and enjoyable experience with features.
—–
(RSpecはBDDの旗印のもとに生まれたテストツールであり、TDDが生産的で楽しい経験となるような特徴を持つよう設計されています） — 翻訳はirasally
RSpecよりもさらにBDDに特化したテスティングフレームワークがCucumberであるという位置づけの理解です。
詳しいディスカッションの内容はwikiを見ていただきたいと思います。
運営の立場で
いやー、20回ですよ、20回。
途中で挫折せず、読書会を20回続けてこれたということに驚きつつほっとしています。
（20回で本書が終わっていないというのはおいておく）
これも、各回に皆様が時間を見つけて参加してくださっているからこそです。感謝。
残りあと数回ですが、ラストスパート、良い時間となるようにしていきたいと思います。
今回のディスカッションは以下のページにまとめてあります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120508
いつも会場を提供していただいている弊社、今回もありがとうございます。
残り数回ですが、よろしくお願いします。
Head First JavaScript読書会 06に参加しました
5月 10th
5月7日（月）に開催されたHead First JavaScript読書会 06に参加しました。
GW明けの月曜日というハードな日程でしたが、無事、乗り切ることができました。
今回はFormのバリデーションと正規表現についてです。
Formのバリデーション
Formとは何ぞや？というところから、httpリクエストの話、httpメソッドの種類(GET, POST, PUT, DELETE, OPTIONなど)について一通りざくっとおさらいしました。
その後、Formデータの取得の仕方、バリデーションが大事な理由などについて話しました。
バリデーションの意義について、313ページには「本当に検討なアプリケーションになるとサーバー上でもデータ検証を行います」と書いてあるけれど、安全のためにはむしろサーバーサイドでデータ検証を行うべきだよなあという話をしました。
何度もサーバーとやり取りをするのもイライラするからちょっとした入力ミスを防ぐことができるよう、Javascriptの制御を入れておく、本当のデータチェックはサーバーサイドでやる、のが良い形なんじゃないだろうか。
安全のためのチェックはサーバー上で行い、クライアントサイドのバリデーションはユーザービリティ向上のために行う、というように目的を分けるという観点はとてもしっくりきました。
正規表現
本書では
- 必須チェックをしたい
- 桁数チェックもしたい
- 数字以外は入力してほしくない
- メールアドレスの形式じゃないものは受け付けたくない
というように、バリデーションのケースがだんだん複雑になってきたところで、正規表現が登場しました。
（よりによって、メールアドレスの正規表現を例に出さなくてもという話はちょっとでましたが）
Javascriptの正規表現は//で囲んで書きます。
"Hello World".match(/^\w{5}\s\w{5}$/)
---
[ 'Hello World', //マッチした
index: 0,
input: 'Hello World' ]
"Hello World".match(/^\w{7}\s\d{5}$/)
---
null // マッチしない場合はnullが返る
グルーピングは()で行うことができます
"Hello World".match(/^(\w{5})\s(\w{5})$/)
---
[ 'Hello World', // マッチした文字列
'Hello', // グループ1番目
'World', // グループ2番目
index: 0,
input: 'Hello World' ]
match関数ではなくRegExpオブジェクトを生成することもできます。
本書では自動的に生成されたRegExpオブジェクトを使う方法が載っていました。
var regex = /^\d{5}/
regex.test("12345")
正規表現はとても便利で、ある程度はできるようになっておきたいし、読めるようにしておきたい。
便利さを感じるようになってから読んだり書いたりを積極的にするようになった。
（正規表現使うたびにgoogleで量化子やメタ文字のリファレンスを探しているので、まだまだですが）
だけど、使いすぎると自分自身も後からメンテナンスが辛くなってくることがあるから、どこまで厳密にチェックするかも含めてさじ加減が大事かもしれないなぁ。
Hokkaido.cap #10 に参加してきました
4月 30th
4月27日（金）に行われたHokkaido.cap #10 に参加しました。
今回は実践パケット解析学習編・最終回。
参考文献のところに載っている他の解析ツールについて勉強しました。
知らないツールばかりだったので新しい発見がたくさんありました。
様々な解析ツール
パケットを解析することができるツールは、使い方によってはクラッキングツールになる、とても危険な道具です。諸刃の剣。
なので、参考文献に載っているツール群も、ウイルス対策ソフトによって「危険なサイト」としてダウンロードページがブロックされることも多いようです。
たしかに、強力なことができるほど便利だけど、その分、悪用した時にも便利に使えるのですよね。
もちろん、クラッキングツールだけではなく、疑似パケットを作成するパケットジェネレーターや、動かしていると”なんかかっこいい”ツールなどもありました。
標準的なネットワークモニタ
よく使用するネットワークモニタツールとしてtcpdump、Microsoft Network Monitor 3、TCPView、NetworkMinorが紹介されました。tcpdumpはギリギリしっていたけれど、他は使ったことはなかったです。
こういうツールを業務で使うことはあまりないけれど、こういうツールがあると知っておくことは大事だなと思いました。
ネットワークは解析すれば簡単に見える物であるということを忘れないようにしないと。
とても大事なこと
許可なく他人の通信をキャプチャしたらダメ、絶対。 犯罪です。（有線電気通信法、電波法）
また、パケット解析の技術は、トラブルシューティングなどを通じて、自分の経験として身につけることが大事であるという話もありました。
この辺りは「コードを書かないとプログラミングの技術は向上しない」のととても似ているなー。
何事も手を動かして、体験して身につけていく物なのですよね。
CTF
パケット解析を題材にしたクイズにチャレンジしました。北海道で有名なあの人のプライベート写真がゲットできるチャンスです。
張り切って挑戦したものの、Hokkaido.capへの参加が2回空いてしまっていたというのもあり、Wiresharkの使い方をすっかり忘れていました・・・ぐぬぬ・・・
しかし、それでもなんとかそれっぽいキーワードを探して、時間内に画像をゲットすることができました。
最後に答え合わせをしたところ、やっぱり無駄なことをたくさんやっていたなあ。
そして答えの近くでグルグル回っていたなあ。
Wiresharkを使いこなせばもう少し楽にできたところを、力技で解いてしまった感は否めない。
Hokkaido.cap は実践パケット解析が一段落したということで、今後は不定期開催になります。
普段の業務で直接的に使うことはあまりないのだけど、いろんな知識を広げるためにも、また次回参加したいと思います 
第19回アジャイルサムライ読書会 @札幌道場 開催
4月 26th
4月24日（火）、第19回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は5名。リファクタリングについてです。
今回は、会場に「リファクタリング―プログラムの体質改善テクニック」を持ってきていただき(@shuji_w6eさんありがとうございます！）一部はこの本を使って内容を補いながら進めていきました。
今回の範囲で「グっときた」ところ
コードを書くことは、良い文章を書くことにとてもよく似ている
一日を通じてたゆまず、継続的にリファクタリングする
「コードを書くことは、良い文章を書くことにとてもよく似ている」は、すごく自分のなかでしっくり来た文章でした。
ちゃんと説明できないことはちゃんとコードに落とせない、だからまず、きちんと人に説明できるようになりたい、そう思います。
勉強会として
この辺りは、本のページ数が少なくエッセンスしか載っていないので、文中でも「読むべき」とされている本と一緒に読み進めるというのはとてもよい試みだったなと思いました。
「リファクタリング―プログラムの体質改善テクニック」はまだ持っておらず、きちんと読んだことがありません。
今回の話を聞いて「優先度：最高」になりました。
また、そこから発展して、押さえておくべき・読んでおくべき本というのをみんなで話すことができたのも、とても良かったです。
リファクタリングについては、コードを良くしたいという気持ちを持ち続けることが大切だなあと思いました。「継続的に」「たゆまず」です。
楽をしようとしてさぼると後が辛くなる。きちんと書いておくと後で劇的に楽になることがある。
そういう経験も含めて、使い捨てにならないコードを書いていきたいです。
今回、実際にリファクタリングを行っているページのコードをみんなで追いながら話をしたのですが、これが結構楽しかったです。
ぐちゃぐちゃのコードをペアプロしながらリファクタリングするようなワークショップ、面白そうだなあ。
運営の立場で
この部になってからページ数が少なめなので、1回1章と決めて進めています。
テーマが明確になっているので、話がしやすいなと感じます。
脱線しても大きなテーマから外れることがなく、また、脱線よりもさらに深い話をする方が増えてきたような気がします。
（ディスカッションのwikiをみてもその辺りがわかると思います）
プラクティスに関するところはこの進め方が適しているような気がしてます。
個人的にも別の本を一緒に読みながら深くを知りつつ進めていける今回の方法はとても勉強になりました。（今後の課題がよく見える）
残り少ないですがプラクティスの部はこの感じで進めていこう。
今回のディスカッションのwikiは以下にまとめてあります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120424
話題になった著書は全てリンク付きで載せておきました。
忘れているのあったら追記お願いします。
最後に、いつもいつも場所を提供してくれる弊社に感謝。
次回もよろしくお願いします。
Head First JavaScript読書会 05に参加しました
4月 26th
4月23日（月）に開催されたHead First JavaScript読書会 05に参加しました。
04は旅の疲れからお休みし、1回あけての参加。
毎回進むページ数は多いのですが、本自体がとても読みやすいので、追いつくことができました。よかった。
今回は「関数」です。
Javascriptの関数は、知れば知るほど奥が深いのですが、この本ではその導入編を扱っています。
スクリプトから関数へ
ただのコード行を関数にしようとするとき、最初は結構つまづいたなあと思い出しました。
コードから関数を抽出できない、というのには色々段階があると思います。
- そもそも、何をする処理なのかわかっていない
- コードを理解していない
という、「もっとがんばりましょう」という段階。
- 重複や同じ処理をしている、というのが見えない
- 処理をかたまりに分けて考えることができない
という、「がんばりましょう」という段階。
読書会の時にも話をしたのですが、この段階の時に大事になるのは「IN/OUT」を意識することじゃないかな、と思います。
何かをもらって、何かを返す。
もらうもの、返すものの値が違っても種類が同じであれば同じ働きをしている -> 関数として抜き出すことができる！ と形が見えやすくなってくると思います。
ここを乗り越えて感覚をつかめてきたら、その先の成長曲線は一気に上がるのではないかなー。
関数定義の方法いろいろ
次のコードはどちらも関数を定義しています。
＜functionで定義＞
hoge(); // ---(1)
function hoge() {
alert('hoge');
}
＜変数に無名関数を代入＞
huga(); // ---(2)
var huga = function(){
alert('hoge');
}
どちらも関数なのですが、定義されるタイミングが異なります。
なので(1)は実行できるけど、(2)はエラーになる（関数の巻き上げ）。
あと、無名関数として定義しておく（huga) と他の変数で参照できたりできる。
読書会で出てきたよい例示を忘れてしまいました・・・・ここ苦手。
コールバック関数
Ajax関連のコールバックは後半で出でくるのでここは主にwindowのイベント処理の話。
イベントハンドラを使うか、windowsオブジェクトのイベントに関数参照をさせるか、どっちをよく使うか、という話をしました。
＜jsファイル＞
var changeHoge = function{ alser('change!');}
window.getElemntById('huga').onclick = changeHoge
＜htmlファイル＞
<button id='huga' onclick='changeHoge()'>
これは、こっちであるべき、というよりは作っているプロダクトによって適した方があるのではないかなーと思いました。
あとはどのイベントか。onloadなどであればjsファイルに書いてあってもいいけど、onclickなどはhtmlソースから追えた方が便利かなと思いました。
こんな感じで初学者向けの本ですが突然深い話をしたりしています。
家で復習をする時に、読書会で出てきたサンプルコードを参照したいのでPCを持参しようと思うのですが、本が重すぎて実行に至っていません。
次回も楽しみです。
第18回アジャイルサムライ読書会 @札幌道場 開催
4月 11th
4月10日（火）、第18回アジャイルサムライ読書会 札幌道場を開催しました。
参加者は5名。今回から第5部：アジャイルなプログラミングに入ります。
ユニットテストについて書かれた第12章をやりました。
今回の範囲で「グっときた」ところ
あっさり諦めちゃだめだ！
勉強会として
章としてはページ数が多くなかったのですが、テストについていろいろな話ができたのがとても良かったです。
普段、自分が「ユニットテスト」と読んでいるものが、その時々によってブレているよなぁ・・・というのを感じていたので、「ユニットテスト」って何をさしているのかな？という疑問をディスカッションでだいぶクリアにできたことが良かったです。
文脈によって違う捉え方をするものであり、様々な分け方があるから、それを理解した上で”なんとなく”ではなく意味を把握して言葉を使わないといけないなと思いました。
本書では「メソッドレベルの粒度で書く小さいテスト」をユニットテストと定義しています。
不安を覚えた時にテストを書く習慣をつけるには、心構えと同時に環境とスキルがないとうまくいかないという話は身にしみました。まさに今の自分。
でも「あっさり諦めちゃだめ」です。時間に追われていても。うむ。
「あぶなっかしいところは全てテストする」「テストで不具合を再現させてからバグを直す」この二つの心構えは、だいぶしみ込んできているなと思いました。
特に後者は、一時期バグの修正を一手に担当していた時にとても安心できた考え方でした。
だから、書かないと不安になる。その不安を知らんふりしてやり過ごすのはよくないな。
個人的なことですが、今自分が書いているソース、だいぶ不安がたまってきているので時間をちゃんとつくってテスト書いてリファクタリングしたいです。
プログラミングで手一杯になっているのだけどテストの時間を作らないとだめだ・・・。
良い機会なのでrspecをちゃんと使えるようにしたいです。
運営の立場で
今回からしばらくは、1回1章にしようかなと思い実践してみました。
ページ数が少ないので内容が薄くなってしまうかなという不安があったのですが、参加者の皆さんの濃い話が聞けて良かったです。プログラミングに関連する話題は皆さん実経験も豊富で、たくさん良いトピックが飛び出してきました。
次回もまったりと1章づつやっていこうと思います。
そんなゆっくりペースではありますが、終わりがだんだんと見えてきました。
焦らず1回1回を大切にしたいと思います。
今回のディスカッションのwikiは以下にまとめてあります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinsapporo20120410
今日は書きやすかったな。
スローペースでじっくり話し合いの時間を持っていたからかもしれない。
そして今日は久しぶりに（かなり久しぶりだったような）、読書会の後、みんなでご飯にいきました。
読書会が始まる前から「蕎麦が食べたい」と言っていた私のリクエストを通していただきありがとうございました！！
お蕎麦美味しかったです！
みんなで食事をしながらお話をするの、大事ですねー。楽しかったです。
最後になりましたが、いつもいつも場所を提供してくれる弊社に感謝。
夏頃までお世話になります。
実践アジャイルテスト読書会 03に参加しました
4月 10th
4月2日（月）に開催された実践アジャイルテスト読書会03に参加しました。
業務後＋自社作業（メールの設定等々）があり、1時間ほど遅れての参加。
ついていくまでに時間がかかるので、どうやって気持ちを入れていくか考えないとあっという間においていかれます。
ということで、この記事を書く前に、今回の範囲を読み直しました。
今回は「第2部 組織的なチャレンジ」の最初「第3章 文化的なチャレンジ」でした。
テストの本なのでテスターとしてのアプローチがメインで書かれていますが、その背後にある
- 既に構築されている組織の文化がどれほど厚い壁となるか
- 阻害する要因は何なのか
- 不安を感じる部分はどこなのか
- どのような心構えでアプローチをするか
- 自分が変わらなければ行けない部分はどこか
という観点はテスターではなくても共感できる部分が多いのではないかと思います。
文化の壁を乗り越える
新しい事を導入する背景として、まず導入する組織の文化を考えなければいけない。
価値観、基準、前提によって作られる、積み上げられる組織の文化。
長い時間をかけて構築されていった組織文化は人間関係や決定権にも影響を及ぼす。
彼らは自分のやり方が心地よいのです
彼らの仕事を脅かすと感じるならば、彼らは変革に抵抗します
「この章は心が折れそうになる」という感想が多かったのは、組織的な壁を感じる事がみんなあるからなのだろうな。
著者自身がいろんな経験をしたのだろうな、というのがリアルな文章から伺えました。
アジャイルと顧客の関係
「ベンダーとサプライヤーの関係」ではなく「同じビジネスゴールを持つ2つのチーム」になる事が望ましい。
オープンな関係を「両方で認める」、同じ場所で働く。
この辺りは、さらっと書かれているとても重要だけれどなかなか難しいところ。
文化の壁の中でも一番分厚い壁なんじゃないだろうか。
変化は簡単ではない
アジャイルはプロセスの流れが速いからと言って変化の浸透が速いわけではない。
むしろ、その流れはとてもゆっくり。
変化を受け入れられない人達の気持ちの根底には、文化の他に個人の不安があるから。
スキル・ポジションの消失・未知のもの、不安な理由は挙げるときりがない。
恐れというのは強い感情であり、それを考慮しないとアジャイルへの移行を妨げることになります
その際のアプローチとして、チームとしてのアプローチが有効になる（決して上から目線であってはいけない、孤軍奮闘も勝ち目はない）と書かれていました。
そして、何より我慢が必要になる。
変化はすぐには訪れない事を肝に命じて我慢して、できるところからアプローチをしていく事が重要。
そして「どう頑張っても無理だったら、別のところへ行くのが良い」というのが最後に書かれてありました。
最後の切り札として、ここまで書かれているあたり、実経験に基づいているんだなと感じました。
3.6のまとめは、心が折れそうになった時に読み返すととても良いと思います。
参加メンバー
テストの話がメインである事もあり、アジャイルサムライ読書会や普段のプログラミングの勉強会とはちょっと違ったメンバーが集まっています。実際に品質管理をメインとしてお仕事をやっている人も多いです。
ですので、本を読んで話す内容がプログラマよりでもなく、テスターよりでもなく、バランスよくいろいろな話を聞く事ができます。
いろいろなメンバーが参加されている事は、私が本を理解するのにとても役に立っている・助かっているなあと感じます。
今後とも、よろしくお願いします。
勉強会へコミットしていた時間が少ないとブログを書きにくいなあととても感じました。
次回はちゃんと参加したいです＞＜
第26回北海道開発オフに参加しました
4月 3rd
3月31日（土）に行われた第26回北海道開発オフに参加しました。
なかなか自分のやりたいことにまとまった時間を取る事ができなかったので、まったりと有意義に過ごす事ができました。
シェルスクリプト事始め
Software Design 2011年3月号に載っている「シェルスクリプト事始め」の第一部を読みながら、シェルスクリプトを書いてみました。
ロジックが必要なシェルスクリプトを書いた事がなかったので、新鮮な気持ちで臨みました。
最終的に書いたのはこんな感じでファイルに実行権を与える事のできるスクリプト。
#!/bin/sh
for file
do
if [ -x $file ]
then echo "$file には実行権があります"
else echo "$file には実行権がありません"
echo -n "実行権を付与しますか？[y/n]"
read answer
case $answer in
y) chmod +x $file
echo "$file に実行権を与えました"
ls -l $file
;;
*) echo "$file は変更されませんでした"
;;
esac
fi
done
echo "$# 個のファイルを処理しました!!!"
気になった事
- 何故 if の終わりが fi なのか？
- 何故 case の終わりが esac なのか？
歴史的背景があるのかなあ。esacは覚えられない。
モチベーション3.0を読む
先日行われたAgileJapan札幌サテライト。その中の基調講演で紹介されていた本、気になったので購入しました。
モチベーション3．0 持続する「やる気！」をいかに引き出すか
posted with amazlet at 12.04.03
ダニエル・ピンク
講談社
売り上げランキング: 1117
講談社
売り上げランキング: 1117
手元に届いたのが開発オフの前日だったので、じっくり読みました。
まだ、第1部の途中までです。
今は「目の前に人参をぶら下げられただけでは、人間のやる気が上がらない（むしろ逆効果になることもある）」という話を事例とともに分析していっているあたりを読んでます。
開発オフの最後の発表では本に載っていた以下の2つの例を話ました。
人間は自分の利益になることであれば必ず実行する？
Aさんが1万円をBさんにあげるとします。
そのとき、AさんはBさんに条件をつけました。
- Bさんはそのお金をいくらかCさんに分けなければいけません。
- BさんがいくらCさんに分けるかはBさんの言い値で決まります。
- ここで、Bさんの言い値にCさんがOKすれば、AさんはBさんにお金を払い、BさんはCさんにお金を分けます。
- しかし、Bさんの言い値にCさんがNOと言えば、Aさんはお金をあげません。BさんCさん共にお金をもらえません。
このような条件下で実験を行ったとき、Bさんの言い値が1万円の5〜6割であれば、交渉が成立し、BさんCさん共にお金をもらえる確率は高かったのですが、Bさんの言い値が1〜2割だと、交渉が決裂し、両者ともにお金をもらえないケースが多かったそうです。
ここで、考えたいのはCさんの立場です。
Cさんは元々もらえる予定のなかったお金が手に入るわけですから、割合がいくらであっても「自分の得になる事」のはずです。
しかし、なぜ、1〜2割だと自分の利益をふいにしてしまうのでしょうか。
・・・というようなところから、「人間は利益になる事であれば必ずモチベーションが上がるのか？」という話につながっていきます。
楽しいことか仕事か？
幼稚園児を複数のグループに分け、次のような実験をしました。
1日目。あるグループには「絵を描いたらご褒美をあげるよ」と教えます。そして実際にご褒美をあげます。
別のグループにはなにも伝えず、ご褒美もあげません。
2日目。両方のグループにご褒美をあげません。
そうすると、1日目にご褒美をもらっていたグループの子供達は絵を描く事に対する意欲が少なくなったそうです。
ご褒美をもらっていないグループは2日目も楽しく絵を描いていました。
「報酬が発生する時点で、楽しいと思っていた事も仕事になる、その瞬間、内部からやりたい！と思う気持ちが薄れる？」というところから、モチベーション2.0と呼ばれる現代の「飴と鞭」のシステムのよくない点を分析していきます。
事例はだいぶはしょっているので、詳しく知りたい人はぜひ本を読んでみると良いと思います。
個人的にはこの本は小説と同じ、右開き・縦書きで、非常にしっくりと読みやすいです。
時間をみて読み進めたいと思います。
開発オフ恒例ランチ
今回もスープカレーで。カリー・ディ・サヴォイ Curry Di. SAVOY というお店に行きました。
トマトと湯葉と豆腐のスープカレーです。
湯葉としっかりした豆腐と豆腐ハンバーグみたいなものが入っており、けっこうお腹いっぱいになります。
辛かったのだけど、もう少し辛いのも食べてみたくなりました。
あと、キーマカレー気になった。
スペアリブもかなり気になった。
今回も楽しかったです。30回目指して！ゆるーく続けていきたいですね。