Orcinusを開発した理由

  Orcinus     営業活動  

おごちゃん

弊社の今注力している商品はOrcinusです。

Orcinusについては今までしばしば書いていますし、商品サイトもありますので、「どんなものか」は書いていますが、「なぜか」という部分について書いてなかったので、あらためて書きたいと思います。

背景

もちろん結果的には「ここにビジネスがある」と思ったからですが、元々はこのような「商品」を作るつもりはありませんでした。

弊社の会計システムHieronymusは便利に使えていましたし、これ自体はオープンソースで公開していて、とりあえず開発者としての責任は果しているので満足していました。 本業のビジネスには直接関係のない、それでいて有用なソフトウェアを開発したらオープンソースライセンスで公開するのは、「開発者としての責任」だと思っているので、そういった意味では十分です。

弊社の本業はもうちょっとハードウェア寄りの「Jar-Garden」とか「目玉親父」であって、純粋なソフトウェア開発とはちょっと違う方向を目指しています。 なぜそうかについてはまた改めて書こうと思いますが、簡単に言えば「商売にしにくい」というのが一番の理由です。 まぁそれは本稿とはあまり関係のない話なので割愛します。

きっかけ

前弊社を畳み現弊社を設立したあたりで、Hieronymusについて複数の問い合わせが来ました。 いずれも「あれ(Hieronymus)はどうするのですか?」というのが趣旨です。

その中に「開業パッケージ」という話がありました。 つまり、「箱(サーバ)」にHieronymusを入れて、「これがあれば開業後のバックオフィスは安心」という感じの「箱」を作りたいという話です。

「バックオフィスの箱」という発想

実はこれは私も思い当たるところがあります。

前弊社を登記した後、最初に考え込んでしまったのが、

  • 会計
  • 請求
  • 給与

です。 要するにバックオフィスシステムですね。

このうち、給与については平時の給与計算についてはそれ用のExcelを知人にもらいました。 特に難しいものではなくて、基本給があって手当を足して基礎控除の類を引いて… というものです。 とは言え、当時はそのようなことがまるでわかってなかったので、こういった簡単なExcelシートでも重宝したものです。 そもそも私一人ですから、あまり面倒な要求もなくて「計算できれば満足」でした。 その年の年末調整は自分でやったと思います(頑張れば素人でもできます)。

請求は開業当初は太い客(日本医師会殿です)があって毎月ありました。 最初は近所の文房具屋でコクヨの請求書を買って来て、それで書こうと思っていたのですが、私は字が下手なので手書きの請求書を使うことには強い抵抗がありました。 そこで、Access DE 請求書 EXというのを見つけて来て、これを使うことにしました。 これに窓開き封筒を用意して送れるように、ちょっとカスタマイズしてあります。 そのためにソース開示のお金を払ったことを覚えています。

これは見積書の作成もAccess DE 見積書 EXというのがあって重宝しました。

ただ、どうしようもないのが会計です。 これは待ったなしですぐやらないと面倒だということはわかっていますが、何しろ私は簿記の類を学んだことがありません。 ですから、「とりあえず手作業」ということは不可能になります。 そこで、その当時オープンソースで公開された「助太刀会計」というものを入れました。

約200社が導入したWeb会計システムをオープンソース化,開発協力者を募集

PHPで書かれていて私にはさっぱり読めません(ということになっています)し、PHPは当時としても既に古いVer 4だったりとか、元々がApacheの環境を前提としていて環境的に重いとか、そもそもドキュメントが全くないとか色々ありましたが、とりあえずLighttpdで動くようにして便利に使っていました。 PHPについては「環境ごとVM化する」「必要な時だけVMを起動する」ということで逃げることにして、クラッシュで全損するまで使っていました。

会計システム Hieronymus(1)

まぁそんなわけで、会社をやるのに最低限必要なバックオフィス業務である、「会計」「請求」「給与」は適当にその辺に落ちているものを寄せ集めてやっていました。

寄せ集めの問題点

「事務員」は私がやっているので、これらを寄せ集めていても、そんなに困ったことはありません。 操作感が違うのは慣れればいいだけですし、データがまとまってないとは言えそこまで事務量が多いわけでもありませんから、手作業でどうにかなります。 ですから、「使える」という意味では十分満足でした。

とは言え、結局は寄せ集めですから、色々困ることが発生します。

  • メンテ対象が多い
  • データの転記が面倒臭い
  • そもそも転記自体を忘れる

という、「最初からわかっていたこと」が結局問題となります。

メンテ対象というのは、3種の別々のアプリをメンテするということです。 3つ集めたのですから当たり前のことなのですが、バックオフィスシステムと言う本業から見たらどうでもいいことにそういったエネルギーを割くこと自体が厄介です。 そんなに高頻度に何かが起きるわけではありませんが、逆にそれであるが故に面倒臭いことです。

データの転記についても、絶対量としてはそんなにあるわけではありませんし、助太刀は「伝票テンプレート」が充実しているので、それを活用すれば随分楽ができました。 とは言え、微妙な違い、たとえば年末調整の扱いや住民税の扱いとか、結構ミスしたものです。 そして、当然ながら「元データ」の方は正しいのです。

転記を忘れるというのは私のボケのせいですが、たとえば給与を出したのを忘れてしまい、残高が合わないということがしばしばありました。 もちろん給与は計算して支給はしてるのですが、会計システムに反映させることを忘れてるのですね。 たまにしかやらないのでしょうがないですねw

まぁそんなわけで、システムに一体感がまるでないので処理がバラバラになってしまうとゆー、ごく当たり前のことが起きていました。

ぱっと見はそれぞれいい感じのフリーソフトやオープンソースがあるので、これらを集めて来ればいい感じにバックオフィスができる。 確かにできるんです。 探せばいいものが無料かそれに近い費用で手に入ります。 それで運用することは不可能ではありません。 十分いい感じに運用できます(した)。

とは言え、

  • そもそもいい感じのソフトを見つけるのが大変
  • 寄せ集めて来るとシステム運用やメンテナンスがバラバラ
  • データ連携? 何それ美味しいの?

というようなことが起きてしまいます。 そして、なまじちゃんと運用できているから、優先順位は落ちます(した)。

API連携という幻想

基幹システムとして使っていた助太刀は、サーバのクラッシュにより消えました。 そこで一週間ほど集中してHieronymusを作った… という話は

会計システム Hieronymus(1)

に書いています。

その時に「これで会計APIができたから全てのシステムを一体化することが可能になる」と思ったものです。 もうちょっと正確に言えば、助太刀が元気だった頃から「会計システムくらい自分で作ったらどうだ」「そうすればAPI連携も可能になるぞ」と思っていて、それが現実のものになったわけです。

さて、ではHieronymusが実用になった時にそれをやったかと言えば、

そんなことはありません

でした。

請求書発行システムは十分便利でした。 また、その当時から旧弊社は売上が下がっているため、請求書を書くこと自体があまりありませんでした。 そうなると、「請求書発行システム」を作るモチベーションは上がりません。 これは「精神的モチベーション」もさることながら「コストバランス」的な意味で上がらないのです。 早い話が「そんな暇があったら仕事しろ」です。

自分で作らなくても適当なものを持って来てAPIを叩くようにすれば良いではないか? という話もありますが、これも現実的ではありません。 そもそも、「日本のオープンソース界」には、そのような「請求書発行システム」は存在しません。 「日本」という枠を外せばあるいはあるかも知れませんが、海外の「請求書」はレイアウト的に日本では通用しません。 海外製のCRMにあるinvoiceは慣習や制度が異なるため使えません。

同じことは給与計算にも言えます。 「日本のオープンソース界」には「給与システム」は存在しませんし、「日本」という枠を外せばあるいはあるかも知れませんが、海外の「給与計算」は日本とは様々な点が異なります。

そんなわけで、Hieronymusという「会計APIを持つ会計システム」ができたところで、「寄せ集め」の状況は改善されませんでした。

オールインワン

そういった状況があった先に、前弊社の破産や現弊社の創業があって、「問い合わせ」もありました。

そこで色々リセットして、あらためて色々考える機会が与えられました。

その「問い合わせ」の中であったこと、また前システムでの反省点から、現Hieronymusが「請求書発行シㇲテム」やCRMを包含するようになりました。

現在のHieronymusでは、送付用の請求書を発行するだけではなくて、電子化証憑としての請求書も生成されます。 後はこれを元に伝票を作成すれば「忘れる」「間違う」ということはありません。 また、元々Hieronymusは対応する伝票のない証憑があるとアラート状態になるので、証憑だけ存在しているというのは一時的にしか許されません。

給与についてはまだ弊社は給与を出していない(役員しかいないし)ので未実装ですが、給与が出せるようになったらすぐに実装するでしょう。 前弊社で一番面倒臭かったのが給与関係(支給だけじゃないです)の伝票の転記だったので、ここはぬかりなくやるはずです。

そんなわけで、Orcinusでは会社をやるのに最低限必要なバックオフィス業務である、「会計」「請求」「給与」は一体化されたシステムとして作られています。

その他のアプリケーション

会社で必要なシステムはいわゆるバックオフィスだけではありません。

弊社のような零細企業であっても、

  • 非同期コミュニケーション
  • 予定表やTODO
  • 文書やファイルの共有
  • ホームページ

というようなものは日常的に必要です。 これは程度の違いはあっても、どこの組織でも必要だろうと思います。

幸いなことに、いずれもクラウドサービスが存在します。 バックオフィスシステム(会計とか)も実はクラウドサービスがありますね。

個々のクラウドサービスは良いものですが、

  • 寄せ集める必要がある
  • 寄せ集めると一体感がない
  • ちゃんと使うと結構費用がかかる

ということで、見える景色はいくらか違うとは言え、私が前弊社を始めた時のバックオフィスと同じような問題が発生します。

このようなものはどこまで行っても「寄せ集め」であることは仕方無いと思いますし、バックオフィスシステムほどの一体感は必要とされないので、そこは諦めてしまっても問題は少ないだろうとも思います。 ただ、そういったものを「寄せ集める」ことそれ自体は結構面倒なものです。

私がHieronymusを作る前、「もうオンプレの時代は終わってクラウドの時代が来るのだ」と思い、クラウド会計システムを評価しました。 自前でやらずに済めばそれが一番ですし、何よりも時間がありません。 多少費用がかかっても、悩み少なく使えることができるのであれば、文句はありません。

結果的に私がしっくり来ると感じるものがなかったので、どのサービスも選択はしませんでした。 その結論自体は私の結論だということで置いておくにしても、そこに至るまでにいくつかある「クラウド会計システム」を、評価できるレベルまで使ってみるというのは、タイミングのことも含めて結構ストレスでした。 いくら「試用はタダ」と言われても、こちらのコストも馬鹿になりません。

これは「会計システム」のようにゴールのはっきりしたシステムでの話ですが、たとえば「非同期コミュニケーション」となると、ゴール自体が明確にできません。 「対話」が中心になるのか「グループチャット」が中心になるのか、リアルタイム性はどの程度必要か… それぞれの違いによって「ベスト」が異なります。

つまり「寄せ集め」であること自体を諦めるにしても、寄せ集めること自体が結構大変だということです。

そして、こういったもののコストを案外忘れがちです。

多くのクラウドサービスで「個人は上位オプションから課金だけど、法人は最初から課金」というタリフのものが少なくありません。 そしてうまい具合に個人の延長で法人で使うと色々な不便があったりして、結局法人は法人で契約しなきゃダメということがあったりします。 そして、法人の課金は案外安くないし、人数分必要だったりする。

そんなわけで、「ありがちなアプリケーション」は「セット」になっていた方が嬉しいなと思っています。

Orcinusはどうしたか

Orcinusの最初の動機は「問い合わせ」からですが、設計についてはそういった個人的な必要性からのものとなっています。 つまり、

自分が本当に必要だったもの

を揃えましたし、その方向で充実させて行こうと考えています。

これは別の方向から見れば、「本来の業務に集中して欲しい」という願いでもあります。

いやー、正直こういった「本業と直接関係ないのに必要なシステム」について考えるのって、面倒臭いものです。 必要だから用意しなきゃいけない、でも本業に集中したいからあまりこれらについて考えたくない。 特に開業したばかりの人にとっては、当然の思いでしょう。 特にこだわりなんてないし、そもそもそんなに興味があるわけじゃないから解像度も低いし良くわからない。 いい感じのものであれば、適当に何でもいい… それがバックオフィスに求めるものじゃないでしょうか?

そういった半ば思考停止して「これだけあれば必要十分」というものを揃えるということを目指したものがOrcinusと言えます。 購入者には本業に集中して欲しい。 それを実現したものとも言えます。

技術的な諸々について

Orcinusという「箱」の選択にしても、CassetteOSというOSにしても、中心となるHieronymusという会計システムにしても、弊社の技術を注力したものです。 それぞれをドヤることも悪くないかなという気はします。 必要があればそれぞれのエントリを見れば、それなりに「力」の入っている部分が見えると思います。

とは言え、弊社は「Orcinusというユーティリティ」を提供することが目的であって、「Orcinusという技術」を提供することは目的としていません。

個々の技術は商品ですが、「Orcinus」という形となったものは、個々の技術よりも「ユーティリティ」に価値があると思っています。 ですから「箱」のスペックについては「必要にして十分 + 将来へも対応可能」というものを用意していますよという程度です。 万一Orcinusとして気に入らなくても、返送して戴ければWindowsに入れ直してお返ししますし、それで使っても不満がない価格相応程度のスペックにはなっています(廉価NASでは無理です)。

ただ、プロダクトとしては「Orcinusというユーティリティ」と考えています。 そのココロについては前節に書いてあるような思いからです。

おわりに

今回はあまり今まで書かなかった「Orcinusの動機」について書いてみました。 直接の商品説明を敢えて避けて書きましたが、逆にどんな商品であるか見えにくかった部分が見えるようになったんじゃないかなということを期待しています。

Orcinusの導入についてはお気軽にお問い合わせください。 お返事以外の連絡(「営業」とか)は一切しません… と言うか、DM営業をやるパワーは弊社にないのです。

最近のエントリー

Orcinusを開発した理由

12月スタート!事務所をクリスマス仕様にしました

金曜ごはん #12 「リピートハンバーグ」

第17回 業務システムをオープンソースで作ること

金曜ごはん #11「タルタルチキン南蛮と、アボカドシュリンプの彩り晩餐」

金曜ごはん #10 「鶏肉祭り」

Hieronymus Ver 2.0.6 release

HieronymusとOJT後のgemini-cli

金曜ごはん #9 「お肉たっぷり700g!"欲張りハンバーグ"ディナー」

金曜ごはん #8 「ジェネリック山ちゃん再び」

金曜ごはん #7「冬の到来。カニとお鍋」

金曜ごはん #6 「最近忘れがちになっている金曜ごはん」

gemini-cliへの新人教育

手軽に台帳の作れるノーコードシステム「NocoBase」

金曜ごはん #5「ジェネリック山ちゃん」

決算が終わりました

金曜ごはん #4 「ご褒美ステーキ」

リゾート暮らし

金曜ごはん #3「冷蔵庫の材料で作るごちそう」

Orcinus のサイトオープンのお知らせ