以下の記事を更新しました。特に、SyncProjectのコードをGitHubで公開しています。他のコードも随時公開していきます。（いや、gappをシームレスにGitHubで扱えるってしらなかったからさ・・・）
Special Thanks
NozbeとTimepotの連携が公式サポートされた
NozbeとTimepotの連携が公式サポートされたので使ってみた所感を書いておく。
まず、期待していたNozbeのプロジェクトが自動連携してTimepotに入るというわけではないので、一定のマニュアルワークフローを想定しないといけない。つまり、Nozbeでプロジェクトを登録したら、TimepotでプロジェクトNozbeからの連携はデフォルトオフになっているので、オフになっているスイッチをオンにする必要がある。
たとえば、この運用がはまる人、オペレーションの場合にはいいのかもしれない、たとえば、Nozbeでプロジェクトを増やさないような運用をしている人（無料だと基本プロジェクトを固定して運用することになるので、このような使い方をしている人）、あとある程度チームで運用していてタイムシート管理をしなければいけないプロジェクトが限られている場合もそうだろう。
ただ、プロジェクトをGTDの意味で使う場合には、どんどん増やす必要があるから、僕には合わないツールだった。Togglを継続して使おうと思う。
NozbeとTogglの連携（TogglのChrome拡張機能にNozbeが追加された）
Chromium OSにしたことで、諸々のChrome拡張機能関連が一括してアップデートされ、あることに気づいた。待ち望んでいた機能だったので、ついついこうやってポストしてしまう。
TogglのChrome拡張機能に、Nozbeが追加されていた！ Chromeで、Nozbeをウェブアプリケーションとして使用していたら、タスクの詳細を示すペインで、Togglの馴染みのボタンが表示されていた。
流石に、NozbeのプロジェクトがそのままTogglのプロジェクトに入るわけではないけど、Togglのタスク用の項目には、Nozbeのタスク名が入る。
すでに気づいていた人にとっては、今更の話かもしれないけど、bawbrにとっては、今週一番のニュースでした。とても嬉しい。
githubの変更履歴を見ると、6月8日にリリースの1.2.0にて追加になっていたみたい。
Chromium OS 導入について
※この記事は自分用のメモです。他の人に必要な情報が十分でないかもしれませんが、ご容赦ください。
自宅で、安いPCが一台余っていたので、Chromium OSを導入してみた。結果として正解だったので、ここにメモしておきたい。
参考にしたページ
中古PC活用：Windows XPパソコンにChromium OSをインストールして再 ...
用意するもの
不要になったPC、4GB 以上のUSB メモリ
手順
- Chromium OSをインストールするPCのCPUを確認する
- ダウンロードサイトから、イメージファイルをダウンロード
- USBメモリにイメージファイルを書き込み
- インストール先PCで、USBから起動できるようにBIOS設定
- USBから起動
- HDDにインストール
- WIFIをうまくつかめないため複数回再起動
デメリット
- キーボードがUS配列（記号を入力するときに、キーボードに記載の文字とは異なるものを入力しなければいけない）
- FLASHが標準では入らない（これは、気が散らないという意味でメリットなのかもしれないが）
メリット
- 何より速い。速度命。速いは正義。機能よりスピード
- シンプル
- 安いから大量に用意できる*1
言語道断と報道の道は同じ意味
高校のときの国語の授業で、漢文を勉強していたときに、「道」の解釈が問題になったことがあった。
漢文の先生が、現代語で「言う」という意味で「道」を使う用例を示しなさいという問いを出された。挙手して、何人かが的外れなことを述べた。いわく、剣道とか弓道の道がそうだとか（これは、「教え」の意味で「言う」ではない）、指導の導がそうだとか（これは「導」で「道」ではない）。
先生が答えを言おうか迷っていたぐらいのときに、僕がつい、「あっ」と僕が声を出してしまった。こういうときに、格好付けたりできないのが自分で、わかった喜びを素直すぎるように顔にも声にも出してしまう。
「報道の『道』です。」
この話は、誇らしい記憶として残っていて、その学期の成績がよかったのが、この話に関係したのではないかと、自分では思っている。当時はインターネットがなかったから、用例を検索するのもできず、唯一の用例として「報道」だけを記憶していた。
30年もたって、インターネットで検索をしてみたら、「報道」に加えて、「言語道断」が挙げられていた。誇らしい気持ちで記憶していたのにほろ苦い気持ちに上書きされたような気にもなったが、これはこれでよしとしようと思う。
要件を明確に定義する方法のうちの一つ（Validation仕様）
要件を明確にする手法に長けていくのは、熟練の技の世界のように思われますが、セオリーとして確立されていることもあります。その一つが、"Validation"（チェック）という型の要件です。Validationは、入力値をチェックして、問題がある場合にはエラーを出すというタイプの要件です。
Validation系の要件では、仕様を＜違反＞するケースをテストしてみるとよいです。違反ケースがすっとかけるようであれば、Validation系の仕様として優れていると判断します。
たとえば、日本では、税番号のような制度がないので、あまりピンとこないかもしれませんが、bawbrが経験してきた中で、税番号のような制度を持つ国は多いです。そのような国では、税番号をマスタに必須で入力しなければいけないというチェックをかけたいという要件が出てきます。これを例に説明をしてみたいと思います。
具体的には、得意先マスタ（顧客マスタ／取引先マスタ）のある項目を必須入力にするという仕様にします。いい例なので取り上げてみたいと思います。
税番号の制度は国によって決められるので、得意先の所在する国を前提条件として記載したいとおもうと、まず、こう書いてしまいがちです。
（例１）「得意先の国がAの場合、税番号は必須とする。」
（違反ケース？）得意先の国がAの場合、税番号が必須となっていない。
違反ケースになっていない。正しい違反ケースは以下のとおりです。
（正しい違反ケース）得意先の国がAの場合に、税番号がブランクである。
「に」という助詞をつけたり、必須に対し「ブランク」と反対語を使わないと、違反ケースがかけません。すっとかけないというのはこういうことです。
そもそも、このグローバル化している世界で、その得意先が輸出先となる場合もあります。日本からその得意先に輸出する際に、日本のシステム側で税番号が必須とするわけがありません。SAPなど、グローバルに使えるERPを使っている場合には、現地国と日本で同じシステムを使っていることも、いまや普通です。こんな仕様を書いたら、日本からその得意先に輸出するための得意先の税番号を入れなければならなくなってしまいます。
必須という言葉がでてきたら、本当に必須なのか吟味する必要があります。必須としたとたん、税番号のない得意先が許されないからです。別の言葉で言い換えてみましょう。まず平たく、「なければならない」という言葉を使うのがよいでしょう。
また、税番号は得意先に固有のものであって、現地法人aの存在とは別です。しかし、現地法人aと取引する段になって、税番号が必須になるのです。だから、下記のように書きます。
（例２）「A国で、現地法人aの得意先に税番号がなければならない」
（違反ケース）A国で、現地法人の得意先に税番号がない。
違反ケースがすっとかけました。これはValidationの仕様として優れていると判断してよいことになります。
二種類のルール（決定型ルールと、実行型ルール）
ルールを理論的に取り扱うために、有用な軸として決定型ルールと実行型ルールという分類方法があるので、ここで紹介しておこう。この分類は理論的なだけではなくて、IT技術を使った実装や、組織で運用する際にクリアな見通しを得ることができる優れた分類方法だと思う。
決定型ルールは、そのルールに従うと答えが得られるもので、たとえば、スマートフォンの複雑な契約体系と割引、キャンペーンをイメージしてもらえばいい。最終的にスマートフォンの契約者が支払う契約金額は、決定型ルールを通して決定される。顧客との信用取引をする際に与信を行うが、その与信額の決定方法なんかも、同じような考え方でいい。
実行型ルールは、そのルールに従っていないことが判断できるもので、たとえば、会議で議事録を作らなければならないというルールは、議事録が作られていないということが判断できるし、環境基準で汚染物質の濃度が所定の基準値以下でなければならないというようなものも同じ考え方だ。
Ron Rossは、実装に示唆を与える３つのポイントを示している。
- 答えとなる選択肢をしめすものか（決定型）、そうでないものか（実行型）。
- ケースをルールに当てはめて評価するタイミングが一回（決定型）か、複数回か（実行型）。
- 義務づけするもの（実行型）か、そうでないか（決定型）。
この二つは、紛らわしく設計しようとおもえば紛らわしく作ることができる。けど、この二つを明確に分けてルールを書くことで、クリアな理解を促すことができる。
この二つのタイプのルールを知ったうえで業務プロセス設計やカスタマジャーニー設計をしようとすると、腑に落ちるかもしれない。
例えば、イトーヨーカドーのようなスーパーのレジは、平等にみんな並ぶけど、外国では並ばずに会計が終わらせられるプライオリティレーンのようなロイヤルティ顧客優遇策があったりする。
ただプライオリティレーンの数を増やしすぎると、一般客のレーンの混雑がひどくなりすぎるかもしれない。逆にプライオリティレーンの数が少ないとプライオリティと言っている意味がなくなりロイヤルティ顧客に不満を与えてしまう。こんなとき、
- プライオリティレーンで、最大でも30秒以上待つ顧客が出てはいけない。
- プライオリティレーンの数は、繁忙時3レーン、閑散期2レーンとする。
1番目のルールが実行型ルールで、2番目のルールが決定型ルールとなる。
実行型の方は、店舗のマネージャーが何らかのそれを維持するためのプロセスを設計し運用することになる。例えば、列の始まりの限界ラインのところにセンサーを置き、そのセンサーが反応したら、レジ係の予備としていた人に連絡が入り、レーンを追加するとか、レジ係が何らかのクレーム対応を始めてレーンを閉じるときには、必ず同じように予備のレジ係に連絡がいってレーンを追加するとか。そのとき、ルールを守るために最適なプロセスが設計される。
決定型のルールは、これを決めておけば紛れがないし、これが最適であるなら何の問題もない。時間で決めているので、その時間が来たかどうかだけを判断すればいい。誰かに義務を課しているかというと、レーンの数は決めているが、義務とは異なる。
このルールは、自分が機械でこの文を読んで見たと考えるとわかりやすい。
問いで、べきかと聞けばべきと答えるだろうし、問いでできるかと聞けばできると答える。レーンは幾つにするべきか、という問いの答えだと読めば、いくつにすべきという答えとして読めるだけで、義務性も権利性もルールに書いてない。
現在のルールエンジンで取り扱えるのは、決定型ルールで、実行型のルールは主にビジネスプロセスで対応する枠組みになるだろう。実装をイメージできる枠組みだから、とても有用だ。
