« 2009年6月 | トップページ | 2009年8月 »

2009年7月

更新と検索を重視する情報共有手段として使いたいWiki

社内ヘルプデスクで、いや、何も社内ヘルプデスクに限った事ではありませんが、仕事上の情報を共有する際、「共通の入れ物」があるととても便利です。メールは手軽さがポイントの書き物で便利なのですが、結局は個人管理になってしまい、「情報共有」として大切な「後から探せる」「更新出来る」という要素を満たす事が出来ません。世の中にはそういった要件に応える製品が沢山あると思いますが、私は手軽に使えるものとしてWikiをお勧めしています。

Wikiがどういう物かを簡単に(乱暴に)言ってしまえば、「更新と検索が容易なテキストデータベース」です。共通の入れ物として使用を徹底すれば、調べ物がとても簡単に出来るようになるだけでなく、情報更新も即座に行えますし、勝手に履歴も残してくれます。共通ルール、簡単なマニュアルや対応方法等をまとめておくには持ってこいのツールです。

そんなWikiにも色々ありますが、私がイチオシなのは「Swiki」というものです。恐らくWikiの中では超マイナーだと思いますが、これが非常に簡単で使いやすいのです。ただ、動作させる準備が少しばっかり独特で、「Squeak」という環境が必要になります。ここでは詳しくは書きませんが、これはLinuxでもWindowsでも動くのでサーバの種類は選びませんが、動かすまで少しばっかりネットでの検索とお試しが必要になるでしょう。

Swikiを選択する理由は2つあります。

1.ページの管理(URL)が数字である
2.とにかくシンプルで誰でもすぐ慣れる

世の中でよく見るWikiは、ページ名がURLに設定されていると思います。これでは、ページ名を変更するとURLが変わってしまうため、命名のハードルが非常に高くなってしまいます。しかし、Swikiは記事は内部的に自動で通し番号で管理され、URLはその番号になり、変更はありません。何でも番号を振って管理するという私の発想にピッタリで、伝達時も「Swikiの32番に書いてあるから」というように、絶対指定が可能という優れものです。

また、シンプルすぎるぐらいシンプルという所も重要です。記述ルールが少ししかないので使い始める最初のハードルが非常に低いですし、無用な表現(装飾)がしたくならないため本来行いたい情報共有に注力できるという利点があります。そのため、「検索する」「見つけて使う」「間違ってたら直す」「直した所を徹底する(変更履歴ですぐ分かる)」のプロセスがとても素早く回せるようになります。

とは言え、「ログインさせて履歴をログイン情報に紐付けたい」というような事ができないであるとかがありますから、やや機能不足を感じる事もあるでしょう。また、オープンソースとは言えSqueakを理解している人は身近にそういるものではないという所でカスタマイズに困るという事もあるかも知れません。そのため、そういう事を感じる段階になれば、別のツールを探して乗り換えを検討する事になってしまいます。ただ、私は今の所、何年も使っていますが、乗り換えなければならない理由に遭遇した事は1度もありません。結局の所、この手の仕組みはまず、「入れ物より中身」が大切ですからね。

もしなんしかの手段を探しているという人がいらっしゃいましたら、1度試してみて頂ければ幸いです。

次回もよろしくお願いします。

| | コメント (0) | トラックバック (0)

社内ヘルプデスクに最適な管理ツールとは?

前回、社内ヘルプデスクの「やること管理」について書きました。そしてその中では、自分でデータベースを作ろうという事にしました。それには2つの意味があります。1つは、「社内ヘルプデスクのメンバは自分で必要なツールを自分で作れるぐらいの実力がなければ説得力がない」ということ、そしてもう1つは「世の中には自分が求めているのにジャストフィットするような製品はまず存在しない」という事です。

世の中には社内ヘルプデスク用の管理ツールが市販されているようです。最近ではITILに準拠しているというのがウリになっている物も多く、そういったツールを導入する事で手軽に高いレベルの運用を手に入れられそうな気がします。勿論、パッケイジソフトを導入するという事は、ノウハウの結晶である「型」を手に入れるという事ですから、発想自体は決して間違っているとは言えません。しかし、それは「世の中一般に通用する型」がある程度以上成熟している場合には有効なのですが、どうするのが正解というものがはっきりしていない分野ではなかなか通用しないのです。しかも、マイナーな分野のパッケイジソフトは値段も高いわけですから、安直に買って駄目なら捨てるというわけにもいきません。買ってしまった以上使わなければならないという変な負担にもなりかねません。

ただ、そうは言え、先に書いた通り、パッケイジソフトはノウハウの結晶である「型」である事は事実です。ですから、そのソフトの機能や使い勝手、発想については大いに参考にして良いと思います。もし実際に触れてみる事が出来る機会であったり、デモ版を実際に使ってみる事が出来るのであれば、積極的に試してみて良い部分を参考にする事を心がけましょう。そして、もし自分たちがやろうとしている社内ヘルプデスクにピッタリと言える製品に巡り会う事が出来たとすれば、自信を持ってそれを導入すれば良いのです。何も、パッケイジソフトを導入してはならない、という事は全くないわけですから。

パッケイジソフトを選定、導入するためにも、まず自分で作ってみる、という経験とその成果は大きな意味を持ちます。それは、自分で自分が使うツールを作るという事で、大きく2つの効果が期待出来るからです。1つは「技術的なスキルアップ」であり、もう1つは「業務整理」です。これらにより、「何をどうするのが一番良いのか?」が見極められるようになるため、それに対する投資対効果も定量的に判断する事が可能になるのです。ですから、とにかく、最初は自分で作ってみる事を強くお勧めしておきます。

またもや、精神論みたいになってしまいましたね。

次回もよろしくお願いします。

| | コメント (0) | トラックバック (0)

社内ヘルプデスクのやること管理手法

社内ヘルプデスクでの「やること管理」を考えてみます。ヘルプデスクは「インシデント管理」を行うという話がよくありますが、どうすればそれがうまく出来るか、というのは、それぞれの組織によって異なります。そのため、ここではその中でも共通して使える手法である「情報の一元管理」を実現するための仕組みを作る、という事を書いてみます。

利用者からの問い合わせをデータベースに入れて管理する、という事は比較的初期の段階で実現しようとされるはずです。しかし、パソコンの設置を管理する事や、ヘルプデスクを取り巻く様々な課題を管理するという事は後回しにしたり、別の手法を用いてしまったりする事が多いのではないでしょうか。

確かに、管理する項目が違うため、同じデータベース(≒テーブル)でなく、別のデータベースで管理しようとする事は分かるのですが、私は極力、ヘルプデスクが行うべき事は全て1つのデータベースに入れられるような仕組みにする事をお勧めしています。それは、物理的に1つのテーブルにしなければならないという意味ではなく、常に「ヘルプデスクのやることリスト」が取り出せる仕組みを作るという事です。利用者への回答、設置の予定、ベンダとの調整、定期的な確認等、片っ端から全てのやることを管理する仕組みにしておき、日々それを消しこんでいけるようにするのです。その仕組みを作るのは大変かもしれませんが、そうする事で漏れ、無理、無駄がない全体と個々の管理が可能となるばかりでなく、それらの情報をメンバ間で共有してより良いサービスを提供する事にも繋げる事が可能となるわけです。

具体的にどうするかは色々な手法がありますが、「よく分からないけどやってみたい」という方には以下の方法をお勧めしておきます。データベースソフトは何でも構いません。

1.まず、自動的に連番のIDを振るテーブルを作って、件名と概要を入れられるようにします。社内ヘルプデスクで実施する全ての作業はこの連番で管理することにするのです。これを「総合管理テーブル」とでも呼びましょう。
2.作業の種類毎にテーブルを作り、それぞれの作業で管理したい情報を入れるようにします。これを「作業テーブル」と呼びましょう。
3.「作業テーブル」には「総合管理テーブル」の連番を入れるようにして、情報を関連付けておきます。こうしておけば、双方からそれぞれの情報が参照、もしくは、更新できるようになります。

日々の「やること管理」は「総合作業テーブル」を中心に行います。各作業を行う時には、「作業テーブル」を中心に行います。各作業の状況を更新すれば、「やること管理」からもそれがわかりますので、「全体」と「詳細」の双方の要求を満たすことが出来ます。作業は全て連番で管理できるため、連番で会話をすれば担当者間の認識違いも最小限に防げますし、各種情報の紐付けも全てこの連番を用いれば用意に行うことが出来ます。

なんとなくイメージできましたでしょうか?

次回もよろしくお願いします。

| | コメント (0) | トラックバック (0)

特定条件でのみ使用するソフトウエアのライセンス管理

特定条件でのみ使用するソフトウエアのライセンス管理はかなり厄介です。「特定条件でのみ」というのは、どこかの部署のみであるとか、どういう業務をする人のみ、というような、「全台共通で入れるソフトウエアではないもの」です。

そういったソフトウエアは、購入時にはどのパソコンにどれを入れてどうなっているという情報が分かっていても、管理を手抜きすればすぐそれが分からなくなってしまいます。また、どういう条件で購入したのかよく分からないソフトを見つけた人が、「あるから使って良いだろう。」という事で勝手にインストールしてしまい、結果的にライセンス違反を犯してしまっている、、、なんて事も発生する可能性があります。つまり、社内ヘルプデスクとしては、物理的なメディア(もしくはインストールに必要なファイル)の管理と、それをどこでどう利用しているかの管理の両方をうまく実現させなければなりません。

ライセンス管理は、SCCM等で実現する事も可能です。しかし、実際にはサーバとクライアントの通信がうまくいかないであるとか、ネットワークに接続しないパソコンは情報を吸い上げる事が出来ないであるとかの問題が発生し、それだけで本当にうまく行くかどうかというと、非常に怪しいというのが私の考えです。

では、どうすれば良いか?

ここは、一部ローテクになりますが、台帳系の仕組みをきちんと作って運用するしかありません。機器に番号を振るという話を書きましたが、ソフトウエアのライセンスもそれと同じ手法で管理するのです。機器とソフトウエアを個体が識別出来る形で情報管理し、インストールしたという事を組み合わせで表現するのです。「インストールする」という作業と台帳更新をセットにして、実際の利用状況は台帳で管理するようにすると同時に、「アンインストールした」もしくは「初期化した(=そのソフトウエアを取り除いた)」「廃棄した」という作業も台帳更新をセットにして、ソフトウエア利用の実体と台帳が完全に一致する仕組みを作っておくのです。こうしておけば、ライセンスキーが必要なソフトウエアであっても、どのライセンスキーを使っているのかという管理まで含めて、実体と台帳を無理なく無駄なく管理する事ができるようになります。

仕組みを作るのは少し大変かもしれませんが、機器管理の一環として取り組めば容易に実現できる事に気がつく事だろうと思います。ソフトウエアの事も含めて全体を最適化すれば、有形、無形、双方の物の管理が簡単、かつ、確実に行えるようになるはずです。

次回もよろしくお願いします。

| | コメント (0) | トラックバック (0)

« 2009年6月 | トップページ | 2009年8月 »