『Running Lean -実践リーンスタートアップ 刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』ノート - 導入・理論 (1 / 4)

2012/12/17に開催された『Running Lean -実践リーンスタートアップ　刊行記念 著者アッシュ・マウリャ氏 来日特別セミナー at Yahoo! JAPAN』のノートの前半です。



◆カスタマーとお金を出す人とスタートアップの中の人の話

◇まずは悪いニュースから…
・ほとんどのスタートアップは失敗に終わる
　→これが現実
・でも失敗するのはスタートアップだけじゃない
　→大企業が新製品を市場に投入するときも同じ
　→→大企業の中の人もアントレプレナー精神が必要
・そして、成功した例の2/3は途中でプランを大きく変えている

◇Not a better plan A but a path to a plan that works
・成功するためには何が大事か
　→必ずしも完璧なビジョンは必要ない
　→→計画がワークするように調整できるか
　→→それをリソースが無くなる前にできるか

◇今日話すこと
・"plan A"から"ワークするプラン"へ、システマチックに調整できるということ
・それをリソースがなくなる前にやるにはどうすればいいかということ
　→スタートアップはリソースがなくなってダメになる、ということが多い

◇どうしてスタートアップを成功させることは難しいのか？
・普通のスタートアップはどういう流れで進むのか
　→まず良いアイデアが浮かぶ
　→→そのアイデア（ソリューション）に恋してしまう
　→→→そしてそれをビルドする
・これが一番典型的な形
　→ソリューションへの情熱があるから動く、ということが多い
　→→それはマーク・ザッカーバーグも同じだった
・我々はプロダクトをそういう風に見てしまいがち
　→「どういう風にペイするか、どういう風に開発していくか」というのが一番難しい
・お金を確保するためにどうするのか？
　→投資家を探したり、社内なら予算をくれる人を説得するのが普通

◇ではお金を出してくれる人はどう見ているか？
・彼らは、我々の考えたソリューションに恋なんてしていない
　→ソリューションなんて何でもいいと思っている人が多い
・彼らの関心毎は1つ
　→いかに提案をスケールアウトさせ、ビジネスモデルとしてペイさせるか

◇お金を出す人が注目するものは何か？
・魅力(traction)があるか？
　→作っている人以外にユーザがいるか？
　→ユーザがバリューを感じているか？
・コストストラクチャとレベニューストリームに関する計画があるか？
・どれくらいのカスタマー数・市場規模があるか？
　→カスタマーが誰かなのかは気にしない
・ディフェンス力があるか？
　→成功した後、どれだけ他社から市場を守れるか
・まとめると
　→魅力(traction)があるか？
　→カスタマーや市場に展開できるか？

◇そこまでの魅力があることが証明できていないなら？
・それはなんとかしないといけない
　→まずはカスタマーから始める必要がある

◇カスタマーはどう見ているか？
・自分の課題やproblemを解決してくれるものが欲しい
　→始めはあなたのソリューションへ恋してない
・関心は「あなたはどういうソリューションを提供してくれるのか?」
　→課題とソリューションの間にあるのがプロミス
　→→プロミスに注目するのがカスタマー
・この時点で注意すること
　→どんな課題を対象にするのか、というのは具体的にイメージできているべき
　→→そうすれば、どういうカスタマーに確認すればいいか分かる
・facebookも最初はカスタマーを絞っていた
　→ハーバード大学の学生のためのサービス
　→今は誰でも使っているけど、最初は違った
・誰にでも受けるよう広いスコープにしてしまうと、結局は誰にも受けないものができあがる

◇次にカスタマーが気にすることは？
・どれだけ負担がかかるかということ
　→負担などいろいろなものが条件を満たしていて、プロミスが魅力的なら参加してくれる
　→→参加してもらえれば、いろいろ試してもらえる

◇True productとは何か
・ビジネスモデル全体のこと
　→ソリューションではない

◇アントレプレナーの本当の仕事は、ビジネスモデルが持っているリスクを削っていくこと
・対話をとおしてリスクを削っていく
　→顧客と
　→社内の人と
　→投資家と
　→アドバイザーと
　→ときには競合他社と
・どう対話するか？
　→それはRunning Leanに書いてある



◆Running Leanの3つのメタ原則
・Document your plan A
・Identify the riskest parts of your plan
・Systematically test your plan

◇メタ原則の基になる考え方
・本当のプロダクト(True product)はビジネスモデルだということ
・ビジネスモデルを考えるときもテクニカルな観点から説明が付くということは重要
　→そこは注意してやった

◇メタ原則1 : plan Aの文書化
・これはなんでもそう
　→家なら設計図
　→旅行なら旅程表
・きちんと文書化しようというもの

◇通常ならビジネスプラン（事業計画）やビジネスケースとして文書化する
・ビジネスプランを書くことが楽しかった人はどれだけいるか？
　→ビジネスプランはとてもｐａｉｎｆｕｌ
　→→しかも書けと指示した人は最後まで読まない
・でもこういうことをしっかりやるのはアントレプレナーには非常に重要
　→その前にどれだけ対話ができているのかという問題があることに注意

◇エグゼクティブサマリとかエレベータピッチを書けといわれることもある
・どうせそういわれるなら…
　→最初から1ページに綿密でシンプルなものを書くのはどうだろうか？
・それがLean Canvas
　→こういう形でも充分作ることができる

◇事業計画やビジネスプランを作ったことがある人は、見出しを見るだけでLean Canvasに何が書いてあるかわかる
・ビジネスで重要となる、コアになるものを書き出したもの
　→特にリスクに着目している
・ビジネスモデルキャンバスに調整を加えてある
　→よりアクションがとりやすいように
・分割統治
　→複雑な問題は要素ごとに分解するという方法
　→Lean Canvasも1つ1つが独立した観点からまとめてある
・だからといってバラバラで良いわけではない
　→最終的にはジグソーパズルみたいに1つにまとまらないといけない

◇メタ原則2 : どこが一番リスクを高いか見つけるには？
・ソフトウェア開発はリスクが高いところから手をつける
　→それはビジネスも同じ
・どこにリスクがあるか、どうやってそれを低減するか
　→これが成功へのひとつの道
・EasiestではなくRiskestなところから始めるということ
　→これはポイント
・プロダクトを作るのはEasiest
　→特にプロダクトを自分で作っている人にとってはそう
・プロダクト自体が失敗するのは作りこみの問題ではない
　→カスタマーが見つからない、市場がないというのが一番の理由

◇どこがリスクなのか見極めるためには？
・Problem/Solution fit
　→課題と解決がどれだけフィットしているか
　→解決・対策に値する課題が存在しているのか
・もともとはトヨタ式、リーンの考え方
　→外・現場に出て行かないといけない
　→自分がいいと思っていることだけをやっていてもダメ

◇カスタマーに存在する問題、その中で何が重要なのか知る方法
・これはいろいろあると思う

◇カスタマーの重要な問題を理解した上で出来ることは
・何を最小単位で提供できるか
・MVP(Most Viable Products)
　→本当に小さな規模のソリューション
　→小さいけどカスタマーにバリューは提供できているもの

◇今までの伝統的なやり方
・時間をかけた作りこみ、テスト、調整
　→それからくカスタマーに使ってもらっていた
　→→そうやってできたものを使ってもカスタマーは迷子になってしまう
・途中のものでも、それがカスタマーの望むものか確認しながら進める
　→全体が出来上がってからカスタマーに出すのではなく
・小さい規模でも「これはカスタマーがバリューを感じている」という確認をとる
　→それからスケールするというステージに進むべき

◇通常のやり方とProblem/Solution fitの違い
・どのサイクルでもカスタマーを巻き込んで進めている
・プランをまとめて、そのプランにどういうリスクがあるかを確認する
　→そのリスクに対して体系的にテストもやるべき

◇メタ原則3 : システマチックにテストする
・Experiment - Eric RiesのBuild-Measure-Learnのサイクル
　→アイデア（仮説）からスタート
　→それを元にプロダクトを作る
　→→本当に小さなもの、全部ではないもの
　→実際に使ってもらう
　→そして定量的定性的に計測する
　→データとして確認する
　→データを活かして学習する

◇学習することによって調整を行う
・学習することで、想定していたリスクの正しさが分かる
　→違えば修正して進めばいい

◇Experimentを回していく上で重要なもの
1. スピード
 →時間は、スタートアップにとって一番大切で一番足りないリソース
2. 全てのExperimentはLearningで閉じる
　→成功のいかんに関わらず学ぶことはできる
3. 適切なフォーカスができているか
　→回そうとしているExperimentのフォーカス自体が正しいか
・フォーカスをきちんとやる
　→これがないと、Experimentのサイクルを回してもアクションが伴わなくなってしまう
　→→カスタマーすらついていないのにサーバを増設したりコードを書いてしまったりとか

◇次の3つを、フィードバックループを回す形でやっていく
1. Document your plan A
2. Identify the riskest parts of your plan
3. Systematically test your plan
・左から右、右から左へと



◆リーンスタートアップとは何か

◇リーンという言葉自体が昔は誤解を生んでいた
　→チープとか良くないプロダクトであるとか

◇リーンはトヨタの製造システムから取ってきた考え
・リーンの考え方の重要なポイント
　→いかにムダを省くか
　→いかにリソースを有効活用するか
・お金は重要なリソース
　→ただ、お金が一番価値があるリソースというわけではない
　→一番価値があるのは時間
・お金や人的資源は増減できる
　→時間は一定方向にしか進まない

◇自分のリーンスタートアップの定義
・ある一定の時間の単位で、何が一番リスクなのか最も効果的に学べるやり方






Ash Maurya様、O'Reilly Japan様、Yahoo! JAPAN様、ありがとうございました。

『DevLOVE2012 - これからの自分戦略 〜組織に埋もれない自分のウリコミ〜』ノート

2012/12/16に開催された『DevLOVE2012 - これからの自分戦略 〜組織に埋もれない自分のウリコミ〜』のノートです。



◆山本裕介氏による自己紹介

◇自己紹介
・あちこち転職する人
・侍（ツール）の人
・元ｔｗｉｔｔｅｒの人
・twitter4jの人

◇自分戦略は何のためにあるのか
・自分がやりたいことをできるようにする
・やりたくないことをしなくてすむように
・収入が上がる
　→仕事の上では大事な話

◇決定する要素
・やりたいこと・やりたくないこと
・やれること
　→やりたくないけどやれること、ってある
・妥協できること
　→やりたくないけど、やりたいことの為に
・自分を取り巻く環境
　→自分がどういう環境にいるのか考えることが重要
　→→会社
　→→日本
　→→世界
・何が金になるのか
　→考えておくことが重要
・やりたい / やりたくないことはどんどん変わっていく
　→自分戦略も常に変わっていく

◇自分はなにをやりたいか
・組織に飽きっぽい、なじめない
・技術（ソフトウェア）で食べていきたい
・でも技術一辺倒にならないように
　→それなりにビジネスマンとして渡り歩けるスキルは大事
・なんとなくグローバルな
　→世界を相手に仕事ができたら面白い。そういう親を見てかっこいいと思ってた
・政治に力を注ぎたくない
　→権力・人の面子とか気にせず技術にフォーカスしたい

◇自分にやれること
・java
　→ずっとやってきた
・エンタープライズアーキテクチャ
　→会社でやってきた
・プロジェクトマネジメント
　→それなりのユーザがいるOSSのプロジェクトをまわし膨らませてきた
・API設計
　→twitter4jはtwitterのAPIを使いやすくするためのライブラリ
　→→APIのたたき方
　→→twitter4jを使う側の使いやすさ
　→→初心者から上級者までいろいろな人が使う
　→→→どうしたら簡単に迷わず使えるかを考えている
　→→→→どうしたら問い合わせが無く、シンプルでスムーズに使えるか
・ちょっとの英語
・ちょっとの折衝
　→顧客と対話する場を自分で作ってやってた


◇自分戦略に辿りつくまで
・何をしてきたか
　→大きく三つ
　→→個人として社会人になるまで
　→→仕事としてこれまで
　→→社会人になって個人として何をしてきたか

◇個人として社会人になるまで
・雑誌掲載のゲーム手打ち
　→主にベーシックとか
・遊ぶだけで満足しなくて改造
・自分でプログラム
　→最初はベーシック
・パフォーマンスの問題が
　→MSXでマシン語(Z80)
・作ったソフトをtakeruで展開
　→自分のソフトを掲載依頼が来た
　→そこからフィードバックをもらえたりした
・結果身に着けたこと
　→プログラミングスキルの下地
　→マシン語（低レベルなレイヤで起きていることの把握）
　→→javaの後ろで何が起きているかとか

◇個人として何をしてきたか（社会人以降）
・作ったものは全てオープンソースに
　→楽するためにはどんな苦労でもしてやる
・侍
　→javaのスレッドダンプの解析ツール
・虚無僧
　→webLogicサーバのモニタリングツール
・わらじ
・twitter4J
　→twitterAPIを触るツール
・変な名前になってるのは？
　→自明な名前をつけるのが好きじゃない
　→英語圏で検索したときに露出しやすい
　→日本発と言うイメージも打ち出せる
・twitter4J
　→javaでtwitterならこれがわかりやすいということで

◇社会人になって個人として何をしてきたか
・（中略）

◇社会人・個人としての活動を通して身に着けたこと
・技術力
　→日本顧客の要求レベルはすごく高い
　→→「問題があったけど、これで回避できました。今度からはこうしてください」では駄目
　→→→「恒久的な対策はどうする」「いつ直るんだ」
　→→→→海外とは違う
・顧客を安心させる能力（ハッタリ力）
　→自社の製品を全て知っているという分けではない
　→だからといって「わかりません」ばかりでは信頼されない
　→→それっぽく見繕う力は大事
・ある程度の折衝能力
　→営業とも仕事をしてきた
・国や地域で（商）習慣が異なるという認識
　→要求レベルが違う
　→注文の仕方も国によって違う

◇振り返って自己分析
・細かいことでも非効率は嫌い
　→人件費がかかりすぎるような仕組みとか
・正義重視（エンジニアとしての正義）
　→効率化/高速化大事
　→→くだらないマニュアルオペレーションではなく、できればなんでも自動化したい
　→→非効率な部分は止めたい
・人の面目のために正義を軽視とか無理
　→「偉い人があの技術を押しているから」とか
・自分の信じることをしたい
・自分の信じるものを売りたい
　→会社は商品の幅を広げていく
　→中にはいけてないソリューションや製品も出てくる
　→ビジネスマンとしてはそういうものも扱わないといけない
　→→自分が信じられないものを使うのはいやだ
・自分の正義から外れる環境はストレス
・政治軽視
　→政治は嫌い
　→密室での会議は嫌い
　→→タバコ室に集まるだけやけに詳しかったりとか
・オープンがすき
・技術を広める
　→社内で内製するだけではなく世界に広める

◇これから何をしていくのか
・何をしたいのか
・自分が何をできるのか
・何をしないといけないのか
　→したいことだけしてもお金にならないかもしれない
　→出来る範囲でないといけない
　→やらないといけないこともあるだろう

◇何をしたいか
・スケールするビジネス
　→時間に対してお金を貰うより自分で開発
　→今からだと周回遅れかもしれないけど、まだ間に合う
・なにかしら貢献したい
　→自分が頑張ることでみんなが助かるようなことがあれば
　→自分が面倒だと思うことは他の人もそうだろう
・DRO(Dont repeat ourself)
　→みんなが、同じ事をしなくて済むような世界になればいいなー
・社内には転がしておくにはもったいないツール・技術がたくさんある
　→「これすごい便利ですね。オープンソース化しないんですか？」「業務時間中に使ったので…」
　→→そういうのはもったいない
　→自分の時間で作って公開すれば世の中のためになるし自分の宣伝にもなる

◇何ができるか
・英語が少し
　→もっと出来る人がたくさん
　→武器というほどではない
・java
　→代わりがたくさんいる
・API設計
　→なかなかお金にならない
・人にものを教える
　→自分からやりたいといってやってるわけではないけど
　→けっこう好き
　→でもスケールしない

◇差別化ポイントとして大事なところ
・手を動かす
　→いろんなツールが普遍的に転がっている時代
　→「○○できます」だと「へー」で終わってしまう
　→→手を動かしてものを作ることがすごく大事
　→今までは中間的なツールばかり作っていた
　→→これからは最終製品のアプリを開発したりしたい
　→→→自分を売り込めるようなものを
　→でもやりたいことばかりやっているわけにもいかない

◇何をしなければいけないか
・当座の資金確保
　→SIerでバイト
・他の収入源も考え中
　→自分が好きな製品の売り込み
　→→ライセンスビジネスって儲かるかというと…
　→→→これに対して力を注ぐつもりはない
　→→製品を作っている会社の社員になるかというと…
　→→→「うーん…」という製品も売らないといけなくなる
　→やりたいのは幸せになれるツールを広めること
　→→自分が好きなものだけを売りたい
・売名
　→全然知らないエンジニアに仕事を頼むのは難しい
・モノ書きで名前を売る
　→収入源としては期待していない
　→→物凄いスピードでかかないといい収入にはならない
　→でも伝えるのは好きだから書く
　→→「あの記事を書いている山本さん」と言ってもらえる
・腕磨き
　→新しい技術にキャッチアップしないといけない
・技術選定
　→自分でサービスを作るのに何がいいか
　→→自前なので標準にこだわる必要はない

◇まとめ
・10年先を見据えたキャリアプラン
　→そんなのない
　→常に変化していくもの

◇結果論として何がうまくいったか
・面白いことを見つけたら転職
　→やりたいことができる（可能性が高い）
　→→ずっといるとやりたくないことがどんどん増えてくる
　→収入アップ
　→新しい出会い
　→→過去の出会いの切捨てではない
　→→→会いたい人とは会える
　→→→会いたくない人とは会わなくていい
・「やだなー」と思ったらどんどん転職するのがいいと思う
　→安定収入のためには同じ会社にずっといるのが無難
・オープンソース
　→技術力向上
　→コミュニケーション能力向上
　→グローバルで通用するマネージメント力向上
　→売名！
・情報発信大事
　→ブログ
　→ソースコード公開
　→勉強会などで話す
・収集するのは簡単
・情報発信すると情報が集まる
　→フィードバックや他人のコメントがもらえる

◇自分戦略
・好きなことをやればいい
・10年先を見据えるなんてできない
　→そうではなく半年先、1年先を見据える
・愚痴はよいけど、行動に移さないとだめ



◆質疑応答

Q.
オープンソース開発を続けるモチベーションの源は？

A.
公開するだけなら簡単だけど、使ってもらえないとつまらない。
誰も使わない、フィードバックがないだとモチベーションを保てない。
だから宣伝はすごくしている。
twitter4jはtwitterが流行ると思ったので作った。
海外のニュース系サイトに投稿したりしてメディアに露出するようにし、認知度を上げた。
そうやっているうちにパッチが飛んできたりして、それでモチベーションが上がった。
いろいろなところで使われているというのは一つのモチベーション。
でも、使う人が増えすぎてプレッシャーを感じることもある。


Q.
仕事の外でアプリを作る時間をどう捻出するか？

A.
気が向いたときにやってる。
業務時間中には全く触らない。
「仕事で役に立ちそうだけど、会社だけじゃなくて世界の他にも困っている人がいるなー」というものは業務時間じゃなく個人で作って公開している。


Q.
所属している会社に飽きたきっかけは？

A.
飽きっぽい性格なので何年かいると飽きてしまう。
逆に何十年も勤めている人にそのモチベーションについて聞きたい。


Q.
面白かったり変だったり印象に残っている面接は？

A.
「会社に来ませんか？」誘われたので顔パスで入れるのかと思って会社に行ったら　…ガチで面接されたことがある。


Q.
ここだけは譲れないといった条件は？

A.
最低限はお金。現状維持以上というのは大事。
あと自分がやりたいことができるか。
でも1億2億くれるならやりたくないことでもやる。






山本裕介様、CyberAgent様、DevLOVE様、ありがとうございました。

『DevLOVE2012 - Social Change 〜ソフトウェア開発者が経営者になるまでと、これからの戦略〜』ノート

2012/12/15に開催された『Devlove2012 - Social Change 〜ソフトウェア開発者が経営者になるまでと、これからの戦略〜』のノートです。



◆はじめに

◇倉貫義人氏の自己紹介
・ソニックガーデンという会社を経営
・twitterとブログをやっている
　→お客様、ユーザに見てもらえる
　→自分達が何を考えているか、やっているかを書いている
　→→ブログなら外の人にも社員にも読んでもらえる
・「心はプログラマ、仕事は経営者」がモットー
　→日本では、営業出身の人やプログラマだったけどその心を忘れた人が経営者をやっている
　→→そういう経営者ではなく、プログラマの気持ちがわかる経営者のままでいたいと思いながらやっている
・少ない人数でどれだけ大きいことが出来るか
　→それがかっこいいと思っている会社
　→たくさんの人数で大きいことをやるのは普通
　→→普通なのはかっこよくない
　→ＩＴは少ない人数でも大きい仕事ができる業界
・Agile x Ruby x Cloudが技術的プレゼンス
　→アジャイルでずっと繰り返して開発
　→RoRでずっと保守性の高い状態を保つ
　→クラウドでスモールスタート・スケールアウトしている
・やっていること
　→自社のサービス
　→納品のない受託開発

◇キーワード
・エンドユーザ「所有から利用へ」
・作り手「完成させることから持続させること」へ
　→お客様は所有するわけではない
　→→完成させても仕方が無い
　→→利用してもらわないといけない
　→→→利用してもらうためには持続しなければいけない
　→完成しただけではお金は儲からない
　→→月々使ってもらってお金になる
　→「バグがありません」と言っても利用者がいなければお金にならない
・「ソフトウェアそのもの」ではなく「ソフトウェアが使えること」を売る
　→今までは作ったものを売ったらお金をもらえるというビジネスモデル
　→→これは八百屋と同じ
　→→→一次産業
　→ソニックガーデンは「使えること」を売る
　→→タクシーや映画館を考える
　→→「そのもの」ではなくて、移動する距離や映画を見ることを買う
　→→→これは三次産業
・ソフトウェアはまだサービス産業になっていない
　→サービス産業としてのITをやっているのがソニックガーデン



◆キャリアと自分が考えていることの話

◇学生時代
・プログラムをずっとやっていた
　→ベンチャーで働いていた
　→アルバイトとしてすごく給料がよかった
・研究室の仲間たちとフリーソフトを開発
　→ウェブで公開
　→みんなダウンロードしてくれる
　→掲示板に書き込んでくれる
・プログラムを書くと反応がもらえる
　→これは最高
　→→「インターネットとプログラミングを一生やっていこう」

◇まず海岸沿いのSIerに
・入社年度に経営方針の転換が
　→「技術大事だね」から「マネジメント大事だね」へ
・デスマーチプロジェクトに参加
　→周りはプログラミングの経験がないが、自分はベンチャー出身
　→→プログラミングができるということで悲惨な現場に
　→→ガンダム世代なので「1年戦争だ！」
・でもプログラマには1億円 ～ 2億円のプロジェクトを立ち直らせることができない
　→どれだけ画面を速く作ることができてもダメ
・あるとき平鍋さんに出会った
　→XP本を紹介された
　→→「俺の考えていることと同じだ！」
　→→「XPやアジャイルを広めていけばプログラマとして出世していく道があるのでは？」
・社内勉強会をやってみた
　→部内のメーリングリストに投げた
　→→でも反応がない
　→社外の勉強会やコミュニティに参加
　→→社内にいると半径3メートルしか見えない
　→→社外にいけばいろいろな人に会える

◇XPを読んで、そのとおりマネジメントを行った
・エンジニアをしていたが、徐々にマネージャの立場に
　→マネジメント・お金の計算…
　→→こういうのは苦手
・XPのとおりマネジメントをやった
　→仲間が集まってきた
・新入社員から育てた
　→やりたくない人がいるので、引き受けてしまう
　→→真っ白なキャンバスにアジャイルを教えることができる
・あえて炎上プロジェクトに入るという育て方もある
　→若いときだけ限定の手法
　→こういう場所ではみんな困っている
　→わらをもつかむ思いなのでやってくれる
　→「朝5分でいいから立ってミーティングしてみましょう」
　→アジャイルとか言わないでやるのがポイント
　→→上手くいったら「アジャイル」という
　→→上手くいかなかったら「それは無理でしょう　…上手くいくわけないじゃないですか」で収める

◇アジャイルのチームを作って中間管理職になったが
・ある日、会社の都合でチームが解散
　→履歴書を書いた
　→→「これじゃ転職してもPMやらされるわ」
・「もう一回プログラマをやろう」
　→でもjavaでは若い人に勝てない
・「エンタープライズでrubyをやろう」
　→でも受託はやりたくない
　→→「社内システムをやろう」

◇人月と完成責任のビジネスモデルは止めようと決めた
・そのために3つ捨てた
　→java
　→マネジメント
　→SIerの受託開発
・あと社内での出世も捨てた
　→「好きなことをやろう」
　→社内システムを作る仕事についた
・内製でアジャイルをやってすごくうまくいった
　→内製でアジャイルはすごく上手くいく
　→最初は2人で始めた
　→→それが全社展開するまでになった
　→→→その社内SNSを使ってイベントを企画・開催する人まで現れた

◇サラリーマンとしての転機
・また部下を持ってかれた
　→自分達でビジネスにすれば解散されないだろう
・社内SNSをオープンソースにしよう
　→会社を辞めて現場に行ってもそこに戻れるだろう

◇自分戦略の振り返り
・オーナーシップを持つ
　→会社を辞めるときまで自分は"会社の中にいる人間"だと思っていた
　→→そうではなくて、個人と会社は対等
　→→単に雇用契約をしているだけ
　→→→どっちが上か下かとかない
　→自分の人生は自分でオーナーシップを持たないといけない
　→→オーナーシップは「自分が会社員である」とか、そういうことには全く関係ない
・変化は自分から起こす
　→待ってから変化を起こすと大抵うまくいかない
　→→自分から変化を起こすようにした
・自分のチームを作る
　→2年目に辞めようと思って相談したとき言われた
　→「まだ止めたほうがいい」
　→→いま辞めても仕事はない
　→→元の会社から仕事をもらう形になる
　→→→ただ下請けになるだけ
　→→→→これはつまらない
　→「有名になれ」
　→→「自分の名前で仕事ができるように」
　→「仲間を作れ」
　→→いまだと自分が病気になったら終わり
　→→本当にやりたいことがあるなら一緒にやってくれる人が必要
　→→→仲間・チームを作らないといけない


◆起業・ソニックガーデン・ビジョン

◇起業を決めたときに考えたこと
・リーンソフトウェアビジネス
　→大きなことをするのに大きなお金を使うのがソフトウェア開発
　→→でも、いまのソフトウェア開発にそんなにお金がいらない
　→→→少人数でも開発できる
　→→→データセンターもクラウドで代替できる
　→→→→少人数でもそれなりのことがやれる
・ライフスタイルカンパニー
　→一生プログラマとして働きたい人がいる
　→→どうすれば（彼らが）それをずっとやっていけるかを考えている
　→上場してバイアウトとか考えてない

◇ソニックガーデンの3つビジョン
・IT業界の産業革命
　→お客様の真のパートナーになりたい
　→「作って終わり」はパートナーじゃない
　→→お客様がもうかったら自分も儲かるような、そういうやり方
・プログラマを一生の仕事にできるような業界にしたい
・いつでも夢にチャレンジできる社会に

◇世の中にはオーダーメードで作りたいというニーズがある
・受託はやるけど納品しない、派遣しない
　→月額定額モデル
・金額を見積もりから分離する
　→出来る範囲で頑張る
・顧問弁護士の働き方と同じ
　→プログラマも月額定額で顧問になればいい
　→→これは、お客様から見たら社員（内製部隊）に見える
　→→個人的には内製が一番いいと思う
・でも内製は難しい
　→実際にエンジニアを雇えるか？
　→いいエンジニアが分かるか？
　→→だからそこにエンジニアとして入る
　→→→移動しないで月額定額でやる

◇月額定額の形態が向いているビジネス領域がある
・次のようなものが必要な領域
　→スピード重視
　→フィードバック
　→スモールスタート
　→スケールアップ
・社員向けのシステムではなく一般向けのシステム
　→例えばEC。お客様の外に付加価値を提供するようなもの
・これからの時代はそういうビジネスばかりになる

◇完成指向から持続可能へ
・バグ0ではなく、出たときにすぐ直せるように
　→バグがないのは当然だけど、長く使っているといつかは出る
　→→そのときにどれだけ早く直せるかが大事
　→ある一点ではなく、ずっと続けることが大事
・コードの共同所有
　→綺麗なコードでないといけない
　→→リファクタリング
　→→コードレビュー
　→→テストコード
　→→→技術戦略に至っていく
　→みんな好き勝手に言語などを選定すると共同所有できない
　→プロジェクト毎に好きな技術を使うと技術が残らない
　→→プラットフォームの統一が必要
　→→→ここまでいくと経営戦略
・サーバ落ちてもいいけどすぐ復旧できるように
　→「絶対に落ちない」ではなく

◇品質とは何か
・仕様どおりに作っても仕様が間違っていると…
　→それはゴミ
　→ビジネス的に正しいことをやらないと価値にはならない
　→→ただただテストとか頑張っても仕方が無い

◇究極的にはプログラマが全部やるべき
・プログラマが要件定義から運用まで全部やる
　→テストはマーケティングからビジネスまで
　→運用はローコストキャリア
　→→技術の統一
　→→徹底的な自動化
　→→→少ない人数でも回せるように

◇所有から利用という波は明らかにおきている
・完成から持続へ
　→一次産業から三次産業へ
・まさしく産業革命
　→こういう活動を起こしていくことが大事

◇ソニックガーデンでは新規事業をたくさんやっていこうとしている
・でもビジネスは難しい
　→失敗したら死んでしまう
　→成功しても死んでしまう
・起業リスクはリスクじゃない。マネジメントすることができる
　→大きな山にいきなり登ったりはしない
　→小さな山を何回か登ってから
　→→起業リスクもそういう風にマネジメントできる
・ウェブ開発は基本的に人件費だけ
　→でもみんなホールインワンを狙う
　→でも脱サラして一念発起とか
　→→これはナンセンスだと思う
・スタートアップはまだ産業ではない
　→スタートアップを成功させるためには経験とか学びの時間が必要
　→→でもサラリーマンにはその時間がない
　→→→会社を飛び出さないといけない
　→→→→これはすごくもったいない
・一発成功はない
　→何回か失敗して、それから成功する
・学びの時間と一念発起のギャップをどうすればいいか
　→年齢が少々高くても企業できる社会に
・ソニックガーデンでは、顧問もスタートアップも一緒にできる
　→優秀な人は週の前半に仕事を終えてしまい、時間を作り出せる
　→→その時間にチャレンジできる

◇プログラマを一生の仕事にできるように
・「高みを目指し続けたい」
　→まずそう思ってもらいたい
　→→でも1人では登れない
・プログラマ = ソフトウェアのエンジニアリング全てに責任を持つ人
　→エンジニアリング = マーケティング・ビジネス・プロダクト以外の全て
　→ソフトウェアの全てを見る覚悟が必要

◇ソフトウェアの価値
　・完成した時点では0
　→お金を払って作ってもらったなら、最初はむしろマイナス
　→動かし続けて始めて価値がうまれる
・運用して使ってもらうところが本当に大切
　→エンジニアには運用・保守 ～ 最後の死んでしまうところまで見る覚悟が必要
　→でもそれができるプログラマってどれくらいいる？
　→→多くない、でもできないわけではない

◇どうすればソフトウェアの全てを見ることができるか
・ずっとRubyとお客と話すことしかやっていないエンジニアがいる
　→そうやって成長すると6年目にCTOになれる
　　→入社1年目から育てると全部のことができるようになる
・戦略とはどんなことに時間を費やすかということ
　→自分の時間を上手く使えばみんなにもできる

◇ソフトウェアの産業革命
・最初の産業革命で、職人から工場の時代になった
　→インターネットの登場
　→→再び工場の時代から職人の時代に
・プログラマはマニュアル化のできないナレッジワーカー
　→ノマドでタイムフリー
　→プログラマの生産性が一番高いのはマネジメントされていない状態
　→→自由にやらせるほど生産性が上がる
・ナレッジワーカーはマネジメントできない存在 = 大企業は不要
・会社としてどうやって自由にやらせる？
　→大きな会社じゃ無理
　→→小さな会社にするしかない
・人を信頼することが重要
　→小さい会社なら、信頼することができる
　→→個人の顔が見える範囲の会社で充分
　→ソーシャルメディアによる信頼と共感の世界
　→出来る量について嘘をつかない

◇ソニックガーデンの三つのチェンジ
・Embrace change
　→変化を受け入れる
・Fearless change
　→自分から変えていく
・Social change
　→変われたならそれを回りに広める



◆途中で出てきた話

◇脳のブレーキを壊す
・この前の（何かの）世界大会で記録が2回3回と塗り替えられることがあった
　→ここ10年破られていない記録だった
・誰かが1人破った
　→他の人も「オレもいける」となった
・社内で半径3メートルだけ見ているとそうなる
　→偉い人も社外の飲み会で見ると普通のおじさんだった
　→→そういう人達がすごい仕事をしている
　→→→「自分もできるのでは？」と思えた

◇外の活動と中の活動をする「ガラパゴスなキャリア戦略」
・大きな会社にいて外で講演・発表している人は珍しい
　→重宝される
・大きな会社でアジャイルをやっている人は珍しい
　→やはり重宝される
・エンジニアは自分の腕こそキャリアと考えがち
　→でも実は自分がいる環境も含めてキャリア
・自分の周りの環境も自分の価値
　→社内でやっていることを内緒にするのは勿体無い
　→社外でやっていることを社内に還元しないのは勿体無い

◇会社で新しいことをするには？
・提案ではなく相談
　→提案だと、上司は必ず反対する
　→→威厳がなくなるから
　→「○○をやりたいけどどうしたらいいか分からない」と聞く
　→→Yes / Noではない聞き方をする
・肩書きはくだらないけど大切
　→役職が低いと返事をくれない人がいる
　→→大企業では大事
・トップかららの視点と言葉を身につける
　→「社長もそういっているよね」ということで納得してもらえる

◇サラリーマンは意外とチャレンジできる
・経営者でチャレンジして失敗するとやばい



◆SIerとそのビジネスモデルについて

◇世の中は人月か成果物の完成責任かのどちらか
・macBookAir
　→モノにお金を払う
　→完成責任のビジネス
・弁護士
　→「絶対に勝訴してください」ではない
　→1時間辺り幾らのビジネス
・日本のSIerはねじれている
　→人月ビジネスなのに完成責任がある
・生産性を上げるほど売り上げが下がる
　→時間や人が必要な提案をする方が評価される

◇SIerでアジャイルをやろうとしてもあまりうまくいかない
・ビジネス的に完全に成功しない
　→アジャイル関係のものには別に悪いことは書いてないのに…
・なぜなのか？
　→そもそものSIerのビジネスモデルが悪い
　→→SIerのゴール：ものを売ること
　→→お客様のゴール：使ってお金をもらうこと
　→どうしてもいさかいが起きる
・SIerのビジネスモデル = 決まった要件の中でどれだけ作るか
　→このモデルが悪いのではないのか？

◇SIerを経営者の視点から見ると
・要するに保険屋
　→ユーザは「システムが完成するという安心」を買う
　→お金を出せば最後はなんとかしてくれる
・リスクを丸抱え出来る企業体力、これが優位性になる
　→合併するのはそういうこと
・保険屋ならそれは正しいかもしれないが
　→赤字プロジェクトに入ったエンジニアは悲惨
　→→人生を消費してしまう
　→→これはお金で解決できない

◇SIerとクラウドのビジネスモデルの違い
・SIerは作ってお金をもらって終わり
　→品質管理が製造業の考え方
　→→作りこんで、売る瞬間が最高品質
・SIerは製造業の考え方
　→一発ゴールの世界
　→こういう世界はウォーターフォールは理にかなっている
　→→アジャイルとか言わなくて良い
・SIerのつもりでクラウドビジネスをやっても全然儲からなかった
　→使っている瞬間を最高にしようと切り替えたら上手く回り始めた

◇今のシステム開発には問題がある
・派遣業界で人間のビジネス
　→業界の中の人から見ても問題がある
・ちょっと画面を変えるだけで数万、数十万かかる
　→業界の外の人から見るとこういう問題がある
・実際はそんなに費用も時間もかからない
　→数字が膨れるのはバッファがあるから
・みんなが自分の分のバッファを積む
　→期日を切ると、それは絶対に達成しないといけなくなる
　→→絶対にやるためにはバッファは積まないといけない
・バッファを積むのは人間だから仕方が無い
　→持たないというのは単なる精神論
　→→でも積むとぼったくりになってしまう。
・バッファが積まれる理由
　→「絶対にできる？」と言われると「5日」と返す
　→「できなくてもいいけどどれだけかかる？」だと「3日」
　→→バッファは"絶対"の約束から生まれる
　→→完成と納品から納期が発生し、それには"責任"が生じる
　→→→そしてバッファが積まれる
・納品しなければ上手くいくのでは？
　→ソニックガーデンがやっていること







倉貫義人様、CyberAgent様、DevLOVE様、ありがとうございました。

『DevLOVE2012 - 周りを巻き込みながら歩んできた関西人スクラムマスターの自分戦略』ノート

2012/12/15に開催された『Devlove2012 - 周りを巻き込みながら歩んできた関西人スクラムマスターの自分戦略』のノートです



◆講演者（中村洋氏）について

◇自己紹介
・大阪在住のエンジニア
・認定スクラムマスター
・5社くらいを2,3年くらいで渡り歩いてきた

◇コミュニティ活動
・devlove関西
　→セッション10個
　→100人を超える申込者があった
・スクラム道関西
　→アジャイル実践者が集まる
　→ワークショップでアジャイルの普及
・デブサミ関西
　→来年は実行委員長　

◇今日一番伝えたいこと
・「ええと思ったらやっていこう」
・人間、やらない理由はいくらでも出せる
　→それだといつまでたってもできない
・そういう思考にそもそも入らないことにした
・フィードバックをもらうようにした
　→厳しいフィードバックもある
　→→でもそれがあれば方向転換、突き進むなど考えることができる
・フィードバックを得る環境を作ることが重要（仲間など）

◇自分戦略の源泉
・基本路線
　→「ええと思ったらやっていこう」
・三つの柱
　→チームの成長
　→エンジニアをつなぐ
　→スパイラルな成長

◇自分の源泉にあるもの - チームの成長
・仕事の仲間が成長していくのを見るのが好き
　→時間、品質などが良くなっていく
　→振り返りで成長している様を見られるのはうれしい
・成長させるのではない
　→成長するのは彼自身
　→成長できる環境を精一杯整える
　→自分の経験を話すことはある
　→→でも押し付けはしない
　→しょうがない環境があれば整える
　→→たやすく成長できるように
・「自分達でできるからお前はもういらない」
　→こう言われるのが夢

◇自分の源泉にあるもの - エンジニアをつなぐ 
・自分には世界を変えるようなコードは書けない
　→でも、そういう人をつなぐのはちょっと上手かもしれない

◇自分の源泉にあるもの - スパイラルな成長
・主に自分自身へのモチベーション
　→同じところをぐるぐる回るのはいや
・次に会ったときお土産を渡したい
　→数ヵ月後も同じレベルのアウトプットをしているのはいや
・「この人と接点があれば自分にとってプラスなんだ」
　→そう思われる存在でいたい
　→でも他人にお土産を求めているわけではない

◇誰かの役に立ちたい
・これはみんな持っていると思う

◇そのためにどうするか
・自分でハンドルを握る
　→周りに影響されずに自分の判断で
・そのために4つのことをやる

◇自分でハンドルを握るための4つのこと

・やりたいことを表明する
　→半年に一度の評価面談ではみんな話す
　→→でも日常からやっている？
　→言っているつもりでも全然伝わっていなかったりする
　→→表明してやっていくこと = 自分のやりたいことをやる第一歩
・爪を砥いで準備
　→表明するだけでは駄目
　→→準備してるかどうかは表明の真剣さにつながる
　→→→やっていた方が回りは認めてくれる
・雪かきをやる
　→他の人がやりたがらないこと
　→チームでやっているとそういうタスクが発生する
　→→そのときに積極的に手を上げて拾っていくことを心がける
　→→→信頼貯金が出来る
　→そうすると、いいボールが回ってきたときにそれをまわしてくれる
　→ムダだと思われているタスクは、自分が好きに出来る
　→→効率化したり作業自体を廃止したりできる
　→→→チームのためになる
・仲間を見つけて巻きこむ
　→人間1人だとダークサイドに落ちやすい
　→言い訳もしやすい
→「それは違う」と言ってくれる仲間は重要



■エピソード

◆とあるお客様にて(10年くらい前）

◇コンテキスト
・100人くらいの開発会社
・ほとんどお客様先に常駐
　→自社には月に一回帰る

◇ここは面白かった
・こういうところはたいがいつまらない
　→ここは違った
・技術的にとがっている人もいた
・常駐先のお客様がいろいろやらせてくた

◇前提
・お客様と自社の両方に信頼貯金があった
・何回か社内勉強会やっていた
　→でもうまくいってなかった
　→平日帰ってきた後
　→→なかなかやらない
　→客先常駐なので、普段は顔を合わせない
　→→休日にわざわざそういう人と会おうとは思わない

◇こういう状況の中での問題
・独りでお客様先へ行くことが多い
　→目の前のタスクでいっぱいいっぱい
　→→技術を学ぶ機会がない
・結果として若手のモチベーションが低い
　→言われたことだけやればいい
・これはもったいない

◇アクション
・チームに若手をどんどん引き入れていった
　→本社に戻ったとき、姿勢のある若手とかいたらチームに引き入れる
　→姿勢を重視
・ペアプロやレビューなど一緒に考える時間を多く取った
　→タスク渡して放置という現場が多いがそうやらなかった
　→→そういう時間を徹底的にとった
・魚ではなく魚の釣り方を教えた
　→最初は釣れない
　→→何回かやると釣れるようになる
　→→→そのうち改善するようになる
・機能で分けてシステム開発
　→工程で分けない
　→「若手はとりあえずテストでも…」ではない
　→→そうではなく、縦串で一通り任せる
　→→→そうすると横のことも判る
　→小さな開発だったのが功を奏した

◇起こったこと
・人を集めすぎたので自分の仕事が回らなくなった
　→朝早く仕事を開始
　→→同じ勤務時間でも、残業するよりはるかに仕事ができる
・指示待ちではないやり方を知ってもらった
　→考えることでやりがいをもてるし、楽しくできる
　→自分でいかようにもできる
　→→ただ、全員がそうなったわけではない
・会社の数字にも貢献できた
　→若手をどんどん引き入れたので

◇ここでのまとめ
・社外常駐でもやりようがある
　→成長もできるし仲間も作れる
　→諦めたりやらない理由にはしない
・自分で仲間を見つけて巻き込もう

◇わざわざなんでそんなことをやるか
・もっと顧客に価値を届けたい
・若手にこうすればいいのではと伝えたい
・そういう情熱があった

◇何で辞めたか
・会社が派遣主体に
　→「翌月から○○に行って」みたいなのが多い
・チームから優秀な若手がはがされる
　→彼らが転職してよい会社にいく
・もういいかなとなった



◆某SIer

◇コンテキスト
・6000人規模でサラリーマンSEはそれなりに多い
・とんがった人もたくさんいた（る）
・人材輩出企業

◇自分の状況
・本部系部門で社内向けフレームワークやツールを作成
・Redmineやjenkinsなど生産性向上のセミナーや勉強会の開催

◇問題
・勉強会に参加者がなかなか集まらない
　→本社での開催ではそこそこくる
・これからとんがるかもしれない人達をつなげることができていない
　→これからとんがろうとしている人が現場にはそれなりにいたにも関わらず

◇アクション
・ローラー作戦
　→声を掛けまくった
　→メール・社内SNS・ランチ
　→→とにかく話しかけるようにした
　→社内SNSでのみ面識がある人に、出張したときに直接会った
　→→そうやって一本釣りした
　→10人に声をかけて1人釣れると成功だと思う

◇ポイント
・全員が社内勉強会に熱心なわけではない
　→大きい会社なので「粛々と定年まで給料をもらえればいい」という人もいる
・相手が何を求めているかを考える
　→相手のメリットや不安を聞く
　→→「今の業務ではすぐに役に立たない…」
　→→「業務時間内なので上司の許可が…」
　→→「勉強不足で怖くて…」
　→→→すぐに使えるコンテンツを入れたりハンズオンして手取り足取りで教える
　→→→相手が欲しいものを聞いて、内容を調整する
　→→→マシンを持ってきてもらって明日もって帰って使えるようなもの提供する
・一部や全部を業務時間外に開催する
　→「残業代はどうするのか？」という声
　→→そういう人は放っておく
　→組織がそういうことを言うなら、それはさっさと見切りをつける
・もっと上の人に働きかけてお墨付きをもらう
　→上にの人はもっと人材育成とかそういう目線がある
　→→彼らを口説く
　→現場の人は目先のプロジェクトを見てしまう
・社外勉強会をそのまま持ち込む
　→休憩の時間に見に来てもらう
　→→突然当てられることや怖いこと、そういうことはないということを知ってもらう

◇Fearless change
・人が取るアクションには理由がある
　→こういう組織はアーリーマジョリティが一番多い
　→→アーリーマジョリティを巻き込むためにアーリーアダプターをいかに巻き込むか
・流れが出来れば自然にいける
　→参加した人が、自主的にコミュニティを作ったりするように
　→各部門にバラバラにいたリーダー達に連携が
・大きな組織でもうまく巻き込めば仲間を見つけコミュニティを作れる
・社外コミュニティの情熱で社内に（小さな）変化をもたせる
　→パッション大事

◇なんで転職したか
・数千人が変わるのを待つには人生は短い
　→1割でも変わればいいかとおもった
　→→だけどそれも遠かった
・ユーザの声をもっと聞きたかった
　→大きい会社なので間に他の部門が入ってしまう
・カットオーバー後の話をする機会がない
　→そもそもチームが解散したりとか



◆今の会社

◇状況
・自社プロダクトサービスを作っている（ウェブブラウザ）
・職人肌のエンジニアが多い
　→毎朝にgithub3時間使う人とか
　→窓の社でノミネートされてるとか
・勉強会主催者もいる

◇やってること
・現在進行形で巻き込みしている
・3チームのスクラムマスタ
・部門の障害をやっつけたりもする

◇問題点
・ドライブ力が物足りない
　→職人肌の人は自分である程度の問題設定を作れる
　→→それを片付けることもできる
　→でもビジネスとかユーザが苦手
　→→そこの突破力がない
・開発プロセスが未成熟
　→個人は当たり前のようにテストなどやっている
　→→でも、組織としてみると俺々ルールが多い
　→方向を間違えなければいいところにいくのに…

◇入ってやったこと
・姿勢を見つめなおしてもらう
　→正解がない問題を自分達で考えるように
　→よいブラウザって？
　→→答えはない
　→→→使ってみて始めてわかる
　→仮説検証する姿勢重要
　→→そういう取り組みをするようにする
・フィードバックを正面から受けられるように
　→厳しいメッセージにも目を背けずに
　→→そこから一生懸命考える姿勢を
・透明性を維持する
　→朝会で自分のことを素直に話せる人ってどれだけいる？
　→→上司の進捗会になっていることが多い
　→→→それは朝会じゃない
　→自分でタスクを取り、周囲が助ける
　→→自分達で判断してやっていく

◇入ってやったこと
・ふりかえり
　→wikiにいろいろ書いてもらう
　→→書いてどうするの？
・テストコードがない
　→テストを書こう
　→→こんなの意味ない
　→→→こういうのを改善した
・タスクボード
　→redmineを使っていたけど…
　→→進捗はよくわからない
　→タスクボードを作った
　→→朝会に持って行ったりしている

◇姿勢を変えるために
・社内勉強会
　→『チーム力を上げる"朝会"のコツ』
　→プロダクトオーナー勉強会
　→ユーザストーリの作り方
・結果
　→自律的なチームになりつつある
　→チームのアジリティも上がりつつある
　→→まだまだこれからできることがあると思う



◆最後に

◇コミュニティについて
・様々な経験を持ついろいろな人達の集まり
・それをどう使うかは自分次第
　→話を聞いて終わるか
　→自分のコンテキストに合わせて使うか
　→使った結果からさらに相談したり
・仲間とめぐり合う部隊

◇何時に起きてるか
・22:00に寝る
　→3:00に起きる
　→→6:00に会社
　→→→9:30に始業

◇情熱はすごく大事
・でも1人で燃やし続けるのは難しい
　→周りを巻き込みように
　→社内にいなければコミュニティで
・巻き込まれてくれている仲間にThanks!

◇「ええと思ったらやっていこう」
・「もうこんな年だから…」「こんな状況なので…」
　→自分が勝手に作っている制約
・いいと思ったらその日から始める






中村洋様、CyberAgent様、DevLOVE様、ありがとうございました。

『スクラム道 EXPO 2012 - 午後のセッション』ノート - 2 / 2

2012/10/28に開催された『スクラム道 EXPO 2012』午後のセッションのノートです。間が空いてしまったので、パート1と2に分けました。

パート1はこちら


◆岩崎 奈緒己氏「分散スクラム」

オフショア & スケーリング（複数チームが連携してスクラム）について


◆海の向こうのスクラム（オフショア）問題と改善
・無理だと思う人たくさんいるのでは？
　→JIRA, Redmine
　→skype

◇問題：全員が映っているわけではない
・ビデオ会議なので起こる
　→誰が誰に話しているか分からない
　→こっちは盛り上がっているが、あっちは…
・解決
　→呼びかける
　→→「○○さんに質問です」
　→実況中継
　→→「○○がいます」
　→→「相談中だから待ってください」

◇問題：途切れる声
・「……が………の……………でいいですか？」
　→大事なときにこそ起こる
・解決
　→チャット
　→→話をしながら打つ
　→ビデオ
・会議用スライドを画面で共有する
　→アジェンダを写しながら話す
　→→その場でスライドに成果を書き込む
・直接行って会う
　→ぜんぜん違う

◇海の向こうのスクラムのまとめ
・特別なツールがなくても話し方やちょっとした準備で改善することが多い
・直接会ってどんな人か知ることが一番効果的（特に初期）


◆チーム連携（一箇所で複数チーム）問題と改善
・リリースバーンダウンを並べる
・全体の課題のためのボードを作る
・同期を作るためにマイルストーンのボード
・体制図

◇問題
・スプリント計画、レビューとか人が多い
　→合戦みたいになっている
・プロダクトバックログが大きい

◇2段階の会議
・多すぎる会議
　→基本はチーム単位で行うこと
・Scrum Of Scrumで連携
　→チームをまたぐ課題は別の会議体で

◇ストーリーマップ x バックログ
・1枚のシートに大量の項目・文字があったので対策
　→プロダクト全体をストーリーマップで表現
　→各チームごとのプロダクトバックログを作成
　→細かい受け入れ条件は別シートへ

◇スケーリングする場合のまとめ
・複数チームに関係することを話し合う会議体が必要
　→そうしないと「あのチームこんなことやってるの？」「聞いてないよ」とか生まれやすい
・各チームがプロダクトの全体像をつかめるような資料が必要
　→各チームが何やっているかは全体像があればだいたい掴める


◆崩れてしまったときの心の持ちよう

◇うまくいっていない場合
・みんなが「これでいいじゃん」で進めてしまった
　→「なんかおかしい。いや、絶対おかしい」となった
・オフショア・大規模だと問題が起こりやすいし複雑化しやすい
　→起こっても見えにくい
　→→チームではうまく行っていてもプロダクト全体では問題とか

◇止める
・そういうときは止めないといけない
　→まずはプロダクトオーナーに相談
・非効率なスプリントを中止する
　→冷静になりましょう
　→大きいものは小手先でやっても上手くいかない

◇消す
・でも緊急でやるべきことはやり切る

◇組みなおす
・情報を整理していく
　→大きなものから小さなもの
　→荒いものから細かいもの
・インセプションデッキが狂っているのにプロダクトバックログを直しても意味が無い

コンセプト
□□□□□□□□
□□□□□□□□
↓
ワークフロー・ストーリー
□□　□□　□□　□□
□□　□□　□□　□□
↓
タスク
□　□　□　□　□　□　□　□　
□　□　□　□　□　□　□　□


◇要求以外でも重要な情報は整理
・検討課題
・リスク
・周知、情報共有

◇1つずつ着実に行う
・みんなが見えるように
　→でも早く
　→→改善疲れが出てくるので

◇巻き込む
・1人でやっていても、周りがしらける
　→息が続くうちに
　→みんなが見放す前に

◇まとめ
・いかに状況を早く見える化するか
・いかに改善が目に見えるようになるか
　→それぞれ掛け算になっている
・プロセスを止めるのも組みなおすのも全員が疲れる
　→巻き込む気力とスピードが肝
　→引っ張るのではない

◇最後に
・『小さな工夫、大きな成果』が大事
　→大規模・オフショアって大きく見えるが、大事なのはちょっとした小さな工夫
　→→それを着実にやれるか
・できないのはそういう工夫を飛ばしているから
・誰がやるか
　→皆で
・ピラミッドになっていて「あの人が言ったからやる」ではない



◆上田 佳典氏「はじめての自己組織化」

◇自己組織化とは何か
・自分の言葉で説明できる？
　→脱コマンドアンドコントロール
　→タスクをアサインしない
　→クロスファンクション
　→優れたチームワーク
　→→いろいろある

◇ここで動画
・self-organization in hanoi traffic



　→信号がない
　→警官がいない
　→それでも自分達で状況理解・判断・行動
　→→外から指示されないというのがポイント
・『チームとして』最適な方法を自分で判断し行動すること
　→『自分として』ではない

◇どういう観点で考えるか
・ビジョン・ゴールを共有する
 →QCD + S
・長期的・短期的で考えることができる
　→ノウハウ共有
　→チームとPOの教育
　→→といった観点を踏まえ、自己判断で行動できるように
・全部インセプションデッキで話す内容
　→インセプションデッキを作って総合判断する
・デッキを作ったら放置でよい？
　→そうではない

◇スクラムマスター・プロダクトオーナー・管理職は自己組織を加速するためにどうすればよいか？
・補助輪になる

◇自分で考えて動くってどういうこと？
・自動車教習所で教わること
　→認知
　→判断
　→操作（行動）
・人が行動して失敗するときはこのどれかの段階でつまづく
　→スクラムマスター・プロダクトオーナー・管理職はつまづく原因を取り除く
　→→特に認知・判断をしっかりサポートする
　→→→ウォーターフォールの人に対しては特に重要

◇プラクティスで気をつけること
・朝会
　→個人のタスク整理ができていない
　→→状況と自分自身がやることを認知できていないから
　→朝会前にリマインド
　→→朝会前に整理するフェーズを入れられるように

◇それでも3つの共有事項がいまいちなことが…
・正直な思いを伝える
　→チームに共有事項の感想を求める
　→→そうやって自分の立ち位置を理解してもらう
・タスクを選べない
　→背中を押す
　→→「失敗してもいい。取っていい」
　→→→今まで失敗しないように仕事していると安全側に倒したがる
　→WIP(work in progress)の制限
　→→自分自身がやることをはっきりさせる
　→WIPがよくわからないならペアワーク
・プランニング
　→ストーリーの実装方法が分からない
　→→スキル不足
　→→消極的
・メタ情報の収集不足
　→プロダクトオーナーに聞けばわかることを聞けない
　→→請負根性
　→→スキル不足
　→プランニングで意見を求める（設計・実装・ストーリーポイント）
　→→「どう思う？」積極的に聞く

◇ポイント
・情報収集する
・自分で考える
・成長する

◇ふりかえり
・課題意識の欠如
　→KPTの希薄化
　→どこか他人事
・自分自身の成長戦略を立てられない
　→TRYがプロダクトの話ばっかり
・本音KPT
→本音で喋れる場をまず作る
→→楽天の藤原さんは、まずリラックスできる場を作るという
→期待を出し合う
→→「どうなって欲しいとか」お互いに求めるものをお互いに出し合う
・根本原因分析
→開発をやっているとじっくり考える暇がない
→→時間が無いならKPTせずにいきなり根本原因分析をするのもあり
→→→ゲームストーミングのSquid（イカチャート）
・じっくり考えることが重要

◇革新会議
・じっくり考える時間がない
　→でも重要
・成長するエンジンが欲しい
　→あればほうっておいても成長してくれる
・従来型の報告会議をビジョン・ゴールのメンテナンスの場にしてみた
　→自分の成長戦略を考える場に
　→→やり方はチームに任せる

◇大事だと思ったこと
・自橙明
　→釈迦が亡くなるときの話「自分で考えて決めろ」
・自分が明かりになって道筋を明るく照らす
　→自らが常に意思決定に関わるように

◇これまでのやり方が通用しないのは何故か
・他人が過去に決めた仕組みやルールだから
　→これからは状況に応じた"意思決定"自体が重要になる
・ソフトウェア開発でも適切なカードを切るスキルが求められる時代に

◇"答え"ではなく"答えを出す方法"を学ぶ
・でもそれだけじゃ足りない気がする

◇神々の意識改革
・お偉いさんの意識を変えてもらう
　→チームや個人を信頼し許可を与える
　→→そういう上司の一言と後押しは心強い
・神々からの支援
　→チームが解決できない問題を解決してみせる
　→→会議室の予約・組織をまたいだ勉強会etc.
　→→→社長に直談判して、社長を通して解決してもらったことも
・アジャイルのゴーサイン

◇まとめ
・チームとして最適な方法を自分で判断し行動すること
・観点
　→ビジョン・ゴールを共有する
　→QCD + S
　→長期的・短期的で考えることができる
　→ノウハウ共有
　→チーム・POの教育
・補助輪
・認知、判断、行動
・神々の意識改革
・信頼、許可、支援

◇最後に
「コマンドアンドコントロールからさよなライオン」

岩崎 奈緒己様、上田 佳典様、スクラム道様、ありがとうございました。

【チラシの裏】今日の送別会の帰り道に思ったこと

2007年の4月、社会人になって初めての給料をもらった週末、電車がなくなる時間まで飲み、そして歩いて帰った。

サラリーマンとして稼いだお金でお酒を飲んだというささやかな満足感とか、これから始まる社会人としての人生に対する晴れやかな気持ちであるとか、今日飲んだ同期の仲間達とずっとやっていきたいという希望とか、自分の世代が今以上に会社を盛り上げていくのだという野望とか、一生懸命勉強して優れたシステムを作るのだという向上心とか、いろいろな気持ちを抱えてワクワクしながら歩いた。社会人として成長していく自分のことを思うと、明日のことを考えるのが楽しくて仕方がなかった。

そして、本日付で私は会社を辞めた。明日から別の会社に勤めることになる。

昔の常駐先の職場の先輩が送別してくれることとなり、普段いかない場所で飲み、自転車に載っておらず、飲んでばかりだったので締めのラーメンが必要　…など、いろいろな条件が重なり、たまたま5年半前と同じ道を歩いて帰ることになった。

キラキラした何かを抱えていたあの日の自分と、その会社を辞めたという半ば冷めた気持ちを抱えている今の自分が同じ道を歩くという偶然に驚きながら、当時のことを思い出したり、今の自分に重ねてみたりしながら帰った。

やりたいことを貫き通すために会社を飛び出したのだという覚悟や、新しく迎えてくれる仲間の期待に応えることへのプレッシャーなど、今の自分には向き合わなければいけないものがあって、だから当時のような純粋で晴れやかな気持ちで歩くことはできなかった。でも、それは、自分が当時より少しは成長していることの証なのだと思った。


今までお世話になった会社の皆様、ありがとうございました。そしてこれからお世話になる会社の皆様、宜しくお願い致します。

『第4回テックヒルズ UI,UXの衝撃 ～ユーザーを魅了するプロダクトの裏側～』ノート

2012/11/07に開催された『第4回テックヒルズ　UI,UXの衝撃　～ユーザーを魅了するプロダクトの裏側～』のノートです。



◆酒井洋平氏 「開発者のためのUXデザイン」

◇UI/UXって？
・UXって？
　→ユーザエクスペリエンスの略
・UIって？
　→ユーザインターフェースの略
・なんでUI/UXで一括りなのか？
　→この状況は不思議
・ネットでも専門家がいろいろ書いている
　→でも、皆「ん？」という状態なのではないか？と思う

◇↑のあたりを整理する
・UXはユーザからみた主観的な経験
・UIはユーザの主観的経験を支えるための接点となるいろいろな道具
　→券売機、ATM、自販機など。

◇人(UX)　←→　UI　←→　システム
・人に属するものがUX
・↑を支えてシステムとつながっているのがUI
・これが同時に語られるのはどういうことかということ。
　→大事なポイント
・旧来、デザイナーはUIを大事に考えてきた
　→いまはUXについても考えないといけない
　→→それはUIがUXを支えているから
　→→→そこまで考えざるをえない状況になっている
　→だからUI/UXという表現になってきている

◇ユーザの主観的経験なのでデザインできるのか？
・個人の内面的なものだからできないと思われるが…
・そうではなく、ある主観的経験が想起されることを企図した設計と考える
　→多くの場合はビジネスとしてやるもの
・ユーザに"価値がある主観的経験"を想起させること企図した設計
　→"個人的には"それがUXデザインだと思っている
・この辺りは議論になっている
　→ウェブ上
　→各種専門家など
　→UX白書
　→→UX白書をググってご覧ください

◇ユーザって誰？　ユーザにとっての価値は何？
・この辺りをいま課題に感じている
　→ユーザって誰？どこにいる？
・見つけてきたユーザにとっての価値を真剣に考える
　→それをやらないとUXはできない
・今までのウェブでは数打てばあたるというところがあった
　→この辺は肌感覚でやっている人も多いのでは？
・どうやって見つけるか？
　→難しい

◇価値発見プロセス
1. 計測
2. 気付き
3. ベンチマーキングと観察
4. 脳内でプロトタイピング
5. ストーリーテリングで価値を訴える
　→このような活動をとおして新しい価値をもたらそうとしている

◇UXデザインをサマライズする
・あるUXの価値（ユーザにとっての価値）がある
　→それをどう発見するか？
　→どう実現するか？
　→→これがポイント
・具体的な価値が見つかったときにどうするか
　→部門横断的に価値に向けて動かないといけない。
　→→マーケティング・プランニング・デザイン・エンジニアリングなど…
　→UXの専門家がいるだけではどうにもならない
　→→全社的に理解してやっていかないといけない

◇展望
・マーケティングやプランニングなどの領域でもUXデザインと同じ考えを別の言葉で使ったりするのではないか
　→同じような活動が行われたり
　→同じことを別の言葉で指していたり
　→→そういうことが多い
・UXデザインの周辺ではその辺が整理されて全体統合的な流れが出てくるのでは
　→それが活発な企業から成功事例が出るのかなー


◆橋本建吾氏　「UI/UXについて 〜LINEの場合〜」

◇UX design ≠ UI design
・全然違うもの

◇理解を深めるために
・Janice Fracerの写真

from The Difference Between UX and UI: Subtleties Explained in Cereal

　→食器や食材がバラバラの状態
　→→この状態だとどうすることもできない
　→→これをプロダクト、機能リストして考える
　→これをスプーンで統合する
　→→スプーンはインタフェース
　→→カップにシリアル
　→→ミルク
　→→スプーンで朝食
・これはUXとしては原始的なもの
　→でも結果として空腹が満たされる
・もう少し上層的な考え方
　→牛乳の量をコントロールしてシリアルの質感を変える
　→砂糖やジャムで味を変える
　→→こういうのもUXのアプローチだと思う
・自分でもチョイスしてみる
　→日本食
　→木の橋
　→漆の器
　→陶器
　→→ユーザの感じるものがずいぶん違う
　→→同じ結果でも与える印象はずいぶん違う
・材料や素材のチョイスで結果が変わる
　→このチョイスがUIデザイナーの役割

◇UXとは？　UIとは？
・UXはユーザの感受であり体験
・UIは感受性を生み出す入り口、窓

◇NHN UX Designプロセス
1. simple
・NHNに入ってまず上長に言われたこと
　→半年くらい言われ続けた
・なぜUIにシンプルさが必要なのか？
　→様々なものが双方向的になっているから
　→→ユーザが参加するインターネット、という構造の出現
・ブログメディアの発展
　→素人の人でも情報が流通できる
　→→不特定多数の人間が情報を流通
　→非専門家による情報の供給
　→→シンプルなインタフェースが必要になる
 →→→誰でも使えるようなもの
・この考えはビジネスのデザインにも影響する
　→そういうデザインの方が強い
　→→0.5秒で持って帰ってもらえるようなもの
　→シンプルにUIを構築すると同時に、シンプルにバナー・広告も考える
　→→そちらの方がよい

2. Quick and Fast
・まず昔の一般的なワークフローについて考える
　→plan →> design -> develop
　→→ウォーターフォール的なワークフロー
　→工期が読みやすくて進行に有利
　→→でもプロジェクトのロールバックには弱い
・今やっている方法
　→UXがリサーチ
　→UIキャッチアップしてプロトタイプ
　→1回では終わらせずループをクルクルまわす
　→あるUIが完成したら開発にまわす
　→ここでもUXの方でデザインやインタラクション、ニーズへの満足度を検知
　→足りない場合は開発に戻す
　→これを半日とか一日単位でぐるぐる回す
・比較
　→ウォーターフォールはプランが無いと動けない
　→後者は起点がどこでもよい
　→→どこからでも回せる
　→→→クイックな開発・意思決定ができる

3. 意匠
・身の回りにあるもの
　→材質とか色など、ポイントを持ってものを選んでいるはず
・スマートフォン
　→→液晶などが進化していて非常に品質の高い表現ができるようになっている
　→毎日使うスマホのアプリにそこまで気を配っている人がどれだけいるのか？
　→（作り手も）あまり心血を注いでいないような気がする
・最近はUIコンポーネントがライブラリ・共有化されている
　→パーツを組み合わせればある程度のサービスができるということ
・差別化を図るには？
　→意匠を追及し、UXを高めていかないといけない
　→→特にUIデザイナが取り組まないといけない、という課題
　→→「ノイズを取り除く」
・流れや空気感を壊さないようなデザイン
　→画面上の情報のボリュームよりも
　→→そういうところにデザイナもコミットしないといけなくなってきている
　→→→「かんなをかける」と表現している
・「かんなをかける」
　→ざらざらした四角い木
　→→かんなをかけるとなめらかで気持ち良い質感になる
　→→→それはUIデザイナがやらないといけないこと
　→→→→そのためにはプロトタイプデザインを重ねていくしかない
・かんなをかけたUIはそれがごく当たり前のように見える
　→その当たり前に気付くか否かが重要
　→→だからプロトタイプを作り日々デザインする
・見た目や使い勝手に磨きをかける
　→そうすることで気持ちいいUXデザインができる

◇まとめ
・UIデザイナの選択の連続がユーザ体験を様々に彩る
　→一つ一つの選択の与える影響が大きい
　→→選択することに、より注視する
・使う人の立場、状況を踏まえデザインをシンプルに
　→シンプルにするのは怖い
　→→そこを踏み込んでいくことほどのUXのアプローチはない
・プロトタイプデザインを繰り替えす
　→そうすることで品質のでこぼこをなくす



◆坪田朋氏　「アジャイル開発におけるUX」

◇UI/UXについて
・UIって単語はイメージしやすい
　→議論の中で出てきても腹落ちする
　→でもUXは違う
　→→議論するときだいたい着地しない
・UXの定義をUX白書から引いてみた
　→「UXという分野は、システムの利用（あるいはシステムとの出会い）を通じて人々が持つ経験について…」
　→→なんど読んでも腑に落ちない
　→うまく言語化できないと思ってしまう
・UXという言葉が1人歩きしている
　→多くの概念を包括している
　→1つの定義で言い表せなくなっている？
　→→この言葉を使って議論することは危険？
・でもUXの意味を考えた
　→システムの利用を通じて人々が持つ体験
・UXって？
　→フレームはある
　→→タイムスパン
　→表すための要素もある
　→→ハニカム構造
　→自分で学んではき出していかないと身につかない

◇UXデザイナーとは
・自分はどう思っているか
　→イケてるプロダクトを作りたいと思っている
・ユーザーの立場を中心に考える
　→ユーザ価値のためにどうプロダクトを作ればよいかを考える
　→様々な方法論を組み合わせて課題・要求を解決する

◇イライラUIが生まれる理由
・最終的なプロダクトアウトはUI
　→なんでイケてないUIが出来あがるか
・ユーザニーズの不理解や市場の勉強不足
　→UXデザインで重要になってくる
・コミュニケーション不足やチューニング不足
　→UXデザインの後に出てくる
・これらがないと、イケていないUIデザインになる

◇Denaでの開発プロセス
1. リサーチ
2. 要件定義、UI開発
3. テストリサーチ
4. リリース
・これをループ
　→UXデザイナはこの全ての責任者だと思っている
　→→何をやるかを決めてチームを回すところまで

◇リサーチでなにをやっているか
・定量調査
　→アンケートを使って、数値化・グラフなどで表現したものを分析
　→→主観が入るところを定量化して明確に
　→→→いろいろな軸で切り取る
　→キャッチコピー・サービスの機能名・コア機能のニーズ・イラスト・キャラクターなど
・定性調査
　→定量調査で終えないものを追う
　→→実際に使ったときにボトルネックになっているものとか
　→→→スマホでゲームしているときの視線の動きなど
　→競合サービスに対しても使い、ヒアリングする
・競合調査
　→何が刺さっているかなどを切り出す
　→→ターゲットユーザー
　→→プロモーションマーケティング
　→→デザイン
　→→→設計
　→→→グラフィック

◇調査した後はUI開発
・要件定義やUI開発をする
　→要件定義は、何が課題で何をするかを決める
・まずはストーリー
　→それからUI設計
　→→ペーパープロトタイピングやワイヤフレームワーク
　→→→課題をどうUIで解決できているかを見る
　→使いやすさを考えるために実機でモックを作る
　→→HTMLやcssで再現
・違和感を感じた部分は何度も作り直す
　→必要かどうか迷った機能は落とす
　→→迷うような機能をユーザは使わない
・UIが決まったらGUI
　→どういうグラフィックにするかをデザイナと決める
　→→複数パターンを作る
　→→→チームやアンケートで採用する案を決める

◇リリーステスト
・プロダクトを始めて触る人が直感的に分かるようにしたい
　→ユーザに見てもらう
　→→テキストやアイコンなどの直感的な判断に関わるところを見てもらう
　→作っている側は慣れるので冷静に判断できない

◇リリース
・本当に受け入れられてアクティビティが向上しているかを見る
　→A/Bテストなど
　→→乱数・特定地域やセグメントなどで分ける

◇まとめ
・UI設計で重要なこと
　→徹底的な分析
　→→定量/定性
　→プロトタイピング
　→→実際に作る前
　→→→巻き戻りのコストを下げるため
　→→UIを決めてからGUI
　→ユーザーテストの実施と繰り返し
　→→盲目的になってしまったところを解決する

◇スクラム開発
・数年前から欧米で流行っているアジャイル開発の手法
　→上記のやり方をどう回すか？というところでスクラムを使っている
　→欧米では採用が多い

◇現場に求められていることは
・スピード
・スピード
・スピード
　→ウェブ開発では重要

◇高いスピードと品質を求められる
・マネジメントの期待する要求でスピードを出す
　→出した後は数字を求められる
・品質をスピードを達成しないといけない
　→スクラムだと品質とスピードが出せる

◇スクラムによる開発プロセスの最適化
・優先度・目的の可視化
・役割の明確化
・コミュニケーションコスト減

◇スクラムフレームワーク
・ストーリー
　→プロダクトバックログ
　→スプリントバックログ
・ミーティング
　→スプリント計画
　→朝会
　→振り返りとレビュー
・役割
　→プロダクトオーナー
　→スクラムマスター
　→チーム
・誰が何をやっているか、意思決定者が誰か、が明確化されている

◇スクラムについて
・ストーリーの書き方
「<サービス>においては、<目的>をしたい。なぜならば<将来の対象>は<現在の対象>に比べて<統計的事実>だからだ」
・スプリントは2週間
　→最初の月曜がプランニング
　→最後の金曜日がレビュー
・スクラムチーム
　→各人が専門（意思決定権）を持っている
　→→意思決定者が明確なので、コミュニケーションコストが減る
・チーム
　→UXデザイナ・リサーチ・エンジニア・UIデザイナなどに分けている
・スクラムではスクラムチームがまとめる
　→ディレクター制だとディレクターに集中してしまう
・チーム外のステークホルダーにはレビューで見せる
　→それを次のスプリントで改善する

◇ディレクション工程のシステム化
・Excelで線表を引く時間すらもったいない
　→ガントチャートはやめて朝会
　→アナログのタスクボード
　→→みんな自分で管理
・ミーティングは全員たってやる
　→タスク管理ツールはシンプルに
　→→タスクボード
・UIデザイン
　→パワポでワイヤーフレームから、チームでホワイトボードへ
　→→決まればデベロッパとGUIの人へ
・偉い人からの差し込み
　→基本的にはブロック
　→→レビューにまわして「次にやりましょう」

◇専門性について
・浅く広くではない
　→スペシャリストが作り、決める
・コンセプト・優先順位を明文化することでチームは自走する
・スペシャリスト同士のコミュニケーションに特化する
　→コミュニケ-ションコストを減らす

◇まとめ
・企画者は1人
　→事業管理している人
・サービスデザインはエンジニアやクリエイターの領域
　→彼らが作るのが一番早い
・UI設計はリサーチとテストがとても大事
・UXを考えないUIは時代遅れなのでは
　→リリースして終わりではない
　→→リリース後の効果分析を徹底的に行う
　→→→次に何をするかを決める






CROOZ株式会社様, 酒井洋平様, 橋本建吾様, 坪田朋様, アカデミーヒルズ様、ありがとうございました。