つれずれなるままの開発日記(最近はFlexばかり..)

Archive for 2月, 2010

gitでは、リモートリポジトリを複数登録できるのだが、このとき、あるリポジトリのあるコミット分だけ反映させたいという事がしたい時がある。
たとえば、オリジナルから派生して開発をしているが、オリジナルのバグ分だけ反映するといった使い方だ。

ここで、リモートリポジトリの登録から、そのリモートの変更分を取り込むまでの手順を記録しておきます。
もしかしたら、これよりいい方法があるかもしれませし、必要のない手順が含まれているかもしれませんが、
とりあえず、解決できる手順を覚書として記録しておきます。

1) リモートリポジトリを追加する

git remote add [name] [uri]

のようにします。
たとえば

git remote add myremote git://git.sourceforge.jp/xxxxxxx.xxxx.git

のようにします。

2)　追加したリモートリポジトリの情報をフェッチする

git fetch myremote

3) リモートから取り込みたいコミットを指定し、自分のワークにコミットする

 git cherry-pick [commit-id]

commit-idとは、git logを指定すると表示されるやつで、具体的には

git cherry-pick 947559c50d59e15b4e5817d8091f3e2862fe293d

のように使う。
ちなみに、この処理は同時にコミットするが、コミットせずに、git add した状態でとめておきたいならば

git cherry-pick --no-commit [commit-id]

のようにすれば、OKだ。

さて、年末によんだ、「ザ・ゴール」と「ザ・ゴール２」がなかなかおもしろかったので、
今回は、その第３弾の話だ。
たしかに、この「制約理論」は面白い。

「チェンジ・ザ・ルール」、「ルールを変えろ」とは・・・あまりにも、正論すぎやしないだろうか？
今まで、この手の本といえば「信じれば変われる！」とか「あなたが変われば、周りが変わる」とか、とにかく、宗教じみた論調で読者を説得しようとしていたと思うが、この「制約理論」は、こういう問題を真っ向から、「理論」「理屈」として取り組もうとしているところが面白い。

今回は、舞台がERPのソフトウェア会社ということで、ソフトウェアを携わる人間としては、非常に親近感がもてて読めた。
そのためなのか、３冊目という事だからか、「ザ・ゴール」・「ザ・ゴール２」を読んでいて感じた違和感がなく、「おっ、始まったな」という感じで読めた。

ストーリーの概要は、amazonの「商品の説明」を読めばわかる事なので、ここでは記述しないが私が持っていたいくつかの疑問や、感じていた事が少しわかってきた気がした。

ちょっと話はそれるが、自分がいつも気にしているのはこういうことだ。と周りに話してきたことがある。

ある娘と、お母さんがクリスマスにだす七面鳥を調理していた。そこで、お母さんは七面鳥を半分に切って、２回に分けてオーブンに入れて調理をしていた。そこで、娘は疑問に思ってお母さんに聞いてみた。「なぜ、七面鳥を半分づつにして焼くの？」
お母さんは「昔からそうやっていたのよ。なぜかしらね。きっとそっちのほうがおいしくなるんじゃないかな？おばあちゃんに聞いてみたら？」
そこで、おばあちゃんに娘は聞いてみるとこう答えた。
「昔はオーブンが小さくてね。半分にしないと入らなかったのよ。」
と。。。。

この話をどこでいつ読んだのか忘れたが、確か学生の頃かもしれない。
でも、働き出して、特に「製品」という枠組みの中でソフトウェアを作りだすと、このようなことを疑問に思うことが非常に大切だと思ってきた。

だが、なぜそれが大切なのか？きちんと説明してくれ。と言われたら言えない。

また、もうひとつ、「製品」を作れる会社と作れない会社がある。
技術的にそれほど違いがない。ただ、作れる会社では「カスタマイズ」をやたらめったらしない。
それが、どうしてできるのか？もしくはそれがどうしてできないのか？

（まあ、私も、営業・周りのエンジニアと戦った。なぜ、できることをやってくれないんだ！協力してくれない！と何度クレームを言われたことか。）

私の中では「やらない」という制約がある中で、考えたほうがよりいい考えができるという程度しか認識がなかった。（人は制限という中から新しい発見をしてきたのだから・・・）

でも、この本を読んでもうちょっと、「理論的に納得がいく」形で理解ができた。

まず１つめは、この本の中ではこんなセリフがあった。（ちょっとかいつまんで・・・）

「新しいテクノロジーを導入するという事は、そこまでそこに限界があったという事を意味する。その限界と長い間、共存してきて、それに合わせて習慣・評価尺度・ルールなどを作ってきた。
そして、新しいテクノロジーを導入して、限界が軽減された。そうすると、それまでの習慣・ルールが今度は限界を課すことになる。」

なーるほど。これは確かに。
つまり、先ほどの七面鳥でいえば、「大きさ」という限界があったが、大きなオーブンにして限界を取り除いていたのに、それを習慣として受け入れたお母さんの考え方自体が制限を生み、結局、オーブンを大きくしても、小さくしても変わりない。
それどころか、「システムの良い提案は、システムにしないこと」などと比喩されるように、この制限をそのまま考えていたら、大きなオーブンのために余計に電気（お金）がかかってしまう。

つまり、システムで制約が限界であったとき、それを取り除いたら、取り除いたようにルールを変更しなければ、限界を取り除く前より、価値（パフォーマンス）が下がるときがある。という事だ。

２つめ。ここの本の会社は、TOCを利用し大成功をおさめた。そして、他の会社が内情を知っても他社は真似できないだろうとこういうのだ。それは・・・

「たとえ我々のプログラムの中身を彼らにコピーさせたとしてもすぐにあれも、これもと機能を追加し始めるに違いない。現場での使い勝手など一切無視だ。」

エンジニアとして技術がついてくるとつい、顧客の言ったことに反応しあれこれと答えてあげてしまう。つまり、カスタマイズしてしまうのだ。
これは、実際に売っているほうとしても顧客が言ったことが、すぐに回答できて気持がいいことだろう。

しかし、先ほど言ったように、「限界をなくす」＝「ルールを変える」が必要になってしまう。
じゃないと、技術で成功しても、顧客に成功はない。

これができるのは、私が考えられるのは２つ。
そして、この本でもほぼ同じことを言っていると思う。

１）そのルールや習慣が変えられるほどの衝撃的なテクノロジーの進歩を伴ったツール。
最近ではインターネットなどはその典型的な例だろう。
したがって、その進歩に乗っかっていけば、ある程度は「ルール」などといった面倒なこととは表面上は付き合わなくて済む。それに、派手でカッコ良くもあるので、見栄えもいい。

２）自らルールを変えるための手法と論理を持ち合わせ、そのために自己改革ができる組織。
つまり、このTOCを実行できるとなるわけだ。（まあ、そのために書いた本なのだから当たり前なのだが・・・）

ただ、テクノロジーが、あまりにも人の理解を超えて進みつつある。
そして、限界になっていない限界を破ろうとやっきになっている感もある。

今のIT企業は（１）を目指して頑張っているのかもしれないが、この不況になってみて成功している会社は（２）の会社ばっかりという気がしてくる。

じゃ、どうして、「簡単ですぐできること」がみんなできないのか？

「単純」＝「簡単」＝「楽」
「複雑」＝「難解」＝「たいへん」

という呪縛や思い込みから人は逃れられないからじゃないだろうか？

人間にとって一番いやなことは、「苦痛」や「苦労」ではなく、「自己否定」を伴う行動が一番いやらしい。

「複雑」で「難解」そうな問題がシンプルかつ楽に解決できたら、それは今までの自分が「無能」であることや、やってきたことが「無駄」であることを認めなければいけなくなる。
こんな、自己否定は誰だっていやだ。

今回は、airxmailライブラリで、gmailを使ってメールを送信する場合の例です。

gmailを使う場合には以下の２つの点に注意する必要があります。

1. SMTPサーバで認証を使用する (SMTP-AUTH)
2. STARTTLSの使用

です。

この２つの条件を満たすのも簡単にできます。
ただし、２の条件を満たすために、as3cryptoのライブラリが必要になりますので、別途ダウンロードしてください。

（2010/02/10時点でのサーバ名とポートです。）

sender = new SMTPSender();
sender.setParameter(SMTPSender.HOST,"smtp.gmail.com");
sender.setParameter(SMTPSender.PORT,465);

//  SMTP-AUTHの使用
sender.setParameter(SMTPSender.AUTH,true);
sender.setParameter(SMTPSender.USERNAME,username);
sender.setParameter(SMTPSender.PASSWORD,password);

// STARTTLSの使用
sender.setParameter(SMTPSender.SOCKET_OBJECT,new com.hurlant.crypto.tls.TLSSocket());

で、接続ができます。
あとは、今までどおりメールの本文を設定していけばＯＫです。

プロジェクトの工数算出というものに対して非常に疑問に思うことがある。

工数とは、各機能を算出してそれらを足していき、そこにある程度のスパイス（保険）を足して算出する感じだろう。
ここに、スパイスというよくわからないものがあるが、このスパイスが経験でズバッと３倍とか、１．５倍とか…
ここまでいい加減でないにしても、それぞれの機能に複雑度・影響度を加味した係数をかけて、足していき・・・・・

って、これで実際に工数を出してみても、本当にその考え方あってるの？と疑問に思う。

そもそも、
そのプロジェクトはいつまでに完了（納品）しなければいけないのか、とか？
何人投入するのか（できるのか？）
が、関係するんじゃないんかなー。

それらは、工数を出してからというかもしれないが。
だったら、導き出せる工数というのは場合の数だけ複数あるのではないだろうか？

そんな状況を示すのは、こういう会話ではないだろうか？

Ａ：「この機能開発の工数ってどのくらい？」
Ｂ：「んー、まあ、ほとんど外部要因を考慮しなければ、作るための工数は１２人月くらいかな？」
Ａ：「じゃ、１人月 100万だから、安全をみて1500万くらいでいいかな？」
Ｂ：「んー、でも、開発にかけられる期間にもよるかな？」
Ａ：「発注がきてから、３か月くらいまでに完成していればいいと思うよ。」
Ｂ：「わー、結構忙しいな、じゃ、人数も増やすから、保険で２倍にして２４人月くらいで・・・」

と、ここで、各会社により、人月単価とか、保険の倍率とかはその時それぞれだが、
工数を答えている方も、経験からなんとなく、期間や、投入できる人数を踏まえて「勘」で、答える。

これを聞いたほうは、２倍もとっているんだから安全な数値だなと思うでしょう。
言っているほうは、十分な保険をとっているという感覚はあるが、実際はそのくらいになってしまうという実感。
または、実際にはこれより遅れてしまうなんてことも普通にあるのではないでしょうか？

これでは、予定の２倍も認めているのに終わらないなんて、怠けているにも程がある！！
ということになってしまう。

または、初めから２４カ月と伝えるようになる。
根拠はということになると、期間が人数が関係しており、
それらが決まっていない以上、つつじつまが合わず、どう考えても、半分程度で終わるのになーという感覚を持たれてしまう。
そして、本当のことを言わないやつらだ・・・と。

実際、「勘」は、理論より正確ということもあり得るが、できるだけ、「勘」の要素は減らした方が、他人には納得がいくはずだ。
そもそも、プロジェクトを周りに認知してもらうには、実施部隊に意味があろうとなかろうと、根拠が必要になるのだ。
そして、誰もが予定通りいくことを願っているのだ。

では、これらの「勘」は、どんな経験から来ているかと考えると・・・

経験１：「多くの人数で行うよりも、少ない人数で行う方が効率よく終わる（ある時は早く終わったりする）」
経験２：「期間を短くするためには、いろいろと同時進行しなければいけないから、その分人数が多く必要」
経験３：「ある程度独立した機能があったら、同時進行してもリスクは低くなる。」

要するに、ある程度の必要な人数というものもあるが、必要以上に増やしても、余計工数がかかる。
また、機能はサブシステム（ある程度独立）ごとに分けられれば、工数は減らすことができる。

ここでジレンマが発生する。
１と２では、人を増やせば、ある仕事量を早く終わらせることができるが、人を増やせば仕事量が増える。

要するに、人が多くなれば多くなるほど、それぞれの関係が複雑化し、よりやらなければいけないことが増えるのだ。
（もしかしたら、メンバーへの教育かもしれない）
つまり、工数は増えるのだ。では、何人がいいの？

一人より二人のほうが早く終わるのは理解できるし、
二人よりも三人・・・・
・・・・・・・・
でも１００人にすると、何だか収集がつかず、余計混乱していく気がする。

では、どのように考えればいいのだろうか？

工数計算の方法を改めて調べてみたものの、どうも、どれだけ人数をかけられて、どれだけの期間の制限があるという前提で・・・
という条件を踏まえると見つからない。
（もしかしたら、勉強不足なだけかもしれないが、私には見つからなかった。）

そこで、自分なりに考えてみることにした。
したがって、何の根拠もありませんが、できるだけ実感にしっくりくるようにしてみました。
（あくまで、私の独断と偏見にみちた計算です。）

そこで、まず考えたのは、
私はここで、人が一人増えると、増える前の工数より10%程工数が増えると仮定してみました。
というのも、人数が増えれば、増えるほどそれぞれの人がネットワークとして関係をもつという事です。
それに、増えれば増えるほど、できない人に合わせていく必要があり、それでできる人の仕事量もより増えてしまうという考え方です。
あまりに、現実に忠実すぎると複雑になるので、複利的に工数が増えてくるという事で表現することにしました。

つまり、ここでは、それらの人同士が増えた分だけ、深く依存しあうという前提です。
ちょっとあいまいですが・・・
（あまり、依存しあわないというケースは後で説明します。）

これで、考えてみると、12人月の工数は一人で行うと12人月だが、２人で行えば、
12 + 12 × 0.1 = 13.2 （人月）

同様に、３人では・・・
13.2 + 13.2 × 0.1 = 14.52

実際にかかる期間はといえば、
13.2 / 2 = 6.6 （か月）
14.52 / 3 = 4.84（か月）

これを数式にしてみる。

純粋工数　　：上の例で12人月のこと。つまり、組織や、人が絡むことにより増える工数を除いた工数を示す。
人的複雑計数：上の例で10%工数が増えるということ。10%ということは1.1になる。
期間　　　　：上の例で、実際かかると予測される期間です。

この式に人数を増やしていくと、だんだんと期間も減ってくる。
しかし、10人、11人(2.829537 カ月）を境にむしろ必要な期間が延びてくる。

これで、経験１と経験２がうまく適用できたきがします。
できるだけ早くという前提では、10人以上かけても無駄だということです。

ちなみに、このときの工数はといえば、約29人月ということだ。
また、３か月以内という条件では、８人投入ということになり、「保険で２倍」という24人月とほぼ一致します。
（というか、これ以降します例のためにあえて近い数字なのですが・・・）

５か月以内でという条件では、３人投入で、工数は 15.2か月です。

これで、同じ機能なのに、期間が変わる＝作業人数が変わる　で、工数が変わってしまうということがある程度根拠になるのではないでしょうか？

ただ、これでは、「２か月以内に納品してほしい」という要望が来たときに、理論的にできません。ということなってしまいます。
実際にはそういうことはないでしょう。

もしくは、もうちょっと工数を減らしてよ。

と、そこで、経験３：「ある程度独立した機能があったら、同時進行してもリスクは低くなる」の登場です。

これで、独立した機能ごとに、グループを割り当て、計算上は、１つのグループの工数を減らすことができるというわけです。
したがって、純粋工数が１２人月を２つのグループに分けて、６人月にしようというわけです。
しかし、実際には、グループを分割しても、それぞれをつなげなければなりません。
ガントチャートのエディタ上で、線を２つに分けてスライドさせればOKというわけにはいかないのです。

実際には、サブシステム間の接続ルールを決めなければいけなくなります。
もっと、プログラムチックに言えばAPIを定義するということでしょうか？

しかも、サブシステム間の関係は、人と人の関係よりは、もっと工数リスクが高くなるのが普通という気がします。

でも、工数リスクが上がっても、トータルで工数は減らせるということは、経験的にわかっています。
これは、一体どういうことでしょうか？

仮にまったく工数が同じだけかかる２つのサブシステムに分割できたとしましょう。
そして、それらの２つのサブシステムはまったく同時に依存関係なく、進めることとします。
ただし、最後につなぐ必要があるので、ここでは、その係数が1.2とし、最後にその分だけ掛け算をします。
（つまり、人と人は10%の仕事増加だかが、グループ間は20%の仕事増加ということです。）

ここでは、工数の増減を知りたいので、上の例で、「３か月以内」＝「８人の投入」という計算になったので、同様に８人投入できることとします。
つまり、１つのグループには４人です。

純粋工数は１グループにつき６か月です。
これを前の式に当てはめると、実際の工数は・・

6×1.1^(4-1) = 7.986

これが、２つのグループで２倍して、係数1.2をかけると

7.986×2×1.2 = 19.1664

になります。
したがって、工数が約24人月から約19人月まで５カ月ほど工数を減らせたという訳です。
さらに、工数を減らせたということは完成までの期間も減らせたわけです。
19.1664 / 8 = 2.39 （か月）

になりました。

これを数式で表せば、

のようになり、ここで分割数を割って、かけているのでそれらを相殺すれば、

のようになります。
ただし、この式の条件は、前にも書いたように、まったく同じ工数で分割できることであり、また、それぞれの分割後に割り当てる人数も平等という前提です。

実際には、工数が違うグループになり、適用する技術ごとに割り当てる人が違うなど、もっと複雑になるとは思いますが、
ここでは、関係性が表すという目的から、すごく（計算上）理想的にサブシステムが分割できる前提で、数式モデルもわかりやすく作れると思うので、そういう前提にしました。

これで、先の２カ月以内で終わらせるための工数は？

上の式に当てはめて探してみると、工数は約23人月なのです。
しかし、条件がある。そう、同時に投入できる人数です。

その人数は12人必要となる。
これは、機能を２つに分解し、６人のチームとするか、
機能を３つに分解し、４人のチームとするかだ。

たとえば、割り当てられるのは上限６人として計算すれば、残念ながら２カ月では完成しない。
という計算になる。

このように、もとある工数見積もりの200%とかいう話ではなく、
実際にこれらの因果関係を見積もって、間接工数をそれぞれ一定の割合として人数とともに考慮していけば、
12人月が24人月にも膨らむことが示せたのではないでしょうか？

さらに、実際のプロジェクトでは、この計算に入れられない一定の阻害要因が必ずと言っていいほど発生します。
よくあるのが、顧客が要件を決めてくれないなど。
でも、200%の安全をとっているという安心から、それでOKとしてしまい許してしまう事は多々あります。

しかし、計算では、実は最初の12人月の200%は安全ではなく、必要な間接工数だったのです。
したがって、余分な保険はほとんどなく、非常に他の要因に対して甘い見積もりだったというわけです。

ただ、まったく、予想できない問題に対してコストを反映するのは現在のコスト競争の中ではできないことかもしれませんし、
それらが発生した時点で顧客と相談でその分の期間延長は呑んでもらえることも多々です。
だけど、実際にはそれ以上に遅れる。それも信じられないほど。

そこには、もうひとつ大きなポイントが上の式にはあります。

12*2 = 24 と 12 * 1.1^(8-1) = 23.xxxx（ほぼ24)

を見直すと、 「2」と「1.1」はやはり、経験（統計）と勘によるものであることには変わりありません。
この値は非常に、ぶれやすいと言えるでしょう。

たとえば、それぞれ「10%」ほど読みを間違えたとしましょう。
（もしくは10%程度であれば、その違いを工数として幅を持たせることを許しましょう。）

実際には1.1という係数自体も人が増えれば増えるほど、大きくなるぶれる可能性が高くなると思うので、
人数が変われば読み間違いやすいでしょう。
また、期間が延長されれば、もともといた人は外れて、新たに人が入ってくるということもよくあるのです。
これで、人的複雑係数の値は変わってきてしまいます。
では、計算してみましょう。

12*2.2 = 26.4
12*1.21^(8-1)=45.57

とかなり、違いが出てきます。
まあ、顧客も責任あるし、４人月くらいはいいか？と思っていたのに・・・
（これでも、２４００万の案件で、４００万円の上乗せを顧客になっとくしてもらうには至難の業です。）
でも、下の計算ではほぼ２倍弱に膨れ上がっているのです。

つまり、もし、締め切りも３か月から１年ぐらいまでなら許せる。人数は不定。ただし、上限は８人くらいかな。

という前提で、１２人月ほどかかりそうな機能を実装するための工数は
「１２人月～４６人月」
こんなことを聞いた、営業やお客さんは「はー、意味わかんね。適当なこと言って・・・」
と思うかもしれないが、ITのプロジェクトは、普通に予定の２倍、３倍かかってしまう事がしょっちゅうあるということが、見事に反映されている気がします。
もしくは、無理やり期間で帳尻を合わせようと、仕様をけずれば、１２人月の仕様から６人月の仕様になってしまうなどです。

そして、小さな読みの間違いでも、結果は大きくぶれるという事です。

「情マネ流マーフィーの法則その2」
情報システムの開発では、計画時の2倍の費用と2倍の時間がかかり、1/2の機能しか実現しない

も、同じような事を言っているので、それなりに反映できている気もします。

どうでしょうか？この理論。

ただ、この理論はあまりにもモデルを単純化しているので、実際には、ここからこれらの関係をもつ要素の依存関係を考慮していき、
ガントチャートなどを作成しながら、さらに関係を見積もっていくのでしょうが・・・・

前回は、HTMLメールを作成したが、今回は、添付ファイル付メールです。

メールの送信の全体の流れは変わりませんので、今回は添付ファイルのメッセージを作成する部分だけ説明します。

ただし、今回もライブラリを新しくなったので、こちらからもっとも新しいバージョンをダウンロードしてください。
前回、setTextBodyにちょっとバグを埋め込んでしまいましたしたので、こちらも修正しました。(詳細)

さて、添付メールの説明です。
といっても非常に簡単です。

var contentType:ContentType = ContentType.MULTIPART_MIXED;
var mimeMsg:MimeMessage = new MimeMessage(contentType);
：
省略
：
var filePart:MimeBinaryPart = new MimeBinaryPart();
filePart.setAttachementFile(File.desktopDirectory.resolvePath("image.jpg"),"添付ファイル.jpg");
mimeMsg.addChildPart(filePart);

sender.send(mimeMsg);
sender.close();

で終了です。
ここで、MimeBinaryPartは、自動的にContent-Typeが、application/octet-streamになります。
また、

filePart.setAttachementFile(file:File,filename:String):void

で、添付ファイルをつけます。
上の例のように、添付するファイルが画像の場合には以下のようにContent-Typeを変更してもいいかもしれません。

var filePart:MimeBinaryPart = new MimeBinaryPart()
filePart.contentType.setMainType("image");
filePart.contentType.setSubType("jpeg");

または、

filePart:MimeImagePart = new MimeImagePart();

とすることで、image/xxxx のようになります。
xxxxの部分は、添付するファイルの拡張子で変わります。