会計とルール

会計は昔からバックオフィス業務であり、重要な位置づけを与えられてきたが、ルールという観点から考えて見ると、やや不思議な世界でもある。

多くの人は会計の世界をルールだらけのように見ていると思う。けど、ルールといっても構造と方法を決めているだけであって、なんだかデータベースの設計書に見えなくもない。

ただ、本質的に会計は経営者や投資家や債権者に有用な情報を提供することが目的だから、有用ではない、または撹乱するような情報、または隠蔽を禁止するというのが会計におけるルールの在り方だろう。

しかし、実際の経理のルールを見たときに、そのような観点から整合的に書かれているかというと、収益費用の期間対応の原則とか、方法の話に帰着しておりそこにやや不満がある。

簡単な例を出して見ると、受託開発をするソフトウェア会社はプロジェクトごとにエンジニアの作業で発生する工数とか、ソフトウェアのライセンス費を集計し、当期の原価にする。一方、契約金額のうち当期にコストベースでの進捗に相当する額を当期の売り上げにする。前提として、コスト見積もりが正確であるということを認めるとしておこう。さて、このような会社の経理規程になにが書かれているかというと、プロジェクトマネージャーはただしくコスト見積もりをしなければならないというようなことが書かれているものだ。

投資家にただしく情報をつたえるためにはコスト見積もりの精度をルールにしなくてはいけない。それは、つまりコスト見積もりを変動させる要因を禁止していくか、限度を定義してかなければならない。

例えば、残業は計画どおりに実施しなくてはならない。スコープ変化は変化分を新規プロジェクトにしなくてはならない。1ヶ月以上のプロジェクトは分解してワークパッケージごとに見積もりしなくてはならない。など。

これらは会計数値の精度をプロセス的に維持向上させるためのルールであっても、業務プロセスの品質を上げていく活動に通じる。

この話は一例だけど、会計のルールはこのように業務プロセスのルールに通じることに気づく。

バックオフィスのルールと思っていたら、フロント業務でのルールになるのは、会計の本質的な価値によるものだ。

会計のルールにはこのような関連性を明確にする意思を持って記述する必要があると思う。

ビジネスルールアプローチで6つのビジネス課題に立ち向かう

ビジネスルールの大家として高名なロン・ロスのコメンタリで、古いものだけど、最近読み直して引っ掛かりを感じたものがあったので、ここにメモとして書いておきたい。

原文はこちら。

www.brcommunity.com

６つのビジネス課題

1. 勝手ルールの存在による混乱・非効率（Consistency)
2. 基盤となるビジネスコンセプトの誤解
3. ビジネスルールがいろいろなところに存在していてアクセスが容易でないこと
4. 大規模な差別化
5. ビジネス環境変化の加速に追従していくこと
6. 退職による知識の散逸

前回、未発見のルールの獲得に関し、チラッと触れたけど、ロン・ロスがターゲットにしているビジネス課題には含まれていない。このことは、ビジネスルールの発見が大事ではないということではなく、一緒くたに考えてはいけないということなんだろうと思う。いずれも既知のルールをどう徹底するかという問題だ。

既知というのは、正確でないかもしれない。充足理由律（*1が、満たされているルールは当然既知であるが、充足理由律が満たされていないルールが満たされているルールと同程度に経営に利用できるかというとそうではない。この点が二つのレイヤを分けている。

*1:

充足理由律 - Wikipedia

）

ルールに書いていないことが何でもできるわけでもない。

前回、ルールに書いていないことはなんでもやっていいというbawbrの主張をしたものの、一つ重要な点を書き残していて、物理的（技術的）にできないことや、経済性や、倫理性、市場性の観点からできないことなど、ルールに書いていないけれども、やりたいと思っても実際にはできないことがある。わかっているルールをすべて明文化にしたとしても、未発見のルールはどうしようもない*1。例えば、絶対売れない製品を売れると信じて上市することは可能であるが、それを売ることはできない。

ルールに書いてないことは何でもやっていいと書いたけど、ルールに書いてないことは何でもできるわけでもない。

この話は実は面白く、このルールに書いてないことをルールにする発見プロセスのスピードがテクノロジーの進化によって早くなってきている。マーケットとコミュニケーションできるインターネットやクラウドのデータなどが、人工知能のパラダイム変化をもたらし、ディープラーニングが一世を風靡している。ディープラーニングがあれば、ルールの明文化が不要という考え方もあるかもしれない。

とはいえ、自動発見されるルールが100％未発見の法則をあらわせているかというと、そうであるわけもないという精度の問題や、ルールを学ぶためのコスト問題と、あくまでもデータは過去のものであるという問題と、シンプルを是とする「オッカムの剃刀」の観点から出てくる問題があり、ルールを明文化することの価値は残る。

*1:本来、ルールといわず、法則とか原則というべきものかもしれないけど

ルールに書いていないことはなんでもやっていいのだろうか？

前回ルールは、制約をし、強制をするもので、それら（制約と強制）がないとルールとして何かがおかしいということを書いた。その裏側として、ルールに書いていないことは、なんでもやっていいということなのだろうか？ 

普通の常識人なら、なんでもやっていいわけではないという風に答えるだろう。

しかし、単純にそのようにルールを書けばいいにもかかわらず、書いていないのであれば、なんでもやってよいとしか捉えようがない。ルール設計者の怠慢や能力不足で書いていないのか、それとも意図して書いていないのか、ルールを読む側は判断できないからだ。

それに、ルール設計者の怠慢や能力不足は避けられないかもしれないが、対策としてプログラムのInclude文のように、他のルールブックを参照すれば、特に労力もかけずにルールの不足は生じない。コンプライアンス目的であれば法令を参照すればいいし、経理であれば会計基準でもいいし、JIS標準でもいいし、もっといえば良心とか常識とかを参照したって悪くはない。

ただ、よく考えてほしいのは、企業にしろ、非営利法人にしろ、公共団体にしろ、組織の目的はその構成員をルールで縛ることではない。ルールは、その組織の目的を達成するためのステートメントの集合なのであって、極端に制限をかけることがその目的に資するかどうかで考えればいい。目的を阻害するルールがたくさんある組織や社会と、そのようなルールがない組織や社会では、後者のほうが速やかに目的を達成することができることは明らかだ。

また、別の観点もある。明文化されたルールは容易に変えられるから、あえて変えたくないルールは明文化しないという意味で、「信念」や「価値観」が使われることがある*1。

組織のルールは、経営から権限移譲されたルールを変更することができる人（おおよそコーポレートの部長達や、各事業の事業部長）が、責任を持つべきで、もし、ルールが変更できないようになっているとすると、もうそれは組織の責任ではコントロールできないものだ。もちろん、脈々と代々伝わっていくこともあるだろうが、代替わりを繰り返すと不文律が劣化しながら伝わっていくというのが世の常だ。

「信念」や「価値観」を明文化してはならないという理由にはならない。「信念」「価値観」こそ明文化して、各ルールと紐づけを行い、ルールの格上げを行っておいたらいいだけのことだろう。

電通の鬼十則*2は、非常に有名だけど、この明文規定は明文規定としてあるからこそ、見直しをしていくことができる。もし、電通のブラック企業性がこの鬼十則にふくまれているのであれば、これを変えればブラック企業性が解消できるだろうし、もし鬼十則こそが電通だとするなら、電通が時代に適合しないというだけだろう。電通が時代に適合するというなら鬼十則を変えたらいい。もちろん変えるためには、相当の覚悟がいることは事実だろう。

 さて、最初の疑問に戻ってみよう。ルールに書いていないことは何でもやっていいのだろうか、ということについて、もしそれがやってはいけないと判断できるのであるとすると、ルールに書いてないほうがおかしいので、ルールを是正するべきであり、やってはいけないと判断することができないのであれば、実施してよいということになる。

ちょっとわかりにくいかもしれないが、ルールは継続的に改善していくものであり、改善をする機会は実際に何かをして結果を得るというフィードバックがないと改善ができない。ルールがないということは、過去にその行動をして問題なかったか、行動をしていないかということを含意する。だから、実施してはならないということになるまでは、実施してよいのだ。

*1:雙葉学園は、雙葉生らしいというキーワードを明文規定なしで使うことで、変更不能な状態を維持している

toyokeizai.net

*2:

公益財団法人 吉田秀雄記念事業財団 | 財団の概要 | 吉田秀雄について | 「鬼十則」

よくないルールを修正する

身近なルールの中にも「よくない」ルールがあって、修正を検討すべきだと思う。会社員の人なら、あなたの会社にも就業規則というものがあって、そこにはこのような条文が書いてあると思う。

採用日から６か月間継続勤務し、所定労働日の８割以上出勤した労働者に対しては、１０日の年次有給休暇を与える。... 

http://tokyo-roudoukyoku.jsite.mhlw.go.jp/var/rev0/0140/9549/05.pdf

 １点目は、「休暇を与える」という語尾。通常この条文は「～従業員が10日の年次有給休暇をすることができる」という意味だと解釈するのが普通。要するに与えるけど、「従業員側が消化しない」のは自由だと読むべきもの。でもね、常識でわかると言ってはいけない。解釈権を人事部に持たせている間は、コンピュータに有給休暇日数計算すらできないことになってしまう。また、（有給取得100％の国、たとえば）ドイツ人がこの文を読んだらまず間違いなく10日休まなくてはならないと誤解するだろう。だから、

「～労働者は年次有給休暇を10日以内で取得することができる」

（bawbr修正後１） 

と書くべきだ。たとえ有給休暇消化率100％は目指すものであったとしても、ルールじゃない。

2点目は、他の条文で年次有給休暇取得可能日数が１日以上だった場合、「１０日」が加算されるのか、それとも最大で１０日なのかが紛らわしい。先の修正案でも上限が変わるのか、それとも加算されるのかわからない。日数を求める計算式が複数の条文になっているのがよくない。

「～労働者の年次有給休暇取得は10日以内でなければならない」

 (bawbr修正後２）

語尾を「でなければならない」に変えただけだけど、紛らわしさが格段に減る。他の条件で付与された日数が無視されて、この条文だけで完結していると読める。条文の独立性は非常に大事で、依存関係をできるだけ減らすことがルールの保守性を高める。

もし、上書き式ではなく、加算式なのであれば、

「～労働者の年次有給休暇取得は、別で定めるものに10日加算した日数以内でなければならない」

 (bawbr修正後３）

 と書けばいい。

ルールの書き方の理屈として、以下のことがわかったと思う。

1. ルールは何かを制約している。権利を付与していたり、制約していないように読めたら何かがおかしい。（上記例では、本当は有給取得可能日数を制限していた。）
2. ルールは何かを強制している。強制していないように読めたら、他の条文との整合がとれていない。（上記例では、上限日数を他の条文にかかわらず規定している。他の条文を参照しないとわからない条文なのに他の条文を明示しないのは何かがおかしい）。

上記を、簡単なスローガンとしておくと、「onlyかmustを使え」ということになりそうだ。（これは、自分のオリジナルではなく、RuleSpeakに書いてあること）。

「あってはならない」ではなく「はいけない」と述べよう

不始末の謝罪や、それを非難する文脈で「であってはならない」という言葉遣いを目にすることがある。あまり目くじらを立てるつもりはないし、他の人が使う分には特段問題にするつもりもないが、自分はこの言葉遣いを使わないつもりだ。

簡単にいうと、「であってはならない」には＜否定形のルールの定義＞という意味と、＜事実の存在の否定＞という意味の両方で使われるから、というのがbawbrの考え。

英語でもあまりその状況は変わらず、"It must not be that ..."と書いたら、何かをしてはならないという意味にも読めるし、that以下の事実の否定の意味もあるように読める。英語の場合には、that以下が現在形で書かれればルールだし、過去形で書かれれば事実の否定と見分けがつくのだろう。

C++やJAVA以降のオブジェクト指向言語でいうところの、クラスとインスタンスの差としてもいいかもしれない。

例えば、「赤信号なのに横断することはあってはならない」という言葉遣いをしたとき、交通教本に書いてある文脈であればルールが書いてあるということだと理解できるだろう。しかし、赤信号で横断する人を撲滅しようとする警察内部の課題検討会議の際に、会議参加者からこの発言があったとすれば、信号無視の検討をするのはおかしいということを含意してしまう。

若くて真面目な１年目のひとが、信号無視の発生件数を集計してえらい人たちに報告している姿を思い浮かべてみよう。「信号無視はあってはならないのに件数が0ではないのはなぜか」などと偉い人たちから言われたら、どうおもうだろうか。本末転倒の事態が生じる。信号無視はあってはならないのにもかかわらず、件数が0ではないのはカウントの仕方が間違っているに違いないという（苦笑。これはパワハラ）。

信号無視だからわかりやすいが、もっと専門性の高い分野、科学や、ビジネス、法律などとなってくると、本当に笑えない事態が生じてくる。

そんなことをいろいろ考えるに、日本語でクラス定義としてのルール記述で否定形を使う場合には「はいけない」という言葉遣いが適切だろうとおもうようになった。「赤信号での横断はいけない」「大気中にベンゼンが〇〇以上含まれてはいけない」「仕入先への発注後金額を変更してはいけない」など。これだと事実の否定の含意はなく、ルール違反は悪いことだけれど存在はするというニュアンスが出てくる。

混乱させるようなことをあえて書けば、刑法には「はいけない」という言葉遣いは使われておらず、「他人の財物を窃取した者は、窃盗の罪とし、10年以下の懲役又は50万円以下の罰金に処する。」という書きぶりになっている。この書きぶりもおもしろくて、「窃盗はあってはならない」とか、「（国が課するのは）10年超の懲役ではあってはならない」というような書きぶりではない。

いずれにしても、否定形のルールというのは解釈が難しくなるので、なるべく肯定系で書きたいところだ。

暗黙の社内ルールとしての会議

 前回、社内ルールとしてのメールを取り上げた。前回必ずしもきちんと伝えきれた自信はないものの、ルールを作ることで生産性が下がるのではなく、ルールを明確に定義しないことによって、生産性を向上する道をふさいでいるということを示したつもりだ。

今回は、暗黙の社内ルールとしての会議を取り上げたいと思うのだけど、これもやはりルールを明確に定義しないことによって、生産性向上をふさいでいるということが言えると思う。

自分の会社での会議を思い出してほしい。ルールが明文化されているかどうかはさておき、どんな決まり事があるだろうか。

1. 会議では議事録を取らなくてはいけない。若手がその役目を負う。
2. 会議では意思決定をする人が参加しなければならない。
3. 会議室は、事前に予約しなければならない。

これらは、社内ルールとして明文化されているかもしれないし、されていないかもしれない。しかし、これらのルールは会議の本質をきちんととらえたものかどうか、という観点で検証するためには、まず明文化されている必要があるということは、前回の社内メールと同様の議論である。

これらのルールが適切かどうか、ということだが、例の１番の議事録を作らなくてはいけないならないのは、当然というようなものでもない。会議を録音しておいてもいいし、チャットツールで公開すると同時に記録としてもいい。だから、ルールとしておくのは記録を残すべきということなのであって、議事録というツールを決めるべきではない。議事録というツールを決めたとたんに、議事録フォーマットが乱立し、統一しようだとか、使いやすいのがこちらだとか、標準化はどうすべきだとか、そんなことに議論の時間が取られる。フォーマットの標準化が必要なら、標準化したルールをきめておいて、これ以外のフォーマットを使ってはならないというところまでルールにするべきである。

そうすると、正しいルールの書きっぷりは、次のようなものとなる。

1. 会議の記録が次の形式で作成されなければならない。（１）会議の開始日付・時刻、（２）参加者一覧、（３）各参加者の参加手段（会議場所）、（４）討議論点、（５）結論、（６）議事録の作成者、（７）秘密区分、（８）会議で使用された資料一覧、が実態として記載されていなければならない。この内容が満たされたものを議事録（Minutes)と定義する。議事録はメールで平文にて作成し、保存のためCCに議事録保存目的アカウントを入れ、発信されなければならない。
2. 会議主催者が、会議の成立または会議の流会を決めなければならない。
3. 会議室や通信手段が会議開始時刻までに指定されていないか用意されていない時には、会議主催者の意思のいかんによらず、会議の流会としなければならない。

上記のルールを見て、面倒だと思うだろうか？　もしかしたら、そう思うのかもしれない。けれど、これは今まで明文化されていなかったことを明文にしただけであり、明文にしているからこそ、変更することも可能であるということを意識してほしい。こういったルールを明文化しないと、自分ルールのようなものがはびこってしまう。