update it, Inc.社長のブログ

さて、私の会社で現在研究開発中のプロダクト（コードネーム：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言語とかで書いていたときにはこれも有りだと思うのですが、オブジェクト指向言語の場合には既にその言語内にパッケージ（あるいは名前空間）とかクラス名とか、管理番号に相当する、もっと良い仕組みが既に存在しているのですから、そんなルールは要らないというか、可読性を下げているだけだと思うのですが、「ルールだから」の一言で押し切られてしまうのですよね。

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

Google Developer Day Tokyo の鵜飼さんのプレゼンをまとめたメモ（ブログ）へ?たのめも「Google のソフトウェア・エンジニアリング」を読みました。Googleは既にテレビを始め、いろいろなメディアで開発スタイルが紹介されていまずが、実際に中で働いているエンジニアの方自身による、社内での開発の様子というのは非常に参考になりました。

いろんなところで持ち上げられているGoogleの開発スタイルは、実際にこうやって聞いてみてすごいな、と思う部分が多いのですが、一方で、あ、これは実は基本的なことをきちんとやっているのにすぎないのだな、と感じることも多く、そういった意味ではなにか自分のまったく知らない世界があるというわけではないという点で、ちょっと安心した部分もあります。

私が一番感銘を受けたのは、Googleでは偉い人（フェローとか）ほどコードを書きまくっている、という話です。日本とは逆ですね。私の会社でもぜひこれを目指したいです。

メモの中に「Design Doc」というのがあるのですが、これは一般にいうところの「システム概要設計書」（会社によっては基本設計書と呼ぶこともあるらしい）そのものですね。同じじゃん、と思ったのですが、一方でさすがだな、と思ったのは「一般的にはあんまり長くない。」ということ。これです。無駄に分厚いものが良いのではありません。（読んでいない人はぜひ過去の私のブログ?設計書に書くべき範囲を読んでみて下さい）

あと、

・パフォーマンス重視
・スケーラビリティ重視
・信頼性重視

というあたりは、Googleならではのプロフェッショナリズムを感じます。ぜひこうありたいですね。