update it, Inc.社長のブログ

ちょっと与太話です。

例えば「15:00に帰る」と言うことに対して、(A)「15:00迄に帰る」と捉える人と、(B)「だいたい15:00ぐらいに帰る」と捉える人がいると思います。時間があまりシビアでない場合にはどっちでも良いのですが、15:00という時間が重要な場合には、(A)「15:00迄に帰る」と捉えてほしいと思います。

しかし実行者（15:00に帰る人）はそんなことは考えません。できるだけ楽な(B)「だいたい15:00ぐらいに帰る」と捉えることも多いと思います。結果として、いろいろと問題が発生することになります。

さてこの問題、何が原因なのでしょうか？　「15:00に帰る」という表現が曖昧ということでしょうか？　それとも気を利かせない実行者が悪いのでしょうか？　または、勝手に15:00迄に帰ることを期待する側が間違っているのでしょうか？

おそらくこれと同じようなことが、プロジェクト内では何百回と繰り返されていて、その度に様々な問題やバグ、仕様間違いなどが発生しているのではないでしょうか？

このケースで重要なのは、コンテキスト（文脈）です。どのようなコンテキストで用いられた文章なのかによって、受取る意味が異なります。「15:00に帰る」という表現そのものは決して曖昧な表現ではないのですが、コンテキスト次第では様々な意味を持ちうる点が曖昧さを生み、情報の発信側と受け手側で同じコンテキストを共有していないと、場合によっては意味を取り違えて伝わる場合がある、ということです。

ところがコンテキストの共有が十分できていない場合というのが実際にはよくあります。「え、そういうことだったの？」というケースです。相手が同じコンテキストを共有していることをきちんと確認しないことには、あなたの言葉は違う意味で受け取られているかもしれません。

IT Proの1万人が使った“Excelのお化け”という記事を面白く読みました。日産とリクルートの事例で、多くの人がExcelファイルを共有して使っている場合に起こる問題点と、その解決方法について書いています。

解決策は、日産の場合にはデータをExcelを使ってXML化し、XMLデータベースに格納する方法、リクルートの場合にはマイクロラボ社のツールを用いるというものでした（ExcelをWebブラウザ内で動かし、そことアプリケーション・サーバを連動させてDBに格納する方式）

それぞれ、いわゆるWeb化はしていないのですが、理由はユーザがExcelを使い慣れているため、そして高額な投資をしてWeb化するほどでもない、という２つの点のようです。

正直なところ、読んで思ったことは、これは最初からわかっていた事だよね、ということです。多少Excelを使い込んでいる人であれば、それだけの大人数（日産の場合、なんと日米欧の１万ユーザ）でExcelファイルをみんなで共有して使った場合に問題が起きないわけがないことぐらい理解しているでしょう。

でも現実問題として、こういうのってよくある話だと思います。上記のいずれもいわゆる情報系であり、勘定系と異なりシステム投資があまり行われません。金がないから、まああるものでいこう、ということになるのです。

法律上必要だとか、何らかの理由がないと、情報系と呼ばれる部分にはなかなか投資してもらえません。人手で回せる間は人手で回す、という発想になりがちです。投資対効果がわかりずらいことも一因でしょう。

しかしビジネスは「情報戦」です。外部・内部を問わず、情報を制する者が最終的には勝つはずです。それらの仕組みを積み重ねていくことで、他者に対する確固たるアドバンテージを得ることができるようになります。日本のシステム投資も、もう少し大局的なものの見方で、情報に投資する、という姿勢が必要なのではないでしょうか？

昨日はCIAJ/Zit共済IT経営改革研究会にて、crossnoteの商品発表をさせていただきました。

ミニ発表ということで、５分間という枠でしたので、ちょっと早口での説明になってしまい、わかりにくい部分もあったかもしれません。そんなわけで、至らない部分もあったかもしれませんが、多くの方に商品を説明させていただく機会を得たことは、非常にうれしく感じました。また多くのベンチャーの社長の方などと交流できたことが非常に楽しかったです。

昨日の説明の切り口は、「プログラミングの世界にはＩＤＥ（統合開発環境）が当たり前になってきているのに、なぜドキュメンテーションの世界は、相変わらずワープロと表計算ソフトだけ、という旧態依然としたままなの？」という観点での説明です。「統合ドキュメンテーション環境」を実現するためのものとしてcrossnoteをご紹介し、５つの導入メリットを説いています。

詳しくは、昨日の資料をこちらに置いておきますので、ぜひ御覧ください。

昨日、あるITベンチャーの社長が出ているストリーミングを見ていたら戦略と戦術の違いに関する話が出ていました。ランチェスター経営に関する本とか読んでも、良く出てくる話題ですが、違うということがわかっても、ではどこまでが戦略で、どこから戦術なのか、という具体的な話になると、私自身、以前はよくわかりませんでした。

一般な話として、戦略を間違えていると、いくらがんばって戦術に長けても戦いには勝てない、ということがあります。でもそれだけではやはりどこまで戦略で、どこから戦術なのかはわかりませんね。

上記のストリーミングの中では戦略とは、考える対象の広さの違いを言っていました。つまり単に直接的な戦いだけを見るのではなく、その前提となる周りの要素（ロジスティックス、外交、その他もろもろ）を踏まえて考えることだ、ということだそうです。これは非常に分かりやすい説明だと思いました。目指すは「戦わずして勝つ」ことこそ王道なりと。

私なりに、さらに付け加えるならば、いろいろな観点で広く捉えた上で、「どの部分に自分の出せる力を集中させるか」というのが戦略じゃないかと理解しています。物事をできるだけ広く捉え、その上で逆に力を集中させるポイントを定めること。これが戦略の本質なのではないかと私は思っています。

誰でも自分に与えられたリソースには限りがあります。その限られたリソースを如何にして最大限有効活用するか、というのが戦略の重要の根源的な理由なのではないでしょうか？

スレッシュホールド（Threshhold）って言葉をご存知の方って、どのくらいいますか？　単語の意味はいろいろあるのですが、ここでは「限界、境界、分かれ目」という意味で捉えてください。電子工作とかやっていた方には割とおなじみの言葉だと思います。

電子回路の世界では、入力電圧をリニアに変化させた場合に、ある電圧を超えたときに出力電圧が急激に高くなるような現象を指します。例えばデジタル回路では、論理上は0に相当する電圧と、1に相当する電圧しかないのですが、これをアナログの世界で見た場合、当然その間の電圧も存在します。でも、このスレッシュホールドというものがあることで、入力電圧がそのスレッシュホールドのレベルに到達すると急激に出力電圧が立ち上がるので、0と1を明確に区別できるようになっています。

最近、いろいろな部分でビジネスの世界でもやっぱり同じようにスレッシュホールドというのがあるのだな、ということを認識ました。入力の部分はほんのちょっとの違いにしか過ぎなくても、そのスレッシュホールドを超えたとたんに、出力されるものは0から1へ、大きく変化する、ということです。

おそらくそれは、世の中では「正のフィードバック」が働いていることから来ているのではないでしょうか？。つまり何かが話題になると、それにつれて関連する部分でもそれが話題になる、いわば「話題が話題を呼ぶ」という現象です。（ちなみに逆をいうと、そのスレッシュホールドに達するまでは、「0」なのです）

「うまい正のフィードバック」をどうやって創り出していくか、がビジネスの成功の鍵ともいえるかもしれません。

昨日の「らっきょの皮インターフェース」と似たような話ですが、ソフトウェアというのはどうしてどんどん重量級になってしまうのでしょうか？

人間の場合、太りすぎは良くない、と注意されますが、ソフトウェアの場合、そのように判断してくれる人はいません。でも明らかに太りすぎているソフトウェアって見ますよね。

問題なのは、太りすぎが明らかであってもダイエットはそう簡単ではないということです。なんかよく分からんコードが残っていて、動いている様子はないんだけど、本当に必要のないコードなのかどうかが判断できず、削除できない、みたいな贅肉コードがあっちこっちにあると、それらを判断して削除するだけでも手間隙がかかり、大変です。

一旦贅肉が付いてしまうと、ダイエットは大変なようです。はじめから贅肉を付けないように、日々の鍛錬が重要だ、というのはスポーツも、ソフトウェアのプログラミングでも同じなのだと思います。

単に（見かけ上）動けばいいということではなく、ある程度贅肉をきちんと処理するところ（最低限のリファクタリング）までやって、初めてプログラムが出来上がったといえるのだ、ということをジュニアなプログラマ達に刷り込む（インプリンティングする）べきでしょう。

システムを設計する際には、必ずといっていいほどいろいろな部分で「皮を被せる」ことが行われていると思います。この「皮を被せる」というのは、あるモジュールを利用する際に、それをそのまま使うのではなく、一般化したインターフェースを自前で定義することで、そのモジュールに対する依存性を下げるために使われています。

確かにインターフェースを介した設計というのはいいことだと思うのですが、現実問題として、その「皮」がまるでらっきょの皮のように何重にも定義されているケースがよくあります。インターフェースを何重にも定義した場合、それぞれの階層毎にテストが必要となり、メンテナンスも大変になり、メモリを余計に食い、パフォーマンスも劣化し、あまりいいことはないはずです。

つまり、何重にもなっている場合には明らかに設計を間違えているわけですが、例えば「決まり」としてそうしなければならない、などといったよく分からない理由で皮が定義されていることがしばしばあります。またどういうわけか、そういった皮を定義することが生きがい（趣味？）のような人もいますよね。だから世の中には無用な皮をまとったシステムが大量に出来上がり、本人達の自己満足のために、客観的にはやたら複雑化したシステムができあがるわけです。

皮を新たに定義する前に、今そこにあるものが目的にあったインターフェースかどうかを検討し、もしほぼ満たすものであれば、むしろ積極的にそれを活用すべきなのではないでしょうか？

日本料理のように、素材の良さを活かしたシステム設計というのも「あり」だと思います。

@ITのWeekly Top 10のGoogle ドキュメントの進化は止まったのかの中の、Google Appsに関するコメントを非常に興味深く読みました。記者の方はGoogle Docsのヘビーユーザだそうで、ユーザ視点に立った評価をしています。一言で言うと、SaaSってことで注目は浴びるけど、基本がなっちゃいないとみんな使わなくなっちゃうよ、とあります。

マーケティングという観点で考えると、まずは使ってもらうことがとても重要です。ですので、Google Appsの『掴みがいい』（使い始めたときにインストールなしで、すぐ使いだせる）というのは非常に強みになります。しかし、いざ使い込むと、既存のオフィスソフトに比較しての低パフォーマンスやバグの問題など、欠陥ばかりが目立つようになり、利用者の期待に応えたものになっていない、としています。

記事の最後はこのように締めくくられています。

— 引用 —
配信方法だけでユーザーを満足させるのは限界がある。ソフトウェアの基本性能を満たしながら、SaaSならではのプラスアルファが求められるのだろう。
————

私も、Google Appsが従来のデスクトップ型のオフィスソフトのSaaS版だ、という位置づけのままであれば、少なくとも日本では現状の地位から大きく躍進することは可能性として低いと考えています。インストールがないという点はシステム管理者からみた場合、とても重要な魅力ですが、もしそれがGoogle Appsの魅力のすべて、だとしたら、その魅力は非常に薄っぺらいものに思えるのです。

日頃利用するユーザが恩恵を受けるようなものこそが、本当に必要とされるものなのではないでしょうか？

ドキュメントを作る際、そのほとんどはコピーして作って、ある部分だけ書き換えて新しいものを作る、そんなケースって結構ありませんか？　この場合に問題なのは、作ってしまった後のメンテナンスです。共通部分の変更の場合、コピーしたドキュメントの数だけメンテナンスしなければならず、大変です。

次のcrossnoteのリリースではそんな場合に有効な「参照」機能が追加になります。ドキュメントをコピー＆貼り付けする際、「参照として貼り付ける」ことで、そこに表示される内容は、オリジナルのドキュメントの中身と同一のものになります。つまりオリジナルのドキュメントを修正すると、それを参照しているドキュメントも自動的に修正されるようになります。

参照している部分は編集ができなくなっているのですが、編集できる状態にして内容を書き換えることもできます。ただし書き換えてしまった場合には、オリジナルのドキュメントを修正しても、自動的には変更されなくなります。この場合でも参照リンク情報は保持されており、修正を取り消して元の状態に戻すことも可能です。

参照はcrossnoteのドキュメント内の枠の単位で可能です。従って図や表、文章などを枠の単位で部品化して、さまざまなドキュメントで再利用し、かつ保守性を高めることができます。

ある方にこの機能をご紹介したら、「ドキュメンテーションもプログラミングと同じになってきた」とおっしゃっていました。うまい表現だと思います。Eclipseでプログラムを書くように、crossnoteでドキュメントを書く時代がもうすぐやってきます。

この機能のリリースはまだ確定していませんが、今月中には行う予定です。お楽しみに。

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

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

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