update it, Inc.社長のブログ

crossnoteを検討してもらうと、かなり広い範囲ですべてcrossnoteを導入しないと使えないんじゃない？　のような質問をもらうことがあります。確かにこの手のものは利用者の数が増えれば増えるほど使いやすくなるものです。

ただしcrossnote自体はプロジェクト単位、もしくはその中の一部のサブプロジェクト単位でも導入可能なものです。最初から大規模に導入しないと意味がない、というものでは決してないです。プロジェクトに関与している協力会社の社員や、ユーザに対しても、持っているライセンスの範囲内ならば自由にIDを発行することができ、それらの人もインターネット環境とPCさえあれば一緒に利用することが可能です。

なお場合によってはなんらかの理由によってユーザ側に導入してもらうのは難しい、というケースもあると思います。そのような場合にはPDFやHTMLなどのフォーマットに変換して、送るという従来の方法をとらざるを得ません。3月の末を目処にWord形式(Office Open XML形式）でのエクスポートも出来るようにする予定ですので、それをリリースすると改変可能な形でユーザに届けることが可能になります。

経済産業省が迷惑メールの広告主に対する懲役刑や罰金などの刑事罰を新設するために、特定商取引法（特商法）の改正案を提出しようとしているというニュースが流れていました。

ちなみにこの場合の「迷惑メール」の定義はなんなのでしょうか？　「改正案は、同意を得ていない送り先への広告・宣伝メールの送信を、原則として禁じる」とニュースで報じられていますが、ということは営業的なメールをやり取りする前には必ず同意を得る必要がでてくるような気がします。というのは、何をもって「広告・宣伝メール」なのかがはっきりしないためです。たとえ送り側が広告・宣伝を意図していない場合でも、事前に承認を得ていない人に対してはメールを送るのがやっぱり難しくなるのではないでしょうか？

あと気になるのは送り先に関すること。今までの迷惑メールの話は個人を対象にしていたと思いますが、対会社の場合はどうなのでしょうか？　まあそんなことはないと思いますが、会社同士の商談の話をするためのメールを送れない、となるとかなりやっかいですよね。

まだ法律の中身をよく分かっていないので推測で物事を判断すべきではないのですが、この法律がどのように運用されるのかについては興味をもってみています。

25日に信用中央金庫で「全国信用金庫データ通信システム」（全信金システム）に障害が発生して振込などの処理ができなくなったというニュースが流れていました。翌日には復旧して未処理だった74万件の為替取引も処理されたようです。また原因は調査中とのこと。

現代の社会では決済系のシステムの障害で決済が出来なくなると、いわば経済の血流が止まった状態になります。最悪、資金繰りで問題が発生すると予期せぬ倒産が発生する可能性すらあります。

長年金融系のシステムをやってきただけに、このニュースはあまり他人事には思えません。決済系のシステムは担当したことはないのですが、日中リアルタイムに動いていたり、その時点で必ず稼動しなければならないシステムを担当していると、そのプレッシャーは大変なものです。

対応に追われている現場の人は大変なことでしょう。がんばってください。

フローとストックという言葉は対比するための用いられることが多いですが、コミュニケーションのためのツールについても、同じようにフロー型ツールとストック型ツールに分類することができます。

フロー型ツールの代表格はEメールやメッセンジャーなどです。これは一過性の情報のやり取りに便利で、当事者間の知識を供給させることができますが、知識の体系的な蓄積には向きません。ブログもフロー型ツールの１つといえます。

一方ストック型ツールは名前の通り、情報を蓄積するためのツールで、Wikiや文書管理システムなどが相当します。後で参照するために情報を体系的に蓄積するには便利ですが、知識を共有させるという目的には向きません。情報を蓄積しても、それだけでは知識が当事者の人たちの頭の中に入ってはいないからです。

さてcrossnoteは、というと、上記のフロー型ツールとストック型ツールの両方の特徴を併せ持っています。基本的にはストック型の文書管理システムのような体裁をしているのですが、ドキュメントの変更点を互いに教えあうことを通して知識の共有をはかっている部分はフロー型の特徴といえます。

実はcrossnoteの次回リリースでは、メールのように定期的にサーバ側に変更通知の有無をチェックする仕組みが載る予定です。これによりcrossnoteはより積極的なフロー型ツールになってきます。お楽しみに。

以前金融系のシステムを担当していたとき、私の業務のもっとも重要な部分は、対象の業務を理解してその業務をうまく回るようにシステムを設計することでした。そのためには業務を理解していることは大前提で、頭の中には自然に対象業務のモデルが出来上がっていました。なので、正直なところ、概念モデルというのはあまり私にとってはメリットが感じられないものでした。

自分で既に理解していることを書き出しても、あまりメリットが無かったからです。実際、以前のブログ「重複を削ろう」では、概念モデルなんて削れるんであれば削っちまえ、ということを書いていました。（まあそのときの趣旨は、業務をモデリングするならばいいけど、概念モデルと称してシステムをモデリングすると、物理モデリングと重複感があるよね、ということですけどね）

ただ最近はちょっと考え方が変わってきて、改めて概念モデルというのは結構いいものだ、と考えるようになってきました。それは自分のためというのではなく、他の人に説明するための道具として、です。特にオフショア開発など、分散拠点開発を行う場合には有効な道具になりそうな気がします。

システムの開発を依頼する場合、相手が対象の領域に精通している場合には必要ないですが、オフショア開発などの場合には、こちらの事情を先方が理解している場合は少ないと思います。結構理解していたとしても、なかなか100％こちらと同じ、というわけにはいかないでしょう。

こんな場合に、まずは概念モデルで対象の業務について、どういうもの（用語）をどのような意味で使っていて、どのように関連しているのか、ということを最初に理解してもらう。これをやって相手（オフショア側）にバックグラウンドをきちっと理解してもらえれば、相手側に創意工夫をしてもらいやすくなり、互いにシステム開発を進めやすくなるのではないでしょうか？

難点としては、そのような業務に精通していて、かつ概念モデルをUMLで書ける人というのはだいぶ限られてしまう、ということでしょうか？　でもこういった部分にはニーズがありそうですね。

ということで、業務寄りの設計者ほどUMLに精通すべきかもしれない、というのが今日の提案です。

あるブログを見ていたら、「上級プログラマの書くコードは保守しづらい」ということが書いているのを見つけました。どうもそう思っている人が結構いるようです。だからそういう人がプロジェクトに居てもあまり意味がないのだと。日本のプロジェクトの現場って、こんな程度なんですよね。

ちなみに私は上級プログラマという言葉はあまり好きではないので、ここから先はスーパープログラマと呼びます。

まあ確かに「難解な」コードを書かれるのはたまらん、と思う気持ちはわかります。でもスーパープログラマと呼ばれる人達が書くのは構造の美しいコードであって、難解なコードでは決してないはずです。

スーパープログラマと呼ばれる人は普通に書いたらやたら長くなるコードを非常に短いコードで書ける人だ、と考えている人が多いようですが、プログラムの書き方の技巧的なことだけで短くしているだけであれば、それはスーパープログラマではないと思います。プログラムの長さが問題なのではなく、対象の問題に対してどれだけすっきりとした構造で問題を解いているか、ということだと思うのです。

（ちょっと補足しておくと、私が今まであったスーパープログラマと呼べる人たちは、さらに問題の対象領域の捉え方をいろいろなレベルで考えることで、さらに高次元の解決策を見つけられる人たちでした）

それにプログラミングがあまりできない人が、プログラミングが出来る人に対して、「それは私たちのレベルではないから止めて」というのはやっぱりなんか違うかと思いませんか？　本当ならばそんなレベルの低いままでずーといる人（成長しない人）は、その仕事をするべきではないと思うんです。みんなが切磋琢磨して少しでもプログラミングのレベルを上げよう、と考えるのが本当の姿であって、みんなの足を引っ張り合って、レベルを下げようって言うのは、結局はやたら冗長な、保守のしずらいプロダクトを作る原因となり、自分達の首を絞めているだけのように思うのです。

でも、現実問題として、そうした初心者レベルのプログラマーをたくさん使って肥大化したコードを大量に生産していくほうが、たくさんお金がもらえるようになっている現在の仕組み=人月単価方式が、諸悪の根源なのかもしれません。

昨日は時間がとれず、ブログが書けませんでした。

今日のタイトルはFlashとJava Applet。昨日Yahoo!メールがFlashベースのインターフェースに切り替え、高速に動作できるようにするというニュースが流れていました。何でもAjaxよりも動作が速いのが売りだとか。ちなみに私はFlashなのに右クリックでコンテキストメニューが表示されるということにびっくりしました。そんなことできるんですね。これなら通常のアプリケーションのUIそのものが実現できますね。

これを見ていてふと思ったのが、そういえばなぜJava AppletはFlashにはなれなかったのだろう、ということ。WebでのJava Appletは当初、起動の遅さが嫌気され、あまり使われなくなったといういきさつがありますが、なぜFlashはあんなにも早く立ち上がり、Java Appletは遅いのか？　そんなに本質的に違うのだろうか？　本当はやればできたんじゃないの？と勘ぐってしまいます。

そして最終的にはアプローチの違いがここまで大きな差になったのだろうと思います。Flashは当初はぱらぱら漫画的な使い方がメインだったと思います。そこにちょっとアクションが定義できる、という感じ。デザインの工程がほとんどでプログラミングがあまり重要ではなかった、というのが、ボトムアップ的に火をつけることができた要因ではないでしょうか？

一方のJava Appletはプログラミングありき。これはトップダウン的なアプローチであり、敷居が高いです。Javaはそもそもプログラミング言語としてスタートしたこともあり、当然といえば当然ですが、もしJava AppletがFlashのような役割として勝ち残る戦略を目指していたら、どうなっていたのでしょうね？　おそらく今のJavaとは全然別のものになっていたのかもしれません。その戦略を追っていった場合にはサーバ側はJavaではない環境で動くことになっていたのでしょう。

でもそうはならなかった。Java Appletでの失敗はJavaにとっては実は良かったのかもしれません。

ちょっと前のブログのタイトル、SaaSモデルの安全性に似ているのですが、今日はリライアビリティ、日本語では「信頼性」の話です。

昨日、Amazonのオンラインストレージサービス「S3」で障害があったというニュースが流れていました。そのちょっと前の2月11日にはSalesforce.comの障害のニュースが流れていました。どちらもSaaSモデルの信頼性に疑問を投げかける内容のニュースです。

数日前の私の書いたブログ「NTTがNGNでSaaS?」で、bridgeさんから以下のようなコメントを頂きました。（こちらに転記させていただきます）

—
米国では「基幹系」「ミッションクリティカル」分野ではデータを預ける信頼性に欠けるためいまひとつ盛り上がりに欠け、セールスフォースドットコムのような基幹やミッションクリティカルじゃないアプリケーションが台頭しつつあります。
日本もそうなるのでは？
—

SaaSモデルが基幹系やミッションクリティカルな世界では使えないモデルだとしたら、非常に適用範囲の狭いモデルになってしまいます。可能であるならば基幹系やミッションクリティカルな世界もSaaSでいけるようにしたいものです。しかし現実問題として信頼度が十分でないとなると、上記のような話になってしまうことでしょう。

SaaSモデルが信頼性の面で疑問符がつきやすいのは、センター一箇所にデータが集まるモデルの場合、それがこけたり、途中の通信回線が不通になると、すべてダウンしてしまうということだと思います。Salesforce.comなどはセンターがダウンしたときに備えて大規模にお金をかけてデータセンターの二重化などを進めているようですが（いわゆるディザスタ・リカバリ、災対センター）、それでも（昨日のブログの話ではないですが）100%大丈夫ということはありえないわけです。

ただ一方で、通常自分のところでシステムを運用している場合と上記のような大手のSaaSベンダーに運用してもらう場合を比較したときに、実際どちらのほうがリライアビリティが高いのか、比較してみないとわからない、という部分もあると思います。正直なところ、自前で運用していても障害は発生しうるわけで、どちらのほうがより起こりにくく、かつ起こってもすぐに回復できるのか、という話だと思います。

先日SaaSの安全性に触れた中で、「経済産業省のほうからSaaS向けSLAガイドラインというのが公表された」という話を書きましたが、難しい側面はあるものの、SaaSをやっていく業界全体として、信頼性を数値で表し、それを保証していく、ということが求められるのでしょう。それと比較して、そのレベルでは耐えられない基幹系やミッションクリティカルなシステムは、自前でがんばって運用する、という話なのだと思います。

とはいっても、上記の信頼性の数値がどの程度信用のおけるものなのか、という話はありますけどね。（数字上はやたら安全に見える原発の話と同じことになるかもしれませんね）

最後に、長くなりましたが、crossnoteはどうか？　というのをちょっとだけ触れておきますと、crossnoteは最悪サーバーがダウンしていても、オフラインモードでドキュメントを参照したり、修正したりすることができます。Webを使わない、Eclipse RCPを使ったSaaSモデルなので、その分対障害性は高いんです。（ちょっと自慢）

最近、私の知っている小学校で、誤って個人情報が書かれた書類をそのまま捨ててしまっていて、問題になったという話しを聞きました。あまり詳しくは知りませんが、ちょっとした騒ぎだったようです。

これは個人情報保護法関連の話題ですが、この手のセキュリティ上の問題がニュースになることがここ最近増えたのではないでしょうか。昔はセキュリティに関して日本人はあまりに無防備すぎたと思いますが、今は逆にだいぶ過敏になってきているようにも思えます。そして行き過ぎると、完璧さを求められることになります。

セキュリティとは何らかのリスクに対して予防的な処置をとることです。リスクは広範囲に渡り存在します。それらを網羅的に、かつ効果的に予防することが求められます。ポイントは「効果的に」予防することであり、そうしたからといってリスクに完璧に除去することはできません。また完璧さを求めることは経済的にも意味を成さないことがほとんどです。

リスクにはいろんなリスクがあり、また予防方法にもいろいろな方法があります。絶対あってはならない生命に関わるリスクには最大限の対処を行うにせよ、そうではないリスクについては、発生しうる経済的な損失額と発生する確率を目安に、リスクの予防策に対してかけるべき額のバランスをとるべきです。そうすることで、本当にリスクが存在する部分がはっきりし、適切な対処が可能になってくるからです。

でも世の中には「絶対大丈夫なんだな？」って念押しされるケースがよくありますよね。絶対大丈夫なんてことは、普通存在しません。そこには何らかのリスクが存在しているはずです。「絶対大丈夫なんだな？」って聞いている側は、それでリスクを転嫁しているわけで、そういう聞き方をしている時点で非常に無責任なことをしているわけですが、単純に「絶対大丈夫です」なんて答える人がいたら、その人もかなり無責任だと思います。

では、「絶対大丈夫なんだな？」って念押しされたらどうするか？　おそらくリスク・マトリクスを用意して、各リスクに対してどのように対処するかを検討した結果を提示する、というのが教科書的な答えだと思います。

でも実際問題として、それでは納得してもらえない場合もあるでしょう。結局のところ、誰かにリスクを押しつけることができるまで、この問題は解決しないのです。言い換えると、リスクテイクができる人（金を握っている人とか、決定権のある人）だけが、「大丈夫です」と答えることができるのだと思います。

え、それでは自分にとっては何の解決にもならない？　あきらめましょう。 🙁

（2014/12 加筆）

通常、プロジェクトにはいろんな会社の人が集まります。協力会社やユーザ企業、コンサルタント、いろいろなバックグラウンドを持った人達の集まりです。そういった人達が一緒になって1つの仕事をしているわけですが、なぜか昼飯時になると「同じ会社」同士で飯を食べに行く、なんて傾向が強くありませんか？

もちろんそうではない人もいます。でも経験的に、一緒に飯を食べる相手に同じ会社の人を選ぶ傾向が強いと思いませんか？

飯を食べに行くだけの話ではなく、何かある毎に会社単位でまとまってしまう、というのは実はプロジェクトに対する所属という感覚があまり無いためではないでしょうか？　つまり所属とは会社に所属するものであって、プロジェクトに所属するものではない、という意識が自然に出来上がっている場合が多いように思えます。

しかしなんでプロジェクトではなく、会社なのでしょうか？　確かに社外秘の情報があるような場合には、同じ会社の人だけで、というのはわかりますが、普通に話しているときには同じ会社かそうでないかはあまり関係ありませんね。会社に所属しているという結びつきよりも、一緒に仕事をしている、という関係のほうがよっぽど強い関係のはずです。

会社というよりはプロジェクトに所属している、という感覚が出てくることがプロジェクトを成功させる上では重要ではないかと私は考えます。