えいのうにっき

a-knowの日記です

Agile Samurai BaseCamp に参加してきた! #agilesamurai

今日は、Agile Samurai BaseCamp(MarkCity13F(CyberAgent))に参加してきたので、メモをとってみましたー。(帰宅後にもちょいちょい手直しします!・2013/12/09 13:42 若干追記) 参加された方・参加できなかった方問わず、別途作成されているTogetterとも合わせて、何かのお役に立てればと思います(スピーカーの方々からもすぐに発表資料の公開がされると思います)!

参加してみた経緯

  • アジャイルとかスクラムとか、前の職場まではむしろ軽視してしまっていた
    • 「どうせ理想論、キレイ事でしょ」って思ってた
  • でも、転職して今の職場にジョインして、そのパワーの片鱗を体感する・見直す場面がちらほらと
    • 銀の弾丸ではないかもしれないけれど・・・
    • アジャイルスクラム・XP・カンバン・・・
    • スクラムマスターも在籍
    • 時には困難なプロジェクトでも、立ち向かう勇気がふつふつと湧くのを実感
  • 今までの自分は、エンジニアを取り巻く環境からの様々な期待を全くコントロールしようとしていなかった
    • 期待を背負い、また期待に押しつぶされ、時に期待を増幅させちゃったり・・・
    • 今度もし自分がそういう立場になったら、二度と同じ失敗はしたくない!
    • あと、現時点で一人しかいないスクラムマスターの何らかのお手伝いができるようになりたいなと思った

アジャイルサムライ原著者からのメッセージ

  • やってほしいこと
    • 学んだことを他の人と共有すること
    • 常によりより方法を探し続けること
      • リードしようとすること。改善しつづけること
    • 楽しい、素晴らしい週末にしてください。楽しんでください

基調講演(角谷信太郎)

  • 講演に用いられたスライド資料はこちら
  • 読んだ人どれくらいいるかな?・・・まぁまぁかな?
  • アジャイルなソフトウェア開発」に一番大事なこと?
    • お客さんにとって価値ある成果を届ける・・・毎週
    • 成果とは「ちゃんと動くソフトウェア
      • ちゃんと設計して、ちゃんとテストを書いて、ちゃんとマージされていて、使う環境でちゃんと使える・・・という状態
    • 「毎週」届けることは果たして可能か?
      • ここで「毎週」という単位は重要ではない・・・「これまでよりも短い間隔」ということ
      • とても大変
      • 実現しようと思うと、いろんな準備・段取り・話し合い・プラクティスをやらないといけない
      • ただ、すべてが「毎週届ける」ことにつながっている、ということを理解することが大事
  • 継続的にお客さんに成果を届けるために、もう一つ大事なこと・"whole one team"
    • チーム内の役割は大きく分けてふたつ
      • 何を作るのかを決める・顧客
        • 顧客もチームの一員
      • どうやって作るのかを決める・開発チーム
      • チームで「一丸と」なることが重要
  • なぜまたアジャイルの本を増やすのか?(なぜこの本を書いたのか?)
    • たくさんの本に書いてある内容をシンプルにしてくれるやつはどこにもなかった
    • とはいえ、まとめてるだけではなく、新しい要素も盛り込んでいる。そのひとつが「インセプションデッキ」。
  • なぜ「サムライ」?
    • peaceful warriorの心得を表現したもの
      • 受け入れること
      • 抵抗しないこと
      • 内なる平和
    • 実在の特定人物をイメージはしていない。「概念」
    • 今日参加してもらった皆さんには、この「概念」を持ち帰ってもらって、明日から現場で体現していって欲しいなと思っています
      • とはいえ難しい。本に書いてある通りにはいかないもの。個別の問題はどうしても個別。なので・・・
  • アジャイルなソフトウェア開発とはどういうものか?=ソフトウェア開発がアジャイルである、とは?
    • 協調性を重んじる環境で、フィードバックに基づいた調整を行い続けること
      • 環境を作ることと継続性。それを実現するために考え続けること
      • 方法論や手段など、それ以外のところばかり見ていてもうまく行きにくいと思います
    • いろんなところでいろんなことが言われていると思うが、ゴールを達成することにむかって協調できるか。これが何より大事。
      • 個々が当事者意識をもって。
    • 大事なのはプラクティスそのものではなくて、それを道具としてどう使って、現場を改善していけるか。し続けていけるか。
    • 私も継続的な活動をし続けることで、ようやく「アジャイル開発というものが受け入れられるための下地作り」ができてきたなと感じている
  • インセプションデッキ
    • 自分たちの向いている方向が顧客、ステークホルダーの向いている方向と合っているか?を確認するための手段
      • プログラマは詳細の管理者・システムの振る舞いを詳細に決める
      • それを実現するためにTDDをどう使っていけるか?を考えるようにしてください
  • まずは、自分より先んじている人から学び取ってみてください

インセプションデッキ、どうやって始めるの?(西村直人)

  • スライド資料はこちら
  • はじめてのインセプションデッキ

    • デッキって何?
      • そもそもなんで必要か?
        • プロジェクトをうまく進めるため。プロジェクトの行き先にスポットライトをあてるため
      • 「そんな大事なこと、はやく言ってよ」を減らす・なくすために。
      • プロジェクトをうまく進められるかをに確認して調整するための活動
      • みんな(プロジェクトに必要な人たち)が集まって、(うまく進めるための)大事なことを(話し合って理解して)調整する
      • インセプションデッキは質問に答えていくだけでできちゃいます!
        • 各自で異なる答えを統一する作業
      • 知らないことをはうまくできないし、みんなの理解は思ったよりバラバラ
      • ゴールとミッションはちがう
        • 達成しないと意味が無いもの、それがミッション
      • ゴールは2通り。ビジネス側のゴールと、製品としての(使う人にとっての)ゴール
      • 他にも大事なことはたくさん。
    • 一言で何がしたいかというと
      • プロジェクトにはいろんなものが期待されている
      • ただ、各期待が実現可能なものかどうかはわからない
        • 無理でしょと思っていても仕方ないし、できると思っていても仕方がない
        • できる調整を少しづつやる
  • どうやって作るの?

    • 準備・理解・調整・まとめ のサイクルで
    • 準備
      • プロジェクトをいざ進めようと思って話をしようとしてもいきなりは難しい。
        • 沈黙だったり空中戦になったり
      • お互いが話しやすいようにたたき台を用意するのが「準備」
    • 理解
      • それぞれの認識に差があることを明らかにすること
      • その差をみんなで理解すること、それが大事
    • 調整
      • どうしても発言力の強いひとに引っ張られる。。
      • それぞれの意見を尊重する!
      • みんなが実現可能だと思えるか、というのを一つの判断ポイントにして。
        • 一斉挙手とかで意思を確認しやすいようにする
    • まとめ
      • あの話って前に話してことと違ってきている気がする・・・というのをふせぐために
      • いつでも確認したり更新できるようにスライドにする。印刷して見えるような場所においておく
        • 共有フォルダ禁止
      • 困った時の判断材料にするために活用する
  • 一人でつくろう!

    • 集まる?対話?むずかしいじゃん
    • まずは自分の理解を一人でまとめてみよう
      • 頭のなかにぼんやり置いてるだけもしんどいし。
    • たくさんのインプット
      • 見聞きしたこと
      • 経験、直感
      • ドキュメント
      • 調べたこと
    • 準備:全部描けなくても構わない
      • 「分からない」ことを理解する
    • 理解:知っている人に聞いてみよう
      • 誰が使うのか・そもそもの経緯は・関わる色んな人の視点・自信のないこと
      • デッキじゃなくても質問しよう
      • 大事なことは、やり方にこだわらないこと
    • 調整:自分が不安を感じることを伝える
      • だれかができると思っているなら、その人にできると思っている理由を聞いたっていい
      • 多くの場合、「こう」と言われるとみんな黙ってる
      • ただそれだと何も変わらない
    • まとめ:最新の情報をまとめて周りに伝える
      • まとめ方がスライドなだけ
      • 周りから「もっとやって欲しい」といわれたら、「じつはこれみんなでやるものなんですよ」と広げていけばいい
    • 実施タイミング?
      • プロジェクトが始まる前後
        • 問題が大きくなってたり、日程に余裕があったり
      • 自分にとっての初日
        • できれば明日であって欲しい
      • ふりかえり
        • マンネリ化してたりする状況の打破に使ってみてもOK
      • 自分が悩んだ時
      • いつでも!
        • あなたがもやもやしているとき、きっと他のみんなももやもやしている
    • ぜったい現場でやったほうがおもしろい
  • 今日のテーマ

  • 単純にプロジェクトのもやもやを晴らすだけのもの?

    • プロジェクトの意図がわかってくる。すると関心が湧いてくる
    • それによりモチベーションが湧いてくる
    • そうなるとさらなる改善のためのアイデアがでてくる
    • 価値につながる
    • 徐々に広がっていく
    • デッキは強力な武器になる
  • 質問タイム

    • ひとつのプロジェクトに属するエンジニアが少なかったり、兼任エンジニアが多かったりする場合、こういうのをやることによって工数が足りなくなることがあると思うが。。
      • 「みんなが協力してやったほうがいい作業」として認識することが大事。「忙しいエンジニア」だけでやろうと思わなくてもいい
      • とはいえ、オーバーヘッドをなくそうとする活動も平行してできているか?も大事
      • 団結してアピールしてみては?
    • 当の本人のモチベーションが「言われたことだけやってりゃいいんでしょ」だった場合?
      • 人をくすぐるポイントは人によって違う。個人ごとにやり方を変えてみる
      • 発生した事故を利用する・・・再発を防止するために。
      • 成功体験から始める
      • エンジニアだけでやる。モチベーションのある人たちだけから始める
      • 無理やりくっつけることはない

体験してみよう!(市谷聡啓・西村直人)

ここでは、パッケージデザインとエレベーターピッチを、ワークショップ形式で作成してみました!

  • 6人でチームになり、その中で2人ずつでペアを組んで、既存のプロダクトに対するパッケージデザインとエレベーターピッチを考えることに。
  • 準備・理解・調整・まとめの1サイクルを、実際に手を動かしてみながらやってみた。
  • やってみての感想
    • やっぱり実際に手を動かす形式・ワークショップ形式はいいね!
    • でも、インセプションデッキを構成する他の要素こそ、やってみたかった・・・!
    • パッケージデザイン、実際にやってみて、日頃触れているパッケージの成り立ちが少し体感できた気がした
      • 「大げさなくらいに」とかw
    • エレベーターピッチも、相手に対してはもちろんのこと、日々の目先の開発に追われがちな開発者の道標としてもいいかもなぁとおもった

他の現場から学ぼう!

中佐藤 麻記子さん

  • アジャイルプロジェクトのコンサルとかやってます
  • インセプションデッキの使い方のひとつの実例としてご紹介できれば
  • はじめにやること
    • メンバーが集まって仕事を始めるとき、最初にやるべきことは?(必要最小限のこと?)
      • 目標を明確にする(エレベーターピッチ)
      • 最初のルールを決める
        • タスクボード使うとかTDDやるとか
      • ルール改定のルールを決めること(レトロスペクティブ・ふりかえり)
  • 私達の活動の目標設定をする
    • "私達は「○○」のために「○○」をします。「○○」のようになっていることが目標です"
    • お客さんに成果を届けること、そのために何が・なんで必要なのかを考える
  • 最初のルール
    • 定期的なレトロスペクティブの開催は必須
      • 開催頻度、場所、参加者 を予め決めておく
    • チームごとのルール
  • "本当の価値は作成されたモデルではなく、モデリングという作業そのものにあることを認識すること、これを重要な思想として採用すべきだ。"
    • きれいにモデルを作成することなど、そのことそのものに意味があるのではなく、「それがチーム内での共通認識になった」ということのほうが大事

柴田さん(@hsbt)

  • スライド資料はこちら
  • ペパボ
  • ぼくはエンジニアなので、コードを書くことで世の中の問題を解決していくのが仕事なはずなのですが・・・
    • 開発プロセス自体もなんとかしていかないと、いいものを継続的に作っていけない
  • プロダクトオーナーから開発チームへのビジョンと価値、優先順位の内容の透明性を担保しなければならない
  • ぶっちゃけイマイチな部分もあった
  • ランディングページをパッケージデザイン的な位置づけで捉える
  • エレベーターピッチは暗記できてるくらいじゃないとやばい
  • やらないことリストを作る
    • 受託開発と違って終わりがないので
  • 自分の部署にいきなり来た新卒が理解できるかどうか?って、意外と重要
    • ビジョンがわかればなんとかなる
  • 共通言語としての「エレベーターピッチ」「やらないことリスト」があるとチーム内でも便利

インセプションデッキ回想録(MTI 岩崎さん)

  • 2年前からスクラムマスター
  • やってみたらすぐに困るつまづき
    • ちょっと忙しくて・・・集まらない
    • なんでここにいるんだっけ?・・・勉強不足
    • 静寂
    • 1時間で!・・・時間がない
      • 前々からやっとくとかたたき台つくっとくとか
  • がんばって対策したら次に困るつまづき
    • 集まりすぎ
    • エンドレス
    • 大盛況、好き勝手言い出す
      • 過ぎたるは猶及ばざるが如し
  • 結局どうやったらいいの?
  • それでもダメなこともある
    • 多少のことでくじけない
      • 謙虚&自省
  • インセプションデッキのあの構成が完成形?
    • 大事なことを効率的に話し合えることが大事
    • 改善し続けられるはず
  • 質疑応答
    • スクラムを広めようとしているがつまづきがおおく心が折れそう。なかなか人を巻き込めない。どうすれば?
      • いきなり多くの人を巻き込もうとしても無理。興味を持っている人から攻める。興味ある人たちだけで進めてみる。
      • それによりなんかしら成果を出す。そのためには多少ずるい手でも使う
        • たとえば予め課長に話を通しておいてから、後輩に挑戦させ、成功体験とさせる。そうするとその後輩が心強い発信役になる
        • 折れたところは強くなる。骨折と一緒!w
    • ウォーターフォール型開発が主流で周りに知っている人がいない。。どういう順番で進めていったらいいか。おすすめな順番?
    • 上司などにアジャイル手法をやりたいというときに、これといった売り文句がない。。
      • 頑として聞いてくれないときには、一度痛い目にあってもらって、それを元に。
    • 破綻している(もはやよくわからずにやっている・作らざるを得ない)と思われるプロジェクトに対して・目先の仕事にも追われている状況でインセプションデッキ、作った方がいい?
      • そのプロジェクトをやることで得られることをメンバー内で確認しあう、とかはどうでしょう?
        • 身につく技術なりなんなり。
    • チームが遠隔地にまたがって編成されている場合のコミュニケーション手法とか気をつけていること?
      • 朝と夕とで顔を見る
      • PCとかを一日つけっぱなしにして、雰囲気を出来る限り共有できるようにする
    • 企画立案の段階からインセプションデッキを作ってみてもいいんじゃないかと思った。そういうのやったことあればいろいろ教えて欲しい。
      • 作るの自体はいいと思う
      • ただそこに開発者を呼ぶことは難しいと思うので、リーダークラスを呼ぶくらいにとどめて少人数でやるのがいいと思う
      • あと短く。長いと無駄だと思われる
      • 後半の5枚はやらないほうがいいかな。エレベーターピッチくらいでいいかも
      • 議論を呼ぶための道具として捉えてます
    • 議論が起こりすぎてしまったとき・膨らみすぎてしまったとき、どうする?
      • 対立しているところはすぐに切っていく。対立じゃなくて、事実に即して議論できるように持っていく
      • 根拠がないせいで盛り上がることも多い。そういうのもすぐ仕切りなおす

基調講演(市谷聡啓)境界なき現場を、行け

  • 講演に用いられたスライド資料はこちら
  • 自分の話をします
  • 明日から頑張れっていうけど・・・。最初の一歩を踏み出すには十分な武器を手に入れられたんじゃないかっていうけど・・・。
  • 大阪で受託開発・組み込み系
    • 日常のしごとをするのに十分な技術さえあればいいのか?という疑問
      • 華はないけどきっと食べていける。でもこれでいいんだっけ?
  • 「達人プログラマー」に出会う
    • 「常にあなたの知識ポートフォリオに投資すること」
    • 「毎年少なくともひとつの言語を学習する」
    • 最初のマスター・センセイ
  • devサミに出会う(2003)
    • 当時数少ないフラットなイベント
    • 泥臭いJ2EEの事例を聞いてワクワクした
  • 東京に出てきて色んな人に出会った
  • デブサミは自分の出来なさ加減を思い知るための場
    • 自分たちももっと良い開発がしたい
  • 現場を超える場を作る
    • 会社内に閉じる必要はないなと
    • devloveを作った。色んな現場とのハブとなるために
    • コミュニティは野戦病院
    • 激戦の日々だったが楽しかった
    • 毎日が試行と学習だった
  • デブサミの母との出会い
    • 同じ思いを持っていたことが判明
    • 自分の仕事を呪っているほど人生は短くない。だから、動き続ける。
  • リーン開発の現場 P.109
    • "理想とは、たどりつくべき場所のことではなく、ありたい姿に向かい続けること"
  • リーンって変わってるなぁと
    • リーンは道具ではなく、「在り方」
  • 「角度を保た」なきゃ行けないなと思っている
    • 目先の仕事だけをこなす・・・角度ゼロ
    • 角度≠0、なら、少なくともどこかにたどり着く!
    • あとはガッツとパッション次第
  • こうありたい
    • 正しいものを正しくつくる
  • ソフトウェアを作り上げるもの
    • プロジェクト・ユーザー・チーム・顧客
    • それぞれを構成するメンバーが自分たちのこと・自分たちの職務を全うすることばかりを考えていたら、「正しいものを正しくつくる」なんてことできるはずない
    • 境界を越えよう、境界をなくそう
  • そもそも境界ってあるの?
    • 境界とは、自分が「ある」と決めたもの。
    • ならば、それを超えるか否かは自分の意思、なはず
    • あなたは一人じゃない、Base Campに出てる人だけでもこれだけいる
  • それでも不安はやっぱりあると思う
    • 父からの言葉「1日1個、何かを学べ」
      • 1年で365個学ぶことができる
  • 今日学んだ武器を手に進むべきは、現場
    • やばくなったらBase Campに戻ればおk

TDDセクションの方について

スライド資料

その他の関連記事などについて(2013/12/20 追記)