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

Archive for 6月, 2010

Javaを使ってAMFからJavaのオブジェクトにするときに、Classがみつからないとはまった。

というのも、今まではAMF3Inputも、見つけたいクラスも同じクラスローダー上であったので、

SerializationContext ctx = SerializationContext.getSerializationContext();
Amf3Input input = new Amf3Input(ctx);
input.setInputStream(bais);
Object ret = input.readObject();

とすれば、なんの問題もなかった。

しかし、readObjectをする前にどうしてもオブジェクトのクラスローダーを指定する必要がでてきたのだ。
これは、たとえばユーザが作ったjarを個別に読込（別のClassLoaderで）、
そのjarの中からオブジェクトを作成するときなんかには必要になるのだが。。

でもって、Amf3InputでClassLoaderを指定するには・・・・
以下の方法でできた。（これで正しいのはわからない。。。）

//  現在動いているスレッドのClassLoaderを取得
//  ここで目的のClassLoaderを作れば、それで自分好みのClassLoaderを指定できる。
ClassLoader loader = Thread.currentThread().getContextClassLoader();

SerializationContext ctx = SerializationContext.getSerializationContext();

//  ここでClassLoaderを指定する。
//  ただし、次のおまじないも必要
TypeMarshallingContext.getTypeMarshallingContext().setClassLoader(loader);

//  ここで、Message.classのインスタンスは別の方法を使って作ってね。という指示。
//  こうすることで、どうやら上で指定したClassLoaderを使う。
//  この指定が無いと、ClassLoaderを使ってくれない。
//  ここではまった！？
//  ただ、BeanProxyで本当にいいかわからないが・・今のところ問題はない。
PropertyProxyRegistry.getRegistry().register(Message.class, new BeanProxy());

Amf3Input input = new Amf3Input(ctx);
input.setInputStream(bais);
Object ret = input.readObject();

とこのようになるらしい。
AMF3Inputのソースを調べていったらそうだった。というメモ書き。

なんの事かと言えば、FlexというかAIRというか・・・・
これに対してローカル上でJavaのプログラムと連携したいということだ。

http://code.google.com/p/flerry

というプロジェクトをひょんなことから見つけた。
こういうのが、誰から教えてもらうわけもなく、調べるわけでもないのにわかるのが、自分で情報を作ってわざわざ公開することの利点だろう。
さすがに、仕事としてプログラムから離れていくと、こういう感覚からは遠のいていく・・・

さて、私もAIRをやっていてちょっと、ActionScriptだけでアプリケーションを作るのはやっぱり限界があるな。と感じた。
やっぱり、ローカルのJava(でなくてもいいのだが）と連携したくなるよな。と。

でも、上のソースはNativeProcessで連携するらしい。
それはそれで、安直だが、すごい割り切っている。

私が、AIRだけでは・・・と思うようになったのは、
パブリックサーバと連携するようないわゆる一般消費者向けRIAというものならいいのかもしれない。
やはり、AIRだけではないし・・・・、サーバはより一般向けにメンテされるし・・・

でも、今までExcelとAccessなんかでなんとかごりごりやってきた業務も含めてWEB化したいといったときに、
本当にWEB化でどうにかなるのだろうか？それに、WEBサーバ（アプリも含めて）なんて運用したい、もしくはできると思うのだろうか？
開発者はどうにかなるかと思うかもしれないが、申し訳ないが、現場の作業者には迷惑な話だろう。
何で、自分の手元のデータをサーバにアップし、サーバ上で加工し、ローカルに落としてこなくてはいけないだ。
何で、自分が使うときだけ動いてりゃいいものなのに、自分たちの管理の外の承認と許しをこわなけりゃならんのだ。
まあ、そう言っても、WEBサーバを運用してなんて言われても、「冗談でしょ！やだね。」
という感じが本音だろう。

でも、ASPやら、SaaSなんかの言葉に乗せられてしまって現場は火の車。
もしくは、売り上げ部門から、ASPやらSaaSを使ってコストを圧縮だ。とうるさい。

と、こんなケースにAIRは当てはまるかな。と思い、

メール配信がAIRからできるようにしたり、Zip（というかOffice Open XML形式）を読めるようにしたりしてみたが、
どうもしっくりいかない。

いざ、ソケット通信やら、DBアクセスやら・・・と非同期なのは、あまりにもやはりやっかいだ。
（んー、スレッドがほしい。せめて、３つだけスレッドが持てますって固定でもいいのだが・・・・）

あとは、Javaでたまりにたまった、ノウハウやら、ライブラリをまたAS3上に再構築するのだろうか？

と考えたら、AIRに限らず、Flashしかり、HTML5しかり、上のような業務RIAを考えたらローカルでJavaと連携することが、
開発者の調達の意味も含めてしっくりする気がする。

じゃ、すべてJavaってのはJavaの開発者の視点からすれば、AIRやらFlexやらのプレゼンテーションノウハウはさすがだよ。と思わざる得ない。
逆に、このプレゼンテーションノウハウを再度Java上で構築するのはJavaFXが広まっていないことからもわかるだろう。

あとはHTML5だよね。実際HTML5があればFlashのプレゼンテーションほどはいらないという場合もあるだろうし・・・

そうなると、やっぱり、ロジックはロジック、プレゼンテーションはプレゼンテーションと得意な言語を組み合わせて使えるようにすることが望ましい。

とこのように考える人が増えたかどうかはしらないが、
AIRとJavaを連携したいとおもう人は増えているようだ。

私は、XMLSocketを使って連携することがベストな気がしている。
HTML5には、WebSocketっていう同じ様なものがあるし。
(トリッキーなことをしなくても、全２重ってとこがGood、つまりポーリングなしでPush配信ができるんだよね)

でも、FlashだったらAMF、それが、たぶん、WebSocketになればJSONとかになるのかな。

というようなことを考えながら、構築中。
んー、でもJavaのモジュール管理をまじめにやろうとするなら・・・・OSGIがベター？

OSGIって、実際の開発現場では使えるのかな。わからん。

flex4のsparkコンポーネントの理解がまだまだなので、メモ。

どうやら、sparkにおいてContainerの基本は、
s:Group
と
s:DataGroup
のようだ。

sparkになって画面表示に関していえば、ContainerとLayoutが分けられた。
（もちろん、利便性のために一緒になっているものもあるが・・・）

Groupはようは、可視コンポーネントを何でも入れてよくて、今までのHBoxや、VBoxのような感じ。

しかし、DataGroupは便利な気がする。
以前のmx:DataGridのように、itemRendererとdataProviderのプロパティを持つ。

従って、dataProviderを使ってデータを提供できる。
そして、そのデータを使ってitemRendererで可視コンポーネントを表示できる。
あとは、ContainerとLayoutが分かれたメリットで、どうそれらを配置していくかを決めていける。

したがって、同じようなデータと部品を規則正しく配置していくのには便利。
たとえば、これを使えばカレンダーコンポーネントみたい物もそれほど難しく作れるだろう。

今日、初めてFlash Builder4を使い始めました。
AIR2.0もリリースされたことですし、それもインストールして、SecureSocketを使ってgmailに接続できるかを確認するのに、
サンプルもFlex4のSparkで書き直すことにしたのですが・・・・

まだ、慣れません。

何が慣れにくいかって、s:XXXX と mx:XXXXX が両方あるあたりですね。

混在できるのは、すでにあるものの移行をしつつ、新しい開発と考えるといいのかもしれませんが、
理解ということになると、

昔のXXXはYYYになります。

というようになれば、理解（あきらめの意味も含めて）がしやすく感じます。

TabNavigatorって、何になるんだ？ってわかりませんでした。今のところ。
工夫しだいで、Sparkだけでもできるのかもしれませんが・・・

mx:TabNavigator　は　s:TabNavigator
と、なっていれば、たとえ、実体が同じでも使いやすと思うのは私だけでしょうか？

<mx :TabNavigator width="100%" height="100%" resizeToContent="true">
		<s :NavigatorContent />
</mx>

って、混じるのはちょっと異物を見ていると感じてしまうのは、
まだ、慣れていないからだけなのでしょうか・・・・

まあ、まださわり初めですので、利点が勝っていることが実感できれば、気にならなくなるかもしれません。

しかしながら、生まれて初めてIDEのVisualEditor（デザイン）の方を使ってしまいました。
どちらのコンポーネントを使うことをIDEは望ましいと思っているのかも含めての意味もありますが、使ってしまいました。

今まで、Flex Builder3でも、Eclipseや、VisualCafe(なつかしい・・・）でも、C++Builderでも使ったことも、使おうと思ったこともない機能なのですが・・・・
マウスで、画面イメージを作っていくことなんて・・・

前回、Http proxyサーバの実装に挑戦してみたにて、

proxyサーバの作成が失敗したが、よい例を見つけたのでそれを参考に、週末に実装してみました。

そして、まあまあ形になってきました。
もちろん、単純にプロキシサーバを作っているのではなく、

出先でネットにつなげない、もしくは、ネットにつなげても非常に遅い、もしくはパケット代で課金されるから・・
という場合に、できるだけコンテンツをキャッシュしてしまおうという事です。
それと、ADサーバなんかにも、こちから余分にお金を払ってまで接続したくはないので、
ある特定のドメインにも、パケット代が課金される場合には接続しないようにするとか・・・・

というような感じです。

現在はまだ、
・SSL通信の時に、proxyができない。
　（SSLのコンテンツはキャッシュするつもりはありません。）
・コンテンツがgzipやdeflate圧縮されているときに、圧縮されたままブラウザに表示されてしまう。

なんかの問題があって、ちょっと、実用レベルにはまだまだですが、
自分自身で使ってみて、そこそこ動くようになれば公開します。

昨日の続きです。

さて、今回は「問題・障害・要望」の管理です。

少ない人数(3,4名程度)でASPを管理しなければならない関係上、思いきって諦める部分は諦めて、
締切、品質を妥当なレベルを維持していくということに関してはそれなりに経験し、苦悩してきたことなので、
多くの方の参考になれば幸いです。

そして、お客さんのところに行って、
「個人でやっているレベルかと思いましたが、だいぶ大人数でやっているのですねー」
と成果物を見て言ってくださった大手企業の担当者さんがいましたが・・・

このときは「してやったり」と思ったものです。

紙を使え・色を使え

１対１でサービスを提供しているケースでない場合、問題・障害・要望は、ぐちゃぐちゃで上がってきます。

「あーそれはバグだな」というケースも、お客さんは要望としてあげてくださるケースもあれば、
「使い方を間違えている」というケースも、「障害だー」と声を大きくしてくるケースもあります。

しかし、これらは調査の結果として「そうであった」ということなのですが、
「如何に顧客の意図を間違いなく早くつかむか？」
が、その後のスピードに大きく影響を与えます。
そして、それはお客様の満足度（心象も含めて）向上にも貢献していくのですから、重要です。

記入には紙を使うのが早いし、汎用的だ

お客さんから報告が上がったら、それを既定フォーマットの紙に記入します。
エクセルファイルや、システムだったりすると、ディスプレイが１つしかないのに、
お客さんと一緒に画面を見ながら、記入していくのに面倒です。

また、お客さんのところに行った時に渡される資料は紙しかもらえないかもしれません。

PC上のデータを紙にするのは簡単ですが、その逆は大変です。
まずは、紙でさばけるだけ、さばきましょう。

そして、それらのセットを２つ用意します。
１つは、種別管理（問題・障害・要望）毎と、もうひとつはお客さん毎です。

これで、お客さん対応の人も、問題解決部隊も、自分たちの軸で見ることができます。
あの情報はどこのフォルダだ！なんて、探す手間が省けます。
立場が違えば、視点も違います。営業中心だ、運用中心だと言わず、
双方で管理するにはコピーが簡単です。

そして、紙のいいところは、量があるということです。

このあと、それらをファイリングしていった時にも、
「結構問題があるなー」とか、このお客さんからは、意見がおおいなーなんてのも直観的にわかるので、

急に過去を引っ張り出したいときにも、データ検索に紙では問題（欠点）があるというかもしれませんが、
データ検索にはない様々なインデックが頭にあるという利点も考慮に入れる必要があります。
人間の記憶容量は意外に大きい物です。ただ、インデックス（思い出すきっかけ）がないので、小さいと思ってしまうだけです。

どんなお客さんなのかを、直観的に判断するには見た目感覚が重要

さて、紙で報告が上がってきても、言われていることが、「問題」なのか？「障害」なのか？「要望」なのか？
を判断する必要があります。

すぐにわからないような問題でも、言われている内容をよーく吟味しないとわからないかといえば、そうでもありません。
たいていは、今までの報告内容が重要なヒントをくれます。
しかし、お客さんにとっては１対１でも、こちらにとっては１対（大勢）です。
１つ１つの会社について機械のように覚えきれていることを求めるのは酷というものです。

ここでSI企業ならば、過去のお問合わせをDBから引っ張りだし、そこで画面に出すなんてことを言うでしょう。
でも、そもそも運用がこれで固まっているわけでもありませんし、
せっかく（？）少ない人数なのですから、「つーかー」で済ませられる部分に新たな負荷を設けたくありません。

と、ここで、「色」の登場です。
お客さん毎にバインダーファイル（コクヨとかの）があり、そこに「色」があります。
この色でなんとなく、お客さんの性質を管理します。

当然「赤」は要注意です。それは、重要顧客かもしれませんし、こちらのミスで非常にケアしなければならない顧客かもしれません。
また、「黄色」「青」とか、数色で管理します。
エクセルとかだと、自分たちで管理したい項目をたくさん作り、結局は管理する工数が大きくなってしまいがちですが、
もともと、曖昧で境界線がないものを、無理に境界線をつくるより、曖昧なままで管理する方が、
根拠のない数値の羅列よりは伝わる情報は多く、そして早いです。

状況が変わったと誰かが判断すれば、色紙を張るなり、差し替えるなりしましょう。
部分的にステータスが異なる事項ならば、付箋の色で管理しましょう。
付箋の色がたくさんつき始めたら、誰かがファイルの色を変えるでしょう。

枚数で、過去と現在の雰囲気を把握

紙でやっていれば、当然、古ければ古いほど、または、報告が多ければ多いほど枚数が増えてきます。
また、終了済みとそれ以外でバインダーを分ければ、

これで、「あー、結構この会社にはやっちまってるなー、まだまだ、完結していない報告があるのかー」とか、
「おいおい、最近障害が増えてきてるが、さばくのがおそいなー」とかもわかります。

よくつかわれるバインダーはそれだけ汚れるし、あんまり使われないのはきれいだし、
そして、何よりバインダーの場所からも各担当者がどのように考えているかも見えたります。
（資料のしたーの方にあるとか、いつもすぐ使えるところにあるとか・・・）

正しい数より、傾向や雰囲気がわかればいいのが管理者です。
ただでさえ少ない作業者の手間を割いて、報告を待つなんてことはあってはいけません。

それを意識して数と組織レベルにそってバインダーを作っていけば、
管理者が知りたい情報がおのずと整理されていくでしょうし、作業者は判断が単純明快になるのです。

こうして管理するだけでも数百クライアントは少人数でいけるので、それを達成してからでもIT化は遅くはないでしょう。
そのときには、管理もかなり洗練されているはずです。

それを根拠に管理ツールを作れば、製品化して売れるレベルだと思いますよ。

ITベンチャーと言っても私が知っている数社とそこで聞いた話ですが、
聞いていいなーと思った話は結構実践してきましたので、まあ、内容についてあーだこーだといえるぐらいは知っています。

実は運用面で意外とITではなく、ローテクを使って大量の情報を素早く判断しているのです。

ただし、ここで言っている大量の情報とは、言い換えると、「文字」や「数値」に表せきれないような情報と言ってもいいかもしれません。

ここでは、その一部をちょっと紹介したいと思います。

１：障害を「音」と「光」で知らせる。

具体的には、パトランプと、サイレンで知らせます。
これでの効果は、多くの人に直感的に通知できることと、雰囲気を経験的に提供できる点です。

誰でも仕事中に、サイレンが鳴れば「うるさいなー！」とわかります。
従って、たとえほかの仕事途中であっても周りの人の依頼を断って、障害に対応できます。
また、関連部署の巻き込みも根回しなしにできます。というか、勝手に集まってきます。

そして、最近「静かだなー」、とか、逆に「うるさいなー」が関係ない人にもわかるので、様々な情報が経験となって伝わるのです。
たとえば、「そろそろハードウェアも買い換え時期かな－」とか、「監視に予算をつぎ込んだ方がいいなー」とか、とか。

このような、職人だけが関知できる経験的勘所も、「音」と「光」にしてあげる事でなんとなく伝わる事が多々あります。

で、このようなノウハウ、実は結構使われている気がします。
USBで接続するこのようなツールも売られているので、一定の需要はあるのでしょう。

２：感情で品質を管理する。

現在のシステム管理では非常にスピードも速く、そして、要件もすぐに変わっていきます。
ただし、問題がいざ発生すると、「テストは十分なのか？」などの議論が巻き起こり、重厚な「テスト仕様書・報告書」ができあがることがあります。

でも、そもそも自分たちで感知できなかった問題なので、他にこの「テスト仕様書・報告書」を承認する人が必要になります。
しかし、これを承認できるような技術者なんてほとんどいません。
従って、ここでできたルールは、ほとんど形骸化し、そしてまた、何もない状態に戻っていきます。
そして、あり得ない障害が多々ある状態に戻ってしまうのです。

そこで感情の登場です。
ここで「テストレポート書」を作りますが、詳細な仕様書や結果は一切求めません。
ただし「私は正しく動くことに自信があります。」と言う項目を設け、その欄にサインしてもらうのです。
（決して、保証を求めてはいけません。求めるのは根拠が無かろうが、「自信」だけです。保証を求めたら決して同意しません。）

そもそも、要求もめちゃくちゃ、動きだって詳細は決まっていないのだから、詳細を求める方が間違っています。
でも、エンジニアというのは基本的に正直者ですから、結構うまくいきます。
そして、自信があるといった以上、責任も持ってくれるのです。

これで、おおかた双方が求める物は満たせているはずです。

自信がないと言ってきたら、上位技術者をつけるなり、結果を用意することでOKとすればいいのです。
これで、ほとんどわかりきった事に対する情報については、細かい情報を求めず、込み入って問題になりそうな事だけが、文書化されていきます。

しかも、組織レベルが上がれば、上がるほど、文書化は必要がなくなってくるのです。

と、２つを紹介しました。
たまーに、これ以外も紹介していければと思います。

昨晩、ほんの２，３時間を使って、nettyでhttp proxyサーバを作ってみた。

その前日、パケット中継を作ってみた。といっても、ほとんど、nettyのサンプルにあるまま。。。
でも、これがすごーく簡単なので結構可能性を感じた。
パケット中継とは、たとえば127.0.0.1:8080にアクセスすると、強制的にそのパケットを192.168.1.100:80に飛ばすようなもの。
これができると、クライアントでいろいろとネットワークで制限されていても、
迂回していろいろなことができてしまう・・・・というもの。
（もちろん、迂回した先にも仕掛けは必要ですが・・・）

unixではstoneなんかがあるが、Windowsではまずそんな用途無いと思っていたが、
IEであるサイトにアクセスしなければいけないが、どうしてもプロキシ設定が変更できず、
でも、ある経路を通ってアクセスしなければならないので、
IEの制限をなくすために自分自身のポート10000から、ほかのIPへ接続をしてしまうという感じだ。

WindowsのAdministrator権限があれば、問題無いようなものも、権限がないにもかかわらずこういう用途をこなさなければならないので、
こんなこったことをすることになる。

とにかく、そこで簡単にできることがわかってきたのでそれを参考に、http proxyサーバに挑戦することにしてみた。
昔、Sharpメビウスというノートパソコンを使っているときに、「モバイルプロキシ」というツールがあって、
これがスイッチで、オンラインモード（自宅・オフィス）、オフラインモードのように切り替えて、
オンラインモードでは、自宅、もしくはオフィスでプロキシの設定を変更できたり、オフラインモードでは、
オンラインモードの時にためた強制ファイルキャッシュで、
コンテンツが見えるようにしてあったのだ。

あれは、なかなかつかいやすかったなー。と思うこともあり、いつかHTTPでのコンテンツキャッシュ機能付きプロキシサーバを作ろうかなと思っていた。
そのとき、ちょっと不都合があったのが、以前見たサイトがどこだったか忘れたが、
あの内容をまたみたいな－という時に全文検索などがあればいいのに・・・・とかとか。

やはり、自分で使うツールは自分で作る方がいろいろと都合がいいかなと。いろいろ拡張もできるし・・・・

で、ちょっと２，３時間でとりあえず、HTTPプロキシサーバだけでも作れるか試してみた。

結果を言えば、「失敗」した。
さすがに、２，３時間ではできなかった。

具体的に何ができなかったと言えば、Keep-Aliveの処理ができなかったのだ。
すべてのリクエストで接続をするようであればできた。

後で、探してみたら
LittleProxy
というサイトで、jboss nettyを使ったHTTP Proxyを公開していた。

どうも、まだFuture系の使い方がしっくりこないが、前にすすめそうだ。

Apacheのモジュール内で、要求されたファイルに対するmimeタイプが決まるのはどこか？

基本的に、mimeタイプは type_checkerフィーズできまる。
そのmimeタイプを決めているのが、mod_mimeであり、mod_mimeでは、

AddType や、TypesConfigなどで指定したmime typeを拡張子を基に判断している。

static void register_hooks(apr_pool_t *p)
{
    ap_hook_post_config(mime_post_config,NULL,NULL,APR_HOOK_MIDDLE);
    ap_hook_type_checker(find_ct,NULL,NULL,APR_HOOK_MIDDLE);
    /*
     * this hook seems redundant ... is there any reason a type checker isn't
     * allowed to do this already?  I'd think that fixups in general would be
     * the last opportunity to get the filters right.
     * ap_hook_insert_filter(mime_insert_filters,NULL,NULL,APR_HOOK_MIDDLE);
     */
}

そしてfind_ctの中で、ap_set_content_typeを使って決定されたmime typeを設定している。

modules/http/http_protocol.c
にある、ap_set_content_typeは、以下のようになっている。

AP_DECLARE(void) ap_set_content_type(request_rec *r, const char *ct)
{
    if (!ct) {
        r->content_type = NULL;
    }
    else if (!r->content_type || strcmp(r->content_type, ct)) {
        r->content_type = ct;

        /* Insert filters requested by the AddOutputFiltersByType
         * configuration directive. Content-type filters must be
         * inserted after the content handlers have run because
         * only then, do we reliably know the content-type.
         */
        ap_add_output_filters_by_type(r);
    }
}

従って、type_checkerの後のフェーズである。fixupsフェーズであれば、
r->content_type
から、要求したファイルに対するmime typeが取得できる。

もちろん、ここでファイルに対するcontent_typeなので、プログラムで出力した結果のcontent-typeは何も反映しない。
AddType text/html .php
とやっていれば、phpの拡張子の場合にはこの時点では
text/html
という訳だ。

技術というのは面白いもので、普及すれば、するほど本当に理解することが難しくなってしまう。
そんなことを思ったので書いてみました。

話のネタはこちらを参考にしています。
volatileで最適化を抑制する

さて、ここで、CやJavaでvolatileという修飾子があるのですが、
これでコード最適化を抑制するとのことです。

なんでそんなことが必要になるかですが、それは
紹介したサイトがすごくわかりやすいので、その説明はしません。

さて、そもそも、コード最適化の恩恵を受けるのが、
私のような
「プログラムはきれいに、わかりやすく作ることが大切だ！」
「CPUがどういう順番で命令が来ることが望ましいなんて興味ないよ！」
なんて方が多くなって、いわゆる、ハードの動きを意識しないソフトウェアエンジニアが多くなると
じゃ、そういうんじゃ、それらを気にしなくてもコンパイラがやってあげますよ。
気にしないでください。これで多くのみなさんが使えるようになるでしょう！！
ということになる。

複雑なことを、簡単にしている場合、たいていは例外ができてしまいます。
これは、日々ソフトウェアエンジニアだったら、そういう物を作っているのでその事情は理解はできます。

ただ、その例外ができた背景まで含めた技術の理解をすることが非常に難しくなってしまうということです。

しかも、今までコンパイラのコード最適化があることしか知らない私などは、
さらにそのような恩恵に助かったという実感もないので、その理解を難しくさせます。

今回の例では、コード最適化が動いた後のコードをイメージして、コードを書くということが一部必要になってしまう。
ということです。

コード最適化によっていろいろなことから解放され、複雑で難解なことから解放され簡単になったのに、
すごく簡単なことが、複雑で難解になってしまったということです。

余談ですが・・・
こういうことって、すごくたくさんあるんだけど、多くの人の理解を超えているので、
開発工数とかも読めなくなるんですよね。

開発工数についての記述を以前「開発工数と期間（納期）と人数の関係について」というのを書きましたが、さらにこういうケースも含めると
Ａ案）100ある機能のうち、99の機能が1日ですが、1の機能が10日から200日です。
Ｂ案）100ある機能のうち、99の機能で99日ですが、1の機能は1日です。
って話になり、
余計、関係者を混乱させる原因になる。
Ａ案は、あわよくば、結構速く終わる。でも最悪１の機能が一生できないこともあり得るという意味の10から200日という幅。
Ｂ案は、確実にできるが、確実に時間がかかる。あわよくば早く終わるということはない。

じゃ、Ａ案のいいところと、Ｂ案のいいところを取り入れられれば11日で終わるかもじゃん！。
ってこと言うが、たいていは無理なんだよね。

たまーに見つかりますが・・・・
でも、これを見つけるときには、技術的視点じゃなく、ビジネス的視点が必要になるんだすよね。たいていは・・・