Date:  Wed, 08 Sep 2004 13:01:12 +0900
Subject:  【オブジェクト倶楽部: 2004-33号】

       ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
       ┃                         ■┃
      ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部   ■ ┃
       ┃                       ■  ┃
       ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
                          No.61 2004/09/08

■ I N D E X
┃
┣【PM】プロジェクトマネジメント入門[17]
┣【UML入門】OCLを教える[1] - OCL知ってますか
┗【アンケート】気になるシステム業界 ホントのところ

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【PM】プロジェクトマネジメント入門[17]

「プロジェクトマネジメント入門」です。
前回までは、プロジェクトの計画段階における作業項目の洗い出しから、リソ
ースの配置、スケジュールの作成、コストの算出、そして、リスク管理まで、
ひと通り話をしてきました。今回からプロジェクトの実施段階について話をし
ます。まず、はじめは「プロジェクトマネジメントオフィス(以下、PMO)」
です。

プロジェクトの実施体制のひとつで、最近、注目を浴びて、文献などでも取り
上げられています。筆者の部署でも「プロジェクト推進室」との名称で、PMO
の機能を持たせ、システム構築プロジェクトを支援しています。

このPMOを導入する・したいという動機は色々あると思いますが、筆者の場
合、一言でいえば、「マネジメントの普及と実践」と考えています。以前、こ
の連載でお話したと思いますが、特にこの業界、ソフトウェア開発の現場では、
マネジメントに対する取り組みはこれからと思われます。開発するソフトウェ
アが大規模、複雑化するに従い、プロジェクト運営も難しくなっているにも関
わらず、マネジメント技術に関しては、導入(普及)が思うように進んでいま
せん。それは、ソフトウェア開発プロセスが規定しにくい、進捗が定量的に計
りにくい、見積確度が高くないなどの理由はありますが、最大の理由は、プロ
ジェクトマネージャという専門(プロフェッショナル)がプロジェクトにおい
て量的な問題から有効に機能していないからだと思っています。それまで現場
で開発バリバリの方が、年功と共にプロジェクトマネージャになるというのが
多く、ソフトウェアに関する知識は豊富ですが、マネジメントに関しての専門
的な知識や実践が浅くなる傾向があります。

これらのことから、開発経験豊富なプロジェクトマネージャのノウハウと、プ
ロジェクトマネージメントの専門的な技術(知識)を融合させプロジェクト
(開発現場)を支援することを目的に、筆者はPMO機能を組織内に設けまし
た。

筆者は、このような動機でしたが、一般的には、次のような理由もあります。
1) プロジェクトのマネジメント業務を現場から吸い上げ、現場の負荷を逓減
  する。
2) 複数のライン(企画、設計、製造、販売など)で実施するプロジェクトを
  効率的に実施する。
3) 個々に任されていたマネジメントの仕方を統一・標準化し、改善・効率化
  していく。
4) マネジメント技術(ノウハウ)を集約し、質の向上を計る。
などが言われています。

しかし、プロジェクトマネジメントに代表されるマネジメントは、その会社の
企業文化も含んだところがあり、改善するには困難な面もあります。特にPM
Oのようなプロジェクト推進に関する業務権限を持ちかねない組織を作るのは、
尚更困難です。このため、従来のライン(企画、設計、製造、販売部署)中心
の縦割りプロジェクト推進からこのようなPMOのプロジェクト推進まで段階
的に移行する方法、もしくは完全的な移行ではなく、折衷的な移行もあります。
この移行方法に関しては、追々、話をしたいと思います。

今回は、プロジェクトマネジメントオフィス(PMO)を設立する動機につい
て話をしました。次回は、PMOが持つ機能について話をしたいと思います。
(事務局長)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/cgi-bin/question.cgi?F001+16+0
普通:
http://www.ObjectClub.jp/cgi-bin/question.cgi?F001+16+1
イマイチ:
http://www.ObjectClub.jp/cgi-bin/question.cgi?F001+16+2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【UML入門】OCLを教える[1] - OCL知ってますか

こんにちは、天野勝です。

みなさん、UMLって知っていますよね。業務やシステムの構造や振る舞いを表現
できる図言語とかいわれているものです。図言語ということで、図だけが注目
されがちですが、実は図の他にもOCL(Object Constraint Language)というもの
がUMLの仕様で規定されているのです。UML1.5の仕様[*1]の目次を見ると
「6. Object Constraint Language Specification」と1つの章として独立して、
記述されているのを確認できます。
このOCLはいわゆる「形式言語」です。さまざまな制約を記述することができま
す。例えば、クラスの不変条件や、メソッドの事前条件、事後条件などを定義
できます。
UML1.5の仕様書に掲載されている例を借りると、「会社での十分な従業員数は
50人以上」というのは以下のように表現することができます。

  context c : Company inv enoughEmployees:
  c.numberOfEmployees > 50

これだけの説明であれば、日本語でちょこっと説明すれば十分なので、わざわ
ざOCLで記述する必要はないように感じます。しかし、制約を増やしていくとい
つの間にか矛盾が発生してしまった経験はありませんか。このようなときにこ
そOCLは役に立つのです。形式言語であるため、記述を解析して検証することが
可能なのです。日本語を解析して検証することに比べれば、ずっと楽にできる
はずです。今後はOCLの検証ツールが出てくると思いますので、仕様の矛盾に実
装になるまで気づかないといったトラブルが減るのではないでしょうか。

今回はOCLはどういうものかという、さわりを説明しました。次回からは、具体
的なOCLの記述例を紹介しながら、OCLの文法や、その可能性について説明して
いきます。(天野勝)

[*1]
UML-1.5: http://www.omg.org/docs/formal/03-03-01.pdf
OCLのみ : http://www.omg.org/docs/formal/03-03-13.pdf
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/cgi-bin/question.cgi?C003+0+0
普通:
http://www.ObjectClub.jp/cgi-bin/question.cgi?C003+0+1
イマイチ:
http://www.ObjectClub.jp/cgi-bin/question.cgi?C003+0+2
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ

今週は「何個のアイコンがデスクトップにありますか?」のホントのところ。
気が付けば、デスクトップ中アイコンだらけだった、ということはありませ
んか?この機会にちょっと数えてみてくださいナ。

  10個以下です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+26+0
  11個〜20個です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+26+1
  21個〜30個です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+26+2
  31個〜40個です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+26+3
  41個〜50個です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+26+4
  50個〜100個です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+26+5
  100個以上です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+26+6
  それは秘密です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+26+7
  ちょっと語らせて!
     editors@ObjectClub.jp まで詳細を!!

アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「プログラマは英語は得意?」の結果は公開中。是非ご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記

こんにちは、編集人です。嵐の予感…というか嵐が近づいてるのは確かですね。
そんな折にこれを書いているのですが、まだ原稿が届いておりません。このメ
ルマガが発行される頃には台風18号は過ぎ去っているはずですが、台風18号が
来る前にまだ原稿が来てないという大変アドベンチャラスなメルマガ編集室で
す。編集後記になってませんね。編集前記ですね。非常にスリリングですね。
  
今週の強引な一言
*** 縁の下の力持ち(ことわざ)***
プロジェクトが成功のうちに終了、これもすべてあのスーパープログラマーの
おかげ。と思うことでしょうが、よくまわりを見渡すと、目立っていないけど、
この人がいなければ成功はありえなかった、という人はいませんか。スーパー
プログラマーが力を発揮しやすいように周囲と調整をしてくれたマネージャや、
言われた事をこつこつと確実にこなしてくれた開発者、必要な機材などを素早
く調達してくれた購買部の人など。みんながいてくれたから、プロジェクトの
成功があったのです。そういう人たちにも感謝の気持ちを忘れないようにしま
しょう。(さわ)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は         ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は   ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行:オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表:平鍋  健児
Copyright (c)2003-2004 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.