イントラでの検索ロジックができそうです

未唯へ。私のシステム設計思想は「自然」です。「ムリやり」にはロマンがない。

30年前に部品表の設計変更システムを作ったときに考案しました。設計者が何を考えて、部品を変えるのかを分析し、「ヘッドロジック」という数学モデルを作り、変更指示書とメンテナンスデータを自動作成しました。

それと同じように、ライブラリの検索ロジックができそうです。熊本の販売店の店長の一言と、システム会社からのロジックを考えていて出来上がってきました。これでライブラリはスッキリします。

ヒアリングした時に、「ふだんは「お知らせ」からライブラリを検索しているが、ライブラリ構成を直接、検索する場合もある。検索ツールが欲しいのは、過去に「お知らせ」で送られてきたもの記憶はあるが、「お知らせ」がなくなってしまっているので、どう探したらいいかわからない」ということでした。

これから、出来る空間は以下の３つです。①物理的なライブラリと「お知らせ」からの誘導、②各部にそった論理的ライブラリをポータル側に保有、③過去の「お知らせ」の検索からライブラリの活用。①はあります。②はポータル側で作ることができます。重要なのは③です。「お知らせ」そのものが検索キーになるということです。「お知らせ」には、これを見て欲しいという「思い」とデータの場所とがつながっています。この「思い」は店舗向けに発信されたものだから、分かりやすいし、簡単なテキストになっているので、検索キーとしてはシステム化が容易です。

そうなると、ライブラリ構成はメインとサブのフォルダー以下の構成は自由で、３つの見方をポータルとライブラリでサポートすれば十分です。その思いをメンテナンスの時にどう作りこむかぐらいが決まれば、ライブラリシステムは出来上がります。

このシンプルな構成で十分であることを、関係者にどう伝えるかです。これが一番難しいかもしれない。皆、作りたがりだから、難しく考え、自分の居場所を探します。

２年計画：昼休みに入ってから、会議が終わったので、50メートル前から受付を見ると、NAKさんがこちらを笑顔で見ていました。一人でお留守番です。チャンスと思い、３分ぐらい話しました。その上、帰る時にゲートで後姿を見たので、ご挨拶。エレベーターの中でちょっとだけおしゃべり。今日は２回だけ笑顔になれました。