□学習日記

□2002/7/2(水) H8春-PM-午後I-問5

　相変わらず、早朝に午後Iを一問ずつ解いています。（時間をかけると会社に間に合わない）

　で、ちと引っ掛かったのがこの問題でした。

　顧客指定のRDBMSを使用して要求性能が達成できないという場合を想定して、請負側では事前に発注元と、どの様
な事を取り決めておくべきか？　という問題なんですけれど。

（私の考えた事）
　顧客指定のRDBMSを使用しているので、RDBMSの問題によりスケジュールの遅延・工数が増える場合には、請負側
は免責される事を契約書に記述する。

（アイテックさんの回答）
　遵守すべき最低要求水準と、達成不能の際の代替プロダクト、および代替プロダクとへの変更時期を取り決めて
おく。

　という事なんですねぇ。アイテックさん回答の内容も大事だとは思うんですけれど、皆さんはどう思われますか？　
自社の提案ではなく、顧客指定なので免責されても良いし、逆に余計にかかった費用は顧客に請求可能であって、
いいですよね。（笑）

　さて、問題を少し離れますが、自分自身のプロジェクトで過去にOSや、RDBMSの不具合で、とんでもない赤字を出
した事があります。PM研修では、自社開発でない標準プロダクトの不具合については免責される事を契約書に記述
すべきであると教わるのですが、現場ではなかなかそうもいかないですよね。顧客の立場からすれば「御社が提案
した構成なんでしょ？」って言われるのがオチですし、そんな事を言うとコンペにも負けてしまいます。

　でも、実態は結構、酷い目に合う事があるんですよねぇ。皆さんは、どのように切り抜けてらっしゃいますか？

□2002/6/25(火) H8春-PM-午後I-問1

　FP法を使用したシステム規模の見積りに関する問題です。問題そのものは難しく無かったのですが、FP法につい
て少し思うところを書いてみようかと思います。

　FP法を使用した場合、一般的にはより客観的な規模の見積りが可能という事が言われていますが、私自身は使っ
た事が無いので実感を持っていません。って言うか、見積り技法は一人のPMがどの技法を使うとか考えるのでは無
くて、会社として組織的に取り組まないと精度は上がっていきませんよね。何故なら、

　FP法を使うにしても、機能数から未調整FPを算出する際の重み付けの判断基準や、未調整FPからFPを算出する際
の調整項目の判断基準、これらはとにかく沢山の事例からブラッシュアップされたテーブルでないと怖くて使えま
せん。COCOMOのコスト要因にしてもしかりだと思います。ましてや、事例類推では事例が無くちゃ話にならない。

　つまり、FP法を使って開発工数の見積りと実績に差異が生じた場合、「そもそもの機能数」「重み付けの結果に
よる未調整FP」「補正係数をかけたFP」「生産性係数」のどこが間違っていたのか、きちんと出来上がったシステ
ムから、フィードバックをかける事が大事そうですね。

　こういう事をプロジェクトにやらせると、ついつい片手間になってしまうし、整理する間も無く次のプロジェク
トに放り込まれたりするので、社内にきちんと管理する部署をおきたいところです。おっ、これって論文のネタに
使えそうな感じかも・・・（笑）

□2002/6/13(木) ・・・

　ここのところ、仕事がピークだったり、体調を崩したり、家庭がゴタゴタしたりで殆ど勉強が進んでいません。
　全然やって無い訳では無く、午後Iにぼちぼちとりかかったところです。でも、何せ過去の問題集なので、昨年
の時の記憶が残っていたりして、あまりいい感じにはありません。（すらすら解けてしまう・・・）

　そうそう、それからアイテックさんの、短期コースの申し込みをしました。こちらは、7月から教材が届くとの
事なので、もう暫く待ちですね。ちなみに、過去2回通信教育を受けましたが、ついつい午後Iや、論文の提出が
遅れてしまうので、午前は後回しにしてでも、午後から先に提出した方が自分にはいいみたいです。

□2002/6/4(火) 日経ITプロフェッショナル6月創刊号〜特集2品質保証活動を極める

　日立ソフトさんでは、開発部隊約6,500名に対し、品質保証部隊約400名との事。16:1の比率でしょうか。つま
り、16人の規模を超えるプロジェクトの場合、品質管理・保証の専任者を1名は別枠で確保する必要があるのだろ
うなと理解しました。どうでしょう？　私の感覚だと、工期・リスクにもよりますが、10人を超えると専任を置
きたいなぁという感じです。

　まぁ、その分上積みになる工数について、営業・顧客をどのように説得するかが問題ですね。
　ん？　上積みになると考えるからややこしい・・・ってこの辺で、続きは機会があれば論文で取り上げてみた
いと思います。

　ところで、ISO/IEC9126の定める品質特性について、こんな覚え方はどうでしょう？
　語呂は、［フルエンプ！］LがRだけど・・・
  　Functionality  ：機能性
  　Usability      ：使用性
  　Reliability    ：信頼性
  　Efficiency     ：効率性
  　Maintainabilyty：保守性
  　Poratability   ：移植性

　EMPといえば、ORACLEを触った事がある人には馴染み深いですよね♪

□2002/5/31(金) 日経ITプロフェッショナル6月創刊号〜プロが教える業種・業務知識−日曜品メーカー編(1)

　この記事もまた面白い。某日用品メーカ・卸・小売を取り巻く情報システムおよび業務のアウトラインが紹介
されています。でも、メーカ・卸・小売の間はEDIで、とサラリと書かれていますが、実際にはもっと泥臭い部分
があるので（と思う）、もう少し突っ込んで欲しいかなと思いました。(2)回目以降に期待♪

　企業規模による力関係とか・・・

□2002/5/30(木) 日経ITプロフェッショナル6月創刊号〜特集1実践プロジェクトマネジメント−第1部, 第2部

　今日はPMの試験対策（笑）という事で、昨日届いたITプロフェッショナルに目を通しています。
　第一部は、受注〜本番までのPM日記という感じの記事で、読み物的になかなか面白かったです。
　ポイントは顧客・自社どちらにミスがあるか判断が難しい時に、かかった費用を両者折半としているところで
しょうか。営業・PMの契約管理がしっかりしているのでしょうね。もう一つ、気になったというか、私も顧客に
言われてみたいと思う言葉。「他社はスマートな提案だが、成功する気がしなかった。その点、貴社はスマート
さに欠けるが、一緒に頑張ってくれそうな気がした」。いいですねぇ・・・
　その他は、PMとしてやるべき事をきちんとやられているという感じです。でも、本当は世の中の多くのPMやや
るべき事は、判っていてなかなかそれが出来ない。例えば、PMの工数までが予算に織り込めないとか、そういう
点で苦労しているのではないかなぁと思います。

　第二部は、「管理」から「経営」に変わるプロジェクトの役割。これまでは、品質・コスト・納期の管理がPM
の主な役割であったが、今後はそれに加えて、タイミング・利用者教育・変化への対応・利用技術が重要になる。
なる程、その通りかもしれません。利用者教育・利用技術は、これまで言われている情報リテラシに置き換えて
も良いかもしれません。システムですから、使って貰ってなんんぼですもんね。
　また、EVMSによるプロジェクト進捗状況の金銭換算もとても面白い記事でした。

　まだ、本当にパラパラと見ている段階ですが、日経ITプロという雑誌、何でもできるスーパーSE（笑）を目指
す自分には、なかなか良さそうな感じです。

＃午後I対策として、朝30分間で単発の記事を読む訓練をしていますが、何時まで続くやら・・・

□2002/5/29(水) 日経オープンシステム5月号〜新人SEのためのUML入門−第2回UML図の読み方と書き方〜

　全然新人SEじゃありませんが、UMLを少しかじりたくて読み始めました。
　同じ記事を読まれている方いらっしゃるでしょうか？
　どうも、電卓のクラス図がしっくりこなかったんですよね。

　電卓アプリケーションのクラスをこのように定義されているのですが、
　┌─────────┐  ┌────────────────┐　┌─────────┐
  │ボタン            │  │液晶画面                        │  │土台              │
  ├─────────┤  ├────────────────┤  ├─────────┤
  │- 幅              │  │- 幅                            │  │- 幅              │
  │- 高さ            │  │- 高さ                          │  │- 高さ            │
  │- 色              │  │- 色                            │  │- 色              │
  │- 表面の文字　　  │  │- 表示している数値              │  ├─────────┤
  ├─────────┤  │- 最大桁数                      │  │+ スイッチON()    │
  │+ 押す            │  ├────────────────┤  │+ スイッチOFF()   │
  └─────────┘  │+ 数値を更新する()              │  └─────────┘
                          │+ エラー・メッセージを表示する()│
                          └────────────────┘
　私としては、こんな感じのクラスが要るのではないかと思うのですけどねぇ・・・
　┌─────────┐
  │計算機構          │
  ├─────────┤
  │- 数式            │
  ├─────────┤
  │+ 計算する()      │
  └─────────┘

　ずい分昔に、オブジェクト指向について社内で議論した時にも、所詮何をオブジェクトと捉えるか、どこまで抽象化する
かなんて、SEのセンスだから、出来上がるシステムの良否は手法(データ中心・構造化分析)が変わってもそんなに変わりは
しないよ、何て話をした事を思い出します。