update it, Inc.社長のブログ

最近会社のWindows XPのPCがだんだん遅くなってきました。どう考えても買った当初と比較して目に見えて遅くなっていると思います。特に起動時がひどいのです。

ディスクのデフラグなどをしてみたり、要らないファイルを消してみたり、さらにはアンチウイルスソフトを入れ替えてみたり、いろいろ試してみたのですが、一向に戻りません。もしや変なウイルスにやられてはいないかと心配になり、Windowsのプロセスをチェックしているうちに、wuauclt.exeというプロセスがやたら太っていることに気付きました。

？と思い、ググってみたところ、ありました。

wuauclt.exe って何?

試してみると、明らかに起動スピードが違います。なるほどね。

（試される方はOwn Riskでどうぞ）

日本のシステム開発というのは建設業に例えられることが多く、開発体制においてゼネコンにあたる元請けから協力会社またはパートナーと呼ばれる下請、さらにその孫請け…という構造になっています。元請けの会社は全体を取り仕切り、開発においては現場監督となるわけです。

昨日ある方と話をしている際に、最近元請けに相当する会社が利益優先で物事を考えるところが増え、どんどん下請けへの丸投げ構造がひどくなっているということを聞きました。効率化を追求するあまり、中身をまったくチェックしないままスルーされていることがままある、ということなのです。

現場監督の話でいえば、建設を知らない人が現場監督をしている、という話になります。建物の中身は建設現場で働く下請けに人に全部任せて、ろくなチェックもせずにそのまま客に引き渡してしまう、ということです。

問題なのは、元請けで現場監督をしている人たちがシステム設計に関する教育を十分に受けていないということ、そしてシステム開発の経験が十分でないまま、いきなり「現場監督」をさせられているということでしょう。

建築の世界では耐震強度をごまかした偽装設計が世間を騒がせ、大きな問題になりましたが、システム開発の世界でも上記のような状況が進行しているとすると、由々しき問題です。最近はシステムのトラブルが原因で実際に会社が傾くような大問題となるケースも良く聞くようになりました。対岸の火事と思わずに早急に手を打っていかないと、いずれ大変なことが起きるかもしれません。

システムがうまく機能しない大きな原因の１つに、非機能要件が満たされていないことがあります。機能要件についてはやらなければならないことが明確なので、きちんと合致していることを検証するのは比較的容易ですが、非機能要件については定義そのものがぼんやりとしている場合が多く、どこまでやれば満たされていると判断できるのかが釈然としない場合が多いのではないでしょうか？

非機能要件の例としては、こんな項目があります。
・性能要件
・キャパシティ要件
・移行要件
・運用要件
・障害対策要件
・セキュリティ要件

「非機能要件については定義そのものがぼんやりとしている」と書いたのですが、これは非機能要件は「?できる状態」をあらわしているものだからではないかと思います。システム全体に渡って定義された状態を満たしていることを検証しなければならないわけですが、「状態」を満たしていることをシステムの外部から見て確信できるようにする、なんてことはなかなか難しいものです。

少し前に、大規模ＥＣサイトのリニューアル後に大規模な障害が発生したという件がネット上で話題になっていましたが、これなども一言でいえば、性能要件とかキャパシティ要件といった非機能要件に問題があったと言えます。それらがきちんと検証されていたかどうかは知る由もないのですが、もし当事者となって考えた場合、じゃあ実際問題、どうやって本番運用前の段階で問題が発生しないことを検証するのか？　というのはかなり難しい問題だと思いませんか？

こういった問題に対処できるのは、似たような環境で多くの事例・経験を積んだ組織ということになるのだと思います。これこそシステム開発の本来のノウハウといえる部分ではないでしょうか？

ITProに叱るより真因を追究、対策べからず集という記事が載っていますが、非常に良い内容です。ミスをした時に対する一般的な行動に対し、実はそれでは効果が出ないよ（場合によっては逆効果ですらある）というのを7項目にまとめて説明しています。

中でもこれは良いな、と思った項目は以下のようなものです。
（7項目中の4項目。コメントは私の独自の解釈です）

—-
×　ミスをしかる、罰する
○　ミスしない人をほめる
—-
ミスをしない人はいません。この当たり前の事実が、事実として受け入れられない人もいます。その場合、ミスをしかり、罰するという方向でしか考えられなくなってしまいますが、誰でもミスをするという事実を前提に考えると、ミスしない人をほめたほうがチームのやり気を増し、明らかに理にかなっています。

—-
×　恥ずかしいから隠す
○　積極的に全社公開
—-
これも上記と同じように、誰でもミスをする、という前提で考えれば、積極的に公開して他の人が同じミスをしないようにするのが賢いやり方です。

—-
×　ルールで縛る
○　絶対守れる最小限に抑える
—-
以前このブログで「シンプルなプロセス」ということを書いたことがありますが、とにかくみんながきちんと実行できることが重要です。たくさんのルールが満載されていても、ルールにがんじがらめになって結局有効に機能しなくなってしまいます。必要最低限に抑えて、みんながきちんと守れるようにすることのほうが実効性が高いと言えます。

—-
×　「チェック強化」で終わり
○　仕組みを見直す
—-
これが特に重要ですね。チェック強化と叫ぶのは簡単ですが、具体的な方法がありません。精神論だけで終わってしまい、現場の感じが悪くなる以外は特に得るところはありません。本当に改善するには「仕組みを見直す」のが最善の方法といえます。

昨日ズィット社の「SaaSの現状とPaaS環境でのソフト開発・適用について」というセミナーに参加してきました。まだあまり詳しくない人が現状についての概略をつかむにはとても良いセミナーだったと思います。

私は今までこのブログでPaaSはあまり取り上げてこなかったのですが、今回のセミナーで注目するきっかけを得ました。PaaS(Platform as a Service)とは、SaaS(Service as a Service)がいわば完成品としてのサービスの提供なのに対し、PaaSは未完成品の”Kit”としての提供だと考えるとわかりやすいと思います。

PaaSは活用の仕方によって、独自社内システム開発のために用いることもできますし、PaaSを使って完成させたアプリケーションをSaaSとして提供することも考えられます。

ちなみにPaaSとはSalesforce.comの造語なのでしょうか？　マイクロソフトなどでは最近Software plus Serviceなるものを推していますが、コンセプトは異なるものの、狙っているターゲット（企業内で利用するシステムのネットワーク・サービス化）が重なっているように思えます。

昨日のセミナーを聞いていてPaaSが少し厳しいと感じた点は、PaaSを選択するとそのPaaS独自の環境（データベースやコンポーネントなど）に取り込まれてしまい、他の環境へ移ることが難しいという点です。PaaS上でアプリケーションの展開をする場合、ある意味PaaS提供ベンダーというお釈迦様の手のひらの上でビジネスを行うことになります。このリスクをどう考えるかが１つのポイントといえそうです。

約1年前に、SaaSについて私のブログでこんなことを書いていました。

■ 技術者の立場から見たSaaS（および技術者の立場から見たSaaSその２）
■経営者の立場からみたSaaS

今回はその第3弾（1年ぶり…）として、ユーザの立場から見たSaaSというテーマを考えてみたいと思います。

ユーザから見たときのSaaSならではのメリットは、実は上記の２つでも同じことを言っているのですが、「継続的な改善」にあると思っています。

一般に、SaaSモデルでは継続的に行われるバージョンアップについて、特別な料金を取ることなしに最新のバージョンが利用できるようになっていると思います。勝手にどんどん機能向上していくということです。継続的に改善が行われていれば、システムが陳腐化するリスクが比較的小さいといえます。

パッケージ型の場合には導入した以降、期間がたつと必ずシステムが陳腐化してきて、いずれ新しいバージョンを導入するか、乗り換えるか、という話になります。この場合、新しいバージョンへの入れ替えにしたとしても、カスタマイズ部分の作りかえやテストなど、それなりのコストと期間を要します。このためになかなかバージョンアップができずに、導入してしばらくたった現在、塩漬け状態になっているというケースも多いのではないでしょうか？

SaaSを導入するという理由はもちろんこれだけではありません。他にも例えば
(1) ハードウェアなどを購入する必要がないこと
(2) 運用を自前で行う必要がないこと
(3) ソフトウェア費を経費化できること
など様々なメリットが考えられます。ただ(1)や(2)についてはアウトソーシングと言った観点でのメリットであり、(3)もリースにすれば同等の効果が得られるなど、必ずしもSaaSでなければ実現できない、というものではないです。しかしこういったメリットも含めて一括で恩恵を受けることができるというのは、やはりすぐれた方式であるといえると思います。

上記に加え、さらにシステムの陳腐化をできるだけ抑えるという観点でSaaS導入を考えるという時代がいずれ来るものと、私は考えています。

このブログ、さっそくGoogle Chromeを使って書いてみているのですが、とにかく軽い！　早い！　ちょっと感動的なほどです。今までFireFoxを使ってきたのですが、これは乗り換えたくなりました。

ユーザーI/Fもシンプルなんだけど、かなり使いやすくデザインされています。デフォルトでよくアクセスするページがホームページになっているのも使いやすいと思います。ページ表示なども概ね問題ないと思います。

１つ気づいたこととして、Flashは表示できるのですが、Java Appletはだめのようですね。（なにか設定すると動くのかもしれませんが）　企業用のアプリケーションではJava Appletを使っている場合が結構あるので、できれば対応してほしいところです。（これはSunにいうべきことなのか？）

### 訂正 2008/9/8 ####
Java AppletもJRE 6.0のUpdate 10（ただし今現在はまだRC版のようです）に切り替えると使えるようになるようです。Update 10からはJava Appletが別プロセスで動くようになるなど、だいぶ大きく変わるようで、Google Chromeははじめからこのバージョンを前提に作っているようですね。
######################

しかしGoogleという会社、Appleが開発しているオープンソースの部品をうまく活用しているとしても、これだけのものを出せるというのはやはりすごい会社なのだと思います。（ちょっと使った感じでは本家のSafariより使いやすいイメージがあります）　技術者としても、経営者としても、うらやましい限りです。

IT Proの1万人が使った“Excelのお化け”という記事を面白く読みました。日産とリクルートの事例で、多くの人がExcelファイルを共有して使っている場合に起こる問題点と、その解決方法について書いています。

解決策は、日産の場合にはデータをExcelを使ってXML化し、XMLデータベースに格納する方法、リクルートの場合にはマイクロラボ社のツールを用いるというものでした（ExcelをWebブラウザ内で動かし、そことアプリケーション・サーバを連動させてDBに格納する方式）

それぞれ、いわゆるWeb化はしていないのですが、理由はユーザがExcelを使い慣れているため、そして高額な投資をしてWeb化するほどでもない、という２つの点のようです。

正直なところ、読んで思ったことは、これは最初からわかっていた事だよね、ということです。多少Excelを使い込んでいる人であれば、それだけの大人数（日産の場合、なんと日米欧の１万ユーザ）でExcelファイルをみんなで共有して使った場合に問題が起きないわけがないことぐらい理解しているでしょう。

でも現実問題として、こういうのってよくある話だと思います。上記のいずれもいわゆる情報系であり、勘定系と異なりシステム投資があまり行われません。金がないから、まああるものでいこう、ということになるのです。

法律上必要だとか、何らかの理由がないと、情報系と呼ばれる部分にはなかなか投資してもらえません。人手で回せる間は人手で回す、という発想になりがちです。投資対効果がわかりずらいことも一因でしょう。

しかしビジネスは「情報戦」です。外部・内部を問わず、情報を制する者が最終的には勝つはずです。それらの仕組みを積み重ねていくことで、他者に対する確固たるアドバンテージを得ることができるようになります。日本のシステム投資も、もう少し大局的なものの見方で、情報に投資する、という姿勢が必要なのではないでしょうか？

昨日の「らっきょの皮インターフェース」と似たような話ですが、ソフトウェアというのはどうしてどんどん重量級になってしまうのでしょうか？

人間の場合、太りすぎは良くない、と注意されますが、ソフトウェアの場合、そのように判断してくれる人はいません。でも明らかに太りすぎているソフトウェアって見ますよね。

問題なのは、太りすぎが明らかであってもダイエットはそう簡単ではないということです。なんかよく分からんコードが残っていて、動いている様子はないんだけど、本当に必要のないコードなのかどうかが判断できず、削除できない、みたいな贅肉コードがあっちこっちにあると、それらを判断して削除するだけでも手間隙がかかり、大変です。

一旦贅肉が付いてしまうと、ダイエットは大変なようです。はじめから贅肉を付けないように、日々の鍛錬が重要だ、というのはスポーツも、ソフトウェアのプログラミングでも同じなのだと思います。

単に（見かけ上）動けばいいということではなく、ある程度贅肉をきちんと処理するところ（最低限のリファクタリング）までやって、初めてプログラムが出来上がったといえるのだ、ということをジュニアなプログラマ達に刷り込む（インプリンティングする）べきでしょう。

システムを設計する際には、必ずといっていいほどいろいろな部分で「皮を被せる」ことが行われていると思います。この「皮を被せる」というのは、あるモジュールを利用する際に、それをそのまま使うのではなく、一般化したインターフェースを自前で定義することで、そのモジュールに対する依存性を下げるために使われています。

確かにインターフェースを介した設計というのはいいことだと思うのですが、現実問題として、その「皮」がまるでらっきょの皮のように何重にも定義されているケースがよくあります。インターフェースを何重にも定義した場合、それぞれの階層毎にテストが必要となり、メンテナンスも大変になり、メモリを余計に食い、パフォーマンスも劣化し、あまりいいことはないはずです。

つまり、何重にもなっている場合には明らかに設計を間違えているわけですが、例えば「決まり」としてそうしなければならない、などといったよく分からない理由で皮が定義されていることがしばしばあります。またどういうわけか、そういった皮を定義することが生きがい（趣味？）のような人もいますよね。だから世の中には無用な皮をまとったシステムが大量に出来上がり、本人達の自己満足のために、客観的にはやたら複雑化したシステムができあがるわけです。

皮を新たに定義する前に、今そこにあるものが目的にあったインターフェースかどうかを検討し、もしほぼ満たすものであれば、むしろ積極的にそれを活用すべきなのではないでしょうか？

日本料理のように、素材の良さを活かしたシステム設計というのも「あり」だと思います。