ソフトウェア開発のメタファ：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発のメタファーはいろいろある。建築、などと対比されることが結構多い。 ここでは、ラグビーで得点する、という活動と対比してみたい。敵の動きはあらかじめ計算できない。監督は試合が始まったら声をかけたりサインを出したりするが、基本的に現場で判断が起こる。つまり、「計画して忠実に実行する」という考え方では得点できない。 野中郁次郎先生が、"The New New Product Development Games"という論文で、製品開発の「知識創造活動」をSCRUMという形で定式化した。これが、アジャイル開発の１つの起源になっている。SECIモデルの知識創造が、現場で起こっており、それを支援するプロセスとして製品開発をモデル化している。 ただ、すべてのソフトウェア開発がこのような「動的な」ものだ、というつもりはない。ものによっては、「計画してその通り実行」というモデルに近いものもある
テスト駆動開発のテストは、テストか？―TDD から BDD へ - An Agile Way [ITmedia オルタナティブ・ブログ]
アジャイル開発の中の１つのプラクティスであるTDD(Test Driven Development、テスト駆動開発)に使われるユニット・テスト、というものの役割について、よくテスト界の人との意見の相違がある。テストとしての完全性、や、品質保証についての考え方から見ると、テストとは呼べないのでは？ということ。 最近、アメリカテスト界の有名人であり、アジャイルコミュニティへの貢献も大きい、Brain Marick(www.testing.com/cgi-bin/blog) 氏とメールで話す機会があった。 アメリカでのコンセンサスは、TDDのテストはテストとしては二義的であり、一義的には、「設計ツール」だ これは、以前「テストの役割=進捗管理＋設計戦略」 blogs.itmedia.co.jp/hiranabe/2005/08/sd4__c05e.html で 紹介した、t-wadaさんの「テス
プロジェクト現場の幼稚園化：An Agile Way：オルタナティブ・ブログ
アジャイル開発やプロジェクトファシリテーションを実践している現場は、幼稚園や小学校とよく似た光景ややり方を目にすることがある。たとえば、「ニコニコカレンダー」だったり、「バグレゴ」だったり、「朝会」だったり、「プロジェクトホームルーム」だったり、「あんどん」だったり。 このエントリは、そのような場面を見て、「いい大人が、何をやっているのか！プロフェッショナルは黙って自分の仕事をせよ！」というような仮想議論（この意見を実は直接聞いたことがない）に対する仮想回答である。 ソフトウェア開発は、「ナレッジ創造(Knowledge Creation)」活動なのだ。よく分かっていないものを、アイディアとコミュニケーションでつないで、ドキュメントにしたり、テストやコードにしたり、マニュアルにしたり、している。この「よく分からないこと」というのは、要求にしても基盤技術にしてもそうだ。顧客は要求を完全に分か
ODD - おもいやり駆動開発：An Agile Way：オルタナティブ・ブログ
思いやり駆動開発（ODD） ソフトウェア開発を成功させる、もっともシンプルな「こころがけベース」のアプローチである。オブジェクト倶楽部2007夏イベントで発表された。ここでは、ついカッとなって私なりにこのコンセプトを膨らませてみたい。 ソフトウェア開発はコミュニケーションでできている。ソフトウェアの欠陥が発生しやすいのは、人と人の境界、プロジェクトとプロジェクトの境界。そしてそこにはコミュニケーションが生まれている。コミュニケーションには相手があり、その相手を「思いやる」ことが、大切だ。読み手のことを思いやるコードを書こう。システムのユーザを思いやる仕様にしよう。そんなシンプルな「こころがけ」だ。 具体的には、こういうこと。 システムを実際に使う「ユーザー」を思いやろう。ストレスなく使え、「思った機能がそこにある」ようなシステムにしよう。そのユーザが普段使っている言葉のUIを提供しよう。製
JUDEでプロジェクト管理(^_^)：An Agile Way：オルタナティブ・ブログ
細谷さんの、面白いエントリ発見。JUDEのマインドマップとユースケース、ユースケーステンプレートを使って、プロジェクトを回していくための、JUDEテンプレートだ。 http://hosotani.blog.bai.ne.jp/?eid=46587 タスク、リスク、ミーティング、TODO、ステークホルダ、などを、これを使って「見える化」できる。 (1)各分析をマインドマップで行う。 (2)マインドマップ上のToDoをユースケースに変換 (3)ユースケース図でステークホルダと関連付ける (4)ユースケース一覧のＣＳＶ出力でＴｏＤｏリスト化 すごくオリジナリティが高く、かつ、JUDEのいいところをうまく利用しながら「現場で利用できる」レベルになっている。この例のように、「JUDEの上に一皮かぶせる」手法をどんどん育成していきたい。 トヨタ生産方式でも言われているとおり、すべてのツールは、手になじ
要のもの・こと分析～仕事の本質ってなんだっけ？(^_^)：An Agile Way：オルタナティブ・ブログ
最近富士通の方に「要のもの・こと」という言い方を聞き、そこから検索して中村善太郎さんの『シンプルな仕事の構想法』という本を読んでみた。 すごいなー、トヨタ生産方式に代表されるような「ムダどり」の発想を、抽象化して捉えている。これは、GTDやらアジャイルやら、リーン思考やらプロジェクトファシリテーションやら、ユースケースやらというものをインスタンスとして扱えるような思考の枠組みじゃないだろうか。 仕事とは、「行わねばならないこと」を「体や頭を使って行うこと」 であり、さらに、 「行わねばならないこと」とは、「もの」を「始めの状態」から「終わりの状態」に変える「こと」 である。そこには「要（かなめ）の変化」があり、あとはすべて贅肉だ。仕事を分析して「要のもの・こと」に焦点を合わせ、排除（Eliminate）、結合（Combine）、シンプル化（Simplify）を検討する。そもそも、仕事に要が
Niko-Niko Calendar にこにこカレンダーのコミュニティ、blog で実験 (^_^)：An Agile Way：オルタナティブ・ブログ
坂田さんやヤマモトさんがやっている「ニコニコカレンダー」という今日の自分のムードの見える化手法がある。 http://www.geocities.jp/nikonikocalendar/index_ja.html チームの壁にこれを貼って、今のチームムードを全員でフィードバックする。ちょっとうまくリーダーに報告できないような「こころもち」も、これなら気軽に伝えられる気がする。略して「ニコカレ」。命名者は、 “つらい気持ちの人も、体調の悪い人も、変化のない毎日の人も、シールを貼っていくうちにこのカレンダーがニコニコマークでいっぱいになればいいなぁ、という気持ちでニコニコカレンダーとつけました。” という。mixi にも、「ニコニコカレンダー愛好会」というコミュニティがある。 ところで、「ブログ」というメディアを使って、「世界ニコカレ」の実験をしてみたい。ブログエントリの「題名」の最後に、自分
Paul Graham in "Joel on Software" あるいは、新しい会社に就職するときの心得：An Agile Way：オルタナティブ・ブログ
Paul Graham in "Joel on Software" あるいは、新しい会社に就職するときの心得 今日は角谷さんの企画で、Aardvark'd のDVDを見た。Joel on Software で有名な会社にきた Intern たち（いわゆる nerd というか、geek）が、ソフトウェアの世界になじみ、巣立つまでの 12 weeks を描いた映画。 面白かった。生Paul Grahamを初めてみたが、かなり俳優バリの存在感。いわく、 「ハッカーと言う言葉には sneaky なにおいがある。そして、もともと”創造”と”ハック”には似たニュアンスがあるのだ。例えば、相対性理論というのは、ユークリッド空間の sneaky なハックだ。」 なるほどー。（ちなみに上映会の後、角谷氏は自転車で３０分以内で通える通勤路を見つけることを、「通勤ハック」と呼んでいた。） この映画を見て、採用と
プロジェクト・ファシリテーション－ファシリテータ型リーダの資質：An Agile Way：オルタナティブ・ブログ
プロジェクトの場作り（ファシリテーション）を行い、チームメンバーの能力を１００％以上発揮させ、１＋１を２以上にする、新しい形のリーダーシップが必要だ。そのたの人材像について、考えている。株式会社ITイノベーションに伺ったとき、Harvard Business Review をパラパラと見ていたら、こんな文章が！ 人々に学び 人々と一緒に計画し 人々が持っているもので始め 人々が知っていることの上に築きなさい。 リーダーが真に優れていれば、 終わってみると 人々は口々にこういう 「自分たちの力でやり遂げた」と。 －老子 うーん、まさに、これが理想だ。。。 ITイノベーションの林衛さんには、前回のオブジェクト倶楽部で主賓講演を頂きました。今回は、「ザ・プロジェクトマネジャーズ」のインタビューを私が受けました。 http://topic.promane.com/iti/dtdisp.asp?en
議事録をマインドマップで：An Agile Way：オルタナティブ・ブログ
ひろえむさんのコメント http://blogs.itmedia.co.jp/hiranabe/2005/07/uml_0aaa.html#comments に触発されて、やってみる。 毎日の議事録をすべて１つのJUDEファイル（プロジェクト）に入れる。 月ごとに、パッケージ化 議事録のテンプレートを作っておく。そのテンプレートを、右クリックで複製するところから、作成を始める。 もしかして、すごい、いいかも。マインドマップの想起性が活かされる。 しかも、「検索」タブで全体を検索できる！ テンプレートは、枝ごとに色分けし、「枝の色を引き継ぐ」属性をオンにしておく。 議事録にかくべきことは、以下に準拠。 http://www.atmarkit.co.jp/farc/rensai/pl03/pl03.html しばらく、これでやってみよう。 やっていると、宿題のところの枝は、「誰が」「いつまでに
「保守しやすい」ことが、良い設計(EoM = Ease of Maintenance)：An Agile Way：オルタナティブ・ブログ
前２回で、オブジェクト指向を「テスト容易性」と「変更容易性」を中心に再定義したい、という話をした。 従来オブジェクト指向の説明に使われている概念、およびそこから得られる（といわれている）再利用性という品質からではなく、 テスト容易性： EoT = Ease of Testing 変更容易性： EoC = Ease of Changing という２つの概念からが、（現代的な）オブジェクト指向設計の焦点であることを主張してきた。最後、なぜこの２つが必要なのか、というと、それは、メンテナンスのしやすさ（EoM=Ease of Maintenance）を高めるからだ。そして、このEoMこそが、2005年のソフトウェア開発の根本品質だ、と言い切ってまとめたい。 EoMの高い設計が、よいオブジェクト指向設計である。 ということである。今回は、前回書いた、EoT/EoCそして、このEoMについて、ソフト
「テストしやすい」ことが、良い設計(EoT=Ease of Testing) - An Agile Way [ITmedia オルタナティブ・ブログ]
良い設計とはなにか、と問われて、凝集度と結合度に関する議論を思いつく人も多いだろう。しかし、この定義によりもっと具体性がある設計方針として、テストを考える。テストの視点によってオブジェクト指向を再定義したい。キーワードは、Eon(Ease of Testing)、テスト容易性だ。 ぼくは、 EoT(*1)の高い設計が、よいオブジェクト指向設計である。 と主張する。設計品質の中で「テスト容易性(EoT)」を最上位と見るのだ。オブジェクト指向のさまざまな機構、用語、考え方は、すべて EoT のため、と捕らえられる。例えば、
KPTを使ったプロセス改善：An Agile Way：オルタナティブ・ブログ
ソフトウェア開発の繰り返し単位（イテレーション）ごとに、そのタイムボックスで行なったことを反省し、未来に生かせるように口に出してみる、という活動を行なう。これは、反省会、回顧、Retropective、Reflection、などと呼ばれる（ぼくは「ふりかえり」という言葉が好きだ）。 アジャイル開発ではこの「ふりかえり」が「KAIZEN加速装置」となる。 これを行なうときに使うフォーマットを写真に示した。ぼくはこれをKPT（ケプト）と呼ぶ（Keep/Problem/Try）。Alistair Cockburnから教えてもらったもので、ぼくはこのフォーマットのヘビーユーザー。 ホワイトボードが３つのセクションに分かれており、Keep（このまま続けること）、Problem（問題点）、Try（次に試してみたいこと）と名前が付けられている。全員参加のふりかえりミーティングを開き、そこで、今回のイテレ
「変更しやすい」ことが、良い設計 (EoC=Ease of Changing) - An Agile Way [ITmedia オルタナティブ・ブログ]
前回は、EoT(Ease of Testing: テスト容易性)によってよいオブジェクト指向設計を再定義したい、という表明をした。今回は、二本目のナイフを抜きたい。キーワードは、EoC(*1)(Ease of Changing)、変更容易性だ。 この記事では、 EoCの高い設計が、よいオブジェクト指向設計である。 と主張したい。設計品質の中で、「変更容易性(EoC)」を最上位と見る。 ここ10年のオブジェクト指向の最大の失敗は、「再利用性」をその最大の価値、として説明しようとしてきたこと。そして分かったことは、再利用がその努力コストに見合う効果がでることは極めて稀であること、また、テクノロジではなくソーシャルな活動が再利用に効くこと、さらに、コードの再利用ではなく、ナレッジの再利用（例えばパターン）の方が、まだ可能性があるということ（少なくとも2005年のコンテクストでは）。 再利用性では
マインドマップによる、ユーザ要望の聞き取り - An Agile Way
実際に、マインドマップを使って、顧客インタビューをやってみた。図書館の業務支援システムを題材に、本物の司書の方に、インタビュー。 最初に、聞きたいことの要点を、マインドマップで書いておき、その枝に聞いたことを追加していく。その枝（マインドマップ的には、BOI）は、 誰が使いますか？ どんな場面で使いますか？ 管理したいものは何ですか？ の３つである。そして、最後に宿題という枝を用意しておき、そのインタビューで出た宿題を追加する。この３つのBOIは、Who/When/What であると共に、 アクター ユースケース ドメインモデル になることを想定している。もちろん、完全にそうはならないが、ネタとして意識する。 マインドマップのコツとしては、最初から用意した質問の枝は、「下線」でなく「箱」をつかい、また「クリップ」アイコンで分かりやすくしている。宿題は、「おうち」アイコンである。このテンプレ
神様ルートクラスを嫌い、POJOを好む：An Agile Way：オルタナティブ・ブログ
ぼくがオブジェクト指向言語を勉強しはじめた90年ころは、「継承」という概念がとても流行っていて、継承によって「差分プログラミング」ができることがオブジェクト指向設計の再利用性の典型例のように言われていた。もちろん、こういう誤解は95年くらいには、みんなウソだと分かってきていた。 しかし、それでもときどき、 すべてのクラスの頂点のような「神様クラス」を作ってしまうことがある。 例えば、90年代の多くのC++オブジェクト指向データベースは、Persistenceのようなクラスを継承することで永続オブジェクトとなるクラスをマーキングしたり、あるベンダーのコレションクラスは、Objectというクラスを継承したクラスのオブジェクトのみがコレクションの要素となることができたり、という具合に。また、EJBも最近まではEntityBeanを継承することでEntityBeanの資格が得られるし、Servel
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
