2012年12月15日土曜日
英語の勉強について
最近、主に朝の通勤電車と休日に愚直に英語の勉強をしつつ、
２ヶ月１回のペースでTOEICを受け続けていたのですが（来月も受けます）。
「どういうふうに英語の勉強してるの？」と聞かれ、
「TOEICの問題集を読みまくる・聞きまくる」
「ダボス会議のCDを聞きまくる」
「中島聡さんや知人が紹介している英語の記事を読みまくる」
と答えたところ、
「TOEICの問題集解きまくるのは違うんじゃないの？目標スコアに到達したらやめちゃうわけ？」
と言われ、ハッとしました。
もし目標スコアが取れたとして、そこで勉強を止めればスキルは鈍ります。
それって全くもって価値がないなと思いました。
てか、TOEICの問題集ってつまらないし。
英語の記事だけじゃなくてCNNのニュースとか英語の小説読んだりとか、
実用性のある勉強法を取り入れようと思います。
指摘してくれた恩師に感謝です。
読みかけの英語版ネジ巻鳥クロニクルがぁぁぁぁ！
2012年12月2日日曜日
1年を振り返る
12月になりました。
あっという間の一年だったなと思います。
今年は自分にとっては大きな転機となる一年でした。
年明けくらいから社内で業務外の時間を捻出して、
業務のような業務でないような活動に参加して、
自分で価値を信じられることをやって、
思っていた以上に今の会社でできることって多いんだなって思って、
それがすごく楽しかったです。
それから、今まで絡むことのなかった、社内の人たちと接することができたり、
プログラマの中島聡さんと会うことができたのも大きかったと思います。
特に中島さんを見たときに技術云々とはまったく別の精神論的なところで、
何かこうビビッと来るものを感じたのです。タマシイと言い換えてもいいかもしれません。
「君たちが野垂れ死んでもいいから10年後に今の会社をスゴイ会社にしろ」みたいな。
同じことを他の人が言っても「こいつは馬鹿か。ふざけるな」ときっと思うと思います。
もともと自分が何をやりたいのだろうと思ったときに
私は人と人とのコミュニケーションの在り方を変えるようなものを作りたいと
漠然と思っていました。その辺のヒントをくれたのはN.Y.に住んでいる、
中学校のときの友達だったりするのだけど。
それはさておき、facebookやmixi(今は廃れていますが)のような世界観とは違っていて、
ハードが絡むんだよな。スマフォなのかな？みたいなところにどーんと来たのが、
業務外の活動でやった「それ」でした。
ただ、業務外でやるにはヒト・モノ・カネに限界があると感じていました。
次第に業務として「それ」をやりたいと思うようになりました。
そんなところに今の部署の公募が来て、
運よく比較的「それ」に近い今に至っています。
今の部署に来て良かったなと思うのは中島さんのような、
狂気に近い、タマシイを持った上司に出会えたことです。
仕事もまったく知らないことばかりだし、毎週ボコボコ。でも、早く成長したい。
てか、自分に力がないと仕事が消えてなくなるかもしれないし、
自分の存在意義がない。
丸2ヶ月、何の成果も出ていないと焦るのですが、そこは給料泥棒と言われようが
ホームランを打つまで粘り強くやっていこうと思います。
今の環境に移れて良かったなと思う一方で、人間の欲は際限がないなとも感じています。
今は今で以前にはなかった、新しい不満が出てくるんですよ。
それは、個人的にはその方向性は間違っているのじゃないかと
思っていることに対して、
これが正しいっていう自分なりの考えというか道筋を示すことが出来ないことで、
もどかしい。
きっと道筋を示せたら示せたで、
それが納得がいかない理由でねじ伏せられるみたいなことがあれば
それはそれでもどかしく思いそうですが。
（サラリーマンとして会社に勤めてるんだからそんなの日常茶飯事でしょとも我ながら思います・・・）
結局、そういうもどかしさをなくそうとして行き着く先とかって
30代のうちに社内企業して別会社化することなのかなって思ってます。
社内企業して別会社化はあくまで手段なんだけど、
起業するぞくらいに自分がやっていることに対して信念や熱意を持たないと、
人と人とのコミュニケーションの在り方を変えるようなものって
作れないのかなって思うんです。
精進します。
振り返りのつもりが所信表明みたいになってしまった。
あっという間の一年だったなと思います。
今年は自分にとっては大きな転機となる一年でした。
年明けくらいから社内で業務外の時間を捻出して、
業務のような業務でないような活動に参加して、
自分で価値を信じられることをやって、
思っていた以上に今の会社でできることって多いんだなって思って、
それがすごく楽しかったです。
それから、今まで絡むことのなかった、社内の人たちと接することができたり、
プログラマの中島聡さんと会うことができたのも大きかったと思います。
特に中島さんを見たときに技術云々とはまったく別の精神論的なところで、
何かこうビビッと来るものを感じたのです。タマシイと言い換えてもいいかもしれません。
「君たちが野垂れ死んでもいいから10年後に今の会社をスゴイ会社にしろ」みたいな。
同じことを他の人が言っても「こいつは馬鹿か。ふざけるな」ときっと思うと思います。
もともと自分が何をやりたいのだろうと思ったときに
私は人と人とのコミュニケーションの在り方を変えるようなものを作りたいと
漠然と思っていました。その辺のヒントをくれたのはN.Y.に住んでいる、
中学校のときの友達だったりするのだけど。
それはさておき、facebookやmixi(今は廃れていますが)のような世界観とは違っていて、
ハードが絡むんだよな。スマフォなのかな？みたいなところにどーんと来たのが、
業務外の活動でやった「それ」でした。
ただ、業務外でやるにはヒト・モノ・カネに限界があると感じていました。
次第に業務として「それ」をやりたいと思うようになりました。
そんなところに今の部署の公募が来て、
運よく比較的「それ」に近い今に至っています。
今の部署に来て良かったなと思うのは中島さんのような、
狂気に近い、タマシイを持った上司に出会えたことです。
仕事もまったく知らないことばかりだし、毎週ボコボコ。でも、早く成長したい。
てか、自分に力がないと仕事が消えてなくなるかもしれないし、
自分の存在意義がない。
丸2ヶ月、何の成果も出ていないと焦るのですが、そこは給料泥棒と言われようが
ホームランを打つまで粘り強くやっていこうと思います。
今の環境に移れて良かったなと思う一方で、人間の欲は際限がないなとも感じています。
今は今で以前にはなかった、新しい不満が出てくるんですよ。
それは、個人的にはその方向性は間違っているのじゃないかと
思っていることに対して、
これが正しいっていう自分なりの考えというか道筋を示すことが出来ないことで、
もどかしい。
きっと道筋を示せたら示せたで、
それが納得がいかない理由でねじ伏せられるみたいなことがあれば
それはそれでもどかしく思いそうですが。
（サラリーマンとして会社に勤めてるんだからそんなの日常茶飯事でしょとも我ながら思います・・・）
結局、そういうもどかしさをなくそうとして行き着く先とかって
30代のうちに社内企業して別会社化することなのかなって思ってます。
社内企業して別会社化はあくまで手段なんだけど、
起業するぞくらいに自分がやっていることに対して信念や熱意を持たないと、
人と人とのコミュニケーションの在り方を変えるようなものって
作れないのかなって思うんです。
精進します。
振り返りのつもりが所信表明みたいになってしまった。
2012年9月16日日曜日
XP祭り行ってやる気が出ました
XP祭り2012行ってきました。
http://xpjug.com/xp2012/
私が現在やっている仕事はデバドラソフトの開発で、
ウォータフォールのビッグバン結合による障害ドリブン開発なのですが、
今後のことを考えるとアジャイルな開発スタイルが必要だと強く感じ、
アジャイルの書籍は斜め読みしたことはあったのですが、
アジャイルとはどんなものかもっと知る必要があると思い、参加してきました。
新しい発見があり楽しかったです。
１．本を読んでやるのと実際にやるのは違う
スクラムのワークショップに参加して感じたことです。 ワークショップの内容はチームを組んで、 動物園を作ってほしいという要求に対して、 チームで要求からタスクにブレークダウンして折り紙を折るというものでした。 私のチームは時間内に折り紙を折ることができませんでした。 原因としては初対面の人たちでお互い遠慮しがちなところがあって 意思決定が遅めだったということもありますが、 一番のポイントはタスク分割をしているときに折紙のプロトを折らなかったことです。 予めプロトを作って折紙を折る時間が分かっていれば納期なり成果物の達成レベルを調整できたのです。 アジャイルでプロトを作るって当たり前じゃんと思うかもしれませんが、 本読んだりしただけでは分からないことで、 実際にやってみないと分からないなと強く感じました。
２．技術的な開発環境だけでなくチームワーク的な開発環境も重要
私は開発でバグや手戻りを減らすには テストコードを書き、テストを自動化し 設計を改善していくことが重要と思ってます。 そのため、CIやTDDのスキルを磨き、 職場にそういった環境を導入することにばかり目が行ってました。 でも、今回初めてスクラムを体験して、 「チーム」でものを作ることの重要性を改めて感じました。
普段、私が開発をしている環境はレビューや最低限のヒアリングや関係者との整合は取りますが、 基本的に個人でやっています。 仕事の属人性が強く、非常にリスクが高いです。
今回のワークショップでは割と意識の高い人が集まっていたので、 誰かが何かの作業で困ってたりするとすぐにフォローし合うようなところがあり、 すごくやりやすかったです。 短い時間でしたが、折紙で動物園を作るというワークの中においての お互いの信頼感はあったように思います。
実際の仕事で、こんなふうにやりやすいと感じたことはありません。 それって、実はすごく問題なんじゃないかと思います。 そして、今の職場には私が知る限りではそういった チームワークの視点を持った人がいないように思います。 技術的な開発環境だけでなくチームワーク的な開発環境も重要だと思いました。
３．でも、やっぱり技術やりたいっす
チームワーク的な部分が重要だし、スクラムも一度がっつりやりたいとも思いますが、 スクラムちゃんとやろうと思ったらそれなりの年月がかかるだろうなと感じました。 スクラムマスターとかになっちゃうとものを作れなくなってしまうので、 自分としては技術を深める方が優先なのかなと。 ただ、今後は自分にとってアジャイルにものを作れるようになることは重要で スクラムマスターを経験して、 その大変さを理解しておくことは経験として必要だと思います。
１．本を読んでやるのと実際にやるのは違う
スクラムのワークショップに参加して感じたことです。 ワークショップの内容はチームを組んで、 動物園を作ってほしいという要求に対して、 チームで要求からタスクにブレークダウンして折り紙を折るというものでした。 私のチームは時間内に折り紙を折ることができませんでした。 原因としては初対面の人たちでお互い遠慮しがちなところがあって 意思決定が遅めだったということもありますが、 一番のポイントはタスク分割をしているときに折紙のプロトを折らなかったことです。 予めプロトを作って折紙を折る時間が分かっていれば納期なり成果物の達成レベルを調整できたのです。 アジャイルでプロトを作るって当たり前じゃんと思うかもしれませんが、 本読んだりしただけでは分からないことで、 実際にやってみないと分からないなと強く感じました。
２．技術的な開発環境だけでなくチームワーク的な開発環境も重要
私は開発でバグや手戻りを減らすには テストコードを書き、テストを自動化し 設計を改善していくことが重要と思ってます。 そのため、CIやTDDのスキルを磨き、 職場にそういった環境を導入することにばかり目が行ってました。 でも、今回初めてスクラムを体験して、 「チーム」でものを作ることの重要性を改めて感じました。
普段、私が開発をしている環境はレビューや最低限のヒアリングや関係者との整合は取りますが、 基本的に個人でやっています。 仕事の属人性が強く、非常にリスクが高いです。
今回のワークショップでは割と意識の高い人が集まっていたので、 誰かが何かの作業で困ってたりするとすぐにフォローし合うようなところがあり、 すごくやりやすかったです。 短い時間でしたが、折紙で動物園を作るというワークの中においての お互いの信頼感はあったように思います。
実際の仕事で、こんなふうにやりやすいと感じたことはありません。 それって、実はすごく問題なんじゃないかと思います。 そして、今の職場には私が知る限りではそういった チームワークの視点を持った人がいないように思います。 技術的な開発環境だけでなくチームワーク的な開発環境も重要だと思いました。
３．でも、やっぱり技術やりたいっす
チームワーク的な部分が重要だし、スクラムも一度がっつりやりたいとも思いますが、 スクラムちゃんとやろうと思ったらそれなりの年月がかかるだろうなと感じました。 スクラムマスターとかになっちゃうとものを作れなくなってしまうので、 自分としては技術を深める方が優先なのかなと。 ただ、今後は自分にとってアジャイルにものを作れるようになることは重要で スクラムマスターを経験して、 その大変さを理解しておくことは経験として必要だと思います。
2012年8月21日火曜日
リーダブルコードは初級～中級者向けの良書
リーダブルコードという本を読みました。
リーダブルコード(和訳) The Art Of Readable Code(原著) コードはただ動けばよいだけでなく、読みやすい必要があります。
コードが読みにくいとバグを内包しやすくなるし、 他人はおろか自分自身も読みにくく変更しにくくなり、 その後の保守コストが上がるからです。
本書はコードを読みやすくするためのノウハウが挿絵とともにコンパクトにまとまっています。
主観ですが、初級～中級者向けの内容で、
大体４時間くらいあれば一通り読みきれるくらいのボリュームです。
たぶん、もっと熟練した人の場合は、 Code Complete や プログラミング作法 や Clean Code などの二番煎じじゃないかという批判もありそうですが、 これらをコンパクトにまとめたということに価値があると思います。 また、既に知っている内容でもああこれあのとき仕事で使ってた内容だよなとか、 あの本で読んだよなと思い返すことで、自分の中の知識がより強固に定着していくので、 良いかと思います。 職場で働いている人たち全員に読んでほしい本です。 なお、The Art Of Readable Code(原著)も平易な英語で書かれていて読みやすいそうなので、英語の勉強がてら読むのもオススメです。
リーダブルコード(和訳) The Art Of Readable Code(原著) コードはただ動けばよいだけでなく、読みやすい必要があります。
コードが読みにくいとバグを内包しやすくなるし、 他人はおろか自分自身も読みにくく変更しにくくなり、 その後の保守コストが上がるからです。
本書はコードを読みやすくするためのノウハウが挿絵とともにコンパクトにまとまっています。
主観ですが、初級～中級者向けの内容で、
大体４時間くらいあれば一通り読みきれるくらいのボリュームです。
たぶん、もっと熟練した人の場合は、 Code Complete や プログラミング作法 や Clean Code などの二番煎じじゃないかという批判もありそうですが、 これらをコンパクトにまとめたということに価値があると思います。 また、既に知っている内容でもああこれあのとき仕事で使ってた内容だよなとか、 あの本で読んだよなと思い返すことで、自分の中の知識がより強固に定着していくので、 良いかと思います。 職場で働いている人たち全員に読んでほしい本です。 なお、The Art Of Readable Code(原著)も平易な英語で書かれていて読みやすいそうなので、英語の勉強がてら読むのもオススメです。
2011年12月23日金曜日
英語の勉強会
たまには海以外のことも書こうと思う。
いつもダイビングと残業しかしていないと思っているそこのあなた、
大間違いですぞ！！
というわけで表題の件、
ちょうど３年前から通訳のお仕事をしていた従姉妹に
シャドーイングとサイトトランスレーション教えてもらって
細々と勉強を続けています。
ちなみに従姉妹は以下のようなビジネスパーソン向けの
英語を指導するお仕事してます（宣伝）
http://www.g-e4b.jp/
＜結果＞
３年で以下２冊の本をシャドーイングしただけ。
１．オバマ演説集
http://www.amazon.co.jp/%E7%94%9F%E5%A3%B0CD%E4%BB%98%E3%81%8D-%E3%82%AA%E3%83%90%E3%83%9E%E6%BC%94%E8%AA%AC%E9%9B%86-CNN-English-Express%E7%B7%A8/dp/425500451X
２．オバマから子供たちへ
http://www.amazon.co.jp/%E7%94%9F%E5%A3%B0CD%E4%BB%98%E3%81%8D-%E3%82%AA%E3%83%90%E3%83%9E%E3%81%8B%E3%82%89%E5%AD%90%E3%81%A9%E3%82%82%E3%81%9F%E3%81%A1%E3%81%B8-CNN-English-Express%E7%B7%A8/dp/4255004927
＜方法＞
「１．オバマ演説集」は朝とか仕事の帰りに一人でやってたのですが、
やるときとやれないときでムラができるということで。
「２．オバマから子供たちへ」は仲間内で有志を募って、
約１年かけて一通りやりました。結局メンバは２人でしたが。
週１，２回で早朝業務時間外で１時間ずつやってました。
＜効果＞
☆英語面☆
Michael Jacksonが何歌っているかくらいは聞こえるようになった
海外旅行に必要な英語のコミュニケーションには困らないくらいにはなった
（例えば財布をなくして警察に事情を説明するとか）
でも、技術系のカンファレンスで英語でガンガン喋られるとついていけない
他部署の外国人と簡単な仕事の話（愚痴）ができるようになった
☆メンタル面☆
仕事も世の中も明るくないことだらけだけど、頑張ろうという気になれる。
言ってることが実体験に基づいているので、
話し方も分かりやすいししっくりくるんですよ。
（演説内容自体はゴーストライターが書いてるかもしれないけど）
でも、その人自身の言葉だから心に響くんだと思う。
今後も続けていきたいと思うのだけど、
次は誰のスピーチをシャドーイングしようか悩み中。
ジョブズの卒業スピーチがよいかなと思うのだが、
http://www.youtube.com/watch?v=qQDBaTIjY3s
あえて、自分でディクテーションでスクリプト起こしても
面白いかもしれない。
いつもダイビングと残業しかしていないと思っているそこのあなた、
大間違いですぞ！！
というわけで表題の件、
ちょうど３年前から通訳のお仕事をしていた従姉妹に
シャドーイングとサイトトランスレーション教えてもらって
細々と勉強を続けています。
ちなみに従姉妹は以下のようなビジネスパーソン向けの
英語を指導するお仕事してます（宣伝）
http://www.g-e4b.jp/
＜結果＞
３年で以下２冊の本をシャドーイングしただけ。
１．オバマ演説集
http://www.amazon.co.jp/%E7%94%9F%E5%A3%B0CD%E4%BB%98%E3%81%8D-%E3%82%AA%E3%83%90%E3%83%9E%E6%BC%94%E8%AA%AC%E9%9B%86-CNN-English-Express%E7%B7%A8/dp/425500451X
２．オバマから子供たちへ
http://www.amazon.co.jp/%E7%94%9F%E5%A3%B0CD%E4%BB%98%E3%81%8D-%E3%82%AA%E3%83%90%E3%83%9E%E3%81%8B%E3%82%89%E5%AD%90%E3%81%A9%E3%82%82%E3%81%9F%E3%81%A1%E3%81%B8-CNN-English-Express%E7%B7%A8/dp/4255004927
＜方法＞
「１．オバマ演説集」は朝とか仕事の帰りに一人でやってたのですが、
やるときとやれないときでムラができるということで。
「２．オバマから子供たちへ」は仲間内で有志を募って、
約１年かけて一通りやりました。結局メンバは２人でしたが。
週１，２回で早朝業務時間外で１時間ずつやってました。
＜効果＞
☆英語面☆
Michael Jacksonが何歌っているかくらいは聞こえるようになった
海外旅行に必要な英語のコミュニケーションには困らないくらいにはなった
（例えば財布をなくして警察に事情を説明するとか）
でも、技術系のカンファレンスで英語でガンガン喋られるとついていけない
他部署の外国人と簡単な仕事の話（愚痴）ができるようになった
☆メンタル面☆
仕事も世の中も明るくないことだらけだけど、頑張ろうという気になれる。
言ってることが実体験に基づいているので、
話し方も分かりやすいししっくりくるんですよ。
（演説内容自体はゴーストライターが書いてるかもしれないけど）
でも、その人自身の言葉だから心に響くんだと思う。
今後も続けていきたいと思うのだけど、
次は誰のスピーチをシャドーイングしようか悩み中。
ジョブズの卒業スピーチがよいかなと思うのだが、
http://www.youtube.com/watch?v=qQDBaTIjY3s
あえて、自分でディクテーションでスクリプト起こしても
面白いかもしれない。
2011年10月9日日曜日
TDD Boot Camp For C++
前述のような問題意識で、
http://thatsmyway-esper.blogspot.com/2011/10/tdd.html
開発サイクルを短くするためのスキルを身につけるために
に行ってきました。
行ってみての感想としては今まで参加した社外イベントの中で一番よかったです。
というのも、
１．実際にプログラムを書いてTDDサイクルを回すことで、
小さいサイクルでプログラミングするスピード感を感じることができた
２．一人では導入するのが面倒くさい、TDD環境を自分のPCに導入することができた
３．ボトムアップでやっていくことの重要性を意識することができた
というのがあったからです。
１．実際にプログラムを書いてTDDサイクルを回すことで、
小さいサイクルでプログラミングするスピード感を感じることができた
これは実際にやってみないと見たり聞いたりしただけでは
分からないことだと思いました。そして、TDDとは話が逸れてしまいますが、
演習のペアプログラミングがすごく楽しくてあっという間に時間が過ぎてしまいました。
疲れましたが、久しぶりにアルゴ的な頭の使い方をして、
仕事の疲れとは違って爽快でした。
２．一人では導入するのが面倒くさい、TDD環境を自分のPCに導入することができた
TDDをやるうえで、一番の敷居はここだと思っています。
私は普段メーカーの製品のデバイスドライバのソフトを作っていますが、
かなりエレキと近いところをやっていて、業務でオシロスコープで波形を測ったりするくらいで、
開発環境がWeb系のプログラマなどに比べて非常に弱いです。
設計者も全員がとは言いませんが、構成管理ツールやテストの自動化などに対して
非常に意識が低く、人によっては作業を全部手でやらないと安心できないという人すらいます。
今回TDDをやるために導入したものは
１．GitHub（分散リポジトリ）
２．GoogleTest
３．Visual C++ 2010
です。知っている人が上記をネットからダウンロードして、
使う分には何も問題ありませんが、知らない人が独力で上記をダウンロードして設定するのは
結構厳しいと思います。
てか、GitHubがすごくいい。
分散リポジトリを初めて使ったのですが、
開発者がローカルで気軽にファイルをコミット（Ｃｉｎ）できるというのがすごくいい。
テストが動いた時点ですぐにファイルをコミットしていくことができるので、
一度に大量にファイルをコミットする場合に比べてすごく安心感があります。
TDDでは失敗するテストを先に作って、
それを成功するようにプロダクトコードを書いていくので
作る側としてはテストを作れば作るほど、
動作が保証されていくので非常に安心感があります。
後、GoogleTestはテストが自動なのでテストの数が増えても苦になりません。
３．ボトムアップでやっていくことの重要性を意識することができた
自分一人だけTDDやって、生産性が向上したとしても、
あまり組織としての利益というのはあまりなくて、
周りを巻き込んでやることの重要性というのを再認識しました。
そして、何かを変えるにはトップダウンではなく
ボトムアップでないといけないのかなとも思いました。
例えば、コンサルの人が使うような資料を以って上を説得して、
トップダウンでTDDをやろうとしても、
きっと異なる開発環境や開発スタイルへの不適応が起こって、
形骸化して破綻するような気がします。
今までそういうのを何度も見てきているし。
最近、誰でもできるようなフレームワークを作って
設計は上流までで、下流のプログラミングは誰でもできるようにして、
安い人件費でコストを下げようみたいな風潮を感じることがありますが、
誰でもプログラミングできるわけがないと思っています。
分かりやすい設計をすることは重要ですが、
誰でも設計・実装できるようにするというのは夢物語で
ちゃんと技術を分かっている人が草の根でやって、教育して
全体の底上げを図っていかないとだめなのかと思います。
というわけで、自宅に環境も整ったことなので、
仕事の合間にTDDの活動にコミットしたい名と思います。
また次のイベントがあったら行きたい！
http://thatsmyway-esper.blogspot.com/2011/10/tdd.html
開発サイクルを短くするためのスキルを身につけるために
TDD Boot Camp 東京 for C++
http://www.zusaar.com/event/agZ6dXNhYXJyDQsSBUV2ZW50GK_kBgwに行ってきました。
行ってみての感想としては今まで参加した社外イベントの中で一番よかったです。
というのも、
１．実際にプログラムを書いてTDDサイクルを回すことで、
小さいサイクルでプログラミングするスピード感を感じることができた
２．一人では導入するのが面倒くさい、TDD環境を自分のPCに導入することができた
３．ボトムアップでやっていくことの重要性を意識することができた
というのがあったからです。
１．実際にプログラムを書いてTDDサイクルを回すことで、
小さいサイクルでプログラミングするスピード感を感じることができた
これは実際にやってみないと見たり聞いたりしただけでは
分からないことだと思いました。そして、TDDとは話が逸れてしまいますが、
演習のペアプログラミングがすごく楽しくてあっという間に時間が過ぎてしまいました。
疲れましたが、久しぶりにアルゴ的な頭の使い方をして、
仕事の疲れとは違って爽快でした。
２．一人では導入するのが面倒くさい、TDD環境を自分のPCに導入することができた
TDDをやるうえで、一番の敷居はここだと思っています。
私は普段メーカーの製品のデバイスドライバのソフトを作っていますが、
かなりエレキと近いところをやっていて、業務でオシロスコープで波形を測ったりするくらいで、
開発環境がWeb系のプログラマなどに比べて非常に弱いです。
設計者も全員がとは言いませんが、構成管理ツールやテストの自動化などに対して
非常に意識が低く、人によっては作業を全部手でやらないと安心できないという人すらいます。
今回TDDをやるために導入したものは
１．GitHub（分散リポジトリ）
２．GoogleTest
３．Visual C++ 2010
です。知っている人が上記をネットからダウンロードして、
使う分には何も問題ありませんが、知らない人が独力で上記をダウンロードして設定するのは
結構厳しいと思います。
てか、GitHubがすごくいい。
分散リポジトリを初めて使ったのですが、
開発者がローカルで気軽にファイルをコミット（Ｃｉｎ）できるというのがすごくいい。
テストが動いた時点ですぐにファイルをコミットしていくことができるので、
一度に大量にファイルをコミットする場合に比べてすごく安心感があります。
TDDでは失敗するテストを先に作って、
それを成功するようにプロダクトコードを書いていくので
作る側としてはテストを作れば作るほど、
動作が保証されていくので非常に安心感があります。
後、GoogleTestはテストが自動なのでテストの数が増えても苦になりません。
３．ボトムアップでやっていくことの重要性を意識することができた
自分一人だけTDDやって、生産性が向上したとしても、
あまり組織としての利益というのはあまりなくて、
周りを巻き込んでやることの重要性というのを再認識しました。
そして、何かを変えるにはトップダウンではなく
ボトムアップでないといけないのかなとも思いました。
例えば、コンサルの人が使うような資料を以って上を説得して、
トップダウンでTDDをやろうとしても、
きっと異なる開発環境や開発スタイルへの不適応が起こって、
形骸化して破綻するような気がします。
今までそういうのを何度も見てきているし。
最近、誰でもできるようなフレームワークを作って
設計は上流までで、下流のプログラミングは誰でもできるようにして、
安い人件費でコストを下げようみたいな風潮を感じることがありますが、
誰でもプログラミングできるわけがないと思っています。
分かりやすい設計をすることは重要ですが、
誰でも設計・実装できるようにするというのは夢物語で
ちゃんと技術を分かっている人が草の根でやって、教育して
全体の底上げを図っていかないとだめなのかと思います。
というわけで、自宅に環境も整ったことなので、
仕事の合間にTDDの活動にコミットしたい名と思います。
また次のイベントがあったら行きたい！
TDDについて
１年くらい更新が滞ってました。
土曜にTDDBootCampというイベントがあって、
非常に楽しかったのと非常に有益だと感じたので
ブログに書いて、シェアできないかと思った次第です。
そもそもTDDって何かについて。
Test Driven Developmentの略でテスト駆動開発といいます。
http://www.amazon.co.jp/Test-Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X
私自身の問題意識としては仕事で、作ったプログラムをCin(あるいはコミット)するまでの
開発サイクルがあまりに長いのが何とかならないものかというものがあって、
TDDBootCampに参加しました。
開発サイクルが長いと以下の問題があります
・一度にCin(あるいはコミット)するファイルの数が増えるので、バグの混入率が上がる
・上記バグにより手戻りが増え、デバッグのための開発コストが増える
・デバッグというのはいつ終わるか見通しがつきにくく工数見積もりの精度が下がる
・そもそも長期間でスケジュールを立てるので、なかなか正確な工数見積もりができない
結果として、プロジェクトの遅延と残業超過、開発者の心身荒廃につながります。
私のいる環境は気軽にCin(あるいはコミット)できる環境ではなく、
一つの対応をCin(あるいはコミット)するのに最短でも３日、通常で１，２週間、
ひどいときだと１ヶ月以上ファイルをローカルに持ち続けていることがあり、
かなり酷い目（鬼残業デバッグ）に会っています。
それに対して、TDDはその名のとおり、テストを最初に作ります。
サイクルとしては以下の１～３のとおりです。
１．プロダクトコードではなくテストコードを最初に書きます。
２．このテストコードはテストとしては失敗する状態のもので、
そのテストが成功するようにプロダクトコードを書いていきます。
３．テストが動いた（成功した）時点で、
すぐにファイルをCin(あるいはコミット)できるというところにあります。
１～３の小さなサイクルを繰り返していくのです。
以下に私がTDDのメリットだと思うことをあげます。
（１）テストを最初に書くので、最初にきちんとユースケースを意識することになり、
開発後半でのユースケース漏れする確率が減ります。
（２）失敗するテストコードが成功するまでプロダクトコードを書くので、
プロダクトコードを書いてからテストコードを書く場合に比べて、
テスト漏れやミスが起きにくいです。
（３）テストが動いた（成功した）時点で、
すぐにファイルをCin(あるいはコミット)できるので、
一度に大量にCin(あるいはコミット)する場合よりもミスや手戻りが減ります。
テストを最初にやって、開発初期の段階で
テスト結果により即フィードバックをもらいながら
小さいサイクルで物を作っていこうというものです。
バグは発見が遅れれば遅れるほど指数関数的にデバッグ・修正コストが増大していきます。
逆に言うと開発初期の段階で見つけることができれば、
プロジェクトの遅延も残業コストの低減にも開発者の健康にもつながるのです。
（TDDだけで上記が達成できるとは言いませんが）
ただ、言うことと実際にやることは全く以って異なるので、
今回TDDBootCampForC++に参加しました。
長くなったのでTDDBootCampForC++については別に書きます。
土曜にTDDBootCampというイベントがあって、
非常に楽しかったのと非常に有益だと感じたので
ブログに書いて、シェアできないかと思った次第です。
そもそもTDDって何かについて。
Test Driven Developmentの略でテスト駆動開発といいます。
http://www.amazon.co.jp/Test-Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X
私自身の問題意識としては仕事で、作ったプログラムをCin(あるいはコミット)するまでの
開発サイクルがあまりに長いのが何とかならないものかというものがあって、
TDDBootCampに参加しました。
開発サイクルが長いと以下の問題があります
・一度にCin(あるいはコミット)するファイルの数が増えるので、バグの混入率が上がる
・上記バグにより手戻りが増え、デバッグのための開発コストが増える
・デバッグというのはいつ終わるか見通しがつきにくく工数見積もりの精度が下がる
・そもそも長期間でスケジュールを立てるので、なかなか正確な工数見積もりができない
結果として、プロジェクトの遅延と残業超過、開発者の心身荒廃につながります。
私のいる環境は気軽にCin(あるいはコミット)できる環境ではなく、
一つの対応をCin(あるいはコミット)するのに最短でも３日、通常で１，２週間、
ひどいときだと１ヶ月以上ファイルをローカルに持ち続けていることがあり、
かなり酷い目（鬼残業デバッグ）に会っています。
それに対して、TDDはその名のとおり、テストを最初に作ります。
サイクルとしては以下の１～３のとおりです。
１．プロダクトコードではなくテストコードを最初に書きます。
２．このテストコードはテストとしては失敗する状態のもので、
そのテストが成功するようにプロダクトコードを書いていきます。
３．テストが動いた（成功した）時点で、
すぐにファイルをCin(あるいはコミット)できるというところにあります。
１～３の小さなサイクルを繰り返していくのです。
以下に私がTDDのメリットだと思うことをあげます。
（１）テストを最初に書くので、最初にきちんとユースケースを意識することになり、
開発後半でのユースケース漏れする確率が減ります。
（２）失敗するテストコードが成功するまでプロダクトコードを書くので、
プロダクトコードを書いてからテストコードを書く場合に比べて、
テスト漏れやミスが起きにくいです。
（３）テストが動いた（成功した）時点で、
すぐにファイルをCin(あるいはコミット)できるので、
一度に大量にCin(あるいはコミット)する場合よりもミスや手戻りが減ります。
テストを最初にやって、開発初期の段階で
テスト結果により即フィードバックをもらいながら
小さいサイクルで物を作っていこうというものです。
バグは発見が遅れれば遅れるほど指数関数的にデバッグ・修正コストが増大していきます。
逆に言うと開発初期の段階で見つけることができれば、
プロジェクトの遅延も残業コストの低減にも開発者の健康にもつながるのです。
（TDDだけで上記が達成できるとは言いませんが）
ただ、言うことと実際にやることは全く以って異なるので、
今回TDDBootCampForC++に参加しました。
長くなったのでTDDBootCampForC++については別に書きます。
登録:
投稿 (Atom)