update it, Inc.社長のブログ

プロジェクトを確実に破綻させる方法としてご紹介する３つ目は、「曖昧プロセス」です。システム開発の開発プロセスが定義されているというのはすばらしいことなのですが、きちんと運用されていない場合にはかえって弊害になるという話です。

最近ではユーザ企業側でも自社の開発プロセスがきちんと定義されているところが多いです。これ自体は悪いことではありません。そしてシステムを開発する人・チームが常に同じであれば、長年の付き合いの中でそれらのプロセスは自然に理解され、伝承されていくでしょう。しかし、人は入れ替わるものです。またパートナー会社が変わるということもあります。

問題はそうしたときにドキュメントに書かれた開発プロセスに具体性が無く、実際の運用においてどうすべきかが曖昧な場合に発生します。ドキュメントにはいいことが一杯書いてあるんです。でもじゃあ、このときには何をどうしなければならないのか、っていう具体的な進め方が曖昧だと、プロセスについての議論が沸騰して、実際のプロジェクトが進まなくなる、なんていう馬鹿馬鹿しい経験をした人って多くありませんか？

ある意味、プロジェクト推進者が「ものがわかる人」ならば柔軟な対応で問題にはならないのですが、逆に厳密さを追求するタイプの人だと最悪です。

そもそもユーザ会社の開発プロセスって、せいぜい１つか２つのタイプしか定義されていないことが多く、その中でさまざまなタイプの開発を網羅しようとしているので、プロジェクトの種類によっては意味を成さないような項目が並んでいることが多いと思うのです。でもそのような場合にどれは行ってどれは行わないっていうことが曖昧だと、開発者側がそれに右往左往される。先に述べた「伝承された」人達にはここのあたりのことは自明だと思い込んでいるのですが、それがさらに曖昧さの入り込む原因になっているのです。

盛り込みすぎたプロセスも曖昧になりやすいです。プロセス定義書だけで厚さ？センチなんてものは、おそらく運用不可能です。で、結局これはやる、これはやらないなんてことが現場で判断せざるを得ない。ところがこの判断のやり方に明確な基準が示されていないと、人によってやったり、やらなかったり、となるわけです。この状態で先に述べた、厳密さを追求するタイプのプロジェクト推進者がいたりすると、開発プロセスを守るためだけの作業に時間を食われ、プロジェクトは確実に破綻します。

本来開発プロセスはプロジェクトをうまくまわすためのツールであって、それ以上のものではないはずです。目的と手段を取り違えないよう気をつけていれば、この手の問題は起こらないはずなのですが、みなさんのところはどうでしょうか？

もう葉桜です。早すぎませんか？

システムのメニュー化大作戦第３弾です。昨日は作業と仕事という観点からメニュー化はシステム開発を作業から仕事へと変化させるという話をしました。今日はメニューと値段について、です。

あなたが外食に出かけたとします。店にはいろいろあって、サービスのいい店、味のおいしい店、価格の安い店、などさまざまです。そして提供する値段もそれぞれです。選ぶ側は徹底して安い店指向の人もいますし、高くてもおいしい、サービスの良い店にこだわる人もいます。

この例では個人の嗜好が入るので、ビジネス上の選択とは必ずしも一致しない点がありますが、とはいえ、ビジネスの世界も必ずしも安いだけがすべてではないはずです。システムを開発する会社にも業務ノウハウを持ち合わせたシステム会社とか、優れた開発プロセスを確立しているシステム会社とか、いろいろ選択枝があります。特に大規模なものや複雑なもの、対応する業務が難しいものなどについては、目的のシステムについてかなりのノウハウがないと開発に失敗する可能性が高くなります。

つまりそういったノウハウを有する会社は当然、契約代金は高くなってしかるべきなわけです。これは原価（システム開発の場合はほとんどが人件費）が多少高いのはありますが、それ以上にプレミアム（上乗せ価格）が付いても買う側が必要ならば払うわけです。

ところが作業ベース、つまり人月計算でシステム開発を行う場合にはこういったプレミアムを載せる余地はあまりありません。ですので受ける側も大して努力しようとしない。しかしメニューで提示するやり方の場合は提示する側に自信があればメニュー価格にプレミアムを載せることが可能です。つまり会社として一杯努力して、すばらしいノウハウを有することができた会社は、プレミアムの恩恵にあずかれるようになる、というわけです。

つまり高いメニュー価格を提示する会社というのは、それなりの自信の表れである、ということになります。もし中身が伴わない会社が高いメニュー価格を提示すればそもそも受注できないですし、すぐに淘汰されていくことになると考えられます。

春ですね。駅から会社まで約１分なのですが、その間の畑で菜の花が咲いています。

社員の一人は花粉症で今日は仕事にならん、とぼやいています。

人から聞いた話ですが、その人の昔の上司に「おまえが今やっているのは作業？　それとも仕事？」という質問をする人がいたそうです。作業とは、いずれ自動化されるようなもの、仕事はクリエイティブで付加価値を生み出すもの、という意味で、お金をもらってするのであれば、作業ではなく仕事をしなさい、という意味だそうです。（言い換えれば作業をしているのであればそんなに金を払わないよ、という厳しい指摘ですね）

確かに仕事ってこの２面性を持っているのだと思います。

さて、昨日書いたブログ人月の神話において、今までの日本のシステム会社は人月で金を払っている、これからはメニューを用意し、メニュー毎に値段を決めるように改めてゆくべきだ、という提案を書きましたが、上記の作業と仕事という観点で考えると、今までの日本の会社は「作業」に対してお金を払ってきた、ということになります。効率が良くても悪くても、かかった時間に対して金を払う。やっていることを作業とみなしているわけです。

もちろん今までのやり方でも係数という形で上記の効率をお金に換算してきました。プログラマー（もしくはSE）のランクってやつです。SE、PL、PG…　などといった形で人に値段（単価）を付けています。でも実際このランクってやつはほとんど経験年数で決まっているのがほとんどで、実際の能力を正しく表しているとは言いがたいのではないでしょうか？

もしこれをメニュー毎の値段という形に改めることができれば、本来PGランクの経験年数しかない人達だけのチームでも、会社で仕組みを整え、品質の高いものをタイムリーに提供できれば、高い粗利を得ることが可能になります。逆に約束したものがうまく仕上げられない場合にはリスクを負う。これが「仕事」に対してお金を払う、ということですよね。

ただ、メニューに高い値段を載せるためには、それに相応の内容なんだってことをお客様にわかりやすく提示しなければなりません。ということで、この話はまた後日。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

update it, Inc.　夜も営業中。