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というタスクの粒度をチームで合意することが大切
◆管理コストをチームで認識を持つ

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

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

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

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

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

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

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

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

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

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

 □アジャイル→守破離


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

□朝会で共有

□アジャイルは哲学だ!