Readingagilesamuraiinhiroshima20120327 - agile-samurai-ja/support GitHub Wiki

アジャイルサムライ読書会 in 廣島道場（第三回）

記録

今回も「タリーズコーヒー中央通り店２階」で始まった第三回でした、かなり早くに着いたのに既に一名お待ちでした。今回は５名でしたので、３階を予約しても良かったのですが、前回それほど苦ではなかったのもあり、そのまま２階で開催です第３章はインセプションデッキですが、短いのと３章は４章と５章の前説的な章なので、３章と４章を連続して読むことになりました思い出した！「Android Bazaar and Conference 2012 Spring」のGang of Fourの話は、Google、amazon、Apple、facebookでした。で、MSが入ってませんねという（某氏に向けて）

ふりかえり（約10分）　　二回目の記録を元に、説明を行いました。

３・２手ごわい質問　　受託開発の場合、多くは営業の人が受注して、開発に引き渡される。これはどうするのか？　　営業は売って何ぼなので、手ごわい質問はしないに決まってる。　　解決策案　　　　１．見積段階で、開発が介入する　　　　２．営業が、開発メソッドを身に着ける　　　　３．営業職を廃止して、開発が営業する。（これがいいかも）３・３インセプションデッキのご紹介　　プロジェクト憲章（プロジェクトの目的とかを記載するもの、スケジュールから要員まで、技術要素なども記入しておく）　　この段階で見積が大きくずれてはいけない。　　チームビルディングに有効（真面目にやっとかないと・・・）４・４やらないことリストを作る　　これは有効だが、きちんといえるか　　運用側の問題（責任）について、どのように考えるのか。やらないことと、出来ないことは違う。　　お客様も社内的に運用出来ないとは言えない場面がある４・５「ご近所さん」を探せ　　ＰＭ（ISO9001だったか）でいうところの、他組織との接点のことか　　コミュニケーションが重要で、組織孤立を防ぐ（喫煙場所が有効に機能する）マスターセンセイと熱心な弟子　　顧客に時間を取ってもらえない、若しくは軽視される場合など　　この重要性を理解してもらうこと、その「機会費用」が必要であることを理解して営業出来ないか感想　　インセプションデッキについての前半はアジャイルでなくてもあるよね、ウォーターフォールでもやるべき内容　　後半では、また違ったメソッドが出てくるかも

訳語に注目した：

プロジェクト憲章 charter : 標準化委員会などで最初に出てくる話。むしろチャーターなしに暗黙知・思い込みでプロジェクトが走り始めるということが不思議かも。。
インセプション inception : 始まり、開始。「相手の夢を支配してアイディアを植えつける」という同名の映画があったらしい。学位授与式という意味も。
ご近所 neighborhood (?) : むかしの Windows 英語版では「マイネットワーク」「ネットワークコンピューター」が "Network Neighborhood" だったことを思い出した。SMB とペアで出てくる NMB の話。。

エレベーターピッチとパッケージデザイン：

エレベーターピッチは論文執筆、論理的。
パッケージデザインは学会発表、感覚的。
「与えらえるもの」でもいいのか？「作るプロセスの経験」が重要？
パッケージデザインは「モチベーション」につながる。美しく心を動かされるものを見ながら仕事するべき。

「なぜ」＝「現場」と「司令官」なのはなぜ？

上と下の境界。その他は「ご近所」。自発的に動くために。

やらないこと：

当たり前であっても言葉にする必要。
チケットのマイルストーン設定で表現できるか？

多忙すぎる顧客のコミットメントを求められるか：

「説明する」より「質問する」？

手ごわい質問：

確かに「手ごわい質問」はしたほうがよい。
が、本に書かれているような、プロジェクトの中止も視野に入れたようなミーティングは現実的にはない。
開発チームの前にプロジェクトが降ってくるころには、納期と予算と要件は決定しており(＝契約が済んでいる状態)、これを異議を唱えることはまずできない。
契約前でも、やらないことを開発側が述べていても、営業がそれを顧客に伝えているとは限らない。この場合、開発チームがＮＯといっても顧客側は受け入れられないということがある。
ただ、だからといって諦める必要はなく、手ごわい質問によって警鐘は鳴らすべきと思う。そのうえでベストプラクティスを模索したい。

エレベーターピッチ：

これは実践すべき。（したい）
開発者視点では「自分が作ろうとしているものが、どのような目的や目標から成るのか？」というのを常に意識するうえで、強力な武器になるのではないかと思う。
目的や目標が分かっていれば、言われるがまま仕事をすることが減らせるし、よりよい提案ができる可能性が増える。迷った時やみなおすときの俯瞰する視点にもなりえる。
特に中途からメンバーが追加されたときは、このエレベーターピッチをまず伝えることで、いきなり仕様書や機能の説明をするよりはより理解が深まるのではないか？

ご近所さん：

ご近所さんは誰がいるのかわからないことが多いので、予め知っておく（列挙しておく）ことは重要と思う。
そのうえで、ご近所さんとお付き合いがチームで協力できると(=チームの誰かに任せっきりにするのではなく)、それは強いチームになりえると思う。

プロジェクトがダメになるのはなぜか

プロジェクトのゴールの認識がそれぞれでブレている。 -> 認識の共通化にインセプションデッキが有用。
てごわい質問をする必要がある。 -> インセプションデッキで自然とてごわい質問を聞き出せる。

インセプションデッキの仕組み

一箇所にプロジェクトメンバーをあつめて、全体像のイメージの共通化をはかる。
ゴールが明確化するため舵取りをメンバーであれば誰でもある程度可能に。

全体像を捉える

インセプションデッキの最初の5つの目的。
プロジェクトの目的の具体化、なぜこのプロジェクトを進めるのかをはっきりさせる。
アジャイルでなくても普通やっていることではないのか -> 上の人しかしらないことが多い

われわれはなぜここにいるのか

道にまよったときの道しるべにしたい
目標を決めるのとはなにが違うのか。 -> 現場の様子、司令官の意図を明確に。
自分自身が現場の仕事をやってみるのが良い。

エレベータピッチを作る

他者へプロジェクトの概要を伝える -> アジャイルじゃなくても普通やってるんじゃ…
きまったやりかたはない。テンプレートにあわせてやると効率的
テンプレートの一覧が欲しい。どこかにないのか？

パッケージデザイン

"エレベータピッチ"と"われわれはなぜここにいるのか"と何が違う?
内側(開発者)の視点ではなく、外側(利用者、無関係な人)の視点でどのようなものを作るのか
ゴールの直感的イメージ。軌道がブレたしても、パッケージデザインに引っ張られてどのように振れてゴールへ辿りつける

やらないことリストの作成

開発者はやらないことをはっきりと認識してることが多いが、当然やることだと思ってることが多々ある。張り出すぐらいのことをしておくと揉めない。
やらないとわかっていれば、無駄な迷いがなくなる。

ご近所さんを探せ

面識がないと人たちがいると暗黙のうちに無関係と考えがち。ここがトラブルの元になる。
探しておかないと御互いの事情を考えない。急に関わることになっても、連携できない。

感想

全員でやらなきゃいけない意識の統一を目的としている
アジャイルではなくてもやるべきことはある。当たり前のことでもある。

手ごわい質問

初めて会う人もいるようなところで初めから手ごわい質問をすることができるのか？それは日本と海外の文化の違いもあるのかも。

パッケージデザインを作る

15分で作るとあるが、15分ではたして作れるだろうか。慣れるまでは少し時間がかかるかもしれない。
パッケージデザインができあがると、何故か作るものがすばらしいものに見えてくる。これは物を作るモチベーション向上・維持につながる。
スマホアプリの開発でアイコンを最初に作っておくと、コンセプト(イメージ)がずれなくなる(ずれが生じてもアイコンを見ることで軌道修正可能)のでぶれたものを作るリスクが減少する効果も。

「ご近所さん」を探せ

プロジェクトが終わりに近づくにつれて知らない人があーだ、こーだと口を出してくる。←これはよくある。そして、その人たちが声に力のある人たちだから何も言えない・・・。
チーム全員がブレストしてご近所さんを探すという進め方とのことだが、はたして皆が同じ時間を共有してとることができるのだろうか。都合のいい時間の調整等がなかなか難しい。チームメンバが多いと多いほど難しくなるのではないかと思う。