アジャイルを低コストで簡単に


評価:
Peter Merholz,Brandon Schauer,David Verba,Todd Wilkens
オライリージャパン
¥ 1,890
(2008-10-27)
コメント:「予測不可能な世界」で最高の「サービス」を作るためのネタ本。
Subject To Change の7章「アジャイルアプローチ」の一節「反復プロセスを安価で容易」から。

ソフトウェア開発の世界

◎基盤を固める(ハード、ミドル、フレームワークあたりまで)
◎バージョン管理 ( subversion を活用する)
◎継続的な統合 ( antを活用する )

この三つが整えば、反復が楽にできる。(簡単・低コスト)

ハードの試作

◎充実したツールキット
◎簡略化した試作プロセス
◎さまざまな精度で試作するための実ツール

ツールキットは、ソフトでも重要。

個人の体験

◎経験豊富な人員
◎意識的に少人数

経験豊富な人員は、成功体験も失敗体験も豊富。
ソフトウェアの世界だと、パターン(とアンチパターン)が最近は出回るようになってきた。
パターンを本で読んでもあまり効果はない。
実践してみて、一回経験すると、十回分の経験に相当するくらい効果がある。

「経験不足」を パターン+一回実践 で、だいぶ補える。

ただし、その一回の実践が「成功体験」にならないと、だめ。やっぱり経験豊富な人材のガイドやアドバイスに価値がある。

--

基盤・バージョン管理・継続的統合も、経験豊富な人材がいれば、すぐ立ち上げることができる。
経験がないと、悪戦苦闘。

豊富なツールキットを、経験豊富な人材は、縦横無尽に駆使できる。
経験がないと、ツールの多さと使いにくさに悪戦苦闘。

パターン集も、経験豊富な人材は、瞬時に理解し、さらに応用して活用する。
経験がないと、意味不明で、悪戦苦闘。

立ち上がりの時に、経験豊富な人材がうまくガイドとサポートをすれば、経験不足なチームもジャンプスタートができそう。

「システムイネーブラー」というのはこういうジャンプスタートを現場で実践的にアジャイルにやるための部品、ツール、ネタなど。もちろん、人材も。

このブログも、そういうネタ集にちょっとでもなれれば、と思っています。


単純にする

システムを作るときの三つの関心事。

・網羅性
・整合性
・単純性

伝統的なシステム開発方法論は、網羅性と整合性に重点がある。
アジャイルな開発方法論は、単純性に力点がある。

単純に考える、ということをネットで検索していたら、こんなページを見つけた。

The Four Laws of Simplicity, and How to Apply Them to Life

四つのステップで、単純化する。

1.Collect 集める
2.Choose 選ぶ
3.Eliminate 捨てる
4.Organize 組み立てる

Collect 集める

関係ありそうなことを、とりあえず一か所にあつめる。
広いテーブルの上に集めるのが良いらしい。

システム開発だと、さまざまな要求事項の収集かな?

Choose 選ぶ

本当に重要なごく少数のものを選びだす。
これは、かなり難しい。
関係者が多いと、おそらく、合意は難しい。
まあ、だれかに「まかせた」とやるしかないかな?

良いシステム設計の基本は、おそらく、この、ほんとうに重要なごく少数のことを「選ぶ」こと。

ユースケース候補が、100とか200とか集まってきた中から、ほんとうに重要な5つを選べといわれたら、かなり大変。

でも、中核の5つのユースケースを見極めれば、システム全体の構造、開発の段取り、人の割り当てなどが、ともて簡単に決まってくる。

Eliminate 捨てる

これも、難しい。
「捨てます」「やりません」「いりません」とぶっきらぼうにいったら、トラブルの種かな?

まあ、私は、とりあえずの置き場所、たとえば、次のリリースの要求リストとか、検討リストとか、名前をつけて、そちらに回すようにする。

別の入れ物をつくって、とりあえずそっちに詰め込んでしまうことで、実質、捨てたのと似た効果を期待できる。

捨てきれなかったことで、後で不発弾として突然爆発、というリスクはあります。
可能であれば、廃棄しておきたいんですが。

Organize 組み立てる

集めて、選んで、捨てた。
あとは、残った重要な要素を、どうやって組み立てるか?

原理は簡単。

・関係するものを集めてグループにする。
・グループの間を空ける。

ソースコードだと、3行くらいをひとつのグループにして、空行でグループの区切りを表現する。

図や表でも「空き」を使って、グループ間の区切りを表現する。

システムでも、システムとシステムの間に「空き」を設けて、区別する。

組織化の基本は、「グループにする」ことと「間を空ける」ことです。

まとめ

集め上手  集め下手
選び上手  選び下手
捨て上手  捨て下手
組み立て上手 組み立て下手

私はどんなんだろう?
あなたはどうですか?

短い納期の仕事って、実はやりやすい。

集める時間がない
重要なことだけ選んで、あとは捨てざるを得ない。
結局、残った部品は少ないので、組み立ても簡単。














全体イメージ:プロジェクトの副題

システムを作るとき、全体イメージがわかる言葉や絵が欲しい。

いろいろな立場の関係者が集まって話をする時に、共通のイメージを表す、言葉と絵がとっても役に立つ。

システム名とかプロジェクト名がかなり大切。
問題は、最初のアイデアの時の名前をずっと引きずることが多い。どこかでちゃんと名前をつけなおしたほうがいいんだけど。

最低なのは、コード名とか、比喩を使ったプロジェクト名。サムライプロジェクトとかいっても、何やりたいかまるでわからない。雰囲気や勢いが好きなんだろうけど、実践的ではない。
でも関係者の中には、こういう名前が好きな人も多い。

実践的なやり方。
名称を議論をしていてもしょうがないので、議論の対象にしない。
さっさと「求人企業向け求職者データベースサービス」とか、何を作るかの手がかりが多い「副題」を作る。こっちは関係者の意思疎通にはるかに役にたつ。たった4つか5つの言葉だけど、この副題の議論は、かなり実りが多い。
目的とするシステムの本質を共通理解する道具になる。

副題は、しょっちゅう変更することが大事。
プロジェクトが進めば、より目的や手段が明確になる、あるいは、方針の変更があったりする。
こういう時に、副題をこまめに変更し、関係者への通知を徹底する。

「副題」という名目で、プロジェクトの中核の考えを、関係者でいつも共有するようにする。
副題を変更してみて、異論がでてくれば、大成功。考えていることが違いを発見できたわけだ。

名前は、識別のための情報。
副題は、説明のための情報。


この 識別用の名前+説明 ( Name + Description ) というのは、情報を扱う基本パターンですね。

REAモデルの Identification パターンと Description パターンの応用です。

絵を描く。台本を書く。

モデルの表現手段としては、絵画や設計図のように「絵」や「図」がある。
もうひとつは、言葉・文章である。

絵(図)のほうは、粗い段階からはじめると、

・略図(ラフスケッチ?)
・構図(全体の配置)
・下絵(実寸の線画)
・原寸模型(モックアップ)

のようになる。

コードは、

・骨組み(スケルトン?)

を作ってから、詳細を書いていく。

あと言葉・文章表現ならば、

・粗筋(ざっと、しゃべるイメージ)
・筋書き(パンフレットなどにある、比較的ちゃんと書かれる)
・台本(詳細)

となって、最後は、
実演(スクリプト、コード)になる。

絵画や舞台の世界では、ここらへんの流れは常識なのかもしれない。(私は、そういう世界を知らないので確信はない)

ソフトウェア開発の世界では、大きな流れはどこでもいっしょだけど、作る順番、約束事、呼び方などは、みんなばらばらなような気がする。
まあ、開発方法論とか開発プロセスモデル、という形で提供されるものもあるけど、定番があるわけではなさそう。

少なくとも、私は、別プロジェクトで同じプロセスに出くわしたことはない。

略図から始まって、原寸模型へ、という流れや、粗筋から始まって、台本へ、という流れは、ソフトウェア開発でも基本のような気がします。

実践 ICONIXプロセス : 本家のトレーニング?

モデリングツール Enterprise Architect を販売している スパークスシステムズ ジャパンで、ICONIX社の代表を日本に呼んで、二日間のトレーニングを企画しているようですね。

代表の方のブロッグの記事

トレーニングの詳細

興味がある方は、アンケートに協力をしましょう。

うちからも何人か参加することを検討しています。(ちょっと高いのがつらいが、せっかくの機会なので)

自分でやるなら  教えるなら

自分でやるなら、XP というか、ホワイトボート使いながら顧客とおしゃべりしながらやるかなあ。 毎日、分析・設計・コード・テストというリズムは好きですね。技術の話より、お客さんのビジネスや業務の話すの好きだし。

ICONIXプロセスでいろいろ知識と経験を積めば、今の若いメンバーたちも XP 流でやれる力量を持ってほしいと思う。

業務用語がほとんどキャッチできない。要件定義のポイント、モデリングの基本パターン、設計の常識、フレームワークの使い方、どれも怪しいメンバーを、いきなり XP 流の世界にというのは、やっぱり躊躇します。

特に、業務用語を聞きとって理解する訓練が足りない。その訓練には、 ICONIXプロセスのドメインモデリングが効果があると実感している。

・どんな言葉をドメインの用語ととらえるか?
・用語(概念)と用語(概念)の関係は?
・今の問題領域の中核は?

絵にしてみると、面白いように、理解の違いが浮かび上がってくる。

実践 ICONIXプロセス : 要件定義

ICONIXプロセスでは、要件定義の主な活動は次の3つ。

● ドメインモデリング (用語集:概念クラス図)
● ユースケースモデリング
-- ユースケースパッケージ図とユースケース図 (機能体系、メニュー体系)
-- それぞれのユースケースの記述
● 要求レビュー (関係者で集まって認識あわせ)

要件定義のための情報収集は、

・画面の紙芝居
・要求の箇条書き
・業務マニュアル

などをあげている。

また、要件定義の初期の作業で、既存システムの調査もあげている。

・既存画面の調査 (ユースケースモデリングの参考情報)
・既存テーブルの調査 (ドメインモデリングの参考情報)

何度も書いている通り、要件定義は、ウォーターフォール系のやり方と本質は同じ。ウォータフォール系のやり方では、もっと細かく手順や書式を決めているけど、やっていることを(乱暴に?)要約すると ICONIXプロセスになる。

ウォーターフォール型の開発プロセスの手順や書式を勉強するのは良いことだと思います。いろいろ参考になる点がある。フルセットで完全に実施する価値はないと思いますが、自分たち流にカストマイズして軽量プロセスでやることは意味があると思います。 Unified Process (UP) は、最初から、カストマイズすることを前提にしているみたいですね。 自己流でトライアンドエラーするより、何か参考になるものをうまく流用したほうが楽ができます。

XP は、クラス図を描けとか、ユースケースを記述せい、とは言っていないけど、必要に応じてやっている。 Kent Beck は、XP では、プロジェクトの最初から最後まで、毎日、要求分析と設計をする。 一日のうち4時間は、分析や設計だといっている。 コード書くのは30分以下らしい。 のこりの3時間ちょっとは、テストと(チームメンバーへの?)サポート。 

XP では、顧客がチームメンバーだから、毎日が要件定義の日々らしい。
XP の要件定義の最初のインプットは、短文のユーザーストリー。 一件一枚のカードに書く。典型的には50枚から100枚くらいらしい。

これって、顧客からの要求の箇条書きだし、もうちょっと形式的にソフトウェア要求仕様書とかと同じものですよね。

参考: http://ootips.org/xp.html

XP, ICONIX, ウォーターフォール系 : 要件定義 詳細化

ウォーターフォール系の要件定義の詳細化は、簡単には書けないです。ドキュメント形式だけでも20種類あったりするので。 まあノリは違いますが、やることの目的や本質はアジャイル系といっしょだとは思いますが。

画面の詳細

画面のスケッチが要件定義の詳細の重要な手がかりですね。

XPだと、ユーザも同じ部屋にいるので、ホワイトボードにスケッチして、HTMLでプロトタイプを作っちゃって、細かいところは話ながら決めたり、直したりしていく、という感じでしょうか? (ひとりで作っているときも、ぶつぶつ言いながら、こんな感じかな)

ICONIXは、手書きで紙や線画(のファイル)として参照可能にしておく、という感じですかね。 まあ、XPとはそんなに違いはない。

ウォーターフォール系だと、画面定義の書式、記述ルール、作成の作業手順など一通り決まっている。

どのやり方でも、画面な詳細な模型は、要件定義の必須情報ですね。

機能の詳細

処理手順は、言葉で書いたり、画面の遷移で説明したりする。入力データの妥当性検証などは、基本は言葉で書く。

XP だと、妥当性検証は、受け入れテストケースとして書く。

ICONIX だと、ユースケース記述の「代替コース(雨の日のシナリオ)」として書く。代替コースは、そのままテストケースなので、これも XP と似た感じですね。

ウォーターフォール系だと、ビジネスルール一覧とか機能仕様書とかでまとめていく。テスト仕様書の情報元という点では、XP や ICONIX と本質的にはいっしょですね。

データ項目の詳細

XP や ICONIX だと、クラス図を詳細化していく作業。 XP は、レビューは動くソフトウェア、ICONIX は、クラス図をレビューする。 XP も ICONIX も、クラス名や属性名は、問題領域の「用語」が中心なので、ユーザも理解できるし、レビューできる。

一つ一つやっていく

XP や ICONIXプロセスは、ユーザストーリやユースケースを一つ選んで、要件定義を詳細化し、実装までやってしまいます。 で、これを繰り返す。

ウォーターフォール系は、全範囲を同じレベルで詳細化を進めようとする。でも、一つ一つの機能単位で要件の詳細確認という点では、XP や ICONIX と基本はいっしょだと思います。
作るドキュメントの量は違うかもしれないけど。

要件定義書

XP や、ICONIX プロセスでは、形式の定まった要件定義書は書かないですね。
XP は、ソースコード(含むテストコード)以外は特にない。

ICONIXプロセスは、要件定義の結果は、ドメインモデル(クラス図)、ユースケースパッケージ図、ユースケース記述をしっかりと作る。 また、変更があれば更新する。必要に応じて、メモ書き、画面の模型などを要件定義の資料として作成する。
関係者で要求レビューをやって、共通理解にすることを必須の手順としている。
(書く内容や書き方は、とっても実践的)

ウォータフォール系のやり方だと、要件定義書は、書式、記述項目、レビューと承認手順がかっちり決まっている。(かなり形式的)

まあ、私の感覚だと、ウォータフォール系のやり方で定義している要件定義作業とアウトプトの本質部分だけを集中的にやるのが、ICONIX プロセスだと思います。
XP だとホワイトボードなどは使うけど、ドキュメントにはしないで、プログラミング言語で要件定義を記述していく感じですかね。

要件として確認すべきことは同じなので、やっていることは、どの方法論でも本質はいっしょだと思いますが、実際にやる作業はずいぶんと違いますね。

XP, ICONIX, ウォーターフォール系 : 要件定義 用語集(概念モデル)

XP, ICONIX プロセス、ウォータフォール系の要件定義で、画面の模型を作るのは、三つとも共通。

機能については、表現の方法が、
XP : ユーザーストリー ( のセット )
ICONIX : ユースケースパッケージ図
ウォーターフォール系 : 業務機能一覧、アプリケーション機能一覧など
など異なる。

まあ、どれも結局は、画面にすると、メニューになることが多いので、本質的には同じことをしているんだと思う。

概念クラスモデルと概念データモデル

アジャイルというか、オブジェクト指向系のやり方だと、要件定義では、概念クラスのモデル(模型)を作る。
ウォーターフォール系の要件定義では、「概念データモデル」とか データ指向のアプローチ (DOA) が多いと思う。

データモデルは、Entity ( 実体 ) と Relationship (関係) に注目する。クラスモデルは、Entity も対象にするが、それ以外の概念、例えば「口座振替」のように手続きのかたまりもクラスとしてモデル化することがある。

もっとも業務的には「口座振替」という手続きを実行した記録を残すので、これも Entity としてモデル化できる。

ようするに問題領域の用語集

私は、概念クラスモデルと概念データモデルが本質的に違うものだとは思っていません。問題領域の知識として用語(概念)を洗い出して、その関係を描けば、似たような図になるのが自然だと思っている。 あまり違ってしまっては困りますよね。同じ問題領域なのに。

ICONIX のようにドメインモデルとは問題領域の「用語集」である、というのが実践的な発想だと思う。

要件定義で重要なことは、役に立つソフトウェアの具体的なイメージを関係者で共有すること。
役に立つソフトウェアは、問題領域の正しく深い理解から生まれる。そのためには、問題領域を説明する「用語(概念)」を正しく捕まえること。

そのやり方は、クラス図でもER図でも用語集でも、どれでも良いと思う。
前に書きましたが、50音順の用語集よりは、クラス図なりER図のほうが、より豊かな情報を提供できるとは思います。(理解の不一致を見つけやすい)

ICONIXプロセスの本「ユースケース駆動開発実践ガイド」では、ドメインモデリングとデータモデリングは違うということは、結構こだわっているようですが。

XP, ICONIX, ウォータフォール系 : 要件定義 一度にひとつ

ある程度の全体像がつかめたら、その次はどうするか?

アジャイル(機敏)なやり方

XP や ICONIX のようにアジャイル系のやり方は「一度にひとつ」のことを具体化していく。 一つのユースケースを、要件を詳細に確認しながら、実装しリリースまでしてしまう。で、次のユースケースを一つ選んで、また要件の詳細確認・実装・リリース。繰り返し(イテレーション)ですね。

詳細な要件の確認と実装は短い時間でやるから、その間に要件や要件の前提条件が変わることはない。
「一度に一つ」片付けていくから、それぞれのユースケースの要件の詳細は、実装直前の要求や条件を反映できる。

全体の進捗は、実際に使える機能(ソフトウェア)の量で確認できる。

ウォーターフォール系のやり方

全体を「一度に一段階ずつ」具体化していく。
概要から一段階ずつ詳細化していく。
概念から一段階ずつ物理実装に近づけていく。 

全体をカバーするために、最初は小数のメンバーで概要を、詳細化が進むにつれ、メンバーを追加して、全体が同時に進むようにする。
スケジュールの前半は、動くソフトウェアはどこにもない。ドキュメントだけ。最終日に一斉にすべてのソフトウェアが動きだす。

縦か?横か?

XP や ICONIX の要件定義は、ある程度の範囲を決めたら、ここぞと思う場所を一気に掘り下げる。井戸を縦に一本掘ってしまう感じ。それが終わったら、他の場所で、井戸を毛一本。

ウォーターフォール系の要件定義だと、範囲全体を1メートルずつ段階的に掘り下げていく感じ。地層を一枚ずつはがしていく感じかな?

変化に機敏(アジャイル)に対応する

アジャイルなやり方を実践していることが多いのは、一般消費者向けのインターネットサービスのためのソフトウェア開発だと思います。

この世界、何がほんとうに消費者の満足につながるか誰も予見できないし、競争環境や技術環境の変化も予見しにくい。つまり、要件定義が難しい。

大まかな構想を決めたら、XP や ICONIX で「一度に一つ」ずつ要件固めてリリースまで持っていく。結果を見て、途中で、構想自体を変えるのも当たり前の世界。

変化へのすばやい適応能力が勝負どころになる分野、変化が予見しにくい分野では、アジャイルなやり方のメリットが大きいと思う。

重装備で準備をはじめちゃうと、身動きが取れなくなる。途中で大きく方針変更したり、中断する場合のダメージも大きい。

calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM