皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

お盆明け第一弾、少々嫌なことを書きます。

顧客は、時として非常にひどいことを言うことがあります。

『ちょちょっとやっとくだけでしょ！』といった、非常に自分方向な言葉を使い、無償で作業をやらせようとすることです。

では、何故このような言葉を浴びせられることになるのでしょうか？

料金規定がないことがひどい言葉を呼ぶ

まず1つ言えるのは、それを言われてしまう事業者のところには明確な料金表が存在しないことが多いです。

料金表が存在せず、『いつも、概ね〇〇円くらいの金額をもらっているから。。。』といった具合で、きっちりとした仕組みが出来上がっていないのです。

その仕組みが出来上がっていないことが不幸を招いてしまっています。

1人会社であることが見えてしまっている

もう1つ、社長1人で行っている会社であることを顧客に逆手に取られてしまっているということもあります。

この場合、料金表があったとしても顧客は違う見方をします。

『自分が社長なのだから料金は自身の算段で何とでもなるでしょ！』という見方です。

確かに何とでもなることは事実ですが、これでは商売になりません。

と言うより、このようなやりとりになってしまう顧客は本来避けるべき対象です。

このような顧客と継続的に取引をした場合、ある程度の期間が過ぎれば顧客は委託先を変えてしまいます。

つまり、顧客に都合良く使われ、賞味期限切れになったところで終了となってしまうのです。

こういったことにならないよう、明確な料金規定を設け、相手のゾーンで仕事をしないといったことを少し考えてみると良いかもしれません。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

今年の夏から来年の春にかけ、ICANN（The Internet Corporation for Assigned Names and Numbers）がルートゾーンに重要な更新を実施するようです。

さて、重要な更新とはいったい何が起きるのでしょうか？

KSKロールオーバーが行われる

以前、『DNSSECを使えるなら使うべき』という記事などにおいて『DNSSEC』というものに関して触れましたが、このDNSSECにおいてDNS応答の検証に使われるルートゾーン情報の電子署名鍵（KSK：Key Signing Key）が更新（ロールオーバー）される、これが今回行われる重要な更新ということです。

DNSのルートゾーンには、ルートゾーンのレコードに署名するZSK（Zone Signing Key）と、そのZSKに署名するKSKとがあり、ZSKは3ヶ月に一度更新されるようですが、KSKは今まで一度も更新されたことがなく、今回初めて更新されることになります。

（本来は5年に一度更新されることになっているようですが、今回は初めての更新のため、2年間の準備期間を設けていたようです。）

では、これによってどのような影響があるのでしょうか？

DNSSEC未使用でも影響を受ける

KSKロールオーバーによる影響は、前述のDNSSECを使っていなければ問題ないというわけではなく、DNSSECを使っていなくても影響を受ける可能性はあるようです。

これは、KSKロールオーバーによってDNS応答のパケットサイズが通常の倍以上になってしまう可能性があり、それによって名前解決ができなくなる、つまり、DNSSECの有無にかかわらず影響を受ける可能性があるということです。

名前解決ができなくなった場合はどうなるか？

当然、ウェブサイトは閲覧できない状態になります。

ただし、実際に影響を受けるのはDNSキャッシュサーバの運用者などになりますので、ホスティングでウェブサイトを公開しているだけの一般ユーザーは基本的には影響はないようですが、ホスティング会社なども現在対応を協議中としているところもあり、その対応がなされれば問題は発生しないということにはなります。

ご参考までに。

契約時の納期は平成10年12月であったが、スケジュール遅延により、被告Bの要望として平成11年3月に変更となった。

皆さん、こんにちは。

業務コンサルタントの高橋です。

少々重苦しいお話しにはなりますが、システム開発における紛争話し第2弾です。

冒頭にある変更後の納期でも結果的にはシステムは完成せず、原告Aは契約を解除し、支払済み代金約2億5千万円の返還と損害賠償3億4千万円の支払いを求めて訴訟を提起しました。

しかし、被告Bとしては、システム開発が遅延した原因は原告Aによる機能の追加・変更などが過剰に要求され、かつ、原告Aが回答すべき懸案事項の意思決定の遅れによるものとして、逆に委任契約解除の報酬と損害賠償として約4億6千万円の支払いを原告Aに求めて反訴を提起しました。

さて、ここまでの段階にてどちらに問題があったと判断されますか？

責任の多くは被告Bに求める判決

裁判では、原告Aによる要件追加や変更については原告Aの責任を認めているものの、システムが完成しなかった責任の多くを被告Bにも求める判決が出たのです。

その要旨としては、

被告Bは、自らの有する高度の専門知識と経験に基づき、本件電算システムを完成させる債務を負っていたものであり、開発方法と手順、作業工程などに従って開発を進めるとともに常に進捗状況を管理し、システム開発について専門的な知識を有しない原告Aのシステム開発へのかかわりを管理し、原告Aによって開発作業を阻害する行為がないように原告Aに働きかける義務を負う。

というものでした。

義務とされたプロジェクト管理

原告Aが機能追加・変更の要求をした場合、委託料、期限、他機能に影響を及ぼす場合などを適時説明し、要求の撤回、委託料の負担、期限の延期などを求める義務を負う。

このように、被告Bには少々厳しい判断が下されたわけですが、この判決内容を見ると、プロジェクト管理はマストでなければならないと考えられます。

相手のゾーンに入らない

顧客は結構無理難題なことを言います。そして、無理難題を言っている割にはコストを叩きまくることもします。悪く言えば足元を見ていることもあります。

しかし、それでも『YES』と言って引き受けてしまうことにも問題があります。

機能追加や変更があれば追加コストがかかることを提示し、懸案事項の回答に遅れが生じているのであれば、いつまでに回答がなければ納期はどれくらい遅延するかなども提示するべきです。

これらを許容範囲内として判断したのであれば良いですが、そうでないのに無理に受け入れてしまっては結果的にもっと大きなリスクを負うことになります。

肝心なのは相手のゾーンに入らないこととも言えるでしょう。