2018-08-03

税理士はfreeeにPOLAの夢を見る？

POLAと聞いて何を思い浮かべるでしょう？
普通の人は化粧品メーカー以外思う浮かばないと思いますが

POLA(Principle of least astonishment)＝「最小驚きの原則」

と言うPOLAがエンジニア界隈には存在します。

POLA

Webサイトのデザイン、ソフトウェアのインタフェース、プログラミング言語のAPIなどに関して、

「ユーザが予想した通りの使い方を提供すべき」
「ユーザの学習曲線を最小化にすべき」

という考え方で、例えば、

Webサイトの場合、サイトのヘッダーにあるロゴマークをクリックするとトップページに移動する
Windowsのアプリケーションなら、「Ctl + S」で保存、「Ctl + Z」で戻る
プログラミング言語ならParseInto(string, radix)の基数radixはデフォルトで10進数

などです。

逆にPLOAに反するアンチパターンとしては

Webサイトでブラウザの戻るボタンで戻れない
Macのアプリケーションで、「Ctl + e」を押したら、行の末尾に移動せずに命令が実行されていしまう(pgAdmin3)
第一引数を勝手に解釈して基数を決めるjavascriptのparseInto

　 console.log(parseInt('020')); // 16 (えぇ汗)

Rubyで真の値が0 (個人的見解！)

などがあります。

クラウド会計ソフトfreee

さて、freeeというクラウド会計ソフトがあります（私も最近利用しています）。
www.freee.co.jp
使うとわかりますが

複式簿記の知識がなくても企業の経理業務ができる
プログラマ的な思考で問題の解決方法の最短ステップを経由するインタフェース設計
Webは生き物の如く、常に機能が(いつの間にか)アップデートされていく
SlackやExcelと言った他のソフトとの連携やAPIの公開と言ったオープンな志向

という点が旧来の会計ソフトと比較した特徴かと思います。

私もfreeeを使う以前は複式簿記で会社の帳簿を付けていましたが、初め非常に戸惑いました。
借方/貸方を意識せず取引データが登録できて楽なんですが、逆にそれに慣れている人にとっては非常に違和感を覚えます。

例えば役員報酬の支払いの場合、従来の複式簿記だと (金額は適当です)

借方 / 貸方 (備考)
役員報酬 700,000  / 普通預金　　700,000  (代取8月分) 
　　　　　　　　　 　 法定福利費　200,000   (社会保険料)
　　　　　　　　　　  預り金　　　100,000   (源泉徴収税)

みたいになりますが、freeeだと

f:id:s-koba:20180803092617p:plain

となり、これが従来の借方/貸方脳で記入していた人からすると非常に「驚き」を覚えます。しかし一方、借方/貸方と言った複式簿記の知識がない人にとっては、直感的にわかりやすい方法になります。よくよく考えると支給額から社会保険料や源泉徴収税の預り金が引かれた額が、実際に振り込まれるお金です。

複式簿記が常識で簿記の知識がなければ帳簿の入力ができなかった従来の常識に対し、freeeは会計村の外から、従来の慣習を無視し問題解決への最短経路を選択するというプログラマ的な発想のもと、クラウドの利便性とWebのインタフェースを引っさげ乗り込んできました。

freeeはPOLA？

freeeは

会計の知識がある人にとっては従来の複式簿記の考え方が邪魔をして「驚き」を覚える、非PLOAなソフトウェア
逆に会計の知識がない人にとっては直感的に使える、PLOAなソフトウェア

と言えるでしょう。

複式簿記を考えた人は天才だなと思っていましたが、それをラッピングし、旧来の慣習を捨てて最新のテクノロジーで知識がない人でも使えるようにしたfreeeは凄いと思います。

普段からソフトウェアをデザイン・構築している私とって、freeeは「衝撃」でした。
そういった意味で、ソフトウェアエンジニアにとってはPOMA (Principle of most astonishment)なソフトウェアで、使うたびに「こういうソフトウェアを作るべきだ」と非常に学びを受けています。
このサービスが提供する本来の目的とは異なるところではありますが。

2018-08-01

AI以前にクラウドで仕事がなくなる話

システム開発 AI クラウド中小企業のIT 業務効率

AIに仕事が奪われる論争

オズボーンリストが出た当りから、「AIに人間の仕事が奪われる」と騒がれています。

https://www.mhlw.go.jp/file/05-Shingikai-12602000-Seisakutoukatsukan-Sanjikanshitsu_Roudouseisakutantou/0000186905.pdf

一方で、AIが付加価値の低い作業をやってくれるため、人間がより付加価値の高い仕事に従事することができ、AIと人間の仕事の棲み分けが行われる。と言った意見もあったりします。この辺の本などで語られています。

10年後の仕事図鑑堀江貴文 / 落合陽一

https://amzn.to/2M80QI1

その前にクラウド化で仕事が奪われている

しかし、実際の現場で見た限りではクラウドで人間の仕事が無くなっています。

正確には、「オンプレミスシステムのクラウド移行に伴い業務フローが見直され、従来必要とされていた仕事が不要になっている。」です。

私も仕事でシステム開発を行い納品していますが、その後も機能を追加を行うことが多く、あるクライアントでは３ヶ月に一つペースで新しい機能を追加・リリースしています。

その際に起こることが「この機能が完成すると、この人の仕事が不要になる」現象です。
そして、実際に３ヶ月に一人ずつぐらいのペースでフロアから人がいなくなっていくのを目の当たりにすると、ちょっと怖い感じがします。

ただし不要になる仕事と言っても、

台帳なるものに手書きで記録をして、それをExcelに入力して集計したものを、回覧して上長のハンコをもらう仕事
入金予定リストを作成して実際に銀行から送られてくる入金リストのFAXと突合して消込を行う仕事
タイムカードの集計を社員の勤務形態ごとに異なる出退勤時間から残業時間を計算し、紙で出された休暇申請などと合わせて給与計算

などなので、仕事を奪ったか？と問われると微妙なところです。

中小企業のシステムの現状

オンプレミスシステムのクラウド移行は、自社にサーバを置いて運用するリスク、コスト、セキュリティ、またハードウェアの物理的寿命、OSのライフサイクル、システム構成のスケーラビリティなど様々な角度から考えても、メリットは大きいと思います。

ちょうど、オンプレミスのシステムのハードの保守が切れ代替の部品がない（本当か？）、OSのサポートが切れる、などの理由で「新しいオンプレミスのシステムに移行しましょう」と提案されている中小企業が私の知る限りでも結構あります。

タイミング的には、オンプレミスのシステムをクラウドに移行し業務フローを見直す良い機会なのですが、悲しいことに、大手ベンダーは大企業から対応していきます。そして、中小企業は中々相手にしてもらえず、悲しいかな新しいオンプレミスに移行するパターンもあったりします。往々にして、その際には既存の仕様の踏襲がファーストプライオリティになり、業務フローの改善までは至らない事が多いのが現状です。

今はモラトリアム期間

とは言いつつ流石に、もう一サイクル回ればオンプレミスのシステムもゼロにはならないでしょうが、ここ数年でクラウドの業務システムが充実してきて、指数関数的に減少していくでしょう。

そうなった際には、AWS、Azure、GCPというクラウドコンピューティングサービスのインフラをバックに持つでしょうからAIも何かしらの形で入ってくると考えられます。

そういった意味でここ3・4年ぐらいは、

経営者目線では、如何に業務を効率化するか
社員目線では、如何に付加価値の高い人間にしかできない仕事ができるか

を考えるモラトリアム期間だと思う次第です。

実際には経営者も社員も、もっと速いスピードでドラスティックに進むのが理想ですし、そうあるべきですが私が肌感覚で感じている現状のお話でした。

と言う訳で、AIやIoT人材も去ることながら、インフラではなく、実際の企業の業務にクラウドシステムを導入できる人材が取り敢えず現状は必要なのではないかと思います。

2018-08-01

夏頃に死んでほしい

マーケティング SEO 社会調査趣味推論ゲーム

Google Trendsで過去一年間の「死んでほしい」と「死なないでほしい」の検索ボリュームを比較してみた。

f:id:s-koba:20180801090859p:plain

下記の推論を行ってみる(絶対数ではなく相対数の比較による)。

「誰かに死んでほしい」と思っている人が多い。
「誰かに死んでほしい」に関連するコンテンツが多い。
「誰かに死んでほしい」と思う人は、検索エンジンで「死んでほしい」と検索する傾向が高い。
「誰かに死なないでほしい」と思っている人が少ない。
「誰かに死なないでほしい」に関連するコンテンツが少ない。
「誰かに死なないでほしい」と思う人は、検索エンジンで「死んでほしくない」と検索が低い。

ちなみに地域別で見てみる。東京以外の夜間人口が多い都市といったところだろうか。

f:id:s-koba:20180801091042p:plain

Hash引数の是非考察

プログラミング

フロントエンド周りのプログラムを書いていると、コンストラクタやイニシャライズメソッドの引数がHashやJSON形式オブジェクト一本勝負パターンをよく目にする。

$("#dialog-start").dialog({
    title: '条件を設定・選択してください',
    height: 670,
    width: 900,
    resizable: false,
    modal: true,
    draggable: false,
    close: function () {
	document.location.href = 'series.php';
    }
});

前々から、この方法に関する是非が気になっていたのだけれど、調べてみるとどうもこの件に関するアンチパターン、ベストプラクティス、デザインパターンのようなものが見当たらない。
個人の見解は出てくるけど。と言うわけで自分なりに考察してみた。
ruby - Passing hashes instead of method parameters - Stack Overflow

Hash引数のメリット

(1) 引数の数、組み合わせが多い場合

幾つもメソッドを定義しなくて良い
呼び出す際に引数の順番を気にしなくて良い

例えば、C#のSystem.IO.StreamReaderはコンストラクタが11個あったりする。
StreamReader クラス (System.IO)

(2) オプションが多い場合

省略する引数へのデフォルト値の指定が不要

(3) 可読性

関数・メソッドの定義を見なくても、値が何を意味するのかが明確
省略する引数へのデフォルト値の指定が不要

(4) 変更に強い

引数を増やす必要があった場合でも、呼び出し側に影響がない

(5) コーディング量の削減

引数用のクラスの定義、それにまつわるExceptionクラスの定義などを行わなくて良い
(※) 行わなくて良いことの是非は別として

Hash引数のデメリット

(1) 引数の型だけが異なる場合の対応

オーバーロードのほうが綺麗にに定義ができる

(2) オーバーライドの目的が不明確

オーバーライドが一つになるので、どの引数のパターンに対するオーバーライドなのかが定義かわからない

(3) インタフェースに使うとインタフェースの意味がなくなる

そのまま

(4) メソッド呼び出し時の型チェックに引っかからない

そのまま

(5) その他

テストフレームワークとの親和性も気になる所

弱い結論

弱い動的型付けの言語において、利益を享受できる気がする
でも、Railsでも多用されているから、強い動的型付けの言語もかも
ガチガチのOOPには不向き
- オーバーロードと対極の思想
- インタフェースには向かない

というわけで、自分としては普段メリットだけに目が行ってついつい多用してしまう、Hash引数に付いて考察してみました。
個人的にはJavaでプログラムを書く際のオーバーロードによる幾つものメソッド定義が余り好きではなかったので、Hash引数好きです。