今年のクリスマスは

毎年、クリスマスは12月初旬の保育園の見事なイルミネーションから始まります。

駅前の３Ｆ建てビルを借り切っている保育園は屋上から園庭までイルミネーションを使って、巨大なツリーを模します。

保育園へ迎えに行く時刻にはすっかり日が暮れているので、毎日、美しいイルミネーションを楽しむことができます。

そして、子供たちは12月中旬の金曜の夜に、クリスマスコンサートを開催します。
クリスマスソングの演奏や、お遊戯を披露して成長を確認させてくれる子供たちとの幸せなひと時です。

コンサートの後は、親子いっしょに、クラスの友人たちと夕食会（飲み会？）を楽しんだりもします。

天皇誕生日には、バースデーケーキを焼き、子供たちと一緒に、フルーツたっぷりのデコレーション。
バースデーケーキ
ついでに、焼き菓子も作って、ワインやオードブルも用意して、友人家族を招いて楽しみます。
マドレーヌ

しかし、今年はちがいます。

今年中に永年勤続表彰のリフレッシュ休暇を連続5日間取得することを命じられている私。
なんだかんだで、ぎりぎり年末に取得することになりました。
夏は忙しくて十分なバカンスを楽しめなかったので、クリスマスは常夏の島で夏休みを楽しむことにしました。

昨年の秋に行って、気に入ったグァムにもう一度行くことにしました。
この秋から、名古屋発のＮＷ直行便が就航になって、朝出発の夕方帰国という子供づれにもやさしいエアが取れるようになりました。
グァム
昨年は街歩きも楽しもうと、アウトリガーリゾートに宿泊しました。
が、結局、毎日ホテルのプールに入り浸りなので、今年は、館内設備が充実しているＰ．Ｉ．Ｃを予約しました。
12/21～12/25までの5日間を楽しんで来マース。

システムサービス開発の契約上の問題点（3）

システム開発をするのは『何を』があいまいなまま着手するというのは、お話しました。『いつまでに』もシステムの性格によってはわりと弾力的です。が、『いくらで』があいまいなことは殆どありません。

『ざっくり、これくらいで。あとは、必要な都度、教えてください。』なんて太っ腹なお客様（というか、どんぶり勘定なお客様）はめったにいません。

引き合い段階で、予算があるのが普通です。

国や自治体だと、予算ありきで事業を計画しますから、まずは、予算作成のために見積をとりますので、『やりたいこと』と『確保した予算』が大きく外れることはありません。（そのかわり、『やりたいこと』は変えないまま予算だけは一律2割カットなんてことは平気です。）

民間のお客様だと、『予算の根拠は何？』というほどお客様が思っている『予算』が実態と乖離していることはめずらしくありません。
そうじゃなくて『惜しい』場合でも、予算は『やりたいことに必要な金額』よりも少ないことが殆どです。

この場合は、『規模を縮小する（ハードの台数、性能を落とす。）』『システム化範囲を縮小する（実現機能を減らす。）』を提案します。

というわけで、ご予算に見合った規模に絞ってご注文を頂きます。

ところが、『よし、システム化しよう』と決めたときにイメージしたり、『ここに注文しよう』と決めたときの素敵な提案書を忘れているわけではありません。

見積の金額は減りましたが、『やりたいこと』が減ったわけではないからです。

そして、いざ運用テストの段階になって
『あれがない、これがない』
と、そぎ落としたはずの機能が亡霊のように復活してくるのです・・・・あーめん。

Windows95発売のお祭り騒ぎがあって、パソコンが爆発的にオフィスを侵食しだしたころ、『ＥＵＣ』が伝家の宝刀として機能減らしの代替手段として口にされました。

予算を握るプロジェクトマネジャーが、予算内に収めるために管理帳票や分析帳票を『ＥＵＣ』にしようと思うのは自然な流れです。

しかし、エンドユーザのＩＴ成熟度にはバラつきが大きいため、『ＥＵＣ』へのデータ切り出し機能を備えたところで、『帳票』にまで誰もが加工できるとは限りません。

だいたい、企業のシステム開発プロジェクトのメンバに選ばれた人たちは、ＩＴを好む人たちです。
この人たちが『ＥＵＣ』で対応できると判断したよりどころは自分のＩＴスキルです。

切り捨てられた部分の帳票を使って仕事をしていた人たちは、いきなりデータを与えられて、『どうぞ、使いやすいように加工してください』と言われるわけです。

人によっては、悪夢の始まりでしょう・・・・・


そして、盛んに推奨されたＥＵＣは今ではセキュリティの観点から制限する方向が主流です。

システムサービス開発の契約上の問題点（2）

システムサービス開発の契約上の問題点（1）の続編です。

さて、運用テスト段階でエンドユーザレベルの確認がなされると、『思っていたのと違う』事態になることは珍しくありません。

一番ありがちなのは、システムは双方が確認のうえで確定した仕様でできあがっている。が、エンドユーザが『使えない』と拒否した。
という場合。
仕様を考えた人と、実際に使う人は『違う』ことがほとんどです。（そうじゃないと、全社をあげてのシステム開発になる。）

委託側のプロジェクトマネジャーがエンドユーザの業務を理解していない場合や、現場サイドの思惑が、経営サイドの思惑とベクトルがあっていない場合など（これは珍しいことではない。）に発生します。

さて、この場合、委託側の責任として『要求仕様』通りのものが納入されているのだから、検収します。
と、めでたしめでたしな訳はありません。

ここで、契約がまだ締結されていない場合は、絶対にもめます。
モノはほとんど完成していますが、契約していないから『いらん！』と言い張れる。

契約が締結されている状態だと、ごねます。
『検収せん！』
という状態。
この検収についても契約書に条項として歌っていますが、いかんせん表現があいまいです。
ソフトウエアなんて難癖つけ始めたらキリがないのです。

システムベンダとしは、システムを使用しての価値を納品することを使命としています。したがって、要求仕様通りだったとしても、納品後に『使えないシステム』を納品すれば日経コンピュータでたたかれます。（冗談）


つわものになると、値引き交渉の一貫として『検収』はゴネます。

この手の値引き交渉についてこれまでに、応じたことはありませんが、帳票の２つ３つは余分に要求に応じましたね。

（国や自治体がお客様の場合には、注文後の値引き交渉はありません。注文前には散々たたかれますが。）

てやんでぇ、四の五の抜かすと引き上げるぞ！と言えたら、どんなに気持ちいいんでしょうかねえ。