Smart Hacks

カテゴリー: ビジネス

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

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

    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ほどのシェアを持つオープンソースソフトウェアが初歩的かつ致命的なバグを残しているとは思えず、とりあえず手動アップグレードを試したところ正常に動作したため、バグ報告はしなかったという状況だったのではないでしょうか。

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

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

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

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

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