受けるソフトウェアパッケージ製品についての考察（前置き）
��まあ仕事が原因だが）寝付けないので、気合い入れてエントリ作ってみる。
お仕事では、日頃問題があったりトラブったり顧客に再現しない問題の原因追及を
求められたりするようなソフトウェアを扱っていたりするわけですけど、
アメリカとかヨーロッパとかだと障害発生したとき「すぐ復旧すればOK」
みたいな感じで話が進むらしいのだけど、パッチひとつ当てるにもどうのこうの
言う企業は日本には多いので、日本の企業（特にソフトウェアベンダがアタマの
あがらないほどデカい企業）に好まれると思われるパッケージ製品について
考えてみたい。
サポートの主観が強いので開発を主業務としている人の声も欲しいな。
傾向をみるとこんな感じ。
a. 英語のドキュメントしかないと怒る
b. 日本語のドキュメントもまともに読めない。読んでいない。
c. ベンダサポートなら何でも知っていると信じ込む
d. 自分が理解できなくても教えてくれる
e. でもサポート契約内容は読んでいない。
f. SLA＝顧客の機嫌
g. コンピュータは完全であるべきものだという過信
h. 実装と仕様を区別しない。
i. すべて仕様として記述されているべきだ。
j. 必要なデータがあればどんな事象も説明できるはずだ。
科捜研はドラマほど何でもわかるわけじゃないです。
独自開発のプロジェクトならともかくパッケージ製品は
いち顧客（とその会社）のためだけに販売されているわけでは
ありませんから。
---------------------------------------------
a. 英語のドキュメントしかないと怒る
開発元が海外のベンダの場合そういうことは結構あります。
一部は日本語、マイナーなものは英語、という具合に。
翻訳費用、版数管理でコスト増大->値段上昇にもつながりかね
ないので難しいところです。
海外のソフトウェアの場合、一次情報・最新情報は今も昔も英語
が主流でしょう。更新分がWebで確認できればよいのではないでしょうか。
b. 日本語のドキュメントもまともに読めない。読んでいない。
マニュアルが読みにくい、使いにくい、っていうのはあるかもしれませんが
PDFを検索することくらいはできるはず。
c. ベンダサポートなら何でも知っていると信じ込む
契約の体系にもよります。ベンダはあなたの所の固有の条件に
左右されることまでは知りえません。
専任の担当が付いているようなところなら何か調べてくれるかも。
これも業務内容と契約次第ですかねえ。
答えてくれる窓口なら窓口で、答えてくれないなら別のところに
問うべきです(同僚とか先輩とか別の窓口を知ってそうな人とか)。
答えてくれない窓口にクレーム入れてもしかなたい。
さっさとあきらめて動いた方が賢明です。
d. 自分が理解できなくても教えてくれる
提示された情報の表現と受け手のスキルに依存します。
ベンダーは正確さのために専門用語を使っているかもしれません。
アプリのコマンド名、OSの機能など妥当な専門用語を
理解できないならばのスキルの問題です。
最近は内部統制とかITILみたいなのも流行ってますね。
自分が理解してないことをことさら掘り下げてもしかたない。
どこにも世界の事をすべて理解している人はいません。
丸投げの元になりえますし不誠実だと思うのなら勉強あるのみです。
e. でもサポート契約内容は読んでいない。
殆どの企業ではおろそかになっているのではないでしょうか。
顧客満足は結構ですけど、契約締結時の文書はちゃんと読んでいますか？
サービス利用にかんして直接利用する人がその内容を理解するようにしていますか？
内容に不満があればプランを換えるとか取りやめる・保留するとかしない
とお互い不満を憶えることになります
でも、さまざまなしがらみのために嫌々買ってたり、
嫌々売ってたりするんでしょうね。
f. SLA＝顧客の機嫌
そういうところはそういうところでいいんではないでしょうか。
双方の合意があれば。
大勢が踊ったらみんな踊る。
踊る阿呆に見る阿呆同じアホなら踊らにゃ損損。
守るべき日本文化ですかね。でも他人に波及させないで欲しい。
g. コンピュータは完全であるべきものだという過信
開発は嘘をつくのではありません。
バグを入れたくて入れるものでもありません。
ただ、間違いを（後略
幸い日本人の国民性からサービスや物作りの質は非常に高いというのはわかります。
しかし、にんげんの作ったものですから完全なものは世の中にはありません。
苦情を訴えるだけでは世の中がかわらないのは２ｃｈもマスコミも コンピュータ
の世界も同じです。
様々なハードウェア供給元があって、多くのハードウェアそれぞれも多数の
3rdパーティから供給されてて、そこに乗るソフトも多様でバージョンもあって、
システム固有の設定もある中で、
規格、実装（開示されてないものも含む）仕様などでなんとか成り立ってるものが
いつも完全に動作が保証されるなんて期待することが間違いです。
サービスを提供する側は 財務、組織、工数で現実的にできることしかしませんし、
受ける側もそのことを理解した上で取引する心構えをもちましょう。
h. 実装と仕様を区別しない。
見慣れない現象をなんでも仕様のために発生していると勘違いする人がまれにいます。
実装は仕様をもとにコード化されますが、「予想もしないような」トラブル時に
「こう動きます」なんて文書はありえません。
一応参考になるのは Joel on Software かな。
http://japanese.joelonsoftware.com/PainlessSpecs/2.html
j. 必要なデータがあればどんな事象も説明できるはずだ
必要なデータというのが一方だけで出せるものとは限らない。
再現可能ならば、1台目のマシンで発生したら2台目ではどうか、
��台目でも発生して、３台目で発生しないなら
��台目２台目の共通点と３台目との違いを探すアプローチは非常に有効。
ポイントがわかれば早い。
風邪の診断で最初からDNA解析する医者は２００７年の２月時点では
いないでしょう。問診から始めてカルテ作って血液検査して、
というようなことをするはず。
以上をふまえて無視しつつ 「次回 」 へ続く。
お仕事では、日頃問題があったりトラブったり顧客に再現しない問題の原因追及を
求められたりするようなソフトウェアを扱っていたりするわけですけど、
アメリカとかヨーロッパとかだと障害発生したとき「すぐ復旧すればOK」
みたいな感じで話が進むらしいのだけど、パッチひとつ当てるにもどうのこうの
言う企業は日本には多いので、日本の企業（特にソフトウェアベンダがアタマの
あがらないほどデカい企業）に好まれると思われるパッケージ製品について
考えてみたい。
サポートの主観が強いので開発を主業務としている人の声も欲しいな。
傾向をみるとこんな感じ。
a. 英語のドキュメントしかないと怒る
b. 日本語のドキュメントもまともに読めない。読んでいない。
c. ベンダサポートなら何でも知っていると信じ込む
d. 自分が理解できなくても教えてくれる
e. でもサポート契約内容は読んでいない。
f. SLA＝顧客の機嫌
g. コンピュータは完全であるべきものだという過信
h. 実装と仕様を区別しない。
i. すべて仕様として記述されているべきだ。
j. 必要なデータがあればどんな事象も説明できるはずだ。
科捜研はドラマほど何でもわかるわけじゃないです。
独自開発のプロジェクトならともかくパッケージ製品は
いち顧客（とその会社）のためだけに販売されているわけでは
ありませんから。
---------------------------------------------
a. 英語のドキュメントしかないと怒る
開発元が海外のベンダの場合そういうことは結構あります。
一部は日本語、マイナーなものは英語、という具合に。
翻訳費用、版数管理でコスト増大->値段上昇にもつながりかね
ないので難しいところです。
海外のソフトウェアの場合、一次情報・最新情報は今も昔も英語
が主流でしょう。更新分がWebで確認できればよいのではないでしょうか。
b. 日本語のドキュメントもまともに読めない。読んでいない。
マニュアルが読みにくい、使いにくい、っていうのはあるかもしれませんが
PDFを検索することくらいはできるはず。
c. ベンダサポートなら何でも知っていると信じ込む
契約の体系にもよります。ベンダはあなたの所の固有の条件に
左右されることまでは知りえません。
専任の担当が付いているようなところなら何か調べてくれるかも。
これも業務内容と契約次第ですかねえ。
答えてくれる窓口なら窓口で、答えてくれないなら別のところに
問うべきです(同僚とか先輩とか別の窓口を知ってそうな人とか)。
答えてくれない窓口にクレーム入れてもしかなたい。
さっさとあきらめて動いた方が賢明です。
d. 自分が理解できなくても教えてくれる
提示された情報の表現と受け手のスキルに依存します。
ベンダーは正確さのために専門用語を使っているかもしれません。
アプリのコマンド名、OSの機能など妥当な専門用語を
理解できないならばのスキルの問題です。
最近は内部統制とかITILみたいなのも流行ってますね。
自分が理解してないことをことさら掘り下げてもしかたない。
どこにも世界の事をすべて理解している人はいません。
丸投げの元になりえますし不誠実だと思うのなら勉強あるのみです。
e. でもサポート契約内容は読んでいない。
殆どの企業ではおろそかになっているのではないでしょうか。
顧客満足は結構ですけど、契約締結時の文書はちゃんと読んでいますか？
サービス利用にかんして直接利用する人がその内容を理解するようにしていますか？
内容に不満があればプランを換えるとか取りやめる・保留するとかしない
とお互い不満を憶えることになります
でも、さまざまなしがらみのために嫌々買ってたり、
嫌々売ってたりするんでしょうね。
f. SLA＝顧客の機嫌
そういうところはそういうところでいいんではないでしょうか。
双方の合意があれば。
大勢が踊ったらみんな踊る。
踊る阿呆に見る阿呆同じアホなら踊らにゃ損損。
守るべき日本文化ですかね。でも他人に波及させないで欲しい。
g. コンピュータは完全であるべきものだという過信
開発は嘘をつくのではありません。
バグを入れたくて入れるものでもありません。
ただ、間違いを（後略
幸い日本人の国民性からサービスや物作りの質は非常に高いというのはわかります。
しかし、にんげんの作ったものですから完全なものは世の中にはありません。
苦情を訴えるだけでは世の中がかわらないのは２ｃｈもマスコミも コンピュータ
の世界も同じです。
様々なハードウェア供給元があって、多くのハードウェアそれぞれも多数の
3rdパーティから供給されてて、そこに乗るソフトも多様でバージョンもあって、
システム固有の設定もある中で、
規格、実装（開示されてないものも含む）仕様などでなんとか成り立ってるものが
いつも完全に動作が保証されるなんて期待することが間違いです。
サービスを提供する側は 財務、組織、工数で現実的にできることしかしませんし、
受ける側もそのことを理解した上で取引する心構えをもちましょう。
h. 実装と仕様を区別しない。
見慣れない現象をなんでも仕様のために発生していると勘違いする人がまれにいます。
実装は仕様をもとにコード化されますが、「予想もしないような」トラブル時に
「こう動きます」なんて文書はありえません。
一応参考になるのは Joel on Software かな。
http://japanese.joelonsoftware.com/PainlessSpecs/2.html
j. 必要なデータがあればどんな事象も説明できるはずだ
必要なデータというのが一方だけで出せるものとは限らない。
再現可能ならば、1台目のマシンで発生したら2台目ではどうか、
��台目でも発生して、３台目で発生しないなら
��台目２台目の共通点と３台目との違いを探すアプローチは非常に有効。
ポイントがわかれば早い。
風邪の診断で最初からDNA解析する医者は２００７年の２月時点では
いないでしょう。問診から始めてカルテ作って血液検査して、
というようなことをするはず。
以上をふまえて無視しつつ 「次回 」 へ続く。
コメント
コメントを投稿
「コメントを投稿できるユーザー」の範囲は変更される可能性があります。