update it, Inc.社長のブログ

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

タイトルは重いテーマです。

日本のソフトウェア産業は製造業に比べてあまりいいことが書かれたことがないように思えます。それは、製造業の分野では明らかに世界No1といえる分野がいくつもあるのにくらべ、ソフトウェア産業は世界No1と呼べるものがないからではないでしょうか？

日本は日本語という見えざる参入障壁に守られているわけですが、この参入障壁がかえってソフトウェア産業の国際競争力を弱めていると思います。もしこの参入障壁が破られたら、そのときには日本のソフトウェア産業というのはひとたまりもないかもしれません。でも現在の中国のソフトウェア産業の成長を見ると、それもありえない話ではないように思えます。

では振り返って、日本のソフトウェア産業の優位性は何だろう、というのが今日のテーマです。いったい何でしょうか？

一昔前（10年以上前？）は日本のソフトウェアの品質に対するこだわりが優位性だといわれていた時代がありました。でも今ではそのときの方法論が死に絶えた？のか、それとも単に過剰品質だったのか、そういったこともあまり言われなくなってしまいました。今ではむしろインドのソフトウェア会社のほうがCMMI5とか誇っていますよね。

となると、後はなんでしょうか？　日本が世界のソフトウェア産業に対して渡り合える分野ってあるのでしょうか？　うーん、あまり思いつかない…

携帯のJavaVMとか車載電子機器用の組み込みソフトウェア等はあるかもしれません。いずれも「製品」に付属するものであるのは興味深いところです。でもソフトウェア単体で勝負するもので世界に名を馳せるものとなると、知的資産としてのRubyぐらい？しかパッと思いつきません。最近のIT系企業がやっていることは米国の焼き直しが多いと思いますし。

こうやって考えてみると実に寂しいですね。私もぜひ日本発のソフトウェア企業として世界を目指したいです。

さて、私の会社で現在研究開発中のプロダクト（コードネーム：APIS）についての説明の第2弾です。

会社のホームページには「銀の弾丸」を目指す、と勇ましいことを書いているのですが、正直なところ、このプロダクトを入れたからといってプロジェクトの生産性がウン倍にアップするなんてことは決してありません。私達が目指しているのはそういうものではなく、プロジェクトチームが円滑に機能しやすくする、手助けのためのツールというか、サービスを目指しています。

私達の対象とする問題領域は、次のようなことです。

・プロジェクトに関わる人数が増えると、仕様を決めるために必要なコミュニケーション量が爆発的に増える。（図の中の矢印が示しています）

実際、プロジェクトの規模が膨らむと、生産性を向上させるために人をつぎ込む以上に、コミュニケーションの問題を改善するための人が大量に必要になります。つまり仕様を関係者全員に伝達して理解させたり、検討したり認識合わせをしたり、意見を調整したりレビューしたり、など、一連のコミュニケーションにかかるコストが膨大に膨らむということです。そしてこういったコミュニケーションがうまくいかないことが、プロジェクトにまつわる悲哀を生む原因になっていると思うのです。

私達のプロダクトはこの問題を改善するための提案です。具体的な説明は次回に譲りますが、一定以上のサイズのプロジェクトのコミュニケーションの問題を如何に解決するか、という観点で設計しています。

もちろんプロジェクトが円滑に機能するのは、チームメンバの前向きながんばりによるものであり、ただプロダクトを入れただけでは効果はでません。非常に勝手ながら、少しでも良くしていこうという前向きのプロジェクトのところにだけ入れて欲しいな、と思っております。

今まで、仕事で「あ、この人はスーパープログラマだな」と思った人に何人か出会いました。スーパープログラマといっても何か一般的な基準があるわけでもなく、学歴も肩書きも資格も関係ないわけですが、明らかに他の人たちよりも「理解力に優れ」、「並みのプログラマの10倍以上の生産性」を上げ、かつ「書いたコードが美しい」人達がいるんです。そういった人たちを私はスーパープログラマと呼んでいます。

こういった人たちに共通するのは、新しいことに対する飲み込みの速さです。「地頭（じあたま）」の良さというのでしょうか。まったく新しいことでも人より早く本質を理解してしまうのですね。プログラミングというのは演習問題をいっぱい解いてお勉強をすればそれなりには組めるようになると思うのですが、そういった基礎能力だけではスーパープログラマにはなれないのだと思います。

かといって、頭が良ければスーパープログラマになれるのかというと、かならずしもそうでもないと思います。誰もが頭が良いと認めるような人がプログラミングをしても、かならずしもスーパープログラマといえるレベルではない場合も多いからです。

いままでお会いした人たちに共通する、重要に思える素質としては次のようなものがあると、私は考えています。

１．集中力、というか熱中力？
２．構成力。コンテキストを読み解く能力。

特に構成力は重要だと思います。全体からコンテキストを読み解いて、自然に構成することができるかどうか。この構成力とは数学とか理数系というよりはむしろ国語力というか、文系に近い能力だと思います。構成力が優れた人ほど理解力に秀でている傾向が強いな、と個人的に持っています。

よくよく考えてみるとプログラミングもコンピュータ「言語」を操つる仕事であり、コンピュータという感情のない機械を相手にしているにせよ、豊かな構成力が求められるのは自然なことなのかもしれません。

ちょっと雑談的な話題ですが…

先週の金曜日に愛用しているノートPCのハードディスクが逝ってしまい、修理に出しました。ちょうど3年前に買ったLet’s noteのCF-W2です。

これを買ったのは自分で何か作ってみたいな、と考えていたからでした。それまではNECのLavie MXというノートPCを使っていたのですが（Crusoe+反射型液晶を積んだ11時間稼動モデルです）、このマシンでは何かを作ろうとしても、例えば開発ツールとしてEclipseを使うにはあまりにも非力で画面も小さく（私のは初代のMXなので、SVGAでした）、作りたくても作れる状態ではなかったのです。Lavie MXもそのとき既に買ってから3年以上経っていたので、思い切って買い換えたのがこのLet’s noteです。（そしてこのLet’s noteを使って、夜中とか休みの日とかにこつこつと作ったのがSwingUnitというヤツです）

このマシンは見た目＝デザインは正直あまり好きではないのですが、軽く、かつバッテリーが長時間持つので、どこにでも手軽に持っていけるので、非常に重宝しました。また今の会社設立に向けての作業用マシンとしても大活躍してくれました。いわば、私の相棒とでも言うべきマシンです。

そんな愛着のあるマシンですが、普段使うときには私は必ずマウスを挿して使っています。タッチパッドはどうしてもマウスが使えない電車の中とかで使うための非常用にしか過ぎません。やっぱりどうもタッチパッドというのは使いにくいと思うのです。その理由は、

１．ドラック＆ドロップがやりづらい。ソフトウェア的に１つの指でドラッグ＆ドロップができるようにするモードもあるが、こちらが思ってもいないときにそれが働くのがいやなので使いません。そうすると親指でボタンを押しながらぐりぐりさせることになるのですが、親指からは作用・反作用の法則で上向きの力で押し返されつつパッドから指を離さないようにするという動作はどうもやりにくいと思います。

２．スクロールホイールがない！　マウスの真ん中に鎮座するスクロールホイールは私にはなくてはならない機能なのですが、ノートPCにはスクロールホイールがありません。Let’s noteにはこのスクロールホイールに変わるものとして、タッチパッドが丸くなっていて、その周囲を指でなぞることで同じ機能を代替できるようになっているのですが、やっぱりこれとて普通のスクロールホイールの使い勝手の良さにかなうものではありません。

１についてはいつもドラッグ＆ドロップをやっているわけではないので、100歩譲るとしても、２は無意識のうちにいつも使うものなので、譲れません。で、私の場合いつもマウスを別に挿して使っている、という次第です。

でも、よくよく考えてみたらなんでノートPCにはスクロールホイールが付いていないのでしょうね？　確かに場所は多少食いますが、今の日本の製造業の技術力ならばお茶の子さいさい（死語？）のはず。Let’s noteにはその昔、トラックボール付きのマシンも確かあったはずだから、絶対できると思うんですけど、どうなんでしょうね？

会社とは利益を得るために存在しています。ですので通常はプロジェクトが赤字の場合、そのプロジェクトは「悪い」プロジェクトである、とされます。でもそれは常にそうなのでしょうか？

もちろん赤字というのはあまりいいことではないのですが、プロジェクトマネージャーを育てるためとか、将来のより大きな案件のための種まきのためとか、戦略的な理由があるのであれば、必ずしも赤字プロジェクト＝悪とはいえないでしょう。これは将来に向けた投資だからです。

逆も真かもしれません。黒字プロジェクトは常に正しいのでしょうか？　黒字を確保しているのだけれども、中にいる人たちが疲弊しまくっているとか、やる気が出せないでいるとか、辞める人が続出しているとか、もしそのようになっている場合、そのときだけみれば確かに黒字かもしれませんが、将来に大きな負債を抱える結果になってしまっているかもしれません。

でも会社というのは、非常に短期的に赤字・黒字だけで良し悪しを判断しがちです。スタート時点は戦略的意味を強調して赤字でもいい言っていても、いざ決算期を迎えるとやっぱり赤字はだめ、と手のひらを返すようなケースもあります。

なかなか難しい問題ですが、やはり重要なのはコンセンサスでしょう。戦略的に赤字プロジェクトを行うのであれば、その意義について関係者間で十分なコンセンサスを得ておくのが肝要だといえます。

先日、以前買ったドラッカー名言集の経営の哲学（ダイヤモンド社　P.F.ドラッカー著　上田惇生編訳）という本を読み返していたら、「オーケストラが明日の組織のモデル」ということが書いてありました。オーケストラとは団員それぞれが専門家で構成され、全員が同じ楽譜をもつことで演奏できると書いてあります。

これってシステム開発プロジェクトでも同じことが言えますね。プロフェッショナル集団で構成され、プロジェクトマネージャーというコンダクタ（指揮者）の下、同じ楽譜（仕様書や設計書）を見ながらシステムを作り上げていくわけです。

オーケストラでは指揮者とは纏め上げる作業をする人であり、もちろんとても重要なのですが、いくら指揮者が華麗にタクトを振っても各団員の能力がなければ音楽はまとまりません。システム開発でも同じ事で、各プロジェクトメンバの専門的な能力がなければシステムという楽曲を纏め上げることはできませんし、各自が調和して行動することも求められます。

ドラッカーさんはこのような、高い専門性をもった人たちが調和して進めるプロジェクトスタイルこそが「明日の組織のモデル」であるとしているわけです。ぜひそのようなスタイルを目指したいですね。

皆さんのプロジェクトではスケジュールにおいて、バッファをどのように設けていますか？　またどのようにコントロールしていますか？

だいぶ前ですが、エリヤフ・ゴールドラット博士の書いたクリティカル・チェーンという本では、TOC（Theory Of Constraints：制約条件の理論)に基づくのであれば、各タスク毎に満遍なくバッファを分散して取るのではなく、複数のタスクの合流点（それらのタスクが同時に終わらないと先に進めない=クリティカル・パス）の直前にまとめて置くべきだと説いています。こうすることで、「仕事は期限が延びれば伸びだ期限の直前までかかる＝パーキンソンの法則」を克服することができる、と説明されていました。

この本を読んだときにはなるほどな、と思ったのですが、私の場合、実際に適用してみると2つのことがわかりました。

１．（悲しい事実ですが）プロジェクトのスケジュールに明示的にバッファを書くと、それを削れという圧力がかかります。各タスクに分散してバッファを書かないでおけば、そのようなことはないでしょう。
２．クリティカル・パスが頻繁に変化するプロジェクトにおいては意味を成さないことがあります。特に目標が変化するアジャイル的なプロジェクトには向かないと思います。

TOCの理論はもともと生産工程管理の最適化のために作られたものなので、工場向けの理論です。ウォーターフォール的に工程管理している場合には有効だと思いますが、イテレーティブな開発モデルにはあまり有効ではないのかも知れません。

いずれにせよ、スケジュールに「バッファ」を明示的に書くことができなかった、というのは非常に悲しい事実でした。ぜひバッファの正当性が認められるようにしていきたいですね。