電子工作コンテスト２００９の作品を観に来てね！
http://www.engineeraward.jp/ele/ceremony.html
なるメールが来ていたので見に行きました。
エンカフェ主催で、ハードウェアな人達が集まるイベント、つーかSNSなんですが、ソフトウェアな私はひとまず入っているだけ、なんですが（苦笑）
＜001＞
＜002＞
この手のハードウェア＆材料、秋月電子などでいろいろ通販で買うことができます。私も買いました。
USBの自作ボードを買って、半田付けをしたところまで、、、はできたのですが、その先が続かず。LEDと抵抗がほったらかしになっている私とは違って、出典された方の技術は素晴らしい！
電子工作と組み合わせたいよなぁ、と思いつつ PIC と USBチップ、無線LANチップの資料までは、半年前に揃えたもの、いまだ手付かずという感じですなぁ。頑張らねば。
ピーター・ドラッカー著「マネジメント 基本と原則 エッセンシャル版」を買う。
http://www.amazon.co.jp/dp/4478410232
原題は「managment: tasks, responsibilities, practices」なので「課題、責任、実践」ってことになっています。元のマネジメントの本は分厚いので、そのエッセンスを抜き出したもの、という位置になっています。
先日、ゴールドラット氏の講演を聞きに行って連休中に考えたのですが、どうやら、機能させることと、発想することは別物らしい。当然のことながら、資本主義という枠組みで生産は、消費の対象であり、逆に言えば「消費慾/需要があるから、生産/製造する」ということです。この話は「マネジメント」の本の最初の20頁ぐらいに、ドラッカーが書いています。
組織論や組織内の立場への欲求/心理については、アドラーが詳しく書いています。ユングの言う創造とは違ったところ（あるいは創造ができない人）のための論理のような気もしますが、いわわば、それぞれの「生き方」に対しての拠り所です。絵画/漫画/小説のような「芸術」を目指すのか、あるいは組織の長を目指しそれに価値を見出すのか？いわゆる「出世」というものです。
最近は、もっと他にも
・チームビルディング（コミュニケーション主導）
・ソーシャル活動主導（人のためになる活動、人に喜ばれる活動）
・治世活動（政治屋ではなく、世のためという活動）
当然、支配/被支配を求める人もいれば、拝金主義の方もおり、まぁ、それはそれなりの世の中なのです。私はそれらを許容します。
そんな中で、ふと連休中に考え続けたのが
・自己実現を支える、発想の概念
・生産を支える（形作るということ）の、現実化という概念
かつ
・資本主義社会という範疇での、社会人としての活動
の３つです。最後のは、お金を稼ぐ/糊口をしのぐ、ということです。
これらの３つを組み合わせたとき、初めて「組織」が必要になります。当然、ひとりでやってもいいのですが、そこまで孤独を愛している訳でもないし、それは、まあ、進化とか利己的な遺伝子とかいうものです。
そんな訳で2000年以来、再びピーター・ドラッカーに戻って来ました。正しい「マネジメント」を学び、実践したいがためです。
managements for intelligence and imagination という言葉を考え出しました。
ひとりでやっていると机上の空論になるので、外部に発信して実践していきます。当然「実現」させていきます。
賛同者を募っていきますので、よろしく。
三方良しの公共事業推進国際コンファレンス2009
http://www.sanpouyoshi.jp/index.html
午後は、三方良しのコンファレンスです。
こちらは、CCPMを導入して、国土交通省、建築業界、公共事業の話になります。
工程のスループットを上げるために、
・ワンデーレスポンス 官庁側が１日以内に返事をする。
→ ラピッド開発と同じ。
・ODSC/CCPMの導入。
→ クリティカルチェーン、TOCの応用
# 私の担当分野としては、IT企業、商店街、専門店、零細工場ですね。
# アイデアの出し方、横連携の方法を真似したいところです。
三方良しは、TOCの岸良さんが旗振りをして5年位前からやっているものです。
株式会社ビーイングの CCPM のソフトを使って、官庁と建築業界が一体になって、コスト改善/納期厳守を行っています。
以下は、ノートのメモです。
農業では地道な「改善」が強み。
工程管理、リスク管理が優秀である。
自分達で作る、そして売る。創造する。というのが「日本独自の文化」
→ アメリカ式、漢民族方式の金融業界は日本には向かない。
→ 財部氏、トッテン氏も同じことを言っている。
→ 流通（マージン業界）には向かない。
逆に言えば、農業方式のほうが、日本人相手には説得力があるのでは？
クリエイティブなものは「真似できない」。専門性が高いもの。
トヨタ生産方式、セル生産、カンバン方式。
モチベーション、家族的な組織。
→ 何故、google の社員/役員が辞めて、自分達で会社を作るのか？
トヨタの「自働化」
・品質は工程で作り込む。
→ QCのように、検査を厳しくするだけでは駄目
・異常があったら機械が自分で判断して止まる。
・７つのムダ
１番は、「造りすぎのムダ」
原材料を消費してしまう。製品の在庫が増える。
ＩＴ業界は、
・手待ちのムダ（指示待ち）
・不良品のムダ（仕様が不十分、動かないプログラム）
動かないものをたくさん作ってもムダ。テストを綿密にやらないと駄目ってのはムダ。
管理とは「維持」＋「改善」のこと。
維持は、標準を決めること。初心者ができる標準ではなく、ベテランが作る標準。
標準を厳しくし、改善する。
トヨタでは、昭和36年にTQCを導入し、平成6年にTQMを導入している。
～～～
ここから所感です。
プロセス改善、スループットの向上で利益が上がるのは、生産/流通などの既存の流れのシステムです。なので、工場や小売（スーパー）などにはうまく適合できます。IT業界で言えば、microsoft のソフトウェア・ファクトリの構想もこれに似ています。
ですが、メモにも書いた通り、「創造」の部分は CCPMやJITからは出て来ません。あくまで、効率/能率化になります。
ただし、TOCで使われている思考プロセス（クラウド）は、この創造に使えます。これは、マインドマップや、ペルソナ、KJ法、ペーパープロトタイピングと同じです。何かを発想するための方法なのです。
個人的に、ひとり作業のために CCPM を活用しています。WBS と同様にカードに分割して、バッチ処理を流すのです。このようにすると、進捗率(バッチの流量)が簡単に計算できるために、終了が予測可能になります。当然、進捗が進むごとに終了予測の精度は高まります。
さて、CCPM ですが、これをそのまま適用するとIT業界（管理側ではなく開発者側）では問題が出ます。というのは、先ほどの「創造」の話になるのですが、予備時間を切り詰め、スループットを上げるために、次への学習時間を取られてしまうのです。
これは、生産や建築の現場では業務時間が厳しく決められているのですが、IT業界の場合はなあなあになっています。なので、深夜勤務、残業がほとんどです。ですから、生産現場では余った業務時間外で勉強会を行うことは可能なのですが、IT業界では余った時間は、他の仕事を詰めてしまうことが常です（これは経営的に問題も多いのです）。
なので、ITの現場に、建築で使われるCCPMをそのまま入れることは、問題が多いのです。
ただし、スケジュール管理、目的の共有、という点では、ODSC/CCPM の工程は非常に重要です。これは建築業界におおいに学ぶべきところです。ですが、次へのステップに進むために「学習時間」の確保も重要です。
ここの部分は、現在の私は
・学習曲線
・行動経済学
・システムへのフィードバック
・知識創造企業
を交えて考えています。
しばらく、この手のプロジェクト管理/運営を考えてはいなかったのですが、ぼちぼち再開しようと思います。
エリヤフ・ゴールドラット博士 緊急来日セミナー
http://drc.diamond.co.jp/gold/
に行って来ました。午前中３時間の講演で２万円は高いのか安いのか？は別として、私にとっては、
・ハーバードビジネスレビュー 半年分
・クリスタルボール
付きということで、まあ、生ゴールドラットが見れるからいいかな、と。
ゴールドラット氏の著書「ザ・ゴール」を読んだのは2001年頃です。日本語版が出版した後、社内で流れていたメーリングリストから情報を拾いました。「ザ・ゴール」に書かれていた、思考プロセスの話、そしてクリテカルチェーン（後に「クリテカルチェーン」という本になっています）を利用したプロジェクト管理/プロジェクトバッファの話は、それらを受けた後から、ぽちぽちと web にアップしています。
随分、以前に書いたもののので、視点がプログラマ寄り（従業員寄り）なのですが、あれから会社を辞めて転職し、個人事業主を経て、開業、その後、休業中、という自分の流れの中で、これらの「経営者」や「マネージャ」の視点での、思考プロセス/TOC/CCPMは、非常に役に立っています。
さて、講演内容は紙のノートに書き込んだのですが、どうせなので web 上でもメモという形で残しておきます。
もう少し整理したら mymy or moonmile solutions として整理し直しましょう。
直前に
・ピーター・センゲの「システム思考」
・ビル・トッテンの著書
・実践行動経済学
を読んでいるので、それに絡めた感想も交じっています。
以下は、雑多なメモです。いちおう参照まで
～～
・大野耐一 トヨタ生産方式
・盛田社長 ソニー
・レミング博士
皆「物理学者」であり、科学的に考える。数字で考えることに慣れてる。
よって、行動経済学のナッジに縛られない
・野中教授の「知識創造企業」、スクラムも参照
DELLのカスタマイズ
生産工場 → 運搬/仕入 → 在庫/倉庫 → 販売 → お客
この「お客」から初めて、お金がフィードバックされる。
これが「スループット」になる。
トヨタの車を誰が使うのか？まで考えてた、生産方式/改善を行う。
「低品質から高品質」を目指す。
「高品質」になった後は、何処を目指すのか？
→ トヨタはここで失敗している。
１つ成功したら、次の成功を求め続ける。改善し続ける。
→ ２段階のジャンプが他会社が追い付けない、スピードを生み出せる。
→ ディテール（詳細）にこだわって、「洗練」させてはいけない。
→ ゴールドラット氏的には「フローを高める」という。
社内の調和（ハーモニー）を重視する。
・社員と社長の関係
・サンプライヤーとの関係
・お客と店舗との関係
品切れがお客との調和を乱す？
→ 槇村さとる著「Real Cloths」8巻を読むと分かるが、
お客様の要求から「調達する能力」が重要
→ ワンストップソリューション
→ リッツカールトン
小売の欠品は平均20%程度。では、損失はどのくらいになるのか？
→ 欠品による痛手は、純利益の2倍にのぼる。
→ ただし、欠品が無い状態をシミュレーションすると、
忙しすぎる、対策のために却って在庫が増える、という状態に陥る。
この場合は、再検討する。
戦略/戦術の話
・戦略は「何のために？」
・戦術は「どうやって？」
http://toc.tv を参照
実は、WBSやODBCと同じ。目標管理、フラッグ管理（http://moonmile.net/mymy/）と同じ。
導入する順序が重要。
→ 孫子、老子に置き換えると分かりやすい？
→ 目先を変えて、説明/理解しやすくするといい。
盛んにゴールドラット氏は「論理/ロジックが大切」というが、
これが、イスラエルのロジック感覚なんだと思う。
・軍事技術
・映像解析
・論理で解けるものを対象にする。
・中東の戦争の近い場所なので、物に囚われない、人/頭脳に属するものを重視する。
・cup/インテルの開発場所
半導体というメモリ関係 サムスン電子/エルピーダは、工場生産に属するもの。
・セル生産、スクラム
・チームビルディングの話
ただし、何を目的にするのか？
だから、何のために仕事/ビジネスをするのか？
私の場合は、商店街/地域の場/地元でどれだけ豊かな（精神的に）生活を送れるのか？
心的に苦痛なものは避けたい。
第13回いたばし産業見本市
http://www.itabashi-industryfair.jp/
に行ってきました。3日間の開催なのですが、明日/明後日と都合が悪くて初日のみ。
本当は土曜日のロボット大会に行きたかったのですが、えーと、誰か写真/ビデオをアップしたら教えてください！
IT屋さんなので、こういうハードな祭りには出たことがないのですが、これからはハードもできなくちゃね、ということで行ってきました。
第1の目的は、ロボトマ/関東ロボット連合の岡田氏に会うことです。これは結構あっさり。ロボトマ（だったか？）のサイトにある写真を見て、同じくらいの歳かなぁ、と思っていたのですが、私よりもう少し若そう。若き経営者ってところです（ロボマニアでもあるのかな？）
ロボット関係と動体認識の話を少しさせて頂きました。私としては、店舗のデモンストレーション、デジタルサイネージ、デジタルマネキン、ジェスチャー認識、道路標識認識などなどに絡めて、ロボットで使うセンサ/フィードバックの機構（ジャイロ系）、圧電センサ、組み込みlinuxの情報を求めて、というところです。時間を作って、志村坂上のお店
ロボトマ
http://robotma.com
にも行きますので、そのときには宜しくお願いします。
# 電通大学の方にもよろしく（名前を聞き忘れてしまいました）
第2の目的は、写真を撮りまくって、silverlight のデモに使うことです。
勿論、まわるだけでは面白くないので、いくつかの会社でお話をさせて頂きました。
ハードとソフトの組み合わせで最初に考えられるのが、CAD/CAM、NC旋盤加工です。
3D造形や金属加工に使われます。ええと、ガンダ○の盾を作っている会社もありました（笑）。洒落がっ聞いていていて面白いです。
株式会社スガヌマ
http://www2.odn.ne.jp/aas30940/
店頭ディスプレイ、少量ロットのプレゼントに使えそうです。
そんな訳で、ばしばし撮った写真を今整理中してアップ。
http://moonmile.net/sl/1119/
株式会社SEメディアパートナーズ代表取締役 大林氏の講義でした。
http://www.itabashi-kigyou.jp/seminar_juku.html
http://www.semp.jp/index.html
サラリーマン（証券）から退職後、社長に就任、その後、合併により上場している社長（株主のいる会社の社長）を経験していらっしゃいます。
で、早速ですが聴講した結論としては、
・構想は楽観的に
・計画は悲観的に
・実行は楽観的に
に尽きる、という話でした、、、で、いいんですよね＞大林社長
私はご存じIT業界に勤めているので、主に製造業、時にサービス業なわけですが、私の主体としては「製造業」。製造業、それもプログラミングの世界は「家内制手工業」に近いものがあります。
まぁ、IT業界の場合、怪しいものから/不明なものまで、色々あるわけで、他の業種から見ると怪しいところだらけなんでしょうけど、理系で突っ走ってきている私の場合は、断然「製造/研究」という頭で、プログラミングしています。
なので、逆に言えば、銀行/証券の仕組みのほうが、私にとっては怪しい世界で（笑）、大林氏も話していましたが、証券の世界は「手数料」で成り立っています。株式を売買する、株式を上場する、Ｍ＆Ａをする、という「株」が動くたびに「手数料」が発生し、それが証券会社/社員を養っています。
同様に、銀行も手数料の世界で、ATMの手数料、他銀行への送金の手数料など、お金が動けば「手数料」が発生します。なので、銀行にお金があるだけでは、銀行は儲からないのです。あっちへこっちへお金を動かすことにより、銀行はもうかる仕組みになっています。勿論、お金とは言っても、実際にモノがあるわけではなくて、数値をあっちにやったり、こっちにやったりするだけです。システム屋さんから見ると、「なんでそんなに手数料がかかるの？」（と言ってはいけないような気も）というものなのですが、まぁ、そういう世界です。そうそう、「当座預金」というのをご存じでしょうか？一般人は使わないのですが、小売の世界ではよく使われます。この当座預金は、一般的に使われている普通預金とは違って、利子は付きませんが、手数料が掛かりません。まあ、このあたりのは話は別途、簿記の話ということで。
さて、この「手数料」ですが、所謂、一般に流通という言われう業界では「マージン」とも言います。ゼネコンIT業界でもご多分に洩れず、「マージン」があります。派遣業界、個人事業主の紹介料、孫会社への開発スルーなど、色々なマージンがあります。「営業費用」と言ったりもします。他の言い方として、「管理費」（笑）もあります。「マネージメント費用」（笑）とも言ったりします。
流通、営業、小売、卸問屋の関係は、それぞれがマージンの世界です。本来ならば（？）、製造→顧客の直販によれば、中間マージンが取られませんが、製造場所が遠方であったり、特殊な世界（美術界など）であったり、そもそも製造側が売ることを考えていなかったりすると、中間経路が発生します。商業というのはそういうものです。
日商簿記の場合、商業簿記と工業簿記の２種類に分かれていますが、この商業にあたるのが商業簿記です。商業簿記の場合は、「仕入れ」と「販売」が重要になります。当然、安く仕入れて、高く販売するのが理想的です。これがマージン＝営業利益です。
資金に任せて、大量購入し販売をこなすのが、所謂「商社」です。大量に仕入れることで、購入価格が下げられます。何故下げられるのかというと、サプライチェーンというのがあって、それを勉強すると分かります。
ええと、かなり脱線していますが。
逆に、製造業の場合は、工業簿記を使います。工業簿記では「原価」と「売価」が重要です。原価は直接費用と間接費用がありますが、人件費は直接費用に入ります。間接費用は主にシステムや経理の管理費を示します。
製造業（実は農業も同じ）の場合は、原価と売価の差分が利潤になります。
さて、この２つを見比べると、
・商業の利潤＝販売－仕入
・工業の利潤＝売価－原価
になり、一見似ているように見えますが、実情はかなり違います。
利潤を多くとるためには、販売/売価を上げる、あるいは、仕入/原価を下げるの２つの方法があります。
どちらも高く売れれば良い、というのは共通しています。しかし、この不況下においては「高く」売るのは至難な技です。
なので、いきおい利潤をあげるためには、仕入を下げる、あるいは、原価を下げる。ということになります。
さて、この「仕入を下げる」あるいは「原価を下げる」というのは、具体的に何を示すのかを考えてみましょう。
■仕入を下げる
仕入というのは、できあがった商品を仕入れることです。装飾などはするでしょうが、ほとんど加工はしません。なので、仕入を下げるということは、仕入先の業者に対して支払う金額を下げる、ということになります。つまり、「会社の外へ」の圧力が強まるということです。
■原価を下げる
原価の場合、材料費などもあり、商業で言う仕入に似たところもありますが、工場のように製造工程を含む場合には、人件費を多く含みます。なので、原価を下げるということは、人件費を減らす。つまり、「会社の内へ」の圧力が強まるというとになります。
単純に考えると、圧力の向きの違いになります。圧力＝企業努力という言い方で考えれば、仕入を下げることは外部の会社に企業努力を求め、原価を下げるということは会社の内部で企業努力をする（リストラも含む？）ということです。
さて、どちらが経営者にとって楽なことなのでしょうか？
この答はそれぞれの方が考えて欲しいのですが（私の中での答えは既に出ています）、まあ、会社によって様々でしょう。
そんな訳で、大林氏の話を聞いて私が思ったのはこんなところです。
# 起業塾での話の内容は全く違うんですけどね。
参考文献としては、以下になります。
ゴールドラット著
「クリティカルチェーン」
リチャード・セイラー、キャス・サスティーン著
「実践行動経済学」
ゴールドラット著「クリスタルボール」発売記念、という訳ではないのですが、チェンジ・ザ・ルールの会（でいいのかな？）に行ってきました。というか
鳥一代
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
VB が ASP.NET MVC から強力な後押しを得るかもしれない
http://www.infoq.com/jp/news/2009/02/MVC-VB
ASP.NETディベロッパはASP.NET MVCを習得すべきか？
http://www.infoq.com/jp/news/2009/05/should-devs-learn-aspnetmvc
～～
Web Formsは偽物です。注意をそらせる手品でいっぱいの皿に置かれた詐欺包み偽コードソースの空事です。Web Formsでなにをやってもウェブでなにもできません。ただ自分のためにWeb Formsを使うのです。
～～
なことが書いてあるのですが、「Web Formsは偽物」になってしまった、というのが正しいところです。
そもそも、ASP.NET 1.0 の頃に Webフォームを作った理由は、Windows アプリケーションと同じように Web アプリケーションを作る、というのが発端なのです。当時、vbscript で *.asp を作っていた頃は、ページに html タグと vbscript が混在していました。この書き方は java の *.jsp と同じでしたし、perl のヒアドキュメントと似たものでした。
これの解決策として、microsoft は windows アプリに似た方式で web サイトを作れるように asp.net の webfroms を作り、一方で java は struts やタグライブラリを充実させました。
その後、何故か microsoft は asp.net 関係の啓蒙をやめています。というか、ほっておいたんですね。というのは、iis 6/7 を開発する一方で、ブラウザアプリケーションではなく、click once を使った「スマートアプリケーション」に力を入れてきたわけです。
が、その思惑とは逆に、javascript で web アプリケーションを拡張する方式が広まり始め、google map や google apps が出てくると、microsoft はブラウザアプリケーションを無視できなくなりました。現に、スマートアプリケーションの路線は、消えつつあります。
こうなると、再びブラウザアプリケーションが主流となるため、生き残ってきた MVC が再び注目を浴び始め、lamp 環境での cakephp や java の struts、途中の ruby on rails の MVC スタイルが流行り始めます。これを microsoft が無視できなくなって asp.net mvc をリリースし始めた、というのが、2000年頃からの歴史的な流れで、今から見ると、タグライブラリ風にコントロールが充実した（ステート＝状態を隠した）web forms が「偽物」っぽく見えるわけですね。
ちなみに、私の目からみると、java のタグライブラリ（weblogicなど）や asp.net の web コントロールは、コンポーネント技術に則って、MVC スタイルを維持できる貴重な技術です。
MVCのスタイルでプログラミングをすると、いくつか利点がありますが、大きなものは、
・View が分離されるので、デザイナと分業ができる。
・Model が分離されるので、UnitTest がやりやすい。
ところです。実は web forms を使った場合も view と model が分離されているため、上記のことが可能です。というかですねぇ、そもそも asp.net の web froms は view と model を分離するために、コードビハイドという仕組みを入れたわけだし、それは、ちょうど、「 mv○モデルになっている」とも言えます。
さて、来春に発売予定の Visual Studio 2010 には ASP.NET MVC 2 が最初から導入されています。Visual Studio 2008 の場合は、後から ASP.NET MVC を入れる必要がありましたが、2010 からは、新しいプロジェクトで MVC のプロジェクトを直接作成できます。
＜004＞
これで ASP.NET MVC プロジェクトを作って、サンプルのログイン画面を起動したのが、下の図です。
＜001＞
ちなみに、デザイン時とコードも載せておきます。
＜002＞
＜003＞
ここで、実行時とデザイン時を見比べてください。ログイン用のテキストボックスがデザイン時にありませんよね。これは、view のコード（*.aspx）の中で、下記のように visual basic あるいは c# のコードで、テキストボックスを表示しているからです。
<% using (Html.BeginForm()) { %>
<div>
<fieldset>
<legend>Account Information</legend>
<p>
<label for="username">Username:</label>
<%= Html.TextBox("username") %>
<%= Html.ValidationMessage("username") %>
</p>
<p>
<label for="password">Password:</label>
<%= Html.Password("password") %>
<%= Html.ValidationMessage("password") %>
</p>
<p>
<%= Html.CheckBox("rememberMe") %> <label class="inline" for="rememberMe">Remember me?</label>
</p>
<p>
<input type="submit" value="Log On" />
</p>
</fieldset>
</div>
<% } %>
この記述が良いかどうかの議論は別にしておいて、次に従来の web forms で同じものを記述した例を載せます。
実行結果は、こんな感じ。ASP.NET MVC と変わりませんね。
＜005＞
デザイン時とコードは、こんな感じです。
＜006＞
＜007＞
ASP.NET MVC と見比べると分かるのですが、デザイン時にテキストボックスが表示されています。これは、実行しなくても外観が分かるので、非常に重要です。
また、コードを見るとすぐにわかるのですが、
<asp:Login ID="Login1" runat="server"> </asp:Login>
のところが、ログインのユーザー名、パスワードを指定しているところです。
この asp:Login は java で言うところの「タグライブラリ」で、標準的な html タグをまとめて記述するタグです。これらは実行時に html タグに展開されます。さて、web ページを作成するときに ASP.NET MVC と Web Forms で、どちらが優れているでしょうか？私には、どう考えても Web Forms のほうが優れているようにしか見えません。
従来の asp.net アプリが優れているのは、これらの「テスト済みの豊富なコントロール」があるからです。また、「デザイン時に外観を検査できる」ことです。なので、「Web Formsは偽物」（WebForms is a lie.）というのは、Rob Conerey氏（Microsoft社員）にしては、随分とビックマウスな話だと思うのですが。どうでしょう？
ただし、java を始めとして、他の web 技術が MVC モデルを採用しているのに asp.net だけが web forms で突き進んでいるというのが、これらの問題ですね。おそらく、路線としては、WPF と windows フォームと似たようなところです。microsoft が自社内で、相反する技術を抱え込んで沈んでいくのは、知ったこっちゃないのですが。
私としては web 技術では、こっちのほうが重要だと思いますね。
Web開発者が知っておくべき八つの分離レベル
http://www.infoq.com/jp/articles/eight-isolation-levels
Silverlight on PHP を考えていて、何か良いサンプルはないかと探していたのですが、最近
Deep Zoom
http://msdn.microsoft.com/ja-jp/library/cc645050(VS.95).aspx
http://www.atmarkit.co.jp/fdotnet/special/deepzoom/deepzoom_01.html
http://itpro.nikkeibp.co.jp/article/COLUMN/20080617/308438/
ってのを見つけました。
技術自体は、去年の夏（2008年8月頃）に発表になっていて、当時の Silverlight 2 で
話題になっていたのですが、今のところ鳴かず飛ばず（？）って感じの microsoft の技術です。
と、言うのも、画像をどんどん拡大できる、ってのは面白い技術なんでしょうが、これって、
google map と似たようなもので、だからどうなの？ という気がしないでも無いわけで。
一体、何に使ったらよいのやら、って感じの代物なのです。実際、microsoft の公式サイトやブログでは、
silverlight 3 と deep zoom を絡めた記事はありません。
ですが、ちょっと考えてみるとですね。
Deep Zoom Composer
http://www.microsoft.com/downloads/details.aspx?FamilyID=457b17b7-52bf-4bda-87a3-fa8a4673f8bf&displaylang=en
＜001＞
というものがあって、結構簡単に、画面に写真が配置できます。
で、もう少し話を進めると、この deep zoom は、MultiScaleImage コントロールで扱えます。
MultiScaleImage コントロールは、.NET Framework 3.5 に入っているコントロールです。
そんな訳で、次なるサンプルページを考えてみたわけです。
＜002＞
よく flash や ajax でありますが、ポラロイド風に商品の写真が並べてあるページですね。
重なったところをクリックしたり、下の画像を見たりすることができます。web サイトの定番の画像です。
gif 画像の場合は、固定なので、クリッカブルマップにするしか方法はないのですが、今回は
silverlight and deep zoom で作るので、拡大縮小がスムーズにできます。deep zoom 自体、
マウスホイールに対応してるので（それ用のコードを吐き出すので）、なかなか面白い動きができます。
それで、早速 Deep Zoom Composer をダウンロードして作ってみようと思った訳ですが、
ありゃ、残念ながら Deep Zoom Composer は、斜めの画像に対応していないんですよね～。
縦横に配置することはできるのですが、画像を傾けるのは無理なんです。このあたり、仕様的に無理なのか、
実装的に難しいのか、よくわからないのですが、現状ではできません。
なので、断念、、、しては詰らないので、もう少し考えます。
deep zoom 自体は MultiScaleImage コントロール上で動いているので、普通の xaml のコントロールと
同じようにできます。ですから、MultiScaleImage コントロールの上に、普通に textbox や image（？）
のコントロールを貼り付けても行けるわけです。実際、textblock を重ねると、半透明やらなにやら、回転やら
ができます。なるほど！
そんな訳で、先の完成予想図を元に、サンプルプログラムを作成中です。
このサンプルは、
.NET ラボの11月の勉強会（11/21）
http://dn-lab.net/
http://www.atmarkit.co.jp/event/calendar/detail.php?event_id=25157
http://japan.internet.com/event/
で発表します。
# 「～ 時々 deep zoom」のところのサンプルですね。
# 実は、こっちに力を入れているという。
そんな訳で、ポラロイド風silveright（silverlight polaroid photo）を作る際の難点として、
・deep zoom の座標は、ViewportOrigin, ViewportWidth, AspectRatio を駆使して使う。
http://msdn.microsoft.com/ja-jp/library/system.windows.controls.multiscaleimage.viewportorigin(VS.95).aspx
・マウスのクリックは、ElementToLogicalPoint メソッドで変換（0～1の間になる）
・子画像は、MultiScaleSubImage クラスで扱う
っていう、ちょっと複雑な事情があります。
回転関係が入るので、回転行列にも、お世話になります。
http://imagingsolution.blog107.fc2.com/blog-entry-151.html
そんな訳で、できがったら、ソースコードとか解説とかノウハウとかをアップしていきます。
設計の事始め（その１）
http://www.moonmile.net/blog/?p=427
の続きです。
先のエントリでは図を使ってチェックポイントを洗い出しました。簡単なシステムならばこの程度でいいのですが、二重化を考えたり、多数のクライアントが参加している場合は、もう少し論理的な（数値的な）計算が必要になります。
というわけで、典型的なWEBサイトを例に、４つのチェックポイント（CPU/DISK/MEMORY/NETWORK）を調べていきます。
＜001＞
この図を Excel の表に直します。
＜002＞
いくつかのチェックポイントが増えているのは、表にしたときに考えた直したものです。
図には無かった、HUBやルータが入っています。インターネットを媒介しているので、ネットワーク速度が不明なところがあるのですが、大まかな数値を入れておきます。
これをハードの現状とします。
さて、これに対して要求仕様から「機能外要件」を入れます。機能外要件は、毎分何回の応答数を返すのか、１回につきどの位のデータ量が流れるのか、という要件です。
実は、この機能外はソフトウェア構成が決まらないと、正確に決定できません。たとえば、WEBサイトからダウンロードするデータ量なんてのは、Flashで組んだときと、典型的なHTMLで組んだときとは大きく違います。システムを Flash で組むのか、HTML で組むのかを要件定義の段階で決めることも可能なのですが（大抵は顧客の要望として、どちらかが決められます）、「言語に依存せずにシステム設計を行う」という（わたくし的な）指針に従えば、ここで Flash か HTML かを決めるのは適切ではありません。
ですが、現実問題として、
・どのくらいのサーバーが必要なのか？
・どのくらいのネットワーク容量を必要とするのか？
を決めないと、ハードを購入する手続きが間に合わないことが多いのです。
なので、ここは大雑把にでも決めないと仕方がないことがあります。
また、既存システムを移行する場合は、ネットワークの回線がそのままだったり、サーバーがそのままだったりすることがあります。そのような場合は、「制約」としてハードの現状が決まってきます。
さて、この「制約」としてのハードの現状に合わせて、ソフトの要件が満たせるのかをチェックします。あるいは、その制約を活かした形で、ソフトウェアを設計するための土台を作ります。
＜003＞
この表が、ソフトウェアが要求するハード要件になります。
少し詳しく表を見ていきます。
クライアントのPCは、決して非力ではありません。CPU 2.0GHz でブラウザを使って閲覧する（あるいは、専用のブラウジングソフトをインストールする）場合でも、そんなに小さいものではありません。ですが、考慮しないといけないのは、
・CPUパワーは 10% 以下に抑える
・メモリの使用量は、100MB 以下に抑える。
というところです。また、ネットワーク回線も 100KB/s 程度に抑えたほうがいいでしょう。
これらの上限は、本ソフトが動いている間でも他のソフト（Wordなど）が快適に動く条件を示しています。大抵、これを忘れてしまうので落とさないために表にします。
同様に、クライアントPCの回線は、ADSLルータの速度に縛られることを忘れないでください。
いきおい、重たいFTPなどを行った場合、ADSLルータは 100KB/s を確保できないかもしれません。その場合に備えた、ソフトウェア設計が必要になります。
逆にWEBサーバーのほうは、同時接続数（プロセス数）を計算に入れます。
ここでは100台のPCがアクセスすることを考えます。
そうなるとクライアントPCから100KB/sの要求を受けるので、サーバー側のネットワークは、10MB/sぐらいは必要ってことになります。
WEBサーバーのCPUを早くしたり、MEMORYを積んだとしても、ここのNETWORKが遅ければ、このシステムは成り立たないことが「すぐに」分かりますね。
逆に、10MB/s のネットワークが確保できない場合は、別なソフトウェア設計が必要になります。
・瞬間風速時にはシーケンシャルに100台をこなす。
・瞬間風速時には、50台分はエラーを返す。
最近のチケット販売やオークション受付のシステムは上記のどちらかを取っています。
もうひとつ、忘れてならないのは、
・ネットワークのデータ量を100KB/sから 1KB/sに減らす
という方法です。100分の1に減れば、ボトルネックはnetworkでは無くなりますね。
この方法は、ソフトウェア設計でしか解決できません。
# どう解決するかは、ご自分の頭で、・・・というか、ソフトウェア設計のエントリまで待っててください。
さて、もう少し表を詳細に見ていくと、WEB Server の両方に HUB が入っているのが分かります。
この HUB はネットワーク的に同じものを示しています。
つまり、
ルータ → HUB → WEB Server
↓
DB Server
という構成を想定しているわけです。
そんな訳で、このHUBにも結構な負荷がかかりますね、ってことです。
構成的には、スイッチングHUBを入れるのが普通なのですが、
ルータ → HUB → WEB Server → HUB → DB Server
のように WEB サーバーにネットワークボードを2枚差しにするのもアリですよね。
あるいはルータ直結にして、
ルータ → WEB Server → HUB → DB Server
という構成も考えられます。
これらの発想は、先の図だけでは分かりません。
ここに示した Excel シートのように実際に数値を書かないとボトルネックが分からないものです。
そんな訳で、システム構成/設計はおしまいです。
値段とかネットワークの取り回し、OSライセンスの購入などについては専門のSEにお願いするといいでしょう。
値段については、いくつかのHPやDELLなどのいくつかの購入サイトを押さえておけば、そんなに難しくはありません（って言っていいのか？）。ただし、安い構成、切り替えの可能な構成などを考える場合には、マザーボードの種類やメモリの種類、HDDの種類まで関わってくるので、専門のSEにお願いしたほうがよいでしょう。
というわけで、次回はソフトウェア設計について書く予定です。
