update it, Inc.社長のブログ

会社の前のイチョウの木がだいぶ芽吹いてきました。

今日も気持ちがいい天気ですね。

昨日の?設計書に書くべき範囲と絡むテーマなのですが、設計書って同じようなことの重複が多いですよね。例えばDOAにしろオブジェクト指向分析・設計にしろ、最初に概念モデルを作って、それから物理モデルを作って…ってように、同じ対象に対して２度モデリングをしています。これって目的が違うし、出来上がりのものも違うものなので、厳密には重複ではないのかもしれませんが、なにか似たようなものを作っていますよね。

で、そもそも先に作った概念モデルってなんなの？　っていうのが今回の主題です。もしそれがシステムをデザインするためのものだったら意味がないんじゃないの？って思うんです。それが業務のモデリングだったら話はわかる。このシステムを導入したときに、あるべき業務をモデリングしたものが概念モデルだっていうんだったら書くべき内容がぜんぜん違うから存在意義があると思うんだけど、どうも本来はそういうものではないらしい。

で、似たような、さらにもっと詳しい物理モデルを後で作るんだけど、そうすると同じテーマで２つのバージョンのドキュメントが存在することになる。苦し紛れに概念モデルは最初の設計時に作って後はメンテナンスされないなんて説明がされたりするんだけど、それって重要な設計書類でないからメンテナンスできないだけじゃん、って思っちゃうんです。

別に設計者の頭の整理をするために勝手に概念モデルを作る作業をやめろとはいいません。が、重要でもないドキュメントは成果物ではない、単なる個人的なノートでしょ、ってのが言いたい。それなのにことさらそういったことの重要性を強調するプロセスを定義しちゃうもんだから、成果物として扱われ、無駄な作業が増えちゃうわけです。

最近あんまり聞かなくなった単語だけど、生粋のアジャイラー、安中です。

システム開発には「なんたら設計書」というのが多く伴います。通常のウォーターフォールによる開発では業務要件定義書に始まり、システム要件定義書、システム概要設計書、システム基本設計書、外部仕様書、テスト仕様書etc…が作られますね。

大量のドキュメントを作成しながら、実際には現場ではあまり有効活用されていないケースも見受けられます。なぜでしょうか？　そういう立場のプロジェクト・メンバーになったつもりで考えてみましょう。

１．量多すぎ。頭に入りきらない。
２．実際に作るとなると参考にならないことが多い。

一番の理由はおそらくこんなところではないでしょうか？　こんな理由から上流工程のドキュメントは下流工程のプログラマーが読んでいないことが多いと思いますし、それが当たり前のように思われているところもあるかもしれません。実際のところ「自分のやる範囲の仕様書だけ見てればいいや」っていうプログラマーも多いかもしれません。

でもこれってもったいないですよね。ちゃんとみんなが「使う」「使える」ドキュメントを作るべきだと思いませんか？

じゃあなぜ、量が多くなりすぎるのか。　そして実際に作るとなると参考にならないことが多いのか。　それは設計書に余計なことを書きすぎているからではないでしょうか？　設計書に一般論や誰でもわかることなど書く必要はなく、そのシステムが「他と違うこと」「特別なこと」を書くべきなのではないでしょうか？　何がエッセンス（本質）かということをきちんと捉えて、そこにフォーカスしたドキュメントであれば、それは量は少ないけど中身がとっても濃いもの、読みやすくてためになるものになると思います。

設計書を納品物として納める場合、設計書に「厚み」が要求されることも多いと思いますが、本来逆で、「お、こんなに薄くまとめられたの？　すごいね！」と、紙としての薄さと内容の濃さで勝負できるように変えていくべきだと私は思います。

何の花でしょう？

今日は春めいていい天気です。

最近なかなか手を付けられないでいるのですが、私はSwingUnitという、JavaのGUIアプリケーションのテストツールを個人的に作っています。（今のところ会社としての仕事ではありません）　JavaにはSwingというGUI構築用のライブラリーがあり、Swingを使って組み立てられたアプリケーションを自動的にシナリオに沿って動作させる仕組みで、JUnitなどと組み合わせるとリグレッション・テストなどを自動化することが可能です。

SwingUnitの開発を始めたのは2004年の秋ごろです。その当時、オープンソースの開発や、さらにそれを使ったビジネスモデルの話を聞くたびに、面白そうと思い始め、じゃあ自分でもやってみようかと考えてはじめた次第です。ただ最初から公開する自信はなかったので、約半年間は手元で開発し、2005年の5月、ある程度そろったと判断してjava.netで公開に踏み切りました。

ちなみにこのSwingUnitで2005年のJavaOne nightに出場させていただいたので、そのときにお会いした方もいるかもしれませんね。

あまり偉そうなことは言えないのですが、実際やってみて感じたことは、正直なところボランティアベースではなかなか十分な時間を確保するのが難しいな、ということでした。作るのは本当に楽しいのですが、仕事をやりながらということになると、実際にSwingUnitのために割ける時間というと休日ぐらいになってしまいます。その休日は家族サービスもしなければなりません。会社を立ち上げてからはその休日の時間も全くとれなくなってしまいました。（一応バグFIXはやっていますが）

格言に「Time is money（時は金なり）」というのがありますが、それを実感する今日この頃です。

もうそろそろ、終わりですね。

花見がしたかったです。

プロジェクトを確実に破綻させる方法の第4弾は、「聞いていない」です。これ、プロジェクトの中ではよく起こりませんか？

聞き手が聞き漏らしていた場合もありますし、本当に聞かされていなかった、ということもあるでしょう。でもどちらにしろ、プロジェクトの中で、「聞いていない」ことが自分の知らないところでいつの間にか決まっていた、ということがたびたび起こった場合、相互に不信感が募ることになります。

「聞いていない」ことによる問題は、それによって何か大きな抜けが発生するといった直接的な面もありますが、それ以上に心理的にネガティブになってしまう問題のほうが大きいでしょう。自分が蚊帳の外に置かれたと一旦感じてしまうと、その人の積極性が失われてしまい、Aクラスのスタープレーヤーだった人がとたんにCクラスの他の人の足を引っ張る人になってしまったりします。

プロジェクトマネージャーやサブリーダーの人は、自分が担当するメンバーに対し、直接関係がないと思った情報でもなんらかの形で伝達するように努めるべきだと思います。プロジェクトマネージャやサブリーダーが知っていることと、プロジェクトメンバーの知っていることには何が特別な理由がない限り、差をつけるべきではありません。何が伝えられないことがある場合には、どういったことは伝達できて、逆にどういったことは伝達できないのかを予め明確に示しておくことも重要です。そうやってみんなに全部さらけ出しているんだよ、とプロジェクトメンバーにアピールすることで、各メンバー一人ひとりのプロジェクトへの帰属意識を高めることができるのではないでしょうか？

入学式の季節ですね。今年はちょうど桜が満開でいい感じです。

ちなみに以前、もう葉桜になってしまったと紹介したのがありましたが、あれば別の種類なのでしょうか？

4月2日のブログプロジェクトを確実に破綻させる方法　その３として「曖昧プロセス」について書きましたが、では逆にうまく回すにはどうすべきなのか？　について述べます。

私はそのためにはプロセスの定義をできるだけシンプルにすべきと考えています。理由は簡単。人間そんなに複雑なものには対処できません。完璧な定義よりも、プロジェクトにかかわるチームメンバー全員が、きちっとを守り続けられることのほうが重要なのです。特定の人しか理解していないような複雑なプロセスは、結局オペレーションできません。一貫性をもって、同じ呪文を繰り返すことが品質を向上させるには重要なのです。定義の完璧さが重要なのではなく、きちっとオペレーションすることが大切だから、できるだけシンプルであるべきだと考えているのです。

ここででてくるのが、ブログ私の履歴書で書いたセブン・イレブン流の話です。私がセブン・イレブンの話を聞いたときに一番感銘を受けたのが、パートやアルバイトまで巻き込んで全社的に一貫して「仮説・検証」していてるという点でした。

シンプルだけと、一貫性のある、強力な呪文をみんなで唱えると強くなれるって、まるで何かのゲームみたいですが、if文の嵐のような大量のプロセス定義よりもよっぽど実効性があるのではないでしょうか？

昨日のシステム開発会社は製造業？サービス業？の続きです。もうひとつの製造業とサービス業の違いとして、相手に提供する成果が一過性のものか、継続的に提供するものか、ということがあります。製造業では製造物（成果物）を買ってもらいます。基本的には買ってもらえばおしまいです。一方のサービス業では、継続的にサービスを提供することが重要です。

少し前からオープンソースの製品を無償で提供しつつ、そのサポートを生業とする企業が出てきていますが、彼らはまさにサービス業といえます。サポートというのは「相手方の時間および手間を肩代わりする」行為であり、継続的に行うことが可能です。製品そのものを売るのではなく、サポート、つまりサービスを商売にしているわけです。

もちろん彼らも裏では一生懸命、製品のバージョンアップをしているわけですが、製造したものを売ってはいるわけではないのです。

このサポートサービスというのはライセンスによる商売の一種とも考えることができます。しかし単なるライセンス商売とは違い、顧客を継続的にサポートし続けること、そしてライセンスの代金は製品そのものに対する代金ではなく、それをサポートすることに対する代金であること、などが特徴となります。

なお、ここでいうサポートって保守のことだと決め付けないでください。実は非常に広範囲のことが、サービスとして提供可能なのです。また製品がオープンソースでなければならない、ということもないと思います。要は製造物を売る商売ではなく、継続的なサービスを提供する商売になっていれば良いのです。

こうしたサービスは、高い技術力やオペレーション能力がないと実現できません。単なる人出しの商売とはまったく異なる業種になります。これこそが今後システム開発会社の進む道だと私は考えます。