実行可能知識 チュートリアル

実行可能知識っていきなり言われたってね.

じゃあ, もっとベタに具体的に実行可能知識って何かってことを書いてみますよ.

というわけで, チュートリアルを書き始めました.

よけいわかんねえって?

そのうち分かる日が来るよ... なぁ, タマ...

仕様書の書き方

ISSEC で仕様書の書き方について講義しました. そのスライド (PDF, 1MB) です.

最終的にはIEEE Std. 1362 (ConOps), 830 (SRS) に落とすのですが, そこはこちらとこちらを見てください. クラシックかもしれませんが, まだまだ学ぶべきことはありますよ. ちゃんと優先度を付けなさいとか, ユーザのニーズ/顧客の期待から書き下ろしなさいとか. ちゃんとそうやって書いているところは意外とないんじゃないかな.

スライドの方はそこに至るプロセスを中心に書いています.

セル生産+アジャイル

@IT 連載第8回, 「セル, 制約, 価値, アジャイル」シリーズの「セル生産+アジャイル」が公開されました.

これだけではなんなので, ソフトウェア・セル生産方式のリンク集.

• 
  松本先生のWebサイトから
  
  
  
  
  • セル生産方式ソフトウェアファクトリ [pdf]
    
  
  
  
  • ソフトウェア・セル生産 [pdf]
    
  
  
  
  • ソフトウェア・セル生産のキーポイント[pdf]
    
  
  
  
  • ソフトウェア・プロダクトラインとソフトウェア・プロセスライン [pdf]
  
  
  
  



• 萩原さん@MSにとってのソフトウェア・セル生産 (+ ソフトウェア・ファクトリ)
  
  
  
  
  • 第8回 ソフトウェア工業化の未来
  
  
  
  



• 山田@メタボリックスにとってのアジャイル・ソフトウェア・セル
  
  
  
  
  • Cell as an Object
  
  
  
  



• 本来の (製造) セル生産方式
  
  
  
  
  • (例えば) セル生産方式/岩室宏
  
  
  
  

ソフトウェア・セル生産はまだまだ発展途上の概念ですから, まだまだ多様であっていいのでしょう.

第 25 回ソフトウェア品質シンポジウム

日科技連の第 25 回ソフトウェア品質シンポジウム (東京有明 TFT ビル) の招待発表で「アジャイルがもたらす天国と地獄」という講演をしてきました.

ご来場の皆さん, 有り難うございました. スライドはこちら (PDF, 204KB) (実際の発表にはここにない情報もあったんですけどね:-)

アジャイルがうまくいかなかった例, うまくいった例を事後のインタビューを通して較べてみたものです. アジャイルかどうかにかかわらず, 皆さんのプロジェクトでプロセスを換えたときにこのインタビュー項目を使って自問自答してみるといいと思います.

自分の講演よりも, 僕の前の関さん (東芝) の発表内容が大変面白くて, 僕の講演でもだいぶ参照させてもらいました.

モデル駆動開発入門

9/4~5 の二日間にわたってモデル駆動開発の講義をしてきました. 資料はこちら.

ポイントは

• OMG の MDA だけがモデル駆動開発ではないし, 逆に MDA の中で開発は一部でしかない



• Django (Ruby on Rails と同じようなフレームワーク) からオントロジまで, モデル駆動開発を広い意味で扱っている



• Kennedy-Carter の iUMLite を扱っているのは日本ではあまりないだろう

といったところでしょうか.

# R on R ではなく Django を扱ったのは, Django の方が好みに合っているから, というだけのことです.

現時点ではモデル駆動開発はまだダメダメです. xUML 系を除けば現場で使う気にならないのも当たり前. xUML 系はコストがかかりすぎるし, いつの間にか MDA からははずれちゃったから主流と思われていない.

一方でモデル駆動開発自体は間違いなくこれから重要になっていくでしょう. ただし MDA 流のトップダウンで重量級のモデル駆動開発も多分そのうちに消える (大胆な予想!). 片や Django や R on R のようなボトムアップのモデル駆動開発, 片やプロセスやオントロジのようなアッパー･モデリングがキー概念です.

それより何より, ソフトウェアの産業構造そのものが変わらなければモデル駆動開発はあり得ない.

というような話を日経 BP の進藤さんにしました. 日経エレクトロニクス 2006.9.11号 (No.934) の「設計図がない」特集になっています. まぁ僕の発言がどの程度反映されているかはともかく:-)

Empirical Project Monitor

某筋からの調査依頼があって, EASE (Empirical Approach to Software Engineering) プロジェクトの EPM (Empirical Project Monitor) というツールを使ってみた.

うーん, 実に SRA (SRAも絡んでいる) らしいというか, 20 年くらい前も SRA で自分, こんなことをやっていたような気がしないでもないが, まぁ時代は変わる. 今風だ.

基本的には CVS (バージョン管理), GNATS (バグ管理), Mailman (メイリング・リスト) を集めて, そこからいろんなデータをリアルタイムで (つまりプロジェクトの終了後ではなく), 取り出して分析するというもの.

た だ今どきとしては, CVS / GNATSに縛られるのはきつくないですか? Subversion とか Trac とか Bugzilla とかいろいろありますでしょ. どうせ縛られるのならいっそのこと, (例えば) GForge にプラグインするような形にできなかったかなとか, そういうインタフェース (API か SOAPプロトコルか何か) を切るのがまっとうそうな気もしたりする.

それから分析結果もリアルタイム性が売り物なら, Web でページをこそこそめくってみるよりは NASA のコンソールみたいになっていて, まずいことになると全画面が点滅してサイレンが鳴り響くとか.

勝手なこと言ってますが...

coLinux のイメージを使って, Windows でちょっと走らせてみました.

1. colinux を Windowsマシン (うちの場合は Windows 2000 Server SP4)にインストールする



1.1. http://www.colinux.org/ からたどってダウンロード (今回は 0.6.3 を利用)



1.2. coLinux-0.6.3.exe を実行して, インストール



注: 普通は c:¥Program Files¥coLinux にインストールされる



2. EPM をインストールする



2.1. http://empirical.jp/~epm/epm_beta.html からたどって coLinux 用イメージファイル版をダウンロード, 解凍



2.2. c:¥coLinux¥imgs というフォルダを作って, 解凍した中の img/*.img (二つある) をそのフォルダに移動



2.3. 解凍した中の EPM094.colinux.xml を coLinux のインストール・ディレクトリに移動



3. 起動する



3.1. コマンド・プロンプトを起動して, coLinux のインストール・ディレクトリに chdir し, colinux-daemon.exe -c EPM094.colinux.xml する



3.2. Cooperative Linux Console が立ち上がり, boot message が流れる. ログイン・プロンプトが出たら, root/empirical でログインできる



4. 設定する



4.0 は Windows XP の場合には不要. デフォルトの TAP のままでいいはず. 2000 の場合に必要.



4.0.1. Windows2000 の場合には TAP が使えないので, WinPCap をインストール (http://winpcap.mirror.ethereal.com/install/default.htm)



4.0.2. EPM094.colinux.xml を編集して network の行を次のようにする.

<network index="0" name="XXX" type="bridged" ></network>

XXX の部分は「マイ ネットワーク」を開いて普通は「ローカル エリア接続」になっているもの. 日本語でいいとはあまり思えなかったので, それを"LocalAreaNetwork" に変えて, それを指定.



4.1. LAN 内に名前と IP アドレスを用意してもらう (うちでは empirical/192.168.0.213). (ちなみに empirical 以外の名前にするにはあちこちをいじる必要があるので, ここでは empirical という名前にしてください. それから empirical の別名として empirical.localdomain も登録してもらうともっといい)



4.2. coLinux に root でログインしたまま, /etc/networks/interfaces を (vi などで) 編集. 編集するのは, address (上でもらった IP アドレス), netmask (管理者に聞いてください, うちでは 255.255.255.0 のまま), gateway (同様, うちでは 192.168.0.210)



4.3. 続いて /etc/resolv.conf を編集. 編集するのは nameserver (管理者に聞いてください, うちでは 192.168.0.207)



4.4. いったん再起動 (# shutdown -r now)



4.5. ネットワーク内の適当なマシンから http://empirical/ にアクセスして, EPM on coLinux というページが表示されれば OK.



5.0. プロジェクト分析結果を見る



5.1. http://empirical/epmtools/index-j.jsp にアクセス. プロジェクト分析結果を見るほかに表示の時の設定やデータ (コード, バグ・レポート, メイルなど) のバックアップなどの管理もできる.



5.2. デモ的な画面を見たければ, sample_prj というサンプルのプロジェクト・データがあるので, ツール実行 | Analyzer リンク | 左フレーム内ラジオ・ボタンを適当に選択 (特にグラフ選択の部分) | 選択ボタン | 右フレームの表示ボタンで, グラフなどが表示される



5.3. グラフの種類



グラフの種類としては次のようなものがある.



累積・未解決障害件数及び平均障害滞留時間

ソースコードの規模推移

更新時期とチェックアウト数の関連

メール投稿数と更新時期の関連

更新と障害件数

パレート図 (いろいろな関連が指定できる)



6.0. EPM を使う



EPM を使うとは, 要は EPM 用の CVS (バージョン管理), Mailman (メイリング・リスト), GNATS (バグ管理) を使うということだ. で, EPM の本来の仕事はそれらのツールのさまざまなデータを集めて, 見えるようにすること.



とりあえず sample_prj にアクセスできることを確かめてみる.



6.1. CVS



Eclipse を立ち上げて, File | New | Project | CVS | Checkout Projects from CVS | Next | Create a new repository ... | Next

host = empirical

repository path = /var/cvsroot/sample_prj

user = user01

password = empirical

connection type = extssh

Next | Use an existing module | sample_prj を選択 | Finish



6.2. メイリング・リスト



http://empirical/mailman/admin/ がメイリング・リスト管理画面. ここからいろいろなところに飛べる. (失敗したときには URL から.localdomain を外す)



メイルを読み書きするには, empiricalをsmtp, pop サーバとして使えばいいはず.



ユーザとしては user01 ~ user20 (パスワードはどれも empirical) がデフォルトで定義されている.



6.3. バグ管理



http://empirical/cgi-bin/gnatsweb.pl からいろいろなところに飛べる.



アクセス管理はない!? どんなユーザ名でも入れてしまう. View Problem Report # に1, 2, 3のいずれかを入れると見られる. 新規に作ることもできる.



というわけで, とりあえず動いているらしいということは分かった...

オブジェクトの西海岸派

UML VM 絡みであるプレゼンテーション (PowerPoint なので注意) を見ていたら, 「オブジェクトには西海岸派と東海岸派がある」などと書いてある. 東海岸派は「オブジェクトはプログラミングのための便利な道具」と思っている人たちで, クラス中心主義者. 西海岸派は「オブジェクトは考えるための道具」と思っている人たちで, オブジェクト中心主義者.

おお, 面白い, 便利じゃんと思ったけれど, 初めて聞いた. こんな言い方, するんですかね. これを書いている人はノルウェーの人なんだけど.

この区分で行けば, 自分はもちろん西海岸派だけど, 今の圧倒的多数の「オブジェクトでやっている人たち」は東海岸派だろう. C++ (New Jersey) は言わずもがな, Java (California) も東海岸派のものだ. それは構造化の手法であってオブジェクトではない, と敢えて言おう. だから今の「オブジェクトでやっているプロジェクト」のほとんどもそれを「オブジェクトでやっています」なぞと言って自滅するくらいならば, 構造化の手法をきっちり使ってやればいいんじゃないの. どうせその程度でしょ.

オブジェクトの良さはぜんぜん違うところにあるんだから. ま, そういう意味でオントロジ (西海岸派の隠し球ですよ) が少しずつ注目されているのはいいことかもしれない. そのうちまた乗っ取られちゃったりするかもしれないけど...

DEVONthinkを使った情報管理

うちでは, 外部の公開されている情報 (調査やなんかで見た Web ページや PDF ファイルや画像やそんなもの) はすべて DEVONthink Pro という知識ベースに突っ込んである.

何が便利かといって, まぁ何も考えずに突っ込んでも後でいくらでも検索や分類ができるところか. MacOSX では Spotlight というデスクトップ検索ツールが頑張ってはいるんだけど, こういう特定の使い方に関してはなかなか適わないと思う.

とは言っても, DEVONthink を使うのもなかなか大変であった. 何しろ高機能だし, 汎用性が高いし. で, 今ではこうなっている.

1. まず DVD サイズのディスク・イメージを作る. MacOSX ではこのディスク・イメージという奴は情報蓄積に大変便利なのである. このイメージいっぱいにデータが溜まったらDVD-Rとかに焼けばよい.



2. で, このディスク・イメージに YYYY/yymm/yymmdd という形のフォルダを掘って, その日に get した情報はみんなそこにどんどん突っ込む. ただしソース・コードやソフトウェアは入れていない (これは別の場所). 圧縮されたものは解凍する. 特定のアプリケーションのドキュメント (.ppt とか) はできれば PDF 化しておく. これは MacOSX では簡単なんで...
   
   
   
   
   1. なんでとりあえず日付というメタ・データでインデキシングするかというと, これがいちばん自明なインデックスであることと, NoteTaker に書かれたジャーナルと突き合わせると「前にこんなことを調べたはずだけどその時はどうだったっけ」ということがすぐに分かるのである.
      
   
   
   
   



3. DEVONthink からはこのディスク・イメージに対して, File | Index... するとファイルの実体はここに置いたまま, インデックスだけ DEVONthink 上に作ってくれる. 実体も DEVONthink に抱えさせてもいいんだけど, そうするとデータ量が増えたとき起動にものすごく時間がかかるのだ. 容量も際限なくなっちゃうし.
   



4. いったん索引を作ってし まったら, ディスク・イメージの yymmdd にデータを追加するたびに, DEVONthink からその yymmdd に対して, File | Synchronize すればインデックスは更新される. yymmdd の下にあるデータ量は大したことないからインデキシングはすぐに終わる.



5. DEVONthink では, いつでも簡単に全文検索ができる. PDF ファイルも最近はテキスト付きが多いし, MacOSX で簡単に作れる. それから簡単にフォルダ風の分類ができる. しかもファイル・システムとは違って, ひとつのファイルを複数の分類に入れることができる. だから何かの目的で get したものはその目的でグループ化しておけば, 後で使い回せる.

というわけで, 今の時点で約 3 年分, 4000 ファイルくらいがここに溜まっているわけだ.

見える化?

「見える化」「見える化」つったって, 今の「見える化」は「見せる化」というか, モノやプロセスの側がヒトによく見えるように工夫しようというもののわけで, ヒトの方がモノやプロセスをよく見えるようにならなくちゃという「見える化」じゃないんだよね.

ヒトの (動体) 視力を上げるのは簡単なことじゃない, と気付いたところから「見せる化」は始まっているんだけど, 「(ヒトの) 見える化」がいつかは必要になるはず.

じゃあどうしたら (動体) 視力を上げることができるか.

1. 「見えちゃった化」. 気づき. 本当は誰かいいコーチがいるといいんだろう. 本人の感度をあげる訓練も必要.



2. 「見たい化」. 欲望. あぁ, あれをもう一度見てみたい, という欲求が重要.



3. 「見える化」. 一度見えるようになるとそれ以外のいろんなモノも自然と見えてくる.



4. 「見ない化」. 一度見え始めるときりがなくなったり, 見ること自体の喜びで終わってしまう. これは見なくていいんだ, とか, 見たらどうすればいいかということが分かってくると本当の「見える化」.



5. 「見えない化」. もう見なくてもいい, というか, 最初からみんな見えているというか:-) 不射の射ですな.

VoodooPad 3

新しい本の原稿を VoodooPad で書こうと思って, 2 から 3 にアップグレード. ところが, だめなんだな, リモートのファイル･システムにおいたドキュメントを開けないのだ.

実は最近の MacOS X は CoreData と いうデータ (アプリケーションの操作対象) を扱うフレームワークを持っていて, バッキング･ストレージとして XML, SQLite, Binary を使うことができる. Binary は今までどおりオブジェクト・ネットワークをシリアライズしたもの. SQLite はオンメモリ / スタンドアロンの RDB にオブジェクト (クラス) をテーブル化して入れてしまおうということだ.

VoodooPad は多分 2 から 3 にアップデートするときに CoreData フレームワークに移行して, バッキング･ストレージを SQLite にしたんだろう. SQLite は速いし, 大量のデータを扱える. その代わりにちゃんとしたロック･プロトコルを持たないファイル･システム上に置くことはできない.

ほとんどのファイルをサーバに置いて, ノートブックを持ち歩いていろんなところで仕事をする僕には大変困った事態なのである.

格言: 「あちらをたてればこちらがたたず」

でもさ, クライアント=サーバの SQL エンジンならともかく, 普通のアプリケーションのデータ･ファイルをリモート･ファイル･システムに置けないってのは「ダメ」じゃないか.

ちなみに VoodooPad はデスクトップ Wiki システム. なんと言っても Wiki ワードを自動的にハイパーリンクにしてくれる. なかなか優れたアプリケーションではあるのだが.

キヌガサタケ

みごとなキヌガサタケ. 食べられるらしいんだけど... 迷う...

ソフトウェア開発は何ものにも似ている

ソフトウェア開発をあたかも建築のように考えてみる, とか庭仕事のように考えてみる, とか絵を描くことのように考えてみる. それによってソフトウェア開発のある側面に新鮮なアイデアをもたらす, というのはよくある手だが, その一方で, いや, ソフトウェア開発はソフトウェア開発なんだから, 他の仕事の比喩ではなく, ソフトウェア開発そのものとして語られるべき, という考え方 (「ソフトウェア開発は何ものにも似ていない」) もある.

ま, そりゃそうなんだが.

でも.

むしろ逆にソフトウェア開発とは建築でもあり, 庭仕事でもあり, 絵を描くことでもあり, ... ってこともあるんじゃないか. ソフトウェアが何ものでもあり得るのと同じように.

プロジェクトの尺度

ソフトウェア・プロジェクトの尺度 (生産性とかコード行数とか欠陥密度) をプロセス改善に使うときの問題点はいろいろあるんだけど, その一つに次のようなものがある. あるひとつの尺度をプロセス改善の目安にすると, その尺度を向上させることはできるのだけれど, 必ずしもプロジェクト全体は良くならない.

例えば, 個人の生産性を尺度にするとひとりひとりの生産性の平均は上がってもプロジェクト全体の生産性は落ちてしまうとか, 生産性を尺度にすると隠れた品質も含めた全体の品質は落ちてしまうとか.

それに対処する方法もいくつかある. その一つは尺度をひとつではなく, 複数にして多面性を持たせる. うまくいくこともあるけど, 結局は尺度が際限なく増えて, ソフトウェアを作っているんだか, 測るのが目的なのか分からなくなることもある.

別 のやり方として, ひとつひとつの尺度ではなく, それらを総合した全体的な尺度を使えばいいという考え方もある. そんな尺度はあるのか? すべての尺度と互換性を持ち, すべての尺度を総合した結果を表すような尺度が. 現代社会ではそれは「貨幣」と呼ばれている. 要するにそのソフトウェアがどれだけ稼げるかを問題にすれば, 「見えざる神の手」がすべての尺度のバランスをとってくれるのではないか, というわけだ.

しかし同時に貨幣という尺度はある規模を超えると非常に不安定で,  それ自身が自律した絶対的な価値になってしまうらしいことも分かっている.  例えば歌には売れた CD の枚数 (= 貨幣価値) とは違う尺度が必要なのだ (本来は).

NoteTakerを使った作業管理

NoteTaker は元は NeXT 向けの Notebook というソフトウェアで, もう10 年以上前からあるわけだが, 今でも他に類を見ない (実は同じく Notebook から分岐した似たソフトウェアもある:-) 画期的なキッチン・シンク・ソフトウェアだ. 2006 年 7 月現在での NoteTaker の使い方をメモとして記録しておく.

さて, ToDo/ジャーナル管理ツールとしての NoteTaker はこうやって使っている.

• 年に 1 冊の NoteTaker ドキュメントを作る. 例えば "2006".
  



• "2006" というセクションを作る. NoteTaker はマルチページ・アウトライナで, セクション, ページという階層で管理できるのだ.
  
  
  
  
  
  • このセクションの "2006" ページにはその年のビジョンを書く. ビジョンなので ToDo の形でなくてよい.
  
  
  
  
  
  
  
  • このセクションの "01" ~ "12" ページには "2006" を実現するための, あるいは実務的な各月の ToDo を書く. たいていは前の月から持ち越したものに, 何かが付け加わる感じだ.
    
  
  
  
  



• "01" ~ "12" セクションを作る.
  
  
  
  
  
  • 各セクションは "2006.04.03" というような日ごとのページと, 月曜日のページの前には "n-th week" という週ごとのページからなる.
  
  
  
  • 週ごとのページは, その週にやる予定のこと. かなり具体的で細かいはず. 週の頭に書く. 毎日チェックする. NoteTaker はアウトラインの各項目にチェックボックスが付くので, 終わったものはチェックを入れ, 新たに発生した項目は追加する.
    
  
  
  
  
  
  
  
  • 日ごとのページはその日にやる予定のこと. 多分週のをさらにブレークダウンしたものになる.
  
  
  
  • さらに日ごとのページにはその日にしたことをほぼすべて, するつど, 片端から書き残していく. 特定のプロジェクトに属さないアイデアや調査事項など成果物もすべて.
  
  
  
  



• NoteTaker を使わないもの
  
  
  
  
  
  • NoteTaker は日常作業, プロジェクト化されていない作業の管理に使う.
    
  
  
  
  • 特定のプロジェクトに関する成果物はすべて NoteTaker ではなく, ファイル・サーバ上の Working/プロジェクト名の下に置く. その一部として, 別の NoteTaker ドキュメントを使うことはもちろんあり得るが.
  
  
  
  • 自分一人だったり, もの作りでないプロジェクトの管理には BaseCamp を, ソフトウェア開発のプロジェクト管理には自分ちのサーバ上の XPlanner を使う.
  
  
  
  

ポイントは"連続性" (continuous-ness) だろうか. ある作業が (半自動的に) 次の作業を生むような仕組み.

"Getting Real"を読む

"Getting Real" は Ruby on Rails の開発者 37 signals による, 彼らなりのアジャイル. 本屋には売っていない. 彼らから直接 PDF で買う. なかなかいいビジネスだ. 要旨を日本語にしてみた.

仕事の作法 2006年版

メモ代わりに2006 年 7 月現在の仕事のスタイルを記録しておこうと思う.

毎日, 朝, MacOSX の Dock を上から順に (NeXTStep 時代からの習慣でうちでは Dock は右端に縦に並んでいる)

• Mail.app
  
  
  
  
  • メイルのチェック, 返事.
  
  
  
  • その場で返事を書けないものはフラグを立てておくと, ToDo というスマート・メイルボックスに入るようにしているから, ときどきこのメイルボックスを見ればよい.
  
  
  
  



• Safari (Web ブラウザ), NetNewsWire (RSS リーダ), gnus on Emacs (NetNews リーダ)
  
  
  
  
  
  • いつも見ている外部情報を巡回.
  
  
  
  



• iCal (カレンダ)
  
  
  
  
  
  • 今日しなければならないことをチェック.
    
  
  
  
  



• 
  NoteTaker (ノートブック)
  
  
  
  
  
  • 昨日の ToDo, 今週/今月の ToDo から今日の ToDo を作る.
  
  
  
  • 後は, ToDo を消化しつつ, やったことを NoteTaker にジャーナリングしていくことの連続.
  
  
  
  



• 
  DEVONthink Pro (知識ベース)
  
  
  
  
  
  • いろんな公開されている外部情報はすべて DEVONthink でインデキシングする.
  
  
  
  



• NoteTaker, CalendarMemo (ノートブック), OmniOutliner (アウトライナ), OmniGraffle (作画), NovaMind (マインドマップ), MagicDraw (UML), Eclipse (プログラミング)
  
  
  
  
  • が主な作業ツール.
  
  
  
  • いわゆるオフィス・スーツはほとんど使わないな.
  
  
  
  



• FireFox+Plone
  
  
  
  
  • で, その作業成果の中から, 公開できるものは FireFox を使って Plone に公開していく.
  
  
  
  • Safari じゃなく, FireFox を使うのは Kupu というビジュアル・エディタを使うため. 外部エディタとして, JeditX や Nvu を使うこともたまにあるけど.
  
  
  
  



• 
  BaseCamp, XPlanner
  
  
  
  
  • 以上は個人の日常的な作業管理だけど, 複数人数でのソフトウェア開発プロジェクトは自分ちのサーバ上の XPlanner で, それ以外のプロジェクトは BaseCamp で管理する.
    
  
  
  
  

メイルや Web, NetNews など決まった外部情報にアクセスするのは基本的に朝と夕方, 深夜の一日 3 回だけ.

Dock を上から順にクリックしていくのを, 一日 3 回繰り返すというのはミソなんである. これを Windows 上でやれ, と言われたら...... 廃業します.

Agile Development 2006 年春号

Agile Development 2006 年春号が出たので, 読んでみよう.

事例研究は 3 件. ひとつは BT (British Telecom, 日本で言えば NTT ですな). BT は業務/IT 分野でアジャイルへのシフトを行っている最中らしく, その中で EAI (Enterprise Application Integration) をやっているチームのアジャイル化の報告 ("Cooking up some Agile Planning"). もう一つはシーメンスで, Scrum と TOC (制約理論, 「ザ・ゴール」で有名な) を合体させたもの ("Agile gets Lean"). これは面白いかも. もっと詳しい話を聞いてみたい. どちらも超大手ですよね. やるところはちゃんとやってると.

"Checks and Balances" はアジャイル・プロセスにおける QA (品質保証) 部隊の役割について. 日本では QA というと一部の会社には「他に行き場所のない人のための部署」みたいなところもあるけれど, 本当にそれでいいの? Action Based Testing (ABT) というのがちょっと気になりますね.

"Take the XP Plunge!" (XP へダイビング!) を書いているのは Kent Beck と Cynthia Andres ("XP explained" 第2版の共著者). 「もう, もたもたしてないでやっちゃいなよ. 水は入っちゃえば気持ちいいよー」という記事です. 救命胴衣は

• XP Explained 第2版を読むこと (笑)



• 自分の学んだことをみんなと分かち合うこと



• みんなの前で「やる!」と言いきっちゃうこと



• どう変えるか, 計画を立てること

だそうです.

"Informed Consent" はアジャイルのための組織形態とは何かという記事. 今までの組織形態はアジャイル・プロセスとは合わない. "sociocratic" な組織 (すべての人が利益を受け取れるような組織) が重要だって. 「組織」はこれからとても重要な問題になるでしょう.

書評は "Behind Closed Doors" (「閉じられた扉の向こう側で」) と "Agile Estimating and Planning" (「アジャイルな見積もりと計画」). "Agile Estimating and Planning" はさっそく発注しちまいましたよ...

記事はどれも短め (平均 3 ページ程度) で, 物足りない感もあるんだけど, 論点は割と鋭い. Agile Alliance のメンバ ($100/年) になると読めます. 何ヶ月かすると非メンバにも公開されるらしい.