2012年7月23日月曜日

Agile Conference Tokyo 2012 『【事例】エンタープライズアジャイル開発における組織と顧客の役割 』ノート

2012/07/19に開催された、Agile Conference Tokyoの講演『【事例】エンタープライズアジャイル開発における組織と顧客の役割 』のノートです。




目次

◆講演について

◇はじめに

◇アジャイルをスケールアップさせるにはどうしたらよいのか?

◇今日もって帰ってもらいたいヒント


◆我々がやっているプロセス : Conversation

◇Conversationの流れ

◇Conversationのポイント
  • 仕事についての学び
  • 仕事をブレークダウン
  • 優先順位付けされたバックログ
  • チーム構築
  • 価値を届ける

◆導入の事例 : マネージャへ

◇概要

◇ゲストスピーカー


◇作業のブレークダウン

◇優先順位付け

◇フィーチャーチーム

◇その他やったこと


◆導入の事例 : チームへ

◇質問を集める

◇キックオフミーティング

◇キックオフミーティングから学んだこと
  • 透明性
  • 何ではなく何故
  • 引き継ぎ
◇イテレーション1

◇まとめ


◆質疑応答




ノート

◆講演について

◇はじめに

組織がアジャイルになっていくプロセスを考えたとき、アジャイル的なやり方・慣行を行ってアジャイルにしていく場合が多いと思います。

しかし、アジャイル的なやり方・慣行は非常に沢山あります。

「1つの会社をアジャイル化するぞ!」というときにはそれだけの考えが必要であるということです。

「これを大企業でやった場合どうなるか?」という事例を今日は見せます。


◇アジャイルをスケールアップさせるにはどうしたらよいのか?


一度に全てやるのではなく、少しずつやるのがよいでしょう。

"Concept to cash"(すぐに何かを出して認証してもらう)という言葉があります。

"Window of change"(変化で生じる差)という言葉があります。

一度にやるわけではありませんが、変化をきちんと見せていくことが大事です。

変化はスケーラブルでなければいけません。

メンバーはそれに合わせて動けないといけません。


◇今日もって帰ってもらいたいヒント

シングルバックログを作りましょう。会社・ビジネスユニット・チームで使える単一のバックログです。

チームメンバーがころころ変わらないようにしましょう。同じチームで違う仕事に入っていくということです。

安定したチームが存在し、その中にある障壁をマネージャが解決していく、というやり方にしましょう。

また、スケーラブルでなければいけないということを考慮した場合、ミニマルなプラクティス、慣行を決めなければいけなません。

そして、これは忘れてはいけないことですが …

チームはいつもアジャイルでないといけません。

意思決定はチームがしなければいけません

(ここでいうチームには百人単位のビジネスユニットなども含みます)。



◆我々がやっていること : Conversation

◇Conversationの流れ

1. まず、作業そのものが入ってきます


2. study demand and need

それについて学習・勉強します


3. work breakdown

細かく分けます。作る側・発注側それぞれに分かるようにしながら作業を進めていきます


4. work prioritisation

優先順位を決めます。まずは一番価値があって時間がかからないもの。それから、その次を考えます

・一番優先順位が高いものは?
・その次にしなければいけないことは?


5. work distribution

次は取り決め。どのチームが成果物を持ってくるかを決めます


6. taem construct

取り決めがはっきりしたら、どのようなスキルセットを持つ人材が必要かを考えて人を集めます


7. doing the work

実際にやります


8. poissible vakue delivered

検証し、最初に戻ります


◇Conversationのポイント

・仕事についての学び

どのような作業が入ってくるかを知っておきましょう。

これが分からないと、そのたびに「あれを変えないと!」とばたばたして効率がよくないのです。

例えば、どんなことをしてほしいという要求をボードに貼り付けておきましょう。そうやって誰が見ても一目瞭然になります。


・仕事をブレークダウン

どんなに細かいものに分割しても、それはカスタマーに何らかの価値があるものでなければいけません。

一番最初は情報がないかもしれません。でも作業をしていくうちに明らかになっていきます。

見切り発車でも始めることがポイントです。

何度も何度も確認することができるので、何か全てが集まるまで待つよりリスクは全然少ないのです。


・優先順位付けされたバックログ

バックログ項目が小さくなっていることがポイントです。

優先順位つけのための共通のメソッドを決め、優先順位別に作業をソートします。

このとき、ベースラインが何かということを把握しておきましょう。

そうすれば、ベースラインを超えたか下回ったかを図ることができます。


・チーム構築

我々が作りたいのはフィーチャーチームであって、コンポーネントチームではありません。

フィーチャーチームは様々なものを取り入れて作業できます。

コンポーネントチームには特定のことしかできないという弱点があります。

フィーチャーチームなら会社全体が何かを学んでいることになります。

なお、作業によってはスペシャリストをプラスアルファとして加える必要があるかもしれません。


・価値を届ける

成果物を少しずつ顧客にわたし、どのような価値が実現できているか検証しましょう。

どのようになされたか、どのようなアジャイルの慣行が使われたか。

それから、デプロイやリリースがどのようになされたか(継続的なデプロイやリリース)。

最後に、提供したものがお客の望むものだったかを検証します。



◆導入の事例 : マネージャへ


◇概要

9人で5日間のワークショップを行い、『Conversation』について話し合いました。

まず講義。そのあとにはハンズオン。昼食時間にゲストスピーカー(過去に研修を受けた人)を呼びました。


◇ゲストスピーカー

ゲストスピーカーを呼んだことは重要でした。

参加者にはアジャイルへの温度差・経験の差があったからです。

さらに、実際の作業がどのように行われているかの理解についても個人差がありました。

ゲストスピーカーの時間は、何を達成したいのかを共有するためのよい時間になりました。


◇作業のブレークダウン

お客様によって異なる入ってくる作業を細かく分割しました(Work Break Down)。

この作業を更に細かくするにはどうしたらよいでしょうか?

受け入れ基準(許可)のレベル(Acceptance criteria)が何なのかは、1つの基準になります。

また、「どこからお金が入ってきているのか?」というのは優先順位付けとは切っても切り離せません。

もっとも予算を出してくれた部門はそれだけのバリューを受け取ることができます。

お金を出したのが20%なら、もらえるリターンも20%ということです。

ただ、"お金に関係ない重要なもの"でやっていくことが重要なので、このモデル自体は将来的には変わるかもしれません。

ポートフォリオをざっくりとみるため、それぞれフィボナッチで見積もりました。最終的な見積もりはチームが行います。


◇優先順位付け


WSJF(Weighted shortest job first = 重要で時間がかからないものから)というのがあり、これを導入しました。

非常に短い会話をして、意見ではなく価値に基づいて優先順位付けをしました。


◇フィーチャーチーム

ここが最も難しい部分だといっても過言ではありません。

どのような人材、スキルセットを持った人物をチームに入れるか …これはマネージャのスキルも求められてけっこう難しいのです。

予算の関係で人を入れられないこともあります。

また、バリューという観点から見た場合、縦型の組織ではないと対応できないということも分かっています。

できるだけ多くの作業を、それが大きくても受け入れられるようなチームを作ろうと思いました。

最も希少な人材をまず振り分けてから、チーム構成を行いました。

チーム構成の際にはアジャイル的なプラクティスも入れました。



◇その他やったこと

Practice-lead(プラクティショナーみたいなもの?)というのを作り、学んだことを他のチームでも共有できるようにしました。

次のプロジェクトでも活用できるように、情報共有を行ったのです。


また、ワークショップ受講者たちの気持ちも計測しました。

「実現可能に思えるか否か」というのを視覚的なチャートで示せるようにし、毎日の研修開始前に調査しました。

初日は「いまひとつ」というのが多かったのですが、だんだん「できる」と思う人が増えています。


そのあと6週間かけて、やろうと決めたことを詳細化しました。

その後、やろうと決めたことについて、4時間のキックオフセッションをやると決めました。

キックオフセッションでは150人(パートナー・ベンダーなど全ての関係者)全員を集めて、やろうと決めたことを説明するのです。



◆導入の事例 : チームへ

◇質問を集める

キックオフに至るまでの時間、マネージャたちはがありとあらゆるものをカベに貼り付けました。

そして、その内容について質問を集めました。


◇キックオフミーティング

このミーティングの開催理由は2つあります。

・これから何が起きるかを教える
・150人という大きい規模のチームにおける懸念について聞く

なぜチェンジが必要なのか、というところから話が始まりました。

「今の状態で変わらなければ、業務に迅速に対応できない」「間違った成果物を届けている」ということについて合意に達し、「だからチェンジが必要だ」という話になりました。


次に150人にフィーチャーチームの説明をし、チームへの振り分けをしました。

それからチームビルディングのための演習をしました。

その後、各々のチーム10分ずつをマネージャが回りました。各チームはそれぞれ違った事柄についてマネージャと話をしていました。

最後はビールを飲んで、CIOのメッセージフィードを受け取りました。


◇キックオフミーティングから学んだこと

このキックオフから3つのことを学びました。

・透明性

全員が学び、何が起きているかわかることはとても大事です。


・"何"ではなく"何故"

マネージャは、誰が何をするかについては説明していましたが、何故については説明していませんでした。

だから、月曜日にマネージャはそれぞれに配属理由を説明して回らないといけませんでした。


・引き継ぎ

既に何かを手がけていて、誰かに引継ぎをしなければいけない人達は苦労していました。


→最後の2つの問題は、1日で解決しました。それだけチームの結びつきが強かったということです。


◇イテレーション1

次のことを2週間の課題としてやってもらいました。

・最初のフィーチャについてディスカバリーセッション(何が争点になるかの話合い)。

・チームに名前を付けてもらいました。

・仕事の進め方についてプランニングをしてもらいました。

・いっしょに食事に行ってもらうなど、何か楽しいことをしてもらいました。

・チームで許されることなどのグラウンドルールを決めてもらいました(ユニークな社会的契約)。

それから、その中で何を学んだかを振り返りしてもらいました。


最後にはショウケースを行いました。

顧客に『何をやったか』と『これから何をするか』を見てもらったのです。

他のチームに『何をやった』ということを発表する機会も設けました。

(ここでショウケースの写真を見せる)


fuzzyに見えるかも知れませんが …我々はこれを劇的な透過性(Hyper transparency)と呼んでいます。


◇まとめ

いわゆるアジャイル的なやり方もありますが、これだけ大きなスケールで変えるやり方もある、ということです。



◆質疑応答

Q.
たくさんのマネージャをワークショップに呼ぶよう仕向けるにはどうすればよいか?

A.
シニアマネジメントのコミットメントがあってこそ始めて実現できることではないでしょうか。

意思決定する権限が無い中間管理職(Frozen middle)からやるのは難しいのではないのではないかと考えます。

ただ、アジャイルはFrozen middleも一般の人達もやりたいと思っています。



Q.
アジャイルプロセスに積極的ではないメンバをチームに入れるべきか?

A.
大きい会社なら中にはアジャイルをやりたくない人もいるでしょう。

ただ、最初はためらっていたとしても、アジャイルのやり方で大きな成果を上げることができることがわかれば、彼らの考えはどんどん変わります。



Q.
リリース毎ににワークショップを開催したか?

A.
ワークショップはリリース毎に2時間行いました。

アジャイルでは毎日合ってミーティングを行います。

それからスプリント毎にも振り返りを行います。

そこまでやって、意識がすりあっているため、2時間で終わります。



Q.
どのくらいの期間、そのチームにかかわっていたか?

会社全体に広げるときにはチーム毎にコンサルティングしたか?

それとも途中からは社内でやってもらったのか?

A.
基本的には組織が自律するまでがゴールです。

大きい会社にはマネージャや偉い人達がたくさんいます。

9人で5日間のワークショップは彼らを呼んでたくさん行いました。

組織がアジャイルに慣れて普及していけば、フォローしなくてもうまくいけると思います。

我々は企業がアジャイルになれるインフラを提供しています。

企業毎のアジャイルでやれるようになってくれればいいと思います。











Gary O'Brien様, ThoughtWorks Inc.様, 株式会社テクノロジックアート様ありがとうございました。

2012年7月22日日曜日

Agile Conference Tokyo 2012 『21世紀型ポートフォリオ管理への変革 〜事例による従来型からビジネスアジリティへの革新方法〜』ノート

2012/07/19に開催された、Agile Conference Tokyoの基調講演 『21世紀型ポートフォリオ管理への変革 〜事例による従来型からビジネスアジリティへの革新方法〜』のノートです。



目次

20世紀のポートフォリオマネジメント vs 20世紀のポートフォリオマネジメント


◇20世紀のポートフォリオマネジメント(伝統的なやり方)
  • 伝統的なやり方で重視されているものは何か?
  • それはどのような(古い)考えに基づいているのか?
  • ソフトウェア開発には伝統的なマネジメントの考え方が残っている
  • 伝統的なやり方の一部分だけをアジャイルにして効果があるのか?

◇21世紀のポートフォリオマネジメント(リーン・アジャイルなやり方)
  • "計画"から"検証による学び"へ
  • "渋滞"から"淀みのない流れ"へ
  • "チームの頻繁な解散"から"継続することによる学びの蓄積"へ


◆結論

◇結論
  • バックログ
  • 検証による学び(validated learning)
  • ポートフォリオかんばん(Portfolio Kanban Board)
  • かんばんの重要さ

◇最後に
  • 本当のビジネスアジリティを得るために


◆質疑応答

◇質問







ノート

20世紀のポートフォリオマネジメント vs 20世紀のポートフォリオマネジメント


◇20世紀のポートフォリオマネジメント(伝統的なやり方)

・伝統的なやり方で重視されているものは何か?

伝統的なPMOはガバナンスとコンプライアンスの2つに注目している。

1. ガバナンス

ビジョン・期待される結果からプロジェクトは始まり、プロジェクトタイトルに基づいて予算・リソースが配分される。そして、予算・スケジュールの中できちんと進んでいるかどうかが監視される。

→監視はしていても、価値について見落としている場合がある。


2. コンプライアンス

 プロセスの方にばかり目がいっていて、パフォーマンスがおきざりにされている。
(きちんとプロセスをフォローし、コンプライアンスに対して監査することも重要)。

 →こういうものを重視しすぎるために、顧客が本当に欲しいものを作る路線に乗っているのかを忘れられてしまう場合がある。



…こういったものはどういうところからきているのか?



それはどのような(古い)考えに基づいているのか?

レフィングウェルは"古い考えに基づくものだが、いたるところにあった現象だ"と書いている。

そして、レフィングウェルはこの古い考え方について、次の指摘をしている。

1. widget engineering

ソフトは製造業のようなものだ、という意識からソフトウェア開発がなされている。図面を書き、それどうりに作れという考え方。


2. order-taker mentality

オーダーをとってから作るという考え方。作れといわれたものを作るというだけの考え方。プロダクトオーナーの考え方もこれに近い(プロダクトオーナー≠スクラムプロダクトオーナー)。


3. Maximize Utilization

そこにあるものを最大限使う。リソースが全て使われていないのであれば、開発でも全て使えないだろうという考え方。
盛りだくさんにしておけば、フィニッシュも盛りだくさんだよね?という考え方。


4. Control Through Milestones

どんなプロジェクトでもマイルストーンについては答えがもらえるという考え方で、マイルストーンについてチームメンバーが言い淀むことがあれば、そこを調べるというやり方。

(プロジェクトによってはマイルストーン自体が非常にファジィであるにも関わらず)。


5. We can plan a full year of projects

1年分のプラン考えることできるという考え方。きちんと計画すればそれをやり遂げることができるという妄想。

失敗する原因はプランニングそのものの何かが崩れているからなので、プランニングさえうまくやれば今年はうまくいくという考え方。


6. Just Get it done

なんでもいいからやれという考え方。
バリバリと推進するようなヒーローが必要で、その周りの人は残業で疲労困憊してしまう。


…非常に馴染み深いものばかりである。

ウォーターフォールメソッドが頭に焼き付いているとなかなかうまくいかない。チームレベルでガイダンスしても、そこから先が未知なので止まってしまうことがある。これを打破してアジャイルにいかないといけない。

レフィングウェルさんはウォーターフォールマインドセットという言葉を使っている。




・ソフトウェア開発には伝統的なマネジメントの考え方が残っている


テイラーは経営科学という世界で非常に有名な人である。

彼は、二人の作業員が一日にどれだけのタスクをこなすことができるかという実験をした。

これを基準値にしてベストプラクティス・標準時間を計るという考え方である。

これがガントチャートに転出され、それに基づいて労働者が働き、基準より早く作業ができればボーナスを出していた。

1900年代初期のやり方であり、馴染み深いやり方でもある


彼の本は翻訳され日本でもベストセラーになった。WW2が始まるまでの間、日本の産業はテイラーイズムに基づいて成り立っていた。

1948年、日本でCivil Communication Section(民間通信局)による経営講座が行われ、ドラッカー・デミングなどのマネジメントモデルが入ってきた。

1979年には松下幸之助が、自分達のマネジメントが一歩進んでいるという話をするまでになった。


しかし、このような新しいマネジメントの考え方が登場した後でも、ソフトウェア開発の世界にはテイラーイズムの考え方が残っている。

何故だろうか?

もう少し違う考え方でソフトウェア開発に挑んでもよいのではないだろうか?



・伝統的なやり方の一部分だけをアジャイルにして効果があるのか?

ウォーターフォールでもうまく言っているという人がいるかもしれない。では何故そのような変化が必要なのだろうか?。


それは"Window of Stability"がどんどん小さくなっているからだ。

一昔前なら3年後の計画でよかったが、今なら3ヶ月後のことを考えないといけない。既にウォーターフォールでは追いつけないような時代に突入している。


多くの企業がアジャイルコンピューティングを導入している。

しかし最初と最後はウォーターフォールで、間だけアジャイルというのが多い(Water-Scrum-Fall)。

このやり方にビジネスアジリティがあるのだろうか? そうではないと思う。




◇21世紀のポートフォリオマネジメント(リーン・アジャイルなやり方)


私はここで21世紀型のポートフォリオマネジメントを提案したい、


・"計画"から"検証による学び"へ


まずは詳細なビジネス計画から離脱する必要がある。これらは教養ある人が『予測しているだけにすぎないものであり、実際の学習をベースに意思決定していくのとは全く異なる。

デミングが「知識というのはインテリジェンス(知能)とは異なるといっている。つまりインテリジェンスを使うのはよいが、意思決定をするときは知識を使えといっている。

アジャイルではこれが重要視されていて、起きていることをさくさくと認識するやり方がとられている。何をやっているのか?その付加価値は何か?というのを認識しながら進めている。


計画にはもう1つ問題がある。

ときには計画通りに行くこともある。そうすると「計画通りだからうまくいっているに違いない」と考えてしまう。しかし、最後にエンドユーザーから「これでは使えない」といわれてしまう。


「それをするべきだろうか?」という考え方に変える必要がある。

実際に現場にいって検証することが大事である。

細かく検証することにより、ものすごく痛い間違いを回避することができる。


今まではProcess->Delivery, Process->Delivery, Process…というやり方を繰り返していた。

我々は、問題を解決したか、そこから何を学んだというサイクルに移っている。




・"滞留"から"淀みのない流れ"へ


フローではなくプロジェクトの滞留をマネジメントするというのがここでの考え方だ。

『たくさんインプットすればたくさんのアウトプットが出てくるという考えではなく、『たくさん終わらせる = もっと沢山終わらせられるという考え方にする必要がある。



人間はマルチタスクが下手な動物であり、グループの中でそれをやろうとするのは大変だ。


タスクがたくさんあるのもプライオリティが頻繁に移るのもよくない。

トヨタの生産システムを見れば分かる。1つ終われば次。

決してタスクがぱんぱんになっている訳ではない。


21世紀のポートフォリオマネジメントでは、優先順位を付けてことを進める。

このとき、ポリシーがあるから流れはスムーズになる。




・"チームの頻繁な解散"から"継続することによる学びの蓄積"へ


しかし、プロジェクトが大きい場合、1つ終われば次(One in one out)だけでうまくいくとは思えない。

プロジェクトの失敗は"何か広大なことを考えてしまって身動きがとれなくなる"こと。「始めてしまった、もう後戻りできない」となる。

こういう所だと、プロジェクトチームはいつの間にかバラバラにされてしまう。


しかし、我々はチームとして尊重されるべきであり、"用事があれば集まり、用事が無くなれば解散"すべきではないと考える。

学習を蓄積していったチームは、有用なメトリクスを所有する状態になる。


昔のような「わからないことはあの人が知っている」というのはよくない。チームが知っていないといけない。




◆結論


◇結論

バックログ


バックログを使い、価値と優先順位をベースに入っていくようにする。

そうすることで自由に動けるし、軌道修正もできるようになる。


価値と優先順位について、リーンコミュニティではMVPと言っている。

実際に顧客に手に届くまで、価値があるかどうかはわからない。だから「いいね」といってもらえるかどうか、少しずつ小出しにして実験する。


アジャイルではDoneの定義と継続的インテグレーション。

間違ったものを継続的にデリバリする企業があるが、それは継続的な学習がかけているということである。

私たちがパスしなければいけないテストとは、お客が価値を感じたか、お金を出したかということである。


まずそこに行って何が欲しいかを学ぶ。そうすることによってアイデアが出てくる。

それから実験してテスト。

それを継続的にデリバリする。

そしてお客からフィードバックをもらい、学習し、そしてサイクルを回す(リーンスタートアップのあれ)。




検証による学び(validated learning)


我々は「これは価値になるはず」と思い込みがちである。

そう思っているなら早く検証する、"検証による学び"というのがポイントだ。



On budget, on planningでは不十分で、お客が満足しなければアウトである。




ポートフォリオかんばん(Portfolio Kanban Board)




我々は劇的な透過性(Radical visibillity)という考えを用いている。

これは、『見えないことはリスクであり、プロジェクトの全てが見えているのであればリスクは低減できているということを意味している。



そして、劇的な透過性を得るためにポートフォリオかんばんを使っている。

ここにはチームレベルの情報が入っていて、入ってくるもの出て行くものをチームが見ることができる。また、価値が検証されてお客様に届くまでの流れも書いてある。

1. study

まずはスタディしてアイデアを出す。


2. ready

ここでは実験。acceptance, validation criteriaが重視される。

全て想定に基づいていた今までのやり方をバリデーションに変え、検証することをかなり絞る。


3. work cell

リリースに向けて動いている段階。

ワークセルの中をいっぱいにするのではなく、リミッタをかけて最小限にしている。
やっているものがほとんど終わったら次を入れる。


ブロックされている場合、一目でわかるのでディスカッションが始まる。

ここで依存関係も見ることができる。


4. release

ここではエンドユーザが試用を行う。

ほとんどのアジャイルチームはここで作業は終わり。

しかし、我々は"contenious validation learning"をしたいので…


5. 1. Pivot

もうちょっと考えが必要かな?というものはPivotにおいておく。


5. 2. Failed

失敗してしまったものはFailedというところにいれておく。

Failedも別に悪いことではない。学べればそれは大変な教材である。


5. 3. Validated


価値が検証されたものが入る。


…そしてこれはサイクルになっている。

Pivotを見ていて浮かんだアイデアは、ワークセルに入っていく。

ポートフォリオかんばんで、コンプライアンスやプロジェクトの健康状態・進捗・学びが一目瞭然に共有されるようになる。



かんばんの重要さ

かんばんは、ソフトウェア開発から戦略変更まで使うことができる。

かんばんが何故こんなに重要か?

大野耐一も言っている。「イノベーション・改革・継続的な改善を促すためにかんばんは不可欠だ」




◇最後に

本当のビジネスアジリティを得るために


20世紀のやり方というのは1890年代にさかのぼる。

このような古い考え方に固守せず、離脱しなければいけない。

本当のビジネスアジリティを得るためには、20世紀のやり方を捨てないといけない。


もうずっと続いていてしみこんだ考え方だが、これを捨てれば、顧客からのフィードバックでさくさくと開発していくことができるはず。

それは21世紀型の思考を持っているからだ。


意識を切り替えることは簡単ではないが、まずは自分達の組織からTryするということ。

得られる結果はすばらしいものばかりである。






◆質疑応答

◇質問


Q.
アイデアには優先順位をつけないといけないが、アイデアの評価というものは難しくないか?

どうやれば?


A.
それは顧客からのフィードバックによる。

エンドユーザに聞いてみるのがよい。

携わる人が会議室に篭って評価しても、それは「思う」だけのことに過ぎない。






David Joyce様, ThoughtWorks Inc.様, 株式会社テクノロジックアート様ありがとうございました。


2012年7月16日月曜日

『勉強会初心者のための勉強会(#study4bg) 2012年夏の陣』ノート


2012年7月14日に開催された『勉強会初心者のための勉強会』のノート。

(ほとんど)勉強会に参加したことがない私でしたがこの勉強会で聞いたプレゼンテーションがきっかけとなり、様々な勉強会に積極的に参加するようになりました。勉強会という場が持っているある種の"壁"を気にしないで行動できるようになったことは非常によかったし、そのための気付きを貰えたという点について非常に感謝しております。

お世話になった勉強会ということで、今回はお手伝いの方面から参加させて頂きました。


◆全体

今回のテーマにはなっていなかったのですが、質疑応答の中で「勉強会ってどうやって探すの?」という点について非常に具体的な話がありました。

  • あずK氏本勉強会の趣旨説明
  • 第3バイオリン氏:勉強会の地域性について
  • 第3バイオリン氏:グループワーク
  • 質疑応答



◆あずK

自己紹介

  • 今年独立
  • web制作やパソコン教室の先生をしている
  • エンジニアライフでコラムを書いている
  • 趣味は音ゲー



あずK :プレゼンテーション

開催のきっかけと趣旨

  • 勉強に慣れていない方でも参加しやすい勉強会を作りたかった
  • ここを踏み台にして他所の勉強会に参加してもらいたい
  • 自分で勉強会を主催できるようになってもらいたい

もっと参加しやすい勉強会があっていいんじゃないかな?というところからスタート。
他の勉強会に参加できなかった人が、「ここに来れましたよ」というところから始まって、他の勉強会に行ってもらえるようになると嬉しい。



勉強会に参加するメリット

  • 無料(安価)で参加できる
  • 独学では得にくい知識・経験談を吸収できる
  • 同じものに興味を持つものと知り合える
  • モチベーションを維持しやすい
  • 立場は参加側・運営関係なく全員フラット

など

主催する側も勉強したくて開いている。
例えば、自分は主催することに慣れていなくて、こういう場所を開催することで学んでいる。
参加する側も主催する側も対等に話しあえるのが勉強会。

だからみんな、この勉強会をきっかけに色々な勉強会に行こう!!



3バイオリン

◇自己紹介

  • 日本各地のシンポジウムに参加してレポートを書いていた
  • 旅芸人テストエンジニアと呼ばれる
  • 新潟のソフトウェアシンポジウムの実行委員長
  • 新潟で勉強会を立ち上げた



3 バイオリン :プレゼンテーション

◇勉強会コミュニティの地域性

北海道から愛知までいろいろな勉強会・シンポジウムに参加して気付いたことがある。
それは勉強会コミュニティには"地域性"があるということ。



地域性を決めるもの:地域の産業

地域によってさかんなIT産業が異なる。組み込み、エンタープライズ、ウェブ …いろいろなものがあり、必要になる知識が異なる。

つまり、その地域で盛んな産業に関する勉強会が主に開催されるということ。
新しく勉強会を開催するなら、既存の勉強会との違いを明確にすること(勉強会同士の競争がある)。

逆に言うと、盛んではない産業に関する勉強会はあんまりないということ。やろうとしても、ニーズが少なくて人を集めるのが難しいかもしれない。

ただ、決して需要がないわけではない。自分の実績から言うとやってみれば集まる。



地域性を決めるもの:県民性

(東京はともかく)それ以外の地域には、そこでずっと暮らしている人がいる。だから県民性というものが存在する。

  • 新しいもの好きor保守
  • 積極的or消極的
  • 自己主張するorしない

など

こういう点を踏まえて、勉強会の進め方やアピールの仕方を変える必要がある。

東京では若い人が多く悪ノリが通用するが、それが保守的な地域で通用するかは別。



地域性を決めるもの:参加者の年齢層

年齢が上がれば役職つきの人が増える。また、年齢で勉強会への参加目的が変わってくる傾向がある。

  • 若い人:自身のスキルアップ
  • 役職付き:チームや部署に役立つ知恵がほしい

どういう年齢層が参加しているか注意を向けてみるといいかもしれない。



◇声が聞こえない ≠ 需要が無い

新潟は需要の有無よりも、自分からやろうとする人が少ないというのがあった。

開催するときは人が集まるか不安だった。でも、開いてみると「こういうイベントを新潟でもやって欲しかった」という声が多かった。

そういう場を作れば、情熱を持っている人が集まる。それは、地域に大人しい人が多いというのとは別。

実際に声を上げてみないと分からない。とにかく声を上げてみることが大事。



◇地域で勉強会を開く

もはや大都市圏にばかり目を向ける時代は終わった。これからは地域色豊かな勉強会は増えると思っている。


例:鹿駆動勉強会



奈良は大阪・京都にすぐ出られる地域。
勉強会も大阪・京都の開催が多く、奈良から行くというのがあったのだが、「奈良県で勉強会をする機会がない、でも奈良でもやりたいよね」というところから始まり、能楽堂を借りて行った。
鹿駆動勉強会のハッシュタグがtwitterのトレンドになるくらい盛り上がった。



◇勉強会を開催するというところまで考えてほしい

自分の地元や転勤先でも勉強会を開きたいという方へ。その土地の地域性を大切にしながらその土地でしかできない勉強会を立ち上げてみてください。



◆ワークショップ:マイヤーズの三角形問題

◇問題

a, b, cという3つの変数に入っている整数を読む。それを見て以下の表示を行う。

  • 正三角形
  • 二等辺三角形
  • 不当辺三角形

このプログラムをテストするために必要な入力はどのようなものか考える。



◇ワークショップのメッセージ

  • 他の人の話や発表から気付きがあるのが勉強会の特徴であり楽しさ
  • 一人で勉強してもは気付かないことがある



質疑応答:勉強会の探し方


◇IT勉強会カレンダー

管理者が登録・管理している。ここに掲載されているものは実際に行われている勉強会の一部。


Azusaar

複数のイベントサイトをまとめて検索できるAzusaarというサービスがある。

http://azusaar.appspot.com/


  • Atnd
  • eventAtnd
  • Zusaar
  • こくちーず
  • partake
  • connpass

などのイベントサイトはAzusaarで一括で検索できる。


◇Azusaar非対応イベントサイト

こういったものは各サイトを1つ1つ調べていく必要がある。

Doorkeeper

  • Doorkeeper
  • everevo (下名追記)
  • peatix (下名追記)

など


◇twitter

自分に合う勉強会を参加している人を見つけてフォローし、そこから辿っていく。

勉強会主催者や勉強会自体のtwitter公式アカウントをフォローするのもよい(下名追記)。




質疑応答:その他

  • "開催したが無反応"みたいな状態を避けたければ、勉強会であらかじめ仲間を作っておく
  • 懇親会には参加すべき。本編以上の情報が得られるし、自分が聞きたいことが聞ける
  • 自分から声をかけてお願いすれば、自分が知りたいことを学ぶことができる
   →求めている勉強会をただただ待っても、それが開催されるかどうかなんてわからない
  • 地元以外の勉強会だと、懇親会とか早めに切り上げないといけないので大変
  • 主催者自身が教えなくてもよい。詳しい人にお願いして来てもらえばよい
  • 女性には女子用の勉強会がある(~女子部とか)







◆最後に

今回参加して印象に残ったのは、参加者の意識の高さです。開始時刻の30分前には集まっていたり、会場設営を自発的に行っていたり、勉強会開催までの待ち時間のうちに各グループ内で自己紹介を済ませていたり …今回参加した方々は、初心者であることに気後れせず、可及的速やかに興味のある勉強会へ参加するのがよいと思いました。






あずK様、第3バイオリン様、アイティメディア様、ありがとうございました。

2012年7月2日月曜日

『スタートアップデザイナーズナイト - パネルディスカッション』ノート


2012/07/02に開催された『スタートアップデザイナーズナイト』のパネルディスカッション部分のノートです。質疑応答だけを抜粋しました。あと誰が何を話したかというところで確信がないので、回答者の名前は書いていません。


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

Q.
コンセプトメイキングから入ることが多いと思う。そして、同時進行をいくつも走らせているかと思うが、気をつけることや抑えていかないといけないことは?

A.
・デザイン・サービスを作るときに、トップやチームがやりたいと思っていることがある
 →どうもって生きたいのか、どういう世界を作りたいのか?
 →どう具現化するかとか、それをどう落とすか?
・ただ単にデザインを作って終わりではない
 →思いや世界観を具現化をしたい
・ヒアリングではすり合わせを行う
 →ひとつの言葉の意味の確認をする
・言葉の意味をすり合わせることを大事にしている
 →(相手が)ふわっとした言葉を使う場合、こちらから見せて「これは(あなたの言う)かわいいですか?」とか提示する


Q.
もともとデザインをはじめたきっかけは?
また、始めたころの勉強方法は?

A.
デザイン始めたきっかけ
・まず紙媒体から入った
 →絵起こしのプロセスなどを学んだ
 →DesignRulesという本を教えてもらった
 →→テクニックベースで基本的なことが入った本
 →→→色彩とか文字の大きさの及ぼす影響や、要素にまとまりを持たせるためには?など
 →→→→これが基点になっている

A.
・デザインは人の目に触れるというところではじめた
・webをやりたい、表側の人間になりたいというところでデザイナになった
・デザイナのリンク集とか、関連している雑誌のレイアウトを真似して作るというのをひたすらやった
・真似に真似を重ねて今のスタイルになっている
・とりあえず見まくった

A.
・デザイナではないが、たくさん勉強をした
 →本は買わなかった
 →いいデザイナと仕事し、やり方・デザインの仕方をひたすら見た
 →→「なんでこうしたのだろう?」「このバランス絶妙」というのを見て勉強した
・案件によってパートナーがいて、それぞれ得意・不得意や特性がある
 →案件やデザインの方向を見て振り分けている


Q.
コミュニケーションで苦労している点は?

A.
・デザイナにテイストを話するとき
 →経営者やクライアントの想定しているテイスト
 →→それをデザイナにどこまできちんと伝えられるか?
・最初は苦労した。
 →それは噛み砕いて伝えないといけない
 →→ぜんぜん違うといわれて修正とかしていていた
 →→→日々試行錯誤だった

A.
・気をつけていることはたった一つ「デザインとコーダの意思」
 →ちょっとでもずれていると最終的なデザインがずれる
・コーダにはデータを渡すだけではなく意思を説明するようになる
 →そうしないと全く別のものになったり、細かい部分が全部変わってきてしまう
・そういうものはチームで全てすり合わせる
 →外部の人の場合はいつもより気をつけて伝える

A.
・運用段階でチームと何をするのかは、ぶれないようにしておく
 →目的意識がずれてしまうとUIやテーブル設計、仕様に影響を与えてしまう


Q.
みなさんコンセプトメイキングから入っている感じだが、製作過程や完成までの流れはどうなっているのか?

A.
・コンセプトメイキングのテクニックはいっぱいある
 →チームによって向いているものがある
・会議の場所を変えてものごとを考えるとか
 →箱根にいって温泉につかりながらとか
 →→そういう限定的な空間で時間をつめてンセプトメイキングを行う
・形にするところでは、先行するサービスやイケてるUIからペーパープロトタイピング
 →そうやって人が使う動線を定義
・それから、エンジニアが設計、デザイナがデザインを行う

A.
・コンセプト自体には全く意味がない
・ウェブサイトでコンセプトを伝えるのって非常に難しい
 →車はかっこいいとかそういうもので買う。細かいスペックなどでは買わない
 →でも、そのようなものをウェブで伝えるのは難しい
・何を伝えたいかをクライアントから聞く
 →そこからどうみせたらいいかを決める

A.
・「こういう案件で、こういうクライアントで」と説明するとき気をつけていること
 →自分がワクワクするかどうか
 →→デザイナはどんなデザインでもできるが、想像性とかが出るように説明しないといけない
 →→パートナーにも「このままじゃ面白くないとけど、こうすると…」とか
 →→→そこまで作っていかずに、中途半端に人に渡してもいいものはできない。
・ワクワクできるものを提供できるように気をつけている


Q.
受託でやっているというが、リリース後も改善で入っている?

A.
・そういう形でやろうと思う

A.
・自分がやった分は最後まで
 →ボタンの大きさとか細かいところまでやる


Q.
デザインってゴールがないけど、テストをどうしている?

A.
・自分の直感次第
 →「悪いから何かを変えないと」というところでは自分の直感しかない
 →クライアントと話あったりして変える
 →→ダメならまた変える

A.
・"対ユーザ"と"対クライアント"で見ている位置が違う
 →ちょこちょこアップデートを繰り返してユーザを飽きさせないのが重要
・ユーザを妄想するのは難しい
 →でも効果検証すると強い
 →仮説を立てデータを見て、その按配でどんどん改善を重ねる


Q.
改善のところとかどうですか?

A.
・スタートアップは公開したあとの方が重要
 →ボタンの配置や色使いとかで数字がすごく変わる
・リリース後に数字を作るのがデザインの役割
 →「データとしてこういう数字がでていて、ここが悪いからこうしたら?」とか
 →ただ修正しようではない
・声や数字を参考にしてデザイナと作る


Q.
数字の取り方は?
大手はABテストを細かくやっていると思うが、スタートアップは?

A.
・google Analyticsとかは使う
 →もっと本質的な見方は別にあると思う
 →→勉強中

A.
・ボタンの検証は難しい
 →みんな目立つように作ると思うが、目立たないことが原因ではない
 →周りのレイアウトがボタンを隠している可能性もある
 →→そこまでの流れが悪ければどれだけ目立ってもダメ
・数字を取るのは難しい
 →twitterなどの反応を見るしかない

A.
・うちもgoogle Analytics
 →細かいところ、テキストのネガポジ分析はできてない
・テキスト差し替えによるコンバージョン検証は毎日のようにやっている
 →一時間ごととかで数字を出している

A.
・Closed Betaで意見が集まって面白かった


Q.
自分自身のやり方もそうだが、そもそもデザインの知識がなくてやっている人も多いと思う。
そういうときの課題は?

A.
・ウェブ未経験だけどこうしたい、こういう技術を使いたい、という人はけっこう多い
 →それはそれでいいと思う
 →分からないから私に声がかかる
・そのもやっとしたものを形にするのが私の仕事

A.
・スタートアップは好奇心旺盛でやりたいことが多すぎる
 →多いのは良い
 →それとユーザが欲するものの中間を捜す
・やってみたいというのは現実に戻すと可能性が小さくなるものが多い
 →ユーザ目線でどうなるかをひたすらアドバイスする
 →釘が出すぎる前にアドバイスするのが自分の仕事だと思っている
・やりたいことをなるべくそぎ落とさせる
 →基盤ができてからやりたいことを追加させる
 →100あったら50に落とし、75でストップさせる
・やるのは大変
 →だけど、それを実現したり他の方法を提案するのが仕事


Q.
ユーザ系とプラン系で別れると思うが、その辺は?

A.
・ディレクターと話すときはバイアスがかからないように
 →いかに自分達を客観的に見るかを注意するように
・改善案を盛り込むとき、方向があっているかどうかをよく確認
 →声は聞いても、染まりきらないように
・バイアスがかかっていない状態で答えを見出すところに重点を置く


Q.
デザイナーとかコーダは自分で探すのか?

A.
・縁があって出会った人や紹介してもらった人と仕事をすることが多い
 →昔からデザインをお願いするならこの人、という人が何人かいる

A.
・自分に合うかどうかもある
 →それぞれ個性や得意なテイストがあると思う
 →それをどれだけ引き伸ばせるか、というのは重要


Q.
日本と海外のスタートアップのデザインが似てきていると思うが、情報集めや真似するときのスタンスは?

A.
・どうしたらローカライズできるかという視点でサービスを見る
 →基本的には文化が違うエリア
・海外の人は写真をものすごく上げるのが好き
 →いい写真があればすぐ撮り、すぐ上げたい
・向こうでやりたいなら向こうの文化にあわせてスタートアップをすべき
 →日本人的な感性相手にやるときは、日本人にあった切り口にしないといけない

A.
・アプリは似ていると思う
→webはまだまだ似つかない。
→似ていると思っているのは我々まで
・サービスを使うのが一般ユーザだと考えるとそこまでは踏み出せない
→海外のデザインを入れると違和感を感じるユーザが多い
・モバイルのUIならぜんぜん取り入れてもよい
→そこで浸透して最後にwebならよい

A.
・見たときに感じるものが日本と海外では違う
 →海外ではcoolが好まれる
 →女性向けだとかわいいを意識する必要がある
 →→でもそれは海外には伝わらない。
・デザインを見せたとき、かわいいと思ってもらえるような感覚を大事に
 →数字には出しにくいが…
・海外のデザインは好きだけど、日本では違うかなという気が


Q.
デザインセンスの磨き方。どういうサイトでインスピレーションをもらっているか?

A.
・ファッション雑誌を見ているのが多い
 →海外のデザインや海外のweb award
・日本向けに作るときはファッション雑誌を参考に
 →日本は青文字系とか赤文字系とか細分化しているのが独特
 →それは紙面にも現れていて、受けるポイントが違う
・若い子はファッショントレンドをwebに感じる人も多いと思う
 →最近のファッション雑誌を見て、トレンドを参考に

A.
・デザインセンスという言葉が好きじゃない
 →自分がセンスがいいとも思わない
・何がいいと思うのかの定義づけも難しい
 →みんな違う
・綺麗とされるウェブサイトには共通していることがある
 →それは違和感がないということ
 →→違和感を消していくとウェブサイトにピタっとはまる瞬間がある
・センスを磨くのは難しい
・横に対してそろっているとか、そういうものの組み合わせがサイトをまとめてくれる要因のひとつだと思う
・ウェブサイトを作るにあたって気をつけること
 →余白をどれだけとってつくるか
 →あとは写真のクオリティには注意
 →フォントのサイズ。フォントサイズは比例するように
 →→フォントがくずれると違和感しかない
 →→三つのフォントサイズで作るようにしている
・いろんなウェブサイトを見て、水準を上げていく
 →違和感を感じるスキルが優れていれば、綺麗といわれるウェブサイトにたどり着く

A.
・感覚を正すことだと思う
 →センスという言葉は好きじゃない
・上のデザイナさんには引き出しを増やせといわれる
 →それをいかに一般的な感性に当てはめるか?
トレンドとか日常的に触れているものをストックすることが重要


Q.
サービスを作るにあたって、自分自身のデザイナとしての役割をどう考えているか?

A.
・受託という言葉のイメージ
 →クライアントとデザイナが対等ではないと思われがち
 →→みんな並列でやるという意気込みでやるべき
・デザイナやエンジニアの提案も面白いことが多い
 →ぜんぜん違う見方の意見がでてきて、それが面白かったり、ブレイクポイントになったりする
・これからクリエイターの価値がどんどん上がっていくと思う
 →彼らの価値を発揮できるようにしたい
 →だから今のスタンスをとっているというのもある
・「なんかかっこいい」とか「いいな」というのを研ぎ澄まして仕事にいかしていくというのが面白い

A.
・デザイナとしての役割はクライアントの声を聞いて形をするということ
 →ユーザに何も考えずに記憶させることが役割
・クライアントの要望や考えは最低限の要素
 →それをいかにユーザに記憶させるかが勝負

A.
・二面性がある
 →自分対ユーザ
 →→デザイナとしてユーザにどれだけ楽しんでもらえるか
 →対チーム
 →→無言実行
 →→"チームのモチベーションを高めるためにチームが喜んでくれそうなことを無言で実行することをデザイナーは求められる"というのがある
・世界への没入感を出すのがデザイナーの役割
 →コンパスを組み立てるのが役割