我々の使命（ミッション）

出発点が曖昧で方向性も曖昧だと、生産されるドキュメントも曖昧になる。

我々の使命は、クライアントの考えを纏め上げていく事にある。抽象的な要求であれば、それを具体的、論理的に落として、あるべき要求に仕上げないといけない。

特に、技術的な部分に関しては、確実なアドバイスをしなければならない。

例えば、纏め上げていく中で、あるAという概念を考え出したとしよう。それを、不用意に広げて、あれもできるこれもできる、にしてはいけない。我々の技術の内外の線をはっきり線引きし（それが我々の提示する概念）、ある技術を導入しようとしたら、それに付随して、どのような技術が必要になるか、そして、それにはどれだけのコストが掛かるのかを説明しなくてはならない。

「携帯電話型の製品を作ることも出来るでしょう。」だけなら、誰でもいえる。シンビーじゃなくてもいえる。

「携帯電話型の製品を作ることは可能です。その為には、こういう技術が必要です。コストはどれくらい掛かります。」という事を明示しなくてはならない。

どっかにいたよね、「遅れる可能性はありますか？」という問いに、「０％です」と答えた人が。そういうことは、いくらでもいえるんです。そして、そう言うことでクライアントは喜ぶでしょう。でも、それではビジネスではない。目の前の、喜びだけにとらわれてはいけない。

現実はどうなのかをクライアントに知ってもらう必要がある。

もっとも、最終的に作られるドキュメントに、それらの、具体的、論理的な技術論を書くべかどうかは別。

最初にやらなければならない事は、プレゼン資料つくりでも、技術論でもなく、ある現実解にどれだけのコストが発生するのかを、クライアントと我々で、共通認識として持つこと。その認識がまだ出来ていない場合において、先に進むことは非常に危険である。

この認識が出来た上で、提案書をつくらないといけない。共通認識が出来ていれば（そして書面に残っていれば）、プレゼン中心の提案書を作る事は問題ないだろう。

個人的には、プレゼン中心のみの資料を作ると、それに引きずられて、技術者も夢を見る可能性があるので、ちゃんとした技術的なバックボーンも含めた資料にする必要があると思っている。

「木を見て森を見ず」「森を見て木を見ず」どちらか一方じゃだめ。プログラム開発もそうだが、営業にしても、経営にしても、提案にしても、遠景をみたり、近景をみたり、移動して、常に、森と木の関係を把握しておかないといけない。

森を見るとは、方向性だ。抽象的な”かん”が大きく物を言う。木を見るとは、日々の推進力だ。具体的な、日々のこつこつした作業。

プログラムで言えば森を見るとは、設計だ。木を見るとは、実装とデバッグだ。

いつも言っていることだが、設計のみのプログラムはありえない。実装とデバッグをして、それを設計にフィードバックして、いったりきたりしながら、完成度が上がっていく。「営業、経営、提案」これらも同じ。

この一つの考え方を獲得したものは、技術でも成功するだろうし、その他でも成功する。

〜数年前のメールから〜