プログラミング C# - 翔ソフトウェア (Sho's)

こちら。

XP祭り2004に参加。

感想などはこちら。

XP祭り2004報告集は、あとの祭に。

• こんなXPerはいやだ

「こんな XPer (エクストリーム・プログラマ) はいやだ」と思うものを自由にあげていくテスト。

Industrial Logic 社 から Extreme Programming Playing Cards と Design Patterns Playing Cards を買ってみた．

※ 参照

# 日本語の情報でも探そうかと，"XPカード" で Web 検索をしたら，Windows XP 対応ハードウェアの情報ばかりヒットしてしまった．

INETA Japan Events! 『アジャイル開発ライブ! ～ 短納期、高品質、仕様変更への素早い対応を実現する開発手法をライブで解説!～』

マイクロソフト主催の「Tech・ED 2004 Yokohama」で、『アジャイル開発ライブ!』というのをやる予定。

アジャイル手法で抽選システムをその場で作り、その抽選システムを使って来場者に技術書籍や INETA からのノベルティをプレゼント。

9月9日(木) 18:30～20:00。

• Tech・ED 2004 Yokohama Welcome to INETA Japan Event!
• INETA Japan ―［ Tech・ED2004 Yokohama スペシャル・プログラム ］Welcome to INETA Japan Events！ ～ .NETに興味を持つコミュニティがおくるイベント ～
• 福井 厚のBlog ― INETA Japan Events! アジャイル開発ライブ! (予告)
• Studio Dragoon .NET Private Edition ― INETA Japan Events！ アジャイルライブ告知です

かのイラク戦争でも使用されたB2爆撃機。

随分とユニークな形状の飛行機である。
これには、垂直尾翼がない。

ステルス機である B2 は、レーダーに映りにくいように、レーダー波を来た方向に反射するような垂直な部位をなるべく無くしてある。

ところで、垂直尾翼というのは、飛行機が安定して飛ぶために欠くべかれざるもの、と聞いたことがある。
垂直尾翼が破損すると、通常の飛行機はダッチロールのような不安定な状態になる。
垂直尾翼があることで、飛行機はまっすぐ飛んでいられるのである。

では何故垂直尾翼のない B2 は安定して飛んでいられるのであろうか。

実は B2 は、CCV （Control Configured Vehicle) の一種で、垂直尾翼がない不安定な状態をコンピュータで制御することで飛んでいる。機体が傾くとコンピュータ制御により機体の傾きが補正されるのである。

つまり、安定して飛んでいるのではなく、こまめにフィードバックと補正を繰り返しているので、安定しているようにみえる、のである。

これってアジャイルだよね。

今、社内でソフトウェア開発プロセス改善のための試みをやっている。
できれば、もっとアジャイルに開発を進められるようにしたい、と願っている。

基本的には、

• 新しいアイデアを組織に導入するためのパターン

のようなアプローチが良いような気がしている。

で、今年度中に、社内で「大きなイベント (Big Jolt)」を一つやる予定。言うほど大したものじゃないが。

新しいことを取り入れようとするときには、やるべきかやらないべきかを議論し結論が出るのを待つより、実際に少しずつでも参加・体験してみて (してもらって)、そこからフィードバックを受けた方が良い。
つまり、ウォーターフォールでなく、アジャイルに進めるのが良い。

それにしてもこの取り組み、中々先に進まない。
何かが不足している。
解決方法を見出すことにばかり焦って、問題をきちんと分析しないのが原因なのか。

『Extreme Programming Explained: Embrace Change, 2nd Edition』 について、情報が出だした。
以下で少しまとめてみた。

http://www.shos.info/develop/xp/xp.html#column20041215

Principles (原理) が随分替わっている。
他も大分進化しているようだ。

XP に関しては、暫く話題が落ち着いてきていたのが、これでまた議論が再燃するような気がする。
というか、再燃してほしい。
いや、むしろ再燃させたい。

最近の XP (謎) は、「現実的な落としどころ」とかを探り出したりなんかしちゃって、なんというか、大人になってしまったというか、成熟して毒が抜けてしまった感じもある。
すっかり角が丸くなってしまって、なんか、「エクストリームさ」が減ってしまったようだ。

勿論、そうやって現実的になっていくのは、良いことに決まっている。

でも、そのエクストリームさがあちこちで議論を呼び、濃いコミュニケーションを作るきっかけになっていたのは確かなんだ。
そうして、残業や休日出勤を繰り返しつつ必死に開発を続ける多くのプログラマたちに多くの変化を与えていったはずなんだ。

今回 XP に関する議論の原点ともいえる『Extreme Programming Explained』の第二版が出たことで、再びそうしたムーブメントが起こることを期待したい。

ともかく、XP はアジャイルに進化していく。
良い方向に向かっているのは間違いない。

エクストリームさは、少しは減ってしまったかも知れない。
でも「エクストリーム プログラミング」という呼び名は変わらないようだ。

"XP" → "Longhorn" とかにならなくて本当に良かった。

# さて、今回はどなたがこの本を翻訳されるんだろうか。

CoffeeDiary ― ユニットテスト侍 Io版

ユニットテースト ユニットテスト♪
すべてのテストを自動で実行するんだぜ！ って言うじゃな～い？

でもあんたのテスト、testFooBで失敗してますから！ 残念！
assertion failed: expected '2' but was '3'

4個のテストで、エラー0個、失敗1個、斬り！

いい。
# .NET 版も必要か。

ウォーターフォール式にアジャイルを導入する手順。

1. 社内で「うちでもそろそろアジャイル開発を導入しませんか」と根回しをします。
2. 「アジャイル開発プロセスに関する調査を行うための準備委員会」の提案書を作成し、上に提出します。
3. 提案書が、課長→部長→本部長と段階的に上にあがっていき、承認されて段階的に戻ってくるのを待ちます。
4. 「アジャイル開発プロセスに関する調査を行うための準備委員会」の責任者となって、委員会を設立します。
5. 会議を繰り返し、その結果を元に「アジャイル開発プロセスに関する調査書」案を作成し、委員会を召集してレビューします。
6. 反対意見をまとめあげて、「アジャイル開発プロセスに関する調査書」を完成させます。
7. もう何もかもがいやになり、全てを窓から投げ捨てます。

ナジャイラ (NAgiler: ドットネッターでアジャイラーの意味) の中西 さん の言葉。

いい。
実に良い。

強い言葉だ。

言い訳じみていないし、説得しようとしていない。

「こうあるべき」、「だからこんな風にしていくべき」なんていう「べき論」なんか寄せ付けない潔さがある。

凛とした感じ。自然体。

毛筆で書いて飾りたいという意見があったので、作ってみた。

以前話題にした “Be Agile. That's my attitude.” という言葉だが、余りに気に入ってしまったので、中西 さん の真似 (謎) をして名刺の裏に入れてみた。

名刺の「ツッコマレビリティ」も上がって良い感じだ。
# アジャグラー シール (謎) とかも貼ってみようかな。

※ ツッコマレビリティ: わざとツッコまれ易くして、ひとがついつい話を振ってしまうような状態は、ツッコマレビリティが高い状態。
ツッコマレビリティを高く保つことで、コミュニケーションが向上する。
類義語: ツッコミビリティ

以前に書いた、社内のソフトウェア開発プロセス改善のための「Big Jolt (大きなイベント)」を明日やる。

今回の "Big Jolt” のポイントは以下のようなもの。

• 会場は職場と離すこと
  • 非日常感の演出
  • 理由を付けて日常の仕事に戻ろうとするのを防ぐ
  • 打ち上げ会場と同じ建物
• 体験型にすること
  • 体験してみないと本当の知識は得られない
• みんなが体験すること
  • 原則全員参加
  • 「忙しいから出られない」は駄目
  • つまり、「いつも開発で忙しくて、今の開発のやり方が良いか悪いかなんて考える暇なんてない」は駄目
• 参加者同士のコミュニケーションを重視すること
  • 問題について話す機会を作る
  • なるべく日頃話さない人同士をグループに
  • アイス ブレーキングを多く取り入れる
  • 打ち上げを行う
• 社外からの人を招いてお話をしてもらうこと
  • 新しいアイディアを入れる
  • 説得力のあるお話を聴く

「社外からの人」だが、今回スペシャル ゲストとして、ファシリテータの 本間 直人 氏に、福井まで来て頂いてファシリテーションについてお話しして頂くよう御願いした。

『プロジェクト ファシリテーション』という言葉もあるように、開発を成功させるにはファシリテーションは、とても重要。

本間 さん のお話は、個人的にものすごく楽しみだ。

# さて明日に向けての準備の続きをしないと。

※ やまざき さん のところより。

• XP開発部屋の一例

「ストーリーカード掲示板」を通して光が入ってくるところが良い。

NAgile を推進されている afukui さん が新しいサイトをオープンされた。

• NAgileで行こう！

NAgile (エヌ・アジャイル) というのは、.NET でアジャイル開発を行うこと。
NUnit をはじめとした .NET 用のアジャイル開発ツール (N*: エヌ・アスタと呼ばれている) を使う。

.NET 開発者にも、是非アジャイル手法が広まっていってほしいと願っている。
※ ちなみに、.NET でアジャイル開発を行う人のことは、NAgiler と呼んでいる。

その他の NAgile のサイト:

• Archway ― NAgile
• hmoriya .net style
  NAgile の考案者の森屋 英治 さん のブログ
• NWiki
  NAgile の情報が満載の中西 庸文 さん のサイト

導入記事はこちら:

• @IT ― .NET開発者のための開発プロセス入門
  (前編) アジャイル開発を導入できていない.NET開発者たちへ
  (後編) .NET開発でアジャイルを導入するための実践テクニック
  「.NET でアジャイル」の達人、福井 厚 さん と 小井土 亨 さん による .NET 開発者向けのアジャイル開発導入方法
  

「NAgileで行こう！」の続き。

# 現在 「NAgileｒ になろう!」 キャンペーン実施中。

NAgile をやっている人のことを NAgiler と呼ぶのは、もう周知の事実だが （謎）、NAgiler を増やすためのキャッチ コピーを考えたので発表したい。

ずばり、

「ナジャイラってなんじゃいら?」

注． 某 Japan Advertising Review Organization, Inc. (社団法人日本広告審査機構) のコピーに似ているような気がするかも知れないが、決して似ていないので気にしてはいけない。

これを、キャンペーン (謎) 等でばんばん流すと、効果がある筈だ (多分)。
はじめは違和感が有るかも知れないが、耳慣れてくると、大丈夫 (謎) なので安心して欲しい (多分)。

現在「NAgileｒ になろう! キャンペーン」続行中! な訳だが。

NAgiler のためのテーマ曲 (意味不明) の候補をあげてみたい。

その名も "Hava Nagila"!

• Most Popular Songs From Israel: Hava Nagila (試聴可)

イスラエルのポピュラーな民謡だそうだ。

男女で輪になって踊るための舞曲で、モーゼ五書の中の祭りと儀式に関する書『レビ記』の収穫を祝う部分を歌にしたものだとのことで、アジャイルなドットネッターにぴったりだ (意味不明)。

amapyon さん のところに以下の記事が紹介されていた。

• 『失敗しない情報システム調達 - 顧客の視点で、アジャイルを説明』

読んでみて、殴られたような衝撃があった。
顧客視点で XP を推奨している。
なんと開発側は「やつら」と呼ばれている。

今年の Developers Summit の『XP事例カタログ』でも、顧客側からの XP プロジェクトの発表があり (by 猪狩氏)、とても新鮮な感動があったことを思い出した。

「視点の転換」。その素晴らしさを改めて思い知らされた感じだ。
XP では特に重要なことだと思われる。
是非心掛けて行きたい。

XP における視点の転換の大切さを示すために、XP の「3 + 1 ビュー」というのを考えてみた。

・XP の「3 + 1 ビュー」

開発者は、えてして開発者の視点でものを考えがちだが、XP をやっていく上では、「顧客の立場」、そして「経営者の立場」でも考えていかないとうまく行かないと思う。

この視点が欠けると、

• XP をやること自体を顧客や経営者に受け入れてもらえない
• XP をやっているのに顧客や会社のメリットになっていない

等というようなことにもなりかねないと思う。

※ 尚、図に入っていない12～24個のプラクティスについてだが、プラクティスにとっては、この 3 + 1 ビューは、横断的関心事であり、アスペクトということになるのかも知れない。

今日、NAgiler の中西 さん が、

「ツールは重要だ。手動で行う作業が二回以上あったらツールを作っちゃおう」

という内容のことを、或る処に書かれていた。

それって「開発プロセスのリファクタリング」だよね。

• プロセスの不吉な匂い
  

  『手動で繰り返される単純作業』
  同じ作業が手動で二回以上行われる

• リファクタリング
  

  名称:	『ツールによるルーチン ワークの置き換え』
  状況:	コンピュータで行えるような作業を、いつも手動で行っている。
  解決法:	プロセスから作業を抽出し、それを自動または半自動で行えるツールを作る。 プロセス内の作業を、そのツールを使うものと置き換える。

# 先日 の続き。

NAgiler の福井さんが、今日或る処で、

アジャイラーになる人はとそうでない人の違いは、面白そうだと思ったら実際にやってみようと考えるかどうかだ

というようなことを書かれていた。そして、

アジャイラーにジャグリングする人が多いのも、面白そうだと思ったら実際に体験してみる人が多いから

とも。

同感だ。

「いいなあ、やってみたいなー」と「いいなあ、実際にやってみます」って、似ているようで、その差は大きい。
後者の方がアジャイルだ。

例えば会社などで何かをやろうとする場合。
「こうやるべきだ」とか「こうあるべきだ」と、「私はこういう風にやってみます」の差は大きい。
後者がアジャイル。

「こうやるべきじゃないか」「いや、それは違うと思う。こうやるべきだろう」のような議論ばかりして、いつまでも実際の一歩を踏み出そうとしなかったり、「やるべき」と言いながらも、『ネガティブ思考』をして、人の提案にケチばかり付け、「それでは駄目な理由」や「自分がやらない理由」ばかりをあげて、動こうとしない人がいる。
アジャイルな人には、そうではなく、少しずつ試しながら何とかうまくいくように自らファシリテートしようとする人が多いと思う。

"アジャイルであること" というのは、つまり、そうした "態度" なのだと思う。

エクストリームな蜘蛛(くも)を発見。

The eXtreme sPider on the eXtreme Web.

It must be extreme agile spider... (riddle)

# 先日の続き。

アジャイラー向けに、標語を思い付いたので、ちょっとメモ。

”Think abstractly, act concretely.”

# パクリだけど (謎)

デジタルペンで書いて取り込んでみた。

C 言語入門者のための演習の課題を作ってみた。

【文字列の演習】

#include <assert.h>

// ここに適切な関数を追加して、「実行できるけど、実行しても何にも起きないように」してね。
//  ・今あるコードを消すのはなし
//  ・#include を追加するのも禁止

void TestIsSameString()
{
   assert( IsSameString("abcde"   , "abcde"   ));
   assert(!IsSameString("abcde"   , "abcdefgh"));
   assert(!IsSameString("abcdefgh", "abcde"   ));
   assert(!IsSameString("abcde"   , ""        ));
   assert( IsSameString(""        , ""        ));
}

void TestCopyString()
{
   char textBuffer[0x1000];
   CopyString(textBuffer, "QWERTY");
   assert(IsSameString(textBuffer, "QWERTY"));
   CopyString(textBuffer, "");
   assert(IsSameString(textBuffer, ""));
}

int main()
{
   TestIsSameString();
   TestCopyString();
   return 0;
}


『C＃で学ぶオブジェクト指向プログラミング 』ブックレビューに続いて、『リーンソフトウェア開発』のブックレビューを書きました。

• ITエンジニアのための ブックレビュー

XP祭り2005に参加予定。

XP祭りは今年で四回目。毎回参加している。
プログラムによると、今年もかなり豪華な内容のようだ。
このイベントは毎回懇親会で色々なアジャイラーとコミュニケーションをとるのも大きな魅力なので、できれば懇親会にも参加したいところ。

『XP 祭り 2005』に参加してきた。

いうまでもなくアジャイル開発の最大のイベントで、今回は第四回だ。

※ 参考: 過去のXP祭りのレポート

• 「XP 祭り 2002」
• 「XP 祭り 2003」
• 「XP 祭り 2004」

これまでの三回と比べて、土曜日開催・お台場のある臨海副都心での開催、というのが新しい。
また、今回は豪華メンバーによるパネル ディスカッションをはじめとして、すごそうなセッションが目白押しだ。とても楽しみにしていた。

朝五時半に起床。六時半に自宅を出て、自動車と飛行機と電車で会場に向かった。

この日の最高気温は32℃だったが、それ以上にとても暑い一日だった。
二百数十人の参加者で、一日中大変な盛り上がりだった。

期待をはるかに上回るすばらしい体験だった。

イベント概要:

XP祭り2005
テーマ	XPのみらい ～これから始めてもいいじゃないか!
日時	2005/09/03 講演会 10:00～18:30、懇親会 19:00～
会場	日本科学未来館 みらいCANホール
主催	日本XPユーザグループ

内容:

今回なんといっても素晴らしかったのは、パネル ディスカッションだ。

これほど粒ぞろいで個性的なエンジニアが揃うパネル ディスカッションは見たことがなかった。
今回もっとも楽しみにしていたセッションだ。

「成功体験と失敗体験」みたいなテーマで始まり、どうなることかと少しはらはらしたが、司会の倉貫 さん の話の振り方が上手で、パネリストからどんどん話を引き出していく。

今回話された主なテーマ:

• 「成功体験、失敗体験」


• 「プロジェクトの成功とは」


• 「フレームワークは嫌いだ」


• 「日本ならでは」


• 「技術者としてのモチベーションのありか」

様々なテーマについて、各パネリストが異なる立場・異なる視点から話すので、とても多くの気付きがある。萩本 さん、平鍋 さん、ひが さん、萩原 さん、関 さん。すべてのパネリストの視点が、私には好ましく、また興味深いものに感じられた。

ひとつの問題にあちこちから次々にスポットが当たる。
そして、異なる話をしながらも、深いところでは意見が一致する。

萩原さんの、

「IT で革命を起こしたい。今の時代は、後の時代から振り返ると、ITによる産業革命にあたる。以前の IT 革命はお金儲けだけの話だった。現在 IT はコスト削減のようなつまらないことにしか使われていない」

という言葉など、多くの言葉に感動した。
ちょっと泣きそうになったかも知れない。

パネリストの方たちの思いが、ずんずんと伝わってきたような気がした。
本当になんてあつい人たちなんだろう。
この人たち格好良すぎ。

パネル ディスカッション以外のセッションも大変素晴らしいものばかりだった。
本当に参加してよかったと思う。

# ちなみにパネル ディスカッションの次に感動したセッションは、角谷 さん のライトニング トークス (後述)。

• 『XP入門』 小井土 亨 氏
  XP と XP 第二版の紹介。個人的には、ジャグリングと暗黙知の関係の話がツボ (謎)。
• 『EXP - Enterprise XP』倉貫 義人 氏
  
  上流工程でも XP をやって、XP による上流工程を「試作工程」、XP による下流工程を「製作工程」と名前を変えてはどうか、という提案があった。
  名前を変えるで意識を変えよう、ということだったが、この考え方にはとても共感できる。
  後の方のライトニング トークスでも、UnitTest での Test を Spec、Assert を Verify、assert を should と表現するものがあった。
  名前を変えることで概念が変わる。
• 『プロジェクト・ファシリテーション ～アジャイル開発から最新動向と集大成～』 平鍋 健児 氏
  
  何回か聴いたことがあるプロジェクト ファシリテーションの話だが、毎回新しい気付きがある。今回はPF小劇場と称して、「朝会」や「ふりかえり」の良い例と悪い例を寸劇で紹介していた。
• 『ユーザ中心の設計』 ひが やすお 氏
  
  ユーザー中心の設計をするために、要件定義のときに「要件の見える化」が重要だという話。「UI モックアップ」「操作マニュアル」、「業務手順書」を使って見える化を行う。
  聴いていて思ったのは、XP でも実際に動くプログラムを早くリリースすることで「見える化」を行うし、XP 以外ではプロトタイプを使う開発モデルもある。ひが さん の方法がそれらより良いと思った点は、
  • 出来上がりの全体のイメージを、とにかく早期に見える化
  • 見える化で使ったUI モックアップや操作マニュアルなどは無駄にならず、最終成果物の一部になる
  というところ。
• 『要求開発とＸＰの共通点』 萩本 順三 氏
  萩本 さん のお話は、これまで他所で何度も聴いているが、もっと恐い人かと思っていた。なんとも優しい語り口だった。
• 講演者＋スペシャルゲストによるパネル『XPのみらい』

  パネリスト:	萩本 順三氏、平鍋 健児 氏、ひが やすお 氏、萩原　正義 氏、関 将俊 氏
  司会:	倉貫 義人 氏
  議事ログ作成:	懸田 剛 氏

  
• 劇団ペケぴー v.s. アンプラーズ
  
• ライトニング トークス
  二つに出てきた。
  • アジャグラー (アジャイラーでジャグラー) チームでトークス
    和田 さん、天野 さん、大熊 さん、池田 さん、小井土 さん、林 さん と一緒に (七人で)。
    ジャグリングを披露。
  • ナジャイラー (ドットネッターでアジャイラー) チームでトークス
    中西 さん、丸山 さん、黒石 さん、と一緒に (四人で)。
    目的は NAgile のプロモーションで、内容は NAgile の紹介と CruiseControl.NET の紹介＋CruiseControl.NET でパトランプを回すデモ。
  ※ 参考: これまでに出たトークスのメモ

  角谷 さんの Ruby のトークスは、すごかった。トークスの鬼だ。一体どこに行こうとしているのか。
  もしかすると、裏に巨額な予算と多人数のスタッフが付いているのかも知れず (謎)。
  その他の人も、とても面白かった。トークスは、年々レベルがどんどん上がっている。
  



• 抽選会
  
  何も当たらなかった。何かが間違っている、と思った (違)。


• 懇親会
  
  参加者は、100人を軽く超えていたのでないか。大盛り上がり。一部でジャグリング大会が始まっていた。色々な人と色々な話ができた。参加していたのにお話できなかった知人もいたのは残念。


• 二次会
  
  二次会になっても、40人を超える参加者。アジャイラーはとにかくアツイ。

関連 Web サイト:

ついに NAgile のリレー連載開始!

• @IT ― 連載 NAgileで始める実践アジャイル開発 「第1回 .NET＋アジャイルなら本当に幸せになれるのか? ――フリーのN*ツールによる楽しいアジャイル開発――」(2005/10/19)

私も Skype で座談会に参加しております。

『XP祭り 2006』 (2006/09/02) で侍塊s が作ったオフィシャルソングが大ヒットしていた。

それがとても気に入ったので、侍RED さんにお願いして、録音したものと歌詞を送っていただいた。
そしてそれを元に楽譜を起こしてみた。更に侍RED さんに添削もしていただいた。感謝。

楽譜と歌詞を許可をいただいた上で以下に公開することにした。
※ 楽譜をクリックすると拡大表示。

Dear XP ～ XP祭り2006 オフィシャルテーマソング～

初めて気づいた 人の本当の強さを
今 二つ机並べて でも パソコンは二人で1台
流れる雲と ソースを眺めたね

XP Dear XP
今も壁に飾ってる
忘れないあの夏の日の
チームでこなしたタスクのカード

XP Dear XP
君ともっと話したい
苦労やなにより喜びを
もっともっとわかちあいたい

人が生きること それは自分を磨くこと
そう 守るだけの強さよりも 変わることを恐れぬ強さを
ココロに抱いて 未来 (みらい) を見つめよう

XP Dear XP
ほら仲間が待っている
時々は 羽目を外しても良いよ
明日 (あす) もニコカレ ほほえむように

XP Dear XP
君ともっと話したい
苦労やなにより喜びを
もっともっとわかちあいたい

君と僕の明日 (あした) のために

© 2006 侍塊s

以下のイベントに参加予定。

スピーカー陣は:
倉貫義人氏、本間直人氏、まつもとゆきひろ氏、牛尾剛氏、川端光義氏、平鍋健児氏と何だかすごい。

9/2 に東京で開催された『XP祭り2006』もとても良かったが、関西の方もプログラムといい、協賛やスポンサーや後援の数といい、サイトの出来映えといい、なんだかとてもパワフルさを感じる。

多くの参加者が集まり、顔見知りの方々も多くいらっしゃるようだ。とても楽しみなイベントだ。

いくつかの懸念:

• 日帰り参加の予定だが、飲み会の途中で帰るのは自分的に微妙。
• 英会話クラスみたいに「会場に入ったら関西弁以外使用禁止」とかだったらどうしよう。

『404 Blog Not Found ― テキストエディタさえあればできるTDD』について。

※ 「それがわからないのであれば、あなたはTDDがわかってないのだ」という強い言葉に反応。

まず、角谷さんは誤解なんか全然していないように思える。

つまり、「Perl だとちゃちゃっと書けて、面倒くさくない」というのは、まさにハッカーの発想であって、TDD は本来そんなハッカーには不要なものじゃないかということだ。

上記記事より引用:

プログラマーにとって最も偉大な習慣とは、プログラマーでない人たちの立場になってものを考えられるかではないのか。テストを書く人はプログラムを書く人と同じとは限らない。いや、本当のところは違っていた方がいいのだ。

私が「eclipseを使っている人はいいけど」と言ったのは、まさにそのことだ。

それがわからないのであれば、あなたはTDDがわかってないのだ。

記事では、「Perlではこんな簡単に書ける」ということで Perl で書いたテストの例が挙げられている。

しかし:

• 上に書いたが、テストがこんな風にちゃっと書ける、というのは主にハッカーにとっての利点であるように思える。少なくとも「プログラマーでない人たちの人たちの立場」のものとは思えない。記事には「プログラミングを全く知らなくてもテストを書くことが出来る」ともあるが、Perl のテストの例を見る限り、とてもそうは思えない。特別なツールを使わずにテキスト エディタでさっと短くテスト コードを書く、というのは、「プログラマーでない人たち」から見ると逆にハードルが高いだろう。そちらの方が簡単、というのは「プログラマーでない人たち」の視点ではなくハッカーの視点だと思う。
• そもそも TDD の一文字目が表わすのは、「プログラマーでない人たちの立場になった」テストではないと思う。あくまでもプログラマーが設計と実装を行うためのものだ。「テストを書く人はプログラムを書く人と同じとは限らない」とあるが、その「テスト」とは違う。こんな風に、TDD の Test は通常のテストと混同されることが多い。通常のテストと混同されないようにTDD の Test は Test と呼ばない方が良い、という議論もあるほどだ。TDD はあくまで設計と実装を楽にやるためのプラクティスであって、プログラマーのためのものだ。

※ 私は TDD はプログラマーの視点変換ツールだと考えていて、その点に関しては記事の方と意見が共通だ。

■ 概要

■ 参加内容

先週末は、社内でイベントを主催した。

「Big Jolt (大きなイベント)」は、組織を改善するためのプラクティスの一つで、以下を守ってやった。

• 会場は職場と離すこと
  •  非日常感を演出しよう!
  • 理由を付けて日常の仕事に戻ろうとするのを防ごう!
  • 懇親会会場と同じ建物でやろう!
• 体験型にすること
  • やってもみないで、ネガティブ シンキングはナンセンス!
  • 新しい体験をしよう!
  • 参加することで何か得をするようにしよう!
•  みんなが体験すること
  • 原則全員参加!
  • 「忙しくて参加できない。改善活動は何も問題がなくなってから」は駄目!
•  参加者同士のコミュニケーションを重視すること
  •  懇親会をやろう!
  • なるべく日頃話さない人と話そう!
  • シャッフルして座席を決めよう!

内容:

実は、六月に「オブラブイベント 2007夏 帰郷」に参加したのだが、その中の・『TPSコミュニティ・クロニクル～改善活動は人を変え、組織の壁を越える～』 by 和田 憲明氏 角野 泰次氏 金野 清隆氏 というセッションに、強くインスパイアされた内容のイベントとなっている。うちの会社の改善活動は「守・破・離」でいうと「守」の段階なので、基本に忠実に実施した。

以下のようなプログラム。

• プロジェクト・ファシリテーションに関する講演 by 平鍋健児氏
• 社内の成功・失敗事例紹介
• 初の社内ライトニングトークス テーマ「見える化」
• 懇親会

所感:

• 「見える化」のポイントはそれが行動を生むかどうかにある、という平鍋氏のお話を皆食い入るように聞き入っていた。これで社内で「見える化」の実践に勢いがついてくれることだろう。
• 初の社内ライトニングトークス。時間の制約でトーカーが三人と少なかったものの、日頃こういう場で人前で話すことが稀な人が話して、大いに盛り上がった。次回はもっと人数を増やしてやりたい。
  ※ ちなみにトークス用の5分間タイマーは私が自作。勿論 .NET で。
• 社内の成功事例では、日頃余り知る機会のない他部署の取り組みを知ることができて良かった、という声が聞かれた。
• 失敗事例の紹介は、とても良かった! 失敗について語れる、そして皆がその話を真剣に聞く、というのは素晴らしいことだ。
• そして、懇親会。各自が多くの人と部署の壁を越えて話し合うことができたようだ。

今後アンケートを取り、より詳しく参加者の方々の声を聞いてみたい。

関連記事:

• An Agile Way ― 福井コンピュータで講演しました。