桐と聞いて管理工学研究所の日本語データベースソフトを思い浮かべる人がどれだけいるだろうか。桐という言葉から普通の日本人が思い浮かべるのは、桐のタンスや桐で作られた木箱ではないだろうか。
Excelを普段使っているユーザーでも日本語データベースソフト「桐」のことを知っている人は少ないように思う。熱烈なユーザーがいる一方で残念ながら一般にはあまり普及していないのが現状だ。
桐は、Excelの設定の知識があり、入力規則や関数を使って表が作れるレベルの人なら誰にでも使いこなせる優れたソフトウェアだと私は思う。マクロの知識は必要ない。ただ、「一括処理」という桐の自動処理機能を使うならExcelのマクロの知識は役に立つだろう。一括処理は、Excelのマクロ程難易度は高くなく、メンテナンス性もいいと思う。
桐の一括処理を使わなくても桐には処理をワンクリックで行うための仕組みが用意されており、ワンクリックするだけで登録した設定に従って自動的にデータを並べ替えたり、抽出したり(Excelの場合なら「フィルタ」機能、桐では「絞り込み」機能)、一覧表を印刷したりすることが可能だ。さらに「履歴」機能を使えば、並べ替え→絞り込み→一覧表印刷をワンクリックで行うことも可能だ。
こうした優れた機能を持ちながら一般にはあまり普及していないのは、やはり価格の問題が大きいと思う。最新版の「桐10」通常版はアマゾンでも4万円程だ。個人で買うには高すぎる。しかし、事業所で購入するなら必ずしも高いとは言えない。だから、大きく普及はしていないが、桐には根強いユーザーが存在しており、今年は発売から30周年を迎える。ちなみに、桐を試用できる体験版が用意されている。
👉根強い「桐」ファンに支えられ、30周年カウントダウンでWindows 10対応
そして、Excelのように普及していないため、メーカーのサイト以外で桐の使い方や疑問を調べる手段が限られている。ネットには、熱心なファンユーザーで作る桐の井戸端会議情報はあるが、初めてのユーザーにはちょっとマニアックに感じられる内容のように思う。
利用者が少ないためExcelなら簡単に疑問を解消できるようなレベルの問題でも桐では、検索しても見つからないことが多い。現在、PCのユーザーはネットから必要な情報がいつでも入手できるようになり、ソフトの解説書は、売れ筋のソフトしか販売されなくなっている。本屋に行ってもExcelやWordの解説書は種類も豊富だが、他のソフトの解説書はほとんど販売されていない。最新の桐10の解説書も現在、販売されていない。だから桐10の場合、メーカーの管理工学所が提供するもの以外ほとんどないのが現状だ。桐に関する情報源はソフトに内蔵されたヘルプ情報やネットからダウンロードできるリファレンスくらいだろうか。
普及していないソフトに対するサポートを提供するソフトウェアハウスも当然少なくなる。桐は、メンテナンス性、信頼性は業務ソフトとしては非常に高いので規模の小さい事業所なら基幹システムを作ることも可能だろう。しかし、その場合は、事業所に専任者を置くことが必要だろう。人材の限られた小規模事業所では、桐の専任者を置くことは困難のように思う。
だから、桐で作られたアプリケーションが購入できるか、桐で気軽にシステム開発を請け負ってくれる業者が存在しなければ、桐の大きな普及は難しい。だが、小規模でローカルなシステム開発は、Excelの設定の知識があり、入力規則や関数を使って表が作れるレベルの人なら誰にでも可能だと思う。桐には、セキュリティのためのツールもいくつか用意されており、例えば利用者(参照利用者、更新利用者、定義利用者)コードの設定も可能だ。ちなみに定義利用者とは、システム開発者のこと。
メーカーは値段を安く設定して普及を優先するより、コアとなるユーザーに対して重点的に販売していく戦略を取っているのだろうか。値段を下げて売ることのデメリットを考慮しての戦略なのだろうからそれはそれで一つの選択と言える。
私は、個人ユーザーとして桐をずっとバージョンアップしてきた。しかし、使いこなしている訳ではない。最初に購入したのは、桐が30年前に発売された直後ではないかと思う。Windows版ではなく、MS-DOS版だ。その当時購入した解説書「データベースシステムの実際 桐全機能解説」(酒井俊一著)がまだ手元に残っている。
奥付には昭和63年3月10日初版発行とある。昭和最後の年の1988年(厳密には1989年が昭和最後の年、その期間は7日間)の発行だ。パラパラめくって驚いたのは、「一括処理」の項目に鉛筆でたくさんの線が引いてあることだ。正直、桐の一括処理プログラムを書いた記憶はあやふやだ。しかし、桐の一括処理プログラムを書ける能力はその当時あったと思う。
なぜなら、当時はBasicで実際にプログラムを作成したり、MS-DOSのバッチプログラムを書いたりしていたからだ。今のようにExcelやWordがPCにバウンドルされて販売されていない時代にMS-DOSのパソコンを使う上でBasicやバッチプログラムは必須だったように思う。しかし、今はプログラムを書こうという意欲自体湧かない。
奥付を見ると著者の肩書は慶応大学大学院工学科出身の管理工学研究所研究員となっている。ということは、桐の普及のためにメーカーの開発者が作成した解説書ということだろうか。記述の中に桐の開発コンセプトがわかる記述を見つけた。
15.4.2一括処理から会話処理を呼ぶ(標題と以下その抜粋)
「桐は会話処理型の編集機能が充実しているので、なまじ苦労してさまざまな機能を一括処理で実現するよりも、会話処理機能をそのまま使ってしまったほうがよいことが多い。桐では一括処理のよい面と会話処理のよい面とを同時に使えるように、一括処理の途中で会話処理を呼び出すことができる。逆に、会話処理中に一括処理を呼び出すこともできる。」
私が今回この記事を書くきっかけになったのは、2016年 2月 29日に投稿した「久々のブログ~Excelで考えたこと」という記事だ。私は、たまたま読んだExcelの解説書に触発されてExcelでマクロを使わずに出納帳シートにデータを入力し、その収支データだけを「貼り付け」機能を使って複写することで収支明細を科目別に集計し、収支決算報告書を出力するシステムを作成した。
このシステムは、Excelの入力ができる人なら誰にでも運用できる自治会等の任意団体向けシステムとして作成した。Excelで作成した理由の一番大きな理由は、Excelが普及しており、PCを業務で使うほとんどのユーザーのPCにExcelがインストールされていることだ。だから、作成したシステムを多くのユーザーに負担をかけずに提供できると私は考えた。特殊な機能は使っていないので古いバージョンのExcelでも動くはずだ。
システムの作成で最も腐心したのは、Excelの機能をどのように利用したら、誰でも使いやすいシステムを実現することができるかということだった。入力ミスによるシートの設定の破壊のリスクを減らし、かつ簡単な操作で目的を実現することができる小規模な会計システム作りは、結構、根気のいる作業だった。それは、Excelのデータ保護機能が低く、日常的にデータを蓄積していく作業に向いていないことに起因している。
自治会等の小規模な任意団体の場合、入力した出納帳を印刷しておけば、仮にデータが破壊されて印刷帳票のデータを基に再入力したところでその入力作業はたかが知れている。私がExcelで作った収支決算報告書シートは、科目別の集計結果を貼り付けるか、入力すればいい仕組みなので、データが破壊された場合でも印刷した帳票が保存してあれば出納帳シートにデータを再入力せずとも収支に関係する科目別の収入と支出のデータだけをExcelで別途集計してその集計結果を収支決算報告書シートに貼り付けるか入力するだけで済むように作成してある。
データ保護が脆弱なExcelを使ってデータを蓄積していくような日常業務を行うのは、ちょっとリスクが高い。そうしたリスクを考えた上で利用範囲を考えるべきだろう。また、マクロを使ったソフトは、セキュリティソフトにウイルスと誤検知される可能性があり、他人に提供することも難しい。時間が経つとマクロを作成した本人ですら解読が難しいくらいだから担当者が変わったときには、最悪の場合、システムを一から再作成する必要があるかもしれない。
Excelの会計システムを作ってみてデータの保護機能のもっと高いソフトはないだろうかと考えて思い出したのが桐だった。私は、桐の個人ユーザーにすぎず、企業内で公式に使っていたわけではない。ただ、営業関係の仕事に携わっていたので顧客や管理先のデータを把握する必要があり、私は、桐で顧客名簿や管理先名簿を作成して使っていた。
無論、会社の端末を叩けば、顧客情報や管理先情報を知ることはできたし、帳票に印刷することもできた。しかし、単票形式のものは一覧性がなく、連続帳票で印刷したものは嵩張りすぎて外出先に持ち出して使うのは難しかった。今のようにタブレットやスマホで簡単に検索する手段もなかったので、桐に入力したデータから必要項目だけを抽出した一覧表は、私の営業に必須のツールだった。一覧性と携帯性に優れたツールとして大いに役立った。
私は、桐が新しくバージョンアップされる度に更新してきた。しかし、使いこなしていたわけではない。必要な機能だけ調べて利用していただけだ。先程、紹介した桐の解説書以外、読了した桐の解説書やマニュアルはこれまでなかった。最新の桐10を持っているが、現在、市販されている解説書はなく、ソフトに内蔵されたヘルプ情報か、メーカーの公式サイトから無償でダウンロードできるリファレンスしかない。
桐10は、基本的には、直近の桐9と機能的に大きな差がない(と勝手に判断)と考えて1つ前の桐9sを使って初心に帰って再勉強してみることにした。ただし、勉強には、2002年10月20日発行の下記のマニュアルを使った。理由は、データサンプルを使った機能別の丁寧なマニュアルだったからだ。ページ数はあるが、図解と重複説明が多く、文字量はページ数から想像される程の量ではない。
<読了した解説書>~Win版「桐」に関するお薦め図書のあれこれ
①桐9 表ツアー
②桐9 フォームチュートリアル
③桐9 レポートチュートリアル
④桐9 表リファレンス
①~④までを順に読了した。(実際には①~③を読了後に後段で紹介する食品管理システムを桐で作成してみた。)④のリファレンスは言葉の意味からすれば、必要なときに参照するものだから事前に読む必要はない。しかし、リファレンスに目を通してみて①~③までのサンプルデータを使った解説と自分で簡単なシステムを作成したときには気づかなかった効率的な使い方のヒントを得ることができたので一通り目を通しておく価値は十分ある。
さらに気づいたことがある。それは「一括処理」や「イベント」という言葉が出てきても「一括処理」や「イベント」の具体的な記述がまったくないことだ。必要な方は、ヘルプの記述を見てくださいということのようだ。Excelでマクロを使ったことのないユーザーには、ヘルプの一括処理の説明を読んでも一括処理のプログラムを書くことは困難だろうと思う。かつて一括処理のプログラムを作成したことがある私でもきっとよく分からないだろうと思う。
しかし、今の私には、マクロも一括処理も興味がないので問題はない。一括処理の記述がないことは、前述したように「なまじ苦労してさまざまな機能を一括処理で実現するよりも、会話処理機能をそのまま使ってしまったほうがよいことが多い。」という桐のシステムの設計思想からきているのだろうと思う。
メーカーは、少なくとも一般のユーザーに一括処理の利用を推奨していないのだろう。一括処理を必要とするようなユーザーは専門のシステム開発受託会社にお任せするべきだ。その方が両者にとって望ましいように思う。桐は、データ保護機能もメンテナンス性も優れており、ユーザー側だけでなく、受託したソフトウェア会社にとってもメリット大きいのではないだろうか。
実は、私は今回、桐で久しぶりにシステムを作ってみる前は、漠然と一括処理を覚える必要があるのではないかと思っていた。しかし、実務担当者が自分の業務を効率化するために実務に即した簡単なシステムを作る程度なら一括処理のプログラムを作る必要はまったくないと感じた。
私は、桐のバージョンアップの度に有償で更新してきたが、最初に桐を使うために覚えた機能の範囲内で使い続けていたので新しい機能や改良された点についてこれまで気づかずにきた。とりわけ「道具箱」という機能の便利さを知り、ああこれは生半可な一括処理のプログラムを作る必要はまったくないなと現在は思っている。詳細は後段で触れたい。
桐が30年も使われ続けている理由
Excelで顧客管理等のデータベースを作成しているユーザーはいるかもしれないが、Excelのデータベース機能ははっきり言って貧弱で日常の業務で使うには、システムの安定性、セキュリティ面で問題があるように思う。マイクロソフトには、ちゃんとAccessというデータベースソフトも存在している。しかし、現在、Office製品ではAccessはオプションという位置づけで販売されており、多くのユーザーにとって、少なくとも個人ユーザーには本格的なデータベースソフトウェアは、そもそも不要なアプリかもしれない。
しかし、趣味で何らかの分野のデータベースをPCで作ってみたいという場合は、個人でもデータベースソフトは必要になると思う。もし、個人でデータベースを構築しようと考える人がいるなら間違いなく、桐がいいと思う。桐はExcelとのデータの受け渡し機能も充実しており、わざわざプログラムを作成せずとも、簡単な操作で高度なデータベースの検索や抽出の操作を行うことができ、帳票の出力も簡単だ。
人材が豊富でない小規模な事業所でデータベースソフトを使って基幹システムを構築する場合は、桐より売れているAccessの方がシステムをサポートする業者が多く、桐は後塵を拝することにならざるを得ないだろう。
しかし、企業内では基幹システムから出力されたデータをExcelに落として二次加工しているユーザー部門は多いように思う。企業の情報部門も汎用性の高くない各部門のニーズに応じたデータ処理のプログラムを開発するより、基幹システムから基礎データをExcelを通じて提供するだけにとどめ、ユーザー自ら基礎データを加工する体制の方が効率がいいように思う。ユーザー部門にとっても情報部門の都合に囚われず、ニーズに合った形でタイミングよく情報を分析・加工することが可能となるというメリットがある。
そうしたユーザー部門に桐を導入してExcelに落としたデータをさらに桐に取り込んで蓄積すればExcelより効率的にデータを簡単かつ迅速に分析することが可能になるだろう。桐で加工したデータをさらにExcelで集計すれば、2つのソフトの弱点を補うことも可能だろう。
ちょっと、乱暴な言い方をすれば、Excelを電卓代わりに使い、桐を電子辞書代わり使うことで現場の業務効率と処理スピードを上げることができるだろう。あるいは、基幹システムを外部のソフトウェア会社に委託してAccessで構築し、現場のデータの二次加工をExcelと桐で処理するということも考えられる。
なぜなら、現場でAccessを使ってデータの二次加工を始めれば業務の効率の足を引っ張ることになると思うからだ。桐は、仕事を一番理解している実務担当者が本末転倒にならないレベルでシステムを作成し、メンテナンスすることが可能な数少ないツールのように思う。Access程売れていない桐が30年も使われ続け、残っている理由はそれなりにあるのだと私は思う。メーカーがExcelとのデータ互換性に力を入れている理由が分かるような気がする。桐の操作は、Excelととても似ており、親和性が高い。
表のデータ構造~Excelとの比較
桐を使ったことのないユーザーにはExcelとの違いが分からないと思う。表(シート)の形でデータを処理するという点ではとても似ているが、データの構造はまったく異なる。Excelの場合、データの基本はセルだが、桐のデータの基本は行(レコード)になる。Excelでは、行と列の位置情報でセルを管理するが、桐は1行をレコードとして管理する。
そして、桐では行の中のセルに当たるものを項目と呼んでいる。この項目の一つ一つに名前が付けられており、同じ項目名は許されていない。なぜなら、レコードの中の項目の識別は、項目名で行われているからだ。
エクセルでは、データの入ったセルの上段にタイトル行を設定してその中のセルに項目名を付けているが、項目名は同じ名前を付けても構わない。それは、データは、すべて何列目の何行目のデータという形で管理されているからだ。項目名すら何列目の何行目のデータにすぎない。
ところが桐は、すべての行が同じ項目数と項目名を持ったレコードとして管理されており、同じ行に同一名の項目の存在は認められない。なぜなら、桐では1つのレコードの中の項目は、項目名で管理されており、何行目の何番目という形でデータを指定するのではなく、項目名でデータを指定するため、同じ項目名を設定することはできない。
データの処理単位は、あくまでも行(レコード)単位であり、データの削除・追加という場合、それは行の削除であり、行の追加という処理になる。
桐は、Excelのように表の任意の位置にいきなりデータを入力して作業を始めることはできない。桐は最初に行(レコード)の項目数と項目名を設定し、Excelの場合のセルの書式に当たる「定義」作業から始めなければならない。何か面倒くさい作業のように思われるかもしれないが、定義するのは1レコードの項目数と項目の属性だけだ。しかも簡易設定を使って作業を始めることができるようになっており、桐がデフォルトで設定した項目名や項目数は、後から自由に変更できるようになっている。
定義の作業が終われば、一行ずつ(レコード単位で)データを入力していくだけだ。項目は事前に設定されているのでExcelのように後からセルの書式設定を調整したりする作業は必要ない。無論、後から項目数や項目名、項目の属性(例えば文字データだとか数値データだとか)の設定を変更することができる。
ただし、定義を変更したときに新しい定義で設定した条件と異なるデータが入力されているとデータが破棄される場合がある。しかし、いきなり破棄するわけではなく、警告メッセージが出るのでその指示に応じて作業をすればいい。
また、利用者コードを設定すれば、参照利用者、更新利用者、定義利用者を設定できるので更新利用者によって不用意に定義が変更される心配はない。
システムの安定性と安全性の問題~Excelとの比較
<Excelではデータの参照・更新利用者と開発者の切り分けが難しい>
Excelのデータの保護は基本的にはセル単位になっており、パスワードを設定したシートでも保護を解除したセルは編集することができる。保護を解除したセルは、セルの書式や入力規則も編集可能であり、開発者の作業の範囲まで侵犯している。このため、入力ミスや操作ミスでシートの設定が破壊される可能性が常にあり、日常的にデータを蓄積するような業務には向いていないように思う。
<桐ではデータの参照・更新利用者と開発者の切り分けが可能>
桐の場合は、前述のとおり利用者コードを設定することで参照利用者、更新利用者、定義利用者(開発者)の切り分けが可能であり、日常的にデータ蓄積するような業務を桐でシステム化しても安定した運用が可能なように思う。また、桐はバグが少なく、データの安全性にも配慮された安定したソフトなので安心して使うことができるだろう。
桐の留意事項~Excelとの比較
○Excelを使う場合、通常、表を開くときに自動的に再計算をする設定(デフォルト)で多くのユーザーは使っていると思うが、桐では、表を開いたときに自動計算はされず、意識的に再計算の処理(桐では置換機能の一部)をする必要がある。例外は、組み込み変数(例えば現在の年月日を格納する変数等)は表が開いた時に再計算が行われる。ただし、関数の中の引数として組み込み変数を使ったときには再計算はうまく機能しない。組み込み変数は更新されても関数の再計算が行われないからだ。
○桐では、行(レコード)を削除してもデータは消去されず、削除行のマークが付けられて保存される。「表整理」というコマンドを使ったときに初めてデータが完全に削除される。
桐の想定される利用分野についての整理
個人の場合 データを日常的に蓄積していくような作業をPCで行いたい人
(例)趣味で何らかのデータベースを作りたい
仕事の場合 データを日常的に蓄積していくような業務をPCで管理するとき
(例)小規模事業所や任意団体のローカルな定型業務
企業内の情報システムからExcelに取り込んだデータを簡単に加工したい
桐を使うメリットは、桐が仕事を一番理解している実務担当者が本末転倒にならないレベルでシステムを作成し、メンテナンスを行えるということに尽きるように思う。
桐の機能の実際
私が作った「食品管理」システムを使って桐の機能を具体的に紹介してみたい。この「食品管理」システムは、私の家内のために作ったものだ。最近、消費期限や賞味期限の偽装問題から食品ロスに対する関心が高まっている。
関連業界の取組も大切だが、私たち消費者自身がもっと食品ロスに関心を払わねばならないように思う。我が家も冷蔵庫やパントリーの中の食品がいつの間にか期限切れになっていることが多い。一応、リフォーム等の折に整理して期限の切れのものを始末してきた。
そして、いつも今度こそ期限管理をきちんとして無駄をなくそうと誓う。しかし、現実は、いつの間にか期限が過ぎた食品が扉の奥で泣いている。いつまで経ってもこの無限ループから抜け出せそうにない。
人は、見えないものを忘れていく習性がある。期限切れの商品を見てもその商品を買ったことすら思い出せないものがある。できれば、すべての食品を見えるところに置いておけばいいのだろう。しかし、冷凍食品を常温で保存することはできないから冷蔵庫の暗い密室に保管せざるを得ない。野菜もすべて室内の見えるところに置いておくスペースはない。それに臭いの問題もある。かくして、食品ロスはいつまで経ってもなくならない。
昭和30年代頃は、冷蔵庫はまだ高価で一般家庭には大きく普及していなかったから、主婦は、毎日、夕飯のおかずを近くの商店街に買い出しに行っていた。だから、食品ロスという問題はあまりなかったように思う。しかも、当時は「もったいない」という気持ちを誰もが持っていたように思うので食品ロスが問題になることもなかったはずだ。
冷蔵庫の普及とスーパーストアの急成長で大量生産、大量販売、大量購入が一般化したことが大量の食品ロスを生んでいることは間違いないと思う。しかし、だからと言って毎日、必要な食品を買いに行くというのも現実的ではない。
ちょっと話が大きくなってしまったが、私が桐で作成した「食品管理」システムは大袈裟に言えば食品ロス問題に対する我が家の取組の産物でもある。見えないから忘れるという問題をどうやって解決するかという問題意識から考えたのが、私の「食品管理」システムだ。
実際には、家内のために作ったシステムだ。家内は、ちょこちょこ買い物に行きたがり、私が、今夜の夕飯は冷蔵庫にあるものでいいからと牽制すると「何もない」と必ず返答する。冷蔵庫にもパントリーにも期限の切れた食品はないと主張していた。
それではと家内でも簡単に入力できる、食品の期限管理のためのシステムを作ることにした。無論、私が入力してもいいのだが、それではなんだか私が家内を監視するためのシステムとなり、反発される可能性があると考えて家内があくまでも自主的に気が向いたときに入力するシステムを考えた。
使い辛いところがあれば、家内の注文通りにシステムの修正でき、操作ミスや入力ミスでデータがパーにならないシステムを作ろうと考えたら、桐で作る以外ないように思った。家内は、ExcelやWordはある程度使える。しかし、入力が面倒くさいようなシステムなら使わないことは目に見えていたのでその点には配慮してシステムを作った。
例えば、データの入力は、リストから入力項目を選択する「値集合」をなるべく使った。食品分類コードと食品分類名は別に作成した表から「表引き」で入力することで入力の負担を減らした。残存日数や期限切れ、在庫状況等のメッセージを表示する項目は、入力した保存期限や在庫数から自動的に計算して表示するように設定してある。
システムを使うことでメリットがあるようなシステムでなければならない。例えば、家内は買い物に行く前に手書きの買い物メモを作っていたが、「食品管理」システムでは、ワンクリックで買い物リスト(最後にサンプルを掲載)が印刷できるように設定してあり、手書きのメモを作る必要がなくなった。商品ごとの在庫数や直近価格が載っているので家内はお店に気に入った食材がなければ最近は買わないこともある。
私は、以前から桐を使っていたこともあり、紙ベースのシステムの構想づくりの時間を除いた桐での「食品管理」システムの原型づくりにかかった時間は、おそらく2~3時間程度だと思う。
その後、使いながら家内の要望を入れてシステムを修正してきた。これはどんなシステムづくりでもある普通の作業だ。使ってみて初めて分かるバグや改良点は常にある。それでも、桐はこうしたメンテナンス作業が短時間で簡単に行える。作業よっては、数十分で終わることも多い。メンテナンスにほとんど頭を悩ますようなこともなかった。
桐でのシステムの作成手順
<どんな項目が必要か考える>
例えば、食品管理のためには消費期限と賞味期限は必須だが、それだけでは不十分である。なぜなら、野菜や果物には、期限が明示されたラベルが貼ってない。だから消費期限と賞味期限の表示のない食品には、別途保存期限を設定して入力する必要がある。それならば、保存期限に統一して管理すればいいとも考えられる。
しかし、賞味期限は美味しく食べられる期限の目安にすぎないので賞味期限が過ぎて捨てていたら、食品ロス問題の解決には役立たない。食品一律に賞味期限+○日を保存期限に設定するわけにもいかない。賞味期限の切れた食品ごとに臭いや状態を確認して対応するしかないように思う。だから、保存期限だけではちゃんと管理できない。賞味期限のデータも必要になる等々。
<項目を桐で定義する>
桐ではすべての行が同じ項目で統一されるので、基本となる1行(1レコード)の項目数との項目ごとの属性(文字だとか、通貨だとか)を最初に定義する。定義ではデータの入力内容を制限する、リストからデータを選択して入力(値集合による入力)する、別の表から転記して入力(表引き入力)するといった入力を省力化する仕組みを設定することができる。
<テストデータの入力と条件名の登録>
桐の表ができたら、試しにデータを入力して不具合や考え落ちがないかチェックする。もし、不具合等で修正が必要になったら、定義に戻って修正すればいい。こうしたテスト入力で1画面分くらいのデータを入力した後、並べ替え、絞り込み、一覧表印刷等の条件を登録していく。無論、条件名を付けずにその都度、並べ替えや絞り込みの条件を変えて実行することも可能だが、条件名を付けて登録することで作業がワンクリックで行えるようになる。
<「道具箱」の設定>
テストデータの入力と条件名の設定が終わったら、登録した条件名をメニューとして設定する「道具箱」への登録を行う。「道具箱」は表の右側に表示され、一つの表に20個まで登録することができる。道具箱を使うことで、条件名を登録した並べ替えや絞り込み、一覧表印刷がワンクリックで実行できる。さらに「履歴」機能を登録すれば、例えば並べ替え→絞り込み→一覧表印刷といった一連の処理を連続してワンクリックで行うことができる。
以上の作業でシステムは出来上がりだ。これに利用者コードを設定して、表のバックアップ(桐には、「ファイルコピー」という表のバックアップ機能あるので、システムの保存してあるフォルダーとは別のフォルダーに簡単にバックアップを作成することが可能だ。)を桐の作業の終了時に毎回行えば、万が一データが破壊されても安全だ。さらに定期的にシステムの入っているフォルダーをエクスプローラーで外部記憶装置に保存すれば万全だろう。
ちなみに桐では、データの保存先がデフォルトで決まっているが、「環境設定」で保存場所を変更することも可能だ。留意点としては、システムごとにフォルダー作成し、関連する別の表(例えば、表引き入力に使用している表)は同じフォルダーに登録しておかねばならないことだ。
以下の表が直近の「食品管理」システムだ。表は2段表示になっている。桐は1画面に収まらない長い表の場合、表を5段階まで段数表示することができるので画面をスクロールしなくともよほど項目数の多い表でないかぎり、すべての項目のデータを確認することができる。右側のピンクの部分が「道具箱」だ。
また、一件の項目数が多すぎて見にくい会員名簿のような場合には、フォーム(入力画面)を作成しておけば、カード形式でデータを確認することもできる。簡易表示の「ワンタッチフォーム表示」を使えば、フォームを作成しなくともワンクリックでカード形式でデータを確認することも可能だ。
ちなみにマイクロソフトのAccessも入力画面を作成するための「フォーム」や独自の印刷帳票を作成するための「レポート」等の機能があり、機能的には似ているが、並べ替えや絞り込み機能を使うためには「クリエ」という機能と概念の習得が不可欠のようだ。使いこなすためのハードルは桐の方が圧倒的に低いように思う。Accessは情報処理の専門家向きのツールというのが私の見立てだ。
「食品管理」システム導入後
2年くらい前に冷蔵庫とパントリーの中の期限切れの食品を廃棄して整理したが、その後、やはり元に戻ってしまっていたことが「食品管理」システムを稼働させてみて判明した。それどころか、その時の整理で見落としがあったようで5年前の賞味期限の食品まであった。やはり見えないものは忘れられる。見えないものは使わないということを実感した。
テレビで有名タレントの豪邸を紹介する番組がよくあるが、キッチンがきちんと片付けられ、食器も食材もすべて収納されていることがある。しかし、仕舞い込んだものの管理はきちんとできているのだろうかと私はよけいな心配をしてしまう。
収納されたまま使われずに眠っているものがたくさんあるのではないだろうか。もしかすると期限切れのままご臨終の食材も相当あるのではないだろうか。うちの家内も「食品管理」システムが稼働する前は、「ちゃんと管理しているから期限切れのものはほとんどないわよ!」と発言していた。
しかし、現実は家内に言い逃れのできない事実を突きつけることになった。しかし、その代わりに賞味期限切れでもまだ使えそうな食材は使い切ろうということになり、期限切れのシチューの素や豆板醤で作られた料理を食べさせられる羽目になっている。これは、喜ぶべきなのか、悲しむべきなのか。
まあ、これも食品ロスを減らし、世界に貢献しようという理想からすれば受け入れなければならない現実だ。ただし、にぼしとか植物油のように酸化しやすいものを賞味期限切れで摂ると健康面での悪影響が考えられる。もったいなくてもこうした食品は廃棄すべきだ。その代り、酸化しやすい食品は早めに使い切る努力が必要だろう。また、ひとつ利口になったように思う?
よかったことは、家内も残っている食材を有効に活用しようと心がけていることだ。買い物も「食材管理」システムに入力したデータを基に印刷した買い物リストを使うようになり、重複買いがなくなり、在庫切れでないものは買うタイミングを考えて購入するようになった。これまでは勘でやっていたことをデータを使って取り組んでいる。女子バレーの躍進もデータ分析の成果だそうだから。家事もこれからはデータ管理の時代だろうか? おしまい
まだコメントはありません。