update it, Inc.社長のブログ

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

日本のソフトウェア産業は製造業に比べてあまりいいことが書かれたことがないように思えます。それは、製造業の分野では明らかに世界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の理論はもともと生産工程管理の最適化のために作られたものなので、工場向けの理論です。ウォーターフォール的に工程管理している場合には有効だと思いますが、イテレーティブな開発モデルにはあまり有効ではないのかも知れません。

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

あるプロジェクトマネージャから、プロジェクトのチーム体制作りで悩んでいる、という話を聞きました。その人は今、ウォーターフォールモデルで詳細設計まできちんと設計した上で、プログラミングに大量に人を投入するスタイルにすべきか、それとも以前に紹介したセル生産方式というべき、エキスパートのエンジニアを揃えてその人たちに自主的に設計からプログラミングを任せる方式にすべきか、ということで悩んでいるという話でした。

エンジニア達に受けが良いのは後者のタイプです。そのほうが仕事が楽しいと感じられるようです。ただ、できるだけそうしたいのだけれども、なかなか人が集まらなかったり、プロジェクト管理の立場では管理しづらい部分があるという点でなかなか結論が出せないでいる、ということでした。

私が感じたのは、作るもののタイプによってどちらのほうがいいのかは変わるのではないか、ということでした。毎回同じようなものを繰り返して作っていて、システムの仕組み上特別に難しい部分がないということであれば、プログラミング工程で人海戦術が可能な前者のスタイルのほうが効率がいいと思います。プロジェクトの遅延に対しても（あまりお勧めしませんが）人を投入することで回復しやすいと思いますし、管理もしやすいでしょう。

一方、作る対象が非常に高度で難しいもので、研究・開発色の強いプロジェクトの場合には、高い専門性が必要とされることなどから後者のスタイルのほうが良いように思えます。このようなものの場合「作ってみないとわからない」ことが多いので、そもそも詳細設計まで落としてからプログラミングに入るというのが難しいことが多いと思います。

作るものの対象に応じてプロジェクトの体制を切り替えるというのが現実的なのかもしれません。

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

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

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

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

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

皆さんのところではどんなコーディングルールが採用されていますか？　最近は対象言語の標準的なコーディングルールを採用するケースも多くなってきていると思うのですが、そのような標準的なコーディングルールとは異なる社内標準が存在するケースも良く聞きます。そのような場合、従うのは当然としても、なにか割り切れない感じを受けませんか？

開発プロセスとかを事細かに定義しているところほど、この手の標準から離れた社内標準のコーディングルールを採用していることが多い気がします。

問題なのは、そのような社内標準のコーディングルールを決めた人たちがその言語環境についてあまり良く知らずに、他の言語で作ったルールをそのまま持ち込んでいる場合です。たまに見るのですが、オブジェクト指向言語のクラス名やメソッド名に管理番号が入っていることがあります。まあ、C言語とかで書いていたときにはこれも有りだと思うのですが、オブジェクト指向言語の場合には既にその言語内にパッケージ（あるいは名前空間）とかクラス名とか、管理番号に相当する、もっと良い仕組みが既に存在しているのですから、そんなルールは要らないというか、可読性を下げているだけだと思うのですが、「ルールだから」の一言で押し切られてしまうのですよね。

やっぱり、何のためのルールなのかを良く考えて、適宜必要であれば見直すという姿勢が必要ですよね。