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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

toyokeizai.net

*2:

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

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

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

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

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

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

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

(bawbr修正後1) 

 

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

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

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

 (bawbr修正後2)

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

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

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

 (bawbr修正後3)

 と書けばいい。

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

暗黙の社内ルールとしてのメール

いくつか暗黙の社内ルールを取り上げたいと思う。その第一に、メールがいいのではないか、と考えた。社内メールの目的は、第一に非同期の連絡手段を社員に提供するということだけど、暗黙にいろいろなルールができているのではないか?

・例えば、24時間以内に返信をしなければならない(偉い人からのメールだと、もっと短くて4時間も返信に時間がかかると、文句を言われる・・・)。

・例えば、宛先に入れているのに、○○さん、とメール本文に書かなければいけない(それも、上司のメール振り分けのルールに引っかかるように!)。

・直属の上司を必ずCCに入れなければならない。

これらは、メールが単に非同期の連絡手段を社員に提供するということからは生まれないルールであるが、社内規定に書いてあるのを見たことがない。にもかかわらず、これらを破ると、上司からおしかりを受ける。じゃあ、最初からルールにしておけばいいのではないのか? AIに仕事を任せたら、このような一つ一つをルールとして定義しておかなければならないのに、明文化されていないのは、何か、問題を抱えていると考えたほうがいい。

・つまり、24時間以内に返信が欲しいのに、そのための連絡プロセスがないこと。そのため、いつでもいい返事ではなく、24時間というリクエストをする以上は、追加のコストを払うべきであるが、それが払われていないこと。立場が上だからということが本当に、正しいルールなのか検討されていないこと。

・つまり、チームとチームの間で連絡するプロセスがないこと。または、個人と個人の間で連絡を取ることが業務上許可されていないにもかかわらず、ルール化されていないこと。

このような状況で、いきなり入ってきた人がうまく仕事ができないとしても、ルールがしっかりしていないから、というほかない。

本来のルールは、以下のようなものが明文化されているべきなのに、暗黙のルールとなっているおかげで、業務プロセスの改善もできない状態になっているのが、現状だろう。

・プライオリティ設定以外の場合、ケースの到着順に回答しなければならない。プライオリティ設定がされたケースの場合、回答の優先対応をしなければならない。回答先はプライオリティ料金を支払わなければならない。

・チーム内で、他チームとの連絡内容が、いつでも照会できる状態でなければならない。

おそらく、ルール化しない理由の一つは次のようなものだと思う。現状、ルールに伴うコストが見えない状況であった。そのコストが見えるようになると、そのコストの負担を誰が取るのか決定しなければならない。その決定が面倒(または怖い)なのだろうと思う。

気の利いた、空気が読める部下がいれば、うまいことやっていくれていて、問題が感じられなかったかもしれない。でも、そのような気の利いた、空気の読める部下を、このような低付加価値の仕事に張り付けていることが、非倫理的だとはおもわないだろうか。

この隠れたコストを見えるようにして、さらにそれを削減するというのは今までのBPRでも一緒だろうから、いってみれば、BPRしたくないという以上の理由も考えられない。

統制される組織は窮屈か?

コンプライアンスのために、効率度外視のルールが決められていることが、日常のビジネスで問題になって久しいと思う。コンプライアンスは、いたって平たく言えば、経営者が、株主やら、検察やら、マスコミやらから、訴訟を起こされたり、逮捕されたり、非難の嵐を浴びせられたりということを避けたいという、いわば「恐怖」をモチベーションに、企業組織に導入された縛り事だったという理解で、間違ってはいないと思う。厳密には、もちろんいろんな整理をすることはできるだろうけども。

ルールがたくさんあると、そのルールを知悉しないと、その組織で効率的に働くことができなくなるし、生産性はルールを前提とした競走という程度のことではなくて、ルールの使いこなし力が生産性の一番の要素というかなり逆転した状態になってくる。本来なら、「一番速く走れる人が誰か競走しよう!」というときに、お互いを邪魔しちゃいけないとか、フライングはダメとか、そういうのがルールだったとおもう。でも、今の大企業の組織の状態は、利益を一番上げたということは、まあ評価されるだろうけど、一番偉いわけではなくて、ミドルマネジメント以下であれば、ミドルマネジメントが決めたKPIを自分の組織やチームのエゴを通して、社内ルールを知り抜いたうえで、社内人脈をベースに出し抜いて他の邪魔をしながら達成し、シニアマネジメントになれば、トップマネジメントが決めたKPIを競合の邪魔をして、自社のエゴを通して実現するというのが出世の道のような状態だ。

まあ、そういうのが大企業の常だとすれば、ルールが明文化されて整備されていれば、それはそれでフェアなのかもしれない。そこに、ルールを前提として業務を変える権限が付与さえされていれば。ルールさえ守れば、どのような仕事の仕方をしてもいい、というコミットメントがあれば、フェアなんだろう。

だから、コンプライアンス過剰なルールで縛られた業務というのは、それ自体が問題ではなくて、ルールを守った業務プロセスを柔軟に変えられる権限が与えられていないということが、一番の問題だというのが、わかると思う。

実際、ルールに業務プロセスの仕方まで書いてあって、それを変えるのは容易じゃない。でも、本来、それは変えていいはず。変える力こそ、従業員に与えるべき、僕はそう考えている。

NozbeとTogglの連携

Nozbeは、GTDのコンセプトに忠実なオンラインタスク管理システムで、チームのタスク管理にも拡張することもできるアプリケーションです。僕は、これをProライセンスで使用しているのですが、一つタスク管理上の悩みがありました。

Nozbe

Nozbeで行ったタスクがどれだけ時間がかけられたのかが記録として残らないということです。実際に、使用した時間を計測したいと思っても、Nozbeには記録する機能がありません。NozbeはあくまでもGet Things Doneのツールであり、やってしまったら後のことは別のシステムで管理すべきという発想なんだと思います。

それはそれでいいのですが、生産性向上をはかる上では、時間の記録も必要だろうと思うのが必然です。

そこで、定評のあるタイムシートシステムであるTogglと連携させることを検討しました。Togglは、プロジェクト別の時間計測が可能なオンラインのタイムシートシステムです。無料のライセンスを使用しています。

最初、IFTTTで連携できないか確認してみたのですが、IFTTTではNozbeとTogglと連携できませんでした。そこで、Zapierを使用して連携できないか確認してみたところ、可能そうであることがわかりましたが、どうも、本格的に連携させたいと思ったら(後で説明しますが、EvernoteやSlackとも連携させることにしたかったのです)、高価なライセンスを買わないといけなさそうでした。そこで、Google SpreadsheetとGoogle Appを使って連携させてみました。実際、今、これを使って運用しています。

30分バッチ処理で、Nozbeで作成したプロジェクトを、Togglのプロジェクトに追加し、また、Nozbeで完了したプロジェクトをTogglでCloseするというインタフェースを利用しています。

要求分析

システム統合をするにあたって、まずは要求分析です。自分がユーザーなので、要求分析といっても簡単なものですが、以下のような要求事項があげられます。

  1. Nozbeで作成したプロジェクトをTogglのプロジェクトに連携させたい。新規作成、完了をTogglに連携させる。Nozbeで新規プロジェクトを作成したら、Togglにも同じプロジェクトを登録したい。
  2. Nozbeで新規プロジェクトを作成したらEvernoteにも対応するNoteを自動的に作成したい。
  3. Evernoteに連携されたNoteに作業記録を書きながら、Togglで時間計測をしたい。
  4. Togglの時間計測を完了したら、SlackにPostして作業時間報告をしたい。

さて、実際の実装に行く前に、要件定義と基本設計を行います。

要件定義

(経済性要件)ソフトウェアの新規購入や、ウェブサービスに対する追加的な支払は0にしなければならない。NozbeはProライセンスを許す。Togglは無料ライセンスを継続したい。追加のライセンスやサブスクリプションを行うソリューションを採用してはならない。

(同期頻度)1時間あたり2回以上、同期が行われなければならない。

(利用技術)開発言語は、JavaJavaScriptのいずれかでなければならない。

(製品)タスク管理ツールは、Nozbeを使う(そもそもの要求事項なので、変えないことにします。Toodoledoを使うとか、タスクシュートを使うとかいろいろ選択肢はありますが、自分が気に入っている基本のツールを変えると、生産性を落としてしまうので、ここでは変えないことを優先します)

ノート管理ツールは、Evernoteを使う(これも、そもそもの要求事項なので、変えないことにします。OneNoteを使うとか、いろいろ他の選択肢もありますが、やはり、使い慣れたものが一番なので)

時間計測ツールは、Togglを使う(これもやっぱり要求事項。以下略)。

報告ツールは、Slackを使う(これも、以下略)。

(連携基盤)Google Spreadsheetと、Google Appを使う。AWSレンタルサーバーを使って、実装することも考えられましたが、経済性要件を満たすようなインフラは見つけられませんでした。そこで、Google Appを使って実装することにします。また、EvernoteGoogle AppでアクセスできるAPIを公開していないので、最小限の範囲でZapierを併用する。

基本設計

機能を大きく4つに分解し実装箇所を以下の通りにする。

 

Google App

1. SyncProject: Synchronize project list of Toggl based on Nozbe prioject

2. Post to slack when toggl timer is stopped

 

Zapier

3. Create Evernote note when Nozbe projec is created

4. Create Evernote tag when Nozbe project is created

 

詳細設計&実装

SyncProjectのGitHubはこちら。

GitHub - bawbr/Nozbe2Toggl: Nozbe2Toggl

SyncTimeEntryのGitHub

GitHub - bawbr/Toggl2Slack: Post to slack when toggl time entry has finished