拙者のメモ帳でござるこの広告は、90日以上更新していないブログに表示しています。2012-08-04野中郁次郎先生の講演を拝聴して野中郁次郎先生の講演を拝聴してきました。ソフトウェア開発と、あまり関係ない講演でしたが得るものがありました。自分なりに講演の内容をアジャイル・スクラムに置き換えて考えて書き出してみました。アジャイルやスクラムとは暗黙知と形式知の共有を促すフレームワークである。(インセプションデッキ、ユーザーストーリー、バックログ、カンバン、ペアプロ、ふりかえりなど、たくさん対話する場がある)コミュニケーション(対話)をとることで暗黙知や形式知が引き出される。イテレーティブな開発と、場と場を繋ぐ事で暗黙知と形式知のスパイラルアップ(善循環)が起こり、さらに知が引き出される。ひきだされた知を集約して全体のノウハウに変換する。イノベーションが起こる。コードの未来をぱくったデザインにしていたのですが、ご本人からメッセージがございました。メッセージくれたら嬉しいなと思ってたけど、実際に来てかなり焦りました。自分が嬉しいのと、まつもと氏がお怒りだったらどうしようという気持ちから変な汗が大量にでました。お怒りでは無さそうなので一安心。本だけで導入は無理、現実はもっと大変で色々な問題がある。・ゴールが間違っている上司の説得より、アジャイルを導入するのはもっと大変アジャイルを導入して失敗すると全く駄目と評価される。大事なのはスポットライトの前で上手く踊る、そのことは本では学べない経験から学ぶ・毎週価値ある成果を届けているか・改善のための努力を続けているか・良くない事を見逃さずに正すスーパーヒーローになればアジャイル、だがスーパーヒーローになるのは怖い。自分たちは普通だからスーパーヒーローになるのは無理。ASS)の言葉を引用お前らの暴力をみんなが見逃しているのが許せない僕は死んでも構わない、かかって来いよ*個人的意見、暴漢を見逃す個人を攻撃するのでは無く助けない文化(プロセス)を批判しているそれが改善、アジャイルをできないのは僕ら自身が原因。・一人じゃない、アジャイルをやりたい仲間がいる改善を続けて、みんなで切磋琢磨すると上手くいく明日からぶちかましてほしい。今日のようにイベントに参加して、現場に何かを持ち帰ろうとしたり、改善を続けようとする人はそんなに多くない。原文読めるようになると翻訳とは違うものがあるでって、誘ってる感じがした。翻訳するにあたり12の原則について思うところがある。マスター先生はアジャイルの概念として存在する。翻訳したことで抜け落ちたことがあるのではないかと思っている。翻訳はあってるけどテンションが足りない。ビアバッシュも含めると10時〜22時の長丁場、スタッフの皆様ありがとうございました。たくさんの学びがあったのですが、個人的に特に覚えておきたい事を残しておきます。読者のかたがたに自身のモチベーションの上げ方をシェアしたい。下の3つの内容について話します。1.アジャイルに関する本がたくさん出版されているのに、なぜアジャイルの本つくったのか?2006年頃コンサルをしていた時、顧客に7冊のアジャイルの本を読んで欲しいとお願いしていた。数が多いので、それらの本を1冊にまとめたかった。2.出版するために出版社の人をどのように口説いたか本作ろうと思うんだけどと同僚のマーティン・ファウラーに相談した。したら、アジャイル本はたくさん出版されているし必要無いと言われた。7冊の本を使って顧客に説明するのは難しい。・XPエクストリームプログラミング入門(一番影響を受けた本)道を示してくれた。当時、誰もテストを先に書くと言った人はいなかったし、ペアプロを前に打ち出すとか、要件定義の分厚いドキュメントをカードで書くなど最初にこの本が発売された時、北米のIT産業にショックを与えた・リファクタリングユニットテストを知った。具体的な例を挙げてくれた。・テスト駆動開発入門ケントベックはもっと例を教えてくれた・ユーザーストーリーアプライズユーザーストーリーがどんなものか良い情報がのっているユーザーストーリーのために1冊読むのはしんどい・アジャイルな見積もりと計画作り中身はいいけど、1冊読むのはしんどい本を作るために、7冊をまとめる以外に新ネタもある。いままでどの本にもインセプションデッキについての記述はなかった7冊+インセプションデッキ=アジャイルサムライマーティン・ファウラーが有名人なのでオライリーを紹介してくれた。ここまでで説明した内容をオライリーに説明したら出版できないと断られた。オライリーに断られたけど、それでも書く必要があると思った。Bookshelfで書かせてもらえた。出版社にアピールする時のコツ・自分の情熱を伝える・解決できていない課題について伝える・サンプルを渡す・大変だけど頑張らないといけない?3.アジャイルサムライ執筆のプロセス(本だけでなく論文、チュートリアルなどを書くのに役立つと思います)単にもう一冊アジャイル本を書きたかったわけではない。楽しく、シンプルに、わかりやすく書く。本の執筆にあたりクリエイティブにならないといけない、中1の時までクリエイティブだった。場所と時間の区切りを作ることが大事だと学んだ。場所の区切り、割り込みの無い誰にも邪魔されない場所に行く事、場所を見つけたら集中するための時間を区切る。近所のスタバを早朝と週末の執筆オフィスにした。2年間いつも同じ席で作業していた。1〜3時間びっくりするほど集中できた。プログラミングの場合は1時間で足りなくて2時間は欲しい。次の課題はソフトウェアプロジェクトマネジメントを楽しむにはどうしたらいいか?人に教えることについてキャシー・シエラにインスピレーションをもらった。DesignPatterns教えようとしていることに、どうやって相手の気持ちを動かすか?ゲームとか読者が考える興味を引く仕掛けが書かれている。DesignPatternsはどうかと提案した。話題の本を書くのが良いのではないか、リーチする出版社と、大物と書く、それ以上にベストセラーにするには読者にフォーカスする内容。考えないといけないことが、読者の人生を良くすることができるかキャシー・シエラを参考にアジャイルサムライに「今すぐやってみよう」を書いた。海賊、忍者ではなく何故サムライ?ダンミルマンの癒しの旅(やすらぎの戦士)という本を読んだ、本のタイトルを気に入っていた。warriorにしようとしていたが、サムライではどうかと出版社に訪ねたらOKがでた。サムライ好きか?西洋文化(ジョナサンが?)が源流なので武士道に対する名誉とか実践するが気に入っている。●アジャイルサムライに描かれている絵についてリアルにすると人を特定されるので抽象的に描いた、抽象的だと読者に共感を得られやすい●何時でも思いついた事を書けるように紙とペンを常に持つ本も繰り返しリファクタリングする。●ソフトウェアも一緒だけど、少ない言葉で多くを語るのが良い●みんなと違う事はない、僕が凄いから本を書けたのではない●みなさんもユニークなスキルを持っている●本を書く時は自分が書きたいと思うことを書くマーチンファウラーみたいにではなく、自分自身を書く自分自身の芸術作品を作りなさい、自分のクリエイティビティを発揮しないのは犯罪的であるスタバで執筆するのが楽しかった、金のためにやってない時給に換算しても50円にしかならない。普段からソフトウェア開発以外でもアジャイルなことをやっている普段やっていることがソフトウェア開発でできない、日常生活で活かせることをアジャイルサムライに書いた。野中郁次郎先生と、スクラム、アジャイル、パタン言語、知識創造についてお話しました。IT!に参加しました。適当にジョナサン氏の発言のみまとめました。興味がある方は全員の発言がまとめられているtogetterもご参照ください。!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:大きいプロジェクトは大変。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。