update it, Inc.社長のブログ

来週月曜日にcrossnoteをVer 1.1.4にバージョンアップします。ここのところほぼ毎週バージョンアップしていますが、今回の目玉は次の２つです。

■ 参照リンクに対応します
■ Excelシートなどを直接、新規作成できるようにします。

crossnoteドキュメントにはいままで参照リンクの仕組みがなかったのですが、ようやく今回のバージョンで対応します。この参照リンクとは、文章中で「3.4 ほげほげ の章を参照してください」と書きたいときに、「3.4 ほげほげ」を参照リンクとして差し込めば、ダブルクリックでその位置にジャンプするようになります。

crossnoteの参照リンクは、Wordなどと違って同じドキュメントだけでなく、他のドキュメントへの参照リンクが作成できることが特徴です。しかも、他のドキュメントの構成が変わってパラグラフや図表などの番号やタイトルが変わった場合、参照リンクの番号やタイトルも自動的に更新されます。なのでドキュメント間での参照が多い場合には特にお勧めの機能です。

なお参照リンクにはURLも指定可能です。この場合にはブラウザが開きます。

そしてもうひとつの目玉が、新規作成のメニュー機能の変更です。今まではExcelファイルをcrossnoteで扱おうと思った場合、いったんデスクトップなどで作った上で取り込むといったようなことが必要だったのですが、今回の対応でExcelやVisioのドキュメントを直接crossnoteのメニューから作成できるようになります。（あ、もちろん対応するアプリケーションがインストールされていないと、参照や編集はできませんよ）

新規作成メニューは設定画面の「新規作成」のところで好きなアプリケーションが選択できるようになっています。（と言ってもあらかじめこちらで仕込んだアプリケーションしか選択できません）

なおこの新規作成メニューの変更は、今後の新しい新機能（？）への「布石」です。お楽しみに。

IT系のニュースを見ていていつも思うんですが、ここのところIT系のニュースをにぎわしているのはコンシューマ向けのいわゆるCGM(Consumer Generated Media)的なものばかりで、ビジネス向けの分野でのニュースというのが少ない気がします。これは単にビジネス向けの場合、地味なのでニュースとして取り上げられにくいのでしょうか？　それとも目立っていないだけで、ニュースそのものはそれなりにあるのでしょうか？

確かにビジネス向けのITというのはおもしろくなさそう、とか、必要もないのに買わされて金を巻き上げられそう（？）とか、関係なさそう、とか、ニュースを見る側があまり興味を持って見る話題が少ないのかもしれません。

もう一つ考えられることが、寡占化です。ビジネスの世界でもIT化もだいぶ行き渡ってくると、今主流のものに満足してしまって、新しいものが入り込む余地がだんだんなくなってきているんじゃないかと思うのです。例えばSaaSは今一番の旬な話題かもしれませんが、実際にはその世界でも既にSales ForceとGoogleによる寡占化が進んできているように思えます。

日本の会社では何か新しいものを導入する際、横並び主義というか、他が入れていれば入れる、そうでなければ入れない、というスタンスの会社が結構多いと思います。これは日本の会社が根っからのリスク回避者というか、コンサバだからでしょう。なので、どこかすでに入ったところがあると、どんどんそこに集まる。そんな状況なのではないでしょうか？

最近ある方にセールスの方法についてお聞きしたところ、昨日絵葉書が送られてきました。その絵葉書には一杯、私に対する励ましの言葉が書かれていました。

それを見て「はっ」としました。セールスは相手に物を売り込むことではなく、相手のニーズを捉え、その心に訴えかけることなのだと。

その方はそれを絵葉書という形で私に説明してくださったのだと思います。

技術者上がりの私は正直なところ、実地でのセールスの経験はほとんどありません。一応一通りそれなりに本などは読んで勉強しているつもりなのですが、本当に「腹に落ちた」状態になっているかというと、まだまだ上辺のあたりしか理解できていなかった、というのが本当のところです。

より本質の部分をマスターして自然に出来るようになりたい、と強く思いました。

先週の金曜日にアイコーチさんがやっているオフショア開発勉強会に出席したのですが、そこで「ITプロジェクトを失敗させる方法」（中村文彦著　ソフト・リサーチ・センター）の著者の方が講師をされていました。

ITプロジェクトが失敗する主因は、実は「超」上流というべき部分で決まっていることが多い、ということを強調されていました。これはプロジェクトが失敗する場合、そのプロジェクトを受注する段階で既に決まってしまっていることが多い、ということを意味しています。受注する段階でそのプロジェクトに関わる関係者（例えば受託側、委託側双方の社長とかも含みます）がプロジェクトをうまく回すために主体的にきちんと協力し合わないとうまくいかないんだよ、ということです。

主体的にきちんと協力し合っていない１つのケースとして、「内部に政治的ないさかいがあり、調整されていない」ことを指摘されていましたが、この話を聞いたときに、過去うまくいかなかったいくつかのプロジェクトが脳裏をよぎりました。

プロジェクトが失敗する原因として、上流工程が問題に占める割合が大きいのは確かですが、実はそれは、そもそも「超」上流工程の問題によって引き起こされている場合が多い、ということになります。

これを解決するにはどうすべきか。講師の方が強調されていたのは、「対話」ということでした。よく「対話」すること。対話とは自分の主張を繰り返すことではなく、相手の話をよく聞いた上で、1つ上の解決策を探ること、だそうです。非常にいい説明ですね。私もぜひ「対話」を実践していきたいと思いました。

設計書を書く際にいろいろな用途でExcelを使っている人は多いのではないでしょうか？　私自身、それなりに活用しています。私の場合には設計書そのものというよりは、周りの資料を作成するために使っています。

例えば、表ベースで仕様をまとめておき、その仕様を元に実際にアプリケーションを構築するための何らかの要素を自動生成する、という使い方をされる人は多いのではないでしょうか？　私も例えば、Excelシート上にデータベースのテーブルの定義を書いておき、それをVBAでDDLに落とすようなことをよくやってきました。

昨日ある方にお会いしたのですが、その方のところではかなりExcelをうまく利用しており、いわばExcelがマスターデータのような扱いになっていて、それを元にHTML化したり、データベース定義を自動作成したり、コントロールするためのXMLを自動生成したり、などといったことをやっていました。

設計書の一部が実際のアプリケーション構築のための元情報となるという考え方は、情報の一元化という観点で非常に効率的だと思います。Excelを使うというのは、こういったことを実現するのにExcelが一番手軽だ、ということから普及しているのでしょう。

設計書を扱うと言っている以上、crossnoteでもこの手のサポートをうまく考えていきたいと思っています。

まったくの雑談になってしまうのですが、皆さんは睡眠時間をどの程度とっていますか？　私は最近は平均4.5?5時間です。多少短めの部分は会社でシエスタして、それで補っています。このシエスタは絶対お勧めですよ。短時間（15分?20分）だけ寝る、というのがコツですが、それをきちんと守ると、そのあとの仕事の効率が全然違います。

あと徹夜は絶対に避ける。これは昔、大学生の頃、アルバイトでプログラミングしていた時の経験からそうしています。そのころ、あるアセンブラのプログラムを作っていた時ですが、何かイベントに間に合わせなければならないということで、締め切りに追われた仕事をしていました。ところがそのプログラムに不具合があり、なかなか治らず、2日間ほとんど徹夜状態で仕事をしたのですが、ぼーっとした状態で仕事をしたことでかえってバグを増やす結果となってしまったのです。（しかも締切には間に合わなかった、という「オチ」が付いてます）

人間、やはり睡眠時間は重要です。時間がない時ほど、きちんと計画的に寝て、起きているときの頭の回転が最大限になるようにしていきたいものです。おそらくそのほうがトータルの生産性は上がるのではないでしょうか？

今まで知らなかったのですが、この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アプリケーションの当面のターゲットが中小企業である、というのも同じ話だと思います。

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

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

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

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

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