植山です。
>ぱっと見ただけで、相当のベテランだなと思いました。
>切り分けがきれいに階層的になっています。
>実務も知っているし、論理的な思考を必要とする（上流の）仕事をされているの
>ではないかと感じました。
お褒めいただいて・・ありがとうございます。
四捨五入で４０歳ですので、確かにベテランですね。(^^)
>>
>> 週末に仕上げて、提出予定です。
>
(略）
>
>気のついたことだけ、コメントします。
>１ 課題では、業務システム＞（業務カテゴリー＞）サブシステム＞機能
>となっています。業務カテゴリ＞業務＞事務作業、の階層と食い違っています。
業務システムの階層と、それを利用する側の業務の階層がこんがらがっている
ので、整理したいと思います。
>２ 事務作業という名称が、う〜ん、って感じです。
>事務作業の継承がシステム運用というのは名前のミスマッチという感じがします。
業務システムのモデル化なので、
業務（業務システムを利用する側）
運用業務（業務システムを提供する側）
と分けて考えた方が良さそうですね。
>３ 植山さんのクラス図では事務作業＞サービス＞システムサービス／人的サー
>ビス、の分割はするどいと思います。
>問題なのは、業務には手作業を含むのが当然と思いますが、業務システムが原則
>として、どこまで手作業を含むかを課題が定義していないような気がすることで
>す。
業務システムを利用する側から見るか提供する側から見るかで違うんでしょうね。
利用する側からみると、なんでも手作業でしょうしね。(^^)
業務システムが導入されても手作業の質と量が変わっただけ！と思うだけかと。
>・課題の求める範囲でモデルをつくるか
>・一般に考えられることまで含んでモデルを描くか
>悩み処ですね。
業務の範囲と、業務システムの範囲を明確にしてモデル化してみます。
「パッケージ」に分割するなどすれば良いのではないかと考えてます。
（業務の方は課題じゃないので簡略化すると）
>４ 調達では、課題が「新たに開発する部分がシステムの本体といえる」といっ
>ていますが、これはおかしいです。
>Web系の開発では、オープンソースをカスタマイズする開発が主流ですから、
>「新たに開発する部分が開発の本体といえる」とはいえますが、これはシステム
>の本体ではありません。
>＃言葉尻の話ですが・・
>これもまた３項と同じく、課題の定義通りにモデリングするかどうかですね。
この辺は検討不足ですね・・・他の方のモデルやMLでの議論を参考にして見るこ
とにします。
今日の夜にでもモデルを修正し、コンテストに参加とします。
（昼は家族と外出で時間がない・・）
以上です。