I resigned as director of 2ndfactory, but am joining to Infragistics, and still experience architect. :)

At end of this August, I resigned as director of 2ndfactory, and am joining to Infragistics from this September. 

I’m pretty excited about this new challenge. Actually I had several chance to work with Infragistics people, including my speaking at their DevDays. These activities inspire me to rediscover what I want to do, what I want to be. This is not direct reason to change, but I’m sure much inspired from them.

In Infragistics, I am going to pursue the “Tao of Experience Architect” at a high, global level. First of all, now I’m planning new UX training in Japan as part of this exploration.

Please keep in touch with 2ndfactory people, they are one of the most capable agency (they call themselves “hybrid integrator” ) in Japan. We already have good relationship between 2ndfactory and Infragistics, but I’m trying to deepen this.

Anyway, new day is coming, my new challenge is started. See you again soon, friends!

P.S. I am going to attend MS BUILD windows conference at Anaheim, this september. If you were there, please say hi to me and go out for drink together !

FLEXを継続的に更新する公開系サイトで利用する

FLEX2を利用したサイトを考える場合に、クライアントサイドのフレームワークとして利用する事が検討されるケースが多いのですが、その際に 入れ子になる.swfを複数社で開発する事が望まれるケースがあります。そんな時、ActionScript3で開発する事がネックになって単純なアニメーションでも話が先に進まないことはあるようです。Goto and Playな状態で使うCS3について確立したパターンが欲しい所ですね。じつは良い本とかあるのだろうか?

[books]Hackers and Painters : Big Ideas from the computer age


デザインとデベロップメントの関係に言及しているという意味でも非常に有名な本ですが、著者自身ハッカー(もちろん、悪い意味ではなく)でありながら成功している経営者であり、美術学校で絵画すら学んでいます。実存の成功者から語られる「技術者の気構え」はその書き口以上に重く、成功のために立ち止まることを許しません。「ものづくり」を愛し、極めようとする技術者の特性はいまさら私が書くようなものではありませんが、よく物語に出てくるような「田舎で隠遁生活を営む孤高の鍛冶屋」であっても日々の生活の糧のために鍬を作らなければならないし、ユーザーを獲得する必要があります。別のパターンで画家のようにパトロンを見つけるという手もありますが、いずれにしても「一流であること」が先に求められることは間違いなく、技術者が自らを先に一流であると位置づけて(生活を含めた)戦略を立てることにはリスクがあると思われます。色々書きましたが、読んで噛み締められる一冊だと思いました。特に現場で戦っている技術者にお勧めです。

HPの考える「IT業界:7つの過去と現在」

@ITにHPの考える「IT業界:7つの過去と現在」という記事がありました。後半でHPそのものの宣伝的なものも含まれるのですが、私としては「コンシューマ向けITとエンタープライズ向けITの差がなくなってきたこと」に着目している点や、「ITを使う目的は過去は個人の生産性の向上だったが、いまはコラボレーションとコミュニケーションにフォーカスしている」という部分、「ハードウェアとソフトウェアの区別がなくなってきていること」「従来はデバイスをネットワークにつなぐことが目的だったが、いまはユーザーをどうやって価値あるサービスにつながせるか」などの前半4つに注目しました。

よく「とはいえエンタープライズ系には色々と事情があるので」という話を聞き、自分もインハウスで働いていた時のことを思い出すと納得する部分もあるものの、今後恒久的にそうであるとはまったくいえないし、むしろユーザーが賢くなってごまかしが効かなくなってきていることは明らかです。「どうして会社のシステムではいつも体験しているようなスムーズな流れがないんだろう?」と思っている人は多いと思われます。

FDDでもっとも重要に思えたもの

かつて紹介したこともあるFDDですが、個人的に大変重要と考えている部分があって、開発のマイルストーンにおいて、その達成率を定義しているところです。

意味のある単位に分割されたタスクを”開発”している際に、仮にタスクの達成を5日といった場合に3日目には60%の達成であるかどうか分かりません。逆にそんなに単純に考えると問題になる場合もあるでしょう。

FDDでは次のようなマイルストーンを設定します。


ユーザー機能単位設計

  1. 領域ウォークスルー(1%)
  2. 設計(40%)

  3. 設計インスペクション(4%)

ユーザー機能単位構築

  1. コード(45%)

  2. コードインスペクション(10%)

  3. 環境への統合(1%)

この計算式の中では、例えばコード完了時点で90%のタスク完成度ということになります。ユーザー機能では2週間で完了できるレベルへタスクを細分化するので(大規模システム開発の常識に照らせば)誤差は少ないとしています。2FCではもう少し小さい単位の方が良いでしょう。

設計から開発に至る順序の問題や、アジャイル視点での開発におけるイテレーション単位などの前提コンテクストがありますが、全体を俯瞰すればこの視点は興味深いです。また、インスペクション(レビュー)を大きなマイルストーンとして割り当てていることにも注目したいです。