2013/12/17(火) JJUG ナイトセミナ 「師走の Jenkins 祭り」に参加してきました。
DoorKeeper
http://jjug.doorkeeper.jp/events/7490場所は日本オラクルさんです。
参加者は180人くらいでしょうか。
最近、仕事でJenkinsを使わざるを得ない立場になり、ちょうど良い機会、ということで参加しました。
以下、個人メモ。
■「Jenkins運用3年でわかったこと」岡崎隆之氏 (@watermint /
http://watermint.org/)
■@ITの記事を執筆・継続的インテグレーションを始めるための基礎知識
http://www.atmarkit.co.jp/ait/articles/1302/13/news030.html■2011年・マスターノードを１つ立ち上げた。
・iOS向けのビルドをやっていた。
・Jenkinsを入れる前はビルドも手作業だった。エンジニアが頼まれるたびにビルドを作って渡していた。
→ エンジニアのところにタスクが集中し、ビルド依頼を受け取って渡す作業に忙殺される。
→ Jenkinsを導入すると、そこを間に入ってやってくれるようになる。
・ビルドの仕方が秘伝のタレになっていたりで、Jenkinsに乗せるのが大変だった。
→ 最初に2ヶ月くらいはビルドが通らない。
・
ビルドというわかりやすいところから導入して、社内でJenkinsの普及活動をした。
・この時代はJenkinsを知らない人も多くて、啓蒙して行かないとまずいな、と思った。
・Jenkinsをどこに立てようかと思って、リッチな環境がもらえなくて、非力なLinuxの仮想サーバでやってた。
→ ビルドはスレーブサーバでやらせて、マスタサーバはビルドを監視するだけの構成とした。
→ 3年経って、今ふりかえって、この構成にして良かったと思っている。
・スレーブサーバを立てるとなると、Jenkinsを触らざるを得ない状況になる。
→ みんながJenkinsを触るようになった。
→ そうなると、ディスクが足りないとかの事象に遭遇するようになって、修正してもらえるように鳴った。
■2011年まとめ(1) とにかくすぐわかるメリットを体感してもらう
・大きな組織にJenkinsを適用しようとするほど、エンジニアでない人に「ボタン押せばビルドができるよ」ということから説明する。
→ 失敗すると赤くなる、ということで、エンジニア以外の人にもメリットがわかりやすい。
・使ってくれるユーザを増やす、育成する
(2) 使ってくれるユーザを増やす、育成する
・やっぱ、使ってくれる人がいないと浸透しない。
・スレーブを作るスクリーンショット付きの手順書を渡したりとか、ログを見てエラー直してあげたりとかして、育成した。
■2012年・Master Nodeが3～10個くらいになって、自分でjenkins立てる人が増えた。
・半分くらいのプロダクトはjenkinsを使うようになった。
・2012年に大きかったのは、2011末にGithub Enterpriseを入れて、Jenkinsと連携して開発できるようになったこと。
・Githubで開発する場合は、パッチとどういう変更かの情報を一括で渡せるPull Requestが使える。
・Jenkinsを使ってGithubからPull Requestを送ると、JenkinsがPull Requestが正しいかをユニットテストしてくれる。
→ それでテストが正しいかをJenkinsから通知する。
・簡単なテストはJenkinsの独立した環境で実行するようにした。
→ 忙しくなるとすごく効果が出た。
→ いろんなPull Requestが来た時に、人手だと捌けないけど、これで行けるようになった。
・Jenkinsを開発以外にも導入するようにした。
→ 翻訳しないといけないものをスプレッドシートに書いてJenkinsに送ると、翻訳して返してくれるようにした。
■2012年まとめ2012年はGithubも入ってきて、みんな工夫しはじめた。Pluginも多いので、いろんなことがサポートできる。
(1) なるべく多様なワークフローを許容する
(2) 事前説明を手厚く、サポートもしっかり
■2013年・マスタノードは前年と同じくらいで、ジョブが倍増した。
・ほぼ新しいプロジェクトは、Jenkinsｗあらかじめ検討している。
・CIが何もない段階から、最初からテストをしよう、という風土ができた。最初から２年くらいかかった。
・浸透してきたとよくわかるのは、Jenkinsが落ちてるときに来るクレームがたくさんになったこと。
→ いろんな人のワークフローに組み込まれているんだな、と思った。
■2013年は苦難の歴史・事件簿をいくつか紹介する。
(1) 事件簿１：JenkinsからGithubへのDOS攻撃
・JenkinsがGithubをポーリングする設定にしたプロジェクトがあって、そのジョブをみんながコピーして使っていた。
→ ジョブの数が増え、DOS攻撃のようになった。。。
・そのときはポーリングの感覚を調整して対応した。
・日々監視していくのが解決策の１つ。
・ジョブをスケジューリングする、というのをユーザに学んでもらわないといけない。
・ポーリングを短くしていた理由は、Github EnterpriseからJenkinsにフックを飛ばすのがわからなかったから。。。
(2) 事件簿２：バージョンに起因するバグ
・ある日、Jenkinsのバージョンを上げたら、GitからCloneできなくなった。
→ GitのPluginが原因だった。泣きながらバージョン戻してみたりして解決した。
・Jenkinsをバージョンアップしたら、特定のジョブだけ見えなくなったことがあった。
・Rubyのpluginがおかしくて、依存性を正しく読み込めずRubyのプロジェクトがうまくロードされなかったのが原因。
→ Pluginのバージョンをすこしづつ変えて対処した。
■2013年のまとめ・チームごとの用件が多様化し、一元管理が難しくなってきた
→ でも、禁止するとモチベーション下がるし、勝手にJenkinsを独自に立ち上げられたりするので、そうしないようにした。
→ それでも多様性を失わない運用が必要
■2014年に何をしたいか(1) JenkinsでJenkinsのCIをしたい
・Infrastructures As a Code
・Jenkinsのpluginのバージョンを上げても、Jenkinsでテストしてからリリースするようにしたい。
・Vagrant + chefで試している。
・うまく運用に乗ったらブログで公開したい。
(2) マスタをVagrantとかでバージョン管理した上で他のチームに引き渡すようにしたい。
・チームの条件に応じていろんなバージョンを選択できるようにしたい。
・Vagrantを組み合わせてチームごとのJenkinsを提供できるようにしたい。
―――
・３年経って、当たり前の進み方しかしない。
・
現状の業務を止めずに変化を加えるには、年単位の時間が必要。・良いツールがあると「全社で標準化しよう」という話が出るが、分割統治をして多様性を受け入れるのが大事だと思った。
・そうしないと反発を食らって使われなくなる。
・
標準化してコストを下げるのではなく、多様性を受け入れて生産性を上げるのが良いのではないか。
―――
■質疑応答Q1.・Jenkins普及の専任部隊がいらなかったのは？
A1.・専任にするほど大きな問題が起こってない。
・戦略的に生産性の基盤を変えよう、という話があれば専任もありかも。
・秘伝のタレを作ってる人は、CIには同意してもらえるけど、手を動かすとこまで手を貸してくれなかった。
Q2.・多くの人がJenkinsを使い始めると、権限まわりはどうしたか。
A2.・Jenkinsのユーザは、今は200人くらい。権限がフラットでもぎりぎり統治がとれてる人数。
・これからは、インスタンス単位で分割して他に影響がでないようにしたいと思っている。
・チームによって要件が違うので、適切なインスタンスを分割したいと思っている。
Q3.・多様性を持たせて運用する、と言っていたが、ルールは決めたか。
A3.・明確なルールは決めてない。
・pluginを入れるとか設定を変えるとかは、チャットで一言ください、としている。
・基本的に、これをインストールするの止めましょう、とはしていない。
・あと、アナウンスをしっかりしましょう、としている。
・サーバダウンとかアップデートとか、ノイズにならない程度にアナウンスするようにしている。
Q4.・Jenkinsバージョンアップで動かなくなったと言っていたが、バージョンアップしたほうがいいのか。
A4.・バージョンアップの動機はセキュリティだった。
・バージョンの差が離れすぎるとpluginのバージョン差が大きくて辛くなる。
・１ヶ月に１回くらいバージョンアップするようにしている。
Q5.・Jenkinsの情報がなくて詰まっている。どこから情報を集めたのか。
A5.・ググる。
・さっき述べた事件があったときは、JenkinsのJIRAで検索したりとかした。でも英語できないときついかも。
・Twitterでつぶやくと川口さんが拾ってくれたりとかしてもらった。
・Jenkins日本ユーザ会に入ってみて聞いてみるのが一番やりやすいかも。
Jenkinsにみる互換性を損なわないコードの保守テクニック発表者 : 川口耕介氏 (@kohsukekawa /
http://kohsuke.org/)
Jenkinsというよりも、Javaでライブラリを開発する際の黒魔術(？)についてがメインでした。
ここでは省略！
★感想：私もどちらかと言えばJenkinsを導入する側なので、岡崎さんのお話は参考になりました。
まずはメリットを感じられるところから着手、標準化よりも多様化、教育や普及も大事、といったご意見はなるほどなぁ、と。
あと川口さんの講演は凄すぎて、ちょと俺のJavaレベルでは後半ついて行けなかった！
こーゆうスゲー人の話を聞くのは刺激的ですね。俺もあんなんなりたい。。。
勉強会関係者の皆様、ありがとうございました。
2013/12/1(日) 「システムテスト自動化カンファレンス2013」に参加してきました。
公式サイト
https://sites.google.com/site/testautomationresearch/eventTogetter
http://togetter.com/li/597476場所は日本オラクルさんです。
参加者は200人くらいでしょうか。申し込み開始から早々と満員御礼になるほどの人気ぶり！
最近弊社でもDevOpsやら継続的デリバリーやら、ちらほら耳にするようになり。。。
そんな私も、それらをテーマにした社内ワーキングに放り込まれました。
ということで、テスト自動化は私の業務にも直結しており、このイベントは前々から大変楽しみでした。
開催から10日ほど経ってしまったが、復習のためメモをダラダラを書き起こしてみる～
■開会の挨拶と注意事項10時開始の15分くらい前から、本カンファレンスの趣旨とかの説明がありました。
意外だったのは、単体テストレベルではなくシステムテストレベルを自動化のターゲットにしている、とのことでした。
タイトルにもあるように「システムテスト」自動化のカンファレンス。興味深い。
■よりよいテスト自動化のためにちょっと考えてみませんか？
― スコープ、ROI、プロセスを中心に ―
近江 久美子 氏 ■１．このセッションは何？・よりよい自動化を達成するために、万能薬はない。
・ソフトウェアのユーザに価値がある単位で行われるテストの自動化を扱う。
・単体テストレベルはスコープ外。
■２．「よいテスト自動化」？■テスト自動化の目的・例：効率化したい
「テスト自動化の学習の時間や準備の時間 ＜ テスト自動化しない場合の再実行にかかる時間」になるようにする。
・手動で行われるテストは単純に置き換えられない。
■３つのスコープから考えてみる１．スコープ
２．ROI
３．プロセス
■３．よりよりテスト自動化のために★３－１．スコープを見極める・自動化できる範囲と、自動化しておいしい範囲は必ずしも一致しない
・自動化しておいしいところを明確にして、自動化する範囲を絞り込む
・思わぬ追加作業が発生しないよう、ステークホルダー間で認識齟齬がない合意を行う
■スコープを明らかにする ①どの （工程とか）
②どこ （プロセスとか）
■「どの」テストを自動化するか ①テストレベル
単体テストなのかシステムテストなのか
②テストタイプ
機能テスト、使用性テストなのか、etc
■テストの「どこ」を自動化するか ①プロセスやアクティビティ
・疑問１：テストって、こんなにアクティビティってあったかな・・・？
（例： テスト計画、テストの分析と設計、テスト実装と実行、評価、レポート、終了）
・疑問２：テスト実行じゃないの？
■テスト実行は、3要素に分けられる 1. DRIVE ・・・ 操作、駆動
2．JUDGE ・・・ 判定
3. REPORT ・・・ 報告
■「自動化可能かどうか」と「自動化必須かどうか」の2点から見極める ①自動化しないと実現できないテストか？
②自動化できるテストか？
③自動化するとおいしいテストか？
■自動化しないと実現できないか？ - 例１： 数百人の接続想定の性能テスト
- 例２： 数ヶ月間連続稼動させる耐久テスト
- そのテストが「必要ならば」自動化は必須
■自動化できるか？ ① 自動化しては意味が無いものはNG
（例：リハーサルに近いもの。それは本番同等に動かす必要がある）
② 制約があり自動化できない
(a)
乱数や外部情報に影響されて変わる部分。
シミュレートでできないことはないが、そこまでやるかどうかを考えること。
(b)
採用した自動化ツールができないこと
例１：印刷物の比較
例２：複数のツールを組み合わせる場合の連携（連携したほうが嬉しいのか）
■自動化は可能だが必須でないテストは？ ・自動化の利点が活かしやすい部分は・・・
１．繰り返し行う部分
２．仕様が変わりにくい部分
（仕様変更にすぐに追随できないとすぐに使えないテストになる）
・回帰テスト、スモークテスト、GUIよりAPIのテストから考えてみるのがおススメ
（画面はけっこー変わるので）
★３－２．ROIを評価する■その自動化、どのくらい価値があるか？・ROIの評価で、おいしいとこだけ自動化する。
・保守・派生プロジェクトでも、時にはROIの観点から見直し、改善につなげる
・利益と投資に分けて考える
■利益・最終的にはプロジェクトやプロダクトの利益につながらなくてはいけない
・テストにもたらされる変化を通して利益を分析する
・自動化はテストの品質・コスト・時間（効率）・スコープを変える
①品質
- 再現性、トレーサビリティの向上
- 自動化準備を通した理解度向上の影響
（自動化はあいまいをゆるさないので、事前に考えるきっかけになる → 結果的に品質向上に寄与）
②コスト
- 人件費を人間しかできない作業へ振れる
- 同じ作業の繰り返しのコスト減
③時間
- 案外、準備に時間がとられる。
- 人間とあまりにも違うスピードでテストやってもダメなことがある。
- でも、イイ点がある。それは夜間にできちゃう点。
- 属人性の低下、知識伝承の効率化（テスト実行の自動化ならば、手順やデータを確認すれば全部載ってる）
④スコープ
- 手動では困難なテストが可能に
この４つで考える。洗い出したら利益に結びついているかを確認する。
■投資・４つの軸×時間で考える （時間による変化もお忘れなく）
・４つ ＝ ツール、テストプロセス、人、プロダクト
・時間： 初期コストと運用テストは異なる
・ツール： 外部調達か内部でつくるかで違いがある
・自動化により、プロセスや必要な人材が変わることがある
・プロダクトが自動化により生まれる制約を満たすか考慮する必要がある
（HTMLのボタンに適切なIDを振りましょう、という制約とか）
■注意点・目的にあった利益と投資で計算する
・投資も利益も、時間やコストで計算する場合は更に見積りが必要
・厳密に評価するとそれなりにコストと時間がかかる
・おススメは、濃淡をつけてROIの評価をすること。
・全部見通すのは困難。ROI評価それ自体が割高になる恐れがある。
★３－３．プロセスを見直す・適したプロセスでなくてはおいしくならない
・どこが手動テストと異なるか？ → 自動化するとそこのテストがなくなる
・ほんとうにそれだけ？
■テスト実行の場合・テスト対象を自動化しやすいつくりにする作業が追加に
・自動テストスクリプトの設計、実装、セットアップが追加に
・自動テストスクリプトの構成管理が追加に
・レポート作成の時間は減る
→ 負荷が変わるものと、タイミングが変わるものがある
・テストを書きやすいようテストチームが実装チームに依頼したり
→ テスト以外の組織とかにも注意する必要がある
・自動化しても、テストプロセスが機能していなければ意味が無い
→ テストプロセスの整備からやりましょう
・自動化で変わっちゃう部分もあるが、変えることができる部分も発生する
★３－４．まだまだあるトピック■スキル、チーム・いろいろ知らなければいけないことが出てくる
・スキルを持った人を集めるか、やり方を工夫することでスキルが違う人同が士分担するアプローチも考えられる
・人材の話はこの後の辰巳さんの話でも登場する
■自動化されたテスト実行のバグの分析・手でテストしている時と違う観点が出てくる。例えば、テスト自体が誤っているとか
・自動テストスクリプトのテスト実行前のレビュー実施
・自動テストスクリプトの設計、コーディングのルール定義
・ログやレポートの出力の設定（ちゃんとわかるように）
■４．おわりに・テストは、プロジェクトやプロダクトの見える化を促進する
（バグ、リリースしてよいかどうか）
・テスト自動化により、テストは柔軟になる、幅が広がる
・テスト自動化を通して、よりよりテスト、よりよいプロジェクト、プロダクトを！
■事例から見るテスト自動化のポイント
TABOK関西 ■１．検これについて by 前川さん・活動は、レビューとテストの自動化が主な対象
・レビューについては、テスト設計コンテストのレビューとかをやってる
・テスト自動化については、自動テストのパターンを集めている。テスト自動化の事例をコレクション中。
■２．自動化事例をまとめてみた by 森田さん・自動化の事例を２軸にマッピングした「テスト自動化マップ」を作ってみた
・アンチパターン
①自動化ハイ ・・・ 自動化自体が目的になる
②建て増し旅館 ・・・ わけがわからなくなる
■３．事例紹介 by 川口さん・タイトル「事例からみるテスト自動化のポイント」
１．ファクトリーオートメーションとは
製造工程を自動化したもの。
・作業ミス軽減
・効率向上
・安全性の向上
２．システムテスト「自動化」の歩み
・２つのフェーズがある。
(1) フェーズ１：初めての自動化
・何をされてもとまらない用にできた。でもやりすぎた。
・稼動までの期間や保守が半端ない
・自動化の効果を実証しないくらいならやらないほうがいい。
・仕事が楽しくなったかどうかで検証した。
(2) フェーズ２：自動化の加速
・フェーズ１：一撃必殺
・フェース２：波状攻撃
・フェーズ１：建て増し旅館、ビッグバン自動化
（自動化の前に、テストとして健全な認識を持つことから始めましょう）
・フェーズ２：自動化ハイ
（もっと上手くできないもんか？）
自動化の難しさの根っこに気づく
・人がやってた仕事ってすごく賢い
・無意識にやっている。そこは自動化しにくい
・目に見えることだけ自動化すると様々なものが隠蔽される
自動化の成功の秘訣に気づく
・効果の計測、振り返りをベースとしたたゆまぬ改善
パラダイムシフトが起こった
・人間の役割を自動化することの難しさを理解する
・無意識を意識化する。人のやってることの表面化・形式化させることが第一歩
・人の思考や行為を自動化するには、高度な専門知識とかが必要
テストプロセス全体を通して
・無意識の意識化
・テスト自動化に必要な技術を整理
・テストシステムとしての最適化・構造化
テストに必要なアクティビティが最適に自動化されたシステムを目指す。
オムロン創業者・立石一真氏の言葉
「機械にできることは機械に任せ、人間はより創造的な分野で活動を楽しむべきである」
■ハンズオンセッション実践で学ぶ、効率的な自動テストスクリプトのメンテナンス
伊藤 望午後はSeleniumのハンズオンセッションに参加しました。
あと、環境構築やサンプルプロジェクトはこちらから。
https://sites.google.com/site/testautomationresearch/event/conference2013_handson私、Seleniumはこれまで、横浜のJUnit写経会で触った程度でした。
そんとき書いたブログはこちら。
『JUnit実践入門』写経・実践会 in 横浜 #6 (特別編) に参加しましたhttp://makopi23.blog.fc2.com/blog-entry-74.html今回のハンズオンイベント、とても勉強になりました～
教材もサンプルも充実しているし、補助のTAさんも人数いたし。
Seleniumを初めて触る人にとっては非常にわかりやすい教材だと思います。
makopi23のハンズオン成果物をGithubにアップしておきました。
https://github.com/makopi23/STARHandsOn-release
招待講演/クロージングセッションテスト自動化のこれまでとこれから
辰巳 敬三 氏 ハンズオンが終わった後、これが最後のセッションだったので聴講しました。
これまでのテスト自動化の歴史について纏められていました。
よくこれだけ調べたもんです。興味深い内容ですね～
★感想：非常に勉強になりました。
特にオープニングセッションの近江さんの講演は、テスト自動化について非常によく纏まっていました。
この資料、あとで見返すだけでもとても復習になりました。
あとSeleniumのハンズオン、これも素晴らしい。
実際、このハンズオンで学んだことを早速業務に使ってみました。
こーゆう、ハンズオンで実際に手を動かして自動化を体験するのはすごくいい取り組みですね。
資料もサンプル題材も、今後もずっと使えるものに纏まっていたと思います。
ハンズオンの平行して実施されていたセッションが聴講できなかったのが悔やまれます。
が、大変充実した１日で、勉強になったし楽しかった。
関係者のみなさま、ありがとうございました～
2013/12/8(日) 「Agile Samurai Base Camp」に参加してきました。
公式サイト
http://www.agilesamuraibasecamp.org/DoorKeeper
http://agilesamurai-basecamp.doorkeeper.jp/events/5844Togetter
http://togetter.com/li/600193ということで、前半の午前分を先日メモに書きました。
「Agile Samurai Base Camp」に参加しました ～其の壱～ （午前の部）
http://makopi23.blog.fc2.com/blog-entry-124.htmlその続きで、今日は午後のセッション分のメモをダラダラと書き起こすことにする。
■体験してみよう！ 市谷聡啓氏・西村直人氏午後のセッションは、実際にインセプションデッキを作るワークショップから開始です。
以下のプロセスで進めていきました。
■チーム分け・6人1組で各テーブルに座る。
・各テーブル2人ペアを3組作る。
・3組それぞれのが、以下のお題から１つを選びインセプションデッキを実際に書いてみる。
■サンプルのお題１．アジャイルサムライ
２．iPhone
３．アメブロ
■「パッケージデザイン」の作成・お題を選んだら、次に「パッケージデザイン」を作ります。
・ちなみに「パッケージデザイン」は「製品ポスター」とも呼ばれるそうな。
・ポイントとしては、「製品としてのゴール」を定め、使う人にとってのメリットを書くこと。
・まず「プロダクトの名前」を決める。
・次にアピールポイントを思いつく限り書き出し、その中からベスト３つを選択する。
・次に、「最高のキャッチコピー」を考える。
・それらが揃ったら、ユーザに手にとってもらえるようなポスターを書いてみる。
・機能面をつらつら書くのは嬉しくもなんともない。「使う人にとっての嬉しさ」を書くこと。
・キャッチコピーは若干、胡散臭いくらいでちょうどいい。ただし嘘はやめましょう。
作り方を要約するとこんなカンジらしい。
１．アピールポイントをブレストする
２．３つに絞る
３．キャッチコピーを考える
４．ビジュアルを考える
５．描く
私のペアはお題として「アジャイルサムライ」を選択しました。
というわけで書いてみた～
・・・いや、うん。時間が無くて残り1分くらいでダッシュで書いたんだ。。。
ペアの方とブレストして意見出しながらやったんですが、なかなか難しいですね。
アピールポイント３つはすぐ選べたんですが。。。
キャッチコピーって1個かつ短い言葉で表す必要があるので、2人が考えた案を両方とも1語に含めるにはどうしたらいいか、みないなので無駄に悩みました。
逆に人数多いほうが、キャッチコピーを１つに集約しやすいような気がする。
2人だと、どっちの意見を取るか？みないなカンジになりがちでした。反省。
■「エレベータピッチ」の作成次に、ビジネスとしてのゴールを簡潔に表すためのエレベータピッチを作りました。
以下の内容を含めます。
・課題
・ターゲット
・嬉しさ
・他に何を使う
・他にない特徴
作る際のポイントは、以下をよく考えて書くこと。
１．どんな課題を解いてくれるの
２．どんな人が嬉しいの
３．何が嬉しいの
４．これがなけれあば何を使う？
５．これを使うべき理由は？
ってなわけで、上記5点について、こんどは個人で書いてみた。
書いた後は、ペアで見せ合った後、同じお題で書いてみた参加者で集まって意見交換の場が設けられました。
こーゆうディスカッションの時間があるのは良いですね～
最後に西村さんの纏めがあり、このセッションは終了となりました。
・次に、デッキじゃなく、質問しよう。
・自分が不安を感じることを伝えましょう。
・最新の情報をまとめてまわりに伝えること。
・現場で練習してください
■他の現場から学ぼう！次は「他の現場から学ぼう！」というテーマで、3名のエンジニアが現場について紹介してくださいました。
■1人目：豆蔵の中佐藤麻記子さん中佐藤さんはDAD本の翻訳者の1人ですね。
9/30に豆蔵であったDAD本のイベントでも講演されていました。
そんとき私が書いたブログメモはこちら。
・メンバーが集まって、これから仕事を始めるさいに、やるべき最低限のことは？
→ 最初はごまかしていた。
・今聞かれたら、以下のように答えるようにしている。
１．目標を明確にする （例：エレベータピッチ）
２．最初のルールを決める （例：タスクボードを使おう、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年頃は、組み込み開発のｎ次受けで３年目くらいからリーダーをやっていた。
・華はない。だが、きっと今後も食べていける。
・これでいいんだろうか・・・？
■達人プログラマー・そんな時、達人プログラマーという書籍に出会った。
・その書籍には「常にあなたの知識ポートフォリオに投資すること」と書いてあった。
・他にも、ありがたい話が細かく書いてある。例えば「毎年少なくとも１つの言語を学習する」
・毎年１つ！？めっちゃ大変やん・・・
・達人プログラマーが言いたかったことは、技術の幅を広げることで、いろんなヒントが得られる、ということ。
・達人プログラマーは最初のマスターセンセイだった。
■Developer Summit 2003・その年にはDeveloper Summit 2003にも出会った。デブサミの第1回開催だった。
・当時、企業色のないフラットなイベントはデブサミくらいしか無かった
・そこで、ウルシステムズの漆原さんの話が刺さった。衝撃的だった。
・泥臭いJ2EEの事例。なんてワクワクするんだ。
・もっと顧客の近いところで！オープンな技術でワクワクしたい。自分の殻を破りたい。
・こりゃ、多重請負ピラミッド階層を下から遡らにゃいかん・・・
・登ってやる！ということで東京に移ってきた。
■2006年～・この頃の自分が多用していた言葉は「デスマーチ」
・「リーン開発の現場」では、デスマーチの定義を以下のようにしている。
→「誰もが失敗するとわかっている。それでもなお律儀に進んでいくプロジェクト」
・幸運にも、いろんな人に出会うことができた。
→ 木下史彦さん、平鍋さん、倉貫さん、鈴木雄介さん、角谷さん
・デブサミは自分の出来なさすぎ加減を痛感する場だった。
■コミュニティ・社内の中でデブサミをやってみようと思った。
・XP祭り2007で初めて人前で話した。
・2008年に転機があった。「会社に閉じる必要は無い」と思い、Devloveというコミュニティを作った。
・コミュニティは野戦病院。ひとときの安らぎを得る場所。
・現場は激戦の日々だが実に楽しかった。毎日が試行錯誤だった。
・自分の仕事を呪っているほど人生は短くない。だから動き続ける。
■2010年・デブサミに登壇した。今度からは登壇する側から手伝う側に回ろうと思った。
■2013年・「リーン開発の現場」という書籍を翻訳して出した。
・自分の考えと合ってるなと思ったところが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というコミュニティを作る行動を起こし、今まで実践してること。
私はそこまで出来ないにしても、コミュニティにはなんらかの形で今後も関わっていきたいなぁと思います。
あと、パパンダパパの↓、いい言葉やな！
「１日１個、何か学べ。そうすると、１年で３６５個の学びがある。そうなればなんとか戦えるやろ」つーか、今回のイベント、勉強会初心者をターゲットに絞っていたのは惜しいくらいの内容だったと思います。
申し込んで良かったです。
あと、スタッフさんにお知り合いが多かったので、最後の「不安を解消しよう！」というラスト１時間はみなさんといろいろ会話ささせてもらいました。
こーゆう場でこーゆう会話を出来るのも、コミュニティの良い所だなぁ～
関係者の皆様、ありがとうございました～
2013/12/8(日) 「Agile Samurai Base Camp」に参加してきました。
公式サイト
http://www.agilesamuraibasecamp.org/DoorKeeper
http://agilesamurai-basecamp.doorkeeper.jp/events/5844Togetter
http://togetter.com/li/600193以下の書籍をターゲットとしたイベントなのです。
場所は渋谷の株式会社サイバーエージェントさんです。
参加者は180人くらいでしょうか。1冊の書籍イベントにこれだけ集まるとは、アジャイルサムライ恐るべし。
今回は早割があるということで、キャンペーンチケット(1000円)に申込みました。
つーか当日、CodeIQの問題を解いて500円の図書カード貰ったので、実質500円で参加できたことに！
個人的に、この書籍は
アジャイルサムライ横浜道場の読書会で2年くらいじっくり読んできた、思い入れのある本です。
たぶん、アジャイル関係の書籍の中で、私が一番最初に手を取った本だったはず。
読書会は他所でもちらほら見かけますが、今回のようなイベントも新しい試みで良いですね～
今回のイベントは「インセプションデッキ」と「テスト駆動開発(TDD)」の２トピックからどちらか１つを申し込み時に選ぶ方式になってました。
というわけで今回、私が選んだのは「インセプションデッキ」。やっぱ、デッキは１つのキモだと思うんです。
デッキをワークショップで丸１日学べるイベントはありがたい。
そういやDevloveでも以前、丸二日かけてインセプションデッキを作る勉強会がありました。
アレはすごく勉強になったなぁ。あの時にチームで頭を捻ってデッキを作った経験が今も活きている気がする。
そんとき書いた参加メモはこちら。もう1年以上前になるのか～懐かしい。。。
2012/9/8(土) ＆ 2012/9/23(日)
「アジャイルサムライDevLOVE道場二周目 第一回 インセプションデッキ(前編)&(後編)」に参加しましたTDDにももちろん興味があったんですが、7月と10月のTDDBCに参加したこともあり、今回はデッキの方に～。
でも休憩時間とかはTDDの方を覗いて、和田さんのお話とか聴いたりしてましたw
以下、個人メモ。丸一日、長いので、午前と午後で２回に分けて書く。
あ、ちなみに自分の復習のためにいつも書いてるので、毎回ダラダラ、メモを書き起こすだけ！
■ジョナサン・ラスマセン氏からのビデオメッセージイベントの冒頭、アジャイルサムライ原著者のジョナサン・ラスマセン氏からのビデオメッセージが上映されました。
ジョナサン・ラスマセン氏はカナダに住んでいるそうです。ジョナサン、実にオープンｗ
こーゆう試みは良いですね！
特に以下３点をメッセージに込められていました。
１．学んだことを他の人と共有する
２．常により良い方法を探す
３．楽しんでください特に２．については、「明日から何をやるか」を考え、自分たちでもっと良いやりかたを見つけていくことを説いていました。
あと「３．楽しんでください」はすごく大事。
アジャイルを勉強したり、こーゆうイベントに参加したりする原動力って、個人的は「楽しいから」に尽きる。
■基調講演 角谷信太郎氏アジャイルサムライ監訳者の角谷さんの基調講演です。
私が今回初めて知った裏話的な要素が多分にあり、大変参考になりました。
■本の一番最初に出てくる図（P.4）・本で伝えたいことを１枚で表している図。
・お客さんは、そのソフトウェアを使う人。その人に価値のある成果を届ける。
・「成果」＝「動くソフトウェア」。もっと言うと、「ちゃんと動くソフトウェア」。
・設計していて、テストしていて、コードベースにマージされていて、お客さんの環境で動くソフトウェア。
・成果を毎週届けることは可能だろうか？
・ソフトウェア開発は難しい。
・何から始めていけばいいかを今日のイベントで考えていきましょう。
■Whole One Team（P.5）・チームが一丸となって、一つのゴールに向かって協調しながら進んでいくことが大事。
・チームには、２つのロールがある。
①何を作るのかに責任を持つ人
②どうやって作るのかを決める開発者の集まり（プログラマ、デザイナ、QA、インフラ、etc）
・チームが「一丸となって」ゴールに向かって進んでいく。
■アジャイルサムライのお話の構造（P.6）・この本の中には一通り、取っ掛かりになるものは全部入っている。
■なぜこの本を書いたのか？（P.7～P.11）・２年前に著者のジョナサンが日本に来てくれた時に話をしてきた。
・マーチン・ファウラーは「もうこれ以上この世にアジャイルの本は要らないと思う」と言っていた。
・でも、たくさん本を読まないと全体像がつかめなかった。
・なら、世の中にある本を１冊にまとめたら値打ちがあるんじゃないか。
・そこで、７冊を１冊にまとめた。
■７冊の書籍（P.11～)①１冊目・ジョナサンが一番影響を受けた本。ケント・ベック著。
・これはアジャイルのムーブメントの始まりの１冊。
②２冊目・ThoughtWorks社で働いていた時に、マーチン・ファウラーがケント・ベックと一緒に書いた本。
・２番目に影響を受けた本。
(1) 目の前にあるコードを良くしていく活動は大事だ。
(2) ソフトウェアを作るとき、ちゃんと作らないといけない。それを継続的に続けて行かないと、動くソフトウェアを届けられない。
最初の２冊にこの２点が来ている点がポイント。
③３冊目・「XPエクストリームプログラミング実行計画」
・今から読む必要はないと思う by 角谷さん
④４冊目・「XPエクストリームプログラミング導入編」
・ケントベックがXPの考え方を示している。
・実際プロジェクトでXPをやるとどうなるの？というのをレポート風に書いてある。
⑤５冊目・最初にして一番いい本。
・「なぜテスト駆動開発をしないといけないのか？」から書いてある。
・絶版なので、なんとかする！ by 角谷さん
・TDDは、和田さんの活動をフォローしていくのがいい。
⑥６冊目・「USER STORIES APPLIED」
・日本語版は無い。いい本だけど、読むのは大変。
・マイク・コーンというスクラム界の凄い人が書いた本。
⑦７冊目・内容が凄く良い本。角谷さんが訳した。
これらをまとめていく必要がある。
■Also had new material（P.18）・７冊の内容だけじゃなく、新しい要素を追加した。それが「インセプションデッキ」
・みんなで認識を合わせていくためのツール。この新しい考え方を導入した。
・これらをまとめて、１冊で読める本として出したのが「アジャイルサムライ」。
・次のステップとして、ソフトウェア開発の現場で試していく入り口にこの本がなるといいな、と思っている。
■なぜサムライ？（P.21）・なぜサムライなのか？なぜパイレーツとか忍者じゃないのか？
・これは、アジャイルサムライの「監訳者あとがき」にも書いてある。
・ジョナサンが一番好きな本は「Way OF The Peaceful Warrior」だった。
・すごい体操選手が怪我をして、自分の生きる意味を見失いがちだった時に、ガソリンスタンドで出会った老人から生きる意味を見出していく話。
・状況を受け入れていくこと、抵抗しないこと、などを説いている本。
・そこで、心穏やかに人生を過ごしていく考え方をソフトウェア開発にも応用したいと考えた。
→ 「The Way of the Agile Warriror」という書名を最初に付けた。
→ 「それでおまえは分かるけど、読者にはそのニュアンスは伝わらない」と編集者に言われた。
→ WarriorをSamuraiに変えた。
・私も「サムライ」が良いと思っている。 by 角谷さん
■マスター・センセイと熱心な弟子（P.25）・マスター・センセイは、実在した武士とかモノノフではない。本の中では「概念」！
・本を書く背景になった20世紀終わり～21世紀初頭のような、アジャイル開発を実践していた人たちが纏まった何か。
・謝辞に挙げている人物たちから受けた影響の象徴としての存在が「マスター・センセイ」。
・具体的には、ケント・ベック、マーチン・ファウラー、メアリー・ポッペンディークや、ThoughtWorks社の同僚の皆さんとか。
■アジャイルなソフトウェア開発とは？（P.27）・10年近く活動してきた彼なりの考えをプレゼンしたのが「アジャイルサムライ」。
・これから取り組む皆さんは、書籍から受け取った思いを持って、現場で実践していけるといいなと思っている。
・でも、なかなか難しい。どうやればいいか。
・大事に思っていることは、「アジャイルソフトウェア開発とはなんなのか？」を考えること。
・「アジャイルプラクティス」という書籍の最初に、アジャイルソフトウェア開発を定義した一文がある。
・
開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行い続けることである。・この一文がすごく気に入っている。 by 角谷さん
・ソフトウェア開発がアジャイルであるとは、価値のあるソフトを届けるというゴールに向かって、チームが協調性を大事にする環境を作る。
・その環境の上でやってみて、フィードバックする。
・成功はない。考えて、実行に移す。
・自分たちのやりかたを調整し続ける。
・プラクティスに囚われると見失うことが多い。
・目的に向かって協調できる環境になっているか？を考える。
・少しづつアクションしてみて、学びながら調整していく。
・今取り組んでいるチームで、フィードバックが効いて、ゴールに向かって協調できているかどうか、一人ひとりが見ていく。それを大事に思うことが重要。
・当事者意識を持って働きかける。
・良いプラクティスはあるが、それをやることではなく、どう現場に働きかけていくかが大事。
・ものごとの名前に囚われないようにしてください。
■次の10年へ（P.31）・やっと、アジャイル開発の考え方が受け入れられやすい下地が整ってきたなと思っている。
・今日の１日がキッカケになればいいなあと思っている。
・でもこの10年、アジャイルをやろうとスタートした人がいては、一人倒れ、二人倒れ。。。
・でも、この周回が大事。
■Inception Deck（P.33）・価値を届けるツールの１つとして、何を作るのか、どう作るのか、自分たちのゴールを明確にする。
・でも、それだけではソフトウェアは書けない。
・その片一方がテスト駆動開発。
・ただ「テスト駆動開発」とか、言葉にとらわれてはいけない。
・コードを書かないと何も実現できない。
■Clena Coder（P.34）・角谷さんお勧めの本。以下は角谷さんの大好きな言葉↓
・プログラマは詳細の管理者である。
・それが我々の仕事だ。
・システムの振る舞いを詳細に決める。
・そのためにテキスト言語を使う。
・（それがコードだ）。・この言葉を実現するためにTDDがどう使えるのかを考えてほしい。
１．学んだことを他の人と共有すること
２．常によりよい方法を探し続けること
３．楽しんでください
■Ron Jeffriesの言葉・
師を仰ぎ、師を追いかけ、師に歩調をあわせ、師の意図を汲み、そして自らが師となるのだ。・同じトピックに興味をもった人たちの集まりはすごく大事。今日の場を大事に。
■どうやって始めるの？ 西村直人氏角谷さんの基調講演の後は、インセプションデッキトラックとテスト駆動開発トラックに分かれました。
インセプションデッキトラックの最初は、アジャイルサムライ監訳者の西村さんの講演です。
１．デッキって何だ？・デッキは、プロジェクトを上手く進めるためのもの。
・プロジェクトの行先にスポットライトを当てる。
・「もっと早くいってよ！」といったような遣り取りを無くすためにインセプションデッキを使う。
・デッキは、プロジェクトをうまく進められるかを確認して調整するための活動。
・いろんな活動はこれまであったが、時間をかけたり一部の人間がやってたりしてた。
・そうじゃなく、みんなが集まって大事なことを調整するのがデッキ。
・やり方は、めっちゃ簡単。質問にみんなで答えていくだけ。
・みんなで話し合って、ひとつの答えを作る。
・知らないことはうまくできないし、みんなの理解はおもったよりバラバラ。
■われわれはなぜここにいるのか・プロジェクトのゴールは１つ。
・ゴールは目指すトコ。
・ゴール以外に、「ミッション」というものがある。絶対に達成しないといけないもの。
■エレベーターピッチ・ゴールは２種類ある
①ビジネスとしてのゴール
お金を出してくれた人の対価がいる。そういう人がいることを知ることは大事。
②使う人にとってのゴール
・デッキで何がしたいかを一言で言うと、「期待」と「実現可能」の両方を早い段階から一致させること。
２．どうやって作るの・準備して、理解して、調整して、まとめていく。このサイクル。
■１．準備・・・難しい。ヘタすると、沈黙したり空中戦になる。
・なので、おたがいが話しやすいようにたたき台が重要。それについて人を集めてディスカッションする。
■２．理解・お互いの違いを明らかにする。
・ファシリテーターが意見を引き出す
・付箋を使って、気になることを書いてもらう。
・大事なのは「みんな」。
・オレの意見を聞け、じゃなくて、相手の意見を聞く。
・「チーム＝みんな」という考え方。
・「あいつはプログラマの意見だから」とかじゃない。
■３．調整・声の大きい人とか役職が上の人とか、「この問題の答えはこうだよね！」というと、みんな沈黙してしまう。
・しかも、誤解をして受け取ってることがある。
・これだと、「みんなとしての答えを出す」ということにはならない。
・なので、それぞれの意見を調整する。
・ファシリテーターを立てたり、付箋を無記名でやってみたりとかの工夫をする。
・大事なのは、出てきた答えが「できそうだ、いけそうだ、実現可能だ」と思えるか。
・それがひとつの判断ポイント。じゃあ、どう確認するか？
・みんなに手を上げてもらって、５段階で指を出してもらう。
・そうやれば全員の意思を確認できる。
・ぱっと手を上げて、２とかだったら話し足りてないとかに気づける。
■４．まとめ・「あの話って、前に話してきたことと違ってきているような。。。」ってなことが絶対起きる。
・なので、いつでも確認できるよう、更新できるよう、スライドにまとめる。
・印刷して見えるところに置いておく。
・共有フォルダに入れても見られないのでダメ。
・作ったスライドが、日々の判断材料になっているかがポイント。
これがオーソドックスなインセプションデッキの作り方。
３．一人で作ろう！・なんだ。。。集まる、対話？？？超難しいやん！
・一人でやってみよう。
・では、一人ではどう始めるのか。
・準備して、理解して、調整して、まとめていく。この４つのサイクルは一緒。この繰り返し。
■１．準備・まずは自分の理解をまとめてみよう
・自分の整理の意味をこめて、スライドを作ってみる。
・たくさんのインプットがあるはず。
・直感が正しかったりする。それを理由付するためにちょと書いてみる。
・大事なのは、全部書けなくても構わないということ。
・「分からない」ということを理解することが、一人で始めるときのポイント。
■２．理解・知っている人に聞きに行けばいい。わからないことを質問する。率直に聞けばいい。
・大事なのは、デッキじゃなくて質問しよう。
・デッキのここを埋めたいのですがわかりません、とかいうと、デッキから説明しないといけなくなる。
・そうじゃなく、わからないことをストレートに聞きましょう。
・大事なのは、やり方にこだわらないこと。
■３．調整・自分が不安を感じることを伝える。「こういうところが気になるんですが」ぐらいで構わない。
・多くの場合、相手から「こうなんだ」と言われると黙ってしまう。
・まずは自分の不安を口に出す。質問をしにいったついでに聞いてみるとか。
■４．まとめ・最新の情報をまとめて、まわりに伝える。まとめ方がスライドなだけ。
・インセプションデッキのフォーマットを使っていれば、注目してもらいやすい。
■タイミング・デッキを書くタイミングはいくつかある。
・プロジェクトが始まるとかは調整しやすい。なので前の方でやる。ただ、それにこだわらなくてもいい
・ふりかえりでマンネリ化してるときにやってみるのもいい。今日はリスクについて、とか、ゴールについて、とか。
・自分が悩んだときとか、いつでも。
・自分がもやもやしてると、みんなももやもやしてるので、興味を持ってやってくれる。
・その手段としてデッキは使える。
■現場で練習・家でやるより、現場でやったほうがいい。
・現場で練習したほうがいろんなバリエーションが経験できる。
■One More Thing・デッキは、プロジェクトのもやもやを晴らすだけではない。
・作ると、プロジェクトの意図がわかってくる。
・すると、自分の作ってているものに関心が生まれる。
・すると、モチベーションが湧くようになってくる。
・すると、自分の範囲外にもアイデアが出てくる。
・それが価値につながってくる。
・それらは徐々に広がっていく。
・広がれば、デッキは強力な武器になる。
・明日から是非調整してみよう。
★質疑応答Q.１プロジェクトのエンジニアが少なかったり、プロジェクトを掛け持ちしてたりすると、デッキ作成のため作業時間が減ると思うのですが、どーすれば？
A.・スクラムは、みんなが協力してやったほうがいいものは、みんなを集めてやる。みんなでやる。
・エンジニアとかデザイナーとか、こだわらずにみんなでやる。
・みんなで集まってやるので、オーバーヘッドがあるのも事実。
・じゃあ、オーバーヘッドを取り除く活動もみんなでやれるか、というと、プロジェクトを掛け持ちしてるとしんどいかも。
・なので、しんどいというアラートをきちんと上げること。
・スクラムで成果をアピールしたあと、プロジェクトの掛け持ちを解消すればもっと成果だせるよ、とアピールすることが大事。
Q.・デッキ作りにエンジニアが受け身で困っている。企画部の人との温度差がある。どーすれば？
A.・人をくすぐるポイントは違う。なので、まず個人ごとにやりかたを変えてみる。
・受身の状況では事故が起きる。なので、それを利用する。
・「デッキ作りをきちんとやってなかったから事故ったんですよ」と、ちゃんと言う。
・あとは、成功体験から始める。
・エンジニアだけでデッキ作りをやるのもあり。そのほうが壁が少ないかも。
★午前の部の感想：初心者をターゲットとしたイベントっぽい位置づけらしいけど、ぜんぜんそんなこと無かった！
少なくともこの午前の講演２本は、玄人、素人の関係なく、万人に聞いて欲しい内容だったと思う。
つーか午前だけでもアジャイルサムライの監訳者お二人＋裏のTDD側で和田さん講演とか、豪華すぎワロタ。
午後のセッションについては、明日にでもメモ書く～
2013/11/28(木) 「リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜」に参加してきました。
DoorKeeper
http://leanfromthetrenches.doorkeeper.jp/events/7026Togetter
http://togetter.com/li/596298以下の書籍をターゲットとしたイベントなのです。
場所は渋谷のmixiさんです。
参加者は60人くらいでしょうか。満員御礼だったようです。
アジャイルは個人的にココ１～２年いろいろ学んできましたが、リーン開発について学ぶのは初です。
あ、一応エリック・リースのリーンスタートアップは読みました。
リンスタはDevloveの和波さんのイベントで興味を持ってから読んだ本ですね～
あと、この日の平鍋さんのスライドにも出てきた、楽天の川口さんの図にはリーンは３種類あると書いてあります。
この図↑。Lean Startupもリーンの一派だそうな。
ちなみに今日の「リーン開発」は、この図で言うと「Kanban」で、これもリーンの一派だそうな。
XP祭りでこの辺の話を聞いたのを思い出します。
ってなわけで、私もこの日までに「リーン開発の現場」をなんとか無事読み終え、晴れて参加したのでした。
以下、個人メモ取ったのをダラダラを書き起こしてみる。
■第一部：リーンとカンバンの本質 - 平鍋健児氏
■アジェンダ１．リーンとはなんだ？
２．スクラムとカンバンの共通点は？
３．{現れる}現場
１．リーンとはなんだ？■Agile and Lean（P.3）・楽天の川口さんが書いた絵について。
・右側にスクラムとXPがある
→ 建築で何回も現れる文脈と問題にパターンをつけていこう、というのが源泉。
・メアリー・ポッペンディークがLeanからAgileに線を引いいたのが先見の明だった。
→ そのため、海外では「リーン＝アジャイルソフトウェア開発」と思ってる人が多い。
・LeanはTPSの系譜を持っている。
・もう一つの親が、野中郁次郎氏の「The New New Product Development Game」。
→ 私の本にその線の話は書いてあるので買いましょうｗ
・カンバンは目に見えることから始めるプロセスなので、日本には向いていると思っている。
・Leanをビジネスに広げたのがLean Startupで、「顧客開発」という言葉を初めて使った本。
■「リーン」と「アジャイル」の関係とは（P.4)・第二次世界大戦後、車を多品種少量生産するために生まれたのがTPS。
・「リーン生産」と「リーン製品開発」はぜんぜん違う、という人もいる。
■スターバックスの事例・スターバックスは、お客さんと話す時間を作るためにオペレーションを早くするためにリーンを使った。
・上から目線でなくチームで分析するサイエンティストがチームにいる。
■平鍋さんの「リーン」の定義（P.5）１．顧客の目で「価値」を定義
・お客の目で見て嬉しいことをやること。
２．価値の流れを可視化
・定義した「価値」を目に見えるようにする
３．それを「エンドツーエンド」で「細く、速く」流れるようにする。
・「エンドツーエンド」とは、入ってから出るまで。
・つまりアイデアになってからキャッシュになるまで。
・ウォーターフォールは「太く」。設計や分析といった作業が「太い」。
・リーンはそうじゃなく、細くして、シューっと流れるようにする。
４．その流れの改善活動を、現場で実際に仕事している人々が行う
・この４番目が一番重要。
・その流れの改善活動を、「現場」の人がやること。
■Waterfall-Scrum-Kanban（P.6）・Scrumは、ビジネスが変わったらやり方を変えられる利点が大きい。
・Kanbanはイテレーション無しでもできるのが特徴である。
・WIPの量をできるだけ小さく。「一日１個」の流しが良い。
・Waterfallは一筆書き。一回失敗すると怖い。爆弾処理のようなもので、最後は爆発して数人死ぬ。
・Scrumは爆弾を小分けにする。爆発するけど小さいから死なない。徐々に爆弾処理が上手くなる。
■リトルの法則（P.7）・WIP = LeadTIme × Throughput
・リードタイム（サイクルタイム）とは、要求が到達してから開発が完了するまでの時間。
・WIPとは中間在庫。
・同じThroughputの場合、WIPとLeadTimeは比例する。
■安定した長さの行列で、何分待つ？（P.8）・待ち時間 ＝ 自分の前に並ぶ人の数 ÷ 一分後に自分の後ろに並んだ人の数
２．スクラムとカンバンの共通点は？■ScrumとKanbanとセル生産の共通点は？（P.11）・「セル生産」とは、一人が製品を最後まで作る方式。多品種に強い。
・３つの共通点はリーン。WIPを制限する。
■What is WIP？（P.12）・アマゾン川を例に挙げる。川の支流が車の部品。車が売れなかったら、支流がすべて在庫になる。
・「売れたら作れ。売れなかったら作るな。」これがカンバンの原則。
・どうやって支流に情報を伝えるか？
→ WIPを少なくして、水かさを減らす。
・顧客が欲しいといったものを作る。それ以外はぜんぶ無駄。
■Yatai（or Hotdog Stand）（P.13）・ホットドックをベルトコンベヤで作ったら無駄になる。
・全体を知ってることで改善が生まれる。知っている１つのことばっかりやっていると改善が生まれない。
・ホットドックの屋台は、ホットドックを１から全部作って、お客さんの笑顔を見れるのが利点。
■Stop starting, start finishing（P.14）・終わるまで、やり始めてはいけない。 by Henrik Kniberg
３．{現れる}現場■方法論の終焉（P.26）・by アリスター・コーバーン
・「ふりかえり改善フレームワーク」を作っている。これは方法論ではない。
・Crystalの提唱者はアリスター・コーバーン。
■ポータブルかんばん（P.18）・まな板立てにカンバンを立てた事例。いつでもどこでもカンバンが使える。
■カンバンの利点・「ここ」とか「あれ」とか言えるのがカンバンの利点。
・ソフトウェアは目に見えないが、カンバンの前で会話することで、「ココにあるからあと２週間くらいかかる」といったような会話ができるようになる。
・エラい人に見てもらうのも、カンバンのポイントである。
■ブラジル、Ci&T社にて（P.27）・アメリカは、オフショア開発先としてインドを利用することが多かったが、最近はブラジルとかが多い。
・なぜなら、時差が少ないから。アジャイルは会話が大事なので、時差がないことが重要。
・地球を縦に見ると、アジャイル開発できる海外の国が見つかる。緯度が近いと時差も少ない。
■現場の事例（P.29）・【写真4】
顧客の目が大事。あるプロジェクトでは、顧客の製品を買ってきてプロジェクトルームに置いていた。
顧客の製品を知ることで、顧客と同じ目でものを見る努力をしていた。
・【写真6】
システムをリリースして顧客と祝杯を挙げたときのシャンパンのコルクをずっと貯めている現場の事例。
・【写真8】
会社に「イングリッシュゾーン」を設けていた。
相手先と英語で悩んだららココに来い、ということで24時間開放している。
■時代の遷移（P.30）・昔は、生産を繰り返せない時代があった。それは「工芸」と呼ばれていた。
・それが進歩し、「交換可能なパーツ」や「交換可能な人」が登場する大量生産の時代になった。
・最近は、「現場で考える人々」を求めるようにまたなってきた。
■リーン開発の本質（あとがき）（P.31）・「人」の要素がプロセスの中心である。
・「現れる」ことこそ、現場の「現」なんだ。
■休憩休憩時間に、リーン開発に関するCodeIQの問題が藤原さんから紹介されました。
その場で解くと、なんと図書券がもらえるとのコト！ということで・・・
ありがとうございます！ちなみに、
でした～
■第二部：「本質」を「現場」に繋げるディスカッション■リスクを取ろうとしない、危機感が無い上司をどーするか
・まず、上司の話を聞いてあげる。そして「協力したい」と上司に表明して言う。
・そうすると上手くいくようになるのでは。
・中間管理職は辛い。。。ので「協力したい」と言うと、賛同してくれると思う。
■応受援・トヨタには「応受援」というシステムがある。
後工程に作業が流れてこない場合は、部屋を掃除してから、前工程を助けにいく風習があるらしい。
■顧客価値・顧客の定義には2種類ある。
１．実際に使う人
２．お金を払う人
・「お金を払う人」を飛び越して、「実際に使う人」が嬉しい、満足するところを見ること。
・エンドユーザにとって役に立たないとダメ。そして、それがみんなで合意できないとダメ。
・我々が作るものを「使ってくれる人」が「いいね！」と言ってくれるのが良い。
■割り込み作業の制御・横槍の作業を付箋に書いて、見せる化して、横槍の量を上司に把握してもらうことが大事。
・これだけ割り込みがあるのでこれだけ遅れます。どうしますか？というふうに、きちんと会話する。
■WIPの「1個流し」だと、作業に関われる人が限られるので、余る人がでるのでは？・本当にWIPで「１個」に制限してしまうと、確かに人は余るかも。
・そうじゃなく、「連続して１個が流れる」ようにするのが良い。
・どのくらいを1個で持つかは、やってみて決める。
・動いているものを目に見えるようにして、みんなの手が開かなくなるように流すようにする。
・カンバンは物理的なものだから、目に見え、人が自分で動くことができるので改善に繋がる。
・目に見えることがシグナルになる。
・それを使ってお客さんが「欲しい！」と言ったものを作る。
・ずっと流れている状態を作り、WIP制限で数を減らす。WIPの量を調整する。
・ソフトウェア開発より、モノの生産の方が未来が読みやすい。
・アジャイルの場合は、毎回違う作業をやるから、簡単には流れない。
・安定的に流すためには、カンバンをどう流すかで変わる。
★感想：いやー、平鍋さんのお話は現場感が満載で、熱かったですねー
思わずウルッと来ちゃいました。
書籍を全部読んで、平鍋さんのありがたいお話を聞いて、リーンについて理解が深まった感があります。
この本を買うまでは、リーンなんて全然知らんかったのに。
特に、書籍で大規模プロジェクトの事例を扱っている点がとても参考になりました。
こーゆう大規模事例を本として体系的に説明してくれている本って、なかなか無いんですよね。
平鍋さん、市谷さん、藤原さんはじめ、会場提供さん、参加者のみなさんありがとうございました～
-->
