ロバストネス図を教える

分析フェーズの目的と結果。このあたりを体感してもらうために、オトナの事情を交えて、上流工程を実践してみました。

ロバストネス図

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

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

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

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

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

上流工程の疑似体験

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

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

 舞台設定:

  私がお客さんです
  生徒がシステムベンダーです。
  私は、スケジュール管理システムがほしいと思っているので、
  電話帳で探して、システムベンダー(生徒)に電話をしました。

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

 私:「スケジュールを管理するシステムがほしいんだけどね~」

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

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

ITソリューション

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

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

  今はどんな風に管理しているのですか?
  困っていることはなんですか?

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

分析と見積もりの実践

私からの要望は、

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

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

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

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

すると、ベンダーさんから出てきた見積もり額は、90~110万円。

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

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

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


それにしても

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


コメント

コメントしてください

closed.