試験代は結構高くて16,500円（税込）もするので、個人で自腹で受けている人は少ないかも知れません。 ただ私は受けて良かったなと思っています。 私はAWSのlishtsailを内部使用のためのシステムの為にもう4年くらいはを使っています。でも実際に使うその部分だけしか触っていなかったので、全体像は良く分かっていませんでした。オンプレミスの時から使い慣れているからという理由から、WebサーバーもWindowsサーバーだけを使っていて、データベースもWebサーバーに直接インストールしていました。ファイルの保存場所もこのWebサーバーに直接保存していました。 今回試験を受けるにあたり、教科書を買って勉強しました。こう言う資格試験の勉強の良い所は幅広く知識が身に着く所と、専門の人から見ればまだまだ浅いのでしょうが、世の中の標準的な実務を知ることが出来るところです。 例えば、データベースはWebサーバにインストールしてしまうと、手動でバックアップを取る必要があります。データファイル自体はタイマーを使って定期的にとる事も出来るのですが、これを全く別の安全な場所にコピーして保存するのは手動でやっていました。これが結構面倒臭いし、バックアップが常に最新のものにはなりません。また、Webサーバーに何かあると、一台しかないこのデータベースも停まってしまいます（可用性）。 これがAWSのデータベースを使うと、基本的にはマネージド・サービスですのでAWSが別のサーバーを電源が別の場所に立ててくれて、かつ、レプリケーションもとってくれるので、サーバーが止まる心配をする必要もなければ、バックアップを手動で取る必要もなくなります。 自己流と言うのは恐ろしいもので、そもそもデータベースを電源が別の場所に立ててレプリケーションをとると言う概念自体がなかったので、それだけでも試験代の元が取れるくらいに勉強になってしまいました。 また、ECSやFargateの存在を知ったことで、今までハードルが高かったDockerを使ったコンテナ上でWebサーバーを立てて、プログラムを走らせることがそれ程難しくなさそうなことが分かりました。それで実際に試してみたのですが、無事に自作のアプリをコンテナ上で走らせて、公開する事も出来ました。 www.yourtaxsecretary.com コンテナ上でサーバーを立てる過程で、Webサーバーにはデータもファイルも保存しない、いわゆる「ステートを持たない」状態にするのが正しいのだと学びました。確かにコンテナにファイルを保存してしまったら、コンテナを破棄した時にデータも失われてしまいます。それでは、ライブラリを含めたコードを変更した時にコンテナを簡単に破棄・交換する事が出来ず、コンテナを使う意味が無くなってしまいます。 この他、ファイルを保存するs3、AWSが内部で仮想的に作るネットワークのVPC、AWS内で横断的に使えるセキュリティの仕組みのIAMなど、勉強するとその良さが分かってきて、本当によく出来たシステムのインフラだなと思いました。システムの勉強は範囲も広く深くて果てしないです。習得には相当の時間がかかります。しかし、極論を言うとAWSにどのような製品があるかを知りその使い方をマスターすれば、今まで多くの専門家エンジニアの方々が多大な時間を使って学び、その知識を使って構築してきたシステム環境を、完全ではないかも知れませんがある程度再現出来てしまうのだなと感じました。 自分の会社のビジネスに実際にシステムを作る必要がある人にとっては、いい時代が来たものです。こう言う構築が難しいシステムを簡単に使えるようにしてくれてるマネージドサービスを使わない手はありません。 私は次は、サーバーの面倒を全く見なくてもいいサーバーレスの仕組みであるlambdaに挑戦してみようと思っています。
Category: システム開発
最近、「ノーコード/ローコード」と言う言葉をよく聞くので、気になっていました。そうしたら、この前渋谷の文教堂でぶらぶら物色していたところ、Googleが出したノーコードと言う記載を見て、つい買ってしまいました。 ノーコードというのはプログラミングをしなくても、サービスやアプリが作れるサービスのようなのですが、実際のところ、やってみないとわからないので、今、本の半分くらいのところまで触ってみました。 何が出来るか ざっくり言うと、クラウド・ネイティブ時代のMicrosoft Accessのような感じで、簡単なデータベースと、各自がスマホから入力できるアプリ（iPhoneとAndroid用のアプリとウェブ用）が自動でできます。 ToDoや在庫管理、顧客管理のデータベースが簡単に出来そうです。私はTodoのサンプルを作ってみました。本を見ながら、所要時間は大体30分くらいでした。Todoのテーブルをカード式で表示したり、終わっていないToDoクエリを引っ張ってきたり出来ました。複数テーブルからのクエリも使えるみたいですし、マクロやトリガに反応して一定の処理をするオートメーションと言うのも出来るようなので、まさにウェブ＆スマホ版のMS Accessです。 データの保存場所は、Googleスプレッドシートも使えるので、事務所内だけでなく、お客さんと情報を共有するのにも何か使えそうです。 こうなると一人当たりの単価の高いKintone辺りは厳しい競争にさらされることになりそうな気もします。 値段 10名までは基本的にほぼすべての機能が無料のようです。10人以上になると、スターター・コースが一人5ドルからで、認証機能やAIなど進んだ機能を使う場合には一人10ドル、もしくはそれ以上になるようです。私はまだ無料コースでテスト利用中です。 値段表 基本的には業務用で、ゲームなどを作る個人用のアプリには不向きです。 以下は、私がとりあえず作ってみたものです。ちゃんとiPhoneにダウンロードして、Googleスプレッドシートのデータを読んでいます。内容も内容も内容も簡単ですが、作るのも簡単でした！
「バケツ」と言う領収書の整理と保管のサービスを始めようと思いソフトウェアを作る所までは何とかやったのですが、これを世の中にいかに宣伝して売っていこうかという段階にきてはたと止まってしまいました。 この商品はどういう人が使いたいのか？という点がわからなくなってしまったのです。もしくは、誰にどう宣伝していったらいいのかがわからなくなってしまいました。 これがいわゆるPMF(product market fit)という問題なのかも知れません。 ソフトウェアには、領収書をアップしたら自動でGoogleの文字認識AIを利用して領収書の文字を読んでテキストにするという機能を付けました。また領収書の写真と一緒に保存できるようにしました。事前に登録されているキーワードを含んでいる場合には特定の科目を割り振って自動仕訳のようにしました。これは裏でやっていることは大したことはなくて、XX自動車とかタクシーというキーワードが含まれていれば、交通費を割り振るような仕組みです。 領収書はお客さんから封筒で定期的にドバっと送ってもらい、人間が紙に貼ってウェブにアップして、その後、大手の倉庫に保管します。ユーザーは、領収書を自分で整理する手間から解放されて、必要な時には画像でも紙でもいつでも取り出せる仕組みです。 ユーザーは領収書を整理してもらうのがうれしいのか、自動仕訳がうれしいのか、それとも領収書が見える会計ソフトがうれしいのか。機能をむやみに増やしても、無駄なものを作っただけの自己満足になってしまっているかも知れません。ユーザーが欲しているものとピントがずれてしまってるかも知れません。 一度立ち止まって考え方を整理した方がよさそうだと思いました。
C#とSwiftで会計のサービスを作っています。名称はまだ仮ですが、「会計のバケツ」みたいなものを考えてます。コンセプトは領収書も請求書も銀行の通帳も全部スマホから写真で取ってくれたら後はこっちで全部やっておきますよ、みたいな会計システムです。 （製作中の画面） 写真を撮ったら仕訳を切る所まで全部自動でやってくれたらいいとは思うのですが、まだまだ人力です。写真で取ってくれたものを、後ろで人が手で仕訳にする予定です。今は、GoogleのAIなど文字認識のすごいサービスがあるので、テキストを認識させてそれから会計科目や摘要を人力で入力して、そのデータが蓄積したら、それをパターン認識させるようなのはそれほど遠くない将来可能になるかもしれません。 私もそうなのですが、経営を一生懸命やろうと思ったら、売上や粗利、人件費、営業利益などは経営計画とか予算に組み入れる指標にせざるを得ません。なりゆきで結果オーライというのではなく、やはり先にこれくらいは利益が欲しいから売上はこれくらい欲しいみたいなことは考える必要があると思います。それで私は毎月の売上を前年比と一緒に方眼紙のノートに記入して持ち歩いているのですが、経営数値はある程度いつでもどこでも見れるようにしておきたいと思います。 そんな時に、会計事務所にデータを任せっぱなしにしていると見たいと思っているのに、そのタイミングですぐに見れない、みたいな状況になってしまい効率がよくありません。 そんな個人事業主や中小企業に役に立つようなシステムを作りたいと思っています。
音声入力がどれくらい使えるものなのか、ちょっと試してみたかったので、AmazonでEcho Spotという画面付きのスマート・スピーカーを買ってみました。 実際に使ってみても、「Alexa、落語聞かせて」とか、「Alexa、ボサノバかけて」と言うと、ちゃんと理解してくれて、注文した音楽をかけてくれるので、すごいなと思いました。 これを会計事務所で何かに使えないかと思い、ちょっとプログラミングを試してみることにしました。 セットアップはそれなりに複雑なのですが、プログラミンの原理自体は本当に簡単です。 「{salary}の社会保険料を教えて。」と言うような文章を手でうち込めば、後はAmazonのサービスの一つである音声認識プログラムのAlexが、ユーザーからの文章を聞き分けて、この文章に合致する場合には、この質問に紐付けた関数を呼び出してくれるわけです。未来ですよねー。参考までに下記が、その呼び出し文（発話）の登録例です。プログラミングの構造は本当にシンプルですよね。 今は、事務所のスタッフの方の提案により、給与計算の時に使う社会保険料を口頭ですぐに答えてくれるものを作っていますが、もっと色々なものが作れそうですよね。
事務所内の業務用ウェブシステムをアマゾンのクラウド（AWS）に移しました。やって見ると、想定していなかった問題が出たりしましたが、結果としてはおおむね順調に動いているようです。 AWSは月に100ドルかかるので、一年間で13万円くらいはかかる予定です。Linuxだったら月に600円でもそれなりに動くのに、こんだけ高いのはサーバーがWindowsのものだからです。 ただ、既存のシステムがWindownsベースで走っていたので、これを一から書き直す選択肢はなかったのでしょうがないとは、思います。 もう一つ見逃せないのが、C#の生産性の高さです。PythonとDjangoや、（深くはやったことがないけど）RubyとRailsの組み合わせも金額的にはお手軽でいいのですが、C#は静的型付け言語ですので、バグが潜んでしまう可能性がPythonやRubyなんかに比べて低いです。コンパイルする際にかなりの割合で問題点を指摘してくれるので、実際に動かす際にはバグがだいぶ減ってます。 それとデータベースとの連携が、同じMicrosoftのSQL Serverを使ったEntityFrameworkと言うのがとても便利です。DjangoだとデフォルトがSqlite3なのですが、さすがにちょっとあれなので、Postgresqlなんかを使ったりしますが、もともの純正データベースではないので、カスタマイズが必要です。しかし、これに結構時間がかかったり、解決できない問題が出てきたりします（これは私の実力が足りないのもあると思いますが）。そういう調べることに使う時間コストを考えると、EntityFrameworkは最初からSQL Serverと使うことが想定されているので、相性が最高です。効率がとても良い。 C#はWindownsをサーバーにしなくてはいけないので割高ですが、プログラムをPythonなどの静的型付け言語よりよっぽど厳密なオブジェクト指向でかけるので安定性が違います。「コストが高いけど、安定性に優れている」C#はまさに実際の仕事に使うプロ用の言語と言えるのかもしれません。世の中ではJavaやC#などの厳密なオブジェクト指向言語のシェアは減ってるみたいですが、しばらくはC#で色々と開発していこうと思ってます。
最近、事務所内の顧客管理システムで使っているWindowsサーバーのハードディスクが少なくなってきたので、サーバーの買い替えを考えていました。DELLで見積もりを取ったところ、最低限度の仕様でもサーバーOS込みで約30万円。一方で、Amazon Web Servicesの値段を調べたところ、Lightsailと言う軽めのプランを使うと、結構値段が安いことがわかりました。 値段はRAMとハードディスクの大きさによるのですが、512MGで10ドル、1Gで17ドル、2Gで30ドル、4Gで55ドルでした。このプランにはMicrosoftの最新のDBであるSQL Server 2016 Expressバージョンが付いてきます。 まずは、OSとDBの有無を選びます。 次に、メモリーとハードディスクのサイズによって料金が異なるので、どれか選びます。 さすがにメモリーが512Mだと使い物にならないと思うのですが、2Gくらいなら何とかなるかもと思いつつ、余裕をもってさらに上の4Gのプランを選びました。 このプランだと月に55ドルなので円換算して月に約6000円、年間で72000円、3年間で21万円です。これならハードウェアを使うより安いです。 AWSのWindowsサーバのリモート操作は、ブラウザ経由で普通にデスクトップのように使えるので便利です。
Djangoがいつのまにか1.x系から2.0にバージョンアップしてました。新しい相続税の計算サイトをDjangoで作ろうと思ってチュートリアルを見て、コードをその通りに打ってもエラーが出ます。なんでかなと良く周りを見たら、なんとそんなことになってました。 しかも良く読むと1.x系からの移行は、一手間かかりそうで自動ではないようです。今後新しく作るサイトは2.x系が良いに決まっているのですが、これまでのものを2.x系に移行するのは手間も大変そうなので勇気がいります。どうしたものか思案中です。 コード自体はPython3で作っていたのでDjangoは1.x系でも2.x系でも動きます。なのでPCを入れ替える必要はないので、そこはせめて良かったと思います。 今まで1.x系をやってたのでまた多少の学習コストはかかりますが、バージョンは新しい方が良いに決まっているので、頑張って新しい方のバージョンでやってみようと思いました。 そういえばPycharmも2017.2 から2017.3に変わっていました。2017.2と2017.3は2017年2月のバージョンと2017年3月のバージョンなのかと思っていたらそうでもなくて、随分と機能がアップしているようです。Djangoの2.0にも対応していると書いてあるので、早速バージョンアップしようかな。 最近（やっと！）わかってきたのですが、システム開発で一番難しいのは、作ることではなくて、何を作るかです。プログラミングが好きなのでコーディング自体とそれに伴う調べ物は苦にならないのですが、作ったものが誰にも使われないものになってしまうと、それまでに投下した膨大な時間を考えると悲しくなってしまいます。最近作ったWEBサービスでレシートを写真でとるとそれを私たちの方で（人間が）仕訳に変換すると言うサービスがあります。確かにレシートを写真でとると仕訳にしてくれるサービスは便利ではあると思うのですが、そう言うサービスを求めるのはどちらかと言うと個人事業者です。会社でも数人規模になってくると、事務の人がいてまとめてくれたりするのでそこに不便を感じることはあまりないかもしれません。つまりサービスがあまり必要とされていないところに時間をかけてWEBサービスを作ってしまったのです。 私たちの仕事は主にどの商品やサービスが儲かっているか、どこに不効率があるかなどがわかるようにするための会計情報を提供することです。少なくとも今のお客様はそう言うものを求めているところが多いです。 そう考えると今回作ったサービスはちょっとピントがずれてました。こうなってしまった以上、ターゲットとするお客様の層を変えるか広げるか、もしくは今のメインのお客様が必要としそうなものをよくよく考えて開発するかしかなさそうです。一回開発を始めてしまうととりあえずは完成するところまで頑張ってしまうので、時間を大量に使ってしまいます。 サービスを作りまくるのも腕を上げるためにはいいとも思うのですが、やっぱり貴重な時間を大量に無駄にする前に、このコンセプトで良いのか良く考えてから作るのが大事なように思いました。例えば紙に書いて一旦客観的に見てみるとか、傷が深くなる前に、始める前の一工夫が大事だなと思いました。
システム開発をやっていると楽しくて時間なんてあっという間に経ってしまうのですが、やりすぎには注意です。 プログラミングは、何かが出来ていく過程が面白くて、作ったものが実際にちゃんと動くと得も言われぬ全能感に包まれます。しかし、気を付けないと普通に200時間、300時間使ってしまいます。この時間が本当にもったいない。 世の中で必要と思ったものを作っているのならいいのですが、下手をすると凝ったエクセル作るのと同じで、自己満足以外の何物でもなくなります。 今、事務所内での請求書発行にかかわる業務は、2人で1－2日かかっています。先日これを聞いてびっくりして、なんとかしなくては、これはシステムで効率化しようと早速この業務をシステム化しようとプログラミングをはじめました。段々できてくると気づくのですが、手間だけがかかって業務が余計めんどくさくなるようなシステムを作りそうになっていることに気が付きます。 あぶない。あぶない。はてさてどこで道を間違えたのか。 まずいけないのは、まずシステムありきの考え方。必要無いのに無理やりシステムを作ってしまいがちです。先の例でいえば、エクセルで十分に間に合っているのにシステムが「作りたい」からシステムを作り始めると、ろくな結果になりません。 逆に世の中にあってある程度普及しているシステムは、その業務に関してニーズがあることになります。人が使っていてそれなりに売れているという事は、そのシステムにお金を払ってでも導入したメリットがあるという事です。 請求書の発行と会計データへの連動は、弥生販売というソフトでも、その他にも色々なソフトで実装されています。つまり実需があるのです。 と言う事は、やるべきことは、次の3つのうちの１つ。 1) 市販のシステムを使う。 2) 担当者の業務を良く聴いて使いやすいシステムにする。 3) 何もしない。 どれも魅力的な選択肢です。このうちでどれを選択するかの考え方ですが、 まずは、現状のエクセルからシステムに替えることによって、どれくらいメリットがあるか（時間がうくか）と考える。 → メリットがなければそのままでいい。 市販のシステムで置き換えることが出来ないか、市販のシステムを使う場合コストはいくらか。→ 高くなければ買った方が（時間的にも）絶対安い。 自社の業務に合わせてシステムを作る必要があって、どうしても市販のシステムでも間に合わない場合には、自社で作るがそれは最終手段とする。 というような考え方でしょうか。 私もシステム開発には人生で数千時間をかけてきたので、何か働ける時間をすごく無駄にしたように感じる時もあります。この時間を他の事に使えばもっともっといろいろな事が出来たように思ってしまうこともあります。が、あまり深く考えず良い事もあると思って前向きに行きましょう。
定番的な業務の場合 世の中で必要なことは人によってもそれほど大きく変わらないので、やっぱり既存のものを使うのが基本でしょう。例えばよくある必要な機能といえば、 顧客管理（SalesForce Zoho） 会計（弥生会計、freee、Quickbook）、 在庫管理 請求書の発行と売掛金管理 出退勤の管理と給与計算 タスク管理 などがあります。 この辺は定番業務なので、ソフトウェアを売ることが目的なのではない限りわざわざ自社でソフトを作る必要は無いでしょう。世の中には素晴らしいものが沢山ありそうです。ただ、ソフトウェアも人が作るものなのでどれも自分が100%満足することはありません。弥生会計はデスクトップのソフトなのでクラウドではまだまだ出遅れています。私の仕事が会計事務所なのでちょっと知っているだけですが、売掛金と在庫管理のソフトでは弥生販売と言うのが世の中で結構使われていますが、機能が少ない事や操作の仕方にわかりにくかったりなど不満に思う事が多々あります。 ソフトウェアの開発が出来る人なら一念発起してこれらのソフトを超えることはないにしても、これらのソフトが実現できていない不便な事を補うソフトを作ることは出来ると思います。ただ、基本は出来るだけ自分で作らず世の中にあるものを使うのが良いと思います。表計算やメールのソフトを自分で作る意味はほとんど無いと思います。 自社の業務そのものである場合 ネットのオークションであったり、人材マッチングの仕事であったりなど、自社の業務や強みそのものがそのソフトウェアでやられている場合は、ガンガンと開発を進めていく必要があります。エンジニアを外注でやる場合もありますが、ノウハウの蓄積が必要なので社内でエンジニアを持つ場合がほとんどです。 こういう会社は自社の強みが確立しているので、収益性が高いことが多いです。私のお客様を見てもその業界で一定の地位を確立してしまっていることが多いです。その業界で知らない人があまりいないくらいになっていることも多いです。忙しいけど儲からない、いわゆる「貧乏暇なし」という状況からは完全に脱け出ています。 中小会計事務所の場合 ちょっとシチュエーションがニッチすぎますが、どの中小企業もその会社独特のプロセスややり方があると思います。私の事務所でもそうです。 お客様からいただいた郵便物の日付と内容の記録（写真付き）、課税売上高と税務署に対する届出書の管理、過去の重要な打合せの記録や留意点のメモ、見積もりなどを自社システムを作って、一つのシステムで一括管理して居ます。そのお客様の情報をまとめて見れるのでとても便利です。 社内ネットワークならPCのブラウザーからでも見れるので、お客様と電話で話ながらでも必要なすぐに情報が出せるので便利です。 システムの内容は一般的でもありますが、会計事務所独自の部分もあり、市販ですべてのニーズを満たすものは売っていなさそうです。こう言うシステムは自社で作った方が良いのでしょうか、それともエクセルやEvernoteなどの既存のシステムを工夫して使って自社開発は避けるべきなのでしょうか。 確かに時間もコストもかかります。ジュニアなエンジニアでも一人を社内で雇用すると500万はかかります。エンジニアの技術が上がっていけば給料も上げて行かなければいけません。システム開発だけでなく、他にも社内のIT周りの仕事をしてもらえるとしても、この固定費は中小企業にはべらぼうです。業務の改善で年間に500万円分以上の効率化やメリットを出すのは相当に大変ですから、ある程度、社内で規模の利益が採れない場合はやるべきでないのでしょう。 このような状況でやるべきことは、きっと、社長がITツールを個人的にも勉強して、出来るだけ既存のものを使いこなすようにすることでしょう。 それでも、システム開発は一度開発したら、（メンテやアップデートが少しは必要ですが）後は勝手に動いてくれます。システムは長い時間ではメリットが少しずつ積み重なっていくものなので、人と違う事をしたいのなら、自社の成長とともにシステムも成長させていくのもありだとは思います。 それより今はVBAやマクロ、PythonやC#など結構簡単に動かせる言語も多いです。ちょっとずつ手作りして細かい事務作業や定番業務を自動化して効率化していくのはあり（というか必要？）だと思います。 一応の結論 一応の結論ではありますが、こたえは一択で、大概の場合、ソフトは既に世の中にあるのでそれを使うのが良いのでしょう。 自社で開発すると、プログラマーも必要だしインフラ周りの人も必要です。ただ、私がプログラミングが好きだという事もあるのでひいき目に見ているのかもしれません。出来るだけシステム開発を自社でやりたいと思っていますが、やらないで本業に注力するのが賢明な選択と言うことになりそうです。