« 2006年10月 | トップページ | 2007年1月 »

2006年12月

2006/12/16

【Ruby関西】FormalMethod、オープンソースを軸としたエンジニア人生

土曜にRuby関西へ行ってきた。
今回も50人以上集まり、懇親会会場までの乗り物でプリンセスラインのバスを貸し切り、懇親会会場のインド料理店も貸し切り、行くたびにどんどん大々的になっている不思議なコミュニティだ。

【1・いけがみさんの話~テスト駆動を代用するライブラリ】

今回一番聞きたかった話がいけがみさんの講演「Ruby で書いたプログラムのデバグ技術」。
最初は、振舞駆動開発ライブラリRSpecやランダムテストライブラリRushCheckのお話。

1・RSpec

RSpec はTest::Unitと違って、テストの仕様を実装から切り離す所に特徴がある。
後で話をしたら、テスト駆動では、境界値条件や同値分析など実際の値を組み込んでテストするのに対し、RSpecでは、assertEquals()の構文を抽象化したものに相当するとの事だった。
確かにこの手法なら、設計仕様と区別して要求仕様がそのまま書けるが、まさにこの作業こそが手間がかかる所。

2・RushCheck

RushCheckはいけがみさん独自のライブラリで、テストで与える入力をランダムで大量作成してテストするツール。
意図は、不良品のサンプリングでサンプル数が多いほど統計学的に確からしさが高くなるように、テスト空間でテストするケースを増やせばバグをあぶりだせるだろう、ということ。

この発想は使えそうな気がする。
潜在的なバグの存在確率は過去の経験値で分かっているならば、ランダムにテストしてその結果を出力すれば、統計学的にどこまでバグをつぶせたか、ある程度見通せる。

但し、かずひこさんが「ランダムテストした時に、その経緯でバグが出るが、順序を変えると再現できない場合はないか?」と質問したように、ランダムテストで状態が変わってしまうような時は微妙な問題になる。

いずれもアイデアは面白いけれど、開発途中という印象を受けた。

【2・いけがみさんの話~FormalMethodは要求仕様を数学として書く手法】

最も興味深かった話は、FormalMethodのお話。
FormalMethod(形式仕様記述)には、「形式的手法」と「数理的手法」の二つの訳語があるが、いずれも「要求仕様を数学として書く」ための手法で、テスト抜きで確からしさを検証できる。

FormalMethodの実装例は、CやJavaでは既に公開されていて、ビルゲイツも「21世紀の新しい技術だ」と絶賛したらしい。

但し、学習時間や計測時間などのネックがあり、テストよりもコストが高いのが最大の弱点。

FormalMethodの例としては、代表的な2つの例がある。
一つは、モデル検査と呼ばれるもので、オートマンを基礎とする。
もう一つは、定理証明と呼ばれるもので、要求仕様を命題へ変換して、PGMと仕様が一致することを証明してしまうもの。

前者のモデル検査のツールは多いらしく、MSでも使っているらしい。
SEA関西プロセス分科会でも、モデル検査の話は以前あったから興味深かった。

後でいけがみさんに、FormalMethodについて聞いてみたら、ハードウェアに近い部分では成功例が多いらしいが、FormalMethodは万能薬ではない、とのこと。

テスト駆動からFormalMethodへ突き進むと、どんどん数学に近づいていく印象を持った。

【3・かずひこさんの話~オープンソースを軸としたエンジニア人生】

かずひこさんが語るオープンソース遍歴と人生観のお話で、考えさせられました。

かずひこさんは、電子辞書からWikiに至るまで、コミュニティへフィードバックしたら歓迎されたという原体験を持っている。

顧客にとって、オープンソースだろうが、ベンダー製品だろうが興味ないというシチュエーションが増えてきたこと。
オープンソースの方が業務の継続という点から見ると、サポートが受けられるというシチュエーションが増えてきたこと。

そもそも、サポートを止めるという行為は、サービス業のプロとしていいのか?
愛よりも誠意の問題ではないか、との指摘。

話を聞くと、オープンソースがビジネスに与える力が変わっているように感じた。

最後の方で、エンジニアとして、会社を辞めたら何が残りますか?と聴衆へ問いかけていた。
オープンソースなら、自分の作品としても残すことが出来る、と。生きた証として。

この言葉はしびれました。

なぜ、Imagine(ジョンレノン)の曲が流れているか分かりませんでしたが、最後のパワーポイントでようやく分かりました。

You may say I'm a dreamer...

But I'm not the only one.
I hope someday you'll join us. :)

今後、フランスで活躍されるとの事。
ご活躍をお祈りしてます。


| | コメント (0) | トラックバック (0)

2006/12/03

Haskellに触れてみる

 偶然見つけたHaskell勉強会へ出てきた。
 本もなく飛び入り参加でしたが、ううううさんの丁寧な進行やいけがみさんの適切な解説のおかげで大変興味深い勉強会だった。

【1】Extreme Readingによる和気藹々の読書会

 Extreme Readingとは、レジュメを担当した人が解説するのではなく、ペアプロのようにその場で読んで噛み砕いて議論するやり方だそうだ。

 初体験でしたが、『ふつうのHaskell』という簡単な本であること、さらにHaskell専門家のいけがみさんがいたおかげで、初歩的な質問から他言語との比較の議論まであって、結構深かった。

 Extreme Readingのやり方よりも、タイムキーパー役のううううさんの進行の上手さがむしろ印象的だった。
#PFP関西でのワークショップはタイムマネジメントがうまくいかなかったことを思い出して。

 大学生が中心で、Haskell初心者ばかり集まった勉強会。
 とはいえ、自分で株式会社を作ったと言う人たちばかりで、そのパワーに圧倒されてしまった。

【2】Haskellのサンプルからのぞける特徴

 講師役のいけがみさんが、Haskellの長所を問われて、

「遅延評価にそれほどの利点ではない。むしろ、型推論が出来ることと、新しい言語だけに良い所があることだ。丁度、PerlよりもRubyの方がスクリプト言語として洗練されているように。」

と答えたのが印象的だった。

 cat演算子と行数カウントをさっそく実装して動かしてみた。
 サンプルは簡単ではあるが、池上さんの言うHaskellの特徴が出ていないだろうか?

--cat.hs --Unixのcat

main = do cs <- getContents
putStr cs

--countLine.hs --ファイルの行数カウント

main = do cs <- getContents
print $ length $ lines cs

 最後にいけがみさんから教えてもらったIBM の Haskell に関するコラムを残しておく。

境界を越える: Haskell を使った関数型プログラミング

| | コメント (0) | トラックバック (0)

2006/12/01

【PFP関西】段取りと仕切りのフレームワーク

 今日開かれたPFP関西ワークショップに参加してきた。
 楽しかったです。
 スタッフの皆さん、ご苦労さまでした。

【1】芦屋さんのお話
 依田さん、前川さんの話の後、芦屋さんのお話があり、最も興味を引いた。
 プロフィール紹介で、2年目までお客さんとよく衝突したが、それ以降19年間、予防に努めてきた、とのこと。
 リスク管理に優れている人なのかな、と思ったり。
 話の節々に冗談を入れて笑いを誘って、聞きやすかった。

【2】時間管理が難しかったワークショップ

 30人の聴衆を、マネージャチーム、若手チーム、エンジニアチームに分けて「楽しく仕事をするには?」をテーマにグループディスカッションを行った。
 自分はエンジニアチームに入り、コミュニケーション、エンジニアライフ、見える化について議論した。
 仕様がなかなか確定しない、プロジェクトの目標が曖昧、という意見が出て、素直に頷く。
 僕は、利害関係者、特に、お客や上司など自分がコントロールしにくい人との調整が難しい、という意見を述べた。

 議論は各人の経験がそのまま出てすごく興味深かったけれども、20分でまとめて発表する段取りや仕切りが上手くいかなかった。
 3チームの発表では、エンジニアチームの発表が、内容は経験に基づいており、優れていると思ったけれども、論点がはっきりしなかったようだった。
 結局、若手チームの「コミュニケーションを上手く取ろう。そのためにティータイムやカップラーメンタイムを設けよう」という発表が最も拍手が多く、優秀賞となった。

【3】プロジェクトファシリテーションを支えるフレームワークは何か?
 
 スタッフの熱意、スタッフの切り盛り、和気藹々としたコミュニティの雰囲気、これらはいずれも2年前のXPコミュニティの雰囲気と全く同じ。
 でも今は、平鍋さんがXPからPFへ活動を発展させた軌跡と同じように、XPコミュニティの活動は停滞して、PFコミュニティへ皆の関心が流れているように思う。
 
 プロジェクトファシリテーションの定義は既にあるけれども、それを支える技術は、段取りと仕切りのフレームワークにあるように思う。
 バーンダーンチャート、かんばんのように仕事の段取りを効率化させるスキル。
 朝会、KPT、ホワイトボードのように、会議やチームを仕切り、ゴールに向かって進行させるスキル。

 XPやアジャイルに興味を持つマネージャは、段取りや仕切りを実行する時に、グッズやツールを使うのが上手い。
 にこにこカレンダーのようなグッズは職場にあるだけでも雰囲気が和むし、笑いも誘える。
 
 懇親会で話を聞くと、こういう小物やグッズは関東のグループが好きでよく編み出すらしい。
 逆に関西のグループは、実際に会って活動してお笑いを誘って、の方が好きらしい。
 地域の特色が出て面白かった。

 PFP関西は今、静かに盛り上がっているコミュニティ。
 要注目。

| | コメント (2) | トラックバック (0)

« 2006年10月 | トップページ | 2007年1月 »