6月6日，銀座のホテルで，あるネットワークの仕事が10周年を迎えたのを記念し，お客様を招いて「10周年感謝の会」を開いた。このネットワークは全国数千拠点の規模で，筆者が担当させいただいている中で最も規模が大きい。まったく取引がなかったこのお客様を初めて訪問したのは1998年2月のことだった。初回なのにネットワークについて3時間近くディスカッションしたことを覚えている。

　その直後，次期ネットワークのコンペに参加させていただけることになり，98年3月6日に提案書を提出した。日付まで分かるのは提案書の下書きを今も大切に持っているからだ。この提案が自分にとっても，チームにとっても「人生にちょっと影響を与えるくらい」重要なものだと思い，自ら提案書の表題と主要部分，10ページを書いたのだ。提案から約2週間後に受注が決まり，以来，10年間仕事をさせていただいている。

　「感謝の会」では筆者の挨拶の中で，この提案書の下書きのうち数枚をスクリーンに映し，当時の思い出話をした。その一枚は筆者が「オブジェクト・フラワー」と呼んでいる図だ。この図は真ん中に目的を書き，そのまわりに実現手段と特徴を書いた花のような図だ。参考に筆者が最近描いているオブジェクト・フラワーの典型を示す（下の図を参照）。この図を見るだけで，提案の目的と特徴，得られる効果が分かる。オブジェクト・フラワーは目的指向で提案や設計を進める筆者が一番大切にしている図だ。

　ネットワークの仕事に限らないが，ベテラン設計者でさえそもそもの目的を忘れて，いつの間にか手段を目的と勘違いしたり，あいまいな「経験価値」（後述）を目的の中心にする，という間違いを犯す。

　今回はあらためて「目的から考える」ことの大切さについて初級，中級，上級の三題話で述べたい。

図●オブジェクト・フラワーの例
図●オブジェクト・フラワーの例
[画像のクリックで拡大表示]

なぜ目的から考えないのか

　まずは「目的を明確に意識していない」という初級レベルの話だ。ある日，ネットワークの運用を担当している若手社員がお客様に提示するSLA（service level agreement）に関する資料ができたので見てほしい，と持ってきた。課長とのレビューは終わっているという。

　資料の一枚目を見た瞬間，ダメだと分かった。「表題」がないのだ。お粗末を通りこしている。言うまでもないが，表題はその資料が何を説明するものなのかその目的を表す。表題もないような資料は，書いた本人さえ言いたいことがハッキリしていないのだ。

　テーブルに座るやいなや，いきなり細かい説明をしようとする彼を制止して，「お客さんに何を言いたい資料なの？」「なぜ，今のタイミングで提示することになったの？」という質問をしなければならなかった。それを聞いた上で，「何を説明する資料なのかが分かる適切な表題をつけて，冒頭に結論を書きなさい。直したら，もう一回課長に見てもらいなさい」と言って3分もしないうちに資料を突き返した。

　大学ではレポートや卒論を書いたはずなのに，なぜ仕事で生かせないのだろう。頭はいいのに，ちゃんとした資料が作れないのは指導不足と反復学習の不足だと思った。「目的にあった表題を決める」→「結論を簡潔に書く」→「分かりやすく根拠を書く」ということを意識して繰り返すことで，誰でもいいドキュメントが書けるようになるはずだ。

　二つめは中級レベルのエピソードで，目的は分かっているが「目的と手段のバランスが取れてない」例だ。この場合の目的は，「ギガバイト単位の個人のメールをキーワードで素早く検索できるようにすること」だった。筆者がコンバインド・コミュニケーション（注）の中核として強力に推進している，オープンソース・ベースのメール/グループウエアにはメール検索機能がある。だが，メールのデータ量がおよそ200メガバイトを超えると検索時間が急激に長くなる。メールの量はどの企業でも増えているし，一つひとつのメールは大きくなっている。各ユーザーにどれだけのメール・ボックスを割り当てるかは各企業の利用実態やポリシーによって様々だが，ギガバイト単位で割り当てたいと言う企業も増えている。そこで大容量のメール・ボックスでも瞬時に検索できるよう，性能強化することになった。

（注）コンバインド・コミュニケーション：コミュニケーションの円滑化と経済化，情報活用の促進を図るため，オープンな技術を使ってイントラ・ポータル，メール，エンタープライズ・サーチなどのサービスを組み合わせ（コンバイン）たコミュニケーション基盤。電話を中心にベンダー独自技術でコミュニケーション・ツールを統合するユニファイド・コミュニケーションと比較し，オープン指向・マルチベンダー指向であること，利用が激減している電話をオプションとしていることが大きく違う（2007年5月に公開した『「さよなら，マイクロソフト」を始めよう』の回を参照）。

　担当するSEはうちのエースで，新しい技術や製品を素早く理解して応用し，動かすということにおいて彼に勝るSEは社内でも社外でもなかなか見かけない。彼が検討した方式はエンタープライズ・サーチのエンジンを使うものだった。検討資料自体は結果を冒頭で分かりやすくまとめてあり，根拠は図を使って詳細に書いてある。ピシッとしたいい資料だ。だが，やはり3分でダメ出しした。

　「エンタープライズ・サーチを個人のメール検索に使うなんて，植木鉢の土をブルドーザーを使って入れ替えるようなものじゃない。こんなに費用がかかっては話にならない。植木鉢にふさわしいスコップのような方法でないとダメ」。

　エンタープライズ・サーチは企業内Googleとでも言うべきもので，社内の情報を有効活用するため，Word，Excel，HTMLなど様々な形式の情報を検索できるエンジンだ。エンタープライズ・サーチのエンジンは，テラバイト単位の情報を効率的に検索できるように複数のモジュールで構成されている。情報を集めてくるクローラー，集めた情報から検索用のインデックスを作るインデクサー，そしてキーワードの解析とインデックスの検索・文書の抽出を行うサーチャーの3モジュールだ。大がかりな構成になっているため，構築コストはばかにならない。

　その彼はエンタープライズ・サーチの担当者でもあったため，メール検索の手段としてそれが最初に浮かんだのだろう。しかし，目的と手段のバランスが取れていない。特定の手段を前提に考えるのではなく，目的にふさわしい手段を選択するというプロセスが必要だ。結局，メール／グループウエアの開発者にも加わってもらって再検討し，メール・システム自体にインデックスを使った高速検索機能を追加することで決着した。開発期間もコストもブルドーザー・レベルでなく，スコップ程度におさまった。