update it, Inc.社長のブログ

ITPro Watcherにある田中克己さんの黒船の大砲がソフト業界に構造改革を迫るを読みました。今の日本のソフト産業がオーダーメイドによる開発ばかりで、同じようなシステムをあちこちで開発するというムダを続けてきたが、いずれ外国のソフト企業に市場を奪われたり、中国やインドのソフト企業に買収されてしまうのではないか、という話です。

確かに今の日本のソフト産業は世界的に見て、ほぼ内需だけで成り立っているという、かなり特殊な状況です。私も「黒船の大砲」がきたらひとたまりもないのではないか、と非常に危機感を覚えています。

この記事の中では自動車産業のように専門部品を作るソフト部品会社とシステムインテグレータと呼ぶシステム組み立て会社に分業化という「近代化」が必要だと説いているのですが、ちなみにこの記事に「ひがやすを」さんが噛み付いているようです。SIerが自動車産業をまねしようとするのはいい加減やめなさいによると、「ひがやすを」さんは真っ向から反論して、

–以下引用–
『SIにあてはめると、外部設計を作り続ける会社、内部設計を作り続ける会社、プログラムを作り続ける会社に分業化するってことでしょ。今と一緒ジャン。そして、インテグレータが上澄みをはねていくと。』
–ここまで–

と言っています。プログラムは「異なるもの」を製造することに意味があり、そういう観点からは同じような部品を作り続ける、というような製造業とは単純に対比できないわけで、これはこれでなるほど、です。

私はというと、上記の二人とはまた別の観点を持っています。ソフト業界の近代化というのは、ソフトウェアを「個別には作らない」方向に進むべきなのでは、ということです。オーダーメイドを減らしていくべきだ、と。前述のような議論が起きるのは、おそらく日本のソフト業界がオーダーメイドにどっぷり浸っているからで、ソフト業界はソフトウェアを作るのが仕事だ、となってしまっているからではないでしょうか？

私は、ソフト企業はこれからソフトをサービスするのが仕事、というように徐々に変わるべきではないのか？と思うのです。もちろん、真のサービスの部分は最高のものを作り上げ、改良し続けます。でもそれ以外の部分は、エンドユーザが使いやすいように組み合わせたり、ちょっとだけ手直しをするだけにして、極力個別には作らない。こうしていかないと海外の巨大なパッケージベンダーに勝てるわけがありません。

サービスする単位としては今までのパッケージという単位は当然のこととして、もっと細かい粒度でのサービスとして提供する、という方法も考えられるわけです。この世界では細かい粒度のサービスを提供する側も、けっして下請けではなく、全体のインテグレータと同等にサービスを提供する、という世界が考えられます。

ソフト企業は製造業からサービス業へ。このパラダイムシフトがないと日本のソフト産業は将来、簡単に乗っ取られてしまうのではないかと私は考えています。

CNET-JapanにEメールに関する興味深い記事が出ていました。「電子メールに未来はない」–米国のウェブ専門家らが指摘というタイトルで、Future of Web Apps（FOWA）カンファレンスで電子メールに関する議論において、出席者からメールはもはや時代遅れで、後進的で、誰もが嫌っている、という厳しい意見が相次いだ、と報告しています。

読んでみると、問題はやはり膨大な量の「スパムメール」に集約されるようです。でも一方で、記事の終わりのほうでは新興のWeb2.0系のメッセージング機能に関する不安についても触れています。

Eメールは非常にシンプルな仕組みだし、ビジネス的にも欠かせない道具だし、これだけ普及したということもあり、なかなかこれに代わるものが現れるとは私には思えないのですが、一方で既存のEメールに不満を持っているのも確かです。

というのは、送ったEメールが相手に届いているのかどうか、読んでもらえたのかどうかが怪しいと感じることが最近良くあるからです。スパム対策でフィルタリングしていることが多いと思いますが、送ったメールが誤ってフィルタリングされている場合もあるんじゃないの？　と疑心暗鬼になります。またスパム扱いされていなくても、大量のメールをやり取りしていると、見落としてしまうことも多々あるように思えます。

メールというのは基本的にはプッシュ型のコミュニケーションツールです。ところがプッシュ型が有効なのは、そこに表示される情報量が少ない場合で、膨大な量の情報がプッシュされた場合には役に立ちません。膨大な量の情報に対しては、プル型、つまり自分が関心のあるデータをピックアップするモデルでないと回らないのです。

メールで日ごろやり取りされるデータが膨大だったり、スパムメールに埋もれてしまっていたりすると、プッシュ型のツールだったメールをプル型として使わざるを得なくなり、結果として伝えるべき情報が伝わらない、という現象が起きるのではないかと思います。

メールの本来もっとも重要な点は、確実にプッシュできる、ということだと思います。メールの未来は、この「どうすれば重要な情報を確実にプッシュできるか」という点に絞って進化できるかどうかにかかっているのではないでしょうか？

金曜日にある勉強会に出ていたのですが、その会ではコーディング規約が守られないのを如何に守ってもらうか、という話をしていました。（趣旨としては「ある特定の条件において」なのですが、その話はいろいろあるので省きます）

そもそもコーディング規約は何のためにあるのでしょうか？　Sun Microsystems社のJava言語のコーディング規約の「コーディング規約の必要性」には以下のようなことが書いてあります。

— 以下、引用–
・ソフトウェアの生存期間におけるコストは、その80%が保守に費やされる。
・ソフトウェアの保守が最初から最後まで元の制作者によって行われることは、ほとんどない。
・コーディング規則は、エンジニアが新しく目にするコードをすばやく完全に理解できるようにして、ソフトウェアの可読性を向上させる。
・ソースコードをひとつの製品として出荷する場合、それがその他のすべての製品と同様にちゃんと梱包されていて、綺麗なものであることを確かめなければならない。
— ここまで —

つまり「ソースコードを誰にでも読みやすくするためのルール」がコーディング規約であるといえます。自分にとって読みやすいということではなく、誰にとっても読みやすいかどうか、です。

もし汚いコードを書いて、そのままにしてしまうと、それは当然、他の人にとって「読みにくい」コードであり、いわば負債を抱えた状態になります。後でそのコードに含まれたバグを取らなければならない人は非常に苦労することでしょう。

この考えからすると、独自のコーディングルールというのはこの精神からは外れたものだ、といえます。独自のコーディングルールは、そのルールに皆が慣れ親しんでいれば良いのですが、人材が動いたときにそのコーディングルールに慣れるまで余計な時間（＝コスト）が発生する、という問題があります。

C言語のように「何もない」場合にはいろいろと独自のルールを導入しなければならないかもしれませんが、JavaとかC#のような言語の場合、むしろできるだけ素な、元々の言語に用意されたコーディングルールをそのまま採用するというのが正しい戦略だと私は思います。

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にとっては実は良かったのかもしれません。