OCUnit(SenTestingKit)でTDDしようと思ったらいきなりハマった

テスト駆動開発入門

せっかくなのでテスト駆動開発入門をObjective-Cで写経しようと思ったら、4章でいきなりハマってしまった。

- (void)testMultiplication
{
  Dollar *five = [[Dollar alloc] initWithAmount:5];
  Dollar *product = [five times:2];
 
  // 本当はこんな風に書きたいが、失敗する
  //STAssertEqualObjects([[Dollar alloc] initWithAmount:10], product, @"aaaaa");    
 
  // このテストも当然ながら両方通らない
  Dollar *a = [[Dollar alloc] init];
  Dollar *b = [[Dollar alloc] init];
  STAssertEqualObjects(a, b, @"aaaaa");
  STAssertEquals(a, b, @"aaaaa");
  
  // NSStringは大丈夫・・
  STAssertEqualObjects([[NSString alloc] init], [[NSString alloc] init], @"bbb");
 
  STAssertEquals([product amount], 10, @"aaaaa"); 
  product = [five times:3];
  STAssertEquals([product amount], 15, @"aaaaa");
}

GHUnitならできるのだろうか？

たのしい自分戦略 -セカイとカイシャと自分の仕事を考える-に参加しました

URL等

http://devlove.doorkeeper.jp/events/2503

メモ書き

会社はツール
使われる物じゃなくて使うものと考える
使いたい会社と関わる
外から使うのもありなんじゃないか

人生を計画して実行するのは難しい。
社内で頑張る or 転職 or 独立 or 起業
同じ会社に10年以上いることって少ない？

転職

　→自分がハンドリングできない事が多い。相手の会社が入って欲しいと思っている時期はコントロールできない

　客観的じゃないし実力勝負でもない、個別ケース以上の話がしづらい

独立、創業

　→宝くじよりマシなギャンブルくらい。
　リスクを取れるか、下げられる事情がある以外は厳しい
　成功した人の話はバイアスがかかっているし、失敗した人は詳細を語りたがらない

ではどうするか？

　→心に棚をつくる

現実から目を背けて、マクロな視点から会社を考えてみる

そもそも法人とは
　→民放＋会社法

　会社法知っている人→チラホラ
　民放＝権利を有志、義務を応う。登記すればいい
　人間みたいな人の集まり＝法人
　人間は自然人

法人の無い世界があるとどうなるか。
任意団体
　→口座が持てない、個人名になる。団体として会場が借りられない、個人名。何かあったら個人に責任がふってくる。←ポイント
　法人は、法人が人格になる。訴えられる時も法人になる
　法人にすれば中の人も外の人も安心

法人の種類
　→営利法人、非営利法人、法人以外

・営利団体の特徴

　→構成員に利益を還元できる。頑張って儲ければさらに事業を拡大、優秀な人材を集めやすい。中の人も全力で活動できる

・株式会社の特徴

　→合議制ではなくなる。株式の配分。多数決だと難しい意思決定ができない、冒険し辛い。独裁制だと冒険しすぎる。
ちょうどいい配分が必要。
　税金が取られる。
　お金を儲けるのが目的じゃない場合には安く済ませたい
　同時に複数の会社に所属し辛い。

　そういう場合には非営利法人。

・NPO

　→公益性が高いが、手間がかかる。報告書とか。その反対が一般社団法人

・会社と自分との関係
　→目的があったほうがいい。
　「とりあえずお金が欲しい」＝わかりやすいが、実現するのは結構難しい。何をすれば良いのかがわからなくなる
　何かをやりたい、一人ではできないことをやりたい。会社はそのためのツールと割り切る。シンプル、ストレート
　平日の昼間からできる、うまくいったら収益になる、組織を大きくしやすい。大きくするのもコストがかかる
　個人よりも法人をつかったほうがやりやすい
　「やりたいこと」の見つけ方。なかなか見つからない。

・高橋征義さんの場合
　→たまたま見つかった。「日本語の技術書も電子書籍で読みたい」
　それでもリリースまで１年以上。
　そこそこ利益が出るまで３年、数百万。
　思いつくのも実現するのも簡単ではない。

実現の方法として、これだけではなかったはず。社内、他社、個人、非営利組織。。でも、会社でやってよかった。
時間、しばらく赤字、関係者に安心感、本気度が伝わりやすい

・「あったらいいな」からの始め方
　あったらいいなを考える→実現方法を考える→実行する
　実現手段の一つの手段が「会社」

・会社の問題
　→実現したい目的がないとしんどい
　例えば「世界を変える」＝おおきな言葉。大げさ。普通の仕事とはギャップがある。

　でもよくそういう言葉遣いは良く聞く。とくにスタートアップ方面。ついうっかり？

　本当に世界を変えるのか

　　→たぶん変えられない。が、だまそうとしているわけでもない。
　　遠くの目標であることが大事。
　　

　　例えばスタートアップ。自由度が大きい。犯罪じゃなければ何をやっても良い。

　　場合に寄っては定款書き換えとかも。

　　　→何をしていいか分からなくなる。混乱。
　　新規事業のほとんどはうまくいかない。たまたま成功しても続かないことがほとんど。
　　そういう組織が求める目標はぶれない目標。でも事業はぶれる。

　　ぶらさないといけない。上手く行かない事業は変えないと死ぬ。

　　適応的に変化。適応的に変える目標は迷走と区別がつかない。
　　変わらない目標

　　　→遠くにある目標にすればいい。遠すぎる目標。

　　　近づくことはできる。遠いので多少ぶれても誤差の範囲。
　　　「北極星を目指す＝とりあえず北上する。北極星にいきたいわけではない」

でも、すべての言葉がそうではない
　→とりあえず遠ければ良いだろう。ではなくて
　例えば「Social Change」

　時を超えたプログラミングの道。XP。
　言ってる事とやっていることに差がある？
　ケント・ベックは昔から同じ活動を続けている＝本物
　本気で変えようとしつづける事はできる。

感想

会社が実現したい目的に対して共感できているかどうかは、モチベーション3.0でも出てくるし、ゴールデンサークルの「Why」でもあったりするわけなので

改めてこういった部分の重要性について学ぶことができたことが良かった。

法律としての会社、法人といったものの知識が無かったので得られた事は大きかったが

自分がこの勉強会で期待していたものとはやや違ったように感じた。

それが何なのかはよくわからず、モヤモヤ。

Scrum Boot Camp The Book を読みました

本日発売ですが、2/8の金曜、待ちきれずに新宿紀伊国屋でフライングゲット！

なんやかんやありつつ、今日の午前中に読み終わりました。

SCRUM BOOT CAMP THE BOOK

自分は2012年05月にCSMとなりましたが、実際のプロジェクトでのスクラムマスター経験は3ヶ月ほどしかありません。

ものすごく濃密で濃い〜3ヶ月のスクラムマスターではありましたが

その後、実際の現場を離れたところで半年間を過ごしたため、色々な勘も鈍くなったり

入ってくる情報も現場と乖離するため、対処療法的なアドバイスしか出来なかったりと

色々とうまく行かない事も多い半年間でした。

そんな中、もう一度CSMに行きたいな。。。せめてScrum Boot Camp等で基本を学び直したいという思いが募る中、この本を出版されるとの情報が。

そして真っ先に飛びついてしまった。という背景です。

私の場合は「基本を正しく復習したい」という目的で購入しましたが、正に求めていたものでした。

基本的な部分はもちろんですが、プロジェクトが進んでいく中でよくある問題を取り上げ

どのように対処するべきか、その心構えを学ぶことができました。

「Scrumは体験して学んでいくための仕組み」だとp266に記載されています。

よく社内でも「サイクルを早くまわすため」にスクラムを〜という話をされますが

早いというのは目的ではなく、チームの成長が可視化されるため「結果的に早くなる」ように感じるのだと思います。

本当に早さだけを追求するのであれば、これまでのやり方を変えずに尻を叩き続ける方が瞬間最大風力は間違いなく早いはずです。

やり方を変えるという学習コストや抵抗勢力、一時的な出力の低下などなど、短期的に見れば良い事だけではありませんが

楽しく成長できる枠組みとして、本当に良く出来た仕組みであると改めて実感しました。

余談ですが、勢い余ってtweetしたものにnawotoさんから直々に返信ががが

@harakachi マジでマジでありがとーです #scrumbcbook

— Nishimura Naotoさん (@nawoto) 2013年2月8日

改めて、ついったー凄いなぁ・・

スプリントが達成できなかった事を放置すると何が起きるのか

チームはスプリントで「ここまでやります」を決められる人達なので

全てのスプリントバックログは消化しないといけないし、消化されていないということはスプリント失敗ということになります。

ここでスクラムマスターとしては「失敗だよ」ということを切り込んでいかなければならないんですが、なかなか「失敗だよ」とは言いにくいものですね。

しかし、こういった事を言いにくいからと言ってスルーし続けると、何が起きるのでしょうか。

何故スプリントは達成しなければならないのでしょうか。

いくつかの問題が起きると思いますが、自分の中では

• プロダクトオーナーからの信用が下がる
• 正しい改善活動に結びつかない
• 今後の計画に支障が出る

と、大きく３つの問題が起きると考えています。

プロダクトオーナーからの信用が下がる

これは読んで字のごとくですが、では信用されなくなると何が起きるのでしょうか。

例えばチームの生産性を疑うようになり、強いプレッシャーをかけたり、コマンドコントロールをしだすかもしれません。

プロダクトバックログのメンテナンスを怠るようにもなるかもしれません。

1スプリントで終わるサイズのプロダクトバックログアイテムにする必要性を感じなくなるようになっていきます。

見積もりの内容にも疑問を持つようになるかもしれません。

「なんでこんなに時間がかかるの？」「もっと早く出来るでしょ」などなど。

信用されていないという状態がプラスに働く事はまずありえないでしょう。

スクラムに限らず、全てにおいて言える事だと思いますが。

正しい改善活動に結びつかない

出来ると思っていたスプリントが失敗すると言う事は、何かしらの原因があったはずです。

そこにフォーカスし、正々堂々と掘り下げ、改善していけば良いだけの話なのですが

スプリントが終わらないという状態を放置すると、この「改善のきっかけ」を無駄にすることになります。

時には外部の影響など、チームではどうにもならない事態が起きたのかもしれません。

ですがその「どうにもならない事態」はいつかまたチームに襲いかかります。

その時チームとしてどうしますか？「どうにもならない事態」は、どうすれば「どうにかできる事態」に出来るのでしょうか。

今後の計画に支障が出る

これは当たり前の話ですが、リリース予定だったものがリリースできない事になります。

もし、そのタイミングでリリースしなければ意味がないプロダクトバックログだったら・・・。恐ろしいですね。

しかし、もう1つ重要なのは「仕掛かり品」を生産してしまったという事です。

「仕掛かり品」は完成品ではないため、何の価値も持っていません。

そのため、プロダクトオーナーはその「仕掛かり品」を「完成品」に変えるために次のスプリントに入れようとすることが殆どです。

時にはもう既に不要な「仕掛かり品」だったとしても、チームが頑張って作った「仕掛かり品」だからしょうがない。というような義理と人情で「完成品」になり、結果不要な機能が搭載される事もあるかもしれません・・・。

こうして計画はどんどんおかしくなり、破綻への原因になっていきます。

というわけで、スクラムマスターは「ダメ」なことに「ダメ」であると伝える事がとても重要な役割です。

心を鬼にし、ゲームの審判のような気持ちで、誠実に、「ダメである事」を伝えましょう。

ただし「終わらせる事」を強すぎるプレッシャーとして与えるのもNGで、例えばテストをサボるようになったりするかもしれません。

このバランスの取り方が腕の見せ所なのでしょうね〜（きっと

リーンカンファレンス2013～ヒット商品を作る仮説検証型開発プロセスとスキル～に参加しました

メモを取っていた分だけなので、漏れなどもたくさんあります。

詳細について

http://esminc.doorkeeper.jp/events/2263

会場

福井県ビジネス支援センター　福井南青山291　2F多目的ホール

会場名がややこしいが、表参道から3分くらいの場所にある。
1階は福井県のアンテナショップ。2階が多目的ホール。
床から電源がとれそうだったものの、金属製のフタが開かず利用できなかった、、、

アジャイルからリーンへ、そしてリーンスタートアップに

講師：平鍋　健児さん

会場アンケート。参加者の職業は？
→ソフトウェア開発者95%、ハード系、生産業はちらほら

永和の中でも半分はウォーターフォールのプロジェクト。
アジャイルはビジネス価値が高い、美味しい部分から作っていきましょうという話のこと。
いきなりショートケーキを作るようなイメージ。
　→今までは難しかったが、ソフトウェア工学が発展した。オブジェクト指向、テスト、リファクタリング、などなど技術の発展。
　15年前にはできなかったことができるようになってきた、しかし難しい。
　最近のお菓子業界は、本当にショートケーキを作れるようになっている。
　毎週ショートケーキを作るのは難しい。うまく合わせるのは大変。
　でも合わせる技術が発展してきた。それがリファクタリングなど。

自動車産業などは指をさして確認が可能。でもソフトウェアは指がさせない。
　→指がさせるものを作ってしまえ　→付箋などアナログ管理に繋がる
　ソフトウェアの成果物はハードディスクに埋もれて見えない。
　見えない状態を作らないようにする。

アジャイルの歴史
　→アジャイルはいくつもの方法論を合わせて呼ぶための名前。アンブレラワードと言われる
　リーンはソフトウェア生産をリーン形式の言葉に置き換えて、組織経営に関わる話としている
　元々はTPSからきている。デミングの思想が取り入れられている。
　テストされていないコード、作りかけは仕掛品だと最初に言い始めたのもリーン。
　KANBANは2010年頃、同じくリーンスタートアップも同じ頃。

スクラム
　→スクラムの原点はthe new new product development game
　new newとは「新製品開発の新しいやりかた」
　工程間で区切るのではなく、最初に考えた人は最後まで面倒を見ろ。ということ。

　スクラムではスプリントの前後が表現されていない。
　バックログはどこへ行くのか。作ったものはどこへ行くのか
　売れるか売れないかわからない世界。
「顧客開発」がもっとも重要。作らなくても、何をつくるべきなのかを見つける

リーンが製品開発を改革する

講師：稲垣　公夫さん

自己紹介
　リーン 元々は1990年、製品開発の世界から。
　1996年 リーンシンキング
　2003年 ザ・トヨタウェイ
　2000年の中場からトヨタのあらゆる切り口の研究がされた。本も多数出版された。

リーン生産とは
　・小さな仮説検証サイクルを繰り返す
　・安価で速い知識獲得方法
　リーンはイノベーションの方法であって、よく言われるような無駄取りではない。
　気がついていたらイノベーションが起きているのが日本的イノベーション

顧客価値の理解
　→顧客価値を理解していないとどうなるか　→　恐怖心から競合製品に入っている機能を全て入れる。いわゆる全部入りの製品ができてしまう。
　全部入りの製品は、使いにくい、値段が高すぎる、不要な機能が入っている

　もし顧客価値を理解していると、どうなるか。
　→ iPhone、ダイソンの掃除機（吸引力が落ちない）
　→ オクソの計量カップ　上から用量が読める
　これらは顧客に「何が欲しい？」と聞いても出てくるものではない。

リーン製品開発とは
　→チーフエンジニア制度、セットベース開発、リズム、流れ、A3プロセス　で構成される。

チーフエンジニアとは
　→起業家的システム設計者、ハイリスクハイリターンの職位。スーパーマン
　オクソの例
　　消費者の困りごとを解決する商品しかつくらないというポリシーがある
　　思い込みから脱する、仮説をたくさん立ててどんどん検証していく
　　日本人は他人の感情を読む能力が高い。誰でも顧客価値を理解できる

顧客価値を深く理解するためには技術的知識が必要。

セットベース開発とは
　→ライト兄弟。1900年頃、なぜアマチュアの発明家が成功できたのか
　「知識を獲得、記録してから設計した」
　当時の有人飛行では墜落して死ぬ人が多かった。ライト兄弟は絶対飛べる確信を得てから作りはじめた。結果、最初の設計で成功した。
　実験を繰り返す。小さな風洞を作って翼の模型を作ったり、揚力の計測をする毎日。
　今では航空工学という新しい学問を発明したと言われている
　　いきなり図面を書くのではなく、知識を得てから図面を書いていた

現在は競争が激しくなり、効率化やスピードが求められる事が多いのでポイントベースになってしまう。よくない。
ポイントベース開発＝希望的観測
セットベース開発＝得られた知識を再利用、

知識バリューストリーム。知識の再利用をする

知恵を工夫で補う。
組織が大きくなってくると、立派な試作品が無いと知識が得られないと思ってしまう
ラフからはじめようとしないとセットベースはうまくいかない

リズム、流れ
　→何を学習したか、何を学習するか。インテグレーションイベント。
　アジャイルと同じ。全てを計画することはない
　仮説　試作　検証のサイクルを繰り返す

徹底的な顧客価値理解をする
家電は量販店で売るようになってからいらない機能が増えていった
お客さんにアピールできる、いらない何かがついた商品が増えた

ゴルフクラブの改良の例
遠くにまっすぐ飛ぶこと以外は徹底的に排除。
これまでの新規開発で多様なデータが揃っていた。

まとめ
　→ヒット商品を確実に出すために
　　顧客価値を理解する、お客さんもしらないような価値をみつける
　　技術知識を身につける

TOCを活用したヒット商品開発プロセス

講師：西原　隆さん

質問：ザ・ゴール読んだ人は？
　→７割くらい
　生産の環境を変えていくビジネス小説　アメリカでは30年ぐらい前に出ている
　生産以外の分野の改善手法も。スループット会計、TOC、CCPM、などなど

リーンとTOC
　ゴールドラット博士
　巨人の肩に立って。影響を受けた人物はフォード、大野耐一。車以外の産業にも使えるように開発した
　リーンの子供がTOC
　ムダを無くす、過剰生産を防ぐ仕組み、全体最適を追求する、継続的改善。TOCとリーンは共通している
　ボトルネックがあるというのがTOCの考え
　　制約条件を管理して改善していく
　　計画のリスク、DBR CCPM DBM
　　思考プロセス
　　製造でDBR、開発でCCPM　→大和ハウス、マツダ、NTTデータ、ドラクエ10 2012の発表事例などなど

売れない商品を早く作っても意味が無い
　Fullkit: 準備が（要求、仕様の確定）が出来ていないプロジェクトにCCPMを適用しても成功させることは難しい
　セットベース段階はリーン、アジャイルで、その後にCCPMということをよくコンサルしている

売れない商品を早く開発してもいみがない
　売れないというのは、キャズムを超えていない状態。キャズムよりももっと前に消えていくものも多い

お客様は強い疑いを持っている。簡単に提案を信用しない。
　→営業でいい経験をしたことがない、完全に信用していない、買う気のあるところを見せてはいけない。

まず自分の製品で解ける問題を説明する。そこで合意形成を作ってから話を進めていく方法が良い
　しかし実際は営業マンは色々なものを売っている。全てでこれを実践するのは難しい。。。
　そのため「売り方を開発」する必要がある。断れないほど魅力的な提案＝マフィアオファー
　　→６段階の抵抗を乗り越える。A3シートに作る。商品企画、営業、開発で仮説検証チームを作る
　　　お客様は機能ではなく、もたらされたよい状態を買う

提案営業とコンセプト立案、構想設計、開発実行
開発と営業の溝を無くす活動が必要。組織の壁が無くなって、初めて出来る。

バリューストリームがビジネスアジリティを加速する　～リーンアジャイルの海外事例～

講師：市谷　聡啓さん

質問：アジャイルを知らない人
　→０人
質問：アジャイル開発をなにかしらやっている
　→半分くらい

よくある課題
　→企画と開発の分断

　ビジネス側
　→一旦企画が開発側に渡ったらあとはお任せ。開発の状況がわからない。
　どういうフューチャーがどういう状態にあるのか、いつリリースできるのかわからない

　開発側
　→来た玉を打つ。何故その要求なのか？まで立ち入らない。基準がわからないので言われた通り作る
　開発チームは頑張るが、部分最適化が進む。

　　ユーザーや顧客のために生まれたアイディアがソフトウェアになり、価値が生まれるというサイクルが回せない

Alan Shalloway の話していたagile conference 2012の内容
　http://www.manaslink.com/articles/4435
　カスタマーからコンセプトが生まれる　→　ビジネスが受け取ってプロダクトにする　→　devが開発　→　カスタマーに戻す
　この流れの中に様々なボトルネックがある。

　質問：「バリューストリーム」を聞いた事が無い人
　→３割くらい

　お客様から始まって、要求がお客様に戻っていくまでの価値の流れ＝バリューストリーム
　ビジネスディスカバリー、ビジネスデリバリー
　MMF＝ユーザにとって価値があって、最小限のもの

　時間を計り、どこに時間がかかっているのか。
　　作業している時間と待ちの時間を算出、アクションからアクションに移る時間もかかるので計る
　　手戻りもある、この時間も計る
　　待ちを含めて全部にかかる時間が見えてくる
　　流れを滞らせているものが何か
　　同時に仕懸かる？待ち合わせ？
　　遅れを評価していない
　　大きすぎ、複雑すぎてわからない

　特定の人に役割が集中してボトルネックになることがよくある

　プロダクトオーナー、プロダクトマネージャーのロールを分けるといい、という話も。
　　マネージャーはMMFにしていく人
　しかしPOの役割を分けると、コミュニケーションのボトルネックが新たに生まれる可能性
　お互いが共通の目標に向かって、日々の状況がわかる仕組みが必要
　　そこでバリューストリーム。どこで分断していたかがわかる。

概念はとてもよくわかるが、これだけでは実践できない。
現場を支える仕組みが必要
そこで

Henrik Knibergさんの話
http://www.manaslink.com/articles/4535

普通のソフトウェアかんばんと言われているものは「todo doing done」で構成されている。これをバリューストリームにする
ideas, feature, next 10 feature, develop, system test などなど、1つでバリューストリームの全てを表現する

デイリーMTGはdelivery cocktail Party
　それぞれのチームで、それぞれの看板を更新
　次の時間で役割毎に集まり直す
　チームだけが知っていれば良いタスクは、タスク用カンバンで分ける

しかしアナログでは定量的に測定するのが難しい
　ベロシティの計算など、手でやるのは大変。
　しかし方法はある。フィーチャー毎にどのくらい時間がかかったかを計る。サイクルタイム。着手した時間と、完了した時間をメモっておく

バリューストリームの書き方
　自分がユーザーの要求になったつもりで、各ステップを通過していく
　歩き回って、自分で発見する。人に聞かない
　書く時間は30分。それ以上かけると詳細になりすぎると。
　顧客から始まり、顧客に終わる。
　マップそのものに価値は無い

リーン開発時代に求められるスキルとキャリア

講師：渡辺　登さん

過去にIPAでスキル標準の策定などを行っていたが、スキル標準を作っていても人材育成には繋がらない

いいものを作っていれば良いという時代ではなくなった
　→ITスペシャリスト、ITアーキテクトから、ビジネスクリエータ、サービスクリエータ

富士通が再定義したロール
　→ビジネスプロデューサ、フィールドイノベータ、コンサルタント、サービスインテグレータ

あまりメモ取れず

アイデアを事業に進化させる企業のサイエンス〈リーンスタートアップ〉

講師：和波　俊久さん

リーンスタートアップの歴史
　元をたどるとスティーブン・G．ブランク。
　ベンチャーの失敗のパターンをまとめていた
　メモ取れなかったのですが、http://www.venturenow.jp/column/ogawa/20120704018199.html　あたりをどうぞ。

フィードバックループで何を学ぶのか
　→そのために、何を作るのか
　事業は一発勝負ではない。積み重ね。

会社の中でやる新規事業開発はお金はそれほど重要ではない
　サポート、支援は大事
　だがモチベーションが一番大事。無くなると何も起きないし、誰も何もしようとしない。
　起業はサイエンスとマネジメント。ようは学べるし実践できる。

いまでも生き残っている会社には、何らかの勝ちパターンがある
　→それを誰でも出来るようにプロセス化　→　きちんと出来る（プロセスを守れる）人が評価される
　マニュアルから外れる人は非常識として扱われてしまう。

　常識が一番のリスク。
　脱皮しない蛇は死ぬ。
　計画を実行できる人よりも、想定外の変化への対応力が必要

ゲームチェンジャーの出現の兆候
　カテゴリ名が変わる時
　携帯電話→スマートフォン　携帯市場がスマホ市場。こういう変化では新しいビジネスモデルが生まれる事がよくある。
　現在は自動車→EVが始まっている。ただの乗り換えだけではない、ガワだけ買ってソフトを入れて。という世界になるのでは。アメリカでは既に数百の会社が。。
　破壊的イノベーションが起きている可能性が高い

スピードを上げるというのは無駄を無くすということ。
無駄の見極めがリーンの本質。

長期で大きいものであれば失敗のイライラが大きい
小さく失敗すればイライラも小さい。そこで学んで次に生かす

感想

平日の昼からということもあり、スーツ率が非常に高かった。
一番良かったのはやはり市谷さん。バリューストリームについてはちょうど「リーンソフトウェア開発と組織改革」を読んでいたところだったのでしっくりきた。

リーンソフトウェア開発と組織改革

そしてバリューストリームそのものをカンバンにしてしまうのは確かに有効な手だと思う。ただしスクラムと相性が悪い感じも。それぞれのエリアで分業が進んでしまいそうかなぁ。悪い事ではないのだけども。
そして「セットベース開発」。これは初耳。
ようは学びをちゃんと溜め込んで、検索もできるようにして有効活用して、打率を上げていこうということなんだけども、リーンスタートアップ的な「まずやってみる」みたいな考えとは相反する。
しかしリーンスタートアップでいう learn の結果をきちんと残すような活動が出来ていれば、いずれセットベース開発のようになるのではなかろうか？

リーンとリーンスタートアップは別物だけど、よく混同されがち。別物だと理解している人じゃないと今回のイベントは辛いのでは？と。（特に最後が和波さんだったりとか）
自分としてはもうちょっとリーンの本質的な部分を勉強する必要がある。こっちのほうがスクラムよりも組織論としてお話出来るようになれる。

一筋縄ではいかなかった無線環境の構築

前回のnasne環境構築の続きです。
まずは何といってもルーターの切り替え作業から。
前もってプロバイダ情報は用意しておきましょうね。

我が家では数年前から活躍していたのはコチラ

BUFFALO AirStation11g&b無線LANBroadBandルータ WHR-G

802.11gであらゆる無線機器を接続しておりました。
WZR-600DHPには同時に11n/a(5Ghz帯の11n接続)と11n/g/b(2.4Ghz帯の11n接続)を利用することができるので
高速通信が必要なものは11n/aで。その他は今までどおり11gのままで。という作戦を立てました。

ルータの設定

まずはAOSS2を利用してiPad2を接続します…が、何故か途中でDHCPからIPを取得しようとしているらしく、失敗。
どうもAUTOの判定がルーターモードになっていない様子。
本体背面のスイッチを切り替えてルータモードに変更。更に余計なハマりをしたくないので、AOSS2ではなくSSIDとセキュアキーから手動で接続。
ようやく繋がり、WZR-600DHPの管理画面に行くことが出来ました。
ここでプロバイダ情報を入力し、外の世界との疎通確認。大丈夫そうです。

イーサネットコンバーターの設定

イーサネットコンバータという奴はちょっと厄介な代物で、画面が無いので接続エラー等の時に対処方法が不明です。
しかしWLAE-AG300NにはAOSSボタンがあります。心強いですね。
ボタンを押して数分待つと難なく接続されているようです。さすがバッファロー！

PS3、nasneの設定

PS3は無線ではなくなるので、イーサネットケーブルを利用するように設定変更が必要です。
nasneの接続は説明書もいらないぐらいシンプル。
ですが事前情報で「nasneを通すとアンテナレベルが下がる」という情報があったので
分配機の1口をnasne専用にしました。無駄かと思いつつ3分配のやつ買っておいて良かった。

動作確認

PS3からのnasne動作確認は特に問題も無く、普通に録画も再生もでき、更に外からの録画予約も試してみましたが、問題なく動作しました。
こんなにも簡単に接続できて良いのか、ちょっと怖いくらいです。 しかしここで問題が。
WLAE-AG300Nは単体でスピードテストをすることが出来るのですが、なんと赤表示。
どうも速度があまり出ていないようなのです。
せっかくなのでローカルエリア300Mbpsを目指したい所。ここから長い戦いになろうとは。。

情報収集

300Mbpsの世界にたどり着くためには、色々と細かい条件が必要です。

1. 親機、子機共に300Mbpsに対応できる 5Ghzの802.11n環境に対応している
2. セキュリティは WPA2-PSK-AES
3. チャネルは自動ではなく固定

1は当然クリアしていますが、2については特に気にしていなかったのでそのままです。
どうやらこの辺りを変更する必要があるみたいですね。

ルーター再設定

管理画面から覗いてみると、認証方式が「WPA/WPA2 mixed mode」、暗号化が「TKIP/AES mixed mode」となっています。
たぶんどの設定でも大丈夫ですよ。というものだと思うのですが、これが間違いの元になりそうなのでmixedモードを廃止し、WPA2-PSK-AESのみに変更。
ところが、管理画面上はWPA2に変更しているものの、管理画面TOPにはWPAのまま。WPA2にならないのです。
これはおかしい。。
ですがとりあえずこのままで。
チャネルはとりあえず44あたりを利用します。

イーサネットコンバーターの再設定

AOSSでは何でどう通信しているのか不明なので手動で再設定します。
PCにLANケーブルで接続し「LAN端子用 無線子機設定ツール」を起動。
SSIDとセキュリティキーを入力…ルータに接続できません。
正確にはWPA2では接続できず、WPAでは接続成功。やはりルータの設定が間違えていたようです。
ここでルータに戻り、再度設定を見直しますがやはり変わらず。
1時間以上格闘し、「もうAOSSとか使わんから切るぞ！」とブチ切れの本体再起動を行ったところ、あっさりとWPA2になりました。
なんということでしょう。私はもう2度とAOSSを使うことはないでしょう。

と、ここまできてやっとイーサネットコンバータで再設定しますが、また繋がりません。
しかも今度はWPA,WPA2の両方繋がりません。
だいぶ頭がおかしくなりそうでしたが、iPadやiPad2, iPhone5で802.11n/aのSSIDにWPA2で接続すると普通に繋がります。

もうわけがわかりません。

ここでまた小一時間格闘し、原因はルータの「Any接続を受け入れない」ようにチェックを外していた事が原因でした。
とても残念な気持ちです。
いろいろありましたが、WLAE-AG300Nの設定も無事終了しました。

スピードテスト

はたして、これで本当に300Mbpsの世界になっているのでしょうか。
実際に計ってみたい。のですが、ローカルエリア内の速度の計り方ってどうやるのでしょう。
ググってもいまいち情報は出てきません。
外とのスピードテストでは70Mbpsくらい出ていたので、中がそれ以下ということは無いと思うのですが。 これでいいのか、いまいちよくわかりません。

まとめ

無線まわりは難しいですね。私はもう2度とAOSSを使おうとは思いません。
300Mbpsの検証方法をご存知の方がいらっしゃれば、是非お知らせいただきたいです。

nasne環境を自宅に構築するまで

色んな方々に「nasne良いよ！」と言われ続けた12月でしたので。
一念発起してnasneを購入しよう！かと思ったのですが、よくよく見てみると無線クライアントが乗っていないし、無線接続をお奨めされていない。。。

TVアンテナと電話回線の口(というかVDSL機)が近くに設置してある家ってどれだけあるねん！

ということで更に検索してみると、どうも5GHz帯の802.11nを利用した無線LANだと大丈夫そうだという事実が。
しかしルータまで買ってられん。どうせまたお高いんでしょう？と調べてみると、これが結構安い。
時代は変わりましたねー。

というわけで年末だし、各所で溜まったポイント類を駆使して色々買いましたよ！

まずはルーター。
昔から安心、安定のバッファロー様。

BUFFALO Giga 11n/a&11n/g AOSS2対応 無線LAN親機 【Wii U動作確認済み、iPhone5・Android端末対応】 WZR-600DHP

昔はこれだけで数万円が飛んでいった気がしますが。時代は変わりました。

そしてPS3とnasneの2台を802.11n化しなければなりませんので、イーサネットコンバーターが必要です。
これも2つ買うのか。。と落ち込むところですが、なんと、2台を一度に無線化できる優れものコンバーターがありました。
まさにこんなの欲しい！と思っている物欲に直撃です。

BUFFALO ネットワーク対応家電用 ワイヤレスユニット スターターパック WLAE-AG300N/V

しかもHUBを付けることによって、周辺のアレコレも無線化できるのです。賢すぎ。恐ろしい時代やで！

そしてテレビアンテナの分配器。
これもね。地味に結構高いんですよ。でもAmazon安い！もうドンキホーテ行けない！
2つに分配するだけでいいんですけど、値段がそんなに変わらないので3つのやつを思わず購入。 ケーブルも3本セットなんです。お得すぎる！

PLANEX 全端子電流通過型 高画質・地デジ/BS/CS/110度CS対応アンテナ3分配器+F型ネジ固定式アンテナケーブル(1m) 3本セット PL-ANT03PESET

そしてもちろんnasne様も。

nasne (ナスネ) (CECH-ZNR1J)

本当は、更に2TBのハードディスクも買いたいところではあるのですが、ぐっと我慢。
今後のHDD使用状況次第ですね。

ということで年末という勢いもあり、色々買いました。遅めの自分用クリスマス。
配線編はまた後ほど。