Agile Samurai Base Camp Re:TDD に行ってきた！

Agile Samurai Base Camp Re:TDD に行ってきました！
http://agilesamurai-basecamp.doorkeeper.jp/events/9333

前回(http://agilesamurai-basecamp.doorkeeper.jp/events/5844)はインセプションデッキトラックで参加させていただき、
「後ろでやってるTDDトラックも見たいなー」
「体が二つほしいなー」
と思っていたので待望でした 笑

印象に残ったところをさっくりまとめます。

基調講演

TDDのこころ／@t_wadaさん

TDDは下記の平鍋さんの記事でいうところの、

アジャイルの「ライトウィング」と「レフトウィング」
http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html

「レフトウィング」に含まれる。

アジャイル開発が語られるときには割と、
「ライトウィング」のほうがフォーカスされがちだという。

が、右サイドだけ強くても点が取れない。
と日本代表の内田と長友を引き合いに出したスライドは、
サッカー経験者としてはすごい納得感があった。

キャプテン翼でいえば・・・
って考えたけど、石崎と早田・・・？
だめだ、これはしっくりこない。

アジャイルサムライのP235ページにも書かれている

最後に残った4つの章では、私が「問答無用で実践すべき」だと考えているアジャイルなソフトウェアエンジリアニングのプラクティスを紹介していきたい。

と紹介される中にも、
ユニットテスト、リファクタリング、テスト駆動開発(TDD)があげられている。

ということで、「開発環境」による支えも、
アジャイル開発の一翼を担っているのだと、
改めて意識させられた。

ペアプログラミング

FizzBuzzをお題としたペアプログラミングを、
デモとしてやっていただいた。

色々と端折られた箇所はあったようですが、
ペアプロにより
・TODOリストを作成
・RED→GREEN→リファクタリングのサイクル
・役割チェンジのタイミング
・新たなTODOの追加
の流れがすごく見ていて分かりやすく、
実践で実際やる場合の想像がついた気がします。

工数見合いの部分とか色々と社内で実施しようとすると調整が難しそうだが、
・その場で2人でコードを見ている分バグが入りにくそう
・互いの知識や書き方のナレッジ共有
・仕様を（ちゃんと）把握する人が2人になる
といったあたりはかなり有効なのかもと思いました。

質問コーナー

@t_wada さんに直接質問できるという貴重な場で、
テストコードがなくプロダクションコードだけしかない場合、どのあたりから手をつけるのがよいのか・・・？
という質問があり、

・依存の少ない部分を狙い撃ちにする
・仕様化テストで今動いている仕様をテストに落とし込む

の部分が非常に腑に落ちました。
仕様化テストについては、

レガシーコード改善ガイドでも紹介されているようなのでぜひ読んでみたい。
テストがないコードはそもそもテストが書きにくいという場合が多いが、それを泥臭くステップバイステップで解消してく・・というような流れで分かるそうなので、
0からテスト駆動始めるよ！じゃない人にはお勧めっぽいです。

アジャイルサムライの次に読む本

これは読みたい！と思ったものをメモ。

JUnit実践入門

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnitの本だけど、Unitテストとは何か？的なところから書かれている。CIとかCucumberとか欲張り。JUnitはこれ1冊でOK!

リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

いまさら説明不要のリファクタリングを知るための良本

レガシーコード改善ガイド

レガシーコード改善ガイド (Object Oriented SELECTION)

先ほどもあげましたが、レガシーコード（テストがないコード）からはじめるTDD本ぽい。
現場に一番必要とされている本かもしれない・・とのことだった。

ソフトウェアテスト技法ドリル

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

TDDをやっているてバグが生まれてしまう場合、
それは自分の考えが及んでいない部分になることが多い。
そういう部分を拾いより品質を上げるためのステップアップの1冊。

達人プログラマ

達人プログラマー―システム開発の職人から名匠への道

新人が入ったときに1冊目これを渡す会社も多いそう。
積まれているので早く読む。

データベース・リファクタリング

データベース・リファクタリング

データベースの体質改善テクニック。
データベースのよくない設計にどう対応するのか？ということが書かれているらしく大変興味がある。
が、絶滅危惧種なので見つけたら保護してください 笑

そのほかにあげられていた本も読みたいが、
特に気になったのが上記な感じ。

他の現場を知ってみよう

皆さん口をそろえておっしゃっていたのが、
自分にもチームにも根付かせていくためには、
“無理をしない”ということをあげてらっしゃった。

テストを書くことで、モチベーションが下がったり、変更が怖くなってしまったりすることの無いようにしないといけない。
プログラミングが嫌いになってしまったら本末転倒。

中でも、@PoohSunnyさんのお話しの中にあった、

×　レガシーコードをTDDで改善する

のではなく、

○　レガシーコードで自分のTDD力を高めよう

というお話は、明日から実際に始めるための勇気をもらったような気がして、とてもうれしかったです！

レガシーコードでTDD力を高めよう #agilesamurai from PoohSunny (Yotaro Takahashi)

私的まとめ

実は以前に@t_wadaさんの発表を聞く機会があって、

テストを書く文化を育てる戦略と戦術 from Takuto Wada

DevLOVE現場甲子園2013で拝見したときも「TDDやらねば・・」と思いつつも
今まで実践できていなかった自分がいたのですが、
本日改めて、「やらねば！」という気持ちとともに「なんかできそう！」という気持ちになっています。

この気持ちを切らさぬよう、頑張りたいです。

いつも自分が「キツいなー」とか「つらいなー」とか思ったときに思い出す言葉があります。

「適度に適当に。好い加減で。」by 嫁

「適当」も「好い加減」も言葉で聞くと、
すごくネガティブな表現というか雑な感じがするのですが、

「適当」
http://dictionary.goo.ne.jp/leaf/jn2/151064/m0u/%E9%81%A9%E5%BD%93/
→程度などが、ほどよいこと。また、そのさま。

「好い加減」
http://dictionary.goo.ne.jp/leaf/jn2/9323/m0u/%E5%A5%BD%E3%81%84%E5%8A%A0%E6%B8%9B/
→程よい程度。手ごろ。適当。

という風に考えるといつも「あ、そっか」と思えて気持ちが楽になります。

そんな感じで、
TDDも「適度に適当に。好い加減で。」
という気持ちで1つずつ、少しずつ進めていければなと思います。

Laravel Meetup Tokyo vol.3 に行ってきた！

Laravel(ララベル) Meetup Tokyo vol.3に行ってきましたー！！
http://laravel.doorkeeper.jp/events/9293

人数は30人弱も集まっておりました。

今回私もLT発表者として参加させていただきまして、
勉強会としていろいろ参加させていただく中でも、
ホントに初めての発表だったのでものすごく緊張しましたが、
やってよかったなーと思っております。

Laravel Meetup Tokyo ルール

・1人10ツイート以上　　
・発表者をディスるのは禁止

発表＆LT

Laravelネタ／新原さん@shin1x1

現在Laravel Japanツアー2014の真っ最中で、
前日も福岡でLaravel布教活動をされてきたという新原さん。

LaravelのAuthの機能における気をつけるべき点を発表くださいました。

Laravel ユーザなら知っておくべきAuthオートログイン from Masashi Shinbara

slideshareに載せていただけると、
おっしゃっていたので公開が楽しみです！
（と、ひそかにプッシュ・・・笑）
[2014/04/10 16:56 追記]
新原さんのスライドを追記させていただきました！

LaravelのAuth機能では、「ログイン情報を記憶」の機能を簡単に実装できるようになっており、
ドキュメントを見ても、

if (Auth::attempt(array('email' => $email, 'password' => $password), true))
{
// The user is being remembered...
}

http://laravel.com/docs/security
「Authenticating A User And "Remembering" Them」

のようにAuth::attemptメソッドの引数にtrueをつけてあげることで、
簡単に「ログイン情報を記憶」を実装することができます。

[2014/04/10 16:56 追記]
詳しくは、新原さんのブログをご参照ください！
Laravel ユーザなら知っておくべきAuthオートログインのこと
http://www.1x1.jp/blog/2014/04/lararavel-artisan-should-know-auto-login-by-auth.html

が、
この「ログイン情報を記憶」、Cookieに暗号化した情報(ID)のみが記録され、
その情報を複合して認証するというロジックのようで、
もちろん、app.phpに記載するkeyの値が流出しない限り、
その安全性は保たれるそうなので、それを徹底すること！
ということだったのですが、
新原さんはその部分、別途認証のカスタムドライバを作成することにより、
Authクラスの認証処理を差し替えて使われているということでした。

【参考】

Auth のドライバを独自実装する方法です。 http://t.co/I8pIVGnBl4 #LaravelTokyo

— Masashi Shinbara (@shin1x1) 2014, 4月 5

また、現在、

PHPプログラミング診断室：連載｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/php-programming-examination-room

を連載されており、
若気の至りで生み出した秘蔵のお宝コード（笑）を投稿して、
連載で採用されるとなんとQUOカード3,000円がもらえるそうなので、
そのようなコードを秘蔵されている方は、
ぜひぜひ投稿をしてみてはいかがでしょうか？？

websocket関連／Yuuki Takezawaさん@ex_takezawa

Larevel、Websocket、Redisを利用したアプリケーションを、
デモを交えてご紹介くださいました。

laravel websocket(use redis pubsub) [Laravel meetup tokyo] from Yuuki Takezawa

発表の前半戦はLaravel(ララベル)の魅力や、
使っていての感想についてもご説明がありました！

また、LaravelはデフォルトでRedisに対応しており、
Takezawaさんいわく、

regis好きにはたまらない親和性

ということでした。

次回は、

次回は無理やりannotation実装か、新世代DB meet laravelをテーマに面白技術枠を目指します。

ということでしたので、
こちらも激しく期待です！

WindowsでもVagrantとChefでLaravelのローカル環境を(自分で)つくりたい！／@blue_goheimochi

という内容で私、LTさせていただいてきました。
冒頭でも言いましたが、そもそも人前で話すの自体、
そんなに得意ではないタイプなのでたいそう緊張したのに加え、
「Windowsでも」というタイトルにも関わらず、
会場内のPC比率は、
Mac9割、Windows1割
という、どアウェイな状況でした 笑

が、やってみて本当に良かったです。
誘っていただいた@mukakenさんに本当に感謝です！

WindowsでもVagrantとChefでLaravelのローカル環境を(自分で)つくりたい！ from Yuta Ohashi

次回もなんとかネタを絞り出して発表できれば！と思っているので、
ぜひ次回のLaravel Meetup Tokyo vol.4(開催日未定)に、ご参加いただければ幸いです。

また、この私の発表の後、
新原さんにアドバイスいただいた内容として、
chef以外でもローカル環境構築くらいなら、
ansibleというプロビジョニングツールもいいよ！
（というかローカルならシェルスクリプトでも済ませてもいいかも！ｗ）
というアドバイスもいただいたので、
そちらも試してみたいと思います＾＾

ハッカソンタイム

発表＆LTの後はグループに分かれて、
プチハッカソン的な時間でした！

・laravel.jpどうしようか？
・新原さんに質問したい！
・Laravel本を読む
・この後LTするスライドづくり

のような感じで方々に分かれもくもく。

中でも、LTをしてくださった@ngmyさんは、

泣きながらLTのスライド作ってる。 #LaravelTokyo

— つらいにゃん (@ngmy) 2014, 4月 5

という悲痛な(?笑)ツイートをされておりましたが、
短時間で完成させたとは思えないような発表をしてくださいました。

「Laravelのパッケージのテストに便利なパッケージ」ということで、
orchestra/testbenchを利用することで、パッケージ開発がはかどるよ！とのことでした。

Laravelのパッケージのテストに便利なパッケージ from Yuta Nagamiya

たしかにテストが書きやすくなることで、パッケージ開発もしやすくなりますよね！
私もそろそろ何かパッケージ作ってみようかしら・・・

そして、最大の盛り上がりポイント・・・・

新原さんが最後にご提案くださった、
読み方問題を解決しよう！のLT。

本コミュニティでは満場一致で、Eloquent = エロクアント、artisan は アーティザンと呼ぶことに決まりました。 #LaravelTokyo

— Masashi Shinbara (@shin1x1) 2014, 4月 5

これです！！！決まりました！！

「Eloquentってさぁ～(読み方あってるかな・・・)」
「artisanいいよね～(読み方あってるかな・・・)」
と、不安になる必要はもうありません！！

Eloquent = エロクアント
artisan = アーティザン

これでよりLaravelについての会話が加速することは間違いないでしょう！！☆

懇親会

という訳で、その後は、
@cosume(アットコスメ)やcosme.com(コスメ・コム)を運営されている、
株式会社アイスタイルさんのご厚意で、懇親会会場として使わせていただき、
Laravel(ララベル)談義が交わされ、夜は更けていったのでした！

まとめ

日本国内でもどんどんと流行の兆しを見せるLaravel(ララベル)！
日本語の情報もすごい勢いで増えていると感じます。
きっと2014年、さらに浸透していくPHPのFrameWorkとなるのではないでしょうか！！

今からLaravel Meetup Tokyo vol.4が楽しみです！
次回も何か発表するぞ！（できたらいいな・・・

【ブックレビュー】嫌われる勇気／岸見一郎 古賀史健

自分が持っている常識が覆される感じというのか、
すごい心揺さぶる内容の本でした。

なかなか1回読んだだけでは、本書の中に登場する「青年」の心理状態のように、
論理的には理解できるような気がしても、感情的には理解し難い…
という感じの印象を受けています。

しかし「読む前と読んだ後では考え方変わったかも。」と思えるくらい、
本書には今まで自分が持っていた常識とは異質な考え方があり、
1つ新たな軸というか考え方ができるようになったんじゃないかなぁと思います。

アドラー心理学

「アドラー心理学」をご存知でしょうか？？
私はまったく知らなかったです 笑

アドラーはフロイト、ユングと並ぶ世界的な心理学の三大巨頭のひとりなのだそうですが、
そもそも私は心理学に明るくないので、フロイトの名前で思い浮かんだのも、

「なんつー夢見ちまったんだ、フロイト先生も爆笑だっぜ」

という、涼宮ハルヒの憂鬱でのキョンのセリフが思い浮かんだくらい無知な状況で読み始めました。

目的論と原因論

アドラーとフロイト、ユングの心理学の大きな違いは、
「目的論」か「原因論」かということだそうです。

このふたつの違いが出てくる哲人と青年の対話の中で、

アドラー心理学ではトラウマは明確に否定している

と言及しています。

「！？どういうこと？」

即座に頭の中には「？」が 笑

しかし、読み進めていくうちに、
私の中ではこのふたつの理論をこうとらえることで落ち着きました。

「トラウマ」があるから「人の前でうまくしゃべれない」（原因論）

ではなく、

「人の前でうまくしゃべりたくない」から「トラウマ」のせいにしている（目的論）

こう考えると割とシックリくる。

私たちは無意識のうちに、
「原因論」の考え方をしている場合が多いらしく、私も例に漏れずそうだったようで、

トラウマは存在しない

という論法には正直面食らった部分があるのですが、なるほどそういうことかと今では理解できている気がします。

対人関係の悩みと課題の分離

すべての悩みは「対人関係の悩み」である

これも即座に理解できない一説 笑

ですが、本書の中で出てくる「課題の分離」でとらえると少しづつ理解できる気がしてきます。

アドラー心理学とは、他者を変えるたための心理学ではなく、自分が変わるための心理学です。(P115)

と哲人も言っておりますが、
ある事象が「自分の課題」なのか「他者の課題」なのか、線を引き、
自分にはどうすることもできない「他者の課題」を区別することができれば、「自分の課題」に対して自分がどう変われるか？に重点を置いた考え方ができそうです。

自らの生について、あなたにできるのは「自分の信じる最善の道を選ぶこと」、それだけです。一方で、その選択について他者がどのような評価を下すのか。これは他者の課題であって、あなたにはどうにもできない話です。(P147)

なるほど、

自分を変えることができるのは自分しかいない

のだなぁと。

そして、

われわれの努力とは関係なく、わたしのことを嫌う人もいれば、あなたのことを嫌う人もいる。

という考え方は確かに当然なんですが、今まで考えたことのなかった、
目からウロコの考え方でした。

ニーバーの祈り

「神よ、願わくばわたしに、変えることのできない物事を受け入れる落ち着きと、変えることのできる物事を変える勇気と、その違いを常に見分ける知恵とをさずけたまえ」(P229)

キリスト教社会で古くから口承されてきた「ニーバーの祈り」という有名な言葉で、
そこから哲人も

われわれは何かの能力が足りないのではありません。ただ"勇気"が足りていない(P229)

と言及しており、なるほど勇気かと感じさせるのですが、

「この一説どっかで聞いたことあるな…」

と思い記憶をたどってみると、ありました！

変えられないものを受け入れる力
そして受け入れられないものを
変える力をちょうだいよ

Wait & See〜リスク〜／宇多田ヒカル

近くないすか？？笑

感謝をつたえること

人は感謝の言葉を聞いたとき、自らが他者に貢献できたことを知ります。

他者から「よい」と評価されても、人は貢献できたとは感じず、
自らの主観によって「わたしは他者に貢献できている」と思えることで、
自らに価値を感じるようになるそうです。

自らが人に対して、「評価」ではなく「感謝」を伝えることによって、縦の関係ではなく、横の関係が築かれる。

あらためて「ありがとう」って感謝を伝えることは大事だなぁと。

まとめ

幸福とは貢献感

であり、

「他者に貢献するのだ」という導きの星さえ見失わなければ、迷うことはないし、なにをしてもいい。(P280)

「アドラー心理学」の今まで自分の中にあった常識とは異質の考え方を理解し、それのいい部分を勇気を持って自分の中に取り入れることができれば、少しずつでも未来は明るくなるのではないかと思います。

嫌われる勇気―――自己啓発の源流「アドラー」の教え

メモ

「いかなる経験も、それ自体では成功の原因でも失敗でもない。われわれは自分の経験によるショックーいわゆるトラウマーに苦しむのではなく、経験の中から目的にかなうものを見つけ出す。自分の経験によって決定されるのではなく、経験に与える影響によって自らを決定するのである」(P28)

いまの自分よりも前に進もうとすることにこそ、価値がある(P93)

アドラー心理学とは、他者を変えるたための心理学ではなく、自分が変わるための心理学です。(P115)

われわれは「他者の期待を満たすために生きているのではない」(P135)

自分が自分のために自分の人生を生きていないのであれば、いったい誰が自分のために生きてくれるだろうか(P135)

あらゆる対人関係のトラブルは、他者の課題に土足で踏み込むことーあるいは自分の課題に土足で踏み込まれることーによって引き起こされます(P140)

自分を変えることができるのは、自分しかいません(P143)

自らの生について、あなたにできるのは「自分の信じる最善の道を選ぶこと」、それだけです。一方で、その選択について他者がどのような評価を下すのか。これは他者の課題であって、あなたにはどうにもできない話です。(P147)

困難に直面することを教えられなかった子どもたちは、あらゆる困難を避けようとするだろう(P154)

われわれの努力とは関係なく、わたしのことを嫌う人もいれば、あなたのことを嫌う人もいる。(P161)

他者の評価を気にかけず、他者から嫌われることを恐れず、承認されないかもしれないというコストを支払わないかぎり、自分の生き方を貫くことはできない。(P162)

あなたは他者によく思われたいからこそ、他者の視線を気にしている。それは他者への関心ではなく、自己への執着に他なりません。(P183)

ほめるという行為には、「能力のある人が、能力のない人に下す評価」という側面が含まれています。(P197)

誰にでも自分が生産者の側で居られなくなるときがやってきます。(P249)

人生における最大の嘘、それは「いま、ここ」を生きないことです。(P275)

【ブックレビュー】グロースハッカー／ライアン・ホリディ

職場の人に薦められ、その場のノリで、

「感想レポート提出するわ！」

と宣言して読み始めた（笑）

帯には

会社もサービスも劇的に成長させるものの売り方、作り方

という刺さる人には刺さりそうな言葉が。

しかし正直なところ最初、上の言葉が刺さったのかというとそうでもない 笑

しいて言えば「ハッカー」という言葉のほうに意識がいき、

「“グロース”の“ハッカー”って何者！？」

という部分が興味の部分でした。

が、内容も面白く、分量的にも読みやすく、
様々なグロースハックの例が散りばめられているので、
飽きずに最後まで読むことができました。

グロースハッカーって何者？

私自身「グロースハッカー」という言葉自体になじみがなく、
グロースハッカーがいったい何者なのか・・・
というのが第一印象。

文中にもありますが、「ハッカー」ってなんか「悪いことするような人」という印象を持っている人も少なくない気がしますが（自分も多少そういう印象はあるし）、

「ハック」(hack)という言葉は本来、「高い技術力を駆使して課題を解決する」という意味であり、ハッカーに対する悪いイメージとは大きく異なる(P99)

とあるように、「ハッカー」は別に悪い人のことをいうわけではなく、
文中の以下の言葉に集約されているなと感じますが、

「利用者を獲得•維持し、サービスを大きく成長（グロース）させていく」（P99）

ということを実践・実行する人
を「グロースハッカー」と呼ぶという認識がしっくりしています。

で、グロースハックってなに？どんな手法？

「じゃあどうすればそんな風に成長を促すようなことができるのさ？」
「銀の弾丸となるものがあるんだよね？」
となるかもしれませんが、
やっぱり銀の弾丸は「ない」です。

「グロースハックとは、ツールキットというよりも、マインドセット（考え方）だ」(P24)

本書でも上記のように言及されており、
実際様々な会社がどういう風に成功してきたか（ツールセット）の話は盛り込まれていますが、
（特にP48からP51に成功した具体的な施策がある）
結局は各々が各々の置かれている立場・現場において、
どんな方法が「グロース」させる手法になるのか？を見つけ出す必要があると思います。

使える分析ツールをフルに活用し、最大限の結果を得られるまで改善して、改善して、改善しまくるのだ。

というように、やはり銀の弾丸はなく、
使える分析ツールで得られるデータ（GAとかメルマガの効果測定とかもうありとあらゆる分析結果）について、
分析し考察し仮説をつくり検証し・・・の繰り返しにより、
PMFにどんどん近づけていくことがその手法なのではないでしょうか。

まとめ

「どんな状況であっても、もっと改善できる」 (P74)

という言葉が示すように、
必ずしも「グロースハッカー」になる必要はないと思うが、
いま自分のいる立場について、現場について、会社について、
関わっているサービスについて、
より深く深く（現状を）知り、分析し、
短いイテレーションの中で、より効果の出る施策を模索し続け、
より高みを目指すことのできるような、
「グロースハックをするんだ！」という意識は、
個人•チーム•会社のどのレイヤーでも共通して持つべきマインドセットであり、
それを実践する・浸透させていくという心を忘れずに、
仕事に生活に活かしていけるといいなと思います。

参考までに・・・

まずは訳者あとがき(P123)からよんでみるのが個人的にはおすすめかも。

グロースハッカー

メモ

グロースハッカーはひたすらユーザーと成長とを追跡する。

マーケティングの本質は変わらないー顧客が誰で、どこにいるかだ

測定可能で効率的な方法で、いかにして注目を集め、持続させ、倍増させて行くか

マーケティングにおける最善の決定とは、特定の人々のリアルで切実なニーズを満たす製品や事業を獲得することだ。

数百万人ではなく、数百人あるいは千人程度の鍵を握る人々を直撃できればいいのだ

ユーザーを引き込む、獲得するためのピンポイントな攻撃が必要。

本能的直感では絶対に得られないPMFに近づくための洞察を与えてくれるだろう

製品開発とマーケティングを完全に別のプロセスとして行う方法はもう古い。

クチコミが生まれるのは運ではない。魔法でも偶然でもない。なぜ話題になり、共有されるのかには科学的な理由があるのだ。レシピがあり、公式すらある。 社会学者 ジョーナ•バーガー

製品やサービス自体に共有せずにはいられない価値がなければならない。

"ゴー•バイラル"したければ、クチコミの種を製品の中に仕込む必要があるということだ。

クチコミは偶然には起きない。設計するものだ。

サービスに追加した機能でユーザーを定着させられるなら、その機能もマーケティングなのだ

ユーザーがそのサービスから離れられなくなる（そして友達を誘う）まで改善しよう。

定着は獲得に勝る ブロンソン•テイラー(P80)

グロースハックは、ROI（投資収益率）の最大化を目指すものだ ― 最も効果的なポイントに全精力を注ぎ込むことだ。

マーケティングとは、顧客の獲得だ。そう考えれば、顧客を獲得するための行動すべてがマーケティングだといえる。

効率的で拡張可能なデータ駆動型の方法で顧客にリーチする

本能的直感では絶対に得られないPMFに近づくための洞察を与えてくれるだろう

【勉強会メモ】リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜

2013/11/28(木)19:30-21:00 におこなわれた、
「リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜」
http://leanfromthetrenches.doorkeeper.jp/events/7026
に行ってきました！

真剣に現場のことを考えているみなさんから発せられるエネルギー？
に触れることができ、パワーをもらいました。

「今、あそこにいた人たちがそれぞれの現場で頑張ってるんだな・・・」

と思うだけで、気が滾ってきますね！がんばろっと。

メモ

Stop Starting, Start Finishing

終わらないと価値は生まれない

「価値」を創造するためには、終わらせる必要がある。
「終わる」を始める。深い。

未完成のもの・仕掛品をいかに減らすか #リーン開発の現場

— takao.oyobe (@TAKAKING22) 2013, 11月 28

【参考】
■5分で理解するリーンな「かんばん」 | 『リーン開発の現場』越境せよ！
http://lean-trenches.com/one-day-in-kanban-land/

爆弾処理にたとえる

大きな爆弾1つを回して行くよりも、
小さな爆弾3つを回すほうがいいよね。
（もし爆発しちゃった場合でも、小さいほうが被害すくないし、WIPも減らせる。さらに続けることでうまくなる。早くなる（WIP制限が増える））

サイレントブレスト

第2部のディスカッションのフェーズで、
「振り返りMTGなどで発言する人が固定されちゃうんだけど・・・？」
という話の中で出てきたワード。

たしかに、メンバー多くなってきたりすると、
発言しない人も増えるし、そもそも発言するのが苦手（自分含む 笑）な人もいる状況で、
「ポストイットに書いて貼る」っていうので、意見が集められればステキだ。

無理に発言を強制するのではなく、
「この人の意見って、こうしたら引き出せるんじゃないかな・・・？」
っていうアプローチを考えなきゃな。

ワザと問題を起こす

策士怖い！笑

中間管理職はつらいから助けてあげる

どこのポジション・役割にいるかによって、
「何にもっともフォーカスして考えるか・・・？」は違う。

「上司は今期って何を達成したいんですか？？」
「私に手伝えることはありませんか？？」
って聞いてもらえることで救われると、
会場にいた中間管理職的なポジションの方も言っていた。

「顧客」の定義はどこ？？

プロダクトを使ってくれる人 ＝　「顧客」
お金を払ってくれる人　＝　「顧客」
だったりするよね・・・って話。現場によって多種多様だろな・・

【平鍋さん的リーンの定義】
１．顧客の目で「価値」を定義
２．価値の流れを可視化
３．それを「エンドツーエンド」で「細く、速く」流れるようにする
４．その流れの改善活動を、現場で実際に仕事をしている人々が行う

大テイラー主義の科学的管理手法。 そことは、ちょっと違っていて、サイエンティストが外にいるのではなく、チームにいるのだ。チームで測って、チームでカイゼンするのがリーンだ。 #リーン開発の現場

— Takeshi Arai (新井 剛) (@araratakeshi) 2013, 11月 28

現場の人間が、自ら自分たちでカイゼンを行っていくのがリーンかな。
そんな現場に変えなきゃ。

明日やること！

まな板立てでポータブルカンバン！！

参考

■第一部：リーンとカンバンの本質 - 平鍋健児氏のスライド

lean from the trenches from Kenji Hiranabe

■リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜 - Togetter
http://togetter.com/li/596298

■End of Methodology (日本語訳)
http://blogs.itmedia.co.jp/hiranabe/2011/05/end-of-methodology-ja.html

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の本質 ソフトウエア開発に活かす7つの原則

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

print_r()とvar_dump()どちらをつかう？？

みなさんはデバッグの際、print_r()とvar_dump()のどちらを使いますか？？

どちらの関数も、オブジェクトの構造を再帰的にたどって出力することができるのは共通していますが、その出力内容は異なります。

print_r()とvar_dump()のそれぞれのマニュアルを見てみる。

それぞれの関数のマニュアルを見てみましょう。

■print_r
http://www.php.net/manual/ja/function.print-r.php

print_r — 指定した変数に関する情報を解りやすく出力する

print_r() は、 変数の値に関する情報を解り易い形式で表示します。

■var_dump
http://www.php.net/manual/ja/function.var-dump.php

var_dump — 変数に関する情報をダンプする

この関数は、指定した式に関してその型や値を含む構造化された情報を 返します。配列の場合、その構造を表示するために各値について再帰的に 探索されます。

PHP 5 では、オブジェクトのすべての public、private および protected なプロパティが出力されます。

ということで、
説明を読んだだけじゃよくわかりませんが、
やはりどちらも変数に関する情報を表示することができるようです。

じゃあどちらでデバッグしてもOK・・・？

じゃあプログラムをデバッグする際、
どちらを使ってもよいのかー
というのはちょっと間違いで、
print_r()とvar_dump()で出力の形式や内容がちょっとずつですが違います。

特に特徴的なのは、配列やオブジェクトの構造を持っていない変数に関する出力が違うというところとvar_dump()は型まで表示されるということでしょうか。

print_r()とvar_dump()の出力の違い

実際に違いを見てみると・・・

値	print_r()での出力	var_dump()での出力
null		NULL
true	1	bool(true)
false		bool(false)
123	123	int(123)
'ok'	ok	string(2) "ok"
array(1,2)	Array( [0] => 1 [1] => 2 )	array(2) { [0] => int(1) [1] => int(2) }
class X { public $p = 1; private $q = 2; } new X()	X Object ( [p] => 1 [q:X:private] => 2 )	object(X)#1 (2){ ["p"] => int(1) ["q":"X":private] => int(2) }

※『徹底攻略 PHP5 技術者認定 [上級] 試験問題集』(インプレスジャパン、2013/9/19) P39より

というような感じになります。

私個人的な使用方法としては、
変数の型まで確認する必要がある場合はvar_dump()、
変数の中身を確認したい場合はprint_r()というような使い分けをしています。

まぁ使用頻度的にはprint_r()のほうが多いかなぁ・・・という感じですが。

とまぁ、print_r()とvar_dump()は出力内容が違うのだなぁということを念頭において、
デバックしたい状況で臨機応変に使い分けていきましょう！

【自宅サーバ構築記録】yumでApacheをインストール(ついでにPHPも)

ちょっと時間が空いてしまいましたが、
当初掲げていた目標は

ApacheとPHPとMysqlでWebアプリ作って、
なんとなく外部に公開したいなーー
っていうゆるい目標を1つの軸に持ちつつやりたいと思います。

ということなので、
ちょこちょこやっていきます。

■Apacheをインストール

[root@luffy ~]# yum -y install httpd

■Apacheの設定・・・の前に
Apacheインストール直後の状態だと、

[root@luffy www]# ls -l /var/www/
合計 16
drwxr-xr-x 2 root root 4096  8月 14 02:30 2013 cgi-bin
drwxr-xr-x 3 root root 4096  8月 14 16:59 2013 error
drwxr-xr-x 2 root root 4096  8月 14 02:30 2013 html
drwxr-xr-x 3 root root 4096  8月 14 16:59 2013 icons

というような具合に、/var/www/いかにhtmlというフォルダが作成され、
そのフォルダ以下がドキュメントルートというような扱いが想定されています。

が！

いくつかのドメインをVirtualHostによって私は扱いたかったのでその想定で設定していきます。

/var/www/virtualhost/domain1.com/
/var/www/virtualhost/domain2.com/

フォルダ構造的にはこんな感じ。wwwいかにvirtualhostフォルダをつくりその中にドメインごとのフォルダを配置して管理するような想定です。

■Apacheの設定

[root@luffy~]# vi /etc/httpd/conf/httpd.conf 
ServerTokens OS
↓
ServerTokens Prod #エラーページなどでOS名を表示しないようにする

DocumentRoot "/var/www/html"
↓
#DocumentRoot "/var/www/html" #基本的にVirtualHostでディレクティブを指定した運用にするので、コメントアウト。

<Directory "/var/www/html">
↓
#<Directory "/var/www/html"> #上と同様

    Options Indexes FollowSymLinks
↓
#    Options Indexes FollowSymLinks #上と同様

    AllowOverride None
↓
#    AllowOverride None #上と同様

    Order allow,deny
    Allow from all

</Directory>
↓
#    Order allow,deny
#    Allow from all

#</Directory> #上と同様

ServerSignature On
↓
#ServerSignature On #エラーページでサーバー情報を表示しないようにする

<Directory "/var/www/icons">
    Options Indexes MultiViews
    ↓
    Options MultiViews ← iconsディレクトリのファイル一覧を表示しないようにする
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

AddDefaultCharset UTF-8
↓
#AddDefaultCharset UTF-8 #文字化け対応でコメントアウト

[root@ruffy ~]# rm -f /etc/httpd/conf.d/welcome.conf ← テストページ削除

[root@ruffy ~]# rm -f /var/www/error/noindex.html ← テストページ削除

■Virtualhostの設定

[root@ruffy ~]# vi /etc/httpd/conf.d/virtualhost.conf

NameVirtualhost *:80

# バーチャルホスト未定義のホスト名でアクセスがあった場合、アクセスを拒否
<VirtualHost *:80>
    ServerName any
    <Location />
        Order deny,allow
        Deny from all
    </Location>
</VirtualHost>

# domain1.com用の設定
<VirtualHost *:80>
    ServerName domain1.com
    DocumentRoot /var/www/virtualhost/domain1.com/html
    ErrorLog logs/domain1.com/error_log
    CustomLog logs/domain1.com/access_log combined env=!no_log

    <directory />
        Options -MultiViews
        AllowOverride All
        Order allow,deny
        Allow from all
    </directory>

</VirtualHost>


# domain2.com用の設定
<VirtualHost *:80>
    ServerName domain2.com
    DocumentRoot /var/www/virtualhost/domain2.com/public
    ErrorLog logs/domain2.com/error_log
    CustomLog logs/domain2.com/access_log combined env=!no_log
    <Directory "/">
        Options -MultiViews
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

■Apacheの起動

[root@ruffy ~]# service httpd start

[root@ruffy ~]# chkconfig httpd on

■PHPのインストール

[root@ruffy ~]# yum -y install php php-mbstring php-gd php-mcrypt php-xml

ってな感じでApache（とPHP）の設定は完了です。