<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>テクノロジックアート技術者のブログ</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/" />
    <link rel="self" type="application/atom+xml" href="http://pw.tech-arts.co.jp/technical/atom.xml" />
   <id>tag:pw.tech-arts.co.jp,2010:/technical//5</id>
    <link rel="service.post" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5" title="テクノロジックアート技術者のブログ" />
    <updated>2010-07-26T23:48:55Z</updated>
    
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type  5.02</generator>
 

<entry>
    <title>Open@ReeL の契約の考え方(続き)</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2010/07/openreel_1.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=416" title="Open@ReeL の契約の考え方(続き)" />
    <id>tag:pw.tech-arts.co.jp,2010:/technical//5.416</id>
    
    <published>2010-07-26T23:44:19Z</published>
    <updated>2010-07-26T23:48:55Z</updated>
    
    <summary>先日ReeL の契約の考え方をご紹介しました。 関連するもう一つのトピックとして...</summary>
    <author>
        <name>shitara</name>
        
    </author>
    
        <category term="ReeL" />
    
        <category term="アジャイル／XP" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        <![CDATA[先日ReeL の契約の考え方をご紹介しました。
関連するもう一つのトピックとしてバッファ管理の話があります。

ReeL では、ご紹介したように、「固定スコープの請負(基本) + 変動スコープ(上乗せ分)」 という考え方を前提としています。
この変動スコープの部分の実態は、現場によりまちまちでしょう。
目標コスト契約であったり、準委任との組み合わせであるかもしれません。
いずれにせよ、変動スコープの部分にも金額的に上限を見て、その枠内で実際に何をやるかを顧客と協議することになります。

すると必要になるのが、変動分予算(=バッファ)の管理です。
ある機能を追加で加えたならば、いくら予算を食いつぶすのか? といった話です。

<strong>○ アジャイル開発での対応</strong>

一般的には、実績ベースです。
人月幾らで契約しておいて、実際にかかった工数を請求します。
これは分かりやすさという意味でメリットは大きいのですが、
顧客側が全てのリスクを背負う形態なので、それを納得してもらう必要があります。
顧客側がリスクをとる前提として、開発側は開発の実態の全てを開示する透明性が必要となるでしょう。

<strong>○ ReeL での対応</strong>

開発の透明性を高め、顧客に全てのリスクを背負ってもらう方式は、日本のSIの現場ではなじみません。
SIer がリスクを吸収してきた一括請負の考え方とはあまりにも異なるからです。
日本のSIの現場では、顧客はそこまでのリスクを背負うことを嫌がるでしょうし、
SIer は開発のコスト構造の全てを開示することを嫌がるでしょう。

また、実績ベースでソフトウェアの価格を決定するという考え方そのものにも違和感はあります。
あるソフトウェアの値段は、その機能の大きさで決まるべきで、安く作るか、高く作るかは
開発側の努力次第であるべきという考え方もあります。

「COMMONDATION-ReeL」では、このような考え方を踏まえ、
バッファの取り崩しにファンクションポイント(FP)を採用しようとしています。
仕様変更や仕様追加に関するFPの変動分から、バッファの取り崩し金額を算出する方法です。
FP と実態との乖離については、開発側で吸収することになります。
実際には、差分FPの算出などでもう少しややこしい話が入るのですが、基本的な考え方としてはこのような話になっています。

ファンクションポイントを使うもう一つのメリットは、客観性です。
ある仕様変更がソフトウェアにもたらすインパクトを、検証可能な形で提示することができます。
バッファの取り崩し量で、顧客側と不毛なやりとりを避けることができます。

Open@ReeL では、さすがにファンクションポイントを自在に駆使することを前提にはできない
と思っていますので、この辺りは考え方のスキームを提示するに留めようと思っています。

整理しますと、
変動スコープのバッファについては、
・取り崩しの単位を顧客と事前に合意しておくことが必須となる。
・取り崩しの単位は、機能単位ベースの見積額の方が導入しやすい
・取り崩しの単位は、客観的に測定可能であった方が好ましい
となります。

実際には、個別のコンテキストに左右されることが大きいので、
「顧客と合意できていれば何でも良い」という話にはなるでしょう。

<small>※ COMMONDATION は、株式会社日立システムアンドサービスの日本における商品名称（商標又は登録商標）です。</small>

<div style="text-align: right;">アジャイルグループ グループリーダー 設楽 秀輔</div>]]>
        
    </content>
</entry>

<entry>
    <title>アジャイルALM</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2010/07/alm.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=415" title="アジャイルALM" />
    <id>tag:pw.tech-arts.co.jp,2010:/technical//5.415</id>
    
    <published>2010-07-23T00:11:01Z</published>
    <updated>2010-07-23T00:16:34Z</updated>
    
    <summary>Agile Conference Tokyo 2010。大盛況のうちに終了しまし...</summary>
    <author>
        <name>shitara</name>
        
    </author>
    
        <category term="アジャイル／XP" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        <![CDATA[Agile Conference Tokyo 2010。大盛況のうちに終了しました。
3人掛けの席がほぼ3人で埋まり、急遽テーブルを追加する等、平日の無料のカンファレンス
にしては、驚異的な出席率でした。
世の中のアジャイルに対する関心の高さが、如実に表れていたと思います。
ご来場いただきました皆さま、本当にありがとうございました。

各セッション、それぞれ様々な方向に突き抜けており、個人的にも飽きることのない一日でした。
特に、ThoughtWorks 社 Jez Humble 様の基調講演や、ツールベンダー様のセッションでは、
アジャイルの最先端の情報が提供されました。
「ここまでやるんだ!!」ですとか「ここまでできるのか!!」といった驚きがあったと思います。

最近、アジャイルはむんむんと存在感を増しています。
その一つのキーワードとして、アジャイル ALM (Application Lifecycle Management)があります。
プロジェクトを進める開発プロセスとしてだけのアジャイルではなく、ビジネスとしてソフトウェアの
製造・販売・サポート・バージョンアップ等、計画から投資回収までの一連のプロセスの
隅々にまで、アジャイルの思想を行き渡らせようとするものです。
もともと、アジャイルはビジネスニーズから発展してきたものですし、
本当にアジャイル開発を進めようと思ったら、企業のビジネスそのものがアジャイルになって
ゆかないと、上手くいきません。
その意味では、当然の流れともいえます。

Agile Conference でも、そのような最先端の流れを感じ取ることができました。
IBM 様の講演では、思いっきり CALM (Collabolative ALM)という概念のご紹介がありました。
Microsoft 様の講演では、直接的な表現こそありませんでしたが、TFS の開発そのものが
アジャイルALM でなされており、同様のコンセプトであると受け止めています。

そして、Jez Humble 様の講演にあった Continuous Delivery 等は、ThoughtWorks 社の ALM の考えに基づいたものとなっています。
ThoughtWorks 社では、<a href="http://www.thoughtworks-studios.com/solutions/application-lifecycle-management">Adaptive ALM</a> というコンセプトを打ち出しています。
詳細は、上記リンクからご確認下さい。
それは、具体的に ThoughtWorks Studios なる製品群で支えられています。
Jez Humble 様は、ThoughtWorks Studios の一つ Go (旧 Cruise)の製品開発責任者でもあります。
弊社でも<a href="http://pw.tech-arts.co.jp/tw/">代理販売</a>をしておりますので、これらのコンセプトに興味をお持ちの方は、お声掛けいただければと思います。

まだまだ、日本のアジャイルは ALM とはほど遠い状況ですが、
昨今のムーブメントを鑑みるに、近い将来これらの考え方が普通になる日が来るような気がしています。

<div style="text-align: right;">アジャイルグループ グループリーダー 設楽 秀輔</div>]]>
        
    </content>
</entry>

<entry>
    <title>Open@ReeL の契約の考え方</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2010/07/openreel.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=414" title="Open@ReeL の契約の考え方" />
    <id>tag:pw.tech-arts.co.jp,2010:/technical//5.414</id>
    
    <published>2010-07-20T09:22:45Z</published>
    <updated>2010-07-20T10:43:13Z</updated>
    
    <summary>Open@ReeL の公表前ではありますが、ReeL における契約についての考え...</summary>
    <author>
        <name>shitara</name>
        
    </author>
    
        <category term="ReeL" />
    
        <category term="アジャイル／XP" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        <![CDATA[Open@ReeL の公表前ではありますが、ReeL における契約についての考え方を
ご紹介したいと思います。

日本のシステムの受託開発においては、SIの一括請負契約が一般的です。
一括請負契約では、本来ならば契約時点でスコープ(開発内容)は固定されて
いるはずです。しかしながら、開発の後工程になってからの仕様変更=スコープ
調整が多発するというのが現実です。

このような仕様変更を受け入れるといった場合には、追加契約をしない限り、
既存の契約金額の枠内(=ベンダー側負担)で受け入れることとなります。
その為、ベンダー側ではこれを見込んで多額のバッファを積んでおくのが実状です。
結果的に、顧客からみたシステムの構築コストは高いものとなってしまいます。

<strong>○ アジャイル開発での対応</strong>

このような問題を解決する為には、アジャイル開発では固定スコープの契約形態
(一括請負)を否定し、可変スコープの契約形態(準委任等)を推奨します。

なぜ固定スコープを否定するのでしょう?
それは、顧客とベンダーの関係において、利益の相反構造を本質的に内包しているからです。
固定スコープでは一定金額の枠の中で作業をするので、作業量の増加を意味する
スコープ変動は、ベンダー側の利益を食いつぶすことになります。
つまり、仕様変更による顧客のメリットはベンダーにとっての不利益となるという、
綱引きが発生する構造になっています。
このような Win-Lose の相反構造は、顧客との協調を最重視するアジャイル開発
にとっては、相容れないものとなっています。

アジャイル開発では、Win-Win の関係を目指します。
仕様変更や機能追加によって、顧客もメリットを得て、ベンダー側も利益を得る
構造に変更する必要があります。
一般的には、準委任契約が向いていると言われていますが、金額に上限を付け
ないと、ベンダー側に機能追加を抑制するインセンティブが働かず、システム
が肥大化する欠点も指摘されています。
顧客との協調関係においては、上限付きの可変スコープな契約が、一定金額内で
最適なストーリーのポートフォリオを一体となって模索するという意味において、
もっとも望ましいと言えるでしょう。

<strong>○ Open@ReeL での対応</strong>

しかし、これまでの商慣習を鑑みるに、上限付き可変スコープの契約に、全ての
契約を移行するのは現実的ではありません。
その為、Open@ReeL では、固定スコープの一括請負契約をベースとして考えます。
そのベースの上に、Win-Win の協調関係のオプションを一部取り込んでいく二段階の
アプローチを採用します。

協調関係を保てるオプションには、様々な形態があるでしょう。
Open@ReeL のベースになっている「COMMONDATION-ReeL」では、目標コスト契約
を想定しています。
詳細は、以下の記事を参照して下さい。

<a href="https://gihyo.jp/dev/serial/01/agt2010special/0002">「Agile Conference Tokyo 2010特別連載
  第2回　COMMONDATION-ReeLの契約と要件管理」</a>


それ以外にも、一部準委任契約を組み合わせる方式ですとか、請負金額に可変の
バッファ部分を設けて、余った分はインセンティブとしてシェアするような
方式も考えられます。

肝心なのは、顧客と契約時に Win-Win な協調関係で話を進める余地を一部に
設けることです。
たとえ一部であっても、そのようなスコープ調整の余地を設けようとすることで
顧客との話し合いは促進し、協調関係を改善させることができます。
また、一部に限定することで、顧客の関与度合を限定し負担を軽減させることにも
つながります。

このように、日本の実情に合わせて、アジャイル開発手法の適用方法を試行錯誤
してゆくことが大切であると考えています。

<small>※ COMMONDATION は、株式会社日立システムアンドサービスの日本における商品名称（商標又は登録商標）です</small>

<div style="text-align: right;">アジャイルグループ グループリーダー 設楽 秀輔</div>]]>
        
    </content>
</entry>

<entry>
    <title>アジャイルカンファレンス東京2010 と ReeL</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2010/07/2010.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=413" title="アジャイルカンファレンス東京2010 と ReeL" />
    <id>tag:pw.tech-arts.co.jp,2010:/technical//5.413</id>
    
    <published>2010-07-16T08:53:36Z</published>
    <updated>2010-07-20T07:31:43Z</updated>
    
    <summary>きたる 7/21(水)に、アジャイルカンファレンス東京2010が開催されます。 ...</summary>
    <author>
        <name>shitara</name>
        
    </author>
    
        <category term="ReeL" />
    
        <category term="アジャイル／XP" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        <![CDATA[きたる 7/21(水)に、アジャイルカンファレンス東京2010が開催されます。
手前味噌で恐縮ですが、最先端のトピックから、開発事例まで非常に興味深いセッションが並んでおります。

本日は、そのなかから、日立システムアンドサービスの英様による
<strong>「大規模システム向け日本版アジリティ開発手法「COMMONDATION－ReeL」」</strong>
のテーマについて簡単にご紹介させていただきます。

実は、私も「COMMONDATION-ReeL」の策定には協力させていただいております。

そもそもの背景として、これまでのアジャイル開発プロセスの導入で試行錯誤を重ねる上で、十分にアジャイル開発プロセスが普及しないという現実がありました。
原因としては、アジャイル開発プロセスには、日本のシステム開発現場では、あまり現実的でない前提が存在していることが挙げられます。
典型的な問題は、スコープ調整によるタイムボックス化です。
成果物を事前に約束する受託開発の SI案件が中心の日本の現場においては、固定スコープを否定する開発プロセスでは、問題解決になりません。
他にも、顧客の積極的な開発への関与や、ストーリー単位のインクリメンタル開発等も、PMOを持たない日本のお客様や、オブジェクト指向になじみのない開発現場では、なかなか難しいものがあります。

また、そもそも「アジャイル」というキーワードそのものに対して、否定的なイメージをもたれる方も多くいます。
自由闊達なボトムアップ型で発展してきた経緯の反動によるものと推察します。

「COMMONDATION-ReeL」では、このような日本の現状を正面から受け止め、肯定し、その上で使えるアジャイル開発プロセスを策定することを目指しました。
「アジャイル開発プロセス」とは何か? といった不毛な議論を避ける為にも「アジリティ開発手法」と呼んでいます。

プロセスの外観は、要件・作成・検証の3フェーズに分れており、ウォーターフォール型のプロセスに酷似しております。
その中に、二段階の反復や、不確定な要件のバッファ管理、顧客代理チームのようなプラクティスをちりばめています。
具体的にどのような内容のプロセスなのかは、アジャイルカンファレンス当日の発表にご期待下さい。

また、「COMMONDATION-ReeL」は、日立システムアンドサービス様の所有の開発プロセスとなります。
ですが、これまでの検討過程を踏まえて、「COMMONDATION-ReeL」の骨組みと汎用的なプラクティスを抽出したものを、「Open@ReeL」として弊社サイトにて公開予定です。
詳細が確定し次第、ご報告したいと思います。

<small>※ COMMONDATION は、株式会社日立システムアンドサービスの日本における商品名称（商標又は登録商標）です。</small>

<div style="text-align: right;">アジャイルグループ グループリーダー 設楽 秀輔</div>]]>
        
    </content>
</entry>

<entry>
    <title>アジャイルカンファレンス東京2009</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2009/12/2009_1.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=407" title="アジャイルカンファレンス東京2009" />
    <id>tag:pw.tech-arts.co.jp,2009:/technical//5.407</id>
    
    <published>2009-12-16T06:16:03Z</published>
    <updated>2010-07-15T07:02:14Z</updated>
    
    <summary>先週のアジャイルカンファレンス東京2009は、たくさんの来場者があり、かなり盛り...</summary>
    <author>
        <name>nagase</name>
        
    </author>
    
        <category term="アジャイル／XP" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        先週のアジャイルカンファレンス東京2009は、たくさんの来場者があり、かなり盛り上がりました。
また、ThoughtWorksと事例のセッションでは、具体的な話があり、地に足がついている開発経験だったので、よかったです。さらに、IBMさん、MSさんのツールの実演は、アジャイル開発の実際を見ることができ、一昔前との違いを見ることができました。

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

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

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

長瀬
        
    </content>
</entry>

<entry>
    <title>アジャイル開発の失敗について</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2009/11/post_22.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=406" title="アジャイル開発の失敗について" />
    <id>tag:pw.tech-arts.co.jp,2009:/technical//5.406</id>
    
    <published>2009-11-11T13:04:08Z</published>
    <updated>2010-07-15T07:02:14Z</updated>
    
    <summary>１２月８日にアジャイルコンファレンスを行ないます。 テーマは大規模なアジャイル開...</summary>
    <author>
        <name>nagase</name>
        
    </author>
    
        <category term="アジャイル／XP" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        １２月８日にアジャイルコンファレンスを行ないます。
テーマは大規模なアジャイル開発です。エンタープライズという言葉もあります。
今回は、大手企業がどのようにアジャイル開発を考えるかということも、焦点です。

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

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

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も普及にはずいぶんと時間がかかりましたが、アジャイルもようやくです。

長瀬
        
    </content>
</entry>

<entry>
    <title>[Ruby] 独習Ruby発売。</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2009/06/ruby_ruby.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=403" title="[Ruby] 独習Ruby発売。" />
    <id>tag:pw.tech-arts.co.jp,2009:/technical//5.403</id>
    
    <published>2009-06-18T05:04:05Z</published>
    <updated>2010-07-15T07:02:13Z</updated>
    
    <summary>こんにちわ。ばたっちです。 ずいぶん、ご無沙汰のエントリになりますが、とりあえず...</summary>
    <author>
        <name>kawabata</name>
        
    </author>
    
        <category term="雑記" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        <![CDATA[こんにちわ。ばたっちです。

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


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

<table><tr><td>
<a href="http://www.seshop.com/detail.asp?pid=10586"><img src="http://www.seshop.com/image/product/200905/117850.jpg" alt="独習Ruby" border="0"></a>
</td><td valign="top">
<a href="http://www.seshop.com/detail.asp?pid=10586" style="text-decoration: none; font-weight: bold; color: black;"><br>独習Ruby<br><br>出版：翔泳社</a>
</td></tr></table>

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


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

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

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

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

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


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

「Code Ruby, Be Happy!」

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


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

<entry>
    <title>The PomodoroTechnique</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2009/04/the_pomodorotechnique.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=402" title="The PomodoroTechnique" />
    <id>tag:pw.tech-arts.co.jp,2009:/technical//5.402</id>
    
    <published>2009-04-30T03:54:38Z</published>
    <updated>2010-07-15T07:02:13Z</updated>
    
    <summary>ケント・ベックがメーリングリストで紹介していた アジャイル開発に関するPDFブッ...</summary>
    <author>
        <name>nagase</name>
        
    </author>
    
        <category term="アジャイル／XP" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        ケント・ベックがメーリングリストで紹介していた
アジャイル開発に関するPDFブックです。

http://www.pomodorotechnique.com/

長瀬
        
    </content>
</entry>

<entry>
    <title>マーチンファウラー</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2009/04/post_21.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=400" title="マーチンファウラー" />
    <id>tag:pw.tech-arts.co.jp,2009:/technical//5.400</id>
    
    <published>2009-04-09T05:28:56Z</published>
    <updated>2010-07-15T07:02:13Z</updated>
    
    <summary>昨日、Qcon2009のために、来日したマーチンファウラーと食事をしました。最近...</summary>
    <author>
        <name>nagase</name>
        
    </author>
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        昨日、Qcon2009のために、来日したマーチンファウラーと食事をしました。最近の米国のアジャイル関係の状況やケントベック、ケンシュウェイバー、デーブトーマスなどの人たちについて、話を聞きました。興味深い話もたくさんあり、さすが、ファウラーだなと思いました。
また、今年の１２月に企画している、ThoughtWorksとのイベントの話もして、日本でのアジャイル関係の活動について、理解してもらいました。

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

長瀬
        
    </content>
</entry>

<entry>
    <title>ThoughtWorksイベント</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2009/03/thoughtworks_1.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=399" title="ThoughtWorksイベント" />
    <id>tag:pw.tech-arts.co.jp,2009:/technical//5.399</id>
    
    <published>2009-03-31T08:42:15Z</published>
    <updated>2010-07-15T07:02:13Z</updated>
    
    <summary>先週、ThoughtWorksに行って来ました。 ThoughtWorksはマー...</summary>
    <author>
        <name>nagase</name>
        
    </author>
    
        <category term="アジャイル／XP" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        先週、ThoughtWorksに行って来ました。
ThoughtWorksはマーチンファウラーが所属する会社で、ワールドワイドで
1200人エンジニアを有する世界No.1のアジャイル開発の会社です。

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

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

長瀬
        
    </content>
</entry>

<entry>
    <title>オフショアにおける人材のアンバランス</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2008/11/post_19.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=397" title="オフショアにおける人材のアンバランス" />
    <id>tag:pw.tech-arts.co.jp,2008:/technical//5.397</id>
    
    <published>2008-11-04T03:02:45Z</published>
    <updated>2010-07-15T07:02:13Z</updated>
    
    <summary>　システム開発を日本から海外に発注するオフショア開発は年々増加しています。しかし...</summary>
    <author>
        <name>nagase</name>
        
    </author>
    
        <category term="オフショア開発" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        　システム開発を日本から海外に発注するオフショア開発は年々増加しています。しかし、オフショア開発は多くの問題を抱えています。今回は、人材育成についての問題を説明します。

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

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

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

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

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

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

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

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

長瀬
        
    </content>
</entry>

<entry>
    <title>[Ruby][Rails] Ruby 1.8.7＋Rails 2.0で。</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2008/07/rubyrails_ruby_187rails_20.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=396" title="[Ruby][Rails] Ruby 1.8.7＋Rails 2.0で。" />
    <id>tag:pw.tech-arts.co.jp,2008:/technical//5.396</id>
    
    <published>2008-07-23T01:37:57Z</published>
    <updated>2010-07-15T07:02:13Z</updated>
    
    <summary> こんにちわ。ばたっちです。 ちょっと前にRubyの脆弱性対応したときのメモ。時...</summary>
    <author>
        <name>kawabata</name>
        
    </author>
    
        <category term="雑記" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        <![CDATA[<p>
こんにちわ。ばたっちです。
</p><p>
ちょっと前にRubyの脆弱性対応したときのメモ。時間経っちゃいましたが。
</p><p>
任意のコードが実行される脆弱性について<br/>
<a href="http://www.ruby-lang.org/ja/news/2008/06/20/arbitrary-code-execution-vulnerabilities/">http://www.ruby-lang.org/ja/news/2008/06/20/arbitrary-code-execution-vulnerabilities/</a>
</p><p>
Rails 2.0系、Ruby 1.8.6系で使ってたので、Ruby 1.8.6-p230に更新したのですが、何やらエラーが。
</p><p>
glibcでメモリ解放のエラーっぽいのが出てしまう。
</p><p>
当時は日本語の情報がまったく見当たらず(今はGoogleでいくつか引っかかりますね)、英語サイトではパッチが公開されたりしてたのですが、試す余裕＆勇気がなくどうしようかと。A^^;
</p><p>
で、結局 Ruby 1.8.7に更新したのですが、Rails 2.0系って Ruby 1.8.7は対応していないので、少し手をいれないといけません。
</p><p>
Rubyで String#charsが定義されたのですが、Railsでは ActiveSupportで用意された charsを使わないといけないというのが問題の様。
</p><p>
config/environment.rbをちょこっといじるだけで、とりあえず回避できます。。ふぅ A^^;
</p><p>
<textarea id="cp20080723_1" style="width:100%; height:100px;" class="codepress ruby linenumbers-off,readonly-on">
if RAILS_GEM_VERSION == '2.0.1' && RUBY_VERSION >= '1.8.7'
  class String
    remove_method :chars
  end
end
</textarea>
</p><p>
参考: ruby 1.8.7 と rails 2.0.2<br/>
<a href="http://znz.s1.xrea.com/t/?date=20080606#p01">http://znz.s1.xrea.com/t/?date=20080606#p01</a>
</p>
]]>
        
    </content>
</entry>

<entry>
    <title>[Ruby][Rails] Ruby会議2008行ってきました♪</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2008/06/rubyrails_ruby2008.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=395" title="[Ruby][Rails] Ruby会議2008行ってきました♪" />
    <id>tag:pw.tech-arts.co.jp,2008:/technical//5.395</id>
    
    <published>2008-06-23T11:56:05Z</published>
    <updated>2010-07-15T07:02:13Z</updated>
    
    <summary>こんにちわ。ばたっちです。 Ruby会議2008行ってきました♪ 私はRubyは...</summary>
    <author>
        <name>kawabata</name>
        
    </author>
    
        <category term="雑記" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        <![CDATA[こんにちわ。ばたっちです。

Ruby会議2008行ってきました♪
私はRubyはRailsから入ったミーハー君なので、Rubyのコミュニティに触れるのは今回が初めて。A^^;

技術系のイベントってその技術が普及すると、企業などが入ってきて事例話とか、宣伝ばかりになってしまうけど、Rubyはまだまだギークが主役の楽しいコミュニティだと思いました。


詳しい内容はあちこちでレポートされていると思うので省略(話についていけなかったというのは秘密ｗ)して、印象に残ったこととかをアウトプット。

一番はやっぱり、１日目のまつもとさん(matz)の基調講演が面白かったです。

まつもとさんの記事はあちこちで読んでたけど、生で声を聴くのは始めて。
話が面白く、上手で引き込まれるスピーチでした♪

テーマは「プログラミング梁山泊」。

梁山泊っていうのは、優れた人が集まる場所のことを言うそうで、これに例えて、
<ul>
<li>技術者が集まり</li>
<li>新しい技術が生まれ</li>
<li>世界を変える</li>
</ul>
ような技術を「梁山泊」として、コンピューティングの歴史を振り返ります。

単なる仕事の道具であったり、技術うんぬんより結果に関心があるようなものは「梁山泊」とは言えないということ。

「梁山泊」には技術力より求心力が必要、UNIXは最初から優れていたわけではないけど、技術者が集まる「場」を提供できたからいいものができた。

つまりコミュニティが重要であると。φ(.. )

例として、LISP、UNIX、Smalltalk、Javaをあげ、そして次の梁山泊は「Ruby」だとつなげていきます♪

Rubyは、LISPやSmalltalkなどの過去の梁山泊を継承し、人や楽しさに注目といった感性を大事にするという特徴のあるコミュニティのようです。


次の梁山泊と言える理由のひとつとして、Rubyの実装系がたくさん出てきていることをあげていました。

Ruby1.8、1.9などのオリジナルなCRuby、JavaVM上で動かすJRuby、Smalltalkで動かす？Rubinious。
他、Ruby.NET、IronRuby、MagLev、。。

(ちなみに、まつもとさんを始めとする少数のCRuby開発陣に比べ、バックに巨大なJavaVM開発者の後ろ盾のあるJRubyはずるいよねって(こそっと)言ってましたｗ)

多様性をよしとするのはUNIXと似てると思います。
同じくLLなPerlやPythonには、複数の実装系が出ていない(PythonにはJythonというのがあるようですが)という比較をされていました。

でも、以前はRubyは複雑だから複数の実装系が出てくるのはありえないって言われてたそうですね。


また、講演後の質問にもありましたが、まつもとさんはMagLevという実装系に関心を持っているというのが印象的でした。

MagLevというのはSmalltalkのVM上で動くRuby？とかで、初の商用の実装系になるそうです。

なぜ、まつもとさんはMagLevにそんなに関心を寄せているのか？という質問に対し、SmalltalkやLISPはRubyの原点であり、そちらの方面からRubyへの逆のアプローチだからだということでした。

これはたぶん、Rubyを作ったまつもとさんならではの思いなんじゃないですかね。
かつての師に認められたような感覚といえば大げさかもしれませんが。A^^;


１日目最後のライトニングトークスも面白かったですね。

コードじゃなくて考え方をJavaからRubyなんだという発表では、プロジェクトの規模を自慢するのはバカがやること、コード数、開発人数が大きくなるのは、物事を簡潔にする能力に欠けている証拠だとか、バサッと切るのは気持ちよかったです。

3Dイメージによる、ピタゴラ装置の発表は斬新でしたね。Wiiリモコンでプレゼンってカッコいいす。

個人的にはtoRuby(栃木Ruby？)の方の発表がよかったです。
年を重ねても新しい技術に積極的に挑戦している姿を見て、「ああいう風に年を取りたい」って思った人は結構いるんじゃないでしょうか？(^^;


長くなってきたのでこの辺で。

他にも、

MacRuby (Macが欲しくなってしまう。。A^^;)

RESTとRuby and Rails (URIベースな設計大事だと思う。REST勉強中です)

iKnowや食べログなどのRails運用事例 (参考になります)

JPmobile (開発苦労話に感動。ぜひ使ってみたい)

GC(ゴミ集め)の話 (GC愛すばらしい。プレゼンのGCメソッドGJ)

とか面白かったです。すげー省略。A^^;


最後に運営スタッフのみなさん、お疲れ様＆ありがとうございました。m(_ _)m
]]>
        
    </content>
</entry>

<entry>
    <title>[Rails] RESTクライアントの認証を動的に切り替える。</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2008/04/rails_rest_2.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=391" title="[Rails] RESTクライアントの認証を動的に切り替える。" />
    <id>tag:pw.tech-arts.co.jp,2008:/technical//5.391</id>
    
    <published>2008-04-18T11:00:00Z</published>
    <updated>2010-07-15T07:02:13Z</updated>
    
    <summary> こんにちわ。ばたっちです。 RESTアプリケーションはステートレスなので、認証...</summary>
    <author>
        <name>kawabata</name>
        
    </author>
    
        <category term="雑記" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        <![CDATA[<p>
こんにちわ。ばたっちです。
</p><p>
RESTアプリケーションはステートレスなので、認証が必要な場合は毎回リクエスト毎に認証が必要になります。
</p><p>
認証方法は HTTP Basic認証が推奨？されていて、Rails 2.0では Basic認証機能が強化(追加？)されてるようですね。
</p><p>
クライアント側でのリソースの参照に ActiveResourceを使う場合は、サイトのURLにユーザ名、パスワードを追加しておけばOKです。
</p><p>
<textarea id="cp20080418_1" style="width:100%; height:60px;" class="codepress ruby linenumbers-off,readonly-on">
class Entry < ActiveResource::Base
  self.site = "http://user1:pass1@localhost:3000/"
end
</textarea>
</p><p>
こうしておけば、リクエスト時に Authorizationヘッダを追加してくれるんですね。
</p><p>
ところで、この site属性はクラススコープなので、リソース単位に一意になるんですが、複数のアカウントで切り替えたい場合(普通はないのかな？)にちょっと困ります。
</p><p>
ActiveResourceでは siteのURLを元に、connection属性(これもクラススコープ)を作っているようなので、これをいじればいいのかもしれません。
</p><p>
別の方法として、headers属性(ハッシュ、クラススコープ)というのがあって、ここにヘッダを追加しておくと、リクエスト送信時にヘッダに追加してくれるようです。
</p><p>
ということは、ここに Authorizationヘッダを追加してやれば、動的に認証情報を設定できるのかも。。
</p><p>
というわけで、以前作った MultiModelScope(see. <a href="http://pw.tech-arts.co.jp/technical/2008/04/rails_with_scope_1.html">[Rails] 複数のモデルに with_scope。</a>)を真似て、MultiResourceScopeというのを作ってみました。
</p><p>
複数のリソースにまたがって、動的に認証を切り替えたいという場合に使えます。
</p><p>
<textarea id="cp20080418_2" style="width:100%; height:350px;" class="codepress ruby linenumbers-off,readonly-on">
class MultiResourceScope
  def initialize
    @resources = []
  end

  def resources ; @resources ; end

  def with_authorization(user, password = "", &block)
    begin
      # Basic 認証のみ
      credential = ["#{user}:#{password}"].pack('m').delete("\r\n")
      resources.each do |r|
        r.headers['Authorization'] = "Basic #{credential}"
      end
      yield
    ensure
      resources.each do |r|
        r.headers.delete('Authorization')
      end
    end
  end
end
</textarea>
</p><p>
こんなカンジに使うことを想定。
</p><p>
<textarea id="cp20080418_3" style="width:100%; height:500px;" class="codepress ruby linenumbers-off,readonly-on">
scope = MultiResourceScope.new

scope.resources << Entry
scope.resources << Archive

e = Entry.find(1)
=>
ActiveResource::ClientError: Failed with 401 Unauthorized  # ★認証エラー
  :

a = Archive.find(1)
=>
ActiveResource::ClientError: Failed with 401 Unauthorized  # ★認証エラー
  :

# ブロック内で認証
scope.with_authorization("user1", "pass1") do
  e = Entry.find(1)
  puts "#{e}: #{e.owner}"
  a = Archive.find(1)
  puts "#{a}: #{a.owner}"
end

# 別のアカウントで認証
scope.with_authorization("user2", "pass2") do
  e = Entry.find(1)
  puts "#{e}: #{e.owner}"
  a = Archive.find(1)
  puts "#{a}: #{a.owner}"
end

=>
"Entry: user1"
"Entry: user1"
"Entry: user2"
"Entry: user2"
</textarea>
</p><p>
認証方法を変えられるようにしたり便利かも。A^^;
</p>
]]>
        
    </content>
</entry>

<entry>
    <title>パターンウィーバーの韓国語版</title>
    <link rel="alternate" type="text/html" href="http://pw.tech-arts.co.jp/technical/2008/04/post_20.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://pw.tech-arts.co.jp/cgi-bin/tamt5/mt-atom.cgi/weblog/blog_id=5/entry_id=390" title="パターンウィーバーの韓国語版" />
    <id>tag:pw.tech-arts.co.jp,2008:/technical//5.390</id>
    
    <published>2008-04-18T05:32:26Z</published>
    <updated>2010-07-15T07:02:13Z</updated>
    
    <summary>韓国語版を開発しました。 ５月ぐらいには、配布できるようになると思います。 画面...</summary>
    <author>
        <name>nagase</name>
        
    </author>
    
        <category term="UML／モデリング" />
    
    <content type="html" xml:lang="ja" xml:base="http://pw.tech-arts.co.jp/technical/">
        <![CDATA[韓国語版を開発しました。

５月ぐらいには、配布できるようになると思います。

画面ショットは、こんな感じです。


<img alt="class.jpg" src="http://pw.tech-arts.co.jp/technical/class.jpg" width="1282" height="994" />]]>
        
    </content>
</entry>

</feed> 

