update it, Inc.社長のブログ

4月20日のITmediaによると、『米Googleが4月19日発表した第1四半期（1?3月期）決算は、売上高は前年同期比63％増の36億6000万ドル、純利益は同69％増の10億ドル（1株当たり3.18ドル）となった。』とあります。この売上高の36億6000万ドルというのは円に換算して約4300億円になります。ちなみに電通の調査レポートによると、2006年の日本のインターネット広告費は年間で3,630億円となっています。Googleの数値は四半期ベースなので、荒っぽいですが4倍して年に換算すると１兆7,200億円になり、日本全体のインターネット広告費の実に4.7倍にもなります。

まさにガリバーですね。

しかし同時に、日本国内の市場というのは小さいな、としみじみ感じてしまいました。実際Googleは世界各国で売り上げを立てているわけで、だからこそこんなガリバーになりえたのでしょう。日本の国内でシェアをとるというのは、それはそれでとてもすごいことなのですが、それだけでは結局は井戸の中の蛙ということなのかもしれません。

日本は製造業の世界では非常に競争力が強く、サービス業もそんなに捨てたものではないと思うのですが、IT系では残念ながらガリバーといえるほどの会社はありません。特にシステムの世界に限ると常に輸入超過状態であり、Made in Japanが世界に出ていっている例は本当に少ないのが実情です。（知的資産という意味ではRubyという輝かしい宝石もありますが）

一方で中国やインドという国々がこの分野では確実に力を付けてきているのは周知の事実です。日本も今後、どんどん攻勢をかけられるようになるのも間違いないでしょう。

1企業人としてどんなことができるのか？　そんなことを考えさせられる記事でした。

エスプレッソマシンってかっこいいんですけどね。

BROOKSのコーヒーのほうがやっぱり手軽なんで、あまり…

タイトルはスパムメールの話ではありません。

システム開発のプロジェクトではメールは必需品だと思いますが、あまりにも大量のメールがやり取りされていて、結局良く見ていない、なんてこと、ありませんか？

メールって言葉でのやり取りと異なり、やり取りしたことが記録に残るし、後で検索とかもできるので、使って当たり前、いまや空気のような存在に近い（？）のかもしれません。またCC:（カーボンコピー）で関係者に一斉に配布できるので、周知という意味でも非常に優れています。でもその便利さが故に、メール依存度が非常に高まり、システム開発プロジェクトにおいても非常に大量のメールがやり取りされるようになりました。

しかし結果としてあまりにも大量のメールのために、プロジェクトメンバが見なくなってしまっている場合があるとすると、情報共有という観点では本末転倒なのかもしれません。

メールの問題点として、以下のようなことがあると思います。

１．情報が分類されていない。欲しい情報にフォーカスしずらい。
２．メールで意見を表明すると「とげとげしく」見える。

メール自体には情報を分類するための仕組みがないので、自分で振り分けルールを一生懸命作ったり、件名の書き方に統一ルールを作って徹底的に守らせる、などといったことする必要があります。しかしなかなかこの分類をきちんと運用するのは難しいものです。でもこれが無いために、見る側が見たい情報かどうかが中身を見ないとわからないために、いちいち全部チェックするのが面倒くさい→見るのやめた、となってしまうのではないでしょうか？

もうひとつの問題点として、メールで意見を表明すると「とげとげしく」見えるっていうか、よく『炎上』したりすることがありませんか？　Face-to-faceのコミュニケーションだと相手の表情がわかるので、相手の感情を考えながら話す内容を変えることもできるわけですが、メールって書いた後にしか、しかも相手のリプライの文面からしか相手の感情が読み取れません。なのでメールだけでやり取りしていると、ちょっとしたことで炎上したりするんだと思います。

プロジェクトの中でそういった現象が起こると、傍から見てよくわからんことで大量のメールがやり取りされることになり、当然その中身はまともに見ない人が増えることになります。

ここはひとつ、メールの代わりにFace-to-faceのコミュニケーションをもうちょっと増やしてみませんか？

またまた「私の履歴書」ネタで恐縮なのですが、今朝(4/19)の日経新聞の私の履歴書（セブン＆アイ・ホールディングス会長の鈴木敏文さん）のなかで、創業以来、周囲からは「なんて非効率なことをしているんだ」とあきれられながらも、OFC（オペレーション・フィールド・カウンセラー=全国各地で一人７?８店舗を担当する）の会議を毎週、全員を東京に集めて行ってきた、という話が書いてあります。

これ、コストのことだけ考えるとえらく非効率のように思えるかもしれませんが、この会議を単なる情報伝達の場ではなく、互いの考え方や価値観を共有する場としてとらえ、フェイス・トゥ・フェイスのダイレクトコミュニケーションを貫いてきたと説明されています。

このface-to-faceのコミュニケーションって大事なんですよね。話している人の身振り手振り、アイコンタクトなどのような技術的な要素だけではなく、同じような境遇にある人達、仲間がすぐ隣にいて、互いにちょっとしたことでも気軽に話しかけることができて、互いにどんなことを悩んでいるのか、どんなことで成功したり失敗したりしたのか、などなど、いろんなことを共有できるってことがface-to-faceコミュニケーションの魅力だと思います。

セブン・イレブンの場合にはこのOFC会議を使って上から下まで同じ価値観を共有することに成功したわけです。

さて、システム開発の現場の話に戻りましょう。昔はタバコ部屋ってものがあって、そこでは仕事の合間にちょっと一服、タバコをふかしたり、コーヒーを飲んだりすることができました。最近は禁煙の高まりからこのタバコ部屋がなくなったところも多いと思うのですが、実はこのタバコ部屋でのface-to-faceコミュニケーションって重要だったな、と思います。（ちなみに私はずいぶん昔に禁煙しています）

昔、タバコ部屋で交わされる何気ない息抜きの会話の中で、なぜかいろんな仕事上のアイデアが湧き上がってくるのを何度も経験しました。

タバコの場合、吸う人、吸わない人の話があるので今タバコ部屋をそのまま復活させるというのも難しい面があると思いますが、何かこれに変わる新しいface-to-faceコミュニケーションの場を考えていく必要があるのではないでしょうか？

ちょっとだけ。

今までの話はいかに無駄を減らすか、という観点の話が主体でしたが、今日はリスク管理、つまり、どちらかというと無駄をしてでも失敗する可能性を減らすためにはどうすべきか、ということについて書いてみます。

開発プロセスは、このリスクを減らすために存在します。プロジェクトが失敗する可能性を減らすために、いろいろと手順や儀式を決めて、その通りに進めることによりプロジェクトが破綻するリスクを減らします。ですので優れた開発プロセスはリスクをコントロールすることができるはずです。

ただし本当に意味のある、効果的なリスク管理はもっと別なところにあると思います。タイトルにある「小さなリスク管理」です。プロジェクトにおいて日常発生するさまざまな細かいリスクをきちんと対処していけるかどうかということ、これに尽きます。例えば問題点をバグトラッキングシステムのようなものできちんと管理しているか、みんながそれを常に見ているか、きちんと対応しているか、そういった実行面がきちんと回っているかどうかが、本当のリスク管理ではないでしょうか？

少なくとも週1回の定例ミーティングを開いて「そのときだけ」リスク項目の消しこみを行う、みたいな形式的な運用ではリスクが管理されているとはいえないでしょう。

会社の近くで咲いていたつつじです。

昨日の曖昧な仕様でプロジェクト・オーナーを1名決めて、その人が勘と度胸ですべての仕様を決めていく、というスタイルのほうが実は費用対効果が優れていることが多いと書いたのですが、これってちょっと誤解を招きやすい表現なので、もう少し説明します。

ここでいうプロジェクト・オーナーとは「ユーザ側の立場の代表」であり、「専門家」である必要があります。単に闇雲に仕様を決めてしまう人ということではなく、ユーザ側が何を欲しているのかが裏の裏までわかっていて、ユーザ側の意見を集約することのできる人、かつ実務にも詳しい人、ということになります。ちなみにユーザ側の立場の代表はユーザの団体・法人に所属していなければならないというわけではなく、本当にユーザ側の立場で思考できる人であれば良いのです。

このような人を設計・開発体制の中に入れ、権限を与えることができれば、おそらくもっとも効率が良くプロジェクトが進み、出来上がったプロダクトも現場のニーズにこたえたものになると思います。

こうやって指名されたプロジェクト・オーナーは権限もある代わりに非常に責任も重大です。この人の考え方次第でシステムがうまく稼動しなかったり、プロジェクトが頓挫するリスクもあります。プロジェクト・オーナーは説明責任を負いますし、かなり大変な仕事には間違いないのですが、特別なタイトルであり、成功報酬型にすることにより、非常に優秀な人にインセンティブを与えながら遂行してもらうことができるようになると思います。

アジャイルの手法の中にはこのようなプロジェクト・オーナーのような人（ユーザ側代表）にプロジェクトに入ってもらうということを薦めているものもあるようですが、まさにそれです。ただしできるだけ強い権限をその人に集中させるべきだと考えています。

日本の会社の中ではなかなかこのような体制に移行できるところはまだ少ないと思いますが、こういう体制でプロジェクトが進められる会社は非常に競争力の強い会社になると思います。

今日は曖昧な仕様書というテーマです。システムで実現すべきことが書いてあるのが仕様書なわけですが、この仕様書が曖昧で何を実現するのかがはっきりしないものって、結構あります。特に厄介なのはシステム開発の最初の期間で、「じゃあ何をやろうか」というスタイルのシステム開発をする場合です。

この「じゃあ何をやろうか」というのはシステムの概要設計フェーズに含まれている場合も多いのですが、これは設計ではなく分析です。本来設計の前に終わらせるべきことなのですが、事を複雑にしているのは、分析の精度をある程度求めると、投資対効果の費用を算出するためにシステム概要の前提を立てる、つまり設計しておく必要がでてくるということです。これはまさにシステムの概要設計にほかなりません。つまりどういうインフラを用い、どういう運用で、どういう技術やパッケージを使い、おおよそのシステム構成はどうで、などといったことがわからないことには費用の算出ができないということです。

分析フェーズの費用算出においてある程度システムの概要に見込みを立ててしまうと、今度はそれがいろいろな意味でシステム概要設計の足かせとなってしまいます。じゃあそれで問題がでないようにしようとすると、結果として「曖昧な仕様書」が出来上がってくることになります。つまり問題を先送りするわけです。

プロジェクトの運用スタイルの中にはわざと決定を先送りするやり方もあるようですが、そうは言っても基本的な事項を先送りされてしまうと、その先の検討が進まない場合が良くあります。例えばちょっと極端ですが、アプリケーション方式でやるか、Web方式でやるか、なんてレベルのことも決まっていないと、システム構成も決められません。それが連鎖して何から何まで曖昧模糊とした状態からぬけだせなくなる、なんてことも起きます。

これって、良心的な、頭のいい人達が集まってやると余計にこの状態に拍車がかかる傾向があります。ちゃんとやろうとしすぎて物事が運ばなくなる状態です。しかもこうなってしまうと分析期間がかかりすぎ、それだけで莫大なコストがかかったりします。プロジェクトを進めるためには、規模にもよるのでしょうが、むしろ1名のプロジェクト・オーナを決めて、その人が勘と度胸ですべての仕様を決めていく（もちろん裏づけは取った上でですが）、というスタイルのほうが実は費用対効果が優れていることが多いのではないかと、経験上私は思います。

これ、疲れたときにいいですよ。

update it, Inc.ではコーヒーとバナナが必需品です。