update it, Inc.社長のブログ

以前PDAというタイトルでブログを書きましたが、いまだにCLIEを愛用している私が最近非常に惹かれているデバイスが、iPhoneです。CLIEの次はぜひiPhoneに切り替えたい！　日本の携帯と規格が違うので導入には困難が伴うようですが、日本の携帯会社さん、ぜひがんばってiPhoneを導入してください。

私がiPhoneに惹かれている理由は、TODOとかアドレス帳とか、普通のPDAに必要な機能がそろっていて、かつ使いやすそうだから。CLIE(というかPalmOS）の場合も、起動が早くて十分に使いやすかったのですが、日本では今現在、PalmOS系の選択枝がありません。そろそろWindows CE(PocketPC)マシンに切り替えなきゃならないかな、と思っていながら、なかなか踏ん切りがつかない矢先だったのです。でもiPhoneについてのレビュー記事をいくつか見ているうちに、iPhoneが日本で発売されるまで我慢して待とうか？という気になってきました。でも待っていて、果たして出るのかな？

本質的にはPocketPCマシンと極端な違いがあるわけではないと思うのですが、日本で売られているPocketPCマシンはどれも重くてワイシャツのポケットに入るようなものではありません。これが私がPocketPCマシンになかなか踏み切れなかった最大の理由です。一方のiPhoneは十分に小さくて軽い。携帯デバイスなんがら、小型であること、軽いことこそが高性能なんです。

またCLIEの場合には携帯とPDAと両方持たなければならなかった、という問題が一気に解決します。この点でも「買い」です。

もちろん見た目のカッコよさとか、アプリケーションの動きの滑らかさも大きな魅力の１つです。ほんと、センスが違いますね。

ちなみにJavaVMはまだサポートされないようですね。でも、こんなことが気になっちゃうのはシステム屋の悪いところか…

ちょっと前ですが、シマンテックがアンケート調査した「PCは遅い！」、ユーザーの6割がストレスという記事が@ITに載っていました。PCそのものは処理能力が年々向上しているはずなのですが、使っている人たちはその恩恵をほとんど感じていない、ということになります。なんとも不思議な話です。

実際、私のPC(Window XP, Pentium D 3.2GHz, 2GByte Memoryのマシン）も朝立ち上げてログインした直後はしばらくまったく使えません。一応画面上、ディスクトップは表示されるのですが、右下の常駐アプリケーションのところが一通り出揃うまでは裏でCPUやハードディスクなどががりがり動いていて、その状態で何かアプリケーションを起動してもなかなか立ち上がってきません。試しにその状態で起動してみると1分ぐらい平気で待たされてしまいます。

でもしばらくして（数分後）落ち着いてからは、すんなりと待つこともなくアプリケーションが起動されます。また通常に使っているときには特に遅いと感じることは少ないです。

上記の記事で皆がPCが遅いと感じているのが、この起動直後の状態を指しているのかははっきりしないのですが、私はかなり関連しているのではないかと考えています。もしそうだとすると、これは何が悪いということになるのでしょうか？　もしかしてアンチウィルスソフト？　そういえば私のPCのアンチウィルスソフトはXXXXxX製ですね。  😎

PCの起動直後というのは、まさにそのPCを使いたいと思って使い始めた直後のことなので、そこで待たされてしまうと、ことさら遅さを感じてしまう気がしています。

突き詰めて考えてみると、ユーザが求めているのは、動かし始めたときの起動の速さなのかもしれません。使い始めたときにさくさくと動けば早いと感じ、なかなか立ち上がらないと重いと感じる。例えばJavaのアプレットが人気が出なかったのに対し、AjaxやFlashがなぜに人気があるのか？　なんてことも、その仮定を裏付ける１つの事例のように思えます。またYouTubeがWindowsのMedia Playerではなく、Flashベースなのも、Google MapやGoogleブック検索がPDFなどではなく、GIFベースなのも、さくっと動きはじめることを重視しての選択のように思えます。

梅雨のこの時期に、なんかでかい台風が近づいているみたいですね。

運用をしている人でないとあまり縁がないものかもしれませんが、今日は障害報告について、です。これをテーマにしたのは、私の経験上、障害報告をもっと「有効活用」すべきではないかと感じることが多かったからです。

システムが障害を起した場合、障害報告書を書いて提出しなければならないことが多いですが、みなさんは、これをどのように活用していますか？　もし障害報告書が単に懲罰的な意味合いでしか使われていないならば、非常にもったいないことです。本来は、同じ間違いを繰り返さないために書くものだと思うからです。

同じ間違いを繰り返さないためには、事後の分析が重要です。直接的な原因ももちろんのこと、その背景の問題についても深い洞察が必要だと思います。そして分析の結果を「失敗のパターン」として広く社内に公表し、改めるべきところを改め、また同じような事例がほかのシステムでも発生しないように社内にとして紹介したり教育していく仕組みがあってしかるべきだと思うのです。

失敗の経験は非常に重要なことです。それを個人の経験として閉じ込めてしまうのは、会社としては大きな機会損失をしていることになります。

こういったことが会社としてうまく機能するようにするためには、それが個人を攻撃するためのものでは決してないことをトップダウン的に伝達し、広く浸透させる必要があります。そうなっていないと、問題を深堀することは、ぎすぎすした、あまり楽しくない職場にしてしまう可能性があるからです。

重要なのは当事者を責めることではなく、次の当事者を作らないように社内が仕組みを作り、バックアップしていくことだと思います。

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

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

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

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

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

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

雨の日が続きますね…

今日はまだ降っていませんが、今にも降りそうです…

プロジェクトを進めるに当たって新規に人を採用しなければならないことが多いですが、皆さんは採用面接ではどんなことを聞いていますか？

私は採用面接ではできるだけ具体的で詳細なことを聞くように心がけています。例えば前にやったシステム開発プロジェクトがあれば、それはどんなシステムだったのかとか、どんな人がどのように使うものだったのかとか、どんな技術をどのように適用していたのかとか、自分の役割に応じてどんなことをやったとか、ドリルダウンするように、できるだけ詳細に質問して聞くようにしています。また技術水準を知りたい時には、かなり具体的な、特定の技術に関する質問（例えばXXXはどう使うのかとか、使ったときにどんな問題があるのかとか）をするようにしています。当然こちらの知らない技術分野の場合もありますが、それでもできるだけわかりやすく説明してもらうようにしています。

なんでここまで詳細を聞くのかといえば、一般論として、具体的な質問をすれば具体的な答えが返ってきて、抽象的な質問をすれば抽象的な答えしか返ってこないといわれています。つまり、質問は具体的であるべきだ、と。

そしてもうひとつの、とても重要な理由が、詳細面を「突っ込む」ことで、その人の対象領域に対する理解度の深さを知ることができるからです。つまり知りたいのは相手の知識ではなく、その人が対象領域に対してどのくらい深く理解しているかを知りたいんです。

単に知識のあるなしは一時の能力に過ぎませんが、深く理解するという能力はその人の基本的な、かつ継続的な能力を示していると考えているからです。自分がやっている仕事に対して浅はかな理解しかしていない人に仕事を任す気にはならないでしょう。

ちなみに最悪なのは、XX知ってる？　的な質問だと思います。XX知っている？という聞き方ではその人の対象物への理解の深さに対する判断を、その人自身に任せてしまっていることになります。その人の本来の能力の高さを知る機会をみすみす逃しているわけで、とてももったいなく感じます。

日経の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)を定めていれば、それに照らし合わせるというのが筋だと思います。じゃあそれがない企業ではどうすべきか？　うーん、今後の課題ですね。