要求開発にて”「これだけ」モデリング”：An Agile Way：オルタナティブ・ブログ
これだけモデリング！というコンセプトで、山岸さんが話された5/28の要求開発定例が面白かったので紹介します（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。 情報システム部門目線で見て、どんどん複雑になるアプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性が今回テーマです。そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなかペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 （※6/5 追記： 以下に、当日の資料を公開します。） これだけモデリングとは、 誰が？ ー 情報システム部門の人（と開発の人が共に） いつ？ ー システム開発の前段階、すなわち「要求開
デブサミで、『インパクトマッピング』のお話をしました！：An Agile Way：オルタナティブ・ブログ
Impact Mapping from Kenji Hiranabe 今日、11年目のデブサミにて、「インパクトマッピング」の講演をしました。その資料をアップロードします。 インパクトマッピングは、イギリスの Gojko Adzic (『Specification by Example』の著者)の近刊です。 製品やWebサービスを開発するとき、ビジネス企画の意図をどのように開発に伝えますか？仕様書を書く？それで伝わりますか？ビジネスの変化に追従できますか？ インパクトマッピングは、ビジネス視点と技術視点、さらにはデザイナーという異なる文化をもつ人間どうし会話をするために、目標とそれを達成するための仮説をビジュアルにマインドマップで表現して、企画の意図を共有します。 中心(WHY) = ビジネス目標。 第一レベル(WHO)＝アクター。目標を達成するために、誰に働きかけるか。 第二レベル(HO
Impact Mapping：An Agile Way：オルタナティブ・ブログ
書籍、『Impact Mapping』を訳しました！ この本は、2012年のJolt Awardをとった"Specification by Example"を書いた、Gojko Adzic 氏の最新作なんです。 日本ではまだあまり知られていませんが、Gojkoさんは、アジャイル開発とビジネスの意図をつなぐ手法を啓蒙しています。 前作、「略称: スペック・バイ・イグザンプル」"Spec. by Example" では、「例(Example)」でもって仕様(Spec.)を記述することがテーマ。これによって、テストだけでなく、ドメインの言葉で開発とビジネスをつなげることを模索しています。ATDD(Acceptance Test-Driven Development)という言葉で語れていたものを、より具体的に書いた力作です。 そして、今回のこの本、『Impact Mapping』(インパクト・マッ
『リーン開発の本質』のあとがき。日本のアジャイルをつくりたい。：An Agile Way：オルタナティブ・ブログ
わけあって『リーン開発の本質』を再読しています。る。日本の中でアジャイル開発を、できるだけ管理者の言葉として伝えたかった本です。この本は本当にたくさんの人に読んでほしいなぁ。ここに、そのあとがき、として書いた文章を掲載します。 最後に書いた、 多くの間違った標準化が、「人は本来怠け者でありしっかり働かせるために規則を作らなければならない」とか｢人は交換可能である｣というメンタリティから発している。もし、組織の文化や方針の中心にこのような考え方があると、もしくは多くの管理者がこのように考えているならば、「決して」リーン活動は成功しない。そうではなく、「人の持つ工夫のモチベーションを活かす」こと、「一人ひとりの人を育てる」ことこそ、マネジメントの中心となるべきだ。「人」の要素はプロセスの中心である。ここをやり間違えてはならない。 日本のソフトウエア業界が、人の持つ知恵と力を大切にしながら、高品
オブジェクト指向の開放/閉鎖原則：An Agile Way：オルタナティブ・ブログ
Open/Closeは、変更の論理を、追加の論理にすり替える、ということなのだけど、ぼくがコンパイル言語特有と言ったのは、Close=触らない=固められる、ということが名前にまで影響していると気づいたからです。それが、ポリモフィズム、あるいは動的束縛のトリック。
アーキテクチャとは？ Grady Booch によると。。。：An Agile Way：オルタナティブ・ブログ
アーキテクチャとは何だろうか？この問いはいろいろな人に聞くといろいろな答えが返ってくるので、「リクルートの面接時に必ず問う」という人もいるはずだ。ソフトウェアと分野に限らなくてもよいし、さらに、システムという分野に限らなくても答えられる。 ぼくの知識の中で、もっともらしいと思われているのが幾つかある。 IEEE1471のアーキテクチャに関するコンセプチャルなフレームワーク これは、図のようなモデルで表現される。これは、かなりフォーマルに「アーキテクチャとは何か？」に答えているようだ。システムには１つのアーキテクチャがあり、１つ以上のアーキテクチャ記述によって記述されており、１つ以上のビューとモデルを含み、ステークホルダと関連している。ステークホルダは１つ以上の関心事をもっており、１つの視点は１つ以上の関心事をカバーしている。。。。。。」と読む（読めるか？）。 RUP RUPは、それ自身、「
データモデリングなきアジャイル開発は危ういか？：An Agile Way：オルタナティブ・ブログ
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
スクラムの原典を読み解く(2)：An Agile Way：オルタナティブ・ブログ
不安定な状態を保つ 最初に綿密な計画書や指示があるわけではなく、チームは自由な裁量と同時に、困難なゴールを目指す。 オリジナルでは... 新製品開発は、トップマネジメントが不可能なくらい大きな目標を掲げてキックオフする。そこでは、明確に記述された新製品のコンセプトの企画書や開発計画書が手渡されるわけではない。逆に、簡単には出来そうもないくらいチャンレジングな課題が与えられ、その代わり、やり方はチームに任されている。新製品開発は、「計画どおり実行すれば完成する」というような計画書ベースの活動ではなく、最初から不安定な活動だと言えるだろう。チームメンバーには高い自由裁量と同時に、極端に困難なゴールが与えられる。これがスタート地点となる。 アジャイル開発では... このような新製品開発における不安定さは、開始時に要求が決定していないアジャイル開発のモデルにも当てはまる。ソフトウェア開発はプロジェ
野中郁次郎先生と、スクラム、アジャイル、パタン言語、知識創造についてお話しました。：An Agile Way：オルタナティブ・ブログ
野中郁次郎先生を一橋大学に訪問、アジャイル、スクラム、創造、マネジメントについてディスカッションする機会を得ました。 先生はもちろん、ナレッジマネジメント、知識創造経営、そして、Scrumという言葉を生んだ、「The New New Product Development Game」という1986年の論文の著者の一人。もう一人は現在ハーバードの竹内さん。一昨年の AgileJapan 2010の基調講演、昨年は、Jeff Sutherland との対談が Innovation Sprint で実現、ハーバードの竹内さんのクラスにJeff Sutherland が呼ばれたりするなど、アジャイル会との交流が進んでいます。 ぼくが持ち込んだ、顧客を巻き込んだ、見える化された職場のワークスタイルの写真なんかを見ながらお話ししていたら、 PDCAって日本人大好きなんだけど、これは本当に欲しいもの、い
ペア・プログラミング：An Agile Way：オルタナティブ・ブログ
アジャイルのプラクティスを、もう一度解説して行きたいと思います。できるだけ、日本の文脈にあった内容を加えて、実践できるように。また、野中先生に後でコメントを頂く予定。 ペア・プログラミング 文字通り、2人一組になってペアでプログラミングを行う。XPでの１つのプラクティスに挙げられており、１台のPCを交互に使って行うのが基本形。昨今ではデュアルディスプレーを使ったり、ネットワークと画面共有を使ったりして遠隔地で実践しているチームもある。 コーディングは単純作業ではない。１つ１つの変数や操作の名前を決めることや、その構造、アルゴリズムにいたるまで、多くの設計判断が入り込む、クリエイティブな活動である。また、ミスが起こりやすい作業でもある。刑事やパイロット、スキューバダイビングなど、リスクが高い作業はペアで行うことは現実の世界にはたくさんある。二人でプログラミングを行うことで、リアルタイムにレビ
日立技術研修所にて、「ソフトウェア・アーキテクトへの道」セミナーの講師をしました。：An Agile Way：オルタナティブ・ブログ
12/15、日立の技術研修所にて、「ソフトウェア・アーキテクトへの道 –アーキテクト自らが語る、今日の自分を形成した学習と経験-」と題した研修の講師をさせていただきました。 今回は、日立情報制御ソリューションズ渡辺滋さんのとってもおもしろい企画です。講師陣は、ビースラッシュの山田大介さん、メタボリックスの山田正樹さん、東海大学の清水尚彦さん、グロースエクスパートナーズの鈴木雄介さん、そして私の5人で、5人が自身の経験とアーキテクトとは何か、を語るという趣向です。 ソフトウェア・アーキテクト、または、ＩＴアーキテクトという職種、称号は、最近、よく話題にのぼります。あるプロジェクトが開発する製品、システムの全体像を把握して、そのソフトウェアの基本設計、方式設計をするプロジェクトの最高技術責任者といった意味で用いられることが多いようです。しかし、実際にアーキテクトの活躍を目の当たりにする機会も
Lean Startup リーンスタートアップ解説(1)：An Agile Way：オルタナティブ・ブログ
サンフランシスコ周辺で最近大きな話題になっている、リーンスタートアップ、について、簡単に導入解説したいと思います。 これによって、アジャイルは「既存の組織改革」という１つの出口から、「新しい起業の創業（スタートアップ）」という、もう１つの大きなビジネスホームグラウンドを見つけたように思います。 この資料は少し古くて、2009年に Eric Ries が Web2.0. Expo にて発表したものの一部です。オリジナルスライドはこちら。 「ウォーターフォール」、「アジャイル」、そして「リーンスタートアップ」、という３段階で説明していきましょう。 ウォーターフォール型の製品開発モデルでは、問題が既知で、解法も既知、という前提にたっています。計画したことが計画通りにうまくいけば、それでOKという世界観です。 ここでの進捗単位は、工程を１つ進む、ということ。となります。計画駆動の進め方です。 これ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Lean Startup リーンスタートアップ解説(2)：An Agile Way：オルタナティブ・ブログ