『なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い』ノート

2012/09/25に開催された『なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い』のノートです。
もっといい話をたくさん聞いていたような気がするのですが、あまり残っていないような　…メモ力をもっと高めていきたいです。


◆ウォーターフォールのコンセンサスを作りましょう

◇歴史的背景と現状
起源は1970年代に発表されたWinston Royceの論文。
ただ、これはバッチ生産のためのパラダイムのものであり、所謂ウォーターフォールではない。

Winston Royce - Managing the Development of Large Software Systems
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

◇ウォーターフォール開発プロセスの歴史
1. Winston Royce 「Managing the Development of Large Software Systems」
　→大規模ソフトウェア開発に関する論文。ウォーターフォールという言葉は使っていない。概念もだいぶ違う。ただ、ウォーターフォールはこの論文を元に開発されている。
2. 米国防総省「DOD-STD2167」
　→手戻りなしの規格がこれ。それまでは標準になるような開発プロセスがなかったので、流行った。
3. 米国防総省「MIL-STD-498」
 →ウォーターフォールがうまくいかなかったので、改めて繰り返し開発の良さを認めた。
4. CMU/SEI「Considerations for Using Agile in DoD Acquisition」
　→アジャイルを使うときの手引き

◇ロイスの論文について
・ウォーターフォールは小規模で自らが使うソフトなら充分かつ合理的
・ウォーターフォールは大規模だとうまくいかない
　→直接的には最終成果物に関わらない追加的工程が必要。
　→なければ失敗する。
　→→オーバーヘッドがあれば妥当に失敗する
　→→なければ失敗が発散する。
・壮大なプロセスを踏まないと発散する
・1回きりではうまくいかない
・反復する
・一つ前の工程に戻ることは想定内
　→それは設計が洗練される行為なので望ましい。
　→反復が局所化されない場合（2つ以上手戻りする場合）はリスクになる
　→→最後のテスト工程で出てくるのは一番まずい。
・テスト工程で明らかになると、手戻りが大きいのでなんとかしないといけない

◇リスクを限定するための5個のステップ
1. Preliminary
　→プログラムデザイン（アーキテクチャ設計）をする
2. 仕様の見える化
　→コミュニケーションの媒体（各種引継ぎのため）。品質の見える化
　→あと、結構な量のドキュメント
　→要求定義書。構想定義書。インタフェース設計書。決定仕様。テスト計画、実施結果、使い方。
3, Do It Twice
　→開発工程を2度
　→プロトタイピング
4. plan, control and monitor testing
　→工数を使うしリリース直前なので、非常にリスクがあり、注力しないといけない
　→テスト計画。進捗把握、品質コントロール
5. 顧客を巻き込む
　→アーキテクチャ設計レビュー
　→実装の設計レビュー
　→受け取り検査

◇ロイスがいいたかったこと
・大規模ソフトウェア開発には特有の課題がある
　→小さいソフトウェアの大きい版ではない
・管理強化・工程の細分化が必要
・管理のためのオーバーヘッドを認識しないといけない
・過小評価するととんでもない失敗をする

◇誤解と偏見
・手戻りあり
・失敗のリスクを限定するためのもの
・リスクに対するコストや時間の追加の必要性
・官僚的なプロセスではない

◇ウォーターフォールはなぜ支持が根強いか
・建設・インフラ開発のアナロジー
・生産工程のアナロジー
・当時は開発プロセスがなかったのでウォーターフォールでもうまくいき、成功体験になった
・水の流れはどこかに落ち着く言うメタファがあり、これが意外と強力


◆ウォーターフォールとアジャイル

◇ウォーターフォールとアジャイルの対比1
・ウォーターフォール
　→作業の分割統治（タスクを積み重ねる）
　→工程表
・アジャイル
　→成果の分割統治
　→達成すること(done)を積み重ねる
　→バックログ

◇ウォーターフォールとアジャイルの対比2
・ウォーターフォール
　→マイルストーン
　→プロジェクトコントロール
　→事前に要求の範囲とレベルを明確にし、成果物を確認
・アジャイル
　→タイムボックス
　→環境・条件の調整
　→つど状況に応じて要求の優先順位を明確にして達成を確認

◇ウォーターフォールの難点
・初期の要求がなかなか確定しない場合
・後の工程になって要求が変更になる場合
・事前よ予見しきれない技術課題
・リスク管理とその運用の難しさ
・コミュニケーションの質の悪化
・官僚的な追加作業

◇アジャイルの難点
・品質保証基準の確立
　→ウォーターフォールは履歴情報を使うことで統計的手法を利用できる
　→→工程と品質基準を結びつけることができる（結びついている）ということ
　→アジャイルはそれができない

◇ウォーターフォール開発を適用する場合
・経験豊富で予見性が高い
・再現性の高い作業の集約になっていて計画できる
・大量の単純作業で労働集約的

◇アジャイル開発を適用する場合
・小規模、少人数
・不確定要素が多く予見性が低い
・リスクが高い
・継続的に保守・拡張する場合
・探索的な試行錯誤が必要な場合


◆まとめ
・「よくわからないけど、とにかくうまくいけばいい」というのは当てものでしかないので学習効果が期待できない
・自分にとっての解決するべき問題やその前提条件を具体的に認知できれば対策は見えてくるはず


◆質疑応答
Q.
「wfのメリットが使える現場ってもうないのでは？」

A.
「あるのは事実。だけど、目指すべきではない。」


◆参加者の意見
・ゲーム業界の場合は、コンカレント型かもしれない
　→コードはアジャイルだけど
　→デザインは違う
　→→いったん決まると、大量のアーティストがキャラクタを作ったりする
・デザイナは音楽聴きながら作業したりする
・プログラム側はほとんどそういうことをしていない
　→それはプログラミングにはコミュニケーションが必要だから


◆補足

・告知・募集ページ
当日のプレゼンテーションのスライド、講演動画のURLが公開されております。
→http://agileucdja.doorkeeper.jp/events/1736

・当日のプレゼンテーションスライド

なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い from Yoichi Tamamaki

玉牧 陽一様, アジャイルUCD研究会様、ありがとうございました。

【チラシの裏】リーンスタートアップ - コンシェルジュMVPの概念を説明する

リーンスタートアップに絡めて、コンシェルジュMVPの概念を説明する

「自動販売機が無い世界で『どの街角でもジュースが売っていると皆が買う』という仮説を立てるとしよう。

これはあくまで仮説なので検証する必要があるが、その為にわざわざ自動販売機を作ることはしたくない。まだそれが顧客の価値なのかは分かってないのだし、できればお金をかけずにこの仮説を検証したい。

だからコンシェルジュMVPを使う。

具体的には、あなたが『自動販売機』と書いた箱を被って街角に立ち、実際に検証してみればよい。

そうやって実際にジュースを売ってみて手ごたえを感じたなら、それは仮説が検証できたということなので、その時に自動販売機を開発すればよい。

逆に手ごたえなんてなくて『誰も街角でジュースなんか買わない』『仮説が間違っていた』ということが分かった場合でも、かかった費用は箱の代金と人件費だけだからそんなに痛くない。

こうやって、人力で顧客価値の仮説を検証するのがコンシェルジュMVP」


本当は、顧客価値についてはもっとしっかり検証する必要があるが、あくまで概念を理解してもらうための説明なので、そこは深彫りしないことにしている。

…自動販売機の中の人ってアイデア、何かの本で読んだ気がするんだよなー。

【チラシの裏】コミュニケーションについての直近の関心

相槌とか同意とか、それが大事なことは間違いない。
でもそれは相手の話を聞いていることを表現するための手段でしかない。

それより、相槌や同意をする理由　…何故そうするのか？ということや、それが学問や実践の領域でどのように表現・理解されているか、ということについて非常に興味がある。あるいは、人間心理や精神活動・何かのコミュニケーションモデルなどの中で、相槌や同意をする理由がどのように定義され、どういう捉え方をされているのか？ということも知りたい。

『相手にどのように向かい合うか』というのは、表層的な手段を散りばめて取り繕えば済むようなものではない。だからこそ、もっとコミュニケーションの奥底にあるもっと重要な事柄を知りたいし、そうやって学びを深めていく中でコミュニケーションの持っている本当の意味について近づいていきたい。

それが座学で学ぶものなのか？というのは間違いなくあるが、座学を押さえておくことにメリットがあることもまた事実。

でもウェブを探してもいまいち情報がないんだよなー。紀伊国屋にでもいって本棚をひたすら眺めていこうか…

【チラシの裏】モチベーションという言葉について

「モチベーションって言葉の意味が人によって違っている。だから、モチベーションという言葉を使った議論は、そもそも空中戦になっている可能性がある」
といった趣旨の会話が、昨日の勉強会であった。

いろいろ思うところがあり、ググってみた。
モチベーションという言葉にはだいたい次のような意味が包含されていることが判った。

モチベーション = やる気
　　　　　　　 = 動機
　　　　　　　 = 自尊心から生まれるもの
　　　　　　　 = 意欲
　　　　　　　 = 欲求
　　　　　　　 = 欲

これらが全て（本質的には）同じものなのならば、モチベーションという言葉を使うことは対した問題にはならない。
同じではないなら、合意を作らず安易にモチベーションという言葉を使用することは、すれ違いや噛み合わなさの原因にもなりかねない。

googleの検索結果を見る限りでは、モチベーションという単語は、〇〇論や〇〇心理・あるいは自己啓発的な何か、といった考えを説明するための道具として使われていることが多かった（〇〇論と書いたのは、それがいろいろあって、全部並べるのは面倒だからだ）。

つまり、モチベーションという単語は、コンテキストによって全く定義が異なっていて、それは、それぞれが物事を捉えるアングルに基づいて好きなように再定義しているとか、あるいは自分の思った漠然とした感覚に当てはめるために字面だけ借りてくるとか、そういった使われ方の集合であるということだ。

十人十色の便利な和製英語になっていて、人それぞれのバックボーンによって意味が全く異なる可能性が高いのが、モチベーションという単語の現状なのである。

要するにオレオレモチベーションがたくさんあるということ。

なので、モチベーションについて議論する際には、その意味について合意を形成し、曖昧さを排除する必要がある。意味を明らかにせず使用してしまうことは、議論の有意義さを損なう可能性がある。

逆に言えば、コンテキストが明確であったり、意味合いについて合意が取れていたりするのであれば、モチベーションという単語を使うこと自体には全く問題がない。

『アジャイルサムライ横浜道場 特別編 パネルディスカッション』ノート

2012/09/06日に開催された『アジャイルサムライ横浜道場　特別編　パネルディスカッション』のノートです。

http://www.zusaar.com/event/355105


誰が何を発言したかというところで曖昧なところがあったので、話者の名前は全て伏せました。



◆インセプションデッキ使ったことはあるか？

◇登壇者A
・契約した段階でやることは決まるので、インセプションデッキをやったことはない
・それよりはチームビルディングをやっている
　→プロジェクトが始まったら、なぜここにいるか？をやる
　→これをやるとだんだんベクトルがあってくると思って活動を続けている

◇登壇者B
・実はアジャイルをやっていない
・アジャイルやる理由には方向づけが必要
・「とりあえず、イテレーションや振り返りをやっているからアジャイル」みたいな所も多い

◇登壇者C
・アジャイルは変化に対応すること
・アジャイルでは振り返りが一番大事だと思う
・振り返りの中から方向付けを行っている
・最初に決めたことは正しいとは思っていない
・何をやっていて何を目指すか、という方向付けは変わっていく

◇登壇者D
・結論として方向付けを失敗した
　→受託した段階で、お客様には何かしらの課題がある
　→参加したプロジェクトでは課題は明確だった
　→お客様に現状維持というところがあった
　→こちらから提案をして遂行していた
　→こちらとしての意向もあったが、そちらにはならなかった
・インセプションデッキでもなんでもよいので、お客様が抱えている問題をきちんと共有する必要がある

◇登壇者E
・チームがあって、チームである程度何を作るかが決まっている。
　→方向付けはそこでできていいる。
・インセプションデッキを作って一番盛り上がったのは、やらないことリスト
　→チームメンバーででやると考えていることがバラバラだった
　→これが方向付けになって盛り上がった

◇登壇者F
・アジャイルでやりたいという話がくる、このときに「やり始めたら上司は基本的に口を出さない」と約束する
・最初はチームはうまく回らない
　→心配になっても口は出さない
　→気になるなら私に相談しろと言う
・チームには段階がある
　→まずは期待や課題・やって欲しいこと（TiDD・タイムボックス的なもの）を伝える
　→やったら次の希望を言う
　→次に一時間面談を行う
　→→「あなたは何をやりたいか、どういう方向性をやりたいか」「こちらとして期待するものは何か」など
・そうやってチームとしてやりたいことの暗黙知をためていって、方向付けをしている


◆方向付けフェーズやお客さんの意向を探るときなど、どうしているか？

◇登壇者C
・今はご年配が使うシステムを作っている
　→そこでの使いやすさは"自分の使いやすさ"とは違う
　→想像して、ヒアリングして、ちゃんと対象の具体的なデータを集めてこないと具体的な方向性は出せない
　→→そこで手を抜くと、内側によった自分達だけが考えたシステムになってしまう
・自分達が生みだす価値が何かを考えたら、使う人をできるだけ想定するしかない
　→使うターゲットが明確なら楽

◇モデレータA
「自分は農協のシステムでタブをつけたら、それは誰も使わないと言われたことがある」

◇登壇者B
・ユーザ会社とシステム会社の偉い人で方向付けが違うことがある
　→そうすると作っても平謝りするハメになる
　→「そもそも何を作ろうか？」「何のために？」「何を効率化しようとしてたの？」というのをやらないといけない
・理解できないものに100%の頭を使うことはできない。

◇登壇者C
・大きいシステムだと全員に周知できないのが問題だと思っている
・方向をごく一部の人が握っているだけだとうまくいかない
・その齟齬を解消しようとするのがアジャイル

◇登壇者D
・お客様のほうで制度を変えようという話があって、お客・コンサル・偉い人の話は合っていた
　→でもそれぞれ方向付けは違っていたのかな？と思う


◆みんなの方向がバラバラだと気付いたときにどうしたか？

◇登壇者B
・バラバラなのは話がまとまってないから
・おなかがすいているというのが一致していても、それぞれの状態が異なる（とにかく食べたい、空腹だけど胃もたれしている…など）

◇登壇者F
・似たような状況があった
　→POはある程度の責任を持っている
　→でも彼がユーザにとって本当にいいアイデアを持っているかというと、そうではない
　→そうなるとPOに対して、いい関係を作ったりモデリングをしても答えが出ない
　→そうするとPOはしょうがないとして、エンドユーザを見つけてそこにアプローチしようとしている。
　→→でもエンドユーザは忙しい
　→→その上の人に働きかけして、デモの時間をもらったりした
　→→そうやって少しずつ関係を作っている
　→→→そうやるとチームが顧客の欲しいものについて考え始める

◇モデレータB
・そもそも人のことを知らなさ過ぎると思う
　→10年後何をしたいかとか、家族のこととか
・何でそれが問題かというと、チームを同じ方向に向けるときに全員に同じやり方ではうまくいかないから
　→「ならば、チームのことをしらないでどう働きかけるんだ？」という話になる
　→「お客はもちろんだが、チームを知るために何をしているか？」という話

◇モデレータB
・向け方はいろいろある

◇登壇者F
・強制しても向かないので、向くようにする必要がある

◇登壇者C
・人はかえられることを嫌がる。変わるようなヒントを提示しないといけない

◇登壇者F
・だから先に聞く
・そこから「そこを僕は期待している」というと喜んでもらえる
　→その人のキャリアも含めてモチベーションを上げていくことを考える

◇登壇者C
・どうしても合わない人もいると思う

◇登壇者A
・みんな人間なので、そこは信頼関係
・相手が困っていることを助け、信頼してもらうことを繰り返し、関係を築く
　→そうすると、こちらがやりたいことができるようになる

◇モデレータA
・チームにコミットしてもらい、チームとしてプロダクトにコミットしてもらわないといけない

◇モデレータC
・作るべきフェーズがとっくに終わってるのに、インセプションデッキが入って無いという話があったが…
→インセプションデッキはいつ作ってもよいもの


◆アジャイルをやると問題が早く見つかって早く対処できるという。本当に？

アジャイルで見つかるものも見つからないものもあると思うが？

◇登壇者C
・アーキテクチャの根幹に関わるようなもので、ちょうど見つからない問題があった
　→アジャイルはコミュニケーションを活発にする手段
　→→チームでは活発的になって、その中で出るような話題は見つかる
　→その隣のステークホルダー、想定しきれなかったユーザの持っている問題は見つけられない
　→→→それで酷い目にあったりする
・コンセンサスが取れていたというところで思い込みがあった
　→それはアジャイルどうこうというより対話のミス
　→そういうものはアジャイルでも取れないよ？

◇モデレータC
「その問題はなんで見つかったの？」

◇登壇者C
「リリース前に想定していたユーザに話をしたときに突っ込まれた」

◇モデレータB
「ポイントポイントでデモしてなかったんですか？
顧客プロキシにはデモしていたけど、顧客にはしていなかったってこと？」

◇登壇者C
「そう」

◇登壇者A
「前向きに捕らえたらリリース前に見つかったという話では」

◇登壇者C
「そうだけど、そのときに作ったひずみで今苦労しているという」

◇モデレータB
「アジャイルで早く見つかるものとそうでないものがある」

◇登壇者A
「今のケースは早くフィードバックを貰えたからいいのでは？」

◇モデレータB
「今のはウォーターフォールでも同じでしょ？」

◇参加者
「逆にアジャイルだからこそ見つからなかったことって？」

◇登壇者B
「アジャイルでは問題がイテレーションごとに解決される。
お客様が暗黙に期待してしまうことがある。
いつか何とかしてくれるでしょ？という」

◇モデレータB
「それはプロダクトバックログの運用ミスのような気がする」


◆参加者
「新しく機能が発生したゆえに、前の問題が出てきたことは？」

◇登壇者A
・ジャストインタイムで機能を提供していたときがあった
　→増改築の繰り返していた
　→何ヶ月かあとにアーキテクチャが破綻した

◇モデレータA
「それはじっくり設計したら回避できたパターン？」

◇登壇者A
「どこかでリファクタリングしていればどうにかなったと思うが、ある程度大きくなるとどうにもならない」

◇モデレータA
「リファクタリングしていればなんとかなった？」

◇登壇者A
「傷は浅かったと思う」

◇登壇者C
「リファクタリングし損ねたのと、アーキテクチャが破綻していたのは別」

◇モデレータA
・リファクタリングっていうのは、ご飯があふれているかきっちり詰まっているかの話でしかない
　→そこに入らないものはそもそも入らない

◇登壇者F
・今のような事例が起きたら、まずチームに問題があったのでは？と考える
　→案件やチームによって、その事態の重要度は違う
　→自己組織化が基本なので、それはチームで答えを出してもらって次に生かしてもらうようにしている
　→→要はチームの力不足
　→→本当は隣の人にも気をつけないといけなかった
　→→それはウォーターフォールでもアジャイルでも変らない
　→→ならどうして最初から考えられなかったのか？というのを促す


◆モデレータA
「チームの力で解決できると言う話であれば　…すごいチームなら何でもできる？」

◇登壇者F
・精鋭が集まればウォーターフォールでもアジャイルでも何でもできる
　→だから、問題にチームでアプローチし、チームなりに答えを出してもらう

◇登壇者D
・早くお客に見せていて気がついたことがある
　→コンサルのいうとおりに作っても、お客に「違うよ」という風に言われる
　→→コンサルの方向とお客の方向は違う
　→→アジャイルならそれを拾っていける

◇モデレータA
「実はコンサルが言っていることが正しくて、ユーザが間違っている場合があると思う。自分の中でユーザ側に倒した理由は？」

◇登壇者D
「お客様の声がすごい強かった」

◇モデレータA
「確実に地獄行きでも？」

◇登壇者D
「そこは取捨選択した」

◇モデレータB
・どのくらいの地獄かによる
→マイルドな地獄なら行かせる
→会社がやばくなるなら絶対とめる

◇モデレータD
「アジャイルかどうかと問題が早く見つかるかはあまり関係ないような気がする」

◇登壇者E
・アジャイルじゃないと「問題が見つからない」と言って隠す
　→アジャイルだと隠しようがない
・今までだと（作成中に）必要だとわかっていても、その時点ではやらなかった
→そのまま作って、使いにくくなってからやっていた
→アジャイルだとその段階で手を入れられる

◇登壇者D
・けっこう頻繁に聞けたときはあまり炎上しなかった
→結局、コミュニケーションがとれてないと駄目


◆ウォーターフォールについて

◇モデレータA
・ウォーターフォールはある時点での幸せな話
　→後で本当かどうかは誰にもわからない
・ウォーターフォールで違ったら、また滝を流せばよいだけ
　→そこでとめてしまうというのがそもそもの原因
　→→スパイラルで回せば解決するのでは？


◆ストーリーは必要になったら詳細化すればよいというが、そもそも詳細にしないと分からないことがあるよね？ということについて

◇参加者
・ユーザストーリのときは詳細に分析するなというが…
　→普通の人の場合、具体的な画面や例外ルールを見せて初めて気付いてくれることがある
　→→詳細な分析をして始めてユーザが受け答えできるという話
・詳細な分析をしてみないと、アーキテクチャに関わるような問題が見つからない場合がある
　→そこは難しい？

◇登壇者A
　→→それはリスクをどうヘッジするかと言う話
　→→→やったことがないというリスクを最優先にするか、価値を最優先にするか

◇参加者
アーキテクチャに関わるところはリスクだから最初にやろうということ

◇登壇者F
・平鍋さんが言っていたこと
　→ショートケーキを小さく作るのと同じで、アーキテクチャも本当に薄く作っていく
　→それでうまくいくのではないかと思ってやっている
　→アーキテクチャもアジャイル的に育てていっている

◇参加者
・ファウラーも「アプリもアーキテクチャも同じ人がやっていないと分厚くなる」言っていた

◇登壇者F
・チームでコミュニケーションできるようにして、横のつながりを作っている
・3週間枚に集まってアーキテクチャやフレームワークを入れていってもらっている


◆モデレータA
「アジャイルを始めるにあたっての最初の問題は？」

◇登壇者E
・ベロシティが0だった
・ストーリが大きすぎた上に、何をしたらいいのか分からない状態だった
・そこがわかってからはよくなった

◇モデレータC
「それは問題？見つかってよかったね？」という話では？


◆モデレータD
「誰も興味を持ってくれないとかは？」

◇モデレータD
・飲み会でうんというまでやるとか
・力を見せるとか
・最初から全ては使えないので一部分だけ使って効果を見せたり
・早く帰ることができるようにしたりとか

◇登壇者D
・名前で言うと拒否られるというのはあるんじゃないかな
　→アジャイルと言う名前を出さないときはよかった
　→アジャイルといった瞬間に「えー？」と言われた

◇登壇者C
・朝会が長いと言うのがある
　→チームにしゃべる人がいると長くなる
　→→個別の状況に入ったりとか
　→→→そういうときはきらないといけない

◇参加者
「それってファシリテーションの能力では？」

◇登壇者C
・そういう人がいるとわかっていても、結局長くなる
・的確な時間に収めるというのはやはり難しい

◇参加者
・朝会の問題は、毎日進捗会議をすることになってしまうということ

◇参加者
・朝会のあるある　…集まらないということが多い

◇モデレータB
・特定の人がいないと集まらないとか

◇モデレータA
・最初に席をたつ人はいつも同じとか


◆モデレータA
「振り返りとかで何かないですか？」

◇モデレータA
・問題を人に落とすというのがある
　→チームではなくて、犯人探しになるとか

◇登壇者F
・KPTがどんどんたまっていった
　→何をどうしたらいいか分からなくなったことがあった
・問題には新鮮さが必要
　→3週間前の問題なんかだんだん忘れてしまう

◇モデレータA
・賞味期限を決めて自動で捨てる人もいる

◇モデレータB
・アクションがないからそうなる
　→Doneの定義がないとなりがち

◇登壇者B
「KPTに何かアクションがとれなくて、ただの愚痴になる状況がある」

◇モデレータA
「制度と会社と仕組みのせい」というのが最初は出がち

◇モデレータB
・そういうのが多いのはもう組織の問題
・チームで拾えないものはマネージャが拾わないといけない
　→こんなこと無理だろうなと思って出てこなくなることの方が怖い

◇登壇者A
・顧客不在
・担当の方が日常業務を持っていて時間をとれないとか
・POが業務知識が薄かったり倒れたりして、来なくなったことがあった


◆そもそもアジャイルをやるスキルがない

◇？
・ペアプロでいいのでは？
・そういうのをやりたがらない文化がある

◇モデレータA
「空気を読んだり、気にしたらダメ」

◇登壇者C
・アジャイルをやるときのチームの意識を一定ラインに保たないとダレる
　→自分の中の人の規律を守らせないといけない
　→守らなかったからって明確なペナルティがあるわけではなくて、緩やかにダレていく
　→→そこでスクラムマスターが欲しいと思う。


◆モデレータB
「個人のバイオリズムもあるのでは？」

◇登壇者C
・気が乗らないとかそういう心理的なものを維持するのは本当に難しい
・でもそれができないとどんどんダレる


◆登壇者A
「だれる原因は？慣れとか？」

◇登壇者C
・自分自身のチームへの責任感をどこまで取れるか
・無理をするというのはアジャイルではない
　→確実にやれる範囲をやるというのはあるが、そこに甘えるとどんどん下がっていく


◆モデレータA
・それは期待マネジメントでは？
　→いつも真面目じゃなくていいのでは？

◇モデレータA
・これらは別
　→アジャイルやるぞ！というテンションの時のオーバーコミット的なもの、それがが落ち着いている
　→単にだれている

◇登壇者D
・ベロシティを計測していたら、見積もりも苦しまずにすむようになった

◇登壇者C
・やれる範囲の見込みがあがった

◇モデレータC
・見積もりの精度も上がった


◆モデレータA
「ベロシティって伸びてる？」

◇登壇者D
ちょっと伸びてるかもしれない

◇モデレータA
伸びてるならいい

◇登壇者D
・残業していないので、けっこう自習する時間がとれていろいろ見えてくるというのがある


◆参加者
「チームのベロシティの上がり具合というのは？」

◇登壇者C
「CI、ユニットテストを明確に意識してくれるようになった」

◇登壇者A
「もうちょっと進むとプラクティスがあるのは当たり前になる」


◆モデレータA
「お客様の変化ってありませんでした？」

◇登壇者B
・アジャイルをやったらフィードバックが早くなった
　→お客様がなんでも言うようになった
・聞き分けもよくなった
　→今まで見たいな無理押しがなくなった

◇登壇者D
・お客様とコミュニケーションを取っている
　→お互いに言いやすくなって信頼関係が築けるようになる

◇登壇者E
・メンバーが明るくなった
　→今まではもくもくとやっているだけだった
　→手が空いたら他の人を手伝ってくれるようになったり、活発になったような

◇明るくなったメンバー
・なんか明るくなったねって言われた
・「進んでこれやったらもっと楽になるのに…」というのをやるのに抵抗がなくなった
・やってもいいんだという気付きがあった

◇モデレータA
・前の会社でカスタマサポート向けの仕事をしていた
　→その仕事を何のためにやっているか、お客様の誰も知らなかった
　→お客様にプロダクトバックログを作ってもらった
　→→そうしたら、お客様が「最終的に会社の業績を良くするためには？」と考えるようになった
　→→→それはすごくよいと思った
　→→→これが最終形だと思う







アジャイルサムライ読書会 横浜道場事務局の皆様, モデレータの皆様, パネリストの皆様、ありがとうございました。

『アジャイルサムライ読書会 新宿道場#10 - トークセッション』ノート

2012/09/01に開催された『アジャイルサムライ読書会 新宿道場#10』のノート。これは前半のトークセッションです。やはり、マスターセンセイの体験から語られる言葉は一味違うというか　…私とは経験値が圧倒的に違うということを痛切に感じました。

何年か後に読み返したときに、今とはまた違った角度から読むことができれるくらいに経験を積んでいきたいと思います。



◆トークセッション

◇マスターセンセイ

・西村直人氏
・角谷信太郎氏


◇質疑応答

※「」がついている発言がマスターセンセイのものとは限りません。ご了承ください


Q. アジャイルやりたい人の転職率の高さは何か？

A. アジャイルはチーム開発。チームでないと始められない

「1人でペアプロしている時期もあった。少しずつ回りを巻き込めたが、本を読んでいるうちにもっと速いペースでやりたくなった」

「「あの人とやりたい！」か「会社を変えたい！」のどちらのパッションがあるかで行動が変わる」

「会社を変えることにパッションがある人もある。会社を変えるのはまた別のパッションということ。自分はそうではないので会社を変えた」



Q. 転職したらハッピーになれるのか？
Q. 転職してすぐにハッピーになれるのか？

A. 自分が転職したときは「アジャイルやってないよ？」といわれた

「客先常駐の仕事ばっかりだった」

「社内の勉強会、プロジェクト間での情報交換などをやっていた」

「アジャイルなプロジェクトはなかったので、アジャイルにできるところは勝手にアジャイルにして始めた。カンバンとか朝会も勝手に始めた」

「現場は少しずつよくなっていった。自分達のやり方が認められることはあったが、それでも変わらないことはあった」

「そのうち、二重にやることの限界が分かってきた。途中から「自分達で仕事を作るぞー」と集まってどうやって契約を取れるかを集まってやった」

「自分で客を取ってまで仕事をするぞ！という人が多かったので、勝算があるとは思っていた」

「売り上げのことは必ず言われる。数字さえ取れば文句は言われない」

「東京は手ぶらできたので色がなかった。自分達で開拓できた。「今までやっていた」ものがなかったのでやりやすかった」



Q. アジャイルって儲かるの？

A. あまり儲からない

「（アジャイルコーチは）いなくてもできるようにするのが仕事なので難しい」



Q. アジャイルの利点は適正なお金で働けること。儲かりすぎたらいけない。と聞いていたので安心した

A. もうちょっと儲かりたいとは思う

「食べられるかというと　…なんとか食べられる」

「もらえる額が決まっている場合、長期間働かされるのでしんどいが、アジャイルはやっただけなのでそこはよい」

「ただ、終わったらそこで終わりなので…」



Q. アジャイルってエンジニアのマインド・スキルが重要だという意識があるが？

A. チームでできるようになっていればかまわない。チームのスキルセットが偏るのはよくない

「スキル重要と呼ばれていく現場は、だいたいレベルが低い（アジャイルをやる以前で、そもそものスキルが低い）」

「お客に価値を届けるという人が多ければ価値をとどけやすい」

「今できない人もプロジェクトの中で学んでいけばいい」

「それは上の人がどれだけ関わるか。成果を出すためにどうすればいいか考えてくれれば結果が出る」

「集めてスクラムやって、だとそこそこの成果しかでない。」

「みんなにアジャイルの価値観がなくてもできる」

「最初は違っても、実際やれば化ける人がいる」」

「縦でスライスして動かすやり方を知り、今までとは違うやり方で成果が出せると気付くと変わる人いる」

「ユーザーからのフィードバックがあると、やっている方も面白く感じる」



Q. キャリアが与えられるものから自分で作るものとなってやる気が出るのか？

A. そうかもしれない

「チーム振り返ってもらうと「仕事の幅・視点が広がった」というフィードバックが多くもらえる」



Q. 与えられるものへの認識が"苦痛"から"もっとやりたいもの"へ変わるというところもあるか？

A. 何がヒットするかは人による

「押しても引いてもだめだという人もいる。絶対変わりたくない人もいるけど、それは100人に1人か2人。だいたいは（度合いはあるけど）順応できる」



Q. 仲間がいないとつらいというのがある。そこへのアドバイスは？

A. やりたい人がいるところに行くのがよいのでは？　一番お勧め！

「プロジェクトの進め方などについては話合うが、そもそも仕事をどうすべきか？ということを会社で普通に話すことはない（飲み会はともかく）。そのような会議体はないし、定例で行ったりもしない」

「言わないだけで考えている人はいる。送別会で「実は…」と切り出す人がいたりして「おいおい！遅いよ！」となることはある」



Q. 失敗談とかありますか？

A. 「なんとかうまく行ったけど、もう一回やれば（もっと）うまくいく！」というのはある。（そういう意味では）失敗ばかりしている

「お客さんの期待をコントロールし、どこまでできるか理解してもうことは重要」

「きちんと踏み込むことも重要」

「リリースにあたっての重要人物や本当の目的などのTough questionも重要」

「"安請負"や"やれると思ってた"で失敗することが多い」

「お客様から言われたことをただやれば価値になると思っていた時もあった」

「「ツールがこうしろと言っている。だからこうする」というのは駄目」

「ツールのせいにしたり、手順を強要したりするのは駄目」

「失敗をアジャイルのせいにするのはよくない。プロジェクトは1回しかないので、何かのせいにするしかないが…　でも、そういうところはアジャイルでなくても失敗する」



Q. ?

「今までの仕事のやり方とは変えていかないといけない」

「昔からある会社は（昔から）違うやり方をしているから、（変化を）やりづらくなっている。大きい組織なら少しずつ変えていくしかない。」

「組織のとしての理解・サポートが重要」

「決める人と作る人の距離を近くしないといけない」



Q. 書類を求めるような、「がちがちに作ってあるから変化に対応する必要がない」と、言っている現場にはアジャイルは向かないと思うが？

A. 「変化しない、タスクがぶれない、要求がぶれない」というのであれば無理してやらなくていい



Q.  テストが実装工程の後にあるプロジェクトの場合、テストファーストで書いていると（バグ発生率などで）困ってしまう。どうすれば？

A. 自分達が書いたテストを後工程でまとめて資料にする

「ついでに既に書いたテストを整理するのもよい」



Q. 大事な要素が後になって判明して大変なことになることがある。どうすれば？

A. わかってから着手すればよい。

「全部決めるのは難しいが一週間なら決められるよね？というのがアジャイル。先のことは難しいという話。フィックスしたものを作ればよい」

「逆はWBSの「先の話は見切ったー！」という話。でも三ヶ月後なんてわからない」

「考えたり、アイデアを出したり、というのも普通にストーリーに入れたりする。あやふやなものを細かくちぎってストーリーにするのが正しい」

「『ふわふわしたものをただ「アジャイルに」とやってもうまくいかない。ただそれはウォーターフォールでもアジャイルでも同じ」

「ユーザはストーリを書けない。それでは価値を計測することもできない。お客様のほうに説明することも大事」

「いったん小さくてもいいから決める。それに対して追加・変更を行う」

「ミニマムでも完成させれば、それは使えるものなので、そこにたいして追加・変更をもらう」

「「できません」とは言わない。「やるけど、できる量は決まっているのでどちらにしますか？」とする。それが変化に対応するということ」



Q. ?

「詳細設計が終わってドキュメントを作っても、結局やり直すことになる。引き継ぐならただ読むだけならだめで、その後ろにあるものも理解する必要があるから。「製造して」とドキュメントを渡されても、製造側は結局全部やることになる。」

「製造フェーズで全部やり直すことがあって、それを詳細要件定義と呼称したことがあった」



Q. ドキュメントをどれだけ作る？

A.  必要なものは作る

「中の人はほとんどドキュメントがいらない」

「お客などに毎日会う環境はいずれなくなる。自分達以外の誰かに引きつぐときにドキュメントを残す必要がある」

「ユーザに合わせて作る」

「全部作るかと言うとそうではなくて、減らせるものは減らせる」

「ドキュメントを書くかわりに、（動作を理解するための）スクリプトは全部作る、というやり方もある。そういう場合、こちらから自信をもって説明することが必要」



Q. 後から入ってくる人向けのドキュメントは？

A. 毎週入ってくるなら作る

「聞いたほうがドキュメントを作るのは良いプラクティス。ドキュメントができあがるので、教える側にもメリットがある」

「何が判らないのか、教える側には分からない。だから聞いた側がドキュメントを作る方がよい」



Q. その日のうちに作ってくれと言う現場があって、そういうところだとエンジニアには無限の負荷がかかる。ユーザ側から見た品質も悪い。そういう現場で人間らしい働き方をするためには？

A. まず見える化

「物凄い量の仕事が来ていることをきちんと見せる。あからさまにおかしいという状況を見せれば、口答えできる」

「退社時間や睡眠時間の見える化も有効」

「見せれば偉い人の誰かが気付く。気づかないなら、それは…」



◇その他

「イテレーションの運営の話について、アジャイルサムライの206ページにしれっと大事なことが書いてある」

「"昨日のテレビの面白いこと"と同列で"アジャイルをやりたい"では誰も信用しない。やはりパッションが必要」

「意外と学習効率って悪くて、学ぶには時間がかかることに気をつける。業務時間外に勉強会などに参加して学んでいる人と、たまたま隣の机に座っている人。使っている時間が全然違う」






西村直人様、角谷信太郎様、tmmkr様、tk0miya様、eji様、ありがとうございました。

【作成中】『ギークのターニングポイント ～『踏み出す』すべを、彼らに学ぶ～』ノート

2012年08月09日に開催された『ギークのターニングポイント』のノートです。"どのように生きるか？""そのためにどうすべきか？"というメッセージがあちこちに登場していて、（今の自分には）とてもよかったです。あと、"わくわく感""モヤモヤ感"について暗黙のコンセンサスが共有されていたのは、意外と重要だと思いました。そのような感覚に対して自覚的な行動を起こせるという点がポイントになるのでしょうか。

◆概要

◇主催 : Web Cat Studio

◇ハッシュタグ : #webcat

◇講演者

・吉岡 弘隆 氏

・武部 雄一 氏

・白石 俊平 氏

◇パネルディスカッションのテーマ

A. 踏み出したエピソード

B. エンジニアのキャリアについて

C. 仕事術について

D. スキルアップについて

E. 後援者同士で聞いてみたいこと

◆はじめに

◇キャリアについて

一般的に次の選択肢がある。

・転職

・異動

・独立

◇エンジニアのキャリアについて

エンジニアには上記キャリアの中間形態となるキャリアが存在する。

他の職種よりも選択肢が多い。

・働きながら技術のコミュニティを主宰（移動・独立）

・自分で会社をやりながら技術顧問・フェローとして複数の会社と繋がる（転職・独立）

・プロダクトやサービスを広げるためにエヴァンジェリスト、それから他のことも（移動・転職）

◇新たなキャリアを踏み出すことについて

このような選択肢を取り、実際に踏み出すのは怖い。

今日は踏み出している3人に来てもらった。

◆目的

◇次の点について持ち帰ってもらいたい

・実際踏み出してみても怖く無い

・そんなに悪くはならない

・いろいろな選択肢があることと、その現状

◇次のことについて考えてもらいたい

・踏み出すか？

・どういう風に？

・いつ？

◆吉岡弘隆氏の年表

◇学生時代

・中学生時代、夏のコンピュータ講座でアセンブラを触る

・高校生のとき、Fortran Cobol, Basic, Lisp, Algol, Pascalを試した。数千行ではなく数十行くらいのコードを書いていた

・大学は工学部に

・大学院で関係データモデルの研究。Prolog, APL, SNOBOL4など

◇1984 / DEC

・日本語版COBOL, VAX/Rdbを作った

・一年間米国に出向してRdbの国際化プロジェクトに入った

・日本語文字コード(JIS X0208:1990, X0212:1990)を作った

標準化委員会では世界中のエキスパートと友達になれる。

行けるなら行ったほうがいい。

◇1994 / Oracle

・本社に出向し、社運をかけるようなプロジェクトに関わった。めちゃくちゃ面白かった

・シリコンバレーの自由闊達の空気に触れることができ、面白かった

・1998年のNetscapeのコード公開、oss運動の始まりに立ち会った

・退社後はNetscapeのコードを見てビルドするのが楽しみだった

◇2000 / MiracleLinux

・Linuxすげーな、世の中変わると思った

・同僚に誘われて社内ベンチャーとしてはじめた

・Samba国際版, Asianuxなどを作った

・Linuxをやっていた関係でコミュニティ活動に興味を持ち、カーネル読書会を始めた

◇2009 / 楽天

・Hacker Centric Cultureを作ることがミッション

・社内SNSの推進。社内勉強会の推進

・社外の人とのコミュニケーションなど

※Hacker Centric Cultureについて

・ソフトは人が作るもの。いいソフト・サービスは素人ではなくプロ・優秀な人が作る

・プロや優秀な人達をどうやって雇う / 育てるのかという経営的な課題がある

・Hacker Centric Cultureで、良いサービスを作ったり、世界に影響を与えるサービスを作る

◇日本とインターネットの世界の常識の違い

インターネットの世界では常識だが、日本では明示的には語られていないことがある。

Google,Facebook, LinkedIn, Twitter, Pinterestなどのコーポレートカルチャーのどこかには共通して共有されているものがある。それは"安く作って高く売る"ではなく、"ハッカーが世の中を変える"というフィロソフィー。

そういうカルチャーをハッカー文化と呼ぶ。

◆武部雄一氏の年表

◇高校生時代

・授業でCOBOLを使ってIOを書いた。テストの成績がよかった。

◇地元の大手の企業（システム開発とは関係ない企業）

・研修は楽しかったが、実際の仕事はめちゃめちゃ面白くない

・決まったオペレーションをやるだけ。人間関係も楽しくない

・周囲の応援もあったが、人生を浪費したくないので一年で止めた

◇バイト

・音楽で食べていくと思い、楽器屋へ

・バイトをしながら安定した仕事を探した

◇システム開発の道へ

・給料の良いバイトを探しているとき、成績のよかったコンピュータのことを思い出した

・COBOLでの開発現場でデスマーチを経験

・リーダー、サブリーダーとして現場を引っ張った

・COBOLはエレガントなコードが書けないので、Javaを書ける言語を使っている会社へ

◇DeNA

・大規模なサービス・システムに関わって技術力の向上したい

・優秀な人達に囲まれて自分をスケールアップしたい

・面白そうな会社をいろいろ回ったが、DeNAが圧倒的に抜けていた

・開発、プロマネ、プロダクトオーナーなどいろいろ経験できた

・ソーシャルゲームが爆発的にはやって、アプリもインフラも未曾有のトラブルを経験。皆で協力してナレッジがたまり、逆にタフになった。

◇現状

・ものつくりから離れている

・エンジニアの採用と育成がミッション

◆白石俊平氏の年表

◇エンジニア時代

・IT業界に行ったのは、仕事にしないと一生パソコンを触らなさそうだから

・修羅場を乗り越えたときに自分の成長した感があり、ベンチャーを渡り歩いた

・どんどん小さい会社に行った（200人→6人→3人）

◇フリーライター

・ある本を書くという夢があり、縁があってテクニカルライターになった

・テクニカルライターは出版社から近く、本が出せた。

・Google がAPIをどんどん出していた時代で、記事を書くとたくさんはてブされた

・いろいろな企業に出入りもできて楽しかった

◇現状

・読書するエンジニアの会を主催

・HTML5のコミュニティを主宰

・Google(API)のExptert

・起業した

・ある会社の技術フェローをしている

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

吉岡

「武部さんの話を聞きたいと思ったんですよ。地域の中で（業界）一番の会社に就職して、親や親戚や地域の人には『よかったねー』といわれていたと思うんですよ。で、一年間過ごしてみて『向いていないなー』とサラリーマンで思ったとしても、止める人はそんなに多くないですよね？　そこを踏み出すきっかけを聞きたいな、思いました」

武部

「１回きりの人生の中で公開したくないな、というのがあって。とりわけ、20代から30代辺りが自分の中で築いていけるものが多いでしょう、と。『人生を振り返ったときに"あのとき変えておけば…"となるはずだ』と。そう思ったときに、そこにいると相当薄っぺらい、と。

給料は非常にいいんですよ。なんてたってボーナスが年4回出るんですから。でも見合ってないと思ったんですよ。当時18歳の俺にこんなルーチンワークやらせて、これに金払う会社ってどうなのかなー、と思って。その辺の企業の感覚も含めて釈然としなかったんです。

仕事で頑張って成果出して、みんなでチームワークを発揮して『やったぜ！』みたいな達成間は得られないな、と思って。

『働くってこんなことだっけ？』と思って、『とにかく絶対違うな』と思って、見通しは全然立っていなかったんですけど、『ここじゃないな』と思って踏み切ったんです。

当時は相当説得力がなかったと思いますけど、モヤモヤ感を拭えないまま踏み切ったんですね」

（続く）