ゴールドラット著「クリスタルボール」発売記念、という訳ではないのですが、チェンジ・ザ・ルールの会（でいいのかな？）に行ってきました。というか
鳥一代
http://www.toriitidai.com/index.html
に行ってきました。まるごと鶏一匹が入っている、参鶏湯（サムゲタン）という鍋ものが有名で、お酒は焼酎関係が中心です。最近、ＴＶ番組（ぶらり途中下車）で紹介されたらしく、月曜日なのに満席という込みよう。
でも、久々に行けて良かった～。美味しかった～。
http://shoppingfeed.jp/media/miid-2387254/item/
なぞと、店の宣伝だけで終わってはいけません。
テーブル席２つだったのですが、ノートパソコンを広げて、発表（らしきもの）をしたので資料を載せておきます。向こうのテーブルでは別の話で盛りがっていたし（笑）。
チェンジ・ザ・ルールの会は、ゴールドラット氏の提唱するTOC（制約理論）の派生の会です。
ザ・ゴール
http://www.amazon.co.jp/dp/4478420408
チェンジ・ザ・ルール！
http://www.amazon.co.jp/dp/4478420440
TOC（制約理論）については、
TOC 制約理論の広場
http://www002.upp.so-net.ne.jp/toc-jp/
を参照してください。
また、IT関係であれば自前ですが、
スループット会計とソフトウェア開発工程の関係
http://www.moonmile.net/mymy/solution/001.html
を参考にしてくれるとありがたいです。
で、以下は、チェンジ・ザ・ルールの会で話した事柄。
さて、この TOC(Theory of Constraints なので、正確には、制約のセオリー/習慣/現象 が正しい）ですが、ある流れを持つときに「制約」があるというのが肝です。制約というのは絞り込みがあるところです。岸良さんが話しているように、流れが悪いところが「フン詰まり」になります。なので、この流れ＝スループットを上げるためには、制約＝フン詰まり、を解消するか、バッチを小さくする＝フン詰まりになりにくいようにする、という方法を取ります。
制約自体を強化するというのは、いわゆるレバレッジ（梃の原理）の話で、梃を動かすとき支点が弱いとすぐに壊れてしまいます。なので、この視点を強くします。会社を例にとれば、
・社長の決断力
・会社が持つ製品開発力（コア・エンジニアリング）
・決済のスムーズさ
などです。逆に言えば、この制約に関係ないところをいくら強化しても無駄です。TOC の場合、スループットを第一に考えますから、制約でない場所を強化しても、制約が弱い限り、その流量は限られてしまうのです。
# 当然、スループット会計を第一としない場合は、この制約の強化は別の意味になります。
# ゴールドラット氏の云うのは「儲け続けること」。対して、ドラッカー氏の云うのは「存続すること」ですからね。
さて、私は普段の活動は執筆が主な訳で、最近は秀和システムの逆引きシリーズの改版に追われています。この本は、tips 集と行って、逆引きのヒントが非常にたくさん集まった本です。なので、ひとつの本に 300 tips があり、執筆期間が２か月だとすると。
・300 tips（サンプルコード込み）
・期間は、２か月間（40日間）
・１日は８時間、ゆえに、320時間で仕上げる
という計算になります。これは、大体１時間に１個仕上げるということです。
これをどのように進捗管理していくのか、というのが問題です。
＜001＞
これが私の進捗管理表です。見るべきポイントとしては、
・tips 単位に分かれている
・文章の完了日を入れる
・サンプルコードの完了日を入れる
・進捗率を自動計算する
ところです。昔は、バーンダウンチャートを表示するために、グラフを使っていましたが、最近は進捗率でだいたい分かるようになったので使っていません。
一見、どこにでもある進捗管理方法です。これをＩＴ業界の場合は、関数単位だったりクラス単位だったり、あるいは機能単位だったりします。
ですが、この進捗管理には重要な意味があります。
それをひとつひとつ解説しましょう。
■tips単位で完了を管理
章単位などではなく、tips単位という細かい単位を使っています。もう少しまとめてと思うかもしれませんが、駄目です。これは、TOCで言う「バッチを小さくする」ところと、デマルコ氏の云う「計測できるもので進捗管理する」という両方を組み合わせています。
これを、プログラミングに置き換えると、機能単位のように大きな単位にしたいところですが、そうすると「いつ完了したのか」が判別できなくなります。また、ひとつの機能を完了させるために数日/数週間かかるために、「進捗率」という計測できない数がでてきます。それを排除するために、「計測できる数」を使います。
ゆえに、プログラミングであれば、１日以内で終わる
・関数単位
・UnitTest単位
・web ページ単位
をお勧めします。勿論、１年に渡るような大きいプロジェクトの場合は、関数単位にすること自体が非常に手間で時間がかかります。このあたりは、WBS風にブレークダウンする、あるいは概算値を使う（ファンクションポイント法など）があるので、それを利用します。機会があれば、後日話します。
■完了日を入れる
さて、細かい tips（バッチ）に分けたので、1個1個のバッチがスムースに流れやすくなります。この流量（スループット）を計算するために、完了日が必須になります。この完了日を「済」や「完了」だけにしておくと、どの位の流量があったのか計算できません。
この執筆の例では、1日8tips仕上げれば、予定通りに終わるという計算になりますが、tips によっては難易度のばらつきがあります。半日かかるものもあれば、10分ぐらいで終わってしまうものものあります。
ですので、1日単位の進捗度に一喜一憂しないために、週単位での進捗度が出せる、また工事進行基準を適用できるように、進捗度合が予測できるようにします。
これは、CCPMで云う「アラーム領域」と同じです。
■完了を明確にする
いわゆる、TODOリスト化（GTD）することです。これは、長期の同じ形式で仕事をする場合、モチベーション（動機）を保ち続けるためのコツです。300 余りもある tips は、当然1日では終わりません。また1習慣でも無理です。2か月間、ひとりでコツコツと作業をするためには、それなりに根性（笑）が必要です。ですが、なにも無いと根性が挫けますよね～。なので、こんな風に「終わった！」を演出します。
ひとつの tips が終わったら、完了日を書き込む。チェックを入れる。
という作業を挟みます。一見、無駄に見える作業ですが、これが気持ちの切り替えにいいのです。
確か、百式ブログで（IDEA*IDEAだったかも）、今日やることのTODOを手帳に書いておいて、終わったら大きく×（あるいは○）を付ける、という動作を勧めていました。大きな仕事は、大きめに書いて、小さな仕事は小さめに書く。そして「達成感」を得る、という方法です。それと同じです。
「所詮、仕事だから」と、黙々とやるのだけではなく、仕事とはいえ人生の貴重な時間を使っているわけですから、何かの実り/達成感/楽しさを得ましょう。ニコニコカレンダーや振り返りの儀式もそれに似たようなものです。
ちなみにチェンジ・ザ・ルール！の会は google グループで誰でも参加が可能です。如何ですか？
http://groups.google.co.jp/group/changetherule?hl=ja
