要件定義「誰が何をやる」の洗い出しが完了したあと、そのシステムが実現可能かどうか、実現するためにどのくらいの労力とお金が必要かを決めなくてはなりません。その工程を分析（または基本設計）フェーズといいます。

分析で、もっとも使いやすい図は、ロバストネス図（だと私は思う）。この図の目的は、作るモノを洗い出すこと。

• ユーザーインターフェース（バウンダリまたはビュー）
• データ（エンティティまたはモデル）
• メソッド（コントロールまたはモデル）

これを書かなければ、決して精度の高い見積もりができません。私が思うに、クラス図なんかよりもずっと大切な図です。

こんなに便利な図なのに、なぜかUML仕様に入らないロバストネス図（なんでだろう？）。でもやっぱり、必ず使う図なので、教えることにしました。ついでに、アクティビティ図を利用した画面遷移図の描き方も講義しました（内容は割愛）。

３週間かけて、ユースケース図、ロバストネス図、アクティビティ図の描き方をみっちり教えこみました。

ではさっそく、それらの図を使って、上流工程をやってみよう！

ここからスタートです。ベンダーさんを応接室に呼んで、ひととおりのご挨拶・名刺交換を済ませｗ、本題に入ります。

ベンダーさんは、何をしていいのかわからず、きょとんとしていました。私は、ベンダーさんが何かをしゃべり始めるまで、だまってることに（沈黙の５分が流れる）。

さてこういう場面で、ベンダーさんは私から、まず何を聞きださなければならないのでしょうか。

ITソリューション＝ITを利用した問題解決。つまり、システムベンダーさんは、問題を解決するために存在しています。だったら、何が問題なのかを聞き出すことが最初でしょう。

「スケジュールを管理したい」。そのセリフの裏には、「今のスケジュール管理方法では、不満だ」という言葉が隠れているわけです。だとすれば、ベンダーさんの口から最初に出てくる言葉は、こんな風になるはずです。

ベンダーがしゃべると、客もしゃべる。話術を鍛えるのも、システムエンジニアの大事な仕事。生徒さんには、そこに気づいてほしいです。

私からの要望は、

• スケジュールを日付時間単位で登録したい。
• カレンダーからスケジュールの詳細を見れるようにしたい。
• １年前、１年後くらいのスケジュールは、見れるようにしたい。
• 明日のスケジュールをメールで知らせて欲しい。

これをユースケース図に直した後、ロバストネス図を使った分析をしてもらったのはこんな感じ。

このロバストネス図から、見積もり額を提示してもらいました。システムベンダー内部の見積もり条件を次のように仮定してみます。

• 人件費　５０００円／時間
• 画面１枚１日、サーバ内部処理１メソッド２日、データベース設定５日　の工数がかかる。
• インフラ費用　１０万円くらい。

すると、ベンダーさんから出てきた見積もり額は、９０～１１０万円。

たかだかスケジュールを登録して見れるようにするだけで、車１台買える金額。生徒たちは、自分が出した見積もり額の大きさに驚いている様子でした。

しかし実際のIT業界において、こんな金額はバカバカしい！と笑えるシステムベンダーは、そう多くはありません（私も、考え方によっては、至極まっとうな額だと感じます）。

ただし、この１００万円という金額は、５０万、１０万、５万に落とすこともできる。それには、きみたちシステムベンダーの技術力や情報収集能力のスキルアップが必要なのですよ。

お客を演じてると、だんだん気持ちよくなっていく自分に気づきましたｗ