update it, Inc.社長のブログ

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

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

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

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

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

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

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

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

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

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

昨日のIT Mediaで「発注者ビューガイドライン」が紹介されていました。「システムの作り直しをなくしたい」――SIer9社がガイドライン公開

まだ全部を読んではいませんが、なかなかの力作です。というか分量がかなり多いです。想定する読み手が

■ 情報システム開発を請け負う側である、SIベンダの従事者

■ 情報システム開発を発注する側である、ユーザ企業の情報システム部門、および業務部門の各ユーザ

となっているのですが、SIベンダの従事者はわかるとして、ユーザ企業側の特に業務部門の各ユーザがこれを見て、果たして分かるかなぁ？　という感じがしました。

おそらく書いてある内容が、SIベンダの視点で書かれているからだと思います。実際外部仕様書を書くベンダ側という観点では、気をつけるべきチェックポイントがいろいろと具体的に書いてあり、とても良い資料のように思えます。でも発注者側の、特に業務部門のユーザがここに書いていることをきちんと理解できるまでにはだいぶ時間がかかるように思えますし、もし理解した暁には十分システムの上流工程設計で飯を食っていけるようなレベルになっているようにも思えます。

とはいえ、きちっとやりたいと考えているユーザにとっては（どの程度いるのかはわかりませんが）なかなか良い資料なのかもしれませんね。

昨日のブログ東証のトラブルは取引集中のため？で「原因が同じ証券会社からの複数銘柄の一括注文（バスケット取引）が短時間に集中し、あらかじめ設定していた注文処理の制限回数を超えたことによるものだったと東証が発表しているようです」と書いたのですが、タイトルにも？を入れていたように、どうも変な説明だと思っていたら、やっぱりちょっと違うようで、書き込みロックのリトライ回数の制限回数を超えたために処理を停止した、ということのようです。

ただ、この説明のニュースで、「デッドロック」のためにという説明がされているのを見つけたのですが、上記の話であれば、これはいわゆるデッドロックではないのでは？と思うのですが、どうなのでしょう？

デッドロックは2つの処理間で互いに依存関係があり、互いに相手のロックの解放待ちになった状態を指します。一度この状態になると、デッドロック監視の仕組みが強制的に処理を止めたり、タイムアウトを発生させてデッドロックを解消させることになるはずです。ニュースの説明では、「登録の再試行を繰り返し、それが設定数の100回を超えたので『デッドロック』した」、と書いてあったのですが、本来デットロックに陥った場合には試行回数をいくら増やしてもロックは開放されません。ある意味、もしこれが本当に設定回数でロックを開放しているのだとしたら、それは本来のデットロックを開放する仕組みとしては正しい動きをしていることになります。

つまり、もし本当にデッドロックが発生したとすると、おそらく設定が問題なのではなく、デッドロックが発生するアルゴリズムに問題があった、ということになるはずです。ところが「東証は、登録の再試行の回数を無制限に変更するなどしてシステムを修復」と報じられているところをみると、アルゴリズムの問題ではなく、単に想定外の大量処理によりI/O待ちが長くなり、リトライ回数が足りなくて処理が停止した、というのが真相のようで、そうだとするとやっぱりデッドロックじゃないんじゃない？と思うんです。

ま、重箱の隅をつつくような話ですね。

昨日、東京証券取引所で株式売買システムの障害で2銘柄の午前の売買を停止したというニュースが流れていましたが、その原因が同じ証券会社からの複数銘柄の一括注文（バスケット取引）が短時間に集中し、あらかじめ設定していた注文処理の制限回数を超えたことによるものだったと東証が発表しているようです。

システムに処理する上限があるのは仕方がないのですが、設定数を超えた場合に停止するという設計はいかがなものでしょうか？　処理上限を超えた量の場合には遅延が発生します、という設計にすべきだったのでは？と思うのは私だけ？

この辺りは要求仕様レベルで予め決めておくべき事項だと思うのですが、もし検討された結果、処理上限を上回った際には止める、という決定をしていたとしたら、？な感じがします。

むしろ要求仕様レベルでは明記されていなかったので、システム開発側で「気を利かせて」そのような制限を付けた？ということも考えられなくはないですが…

しかしこの手のシビアなシステムの場合、要件定義（特に非機能要件）が非常に難しいですね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ちょっと前のブログのタイトル、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面に「ITシステム　ネットで提供　NTT、次世代網で」「安全性高く　企業向け年内参入」という記事がでかでかとでています。

「ITシステム　ネットで提供」とあるのは言わずもがなSaaSのことです。NTTではSaaSを事業として開始し、サーバーを置くデータセンターや認証・決済機能を整備するとのこと。国内外のソフト会社に呼びかけて…云々と書いてあります。NTTが乗り出すということであれば、SaaSの時代に一気に突入しそうですね。

ただちょっと解せなかったのが、なぜNGN（次世代網）でなければならないのか？という点です。まあ戦略上はわかりますが、NGNの場合、どこでも使えるというユキビタス性が確保できるのはいつになるのでしょうか？　また海外とのやり取りには使いにくい？　結局はインターネット経由になる？　疑問は尽きません。

昨日、車輪の再発明というブログを書きましたが、果たしてNGNは車輪なのでしょうか？　キャタピラなのでしょうか？
いずれにせよ非常に気になるニュースでした。