#DevLOVE ビジネスとデザイン~ビジネスは悪くない~

イベントページ:http://devlove.doorkeeper.jp/events/2879

GxPこと、グロースエクスパートナーズさんに初来訪しました!

東サンの講演より

※本件は、DevLOVE2012、デブサミ2013の再演です。

ノート

  • Q. どうすれば、世界が変わりますか?実際に世界を変えた人を頭に浮かべてください。
  • Q. あなたにとって、開発は、趣味なのか、生きる為の手段なのか、プロなのか?
  • レコメンド書籍:『僕たちはいつまでこんな働き方を続けるのか』

    僕たちはいつまでこんな働き方を続けるのか? (星海社新書)

  • 労働価値:交換(労働)価値
    rf. 日本におけるテクノロジのハイプ・サイクル(2012年) http://gartner.co.jp/press/html/pr20121003-01.html
  • 満足度を変えずに利益を出すようにしなきゃいけない。
  • スキルビルディング!

おすすめしたいポータブルスキル 4つ

  • コミュニケーションスキル
    => 今現在何ができるか、ではなく、人ができていれば、その人を育てることを大事にしているとのこと。
    => 英語は、きわめて安上がりで、年収を上げられるツールのうちのひとつ。コスト効果の高いスキルの一つ。
  • 環境適応能力
  • マクガイバリズム http://dvd.paramount.jp/macgyver/ a.k.a. そこにあるもので対抗していく力
  • デザイン思考

スキルとしてのデザイン

  • UIで見える形にしてあげる = もはや必須の力になってる!
  • => デザインスキルは使用価値も(労働)価値も高める!
  • “デザインは人間を積極的に対象にしている”

最低考える6つのUI要素

  • アセット
  • スタイル
  • モーション(砂時計とか、待たせる時のアクション)
  • レイアウト
  • UIコントロール
  • スクリーン
  • テクノロジを選んだ段階で、できることは限られてくる
  • パレートの法則
    最初の20で80分かった気になる。でも、その先の80が大変なんや、と。
    本編のスキルは100を目指して、隣接分野を20(80)入れるのが大切。
  • デザインもテクニカルで多い => 溜めて資産化して力にしていく

すでに予測は立っている

  • IDCジャパンの予測
    http://www.idcjapan.co.jp/Press/index.html
  • ガートナーの予測
    http://gartner.co.jp/press/html/pr20121113-01.html
  • 今後は、革新、差別化、記録、の3ジャンルのアプリに分類される。 保守で7年なんて契約、もはや現実的ではない。
  • Device Age = Dev-Ice-Age デベロッパーの氷河期到来
  • CLI => GUI => NUI(Natural User Interface) の時代
    Win8はGUIとNUIの間。
    Win8を目指して、GUIをしてる人たちが、これからを生き残れる人(淘汰される可能性もあるけれど生き延びれる可能性もある)
  • 開発スピードを加速させる生産性と選択能力
  • UIでデリバリーされるユーザーのコントロール能力
  • たくさんのカードを持とう
  • 「作らない」ことを決める大事さ
  • xxみたいなのを作ってください、というイメージが既に顧客にある  簡単に回避できる方法を知っていること。

Call to (Small) Action

ツールを使ってみてくださいw
http://jp.infragistics.com/promotions/igniteuigrid.aspx

next action

Call to Action

ダイアログ(ワールドカフェ)

個々人の自己紹介のあと、ワールドカフェを3回戦

この日は、その日驚いたこと、がテーマで、何も意識せずにその日あったことを話したら、セッションとひもづけたりしたらあるじゃない!とその後に解説されてビックリした(すみません)

体験フィルターの活性化という意味で自己紹介大事ですよ!だそうです!

結果共有への各総括

各チーム毎、出て来たものは違って、技術に特化したテーブルもあれば、割と広く見られているようなテーブルにばらけました。
そういう場合は、各個人のワークになってたり独壇場になっている場合が多いのですが、すぐ目の前のこと(技術)とバズワード(ちょっと古い)を適当に挙げているような印象もあり、逆に言えばやらされ感が出ていたかなぁ。と。

でも、これをきっかけに自分の視界が広がるようなことにつながればいいのですが、そこまでいくかなぁ、なんて。

そんなワールドカフェの結果を総括した東サンの話を聞いていて、ほほぅ!だったので、引用します。

  • 抽象化して考えると膨らむかもしれない。たとえば、「若い人と話す」ではなく、面白い話ができるようになる、を目指すなど。
  • 大きな話になったときは、かえって、細かいところに戻るのが大事 。
    そして、それが大きな話にどうつながるかを考えるとよい。
  • サイクルがあるので、それが何週か繰り返された時に何が重要かを考えてみると、大きな流れが見えるかもしれない?!
  • 結果(五感)にすぐにたどり着いてしまったようなので、概論化する前に、具体的に過去の自分を振り返ってみると面白いかなと思う。

感想など

  • 現状維持は悪。
  • 「テクニカル に対して、ポータブル も求められる時代」という主張に対して、プログラマはテクニカルだろ、という主張との兼ね合いが難しいと思った。
    とはいえ、プログラマに求められるコミュニケーションスキルって、「人として」とか「社会人として」とかのレベルでやばげな人もいるよね。それが最低限だとして、でも新しい何かを生み出すには人が必要だと思っているので、コミュニケーションスキルはそういった面でも必要な時代になっていくと私は思いたいです。
  • 「コミュニティに来ているので(コミュニケーションスキルは)クリア」と、認められるのが新鮮でした。
    某C社の就活では、勉強会なんて何の意味があるの?と言われて、結構がっかりしたというか、そういう会社なのかと思ったので。(今思えば、ただの圧迫気味な質問でどう考えてるか聞きたいだけだったのかもなぁ・・・)
  • 環境適応能力」はたぶん私は長けてるんだけど、でも本当にそこで何がしたいかを考えて、出し惜しみするスキルも必要なんだなと思い直せて良かった。

ブレスト祭

DevLOVExhcd value協同開催のイベントに参加してきました。
当日のスライド

30~40名程度のブレストのワークショップです。
「学びを実感するにはどうしたらいいか」がテーマで、2人でブレスト、3人でブレストを行った後に、いいもの!をバージョンアップするワークをしました。

以前、参加したはてブ主催のスタートアップセミナー(2012年1月開催)で見たものと内容が似てました(後で石井さんに聴いたところ、石井サンのアイデアを元に、はてブが自社用にカスタマイズしたものだということ!世の中狭い!?)

そのワークでは、いいアイデアは上位20%に偏る、ということで、個人が考えたアイデアを会場内に公開して、☆を付けていってもらい、☆10個以上集まったテーマに対して、人気投票(どれを深堀したいか)を考えることになりました。

以下、面白そうだなと思ったテーマ

  • 定期的に繰り返される勉強会
  • 勉強会のブログなどを公開したときに、たとえば講演者から添削される(そこは意図してません、とコメントに書くと公開処刑になってしまうので)また、付箋などで、具体的な箇所に指摘できる。
  • 勉強会同窓会(数ヶ月後に再度集まったときに学びを活かせているか話し合う。男性女性セットにして、ちゃんと勉強してたら来れるとゆう特権をつけてみるなど
  • なでなで機能、指定した人になでなでしてもらえる。

私のテーマ:大人のキッザニア
参考サイト:キッザニア東京

私が大学時代の頃は、キッザニア東京は無くて、海外にしかありませんでした。紹介ムービーを観た時は、もうカナダ行くしかないな!と思った事を覚えています。前々からずっと、人生面白いんだぜ!をテーマに気づきや発見が得られるような機会を提供したいという気持ちがあるんですよね。

私は、むしろ、別の職業観を通して、自分の職業を振り返った時に、新しい発見があるんじゃないか?という意味でキッザニアを打ち出したんですが、ブレストでアイデアが膨らみました。

ひと言で言うと、「いいとこ取り」です。

たとえば、とてもおいしいコーヒーの淹れ方を教えてくれるセッションがあったとします。本職だとそれ以外の仕事もたくさん入ってくるわけですが、その道専門の人に、まさに技の部分だけ味わえる、と。会社員は8割?が雑用とかゆう一節もあるので、本職にフォーカスできる環境って貴重。また、飽きさせない工夫として、セッションは月毎に変える、マスター制度(講座ごとにポイント的な)を取り入れる、など、実際に行ってみたいと思えるようなレベルまで持っていくことができました。

ただ純粋に、プログラマに特定して、職種ごと、言語ごとでセッション開くのもありかとは思ったんですが・・・。だっていわゆるIT標準にある支軸を間近に体験することなく、選べやーって言われてる人って多いのではないかなと思うわけです。(私だけかな)そんな状態で、35歳迎えたら、本当に定年になっちゃうと思うわけですよね。

さ、話がずれたところで、元に戻しますと、このあと、本当は全チーム成果発表といきたいところが時間の都合で・・・終了

その後、石井先生のQ&Aコーナに移り、「今日はとても早口で説明したけど、普段はこんなスピードありえない。みんなのモチベーションが高いからできたことだ」とお褒めのコトバを頂きました!

いやー、楽しかった。で、終わらせない様に、すぐに使えるツールとして手元にストックしておきたいと思います。ぬーん。

アジャイルサムライ DevLOVE道場 #5 飛翔

今日が7ヶ月に渡る道場の締め日となりました。

ちゃんと作り上げたかったのですが、実際は全く形に成らず・・・。

第5回目を踏まえて、改めて、なんでだろう?と考えてみました。

当日は西村さんと角谷さんがいらして、
発表を聞いてもらえ質問に答えて頂き、ワールドカフェでは対談し、
懇親会でもお話しでき・・・と、疑問を解決する場としてはかなり
成り立っていたなぁと。(さすがDevLOVEクオリティ)

その中で印象的だったことをいくつか挙げておきます。

・開発メンバは最低限同じ場所にいる必要がある。

・インセプションデッキはキレイに創る必要は無い。

・あの形を守るのではなく、何を考えるかを決めておくのが大事。

この辺りは前提からくつがえされたなというのが苦笑pointでもあるんですが、コミュニケーションツール検討や、応答までの時間ロス、度重なるオフラインミーティングを続けた結果、アジャイルって意外と時間がかかるじゃないかー、大変やないかーと背負い込むことが多かったかなと。

「いったいいつになったら作り始めるんだろうか?」
「何が早いんだ?」

と、思ってしまい、ちょっと現実的にとらえるのが難しくなってもいました。そうやって考えてしまうために、モチベーションが下がって行ったのかもです。

つまり、これはあくまでワークショップであって現実には即さないんじゃないかと。

でも、そうじゃなかったんですよ。

「実際にインセプションデッキは使っています」

全然理解できなかったのは、全然扱い方が間違っていたから。

つまり、

私は、ウォーターフォールに慣れ親しみ過ぎていたということです。

どうでもいいドキュメントに時間を使ってしまう性質がこびりついていたのです。

懇親会で、角谷サンと「Ajileは開発者を幸せにしますか」という話をしたときに、「幸せってなんですか?」と逆に質問されてしまったのですが、不幸せな点から考えると、不要なドキュメントにかける大量の時間は、プログラミングの時間を奪います。納品作業は私にとって、苦痛です。

そのうえ、「このドキュメントどうせ見ないし」って分かっているようなものを罫線がどうとか訂正するの、かなり死にたくなります。だって見ないもん。いっそのこと、バグってると言われたら、「詳細設計書見てから教えて下さい」なんてこと、言えるわけないし。そんなネゴ取れるかっつーの。

他に、「ドキュメントも作成するか選んでもらう」という手法はレガシー組織にとっても有効なんじゃないかなと思いました。

機能を追加するか、
読まないドキュメントを作成するか、
いずれか、です。

とにもかくにも、このドキュメント命な私に気づけたのが、最大の成果かなと思います。

システムはもっと簡単に創れる。→ 不足、誤解されがち
必要なところに力をかけよう。→ 正解

私にとっては、この図式を腹落ちさせるのが、この道場だったんじゃないかと思いました。

「現場に対して、今後アクションをするのは、このワークショップよりはるかに難しい。でも、この道場で出逢ったみんなは同じ状況にいるのだから、門下生として相談していけばいいじゃないか」

という言葉を胸に、それぞれ現場で飛翔していきましょう。
お疲れさまでした。

togetter
http://togetter.com/li/248786

アジャイルサムライDevLOVE道場 第三回

本日は、オラクルで開催しました。

当日の資料はこちら。

仕事で遅れてしまい、浦島太郎状態でしたが、
なんとかメンバーの方にフォローいただき、やんややんやしてきました。

この内容は『アジャイルサムライ』本編には出てきませんが、
実際に製造に入る上では考える必要があります。

タスク分割の中で、

 スプリント0:開発環境
 スプリント1:優先順位の高い仕事

を決めました。ユーザーストーリーを前回で作りましたが、
開発環境に関しては、 ストーリーになっていませんでした。

よって、「タスク外」です。

でも、実際は環境構築をしなきゃいけないし、リリースしなきゃいけない。
フレームワークの制限を受けるかもしれないし、そもそも実装できないかもしれない。

タスク分割というのは、1タスクを0.5〜4時間ぐらいで分散していきます。
1日の工数が8ではなく、4だったのが印象的でした。
ついつい、5人日=40時間と考えてしまいがちですが、
実際に1日で働いている時間は、4時間程度にしたほうがいいという考えです。

これで組んで行けば見積もりに対して大幅に遅れることはないと思いました。
また、そのあとに出てくるバーンダウンチャートは、成果に対してコミットメントし、
かかった時間については評価しないそうです。

これってすごく精神的に優しい!
やっぱり「あいつだめだな」フラグを立てて行くよりずっと効果的でしょう。

だって、そんなことされて前向きな気持ちになれますか?
あたし、えむじゃねーし。

ってことで、アジャイル取り入れてゆきたいのれす!

アジャイルサムライDevLOVE道場 第二回 発展

ほぼ一年後に振り返ってるので、詳細を知りたい場合は、まとめ職人の下記ブログを参照ください。

アジャイルサムライ DevLOVE道場 『第二回 発展』に参加してきた #agilesamurai #devlove

振り返り

当日のノートがあったので、それを元に考えてみようと思います。

確か、当日は遅れて参加してしまった気がしまいました・・・。

INVEST〔p111参照〕

Independent(独立している)
Negotiable(交渉の余地がある)
Valuable(価値のある)
Estimable(見積もり可能)
Size Light(程よい大きさ)
Testable (テストでける)

Estimableはスペルミスではなく、あえて使ってると聞いたのは記憶にあります。

講義の後は、ユーザーストーリをカードに書き落とすワークショップに入ります。

Card〔p119, p187参照〕

表:ストーリー(テンプレート)
裏:制約(受け入れ基準(見積もり、タスク分配)、制約、気になる事))

を書くのですが、いきなりカードにすることには抵抗があったので、いつも通り?付箋にひたすら書いていきました。ストーリーをずらずらと、それに対して、制約があれば、ストーリー付箋に対して追加していきます。そいえば、図は全然書きませんでした。(それで後々、個々のイメージが合ってない事にオノノクわけですが・・・)

このとき、ストーリーが以下の通りになっているか注意する必要があります。

お客さんがワクワクするようなストーリーを書こう!〔p108〕

ついつい実装よりの話になってしまいがちなんですが、そうではなくて、「ログインできる」とか動作が分かりやすい内容が求められます。(って、これじゃ全然ワクワクしないけど・・・)

合わせて、見積もりも行います。
また、付箋の内容も、カードに書き写していきます。(時間足りなくてできなかったけど)

このとき、はじめてプランニングポーカーを触りました。それぞれが思うタスクの大きさを「いっせーのせ!」で出して、結果が違ったらそれについて討論するやつです。その後、見積もりを何度かしたことがあるけど、「あいつが適当に見積もったせいで今デスマなんだぜ」的な話を聞いたこともあるので、こーゆーみんなで決めましょうツールがあると、平和でいいですねwと思います。なかなか難しいのかな。

と、本日もモリモリ頑張りましたー。プランニングポーカーは、実はこの後の懇親会で、@haradakiroさんに頂くことになりました!めっちゃ嬉しい。そうだ、Agile girlsを作る話をしたのだった。nawoto_girlsじゃなしにw

引用元

アジャイルサムライ−達人開発者への道−

著者/Jonathan Rasmusson
監訳/西村 直人・角谷信太郎

4274068560
オーム社
2011-07-16
売り上げランキング : 1120

アジャイルサムライ DevLOVE道場 第一回萌芽

アジャイルサムライ バナー

 

 

コクチーズで募集していたので、参加してきました。

現在、各地で開かれている『アジャイルサムライ』を使った勉強会になります。

DevLOVEバージョンでは、実際にやってみよう!
が、メインテーマになっています。

第一回では、第1章〜第5章までを扱い、インセプションデッキの作成を行いました。
本は読んで来ている事を前提に、いきなり実践編です。

手元には、内容をざっくりまとめたパワポ資料が配布されます。
司会者の号令のもと、挨拶後すぐにチームでの作業が始まりました!

まずは、何を作るのかを10分間で決めます。
今後しばらくつきあうPJがまさかの10分で決まるわけですが、
普段プログラムに慣れ親しんでるだけあって、
欲しいアプリは身近にあったみたいです。

意外と一人一ネタはすんなりと出せました。

続きまして、前半戦(30分)では、第4章の内容を 扱います。
うちのチームでは、付箋を使ってそれぞれ考えて行きました。

付箋のいいところは、取り返しや変更が用意なのと、
順番を自由に入れ替えられる自由さですね。

01. 我々はなぜここにいるのか?
 〜何を果たすためにこのチームが、
  プロジェクトが発足されたのか〜

プロジェクトが発足されるにあたって、現状の満たすべき問題点を洗い出します。

P> そもそもこの命題の意味を理解してなかった。
T> それぞれの課題の内容を人に伝えられるレベルで理解しておく。 

02. エレベーターピッチ
 〜エレベータートークのPJバージョン〜

01と近かったので、割と簡単に埋めることができた。
30秒で簡潔にすべてを表現させる。
それぞれフォーマットに沿って、空欄を何にするか検討していきました。

K> 時間がかかりそうなところは適宜飛ばして時間を有意義に使った。

03. パッケージデザイン
 〜PJを簡潔に表すキャッチ、イメージ、売り文句 〜

P> イメージを作るに当たって、らくがき帳を用意したほうがよかった。 

04. やらないことリスト
 〜何に注力するか、逆に諦める事は何か見極める〜

割と出しやすかったが、機能面に特出していた。
技術面などトータルに考える視点が必要。

K> 付箋は自由に並べ替えが効くのでとても役に立った。
K> 少し突き放して冷静に場をとらえる。
P> 機能面にとらわれすぎていた。 
T> 広い視点でとらえる。 

05. 「ご近所さん」を探せ
 〜プロジェクトコミュニティを考える〜

プロジェクトではないので、一番イメージしづらかった。
実際の利用者などを細分化して考えてしまった。

P> 今回の作業では必要なければ理由を述べて適当に止める。
T> 本を熟読する。

おつかれさまでした・・・。

会場の雰囲気
続いて後半戦(30分)です。

06. 解決案を描く
 〜アーキテクチャの構成図を描く〜

P> もっとシステム考えておきたかったところだが、
それぞれ外部情報を取り込むサービスを作る予定だったため、
それらAPIの情報を既存知識に持っていなかったため、うまくいかなかった。 
T> 作りたいものに対して、必要な知識を常に考えるようにする。 

07. 夜も眠れない問題
 〜 取り込む値打ちのあるタスクを見極める〜

検討して行く間に、それは本当に優先順位が高いのか?
疑問になるような課題も上がっていった。
それぞれの基本知識や思考の方向も見られるチャンスにもなる。

 K> 異論はためらわずに唱える。同時に、代替案も出す。
(否定だけは簡単。かつ否定だけだと異論も起こりがち)

08. 期間を見極める
 〜ざっくりしたタイムライン〜

そもそもの期間が短いので、現実を見極めるには良かった。
機能はできるだけ縮小する必要があるが、その割にやりたいことがいっぱいあった。

EUとPGを兼ねてみる面白さがあるかも。

09. 何を諦めるのか
 〜トレードオフスライダー〜

これも、実際のPJであれば、本気で考えなければいけないところだが、
今回では諦めるところが明確だったので、あまり実践できた気がしない。

時間は限られ、予算は0で、品質はある程度諦める、
スコープは、その時々・・・

10. 何がどれだけ必要か
 〜何人?何ヶ月?おいくら?〜 

これは、09を考えるにあたって、算出していたので、
数字として書き出すだけだった。
具体的な数字を前にして、現実が見えた。

合間、合間に各チームの発表を挟んで、リアルタイムで進んで行きました。
活気溢れ、珍しく一体感を覚えられる勉強会でした。

こんなところで今回は終了です。
次回はユーザーストーリーを見極めて行くそうです。

本日もおつかれさまでした〜。

打ち上げ