明日のUlitimate Agilist TokyoのOpenjamで暴れてきます #uatagile
いよいよ明日（2012年11月17日土）に、Ulitimate Agilist Tokyoが開催されます。
という心躍るイベントがついに開催されます。
UATに参加する理由
私事になりますが、私自身アジャイルと出会って1年間が経ちました。
この1年間はとても密度が濃く、多くの失敗と成功の中でサービス開発の本質を追い求めてきました。もちろん答えは出ていませんが、暗闇の荒野の中で勇気を持って前に進んでいる感触を持てています。
私にとって今回のイベントはこの1年間のRetospectiveです。この1年間でどんな成長ができたのか、今年末そして来年以降どのように世界を変えるのかを考えながら参加しようと思っています。
Openjamに参戦
追記: イベントが終わったので発表資料へのリンク追加しました
私もOpenjamにてsecret base ~Jeff Pattonがくれたもの~というタイトルで発表させていただきます（表紙だけ大公開）
Jeff Pattonと私のチームが出会い、
- チームがどう変化したか？
- 彼が伝えたかったことは？
という体験にまつわる話をお話しさせていただきます。
未熟者ではありますが、登壇者の皆さんにも負けない意気込みでぶっ込んできます。
皆さんぜひ明日お会いしましょう！！
いろんな会社の若手エンジニアを収穫してきた！＠オブラブ収穫祭 #oblove
オブラブさん主催オブラブ収穫祭〜若手エンジニアの集い、実りの秋〜に参加してきました。
まずはいつもの・・・
フライングオラクルなう！ #oblove (@ 日本オラクル株式会社 本社) 4sq.com/Tn9j6q
— takao.oyobeさん (@TAKAKING22) 10月 13, 2012ギリギリ若手枠で参加中！ ： オブラブ 収穫祭 〜若手エンジニア、実りの秋〜 esminc.doorkeeper.jp/events/1746
— takao.oyobeさん (@TAKAKING22) 10月 13, 2012なぜ参加したか
主には以下の2つの視点で参加してきました。
- 同年代のエンジニアがどんな経験をしているのか
- 他社の新人教育制度はどんな感じなのか
私自身社会人4年目のエンジニア（ギリギリ若手枠：25歳前後）で、約1年前から勉強会等に参加するようになって他社の方と交流する機会が増えたのですが、自分より年上の方が圧倒的に多い印象でした。そんな時にこの会を知り、他社の同年代の人達がどんなことをしているのかのぞいてみたくなりました。
またこの4年間の間にメンター（新人教育担当）を何度かさせていただいた経験もあるのですが、他社がどのような教育を行っているのか教育側からのお話も聞けるいい機会だと思い参加しました。
参加者は若手エンジニアが過半数、教育担当者10数人、学生数人でした。
講演レポート
以下講演のポイントをまとめさせていただきます（ムラはご容赦下さい）
講演概要
- 各社新卒1〜2年目数名＆教育担当者の方の発表
- COOKPAD、paperboy & co.、DeNA 、GREE、永和システムマネジメントの順
- 井原さん（@ihara2525）
- 社長室エンジニアの方（教育側）
- 教育制度は基本的には無い
- やりたいことをやってもらうという方針
- 新人に求めることは、会社に何かをしてもらうのではなく会社を利用して何をするのか
- 遠慮は悪
- やりたいこと、得意なこと、やるべきことの重なる部分を見つける
- やる気がある人を集める
- やらせるのではなく、やりやすい環境をつくってあげること
発表スライド：How to Glow Up in COOKPAD
- 中村さん（@r7kamura）
- 2012新卒入社エンジニア
- 本人主義の中でどうやって強くなろうとしたのか
- 初日から自走、責任（本番権限）、成果
- 下手なコードを書くと全エンジニアから指摘が飛んでくる
- Githubの全てのdiffをチェックしていたらコードを書けるようになった
- 社内から得たものだけでは社内以上にはたぶんなれない
- 勉強会などの社外活動やオープンソースを通して社外からも情報を得る
- 自分自身も新しい知識（アジャイルなど）を社内で展開していく
- PM5:00を過ぎたらリファクタリングすることにしている
- 中尾さん（@shikakun）
- 2012年新卒入社デザイナー
- 大学時代に映画作り→他人とつきあうのはつらい→Web業界なら1人でも→入社
- デザイナーがいない部署に配属
- 1週間缶詰めで新人だけでサービスづくり（まめぶろ）
- サービス作りは盛り上がり、その後もコピー機の後ろでカンバン
- エンジニアに混ざってRailsを勉強
- shikakunアプリ公開中（shikakunのアカウントでTweetできちゃうアプリ）
- やってみると、誰かと一緒になにかをつくることは楽しい
- 黒瀧さん（@kurotaky）
- 2012年新卒入社エンジニア
- Nexus7を購入した際、宛名がBlack Waterfall（黒瀧）と送られてきた
- 新人研修でカスタマーサービス研修→人がサービスを使っていることを実感
- emacsを使わないと教えてくれない研修
- 一ヶ月でRailsをマスターする研修
- 社内のスーパーエンジニア達に箱詰めで教えてもらう（ドクターペッパー付）
- ひどいコードを書くとさらされる
- 問題が発生したらログを読む／エラーメッセージを読む／テストする
- サービスリリースしたらくす玉を割る文化
- 社内に意識本棚という意識が高い本が並ぶ本棚が存在
- 損失も負けじと意識本棚（お金がないので平積み）を実施中
- 後藤さん（@go_to_mo）
- 新卒2年目のエンジニア
- エンジニアを大切にする会社だと実感
- エンジニア研修をクリアしないとエンジニアになれない
- 新卒でもいい意見は採用される
- エンジニアもバリバリ企画にからむ
- 社内にすごい人がたくさんいる
- 自分よりすごい人がいないと成長が止まってしまう気がするのでいい環境
- 大事にしていることは次の3つ
- いい環境は自分でつくる
⇒うまくいく方法を自分で考える - 人のせいにしない
⇒成長しないし誰も得しない - 人にやさしく
- バイブルはリーダブルコード
リーダブルコード |
- 武部さん（@nuichi）
- 新人研修設計担当者（教育側）
- 日本でもトップレベルのエンジニア研修だと自負
- あるある一般的な研修
- 現場の負荷が高い
- チームやメンターに教育が依存してしまう
- 現場「やっぱり受け入れなきゃダメですかね？」
- DeNAの研修
- 基礎を終えましたではなく一流にする
- ポテンシャル採用なのでプログラム未経験者も多数
- 現場「待ってました！よく来てくれました！」
- 「東京大学に二度入学するよりも難しい（研修）」 via 研修担当者
- 「宇宙飛行士になる訓練よりは、少しマシ」 via 研修責任者
- ↑ざっくりな研修内容
- 研修する側が大事にすべきこと
- 育てることは生半可なことではない
- 現場がほしがる人材を育てる
- 吉川さん（@tsuyoshikawa）
- 教育側
- 社内テンプレをつかいなさいってアレ・・・orz
- メンターをつけて後はよろ！は現場の負担が大きい
- GREE Bootcamp （参考リンク）
- 基本的なGREEの開発の流れの習得
- 技術とマインドは切り離せない
- 教える側のスキルも向上させる（教える側の振り返り）
- 教育の基本は（自分が）もらったものを（後輩に）返して行くこと
- 露木さん
- 2012新卒エンジニア
- 今回が勉強会デビュー
- 入社前に思っていた会社像と大きく変化した
永和システムマネジメント
発表スライド：スキルアップ作戦
- 馬場さん（@kbaba1001）
- 2012新卒入社エンジニア
- 入社して感じていることはコードを書くスキルの向上
- Githubのpull requestに対して今週だけで146個のコメント
- 教えていただけることがありがたい
- コードを介したコミュニケーション
- 永和のGit Masterには変なコードは存在しない！
- 社内のコードを読むことで本とは別の知識を得られる
- 外部勉強会は正直めんどくさいと思っていた
- が、社内にはスーパースターばかりなので同じレベルの人とも出会えるいい機会
- 同レベルの人とのふれあいの中で教え合うことでレベルアップ
- 今の一番の課題は続けること
- 田垣さん（@akiinyo）
- 新卒2年目エンジニア
- プログラム未経験で入社
- 自分でWebアプリをつくれたらいいなーというあこがれで入社
- 入ってみるとそこは想像以上にわけのわからない世界だった
- 最初は動きそうなコードをコピペ（結局大量のコードを読むので勉強になった）
- キーワードでひたすらgrep
- おすすめは自分のPRJのコードをとにかく読むこと
- 最初は「テストを先に書くといいらしい」からスタート
- そうすると・・・実装しやすくなる、意識高いらしい
- やってみてもよくわからない、でもやる！
- 最初は仕事ができる気がしなかったけど今は少しだけ自信がついた
- pull requestするとはなまるマークやくじらさんの絵文字がもらえるようになった
- その世界の住人になりたいと思う気持ちがあれば大丈夫
- みんな受け入れてくれるし、楽しいことや嬉しいことがたくさんあった
- 諸橋さん（@moro）
- 10年目エンジニア（教育側）
- われわれはどうしてお金をもらっているのか考えることが重要
- 誰がお金をだしてくれているのか
- お金をもらうには、「ちゃんと仕事を終わらせる」「普通にやる」
- ちゃんと仕事を終わらせるにはアウトプットの意識が重要
- シンプルに議事録てアウトプット意識してもらう研修
- 報告することは自分の気持ちを伝えること
- 悪いニュースこそ早くいう
- チームであればたいていのことは解決できる
- 普通のことをふつうにやる
- 新人の子の発言「テスト書かないでどうやってコード書くんですか？」（純粋）
まとめ
大量採用への対応のために大きな仕組みづくりが求められているケースもあったり、会社の状況も様々なので教育に対する取り組みも多種多様でした。
しかしその中でも、
- どう成長してもらうかを本気で考える
- 状況によって教育も常に変化させていくこと
は共通事項のように感じました。
業界動向も最新技術も入ってくる人材も大きな流れの中で大きく変化していくため、教育もそれにあわせて変化していく必要があります。
本勉強会のように、他社のリアルな教育への取り組みとそれによる被教育者の成長を知ることができる機会はとても貴重だったように思います。
という真面目なまとめの後で個人的な感想です。
まずは同年代（よりもちょっと後輩だったかな）のエンジニアの皆さんが活き活きとなにより発表されていることが印象的でした。それを見ながら、
やっぱりプレゼンテーションはテクニックや名前じゃなくて、想いやメッセージや臨場感だのぅ。まー単純にそっちの方が好きなだけかもですが…
— takao.oyobeさん (@TAKAKING22) 10月 13, 2012なんて感じたり。
中でも個人的な今日一は、田垣さんのプレゼンでした。
プログラミング未経験で永和さんに入った新卒2年目エンジニアの女の子のお話、同じく未経験で入ったのですっげーわかるなあw（4年目だけど） #oblove
— takao.oyobeさん (@TAKAKING22) 10月 13, 2012私自身も未経験からのエンジニアスタートなので共感する点が多かったこともありますが、等身大で全力なプレゼンテーションがとってもすばらしかったです。
それにしても・・・
プログラム未経験で入った2年目の女の子が普通にTDDで実装してpull requestを送って絵文字のコメントをもらって喜ぶ永和さん恐るべしです！！
また個人的にうれしい出来事もありました。
勉強会に参加しながらまわりの後輩を連れてきたかったなーなんて思っていたのですが、
同じグループの新卒エンジニアの子を勉強会で発見！グループのエンジニアMTGで自分が行く勉強会や面白そうな勉強会をちまちま紹介していたのを見てきてくれたそう。こーゆーの嬉しいなー
— takao.oyobeさん (@TAKAKING22) 10月 13, 2012難しいことだけでなく、学びってこういう小さなところからつながっていくこともあるんですね！
My Activity
★これまでの活動まとめ（思い出したら更新予定）
2017/12/22 WEB+DB PRESS Vol.102【執筆】
- ペアプロ／モブプロ特集
2017/12/11 アジャイルひよこクラブ 結局スクラムってなんなの？日本のパイオニアから学ぶアジャイルの歴史【発表】
2017/11/18 JJUG CCC 2017 FALL【ワークショップ】
2017/11/16 ヴァル研究所ライトニング大会【発表】
2017/11/12 DevLOVE リンスタ関ヶ原 〜敗軍の将、兵を語る編〜【発表】
2017/11/8 エンタープライズアジャイル勉強会【発表】
2017/10/28 Rakuten Technology Conference2017【運営】
2017/9/16 XP祭り2017【発表】
2017/9/10 モブの宮【発表】
2017/8/25 Nu-bla Geeks Who Drink in Tokyo-Agile Team Edition-【発表】
2017/7/21 DevLOVE関西「心理的安全性」のことに思いを馳せる【発表】
2017/7/11 モブプロディスカッション【運営・発表】
2017/6/18 DevLOVE 200 Bridge【発表】
2017/5/25 アジャイルチーム未来会議【運営・発表】
2017/4/25 DevOpsDays Tokyo 2017【発表】
- モブプログラミング体験会
- 朝まで生DevOps（パネルディスカッション）
2017/1/28 DevLOVE 199 越境CON 【発表】
2017/1/12 Regional Scrum Gathering Tokyo2017【発表】
2016/11/26 プロダクトオーナー祭り2016【発表】
2016/9/24 XP祭り2016【発表】
2016/2/27 Dots Conference Spring 2016【発表】
2015/9/4 Developers Summit 2015 KANSAI【発表】
2015/6/21 Agile Samurai Base Camp【発表】
2015/2/28 Regional Scrum Gathering Tokyo 2015【発表】
- Agile ガチンコ Fight 第0試合
2015/2/27 インセプションデッキをどう作って、どう活用してる？実践事例を発表【発表】
2015/2/20 Developers Summit 2015【発表】
2014 UltimateAgileStories Iteration4【執筆】
2014/12/13 Agile Samurai Basecamp 2014 Inception Deck【発表】
2014/11/8 プレイバックDevLOVE現場甲子園【発表】
2014/11/5 俺のコードレビュー勉強会【運営・発表】
2014/10/25 Rakuten Technology Conference 2014【運営】
2013/11/9 DevLOVE現場甲子園2013【発表】
2013/11/6 変化の担い手チェンジエージェントの実践を追え！【発表】
2013/10/26 Rakuten Technology Conference 2013【運営】
2013/5/24 Agile Japan 2013【発表】
2013/2/15 Developers Summit 2013【発表】
- アジャイルサムライって当たり前になるのかな 53page〜
2013/1/16 Scrum Alliance Regional Gathering Tokyo 2013【発表】
2012/11/17 Ultimate Agilist Tokyo - 集え、日本の活動家たちよ【発表】
2012/11/3 アカリクIT企業交流セミナー【発表】
- Embrace Change - プログラム経験なしから楽天で過ごした3年間 -
2012/10/21 DevLove ゲーム・開発・UXD 情報交換会【発表】
2012/10/20 Rakuten Technology Conference 2012【運営】
2012/10/17 第8回 企業内リーンスタートアップ勉強会【記事】
- マナスリンク公式レポーター
2012/9/15 XP祭り2012
2012/9/14 サムライ・エピソード 26人のサムライ達【執筆】
2012/8/31 Agile2012 社内Feedback【発表】
2012/8/13-17 Agile2012【記事】
2012/7/19 アジャイルサムライ読書会 横浜道場 特別編 「アジャイルは組織を変えられるのか」【発表】
2012/5/21 DevLove「全員スクラムマスター。」【発表】
2012/2/末 Developers Summit 2012 FeedBack会【発表】
2011/12/10 DevLOVE HangarFlight – Snow Barrage –【発表】
2011/11/27 WordCamp Tokyo 2011【運営】
DISCOVER TO DELIVER : ユーザーの本質的価値をDISCOVER(発見)しDELIVER(届ける)する新たな方法
Agile2012で参加したセッションの中で、個人的にもヒットだったThe Product Partnership: Using Structured Conversations to Deliver Value（直訳：プロダクトとの友好的な協力関係）。セッション内容は、DISCOVER TO DELIVERという発売前の本を題材に著者であるMary GormanとEllen GottesdienerがWork Shopを行いました。
先日(2012/9/25)、ついにそのDISCOVER TO DELIVERが一般発売されたので、ご紹介させていただきます。※もちろん本は全編英語ですw
参考リンク
- DISCOVER TO DELIVER : Book Web Site ※ここから購入できます
- 著者であるEllenのBlog
About "DISCOVER TO DELIVER"
DISCOVER TO DELIVERでは、価値を見つけて届けるまでの過程をステップで説明しています。
ポイントをまとめると、
- ユーザーを中心におく
- 会話することが重要
- ストーリーやバックログ
- Discover (発見) と Deliver (届ける) を繰り返す
- 繰り返してユーザーにとっての本質的なプロダクトの価値を導きだしていく
こんな感じです。
本で紹介されているプロダクトのコンセプトや価値を探求していく各ステップは、フレームワークのような使い方ができると思います。
以下のAgile2012のセッションレポートにもありますが、ちょうどインセプションデッキとストーリーの間をカバーするような内容になっているため、プロダクトオーナーに近い仕事の方にはぜひ読んでいただきたい内容です。
（著者であるMary & Ellen with @uedayoさん）
私はセッションを受けて内容がとても面白かったので、会場内で事前販売していた本を購入しました。本は、写真の壁に貼ってあるようなイラストが多く、英語は得意でない私でもイメージがわくので読み進めることができています。
Agile2012のセッションの反響や発売後のTwitterを見ている限り、アメリカでも注目の本・手法の一つです。今後名前を聞くようになるかもしれません。
P.S.
せっかくいち早く輸入できたので、もうちょっと内容を理解して日本で紹介できるといいなーと思ってます。もしご興味がある方はぜひコメントやShareをお願いします。きっとやる気が出てきますw
Experience Visionをはじめてきた #devlove
DevLove主催のExperience Visionのはじめかたに参加してきました。
#devlove えくすぺりえんすびじょんをまなびにきたよ！ (@ 株式会社 KDDIウェブコミュニケーションズ (KDDI Web Communications Inc.) w/ 5 others) 4sq.com/Rkerem
— takao.oyobeさん (@TAKAKING22) 9月 27, 2012なぜ参加したか
ユーザーから見たら、開発もマーケティングも営業もビジネスも関係なくサービス提供者に過ぎません。
私はこれまでどちらかというと開発者としての視点でサービスづくりに携わってきましたが、最近になってようやくサービス提供者としての視点で何ができるのかを課題に感じるようになりました。
Agile・Scrum・User Story Mapping・Lean Startupなど最先端の考え方／プロセスにおいてもビジネスと開発の関係性は常に語られていますが、まだ私の中では腹落ちしていない部分があり、私のようなぺーぺーに何ができるのかを見つけるヒントを探しに参加してきました。
What is Exeperience Vision
EXPERIENCE VISIONの共著者のお一人である山崎和彦先生にご講演いただきました。
エクスペリエンス・ビジョン |
EXPERIENCE VISIONは、こんな本！！
- ビジョン提案型デザイン手法の本
- 7月に発売されたばかり
- 5年かけてWork Shopや実践をまとめられている
- すぐに実践（Work Shop）できるテンプレートがダウンロードできる
- 具体的な事例紹介入り
- 略してえびちゃんえび本 ※山崎先生公認
以下のリンクが参考になります。
講演レポート
以下ご講演のポイントをまとめさせていただきます。
詳細な内容は以下リンクを参考にして下さい。
- 当日のTime line (togetter)
- 「Experience Vison のはじめかた」に参加してきました。 (via @takigawa401さん)
- DevLOVE エクスペリエンス・ビジョンのはじめかた NAVERまとめ
What is Exeperience Vision
まずはExperience Visionの概要をご説明いただきました。
- 5年間かけてWork Shopの成果や経験をまとめたもの
- Product Designはそこら中で言われているが世界を見てもあまり教科書が無い
- 世にある多くの方法論はそれだけで世界が変わるかのように書かれがち
- 世の中にあるよい手法はなんでも取り入れて、ないものは作るスタイル
- 目の前の仕事に追われがちだが、もう少し遠くを見て本当にユーザーにとって大事なことはなにかを考えてしっかりと戦略を立てる
- プロジェクトの目標立ての部分をもう少し大事にする
- ビジョン提案型デザインの大まかなイメージ
- 人間中心設計に基づくビジョン提案型デザイン手法
- これまではユーザーへのヒアリングや要求からプロダクトを作ることが多かったが、ユーザーの価値に基づいてエンジニアやデザイナーから提案していく
- ユーザーを中心に置き、ユーザーの潜在的なニーズを形にしていく
- 一度上（価値）に登るのが特徴
- 一度上に登ることで全体を見る
- Change Gameのことを考える
- Change Game：既に効率化されている大企業と同じ土俵で戦わない
- EXPERIENCE VISIONの中で紹介されているテンプレート
- ビジネスモデル・キャンバス(※)に似ている
- 全体を見ることはできるというのはとても大事
※Business Model Generationで紹介されているフレームワーク : 参考リンク
Exeperience Visionのはじめ方
Experience Visionの中でも構造化シナリオを中心に少し掘り下げていただきました。
- 役割に関わらずビジョン提案やサービス構築に主低的に貢献することが求められている
- ユーザーにとっての本質的な価値を導きだし、そこに体験や経験を提供すること
- 結果からくる問題解決とは別に、本質的な価値にアプローチする手法
- 問題解決型デザイン
- 提案型デザイン★
- 前者はたくさん本があるのでExperience Visonでは後者に特化している
- 人間中心設計をイノベーションにもっと使って行く
- 異文化の人と一緒にやらないとイノベーションは起こせない
- 技術、マーケティング、デザイナー、ビジネス・・・いろんなストロングポイントを持った人達が協力することで何かが生まれるという発想が大事
- 基本的なアプローチ方法
- フレームワークの全体像
- 本質的欲求を理解するためのいろんな方法
- ユーザー視点とビジネス視点の二つの視点
- 仕様書はモノや動きしか書いていないが、シナリオはモノとそれをどう使うかを表す
- シナリオは日本語がわかれば誰でもわかるので、異なる役割の人達がコラボレーションする際の共通言語になる
- 理解できるということは、コラボレーションができるということ
- シナリオごとに評価を繰り返す
- リリースしてからではなくシナリオの時点でユーザーのことを考えているのかを評価
- シナリオそれぞれの種類の特徴と評価項目
- 構造化シナリオの特徴まとめ
- ユーザー視点での評価について
- それぞれのシナリオで評価のし方を変えていく
- ビジネス視点での評価について
- よくみる計画書には製品とビジネスのことしか書いていない
- どう進めるかについては戦略（担当が別だ）だと言われてしまいがちだが、それでは新しいものが生まれない
- 目標設定を高く持つことが大事
QA
QAの中のポイントだけまとめます。
Q. 調査をしているが信頼してもらえない。どう乗り越えたらよいか？
まとめ
お恥ずかしいことに「Experience Visionのはじめかた」というタイトルにかまけて予習をさぼってしまってましたが、これはちゃんと読まねばならん！とさっそく手に入れました。
えびちゃん購入 #devlove エクスペリエンス・ビジョン [楽天] r10.to/hJcBbW #rbooks twitter.com/TAKAKING22/sta…
— takao.oyobeさん (@TAKAKING22) 9月 27, 2012感想については講演中のTweetにすべて表れています。
Experience Visionまだ聴いてる途中だけど、これ最近感じていた課題の解決のヒントになる気がしてきた！かゆいところ。 #devlove
— takao.oyobeさん (@TAKAKING22) 9月 27, 2012個人的に今日の話を聞けて、Lean Startup、UX、Agile、UCDとかがつながってきた！ #devlove
— takao.oyobeさん (@TAKAKING22) 9月 27, 2012これまでいろいろなことに興味を持って勉強をして現場活動につなげてきましたが、だからこそ今回Experience Visionの話をきっかけにいろんなものがつながる想いがしました。
冒頭に書いた通り、AgileやScrumやLean Startupなど個々で足りない・腑に落ちない部分がありました。山崎先生がおっしゃったようにビジネスや開発を通して価値提供という大きな範囲でみたら、たった一つの考え方でうまくいくことは難しいです。プロセスや方法論自体も目的を達成するためにいろいろなものを素早く小さく試して評価して、いいものを組み合わせていけばよいと思います。
Experience Visionの内容についてはもちろんまだわからないところが多いです。
しかし、サービス提供者としてユーザーの本質的な価値にアプローチすることが本当に大事なことだと改めて思いました。開発やビジネスやデザイナーというユーザー視点ではない分割は忘れて、自分に何ができるのかを考えてみたいと思います。
|
エクスペリエンス・ビジョン |
まずは本を読んで素振りからはじめますか！
アジャイルとウォーターフォールについて本気出して考えてみる
なぜアジャイルなのですか？改めて考察するウォーターフォールとの違いに参加してきました。
ウォーターフォール（以下WF）はよくDisらr・・・アジャイルと比較されます。
私もアジャイル開発を知るまでそうではない開発を経験したことがありますが、おそらくそれらはWF開発をしていたわけではなく、WFのようななにかに過ぎなかったと思います。
だから、ちゃんとしたWFについても勉強したいなーと考えていたのでとてもいい機会になりました。
株式会社ジャムズを経営されている玉牧 陽一さんのご講演のポイントをまとめます。
詳細については下記SlideShareをぜひご覧ください。
WFの原点に関わる流れ
- 1970年 Managing the Development of Software Systems via Winston Royce
WFの本質が書かれている論文。 - 1985年 米国防総省の規格書「DOD-STD-2167」★
Royceの論文を参考に米国防総省がPRJの進め方をまとめた規格書。
これがWFの原点と言われている。
手戻りは絶対だめ！！と述べている。
⇒追記：手戻りがだめと明記されたのは1988年発表の2167A版（原田さんありがとうございます）
1995年のレポートで、この方法によるPRJの約75%が失敗もしくはうまく適用できずに終わっていると報告されている（※参照） - 1994年 上記の改訂版「MIL-STG-498」
繰り返し型開発 - 2010年 CMU/SEI「Considerations for Using Agile in DoD Acquisition」
アジャイルを用いた調達やこれからの導入を促す趣旨のレポート
※このあたりのことをまとめているIPAレポートがあった ので載せておきます。
米国におけるアジャイル・ソフトウェア開発の動向 via 渡辺弘美さん
WFの本質となった論文の概要
- 1970年 Managing the Development of Software Systems via Winston Royce
- 一番シンプルな開発モデル
- 小規模で自らが利用するソフトウェア開発には十分かつ合理的
- しかし大規模なシステム開発ではうまくいかない
- 実際のPRJでは追加工程が要求される（管理コストによるオーバーヘッドなど）
- 一方通行でうまくいくわけがない
- 手戻りは存在するがあくまで想定内（1つ手前の工程まで）におさめる
- 顧客を巻き込むことの大切さ
- ソフトウェア開発はシンプルなモデルのような簡単なものではない
要点まとめ：
1970年の論文だが今でも多く使われているWFの本質が述べられている。WFでは手戻りは絶対だめという風潮があるが、これはWFの原点となった「DOD-STD-2167」で手戻りはあってはいけないものとされているからである。しかし、Royceの論文では手戻りがあることを前提としていて、その手戻りを想定内におさめることが大事だ述べている。
当然この論文がそのまま開発に活かせるものではないが、それまで体系的にPRJの進め方をまとめられていなかった中で初の取り組みであった。
WFとAgile
- 問題解決 ＝ 要求、アウトプット
- 問題解決における前提的 ＝ PRJの外で決めるものでPRJの中ではStatic
- 問題解決における前提的 ＝ PRJの外で決めるものでPRJの中ではStatic
- 解決手段 ＝ 要求を満たすための方法
- 解決手段における前提的 ＝ 良い方法は既存でそこに近づける
- 解決手段における前提的 ＝ PRJの中で決めて行く
WFの難しい点
- 初期の要求がなかなか確定しない場合
- 後の工程になって要求が変更になる場合
- 事前に予見しきれない技術的課題
- リスク管理とその運用の難しさ
- コミュニケーションの質の悪化
- 官僚的な追加作業
アジャイルとWFの使い分け
要点まとめ：
アジャイルとWFはそれぞれに前提条件・向き／不向きが異なる。そのため、現状やプロジェクトの特性を正しく理解して適正をみる必要がある。
どちらがいい／悪いではなく、概念やプロセスを理解してそれを活かせるように現場現場で適用して行くことが重要である。
我々の仕事（ソフトウェア開発もアジャイル開発もWF開発も）はそんなに簡単なものではない。
スパイラルとアジャイルの違い
- スパイラルとは小さなWFの連続
- スパイラル→渦を描きながら最終的には真ん中に収束して行くイメージ
- アジャイル→ぐるぐるまわりながら中心ですら適切な場所に移動していくイメージ
- 収束を前提とするかしないかの違い
まとめ
今回の勉強会を通して感じたことは、
"WF（ウォーターフォール）とAgile"とか"WFとWFでないもの"っていうよりも、なんでもないもの大半で一部のWFとAgileって感じのイメージ。
— takao.oyobeさん (@TAKAKING22) 9月 25, 2012やっぱり神懸かり的なウォーターフォールによる成功体験は、プロジェクトマネジメント視点ではしてやったりな気がするなー
— takao.oyobeさん (@TAKAKING22) 9月 25, 2012です。
少しこのあたりの話になると盲信的に、
「アジャイル最高！」
「WFはだめだ！」
「WFでないとだめだ！」
となってしまっているケースをよく見ます。
しかし、アジャイルもWFもあくまで目的を達成するための選択肢に過ぎず、どちらがいい／悪いという議論は無意味な気がしています。
それよりも、
- 自分たち（プロジェクト、チーム、環境、状況）を理解して今何が必要なのかを見極められるようになること
- それによって結果を出すこと
こそが重要であることを忘れてはいけません。
・・・という前提で、きちんとWFできる状況を考えてみると、
- ゴールが明確であること
- 状況／環境がコントラブルであること
- プロダクトがコントラブルであること
- 要求の出し手／プロダクトの作り手が機能できること
- 関係者のコミュニケーションが良好であること
- 上記全てがPRJの終了まで継続すること
これらの条件が必要かなと思います。
うーん難易度が高い！！
でも一度はキレイに滝を滑り降りたい！！
なんて野望を胸に抱きました。
【SME26】 達人出版会よりサムライ・エピソードが発売されました
本日 2012年9月14日、達人出版会さんよりサムライエピソードが発売されました。
サムライエピソードとは、日本のアジャイラー総勢26名が現場で経験した成功・失敗を生々しく綴ったライブログとも言える一冊です。
実際の体験をリアルに綴っているので、日本のアジャイルな現場でどんな戦い（？）や修行が繰り広げられているのかを知ることができます。How To本とはまた違った気づきを得ることができるかもしれません。
今まさに現場で挑戦している方や興味を持っている方にはぜひ読んでいただきたい一冊です。
私も一つの章を執筆させていただきました。
明日のXP祭り2012で発表させていただく内容も一部含んでいますが、私も例にもれなく現場での体験をもとに書かせていただきました。
※ちなみにSME26は勝手に私が言っているだけで正式なグループ名でもなければ、どこからの劇場で活動しているわけではありません。
とりまとめをしてくださった@HIROCASTERさんが中心となって、勉強会などで有志を募って集まった26名のサムライ達です。
今回本ができあがるまではGitやFacebookを使ってやりとりをするという面白いプロセスを踏んでいたりします。
達人出版会さんなので電子書籍での販売です。
Kobo Touchなんかで見るといいんじゃないかなー（ステマ）。
【参考リンク】
電子ブック楽天＜kobo＞ kobo Touch 【販売：楽天kobo】【今なら送料無料】 |
