カテゴリー別アーカイブ: コラム

環境の大掃除

2021年となりました。今年もよろしくお願いします。
年末年始の外出を控えたためか、個人的にはあまり新年という感じがしていませんが。アンテナハウスも4日から営業しています。

私は年の区切りくらいを目安に、大掃除をしています。家の大掃除ではなく、開発環境の大掃除です。業務用の環境ではそうもいきませんが、プライベートの計算機はOSのクリーンインストールまでしていたりします。一定期間でシステムを一新することを「式年遷宮式」と呼ぶこともありますが、そこまで大袈裟なことはしていません。ただ、何度か行っていると「今なくすと困るもの」「なくすと後で後悔しそうなもの」「常に必要になるもの」など、日常で分類をしつつ作業を心がけるようになってきました。パスワード類はパスワード管理ソフトに、画像ファイルはクラウドストレージ上で分かりやすいように、といったこともあります。もっと素朴には、デスクトップ画面に使っていないファイルのアイコンがいっぱい……というのはあまり落ち着かないので。

しかしより重要なのは自分用の開発環境構築です。

依存ライブラリの競合や以前の開発の残骸による意図しない動作など、ある開発環境を掃除せず使い続けるのはなかなかリスキーです。自分用にカスタマイズした環境について一番把握している(べき)なのは自分ですから、「分からなくなってきたらリセットする」くらいの気持ちでいます。緊急性が無ければ実際に再構築するまで時間を置くことで、引き継ぐべき情報の洗い出し、次の環境で試行することの設定などを行います。

近年はローカルの開発環境もかなり調えやすくなったと感じています。
ラップトップ計算機のストレージに余裕ができたのでローカルでもDockerコンテナを多数置けたり、WSL2でWindows上でLinux環境が楽にテストできたり、Windowsでもサンドボックスが簡単に扱えるようになりました。エディタもVSCodeでインストールしているプラグイン環境を他の計算機のVSCodeに持っていったりと、プライベート用途程度であれば「天気が良いからOSをクリーンインストールしよう」くらいにハードルが下がってきたように思います。

一方ドキュメント環境はあまり調えられていません。個人的な抱負ではありますが、少しでもこれを向上させることを今年の目標とします。



情報充実の冬

プライベートでアドベントカレンダー(12月1日から25日までを数えるために使用されるカレンダーで、箱などを用意して窓を毎日ひとつずつ開けていくもの。から派生した25日間(あるいはそれ以上)ブログ記事などを毎日投稿、公開していくWeb上のイベント)を続けています。そう長い歴史があるわけではありませんが、技術記事の検索などをするとこの時期に書かれたものが結構あります。

アンテナハウスにはアドベントカレンダーの風習は今のところありませんが、技術情報、製品情報の充実には力を入れています。隔週火曜に定期開催しているウェビナーもその1つですね。

年内の残りのウェビナーは2つ、本日12月8日と、12月15日ですね。



※終了しました。

ウェビナーの内容を編集し後日動画で公開なども行っています。開催時間の都合上参加が難しい方も、アンテナハウスのYouTubeチャンネルに登録いただくと新着動画情報が分かります。

各製品ページやその他のページも随時更新されています。直近でも色々追加されているようです。


ドキュメント技術関連の日本語動画はあまりない?

つい先日、有名なLaTeX入門書の第8版が発売されました*1。私は6版の頃から購入していますが、新しい項目の追加もされており、旧版をお持ちの方もおススメです*2。使い方なども含めて時代に合わせた内容のアップデートの大切さも教えてくれる書籍です。基礎的、原理的な内容を扱ったものではないのに20年近く内容が更新されながら販売され続けている書籍というのはかなりすごいことだと思います。

ところで2000年頃は結構出版されていたXMLについての書籍はほとんど見なくなりました。「XMLが廃れた」というよりは「XMLを手書きする機会が減った」あるいは「基本を覚えた後はIDEのガイドに従うだけで済むくらいにツールが成熟した」ということの結果かもしれません。

いやいや「現代はみんな動画で情報を得ようとしているのかも」とYouTubeで「XML」を検索してみると、そこそこの件数が表示されました。しかし「PDF」で調べたときに比べるとかなり少ないようです。PDFはPDFで単語が検索にひっかかるものの話題がかなり異なる「ノイズ」が結構あったので軽く調べた程度ではちゃんとした数字を出すのは厳しいですが*3、PDFと比べ世間的な関心はやはり薄いのかもしれませんね。ちなみに「XSL」「XSL-FO」になると英語での結果を含めてもかなり限られる、というより日本語の動画がほとんどありません。

そんなPDFにしても、「このツールを使えばできます!」という内容がほとんどになり、「なぜかPDFという形式を使わなきゃいけないみたいだけど、なぜPDFがいいんだろう」といった技術的な話題を取り扱っているものはあまり見ません。「明日提出しなければいけない書類を前にそんな内容は観ていられない」というのはそうかもしれませんが、今の情勢は、そんな間に合わせの状況を変える転換点にきているのかもしれません。とりあえずの問題を解決するための「ツールの使い方」も大切ですが、より効率的に、根本的に問題を解決するためには技術そのものへの理解も重要です。「日本語で弊社の得意とするドキュメント関連の技術をしっかり動画で解説してほしい」というご要望がありましたら、ぜひ声をお寄せいただければ幸いです。

弊社PDF関連製品の使い方やウェビナーの過去回をまとめた動画を公開しています。

*1ですが、最初に付録の参考書籍一覧を見たとき「こんなのもう手に入らないだろう」と思っていたのに、気が付けば6割近くを所有していたり。一方で10年前にはフリーで配布されていた組版ソフトウェアの情報の方が手に入りづらかったりして歯がゆく思う今日この頃。

  1. *1 『[改訂第8版]LaTeX2ε美文書作成入門』(奥村晴彦,黒木裕介 著, 技術評論社, 2020-11-14, ISBN 978-4-297-11712-2)
  2. *2 TeXの始まりから数えれば40年くらい歴史あるものでも「枯れた」とは限らないのがソフトウェア(LaTeXについては今年かなりの大変更が入ったりしています)
  3. *3 LaTeXはLaTeXで組版と関係ないLatexが結構混じってくるので大変検索しづらいです

P.S. 記事を書いた後「記事タイトルはこれでいいんだろうか」と悩み、DITAやS1000D、SphinxやPerlDocなども検索してみましたが、タイトルは変えなくて良さそうでした。


「PDFは編集できない」って? ちょっとちょっと政府CIOの皆さん、その認識はぜひ改めていただきたい。

菅内閣目玉の政策として「デジタル庁」があります。デジタル庁は現在準備室が発足し、来年(2021年)の発足を予定しているようです。IT技術をつかってデジタル化を図るには、共通化やポータル化が必須なので、強い権限をもつデジタル庁を作るのは適切な考え方でしょう。

ところで、これに関連し、政府CIOポータルに「デジタル・ガバメント実行計画」というページがあります。

デジタル・ガバメント実行計画

全文(PDF)

この資料、PDFファイルで全215ページなのですが、検索すると、その中にPDFについて言及している箇所が2か所あります。

◎1か所目(p.56)

「(d)編集可能な電子ファイルによる申請書様式の提供
利用者が行政手続を行う際の利便性向上のため、当該行政手続に係る情報をWebサイト等で容易に入手でき、かつ、Webサイトの入力フォームを利用して直接申請書の作成を可能とする又は申請書様式の電子ファイルをPDF などの編集不可な形式ではなく、編集可能な形式の電子ファイルで入手可能とする。」

◎2か所目(p.75)

「また、業務上使用する文書等について、デジタルデータで作成された文書であっても、文書交換を行う際には紙媒体や PDFファイルなどの編集等が困難な形で流通しているなど、業務が非効率になっている場合がある。また、各府省のWebサイトで公開されている資料についても、編集が不可な状態のものや、資料のステータス(日付、会議名、担当府省等)が不明なものも散見される。」

これを読むと、PDFは編集不可、あるいは編集困難とされています。どうやら、デジタル政府では、申請書などはPDFファイルで用紙を配布するのはやめて、Webサイトの入力フォームを推薦したいようです。

では、実際のところ、PDFファイルは編集できない・編集困難なのでしょうか? 次のような事情を考えると、「デジタル・ガバメント実行計画」のPDFファイルに関する記述は、現在では適切ではないと思われます。

PDFは編集できるという事実
第一に、現在市場には、非常に多様なPDF編集ソフトが流通しています。有名どころは某A社製品ですが、アンテナハウスでも『瞬簡PDF編集』を販売しています。

第二に、アンテナハウスの『瞬簡PDF 書けまっせ』のように、PDFを紙のように見立てて、PDFファイルの上に文字を重ねて書きこむ(追記)ソフトも増えています。

第三に、PDFで申請用紙を作る形式として、PDFフォームがあります。PDFフォームを使えば、特別なツールを使わなくても、PDFフォームに文字を書きこむことができます。「PDFフォームとはなにか? 申請のデジタル化にPDFフォームの活用を期待する

Webフォームも良いですが、Webフォームはサーバーサイドの用意も必要であり、大きな開発工数や保守工数がかかります。また、専門家でないと多様なフォームを作るのは難しいので、非常に多岐にわたる形式のフォームを誰でも簡単に作成して配布するのはWebフォームでは難しいと考えられます。PDFをもっと活用する方が効率的でしょう。

ぜひ、政府CIOの方々には認識を改めていただきたいものです。


shunkan pdf henshuu
shunkan pdf kakemasse
tyotto hitoiki antenna house webinar

fo:bookmarkというマークアップから考えるしおり

『岩波国語辞典第八版』*1によれば、「しおり(しをり)」には2つの意味があります。

1. 本の読みかけのところに挟んで目印とするもの 2. 初めての人などにわかりよく説明した本。手引き

岩波国語辞典第八版

「目次」は次のように記されています。

(書物の)内容の題目を、書かれている順に並べて記したもの

岩波国語辞典第八版

しおりについて、1の意味では、読み手側が設定するものという印象が強いですね。ちなみに岩波国語辞典だとブックマークはWebブラウザのブックマーク(お気に入り)機能についての言及となっています。

さて、XML組版の仕様であるXSL1.1仕様にはしおりを作成するための機能fo:bookmarkfo:bookmark-titlefo:bookmark-treeが存在します。1.1の仕様に1.0との差異が記載されているのですぐにわかりますが、実は1.0のときには存在しなかった機能です*2

『XSL-FOの基礎 第2版』*3にしおりのFOについての解説があります。また、Antenna House XSL Formatterの*4サンプルFOのページ*5からしおりの設定されたPDFを確認できます。

<fo:layout-master-set>
    …略…
  </fo:layout-master-set>
  <fo:bookmark-tree>
    <fo:bookmark internal-destination="MARK001">
      <fo:bookmark-title font-weight="bold">
    目次</fo:bookmark-title>
    </fo:bookmark>
    <fo:bookmark internal-destination="MARK002"
                 starting-state="hide">
      <fo:bookmark-title>第1章</fo:bookmark-title>
      <fo:bookmark internal-destination="MARK003">
        <fo:bookmark-title>1.1</fo:bookmark-title>
      </fo:bookmark>
     ...
     </fo:bookmark-tree>
     ...
    <fo:page-sequence ...>
      <fo:block font-size="2em" font-weight="bold" space-after="5mm" id="MARK001">Bookmark sample-1</fo:block>
        <fo:block font-size="1.5em" font-weight="bold" id="MARK002">Lorem Ipsum</fo:block>
          <fo:block space-before="4mm" margin-left="2em" line-height="1.4">
         <fo:block keep-with-next="always" font-weight="bold" id="MARK003">Lorem ipsum dolor sit amet</fo:block>
            <fo:block>...</fo:block>
        </fo:block>
...
</fo:page-sequence>

ごく簡単に説明すると、fo:rootの子としてしおりのツリーを用意し、その子として、目的のIDやURLなどをプロパティの値に持つしおりfo:bookmarkとしおりの項目名fo:bookmark-titleを記述します。上の例ではfo:blockにそのIDが記述されていますね。ツリー構造ですので、階層も表現できます。

PDFなど、ページドメディアへの出力を意識したマークアップであるXSL-FOの機能として用意されていることから分かる通り、これは文書コンテンツ提供側が用意するしおりです。
XSL-FOは(中間形式にせよ)ページドメディアとしてかなり明示的なマークアップを求めますから「fo:bookmark*」は「この箇所をしおりとする」というはっきりとした意思表示となります。
文書コンテンツ作成者がコンテンツ頒布時に「この部分は読みかけ」というしおりを作ることは稀なことと捉えて良いでしょう。そして、fo:bookmark-titleというマークアップ名から分かる通り、しおりの項目名は長い段落などを記述する箇所でもありません。

目次項目は当然その項の内容を反映しまとめたものになりますから、しおりは多くの場合目次項目と同じ箇所でマークアップされ、対応したPDFビューアーでは「しおりを表示」といった機能でページ表示とは独立して表示できます。
特に数百、数千ページのPDF文書を頻繁に読む機会のある方は頷かれるのではないかと思いますが、紙の文書ではそれこそ「しおり」を挟んで分厚いページの束をまとめてむんずと掴んで目次に戻ったりできますが、PDFビューアー上で毎回目次ページへ戻って目次項目を確認するというのはそこそこ時間がかかります。

個人的には、しおりの重要な点として「ページ外の要素」であることが大きいのではないか、と考えています。目次で「2.3 詳細 200ページ」、文章中に「299ページに詳細」、索引ページに「fo:bookmark…300p」といったページ参照があるのはそれはそれで重要ですが、「本文を読みながら文書(あるいは文書外)の他の箇所への目印へすぐにアクセスできる」機能がしおりといえるのではないでしょうか。そして、XSLでは文書コンテンツ提供側がそれを提供することになります。

ところで、XSL-FOとXSL-FOプロセッサーによる処理ではPDFの作成時にしおりをマークアップすることになるので、すでにPDFとなっているものにしおりを付与することは範囲外です。Antenna House Formatterでは「PDFを画像のように埋め込む」といったことができるので、多少トリッキーな方法で後からしおりを付与することもできなくはありません。しかし専用のソフトウェアがあればもっと分かりやすく、そして効率的にしおりを付与できます。

antenna house webinar pdf bookmark

隔週で火曜に開催している「ちょっと一息 アンテナハウスウェビナー」、11月10日(火)16時からは「そもそも、PDFのしおりとはなにか ~目次と何が違うのか。どう作って活用するか~ 」というテーマでお送りします。この記事を書いているのが担当者でないため、発表内容の詳細はわかりません。しおりってなんなんでしょうね……。この謎を明かすためにも明日のウェビナーは必見です。

参考文献・資料

  1. *1 『岩波国語辞典第八版』(岩波書店, 2019年11月22日第1刷発行, ISBN 978-4-00-080048-8)
  2. *2 https://www.w3.org/TR/xsl11/#change10
  3. *3 https://www.antenna.co.jp/AHF/ahf_publication/data/xsl-fo-v2/201603282131.html『XSL-FO の基礎 第2版 – XML を組版するためのレイアウト仕様』(アンテナハウス株式会社, 2017年3月, ISBN 978-4-900552-48-7)
  4. *4 Antenna House Formatter
  5. *5 https://www.antenna.co.jp/AHF/ahf_samples/sample-fo.html#pdf


会議記録ってActivityStreamsなのでは

先日、社内の会議で議事録を担当する機会がありました。
「議事録」と呼ばれる形では読みやすさのために不必要なものを省くことも必要ですが、最終的な議事録として整形する以前の状態として、会議の記録は詳細に記録しておくにこしたことはありません。

音声記録を取ってそこから書き起こすにしてもSpeechToText技術で自動文字起こしをしたり、書記を指定せず会議中に共同編集ファイルに記録していくなど、ここ数年で普及が進んだ技術をフル活用することもできるでしょうし、その導入コストやセキュリティリスクと従来の方法を天秤にかけて後者を選ぶこともあるでしょう。

さて、さまざまな制限があるとき「何を記録するか」という観点が重要になります。
この取捨で落ちた情報は(推測や関連情報の補完といったことは考えられますが)基本的に復元できません。

会議開始前に用意できる情報としては次のようなものがあるでしょう。

* 会議の題目
* 日時
* 出席者、欠席者
* 事前資料

会議の流れがある程度決まっているのであれば、あらかじめ枠組を用意しておき、内容をある程度カテゴライズできます。

そういった事柄は先でも後でも良いとして、主題は会議の内容自体の記録です。
会議終了後議事録を再構成することを考えると、落としたくない内容は次のように整理できます。

* 発言者
* 発言内容
* 発言の文脈(前後関係)
* 提示資料

文脈についてはもう少し分ければ「何についての発言か」「誰に対しての発言か」「会議のどのタイミングでの発言か」といった情報になります。
また、会議のタイミングに関連して、会議そのものではないものの「途中退室」「一時中断」といった情報も記録できた方がよいかもしれません。

さて、発言者やタイムスタンプ、発言内容といった内容に加えて、さまざまな出来事を記録するための標準仕様は何でしょうか? そう、W3CのActivityStreamsです。

ActivityStreamsは2017年に2.0がW3C Recommendationとなった、ユーザーのメッセージ投稿、フォロー、などのActivityを記録するための形式です。原型としてはユーザーフィードの形式であるAtomを拡張していますが、2.0ではJSON Linked Data(JSON-LD)を基本エンコード形式としています。

ActivityStreamsとして規定されているのはデータ形式としての仕様までで、
このActivityStreamsを採用する分散SNSプロトコルとしてActivityPubがあります。
ActivityPubの実装としてはMastodonなどが有名ですね。

分散SNSの概念説明などをするととても長くなってしまうため割愛しますが、分散SNS用プロトコルについて短くまとめると「プロトコルを共通にすれば他のサービスと共通のインターフェースでやりとりできる」という、標準仕様の利点をSNSにも適用したもの、といえるでしょうか。

ActivityStreams以前にもメッセージングの共通プロトコルはXMPPなどあったわけですが、
これは「JSON-LDを基本エンコード形式とする」点、「メッセージに留まらないActivityを記録する」点など、マイクロブログやチャットに留まらないSNS全般とインターフェースを持てるように設計されています。それこそ議事録なども含めてActivityStreamsに落とし込んだ企業製品もすでにあるようです(記事執筆中に初めて知りました)。

話を戻して、会議の記録とActivityStreamsのマッピングについて考えてみましょう。
疑似的なものなので、typeの指定などが必ずしも適切なものになっていない場合があります。
厳密にはURIであるべき箇所などもあります。

会議中の1つの発言をActivityStreamsで表してみます。

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "上司1の発言",
  "type": "Create",
  "actor": {
    "type": "Person",
    "name": "上司1"
  },
  "object": {
    "type": "Note",
    "name": "上司発言1",
    "content": "会議を始めます"
  },
  "published":"2020-10-26T15:00:00Z"
}

@contextはJSON-LDでのXML名前空間のようなものとして捉えてください。
typeなどは、コアの部分とは別に規定された語彙を用います。
actorはそのactivityを行う主体、ここでは「上司1」というPersonですね。
「上司1がNoteというタイプのObjectをCreateした」ことで「上司1が発言した」ことが表せるというわけです。

選択式の質問を行った場合をみてみましょう。

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "name": "質疑応答2",
  "id": "shitsugi2",
  "type": "Question",
   "content": "昨日の朝はごはんとパンどちらを食べましたか?",
   "oneOf": [
     {"name": "ごはん"},
     {"name": "パン"}
   ],
   "replies": {
     "type": "Collection",
     "totalItems": 3,
     "items": [
       {
         "attributedTo": "上司1",
         "inReplyTo": "shitsugi2",
         "name": "ごはん"
       },
       {
         "attributedTo": "部下2",
         "inReplyTo": "shitsugi2",
         "name": "パン"
       },
       {
         "attributedTo": "部下1",
         "inReplyTo": "shitsugi2",
         "name": "パン"
       }
     ]
   },
   "result": {
     "type": "Note",
     "content": "昨日の朝、ごはんを食べたのは1人、パンを食べたのは2人ですか。"
   }
 }

大本のオブジェクトがQuestionタイプ、そして択一の選択肢oneOf、その回答をrepliesのCollectiontとしています。attributedToはここでは回答者、inReplyToが何に対しての回答なのかを表します。resultとして回答の結果に言及しています。

「会議3」に途中参加の人「同僚1」がいたことを表してみます。

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "同僚2が途中参加",
  "type": "Join",
  "actor": {
    "type": "Person",
    "name": "同僚2"
  },
  "object": {
    "type": "Group",
    "name": "会議3"
  },
  "published":"2020-10-26T15:00:00Z"
}

3つほど例を作ってみました。全てとはいいませんが、大部分のことはActivityStreamsで規定された範囲で表せそうな感じがありますね。

オンライン会議が身近になったことで、会議や議事録作成の機会が増えた方もいるかもしれません。
より効率的にできるところは進めていく、その第一歩は「物事をふさわしい枠にはめる」ことではないかと思います。もちろん上のように生のJSONを記述するのは非効率ですが。
そんな視点から、標準仕様を読んでみるのも面白いのではないでしょうか。

さて、「PDF作成でも用途にふさわしい作り方があるのでは」ということで、2020年10月27日(火)16時からウェビナーで「PDFお助け便利帳『無料で作るPDF 3つのポイント+活用ノウハウ3選』」をお送りいたします。

参考資料


オンライン化の難しいイベント

この間の休日を利用して、ある能力認定試験を受けにいきました。
春に行われる予定の試験でしたが、情勢を受けて中止、延期をされていました。
物理的な接触機会が減ると、紙面上で得られる情報の存在感が以前より増します。
公的な資格などはその分かりやすい形ですが、肝心の資格を得るための機会が
情勢を受けて失われるというのはなかなか難しいところです。
数十万人規模の試験となると、影響は大きいですね。

会場は同系統の別試験を受けた時よりも受験者同士の間隔が広く取られており、会場前で朝時点での体温を記入した用紙の提出や簡易的な検温、マスクの装着義務付けなどおおよそ可能な対策が行われていました。「これをしていれば安全!」というものではありませんが、「現実的に可能な範囲で対応する」新たな生活習慣をこういった場でも意識させられます。

大人数が同時に受験するとなると、不正を防ぐ措置、試験を行う設備の用意として受験者を会場にまとめて、紙の回答用紙に記述し、監督者が巡回するという形をコストパフォーマンスで上回るものはなかなかありません。
とはいえ、大規模な感染リスクという新たなコストを込みで考えると、悩ましそうな問題ではあります。あるいはもう少し小さい規模で問題の作成コストなどが下がるのであれば、受験者がコンピュータ環境のある会場へ赴いて試験を受けるCBT試験なども可能になるかもしれません。

せっかく開催できた試験ですが、試験が始まっても空席のままのところが結構な数ありました。さまざまに事情があるでしょうが、次の機会がこれまで通りあるか分からないことを考えるともったいなさを感じました。

試験は午前と午後に分かれており、午前試験の後の休憩時間で各自で昼食をとります。会場付近の飲食店が軒並み営業しておらず、コンビニと小規模な店ひとつくらいしか利用できないため、受験者であふれてしまっていました。もともと休日は営業していない店もあるかもしれませんが、貼り紙で臨時措置を行っていると書かれた店もありました。物理的に大勢が集まる機会というのはこういったところでも現在の情勢と相性が悪いようです。

午後試験を受けて帰宅。記憶の彼方に去りつつある知識を絞りだして答えを導きだす作業は久々で、少し楽しくもありました。

さて、こういった「開催はしたいが迅速なオンライン化は難しいイベント」がある一方で、「今までされていなかったがオンラインにもできるイベント」のオンライン化はかなり進みつつあるように感じます。オンラインでの開催を経て、次回はまた会場での開催を試みるイベントもあります。その過程で「なぜ今までこの形態でイベントを行ってきたのか」と改めて洗い出す作業はイベントをより洗練させていく上で大切なものでしょう。

「このイベントはどのような形態があっているのか」「この形態で行うならどのように見せ方を変えればいいのか」といった試行錯誤はドキュメンテーションにも共通することかな、と思い浮かびましたが、コミュニケーションを要するほとんどのことで共通するのかもしれません。

そんな試行錯誤の一環ともいえる弊社のウェビナーやイベントにもご参加いただければ幸いです。

先日の記事にもありましたが、
なにか、こんな話が聞きたいというご要望がございましたら、ぜひ次までメールでご連絡ください。なんとか知恵を絞ってご要望にお応えいたします。

連絡先 アンテナハウスウェビナー委員会
メールアドレス cas-info@antenna.co.jp

テレワークの時代、皆さんはPDFを上手に活用できていますか?

PDFお助け便利帳『無料で作るPDF 3つのポイント+活用ノウハウ3選』
16:00〜16:45


あらためて家計簿を電子管理する

個人的な話題ですが、最近、個人の家計簿をつけることにしました。付けた方が良いとは思いつつ、ざっくりとした勘定以外は今まで行っていなかったのです。
利用している銀行をネットバンキングの1社にし、おおよそ全ての金銭記録が把握できるようになったので挑戦することにしました。
個人事業主などではシビアに記録する必要もありますし、事前にしっかりと勉強をする、専門家に依頼するなどが必要ですが、自分で個人の銀行記録を管理する程度であれば軽めの気持ちで始めるのも良いだろうと思ったのです。

昨今かなりの銀行が電子データでの情報のダウンロードも可能になっています。ダウンロードできる形式は銀行によりけりになってしまいますが。

利用していた銀行ではCSV形式でデータがダウンロードできるようでした。
使用したソフトウェアはCSVに対応していましたが、日付のフォーマットがそのままでは読み込めず、一度他で変換してから取り込むことに。

CSVは単純な構造ですから、意味あるデータとして扱う際はたいてい、ソフト側で項目の対応付けを行う必要があります。自動でやってくれるソフトウェアもありますね。今回は「入金」「出金」「説明」「日付」をマッピングしました。

使用したソフトウェアは他にOpen Financial Exchange Format(OFX)形式などにも対応していました。これは銀行などで使用されるXMLアプリケーションで、WindowsではMicrosoft Money形式と表示されていたようです。XMLでオープン仕様なのでMicrosoft Moneyが販売終了しても扱えなくなるものではありませんが、有名製品が商用販売を終了したことで「過去のもの」と思われている方もおられるようです。
私などはOFX形式でデータがあった方が便利と感じますが、Webを散策していると「たいていのソフトで開くことのできるCSVでダウンロードできる銀行を使いましょう」といったことをおっしゃられる方もいて、なるほど人や環境によって、必要な情報の精密さも違うんだなと改めて感じました。

電子決済がどっと普及したこともあり、家計簿をスマホアプリなどで管理するハードルも下がってきました。
私のように過去に複雑だと思って手を付けなかったことを今改めて始めてみると、思ったより簡単ということもあるかもしれません。手作業で行うことが多いと感じたら、ソフトウェアやファイル形式を見直す時期かもしれません。

ちなみに、その次に取り込んだデータを仕分けする作業を行ったのですが、数年分の記録があり、休日中に作業は完了しませんでした。


アンテナハウスでは、隔週火曜16時からアンテナハウス ウェビナーを開催しています。


ユーザーニーズとウェビナー

先日、家族から「会社から配布された書類に文字を入れて提出しなければいけないらしいが、どうしたらいいのか」と相談されました。
メールに添付されたファイルはPDF。これは弊社の製品を売り込むチャンス!?と思ったものの、「瞬簡PDF 書けまっせ」を売り込んでいる途中でもう一通メールが。こちらはどうやらMicrosoft OfficeのExcelファイルが添付されていたようで、最初のメール添付ファイルは書くべき書類のサンプルだったようです。

売り込みは途中で頓挫したものの、勤務している会社でどういった製品を取り扱っているのか、普段は「なんか難しそうだから聞きたくない」という態度の家族にも紹介できる機会となりました。
とはいえ「それが自分たちの生活や仕事にどう影響するのか」という範囲でしか興味は持ってもらえず、PDFについても「OfficeソフトのファイルやWebページがあればいいじゃないか」という家族の意見を覆すには至りませんでした。

これは逆に考えれば「それが自分たちの生活や仕事にどう影響するのか」「わかりそうな話」であれば興味はある、ともいえます。加えて「素早く」とついていればなおのこと。

さて、アンテナハウスでは「アンテナハウス ウェビナー」を毎月第2火曜、金曜の16時より開催しています。
弊社の製品や技術でどんなことができるのかわかりやすく紹介、解説する試みですが、これは同時に「どんな製品や技術が皆さんの生活や仕事で役立つのか」「どういった事柄と絡めて知りたいのか」「どのくらいのレベルで知りたいのか」といったフィードバックを従来よりも気軽に聞きたいという、皆さんと弊社の双方向のコミニュケーションの試みでもあります。

はこんなセミナーもあります。

ぜひご登録、ご参加いただき「どこがわかりやすかった」「ここを教えてほしかった」など、ご意見をいただければ幸いです。

他にも、「マンガでわかる!! アンテナハウス システム製品利用例シリーズ」という、
ストーリー仕立ての製品利用例のご紹介もしています。


テレワークの目的を考える やはり日本では首都直下地震対策が一番重要

3月下旬から新型コロナウィルス感染症(COVID-19)対策として日本でも世界でもテレワークで働く人が急増しました。

前回(2020年5月よりテレワークを本格導入へ。中小企業のテレワーク実践例としてご参考まで。)は、主にCOVID-19対策の緊急措置をきっかけとして、弊社でテレワークを導入したこと、その問題点について報告しました。

その後、日本では5月下旬に緊急事態が解除され、また欧米でも解除の動きがあります。それに伴いテレワークについて大局的に・冷静に見直そうという話題も紹介されています。例えばFacebookは、COVID-19対策で大部分の社員が自宅からテレワークで働くようになったため、シリコンバレーの本社がゴーストタウン化していて、今後、シリコンバレー本社の価値などを含め抜本的な対策を考えていると発表しています[1]。

日本では首都圏を除くエリアが5月18日から緊急事態解除、首都圏が5月26日から緊急事態解除となりました。新型コロナウィルス(SARS-Cov-2)がいなくなったわけではなく、まだ感染リスクが残っている状況ですが、都心に働く人が徐々に戻ってきているようです。弊社でも、現在は希望者のみを対象として平常時のテレワーク規定を運用しており、社員の約3割がテレワーク、約7割が通常勤務となっています。

2カ月程度ですが、テレワークを実施する過程でいろいろな問題点が上がってきています。今後、そうした問題の一つ一つにきめ細かく対処することが必要です。一方で基本に立ち返って、なんのためにテレワークを導入するのか、一番大きな目標として、なにをすべきだろうかを最初に考えてみたいと思います。

首都圏直下巨大地震の可能性を考える

テレワークの目的を原点から考えなおすとすると、日本の大都市、特に東京が抱える、感染症とは別で、もっと大きなリスクである「首都直下巨大地震」について考えざるを得ません。

米国や欧州(イタリアやスペインを除く)の多くの先進国の国土と比べると、日本の主要部分が所在する日本列島は、世界の中でも特に火山と地震が集中している地域です。その原因はプレートテクトニクス(地殻表面が多数のプレートに分かれていて、各プレートはマントル対流に載って移動するという現象)にあります。プレートテクトニクスを少しでも学んだことがあれば、地球上の火山と地震はプレート境界線に沿って分布していることを知っていることでしょう。

最近の研究では、日本列島の中央から北部はオホーツクプレートに属していて、その南端である中部地方と関東地方の下にはフィリピン海プレートが沈み込んでいるそうです。その境界が相模トラフです。フィリピン海プレートの下にはさらに太平洋プレートが沈み込むという複雑な構造になっています[2]。プレートの移動速度は、例えばフィリピン海プレートは年間3cm程度で、この移動がプレート間の境界面にひずみ(すべり欠損)として蓄積されます。1923年9月に発生した大正関東地震(M7.9)はフィリピン海プレートの上部境界で発生しています。その前のM8クラスの地震は、1703年五代将軍徳川綱吉の時代の元禄関東地震(M8.1)とされています。これもフィリピン海プレートの上部境界で発生しています。この間200年ですが、大正関東地震では200年分の移動に相当する6~7mのプレート境界のすべり欠損が解消されたとのことです。200年に1回であれば次の関東大震災は2100年過ぎになりそうですが、関東地方の地下は複雑で様々なタイプの大地震の巣があります。そして、M7クラスの地震は過去100年間に5回発生しています。こうした地震は周期的でないため地震本部では確率予測をしており、それによると「30年以内にM7クラスの地震が発生する確率は70%」とされています[3]。前回のM7クラスの地震は1987年の千葉県東方沖地震(M6.8)です[4]。確率予測のため、いつ起きるか分からないが、いつ起きても不思議ではないということになります。

会社としてどのように首都直下地震に備えるか

大地震対策の基本としては、事務所の建物や内部の耐震対策があります。しかし、耐震性の強化で仮に、震災時の事故を回避したとしても、首都圏ではインフラの破壊、それによる水や食料不足など様々な問題が見込まれます。弊社では経営理念に「社員が仕事を通じて物心両面の幸福を得られるようにする」ということをあげていますが、それを平たく言えば、会社とはそこに集まった社員の生活の糧を得るための場ということになります。地震で経済的に飢えてしまっては会社の役目を果たせません。

そこで、仮に首都直下大地震に遭遇してしまっても、会社がなくなることがなく、ずっと継続していけるようにしなければなりません。こうしたことに備えるには、やはり働く場所を首都圏に過度に集中させず、地方に分散化していくことが重要だと思います。そのためにテレワークを活用することが重要だろうと考えます。それにしても日本という国は災害が多いですね。

[1] Facebookが社員半数をリモートワークに、シリコンバレー外に複数の拠点開設へ
[2] 『日本列島の下では何が起きているのか』(中島淳一著、講談社ブルーバックス、2018年10月発行)第10章 関東地方の地下で何が起こっているか?
[3]  関東地方の地震活動の特徴 (地震本部)
[4] 『首都直下地震』(平田 直著、岩波新書、2016年2月)


Pages: Prev 1 2 3 4 5 6 7 8 9 10 ... 110 111 112 Next