Archive for the ‘制約理論(TOC)’ Category
2010/2/27
今日は、クラウドの構成、事例を聞いてきた。
そこで、あれ、ちょっと待てよ、「そもそもクラウドになったらロードバランサーって必要か？」
ということを思った。
っていうか、必要になるようにしか構成を結局組めないのか？というのが本音だ。
ただ、WEBのコンテンツを提供しているようなメディアは除外していただきたい。
対象は、いわゆるSIerにハード構築を依頼するようなレベルの話だ。
（ただ、自社ですべてやっている場合なら、必要であれば、自分たちでロードバランサーもどきなんて作ってしまえとも思ったりもする。それで充分なのだから。）
あくまでもこれからの前提は私が見てきたサーバ構成ですが、たいていはネットワーク構成の教科書にあるような構成なので、
多くのケースが当てはまるのではと思う。
さて本題にもどり、なぜ私たちのサービスにはロードバランサーが必要なのだろうか？
冗長性を・・・・２重化を・・・・
と、こんな感じの答えが聞こえやしないだろうか？
じゃ、クラウドでハードが壊れることをあまり考慮しなくても？やっぱり？いる？
ロードバランサーがあれば、高負荷にも耐えられるじゃないか？
でも、じゃ、高負荷でボトルネックになるDBは、それ以上にロードバランスができるようなDB設計になってるの？
っていうか、DBは１つしかないですよ。
あっても、故障時に切り替えられるようになっているだけじゃないですか。
（わたしは、サービスをやるときにはテーブルを移動できるようにするため、基本的にリレーションははらないが・・・・、
昔、遊びで、１つのシステムのコンテンツのDBがDB2と、MySQLとPostgreSQLに分割してって遊んだことがあるなー。
いや、遊びといってもテストですよ。テスト。）
じゃ、WEBも故障時に切り替えられればいいんじゃないの？そのレベルでいいのでは？
これは思えば、「TOC：チェンジ・ザ・ルール」で言っていたケースだ。
クラウドにより制約がなくなった。もしくは、無視してもいいようになってきた。
にも関わらず、相変わらず、構成は昔のままなので、その対策であったポリシー自体が今度はボトルネックになってしまうのだ。
（というか、個人的には、ロードバランサがあり、また、WEBの多段層化のおかげで、
その後工程でとまどっているにも関わらず、次から次へとリクエストを受け付けて中間層でパンクしてどうにもならない。というケースをよく見た。
まあ、要するにアプリがバグっているのだが・・・ApacheやDBにほぼバグは発生しないことを考えればしょうがないが・・・
ただ、だったら、WEBでリクエストを絞って受け付けないほうがまだ顧客のためだ！という思いもある・・・）
私の今のクラウドの理解が正しければの話ですが・・・・・
いやー、このあたりが本当かどうかを実際にためしてみたいものですが・・・・
Posted in 
2010/2/11
さて、年末によんだ、「ザ・ゴール」と「ザ・ゴール２」がなかなかおもしろかったので、
今回は、その第３弾の話だ。
たしかに、この「制約理論」は面白い。
「チェンジ・ザ・ルール」、「ルールを変えろ」とは・・・あまりにも、正論すぎやしないだろうか？
今まで、この手の本といえば「信じれば変われる！」とか「あなたが変われば、周りが変わる」とか、とにかく、宗教じみた論調で読者を説得しようとしていたと思うが、この「制約理論」は、こういう問題を真っ向から、「理論」「理屈」として取り組もうとしているところが面白い。
今回は、舞台がERPのソフトウェア会社ということで、ソフトウェアを携わる人間としては、非常に親近感がもてて読めた。
そのためなのか、３冊目という事だからか、「ザ・ゴール」・「ザ・ゴール２」を読んでいて感じた違和感がなく、「おっ、始まったな」という感じで読めた。
ストーリーの概要は、amazonの「商品の説明」を読めばわかる事なので、ここでは記述しないが私が持っていたいくつかの疑問や、感じていた事が少しわかってきた気がした。
ちょっと話はそれるが、自分がいつも気にしているのはこういうことだ。と周りに話してきたことがある。
ある娘と、お母さんがクリスマスにだす七面鳥を調理していた。そこで、お母さんは七面鳥を半分に切って、２回に分けてオーブンに入れて調理をしていた。そこで、娘は疑問に思ってお母さんに聞いてみた。「なぜ、七面鳥を半分づつにして焼くの？」
お母さんは「昔からそうやっていたのよ。なぜかしらね。きっとそっちのほうがおいしくなるんじゃないかな？おばあちゃんに聞いてみたら？」
そこで、おばあちゃんに娘は聞いてみるとこう答えた。
「昔はオーブンが小さくてね。半分にしないと入らなかったのよ。」
と。。。。
この話をどこでいつ読んだのか忘れたが、確か学生の頃かもしれない。
でも、働き出して、特に「製品」という枠組みの中でソフトウェアを作りだすと、このようなことを疑問に思うことが非常に大切だと思ってきた。
だが、なぜそれが大切なのか？きちんと説明してくれ。と言われたら言えない。
また、もうひとつ、「製品」を作れる会社と作れない会社がある。
技術的にそれほど違いがない。ただ、作れる会社では「カスタマイズ」をやたらめったらしない。
それが、どうしてできるのか？もしくはそれがどうしてできないのか？
（まあ、私も、営業・周りのエンジニアと戦った。なぜ、できることをやってくれないんだ！協力してくれない！と何度クレームを言われたことか。）
私の中では「やらない」という制約がある中で、考えたほうがよりいい考えができるという程度しか認識がなかった。（人は制限という中から新しい発見をしてきたのだから・・・）
でも、この本を読んでもうちょっと、「理論的に納得がいく」形で理解ができた。
まず１つめは、この本の中ではこんなセリフがあった。（ちょっとかいつまんで・・・）
「新しいテクノロジーを導入するという事は、そこまでそこに限界があったという事を意味する。その限界と長い間、共存してきて、それに合わせて習慣・評価尺度・ルールなどを作ってきた。
そして、新しいテクノロジーを導入して、限界が軽減された。そうすると、それまでの習慣・ルールが今度は限界を課すことになる。」
なーるほど。これは確かに。
つまり、先ほどの七面鳥でいえば、「大きさ」という限界があったが、大きなオーブンにして限界を取り除いていたのに、それを習慣として受け入れたお母さんの考え方自体が制限を生み、結局、オーブンを大きくしても、小さくしても変わりない。
それどころか、「システムの良い提案は、システムにしないこと」などと比喩されるように、この制限をそのまま考えていたら、大きなオーブンのために余計に電気（お金）がかかってしまう。
つまり、システムで制約が限界であったとき、それを取り除いたら、取り除いたようにルールを変更しなければ、限界を取り除く前より、価値（パフォーマンス）が下がるときがある。という事だ。
２つめ。ここの本の会社は、TOCを利用し大成功をおさめた。そして、他の会社が内情を知っても他社は真似できないだろうとこういうのだ。それは・・・
「たとえ我々のプログラムの中身を彼らにコピーさせたとしてもすぐにあれも、これもと機能を追加し始めるに違いない。現場での使い勝手など一切無視だ。」
エンジニアとして技術がついてくるとつい、顧客の言ったことに反応しあれこれと答えてあげてしまう。つまり、カスタマイズしてしまうのだ。
これは、実際に売っているほうとしても顧客が言ったことが、すぐに回答できて気持がいいことだろう。
しかし、先ほど言ったように、「限界をなくす」＝「ルールを変える」が必要になってしまう。
じゃないと、技術で成功しても、顧客に成功はない。
これができるのは、私が考えられるのは２つ。
そして、この本でもほぼ同じことを言っていると思う。
１）そのルールや習慣が変えられるほどの衝撃的なテクノロジーの進歩を伴ったツール。
最近ではインターネットなどはその典型的な例だろう。
したがって、その進歩に乗っかっていけば、ある程度は「ルール」などといった面倒なこととは表面上は付き合わなくて済む。それに、派手でカッコ良くもあるので、見栄えもいい。
２）自らルールを変えるための手法と論理を持ち合わせ、そのために自己改革ができる組織。
つまり、このTOCを実行できるとなるわけだ。（まあ、そのために書いた本なのだから当たり前なのだが・・・）
ただ、テクノロジーが、あまりにも人の理解を超えて進みつつある。
そして、限界になっていない限界を破ろうとやっきになっている感もある。
今のIT企業は（１）を目指して頑張っているのかもしれないが、この不況になってみて成功している会社は（２）の会社ばっかりという気がしてくる。
じゃ、どうして、「簡単ですぐできること」がみんなできないのか？
「単純」＝「簡単」＝「楽」
「複雑」＝「難解」＝「たいへん」
という呪縛や思い込みから人は逃れられないからじゃないだろうか？
人間にとって一番いやなことは、「苦痛」や「苦労」ではなく、「自己否定」を伴う行動が一番いやらしい。
「複雑」で「難解」そうな問題がシンプルかつ楽に解決できたら、それは今までの自分が「無能」であることや、やってきたことが「無駄」であることを認めなければいけなくなる。
こんな、自己否定は誰だっていやだ。
2010/1/29
最近、The GOALを読んでからちょっとだけ、TOCを勉強してみようかなと思いかじっているうちに、ITプロジェクトの管理に関しては本格的に勉強する価値があるのではないか？という気がしてきた。つまり、自分で経験的に知っているというレベルから、人に説明するうえで体系的な知識として使えるのでは？という意味です。
現場でITプロジェクト管理をやっていると、まず、政治的関係者は、PMBOKなどの言葉や、また、工学的な理論などよりも、マーケティングやら販売手法やらを考えている人たちの言葉に近いほうを形式的に学んだほうがいいような気がする。
というのも、PMBOKなどをかじる機会があったが、あまりに規模がでかすぎるという気がした。
何々、何々をするべき・・・
ってあるが、ITプロジェクトでは数百万から2,3千万程度の案件では、実際の実働部隊は二人くらいで、それ以外すべて管理者なんてことだってあり得る。ほとんどは、管理者の管理に翻弄され、実動する人たちに何も伝えられないって場合があるのではないだろうか？
で、実際には、実動する二人が勝手につくってしまってある程度できてから、やっとまともな話ができる状態になる。
そんなのが普通というときに、だいそれた「PMBOK」やら高度情報処理試験での「プロジェクトマネージャ」の理屈・知識は本当に通用するのだろうか？
あまりに、正論すぎる気がする。
（知らないより、知っていたほうがいいのはよくわかるし、それに、よく理解していれば使えるのもよくわかる。でも、小さい（予算が少ない）案件ほど、かなりの変則的応用を求められると思うので、小さい案件で基本を学び、徐々におおきくってプロジェクト管理の手法の学習としては無理があるのではないだろうか？関係者の調整力を学んでいくっては有効だが・・・
それに、学問が正論じゃなきゃ意味がないだろ！っていう気もする。）
それよりも、ほとんどうまくいかなく、問題と間違いだらけという前提から始めることができる「制約理論」ってのは、かなり現実にフィットしている気がする。
たとえば、「スケジュールというのを意思として決める」というより、制約として上から落ちてくるってのが普通だと思うし、使う技術・環境なんかも、選択するっていうよりも、今いるメンバーやハードで何が、どこまでできるか？っていう制約って考えるということになる。
たとえば、何かを変更したときに、カッコよく言えば「変更管理」っていうが、要は間違いに気付いただけだったりする。しかし、それを知る手法がわからないとか・・・
それに、たいてい失敗しているプロジェクトをみると、崇高な感じのドキュメントやら、過剰に投資した環境が多々見られる。なんでこんなになってるんだー。ってみると、コンサルタントなどを通して形式的には正しい方法をとっていたり・・・
という意味では、こんな時代に必要なのは、「失敗しないためのプロジェクト管理」ではなく、失敗の中から「成功させる」を生み出す理論のほうが大切なのではないだろうか？
そう考えれば、人は自由な選択と意思から計画的に生み出すものよりも、多々ある制約から生み出すものの方がよりいいものが生まれると思ってしまうのは私だけだろうか？
私も過去、自分がある制約からやりたいことができず、んー「まあ、これで今のところはいいか！？時間があるときにきちんと作りなおそう」と言って割り切って機能を実装したものが、ほかの会社ではその機能をみて、どうやってそれを実装しようかと試行錯誤していたということを聞いた。
それは、まさに制約から偶然生まれた「そういう事」だったのかも知れない。
次回は、「制約理論」と「サーバ管理」の関係を書いてみたと思う。
2010/1/15
本の紹介:「ザ・ゴール１・２（企業の究極の目的とは何か・思考プロセス）」
年末年始に、上記本を読んでみました。といっても、３日ぐらいでこたつにはいって読み切りました。
まあ、年末年始くらいはあまり読みそうにない本をあえて選んでみることにし、
以前、本屋でたくさんならんでいたのを思い出し、これらの本を読んでみることにしました。
ストーリーとか、内容とかは他のサイトでも、Amazonでの批評などでもわかると思いますので、
ここは、あるいちIT技術者として読んだ時の感想とでも述べたいと思います。
まず、１のほうの内容（理論）はまあ、考え方が体系化されて説明されてはいますが、
普段、このような思考をめぐらせて仕事をやっているので、それほど新鮮味は感じませんでした。
それと、舞台が製造業なのでちょっと、違和感があるといえなくもありません。
しかし、１の話がわからないと２の話につながらないので、さらっと読んだほうがいいというレベルでした。
２では、製造プロセスの改善というストーリーから、思考プロセスの改善という方向へすすんでいきます。
したがって、より広い範囲で適用可能ということで、内容も具体的なことから抽象的な話へすすんでいきます。
この２も技術者として読んでいくとそれほど新鮮味もないのですが、
これが「マネジメント」「マーケティング」という分野に向けても書かれている内容なのです。
しかも、これがそれらの分野の人たちには「新鮮」というじゃありませんか！
もちろん、理論自体が新しいということではなく、現在の人がその発想を知るということが新鮮という意味です。
ですから、本屋さんの目立つ棚にあったわけです。
でも、先ほど言ったように、考え方（思考の癖とプロセス）はもともと、
科学者などがやってきたアプローチをもとにしているのですから、
それは、技術者である私がなじみやすいと思ったのもうなずけると思います。
その証拠に、たとえば「アルゴリズムを作るための思考プロセス」、「システムのボトルネックを見つける思考プロセス」
なんてような本が技術書の棚で目立つようなところにあることはないと思います。
「プロセス」自体の説明はありますが、プロセスを作るためのプロセスまで説明はたいていしません。
したがって、技術者たちはこのような思考プロセスをすでにもっていることを前提に、
ほとんどの本が記述されているだとおもいます。
ようは、私がこれらの本をよんでちょっと新鮮に思ったのは、
１．「マネジメント」「マーケティング」に関しての思考プロセスはすでに技術者のほうが理解できている。
２．コンサルタントや経営者・管理者などと、「思考プロセス」がことなるからわかりあえないなんてことはない。
ということです。
でも、実際、管理職や経営者から理論的思考に基づいた話を聞くのはまれなのです・・・・
（だから、コンサルタントからこのような理論をまとめてもらう必要がでているのでしょうが・・・）
これは、「思考プロセス（という文字）」が「理系」だからではないでしょうか？
なぜか、日本人（以外はしりませんが・・・）は、事を「理系」か「文系」かに分ける人が多くいます。
そして、このように分ける人は、「理系」と「文系」はお互い侵食しあわないようにしている風潮があります。
したがって、「文系」と自負する人間はこの「理系」な異物を拒否するのではないでしょうか？
同様に自分が「理系」と自負する人間も「マーケティング・経営（政治）」とかの「文系」な異物を拒否するのでしょう。
このような考え方を持っている方が広く人の上にたってもらうには、
中高時の「理系」「文系」という人の２極化による分離をやめれるようにすればいいのかなと思いました。
私も高校なんかの時には、「文系」と言われることはまったく勉強しなくてもいいとおもったほどですし・・・
ようは大学入試至上主義から来ているのかなーと思った次第です。
せめて、「文学系」、「芸術系」、「工学系」、「理学系」・・・なんて別れていて、
２つぐらい選ぶようになっていれば、もうちょっとましになったかなーなんて、思ったお正月でした。
