update it, Inc.社長のブログ

ナレッジマネージメントがブームだったころから、社内ネット上で情報共有をしたり意見交換するため仕組み（掲示板やネットニュースなど）が整備されてきています。最近ではWikiや社内ブログ、さらには社内SNSなどといった話も聞きますよね。もちろんうまくいっている、という話も聞くのですが、どちらかというとあまり活発ではない、とか、自然に消えちゃった、というあまりうまくいっていないという話を聞くほうが多いです。なぜでしょうか？

昔のナレッジマネージメントブームのときによく言われた反省点としては、そのような情報共有の場に載っている情報というのは、死んだ、役に立たない情報ばかりだという話でした。実際、当時はトップダウン的に情報共有の場が設定されたので、中のコンテンツの充実という部分がおざなりになりがちだったのでしょう。

最近のWikiや社内ブログ、社内SNSについてはむしろボトムアップ的に進められるので、そのようなコンテンツの問題については減ってきていると思うのですが、それでもあまり活発にならない理由のひとつとして、参加者が偏ってしまいやすいということがあると思います。社員の一部しか積極的に参加せず、ほとんどの人はROMレベルで、あまり見てもいない人もいる、という話を聞くことがあります。

おそらくこういったことが面白いと感じる人は積極的に参加してくれるのだと思うのですが、そう感じない人も多いのかもしれません。

もし、せっかくボトムアップ的に回りだしているのならば、例えばもっと経営層からコミットメントすべきではないでしょうか？　経営者自身がそこに1ユーザとして参加すべきだと思いますし、参加することのメリットをより明確に伝えるべきだと思います。

うまく使えば会社の社風とか文化を作るうえでの重要な仕組みになりうるものだと私は考えます。ぜひうまく「使って」いきましょう。

日経のITProに「御意見募集、“Excelレガシー”への対処法」というのが載っていました。EUC(End User Computing)で作られたExcelマクロの数々が、内部統制に注目された今、ブラックボックス化して問題になっている、という話です。実際、情報システム部門が管理しなければならなくなったが、いまさらどうしよう、という感じで困っているところも多いのだと思います。

もともとEUCというのは情報システム部門がバックログを一杯抱えて現場のニーズにこたえきれないために始まった、という面もあると思うのです。それなのに今になってやっぱり情報システム部門が面倒見て、というのは正直つらいところでしょう。

そもそもスクリプトとかマクロといったものは、現場の「ちょっとした」ニーズにこたえるためのもので、恒久的に利用されることまでは想定していないもののはずです。でも一旦それが現場で回りだすと、それが「システム」化してしまいます。そしてやっかいなのが、通常そういったEUC的に作られたシステムというのは十分にテストや検証が行われておらず、拡張性にも欠けるということだと思います。

今まで作られてきたそういったツールについても、「システム」化したものについてはもうちょっときちんとしたテストを実施すべきなのだと思います。私はEUCそのものは悪いことだとは思っていません。すべてを情報システム部門でやるのは無理な話です。簡単にExcelでできることであればそうすべきでしょう。ただし、定型的な業務の中でExcelマクロを利用する場合には、ある一定のテストプロセスを経た上でなければ利用できない、などの規定が必要なのではないかと考えます。

最近ちょっと下火になってきた感はありますが、一時、MDA（モデル駆動型アーキテクチャ）というのが盛んに提唱された時期がありました。これはOMG (Object Management Group)が提唱したソフトウェアの設計手法で、一言で言えば（乱暴ですが）アーキテクチャ非依存のモデルを書いてしまえばどのアーキテクチャにも変換して対応できるようにするよ、という方法です。モデルを書いておまじないをすると、アーラ不思議、システムが自動的にできあがり！ってことです。（いや、もちろんそんなことはないですが）

ここまで聞くとすごいいいもののように聞こえますが、私はこの手の技術には非常に懐疑的です。理由はひとつ。メリットが見えない。そんな回り道をして何が得たいのか？ということです。もっと具体的にいうと、以下のようなことになります。

１．アーキテクチャ中立を叫んでいるが、Javaで実現していること（OSに依存しないプログラミング環境）で十分なのではないか？　ということ。

２．モデルを作って枠を自動生成し、それに実装を入れていくという方法は美しいが、それだけでは詳細設計やコーディングの工程が自動化されることはないだろうということ。（そこまで自動化するためには、結局モデル上で一生懸命実装する羽目になる）

３．MDAの仕組み上の制約によってかえって実装が難しくなる場合があること。特にモデルと実装を分離しなければならないがために、簡単にできるはずのことが簡単にはできなくなったりする場合があること。

４．そもそも実装からかけ離れて定義された枠に縛られて、トンでもないプログラミングを強いられるプログラマーがかわいそうだということ。モデルを設計する人の知恵がプログラマーの知恵をいつも上回っていて、モデルの設計結果がいつも完全だ、なんて保障はどこにあるのでしょうか。極めてウォーターフォール的な香りのする発想だと思います。

この手の方法がうまくいかないことは大昔のCASEツールのときの失敗（言い過ぎか？）で明らかだと思うのですが、懲りていないというか、歴史に学ばない人が多いということなのでしょうね。

システム導入の検討事項としてもっとも端的に、かつ最重要といわれることに費用対効果があります。システム導入にかかる費用と、その結果得られるベネフィットをそれぞれ金額換算するわけですが、事務作業の合理化のためのシステムならば比較的スムーズに金額換算ができるものの、ナレッジ系のシステムとかCRMとか、世の中には効果を金額換算するのが難しいシステムも多々あります。

そういったシステムの場合、それを提供しているベンダーが出した費用対効果の数字にどれだけ信憑性があるか、という問題があります。第三者機関が学究的・客観的に算出したというのならばいざ知らず、一見第三者機関に見えるものの、そのベンダーが金を出していたりなど、とても信用できないケースもあるからです。そしてIT系のコンサルティング・ファームが出した数字を鵜呑みにして導入したのに、蓋を開けてみたらさっぱり違っていた、なんていうユーザ企業側の話も良く聞きます。

システムを導入するとかなり効果があるのはわかっている、でもその導入の効果と対象事業から得られる利益との相関関係を説明できない。このようなケースではそもそも費用対効果という単純化した金額に換算することがナンセンスなのかもしれません。

言い換えると、費用対効果では信憑性のある数字が得られないものでもそれっぽく費用対効果を算出しなければならない、というプロセスに問題があるのだと思います。つまり「システムを導入するときには費用対効果は算出するものだと決まっている」ことが問題だと思うのです。

金額換算が難しいとしても、システム導入の効果は、金額以外の要因については客観性をもって表現できる場合があります。怪しげな金額を信じるよりはむしろ、客観的に正しいと考えられる事柄を判断基準として採用したほうが、より正しい結論が導き出せるのではないでしょうか？

でも、これだけでは「よーし、良くなるのはわかった。でも導入すべきかどうかはわからん」という結果になります。つまり金額とは異なる判断基準の軸が必要だということになります。

もし企業がKPI (Key Performance Indicator)を定めていれば、それに照らし合わせるというのが筋だと思います。じゃあそれがない企業ではどうすべきか？　うーん、今後の課題ですね。

最近、学生の就職先として情報系（IT系）の企業の人気が下がっているという話を聞きます。へー、そうなの？程度の軽い気持ちで聞いていたのですが、良く良く考えてみると由々しき事態なのですね。

先日、京都大学出身の人と食事をしたのですが、その人が言うには今現在、京大の工学部で一番不人気なのが情報だ、と話していました。私が大学生のころは情報工学というのはある種憧れの分野だったと思うのですが、その話を聞いて時代の変遷を感じてしまいました。

やはり新３K（きつい・厳しい・帰れない）のイメージが一般にまで定着してしまったということの裏返しなのでしょうか？　昔は最先端の技術でよくわからない、何が神秘的で遠い存在だったコンピュータが、いまや非常に身近な、コモディティ的な存在に変わってしまったこともあるのかもしれません。

新３Kの汚名返上のためにはどうすべきか。やっぱり「そう（＝きつい・厳しい・帰れない）ではない」ように、この業界を変えていくしかないのだと思います。でも、世の中には同じか、それ以上にきつく、厳しく、帰れない業種にも関わらず、こういったことがささやかれない業種も存在します。たとえ「きつい・厳しい・帰れない」であったとしても、やっていることが楽しくやりがいのある仕事だと感じられるのであれば、そんなにネガティブなイメージにはならないと思いますし、ネガティブに伝える人も減るのではないかと思うのです。

要は仕事に対してどれだけやりがいが感じられるか、ということにかかっているのだと私は思っています。他の業界に比べれば確かにちょっとはきつくて厳しくて、残業も多めかもしれない、だけどやりがいのあるすばらしい仕事だよ、って紹介できるように変えていきたいと私は思います。

皆さんはアプリケーションが使いにくくてイラついたことはありませんか？　私は根が短気なのか、よくあります。つい先日も会社で使っている、あるバックアップソフトのあまりにもの使い難さに腹を立ててブーブー言っていました。

その時に腹を立てていた理由は、こんなことでした。

１．単純なことをインスタントにやる方法がない。（すべての処理について一旦ウィザードを使ってタスクを生成し、その後で実行する形になっている）
２．処理をしている間のリアルタイムのフィードバックがわかりずらい。
３．エラーが発生したときに、正しいエラー原因が提示されない。
４．処理が失敗しているときに、ログを見てもなんだかよくわからない。

おそらく作る側は、バックアップの日々の運用の自動化を第一の目的として作っているので、１．については仕方ないのかな、とは思うのですが、ちょっとテープのVerifyがしたいな、と思った程度のことでもいちいち同じ手順を踏まなければならない、ということでまずちょっとイラつきました。

次に２．ですが、一応リアルタイムのフィードバックはあるのですが、起動した処理との関連がわかりずらい。この「わかりずらさ」でさらに　イラつき度++（インクリメント）されました。

で、３．ですが、処理が失敗すると画面上に赤いエラーという文字が点滅するのでエラーであるのがわかるのですが、このエラーの原因がおそらく見当違いなエラーメッセージになっているのです。昔、MS Officeで「メモリーが足りません」というエラーメッセージが頻発したときに、知人から実際にメモリーを増設してみたのだけどだめだった、という話を聞いたことがあるのですが、まあそんな感じの話です。エラーが発生しているときに見当違いの原因を提示されると、イラつき度 *= 10（10倍して代入）ぐらいになります。

最後に４．のログを見てもわけがわからん（そもそも失敗していることがでていない、結果には「完了」と出ている、など）に至って、ついに throw new IraIraException() したわけです。

まあ、「またひとつ勉強させてもらった」と考えれば良いのかもしれません。こういった一つ一つのことを反面教師として捉えて、自分が作るシステムがそうならないようにしていきたいと思いました。

最近よく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やハードウェアに対応するには、教育コストも余計にかかることになりますが、それを加味してでも将来の技術標準に対するリスクヘッジという観点で十分にペイできるのではないか、と私は考えます。

もし顧客から、まだ内容が明確になっていない新しいシステムについての概算見積もりが欲しいといわれたら、あなたはどうしますか？　リスクを回避するために、システムの設計フェーズと実装フェーズを分けて、最初はシステムの設計フェーズのみを確定金額で受注し、実装フェーズは別途見積もりを行う、というのが教科書的な答えになるのですが、問題なのは上記のような手続きになるにせよ、顧客側では最初の概算見積もりに基づいてシステムに必要な予算を立てるため、結局その最初の概算見積もりが上限になってしまうことが多い、ということです。私も今までなんども、これで痛い目にあってきました。

概算見積もりの難しさの主因は、情報の少なさにあります。見積もり精度の良い手法というのがいろいろと編み出されていますが、結局その手の手法は何を作るのかがかなり具体化していないと適用できないものがほとんどで、概算見積もりが必要な段階では用を成さない場合がほとんどです。何を作るのかが確定していないのに正確な見積もりなどできるわけがありません。以前、概算見積もりの段階でソースコードの行数をベースに費用を見積もったベンダーを見たことがあるのですが、その思い切りの良さにある意味すげーっ（褒めたわけではないですよ）と思いました。

知人のプロジェクトマネージャの話では、「いろいろ考えて積み上げて算出した数字を、最後に3倍する」と答えてくれました。この最後の3倍というのが味噌で、そうすると経験的に収支トントンになる場合が多い、ということです。最後の倍率は状況によってはいろいろ異なるのかもしれませんが、少なくとも概算時に積み上げた数字というのは、まだ内容が見えてない分、大きな穴が開いている場合が多いので、かなり余裕度を見ておかないと痛い目に合うよ、ということを物語っているのだと思います。