update it, Inc.社長のブログ

タイトルの「人月の神話」は知っている方も多いと思いますが、フレデリック.P.ブルックス,Jrが書いたシステム開発プロジェクトにおける古典的名著です。読んでおいて絶対に損はない本だと思います。そこにはその当時の大規模なプロジェクトを通して得たさまざまな知見が詰まっていて、現在でも通用する内容がいくつもあります。今日はその「人月」の問題について、です。

少なくとも日本国内では相変わらず人月単位の仕事が行われています。日経ITProで最近話題になった松原友夫さんの書いたオピニオン「日本のソフトウエア産業、衰退の真因」でも指摘されているように、システム開発の現場では裁量のない請負契約が相変わらず横行し、単なる人だしとなっているシステム会社が多いのが実体だと思います。しかしこんなことを繰り返していては、いずれ単価の安い外国のシステム開発会社に仕事を奪われるのは確実です。

３月２６日に書いたプロジェクトを確実に破綻させる方法　その２において、投資額の上限を合意する方法というのを書いたのですが、日本のシステム開発ではこれを行うときに人で換算するのが、そもそもおかしいのです。これはシステム開発がタスク指向的に設計されるからだと思います。つまりシステムを開発するために必要なタスクに分解し、それぞれのタスクに必要な人数と日数を計算し、それを積み上げて…とやっているからです。これを繰り返している限り、日本のシステム開発会社はフラット化する世界との競合に敗れ、敗退するしか道がないのではないでしょうか。

デパートでオーダーメイドのスーツを買ったとします。そのときに支払う金額は、予め「生地いくら」「ボタンいくら」「仕立て工賃いくら」といったようにメニューができています。もちろんその中には最後の「工賃」のようなタスクに対する金額も含まれているのですが、デパートの場合、「今回のすそ直しには２人日かかるからいくらです」、とはいわずに、「すそ直しはいくらです」という形で値段が決められています。つまり工程を人日に換算するのではなく、その１つ１つのメニュー毎に値段が決まっているわけです。普通、物を売る場合にはこのようにメニューがあって、メニュー毎に値段が決まっているのが当たり前なわけです。

ところがシステム開発には一般的にそのようなメニューを持っている会社がない。それはタスク指向的に場当たり的にシステム開発が行われているからです。もちろんこのメニューは作るのが難しいのは当たり前です。メニュー化ができるということは、その先の開発において部品化が正しく行われているということ、そして開発工程が標準化されているということを示しているからです。つまり、このメニュー化ができた会社はフラット化する世界の中でも生き残ることができる会社になれるはずだと、私は考えています。

今はajax花盛り。世の中の潮流はどんどんブラウザベースに流れていますね。そんな中で日経ITプロのブラウザはどんどん使いずらくなるという記事はなかなか面白い視点から見ているな、と感じました。Ajaxをセキュリティーの観点からこのままで大丈夫？と懐疑的に見ている記事です。

確かに今までのクライアント/サーバー型アプリケーションに比べ、いろいろなアプリケーションが相乗りし、いろんなサーバーへ簡単にアクセスできるブラウザベースのアプリケーションはセキュリティーの問題が発生しやすい構造だといえるのでしょう。

この記事の中で私が一番注目したのは、実はセキュリティーの話ではなくて、ブラウザをオフラインで利用する技術の話でした。オフラインのときに「ブラウザ上で一種のプロキシ・サーバーを稼働させて，Webアプリケーションを利用する」という形態だそうです。そういえば、同じようにオフラインでの利用を可能とする技術として、あまり詳しくはないのですが、AdobeがApolloというプロジェクトでFlashベースのアプリケーションをブラウザから切り離して動作できるようにするという話がでていますね。

いずれにしても現時点ではブラウザベースで成り立つアプリケーションとそうでないアプリケーションがあるのは事実だと思います。例えばAdobeのIllustratorがAjaxベースで書き直されてブラウザで動かせるようにしたとしても、それが使い物になるとは今はとても思えません。（PCにインストールしたって、あんなに起動に時間がかかるんですから）

ただ今まではブラウザベースでは成り立たないと思われてきた分野に徐々にアプローチしようとしていることは事実なのだと思います。特にオフラインでも使えるようになると利用の範囲が広がると思います。

では従来タイプのアプリケーションには未来はないのか？　いや、私は新しい未来型のブラウザベースではないアプリケーションというのがあると思っています。もちろん大部分はブラウザベースに移行してしまうと思うのですが、大量のリソースを必要とする複雑なアプリケーションはどうしても従来型の、インストールが必要なアプリケーションとならざるを得ないと思うのです。

従来型のアプリケーションが忌み嫌われてきたのは（言い過ぎか？）、アプリケーションの保守管理の問題が大きかったと思うのですが、例えばFireFoxは2.0のような手のかからない自動更新の仕組みがあれば、あまり保守管理の問題はなくなるのではないでしょうか？

逆に従来型のアプリケーションには、たとえサーバがダウンしていても使い続けることができるという強みがあります。（もちろん業務によりますが）　またネットワークがつながらない場所でも、どこでも利用できるというのも強みです。この耐障害性の高さ、どこでも利用できるという特性をうまく生かせば、面白い未来型のアプリケーションができるんじゃないかな？って思っています。

会社の隣の公園では釣りができます。（公営の公園では珍しい？）

結構平日の昼間でも釣っている人がいるんですよね。

次にご紹介する「プロジェクトを確実に破綻させる方法」は、「完璧な要件の追求」です。これってシステムを作る側ではなく発注者側で起こりがちな話なのですが、システムを『抜けのないもの』にするという気持ちが強く働きすぎて、結果まともに仕上がらなくなる、というケースです。

システムを現場で実際に使うことを考えると、いろんな要件が出てきます。期末にはこれをやらなきゃならないとか、これが発生したらこの処理が必要だ、とか、そういった通常処理とは異なる処理についても検討が必要です。そうやって必要な処理を並べていくと初期段階では単純なシステムだったはずのものが、ふたを開けてみたらすごい工数の開発が必要だった、なんて経験がありませんか？

もしそう感じたならば、それは「完璧な要件の追求」の罠にはまっていないか、もう一度見直してください。この罠にはまっているとすべての要件の優先順位が高く設定されてしまい、どれも「落とすことにできない」要求になってしまっているはずです。しかも困ったことに優先順位を設定できるのは通常発注者側なので、受注者側では鵜呑みにしてしまいがちな点が非常に厄介です。

もし「完璧な要件の追求」の罠にはまりそうだと感じたら、ちょっと立ち止まってそのシステムに求められているROIのレベルを発注者側と確認してみてください。そもそもそのシステムを導入することによって、どれだけの利益を得ようとしているのか、そしてその利益に見合う投資とはどれだけか、ということです。

これによってまず最初にこのシステムにかけることのできる投資額の上限を合意しておくのです。これ以上投資する必要があるならば、それはそのシステムを作らないほうが良いのだ、ということを最初にはっきりさせておくことがポイントです。（逆にでてきた投資額の上限が際限なく高いものの場合には、腹をくくって突進しましょう  :grin:）

ちなみにこの投資額の上限を合意する方法については他にもご紹介したいことがあるのですが、それは後日ということで。

update it, Inc.　夜も営業中。

私は毎朝事務所に来ると、まず一通り掃除をするようにしています。掃除機をかけ、床を水拭きし、必要に応じて机の拭き掃除などもします。小さな事務所でかつ少ない人数しかいないので、毎日しなくても耐えられるのかもしれませんが、あえて毎日するようにしています。これは、私から社員の方々への、「ホスピタリティ」の１つだと考えているからです。このホスピタリティーは update it, Inc.のCreed（信条)の第７条に掲げていることです。次にその抜粋を載せます。

7. Hospitality – 自分が「高級旅館の女将」になったつもりでお客様に接しよう。彼女らは誇りと情熱を持ってお客様に最高の体験をしてもらえるように常に気をかけている。

ホスピタリティとは、辞書では「心のこもったおもてなし」と説明されていますが、私流の解釈では「先回りして相手が気持ちが良いと感じるように振舞うこと」だと考えています。そして決してへりくだるのではなく、誇りと情熱をもって、対等な立場でお客様を導いてあげるのです。

いわゆるサービス業の世界ではホスピタリティというのは非常に重要な要素だと思いますが、情報・IT業も対お客様という観点では、一種のサービス業だといえます。例えばコンサルティングなどは特にそうです。コンサルタントはまさに、相手に先回りして考え、相手に「なるほど」と気持ちよく思ってもらえるように振舞うことが求められます。そのように考えるとホスピタリティを追求するというのも実は重要なことだと私は考えています。

隣の公園で花が咲いていました。

暑さ寒さも彼岸までって言いますが、ちょっと和らいできましたね。

プロジェクトを確実に破綻させる方法ってのは穏やかでないタイトルですが、プロジェクトにおけるアンチパターンをいくつか紹介していきたいと思います。プロジェクト管理「手法」についてはPMPとかを勉強すればわかりますが、実際には手法をいくら勉強してもうまくいかないものはうまくいかない。じゃあなぜ？　ってあたりを掘り下げていきたいと思います。

まず最初は「プロジェクト関係者が一致協力していない」。って、小学生でもわかるような話ですが、実はプロジェクトが破綻したケースって、裏の（というか本当の）原因がここにあることが結構多いのではないでしょうか？　つまらないことでメンバー間で意地を張り合っているとか、相手を蹴落とすように競争をしあっているとか、信用していないとか、見下しているとか、そういったメンバーや関係者間のどこか親密ではない関係が、コミュニケーション不足や誤解を招き、プロジェクトへの不満が鬱積し、やる気が低下し…という負のスパイラルを発生させる最大の原因になっていることが多いのではないでしょうか。

逆に、一致協力しているプロジェクトは強いものです。大変な修羅場ですら乗り越える力を持っています。大変だけど、プロジェクトに参加していることが楽しいと感じられるプロジェクトは、おそらくそれだけで成功する確率が大きく高まると思います。

このアンチパターンから脱却するための一番のお勧めの方法は、「仲間意識の共有」です。プロジェクトメンバーや関係者はみんな仲間なんだって、特にリーダークラスの人たちが率先して意識し、発言する。同じプロジェクトを進めてくれるメンバーは、たとえパートナー会社の人であろうが派遣の方だろうが、みんな仲間なんだって、そういう気持ちを育み、一緒にやっていこうっていうちょっとアナクロなやり方が、実はいろんな「手法」を駆使するよりもよっぽど効果的でお勧めの方法です。

うーん、そろそろ換えなきゃ。

ダイソウの100円ポプリです…

システムを設計するときに気をつけていることを１つご紹介します。それはタイトルにある「具体的な検証」です。システムの仕様を設計する際にもっとも重要なこと、それは使う側の立場になって設計することだと思います。使う側のさまざまなシチュエーションを想定し、それに対してシステムがどう応じるのかを検証しておく、ということです。

通常、システム屋がシステムを設計すると、実現すべきことを要件定義としてまとめ、それを正しく実装するというアプローチをとると思います。これは当然正論で間違いではないのですが、いかんせん、要件として書き出された内容を深く理解しているわけではないために、使う側のほんのちょっとした「こだわり」にたいしてあまりに無配慮なことが多いのではないでしょうか？

もちろん不必要なこだわりをシステムに詰め込んでしまうと要件が膨らみすぎ、これはこれで破綻します。ですので「こだわり」をストレートに要件にしてしまうのではなく、なぜそれにこだわるのか、その背景ではどんなことを考えて、何を実現しようとしているのかをできるだけ「具体的に」理解します。この具体的に、ということがとても重要で、誰が、いつ、何を、どのように、何のために、をはっきりさせ、またその周りにある他の「具体的な事象」との整合性を検討していきます。そうやって考えていくと、「あ、こういうことなんだ、」と初めて顧客側の考え方がわかり、その上でより良い解を顧客に提示することができれば、信頼を得られますし、システムもより良いものになると思います。