update it, Inc.社長のブログ

今まで知らなかったのですが、このGliffyというWebアプリすごいですね。Flashベースのアプリのようですが、Visioと同等レベルのことができます。もちろん細かいことを言ってしまえばVisioと同等とはいかないのですが、通常のお絵かきレベルであればVisioと変わらないのではないでしょうか？　しかもFlashベースということもあってアクションの技が細かい。Visioにゲーム感覚の遊びの要素がちょっと加わった感じです。

もちろん実用性も十分です。保存履歴があるので、元に戻すのも楽ですし、出力フォーマットではSVGが選べるあたりがいいですね。コネクタの実装もなかなか使い良いものです。

うーん、crossnoteも書ける図形のレベルはそんなには変わらないと思うのですが（でもcrossnoteは回転とかまだできない）、あの「遊び感覚」というか、エフェクトは真似できないですね。こういうあたりはで選択したプラットホームの違いが大きいと思います。UI周りはFlashベースのアプリにはかなわないですね。

こういうWebアプリがいろいろ他のWebアプリ(Google Appsなど)と連携しだしたら、MS Officeもかなり苦戦するかも。

情報系と呼ばれるシステムで扱われるナレッジワークは、なんらかの新しい事や物を作り出していくのが仕事です。前回と同じ業務ではないということで、非定形業務ということもできます。システム開発の設計書の作成なども当然ナレッジワークであり、非定形業務と呼ぶことができます。（システム開発の設計書の作成も、いつも同じ仕事だよ、というぼやきは聞こえそうですが…）

さて、こういった非定形業務を支えるシステムというのもいっぱいあるわけですが、こういったシステムの導入の効果について、なんらかの形で数値化したいと思った場合、どういう方法があるのでしょうか？

よく聞くやり方としては、ナレッジワーカ一人当たり、効率化による時間の節約分を金額換算するという手法があります。確かにその対象者が残業だらけで時間短縮により残業代が節約できればその通りになるのですが、通常は実際のところその時間短縮分の効果があるのかどうか、見えにくいという問題があると思います。

非定形業務の場合、1つ1つの仕事にかかる時間の変動幅が大きすぎて、ある小さな部分が効率化されたとしても全体の時間にその分が現われにくいからではないでしょうか？　なので、ナレッジワーク向けのシステムの効率性を数値化しても、いまいち説得力がないというか、信ぴょう性に欠ける気がするのです。

でもだからといってナレッジワークをシステム化しても意味はない、ということにはならないでしょう。ナレッジワークにおける単純作業（機械がやるべき作業）やコミュニケーションを改善するような仕組みは、上記のような数値化は伴わなくても明らかに本人たちにとって「仕事をやりやすくする」という観点で改善してくれるからです。

ナレッジワーカにとって、この「仕事のやりやすさ」は重要な指標でなないでしょうか？　長期的にみた場合、仕事がやりやすい環境にはいい人が集まり、いい仕事ができるようになると思います。

この「仕事のやりやすさ」を数値化できると良いと思うのですが、何か計測可能な、良い指標はないものでしょうかね？　アンケートを取るぐらいしか思いつかない…

従来のクライアント・サーバ型システムでは、カスタマイズ性の高さを謳うパッケージ・システムが数多くありました。それはエンド・ユーザ・コンピューティング(EUC)の普及の鍵だったのだと思います。その当時、企業の情報部門が処理しきれないバックログを抱えていることが問題視されており、効果的な対応方法としてEUCが積極的に取り入れられた時期がありました。

最近はEUCを声高に訴えるところは減ってきているのではないでしょうか？　これはEUCがメンテナンス性に問題があり、現場の人が変わると対応できなくなることが多く、コンプライアンス的な観点から問題視されてきたためだと思います。EUCのすべてを否定することはないと思いますが、できるだけEUCではなく、業務のプロセスを見直した上でシステム化で対処すべきだ、というのが現在の流れではないでしょうか？

「業務のプロセスを見直した上でシステム」という観点でパッケージシステムを考えた場合、そこに求められるのはあるべき業務の姿をそのままシステムとして実現する機能であり、ごりごりプログラミングすればできますよ、というシステムではなくなってきていると思います。業務のプロセスのバリエーションに対するオプションというか、カスタマイズ性は必要だと思いますが、それは「設定」するだけの話であり、なんでもできるプログラミング環境が求められているわけではないと思います。

このように、あらかじめ必要な機能をシステムに盛り込むというか、そういったサービスを組み合わせて用意することにより、EUCの弊害であった属人性を排除する、というのが現在の流れでしょう。

この流れは中小企業から始まるのだと思います。通常、世の中の大きな流れはまず大企業が導入して、それを中小が後追いする、というのが定番だと思いますが、大企業は既に大量にカスタマイズされたアプリケーションがあり、そう簡単に身動きがとれる状態ではありません。それに比べ束縛されるもののない中小企業のほうがこの流れに乗りやすいのではないでしょうか？　SaaSアプリケーションの当面のターゲットが中小企業である、というのも同じ話だと思います。

昔、転職をした際に、転職前後で「あれ？」と思うぐらい文化的な違いを感じたことがあります。どういう言葉で表現すべきか、いまいち適当な言葉が見つからないのですが、とりあえず「説明責任と合意」というように表現しておきます。

その転職以前は、仕事はあうんの呼吸で行うものという認識がありました。できるだけ普段から密にコミュニケートすることで、極力あうんの呼吸を保つ。こうすることで非常に効率的に物事を進めることができます。でもその一方で、私の場合、きちんと説明し、合意を求めるという部分をたびたび省いてしまっていることがありました。結果としてなんとなく相手が理解しているものと期待しているのに、いざ蓋を開けてみたら非常にまずいことになっていた、なんてこともあったかもしれません。

転職先で感じたのが、この「説明責任と合意」を意識してやっているな、という点でした。特にその会社の経営陣の人はかなり意識して、自分の言葉できちんと説明し、相手に納得してもらうということをやっていたように思います。

正直なところ、私はいまだに「説明責任と合意」を、結果としてないがしろにしてしまうことが多いように思えます。意識してそうするように努めてはいるのですが、後になって反省することが多々あります。長年培った仕事のスタイルというのは一朝一夕にはなかなか変わるものではないのかもしれません。

長年連れ添った夫婦でも同じような状態になる例があると聞きますが、やはり説明すべき点はきちんと説明するという姿勢が必要なのだと思います。勝手に相手がわかっているだあろう、という推測のもとで物事を進めるのではなく、きちんと「説明責任と合意」を果せるよう、努力していきたいと思います。

最近、SIerの受注ソフトウェア開発業の会計基準が2009年4月から工事進行基準に変わる、という記事が@ITで流れていました。デスマーチがなくなる？ IT業界に義務付け「工事進行基準」ってなんだ

従来は工事完成基準といって、開発終了時に売り上げと原価を一括計上することが多かったのですが、こうするとどんぶり勘定で行われるプロジェクトが多かったということで、これからは工事進行基準にすることで会計上におけるプロジェクト開発の透明性を増そう、という話らしいです。

工事進行基準のやり方はいくつかあるようですが、一般的な原価比例法の場合、工事原価と実際にかかった原価から進捗率を求めるという方法になります。こうして求めた進捗率と、工事収益総額、および工事原価総額により、工事進行基準における損益が計算できることになります。従ってプロジェクトを開始する前に原価と収益の見積もりをある程度の精度で求めることが要求されます。また実際にかかった原価を裏付ける資料も必要になると考えられます。

この工事進行基準という考え方は、もともと工事進行基準が適用されてきた建築工事などのおいて、長期の請負工事においてあらかじめ収益の獲得が保証されているのだから、各決算期毎に適正に収益を計上しなさいよ、というところから出来上がっているようです。

でも、ということは、システム開発プロジェクトのように、長期の請負工事においても「収益の獲得が保証されている」とは言い難い状況の場合はどうなんでしょうね？　実際上記の原価比例法で損益計算するとして、赤字プロジェクトの場合には途中から人を余計に投入して回復しようとするため、その時点で見積もり修正をしなければ実際より早く進捗率が上がっていくことになります。これはこれで変ですよね。ということは都度、見積修正をするのか？　どうなんでしょうか？

私自身、このあたりはまだ疎いので、もうちょっと勉強してみようと思っています。

ここのところ、春本番という感じになってきましたね。

今日の天気はいまいち曇っていますが。

この1週間、少しずつcrossnoteのホームページを書き換えています。以前のcrossnoteのホームページは文字ばかりで、わかりにくかったのを反省し、できるだけ図を多く入れて説明するようにしました。またcrossnoteの動いている様子も見れるようになっています。

crossnote

ぜひご覧ください。

ひさびさの写真です。会社のすぐ近くで撮ったものです。

実は１週間以上前に撮っていたのですが、載せていませんでした。

さて先日、Ver 1.1.0のリリース時に見送ったもうひとつの目玉機能「Q&Aの管理機能」ですが、おそらく明日(4/4)にリリースできると思います。（本当は今日のつもりだったのですが、いろいろな都合で１日延ばしました）

Q&Aの管理機能というと、単にQ&Aのやり取りの一覧表のことだけ、と思われてしまいますが、実はこれが大きな将来性を持っていると考えています。なぜならば、これで細かいTODOを管理できるようになってくるからです。このTODOは、要件管理で扱う要件よりはもっと粒度の細かい、ちょうどプログラミングをする際にソースコードに書くTODOに相当するようなものです。

TODOは結局のところ、いつまでに、誰が、何をするかというだけのことです。今まではTODOをPCのディスプレイに付箋紙で張り付けたり、プリントアウトしたドキュメントに付箋紙をつけたりしていたと思いますが、これだと期限までにちゃんと仕上げたかどうかが確認できません。またみんなで共有することもできません。

ディスクトップ上で付箋紙が使えるアプリケーションもありますが、本当に付箋紙を張りたい対象は、作業している対象そのもの、たとえばドキュメントを書いている場合にはドキュメントにTODOを書き込めれば便利なはずです。そうすることで、みんなでTODOを共有することができますし、ドキュメントを見れば、なにが「やりかけ」なのかが一目瞭然になります。

そしてプロジェクト全体でどんなTODOがあって、予定を過ぎているものはないかとか、誰か特定の人がボトルネックになっていないか、などを確認するために一覧機能を利用します。こうすることで、TODO全体をプロジェクトで管理することができるようになってきます。

明日のリリースをお楽しみに。（と言っておいて、リリースできなかったらまずいね。:lol:）

今日、MicrosoftのOffice 2007で利用されているフォーマットであるOffice Open XMLがISO標準として認められたというニュースが流れていました。

先日リリースしたcrossnoteのWord 2007形式での出力機能でもこのファイルフォーマットを利用しているので、会社としてありがたいニュースです。ただ実際に携わってみた感想を言えば、ちょっと 「？」な部分もあります。

実際にこのフォーマットでの出力をやってみてわかったのは、これはやっぱりMSフォーマット！ということでした。

まずXML Schemaの定義に基づいてモデルオブジェクトを生成しようとしたのですが、JavaのBinding compilerではどれを試してもOffice Open XMLのSchemaを処理できるものがありませんでした。XML Schemaが悪いのか、Binding compilerが悪いのか、うちの使い方が悪かったのかはわかりません。まずここで最初の、「？」。今回は出力だけなので、DOMにいったんぶち込んで、それを吐き出すようにしています。

次の悩みどころは、実際にWordで表示してみるまでわからない、という部分。Schema定義的にはオッケーなはずなのに、Wordで表示してみるとなかなか思ったように表示されず、というのにだいぶ苦労させられました。特に図形部分はまだ情報が少なく、トライ＆エラーの連続です。基本的にMS Officeがないとちゃんと動くOffice Open XMLのファイルは定義すらできません。ということで、やっぱり「？」。

最後の「？」は、最新の定義なのに「Deprecated」の嵐であること。後方互換性のためなのでしょうが、最新のXMLの規格になんで後方互換性が必要なのか？　よくわかりません。さらにそのDeprecatedとなっている機能を使わないと実現できない部分もあるように思います。ちなみにVML(Vector Markup Language)はDeprecated的な扱いのようですが、結局使いまくりです。

ま、MS Officeが「リファレンス・インプリメンテーション」ということなのでしょうね…