社内に「情報カード」のようなものを蓄積するニーズがあるのなら、MediaWiki（メディア・ウィキ）の導入を検討してみるといいでしょう。このソフトは、WikiPediaと呼ばれるWeb上のフリーの百科事典をつくるプロジェクトに用いられているフリーのソフトです。専用サーバーが無くても普通の安価なノートパソコンやデスクトップパソコンでもインストールできます。 （ただし、インストールには幾分ITの知識が必要です。CDをセットしてボタンを押すだけ、というものではありません）

たとえば操作マニュアルや業務マニュアルなどを頻繁に改定して配布する必要がある場合などに便利です。たとえば、「ウエスとバフを用意し、アールを丁寧にポリッシャーで磨きます」といった説明を、「ウエスとバフを用意し、アールを丁寧にポリッシャーで磨きます」(←リンクをクリックしても何もありません)というふうに、用語を全てリンクに置き換えることもできるし、画像やイラスト、動画を掲載することもできます。MediaWikiが優れているのは、文書の改定履歴がすべて保存されていて、誰がいつどのように改定したのかがすぐわかることです。 また、こうして登録した用語を再利用して、初心者用のマニュアルページや熟練者用のマニュアルページを記述することもできます。

分かりやすいマニュアルにするために、初心者には初心者向けにわかりやすい言葉で、日報の代わりにその日あたらしく覚えた事項をMediaWikiに書かせるようにします。熟練者グループにはインセンティブを払って、１項目完成毎にたとえば500円等を支払うようにします。

あるいは、取扱商品の商品カルテのようなものを作ることも出来ます。１商品に対し、開発コンセプト、時代背景、製造コスト情報、原材料、主要納入先、過去の販売動向、お客様からのフィードバックなどを各部門が別々に記載し、更新してゆきます。

商品を定期的に改廃するときには大変便利な上、商品開発、原料調達、宣伝企画、営業、お客様の声等を一貫して記述することが出来ます。

普通のWindowsXPパソコンを用意し、Apache（Webサーバー）、MySQL（データベース）、PHP（開発言語）といったモジュール（全て無料）をインストールし、その上にこのソフトをインストールします。インストールについては、きたがわゆうすけさんの自宅サーバーで行こうというサイトを参考にすると、ちょっとパソコンに詳しい人ならば出来ますが、結構面倒くさいので、プロにお願いしたほうがいいと思います。

Google Desktop 2という無料のツールは、なかなかいい感じである。 これは、Googleの検索技術で自分のパソコンの中身が検索できるという代物である。 メールもWebも、WordもExcelもPowerpointも一緒に検索してしまえる。それも一瞬である。 あたかもインターネットで検索するがごとく一瞬で検索できてしまう。

これまで、Outlook Expressなどでちょっと多目の過去のメールを検索すると、数十秒程度かかっていたものでも、なんのストレスも無くすっと検索されるのは気持ちが良い。また、メールで読んだのか、文書で読んだのか定かでないものも、これで検索すると大変楽である。

一番助かるのは、大量の過去の電子メールの中から目的のメールを拾い出す場合だ。 Google Desktop2と下記の小さなプラグインを組み合わせて使うと、ものすごく速く、軽く検索できる。 http://desktop.google.com/plugins/i/outlookexpress.html

インストールは一瞬で終わる。その後、検索用インデックス作りがはじまるのだが、これに数時間から数十時間かかる。私の場合はデータが多いので、土日の間にインデックスが作成し終わった。

天気予報やニュースなど、目的からすれば不要な機能もあるのだが、無料なので仕方無い。
大量のメールや、整理整頓されていないパソコン内文書にお悩みの方は、いちど、試してみてはどうだろう。

ITコーディネータ／太田垣博嗣

2005年12月から2006年1月頃、楽天がANA等いくつかの提携先と組み、ボーナスポイント2000点（つまり2000円のお買い物券）の付与を餌に、新入会員獲得キャンペーンを実施した。

ところが、ちょっとした操作を繰り返すだけで同一人物が何度も申し込むことができてしまったため、楽天ポイントを大量に集める人がでてきてしまい、さらにその方法がネットに広く流布した。楽天では慌ててこのキャンペーンを中止し、キャンペーンに乗って普通に応募した人の分も取り消した上、そのポイントを使用して購入した商品の代金を会員に請求したという。

お買い物券を沢山持って商品を購入した人に、「あのキャンペーンでズルをした人がいましたので、金券はナシにして、現金でお買い上げいただきます」というような感じである。 その後は、正規のポイント取得者に対してはポイントを戻したり、本当に請求が来るのか等、ネット上には噂が飛び交い、しばらくドタバタが続いた。（幸か不幸か世間ではライブドア問題で、あまり話題にも上らなかった）

このケースでは基本的には、ポイント制度の設計やシステム設計の問題であるが、数多くの不信感を利用者にバラ蒔いてしまったことも確かである。

また、最近ではコンビニや携帯電話支払い等を組みあわせた方法が広がっている。マイレージやポイントが溜まる、「とあるクレジットカード」をコンビニ払いで作っておき、クレジットカード会社から請求が来たら、携帯Edyにクレジットカードから支払い額分をチャージして、コンビニで支払うというもの。（もっとも既にこういった連鎖に対し、防止策を講じる会社も出てきているというが、さてどうだろうか？）

つまり、いくつかの支払い手段を組み合わせて、お金をぐるぐる回してゆくと、通過した電子マネー媒体にどんどんポイントが溜まる連鎖の環ができるという仕組みである。個別のシステムには問題は無いが、全体としてみると、予期しない動きができてしまっている。

システムが繋がるということは、こうした怖さを含んでいるといえる。ひとつひとつの情報システムでは、しっかりとシステムを作っていたとしても、大きな連環の全体を見て開発しているわけではないから、こういう裏技的な問題が発生してしまう。

社内システムでも同様だ。いくつかのシステムをうまくつないでゆくと閲覧できてはいけない情報が閲覧できたり、社内で禁止しているはずのソフトの不正コピーが、社内ルールの順序を入替えるだけで正規ルートで可能になっていたりする。

一つ一つのシステム運用は、担当するシステム会社のエンジニアに聞けば分かるが、会社全体の運用を確認することは、その会社でなければできない。システムを１社に任せてしまうと、コスト面やサービスの質の面で問題があるが、複数会社に分散させてしまうと、今度は全体統括に対する責任が重くなってくる。

このあたりは、社内システムの普及具合、社員の意欲や人材、システム会社の状況等を総合的に見て、一番良い方法をケース毎に見てゆかなければならないと思う。

3月11日、ITコーディネータパートナーズ主催（まいど！フォーラム後援）のITC表現力研修が行われました。そのときに参加者が作成した論文が、当サイトの投稿論文コーナーに掲載されました。

まいど！フォーラム世話人

ITコーディネーターの活躍の結果なのか世間の潮流なのかわからないが、最近システムベンダーの立場で、RFP/RFI（提案依頼書、情報提供依頼書）を受け取って提案書を書く機会が増えた。複雑なシステムの場合には、RFPを受け取ったシステムベンダーから「このパートに、おたくの製品使えそうだから、そこのところを書いて欲しい」といった孫受け依頼や、「とりあえず名乗りは上げたんだけど、うちじゃできないので、考えてみて！」と丸投げのような依頼もある。

逆にお客様サイドに立って、RFP/RFIのような位置付けの資料を書いてベンダーに渡すことも増えた。

こういった資料は書くのに結構骨が折れる。システムの内容がわかっていたとしてもそれを文章に表現することはなかなか難しい。実際のシステム案件で書いたり読んだりしてゆかないと、書くセンスというか要領はなかなか身についてゆかないものである。他のシステム開発技術と同様に、RFP/RFIの作成技量というのも徐々にシビアになってゆくのだろう。

最近ちょっと困り者なのが、RFP/RFIを名目に、ノウハウを全部吐き出せと言わんばかりの無責任な提案依頼書だ。RFP/RFIを発行する最大の目的は、ユーザーニーズを書面にあらわして、複数のベンダーから意識のズレの少ない提案を貰うというところにある。次に、副次的な要素として、ユーザーが知らない画期的な手法や製品があった場合にそれを積極的に活用する為にベンダーに対して情報を求め、知見を得るという目的がある。

したがって、ユーザーニーズとベンダー各社が持つ技術や製品、ソリューションとのフィット＆ギャップを見るのが重要なはずなのだが、時折「あなたが持っているIT技術を使って、私たちのビジネスモデルをどう変えることができるのかを示してください」とか「そのシステムのデータベース設計図、スキーマ構造図、エンティティ設計書を出してください」などと堂々と依頼してRFP/RFIに出会うことがある。たいていは、どこかのシステムベンダー等がユーザーの代理で作成した資料だ。

こういうRFP/RFIを受け取ると、提案する側の私のテンションは一気に冷めてしまう。

ITコーディネータのプロセスガイドラインの中では、RFP/RFIの発行は、経営戦略・ビジネスモデルに関する社内コミットメントが済んだ後に、それを実現するための手法リサーチや協業ベンダーの発掘のために行うことになている。ところが、情報収集といいながらビジネスモデルの検証や有効性を問うというのはどういうことだろうか。

エンティティ設計書を提出して、はたしてそれを評価する人材がユーザーや、ユーザーの代理となっているシステムベンダーに居るのだろうか。もちろん居る場合もあるのだろうが、実際には少ない。短い時間の中で、そんな資料をしっかり理解する時間は無いはずだ。むしろ、システムベンダーからすれば知財の流出に他ならない。

提出した資料はユーザーの手に渡り、秘密保持契約を締結しているとはいえ、ユーザが関与している他のシステムベンダーが閲覧することは間違いない。

もちろん、こちらとしては仕事が欲しいから、できるだけの情報は提供しようと思うのだが、１週間とか１０日といった限られた提案時間の中で、大量の資料を提出させるのははたして意味があるのかと感じることがある。

もうひとつ、「腹立たしいRFP」がある。こちらは書かれていることにではなく、書かれていないことにである。その会社のIT経営の成熟度に関する情報が非常に少ないということがある。たとえば、導入後のサポートやシステム運用等について沢山記述するよう要請される場合があるのだが、ユーザーのIT経営成熟度がわからないと、なかなか提案しづらい場合がある。

たとえばRFPでも、ある程度ターゲット製品が予想されている場合、その製品と自社の開発要件との適合性を見る場合や、その製品の販売代理店として確かな力量があるのかを見極める場合のRFPと、世間にどんな製品があるのかを把握したい場合になげるRFPとは、書き方も変えてゆかなければならない。

後者の場合などは、運用体制や会社の情報化がどのように浸透しているのかがわからないと、提案は非常にブレたものになる。これが書きにくいというのであれば、いきなりRFPをどーんと発行するのではなく、数回にわたってRFIを発行し、消化できる程度の整理された情報を得つつ、競合各社の営業ともある程度仲良くなってゆきながら最終的にRFPを発行するようなやりかたも考えるべきであろう。

今は未だ世間にRFPを書きなれたエンジニアやアナリストは少ない。
多くのRFPに接する機会を持っているITコーディネータは、良いRFP、悪いRFPを世に問うてゆくのも責任の一部ではないかと感じている。

ITコーディネータ／太田垣博嗣