読者です 読者をやめる 読者になる 読者になる

アジャイル浪人

拙者のメモ帳でござる

野中郁次郎先生の講演を拝聴して

野中郁次郎先生の講演を拝聴してきました。

ソフトウェア開発と、あまり関係ない講演でしたが得るものがありました。

 

アジャイルソフトウェア開発宣言で書かれている、

 「プロセスやツールよりも個人と対話を」

について、靄のかかったような状態で理解していたのですが、

少し靄が晴れました。

自分なりに講演の内容をアジャイルスクラムに置き換えて考えて書き出してみました。

 

アジャイルスクラムとは暗黙知形式知の共有を促すフレームワークである。

インセプションデッキ、ユーザーストーリー、バックログ、カンバン、

 ペアプロ、ふりかえりなど、たくさん対話するがある)

コミュニケーション(対話)をとることで暗黙知形式知が引き出される。

さらにイテレーティブな開発と、を繋ぐ事で

暗黙知形式知のスパイラルアップ(善循環)が起こり、

さらに知が引き出される。

ひきだされた知を集約して全体のノウハウに変換する。

そしてイノベーションが起こる。

 

アリーヴェ デルチ!

 

 

暗黙知・・・個人が経験の中で培ってきた思いやノウハウや感覚など

       社会生活の中で蓄積する主観的な経験知

形式知・・・言葉や概念

       数値として客観的に表すことができる知

Rubyのお父さん、まつもと氏からメッセージいただきました

自分はRubyのお父さん まつもと氏に少し似てると仲間内で言われることがあるので、

TwitterFacebookのアイコンを

 

まつもとゆきひろ コードの未来 

 

をぱくったデザインにしていたのですが、ご本人からメッセージがございました。

メッセージくれたら嬉しいなと思ってたけど、実際に来てかなり焦りました。

自分が嬉しいのと、まつもと氏がお怒りだったらどうしようという気持ちから

変な汗が大量にでました。

f:id:shio2006:20120625205059p:plain

 

とりあえず、お怒りでは無さそうなので一安心。

3/24 Agile Samurai Dojo Gathering アジャイルサムライ翻訳者 西村直人氏のお話

西村氏の講演はKICK ASSに尽きる 

講演資料

f:id:shio2006:20120324174100j:plain

 

アジャイルを導入できないたくさんの理由

 ・自分が勉強して知識を得るのを待つ

 ・アジャイル経験者がいない

 ・良い顧客

 ・契約

 ・上司

 ・様々なしがらみ  *個人的意見、プログラムやITについて知らない、覚えたくない自称SEやPMの存在

 

アジャイルを導入できるのって何時だ

 ・充分勉強して知識を得ることができたから

 ・良い顧客 

  など

全てが揃う日が来る事は絶対に来ない

 

最近、アジャイル開発を導入しようという人が増えているが、

本だけで導入は無理、現実はもっと大変で色々な問題がある。

 ・エースの離脱

 ・アジャイルに馴染めないメンバー

 ・放置されるバグ

 ・問題のスルー

 ・ゴールが間違っている

上司の説得より、アジャイルを導入するのはもっと大変

アジャイルを導入して失敗すると全く駄目と評価される。

 

大事なのはスポットライトの前で上手く踊る、そのことは本では学べない経験から学ぶ

 ・毎週価値ある成果を届けているか

 ・改善のための努力を続けているか 

 ・良くない事を見逃さずに正す

スーパーヒーローになればアジャイル、だがスーパーヒーローになるのは怖い。

自分たちは普通だからスーパーヒーローになるのは無理。

映画KICK ASS

(コミックのスーパーヒーローに憧れるギーク少年がKICK ASSと名乗りヒーロー活動をするコミック)

暴漢に立ち向かう主人公(KICK ASS)の言葉を引用

 お前らの暴力をみんなが見逃しているのが許せない

 僕は死んでも構わない、かかって来いよ

 *個人的意見、暴漢を見逃す個人を攻撃するのでは無く助けない文化(プロセス)を批判している

それが改善、アジャイルをできないのは僕ら自身が原因。

だけど我々には拠り所がある、

 ・アジャイルを歓迎してくれる会社

 ・アジャイル道場

 ・一人じゃない、アジャイルをやりたい仲間がいる 

改善を続けて、みんなで切磋琢磨すると上手くいく明日からぶちかましてほしい。

今日のようにイベントに参加して、現場に何かを持ち帰ろうとしたり、改善を続けようとする人はそんなに多くない。

ここにいる自分達こそがそれをやっていけるんだ。

■国内事例

 ・幕末の志士、商人、農民、貧乏サムライが幕府を倒した

10年前の北米と同じ盛り上がりを感じる

アジャイルはキャズムを超えた

皆でサムライ戦記(アジャイルに関する体験談)書こう

3/24 Agile Samurai Dojo Gathering アジャイルサムライ翻訳者 角谷信太郎氏のお話

原文読めるようになると翻訳とは違うものがあるでって、誘ってる感じがした。

*Jonathan Rasmusson氏も講演で言っていた教えようとしていることに、どうやって相手の気持ちをいかに動かすか?

 

講演資料

f:id:shio2006:20120324142200j:plain

 

翻訳するにあたり12の原則について思うところがある。

マスター先生はアジャイルの概念として存在する。

 

 アジャイルマニフェスト=神まどか(まどかマギカ)

 

するっと頭にはいるから、そのまま流してしまうのではないか、

翻訳したことで抜け落ちたことがあるのではないかと思っている。 

翻訳はあってるけどテンションが足りない。 

 

3/24 Agile Samurai Dojo Gathering アジャイルサムライ著者 Jonathan Rasmusson氏のお話

Agile Samurai Dojo Gathering ビアバッシュも含めると10時〜22時の長丁場、スタッフの皆様ありがとうございました。

たくさんの学びがあったのですが、個人的に特に覚えておきたい事を残しておきます。

まずは基調講演 “Personal Influences And Motivations Behind Agile Samurai” by Jonathan Rasmusson

講演資料

f:id:shio2006:20120324110900j:plain

読者のかたがたに自身のモチベーションの上げ方をシェアしたい。

下の3つの内容について話します。

1.アジャイルに関する本がたくさん出版されているのに、なぜアジャイルの本つくったのか?

 2006年頃コンサルをしていた時、顧客に7冊のアジャイルの本を読んで欲しいとお願いしていた。

 数が多いので、それらの本を1冊にまとめたかった。

 

2.出版するために出版社の人をどのように口説いたか

 本作ろうと思うんだけどと同僚のマーティン・ファウラーに相談した。

 そうしたら、アジャイル本はたくさん出版されているし必要無いと言われた。

 しかし、7冊の本を使って顧客に説明するのは難しい。

●顧客に渡していた7冊の本

XPエクストリームプログラミング入門(一番影響を受けた本)

 道を示してくれた。

 当時、誰もテストを先に書くと言った人はいなかったし、

 ペアプロを前に打ち出すとか、要件定義の分厚いドキュメントをカードで書くなど

 最初にこの本が発売された時、北米のIT産業にショックを与えた

リファクタリング

 ユニットテストを知った。自動テストでリファクタリングを支えることを知った

・XPエクストリームプログラミング実践編

 本はたくさんあったけど具体例がなかった、この本が具体例を教えてくれた

XPエクストリームプログラミング導入編

 具体的な例を挙げてくれた。

テスト駆動開発入門

 ケントベックはもっと例を教えてくれた

ユーザーストーリーアプライズ

 ユーザーストーリーがどんなものか良い情報がのっている

 ユーザーストーリーのために1冊読むのはしんどい

アジャイルな見積もりと計画作り

 中身はいいけど、1冊読むのはしんどい

 
本を作るために、7冊をまとめる以外に新ネタもある。

いままでどの本にもインセプションデッキについての記述はなかった

 

  7冊+インセプションデッキ=アジャイルサムライ

 

マーティン・ファウラーが有名人なのでオライリーを紹介してくれた。

ここまでで説明した内容をオライリーに説明したら出版できないと断られた。

オライリーに断られたけど、それでも書く必要があると思った。

結果、Programatic Bookshelfで書かせてもらえた。

出版社にアピールする時のコツ

 ・自分の情熱を伝える

 ・解決できていない課題について伝える

 ・サンプルを渡す

 ・大変だけど頑張らないといけない?

 

3.アジャイルサムライ執筆のプロセス

(本だけでなく論文、チュートリアルなどを書くのに役立つと思います)

単にもう一冊アジャイル本を書きたかったわけではない。

楽しく、シンプルに、わかりやすく書く。

本の執筆にあたりクリエイティブにならないといけない、中1の時までクリエイティブだった。

クリエイティビティのヒントをジョン・クリーズ(イギリスのコメディアン)にもらった

フォルティ・タワーズ(イギリスのコメディ番組)の脚本の書き方の講演を見て、

場所と時間の区切りを作ることが大事だと学んだ。

場所の区切り、割り込みの無い誰にも邪魔されない場所に行く事、場所を見つけたら集中するための時間を区切る。

近所のスタバを早朝と週末の執筆オフィスにした。2年間いつも同じ席で作業していた。

1〜3時間びっくりするほど集中できた。

プログラミングの場合は1時間で足りなくて2時間は欲しい。

 

次の課題はソフトウェアプロジェクトマネジメントを楽しむにはどうしたらいいか? 

人に教えることについてキャシー・シエラにインスピレーションをもらった。

Head First DesignPatterns

教えようとしていることに、どうやって相手の気持ちを動かすか?

ゲームとか読者が考える興味を引く仕掛けが書かれている。

出版社にアジャイル版Head First DesignPatternsはどうかと提案した。

話題の本を書くのが良いのではないか、リーチする出版社と、大物と書く、

それ以上にベストセラーにするには読者にフォーカスする内容。

しっかり考えないといけないことが、読者の人生を良くすることができるか

キャシー・シエラを参考にアジャイルサムライに「今すぐやってみよう」を書いた。

 

●日本で一番受けた質問

海賊、忍者ではなく何故サムライ?

ダンミルマンの癒しの旅(やすらぎの戦士)という本を読んだ、本のタイトルを気に入っていた。

タイトルをway of the agile warriorにしようとしていたが、サムライではどうかと出版社に訪ねたらOKがでた。

なぜサムライ好きか?西洋文化(ジョナサンが?)が源流なので武士道に対する名誉とか実践するが気に入っている。 

 

アジャイルサムライに描かれている絵について

 リアルにすると人を特定されるので抽象的に描いた、抽象的だと読者に共感を得られやすい

●何時でも思いついた事を書けるように紙とペンを常に持つ

 本も繰り返しリファクタリングする。

 テストはないけど繰り返し読んで良い感じだと思えるのがグリーンになる基準

●ソフトウェアも一緒だけど、少ない言葉で多くを語るのが良い

●みんなと違う事はない、僕が凄いから本を書けたのではない

●みなさんもユニークなスキルを持っている

●本を書く時は自分が書きたいと思うことを書く

 マーチンファウラーみたいにではなく、自分自身を書く

 自分自身の芸術作品を作りなさい、自分のクリエイティビティを発揮しないのは犯罪的である

  

スタバで執筆するのが楽しかった、金のためにやってない時給に換算しても50円にしかならない。

普段からソフトウェア開発以外でもアジャイルなことをやっている

普段やっていることがソフトウェア開発でできない、日常生活で活かせることをアジャイルサムライに書いた。

日常をソフトウェア開発に持って行くことが自然

 

アジャイルブックマーク

ざっくりわかるアジャイル開発

プランニングポーカーかんたんガイド 

(非公認) スクラムフレームワークかんたんガイド 作ってみました。

野中郁次郎先生と、スクラム、アジャイル、パタン言語、知識創造についてお話しました。

[資料公開]Doneの定義 虎の巻 #scrumdo

Agile do IT! パネルディスカッション - 「Scrum Masters Talk」ジョナサン氏の金言

Agile do IT!に参加しました。

適当にジョナサン氏の発言のみまとめました。

興味がある方は全員の発言がまとめられているtogetterもご参照ください。

パネルディスカッション - 「Scrum Masters Talk」@Agile do IT !

 

Q:スクラムって楽しい?雰囲気ってどう?

A:色々なチームがあるから、どのチーム同じ雰囲気って訳じゃない。

  一人の人がチームに変化をもたらすことができるからアジャイルは面白い。

  完成品は出来上がるまでわからないからエキサイティングだ。

 

Q:スクラムチームの人数はどれぐらい?

A:少人数が好き。最低でも10人以下だが最適な人数は2〜3名

 

Q:チームにツール類(ジェンキンスなど)のスペシャリストをいれるか?

A:チームがツールの使い方を学ぶためにスペシャリストは入れない。

 

Q:チームの外からくる仕様追加や変更などの要求については?

A:予期しないことを想定して、スケジュールに1割ぐらい余裕は持っておく。

 

Q:プロダクトバックログで一番大事なこと

A:プロジェクトの初期はアーキテクチャのリスクを見極める

  イテレーションの3回4回目にどれだけリソースを投入できるか見極める

  その後は顧客に価値があるものを納品し続ける

 

Q:アジャイルを初めて導入するチームにスクラムマスターで入った場合どうすれば成功するか

A:まずBootCampを実施してアジャイル開発プロセスについて話し合う。

 その理由としてアジャイル開発を始める前に、チームが抱えているアジャイルについての不安を払拭してあげることが大事。

 チームのメンバーに一方的にアジャイルをやりますと言うのはフェアではない。

 反対意見を言う場を与えて意見を発散して、チーム全員がアジャイルを導入することに同意してから始めると成功しやすい。 

  

Q:TDD、リファクタリング、テスト自動化、CI、について

A:今、テクノロジを取り入れていることではなく、取り入れようとすること、開発環境を改善しようとする方向性が大事。

*個人的解釈

 開発だけでなく環境もアジャイルに常に改善し続ける事が大事 

 

Q:レガシーコードを改善するためにテストを書きたいがプロダクトオーナーにどのように説明するか

A:大きくリファクタリングしないで、小さく小さくリファクタリングして積み重ねる。

 レガシーコードのシステムに手を加えるぐらいなら、新しくシステム作った方が良いよってプロダクトオーナーに言う。

 プロダクトオーナーにリファクタリングについて何度も言及している。

 プロダクトオーナーに2週間ごとにリファクタリングが必要だとしつこく言ってると自暴自棄になるので避けるべき。

 対処方法、毎週すこしづつリファクタリングをお願いする。

 

Q:あらぶる四天王「スコープ」について、すんなりとスコープの再定義を許す?

A:提案、スコープは臨機応変に変えれるバッファを持つ。

    ステークホルダーに時間は無いし、やることは山ほどあると常に言い続けてアピールする

    プロジェクト始める前に必ず言うこと。

 

Q:大規模スクラムスクラムスクラム)の場合のハンドルのしかた

A:大きいプロジェクトは大変。

  ハイレベルのマスターストーリーリストを作成して、その下にサブストーリーリストを作成する

 

Q:スクラムマスター、プロダクトオーナーに必要なスキルって何?どうやったらのばせる?

A:目標として、それほどチームに求められる存在にならないこと

 *個人的解釈

 チーム全体が自己組織的に動き出し、プロダクトオーナーやスクラムマスターが動かなくてもいいのが良いアジャイルのチームだと理解

f:id:shio2006:20120319201000j:plain