カテゴリー: ビジネス

  • Gmailに届いた領収書などを自動保存するGoogle Apps Scriptを作った

    Microsoft Power Automateを使った業務の自動化をこれまでかなり高いレベルで進めてきましたが、個人のGmailに届くメールからの経費精算業務とかも自動化を進めたいと思って、Google Apps Scriptで2つのスクリプトを作りました

    マネーフォワードクラウド経費などクラウド会計システムを利用していればかなりの部分は自動化されるものの、それらでカバーできない部分もあるのと、他の用途でも活用できるように汎用性を持たせた形で開発

    1つは、Gmailに届いたメール本文を、差出人アドレス(ドメインのみでも可)を条件として、Googleドライブの指定フォルダにファイル名 [yyyyMMdd_HHmmss_Vendor.pdf] のルールでPDFとして自動保存するスクリプト「GmailToPDF」

    もう1つは、Gmailに届いたメールの添付ファイルを、差出人アドレスとメールの件名を条件として、Googleドライブの指定フォルダにファイル名 [yyyyMMdd_HHmmss_元ファイル名or新しいファイル名.元拡張子]  のルールで自動保存するスクリプト「AttachementToDrive」

    例えば、Cloudflareからの領収書は「cloudflare_invoice_2024-12-18.pdf」というファイル名形式で届くので、同日に2通発行されるとファイル名が重複するとか、Google Workspaceの領収書は「5119000000.pdf」という形式で、どこからの領収書なのかファイル名で判別できないとか、そういった点をカバーする形でファイル名をつけるようにしています

    スクリプトはGitHubで公開しているので、興味のある方はぜひご参考ください

    https://github.com/akihisa-higuchi/Google-Apps-Scripts

  • 0.7mmのこだわりと、速乾性が高くて滲まず書き味も良い 三菱鉛筆 ジェットストリーム

    高校の入学祝いでPARKERのボールペンを貰ってからずっと愛用していたのですが、2011年にミニマリズムを意識してからはその辺で売ってる市販品を色々と試し始め、

    最終的に書き味がすごく気に入った三菱鉛筆のジェットストリームを長い間使ってきました

    その後、PARKERに挿せるジェットストリームの替芯が出たことを知って、DUOFOLDに買い替え

    Parker・Moleskine・ポストイット

    速乾性が高くて滲まず書き味も良い 三菱鉛筆 ジェットストリーム

    以前に、書き心地やインクの滲みが気になったので、ボールペンの買い換えを検討していた時に、評判が良いのは知っていた三菱鉛筆のジェットストリームを店頭で試筆したところ、

    速乾性が高くて滲まず、書き味も良く、これまで使ってきた中で間違いなく最高のボールペンで、他との違いが想定以上で、すぐに購入しました

    スキャンして共有するというデータ時代に対応する

    紙の文書をスキャンした場合、文字が読みづらいことがありますが、0.7mmのボールペンだと文字がハッキリするので、手書きした箇所でこれが起きることがなくなります

    スキャンして共有が当たり前になった今では、ボールペンは0.7mmを選ぶことをオススメします

    また、自分はデジタル活用が進んでもうやっていないのですが、青インクとの使い分けも便利です

    誰かが手書きした部分が含まれる文書が資料として配布された場合、元々の手書き箇所と自分が追記したものが一目でわかるので、スキャンして共有した時も区別がつきやすいです

  • ペーパレス化は目的を明確に

    ペーパレス化は、目的と目標が曖昧なまま進められてしまうことが多いようです。

    ペーパレス化によるメリットは大きく三つ、一点目は印刷コストや保有コストの削減、二点目は作業効率の向上、三点目は情報へのアクセス性の向上です。

    このうちどの点をもしくはすべてを抑えるのか、どのレベルまでの成果を求めるのかで、ペーパレス化の方法が変わります。

    享受できる利益とペーパレス化に必要となるシステムの導入や教育研修等のコストを勘案して、データとして作成した文書をデータのまま活用するのはもちろん、紙の文書をデータ化するところまでやるのか、またそのデータに文字データを含ませるのか、社外から携帯端末でデータへアクセスさせる等、ペーパレス化の方法とそのレベルを決めなければなりません。

    文書をデータとして活用できる環境

    ペーパレス化の目的を達成するためには、文書をデータとして活用できる環境を整えることが必要です。

    まず、前回の「ペーパレス化はなぜ失敗するのか」で紹介した大画面ディスプレイの採用やマルチディスプレイ化などによるパソコン上での作業領域の確保が最低限必要となり、その次に目的に応じて以下のような取り組みが必要となります。

    文書作成の効率化

    各種文書のテンプレート(雛型)とサンプル(作成例)を社内ネットワーク上で公開することで、文書作成の効率化が実現できます。

    文書データの検索

    Windows Vista 以降の Windows、Mac OS X 10.4 以降の Mac OS は、従来のファイル名のみの検索ではなく、文書データの内容も対象とした実用性の高いファイル検索機能を有しており、これらのOSを利用すれば、文書データの検索効率は格段に高くなります。

    社外からのアクセス

    ノートPCや携帯電話等により、一定のセキュリティ性が確保される方法で社内の文書データへアクセスできれば、取引先との打ち合わせや営業においてその文書を活用することで、より高い成果を期待できます。

    また、取引先との打ち合わせに遅刻しないよう、30分前に近所の喫茶店等で待機することもあると思いますが、そういった時間や移動時間に社内のデータにアクセスできれば、その時間をムダなく活用することができます。

    紙の文書をデータ化する

    データ化された文書を活用する環境が整えば、紙の文書のデータ化も検討事項になるでしょう。しかし、紙文書のデータ化はその効率が良くなければ進まないにも関わらず、効率よくデータ化できる環境が整っていることは少ないのです。

    例えば、サラリーマン時代には、複合機を使って文書をデータ化していましたが、スキャンに時間がかかるため、あまり活用する機会のない書類は紙のまま保管していました。

    起業してからも、しばらくその方法が続いたものの、外出先でデータを活用することの重要性が高まったこと、iPhoneやオンラインストレージ等、社外でデータを活用できる手段が充実したことにより、紙文書は原則としてすべてデータ化することにしました。

    とは言え、これまでの複合機ではスキャンに時間がかかりすぎるので、それを解決するために、専用のドキュメントスキャナー 富士通 ScanSnap と、また製本された書類を裁断してスキャンできるよう、断裁機 プラス PK-513L を併せて導入しました。

    ScanSnap のスキャン速度はかなり速いです。印字率の高い書類でもカラー書類でも、A4 1枚 両面を約2.5秒でスキャンします。

    また、両面同時にスキャンできるところはさすが専用ドキュメントスキャナーだと感心します。これだけ高速に書類をスキャンできると、作業が煩わしくて紙文書のデータ化が進まないということもありません。

    断裁機は、他に安いものもありますが、180枚もの紙をまとめて裁断できる、垂直に裁断するため切り口がキレイ、光で裁断位置を確認できると、他の機種と比べてかなり便利であるためこの機種にしました。何より、ScanSnapと併用している人が多いことも選択する決め手になりました。

    これにより、製本された書類はもちろん、書籍もすべてデータ化することができました。

  • ペーパレス化はなぜ失敗するのか

    ペーパレス化で作業効率が下がる

    2000年頃からペーパレス化という話をよく聞きますが、まだその成功例は多くありません。紙をデータ化したからといって作業効率が上がるとは限らず、逆に作業効率が下がるケースの方が多いのです。

    その原因は主に二つで、一つは作業者のITレベルの問題です。ただし、こちらはペーパレス化を進める際には誰もが想定する課題であり、大抵は必要な教育研修が計画・実施されることから大した問題にはなりません。

    ペーパレス化が失敗する一番の原因は、もう一つの作業領域の問題にあります。

    データ化により作業効率が33%低下

    そもそも、データ化した書類はどのように利用されるのか。その大半は、何らかの書類を参照しながら別の書類を作成するまたは何らかの作業を行うという形で利用されます。

    この場合、紙の書類であればデスク上に1枚でも複数枚でも並べて参照しながらPCで作業ができますが、データ化した書類の場合はPCで表示するため、その分肝心の作業領域が狭まります。

    多くの企業では、17~19インチのディスプレイが1枚という環境で作業を行っているため、書類を表示しながら同時に作業を行う場合、書類の表示だけでおおよそ半分もの画面を使うことになります。

    画面の領域(解像度)が2倍になると作業効率は約33%向上するため、この場合は逆にそれだけ作業効率が低下することになるのです。

    書類を保管する物理的スペースが不要になる、検索により必要な書類にすばやくアクセスできる等の利点を勘案しても、メインの作業で作業効率が33%も低下すれば、総合的に見てマイナス要素の方が大きくなるため、ペーパレス化を進める意味はありません。

    それにも関わらず、このような当たり前の課題をペーパレス化を進めようとする担当者もベンダーも認識していないことが多い、もしくはベンダーはその課題に気づいていても、システムを売り込む立場であることから、そういったネガティブな情報を出さないため、実際にペーパレス化を進めて失敗してみるまでその重大な課題は顕在化しません。そのため、多くのケースにおいてペーパレス化は失敗するのです。

    大画面やマルチディスプレイ化は必須

    もし、本気でペーパレス化を実現したいのであれば、まずはディスプレイ上に十分な作業領域を確保しなければなりません。

    そのためには、大画面ディスプレイの採用や、ディスプレイを追加して2枚以上で利用するマルチディスプレイ構成が必須と言えます。

    ペーパレス化を進めなくとも、先ほどの画面領域が2倍になると作業効率が約33%向上するという点より、業務用PCでの大画面ディスプレイの採用やマルチディスプレイ化は強く推奨します。

    特に最近では、24インチ以上のディスプレイも3万円ほどで購入できるため、費用対効果が極めて高く、もし、現在19インチのディスプレイを使っていて、これを24インチ2枚の構成に変更した場合は、作業効率は約84%も向上し、十分な作業領域が確保されたことでデータ化された書類もストレスなく扱うことができます。

    しかし、これだけではペーパレス化の阻害要因を解消しただけで、まだペーパレス化の成功には届きません。長くなるので続きはまた次回。

  • オープンソースソフトウェアが抱える問題

    ブログをWordPress 2.8.1 へバージョンアップしました。

    WordPress 2.8.1では、先月公開された WordPress 2.8が抱えていた自動アップグレードを行うとWordPressを含むサーバー上のファイルが削除されるという致命的なバグが解消されています。

    WordPress 2.8 がベータテストを終えた正式版であったにも関わらず、非常に初歩的かつ致命的なバグを抱えていたことは大きな問題となっていますが、これはオープンソースソフトウェアが抱える根本的な問題とも言えます。

    オープンソースソフトウェアが抱える問題

    オープンソースソフトウェアに対して、無料で完成度が高く、特にシェアが高いほど安定性もセキュリティ性も高いというイメージを持たれている方が多く、安易にオープンソースソフトウェアを導入する企業も増えています。

    しかし、シェアの高いオープンソースソフトウェアが常に安定しているとは限りません。

    今回問題となったWordPressは、世界トップシェアを誇るオープンソースのブログシステムです。そのシステムのベータテストを終えた正式版で、非常に初歩的かつ致命的なバグが発生しました。

    通常、ソフトウェア開発時のテストは、テスト計画を作成した上で、すべての機能が正しく動作するか一通り検証します。

    この後、システム動作環境の違いによる問題や想定しない動作による問題を発見するために、ベータテスト期間を設けてユーザーにテストを委ねることがありますが、これはあくまで機能テストが終わった後の話です。

    しかし、無償で配布するオープンソースソフトウェアでは、製品のようにバージョンアップの度に開発者が十分な機能テストを行うことは難しいという状況があります。

    そのため、新規に組みこんだ機能の機能テストは開発者により行われるものの、既存機能の機能テストはベータテストに委ねられることも多いのです。

    今回、WordPressで、自動アップグレードという一般ユーザーがアップグレード時に必ず実行する機能に致命的なバグが残っていましたが、開発者が既存機能に対するテストを行っていれば簡単に発見されていたと思います。

    しかし、そのテストをユーザーに委ねた結果、正式版を配布するまでバグが発見されませんでした。あくまで推測ですが、以下のような理由が考えられます。

    オープンソースのベータテストに参加する人の大半は、プログラムに精通したエンジニアです。彼らのほとんどは、初心者向けの機能である自動アップグレードを使わずに手動でアップグレードを行ったのではないかと思います。

    ベータテストのユーザーは、テスト計画に基づいたテストを行っているわけではないので、手動でアップグレードを済ませてしまえば、自動アップグレードの検証は行わないでしょう。

    また、自動アップグレードで不具合が発生したユーザーも、WordPressほどのシェアを持つオープンソースソフトウェアが初歩的かつ致命的なバグを残しているとは思えず、とりあえず手動アップグレードを試したところ正常に動作したため、バグ報告はしなかったという状況だったのではないでしょうか。

    このような問題を避けるためには、オープンソースソフトウェアも製品と同様に、既存機能の機能テストも開発者が行うか、もしくはテストのための明確なガイドラインと情報共有の仕組みを構築した上で、それをユーザーに委ねる必要があります。それを行っているオープンソースソフトウェアもありますが、ほとんどのものでは行われていません。

    また、企業で導入する場合には、もう一つ大きな問題があります。上記のように、オープンソースソフトウェアは、テストが十分に行われていないことも多く、製品とは違い動作の保証もありません。

    オープンソースソフトウェアを導入して、正常に動作せずに残念でしたと諦められる程度の案件であれば構いませんが、そうでない場合は、シェアの高いものであったとしても自社での動作テストは欠かせません。動作テストを行うということは当然コストがかかるわけで、そのコストは競合製品の価格を上回ることも少なくありません。

    また、バージョンアップにより仕様が変更され、独自に追加した機能が動作しなくなるケースもあります。この場合、バージョンアップをしなければいいのですが、同時にセキュリティ修正が行われている場合はそうも言えず、追加した機能の再開発が必要となります。これも思わぬコスト増に繋がります。

    オープンソースソフトウェアの導入は、安易に決定できるものではありません。メリットとデメリットをよく精査した上で導入する必要があるのです。