開発の現場にてプロジェクトファシリテーションのワークショップ：An Agile Way：オルタナティブ・ブログ
永和システムマネジメントの川上さんが、プロジェクトファシリテーションの中でももっとも効果が高いとされるプラクティス、「ふりかえり」のワークショップを開催します。 http://www.shoeisha.com/mag/kaihatsu/workshop/ 有料セミナーですが、ぜひ、現場リーダー教育としてご活用ください。実際に参加してファシリテーション（司会のやり方）を体験してもらうことで、もちかえって自身の現場をカイゼンするきっかけを掴むことが、目標です。 ふりかえり、というのをご存知ない方のために、簡単に解説を。。。 ふりかえり、というのはチームが１つの開発単位（一週間とか一ヶ月とか）を終えたあとで、その期間をふりかえって、「次に活かせる何か」をチームで発見しよう、と言う試みです。うまくいったことは続ける。うまく行かない問題は、解決を考える。 KEEP = 続けて行きたいこと、PROBL
わが家のルールと、参加型意思決定：An Agile Way：オルタナティブ・ブログ
夏休みに入った機会に、平鍋家のルールを決めた。 土曜の午前中はみんなでそうじ ゲームのはじめに時間をかく 弱いものいじめはしない 出かけるときには「だれ」と「どこ」へ行くか、何時に帰るか言っていく おはよう、ありがとう、ごめんなさい 自慢したら「すごいね」という 動機は、「国家の品格」を読んで、父親として、子供たちに伝えたいことがあった、というのが１つ（３番目）。最近ゲームばかりしているので、時間のルールを作りたかった。それから、最近平日には東京にいるので、休み中、妻が子供を見るのに苦労をするだろう、というのもある。自立的に意思決定できるように、簡単な行動原則を作りたい。 父親の一言（トップダウン申し渡し）でも良かったが、自称ファシリテータとしては、全員のコミット感を得るために、全員参加型で書くプロセスを共有したいと思った。家でやるにはちょっと難しいかな、とも思ったが、やってみたら案外うま
ビジネス設計とシステム設計の分離は可能か？at 要求開発サミット２００６パネルディスカッション：An Agile Way：オルタナティブ・ブログ
3月17日に行われた要求開発のパネルディスかションで、「ビジネス設計」（ユーザ側、発注側）と「システム設計」（ベンダー側、受注側）の間をどう埋めるか、という議論がおもしろかった。 日本総研の細川さんが、その２つの間に点線を引いていたのを、システム側からビジネス側に食い込む斜め線をひき、システム側からビジネス側に押し出すような三角形にし、このデルタ地帯を「黒い三角形」と呼んだ。 豆蔵の萩本さんは、「現にビジネスの設計においてITを抜きでは語れない」ことから、そもそも現在、この点線分割が出来ないことを主張した。動くものを見てみないと、話にならないことが多いのだ。これは、アジャイルの立場とも強く符合する。 ぼくが最もおもしろいと思ったのは、甲府市役所の土屋さんの意見。「システムの側からも、工夫してビジネスの要求を聞き出して欲しい」ということ。「射止めたい異性のためには、さまざまな工夫をしてコミュ
分散ペアプロ(Remote Pair Programming)は可能か？～JUnit の開発はSkype/VNCで：An Agile Way：オルタナティブ・ブログ
分散ペアプロ(Remote Pair Programming)は可能か？～JUnit の開発はSkype/VNCで リモートでのペアプロは可能だろうか？YES。 実はJUDEの開発は、日本と中国での分散開発だ。ただし、完璧なペアプロではない。共通言語がお互い片言の英語、という状況であり、電話を使うのは返ってストレスになる。実際にはメッセンジャーを常時立ち上げて会話している。表示名を「名前（現在のタスク名）」とするなど、工夫をしてコミュニケーション効率を高めている。 最近のXP本家メーリングリストに、Kent Beck が投稿していた。 JUnit の開発は、コードの50%がペア。実際リモートペアプロなんだ。VNCとSkypeを使っている。 なるほど。Skype/VNCが使えるようになって、リモートペアプロの手段も現実的になってきたのだなぁ。 ちょっと、話題がずれるが、ペアプロの効用にはいろ
医療の現場でマインドマップ！：An Agile Way：オルタナティブ・ブログ
とっても面白いマインドマップの事例ブログを発見(im さんありがとう)。 medtoolzさんhttp://medt00lz.s59.xrea.com/blog/archives/2005/11/post_308.html 患者さんを診察して、その場で患者さんをセントラルイメージとする、マインドマップを書き、これを見ながら申し送りをするという。 何かの議論になったときは、どこに何が書いてあるのかすぐ分かるのでたしかに速い なるほど。確かにマインドマップの利点をうまく使っている。また、色と曲線を使え、というコツも、納得だ。（直線だと視線が行き場をうしなう。色には、TODO、引継ぎ、とか意味を持たせる） また、西洋医学のカルテの書き方POS（小売業界のPOS－Point Of Salesとは別：Problem Oriented System）では、 S:患者さんのお話 O:理学所見や検査所見
TheWorldCafe ～会話を使ってぼくたちの未来を形作る～：An Agile Way：オルタナティブ・ブログ
「ワールドカフェ」、というファシリテーション手法をご存知だろうか。実はぼくも最近知ったのですが、「カフェ」での会話というスタイルを使って、みんなで共通の課題について話合おう、という趣向です。 （↓のマインドマップは、クリックで大きくなります。詳細は、http://wiki.esm.co.jp/TheWorldCafe.pdf) 書籍 The World Cafe: Shaping Our Futures Through Conversations That Matter http://www.amazon.co.jp/exec/obidos/ASIN/1576752585/xpjp-22/ 背景には、現在の社会的、技術的な関心事と未来の方向性は、個人個人の頭の中そして、それらの「ソーシャルネットワーク」にある、という気づきがあります。これは、現在のインターネット上のblogやSNSを見てい
ユーザ要望の聞き取り方を学ぶー究極の目的とは？：An Agile Way：オルタナティブ・ブログ
ユーザ要望の聞き取りをする場合、利用者や利用場面を聞くことは重要だ。しかし、もっとも重要なことはなんだろう？それは、そのシステムを作る目的は何か、だ。要求開発でも言われているように、「正しくない要求を正しく実装しても意味がない」。そのシステムを作る目的をはっきりさせることが、要求を聞き取る場合に最も重要なことだと思う。 目的はいくつかある、というかもしれない。では、究極の目的はなんだろう。それを聞き出す、魔法の質問がある。 作ろうと思った動機はなんですか？ この質問は、ぼくが家をたてるときにミサワホーム福井支店の営業、大野尊言さんに聞かれて、感動したものだ。ぼくは家を建てるときに、自分でラフなRFPを書いて数社に提案をお願いしようとした。他のハウスメーカーや工務店が、予算、間取り、和洋、などを聞いてきたのに対して、大野さんは、この質問をした。「家を建てようと思った動機はなんですか？」 ぼく
マインドマップによる、ユーザ要望の聞き取り - An Agile Way
実際に、マインドマップを使って、顧客インタビューをやってみた。図書館の業務支援システムを題材に、本物の司書の方に、インタビュー。 最初に、聞きたいことの要点を、マインドマップで書いておき、その枝に聞いたことを追加していく。その枝（マインドマップ的には、BOI）は、 誰が使いますか？ どんな場面で使いますか？ 管理したいものは何ですか？ の３つである。そして、最後に宿題という枝を用意しておき、そのインタビューで出た宿題を追加する。この３つのBOIは、Who/When/What であると共に、 アクター ユースケース ドメインモデル になることを想定している。もちろん、完全にそうはならないが、ネタとして意識する。 マインドマップのコツとしては、最初から用意した質問の枝は、「下線」でなく「箱」をつかい、また「クリップ」アイコンで分かりやすくしている。宿題は、「おうち」アイコンである。このテンプレ
KPTを使ったプロセス改善：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発の繰り返し単位（イテレーション）ごとに、そのタイムボックスで行なったことを反省し、未来に生かせるように口に出してみる、という活動を行なう。これは、反省会、回顧、Retropective、Reflection、などと呼ばれる（ぼくは「ふりかえり」という言葉が好きだ）。 アジャイル開発ではこの「ふりかえり」が「KAIZEN加速装置」となる。 これを行なうときに使うフォーマットを写真に示した。ぼくはこれをKPT（ケプト）と呼ぶ（Keep/Problem/Try）。Alistair Cockburnから教えてもらったもので、ぼくはこのフォーマットのヘビーユーザー。 ホワイトボードが３つのセクションに分かれており、Keep（このまま続けること）、Problem（問題点）、Try（次に試してみたいこと）と名前が付けられている。全員参加のふりかえりミーティングを開き、そこで、今回のイテレ
ユースケース重要！（not 図、but 記述)：An Agile Way：オルタナティブ・ブログ
ユースケースは、やはり重要なのである。とはいっても、「ユースケース図」ではなく、「ユースケース記述」の方だ。 ユースケース図は、機能名を楕円で囲っただけだ！ と喝破したのは、「ユーザ中心設計(UCD)」のひがさんだが、ユースケースは、図ではなくて、シナリオにこそ、真価がある。図を書くと、ついつい構造化したくなり、include や extend を使ってどんどんどんどん深くなってしまう。そっちの方に行ってはいけない。 ユースケース記述を、充実すべきだ。その粒度、フォーマット、項目を最新の注意で設計しよう。細かな画面仕様やフィールド仕様でなく、まずは、「意図」が伝わるように。 最近のJUDEは、「ユースケース記述」をすっごい充実している。とくに、記述のフォーマットをカスタマイズできる。これで、独自の記述様式ができると共に、あらかじめフォーマットとして、RUP形式、アリスタコバーン形式が用意し
ソフトウェアのプル生産：An Agile Way：オルタナティブ・ブログ
今回は、トヨタ生産方式とアジャイル開発の共通点である、「プル生産」について書いてみたい。前回から継続している「テスト」の話に関連している。前回は、上流から下流へ向かって１個ずつ要求を流す、という話をしたが、今回は、生産指示（いつどれだけ作って後工程に流すか）について。 トヨタ生産方式では、工程間に溜まった仕掛を在庫（＝ムダ）と捕らえている。この在庫を「かんばん」で管理し、前工程への生産指示を出す。後工程が必要になって初めて、前工程が作る。前工程は、生産指示がない限り作らない。生産物は必要な分だけ前工程から後工程へと流れ、生産指示は逆に後工程から前工程へと流れるのだ（後工程引き取り）。 たくさん作ることは良いことだという作り手側の論理で生産を続けると、前工程から後工程へと生産物がプッシュされることになる。後工程で必要とする以上の生産物は、ムダとなり工程間に在庫として貯まる。これが、在庫のムダ
テストの役割（進捗管理その２）：An Agile Way：オルタナティブ・ブログ
Alistair Cockburn は、ソフトウェア開発の「1個流し」(*1)と進捗管理について、おもしろい例を出している。次の問題を考えてみて欲しい。 ３０個の部屋がある豪邸を考える。この豪邸から、1ヵ月後に引越しをすることに決めた。全部屋を掃除し、捨てるものと運ぶものに分類し、ダンボール箱に詰めなければならない。どのように進捗を管理したら、１ヵ月というデッドラインを守れるか。 ウォーターフォール的計画： １．最初の1週間で全部屋の掃除を行なう ２．次の1週間で全部屋の捨てるものと運ぶものを分類し、ステッカーを家具や備品に貼る ３．次の1週間で全部屋のダンボール箱詰めを行なう ４．次の1週間で全部屋のチェックを行なう ５．４週間あるので、４週間後には全部屋のチェックまで終わる 1個流し的（アジャイル的）計画： １．日割りで、１日に１つの部屋を、掃除、分類、箱詰め、チェックまで終える ２．
テストの役割=進捗管理＋設計戦略：An Agile Way：オルタナティブ・ブログ
「EoM=EoC+EoT」を鍵概念として、良い設計とは何か、よいプロセスとは何か、を再定義しようとしている。今回は、テストの役割について再考する。 テストは設計とプロセスの両方の基本単位だ。まず、テストと進捗管理の話をしたい（テストとドキュメントの話、テストとコミュニケーションの話、テストと開発リズムの話、などと続く予定）。 みなさんは、進捗指標として何を使っているだろうか？「工程ごとに違うが、成果物の完成に対する到達度だ」という答えが一般的だと思う。しかし、「設計書９０％完成という報告が２週間続いている」というような進捗会議に参加したことはない？ （きっとあるはずだ。） ぼくが考える進捗管理の基本は、 の3点だ。先に述べた「設計書のページ数」という単位は、３つの条件をどれも満たしていない。すべての設計書を否定するつもりはないが、設計書は内部の中間生産物であることが多いし、１００％終了とい
「保守しやすいこと」が、良いプロセス～開発における、「設計」と「プロセス」の双対関係～：An Agile Way：オルタナティブ・ブログ
前回、「EoM(保守容易性)が良い設計の基準だ、そして、EoM＝EoT+EoCだ」という議論を書いた。ここまでの議論は、ソフトウェアの設計についてのものであり、開発の「プロセス」（あるいはプラクティス）とは無関係に進めてきた。ここで、１つの経験則を使って、プロセスの方（鏡の反対側）を見てみたい。その経験則とは、 コーンウェイの法則： ソフトウェアの構造は開発チームの構造に一致する。コンパイラを４チーム編成で作れば、４パスコンパイラになる である。（※この法則は、ソフトウェアとチームの「構造」（organization）について述べたものだが、ここでは、プロセスについて拡大解釈する） この法則を使うと、３つの設計品質についての方針は、そのまま、プロセスについての方針にミラーコピーできる。 EoTに関するプロセスの命題は、テストというより、「テスティング」という活動が、プロセスの中で最も重要な
「変更しやすい」ことが、良い設計 (EoC=Ease of Changing) - An Agile Way [ITmedia オルタナティブ・ブログ]
前回は、EoT(Ease of Testing: テスト容易性)によってよいオブジェクト指向設計を再定義したい、という表明をした。今回は、二本目のナイフを抜きたい。キーワードは、EoC(*1)(Ease of Changing)、変更容易性だ。 この記事では、 EoCの高い設計が、よいオブジェクト指向設計である。 と主張したい。設計品質の中で、「変更容易性(EoC)」を最上位と見る。 ここ10年のオブジェクト指向の最大の失敗は、「再利用性」をその最大の価値、として説明しようとしてきたこと。そして分かったことは、再利用がその努力コストに見合う効果がでることは極めて稀であること、また、テクノロジではなくソーシャルな活動が再利用に効くこと、さらに、コードの再利用ではなく、ナレッジの再利用（例えばパターン）の方が、まだ可能性があるということ（少なくとも2005年のコンテクストでは）。 再利用性では
「テストしやすい」ことが、良い設計(EoT=Ease of Testing) - An Agile Way [ITmedia オルタナティブ・ブログ]
良い設計とはなにか、と問われて、凝集度と結合度に関する議論を思いつく人も多いだろう。しかし、この定義によりもっと具体性がある設計方針として、テストを考える。テストの視点によってオブジェクト指向を再定義したい。キーワードは、Eon(Ease of Testing)、テスト容易性だ。 ぼくは、 EoT(*1)の高い設計が、よいオブジェクト指向設計である。 と主張する。設計品質の中で「テスト容易性(EoT)」を最上位と見るのだ。オブジェクト指向のさまざまな機構、用語、考え方は、すべて EoT のため、と捕らえられる。例えば、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
UMLのネイルアート、発見！(^_^)：An Agile Way：オルタナティブ・ブログ