2012年4月23日月曜日

Infotalk#41

2012/04/20に開催されたInfotalk#41のノートです。


講演の内容も面白かったですが、質疑応答の話が(自分にとって)リアルで興味深かったのでこちらのノートをまとめました。話題が多岐にわたっているのですが、それぞれに「なるほどー」と思うところがあってよいです。 …もっと話を聞きたかったし、懇親会には参加すべきだったと素直に思いました。



◆モデリング

◇ユーザにモデリングしてもらうことの目的

まず、モデリングの目的について考える。成果物が目的なら専門家がやればよい。参加している人達に全体像を理解してもらうことが目的なら極力彼らにやってもらうようにした方がよい。技術を身につけるためには、見るだけではなく五感を使うことが効果的である。


◇概念モデリングを実生活の中で身につけるためにオススメの方法

本を買ってやってみてもわからない。講習会に行くか、経験者と一緒にやってみる。

モデリングには適正があり、できる人とできない人がいる。センスがある人は1日2日でも割とできるようになる。(あくまで山勘だが)まともにモデルできる人は5%くらいしかいないのではないか。ただし、できない人にも分かる日が来る。


◇いままでモデルを知らなかった人がモデルをとらえられるようになる、という変化について

(モデルを)とらえるというよりは、(モデリングを)分かってしまうというのが適切だと思う。

例えば、PBLの成果発表の際に聴衆からアンケートを取ると「あんなのでわかるわけがない」という回答がよくあり、やったことがない人がそう思うのは当たり前だと思うが、やっている人はPBLのやり方で分かってしまう。論理的な話としては怪しいが、そういうものがある。


◇論理だけでは達成できない世界がある?

論理だけで達成できる世界とそれだけでは達成できない世界があるのではないか。非科学的な話になるが、潜在脳みたいなものがあり、そこで問題意識を持ってとらえていると、ある日突然それが顕在脳に移り、「あぁ、なんだ…」というものになったりするのではないか。


◇モデルができる人とできない人の違い

本人が分かると思うかどうか。やってみて「なんだこれは」「こんなのやっても仕方がないじゃないか」と思ってしまう人はやらない方がいい。モデリングはあくまで特性の1つであり、それが全てではない。全員ができる必要はない。モデルと違う頭を持っている人は、自分の得意なところを伸ばせばよい。モデルに拘る必要はない。



◆情報システム業界

◇収入・就労形態及び業界について

雑誌などにIT業界年収ランキングなど掲載されていることがあるが、あれはあくまで平均年収。稼いでいるのはフリーでやっている人やコンサルティングファームにいる人。情報システムのSEという範疇だと余り稼げない。

日本の情報システム産業は人貸し業になってしまっており、人月幾らで人を貸すという話しかやっていない。なので、例えば月200万の人間の年収は7~800万くらいだし、60万なら年収200万くらいにしかならない。そういう意味で人貸し業としてのITベンダーは終っている。


◇CIOについて

日本にはまともなCIOはいない。これが上がりのポスト、という人がいっぱいいる。偉くなった人が最後の数年を過ごすポジションである。つまり、可もなく不可もなく終るということしか考えていないような世界。

◇情報システムの成熟度について

1. CIOがいらない世界

一番最初の情報システムはサイロ型。それぞれのシステムが独立。システムは特定の機能だけを表現する為のもの。インタラクションは皆無。情シ部の部長や課長がいて、次に何を作ればいいかが分かっていればいい。


2. 情報システム部の部長上がりでCIOが勤まる世界

コンピュータのスペックが上がってくると、インフラを統合しようという話になり、方法論を標準化しようという世界になる。情報システムの長には、技術の観点からシステム間の横串をさす技術が求められる。


3. CIOにビジネスの観点が必要となる世界
CSMなど、ビジネスの中で横串を指すという話になっていく。そうすると技術だけでなくビジネスの観点が必須となり、ビジネス出の人がCIOになる。これがここしばらくのトレンド。


4. 最近~今後の世界

ビジネス出の人がCIOになるというトレンドがあったが最近では逆になっており、実装方法が求められるようになっている(例えばホストと、PCサーバを並べてスケールさせるのではコストが全く違う)。こういう世界でシステムを考える為にはハイブリッドなスキルが必要になる …でもそんな人はいないので、ビジネスと技術の両方ができるチームを作り、対応していくような世界になっていくのではないか?





南波 幸雄様、KOYAMA Hiroshi (pk0612)様、ありがとうございました。

2012年4月14日土曜日

第5回 TFSUG:ウォーターフォールからアジャイル、リーンへ - TFS de アジャイルを書いたわけ

2012/04/13に行われた『第5回 TFSUG:ウォーターフォールからアジャイル、リーンへ』のノート。これは前半。


■『TFS de アジャイルを書いたわけ』

『TFS de アジャイル』は、『寝ても覚めても.NET(?)』というブログの次の記事です。

・寝ても覚めても.NET(?) - TFS de アジャイル
http://cs.gogo-asp.net/blogs/libaty/archive/2012/03/28/TFS-de-_A230B830E330A430EB30_.aspx


自分のスタンスやアジャイル導入への経緯、アジャイル導入後について、行ったことや感じたことが綴られています。

libaty様自身が引き続きブログで体験談や思ったことなどを綴っているので、詳しい話や経過を知りたければそちらを見た方が確実なのですが、個人的にとても興味深かったのでノートにまとめました。



◆前提

・体験談であるが、アジャイルを実際に始めてから5日しかたっていない。



◆状況

◇背景・周辺

・アジャイルには特に興味はなく、ウォーターフォール開発を続けていた。
・頭の中はウォーターフォール一色。
・便利そうなのでユニットテストや自動ビルドなどのプラクティスは使っていた。
・社外の知り合いにアジャイルソフトウェア開発に携わる人物が多数いる。
・グループ会社内に導入実績が多数 + アジャイル支援チームがある。


◇アジャイルへの立ち位置

・始めようとしたのがここ数ヶ月の話。
・やってみたいという意識が強い。
・アジャイルが本当においしいか知りたい。



◆導入への経緯

◇1月~2月の種蒔き

次の活動により、ミーティングで居眠りしている人物が発言するようになった。

・技術関係の勉強会から、アジャイル関係の勉強会へ参加の幅を広げた。
・部下をイベントに引っ張り出した。
・上司にはアジャイル関係のイベントに行くことを伝え続けた。



◆導入

◇流れないウォーターフォール開発を続けているパッケージにアジャイルを行うという形で参画


・流行っているということでスクラム。
・スプリントの長さやリリースのタイミングは、だいたいこのくらいと聞いている数値を採用。
・プラクティスをいろいろやってみる。
・プラクティスの採用に迷ったら、とりあえずやる方向に倒す。
・困ったときはアジャイル支援チームから助けをもらえる体制へ。
・タスクの2点見積もりを採用。
・チームメンバーと目的や意識の共有をした。

・敵対関係(怒り)の感情を作りだす。敵はチームメンバーではなく、問題。



◆導入後

◇実際にやってみて困ったこと

勉強会は15時間を行ない、やり方はわかっていたが…

・フィーチャとファンクションの区別。
・タスクやバックログの粒度。
・開発に必要なドキュメントって何?
・品質保証、品質管理、テストはどうするの?


◇アジャイル支援チームから次の指摘があった

・何故やるのかを考えるように → 言われたがピンとこない。
・とりあえずやってみれば → 失敗したという前例は、採用しない理由になってしまうので怖い。


◇タイムボックスの使い方が難しい

・タイムボックスの枠内で会議ができない。話が発散してしまう。
・時間内に収まらないので延長してしまう。
・とりあえず同意して済ますと、後でひっくり返す人物がでてくる。


◇スプリントも難しい

・作業について時間に追われているような感覚になる。
・ヒマがなくなってしまう。


◇計画できない・考えても仕方がないという状態で動くことへの気づき

・時間を使っただけになってしまう。
・その場でどうすればよいか困ってしまう。
・とりあえずやってみると無計画は似ているが違う。
※註:前者は『ある程度まで段取りなどした上で見切り発車』、後者は『何も考えずにする』、という区別をなさっていると思います。


◇その他

・頭をすごく使うので疲れる。
・お菓子の重要性を認識。




◆良かったことと悪かったこと

◇良かったこと

・みんなで仕事をする、という感じがでてきた。
・議論が活発になった。若手も自発的に発言するようになった。


◇悪かったこと

・疲れる
・メンバーの(技術・ファシリテーションなどの)スキル差が如実に現れる。





TFSUG様、@LIBATY様、@SHIBAO800、お疲れ様でした。


2012年4月7日土曜日

『 IDEOディレクターElle Luna氏とOneSheetの創業者Brenden Mulligan氏による「Startup Strategy」』ノート

2012/04/04に開催された『 IDEOディレクターElle Luna氏とOneSheetの創業者Brenden Mulligan氏による「Startup Strategy」』のノート。


これはElle Lunaさんのプレゼンテーション。

※管理人のヒアリングスキル及びあくまで意訳であることには留意してください。








◆Elle Luna 『How you can think like a designer To make difference in your startup』

 - 『デザイナーのように考え、スタートアップを差別化する方法』


◇はじめに

 今日お話するのは、本当に具体的なことです。

 IDEOを辞めスタートアップの会社に入ったときくらいから、ずっと考え続けてきたことです。

 スタートアップにあたり、デザイナーのように考えるには? ということについて話します。テンションがあがってしまいます。




◇何故デザイナーのように考えるのか?

 スタートアップの際、なぜデザイナーのように考えなければいけないのか?と思っている人もいますよね。

 あくまで私見ですが、スタートアップをデザインすることは必要不可欠だからです。

 それはrethinkすることであり、(デザインがなければ)会社の評価はそれだけ小さくなってしまうからです。

だから話すのです。デザインは本当に重要です。



◇何故デザインなのか?


自分のビジネスが将来どうなるかなんで誰にもわかりません。スタートアップも、何がどうなるかはわかりません。

最善策の代わりとして、『試してみる』ことができます。

あなたはマーケットにフィットする箇所を、スタートアップの中から見つけようとします。ファウンダは、開始してみるまでそのサービスがどこに向かって進んでいるのかは分からないものなのです。

たくさんの曖昧さがあります。たくさんの知らないことがあります。デザインが素晴らしいのは、それが曖昧さを許容する為の非常に偉大なプロセスであるからです。プロセスがあれば、どこに向かっているのかわかります。



1. Start with people - 人から始める

最初のステップは『人から始める』。ブレインストーミングやイケそうなアイデアの実現方法に時間を費やす代わりに、そうするのです。ブレインストーミングから始めてしまうことには本当に問題があります。外の世界に触れないままで明確化できる、という人はそう多くないのです。

では、本当の課題はどこにあるのでしょうか? 課題は生身の人間のところにあります。日々、あなたの周りの人達は問題を抱えています。あなたは助ける必要があります。


※ここでSquare創業者が引き合いに出される。彼は、人を良く観察し、カードでの買い物には沢山のプロセスが介在していることに気づいた。そして、そのプロセスって本当に必要なのか? となった。





人から始めるにあたって、次の三つの質問を自分に問いかけましょう。

・人々が抱える日々の本当の課題をどのように観察できていますか?

・あなたのプロダクトを(多少手間があったとしても)ユーザが使おうとするモチベーションは何ですか?

・あなたのプロダクトの中でstep1. step2. …のような(こまごまとした)操作をユーザにさせているものは何?





2. Stop talking, start making - 話すより作る

スタートアップのアイデアは聞きたくありません。私は見たいのです。ポストイットでも構いません。できあがった何かが見たいのです。

それがあれば、皆とより早いタイミングで、より実りのある話ができるのです。

もう1つポイントがあります。よいアイデアというのは思いを巡らせているときには出てこないということです。考えることは素晴らしいことですし、よいアイデアを持っているというのもわかります。

しかし、実際にアイデアを掴む為には、作らないといけないのです。

分かりますか? 作り、試行する、ということを始めなければいけないのです。

さて、私が大好きな、作ることの力やどうやって全く作り変えてしまうかに関するIDEOでの話をします。


※鼻の美容整形に使用する器具の製作事例を紹介





もう作り始めることができますね。

・プロトタイプから何を学ぼうとしていますか?

・学びたいことを迅速かつ多量に得る為に、どうすればよいですか?

・チームは、明日からでも大まかなプロトタイプを手早く作ってみせることができます





3. Prepare to throw away a lot of work - たくさんの仕事を捨てる為の心構えをする

頭にあるものを実体に落とし込むため、手早くプロトタイプを作ります。つまり、沢山の物ができあがるということです。

これでもかというくらいの山を見たこともあります。

あなたは思考を重ね、沢山のアイデアを目に見える形にします。沢山の物を作り、そして、いつかは放ってしまう必要があります。

さて、よりよくするために沢山の成果物を捨てて見せたインスタグラムという企業の話をしましょう。

彼らが最初に始めたのはBurbnというサービスでした。150人向けのベータテストを行ない、ファウンダはユーザの行動を観察しました。

なんと、ユーザは写真をアップロードしようとしていたのです。Burbnに写真のアップロードする機能はなかったにも関わらず、です。

ユーザは写真を他のサーバにアップロードし、そのURLを貼り付けることで写真をやり取りしたのです。なんでこんなイカれたことをやっているのでしょうか?

ユーザは超カッコいい写真をシェアしたかったのです。

ここで彼らは気がついたのです。「写真をシェアするというのはこんなに面倒なのか。たかが写真のアップロードをする為だけに、Burbn外のサービスで幾手間もかけないといけないなんて…」

彼らは考えたのです。「なんで、何を差し置いても(写真をシェアする機能を)提供していなかったのか? みんながカッコいい写真をシェアしたいなら、それが彼らのニーズじゃないか?」

そして彼らは6週間でインスタグラムを作りました。6週間ですよ!

なんでこんな短期間でできたかというと …Burbnのインフラストラクチャがあったからです。Burbnは非常に複雑なアプリケーションでした。だからBurbnをリビルドするのではなく、Burbnから使えそうなものを取り出して作りあげたのです。

Burbnは非常に複雑でしたが、全て捨てました。最良の部分だけを取り出し、この絞り込まれたシンプルなプロダクト(インスタグラム)ができたのです。

たくさんの人に親しまれている、それがインスタグラムです。

なので、できあがったものを捨ててしまう心構えはしておきましょう。





ここで、3つの質問があります。

・あなたは作ったものを捨てられますか?

・捨てるときに直面する困難とは?
→それが他の部分と結合してしまっているときです。

・ユーザエクスペリエンスをシンプルにする為に切り捨てられる余計な機能はなんですか?





4. Spend as much time as possible talking to people who don't start startups - スタートアップをしていない人と時間が許す限り話す

時間はできるだけスタートアップをやってない人達と話す為に使いましょう。

我々にとって、こういう場所(このイベント)に来て会話をしたり、どこかのスタートアップにいっては友達と話をしたり、スタートアップの輪とつるむのは容易いことです。なので、サンフランシスコには20代の企業家がデザインしたアプリケーションが氾濫することとなります。私だったらもっとよくすることができる、というものばかりです。

ある企業の話をしたいと思います。シリコンバレーでは無いものとされていた人達にフォーカスし、世界のどのスタートアップからも差別化した企業です。すぐに注目され、急成長したシリコンバレーのスタートアップです。

Pinterestです。Pinterestというのは仮想のピンボードです。気に入ったものをピンして、シェアすることができます。ユーザーは気に入った画像をピンできます。

デザインは綺麗かつ非常にスマートな作りで、パワフルなプロダクトです。ただ、疑問があります「これが誰かを引き付けるのでしょうか?」

ヒントはサンフランシスコにいる男性ではないということです。 …母親です。 Pinterest はたくさんの母親を引き付けているのです。500万人の母親に愛されています。ここには典型的なサンフランシスコのギークはいません。

Pinterestは女性駆動です。西海岸でも東海岸でもなく、アメリカ中部から中西部に住んでいる女性です。

彼女達はレシピをピンします。夕飯を何にするか考えたいのです。手芸のアイデアもピンします。休暇など、子供達に着せる服用のものです。

あとはかわいい子猫の写真をピンしています^^。

このPinterestの基本的な点こそが、Pinterestを怪物たらしめているのです。

Pinterestのユーザ層はいわゆるシリコンバレーのそれとは違います。

彼女達はTechCrunchを知りません。(逆説的になりますが)だから、 Pinterest はシリコンバレーの外で見出されたのです。

ではどうやって手付かずの巨大なユーザ市場を見つけるのでしょうか?
彼らには男性以外をターゲットにするということと、デモグラを使うことへの才能がありました。

だから、信じられないくらいの巨大な市場を見つけることができたのです。





あなたに必要なのは次のものです。

・スタートアップの外の世界で、誰と話していますか?

・自分が推測していることに取り組んでいますか?

・インスピレーションの為に、文化や流行あるいはそれに近い体験をどのくらいしていますか?

・あなたの市場に対し、デザインをすることができますか?

アプリケーションを次から次へと作る際、デザインは信じられないくらいの競争優位になります。友人とコラボレーションし、始めましょう。





5. Humanize your story - 自身の物語を人間味のあるものにする

最後のステップは、あなたの物語を人間味のあるものにするということです。

作業を終え、スケッチを終え、ピザをこれでもかと食べ終える頃、ユーザーの全ての困難と向き合いたいという欲求がでてきます。

言いたいのは、彼らはそんな困難を求めていないということです。

広告なのですが、このビデオを見てください。

これはカナダのイヌヴィク(Inuvik)という小さな町のビデオです。この町では1年のうち1ヵ月、日が昇らないのです。

トロピカーナは10万ルーメンの明かりでこの小さな町を照らしました。





人はあなたが作ったものから、何かを経験します。
人はあなたがこの世界へもたらしたものに興味を惹かれます。
人は特徴を友人やチームへ話そうとします。
人は製品に隠れた力を、余すことなく友人へ話そうとします。
何を感じたかを覚えているのです。だからあなたの作ったものを愛するのです。

人を射抜く為に最初にできて最高の方法は、人に調和し寄り添うことです。

なぜならデザインは人々を射抜き、人々に入りこんでいくものだからです。

どうやってユーザを通じ自分の物語を人間味のあるものにするかについての素晴らしいビデオを見せたいと思います。


Tropicana - Soleil






ありがとう。



----

以上です。







Elle Luna様、Brenden Mulligan様、Open Network Lab様、お疲れ様でした。

2012年4月1日日曜日

アジャイルサムライ読書会 新宿道場#4



2012/03/31に開催された『アジャイルサムライ読書会 新宿道場#4』のノート。


今回の範囲は次のとおりです。

・第9章 イテレーションの運営:実現させる

・第10章 アジャイルな意思疎通の作戦

・第11章 現場の状況を目に見えるようにする


3チームに別れ、上記範囲内で話し合いたいことをそれぞれ決定し、ワールドカフェを行ないました。
以下はワールドカフェの成果物であるチーム毎の発表と模造紙を書き起こしたものです。



~発表~

1. チーム ギロッポン

アジャイルな分析は何をどこまでやればいいかというテーマについて。

■第1フェーズ

・分析は『やりたいこと = ゴール』を決めるもの

ウォーターフォールの場合は一番初めに全部決めるが、アジャイルの場合はその時点でやりたいことを決める。言い換えると、WFは固定でアジャイルはスナップショット。


・『分析 = 要求をまとめること』という話

この点においてウォーターフォールとアジャイルは同じように見えるのだが、やはり違いがある。

モックはアジャイルとFWでは観点が全然違う。ウォーターフォールのモックは、それを作ることは設計を作ることである。やることをびしっと決めてしまう。アジャイルではあくまでもある時点でユーザが欲しいもののスナップショットである。より深く掘り下げるための材料として作っている。


■第2フェーズ

・アジャイルのメリットとデメリット

メリット : 変化に強い。
デメリット : エンドが見えない。なので契約ができない。


・局所最適化

アジャイルでやるとどうしても視野狭窄に陥りがち。選択するストーリーの順番によっては局所最適が発生してしまい、全体から見た場合にイケてない、ということが起こる可能性が高くなる。これは事実なので注意していかないといけない。

局所最適化の有無はストーリーの選択にかかってくる。つまり、局所最適化を避ける為には優秀なプロダクトオーナーが必要。


・アーキテクチャジャンプ

機能面・技術面からアーキテクチャジャンプが発生する可能性がでてくる。アーキテクチャジャンプに対しては、リファクタリングを行うことでリスクが低減できるかもしれない。アジャイルでやる場合は絶えずアーキテクチャジャンプを意識している必要がある。

また、アーキテクチャジャンプは、増大したエントロピーを下げる為に発生する。なので、エントロピーを上げないようにストーリーを選択する必要がある。

なお、ウォーターフォールは一番初めに全て決めているのでアーキテクチャジャンプは起こりえないらしい。個人的には絶対そんなことないと思う。


■第3フェーズ

・BDDをもっとしりたい、という話

BDDは仕様(やりたいこと)を決めたあとで、受け入れテストを書くものだという話を聞いている。

で、TDDとBDDは本質的には同じだ、という話になり、BDDとTDDの組み合わせでやれば一番いいのではないか、ということになった。



2. 運用島


大きく分けて二つの話題があった。

■朝会のメリットって何?

朝会のよくある話として、ただ進捗報告会になってしまうというのがあるが、そういう朝会は無駄である。

朝会には、みんなでプロダクトを作る、チームを固めていく、というメリットがある。
また、個人で抱えている問題を他のメンバーがサポートする、というメリットがなければならない。

これをやるためには他の人が何をやっているのかというのをちゃんと意識していくことが必要である。


■レトロスペクティブを上手くやるには?

KPTをいきなりやれと言われてもなかなか出せないもの。
そういった人を巻き込むにはどうしたらいいか。

守破離でいうところの守の部分をやってもらおうというのが第一歩として必要なのでは?
強制的にKPTをやらせてみることが必要で、ルーチン化してしまってもいいので、とりあえずやってみよう、と。
慣れてくれば、トライに対してフィードバックをディスカッションする、ということをやっていけばいい。

それを繰り返していくうちに「自分達が変わった」という実感が得られるはず。
そういった実感(ゲームでレベルが徐々に上がっていくというような間隔)を得ることができれば、自分達からレトロスペクティブをやりたいなという気持ちになるのではないか。



3. 宇宙チーム


『カンバンにおける情報共有・同期の方法』『見える化を持続するための取り組み』というテーマを中心に話しあった。


■カンバンの鮮度

カンバンを使っていても、皆が進捗を実績どおり頻繁に必要なときに更新してくれるわけではない。

こういう場合は朝会で共有するのがよい。今日・今週・今後やることをデイリーで更新し、毎日の朝会で進捗報告することで持続させられる。朝会以外では全く更新しない人も、朝会に対してなら更新してくれるだろう。


■タスクの粒度やふせんの色などによる見える化

タスクの種類でふせんの色を分けることで見える化を進めることができる。

・どれが滞っているか

・時間がかかっているか

・何か優先順位で待ちになっていてまずい

など。

『agile do it!』でスクエニの事例が発表されていた。


■待ちカテゴリがあるとよい

待ちの原因をふせんで分かるようにすることで、相手を気遣うという事例があった。

「自分のタスクが終らないと、彼は何もできないんだ」と思って、そのタスクの優先順位を上げて作業してくれたことがあった。

なので、待ちの優先順位をわかるようにするとよいのではないか。


■ゲーム感覚

ふせんをToDo, Done, Doingと動かすことでゲーム感覚を得られる。Excelにはそれはない。

Doneに近づく = ゴールに近づいているということが意識的に感じられるので楽しくできる。


■タスクの粒度

ToDo, Done, Doingなどで、タスクの粒度についてチームで合意していることが大切。


やっている人はタスクの粒度は半日から1日、長くても二日、短くてもせいぜい一時間と思っていたが「30分単位でタスクをきりたい」という人がいた。



ふせんの粒度はタスクの管理コストと相関する。『ゲーム感覚』の話で言えば、タスクは細かい方がいいのかもしれないが、管理コストについてチームで認識していることも重要。


■カンバンとモチベーションの話

カンバンについて自分の仕事を自分で選ぶことができればモチベーションがあがる。

終ったものリストを作りDoneをそこに集める、どれだけ作業したかを説明できるし、やった仕事が溜まるのでチームのモチベーションになり、よい。



■カンバンとバーンダウンチャート

カンバンとバーンダウンチャートを一緒に表示しておく。イテレーションの中はカンバンを見ればいいし、総残量はバーンダウンチャートで見ることができる。



■カンバンを使うメリット・デメリットをチームで共有した方がよい

メリット・デメリットを説明した上で、使うか否か・どのように使うかをチームで共有し合意を得る。
そうすることでカンバンに対する拒絶反応を減らし、楽しくできるのではないか。


■進捗を取り繕うという話

チームの空気が悪くなるので犯人探しをしない。
イテレーション中はやることに集中する。
振り返りの時に『チームとして』なぜ遅れたかという原因を把握し『チームとして』今度どうするかを決める。
チームをコントロールすることが大切で、誰が犯人であるという話ではない。


■質疑応答

Q. 遅れた原因について教えるところのコストをどう考えるか?

A. 最初に教えることで得られるメリット・将来性を考え、見込みで教えるべきか否かを考える。


Q. タスクの粒度の基準は時間という話だったが、重要度によってはたとえ30分であっても切る必要があるのでは?

A. チームで合意ができていれば30分のタスクを切ってもよいのでは。







~模造紙~

1. チーム ギロッポン

■アジャイルな分析は何をどこまでやればよい?

□実装まで。でもウォーターフォールとはタイミングが違う

□分析でやりたい事(ゴール)を決める!

□分析って?
◆ユーザーストーリー
◆やりたいこと

□今はユーザーストーリーを出してユーザに見せる
◆全部始めにやった
◆最初にまとめてやったのは失敗だった?

□(アジャイルな)分析の定義は?
◆要求を決めることなんじゃない?

□メリット:変化に強い。デメリット:エンドが見えない。契約できない
◆局所最適化?
◇ストーリーの並べ方にコツがあるのでは
→どう予見? 回避は?

◇優秀なPOが欲しい。必要だよね!

□BDD
◆振る舞い駆動
◇Rubyが強いぜ!

◆RSpec
◆TDD
◆懇親会で!

□アーキテクチャジャンプの話
◆こまめなリファクタリング

□(アジャイル)受け入れテストを書いてから設計する(P.19)

□モックの意味
 ウォーターフォールにおける→固定
 アジャイルにおける→スナップ

□ウォーターフォールの場合は現行を全部調べる
◆アジャイルでは作るところだけ分析。ウォーターフォールは全部やってしまう

□ウォーターフォールでもモック作ってやってたけど?
◆アジャイルのとどう違う?
◇ウォーターフォールは全部作る?
→作って仕様を決めきってしまう
→設計書を作るためのもの

◇アジャイルは荒く作る
◇作ったモックを思い切って捨てるかどうかがアジャイルとの違い?
→小さく作っておかないと、捨てにくくなる

□ウォーターフォールの場合は全部決める→固定
 アジャイルの場合はその時点でやりたい事を決める→スナップ

□ウォーターフォールもアジャイルも根本的には「分析」は同じじゃね?




2. 運用島


■朝会のメリットって何?

□個人のかかえている問題を他のメンバーがサポートできればメリット
◆それをやるには他の人が何をやっているのかをちゃんと意識しないとダメ
→かんばんとかで共有するとかいいかも

□チームを固める

□「みんなで作る」チームにする

□アジャイルでなくてもできるのでは?

□ただの進捗報告会は無駄。役割分担を明確に
◆イテレーションゼロで固める

□「裸の王様」リーダーへのアプローチ
◆どうしても話が通じなければリーダーの上の人にアプローチ


■ふりかえりのときにだんだんとルーチン化してしまう。レトロスペクティブをうまくやる方法は!

□ルーチン化でもいいからまずやってみる。慣れてきたらディスカッション
◆「変わった」という実感が得られればいい。
→マイナスをゼロにするKPTからゼロをプラスにするKPT


■「建設的」にフィードバックする言葉
 ※話の持っていき方はどんなものがあるのか

□(意見を)出せない人を巻き込むには
→とりあえず強制的に出させる

■?

□まず下のメンバーで結束
→そこからチーム
→リーダーをうごかす

□『人の動かし方』カーネギーのが参考になった

□「傾聴・否定しない」というルール決める
→でもリーダーの役割のことが多い
→打診するときに「メール+即口答」

■その他

□チームを分割して全員が話してタスク化する。重要

□朝会は偉い人が話す場合、あまり意味がないように感じる

□朝会では2~3分/人。話し込んでしまって失敗したなぁと感じる

□リードの人(スクラムマスター)が集まる打合わせは毎日あるが、20人規模

□振り返り→KPT→振り返り…
◆(KPTで)アウトプットはできる
◆どうフィードバックにつなげるかディスカッションできれば
◆改善していく”体感”って大事

□アジャイルな意思疎通
◆ウォーターフォール/アジャイルに関わらず必要。

□KPT
◆サイクルを作る
=re・input
◇tryを実行するのが重要
→かえられるという実感
→みんなから意見しやすい雰囲気

◇振り返りの振り返り
◇なぜうまくいかないのかを話あう

□他のチームが混ざって混乱したことがある
◆無関心を作らない雰囲気作り
◆内職したい人がいたら負け




3. 宇宙チーム

■カンバンにおける情報共有・同期の方法
 "見える化"を持続していく為のとりくみ
 カンバン向きのプロジェクトとは?
 カンバン・ストーリーボードって本当に貼り出さなくても使える?

□進捗をとりつくろう組織で使えるか?
◆助け合うというマインド
◇和の文化

□タスクはふせんの色で種類分け
◆「待ち」カテゴリを作る
◇待ちの原因をふせんで分かるようにしたので相手が気遣ってくれたりした

□タスクを書き出す→思いっきり忘れられる

□タスク:ふせんの色で粒度をわけてカンバンに貼る

□ストーリーをタスクに細分化する
◆ふせんの色を変える

□自分の好きなタスクを自分で選ぶ(モチベーション)

□(タスク)1日1日、個人で振り返りをする

□(タスクボード)できるだけ時間を使わずに管理できるようにする

□終わったリストが必要

□周囲の人達にタスクボードの説明をしておくといい

□今週・今日・将来をデイリーで更新→持続させやすい

□ふせんをリズム良くうごかしてテンポよくしていた。ゲーム感覚

□ゲーム感覚 vs Excel管理

□タスクボードをスクエニは上手く使っている
◆スライドをwebで見られる

□ToDO, Doing, Doneというタスクの粒度をチームで合意することが大切
◆管理コストをチームで認識を持つ

□カンバン
 ・ライフハックの延長
 ・プロジェクト管理というよりタスク管理
 ・タスクの消化をゲーム感覚に

□フィーチャの実装はイテレーション。保守運用業務はカンバン
◆イテレーション中のわりこみ業務?
◆カンバンでフィーチャ実装 …見積もりは?
◇見積もりにバッファ持っておくしかない?

□カンバンを使うメリット・デメリットを共有しよう

□カンバンでタスクを終えるとゲームのような感覚になる

□カンバンとバーンダウンチャートを一緒に表示しておくといい

□カンバンは、一旦完成したものに対しての追加・修正に向いている?

□割り込みタスクとカンバン
 ・緊急レーン
 ・余裕を持ったアサイン

□フィーチャ開発はイテレーションがあってそう

□フィーチャ実装と運用でタスクの種類が違う?

□バグ・デフィーチャは別次元から差し込んでくる
◆バッファを持っておくしかない?

 □アジャイル→守破離


□犯人探しをしない。チームとしてどうするか
◆チームをコントロールすることが大切

□朝会で共有

□アジャイルは哲学だ!



2012年3月22日木曜日

AgileUX NYC 2012 Redux in Tokyo - パネル・ディスカッション




Agileuxnyc_original

2012/03/14に行われた『AgileUX NYC 2012 Redux in Tokyo』のノート。これは後半のパネル・ディスカッション分。なんだか刺激的でいいですよね?


パネリスト



・和波俊久氏 / LeanStartupJapan

・樽本徹也氏 / 利用品質ラボ

・川口恭伸氏 / アギレルゴ・コンサルティング

・坂田一倫氏 / 楽天





◆自己紹介


◇樽本氏

・開発がどんどんアジャイルになってきている。

・開発がウォーターフォールだからUXやUCDもウォーターフォールになっていた。開発がアジャイルになったらUXやUCDもアジャイルをやらざるを得ない。

・UXからアジャイルを仕掛けているわけではない。

・アジャイルに巻き込まれると今までのやりかたが通用しなくなる。その日は日本でも近い。

・UXをやっている人は早くアジャイルを勉強した方がいい。


◇和波氏

・スタートアップとアジャイルには決定的な違いがある。アジャイルはプロジェクトに適用するものなので絶対に終わりがあるが、スタートアップは絶対に終わらない。
・中身の動かし方は基本的に一緒で、非常に親和性が高い。

・リーン・アジャイル・顧客開発それぞれの源流をまとめたのがリーンスタートアップである。
・顧客開発を先にしないと駄目、というウォーターフォールへのアンチテーゼが元々のリーンスター・トアップ。ここには開発は全く含まれていない。
・Eric Riesはリーンスターアップに開発プロセスを追加した。


スタートアップ側からすると、どうやって終わらせていくか?というところに興味がある。




◆パネル・ディスカッション


◇UX(デザイナー)の悩みとリーンスタートアップ

坂田 「社内でもアジャイル勢が増えている。自分はデザインだが、デベロッパの方でも勉強会が頻繁に行われていて、デザインがいなくてもできるのではないか?という風になってきている。カードソートやストーリーマッピング、そういう手法がどんどんできるようになっている。で、スクラムマスターとかプロダクトマネージャーさえいれば、そこからイテレーションやスプリント・顧客の開発の方法を立てるといったことは回していけるという認識がある。さっきの話と繋がるのだが、つまり、デベロッパとビジネスだけでもプロジェクトが周ってしまうということ。たしかにそちらの方が早い。

我々みたいにブラックボックスでぶっこむと「金も時間もかかるじゃん」ということで、結果的に(周りが)離れていってしまう、という危機感がある。我々も今回のようなセッション等を設けて「アジャイルエクスペリエンスデザインという本の中にも、UXという手法が取り入れられているんですよ」といいったことなど「実は普段からこういうのをやっていたんです」っていうのを、どんどん打ち明かしていく必要がある。

最近ではユーザビリティテストというプロジェクトに被験者を1週間に1回呼び、そこにステークホルダーとエンジニアを呼んで、さっきのペアインタビューに近いのだけど、やって、精度を高めていくという。ことをじょじょにやり始めている」


川口 「聞く限りでは、デザイン(UX)とデベロッパが分かれていますよね。ビジネスというのは何をやっているんですか?」


坂田 「さっきの話でいうと、要件を作っている。ウォーターフォール型っていうのがまだあって、要件を出して、というところをやっている。技術的なフィーザビリティーっていうのを、デベロッパが検証して、デザインに落とすと」


川口 「ビジネス・デベロッパ・UXの3つがあると …もう少し頑張ったらリーンスタートアップじゃないですか」


坂口 「リーンスタートアップに話を戻せば、このの構造はたしかに理想。プロダクトストアドシップを考えたときに、ビジネスデベロップメントという舞台と、カスタマーデベロップメントという舞台と、デベロッパという舞台と、三つの舞台があると提唱した人物がいて、まさにその通りの図になっている。 …が、うまくいっていないというのが現実である」


樽本 「なんで3つに分けているのか? 一緒に勤務はしていなのか? プロジェクト毎には?」


坂田 「プロジェクト毎になっているが、入るステージがそれぞれの担当で違うというのが現実」


樽本 「各々3人ずつくらい引っこ抜いてきて、7-8人のチームを組んで、プロジェクトを回すっていうのが一番いいような気がするが? 同時にやればリーンUX。本当のアジャイルUXになる」


川口 「ちょっとしたことって感じですよね」


樽本 「うん。ちょっとしたこと。やれるじゃないですか」


川口 「でも、そんなことはないと思います(笑)」


樽本 「だから分かれてるからおかしいだけで、坂田氏はもともとUXですけど …今はこのプロジェクトのチームメンバーです。あなたはデベロッパだけれども、今回はここのチームメンバーです。で、あなたはビジネスだけど、でもこのプロジェクトはここにいてくださいと。で、全員でヨーイドンでスタートする。ユーザリサーチから全員でやると。で、開発の終わりまでビジネスも全部付き合う …という風にやると、いま海外でやろうとしていることになります。

日本ではそこが違って、それぞれドキュメントを渡したりとかですね。1つのチームになってしまえば、お互いにハッピーに仕事ができると思うんですけどね。それは駄目なんですか?」


◇アジャイルと決算

和波 「中身のやり方って、どんどん進化させて時代のスピードにあわせていくべきだとは当然思うんですけど …実は先週、僕の方も大企業で、リーンスタートアップは採用できるのかみたいな勉強会をやってきたんですね。その中で、すごく心に響いた、ここを乗り換えなければ駄目なんだというのがあったんです。

株式会社である以上、決算を迎えなければいけないと。

で、決算を迎えるということは、動かしたプロセスに対して、何らかの定量的な結果を報告しなければいけない、というのがあるんです。サービスを開発しているときに、じゃあそれってどうやって定量的に図るんですかっていう、まさにブラックボックスの中で何やってるんだっていうのを、どこかのタイミングでは必ず定量報告をしなければいけないという。そこはつらそうだなーと思いましたね。
そこを乗り越えられるような、何か報告の仕組みのようなものができると、もしかしたら導入が楽になるのかな、という感じでしたね」


川口 「逆に、決算に紐付いた予算という仕組みが実は歪みを生むという …その、ビジネスに合ってない決算期だったりすると、歪みを生むので。

もう1つのムーブメントとしてはアジャイルの方で言われている、Beyond Budgetting Round Table (BBRT)っていう。2003年くらいなんですけど、予算を撤廃してしまった会社というのが世の中にはあるらしいと。決算は当然でるんだけど、それは結果だと。だから年間の予算をたてるなんて
全然当たらないじゃん、みたいな。ただしマイクロな計測はものすごくやって、さっきの …経営のダッシュボードを常に更新することで、経営の健全性は保てるんだから、予算いらないんじゃね? というムーブメントがあるらしいという」


樽本 「それはアジャイルなの? 完全に?」


川口 「アジャイルには寄せているけど、アジャイルが発信ではないらしいです。予算を作るのを止めよう …超える、みたいな。」


樽本 「これはいいね」


和波 「その点スタートアップの場合、すごくわかりやすい。レベニューあげるか、次のラウンドでお金を作るか、どちらか適えないと死んでしまうという。単純に非常にわかりやすい、と。バーンレートといって、いかに資金(お金)を使わないで先まで生き延びるか、その間に顧客を掴むか、という。いかにバーンレートを先延ばしにしている間にイノベーションを起こすか、という戦いなので」


坂田 「すいません。このままずっと話をしていると質問に答えられないので… 1つくらい行きましょうか」



◆質疑応答

坂田 「『顧客開発のためのPDCAについてなんですけど …何かインプットがあれば共有いただきたいです。特に顧客セグメントの仮説立案のtipsやスケーラビリティを意識した検証方法などありましたら、お願いします』といったところです。多分、リーンとか意識しやすいと思うんですけど」


和波 「リーンスタートアップを実際に薦めてみると、デモグラとかジオグラとか関係なくなっていって、とにかく課題にセグメントしていく以外にないと思ってるんですけど …そういうことですかね?」


川口 「あと、今回の資料にはでませんでしたけど、37SignalsっていうRuby On Railsで有名な会社が出している『小さなチーム、大きな仕事』。ユーザとペルソナをがーってデータで集めるよりは、自分がペルソナになるのが一番早いって、自分が使いたいと思うものからまず仮説を立脚するっていうのが早い、みたいなことが書いてありました」


坂田 「あと、去年、Janice FrasierさんというLuxrのファウンダの1人が日本にこられたときに、リーンワークショップというイベントがありまして、そこでやられていた方法というのが、正にペルソナを作って検証していくという方法でした」



◇インタビューは強力


坂田 「…(Janice Frasierさんリーンワークショップは、)ずっと6時間くらいやっていたんですけど、そこでやられていた方法というのが、「自分が使ってもらいたいサービスを1つ考えてください」そして「そのサービスを使うであろうセグメントをプラグマティックペルソナで4つの枠にざっとでいいので書いてください」と。で、そのユーザーが本当にいるかどうかというセグメントの検証のために、インタビューをしにいってくださいという。

で、その、さっきのLane Hallayのペアインタビューでもあったんですけど、それでペルソナをどんどん進化させていって、本当に我々がこれ使ってほしいユーザ・セグメントっているんでしたっけ? っていうところからそもそも入るっていう。

そのペルソナの内容があっているかあっていないか …というか、本当に実在するか否かっていう考えではなく、そのセグメントって本当にいるんですか?っていうところから入っていくのがポイントでした」


川口 「ペアインタビューのときに、今日はちょっとスライド乗ってないんですけど、実はLane HallayとJeff Pattonが2人でインタビューをした写真とかが出てて、僕的にはすごいウキウキして見てたんですけど、あのー、やはり、開発者でないとわからないアイデア・解決・問題もある。で、UXの人だけでインタビューするっていうのは、やっぱりその方が早いんですね。それを持って帰ってきて、その場で、後でトークするという方が解決が早いんで、やっぱり壁があると巻けですね。

で、アジャイルの人達ってすごくて、もともとアジャイルの考え方の一つが完璧なドキュメントを求めない、っていうんですけど、それは何故かというと、求めない変わりに、人と人が話してコミュニケーションするという、っていうのを重要視していて、その方が100倍早いって言っていて、そちら側にみんな吸い寄せられてる感じはしますね。どちらが偉いという話ではないんですけど。そういうことはすごいいいアイデアだと思います」


樽本 「インタビューはUXの専門家でなくてもできるんですよ。Contextual Inquiry(コンテキスト調査法)っていって。ちょっとやり方を教えて挙げれば、開発者、自分でもできちゃうんですよね。それでね …多少インタビューのテクニックがひどかろうと、だいたいデータはとれるんです。一番大事なのは、できればインタビューを全員で聞くのが一番いいんです。

誰がインタビューしても構わないけど、他の関係者も全員そのインタビューを聞くと。そうすると、いろんなところでアイデアが出てくるンですよ、製品のアイデアが。で、勿論、全てのセッションにチーム全員を同席させるっていうのは、これかなりのコストになってくるので、時間の都合もつかなくなるのでね。

いまよくやるのが、録音するか、それかもう、その場で、みんなブラインドタッチできるしょ? 入力しちゃうんですよね。テキストをばーっと。適当に。で、その速記録をみんなに渡して、あとその、録音とセットにして、イントラネットかなんかにあげといて、そしてみんな自由に見られるようにしてあげると。で、そのインタビューの記録を読んで、そのインタビューの様子をビデオや音声で聞いて、で、ブレインストーミングをやるんです。そうするとぼっこぼこアイデアが出てくる。エンジニアの方から」



◇リーンとリリース


川口 「この中でユーザーテスティングとか、…開発に関しても、アジャイル以前のウォーターフォールを目指していたときは、どちらかっていうと、科学的な根拠、大数の法則だったり、5人調査しないとそれは知見にならないとか、考え方から、もっと少ない人数でいいじゃんと。アイデアが得られるなら、少ない人数でもどんどんと定期的にやっていこうよ、という流れがあります」


樽本 「そうですね、アジャイルUXとかアジャイルUCD、リーンUX、それはもう全てその考え方ですね。精度よりもまずアウトプットを出してしまう。データの精度をあげるよりはまずアウトプットを出して、それを早くユーザで検証すると。

とにかくアイデアの数勝負なんですよ。どんなに素晴らしい調査データがあったからって、アイデアでなきゃしょうがないじゃない。それでアイデアなんて、どの瞬間にでるかわからないんだから、
1人の話を聞いてる頭の5分でアイデアがでたら、それで充分役に立つわけだから。それで必ず成功するわけではないけども、でもアイデアを出すことがまず大事で、そのアイデアを紙のまま置いてたって、そのユーザには仕えないんだから。

早くコードにして、動く形にしてユーザに見せて、試してもらって、それでそれがうけるかどうか。それ検証した方が早いじゃないですか」


川口 「アウトプットからアウトカムっていうのが正にそれで、アウトプットっていうのは精度の高い、すごく品質の高いもの。でも品質が高くたって、使われないなら意味ないじゃんって」


樽本 「そういうこと」


川口 「その無駄を減らして、リーンにしようということなんですね」



◇結果が全て。データを集めるより作る


樽本 「結果が全てなんですよね。今は。どんな立派な調査やったって、製品売れなきゃしょうがないでしょ?って。だからリーンスタートアップなんですよ。製品作るところをスティーブ・プランクも書いているし、マーティン・ケイラーも全部書いているんだけど、製品みんなで一生懸命作ったってね、売れなかったらどうするんだって。売れなかったらあなたの苦労全部無駄になるでしょう、って。だったら作りながら売ったらどうか、って。売れるものちゃんと考えながら作ったらどう、って。それがリーンスタートアップの考え方ですよね?

だから製品開発に対して顧客開発って言葉を使っているんです。今までは製品開発が終わってから、営業するって言っていた。それじゃ間に合わないっていう。その製品もしかしたら間違っているかもしれないよって。お客さん欲しいと思ってないかもしれないよって。だから作りながら売ったらどうって。そしたら、売れるかどうかすぐわかるからって。売れなかったらピボットしちゃえって。

だからデータ集めるより作れって。早くコード書いた方がいいんだって」


和波 「最初からそのつもりでいるっていうのがいいですよね。そうすればいいんですよね。ユートリ(ユーザーストーリ)とかも最初から、何か学びに行くんだって言う気持ちがちゃんとセットされていると、どんな人でもちゃんとインタビューできているという。そういうことですよね。




◇AgileUXはどんどん進化している


樽本 「そのとおりです。もうね、インタビューなんて誰でもできる。Contextual Inquiryなんて、エンジニアに教えればどんどんできるようになる。どんどん教えてるよ。だから、UXの人これから大変ですよ。開発者がみんなUXの技術見につけちゃうから。

さっき坂田さんが言っていたよね? 彼らだけでできるんじゃないか? って。できるようになってきてるんですよ。UXだけじゃ食っていけないはずです。絶対に」



川口 「すごいですよ。その話。僕がリアルに感じるのは、AgileUXの最初の頃って、UXの部署、専門家の人達と開発の専門家の人達をどうやって組み合わせるかっていうところで、最初はパラレルトラックアプローチっていうのが割と言われていたんです。

どうやってやるかっていうとスプリント・イテレーションで期をあわせてクロスに、ユーザ調査の成果がでたら、それは次のスプリントで開発にわたって、開発が終わったら次のスプリントでユーザのテストをする …UXチームに渡すと。

これを組み合わせると、こう、メッシュ上に仕事を受け渡して、仕事がうまく一緒にできるよ、と。これが頭書言われていたパラレルトラックアプローチなんですけど、今回のAgileUXのカンファレンス、誰もパラレルトラックアプローチって言ってないんですよ。

みんな言っているのはチームの中にどうやってUXが入るのかというのと、UXの人達がどうやってプログラムを学ぶか、とか。どうやってビジネスラウンドと一緒にやっていくかっていう話をしていて、もう、全然くっつき具合がだいぶ進んできたな、という感じがします。この三年くらいでだいぶ変化がでてきた気がします」




◇コアユーザ・エヴァンジェリストユーザを掴まえる


坂田 「話は戻るんですけど、さっきのユーザーインタビューで出ていたジャニスさんのリーンワークショップの中にヒントといいますか、1つこうやったらいいんじゃない? というのがあったんです。

インタビューのときに、ペルソナっていうセグメントって本当に実在するのか、という検証をするっていうのがあったんですけど、あわせてコアユーザーかどうかを見極めなさいっていうアドバイスを頂いて …まさにリーンだと思うんですよね。本当にこのサービスを使ってくれるという、需要があるのだろうか? というところを、質問を通してコアになるかなりえないかを発見していく。で、コアになるっていうフラグを立てたら、その人が本当に使うであろうサービスの領域を定めて。

多分それがMVPだと思うんです。なんでかというと、ピボットするというのは、ビジネスモデルを変えるという話に関わるんですけど、極端な話、全部変えたら元も子もない。どこまでを変えるかというところが、おそらく質問として上がってくると思うんですよ。ピボットをどこまですればいいんだ? という話は僕自身も(考える必要が)あると思うんです。ピボットする軸の振り幅っていうのを見極める必要があって。

それは、先ほどのコアユーザが逃げないような、引き続き使ってもらえるような、最低限の自分たちのコアとなるもので、それを見極めなさいっていうのがありましたね」


和波 「すごいわかりますね。あの、間違った人にインタビューしていると、すごく悲しい気持ちになってくるんです。本当に、この人の話は、あと何分聞こうがたぶん意味はない、というのが途中でわかる瞬間があったりすると悲しくなるんですよ。スティーブ・プランクはエヴァンジェリストユーザというものを見つけなさいということを行っているんですよね。で、その人達は、とにかくそのサービスって言うのを早く世に生まれて欲しいと、心から切に願っている人達。で、そういう人達が必ずいますという話があるんです。

ちょっと、具体例なんですけど、僕の場合は事業開発の支援というところをやっているので、スタートアップの人達ってものすごく世の中に対して新しいバリューを提供しようか、というのを頑張っているんですね。

でも、僕から見ると、そのサービスが本当に拡大するか否かって、例えば、BtoBのビジネスとかだと、企業さんがそれを採用する障壁っていうものをどんどん下げてあげる。そうすると、すーって採用できたりするんだけど、その機能を一向に開発しようとしないんですね。だから『たしかにあったら面白いなーと思うんだけど、うちの会社には馴染まんなー』と思ったら絶対採用しない、みたいなところが気づかないんですよね。ずーっと気づかないまま。

だから、そういうインタビュー繰り返しちゃうと、何を作れば採用障壁が下がるんだ、というインタビューをしなければいけないということに気づかぬまま、ずっとお金を浪費していくっていう、そんなパターンがあったりするんですね」


川口「最近、カンファレンスのインタビューで増えていたのが『あなたはこのカンファレンスを他の人に薦めたいですか』って質問で、これ正にエヴァンジェリストユーザがどれだけ付くか、ファンになってくれるか、っていうのを探している。すごく増えましたよね、最近。これ(AgileUX NYC 2012)のインタビューもありましたよね?」


坂田「はい」


川口「勧めたいですか?っていう」


坂田「そうですね。ぜひ薦めたいですって(答えました)」


川口「エヴァンジェリストユーザが1人掴まる(笑)」







和波俊久様、樽本徹也様、川口恭伸様、坂田一倫様、お疲れ様でした。


2012年3月18日日曜日

『Developers Summit 2012』2月17日(金) - 2日目メモ

今更ながら、『Developers Summit 2012』2月17日(金) - 2日目メモ。




17-C-1 Business Model generation


◆ビジネスモデルとは

・全ての(会社だけではなく、NPOやその他のものも含めた)組織が持っているもの。

・組織がどう回っているのかを書いたもの。

・誰の為にどのような価値を生み出しているのかを表現するもの。



◆ビジネスモデルキャンバス

・これにビジネスモデルを記述する。ビルディングブロックで構成される。

・コンサルタントや管理職だけではなく、一般の社員も理解できるもの。

・これを使えば、この中の共通の言葉で話すようになるので、非常にパワフル。

・組織というとより、事業のモデルを記述する為のもの。
ただし、組織の分析や改革にも使用できる。



◆ビジネスモデルを変更したい場合

・キャンバス内のオブジェクトを動かし、その際の影響を考える。



◆ビジネスモデルキャンバスと、その構成要素(ビルディングブロック)について。

・収益と支出について、キャンバスを2分する。

収益と、それを生み出す構成要素が右側。

支出と、それを作り出す構成要素が左側。


◇収益に関するビルディングブロック

・レベニューストリーム

 これらがうまく繋がれば、収益の流れが生まれる。
 収益を生み出す構成要素


・カスタマ

 最も重要な顧客だけを書く。

・バリュープロポジション

 顧客にもたらす価値。サービスそのものではない。

・チャネル

 顧客との接点。マーケティングの5Pと同じもの。

・カスタマリレーション

 コミュニケーションの手段。
 どれだけ自動化されているかが重要。
 新規顧客と既存顧客のどちらを重視するのかという優先順位がはっきりしていることも重要。


◇支出に関するビルディングブロック

・コストストラクチャ ビジネスを回す為に必要な支出。

 支出を生み出す構成要素

・キーリソース

 モデルを回す為に必要最低限のものだけ。
 それが無くなったら、即座に業務が止まるようなものを書く。

 例えばgoogleなら、キーリソースは社員ではなくプラットフォーム。

 googleのサービスに繋がらなくなれば、その瞬間にビジネスモデルは成り立たなくなる。
 社員が全員いなくなったとしてもすぐに収入がなくなるわけではない。

・キーアクティビティ

 毎日BPをつくり、カスタマとコミュニケーションする為のもの。
 普段当たり前にしていること。


・キーパートナー



17-C-2 仕事のバトン、渡っていますか? - プロジェクト管理におけるコミュニケーション基盤作り



◆waterfall or agile

・パッケージ開発など、見積もりが効くものはウォーターフォールがよい。それ以外はアジャイルの方がよい。



◆excel or チケット

・まともなプロジェクトかつ、時間軸が不安定なタスクばかりならチケット駆動開発がよい。
タスクの前後関係が見えなければいけない or 安定しているならexcelで管理するのがよい。



◆課題管理について

・まずは時間管理ができていなければならない。

・切り出したタスクの中で、それでも不確定なものを課題管理システムで管理する。

・情報公開範囲との兼ね合いがあるので、Q&Aやバグなど機能毎に切り分けること。

・リーダーがタスクを割り振ること。

・計画的な(繰り返して行う)ものには使わない。



◆課題管理表のデザインのポイント

・タスクを階層化しすぎない

・複数のコミュニケーションツールを併用せず、一本化する
(電話での依頼はexcelに書き、メールの依頼はnotesに書く、みたいな使い方は駄目)。



◆課題管理表の書き方のポイント

・誰がクローズするのかを決める。

・言葉使いには気をつける。

・事実のみを書かせる。






17-A-4 Scrumで組織改革



◆はじめに

市場・会社が急拡大している。人を増やしているが、次のようになっていた。


◇経営

・業務遂行の質やスピードが上がらない。

・意味のあるアウトプットが増えない。

・スケールする為の取り組みがない。


◇現場

・周囲や自分のしていることが分からない。


このような課題を自己解決できるような会社にしようと考えた。 



◆仕事の現状

次のとおり。


◇スケジューリングが困難

・案件が突発でやってくる。

・状況認識できない。

・今が忙しい。

・タスクが多い。

・優先順位がついていない。


◇責任範囲が不明瞭

・可視化できていない。


◇課題・問題が放置される

・目先の仕事もそうでない仕事も、価値はどのくらいかを図る必要がある。

・目先はアウトプットの価値が図りやすい。

・結果として目先の仕事ばかり処理される。


スクラムなら解決できそうだと思われた。 



◆1回目


◇やってみた結果

・スプリントで優勢順位が付いた

・なんだかんだで、スクラム外の仕事もせざるをえない。

・ツールなどが意図したとおりには機能しない。

・リリース品質に近づかない。

・助け合うマインドができた。

・大きな問題が後回しになった。

・バックログが増えていく。

・明確化や意思決定が遅れた。


◇振り返り

・問題の可視化・共有ができる。

・スプリント毎に成長する。

・スクラムは難しい。


これなら課題を解決ができそう。



◆2回目


◇したこと

・開発者を一箇所に。

・スクラム前に1週間ほどスプリント0を行なう。

・ミッションの明確化。

・責任分割。

・優先順位。

・バックログを作成。

・ツールを整備。


◇振り返り

・タスクをストーリー化したが、意思決定で迷う状況があった。

・振り返りを嫌うチームがでてきた。


◇この段階での結論

・スクラムを知らない(理解が浅い)人にただ行わせるのは逆効果。

・スクラム意外の方法で解決すべき問題がある。

・スクラム自体は有効。



◆3回目


◇ 行ったこと

・各チームにアレンジしてもらった。

・突発の対応を許可した

・大規模な開発に適用した

・チーム内メンバーの入れ替えをした

・業務改善に適用した

・スプリント0の前にプレプランニングをした。

・スクラムマスター会議をした。

・チームを超えた共通なルールを作った。

・チーム毎の個別のルールを作った。

・エピックというストーリーの上位概念を入れた。


現在実施中。



◆結論

・組織間のコミュニケーションが増えた。

・自己解決するように組織化された。

・メンバーが自分からやりたいことをするようになった。






Tim Clark様、今津 美樹様、鈴木 雄介様、貝瀬 岳志様、お疲れ様でした。



2012年3月16日金曜日

AgileUX NYC 2012 Redux in Tokyo - AgileUX NYC ハイライト


Agileuxnyc_original

2012/03/14に行われた『AgileUX NYC 2012 Redux in Tokyo』のノート。これは前半のAgileUX NYレポート分。非常に濃かったです。



◆Eric Burd

◇same problem statement

1. アジャイルやリーンはテクノロジやデザインというチームにフォーカスを当てがち。

2. だが、HRやマーケティング・セールスなどの関係部署にもアプローチする。

3. 全社的にみて共通の課題はなんだったかということを重視し、定義する。


◇ステークホルダーをどう巻き込むか?

1. ステークホルダーは忙しいのでなかなかプロジェクトに巻き込めない。

2. ランチはあるので、このランチ時間を借りる。

3. ユーザを呼んでその一時間でセッションをする。

4. これを週一で行ない、ユーザのフォローをしている。


◇スモールウィンを探す

・小さな成功を社内に探し、成功させ、エッセンスを社内に確立する。

・どこまでいったらこれサクシードだよねっていうのを見極めて探す。

・顧客やらビジネスプロジェクトやら、どこから導き出されたものかって言うのを整理する。




◆Phin Barnes

◇investing in design

デザインに投資するという、インベスターによる話。

・社内に導入するには、果たして私達にできるのだろうかというハードルや壁がある。

・アジャイルという言葉になじみがある人達にそういう壁がある。

・スキルセットではなくマインドセット。

・デザインはカスタマーデベロップメント(顧客開発)という原点をリードする立場にならないといけない。

・じゃあ組織を動かすものってなんだろう?定性データ?定量データ?

・データを見据えるだけではなくて、どのようなインサイトが組織内に成果をもたらし動かすのかっていうのを考えていく必要がある。

・(単なる)成果をもたらすものとしてではなく、持続的な文化として発信していく。

・リーンスタートアップでいうところの、カスタマーディスカバリー・バリデーション・クリエーション・ビルディングっていうのを回していくというのを我々の作業に落とすと、課題定義・スケッチ・プロトタイプ・ソリューションの改善・最適なソリューションの開発っていうのを回していく。そういったことを推奨していた。


  ※ Phin Barnes の発表について、坂田氏が気になった点

   共通課題をどう見せていくかというのでダッシュボードが採用されていた。
   ・数字は継続的にアップデートされていて、全社員で見れるようになっている。
   ・ダッシュボード化 = tamgible(触れるようになっている)
   ・この数字をカスタマーデベロップメントサイクルで改善していく
   ・↑が結果的に1つの文化になっていく。


◇定量データは、もはや遅れている

・我々はデザインドリブンの会社であり、もはや遅い。全然響かないし新しくない。

・次は、定性的な要素を加え、コンテキストを導入することが人を動かす力になるのではないか?


※アジャイルではダッシュボードが流行っている。リーンスタートアップでも最後のメトリクスが重要視されていて、定性定量も含めてインフォグラフィックスのような一枚絵、しかも自動で更新されるものをみなで見て判断を下す。そういう文化である。



◆Josh Seiden

◇要件を仮説に置き換える

1. アジャイルやリーンのコンセプトを社内に導入するにはそもそも要件という考え方じゃ駄目。

2. 要件は断固たるもので、いくら我々がUCDプロセスとか回したとしても変えることは不可能or困難。

3. 仮説はもちろん仮説なので正しくない。検証していく必要がある。

4. これにより不確実性がエッセンスとして取り込まれる。

5. それゆえにテストしたり学ぶ姿勢をチーム全体が保ってくれる、という力がある。




◇要件について

1. ビジネス責任者のこれがやりたい、というニーズはそのまま要件として認識される。

2. それを元に作業する人達は、その背景にあるユーザやマーケットニーズを知るすべが無い。

3. 要件ではビジネス側が要件を考えて、それを開発やデザイナが作るという風になる。

4. フェーズが完全に切り分けられてしまうが、それはウォーターフォールではないか?



◇ケーススタディ - アプリのインストーラー

1. 我々の顧客は無料で提供されているインストーラに価値を見出すのではないか?という仮説。

2. 具体的に何を造ればいいかを頭に浮かべる。

3. それをいくつかのsub-hypothesisにブレイクダウン。

4. テストを早く回せる感じのミニシナリオを作る。

5. インストールのプロセスが早ければ、顧客は無料のアプリをダウンロードするのでは?となる。

6. 仮説は検証するため、mbpで最小限にこれを達成する方法を考える。

7. インストーラをサポートするような画面や機能が必要なのではないか?となる。

8. 結果として、最初の要件とは全然違っている。

※mbp - minimum variable product。リーンスタートアップの概念。



◆Lane Halley

もともとデザイナー。どうやったらアジャイルと一緒にやれるのか?を考えてきた人。

デザインの立場になってアジャイルやリーンスタートアップをとらえてみた、という話。


◇デザインのアプローチが変わってきている

・デザインをチーム全体の責任にする必要がある。

・デザインというロールが変わってきている。

・部署や役割という垣根を越えたデザインが必要 = cross functional pairingを使う。

・デザイナーはプロジェクトのファシリテーターになるのではないか?

・デザインしているプロダクトやサービスの担当・責任を任せることができるチーム(プロダクトオーナーチーム)を作る。


◇cross functional pairing

1. デザイナ(特にフロント・ミドルエンドと呼ばれる場所のエンジニア)とペアで開発の人が実際に一緒になって作っていく。


2. 結果的に、クイックにビジュアルにすぐに形になる。

3. で、協力的・持続してcontinueousというのが可能になった。

※crossやコラボレーションがキーワード。

※ステージの最初からペアで行うなら、チーム体制を意識する必要がある。



◇インタビュー法

・early provisional persona - 本当に影も形も無いような、雑な仮説ベースを作る。

そういうセグメントがいるのでしたっか?というのをインタビューする。

・pair interviewing - インタビューはデザイナーだけではなく全員でやる。

・mutliple note takers - 1人に任せてノートを取らせない。あらゆる視点からノートをとり、気づきをシェアするという、

UXだけじゃなくてデベロッパも一緒にやる。同じ cross function paring の人もいれる。



◇プロダクトオーナーチームとcross functional paring は彼女達が作った仕組みに密接に関連している

1. プロダクトサービスの担当とコアのUXの人達と、開発者はアーキテクトくらいしか入っていない。

2. そのチームが製品全体を設計している。

3. デザインの骨格共通のデザインの部分も設計している。

4. ↑のフェーズが終わったら、各モジュールを作る。


l※デザインのコアをやった人がそのまま降りて、チーム(開発者)の横にいるようなペアを組む。


※ペアプログラミングはアジャイルでは良く言われるが、ここは、開発者同士ではなくてデザイナとやるという新しいやり方でやっている。



◆Anders Ramsay

アジャイルが良くするものは何かを突き詰めたものは、UXRagbyという表現になるのではないか。

◇リレー

1. トラディショナルな開発式、WaterFall。

2. 一人一人が走って、次の人にバトンを渡してじゃあどうぞって感じで、ハンドオーバーをしている。


◇ラグビー

1. 数人単位でボールを追いかけていて、トライをして、またトライを狙いにいくみたいな感じで連続したプレイを続けるスポーツ。

2. まさにアジャイルってそれなんじゃないか?と。

3. ラグビーのパスは言ったりきたりするが、まさにチームでもそう。

4. ペーパープロトから開発、というプロセスもバックアンドフォースのパスといった感じで、やっていくべきでは。



◆Jennifer Gergen

仕事をするためにプログラミングを自分で学んだということで拍手喝さいを浴びていた。

アジャイルUXをUXあるいはデザイナー側から対面している人。


◇デザイナーとプログラミング

・全部のプログラムを組めるようなスキルがあるわけではない。

・自分が少しプログラムを組めることで、会話がすごく円滑になる。

・ものすごく早くアウトプットが出る。


◇開発とデザイナのクロスファンクショナルペアリングをどうやってやっていくべきか

・イテレーションは機能とかページの開発には優れている。

・イテレーションは影響範囲が測定しづらい大きなデザインの変更には向いていないのでは?

・策としてAToMICデザイン(asset to markUp iterate colaboration)を提案する。



◆まとめ


◇UX/UXデザインはどう振舞うべきか -> demystifyする

1. 現在のUXデザインは、中で何が行われているかわからないブラックボックス状態である。

2. チームメンバーUXデザインってマジックみたいだよね、と考えている。

3. デザインは一筋縄ではいかない。いろいろ考えながら一本の縄を歩いているような状態。

4. だからこそ、ブラックボックス状態では納めない。

5. 頻繁に成果物を見せながら学んだことをプラスアルファしてシェアしていく必要がある。


◇共通言語で話す

・医者のように、他人が理解できる言葉で話すということを推奨。


◇要件と仮説


・要件は仮説になるべき。

・デザインは仮説を検証する実験になるべき。

・成果物は実験の結果。



◇その他

・UXにはメンタルシフトが必要。

・我々が日々していることを、スキルセットではなくマインドセットへのメンタルシフトを通して現場レベルに落とし、実行していく時代なのではないか?



◆補足

話の中に出てきたけど、放り込む場所が無かったものをここに記載。


◇アウトプット(成果物)とアウトカム(結果)の違い

・アウトプットはできたもの。

・アウトカムはそれを使ってユーザが何を得たか。


◇Jennifer Gergenがプログラムを学んだという件について

・デザイナーがプログラミングを学んでいるということに対して需要が高まってきている。

・デザイナーがプログラミングにシフトしつつある。


◇デザイナーは開発から招待されているが、デザイナーは彼らを招待していないのではないか?

・プロセスやコンセプトを理解して一緒に作業しよう、という風に招待をしていないので、コラボレーションが難しくなっているのではないか?






坂田一倫様、川口恭伸様、お疲れ様でした。