公式サイト
http://www.agilesamuraibasecamp.org/
DoorKeeper
http://agilesamurai-basecamp.doorkeeper.jp/events/5844
Togetter
http://togetter.com/li/600193
ということで、前半の午前分を先日メモに書きました。
「Agile Samurai Base Camp」に参加しました ～其の壱～ （午前の部）
http://makopi23.blog.fc2.com/blog-entry-124.html
12/8(日) 「Agile Samurai Base Camp」に参加しました ～其の壱～ （午前の部） http://t.co/QnHpOxAKC0 #agilesamurai
— makopi23 (@makopi23) 2013, 12月 9その続きで、今日は午後のセッション分のメモをダラダラと書き起こすことにする。
■体験してみよう！ 市谷聡啓氏・西村直人氏
午後のセッションは、実際にインセプションデッキを作るワークショップから開始です。
以下のプロセスで進めていきました。
■チーム分け
・6人1組で各テーブルに座る。
・各テーブル2人ペアを3組作る。
・3組それぞれのが、以下のお題から１つを選びインセプションデッキを実際に書いてみる。
■サンプルのお題
１．アジャイルサムライ
２．iPhone
３．アメブロ
■「パッケージデザイン」の作成
・お題を選んだら、次に「パッケージデザイン」を作ります。
・ちなみに「パッケージデザイン」は「製品ポスター」とも呼ばれるそうな。
・ポイントとしては、「製品としてのゴール」を定め、使う人にとってのメリットを書くこと。
・まず「プロダクトの名前」を決める。
・次にアピールポイントを思いつく限り書き出し、その中からベスト３つを選択する。
・次に、「最高のキャッチコピー」を考える。
・それらが揃ったら、ユーザに手にとってもらえるようなポスターを書いてみる。
・機能面をつらつら書くのは嬉しくもなんともない。「使う人にとっての嬉しさ」を書くこと。
・キャッチコピーは若干、胡散臭いくらいでちょうどいい。ただし嘘はやめましょう。
作り方を要約するとこんなカンジらしい。
１．アピールポイントをブレストする
２．３つに絞る
３．キャッチコピーを考える
４．ビジュアルを考える
５．描く
私のペアはお題として「アジャイルサムライ」を選択しました。
というわけで書いてみた～
・・・いや、うん。時間が無くて残り1分くらいでダッシュで書いたんだ。。。
ペアの方とブレストして意見出しながらやったんですが、なかなか難しいですね。
アピールポイント３つはすぐ選べたんですが。。。
キャッチコピーって1個かつ短い言葉で表す必要があるので、2人が考えた案を両方とも1語に含めるにはどうしたらいいか、みないなので無駄に悩みました。
逆に人数多いほうが、キャッチコピーを１つに集約しやすいような気がする。
2人だと、どっちの意見を取るか？みないなカンジになりがちでした。反省。
■「エレベータピッチ」の作成
次に、ビジネスとしてのゴールを簡潔に表すためのエレベータピッチを作りました。
以下の内容を含めます。
・課題
・ターゲット
・嬉しさ
・他に何を使う
・他にない特徴
作る際のポイントは、以下をよく考えて書くこと。
１．どんな課題を解いてくれるの
２．どんな人が嬉しいの
３．何が嬉しいの
４．これがなけれあば何を使う？
５．これを使うべき理由は？
ってなわけで、上記5点について、こんどは個人で書いてみた。
書いた後は、ペアで見せ合った後、同じお題で書いてみた参加者で集まって意見交換の場が設けられました。
こーゆうディスカッションの時間があるのは良いですね～
最後に西村さんの纏めがあり、このセッションは終了となりました。
・次に、デッキじゃなく、質問しよう。
・自分が不安を感じることを伝えましょう。
・最新の情報をまとめてまわりに伝えること。
・現場で練習してください
■他の現場から学ぼう！
次は「他の現場から学ぼう！」というテーマで、3名のエンジニアが現場について紹介してくださいました。
■1人目：豆蔵の中佐藤麻記子さん
中佐藤さんはDAD本の翻訳者の1人ですね。
 | ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド (Object Oriented SELECTION) (2013/06/22) Scott W. Ambler、Mark Lines 他 商品詳細を見る |
9/30に豆蔵であったDAD本のイベントでも講演されていました。
そんとき私が書いたブログメモはこちら。
9/30(月) 豆ナイト Presents 「DAD はアジャイル開発の決定打となるのか？」に参加しました / makopi23のブログ： http://t.co/UEO2EDbREK
#dad_mamenight #DAD本
— makopi23 (@makopi23) 2013, 10月 7・メンバーが集まって、これから仕事を始めるさいに、やるべき最低限のことは？
→ 最初はごまかしていた。
・今聞かれたら、以下のように答えるようにしている。
１．目標を明確にする （例：エレベータピッチ）
２．最初のルールを決める （例：タスクボードを使おう、TDDやろう）
３．ルール改訂のルールを作る （例：レトロスペクティブ（ふりかえり））
・最近は最低これ３つを挙げるようにしている。
・何のためにそれをするのですか？という点を必ず最初に決めてもらう。
・最終的にお客さんの価値に結びつくから、いろんなプラクティスをやるはず。
→ それには何か理由があるはず。それを最初に決めてください。
・もう一つお願いしているのは、レトロスペクティブを必ずやりましょう、という点。
・最初に決めたことが出来てないなら、なぜ出来ていないのか？それをフォローするために何ができるのか？を考える。
・定期的に振り返りをやること。振り返りは絶対にやったほうがよい。
・インセプショんデッキを作るホントの価値は、それを作る「過程」にある。
・作られたスライドが綺麗なのが価値ではない。
・インセプションデッキを作る体験の過程で、道具を使って他の人とコミュニケーションができた、その過程が大事。
・「あぁなるほどな」という共通認識が作られることが重要。最終的なスライドは備忘録に過ぎない。
・みんなと会話する過程を大事にしましょう。
■2人目：SHIBATA Hiroshiさん
・RubyとかJenkinsのコミッターをやっている。
・一日に20コミットくらいしている。
・paperboyという会社に所属している。企業理念は「もっと、おもしろく、できる」
・支社１００人、東京本社に２００人の社員がいる。
・仕事の一例としてはカンファレンス発表やリンスタ、あとWEB+DB Pressという書籍の記事執筆も。
・自社で平鍋さんに講演してもらって、そこを突破口に、アジャイル導入研修、PO研修をやった。
・なんでこんなことやるかというと、POと開発チームにミッションをちゃんと伝えないとうまくいかないから。
・平鍋さんの一言「とりあえず、書いたものを部屋の壁に貼っておきなさい」
・言われたとおり、エレベータピッチとかアジャイルマニフェストを、ご飯を食べる位置に貼ってみた。
・最初の１ヶ月は評判が良かった。
・飲み会にならないとわからないことが、エレベータピッチを壁で貼ることでわかるようになった。
・エレベータピッチも、暗記して言えるくらいに作るようにした。
・サービス開発は終わりがない。なので、やらないことを決めないと永遠に作り続ける。
→ 「やらないことリスト」を作るようにした。
・インセプションデッキを書く際のポイントは、「新卒が理解できるか」が重要。
・ビジョンがわかることが重要。
・「おしかけOJT」というのを社内でやっている。OJTとして新人を部署に押し込む。
・部署でインセプションデッキを作ってないと、その新人にビジョンを伝えるのに2日くらいかかる。
・インセプションデッキが既にあると、それが2時間で済む。
・インセプションデッキがあると新卒のモチベーションも上がるし、仕事をやらせるにも有効。
・「このサービスのエレベータピッチってなんですか？」とまで社内で言われるようになって、「エレベータピッチ」が理解してもらえるようになり便利。
・インセプションデッキは意思疎通のコンテキストとして使っている。自分が便利だし。
■3人目：岩崎さん
・タイトルは「インセプションデッキ回想録」
・伝えたいことは、「やってみたらすぐに困る"つまづき"や、多少のことでくじけない心構え」
・最初のつまづきは「インセプションデッキで人が集まらない」
・確保できた時間が１時間しかなくて、時間がきたら途中でもそこで終わる・・・
・対策として以下をやった。
-やる気のある人で読書会
-たたき台づくり
-うまくいかなかったらやりなおす
-会議依頼は前々から
-２時間×２回やるようにしたりした
・次のつまづきは「人が集まりすぎ」
・エンドレスインセプションデッキになった。。。
・「過ぎたるは及ばざるが如し」とは言え、「及ばざるが過ぎたるが如し」
・ファシリテーターがすごく大事と気づいた。
・中間くらいを狙うようにした。（例：人が集まりすぎず、少なすぎず）
・大事なことは「やってみる、改善を続ける、みんなの経験を集める」
・引っ張る人の経験だけではダメ。
-根気よく探す
-根気よく育てる
-ファシリテーターを用意する
・それでもダメなことがある。でも、多少のことで挫けないこと。
・謙虚＆自省。ただ、自己満足はだめ。これが微妙なライン。
・インセプションデッキにはフォーマットがあるが、大事なことを「効率的に」話し合える形に改善できるはず。
★質疑応答：
Q.
インセプションデッキを作ろうとしない人は、どーすれば？
A.
アジャイルやインセプションデッキをやろうとしない人に、失敗していただく。
痛い目を見てもらい、じゃあ次にちゃんとやりましょう、と持っていく。
Q.
プロジェクトがが既に破綻していて、インセプションデッキが作れないことがある。
目の前のことを片付けるので精一杯な状態になっている。
そんなとき、どーやってデッキを作ればよいのか？
A.
無理なときはある。モチベーションを上げるために、目的を他に向けてみる。人材育成とか、技術習得とか。
Q.
チームが遠隔地編成のとき、どーすれば？
A.
朝会や夕会をSkypeでやって、最後終わるときに、お互い手を振って、「さよならー」とやってる。
ちゃんと顔を見るようにしている。
PS3とかPCを使って、互いの職場のリアルタイム動画を流し続ける。そうすると何が起こっているかわかる。
Q.
企画にインセプションデッキを使うのはどうか？
A.
作るのは良いと思う。
ただ、企画の段階で開発する人を呼ぶのは難しい。デッキ作りはみんなでやらないとダメ。
なので、もしやるなら、技術とか開発に明るい人を加えて少数でやるのはありかもしれない。
ちゃんと体制ができでからデッキ作りはやったほうがいい。
議論を促す道具としてインセプションデッキを使うのはあり。
ただ、１時間それをやったからといって、神企画が出るわけではない。
Q.
議論が行き過ぎた時はどうするか？
A.
議論が出ているところは途中で切っていく。
人と人、部門と部門、という対立ではなく、「事実」に持っていく。
根拠のない議論はストップさせる。
妄想での議論はやめる。
■基調講演 市谷聡啓氏
実質この日最後のセッションは、Devlove主催の @papanda さんです。
この話を聞いて、自分とダブる部分が何箇所もあってビビッた・・・
--
・今日は自分の話をする。
■2003年頃
・2003年頃は、組み込み開発のｎ次受けで３年目くらいからリーダーをやっていた。
・華はない。だが、きっと今後も食べていける。
・これでいいんだろうか・・・？
■達人プログラマー
・そんな時、達人プログラマーという書籍に出会った。
 | 達人プログラマー―システム開発の職人から名匠への道 (2000/11) アンドリュー ハント、デビッド トーマス 他 商品詳細を見る |
・その書籍には「常にあなたの知識ポートフォリオに投資すること」と書いてあった。
・他にも、ありがたい話が細かく書いてある。例えば「毎年少なくとも１つの言語を学習する」
・毎年１つ！？めっちゃ大変やん・・・
・達人プログラマーが言いたかったことは、技術の幅を広げることで、いろんなヒントが得られる、ということ。
・達人プログラマーは最初のマスターセンセイだった。
■Developer Summit 2003
・その年にはDeveloper Summit 2003にも出会った。デブサミの第1回開催だった。
・当時、企業色のないフラットなイベントはデブサミくらいしか無かった
・そこで、ウルシステムズの漆原さんの話が刺さった。衝撃的だった。
・泥臭いJ2EEの事例。なんてワクワクするんだ。
・もっと顧客の近いところで！オープンな技術でワクワクしたい。自分の殻を破りたい。
・こりゃ、多重請負ピラミッド階層を下から遡らにゃいかん・・・
・登ってやる！ということで東京に移ってきた。
■2006年～
・この頃の自分が多用していた言葉は「デスマーチ」
・「リーン開発の現場」では、デスマーチの定義を以下のようにしている。
→「誰もが失敗するとわかっている。それでもなお律儀に進んでいくプロジェクト」
・幸運にも、いろんな人に出会うことができた。
→ 木下史彦さん、平鍋さん、倉貫さん、鈴木雄介さん、角谷さん
・デブサミは自分の出来なさすぎ加減を痛感する場だった。
■コミュニティ
・社内の中でデブサミをやってみようと思った。
・XP祭り2007で初めて人前で話した。
・2008年に転機があった。「会社に閉じる必要は無い」と思い、Devloveというコミュニティを作った。
・コミュニティは野戦病院。ひとときの安らぎを得る場所。
・現場は激戦の日々だが実に楽しかった。毎日が試行錯誤だった。
・自分の仕事を呪っているほど人生は短くない。だから動き続ける。
■2010年
・デブサミに登壇した。今度からは登壇する側から手伝う側に回ろうと思った。
■2013年
・「リーン開発の現場」という書籍を翻訳して出した。
 | リーン開発の現場 カンバンによる大規模プロジェクトの運営 (2013/10/26) Henrik Kniberg 商品詳細を見る |
・自分の考えと合ってるなと思ったところがP.109にある。
→ 「理想とはたどりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ！」
・これは合意出来るな、と思った。
・リーンはスライドP.53の絵には出てこない。それは、リーンが「あり方のはなし」をしているから。
■今どういうところに気をつけているか
・角度を保て。
・毎日とりあえずやっていこか～、だと角度は0度。
・角度≠0だと、少なくともどこかに辿り着く。なので、少なくとも0にはしない。
・あとはガッツとパッション次第。
■理想ってなんだ
・Do the Right Things Right.（正しいものを正しく作る）
・きちんと作る。作っているものが本当にお客さんに必要とされているのか、を考える。
・ソフトウェアを創り上げるものとして、以下４つが関わってくる。
１．プロジェクト
２．ユーザ
３．顧客
４．チーム
・「誰が、誰と、誰のために、どういうルールで、何を」作るのか、を同時にやっていく。
・この５つの変数が時々で変わる。これをどーやってやっていくのかは難しいこと。
・理想に近づくには、上記１．～４．の境界を超えて行かないといけない。
■境を、超える
・・・本当に境界なんてあるのか？
・境界とは、自分が「ある」と決めたもの。
・ならば、それを超えるかいなかは自分の意思に関わってくる。
・そして、ここにいるあたなはもはや一人ではない
■不安
・文系だった私がソフトウェア開発に飛び込むにあたり理系の父が教えてくれた、たった一つのこと。
・「１日１個、何か学べ。そうすると、１年で３６５個の学びがある。そうなればなんとか戦えるやろ」
・今日の皆さんは１つの武器を学んだ。
・やばくなったらベースキャンプへ戻ればいい。違う武器をとれば良い。
★午後のセッションの感想：
まず、最後の市谷さんの話に、自分とダブる部分が何点かあって、ビビッた。
私も入社１～３年くらいは、ずっと「今のままでいいのか」とすんごく悩んでいた。
私がやりたかったのは、バリバリのプログラマ。技術力で生きていくエンジニアになりたいと思ってました。
恥ずかしながら、NHKの「プロジェクトX」に出演できるような熱いエンジニアになることが目標でした。
なのに私が就職した某SIerは、プログラムを書く仕事を任させることはほとんどありませんでした。。。
先輩の仕事ぶりをみても、それは明らかで。
今のままでも食べてはいける。でも、私が思い描いていた「エンジニア」の姿とは明らかに違う。
そんなわけで、自分で技術書とかを買いまくって、ひたすらプログラミングとかの勉強をしていました。
そんな時期に市谷さんと同様、私も「達人プログラマー」を購入。
忘れもしない、入社2年目の冬。「Code Complete」の次に手を取った本で、衝撃を受けた。
市谷さんが挙げた「毎年少なくとも１つの言語を学習する」という一文、私も常に頭にあった言葉です。
なので私も、一昨年はHaskellを勉強し、去年はPythonを勉強し、今年はRailsをかじり始め。。。
1年に1個、新しいプログラミング言語を学ぶ、という一節は、この本を読んで以来、頭から離れなかった。
あと、私も市谷さんと同様、ウルシステムズの漆原さんの講演を聞きに行きました。これもすごい偶然。
当時入社1年目、どうしても今の会社と自分のやりたいことのギャップに悩んでいて。。。
そんときは「漆原さんvs悩めるエンジニア10名くらい」の小さなディスカッションだったんですが、当時は新人にも関わらず自分探しに必死で、セミナーの案内を見て、即申し込みしたっけ。。。
その後は私も、社外の勉強会に出会い、デブサミとかにも参加し、コミュニティにも興味を持つようになり。。。
・・・な～んて、しみじみ、自分のこれまでを思い出し、重ねながら市谷さんの話を聞いてました。
市谷さんの凄いところは、Devloveというコミュニティを作る行動を起こし、今まで実践してること。
私はそこまで出来ないにしても、コミュニティにはなんらかの形で今後も関わっていきたいなぁと思います。
あと、パパンダパパの↓、いい言葉やな！
「１日１個、何か学べ。そうすると、１年で３６５個の学びがある。そうなればなんとか戦えるやろ」
つーか、今回のイベント、勉強会初心者をターゲットに絞っていたのは惜しいくらいの内容だったと思います。
申し込んで良かったです。
あと、スタッフさんにお知り合いが多かったので、最後の「不安を解消しよう！」というラスト１時間はみなさんといろいろ会話ささせてもらいました。
こーゆう場でこーゆう会話を出来るのも、コミュニティの良い所だなぁ～
関係者の皆様、ありがとうございました～
