Scrum Boot Camp Premium 参加報告
http://www.seshop.com/product/detail/14217/
アジャイル、スクラムを机上の知識としてばかり溜め込んでいるので、実践を少しでも体感したくて参加しました。
会社ではアンオフィシャルにアジャイル言いまくってますが、ちゃんと決裁通して参加したということで少しだけオフィシャルに近づいたと思いたいところです。
アジャイルサムライ監訳者の@nawotoさん、@ryuzeeさんによる講義に、いくつかのワークショップをグループで実践して進めていく形です。
講義、ワークショップを通じて感じたことをメモ。
ちょっととりとめないです。
■わかっていなかったことがわかった
Scrumのフレームワーク、一つ一つの要素を理解していたつもりだけど、ああやって体系的に説明されながらワークショップやると、それぞれの要素の存在理由や、つながりがよくわかった気がします。
細かいことは色々あるんだけど、一番わかっていなかったことは、
アジャイルの究極の目的は、本当に価値のあるソフトウェアを届けること。
ってこと。
なんだ、そんなの誰でも知っているよって言われそうです。
ところが、私の中では、「人間を重視する」、「誠実に」とかそういう要素がすごく響いていたんですよ。
アジャイル以前から、そういう働き方に憧れていた。
アジャイルという状態には、それがある。だから私はそこを目指したい、という動機が大きな割合でありました。
もちろん、「価値のあるソフトウェアを届けること」にも強い気持ちを持っていましたが、いくつかの理想とする状態の一つだった。
今日のトレーニングで、そこに認識の変化が生まれた気がします。
仮に「人間を重視する」、「誠実に」、っていうことが目標だとすると、全ての開発はアジャイルにしちゃえばいいじゃん、とかそこまで正直思っていたりしました。
でも、それでさえも、たぶん、手段なんだと今日思いました。
世の中にとって本当に価値のあるソフトウェアを届ける。
そこに至る最適化の中に、「人間を重視」、「誠実に」という手段がある。
それなしには「価値あるソフトウェアを届ける」ことが難しくなってきている。
ある条件の下では、「プロセスやツール」、「包括的なドキュメント」で「価値あるソフトウェアを届ける」ことができれば、それでよいのでしょう。
銀の弾丸を期待していたつもりはないのですが、「働き方」と「開発」を少し重ねすぎていたのかもしれません。
いや、やっぱり、それって銀の弾丸と思っていたのか。。。。
■ScrumがScrumであることのストーリー
「軽量であること」と「軽量さによって難しくなる部分の担保」というScrumにおける構図が自分の中で浮き彫りになりました。
アジャイルの軽量さは、プログラマーの本能的に近い部分に合致するから、プログラマーには受け入れやすいけど、軽量にやることも「価値あるソフトウェアを届ける」ための一つの手段である。別に、プログラマーが快適に過ごしたいからやるわけじゃない。
・フィードバックをこまめに得ながら進むことが、「価値あるソフトウェアを届けること」に直結する。
・じゃあ、確認しながら、一周を短くやろう。
・でも、短くやるには、ソフトウェア開発ってとっても大変だよね。
・軽量にしよう。ムダを徹底的に省こう。
・ムダを省く代わりに、リスクも生まれる。それを担保する仕組みが必要だよね。
・そこでScrumのフレームワークや各種のプラクティスが登場する。
・それは規律だ。厳しい。難しい。
このストーリーが結構見えてなかったんです、私。一つ一つの要素をちゃんと理解していたつもりだったけど、こういう風には人に説明できなかった。
■修得するのではなくつくりあげていくものだ
Scrumはフレームワーク。それを使って自分のコンテキストで組み立てる。
手法に縛られず、とことん自分流を追求した結果、それがアジャイルという状態、みたいな人を周りで少し見てきました。
「つくりあげる」
力強い言葉です。
■After5プロジェクト始めました
仕事ど真ん中のアジャイルプロジェクトがなかなかうまく始められません。
3ヶ月前ぐらいにFacebookで偉そうに宣言したのですが。。。
ともかく手を動かしたくて、業務外の時間で後輩を巻き込んで始めました。
今週、ちょうど、ストーリーを書いて、ストーリーポイントを付けて、スプリントを回し始めているところです。
アジャイルサムライ熟読してたけど、今日のトレーニングを受けて、始めたばかりのスプリントでさえ、できていないことがたくさんあることに気付きました。
after5はカンバンでやるといいよってアドバイスもいただきました。アジャイルサムライにも書いてあったね。
とにかく、今の頭でっかち状態から早く抜け出したい。それでストレス溜まってます。
以上、自分の不甲斐なさばかり出しているようで少し恥ずかしいですが、まだ未体験の方はこんな感じで気付きの多い場なので、是非受けてみてはいかがでしょうか。
ちなみに、このポストイットはQ&Aの一覧。なんと1時間半もQ&A解説。濃かったです。
プロダクトオーナー勉強会 Business Model Canvas
先月に引き続きプロダクトオーナーに参加してきました。
https://sites.google.com/site/spostudy/list/no14_20120706
今日のお題はBusiness Model Canvas。
Business Model Generation という本で語られている手法です。
- 作者: アレックス・オスターワルダー,イヴ・ピニュール,小山龍介
- 出版社/メーカー: 翔泳社
- 発売日: 2012/02/10
- メディア: 大型本
- 購入: 29人 クリック: 473回
- この商品を含むブログ (68件) を見る
ちなみに私はこの本を読んでいません。
プロダクトオーナー勉強会の目的は、プロダクトオーナーがプロダクトの本当の価値を検証するリアルな訓練をすること。
まず、最初にBusiness Model Canvasの定義。
Business Model Canvas とは、組織や事業の設計図を考える過程や結果を元に、新たな発見を得ようとする思考モデル。
Canvasのイメージは以下pdfを参照
http://www.businessmodelgeneration.com/downloads/business_model_canvas_poster.pdf
こちらは紹介動画。
この絵をどう捉えるか。
Business Model Canvasには3つの軸がある。
- 共通言語で議論ができる
- 複数のモデルを比較できる
- 全体像を直感的に理解できる
そして、もう一つのビューがある。
Canvasの左側は「左脳的ロジック＝効率」、右側は「右脳的感情＝価値」
以上、定義。
それでは、ワークショップの模様。
Business Model Canvas はプロダクトに関するいくつかの要素を挙げていき、まず現状のビジネスをモデル化する。勉強会のワークショップでは模造紙に要素を付箋紙でブレストして、モデルを形作っていきました。
その後、ブレストした付箋紙から、現状を更に良くする代替部品について議論する。議論するなかで、あるエリアにある付箋紙が、実は別のエリアの要素になったりする。例えば顧客だと思ってた要素が実はパートナーとして捉えると新しい価値が見える、とか。
進め方にはいくつかの方法があるようです。
私たちのチームはある会社のスマフォ向け電子出版ビジネスについて議論しました。
ここではまず顧客に提供する価値が重要と考え、顧客になり得る要素からブレストしていきました。
顧客→価値→顧客とのコミュニケーション→チャネル→主要活動→リソース→… という順番でやりました。
コンテキストによってこの順番を使い分けてもよいそうです。
例えば、自分達が持っているシーズをうまく活かすビジネスを模索するならば顧客ではなく、主要活動のブレストから始めるケースもあるようです。
ワークショップでは時間がやや足りなかったので、現状の洗い出しまでしかできませんでした。
最初のブレストフェーズでは、要素によって大事になるべく具体的に出した方が良いものや、軽く流して良い部分もあるようです。出しきった後に議論して、要素を入れ換えたり追加することが大事。
私がこのモデルで斬新だったこと。
「左脳的ロジック＝効率」「右脳的感情＝価値」の構成。
Canvas の左側にはコストやリソースなど左脳的な要素がちりばめられていて、 右側には価値や顧客とのコミュニケーション(ハートマーク)みたいな右脳的要素になっています。このバランスがよくて、両方をひとつのモデルで眺めることができる。
私は自分が良いと思うものを説明するときに、極めて右脳的に説明してしまう傾向があります。
このモデルでは、そこをバランスよく思考できる仕組みがあります。右脳対左脳みたいな噛み合わない議論というのはありがちですが、それがCanvas に見えるってのはなかなか良いアイデアだと思いませんか？
最後に。これをどこでどのように使うか。
名前からすると、新規ビジネスの考案に使うっていうイメージですが、もう少し柔らかい場面で使うのがよいのではないか、というのが識者の意見でした。
例えば、意見交換会的やディスカッションの場で、ただただテーマについて話してもなかなか噛み合わなかったり、前提合わせで苦労したり。
そういうときに、これをたたき台として使うと、より現実のビジネスに目を向けた「語り合い」ができるのではないか。
ここ数年、社内で感じていたことは、全てが制度や左脳的ロジックで動いていて、あえて自分は右脳的行動に振り切ろうとしているところもありました。
ただ、それだと会話がやっぱり成り立たない。最終的にはバランスよく使わないと全体最適には向かわない気がしています。
それを補助する対話のツールとしてまずはどこかで使ってみたいと思います。
企業内リーンスタートアップ勉強会 第五回
第五回企業内リーンスタートアップ勉強会に参加してきました。
- 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
- 出版社/メーカー: 日経BP社
- 発売日: 2012/04/12
- メディア: 単行本
- 購入: 24人 クリック: 360回
- この商品を含むブログ (96件) を見る
テーマはMVP。野球とかのアレではありません。
Minimum Viable Product
そのまま訳せば、実用最小限の製品、っていうことになりますが、これには多くの誤解が伴うようです。
Product、製品と言っていますが、製品だけを意味するものではありません。
MVPの絶対条件。
・最小限の努力で最大限の検証結果を得ること。時間と資源。
・修正が容易なこと
・使い方が一目瞭然であること
つまり、製品というだけでなく、もしかしたら「実験」かもしれないし、「検証」かもしれないのです。
エンジニアは何かとモノを早く作りたくなりますが、最も効率的に価値を検証できる手段が何かと考えることが重要なようです。
もしかしたら、「製品」っぽいモノになることもあるのでしょう。
ちなみに、リーンスタートアップでは、構築→計測→学習のフィードバックループを回すことで、より良い製品に成長させていきます。
このフィードバックループを可能な限り少ない努力で学習する効果を最大化するためのMVPという見方もできます。
勉強会では気になった疑問についてワークショップ形式で語り合いました。
私も出した質問なのですが、多かったのが、「MVPのミニマムってどのくらい」というものです。
最初のプレゼンをした和波さんが言うには、その問いはそもそもミスリードとのこと。
どのくらいかと言っている時点で製品を想定しているのではないかと。
フィードバックループを回していく上で大事なことは、どんな課題設定をして、何を検証するのかを最初からシナリオとして組み込んでおくこと。
これって、TDDの考え方と同じですよね。検証することを最初に考えておくことで、構築するものの価値も明確になる。基本の原則は同じ。
ところで、本自体はまだ実は半分ぐらいしか読んでいません。
ちょうどMVPのところを読み終わったところなので、タイミング的にはとても良かったです。
一人で読んでいるよりも、やっぱり議論すると理解が深まりますね。
問題は次の行動に移せるか。
自分は社内の施策や標準化をやるのが仕事なのですが、最近、社内で本当にリソースをかけるべきことが何かということについて悩んでいます。もしかしたら、自分がやってきたことは大部分がムダだったんじゃないかとか。
企業内リーンスタートアップという言葉は、企業内でのビジネス的なスタートアップだけでなく、価値を提供する全ての活動に適用できる、かなり原則的なものなのじゃないかと考えています。
社内におけるMVPとは何か、今やろうとしていることのフィードバックループをどう回せば成功のシナリオに近づくのか、考え中です。
モチベーション3.0 持続する「やる気！」をいかに引き出すか
モチベーション3.0 持続する「やる気!」をいかに引き出すか
- 作者: ダニエル・ピンク,大前研一
- 出版社/メーカー: 講談社
- 発売日: 2010/07/07
- メディア: ハードカバー
- 購入: 101人 クリック: 5,453回
- この商品を含むブログ (153件) を見る
タイトルが釣りっぽく感じられ、最初は敬遠していましたが、前エントリーで触れたアジャイルジャパン2012で紹介された動画から興味を持ちました。
原題は "Drive The Surprising Truth about What Motivates Us"
直訳すると、「やる気。私たちを喚起する驚くべき真実」
こちらの方が内容を詳細に表しているかもしれません。
本書は、外発的動機をモチベーション2.0と呼び、内発的動機をモチベーション3.0と呼び、はっきりと区別することで、新たなステージへのステップアップを読者に強烈に植えつけます。
外発的動機とは、アメとムチが導くモチベーション。
内発的動機とは、自律性、熟達、目的が導くモチベーション。
確かに私もこれまでは内発的動機がよいという一般認識を持っていました。しかし、だからといって外発的動機がそこまで「悪い」という認識を持てていませんでした。給料をもらえるから働く、普通のことだと思っていました。
本書は一刀両断に斬り込みます。
モチベーション2.0という社会OSが引き起こす様々な問題が、どのようなメカニズムで引き起こされるか、科学的な裏付けを武器に鮮やかに解説します。
それは、あなたの会社、私たちの社会で必ず目にする"よくある"問題です。
多くの人は、自分自身がどこかで、モチベーション2.0を前提として動いていたことに気付かされるはずです。それほどまでに、モチベーション2.0というOSは社会の隅々に浸透しています。
会社と自分の折り合いの付け方、あの表裏感は一体何だったのか。人間は本来的に命令に従うのではなく、自らの内なる声に耳を傾けたいのです。自律的であり自己決定的であるのです。それこそが人間性。
そのエネルギーは、今現在、様々な場所で花開きつつあります。
アメリカでのNPO,NGOの台頭。
日本の大企業内でも、サードプレイス的な少集団活動が数多く生まれています。
個人は目覚め始めています。
これからの21世紀は、このモチベーション3.0を推進力に、まだ見ぬ社会の熟達＜マスタリー＞を目指す必要があるのでしょう。
ちなみに。
PMBOK、プロジェクトマネジメントはモチベーション2.0に立脚した考え方。
アジャイル、コーチングはモチベーション3.0をOSとします。
だからこそ
Be Agile!
アジャイルジャパン2012 東京サテライト ふりかえり
アジャイルに2つの出口がみつかった
これは、先日のデブサミ2012で平鍋さんが語った言葉です。
10歳のアジャイルが迎える新しい局面。
「組織改革」と「スタートアップ」。
少しだけ個人的な話を書きます。
私はアジャイル大好き人間ですが、恥ずかしながらアジャイル開発をやったことがありません。
だからこそ、普段の行動や考え方だけでもアジャイルで在り続けようと努めています。
そして、自分なりに小さな行動をしてきたつもりです。
- 勉強会の開催
- チームへの問いかけ
- やってみる精神
- ふりかえりサイクルの短期化
- 自律的リーダーシップの追求
半分ぐらいは意識的に、もう半分ぐらいは無意識に、その行動は「組織改革」を目指すものでした。
いずれ行き詰まりました。
誰かに邪魔されたわけではありません。
息切れしたのです。
4年ぐらいそんなことを色々やってみましたが、何かが変わる感じはなかなか持てませんでした。
組織改革。自分の存在はあまりにも小さすぎるように思えました。
それでも、変わったことが少しだけありました。
あがく中で築いた人脈、仲間がいること。
私はある意味で組織に執着しています。
それは、私の働く動機が、「誰かのために」「誰かと一緒に」だから。
やっぱり組織をなんとかしたい。
ある人との対話をキッカケに私はまた動き始めます。
新しいことを始めました。
社内での技術者コミュニティです。
布石はありました。
元々やっていた読書会。
うっすらと、
「この潜在的な大きなチカラでビジネスができないか」
と考えました。
既存の組織構造とか、現実とか、ビジネス知識はあるのか、そういうことは度外視です。
衝動です。今ここにある技術力、熱い何か。
このコミュニティからビジネスを指向することができないか。
ここ1ヶ月そんなことを考えています。
そこで出会った言葉。
アジャイルの2つの出口。
「組織改革」と「スタートアップ」。
「組織改革」という言葉を額面通りに受け取ると、周りを変える、他人を変える、そういう要素が感じられます。
他人を変えることは本当に可能ですか？
本当にコントロールできるのは自分だけ、この4年間に私が学んだことの一つです。
未だに組織というものが何者か、わかっていません。
本当に変えられるのか。
むしろ、自分ができることをやる。信じることをやる。
それが、ちゃんと価値につながることであれば、それでいいんじゃないか。
そう思えました。
ダイレクトな組織改革は、ある程度中小規模の組織であればできるのかもしれません。
いや、小さな組織においても、スクラムマスターは、本当の自己組織化が難しいと言います。
大きな組織では、真正面からの組織改革、とても難しいことだと思います。
むしろ、新たな成功事例を作ることが大事ではないでしょうか。
成功事例が組織を自律的な気付きに導くこともあるのではないでしょうか？
そして、その領域を少しずつ広げていくことが、結果的に組織改革になっていくのではないでしょうか。
大きな組織の中でも、自己組織化されたチームを作ることは可能だと信じています。
アジャイルは開発を顧客価値とダイレクトにつなげるという側面も持っています。
我々技術者はアジャイルを通して、ビジネスに目覚めなければいけないのかもしれません。
それをやっていくことが、いずれは組織改革になるのではないか。
それを私は組織内の「スタートアップ」と呼びたいと思います。
そして、目指したいと思います。
アジャイルジャパン2012は、その自己確認の場となりました。
Agile is Rockn' roll!
倉貫さんの言葉はいつでも力強いです。
組織と真摯に向き合う組織改革ではなく・・・
少しやんちゃに、お茶目に、技術者の衝動から、コトを始めよう。
これは仕事じゃない。
ムーブメント。
「社員としての私」ではなく、「私としての私」の音を奏でよう。
倉貫さんは更に言います。
銀の弾丸が見つかった。会社を小さくすること
私は「チームを小さくすること」と解釈しました。
顧客を含めたバリューチェーンを小さくすれば、同じことができるのではないか。
ジョナサンがヒントをくれます。
チームのモチベーションを長く高めるもの。
「目的、熟達、自律」
目的は見つけつつある。
熟達を楽しむための仕掛けを考えている。
自律を促すリーダーシップを身に付けてきた。
「君は一人じゃない」
衝動を共有する仲間がいる。
おっと、アジャイルジャパン2012にはこんなコピーがありました。
スタートアップへの羨望を胸に、私はアジャイルジャパン東京サテライトを後にしたのです。
サービスのコピーを始めた（ないない）
サービスを作ることが目標です。
偉大な方から頂いたアドバイスを元に、サービスをまずはコピーしてみます。
Ruby On Railsを少しずつ1ヶ月にわたって触って、なんとなく作れそうな感じになってきたので前に進んでみます。
元々、本業が開発プロセスを定義したりすることなので、始めるときに色々大仰に考えてしまうのだけど、色々わりきります。
とりあえず、こんな順番で。
コピーは色々問題あるので、公開するつもりはありません。
本当はレビューとか誰かにしてほしいけど、それは次の段階かなぁ。
さて、どれぐらいかかることやら。
SQLite3でvarchar型に最大文字数制限ないのね
Railsのmigration機能を色々試していて。
class ChangeBooks < ActiveRecord::Migration def self.up change_column :books, :publish, :string, :limit => 15 end def self.down change_column :books, :publish, :string, :limit => 255 end end
こんなmigrationファイルを定義してみました。
publish列のvarchar文字制限を255から15にしてみたのですが。
いくらやっても、15文字以上入っちゃいます。
どうやらSQLiteは、文字制限などは一切課さないそうだ。
Note that numeric arguments in parentheses that following the type name (ex: "VARCHAR(255)") are ignored by SQLite - SQLite does not impose any length restrictions (other than the large global SQLITE_MAX_LENGTH limit) on the length of strings, BLOBs or numeric values.
http://www.sqlite.org/datatype3.html
まあ、軽い用途ですね、ほんとに。
