TDD BOOT CAMP in TOKYOに行ってきました！

WORK PHP

2011/07/09に開催された「TDD BOOT CAMP in TOKYO」に行ってきました。

まずは、Symfonyしゃべりばでのひょんなきっかけから、この素晴らしいイベントの主催をされた[twitter:@HIROCAST]さん、会社でもお世話になっておりますが、開催協力と講演をしてくださった[twitter:@t_wada]さん、各言語をサポートいただいた[twitter:@shishi4tw]さん、[twitter:@setoazusa]さん、[twitter:@kyon_mm]さん、[twitter:@sue445]さん、設営から運営をサポートしてくださった方々、LTをしてくださった[twitter:@remore]さん、[twitter:@tomy_kaira]さん、Ustの配信にご尽力いただいた[twitter:@brtriver]さん、[twitter:@gilbite]さん、そして現地、サテライト、Ustの向こうで参加されたすべての方々、

ありがとうございました！


すでにたくさんの方が、感想ブログやまとめをしていただいておりますので、ＬＴでは言えなかったことや、ＴＬ等を読み返しての感想的なものを綴ってみたいと思います。


まずは、皆さんのブログ等はこちらです。捕捉できていないものがあれば教えてください。


#tddbc (TDD Boot Camp) in Tokyo 開催します!!・・・始まりの１ページ
ATND・・・ATNDページ（競争率約４倍の狭き門でした）
TDDBC FAN PAGE・・・tddbcのFacebookファンページ
ポジションペーパー・・・現地参加者のポジションペーパー
togetter・・・[twitter:@irof]さんによるtogetterまとめ
TDDBC in Tokyo 1.5 主催レポート #tddbc・・・[twitter:@HIROCAST]さんの主催レポート
TDDBC 東京 1.5・・・[twitter:@tomy_kaira]さんの参加レポート
Boot Camp in Tokyo 1.5 に参加しました・・・[twitter:@remore]さんの参加レポート
Gitのいろは・・・[twitter:@tomy_kaira]さんのＬＴ資料
人類ペアプロ計画・・・[twitter:@HIROCAST]さんのＬＴ資料
TDDを実践してわかったTDDつまづくあるあると自分なりの乗り越え方まとめ・・・[twitter:@remore]さんのＬＴ資料
TDDBC東京1.5 へ行ってきました #tddbcComments・・・[twitter:@norry_gogo]さんの参加レポート
TDD Boot Camp in Tokyo 1.5 #tddbc に参加してきましたComments・・・[twitter:@yujiorama]さんの参加レポート
TDD Boot Camp in Tokyo懇親会に参加してきました。・・・[twitter:@yanchi]さんの懇親会参加レポート
TDDBC東京1.5に参加してきた・・・[twitter:@akitsukada]さんの参加レポート
TDD Boot Camp in TokyoにUstream参戦してみた(講演・LTのみ) #tddbc - Diary of absj31・・・[twitter:@shinyaa31]さんのUst参加レポート
当日の様子・・・当日の様子アルバム


2011/07/14 6エントリ追加！（※今後は追加の依頼があれば足していきたいと思います）

TDDBC TOKYO 1.5・・・[twitter:@tmtms]さんの参加レポート
JavaプロジェクトでGroovyを導入すべき５つの理由・・・[twitter:@kyon_mm]さんの参加レポート
TDD Bootcamp 1.5 in TokyoでTDDのイロハを教わった・・・[twitter:@mahm]さんの参加レポート
TDDBC in TokyoにUst参戦してきた・・・[twitter:@shitai246]さんのUst参加レポート
サテライト #tddbc 佐賀に参加・・・[twitter:@pocketberserker]さんの佐賀サテライト参加レポート
サテライト #TDDBC 佐賀 に参加してきました・・・[twitter:@Naoki_Rin]さんの佐賀サテライト参加レポート



さて、上のリストを作っていたら疲れ果てました。。。。が、気を取り直して少しだけ感想を。


「アジャイル」と言う言葉ほどではありませんが、「ＴＤＤ」と言う言葉も誰が何のためにと言ったコンテキストや、言葉そのものがさす具体的なプラクティスや、その先に求める何かによって、議論をしていてもかみ合わなかったり論点が飛躍したりしてしまいます。


私にとってのＴＤＤは２００１年か２００２年ごろ、取引先の情シスのJavaエンジニアの方にその言葉を初めて聞かされたことから始まりましたが、この時は単なる「テストファースト」と言う意味でとらえており、言い訳をすると１９９８年頃から独学で「なんとか動くもの」をひたすら作ってきて、ソフトウェア工学とかなんちゃらアルゴリズムなどを一切学んでない身としては、ユニットとかコンポーネントの意味もよく理解していなかったので、小さな粒度でテストする、ましてやそれを先にする意味がさっぱり分かりませんでした。


お客さんは１日でも早く動くものを見たいわけだし、ＩＴのプロでないからこそ動くものを触ってみなくては最終的な良し悪しを判断できない。そういう思いが強かったからこそ、当時は簡単なモバイルＥＣサイトの骨格であればperlやphpを使って２、３日で作ってデモを通して、セキュリティ、パフォーマンス、デザインをブラッシュアップしていました。また、メソッドやモジュールは単なる部品で、部品の品質をどんなに高めてもその部品を組み合わせてできる「製品」がとんでもでは、だれも喜んでくれない、と考えていました。


時は経ち、今年の１月にDevLoveの「TEST x TEST x TEST」に参加しました。この時は２００２年に２名だった会社が６０名弱になっており、自社ＤＣで運用・保守しているお客様のシステムもリリースから数年経過するものも増え、システムが生み出している価値も大きなものになってきたため、エンドツーエンドテストに対する人海戦術が精神的に破たん寸前でした。Seleniumなどは導入していましたが、やはりバグがでるとそのソフトウェアに関わるすべての人にいろんな不幸が訪れました。ＱＡ部門の設立も社内で散々議論されましたが、ソフトウェアのテストでテストしなくてはならないものには「使う人に幸せを提供できているか」と言った最大の関心事があります。そのソフトウェアを使う人や業務の背景を知り、なぜ大金を投じてこのソフトウェアが作られたかを心の底から理解していなくては精度の高い（製品の一貫性を担保すると言った意味ではない）テストはできないと感じておりました。そこで他社での事例を知りたく前述のイベントに参加しました。ここで[twitter:@t_wada]さんと[twitter:@ryuzee]さんに出会い、非常にテクニカルであるものの説明や、体系的なものについていろいろお聞きしました。その時のお二人に共通していたのは、ツールや技法の話をされていても「なぜテストするのか」についての本質に確固たる信念があることでした。


その後「縦サミ」で和田さんの講演を聞き「私では社員に教えられない大切なものをこの人なら早く、具体的に教えてくれるのではないか」と感じ、すぐにコンタクトを取りました。まず当社の現状を知っていただき、その上でしてもらえることがあるかどうかを直接お会いして相談に乗っていただきました。和田さんには迷惑だったかも知れませんでしたが、自社の会議室にお呼びして前日に急いで作ったパワポ資料を見ていただきました。内容はほぼ経営理念についてです。何かの専門家にご相談させていただく際は、創業からのいきさつとその分野に関する今困っていること、ご協力いただいて得たい成果をお話しすることが多いのですが、ソフトウェア開発を生業にしている当社にとって和田さんにご協力いただきたかったのは、表面的なＴＤＤのやり方やバージョン管理システムの運用ではなかったので、経営理念や社是をお話しさせていただいた上でご賛同、ご協力いただけるか相談しました。


昨日のＬＴで「経営者、役員、事業部長いますか？」とやりましたが、このクラスの方には目的から導入していただきたいと強く思っています。現場では手段から入って成果を上げることも大事だと思いますが、どんな素晴らしいツールや体系、手段も目的がぶれていては現場は戦場のままだと思います。目的があればＴＤＤ（プラクティス的な意味で）をする必要のあるシーン、ないシーンに悩むことはないはずです。


さて、ＴＤＤやペアプロ導入でよく語られるのが目先のコストです。開発工数の増加、ペアプロによるできる人の生産性低下などなど。


開発工数の増加は、当日の和田さんの資料にもありましたがトータルで見たときに増加分を補っているもの（たとえばデバッグコスト）が十分にあるので、「ＱＡ部門が独立していて、詳細設計はどこからか降りてきて、コーディングだけをさせられている現場で、且つコーディング期間は従前のまま強制的にＴＤＤを導入」されない限りデメリットは少ないのではないでしょうか。当社の場合、開発部門が企画、要件定義、設計、開発、テスト、運用、保守を一貫してやっているので、寿命の長いソフトウェアを扱う上ではかなりメリットが大きいと感じています。


ペアプロに対する問題点ですが、ソフトウェアは単一の開発者の物ではありません。コードや価値は共有すべきものなので、単一の開発者の生産性を論じること自体がいかにその開発者にあらゆるものを押し付けようとしているかの現れではないでしょうか。もちろんできる開発者にとって成長の遅いエンジニアとのペアがもどかしく苦痛になる場合も想像できなくもありませんが、これは「誰が」ではなく「チーム」がソフトウェアを開発し保守していくことを「文化」にできれば解決できるのではないかと思っています。


ペアプロやペア運用は組み合わせにもよりますが、成長を促進し、安心感を増大するには優れた手法だと考えています。特に運用まで一貫し、寿命の長いシステムを扱う場合、目先のコストより長いスパンでコストや創造する価値を測ってほしいと思います。


あー、、、２時までに書き上げようと思っていましたが、２時３０分になっちゃいました。また、加筆・修正するかも知れませんが、今日はここまで。


07/10 08:00追記
大事なことを書き忘れていました。ＴＤＤを組織的に導入することを決定した場合、決定権者がその効果を信じて導入する以上、守るべきことがあります。それは、導入に際して現場がやりたいと思えるようにファシリテーションすることです。強要や強制ではありません。最終的に会社や組織の文化として根付いて、少数のやりたくない派の人や、まったくの新人にとっては「会社がやれって言ってることだから」となってしまうかも知れませんが、導入時は全く別です。もし現場から「開発時間が２倍かかる」と言われたら、２倍の時間を取りましょう。きっとＷＢＳの結合試験や単体試験後の「フィードバック・修正期間」とされている時間が、後で短くなるはずです。開発期間が長く見積もられたが、お客様への価格に反映したくてもできない（競争力が失われると思っている）のなら、価格は開発期間が１だった時の見積もりで提示してください。万が一、他工程は圧縮されず、純粋に開発期間だけ伸びたのなら、出た足は投資だと思ってください。現場に安心感を与え、成長を促進するために導入するのに、「残業して、土日出社してＴＤＤ」とかばかげてますよね。


最後に、ＬＴ資料貼っておきます。

テスト駆動開発始めました！
View more presentations from Kiichi Kajiura