顧客ヘルプデスクの裏話

Copyright © 2015 NEOAXIS CO., Ltd. All rights reserved.
顧客ヘルプデスクの裏話
ソリューション第2事業部
営業部主査佐藤正彦
ナレッジソリューション部 Notesエバンジェリスト阿部覚

Copyright © 2015 NEOAXIS CO., Ltd. All rights reserved. 1
ネオアクシスの会社概要
【本社：アクセス】東京メトロ丸ノ内線「西新宿駅」徒歩3 分
都営大江戸線「都庁前駅」徒歩7 分
ＪＲ・京王・小田急「新宿駅」徒歩9 分
ネオアクシス株式会社
1億円
188人
代表取締役社長高橋正行
ITホールディングス株式会社（100％）
（東京本社）
〒160-0023
東京都新宿区西新宿八丁目17番1号
住友不動産新宿グランドタワー
（西日本支社）
〒530-0003
大阪府大阪市北区堂島1-2-5
堂北ダイビル
（秋田営業所）
〒018-0402
秋田県にかほ市平沢字山王森4-5
1979 年 5月 18日常務取締役山本修司
（ソリューション第１事業部長兼社長室長）
取締役海老江茂和
監査役（社外）山口知昭
約３5億円
設立
資本金
社員数
代表者会社名
事業所
株主
取締役
事業規模

グループウェア
お客様の環境に応じた最適な情報技術基盤をご提供いたします。

本セッションでは・・・
顧客常駐でのサポート体験から
ややアプリ技術よりのお話をさせていただきます
本セッションの構成は
★サポート時のエピソード中心で
• ユーザーサポート編
• アプリ管理編
★サポートの立場から、アプリ開発についてひとこと
• 内作デベロッパー編
トレンド技術ではなく、従来からの技術者もお分かりいただける内容・・だと思います。

ユーザーサポート編
「Notesのインストールがうまくいかないです」
遠隔の事業所に限り、ユーザー自身によるNotesインストールをお願いしています。
このお問い合わせは、最近増えていると思います。
私の経験しているスタンダード版のインストールに限っても
・インストールを開始したら、WindowsアカウントのID,パスワードを要求されてしまうこと
が増えた（ここで管理者のID,パスワードを入れてもうまくゆかないことが多い）
・インストールの種類が増えたことによる混乱
「マルチユーザー」と「シングルユーザー」
(Windowsのアカウントによっては、どちらか選べないことあり）
経験した客先では、専用の管理者アカウントで
Windowsにログインしてから
インストールを行う手順に統一し混乱を回避
できればIBMさんに、Windowsアカウントのタイプごとに可能なインストールのパターンを
出してほしい。

「いま、間違えて文書を消してしまいました」
もし、そのデータベースが他のサーバーと複製していて
まだ一方のサーバーには文書が残ってるなら
こんな裏技
残っている方のサーバーで、複製される前に
急いで文書を更新する！
ここをカチカチ
繰り返すのが
手っ取り早い

「いま、間違えて承認ボタンを押してしまった
元に戻してほしい」
もし、そのデータベースが他のサーバーと複製していて
まだ一方のサーバーでは文書が承認前なら
同じ裏技が使えます。
ポイントは
「わざと競合させる」
必ず勝者になるよう
大目にカチカチ更新

「昨日、間違えて承認ボタンを押してしまった
元に戻してほしい」
前述の方法には間に合わなかった場合
もしくは、そう都合よく複製DBなんてないよ、という場合
通常は「あきらめて最初から申請しなおしてもらってください」でしょうか？
何とか対応するようにしています。
「承認されたときに変更されたフィールド」を洗い出し、正しい値に修正すればよい。
承認ボタンのソースコード(式など）を追えば、どのフィールドかは一応わかるけど
そこをいちいち見なくても対応できる場合があります。

ここで、常備ツール
「文書書き出しアクション」
後述する個人ビュー
ビューで選択した文書(NotesDatabase.UnprocessedDocuments)の
全フィールドを書き出すアクション
★常備ツール★
サポート担当が持つ「ツールDB」に、役立つビューやエージェントなどの設計要素を
入れてあり、必要な時、対象のDBにコピーして使っています
• 「フィールド名」(NotesItem.Name)
• 「値」(NotesItem.Text)
• 「フィールド最終更新日時」(NotesItem.LastModified)
を、CSV形式で書き出す。
書き出してからExcelで開き、「フィールドの最終更新日時」でソート

フィールド更新日時順に
なったことで
承認時に更新されたフィールドが
明らかに
あとは承認前の適切な値に戻す。
（この例の場合、システムフィールド$UpdatedBy は修正対象外）
書き出してからExcelで開き、
「フィールドの最終更新日時」でソート

「文書書き出しアクション」
ビューで選択した文書(NotesDatabase.UnprocessedDocuments)の
全フィールドを書き出すアクション
自分の「ツールDB」に入れてあり、必要な時対象DBにコピーして使っています
CSV形式で「フィールド名」「値」「フィールドの最終更新日時」などを書き出す
これをExcelで開いたら、「フィールドの最終更新日時」でソート

「いつの間にか文書が消えていました」
・まずは実際に消えたかどうかを確かめる（消えていないこともけっこうある）
・実際に消えていたケースでバックアップがあれば、可能なら完全に戻す

・まずは実際に消えたかどうかを確かめる（消えていないこともけっこうある）
「ドラフト保存」「一時保存」のボタンが、現在のユーザーを唯一の読者にして
保存してしまう場合がある
DBの権限によっては、文書の作者以外がやってしまう場合も
Domino Administrator でフルアクセスアドミニストレーター権限を使い
DBを確認。

・実際に消えていたケースでバックアップがあれば、完全に戻す
もちろんコピペで戻してもいいですが・・・
バックアップ本体

「選択文書コピーエージェント」
ビューで選択した文書(NotesDatabase.UnprocessedDocuments)を
相手のDBにコピー(NotesDocument.CopyToDatabase)するエージェント
レプリカ同士なら、CopyToDatabaseによって、同じ文書IDに
※レプリカが異なるコピーDBの場合は同じにならないことも
※notes.iniの設定によって、レプリカでも同じにならないことも

・実際に消えていたケースでバックアップがあれば、完全に戻す
同じ文書IDで戻るので、文書リンクのリンク切れも防げます。
バックアップ本体
＜注意＞レプリカ同士の作業なので、作業途中でうっかり相互に
「レプリカの更新」をしてしまわないよう細心の注意を
複製の設定やレプリケータページを確認
・・・自信がない場合はコピペで戻しても

「DBアクセスできなくなった」
原因は、サーバーダウン
ただし、そのサーバーは、今は復旧しているのに（私はアクセスできるのに）
そこで電話先のユーザーさんに「DBのアイコンを読み上げて頂けますか」

「DBアクセスできなくなった」
さらなる原因は、レプリカ先のDBアイコン
Aサーバーがダウンしている間に、ユーザーがいちどDBを開こうとした。
いつものサーバーがダウンしていたので、リダイレクトされ
レプリカがある別サーバーのアイコンに自動で切り替わってアクセスを試みてしてしまった。
レプリカ先のBサーバーでは、一般ユーザーのアクセス権限が「なし」だった
Bサーバーが復活した後も
クライアントのアイコンは
切り替わったままだったため
アクセスエラーが続くことに

「みんなにはA,B,Cのカテゴリが表示されてるけど、
私が開くとD,Eしか表示されないんです」
権限の問題？
そもそも、たとえA,B,Cの各文書を見る権限がないとしても
A,B,Cカテゴリ(▼)だけは表示されるはず
ACLや文書権限をひととおり調べる。質問者さんにも閲覧権限はありそう。
みんな質問者さん

「みんなのビューにはA,B,Cのカテゴリが表示されて
るけど、私が開くとD,Eしか表示されないんです」
対面でパソコン画面を見せていただいていたのだが
ふと思いついて、質問者さんのパソコンに手を伸ばし
上↑矢印キーを押したら解決
（こんなオチもありました、ということで）

「Notesのパスワードが通らなくなった」
この質問には2つの原因が考えられるので、まずは切り分けます。
「どの画面で起きてますか？」
「Notesの起動中画面」
→ユーザーが自分の設定・変更したパスワードを本当に忘れてしまった
「ワークスペースでDBを開こうとしたところ」
→パスワードの有効期限が切れてしまった

アプリ管理編
ある日のアプリケーションエラーで判明した事実
当時のサーバー環境は Domino 8.0
このときの問合せは、あるアプリで処理が突然動かなくなったというもの
動かなくなった処理について検索すると
「その問題は、Domino 8.5.2で発生し、FixPackで修正」なんて記事が
その会社は外資系で、日本に置かれたサーバーたちも、本国からコントロール
もしや、とDominoディレクトリを調べると、サーバーが8.5.2にバージョンアップしていた！
→ 日本なら、周到にアナウンスして、とても計画的に行うバージョンアップ。
海外では、抜き打ちアポなし・・かもしれません。

アプリ管理編
「ビューの管理」を覗いてみたら
あるアプリDBの状況に疑問を持つ
文書数はそこそこあるけど、添付は全くない
１GB単位のサイズ
文書のわりに大きすぎるぞ
データベース異常肥大の障害事例かな？
Domino Administratorの
「ビューの管理」で確認

アプリ管理編
普通のDBだとこんな感じ。0~数%。
問題のDBでは、ここが99%くらいになっていました。

アプリ管理編
原因はどのビューも全列(30列くらい)に列ソートがついていたこと。
全ビューの列ソートを解除してから圧縮したら
DBサイズは激減、30MBほどに。
→ビューのつくりにもよるが
列ソートは必要なところだけにしないと
もったいないことに
なお、この経験当時はなかったのですが
最近のバージョンではこんなチェック項目もあります。
(効果のほどは未確認)

アプリ管理編
「ちゃんと経理チームに権限与えたのに、
経理からDBが見れないと云われました」
ちゃんとしてるようで

アプリ管理編
「ちゃんと経理チームに権限与えたのに、
経理からDBが見れないと云われました」
ちゃんとしてるようで
イマイチちゃんとしていなかった
DB管理をどこまでユーザー部門にゆだねるかは悩みどころ。

内作デベロッパー編
顧客先での開発担当者としては・・
少し趣向をかえて、顧客先のアプリ開発を行う担当者として
心がけていることから、

“設計資産をのこし
設計負債をなるだけつくらない”
「設計資産」のマイイメージ
• 再利用可能
• 作り手の意図がつかみやすい
• 無駄な動きが少なくパフォーマンスがよさそう
改修の生産性に貢献

では「設計負債」とは?
おそらく、Notes/Domino開発者の皆さんが、
既存アプリをメンテナンスするために
設計を覗いたときに
「これ、邪魔だな、やりづらい」、と感じてしまう、
いろんな障害物
短く「設計負債」としましたが、
「設計の余剰在庫」
というほうが当たっているかも

「設計負債」の例（１）
使われていない設計要素
• 一時しのぎのためのエージェントがいつまでも残っている
• 「山田確認用」という名前の共有ビュー（山田さんは昔の窓口担当者）
• 改修する前のフォームやビューがバックアップ用の名前で残っている
（「MainForm200705bkup」･･とか）
DBをXPages化したとします。
XPages やカスタムコントロールが DBの設計要素に加わります。
代わりに、Notesクライアント用の機能が使われなくなるのに、
Notes用のフォーム・ビュー・アクション・エージェント・・中身の機能ごと残るなら
それは設計負債になる･･かも、しれません。

「設計負債」の例（２）
要るか要らないかよくわからない設計要素や機能
それ自体は使われているフォームやビュー内の
アクション・ボタンが
いつの間にか使われなくなっていて
誰も使い方を知らないなんて場合
式で使用するための非表示ビュー。
@DbLookupや、GetDocumentByKeyで、間接的に利用されるもの
自DB内ならまだ確認しようがあるが、どこか他所のDBが間接利用してるかもしれない。。

「設計負債」の例（３）
世代別の設計要素
特に…フォーム
項目の追加変更のたびに、新しいフォームが追加されてしまうたぐい
MainForm
New_Mainform
MainForm3 世代別なだけでなく、名前のつけ方もバラバラなんてことも
過去の文書は過去のレイアウトで見たい。。
それももっともですが
過去の文書ではもういらないアクションやボタンもそのまま残存重複します。
各ビューの選択式も汚くなる。。
よほどのレイアウト変更でない限り、同じフォーム内で改修する工夫をします。

「設計負債」の例（４）
コードレベルの設計負債
：
End If
%Rem
%End Rem
改修の際に、変更前の元の処理内容を
念のためコメントアウトして残しておくたぐい
個人的な経験でいえば、
あとから見た担当者として９０％以上は不要で
コードを読み取る際の障害物でしかありません。

コードレベルの設計負債・・・これも
：
End If
'99年10月 xxxx対応 xxのxxxはxxするように変更
If xx = xxxx then
：
：
：
End If
' xxxx対応ここまで by TSB 佐藤
改修の際に、改修範囲と改修内容、変更者を明示するたぐい
（不具合発生時の責任範囲明示用？）
あとから見た担当者として
範囲なんて不要だし邪魔、トラブル時の切り分けになったのも見たことない
普段知りたいのは変更点じゃなくて、そもそもの処理概要

コードレベルの設計負債・・・これも
：
End If
'(20151118 S.Abe)
If xx = xxxx then ’xxする処理
：
：
：
End If
阿部は、改修範囲の先頭に、しるしを残すだけにしています。
（実際にはもっと右、Tab×20以上）
これすら要らないのでは。
式言語やXPagesのJS内ではほとんど見かけない(と思う)し。

「設計負債」の例（５）共有個人ビュー
初めて使う際にユーザーのデスクトップにコピーされるビュー。
共有個人ビューが問題なのは、そのビューに改修が発生したとき。
個々人のパソコン内にコピーされたデスクトップのビューを
改修する方法はないに等しいため
行いたい改修をすべての個人に反映するには、
都度、名前を変更した別の共有個人ビューを作る羽目に
・・コントロール困難な設計負債のひとつ
（フォルダペインを使い、
ナビゲータやアウトラインを使っていない場合は
ユーザーの画面に要らないビューが増える）

設計負債が多いほど・・・
当然、まとまった改修が必要になった場合に
要らないかもしれないものの分まで面倒見るので
見積金額がはねあがります。
古いアプリほど金食い虫になってしまう
Notes/Domino の経験が長い方ほど思い当たるのでは
(自戒・反省もこめて)

設計負債をへらしたい
改修を受注したベンダーの立場であれば、
無関係の設計要素まで勝手に消すことはできませんが
社内要員として顧客常駐している立場であれば
（その会社の文化にもよるが）消せる場合があります。
社内で何らかの改修を依頼された際に
改修の妨げになりそうな周囲の設計に対してクリーンアップ。
「このビュー使ってないですよね、邪魔ですか？」
ユーザー側担当者に見えるものは確認して消せたり。
不用意に消さずに、要らなそうなところは予めあたりをつけて様子を見ることも
常駐の立場なら可能（かも）。

設計負債の見分け方
「この設計要素は設計負債かも
（使われていないかも）」と思ったら
実際に、DB内で使われていない、
ほかの設計から参照されていないのを確認
• 標準の「ファイル - アプリケーション - 設計の一覧」
• 可能ならTeamStudioさんの「Analyzer」
要素の名前（フォーム名、ビュー名、コードのファンクション名など）が
ほかで使われていないかを検索
※別名での検索も忘れずに
※他DBと連携しているアプリは、自DBの調査だけでは漏れることがあるので注意
(特に、ビュー。ここは課題でもあるけど)
「フォーム」については、設計内でダイアログなどに使われてないのを確認するほかに、「その
フォームを使った文書がDB内にないのを確認」

「フォーム別日付順全文書ビュー」
その名通りの個人ビュー
文書として使われているフォームがわかるので、これを対象DBにコピーして
使われてないフォームのあぶり出しに使用
（前述の「文書書き出しアクション」もこのビュー内のアクション）

Notes/Domino 以外では？
もちろん、ほかのツールでも「設計負債」は起きえるはずです。
導入したばかりの新しいツールには基本存在しないため、
使い始めはスマートに見えても
年月を追うごとに増えてゆく可能性
設計負債のないツールがあるとすれば、機能がシンプルで、
複雑な業務要件に対応できないツールでは？
設計負債を発生させなくするのは困難だと思います。
現場で、ある業務がフェードアウトするときに
それを察知して
設計部品が自動でフェードアウトしてくれる仕組みを持つツール、ありますか？

Notes/Domino 以外では？
設計負債防止・抑制の観点でNotes/Dominoが良いとおもうところ
• 「設計の分析」機能や TeamStudio等の分析・解析製品で
あぶり出しがある程度可能
• "バージョンアップに伴う設計負債"とは、ほぼ無縁と思われること
他社製品はツールによって、下位互換がない機能が発生し
設計負債の重~い対応が必要になる
（Notes/Dominoは26年前のDBも現役で動きます）

安心してください
ノーツは
使い続けていいんです

顧客ヘルプデスクの裏話

顧客ヘルプデスクの裏話

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie 顧客ヘルプデスクの裏話

Ähnlich wie 顧客ヘルプデスクの裏話 (20)

Mehr von Satoru Abe

Mehr von Satoru Abe (20)

顧客ヘルプデスクの裏話