update it, Inc.社長のブログ

昨日、関東甲信地方が梅雨入りしたと気象庁から発表があったようですが、今日は（今のところ）横浜地方、おもいっきり晴れてますね。

公園のアジサイがきれいです。

最近よくSaaS(Software as a Service)という単語を聞くようになりました。基本的には昔のASPという単語の焼き直しなのですが、そのときは騒がれた割に掛け声倒れで終わってしまったためにあまり良い印象がありません。そういうこともあって新しい言葉が造語された、ということもあるのでしょう。もちろん「SaaSとASPではここが違う」とか説明がありますが、本質的な部分は一緒だと思います。ただし社会基盤として高速で安価なネットワークが完備されたことで、ASPのときの失敗の大きな原因が取り除かれているといえるでしょう。

私は、このSaaSは単なるブームではなく、勝ち残るシステム提供会社が進む道だと考えています。SaaSの世界ではシステム開発会社ではなく、システム提供会社となります。この「開発」から「提供」へ変われるか変われないかが、大きな分岐点であり、勝者と敗者の分かれ目になると考えています。

今までシステムを開発することを生業としてきた会社は、基盤的なものを提供する一部の会社を除いて、システム提供会社の下請けに甘んずるか、どんどん狭くなる市場から徐々に淘汰されるか、システム提供会社の提供するサービスに対するコンサルティングで食べていくか、それらのいずれかになっていくのではないかと私は予測します。

そうなるとすると、百貨店的な分野を問わないシステム開発を手がけているベンダーよりも、ブティック的に、ごく専門的な特定の分野についてのシステム開発に強いベンダーのほうが有利になるのかもしれません。というのは、どのようなシステムを提供すべきかがわかっているからです。

以前のブログでも書きましたが、これこそが「製造業」から「サービス業」への転換です。さて、日本のシステム開発会社の中で、どれくらいの会社がこの流れについてこれるのでしょうか？

皆さんはシステムテストを行うときのテストデータはどうやって準備していますか？　全パターンデータを手作りという場合もあるかもしれませんが、むしろ本番データを活用することのほうが多いかもしれません。個人情報などの部分をマスキングした上で本番データを一部コピーしてシステムテストに利用するというのは比較的よくやる話だと思います。

本番データをシステム・テストデータに使う場合、一番問題になるのはテストパターンのカバレッジに関する部分ではないでしょうか？　つまりテストしたいパターンについて十分なカバレッジをもったデータの場合にはそれをそのまま使えばよいわけですが、本番データだけではテストしたいパターンを網羅できていない場合も多いと思います。そのような場合にはなんらかの形で人工的にパターンデータを作り出す必要がでてきます。

場合によってはテストデータを作るためのツールやプログラムの別途開発が必要なこともあるかもしれません。そのためには工数もかかります。いざテストという工程になってからでは間に合いません。

つまり、システムテストへの準備はシステムテスト工程になってからでは遅い、ということです。システム開発と同時にシステムテストに向けたデータ準備を忘れずに。

でも、九州のほうではそろそろ入梅しそうだとのこと。横浜もこの天気は今日まででしょうか？

5月末にかけて、NTT東（西）日本のIP電話サービス「ひかり電話」関連の障害のニュースが続きました。5月23日に起きたのは東西間接続装置のハードディスク交換時に作業ミスで誤ったコマンドを送信したのがきっかけで東西間の通話が普通になったという件。一方5月30日には、ルーターのソフトウェアのバージョンアップに絡んで、着信できなくなる障害が発生した、という報道がありました。

この２つのトラブルは、もちろん直接的には別々の原因から起こっており、たまたまトラブルが続いた、ということだと思うのですが、システム屋の観点から気になったことを書いてみたいと思います。それは、こういったトラブルから何を学ぶか、ということです。

私が一番気になったのは検証環境での事前テストはやったのだろうか、という点です。システムにはバグがつき物です。新しいものを入れたときにトラブルが発生するというのは良くある話です。トラブルの原因は個別にいろいろあって、完璧にトラブルはなくすスペシャルな方法はないと思いますが、本番適用の前に、事前にトラブルを検知することは、ある程度できるはずです。つまり検証環境を用意して、そこで「事前にチェック」することで、本番でのトラブルを回避できたかもしれない、という点です。

検証環境は本番環境そのものではないので、必ずしもすべてのトラブルをあぶりだせるわけではありません。しかし、できるだけ本番環境に近い状況を擬似的に作り出したり、場合によっては本番環境以上に厳しい状況を人工的に作り出すことによって、どんなことが起こるのかを事前に確認することができます。

検証環境においてテストをシステマティックに回すというのも、高度なノウハウが要求される分野です。ただ単に検証環境で動かせばいいというものではありません。トラブルをあぶりだすには、総合的なチェックにとどまらず、やばそうな部分を予め抽出しておいて、その部分については重点的にチェック（ストレステストなど）するということも必要になります。

トラブルを繰り返さないためには何をすべきか。常に考えていきたいと思います。

初夏ですね。というか、今日は真夏ですね。

エンタープライズ・アーキテクチャ（Enterprise Architecture、以下EA）が叫ばれるようになって久しいですが、あなたのところでもEAしていますか？　ユーザにとってメリットが大きいはずのEAですが、正直なところ、（ちょっと不謹慎ですが）システムを作る側からすると邪魔に思える存在だったりします。それはEAは技術の標準化を求めるものであり、技術革新とは相容れない要素があるからだと思います。今回の案件にはこの技術がぴったりのはずなのに、EAから外れるから使えない！　なんて経験、ありませんか？

私が一般に言われるところのEAについて疑問に感じているのは、果たしてドックイヤーと呼ばれるシステムの世界において、技術革新を無視して社内標準を採用し続けることが正しい戦略なのか、という点です。もちろん何でもかんでも新しいものに飛びつけ、と言っているのではありません。しかし適切に技術評価を行ったものであれば、むしろ積極的に新しい優れた技術を採用したほうが長期的には正しい戦略ではないのか、と思うのです。

EAの中でも、例えばデータモデル、コード体系の統合やアプリケーション間のインターフェースの共通化などはぜひ進めるべき課題だと思うのですが、一方、運用管理コストの低減という観点で、対象のハードウェアやOS、ミドルウェアに縛りを付けてしまうというのはいかがなものかと思います。もちろんあまりにバラエティーに富みすぎては管理できなくなってしまいますが、単一のハードウェア、OS、ミドルウェアに統一した場合の、システム・ポートフォリオのライフサイクル全体にかかるコスト・効果と、２，３のハードウェア、OS、ミドルウェアに分散「投資」するコスト・効果を比較した場合、むしろ後者のほうが優れている場合が多いのではないかと私は思うのです。

今の運用管理者では管理できないから、という理由で実現できていないとすると、厳しい言い方をすれば、それはその運用管理者をただ甘やかしているだけにしか思えません。もちろん新しいOSやハードウェアに対応するには、教育コストも余計にかかることになりますが、それを加味してでも将来の技術標準に対するリスクヘッジという観点で十分にペイできるのではないか、と私は考えます。

会社の隣がケーキ屋なんですが、その前で犬がお行儀良くご主人を待っていました。

年金記録漏れの問題が世間を騒がせています。年金記録5000万件が過去のシステム切り替え時などでうまくリンクがとれずに宙に浮いたままになっている件です。この件でＣＳＫホールディングスの有賀貞一さんがNIKKEI NETのIT+PLUSに寄稿している記事業務・システムの視点が欠落した「年金記録漏れ」問題の与野党議論を読み、大変面白いとおもいました。

「いかに政治家や官僚が社会インフラである情報システムと、それにまつわる業務処理に無知であるかが明解になった」
さすがシステムの専門家だけあって、業務的な観点、システム的な観点、コスト的な観点から、今回の決定が如何に「何も考えずに」行われているかを指摘しています。

読んでいて感じたのは、著者の有賀さんは「政治家や官僚」に特有なこととして指摘しているのですが、果たしてそうなんだろうか？　という点です。実はシステムの開発に絡んで世間一般によるある話ではないだろうか？と思ったからです。

つまり業務的な観点やシステム的な制約事項などが考慮されずに先に予算や期限ありきで物事が決まってしまって、あとからシステム担当者がそれにあわせるために四苦八苦、というのは良く聞く話だからです。もちろん今回の決定は1年という短い期間に区切ることにより、不安感を払拭するという戦略的な意味があるのは間違いなく、戦略を重視してそれにあわせて現実を変えていくという考え方そのものは正しいと思います。これは一般の企業でも同じような話であり、先に予算が決まるのも、対象の業務に対する投資対効果をベースに枠を決めていると考えれば正しい行動だといえます。

ただし問題なのは、いくらそれが戦略だとしても裏付けのないまま事を運んだ場合のリスクを考えていないことにあるでしょう。一年以内の突合を公言したために、期限を守ることが絶対条件になってしまった、と考えると、この後、悲喜こもごもとしたことがいっぱい起きそうだな、と勝手に想像してしまいました。

プロジェクトマネージャの重要な業務のひとつとして、プロジェクトメンバに対する評価があります。これは単にそのメンバへの支払いを決めるということではなく（そもそも普通のプロジェクトマネージャの場合、そこまで権限をもっていないことが多いですね）、プロジェクトメンバのやる気を高めるための1手段として評価を行うという側面が多いのではないでしょうか。

あるプロジェクトマネージャの人から聞いたのですが、その人はできるだけプロジェクトメンバーが日常で話した、何を目指しているのかとか、どんなことがしたいとか、そんなことををノートなどに記録するようにしているそうです。そして評価のフィードバックのときなどで、以前こんなことを言っていたけど、こうだったね、みたいに伝えてあげるようにしているそうです。

プロジェクトメンバからすると、ああ、この人は私のことをちゃんと見ていてくれているのだな、と感じることになります。この『見守っているよ』感がうまく伝えられればチーム運営上、大きなアドバンテージとなるに違いありません。プロジェクトマネージャからはプロジェクトメンバは1対多の関係なのですが、プロジェクトメンバからみれば1対1の関係だと考えてあげることが重要なのだと思いました。