『Experience Vision のはじめかた』ノート

2012/09/26に開催された『Experience Vision のはじめかた』のノートです。

DevLoveは今日で93回目とのこと。あと7回で大台です！

◆山崎和彦様 - 自己紹介

　

　◇経歴

　

　　・京都工芸繊維大学で工業デザインを専攻

　

　　・クリナップからIBMへ

　

　　・IBMでは工業デザインからソフトウェアのインタフェースデザインへ。ユーザエクスペリエンスデザインセンターを作った。

　

　　・その後はコンサルティングとして、UCDやUXを伝える活動

　

　　・そして千葉工業大学へ

　

　IBM時代にアメリカ人の同僚が言っていた。「アメリカでは家に帰ってから勉強している。大学も単位辺り2万円でとれて、5年かけてMBAが取れたりする、向こうでは余暇としてそういう生き方ができる」

　そういう生き方に興味を持って、神戸芸術工科大学・東京大学で手法を学び、現場で実践していった。いまも商品戦略ウェブ戦略パッケージングなどもやっている。

　

　

　◇執筆活動

　

　　やり方をまとめることの大事さを思い、本も書いた。

　

　　・使いやすさのためのデザイン

　

　　・情報デザインの教科書

　　　→この分野を学ぶための教科書として作った。

　

　　・プロダクトデザイン

　　　→教えることが先生毎に違って、どうなの？と思って出した。工業デザインって、どこでも聞くけど、教科書がない。僕らが始めて作ったという自信ができた。

　

　本として出版することで手法や考え方を使ってもらう。

　自分が学んで経験したことを使ってもらえることで、社会に役に立ったと言う実感がある。

　今日もその延長にある。

　

　

◆エクスペリエンスビジョンについて - どういったものか

　

　◇エクスペリエンスビジョンについて

　

　　・ビジョン提案手法のフレームワークである

　

　　・新しいビジョン・サービスを構築するために役立つという視点から作った

　

　　・ユーザの本質的体験から見た、ユーザがもっと喜ぶような新たな体験を与えるため、本質的な価値と展望を探ることが目的

　

　　・本質的欲求からはじめ、上位の価値やサービスを考える

　

　　・エクスペリエンスビジョンのプロセスを全部使わなくても、全体像がつかめるようなテンプレートがある

　

　

　◇エクスペリエンスビジョンの歴史

　

　　・エクスペリエンスビジョンは5年かけて作った

　

　　・ワークショップや合宿で実証していったら5年かかった

　

　　・いい手法はどんどん取り入れていきたかったから5年かかった

　

　　・世の中にあるものは使い、無いものは考え出した

　

　

　◇エクスペリエンスビジョン本について

　

　　・エクスペリエンスビジョンで使用するテンプレートはダウンロード可能

　

　　・本を持っていなくても落とせる

　

　　・エビ本には、エクスペリエンスビジョンの適用事例・教育事例・ワークショップ事例も書いてある。

　

　

　◇既存の手法をどんどん取り入れたことについて

　

　　・手法を考えた人は、それを使えば世の中を変えるような書き方をしてしまう。でもそれは嘘

　

　　・手法は一部分でしかない

　

　　・いろんな手法を上手く使いこなす。エクスペリエンス・ビジョンにはそういう役割を持たせている。

　

　

　

◆エクスペリエンスビジョンについて - 関連領域との関わり

　

　◇ビジネスとエクスペリエンスビジョン

　

　　・エクスペリエンスビジョンにはビジネスの観点もある

　

　　・ユーザとビジネスの両方を見ている

　

　　・モノを売っている人がどうやってサービスに転換していくか？など

　

　

　◇HCDとエクスペリエンスビジョン

　

　　・エクスペリエンスビジョンでは勿論HCDを使っている

　

　　・エクスペリエンスビジョンはユーザの価値に基づいて企画やエンジニアが提案するアプローチを取っている

　

　　・今までのHCDはユーザのニーズを受けるものだった

　

　　・今までのHCDは問題解決に寄っていた

　

　　・欧米のHCDの使い方やデザイン思考のアプローチを見ると、HCDはイノベーションの源泉としても使える

　

　　・HCDには問題解決と提案型の2つの使い方があり、それはプロジェクトに応じて使い分ければよい

　

　

　◇シナリオとエクスペリエンスビジョン

　

　　・構造化シナリオを取り入れていることはエクスペリエンスビジョンの特徴

　

　　・シナリオができればユーザの本質的価値を評価できる

　

　　・シナリオを使えば、きちんとしたウェブサイトなどを作ることなく価値を調査することができる

　

　　・戦略的にやるときはバリューシナリオまでやるけど、日々のプロジェクトはインタラクションシナリオで留めたりとか　…そういう使い方もできる

　

　　・ユーザ視点->プロトタイプ、ビジネス視点->ビジネスモデル、の形でシナリオの視覚化ができる

　

　

　

◆バリュー（本質的な価値）について

　

　◇エクスペリエンスビジョンでは

　

　　・構造化シナリオ手法を使い、段階的に明らかにしていく。

　

　　・フレームワーク上では、上半分をユーザ・下半分をビジネス。それを真ん中のシナリオでつないでいる。

　

　

　◇バリューなどの上位概念について取り組むということ

　

　　・これが曖昧だったりレベルが低かったりすると、いいアイデアが埋もれる

　

　　・そういうことはすごくある

　

　　・戦略作りはすごく大事

　

　　・プロダクトを作って、じゃあ2年~3後はどうするのか？ということが書いてない企画がほとんど。

　

　　・半年後の製品をただ考えるのと、ユーザの慣れも考慮したうえで2年～3年後のことを考えるのでは全然違う

　

　　・企画書は自分のウェブサイトや製品のことしか書いてない。戦略は戦略部門の話で別、となってしまう

　

　　・そういう中では新しいことをやるのは難しい

　

　　・新しいことには投資もリスクもある。それは単体の投資では回収できないことが多い

　　　→だから、上のレベルで目標設定することが重要

　

　

　

◆ユーザについて

　

　◇ユーザの本質的価値を知るためには

　

　　・提供価値分析やKA法という手法がある

　

　　・目の前の事象に対して、ユーザの価値や心の声を見つけ出していく

　

　　・潜在ニーズはフォトエッセイや行動観察で明らかにする

　

　　・顕在ニーズは日記や質問

　

　

　◇ユーザ設定

　

　　・ビジネスを考えるのであればステークホルダーも必要

　

　　・ステークホルダー = ビジネスに影響を与える人

　

　　・優先順位をつけて、具体的な対象ユーザを明確にする

　

　

　

◆シナリオについて

　

　◇シナリオとは？

　

　　・シナリオはモノとヒトの関係を表すことができる

　

　　・仕様書にはモノのことしか書いてない

　

　　・シナリオは日本語が読めれば分かる

　

　　・仕様書は専門家が見ないと分からない

　

　　・シナリオを介せばエンジニアとデザイナーが互いにコミュニケーションできる

　

　

　◇構造化シナリオについて

　

　　・シナリオを階層化していることがポイント。

　

　　・バリューシナリオ（ユーザの価値 / なぜ？）

　　　→バリューシナリオ：新規性・魅力がポイント

　　　→ユーザ・ビジネスにとっての価値

　　　→ユーザにとっての本質的欲求がビジネス提供者の提供方針がベースになる

　

　　・アクティビティシナリオ（ユーザの行動 / 何を？）

　　　→バリューシナリオの1シーン

　　　→ユーザの活動の全体が分かるように描く

　　　→ペルソナはこの段階ではっきりしている必要がある

　　　→有用性・便利さがポイント

　

　　・インタラクションシナリオ（ユーザの操作 / どうやって？）

　　　→効率・全体としての使いやすさがポイント

　　　→アクティビティシナリオの1タスク

　　　→具体的なモノ、その使い方を書いていく。

　

　　アクティビティシナリオとインタラクションシナリオの違いについて。アクティビティは人の行動なのでモノははっきりしていない。逆に、インタラクションはモノがはっきりしている。例えば、朝気持ちよく起きるのはアクティビティで、それを照明器具でやるというのがインタラクション。

　

　

　◇シナリオの評価方法

　

　　・ユーザの側面からの評価方法（代表的なもの）

　　　→魅力性・新規性・有効性・効率性。

　　　→魅力と新規は満足度に関係する

　　　→有効と効率は便利さに関係する

　　　→どれを評価するのかはプロジェクトの段階で変わる。例えばバリューの段階なら効率性より魅力性や新規性を見る。

　

　　・ビジネスの側面からの評価方法

　　　→戦略性・事業性・市場性・実現可能性・社会性

　　　→例えば、最初のバリューの段階で戦略を評価し、アクティビティで市場性を見て、操作で実現可能性を見る

　　　→3年後の話を考える時に操作性の話をするのは違う

　

　

　

◆エクスペリエンスビジョン・情報デザインに関して出てきた話

　

　◇問題解決と提案

　

　　・問題解決のプロジェクトは必要だけど、それだけじゃダメ

　

　　・新しいものやこれまでなかったものを考えるためにはユーザの本質に立ち返って、エンジニアからユーザに提案することが必要

　

　　・ただ提案するだけではなくて、ユーザの立場から提案することが重要

　

　　・ユーザの価値に基づいてビジョンを考えると新しいものが見える

　

　

　◇企画提案書について

　

　　・技術・実現可能性がポイント

　

　　・総合的なビジネス企画を立案する

　

　　・製品やサービスに対するユーザ要求仕様をまとめる

　

　　・ユーザ視点から見た仕様の根拠を書く

　

　　・うれしい体験 - 「HCDから見たポイント」「差別化・新規性・魅力」を書く

　

　

　◇本質的な価値の見つけ方

　

　　・本質的な価値を見つけるのは難しい

　

　　・バリューシナリオを作って共感度を見ていくのがよい方法だと思っている

　

　　・シナリオ作りならお金がかからないので、そこを評価して価値を見つけていけばいい

　

　　・何もないところからブレストしても仕方がない

　

　　・砂金取りと同じで数を打たないと駄目。

　

　　・新しいものはどこにあるかわからないので、広くユーザにアプローチすることが大事

　

　　・そのためにはできるだけ簡単な形で聞く方がよい

　

　　・シナリオは完全なプロトタイプよりも量が作れる

　

　　・シナリオなら「こんなものも？」という、プロトタイプでは（費用と優先順位的の兼ね合いで）試せないようなものについても調査ができる

　

　

　

◆もう少し周辺の話

　

　◇ゲームチェンジについて

　

　　・同じ土俵で戦うと安くて効率のよいところには勝てないというのがある

　

　　・そういうとき、欧米ではゲームチェンジを使う

　

　　・アメリカは自分達でルールをどんどん作っている

　

　　・改良だけで日本がやっていくのは今後難しいのではないか

　

　　・目の前の問題を解決するのではなくて、ユーザに本当に必要なものを長い目で見て戦略を立てることが大切なのではないか

　

　　「新しい目覚まし時計をデザインして？」と言われると、既知の固定された記憶の中でデザインしてしまう。そうではなく「朝、気持ちよく起きることができる体験をデザインして？」とすると、1つ上のレベルで考えることができ、もっと自由な提案ができる。チェンジゲームというのはそういうこと。

　

　

　◇スケッチとプロトタイプの違い

　

　　・散策的にアイデアを作るのがスケッチ

　

　　・検証的なものがプロトタイプ

　

　

　◇新しいサービスの確かめ方

　

　　・イベントを1回だけやる。ユーザにとってうれしいかどうかはそれだけで判断できる

　

　

　◇アクティングアウトの使い方

　

　　・いろいろある。実際に設計者が使ってみるとか。

　

　

　◇クイック＆ダーティ

　

　　・クイック＆ダーティに実験することがすごく大事

　

　

　◇構造化シナリオはウォーターフォールっぽくない

　

　　・アジャイルとシナリオは近い

　

　　・どこまで深くやるか？という違いだけの話。

　

　　・アジャイルはソフトウェアまで作るが、（エクスペリエンスビジョンでは）クイックにシナリオ・プロトタイプを作って済ませる

　

　　・クイックに作るのが大事

　

　

　◇心配していること

　

　　googleが自動運転の車を街で走らせ、実証的に走り方をプロトタイピングしている。日本は法律上そういうことが絶対にできないと言われている。iRobotもろうそくが倒れたら火事になるからできなかった。そういう日本人の潔癖さが、機会を遠ざけていることを心配している。 

　

　

　◇異文化

　

　　アメリカでは、新しい発想をするためには異文化の人がいないという認識をする人が多い。技術者・マーケティングの人・デザイナー　…そういう人が混ざることで新しいものができるという発想が大事だと思う。 

　

　

　

　

　

山崎和彦様, DevLove様, ありがとうございました。

　

　

『なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い』ノート

2012/09/25に開催された『なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い』のノートです。
もっといい話をたくさん聞いていたような気がするのですが、あまり残っていないような　…メモ力をもっと高めていきたいです。


◆ウォーターフォールのコンセンサスを作りましょう

◇歴史的背景と現状
起源は1970年代に発表されたWinston Royceの論文。
ただ、これはバッチ生産のためのパラダイムのものであり、所謂ウォーターフォールではない。

Winston Royce - Managing the Development of Large Software Systems
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

◇ウォーターフォール開発プロセスの歴史
1. Winston Royce 「Managing the Development of Large Software Systems」
　→大規模ソフトウェア開発に関する論文。ウォーターフォールという言葉は使っていない。概念もだいぶ違う。ただ、ウォーターフォールはこの論文を元に開発されている。
2. 米国防総省「DOD-STD2167」
　→手戻りなしの規格がこれ。それまでは標準になるような開発プロセスがなかったので、流行った。
3. 米国防総省「MIL-STD-498」
 →ウォーターフォールがうまくいかなかったので、改めて繰り返し開発の良さを認めた。
4. CMU/SEI「Considerations for Using Agile in DoD Acquisition」
　→アジャイルを使うときの手引き

◇ロイスの論文について
・ウォーターフォールは小規模で自らが使うソフトなら充分かつ合理的
・ウォーターフォールは大規模だとうまくいかない
　→直接的には最終成果物に関わらない追加的工程が必要。
　→なければ失敗する。
　→→オーバーヘッドがあれば妥当に失敗する
　→→なければ失敗が発散する。
・壮大なプロセスを踏まないと発散する
・1回きりではうまくいかない
・反復する
・一つ前の工程に戻ることは想定内
　→それは設計が洗練される行為なので望ましい。
　→反復が局所化されない場合（2つ以上手戻りする場合）はリスクになる
　→→最後のテスト工程で出てくるのは一番まずい。
・テスト工程で明らかになると、手戻りが大きいのでなんとかしないといけない

◇リスクを限定するための5個のステップ
1. Preliminary
　→プログラムデザイン（アーキテクチャ設計）をする
2. 仕様の見える化
　→コミュニケーションの媒体（各種引継ぎのため）。品質の見える化
　→あと、結構な量のドキュメント
　→要求定義書。構想定義書。インタフェース設計書。決定仕様。テスト計画、実施結果、使い方。
3, Do It Twice
　→開発工程を2度
　→プロトタイピング
4. plan, control and monitor testing
　→工数を使うしリリース直前なので、非常にリスクがあり、注力しないといけない
　→テスト計画。進捗把握、品質コントロール
5. 顧客を巻き込む
　→アーキテクチャ設計レビュー
　→実装の設計レビュー
　→受け取り検査

◇ロイスがいいたかったこと
・大規模ソフトウェア開発には特有の課題がある
　→小さいソフトウェアの大きい版ではない
・管理強化・工程の細分化が必要
・管理のためのオーバーヘッドを認識しないといけない
・過小評価するととんでもない失敗をする

◇誤解と偏見
・手戻りあり
・失敗のリスクを限定するためのもの
・リスクに対するコストや時間の追加の必要性
・官僚的なプロセスではない

◇ウォーターフォールはなぜ支持が根強いか
・建設・インフラ開発のアナロジー
・生産工程のアナロジー
・当時は開発プロセスがなかったのでウォーターフォールでもうまくいき、成功体験になった
・水の流れはどこかに落ち着く言うメタファがあり、これが意外と強力


◆ウォーターフォールとアジャイル

◇ウォーターフォールとアジャイルの対比1
・ウォーターフォール
　→作業の分割統治（タスクを積み重ねる）
　→工程表
・アジャイル
　→成果の分割統治
　→達成すること(done)を積み重ねる
　→バックログ

◇ウォーターフォールとアジャイルの対比2
・ウォーターフォール
　→マイルストーン
　→プロジェクトコントロール
　→事前に要求の範囲とレベルを明確にし、成果物を確認
・アジャイル
　→タイムボックス
　→環境・条件の調整
　→つど状況に応じて要求の優先順位を明確にして達成を確認

◇ウォーターフォールの難点
・初期の要求がなかなか確定しない場合
・後の工程になって要求が変更になる場合
・事前よ予見しきれない技術課題
・リスク管理とその運用の難しさ
・コミュニケーションの質の悪化
・官僚的な追加作業

◇アジャイルの難点
・品質保証基準の確立
　→ウォーターフォールは履歴情報を使うことで統計的手法を利用できる
　→→工程と品質基準を結びつけることができる（結びついている）ということ
　→アジャイルはそれができない

◇ウォーターフォール開発を適用する場合
・経験豊富で予見性が高い
・再現性の高い作業の集約になっていて計画できる
・大量の単純作業で労働集約的

◇アジャイル開発を適用する場合
・小規模、少人数
・不確定要素が多く予見性が低い
・リスクが高い
・継続的に保守・拡張する場合
・探索的な試行錯誤が必要な場合


◆まとめ
・「よくわからないけど、とにかくうまくいけばいい」というのは当てものでしかないので学習効果が期待できない
・自分にとっての解決するべき問題やその前提条件を具体的に認知できれば対策は見えてくるはず


◆質疑応答
Q.
「wfのメリットが使える現場ってもうないのでは？」

A.
「あるのは事実。だけど、目指すべきではない。」


◆参加者の意見
・ゲーム業界の場合は、コンカレント型かもしれない
　→コードはアジャイルだけど
　→デザインは違う
　→→いったん決まると、大量のアーティストがキャラクタを作ったりする
・デザイナは音楽聴きながら作業したりする
・プログラム側はほとんどそういうことをしていない
　→それはプログラミングにはコミュニケーションが必要だから


◆補足

・告知・募集ページ
当日のプレゼンテーションのスライド、講演動画のURLが公開されております。
→http://agileucdja.doorkeeper.jp/events/1736

・当日のプレゼンテーションスライド

なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い from Yoichi Tamamaki

玉牧 陽一様, アジャイルUCD研究会様、ありがとうございました。

【チラシの裏】リーンスタートアップ - コンシェルジュMVPの概念を説明する

リーンスタートアップに絡めて、コンシェルジュMVPの概念を説明する

「自動販売機が無い世界で『どの街角でもジュースが売っていると皆が買う』という仮説を立てるとしよう。

これはあくまで仮説なので検証する必要があるが、その為にわざわざ自動販売機を作ることはしたくない。まだそれが顧客の価値なのかは分かってないのだし、できればお金をかけずにこの仮説を検証したい。

だからコンシェルジュMVPを使う。

具体的には、あなたが『自動販売機』と書いた箱を被って街角に立ち、実際に検証してみればよい。

そうやって実際にジュースを売ってみて手ごたえを感じたなら、それは仮説が検証できたということなので、その時に自動販売機を開発すればよい。

逆に手ごたえなんてなくて『誰も街角でジュースなんか買わない』『仮説が間違っていた』ということが分かった場合でも、かかった費用は箱の代金と人件費だけだからそんなに痛くない。

こうやって、人力で顧客価値の仮説を検証するのがコンシェルジュMVP」


本当は、顧客価値についてはもっとしっかり検証する必要があるが、あくまで概念を理解してもらうための説明なので、そこは深彫りしないことにしている。

…自動販売機の中の人ってアイデア、何かの本で読んだ気がするんだよなー。

【チラシの裏】コミュニケーションについての直近の関心

相槌とか同意とか、それが大事なことは間違いない。
でもそれは相手の話を聞いていることを表現するための手段でしかない。

それより、相槌や同意をする理由　…何故そうするのか？ということや、それが学問や実践の領域でどのように表現・理解されているか、ということについて非常に興味がある。あるいは、人間心理や精神活動・何かのコミュニケーションモデルなどの中で、相槌や同意をする理由がどのように定義され、どういう捉え方をされているのか？ということも知りたい。

『相手にどのように向かい合うか』というのは、表層的な手段を散りばめて取り繕えば済むようなものではない。だからこそ、もっとコミュニケーションの奥底にあるもっと重要な事柄を知りたいし、そうやって学びを深めていく中でコミュニケーションの持っている本当の意味について近づいていきたい。

それが座学で学ぶものなのか？というのは間違いなくあるが、座学を押さえておくことにメリットがあることもまた事実。

でもウェブを探してもいまいち情報がないんだよなー。紀伊国屋にでもいって本棚をひたすら眺めていこうか…

【チラシの裏】モチベーションという言葉について

「モチベーションって言葉の意味が人によって違っている。だから、モチベーションという言葉を使った議論は、そもそも空中戦になっている可能性がある」
といった趣旨の会話が、昨日の勉強会であった。

いろいろ思うところがあり、ググってみた。
モチベーションという言葉にはだいたい次のような意味が包含されていることが判った。

モチベーション = やる気
　　　　　　　 = 動機
　　　　　　　 = 自尊心から生まれるもの
　　　　　　　 = 意欲
　　　　　　　 = 欲求
　　　　　　　 = 欲

これらが全て（本質的には）同じものなのならば、モチベーションという言葉を使うことは対した問題にはならない。
同じではないなら、合意を作らず安易にモチベーションという言葉を使用することは、すれ違いや噛み合わなさの原因にもなりかねない。

googleの検索結果を見る限りでは、モチベーションという単語は、〇〇論や〇〇心理・あるいは自己啓発的な何か、といった考えを説明するための道具として使われていることが多かった（〇〇論と書いたのは、それがいろいろあって、全部並べるのは面倒だからだ）。

つまり、モチベーションという単語は、コンテキストによって全く定義が異なっていて、それは、それぞれが物事を捉えるアングルに基づいて好きなように再定義しているとか、あるいは自分の思った漠然とした感覚に当てはめるために字面だけ借りてくるとか、そういった使われ方の集合であるということだ。

十人十色の便利な和製英語になっていて、人それぞれのバックボーンによって意味が全く異なる可能性が高いのが、モチベーションという単語の現状なのである。

要するにオレオレモチベーションがたくさんあるということ。

なので、モチベーションについて議論する際には、その意味について合意を形成し、曖昧さを排除する必要がある。意味を明らかにせず使用してしまうことは、議論の有意義さを損なう可能性がある。

逆に言えば、コンテキストが明確であったり、意味合いについて合意が取れていたりするのであれば、モチベーションという単語を使うこと自体には全く問題がない。

『アジャイルサムライ横浜道場 特別編 パネルディスカッション』ノート

2012/09/06日に開催された『アジャイルサムライ横浜道場　特別編　パネルディスカッション』のノートです。

http://www.zusaar.com/event/355105


誰が何を発言したかというところで曖昧なところがあったので、話者の名前は全て伏せました。



◆インセプションデッキ使ったことはあるか？

◇登壇者A
・契約した段階でやることは決まるので、インセプションデッキをやったことはない
・それよりはチームビルディングをやっている
　→プロジェクトが始まったら、なぜここにいるか？をやる
　→これをやるとだんだんベクトルがあってくると思って活動を続けている

◇登壇者B
・実はアジャイルをやっていない
・アジャイルやる理由には方向づけが必要
・「とりあえず、イテレーションや振り返りをやっているからアジャイル」みたいな所も多い

◇登壇者C
・アジャイルは変化に対応すること
・アジャイルでは振り返りが一番大事だと思う
・振り返りの中から方向付けを行っている
・最初に決めたことは正しいとは思っていない
・何をやっていて何を目指すか、という方向付けは変わっていく

◇登壇者D
・結論として方向付けを失敗した
　→受託した段階で、お客様には何かしらの課題がある
　→参加したプロジェクトでは課題は明確だった
　→お客様に現状維持というところがあった
　→こちらから提案をして遂行していた
　→こちらとしての意向もあったが、そちらにはならなかった
・インセプションデッキでもなんでもよいので、お客様が抱えている問題をきちんと共有する必要がある

◇登壇者E
・チームがあって、チームである程度何を作るかが決まっている。
　→方向付けはそこでできていいる。
・インセプションデッキを作って一番盛り上がったのは、やらないことリスト
　→チームメンバーででやると考えていることがバラバラだった
　→これが方向付けになって盛り上がった

◇登壇者F
・アジャイルでやりたいという話がくる、このときに「やり始めたら上司は基本的に口を出さない」と約束する
・最初はチームはうまく回らない
　→心配になっても口は出さない
　→気になるなら私に相談しろと言う
・チームには段階がある
　→まずは期待や課題・やって欲しいこと（TiDD・タイムボックス的なもの）を伝える
　→やったら次の希望を言う
　→次に一時間面談を行う
　→→「あなたは何をやりたいか、どういう方向性をやりたいか」「こちらとして期待するものは何か」など
・そうやってチームとしてやりたいことの暗黙知をためていって、方向付けをしている


◆方向付けフェーズやお客さんの意向を探るときなど、どうしているか？

◇登壇者C
・今はご年配が使うシステムを作っている
　→そこでの使いやすさは"自分の使いやすさ"とは違う
　→想像して、ヒアリングして、ちゃんと対象の具体的なデータを集めてこないと具体的な方向性は出せない
　→→そこで手を抜くと、内側によった自分達だけが考えたシステムになってしまう
・自分達が生みだす価値が何かを考えたら、使う人をできるだけ想定するしかない
　→使うターゲットが明確なら楽

◇モデレータA
「自分は農協のシステムでタブをつけたら、それは誰も使わないと言われたことがある」

◇登壇者B
・ユーザ会社とシステム会社の偉い人で方向付けが違うことがある
　→そうすると作っても平謝りするハメになる
　→「そもそも何を作ろうか？」「何のために？」「何を効率化しようとしてたの？」というのをやらないといけない
・理解できないものに100%の頭を使うことはできない。

◇登壇者C
・大きいシステムだと全員に周知できないのが問題だと思っている
・方向をごく一部の人が握っているだけだとうまくいかない
・その齟齬を解消しようとするのがアジャイル

◇登壇者D
・お客様のほうで制度を変えようという話があって、お客・コンサル・偉い人の話は合っていた
　→でもそれぞれ方向付けは違っていたのかな？と思う


◆みんなの方向がバラバラだと気付いたときにどうしたか？

◇登壇者B
・バラバラなのは話がまとまってないから
・おなかがすいているというのが一致していても、それぞれの状態が異なる（とにかく食べたい、空腹だけど胃もたれしている…など）

◇登壇者F
・似たような状況があった
　→POはある程度の責任を持っている
　→でも彼がユーザにとって本当にいいアイデアを持っているかというと、そうではない
　→そうなるとPOに対して、いい関係を作ったりモデリングをしても答えが出ない
　→そうするとPOはしょうがないとして、エンドユーザを見つけてそこにアプローチしようとしている。
　→→でもエンドユーザは忙しい
　→→その上の人に働きかけして、デモの時間をもらったりした
　→→そうやって少しずつ関係を作っている
　→→→そうやるとチームが顧客の欲しいものについて考え始める

◇モデレータB
・そもそも人のことを知らなさ過ぎると思う
　→10年後何をしたいかとか、家族のこととか
・何でそれが問題かというと、チームを同じ方向に向けるときに全員に同じやり方ではうまくいかないから
　→「ならば、チームのことをしらないでどう働きかけるんだ？」という話になる
　→「お客はもちろんだが、チームを知るために何をしているか？」という話

◇モデレータB
・向け方はいろいろある

◇登壇者F
・強制しても向かないので、向くようにする必要がある

◇登壇者C
・人はかえられることを嫌がる。変わるようなヒントを提示しないといけない

◇登壇者F
・だから先に聞く
・そこから「そこを僕は期待している」というと喜んでもらえる
　→その人のキャリアも含めてモチベーションを上げていくことを考える

◇登壇者C
・どうしても合わない人もいると思う

◇登壇者A
・みんな人間なので、そこは信頼関係
・相手が困っていることを助け、信頼してもらうことを繰り返し、関係を築く
　→そうすると、こちらがやりたいことができるようになる

◇モデレータA
・チームにコミットしてもらい、チームとしてプロダクトにコミットしてもらわないといけない

◇モデレータC
・作るべきフェーズがとっくに終わってるのに、インセプションデッキが入って無いという話があったが…
→インセプションデッキはいつ作ってもよいもの


◆アジャイルをやると問題が早く見つかって早く対処できるという。本当に？

アジャイルで見つかるものも見つからないものもあると思うが？

◇登壇者C
・アーキテクチャの根幹に関わるようなもので、ちょうど見つからない問題があった
　→アジャイルはコミュニケーションを活発にする手段
　→→チームでは活発的になって、その中で出るような話題は見つかる
　→その隣のステークホルダー、想定しきれなかったユーザの持っている問題は見つけられない
　→→→それで酷い目にあったりする
・コンセンサスが取れていたというところで思い込みがあった
　→それはアジャイルどうこうというより対話のミス
　→そういうものはアジャイルでも取れないよ？

◇モデレータC
「その問題はなんで見つかったの？」

◇登壇者C
「リリース前に想定していたユーザに話をしたときに突っ込まれた」

◇モデレータB
「ポイントポイントでデモしてなかったんですか？
顧客プロキシにはデモしていたけど、顧客にはしていなかったってこと？」

◇登壇者C
「そう」

◇登壇者A
「前向きに捕らえたらリリース前に見つかったという話では」

◇登壇者C
「そうだけど、そのときに作ったひずみで今苦労しているという」

◇モデレータB
「アジャイルで早く見つかるものとそうでないものがある」

◇登壇者A
「今のケースは早くフィードバックを貰えたからいいのでは？」

◇モデレータB
「今のはウォーターフォールでも同じでしょ？」

◇参加者
「逆にアジャイルだからこそ見つからなかったことって？」

◇登壇者B
「アジャイルでは問題がイテレーションごとに解決される。
お客様が暗黙に期待してしまうことがある。
いつか何とかしてくれるでしょ？という」

◇モデレータB
「それはプロダクトバックログの運用ミスのような気がする」


◆参加者
「新しく機能が発生したゆえに、前の問題が出てきたことは？」

◇登壇者A
・ジャストインタイムで機能を提供していたときがあった
　→増改築の繰り返していた
　→何ヶ月かあとにアーキテクチャが破綻した

◇モデレータA
「それはじっくり設計したら回避できたパターン？」

◇登壇者A
「どこかでリファクタリングしていればどうにかなったと思うが、ある程度大きくなるとどうにもならない」

◇モデレータA
「リファクタリングしていればなんとかなった？」

◇登壇者A
「傷は浅かったと思う」

◇登壇者C
「リファクタリングし損ねたのと、アーキテクチャが破綻していたのは別」

◇モデレータA
・リファクタリングっていうのは、ご飯があふれているかきっちり詰まっているかの話でしかない
　→そこに入らないものはそもそも入らない

◇登壇者F
・今のような事例が起きたら、まずチームに問題があったのでは？と考える
　→案件やチームによって、その事態の重要度は違う
　→自己組織化が基本なので、それはチームで答えを出してもらって次に生かしてもらうようにしている
　→→要はチームの力不足
　→→本当は隣の人にも気をつけないといけなかった
　→→それはウォーターフォールでもアジャイルでも変らない
　→→ならどうして最初から考えられなかったのか？というのを促す


◆モデレータA
「チームの力で解決できると言う話であれば　…すごいチームなら何でもできる？」

◇登壇者F
・精鋭が集まればウォーターフォールでもアジャイルでも何でもできる
　→だから、問題にチームでアプローチし、チームなりに答えを出してもらう

◇登壇者D
・早くお客に見せていて気がついたことがある
　→コンサルのいうとおりに作っても、お客に「違うよ」という風に言われる
　→→コンサルの方向とお客の方向は違う
　→→アジャイルならそれを拾っていける

◇モデレータA
「実はコンサルが言っていることが正しくて、ユーザが間違っている場合があると思う。自分の中でユーザ側に倒した理由は？」

◇登壇者D
「お客様の声がすごい強かった」

◇モデレータA
「確実に地獄行きでも？」

◇登壇者D
「そこは取捨選択した」

◇モデレータB
・どのくらいの地獄かによる
→マイルドな地獄なら行かせる
→会社がやばくなるなら絶対とめる

◇モデレータD
「アジャイルかどうかと問題が早く見つかるかはあまり関係ないような気がする」

◇登壇者E
・アジャイルじゃないと「問題が見つからない」と言って隠す
　→アジャイルだと隠しようがない
・今までだと（作成中に）必要だとわかっていても、その時点ではやらなかった
→そのまま作って、使いにくくなってからやっていた
→アジャイルだとその段階で手を入れられる

◇登壇者D
・けっこう頻繁に聞けたときはあまり炎上しなかった
→結局、コミュニケーションがとれてないと駄目


◆ウォーターフォールについて

◇モデレータA
・ウォーターフォールはある時点での幸せな話
　→後で本当かどうかは誰にもわからない
・ウォーターフォールで違ったら、また滝を流せばよいだけ
　→そこでとめてしまうというのがそもそもの原因
　→→スパイラルで回せば解決するのでは？


◆ストーリーは必要になったら詳細化すればよいというが、そもそも詳細にしないと分からないことがあるよね？ということについて

◇参加者
・ユーザストーリのときは詳細に分析するなというが…
　→普通の人の場合、具体的な画面や例外ルールを見せて初めて気付いてくれることがある
　→→詳細な分析をして始めてユーザが受け答えできるという話
・詳細な分析をしてみないと、アーキテクチャに関わるような問題が見つからない場合がある
　→そこは難しい？

◇登壇者A
　→→それはリスクをどうヘッジするかと言う話
　→→→やったことがないというリスクを最優先にするか、価値を最優先にするか

◇参加者
アーキテクチャに関わるところはリスクだから最初にやろうということ

◇登壇者F
・平鍋さんが言っていたこと
　→ショートケーキを小さく作るのと同じで、アーキテクチャも本当に薄く作っていく
　→それでうまくいくのではないかと思ってやっている
　→アーキテクチャもアジャイル的に育てていっている

◇参加者
・ファウラーも「アプリもアーキテクチャも同じ人がやっていないと分厚くなる」言っていた

◇登壇者F
・チームでコミュニケーションできるようにして、横のつながりを作っている
・3週間枚に集まってアーキテクチャやフレームワークを入れていってもらっている


◆モデレータA
「アジャイルを始めるにあたっての最初の問題は？」

◇登壇者E
・ベロシティが0だった
・ストーリが大きすぎた上に、何をしたらいいのか分からない状態だった
・そこがわかってからはよくなった

◇モデレータC
「それは問題？見つかってよかったね？」という話では？


◆モデレータD
「誰も興味を持ってくれないとかは？」

◇モデレータD
・飲み会でうんというまでやるとか
・力を見せるとか
・最初から全ては使えないので一部分だけ使って効果を見せたり
・早く帰ることができるようにしたりとか

◇登壇者D
・名前で言うと拒否られるというのはあるんじゃないかな
　→アジャイルと言う名前を出さないときはよかった
　→アジャイルといった瞬間に「えー？」と言われた

◇登壇者C
・朝会が長いと言うのがある
　→チームにしゃべる人がいると長くなる
　→→個別の状況に入ったりとか
　→→→そういうときはきらないといけない

◇参加者
「それってファシリテーションの能力では？」

◇登壇者C
・そういう人がいるとわかっていても、結局長くなる
・的確な時間に収めるというのはやはり難しい

◇参加者
・朝会の問題は、毎日進捗会議をすることになってしまうということ

◇参加者
・朝会のあるある　…集まらないということが多い

◇モデレータB
・特定の人がいないと集まらないとか

◇モデレータA
・最初に席をたつ人はいつも同じとか


◆モデレータA
「振り返りとかで何かないですか？」

◇モデレータA
・問題を人に落とすというのがある
　→チームではなくて、犯人探しになるとか

◇登壇者F
・KPTがどんどんたまっていった
　→何をどうしたらいいか分からなくなったことがあった
・問題には新鮮さが必要
　→3週間前の問題なんかだんだん忘れてしまう

◇モデレータA
・賞味期限を決めて自動で捨てる人もいる

◇モデレータB
・アクションがないからそうなる
　→Doneの定義がないとなりがち

◇登壇者B
「KPTに何かアクションがとれなくて、ただの愚痴になる状況がある」

◇モデレータA
「制度と会社と仕組みのせい」というのが最初は出がち

◇モデレータB
・そういうのが多いのはもう組織の問題
・チームで拾えないものはマネージャが拾わないといけない
　→こんなこと無理だろうなと思って出てこなくなることの方が怖い

◇登壇者A
・顧客不在
・担当の方が日常業務を持っていて時間をとれないとか
・POが業務知識が薄かったり倒れたりして、来なくなったことがあった


◆そもそもアジャイルをやるスキルがない

◇？
・ペアプロでいいのでは？
・そういうのをやりたがらない文化がある

◇モデレータA
「空気を読んだり、気にしたらダメ」

◇登壇者C
・アジャイルをやるときのチームの意識を一定ラインに保たないとダレる
　→自分の中の人の規律を守らせないといけない
　→守らなかったからって明確なペナルティがあるわけではなくて、緩やかにダレていく
　→→そこでスクラムマスターが欲しいと思う。


◆モデレータB
「個人のバイオリズムもあるのでは？」

◇登壇者C
・気が乗らないとかそういう心理的なものを維持するのは本当に難しい
・でもそれができないとどんどんダレる


◆登壇者A
「だれる原因は？慣れとか？」

◇登壇者C
・自分自身のチームへの責任感をどこまで取れるか
・無理をするというのはアジャイルではない
　→確実にやれる範囲をやるというのはあるが、そこに甘えるとどんどん下がっていく


◆モデレータA
・それは期待マネジメントでは？
　→いつも真面目じゃなくていいのでは？

◇モデレータA
・これらは別
　→アジャイルやるぞ！というテンションの時のオーバーコミット的なもの、それがが落ち着いている
　→単にだれている

◇登壇者D
・ベロシティを計測していたら、見積もりも苦しまずにすむようになった

◇登壇者C
・やれる範囲の見込みがあがった

◇モデレータC
・見積もりの精度も上がった


◆モデレータA
「ベロシティって伸びてる？」

◇登壇者D
ちょっと伸びてるかもしれない

◇モデレータA
伸びてるならいい

◇登壇者D
・残業していないので、けっこう自習する時間がとれていろいろ見えてくるというのがある


◆参加者
「チームのベロシティの上がり具合というのは？」

◇登壇者C
「CI、ユニットテストを明確に意識してくれるようになった」

◇登壇者A
「もうちょっと進むとプラクティスがあるのは当たり前になる」


◆モデレータA
「お客様の変化ってありませんでした？」

◇登壇者B
・アジャイルをやったらフィードバックが早くなった
　→お客様がなんでも言うようになった
・聞き分けもよくなった
　→今まで見たいな無理押しがなくなった

◇登壇者D
・お客様とコミュニケーションを取っている
　→お互いに言いやすくなって信頼関係が築けるようになる

◇登壇者E
・メンバーが明るくなった
　→今まではもくもくとやっているだけだった
　→手が空いたら他の人を手伝ってくれるようになったり、活発になったような

◇明るくなったメンバー
・なんか明るくなったねって言われた
・「進んでこれやったらもっと楽になるのに…」というのをやるのに抵抗がなくなった
・やってもいいんだという気付きがあった

◇モデレータA
・前の会社でカスタマサポート向けの仕事をしていた
　→その仕事を何のためにやっているか、お客様の誰も知らなかった
　→お客様にプロダクトバックログを作ってもらった
　→→そうしたら、お客様が「最終的に会社の業績を良くするためには？」と考えるようになった
　→→→それはすごくよいと思った
　→→→これが最終形だと思う







アジャイルサムライ読書会 横浜道場事務局の皆様, モデレータの皆様, パネリストの皆様、ありがとうございました。

『アジャイルサムライ読書会 新宿道場#10 - トークセッション』ノート

2012/09/01に開催された『アジャイルサムライ読書会 新宿道場#10』のノート。これは前半のトークセッションです。やはり、マスターセンセイの体験から語られる言葉は一味違うというか　…私とは経験値が圧倒的に違うということを痛切に感じました。

何年か後に読み返したときに、今とはまた違った角度から読むことができれるくらいに経験を積んでいきたいと思います。



◆トークセッション

◇マスターセンセイ

・西村直人氏
・角谷信太郎氏


◇質疑応答

※「」がついている発言がマスターセンセイのものとは限りません。ご了承ください


Q. アジャイルやりたい人の転職率の高さは何か？

A. アジャイルはチーム開発。チームでないと始められない

「1人でペアプロしている時期もあった。少しずつ回りを巻き込めたが、本を読んでいるうちにもっと速いペースでやりたくなった」

「「あの人とやりたい！」か「会社を変えたい！」のどちらのパッションがあるかで行動が変わる」

「会社を変えることにパッションがある人もある。会社を変えるのはまた別のパッションということ。自分はそうではないので会社を変えた」



Q. 転職したらハッピーになれるのか？
Q. 転職してすぐにハッピーになれるのか？

A. 自分が転職したときは「アジャイルやってないよ？」といわれた

「客先常駐の仕事ばっかりだった」

「社内の勉強会、プロジェクト間での情報交換などをやっていた」

「アジャイルなプロジェクトはなかったので、アジャイルにできるところは勝手にアジャイルにして始めた。カンバンとか朝会も勝手に始めた」

「現場は少しずつよくなっていった。自分達のやり方が認められることはあったが、それでも変わらないことはあった」

「そのうち、二重にやることの限界が分かってきた。途中から「自分達で仕事を作るぞー」と集まってどうやって契約を取れるかを集まってやった」

「自分で客を取ってまで仕事をするぞ！という人が多かったので、勝算があるとは思っていた」

「売り上げのことは必ず言われる。数字さえ取れば文句は言われない」

「東京は手ぶらできたので色がなかった。自分達で開拓できた。「今までやっていた」ものがなかったのでやりやすかった」



Q. アジャイルって儲かるの？

A. あまり儲からない

「（アジャイルコーチは）いなくてもできるようにするのが仕事なので難しい」



Q. アジャイルの利点は適正なお金で働けること。儲かりすぎたらいけない。と聞いていたので安心した

A. もうちょっと儲かりたいとは思う

「食べられるかというと　…なんとか食べられる」

「もらえる額が決まっている場合、長期間働かされるのでしんどいが、アジャイルはやっただけなのでそこはよい」

「ただ、終わったらそこで終わりなので…」



Q. アジャイルってエンジニアのマインド・スキルが重要だという意識があるが？

A. チームでできるようになっていればかまわない。チームのスキルセットが偏るのはよくない

「スキル重要と呼ばれていく現場は、だいたいレベルが低い（アジャイルをやる以前で、そもそものスキルが低い）」

「お客に価値を届けるという人が多ければ価値をとどけやすい」

「今できない人もプロジェクトの中で学んでいけばいい」

「それは上の人がどれだけ関わるか。成果を出すためにどうすればいいか考えてくれれば結果が出る」

「集めてスクラムやって、だとそこそこの成果しかでない。」

「みんなにアジャイルの価値観がなくてもできる」

「最初は違っても、実際やれば化ける人がいる」」

「縦でスライスして動かすやり方を知り、今までとは違うやり方で成果が出せると気付くと変わる人いる」

「ユーザーからのフィードバックがあると、やっている方も面白く感じる」



Q. キャリアが与えられるものから自分で作るものとなってやる気が出るのか？

A. そうかもしれない

「チーム振り返ってもらうと「仕事の幅・視点が広がった」というフィードバックが多くもらえる」



Q. 与えられるものへの認識が"苦痛"から"もっとやりたいもの"へ変わるというところもあるか？

A. 何がヒットするかは人による

「押しても引いてもだめだという人もいる。絶対変わりたくない人もいるけど、それは100人に1人か2人。だいたいは（度合いはあるけど）順応できる」



Q. 仲間がいないとつらいというのがある。そこへのアドバイスは？

A. やりたい人がいるところに行くのがよいのでは？　一番お勧め！

「プロジェクトの進め方などについては話合うが、そもそも仕事をどうすべきか？ということを会社で普通に話すことはない（飲み会はともかく）。そのような会議体はないし、定例で行ったりもしない」

「言わないだけで考えている人はいる。送別会で「実は…」と切り出す人がいたりして「おいおい！遅いよ！」となることはある」



Q. 失敗談とかありますか？

A. 「なんとかうまく行ったけど、もう一回やれば（もっと）うまくいく！」というのはある。（そういう意味では）失敗ばかりしている

「お客さんの期待をコントロールし、どこまでできるか理解してもうことは重要」

「きちんと踏み込むことも重要」

「リリースにあたっての重要人物や本当の目的などのTough questionも重要」

「"安請負"や"やれると思ってた"で失敗することが多い」

「お客様から言われたことをただやれば価値になると思っていた時もあった」

「「ツールがこうしろと言っている。だからこうする」というのは駄目」

「ツールのせいにしたり、手順を強要したりするのは駄目」

「失敗をアジャイルのせいにするのはよくない。プロジェクトは1回しかないので、何かのせいにするしかないが…　でも、そういうところはアジャイルでなくても失敗する」



Q. ?

「今までの仕事のやり方とは変えていかないといけない」

「昔からある会社は（昔から）違うやり方をしているから、（変化を）やりづらくなっている。大きい組織なら少しずつ変えていくしかない。」

「組織のとしての理解・サポートが重要」

「決める人と作る人の距離を近くしないといけない」



Q. 書類を求めるような、「がちがちに作ってあるから変化に対応する必要がない」と、言っている現場にはアジャイルは向かないと思うが？

A. 「変化しない、タスクがぶれない、要求がぶれない」というのであれば無理してやらなくていい



Q.  テストが実装工程の後にあるプロジェクトの場合、テストファーストで書いていると（バグ発生率などで）困ってしまう。どうすれば？

A. 自分達が書いたテストを後工程でまとめて資料にする

「ついでに既に書いたテストを整理するのもよい」



Q. 大事な要素が後になって判明して大変なことになることがある。どうすれば？

A. わかってから着手すればよい。

「全部決めるのは難しいが一週間なら決められるよね？というのがアジャイル。先のことは難しいという話。フィックスしたものを作ればよい」

「逆はWBSの「先の話は見切ったー！」という話。でも三ヶ月後なんてわからない」

「考えたり、アイデアを出したり、というのも普通にストーリーに入れたりする。あやふやなものを細かくちぎってストーリーにするのが正しい」

「『ふわふわしたものをただ「アジャイルに」とやってもうまくいかない。ただそれはウォーターフォールでもアジャイルでも同じ」

「ユーザはストーリを書けない。それでは価値を計測することもできない。お客様のほうに説明することも大事」

「いったん小さくてもいいから決める。それに対して追加・変更を行う」

「ミニマムでも完成させれば、それは使えるものなので、そこにたいして追加・変更をもらう」

「「できません」とは言わない。「やるけど、できる量は決まっているのでどちらにしますか？」とする。それが変化に対応するということ」



Q. ?

「詳細設計が終わってドキュメントを作っても、結局やり直すことになる。引き継ぐならただ読むだけならだめで、その後ろにあるものも理解する必要があるから。「製造して」とドキュメントを渡されても、製造側は結局全部やることになる。」

「製造フェーズで全部やり直すことがあって、それを詳細要件定義と呼称したことがあった」



Q. ドキュメントをどれだけ作る？

A.  必要なものは作る

「中の人はほとんどドキュメントがいらない」

「お客などに毎日会う環境はいずれなくなる。自分達以外の誰かに引きつぐときにドキュメントを残す必要がある」

「ユーザに合わせて作る」

「全部作るかと言うとそうではなくて、減らせるものは減らせる」

「ドキュメントを書くかわりに、（動作を理解するための）スクリプトは全部作る、というやり方もある。そういう場合、こちらから自信をもって説明することが必要」



Q. 後から入ってくる人向けのドキュメントは？

A. 毎週入ってくるなら作る

「聞いたほうがドキュメントを作るのは良いプラクティス。ドキュメントができあがるので、教える側にもメリットがある」

「何が判らないのか、教える側には分からない。だから聞いた側がドキュメントを作る方がよい」



Q. その日のうちに作ってくれと言う現場があって、そういうところだとエンジニアには無限の負荷がかかる。ユーザ側から見た品質も悪い。そういう現場で人間らしい働き方をするためには？

A. まず見える化

「物凄い量の仕事が来ていることをきちんと見せる。あからさまにおかしいという状況を見せれば、口答えできる」

「退社時間や睡眠時間の見える化も有効」

「見せれば偉い人の誰かが気付く。気づかないなら、それは…」



◇その他

「イテレーションの運営の話について、アジャイルサムライの206ページにしれっと大事なことが書いてある」

「"昨日のテレビの面白いこと"と同列で"アジャイルをやりたい"では誰も信用しない。やはりパッションが必要」

「意外と学習効率って悪くて、学ぶには時間がかかることに気をつける。業務時間外に勉強会などに参加して学んでいる人と、たまたま隣の机に座っている人。使っている時間が全然違う」






西村直人様、角谷信太郎様、tmmkr様、tk0miya様、eji様、ありがとうございました。