›5 24, 2005
UML
ゴールデンウィークは読書三昧です。
●仕事のなかの曖昧な不安―揺れる若年の現在
| 仕事のなかの曖昧な不安―揺れる若年の現在 | |
 | 玄田 有史 中央公論新社 2005-03 売り上げランキング : 9,337 Amazonで詳しく見るby G-Tools |
労働者というくくりで考えるにしても、若年と団塊の世代とでは敵対すると
うすうす感じているのではないか。
最近の若者は無気力だとおじさん達は言う。たしかに戦後日本の復興を目的
に仕事に励んできた方々ほどの気力は、ほとんどの若者はもちあわせていない。
だが、今企業のリストラクチャリングの中、無気力になっているのはおじさ
ん達で、若者のほうが気力溢れていると思う。
会社を利益の出る健全な体質に変えようと思ったとき、労働者世代の中でこ
そ対立が顕著になるのではないだろうか。
労働者というくくりを超えて、いまの団塊の世代（５０代）は、過去を否定
し現状を変えることは、自己否定につながる。
そして既得権益が徹底的に現状維持に留めているのかもしれない。
事実、利益に直結している若者が安月給で、何もしていないおじさん達が、
高い給料のままであることが多い。労働力に見合った報酬が支払われていな
い仕組みで日本経済が動いているのだ。
企業に限ったことだけでなく、マスコミ、政府、各種団体といたるところで
団塊の世代のおじさんたちが最高意思決定者になりつつある。
このような状況下では、彼らの既得権益を守る為、誰かが犠牲にならなくて
ならなくなってきているのだ。
さて、若者達はどのように反逆して行けば良いのか。何を信じるのか。本を
読んでみよう。アマゾンの読者レビューにあった次のせりふが忘れられない。
「私たちは、団塊の世代!!に奉仕するために生まれてきたのではない。 」
▼ UML ▼━━━━━━━━━━━━━━━━━━
情報システムの設計書はざっくり以下のようなものがある。
(1)外部設計書
(2)内部設計書
(3)詳細設計書
外部とは、ユーザから見たときの設計書で、使用者の画面遷移等を定義し
ていき、相互理解を完全にする。
内部とは、外部で実装された設計をシステム内部での定義を設計している。
詳細とは、内部で定義された遷移をプログラムでどのように実装するか。
□UML（Unified Modeling Language）
これまで、システムの設計にフローチャートやディシジョンテーブルという
処理の流れと遷移を表すツールを用いられていた。
しかし、突然それらのツールが役に立たなくなったのだ。
考えてみて欲しい。処理が順番に分岐して一貫するだろうか？これまでは
そうだった。しかしオブジェクト指向という考えが１９９０年代に台頭し
てきてから、処理という概念が変った。
オブジェクト指向の概念は省くとして、簡単に言えばこの世の
ものは全て部品の集りであり、それらは共通に使うことができる。
処理にはイベントも含むオブジェクトだ。
これが専門家から見て正しい認識かはあやしいので、詳しく学びたい人は
UMLの本を片手に、JAVAのようなオブジェクト指向言語のプログラミングを
やってみると良いだろう。
この考えはプログラマーやシステム設計に携る人以外にも極めて重要だと
認識している。
| UMLによるオブジェクト指向モデリングセルフレビューノート | |
 | 荒井 玲子 ディー・アート 2005-04 売り上げランキング : 378 Amazonで詳しく見るby G-Tools |
さて、UMLとは1990年代前後から登場したオブジェクト指向分析・設計方法
論である。
UMLは様々な事象をより明確に伝えるのに有効であり、自然語のあいまいさ
を補足し、プログラム言語の複雑さを回避できるモデリング言語である。
日本語や英語だけでは明確に規定・表現できないのが自然だ。
UMLは外部設計段階の記述から詳細設計（下流工程）段階の記述までを、
含んでいて、上流工程ではユースケース図といった顔文字や直線を含んだ
直感的な表記法で、下流工程にいくとシーケンス図やコンポーネント図と
いったイベントや部品を規定する設計図がある。
□情報化資源調達
さて、UML等による設計書およびRFI、RFPからIT化実装のためのシステム化
要件をＩＴベンダに提出することとなる。
ＩＴベンダと協議の上ソリューションを決定しIT資源調達契約を締結する。
この段階になると、以前紹介したファイナンス的な内容でTCO（トータルコ
スト）から投下資本の回収期間を算出したりする。
ここまでで経営戦略からシステム化、ＩＴベンダに資源調達要件を提出する
ところまでレビューした。
プロジェクトのトップにはＣＩＯが望ましい。これらシステム化はＩＴに
精通している外部のシステム・インテグレータと協業しながら情報システム
部門のような部署もしくはプロジェクトが参画する。
□CMM（Capability Maturity Model)
もとは米国国防省（ペンタゴン）のプロジェクト管理が目的で開発された、
組織の能力レベルを5段階で評価するモデルである。
ＣＭＭではソフトウエア開発を行う組織のレベルを、成熟度の相違から分け
ている。
未熟な組織と成熟した組織の違いを見ていこう
▽未熟な組織
1.プロセスがプロジェクト進行中に徹底されていない
2.プロマネは目前の危機の解決ばかりに集中している
3.スケジュール作成があいまいな為、期限超過、予算超過する
4.成果物品質判断の客観的基準がない
5.プロジェクトが遅滞するとレビューやテストがカットされる
▽成熟した組織
1.独自のプロセス管理能力がある
2.作業活動は計画されたプロセスに従って実行される
3.プロセスはきちんと定義され、必要に応じて更新され責任範囲が明確
4.プロマネは成果物と品詞区と顧客満足度をモニタする客観的基準がある
5.スケジュールと予算は過去の実績に基いている
□５つのレベル
さて、では５つのレベルを見ていこう。
レベル０：無のレベル
組織プロセスが欠如にしてる。
レベル１：初期レベル
プロセス対応が場当たり的。プロセスが定義されておらず、個人のスキル
に完全に依存している。
レベル２：反復実施
コスト、スケジュール、機能従属性を確認するための基本的なプロジェクト
管理プロセスがようやく確立されている。
レベル３：既定義
組織の標準プロセスとして文書化、標準化そして統合化されている。
レベル４：既管理
プロセスおよび成果物品質の詳細な計測結果により定量的に理解され
制御されている
レベル５：最適化
継続的なプロセス改善ができてる。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【SkillStorage.com】経営戦略入門
発行/編集元：Skill Storage
http://www.skillstorage.com/
mailto:fatty@skillstorage.com
登録・解除は以下のURLで行うことができます。
http://www.skillstorage.com/subscribe
SkillStorageを友達に紹介しよう。
Get it http://skillstorage.com/kei/oemail/
当サイトへのリンクは自由です。又、引用・転用について御希望の方は、
当編集部までお問い合せ下さい。
Copyright(C), Skill Storage.com., 2000～2002
---------------------------------------------------------------
Reproduction of this publication in any form without prior
written permission is forbidden.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GWは終った。次のは夏休み。あと130日
