update it, Inc.社長のブログ

正月に実家に戻ったときの話です。PCの具合が悪いというので、ちょっとチェックするということになったのですが、あまりにも示唆に富む内容だったので、ここに書いておきます。

まず背景として、私の親はWindows 95時代からコンピュータを使ってワープロしたり、インターネットしたりしていたので、比較的早くから親しんでいたほうだと思いますが、そうはいっても基本的に素人です。仕組みがわかっているわけではなく、単に「使っている」というだけです。

で、実家にはワープロとしてバリバリ現役のWindows 95マシンと、インターネットに接続するためのWindows XPのノートマシンがあります。Windows 95マシンは主に母親が自分の作品を書くためにワープロとして使っているのですが、ウィルスチェックソフトで動くものはもう存在しない＆あったとしても動かすと遅くて使い物にならなくなるので、外部には一切接続しないで使っています。インターネットを使って調べ物をするときにはXPのマシンを使います。

なぜ、２つのマシンを使う必要があるのか？　それは１つにはノートのキー配列が使いにくいというのもあると思いますが、もうひとつ、XPのマシンのほうが動作が遅いという事情もあります。

CPUを比較すると、Windows 95のマシンは初代Pentiumの200MHzぐらいで、一方のXPのマシンはPentium 4の2GHzぐらいのマシンです。しかしWindows 95マシンとXPマシンを電源起動時からの全体で比較すると、どうもWindows 95のほうが早くWordを起動することができ、かつ動作も十分快適なのです。！！！

CPUの速さで比べたら、圧倒的にXPマシンのほうが早いはずなのに、です。

さて、ここで輪をかけて事態を悪化させることが起きていました。家族の者が、XPマシンにこっそり最新版のOffice 2007をインストールしてしまったのです。

さて、どうなったと思います？

マシンは起動してまともに使えるようになるまで、数分かかるようになってしまいました。IMEは遅くてまったく使い物になりません。（ちなみにこの件は以前このブログで回避法を書いています）　母親は、これではあまりにも遅すぎてインターネットで調べ物も出来ない、とこぼしていました。

でも実家の者でOffice 2007をインストールしたことで動作が遅くなったということが分かる人は誰もいなかったのです。まあ、当然です。普通の人だったら、そもそもそんなことを調べようとも思わないでしょう。最新版をいれたのだから、普通は何か良くなることを期待するでしょう。悪くなることを想定できる人はシステム屋さんだけです。遅くなったら、ああ、よくわかんないけど、遅くなったな、ということで単に我慢してしまうのではないでしょうか？

ちなみにこのXPマシンはOffice 2007をアンインストールして、元の状態に戻りました。原因を特定してアンインストールして…というのに私の数時間を費やしてしまいましたが。

そういえば、会社でCore 2 Duo + VistaのノートPC + Office 2007を使っていても、使いやすくなったと感じることはないなぁ、と思いました。

ソフトウェアは何のために進化しているのか？　ちょっと考えさせられる出来事でした。

あけましておめでとうございます。
今年もよろしくお願いいたします。

最近ブログをあまり更新できていませんが、少しずつ書いていきたいと思います。

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

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

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

wuauclt.exe って何?

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

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

昨日 crossnote Ver 1.3.2をリリースしました。

今回のリリースではワークスペースの使い勝手の改善、目次機能の強化、キー・アシスト機能の強化、管理ツール関連の改善、パフォーマンス改善などを行いました。

■ ワークスペースの使い勝手を改善しました

ドキュメントのコピーや移動について、Windowsでの操作と同様にコピーやペースト、やり直し（1回のみ）が可能になりました。マウスによるドラッグ＆ドロップの機能も強化し、位置が移動できるようになっただけでなく、crossnoteの外にドラッグすると、自動的にエクスポートして取り出せるようになりました。例えばワークスペースのドキュメントをそのままドラッグ＆ドロップでメールに添付させることもでき、使い勝手が大幅に向上しています。

■ 目次から該当ページへのリンク機能を強化しました

目次からダブルクリックで該当箇所にジャンプするようになりました。なお「戻る(ALTキー+←)」でジャンプ元に戻るようになっています。

■ キー・アシスト機能の強化

キー・アシスト機能を強化し、キー操作だけで操作できる内容が増えました。特にCTRL+Mによるエディタ画面の最大化の機能はノートＰＣなど、狭い画面で利用する際に便利です。

■ 管理ツールの改善

管理ツールのプロフィール管理をcrossnoteのプロフィール管理とは分離して管理するようにしました。それぞれデフォルトのＩＤをもつようになりましたので、管理ツールとcrossnoteを切り替えて利用する際に使い易くなりました。

■ 大量のドキュメント利用時のパフォーマンス改善

大量のドキュメントを利用する際のパフォーマンスをアプリケーション全体に渡り改善しています。

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

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

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

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

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

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

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

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

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

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

ついに来た、という感じでしょうか？

Microsoft、クラウドOS「Windows Azure」を発表

Amazon EC2のように、Microsoft自身がデータセンターを運用し、Windows Serverのクラウド版とでもいうべきAzure Service Platformを提供する、ということのようです。

Microsoftの開発環境(Visual Stadio)などを使って開発ができるという点で、プロプライエタリ とはいえ、業界標準ともいえる開発環境なので、以前PaaS(Platform as a Service)で書いたように「独自の環境」に取り込まれてしまい、他の環境へ移ることが難しいという問題を実質的にクリアできそうだと思います。

最初はインターネット向けのサービス基盤としての利用が多いと思いますが、私はこれは社内システムの構築基盤として有力な候補になってくる可能性があるように思えます。つまり社内システムをWindows Azure上で構築するということです。

ある意味、データセンター業務に相当する分野に本格的にMicrosoftが乗り出してきたということになります。利用する側から見ればチャンスであり、逆に今までの提供する側にとっては、かなり脅威に感じるところも多いのではないでしょうか？

相変わらず＠ＩＴ自分戦略研究所の後藤和彦さんのコラム下流から見たIT業界「SEとPG、どっちが頭がいい？（1）」が面白いです。少し攻撃的な内容ですが、とても共感を呼びますし、ためになります。ぜひ読んでみてください。

ただし、私はSEという職種は必要だと考えていて、そういった観点では後藤さんとはちょっと意見が異なります。

そもそもSE v.s. PGのような職種間での上下関係という考え方そのものが間違っている、と考えています。（参考システムエンジニアとプログラマー）　本来やる仕事の内容がぜんぜん異なるものであり、どっちが偉いとかいう話ではないはずです。でも今までの日本のシステム開発の現場では、PGの上がSEという固定観念が出来上がっています。これは悲しい事実だとしか言いようがありません。

そもそもSEとPGではやるべきことが異なります。顧客の要求仕様（機能要件、非機能要件）をまとめ、仕様を確定させたり、出来上がったものがその要求仕様に合致したものかどうかを検証したりするのがSEです。また複数のPG間のコーディネイト役としてモジュールやインターフェースを設計する場合もあります。要求仕様を満たすためのデータ設計も必要です。しかしSEがやるべき仕事とはそこまでであって、中身を創り上げる実装はPGの仕事です。

ある程度の規模のプロジェクトの場合、SEの仕事はPGの仕事の片手間にやるようなものではないはずです。世の中にはPGとやることがあまり変わらないSEがはびこっているとすれば、それはおそらく上記のシステムエンジニアとプログラマーに書いた「自称SE」なのではないでしょうか？

昨日、サン・マイクロシステムズ用賀本社のセミナールームをお借りして「工事進行基準時代のプロジェクト・マネジメントセミナー」を行いました。ご出席していただいた方、誠にありがとうございました。

前半は工事進行基準の初歩として、基本的な概念の説明、後半は実際に工事進行基準で今までプロジェクトを行ってきたところの例を元にケーススタディを行いました。少しは役にたつ情報をお伝えできましたでしょうか？

今後も随時、皆さんのお役に立てるような情報を、様々な形で発信していきたいと考えております。今後もよろしくお願いいたします。

最近＠ＩＴの自分戦略研究所で後藤和彦さんが書いているコラム下流から見たIT業界を興味深く読んでいます。コラムではプログラマという立ち位置からプロジェクトを見渡した時に見える数々の問題点を論じています。

上流工程担当者 v.s. 下流工程プログラマという構図も見え隠れしていて、上流工程担当者の人の中には読むと不快に思う人もいるかもしれませんが、違った立場・角度から物を見ることによって見えなかったことが見えてくる、という観点ではぜひとも読むべき内容だと思います。

このコラムで指摘していることとして、上流工程の設計に異常に時間がかかりすぎていないか？　ということがあります。プログラマの立場から見て、何でこんなにつまらないことに無駄に時間をかけているのか、という指摘があります。後藤さんのコラムでは無能な設計者への怒りが伝わってきます。

実は私も以前、1ベンダーの立場としてあるプロジェクトに参加していた際に、同じようなことを感じた時がありました。決めるべきことが決まらず、内容のないレビューを繰り返し、無駄にスケジュールがどんどん後ろにずれていく。でも1ベンダーとして参画している中でできることは限られ、その時はとてももどかしさを感じました。

このように確かにプロジェクトにおいて上流設計がうまくいっていないケースは多々あるのですが、上流工程には『政治的な要因』が絡みやすく、担当者が有能・無能にかかわらず構造的に前に進めにくくなりやすいものです。だからなかなか仕様書が完了しないというのも、必ずしもその人の責任とは言い難いのです。

上流工程の仕事は、実は仕様書を書くということではなく、仕様書を書けるようにコンセンサスを作り上げるということです。仕様書は結果であって、そこに至る過程の検討内容が重要なんです。コンセンサスがとれていれば実は仕様書を書くという仕事はそんなに難しいものではありません。でも現実問題として、そのコンセンサスを取るのに時間がかかり、その結果上流工程の設計全体がずるずると時間がかかることになってしまいます。

でも世の中には単に仕様書を書くことが上流工程の仕事だと思っている人も多いですね。本来上流工程では何をしなければならないのかを、みんなが理解する必要があるのだと思います。