2006年09月04日

■教育を受けることの意味

自分がインストラクターだったから、というわけではないのだけれど、
そして、決して、どこかの会社の回し者、というわけでもないのだけれど(笑)、
教育を受けることの意味はちゃんとあると思う。

独学で現場に出た人と、体系だって学んできた人の違いは、
入り口の広さだと私は思っている。

どうしても現場で必要に応じてスキルを磨いてきた人は、その必要に応じてスキルを追加していくような形になる。時にそれは視野の狭さにつながることがあり、どうしても自分が経験してきた機能の中で対応しようと考えてしまう傾向がでてしまう。
逆にトラブル時の現場対応能力はたいてい現場でスキルを磨いてきたエンジニアの方が優れていることが多い。

最近でもエンジニアに「こんなことできないかな?」と聞かれて、
「こんな関数あったでしょ」と答えたりすることがある。
たいていは私よりノーツに詳しいはずの現場のSEだ。
「なんでそんなマイナーな関数をしってるんですか?」という反応が返ってくる。
それは満遍なく機能を見てきたせいなのかもしれないし、
私がノーツな人だからかもしれない(笑)。

教育の受講に関しては費用の問題を筆頭に、現場を離れられないなどの問題があることは承知しているが、少し現場で苦労した上で、教育を受けるというのが一番身につくのではないかと思う。
うまく行かないジレンマを知っているからこそ、どうやったらいいのか、と積極的に講師に質問したりもできるし、普段ならおっかなびっくり触っているシステムを再起動しほうだいだったりする。
私自身もそういう受講生が来たときが楽しくて話のしがいがあったな、ということを思い出す。

学問にはたいてい各論と総論がある。
現場では各論を磨き、教育で総論を理解する、というのが全体的なスキルを取得するのにいい流れなのだと私は信じている。

ただ、最近はNotes/Dominoの教育を受けることが教育機関が減っているので難しくなっているし、いいインストラクターと出会えるか、という点も運試しみたいなものだったりもするので、効果はそれ次第、という側面もあったりする。

物事を点でなく、線や全体像でみると新しく見えてくるものもある。
posted by せりあ at 18:20| Comment(6) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年09月01日

■使いやすいアプリケーション

社内の業務システムのほとんどがWebアプリケーションになっている。
確かにPCにソフトを入れる必要はないから、クライアントモジュールのバージョンアップに煩わされることはない。
開発側の都合でIEを強制的に使わせられることに辟易するくらいで(笑)。

だけど時々、これって使いやすいんだろうかとジレンマに陥ることがある。
最近は進化してきたとはいえ、やはり操作性は圧倒的に悪い。
表現できる範囲が狭いのと、セッションが切られる(一定の時間がたつとセッションを切る仕組みにしているアプリがほとんどだよね)。
何かを入力している時に電話を受けて、スタッフの質問を受けて、トイレに行ってきたりなんかするとたいていはセッションが切れる。
保存しておけばいいのかもしれないけどバタバタしてるときには忘れるのが常。
WWWメールもいろいろなアカウントを持って使っているけど、どこでも使える便利さを除けば、それほど使い勝手がいいとは言えない気がする。

よくノーツが使いづらいという話を聞くけれど、私にしてみるとブラウザベースのアプリよりよっぽどましだと思うのだけど、使い方がWindowsライクでないのが致命的なんだろな。


開発者が検索の機能を意識しなくても簡単にビューの検索や全文検索ができる、みたいにノーツクライアントだから提供される便利な機能を捨てがたいと思ってしまう私はやっぱり『ノーツな人』なんだろうと思う(笑)。

次のhanoverに期待してるのはノーツクライアントのよさを残してリッチクライアントのよさも引き出すこと。
業務でアプリケーションを使う人の本音は『直感的に操作できること』と『仕事の流れをとめないこと』、そして『同じデータを何度も入力させないこと』みたいな現実的なもので見かけの派手さではない。
そんな気持ちをくんでくれて、使いやすいものになるといいのに。

話がまとまらなくなったけど、目的地に着きそうなのでこの辺で。
posted by せりあ at 09:25| Comment(0) | TrackBack(1) | MISC | このブログの読者になる | 更新情報をチェックする

2006年08月31日

■伝わらない

昨日のある管理職との会話。

『そういえば、ノーツってなくなるんだって』
「え?何の話ですか」
『ほら、何とかって製品に統合されてなくなるんでしょ』
「いえ、あの、それは逆ですよ」
『そうなの?おかしいなぁ』

といういとも不思議なもの。
多分、私の勤めている会社はNotes/Dominoのライセンスを売りまくっている会社のはず。
管理職ですらこの認識では現場はさらにひどいだろ。

どうしてもノーツを使いまくれなんていうつもりはないけど、
こんな噂チックな話は出回るのが早いし、こういう会話が客先でも繰り広げられることは容易に想像できる。

なぜ、情報はこんな風に歪んで伝わるのだろう。
もちろん正しいソースから情報が伝わらないことや、バイアスのかかった受け取り方や伝え方をするからだろう。
それはメーカーとしては致命的な情報伝達になってしまう。
たまたま今回のケースは私が知っている範囲の情報でフォローができたけれど、その確率の方が低そうだ。

製品のアピール力が足らないのではないかと感じるこの頃。
ま、製品戦略もここ数年行ったり来たりしていたせいなのかもしれない。
つい最近まで私の顧客も管理職と同じことを言ってたのも事実。
価格とか、技術とか、サポート以前に製品そのものが不安になるようでは困るよね。
小さい会社の製品なら仕方ないけど。

これからのアピールに期待します。
posted by せりあ at 08:22| Comment(4) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年08月29日

■Search

ふと、思うことがある。
仕事をしているといいながら一日の大半を探し物に使っているのではないかという疑問だ。

あの作りかけのファイルどこにあったっけなぁ?
あのメールに詳細が書いてあったはずなんだけど、いつもらったメールだっけ?
ファイルサーバに入ってるドキュメントの最新版てどれなんだろう、って。

PCが誕生して25年。
Internetが一般に普及し始めて10年近く。
個人がそれそれ一台のPCを使うようになって数年。

私たちは情報の波に飲まれて毎日を過ごしている。

押し寄せてくる情報の中から自分が必要とするものを選びとることも一つの技術になっている。
情報が増えたことで、欲しいものが見つかりにくくなってしまい、
見つけてもなお、入手した情報を体系的に保管し、さらに探しやすくしておかないと次に使おうと思ったときにまた探し物をすることになる。

だからこそ、いま『検索すること』は注目を浴びる技術になったのだと思う。またマシン性能の向上や検索アルゴリズムの進歩が私たちに『検索する』という古くて新しい技術をさらに使いやすく提供してくれているのだと思う。

だけど、便利になれば便利になるほど、さらに便利を求めるのが人の常。

私も検索で私がアクセスできるすべての電子データ素材(本当はそれだけじゃないんだけど)を探せたらいいなと思ってしまう。
それがローカルに保存されているメールだろうが、WEBメールアカウントのメールだろうが、ブログの記事だろうが、オフィスのファイルだろうが、Notesデータベースだろうが。
それを何とか実現しようとしているのがGoogleであり、GoogleDesktopなのだろうと思う。
それでもGoogleと異なり、Desktopにはサイトランキング的なアルゴリズムの検索ではないと思われる。
当然、ローカルに保存されているデータにはURLリンクはないのだから。
検索結果をみると、全文検索のように見える。(もし違っていて、ご存じの方がいたら教えてくださいな。)
今後、もしDesktopに保存されているデータの検索に優先順位をつけるとしたらきっと人の行動パターンになるのではないかと思う。

いつかこんなものが探したいな、と思うと(思考を読み取るようなデバイスが必要かもしれないけど)、検索結果が出てくるような日がくるのだろうかという夢見たいな現実を思うと検索という技術から目を離せない気がするのだ。

そいうい意味ではNotes/Domino自身の検索機能はデータを蓄積する簡単さに比べるとまだまだ使いづらいし、何たって遅い。
検索に関するすばらしいアイディアがNotes/Dominoにも反映されたらいいな、と思わないこともない。

使いやすく、早くて、欲しいものが見つかる検索って魅力的。
そこにもちろん探せてはいけないものが見つからないというセキュリティにも気にかける必要があるとは思うけれど。
posted by せりあ at 17:53| Comment(0) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年08月23日

■強固すぎるセキュリティ

Notes/Dominoファンの私でも、すべてが素晴らしいと思っている訳ではない。
もう少し改良して欲しいと思う部分もいろいろ。

その中のひとつがIDファイルの扱いだ。
特にNotesクライアントを使うとき、IDが私たちを悩ませることがいくつかある。

一つはそのファイルが基本はローカルに保存されること。
複数のユーザーが一つのマシンを使うとき、利用するPCがころころ変わるとき、これは不便だ。
それでもこれは回避の方法がある。
サードパーティーの製品をつかったり、比較的、新しいバージョンのNotesであればローミングの機能がある。

もっとも不便だと思うのはIDファイルのパスワードの初期化ができないこと。
もちろん事前のバックアップやID復旧の機能を使えば何とかなる。
だけどどちらも最初から計画していないとダメで、後から気づいて何とかできる機能がない。
(私の認識では、まだないと思っていますが、もしあったら教えてください。)

しかもID復旧って手順が煩雑すぎて、垣根が高い。

だからセキュリティ上の問題があると分かっていながら、全員のIDのバックアップを取る羽目になってしまう。
さらにそれを権限を絞ったファイルサーバーに置くか、ローカルPCに保存し、さらに念のためにテープなどの外部記憶媒体に保存することになる。

確かにセキュリティを強固にするというのが重要なことも分かる。
だけどこのIDファイルのパスワード初期化だけはもっと簡単になってほしいと思うのだ。

〇xchange(ま、設定はADだけど)とか、〇endmailレベルでオペレーションできる製品を知ってる人に取っては、このID管理に関するストレスは大きいと思う。

どうにかならないものなのかな?
posted by せりあ at 09:08| Comment(0) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年08月18日

■管理クライアントは便利だけれど。

管理クライアントは確かに便利だけれど、これを使っていると、
管理系のデータベースがどんなものがあって、それぞれの役割範囲が
分かりにくいような気がする。

ドミノディレクトリの内容ですら、別々のタブであっちいったり、こっちいったりで
参照しなきゃいけないのは私にとってはどうもなじみづらく、
結局、クライアントで普通にワークスペースにアイコンを追加して、
管理用タブを作ってしまう私はやっぱり第一世代だから?(ね、茶坊主くん)

人間はなかなか馴染んだものを手放せないという例なのかもしれない。
posted by せりあ at 21:10| Comment(2) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年08月16日

■パスワードクオリティスケールの怪

ユーザーに入力してもらうパスワードの難しさを設定するときに使う機能なんだけれど、
使い勝手が非常に難しい。

いつも説明に困ってしまう機能なのだ。
なぜかというと、設定値と設定できるパスワードの内容がユーザーから分かりにくいアルゴリズムになっているから。
例えば、パスワードは8文字以上で数字を含むという設定がしたくても厳密には不可能なのだ。

設定値は数字で指定できるけど、それはパスワードの難易度で文字列ではない。
しかも複合的な条件で判定しているので場合によっては英文字だけだと8文字必要だけど、数字や記号を入れると7文字でもいい、みたいな判定をする。
その条件も全ての設定値に対して詳しい説明がヘルプにあるわけでもない。
非常に困ったちゃんな機能なのだ。

パスワードの設定パターンが明確に分かってしまうことは、ハッキングを考えたときに悪く働くと考えたのだろうか。
この機能を考えた意図は私には分からない。


エンドユーザーに説明しづらいことが理由でこの機能は導入の検討はしてもお蔵入りになる可能性が高いのも現実だ。

実際に使っているユーザーさんはいるのかな?
posted by せりあ at 08:56| Comment(5) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年08月11日

■ノーツらしさを知ること

■NAT33's Blog−『新人に教えたいこと その1』へのTB

上記の記事を読んでちょっと感じたことを書こうと思う。

ノーツの統合開発環境はバージョンが上がるごとに進化している。
昔は@関数しか使えなかったといっても誰もピンとこないだろう。
開発の選択の幅も広がったし、VBやJavaを知っている人がとっつきやすく
なった側面もあるのだろうと思う。
それでも私が誰かにノーツの開発を教えるととしたら、最初はLotusScriptすら、
使わせずにちょっとしたワークフローのアプリケーションを作ることを指示するだろう。

それはノーツらしさがそこにあると思っているから。
もちろん今はWEBクライアントの対応などでノーツ独自の世界だけでは表現が足らないと思われる部分もある。
でもノーツクライアントを使うのであれば、@関数とノーツ個々のオブジェクトが持っているプロパティを利用してそれなりのアプリケーションを作ることができる。
そうしてノーツのノーツらしい部分を知った上で、その特性を生かした開発を進めて
欲しいと願っているからだろう。

ノーツがはやり始めたころ、開発が簡単だといわれた極意はそこにあると思っている。
そして、きっと、初期のノーツの開発環境のコンセプトはきっとそこにあったのだと信じて疑わない。
開発言語というスキルがなくても、LEGOで部品を組み合わせていくように、ちょっとしたアプリケーションが作れて、使い回せる。
だからプロジェクトごとにどんどん新しいデータベースを作るのだと。

時代は少し変わってしまった。
開発を取り巻く環境も変わってしまった。
エンドユーザが簡単にデータベースを作る時代ではなくなってしまった。
それは情報管理やセキュリティ等の問題ともあいまっているのだと思う。


そんな環境の中で、新しくノーツの開発を学びはじめる人たちは、言語に強い(開発になれた)人が多くなり、自分が使い慣れたツールを使おうとする方向に向かう。
しかしそれは時として無用にコードを書いてしまうという落とし穴にはまることもある。
それは開発者にとっても、顧客にとっても不幸な出来事だと思う。

これからノーツで開発を学ぶみなさん、
他の言語を習得してから、ノーツ開発に従事したみなさん、
どうか、プロパティでできる基本の機能や@関数の便利さを知ってください。
@関数でできることをわざわざLotusScriptでやる必要はないのです。

この記事を書きながら、ふっと、思いつき。
@関数だけで作った使いやすいデータベース募集、なんてイベントがあったら面白くないですか(笑)?
制約があると人は知恵をたくさん使って解決しようとするものね。

私の夏休みの宿題にしてみようかな。
どうですか、みなさん、自信のある方はいますか?
posted by せりあ at 21:08| Comment(9) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年08月10日

■サポート期間の話

私が面倒を見ているシステムはお役所ばかりだ。
彼らのシステムはリースで四年くらいのスパンで入れ替えることがほとんど。
そのタイミングによっては中途半端な時期にサポート切れを迎えてしまう。

最近はどんなソフトもサポート期間が短い。
Domino6の初期に入れたシステムが来年にはサポート切れになる。

安定しているシステムをサポート切れだけの理由でバージョンアップをするという必要性を感じないし、次のリプレイスとの間隔が微妙だというケースもあり悩ましい問題として私にふりかかる。

機能が付加されて、新しいバージョンがでることは技術者として楽しみではある。
だけど運用する立場にたったとき、これはまた違う側面をもってSIerを悩ませる。

進化のスピードが早すぎることがひとつの原因なのだとわかっている。
ただ時々、工業製品の規制のように基準があったら顧客にももう少し説明しやすいような気もする。

部品を十年とっておくというレベルまでは行かなくても、もう少し工夫はないものか。
ま、Dominoの場合はセキュリティー対策系の製品よりは寿命は長いのだけれど。

さて、どうしたものかな。
posted by せりあ at 09:06| Comment(0) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年08月04日

■エンジニアとチェンジニア

私の素朴な疑問を解決してくれた茶坊主くんに感謝しつつ、
Notes/Dominoから多少それることを承知でこのトピックを書こうと思う。

私をコンピュータの世界に導いた先輩の台詞で納得した言葉がある。
「最近、この業界はエンジニアよりもチェンジニアが多い」と。

表現としてはちょっと大げさかもしれないけれど、
Windows世代のエンジニアにそういう傾向が強いことを感じていた私は
なるほど、上手いことを言うな、と感じた。

ようするにこういうこと。

システムで何か上手くいかない現象が起こったときに、
きちんと原因を調べずに、相性という表現を使ったり、
原因が分からないのに、闇雲に設定変更をして「上手くいきました」と
言うことが多いと。
その行動はエンジニアではなく、チェンジニアだというのだ。

茶坊主くんのように、起こっている事象に対してそれが起こる理由を追求し、
そのアーキテクチャを理解すると、上記のような対応にはならないだろうと思うし、
自分のシステムに対してはそういった姿勢で対応したいと思っている。
どの設定をしたらどんな機能が動くかを知ることも重要だけれど、
どんな仕組みでその機能が動いているかを理解することで、
さまざまな場面で応用がきくようになっていくのだと思っている。

どんどん好奇心を活用して、なぜ、どうしてを追求したいと思う人が、
エンジニアに向いているのかもしれない。

みなさん、チェンジニアになっていませんか?

posted by せりあ at 22:16| Comment(6) | TrackBack(1) | MISC | このブログの読者になる | 更新情報をチェックする

2006年08月03日

■QuitとExit

ドミノサーバの終了のコマンドはQuitでも、Exitでもいい。
DOMINOとしてはこれで問題ないと思う。

どうでもいいけど私の失敗談をひとつ。
かつて勤めていた会社のDOMINOサーバにリモートでアクセスして、
メンテナンスをしたあと、ただ、コンソールを閉じたかっただけだったのに、つい、DOS画面を閉じる時の感覚で、なんとExitをしてしまった私。
いつもはquitを使っていたのでExitでもDOMINOサーバが落ちることが、
すっかりと頭の中に入っていなかったんですね。
事態に気づいて、休日にあわてて会社に飛んでいきましたとさ。
ま、小さい会社でインストラクタがシステムの管理も兼任だったので、
あまり厳しくは問い詰められなかったけれど、本人はもう、真っ青でしたよ。

そのときの教訓。
コマンドは打ってから実行する前にもう一度、正しいかを確認しよう。

あ、もちろん当たり前のことですが。
posted by せりあ at 01:26| Comment(0) | TrackBack(1) | MISC | このブログの読者になる | 更新情報をチェックする

2006年08月01日

■CPUライセンスの行方

最近、マルチコアのサーバが増えてきたこともあって、
各社ともこのマルチコアのCPUライセンスの方式を検討してきている。
岩間さんのブログでも紹介されていたけれど、
IBMはCPUの処理能力によりValueを計算する方式にするという。

マルチコアCPUで力を発揮するSUNのT1シリーズのプロセッサの場合、
1CPU4コアで、普通の2CPUのサーバの0.6倍くらいの費用になるらしい。
この計算で得をするのはSUNになるのだろうか?
というのも、このT1プロセッサの場合、
CPU単体の処理能力というより、各コアで多くのスレッドを実行できることで、
その優位性を強調している仕組みなのだから、CPU数は減りコアが増える。

例えばDominoサーバをSUNのサーバで構成しようとすると、
以前のシリーズよりもT1シリーズで構成を組んだほうが、
CPUライセンスが安くなるような気がする。
(サーバのパフォーマンスをどう比較するか、という問題はあるが)

Dominoを含むIBM製品に関わらず、このCPUライセンスの体系は
どこのベンダーもどうすべきかというのを悩んでいるところなのかもしれない。
もう少しじっくりその動向を見て行きたいと思う。

いずれにせよ、安くなることに越したことはないのだけれど。
posted by せりあ at 20:43| Comment(0) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年07月26日

■小休止

このブログには毎日たくさんの人が訪れてくれる。
自分が普段書いてる普通のブログとは比べ物にならない。
それはNotes/Dominoというキーワードにひきつけられて
来てくれる人々なんだろうなと思う。

そういう意味ではちょっとばかり期待を裏切っているかもしれません。
一つ一つの技術に特化して何かを説明するという方向には今のところ、
向かいそうにない気がします。

それは自分自身が今、最前線にいないせいなのかもしれませんね。
そういう内容を期待して下さっている方にはごめんなさい。
また、どうしてもネタ的に鮮度にかけるところもあるのかしらと
思っていますが、この路線で書いていく予定です。

最新の技術についてはお友達が書いてくれそうな気がしてるのだけど、
まだ、ブログの道にたどりついていないようです(笑)。

余談。
このサイトで使っている[doctornotes]という名前はNotesインストラクター
だった人たちには懐かしいんじゃないでしょうか?
私もいまだにテストユーザを作るとつい、この名前を使ってしまいます。
テキストの中にいつも出てくる有名な名前なのです。
あ、著作権に引っかかる?これ。

とりあえず、そんなところ。
posted by せりあ at 18:21| Comment(4) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年07月22日

■技術者に必要なもの

IT系の技術者にとって必要な道具の一つはやはり英語だと思う。
それはNotes/Dominoを扱っていようが、その他のプロダクトを扱っていようが、
変わらない普遍の事実だと思う。

この業界で扱われる主要なソフトの多くはアメリカからやってくる。
最新情報を手に入れようとおもうとどうしても英語の文献が多くなる。
私がノーツのインストラクターになったころは日本語の情報はほとんど、
ないに等しかったので、英語で情報を仕入れるしかない時代だった。

ちなみに私は中学、高校と英語の成績は低迷していた。
ちっとも面白くない教科だと思っていた。
もう少しまじめに勉強をしておけばよかったかもしれない。
大抵の場合、大人になってからそう思うもの。

たまたま私の場合は大学生のときに国際ボランティアに参加して、
コミュニケーションが取れないことのつまらなさに気づいて英語を
勉強していたことが社会人になってから少しだけ役に立った。
技術資料の英語はさして難しくない。
中学生ぐらいの英語の知識と、専門の単語が分かるようになれば、
ある程度は想像がつく。
利用されている専門的な言葉はほとんどカタカナ化されているので、
読んでいるうちに、「ああ、あれのことか」と気づいたりする。

もともとおしゃべりな私が英語しかコミュニケーションの取れない世界で、
押し黙っているストレスが私を学習に向かわせたのだと思う。

とはいえ、ある日までそれは技術書を読むためと、
テレビドラマや映画を楽しむため、ぐらいにしか使われなかったスキルだった。
でも、英語を勉強し続けたことで私は一つのチャンスに後ろ向きにならずにすんだ。

「仕事でマレーシアに行ってみない」と声をかけられたとき、
好奇心旺盛な私はその先に何が待っているかも分からず、
「行きたい!」と二つ返事で答えたのだった。
それまで外国人と仕事をすることもなかった私が、いきなり外国で仕事なんて、
よく思い切れたものだな、と今でも自分に感心する。

その話が私に舞い込んできたのはNotes/Dominoに詳しかったこと、
そしてほんの少し英語が分かることが理由だった。
英語という比較的スタンダードな言語を理解できることは、
技術者としてのチャンスを広げることになるのだと思う。

マレーシアでの珍道中はまた別の機会に。
posted by せりあ at 18:20| Comment(4) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年07月20日

■OSに依存しないシステム

ある日のこと。

突然に小さな企業のメールや情報共有を一手に担っていたフル活動していたDominoサーバーが息を引き取った。
幸いデータバックアップは取ってある。
代替機もある。
いったい何時間で環境復旧ができると考えるだろう。

あっという間に別のサーバーに構築できることはDominoサーバーの利点だと思う。
サーバーIDとドミノディレクトリを含むデータさえあればそれをOSプラットフォームを問わずDominoサーバーをまるで今まで動いていたものと同じように立ち上げることができる。

こんなに柔軟性のあるシステムを他に見たことがない。

冒頭のお話ではOS環境が整っているマシンがあり、
データ復元と設定確認、基本的な稼働テストを含めて三時間強だった。

私はそんなちょっといい加減とも思えるその仕組みに何度も助けられた。ハードを含めた移行でも計画が立てやすかっかりもする。

OS依存のグループウェアでは難しい芸だ。
タグ:Notes/Domino
posted by せりあ at 09:17| Comment(0) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年07月18日

■名前を変えること-システム管理プロセスって便利じゃない?

つい先日、複数の組織が統合された後のシステムリプレイスを期に
組織名とドメイン名を新しいものに統合したいという案件があった。
しかもメール、アプリケーションのデータはそのまま移行するという。

ドメイン名はさておき、組織名の変更は骨だな、と感じた。
アプリケーションでどの程度、使われているかが分からないことも
不安の一因だったと思う。
最終的にはシステム管理プロセスを利用したこともあり、思ったよりも、
苦労はせずにすんだ。きっと、作業が難しいというよりは、
その作業のプロセスを面倒に感じるのかもしれないと思った。

「名前を変えるのがそんなに大変なの?」という疑問を持つ人もいるかも知れない。
確かにいまのNotes/Dominoのバージョンでシステム管理プロセスを使えば、
それほど難しくない。この機能がなかったときのことを考えると進歩が嬉しい。
(この機能はR4で追加された機能で、最初は使いもにならかなったような記憶がある)

システム管理プロセスで名前の変更をするとまずユーザ文書が変更される。
その後、グループ文書も、その他のアドレス帳文書も、そしてデータベースのACL、最後にはデータベースに含まれている読者名、作成者名も変えてくれる。
(それでも独自で開発したアプリケーションで読者名フィールドや作成者名フィールドを使わずに名前を取得する仕組みを作ってしまったりすると、手動での対応が必要になるが)

ふと、この名前を変える行為は人間が姓を変更するときの手続きに似ていると思った。
名前を変える必要があるところを順繰り変更していく、というその様が。

ユーザ文書は実生活において戸籍のようなもので、
結婚や離婚をして姓が変更されると、まず、これを届けによって変更される。
それですべての作業が済めばたいしたことはない。
人間社会では銀行のキャッシュカードを変えて、クレジットカードを変えて、
パスポートの名義を変更し、契約しているあらゆる氏名を変えて行かなければ、
利用することができなくなるのだ。
その過程ではやれ、住民票をもってこいだの、戸籍謄本をとれ、だの、
面倒なことが付随する。しかも平日の営業時間帯に本人が来い、というのもある。

Notes/Dominoで処理をするなら、本人は受け入れの処理をするだけでいいし、
システム管理プロセスでほとんどの仕事をやってくれる。
結婚、離婚を経験した私としてはこの世界にシステム管理プロセスのような仕組みが
あれば、銀行や役所の窓口で待たされることもなかったのに、と思う。

こんな風に意外に便利なこのシステム管理プロセスをきちんと
使いこなしている管理者にはあまり出会ったことがない。
システム管理プロセスでできることとその利用方法が様々であること、
処理のタイミングが分かりにくいこと、システム管理要求データベースの複製が
きちんと取れる必要があることなど、確認すべき項目が多いことがその理由なのかもしれない。

こんな風に便利に使っています、という方がいらしたら是非、ご指南ください。
posted by せりあ at 18:58| Comment(2) | TrackBack(0) | MISC | このブログの読者になる | 更新情報をチェックする

2006年07月15日

■できることを探そう

ドミノ仲間の茶坊主くんがブログを始めようと思う、とメールで決意を語ってくれた。
私もぼやぼやしていられないぞと思った。
煽られやすい性格な私。
しかもしばらく現場からは遠ざかっているから、技術的なことをバリバリ書く、というのも難しそうだ。

だけど、インストラクターを経験してから、SEそしてプロマネになった私だからこそ、書けることもあると開き直って初めてみることにした。

真面目だけど、柔らかめで、思いを伝えられたらいいなと思う。
熱い思いは必ず伝わるものだと信じているから。
試行錯誤しながら書いて行くつもりですので、ご意見をいろいろ聞かせてくださいな。

これをきっかけにコミュニティーが広がるのを楽しみかな。
posted by せりあ at 10:56| Comment(0) | TrackBack(1) | MISC | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。