テクノロジックアート技術者のブログ

先週のアジャイルカンファレンス東京2009は、たくさんの来場者があり、かなり盛り上がりました。
また、ThoughtWorksと事例のセッションでは、具体的な話があり、地に足がついている開発経験だったので、よかったです。さらに、IBMさん、MSさんのツールの実演は、アジャイル開発の実際を見ることができ、一昔前との違いを見ることができました。

http://gihyo.jp/news/report/2009/12/1601

カンファレスの後の金曜日に、ThoughtWorksサンフランシスコ支社に行って来ました。
北京のオフィスとは少しの違いだけで、いかにもアジャイルな会社という雰囲気でした。
また、お客さんの現場に案内していただき、実際のアジャイル開発の様子を見学することができ
米国でのアジャイル開発を実感できました。

これからは、日本でいかにアジャイル開発を成功させるか、というのが重要です。
日本では、契約や品質の問題があり、米国と同じようにはできません。
カンファレンスで発表しましたが、アジャイル開発QIMP研究会というを発足しましたので
この研究会のアウトプットを期待していただければと思います。

長瀬

投稿者: nagase 日時: 15:16 | パーマリンク | コメント (0) | トラックバック (0)

１２月８日にアジャイルコンファレンスを行ないます。
テーマは大規模なアジャイル開発です。エンタープライズという言葉もあります。
今回は、大手企業がどのようにアジャイル開発を考えるかということも、焦点です。

今日、日経コンピュータのアジャイル事例の記事を読みました。
大手企業が成功しているのですね。うちが関係しているプロジェクトが２つ（３つかも）
ありました。

アジャイルの事例が気になったので、アジャイル開発　失敗でググってみました。

http://japan.internet.com/column/developer/20090203/26.html

http://www.infoq.com/jp/news/2008/07/agile_failures

http://www.thinkit.co.jp/free/article/0608/3/1/

http://www.asp-edita.jp/doda/one/doda4075_365.html

http://builder.japan.zdnet.com/news/story/0,3800079086,20379593,00.htm

かなり面白い記事が出て来ました。

そう、アジャイル開発は難しいから、失敗することも多いのです。

これから、アジャイル開発が流行ってくると、失敗事例もたくさん表面に出てくると思います。

アジャイル開発を導入する前に、開発対象のシステムがアジャイルに向いているか、顧客との関係、プロジェクトの雰囲気、メンバーのスキル、など、成功するために見極めるポイントがいくつもあるのでそういうことを考えて、アジャイルにするかどうかを決めるべきです。

２０００年にはじめてXPを日本に紹介し、Agileの日本での呼び方をマーチン・ファウラーの発音に合わせて、アジャイルに決めて、１０人経ってようやく、再注目されだしました。

JavaやUMLも普及にはずいぶんと時間がかかりましたが、アジャイルもようやくです。

長瀬

投稿者: nagase 日時: 22:04 | パーマリンク | コメント (0) | トラックバック (0)

こんにちわ。ばたっちです。

ずいぶん、ご無沙汰のエントリになりますが、とりあえず生きています。(^^;

ご縁があって翔泳社様の「独習Ruby」の執筆をさせて頂いていたのですが、ついに書籍が発売されました！（パチパチ）

独習Ruby 出版：翔泳社

本ができて来ると、「おおーっ、本物の本だー」って感動しますね。
本書いてるんだから、当たり前といえば、当たり前なんですが。。

Ruby関連本の出版ラッシュが、そろそろ落ち着いてきたかなというタイミングですが、こちらは「独習」シリーズということもあり、先端を行く人よりは、じっくりRubyを学習したい人に手にして欲しい本だと思います。
（Ruby関連本はハッカー気質な人を想定している本が多いようなので。。A^^;）

内容はRubyという言語の習得はもちろんですが、文法が分かってもオブジェクト指向プログラミングはできないので、

「じゃあ、オブジェクト指向でプログラミングするにはどうするのよ？」

というところにも踏み込んでみました。
Rubyも学べて、オブジェクト指向プログラマにもなれるというわけですね♪(^^)v

さらに、一歩先に行くための TDD(テスト駆動開発)やデザインパターンについても説明しています。

ちなみに、本書は序文に「達人プログラマ」「Programing Ruby」の Dave Thomas氏からメッセージを頂いています。(光栄！)

「Code Ruby, Be Happy!」

プログラミングを楽しむための言語であるRubyを、シンプルに表現していますね♪
こんな一文が書けるようになりたいものです。。A^^;

最後に、編集作業でお世話になりました翔泳社のＵ様、執筆作業のフォローして頂いた長瀬社長はじめ、社員の皆様、ありがとうございました。m(_ _)m

投稿者: kawabata 日時: 14:04 | パーマリンク | コメント (2) | トラックバック (0)

ケント・ベックがメーリングリストで紹介していた
アジャイル開発に関するPDFブックです。

http://www.pomodorotechnique.com/

長瀬

投稿者: nagase 日時: 12:54 | パーマリンク | コメント (0) | トラックバック (0)

昨日、Qcon2009のために、来日したマーチンファウラーと食事をしました。最近の米国のアジャイル関係の状況やケントベック、ケンシュウェイバー、デーブトーマスなどの人たちについて、話を聞きました。興味深い話もたくさんあり、さすが、ファウラーだなと思いました。
また、今年の１２月に企画している、ThoughtWorksとのイベントの話もして、日本でのアジャイル関係の活動について、理解してもらいました。

技術と関係ない話では、日本食やお茶の話をして、盛り上がりました。前回、MSさんと企画したアジャイルコンファレンスから３年が経ちましたが、ファウラーはほとんどかわらず、前向きでした。
Rubyにかなり力を入れているので、もうすぐ出版される「独習Ruby」の話をしておきました。
「独習Ruby」の中でもふれていますが、RubyのためのデザインパターンやTDDという議論を
ファウラーとできたらと思いました。

長瀬

投稿者: nagase 日時: 14:28 | パーマリンク | コメント (0) | トラックバック (0)

先週、ThoughtWorksに行って来ました。
ThoughtWorksはマーチンファウラーが所属する会社で、ワールドワイドで
1200人エンジニアを有する世界No.1のアジャイル開発の会社です。

彼らの環境、ツール、事例を見せてもらい、本格的なアジャイル開発に
驚きました。彼らのアジャイル開発のイテレーションは１週間で、かなり
短いサイクルで開発しています。また、アジャイル開発のサイズについて
聞いたところ、400人ぐらいまでは大丈夫とのことです。実際に、400人の
アジャイルプロジェクトをコンサルしていると言っていました。
日本では、本格的な大規模アジャイルプロジェクトの経験を持っている人が
いないので、ビジネスパートナーであるこちらが窓口になって、コンサルビジネスを
今後は行なっていきます。

これに先だって、秋ぐらいに、ThoughtWorksのイベントを開催する予定です。
本格的なアジャイルのコンファレンスに先々はしていきたいので、期待していて
ください。

長瀬

投稿者: nagase 日時: 17:42 | パーマリンク | コメント (0) | トラックバック (0)

　システム開発を日本から海外に発注するオフショア開発は年々増加しています。しかし、オフショア開発は多くの問題を抱えています。今回は、人材育成についての問題を説明します。

　オフショア開発企業での技術者は、大学の技術系の学部を卒業して、もしくは専門学校でのプログラミング教育を受けています。入社前に基本的なプログラミングや開発環境についてのトレーニングを受けます。そして、すぐにプログラマとなり、コーディング作業を行ないます。日本では、プロラグマを２〜３年やって、後に設計ができるようになり、SEとなっていきます。ところが、オフショア開発ではSEではなく、プログラマの次はPM（プロジェクトマネージャー）になってしまいます。それは、オフショア開発では設計工程を行なうことがあまりないからです。設計工程は日本で行なってしまうため、オフショア側ではプロジェクトの管理、実装、単体テストしかなくなります。そうなると、オフショア開発企業にはSEがほとんどいなくなってしまいます。人材の比率が、非常にアンバランスになってしまうのです。

状況と原因をまとめると、以下のようなことが考えられます。

・日本で設計するため、設計ノウハウがたまらない。
・設計の教育を社員にすると、エンジニアが転職する。
・設計の指導をするトレーナー（教育者）がいない。

オフショア側に設計者がいないことによって、オフショアに出せる開発は、実装工程、単体テスト工程だけとなり、開発全体の１／５程度になってしまいます。このぐらいの規模であれば、オフショアによるコストメリットは得られません。
たかだか１／５のために、出張費、コミュニケーションロスのための手戻りなどがかかると、メリットはほとんどなくなってしまいます。
さらに、設計ができないプログラマによって書かれたコードは品質が悪く、保守費用が日本で開発したものと比較して３倍以上かかります。結果として、オフショア開発によりメリットを得られるばかりか、デメリットの方が大きくなります。不良資産を抱え込むのと同じです。

オフショア先での人材育成と人材マップが変わらなければ、今後はオフショア開発が減っていくでしょう。そんなオフショアで開発するよりも、アジャイル開発やUMLによるモデル駆動型開発によって、生産性を上げて、国内で開発した方がいいでしょう。

それでは、この問題の解決策はどうすればいのでしょうか？

それは、オフショア開発企業でも設計に関する教育をして、SEを育成するしかありません。もちろん、せっかく教育したエンジニアが転職してしまうかもしれません。しかし、設計できなければ、今後は開発の仕事を得られません。

次回は、弊社の中国での教育の実際を説明して行きたいと思います。

長瀬

投稿者: nagase 日時: 12:02 | パーマリンク | コメント (0) | トラックバック (0)