原幹公認会計士事務所

内容に関係なくねこ画像が入るのは仕様です。

ということでAZXさんから献本いただきました。多謝。

【目次】
第I章 ベンチャー法務戦略
第II章 会社設立時から気をつけるポイント
第III章 起業家が知っておきたい会社法の基本
第IV章 ビジネス上必要な文書の作成
第V章 資金調達,ファイナンスにあたっての注意点
第VI章 M&Aにおける重要事項
第VII章 労務管理の留意点
第VIII章 知的財産権の管理
第IX章 IPOに耐えうるコーポレートガバナンス

Q&A形式で各テーマへのリファレンスを解説する形式ですので、どこからでも読むことができます。個人的には身近な話として

• QII-1「会社設立時の資本政策」
• QV10-14「種類株式のポイント」
• QVI-3「M&Aにおける新株予約権の取扱い」
• QIX-2「ベンチャーのステージに応じた機関設計」

がコンパクトにまとまっていたため、興味深く読ませていただきました。

リアルに困ったときは専門家の助けを借りるとして、広く浅く調べるときのリファレンス本として手元に置いておきたい一冊かと思います。

最近の体験談になりますが、業務で日常的に使っているDropboxのトラブルで、ローカルファイルが勝手に二重にコピーされるという現象が起きてしまい、復旧に少々時間をとられました。(現在は解消済み。原因はDropbox以外のところにありました)

クラウドサービスに普段の生活や仕事でどっぷり依存している分、トラブルに陥ったときに業務に支障が出ないよう、事前に対策を講じておく必要があります。当事務所もいつのまにかさまざまなクラウドサービスをを業務で日常的に使うようになりましたが、さまざまなトラブル経験を経てサービスとの付き合い方を慎重に検討するようになっています。

現在、業務で主に使っているクラウドサービスは以下のとおりです。

• Dropbox(ローカルファイルの同期/クライアントとの一時的なファイル共有)
• Box(クライアントやスタッフとの一時的なファイル共有)
• OneDrive(クライアントとの一時的なファイル共有)
• basecamp(プロジェクト管理/クライアントとのメッセージのバックアップ)
• Makeleaps(請求書作成)
• Chatwork(クライアントとのコミュニケーション)
• Office365(メール/共有フォルダ)
• G-Suite(旧Google Apps。メール/カレンダー/共有フォルダなど)
• クラウド会計ソフト(freee/MFクラウド会計/その他)
• 弥生ドライブ(弥生会計のバックアップファイルの保持)

少々多い気がしますが、こちらの都合で相手に特定のサービスを使うことを強要できないので、なるべく間口を広くしてあらゆるケースに対応できるようにしています。会計事務所業務の場合、クライアントに合わせてあらゆる会計ソフトを使える環境が必要になることが多いのですが、クラウドサービスについても同じようなことが言えそうです。

以前は自前で運用していた作業をクラウドサービスに頼るようになってきていますが、乗り換えるかどうかは以下の単純な式で判断するようにしています(結果として、メールサーバやネームサーバの自前運用はだいぶ昔に取り止めました)。

自前運用するコスト＞クラウドサービスを利用するコスト

また、これらのサービスについて、以下の運用ルールを守るようにしています。

• 特定のサービスに依存しない
  たとえばBoxのようなファイル共有サービスにファイルをアップロードする場合、ローカルファイルに最新のファイルを保持しつつ共有フォルダにアップロードするようにします。特定のサービスに最新ファイルを保持するようにすると、サービスに不具合が出たときに身動きが取れなくなります(今回のDropboxのトラブルがまさにそのようなケース)。仮にそのサービスが突然終了しても困らないようにはしておきたいものです。
• サービスのセキュリティを過信しない
  たとえば、サービスによっては「当サービスで取り扱うデータは暗号化されているので安心です」という触れ込みがされますが、ユーザーには検証する手段がありません。どのように管理・補完されているかわからない以上、たとえば業務上の重要データや機密データを特定のサービスに恒久的に保管するのは基本的に避けたほうがよいでしょう。
• 共有するファイルやフォルダに期限を設ける
  クラウドサービスを使う以上、さまざまなファイルを一時的にクラウドに保管することは避けられないわけですが、そのようなファイルはどうしてもそのまま放置されがちになるので、期限が来たら自動的にアクセス不能にできる手当てが必要です。DropboxやOneDriveはこのような機能を備えています。
• ローカルバックアップの設定を確認する
  不慮の事態に備えて、クラウドサービスに保管されているデータをローカルデータとしてダウンロードできるかどうかの設定を確認します。サービスが突然終了するとしても慌てずにすみます。
• 各サービスのパスワード管理を厳重にする
  「複雑なパスワードを設定する」「特定パスワードを使い回さない」などは基本中の基本ですが、重要なデータを保管するものであればあるほど不正アクセス対策は厳重に行う必要があります。二要素認証は必須でしょう。1passwordなどの利用もいいですね。

これらのうち「特定のサービスに依存しない」という運用ルールは特に重視しています。業務に支障が出ないように、サービスからの独立性とはいわずまでもある程度中立に使い分ける立ち位置が必要に思えます。

今後さらに多くのクラウドサービスが出現してサービス間の連携が図られていくとなると、一ユーザーとしてもそれらのサービスとの距離感をうまく考えておく必要がありそうです。

※お問い合わせはこちらから

https://ssl.form-mailer.jp/fms/e5d2273b248067

やわらかめのエントリです。

今日も順調に業務妨害してくれる我が家のねこですが、ふとこいつを財務諸表で表現するとどうなるのかな、てことで思考実験してみます。「ねこ財務諸表」とでも呼びましょうか。

※画像はイメージです

まず、そもそもねこ財務諸表を作成したととして、誰に対して報告するためのものなのかと考えてしまいますが、不特定多数の投資家ということはなさそうなのでとりあえず「飼い主」としておきましょうか。株主一名。

• ねこ損益計算書の内訳
  • 収益:なし
    • どこかのコンテストで賞でもとらないかぎり、貨幣的にはありません。まあ精神的価値があるものとしても貨幣的には表現できないですね。
  • 費用: ごはん、トイレ代、病院代など
    • 安くはないですが、確実に支出が発生します。よって、費用はそのまま「損失」になるのですが、対応する収益が(非貨幣的ではありますが)相殺して余りあるので全く問題ないかと。

• ねこ貸借対照表の内訳
  • 資産： ねこ本体
    • ここで悩むのが、果たして「「有形固定資産、耐用年数10-20年、変動あり」と考えるのか、「生物資産」と考えるのかですが、生物資産の耐用年数表は牛馬といったものばかりで当然のごとく犬や猫はありません。
    • 参考：生物資産の耐用年数
      https://www.nta.go.jp/shiraberu/zeiho-kaishaku/tsutatsu/kihon/hojin/07/07_06_04.htm
  • 負債： なし
    • よほど超高級でないかぎり借金してねこを買うということもないと思うので、ここではないものとします。
  • 純資産: ねこ本体

なんのことはない、B/Sで表現されるのはねこそのものでありました。

なんだかオフバランス項目ばかりになってさっぱりな感じですが、ねこに貨幣的価値を求めてはいけないということなのかもしれません。

※お問い合わせはこちらから

https://ssl.form-mailer.jp/fms/e5d2273b248067

週刊「税務通信」の主要トピックのご紹介です。

電子帳簿保存法Q&A(平成28年9月30日以後の承認申請対応分)に、いわゆるコーポレートカードの利用明細と読み取った画像を関連付けた場合の対応について回答が公表されました。(問67-2)

全体

https://www.nta.go.jp/shiraberu/zeiho-kaishaku/joho-zeikaishaku/dennshichobo/jirei/07_3.htm

問67-2

https://www.nta.go.jp/shiraberu/zeiho-kaishaku/joho-zeikaishaku/dennshichobo/jirei/ans3/03.htm#a67-2

本Q&Aのポイントは以下のとおりです。

• 以下の2条件を満たす場合、規則第3条第5項第4号ロの「定期的な検査」を行う体制が整っているとみなすことができるため、定期検査前でも原紙証憑を廃棄することができる
  1. カード利用明細と領収書を読み取った画像を的確にひも付けること
  2. 経理担当者等において領収書を読み取った画像の内容を確認し、カード利用明細と的確にひも付けられていることを確認・管理すること

上記要件の「ひも付ける」については、

• 「カード番号の一部」（又はカード支払である旨）、「利用日」、「利用金額」、「利用店名」等の情報に基づき、

  • クレジットカード会社から発行されるカード利用明細がデータである場合には、カード利用明細と領収書の画像をシステム上で関連付けること

  • カード利用明細が書面である場合には、例えば、カード利用明細に記載された各支払項目の横に手書きで番号を付すとともに、領収書の画像のファイル名にも同番号を付すこと

という例示が行われています。 なお、カード利用明細は保存しておく必要があります。

また、平成27年9月30日以後の承認申請対応分においても、同様のQ&Aを追加しています。(問58-2)

https://www.nta.go.jp/shiraberu/zeiho-kaishaku/joho-zeikaishaku/dennshichobo/jirei/ans2/03.htm#a58-2

コーポレートカードの明細と領収書画像の関連付けを確実に行っておくことが必須になります。

※お問い合わせはこちらから

https://ssl.form-mailer.jp/fms/e5d2273b248067

※本エントリは特定の製品やサービスにまつわる経験談ではなく、さまざまな事実に基づく私見です。以下「利用者」はユーザー企業や個人、「提供者」は製品やサービスのベンダーをおおまかに指します。

「それは仕様です」

日常的に仕事でソフトウェアやサービスを使っていると必ず巡り合い、そしていらつくフレーズではないでしょうか。仕事に使いたい機能がない/不足している/振る舞いが間違っている利用者が認識し提供者に問い合わせると、提供者から出てくる魔法の言葉です。私も含めて、このフレーズが出てくるとまじめにベンダーにレポートしようとか真摯に話し合おうとかそういった気力が当社比90%減ぐらいになります。いらいら。

なぜこのフレーズは苛立ちを産むのでしょうか？思うに、利用者側から見れば

• なぜこの仕事に使うためのこの機能がないのか/正しく動かないのか
• これだけやってくれれば仕事が楽になるのになぜ実装されないのか
• そもそもそういった機能が必要という認識があるのか、素人じゃあるまいし

という思いを止めることができず、提供者側の

• 当社(私)としては最善を尽くしてよい機能を提供している
• 提供している機能で便利になるし何か問題でもあるのでしょうか
• ソフトウェアも万能ではないのでできないものはできませんよ

という視点が利用者からほの見えるからなのかもと。(あくまで想像ですよ)

提供者側の論理も理解はできるわけです。それまでなかった便利な機能を提供することでユーザーに付加価値を提供し、仕事の利便性を上げることができる。ただしそれを作るのに投じるリソースは限られていて、すべてを実装することはできないのでおのずと優先度をつけざるをえないということです。

一方で利用者側のある意味わがままな視点を斟酌するならば、仕事を楽にしてくれる機能やサービスはいくらでも(コストに見合った形で)利用したいわけで、そこに支障が出てくることは無用のストレスを産む。提供された機能の便利さという付加価値はストレスの前には無力であるということ。利用者は「業務」への期待値があり、提供者は「機能」の付加価値がある。そのギャップのおかげで提供者も利用者もお互いに不幸になっている気がします。

ではどうすればよいのか。

利用者側のサービスへの高すぎる期待値を少し補正して、「これだけ使えれば便利じゃないの」というレベルで満足する割り切りが大事な気がします。

利用者側としては

• 機能やサービスに対する期待値を過剰に持たない
• 機能やサービスの付加価値を正しく評価する(よいところを見る)
• 仕様に対しては早めにあきらめて期待せずに待つ

といった寛大(?)な態度も求められそうです。一方の提供者側としても「それは仕様です」のマジックワードに依存しきるのでなく、自らの提供する価値をしっかりアピールするとともに利用者の視点を理解して機能向上に努める視点は必要になりましょう。業務システムであれば「機能提供」だけが役割ではなく、機能提供を通じた「業務支援」が求められる役割である、という視点を持つことで、より利用者に寄り添うことができると思われます。

「仕様です」にイライラしないためには、提供者側も利用者側も歩み寄りが必要なのかもしれません。

※当事務所へのご相談・お問い合わせはこちらから

https://ssl.form-mailer.jp/fms/e5d2273b248067

開発生産性という文脈で、「技術的負債」というキーワードを時々耳にするようになりました。果たしてこれはどんな考え方なのでしょうか？

「技術的負債」は、Wikipediaによれば次のように定義されています。

https://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E7%9A%84%E8%B2%A0%E5%82%B5

行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。

最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる。

ここでは「組織で共有されない知識」「複雑すぎて変更が難しいコード」などが例示されています。品質の低いコードを使い続けることを「利息の支払」と表現しているのが興味深いですね。ここでは、当初採用した技術やコードが足かせとなって開発生産性に影響を及ぼす事象全般、と仮に定義します。

たとえば商用サービスに利用するアプリ開発の場合、アプリそのものでのユーザー獲得や収益向上を直接的に志向することから、開発段階での最適なアーキテクチャ選定を行い、その後急速に陳腐化しないよう保守性や拡張性に配慮する必要があります。

仮に技術的負債をイメージするならば以下のようになるでしょうか(以下、複式簿記のルールをあえて逸脱して表現します)。

ソフトウェア資産(付加価値を持つ無形の資産)を生成するには「ヒト」の知恵と作業が必須になります。従って、一般的な処理の流れとしては

1. 人件費の計上
2. ソフトウェア（及び技術的負債）の発生
3. 売上の計上
4. ソフトウェアの償却

という順番になりましょう。

このとき「技術的負債」はどこにマッピングされるのでしょうか。現行の会計ルールではそもそもオフバランス項目なので、B/Sには出現しません。結果として、利息の支払い(たとえば低品質コードを使い続けること)による費用が表面化しないことから、P/Lインパクトとして意識されることはないでしょう。しかし一方でボディブローにように経営資源を費消する側面があることは留意する必要があります。

技術的負債を抱えることのデメリットとして容易に想像できるのは、たとえば回収コストが足かせとなってその企業の競争力の阻害要因になることです。たとえば一点突破を目指して新たな市場を創造することを目指すようなベンチャーにとっては、リソースをいかに集中投下するかが重要なので阻害要因は極力排除したいはずです。技術的負債の存在が収益獲得の足を引っ張るのであれば、そのようなリスクは排除しておきたいはず。

ではどうすればよいのでしょうか？一般的には

技術的負債の解消(2)および利息支払い(5)のスピード＜収益獲得のスピード

を維持することで、生産性を下げずにビジネスのスピードを維持することができるかもしれません。よりよいのは技術的負債の解消(または利息の支払)期間中に次のプロダクトへの投資が完了し、リリースと同時に技術的負債を完済していることでしょうか。(完済の意味するところが明確にイメージしにくいところですが)

特定のアーキテクチャを採用する段階で不可避的に技術的負債が発生することから、現行の会計ルールでは見えない(オフバランスなので)技術的負債のP/Lへのインパクトをいかに可視化して改善プロセスに乗せて行くのか(または行くべきなのか)。このあたりに、特にベンチャー企業の成長スピードへのヒントがあるのかもしれません。

※お問い合わせはこちらから

https://ssl.form-mailer.jp/fms/e5d2273b248067

タイトルは大袈裟ですが、内容は覚え書きです。

月末月初恒例の請求書とりまとめ業務を毎月繰り返しつつ、この仕事のやり方がいつ変革を迎えるのかをぼんやり考えながら今回のエントリを書いています。もう月中ですが。

最近読了したクラウドアーキテクチャの解説書です。

Cloud First Architecture 設計ガイド

クラウドファーストとマイクロサービスの関係と歴史がわかりやすくまとめられていて、非エンジニアの私にもわかりやすい良書でした。端的に書くと、システムの安定運用のためにマイクロサービス化が不可避な歴史があり現在の主流になっているという内容です。

経理業務のようにとかく属人的になりがちな業務にこのような発想が適用できないものかぼんやり考えております。手続型で記述され定着している業務をマイクロサービス(的なもの)に落とし込めば冗長化も実現しリソースの代替可能性も確保できていいことづくめのような。人間はいらなくなりますが。

経理業務になぞらえるならば、たとえば請求業務を手続きとして記述すると

1. 請求対象の受注を集計する
2. 請求書を作成する
3. 請求書を確認/承認する
4. 請求書を送付する

となるわけです。手続視点で処理が進むので処理方法が属人化しやすく標準化しにくい。「集計」「作成」といった処理モジュールごとにサービス化が進めば属人化から少しは解放されるのではないかという課題認識があります。

これらのうち2)作成4)送付については近年でサービス化が大きく進展しています。関連するクラウドサービスも数多く出てきました。究極的には1)集計についてもB2Bでの請求トランザクションを相互にやりとりすることになり人間の作業は3)確認/承認のみ(しかも例外的に行う)という姿に帰着するのかもしれません。定期的にルールと例外データを見直すだけの役割なので業務負荷は激減しそうです。

「集計」「作成」「送付(交換)」のそれぞれがマイクロサービス化されることで、その時々で最適な技術要素が採用され代替されていき、結果として業務全体の最適化が図られていく。現在はベンダーごとに個別実装している状況がサービスのプロトコルも標準化されて異なるサービス間での請求データ交換が安価に実現されるようになる。という姿までが妄想です。

もっとも、これらを実現するためには自動化できる請求プロトコルの確立が必要だしハードル高いしもう少し時間かかりそうかなと思ったらすでに法律文書の電子交換のためのプロトコルがあるようですね。

Legal Electronic Data Exchange Standard(LEDES)
https://en.wikipedia.org/wiki/Legal_Electronic_Data_Exchange_Standard

残念ながらあまり普及していないようです。SAPやOracleが請求書フォーマットを独自にXMLで実装しているようですが、このあたりのルールが大手ベンダーを中心に将来は統合されてくるのでしょうか。

このテーマはもう少し突き詰めて考えていくことになりそうです。

日本公認会計士協会IT委員会研究報告として

「スキャナ保存制度への対応と監査上の留意点」

の公開草案が公表されました。コメント受付期限は2016年10月26日までです。

http://www.hp.jicpa.or.jp/specialized_field/20160926aub.html

参考リンク
http://iwatani-c.cocolog-nifty.com/blog/2016/09/it-c417.html

平成17年9月8日付けで公表したIT委員会研究報告第30号「e-文書法への対応と監査上の留意点」の見直しの一環としての草案だそうです(本研究報告にともない30号は廃止)。

平成27年及び28年の内閣府令改正にともなう企業側の対応として想定するべき事項が記載されています(実質的に、上場企業ないしは上場準備企業が対象ですね)。

平成27年と28年の改正概要が付録を含めてコンパクトにまとめられているので、概要を理解するには役立ちそうな資料になっています。

本草案では「監査証拠がイメージ文書の場合の留意点」として、以下の4点が挙げられています。

1番目は「被監査会社の内部統制への影響」として、企業側で留意するべき点です。

(1)イメージ文書の特性から生じるリスク(改竄の痕跡、大規模な漏洩など)
(2)リスクの評価と対応及び統制活動
・全般統制
ア．スキャナ保存システムの開発管理
イ．アクセス権の管理及びユーザー認証
ウ．バックアップの実施
エ．情報セキュリティ対策の実施
オ．情報システムの運用管理
・業務処理統制
ア．関連付け
イ．電子署名
ウ．タイムスタンプ
エ．履歴情報の保存
オ．原本とイメージ文書の照合
・職務の分離
(3)モニタリングの実施

全般統制においては、スキャナ保存システムの開発管理や運用管理への影響が懸念され、また運用管理については文書の電子化プロセスや履歴情報の保存や保管という観点での管理運用規定の整備が求められることから、いずれにしても相応にパワーがかかりそうです。

業務処理統制においては、イメージ文書と帳簿の関連付けや電子署名の実質的な義務付けなど、こちらも従前の社内システムで対応できないポイントが多い模様。

 2番目は「監査人の対応」として、監査人側で留意するべき点です。

(1)スキャナ保存手続の理解
(2)スキャナ保存に関する内部統制の理解及び整備・運用状況の有効性の評価
(3)不正リスクの検討
(4)イメージ文書の証明力の評価

特に(4)については「原本以外の文書の信頼性」が内部統制に依存するものとして、その証明力を評価するための追加的な手続を求めています(正しい管理番号が付されているか、電子署名やタイムスタンプの確認など)。対応する企業側としては、これらの手続に耐える運用を検討することになります。

3番目は「原本の保存に関する被監査会社との協議として、被監査会社と監査人が協議するべきポイントが例示されています。

(1)原本保管する必要性のある書類及びその期間の検討
(2)被監査会社の内部統制の検討
(3)文書管理規程等の改訂の検討

監査人との打ち合わせアジェンダのひな形として使われそうです。

4番目は「コンピュータ利用上の留意点」として、イメージ文書の取扱い全般にわたる留意点です。

(1)スキャナ保存データを利用した不正リスク対応
(2)スキャナ保存データの取扱い
(3)イメージ保存データ入手時の取扱い

(3)については「データ提供依頼書」といった文書を通した手続により、正確性・網羅性・正当性を担保するルールを定めています。

改正後の運用は29年1月1日より可能ですが、仮に導入を進める場合には社内システム更新への影響は早めに見積もっておいたほうがよさそうです。

※当事務所では新スキャナ保存制度対応のご相談も承っております。お問い合わせフォームよりお気軽にご連絡ください。

https://ssl.form-mailer.jp/fms/e5d2273b248067

Webメディア「TechTarget Japan」に

「徹底解説：2017年1月から領収書のスマホ撮影をスタートするために準備すること」

が掲載されました。

電子帳簿保存法の2016年改正にともなう会計業務のペーパーレス化への促進について書きました。
これから取り組もうとしている企業様の一助になればと思います。
ご一読いただければ幸甚です。

※閲覧には会員登録(無料)が必要です

http://techtarget.itmedia.co.jp/tt/news/1608/22/news02.html
 

Facebookページ
https://www.facebook.com/TechTargetJapan/

旬刊「経理情報」7月20日号(No.1452)に 特集記事

『ベンチャー企業の経営管理はこうする』

を寄稿しました。

同誌で表紙が自分の記事タイトルになるのは初めての体験で、若干びびっております。

現段階の自分の考えをまとめた内容ですので、今後さらに深掘りしていく予定です。

ご一読いただければ幸甚です。

公式サイト

http://www.keirijouhou.jp/

Facebookページ

https://www.facebook.com/%E6%97%AC%E5%88%8A%E7%B5%8C%E7%90%86%E6%83%85%E5%A0%B1-102995733171378/timeline/

本記事へのご意見・ご感想

https://ssl.form-mailer.jp/fms/e5d2273b248067