update it, Inc.社長のブログ

ここ最近、工事進行基準に関する情報もだんだん増えてきたようですが、相変わらず当事者のＰＭの方からは不安視する声が聞こえます。そこで、システム開発会社の経営者やプロジェクト・マネージャ、プロジェクト・リーダの方を対象とした勉強会を企画しようと考えています。

この勉強会の趣旨は、プロジェクト・マネージャにとっての工事進行基準とは何か、という理解の部分から初めて、徐々にケース・スタディや参加各社間での対応状況に関する情報交換などの場にしていきたいと考えております。

セミナーではなく、勉強会という形式ですので、できるだけ無料で開催し、参加者が互いに情報交換できる場にしたいと考えています。後日、詳細をホームページなどで告知したいと思います。

通常、会社は期初に予算編成を行い、それに従って事業を進めるという形式のところも多いと思います。このような会社の場合、期初に予算編成をする時点で、全体の枠が決まってしまい、システム開発についてもその枠に縛りがかかることになります。

システム開発においてこの方法が問題になるのは、その期初に予算編成する際にはまだ要件が確定していない、ということです。要件が確定する前に金額がざっくりと決まってしまうので、本来はその金額の枠内に収まるように要件を固めていかなければなりません。

しかしシステムの受注開発の場合、要件を金額の枠内に収めるためにはどうすべきかについて、明確な手法はありません。システム開発を請け負う側が頑張ってできる範囲がすべて要件の範囲となってしまい、結果としてその「頑張り」はすべて末端のプロジェクト・メンバの負担へと転嫁されてしまいます。

システムを発注する側としては、金額の枠が決められてしまっているのは事実で、いきおい「金はこれしかないけど、なんとかなりませんか？」という話になり、それが上記のような流れでシステム開発の現場は常に忙しい、となってしまっているように思います。

この循環を断ち切るにはどうしたらよいのでしょうか？

Googleのストリートビューの日本版を早速試してみました。なんと我が家が映っていました！　航空写真のときにもすごいと思ったのですが、これはそれに輪をかけてすごい。しかしいつ撮りに来ていたのだろうと思います。例のGoogleカーで撮りに来ていたのでしょうか。

私のうちは横浜なのですが、うちの近所のカバー率は結構高いように思えます。おそらく地図で青い道路はストリートビューがあると思うのですが、主要道路だけでなく、結構細めの道でもちゃんとデータがあるようです。

会社は、というと、会社の表側は遊歩道になっていて車が入れないため、残念ながらupdate it, Inc.の看板は見えなかったのですが、会社の裏の道路から会社の建物は移っていました。

ちなみに私はFireFox 3で見ているのですが、なぜか地図の下側にちゃんと描画されない領域ができてしまいます。バグかな？

Google Mapsは最初出たときの衝撃がすごく、特に外国まで地図や航空写真で見れたのが楽しくて、最初のころは暇があれば昔、香港に転勤していたときに住んでいたマンションを見つけたり、子供の時に住んでいたあたりを探索したりなど、いろいろ楽しんでいました。ただ最近は他の地図も追い付いてきた上にGoogleの反応が遅くて使いづらくなってきたため、ちょっとご無沙汰気味でした。でも久しぶりに使ってみたら、反応がかなりまともに戻った気がします。

またしばらくは使ってみて、ストリートビューにはまりたいです。（そんな暇はないですが）

@ITの記事で「注目のRIA環境JSライブラリ「Ext JS」が国内販売開始」というのが紹介されています。これはJavaScriptベースのユーザインターフェース用の部品ライブラリーです。ちょっとサンプルを見てみた（こちらのページ）のですが、これはすごい。ぜひデモを試してみてください。

Zimbra並のRIAが簡単に作れそう。JavaベースのUI構築ツールであるSwingやSWT以上のことが軽くできる気がします。

しっかし、JavaScriptでこんなものが作れるのに、なんでSwingには同様なものがないのだろうか？　（ま、SWTはネイティブだから仕方ないけど）　条件として、そんなに差があるわけではないと思うし、むしろJavaScriptでやる方が制約が大きくて難しい部分も多いと思うのですが、この差はいったいなんなのでしょうか？

Swingも次のJavaFXに期待ってことなのでしょうか？　SWTはいったいどうするんだ…　UIは進化が早いので、SWTにようにWindowsネイティブの世界に縛られているとどんどん遅れていくような気がしてきました。

今夜、予定どおりにいけば crossnoteをver 1.2.2にバージョンアップします。今回のバージョンは主に細かい使い勝手の改善で、大きな機能追加はありません。

主な内容は、
1.Proxy認証関連の修正

2.Word 97/2000ファイルの変換取り込み（暫定版）

3.質問＆課題管理表のフィルタ機能の改善

4.表の使い勝手の改善

といったところです。

ソフトウェア開発に関するデスマーチについて調べているうちに、デスマーチには敵がいることがわかりました。そうですよね。何か敵がいるから、デスマーチになるわけです。

でもどういうわけか、あまりその敵について言及しているものは少ない気がします。遠慮？　体裁？　人間関係？　仕事？　いろいろな要因が絡んでいるのでしょうが、デスマーチが如何にひどい状態かが書かれていても、その敵について詳しく書いているものはあまり多くありません。

でも何が敵なのかがはっきりしないことには、対策が打てるわけがありません。（でも上記のようなケースは、敵ははっきりしているのだけれども、対策が打てない状況を表している気もする）

ここで言う敵とは、デスマーチに至った根源的な原因です。もちろんその原因だけではなく、いろいろな要因が絡み合ってその状態になってしまうのだと思いますが、でも誰もが声には出さないまま、心の中では、「これは×××のせいだー！」っていうのがあるのではないでしょうか？

敵をあぶりだすことは、デスマーチを減らすための第一歩でしょう。

でもそれを声高に言えないという点に、デスマーチが起こるそもそもの理由があるのかも。目的をきちんと共有するなど、風通しを良くするための努力をしていれば、起こりにくくなるかもしれません。

最近、「キャズム」（ジェフリー・ムーア著、川又政治訳　翔泳社）という本を読んでいるのですが（これも同じ営業を教わっている方に勧めらた本です）、当社のようなテクノロジー・ベンダが立ち上がるには、その初期段階においてイノベータ（テクノロジー・マニア）に続いて、アーリーアダプタと呼ばれるビジョナリーが必要だ、と書いてあります。

キャズムという話は、むしろそのあとのアーリーアダプタからアーリーマジョリティに移行する際に、深い谷（キャズム）があり、難しいよ、というのがメインなのですが、今の私の関心事は、初期段階からどう離陸するのか、という点なので、ビジョナリーという言葉が強く印象に残りました。

ビジョナリーとは、自分の夢を描き、それに向けてリスクを取って行動することを厭わない人だと言えます。つまりコンサバなタイプではビジョナリーとはなり得ません。

私たちは、私たちの思い描く夢と、そのビジョナリーの夢を一緒に共有していきたい。そしてビジョナリーのためであれば、最大限の努力によって、その夢の実現し、喜びを分かち合えるようにしたいと思います。

これは、先日ブログで書いた「顧客との対話をベースに、ベストプラクティスをいち早く取り込み、誰よりも早く成長するシステムサービスを提供できること」という話とぴったり一致する戦略だと考えています。

我こそはビジョナリーだ、と思う方。ぜひコンタクトしてください。

ここのところ、アップデイティットの会社としての強みって何だろう、とずっと考えてきました。将来会社を発展させるにあたって、他の会社と何が違うのか、を明確にしなければならないからです。

ここで言う会社としての強みとは、商品の強み以外の、会社としての強みのことです。会社の成長戦略を描くうえでは、会社としてどこが他と違うのかを明確にできなければ、将来に渡る成長曲線を描くことができません。

そして最終的に達した結論が、次のことです。

「顧客との対話をベースに、ベストプラクティスをいち早く取り込み、誰よりも早く成長するシステムサービスを提供できること」

これは今まで私が過去のＳＥ時代を通して実践してきたことです。

私はもともとは金融系のＳＥとして、キャリアの大半はデリバティブやスワップ、債券トレーディングなどを扱う、フロント・ミドル分野にかかわってきました。こられの分野では売れる商品がどんどん変わり、如何にそれに先んじて対応できるかが勝負の決め手です。ですのでいつも私は顧客のそばにいて、顧客との対話をベースに彼らの望むものをいち早く提供することができるか、という点に注力してきました。

その結果、顧客の方にびっくりされるのがたまらなく好きだったんです。そして実際そうすることが、顧客の利益に結びついていたと考えています。

そしてそれを実現するためには、どのようなシステムでなければならないかを常に考え、オブジェクト指向プログラミングを実システムにいち早く導入したり、ＲＡＤ手法やイテレーション開発などを活用したりなど、その時代の最先端の仕組みをいち早く利用して、勝負を乗り切ってきました。

こういったことを通して得たノウハウが、先に書いた「顧客との対話をベースに、ベストプラクティスをいち早く取り込み、誰よりも早く成長するシステムサービスを提供できること」だと考えました。

次のステップは組織としてこれをＤＮＡとして確立し、浸透させることです。
がんばります。

先日、成功報酬型の業務システムの話を聞きました。そのシステムで扱ったものが売れると、1つ売れる毎にいくら、というのが決まっていて、その分お金が入る仕組みだそうです。開発元はその分リクスをとっていて、開発元がその費用の大部分を負担しているようで、導入費はかなり抑えられていると聞きました。

対象の商品が売れると儲かる仕組みです。リスクはありますが、面白い商売だと思いました。システムを使う側としては商品が売れたときにその分支払えば良いので、システムコストをあまり気にせずに導入できます。ランニングコストとしては効いてくるのですが、売れるか売れないか、売ってみないとわからないのが商売です。売れなければコスト負担が非常に少ないというのは魅力的でしょう。

言い換えると、システムの初期費用を軽くカバーできるほど売れるとわかりきっているものには、この仕組みは使われにくいのかもしれません。その場合にはシステム開発コストを負担してでも、ランニングコストを下げたほうがいい、という判断になるでしょう。

しかし大半の商品というのは、どの程度売れるのかがはっきりしないものではないでしょうか？　このようなシステムがあれば導入する側は大抵は飛びつくと思います。またシステムを売る側としても顧客が儲かれば自分も儲かるという、Win-Winの関係を築けます。

「顧客とともに栄える」非常に良い仕組みのように思いました。

先週、あるセミナーで話を聞いてきたのですが、その際に講師の話を聞いていて非常に印象に残ったことがあります。それは「成功者をまねると成功しやすいらしい」ということです。

そりゃ当たり前といえば当たり前ですね。でもこの当たり前のことが以外とみんなできないんで、成功できないのかもしれません。

で、この成功者をまねるというのは、そういう人たちから直接話を聞いたり、一緒に仕事をしたりして、いろんなことを学ぶという点が一番の秘訣のようです。成功した人たちに囲まれていると成功しやすくなる、という話を聞きますが、これはそういう効果（成功者から自然に学ぶ（まねる）ことができる）が大きいのでしょう。

そしてそうするためには、やはり自ら動いて、そういう成功している人たちに接触できるように努力しなければならないのだと思います。

昨日お会いしたある方もある分野で非常に成功されている方なのですが、成功が成功を呼ぶように、自然にそうなった、と話していました。その方も非常に外交的な人で、とにかく人と話をしているのが仕事、という感じらしいのですが、そのように多くの人と情報交換をしていく中で、自然に成功への種を得てきているように思えました。

頭でっかちで、動かないのはだめなようですね。