| STATE |  |
ENTRY | <<new | 1 / 22pages | old>> |
|
[Business]リスクコントロール
ビジネスとは結局「お金」の前では平等である。
モノ／サービスを提供して対価をもらうことである。 ここで「リスク」とは何かを考えよう。リスクとは不確実性。M&Aのときのデュージェリとかで数値化するときは、分散（平均と変動値の差の2乗）で表されることからもわかる。つまりお金をもらえるかどうかの不確実性のことです。いくつかあります。 ・モノ／サービスに対して対価を認めてもらえないとき ・モノ／サービスに対して対価を認めてもらっても支払ってもらえないとき ちなみに、大企業にしか勤めたことの無い人は分からないでしょうが、後者は本当にある話です。 まぁ、それはおいておいて、前者が所謂よく言われるリスクであり、我等が業界もそのために色々とがんばっていることでしょう。その頑張っている間はキャッシュアウトしかありません。キャッシュアウトしておきながら、上記リスクが顕在化してお金が入ってこなかったら、キャッシュはショートしたままです。ショートした状態で、他に支払うことが出来なくなってしまったら倒産です。 だからこそリスクをヘッジをする必要がある。 保険とかもそういうアナロジですね。最近なら為替ヘッジだとか、石油価格のヘッジだとか。 我等が業界で有名なのが、「一括」やら「委任」やら。書くまでもないと思うが。 ・一括…やれる部分をコミットしてその成果に対して一括で報酬を受け取る契約形態 ・委任…働いた部分だけ報酬を受け取る契約形態 前者は自由に出来る分、頑張って推敲しなければ食いっぱぐれる可能性があり、リスクが高い。つまり、自身でリスクをコントロールできる必要があるということ。後者は頑張っていれば食いっぱぐれることはない。だめなら翌月別の働き口を見つけるだけだ。つまり、リスクのコントロールは仕事を出す側になる。 当然ビジネスはリスクをどうコントロールできるか？契約の甲乙でどれだけリスクを平準化できるか？がキーになるので、仕事を出す側は委任をできるだけ避けたい。そして、デカくなればなるほど、リスク管理はシビアに管理しないといけない。 さて、そんな状況下ということを意識すると、次の問いにはどう考えるか？ ・何故膨大なドキュメントを書くのか？ ・何故不確かな仕様でもFIXさせるのか？ もっと言えば、 ・何故OSSは今頃日の目を浴びたのか？ 2000年ごろから機能的にはそこそこApache, PHP, MySQLって使えました。まぁPHP4のはじめは変数の頭数バイトがどっかにいくなんていう有り得んバグもあったが（笑）。 一括でやってもらえますか？ それとも、ビジネスモデルかえますか？ 案外ぜーんぶ委任でいったりしたらどうなんだろうか？ｗ あぁ、スーツっぽいことを書いてしまった。。 そろそろ技術ネタいっとくか。。 |
|
|
[Business]一連の話への結論
とりあえず、一連のゼネネタやスーツ論とかに対する自分の結論は、一応おぼろげながら持ってます。
簡単に言えば、ビジネス構造を変えたければ、カネの流れを変えないといけないのです。カネの流れを変えるということは、単純に言うと、貸借対照表ベースの考えか？損益計算書ベースの考えか？システムはコストか？投資か？ということです。 一方、米国をはじめとする先進国にSIerはあるか？ これが違いである。 とはいえ、ゼネコン含む既存ビジネスを打破する一番の障壁は、商習慣なのです。これは綺麗事だけでは破れない。要は、人月なりは綺麗事では破れないのです。商習慣は文化です。 私はこれへのアプローチの仮説は、「システムの対価は株式で」です。 かなり極論は入ってますが、先にエントリした、 ・経営に何がしかの責任をもつ立場で参加すること、 ・システムのパフォーマンス（"速さ"という意味ではない）に基づいたプライシング（というか評価）モデル を実現するにはこれが一番フィットすると思うのです。 （誤解しないように書いておくと、原価計算は人月で良いと思ってます。） で、妄想を打破するために、いちお、6月までに仕込みを入れてます。 えらそうなことは、やってから言います。 言わなければ、失敗したんだな、と優しく見守ってやって下さい（笑） |
|
|
[Business]ゼネコンを知る
ゼネコンをつぶす前に、とりあえず敵の情報を整理していこうかと。
SIという「世界」の中心で愛を叫んでみる。"ビジネス現場"で居て思うこと。 何を隠そう、私もあるプロジェクトの上流からしてますが、PG達がやる前に先行してTeedaのソースをみたりしてアーキテクチャのウラをとったりしています。 しかしながら、物理的にそういうのに時間を割くことがきつくなってきてます。 なぜなら、 �．轡好謄爐竜�模がでかい そういうものなんだから、これは仕方が無い。当然フェーズ分けをしているのだが、システム全体のアーキテクチャを考えるには、一部機能だけを考えるわけにはいかない。なので、最終ゴールのシステムがでかけりゃ、仕方が無い。 �△任�いと人が要る 物理的に独りじゃやりきれない。だからといって、少数精鋭&アジャイルでやる為に期間を長くとりますか？すると、サービスインを伸ばしますか？投資予算はどうしますか？減価償却計画、しいては、財務戦略はどうしますか？減価償却はキャッシュフロー計算書にもインパクト及ぼします。しかし、我々は"ビジネス"をやってるんです。債務を履行し、人に給料を払わないとイケナイのです。だから、期間は伸ばせないよね？じゃぁ、誰かに手伝ってもらうしかない。 ��人が多いと品質が一定しない やっぱり人間は一人一人がオンリーワンなんです。だから、やってることがばらつく。製造業のようにセル型生産方式というが、それはトヨタ式のロジックがシステム開発に合わない部分があるのと一緒で、最終製品が決まっているから守るべき品質もはじめから決まっている。しかし、システム開発においてははじめから分からない。つくってから気付くことが多々ある。そして修正する。いくらできるだけ早くに動くものを各自要件定義から開発までやったとしても、個々の品質は上がるかもしれないが、バラツキは収まるとは限らない。バラツくと何が辛いかと言うと、メンテコストがかかる。その作った人が5年くらいずーっとメンテしてくれるなら良いが。もしくは、バラツかないように最初はちょっとづつやりますか？それは�△里箸海蹐粘�間延長ができないという結論が付いている。 �い世�ら管理するしかない すると平仄をとらなければならない。あるいは経験があるなら、最初からそのルールで縛りを入れなければいけない。できるだけ楽をできるように作戦を考えなければいけない。つまりは管理しなければならない。 以上、見事いっぱしのスーツ族の完成です。しかし、このようにスーツ族の登場は必然なのです。現状自分はこの�い膨礁未掘∨粗�で言ったようにコードとかに触れることがひじょーに少なくなってきて寂しい限り そして、この� 銑い離襦璽廚�結果的にゼネコンを形作るのだと思います。 そうなると、ここで変えれるのは、�，隆覯茲修里發里鬚劼辰�り返すこと。 しかし、一介の業者(SIer)でこれを実現するのはかなり困難。 それを実現するにはこれぐらい必要になってくるんじゃないかなぁ。 ・経営に何がしかの責任をもつ立場で参加すること、 ・システムのパフォーマンス（"速さ"という意味ではない）に基づいたプライシング（というか評価）モデル |
|
|
[Business]Deep Integrationか？
いったい来週何がおこるのでしょうか？
とりあえず、関係者の状況として、 SalesForce ・最近流行のSaaSだし！（意味不明ｗ） ・ZohoがSalesForceとは顧客ドメインが異なる（Zohoは小規模狙い）も、今後イノベーションのジレンマのケーススタディにされそうな状況になる恐れアリ。 ・Force.comとかをはじめたし、アプリプラットフォームとしての覇権をもっと増やしたいところ。 ・最近人材流出が甚だしく、広告収入とかも連続減速中（だからビジネスソリューションにもって行きたい？）。 ・Google Office系はZohoにしてやられ放題。 ・OfficeやらBigTableとかのユーティリティモデルの整備と並行して、GoogleのGoogle App Engineのリリースによるアプリプラットフォームの整備という、挟み討ちを計画中。 競合 ・領収書作り、HRM系、PrtMgmtアプリやらで、Zohoが最近相当頑張っている 文字通りGoogleとSalesForceがDeep Integrationをすれば。。？ "Deep Integration" Between Google Apps and Salesforce to Be Announced Next Monday, TechCrunch http://www.techcrunch.com/2008/04/07/rumor-salesforce-to-resell-google-apps/ |
|
|
[Business]縛り
本当なら伸び伸びとやってもらいたい。
クリエイティビティを大いに発揮してもらいたい。 しかし、うちらはプロなんです。 お客から見たら、「コードを書く」プロではなくて、「システムを作り上げる」プロである。 あなたは、コードを書くPGですか？ それとも、システムを作り上げるPGですか？ コードを書くことだけが、システムを作り上げることか？ お金は誰が出すのか？ これが現場。これがライン。スタッフなら違う。 コードを書くだけなのなら単価は下がる。 本当なら縛りなんてかけたくないんです。 だけど、上記目的を達成するためなら、縛りをかけるという手段を私は選ぶ。 ただし、それは売買が成立する間柄での話。 上記で「これがライン」と書いたのはこれのヒント。 つまりは既存SIビジネスモデルでの話。 一方でこれも何とかしていきたい。 |
|
|
[Break]乗り越えられるか？
ソニーの「イノベーションのジレンマ」について一言, Life is Beautiful
先のエントリの続きじゃないですが、この示唆深い書き込みを読んで2つのことを感じた。 ・スーツはギークを理解しなければいけない いや、むしろ「理解する」という上から目線な段階で、すでに理解できていないというか、交わることはないのかな、と。というか「ギーク」という言葉自体ナンセンスな気がする。 このギークが、誰からお金をもらっているとかそういう社への帰属意識が皆無というどうしようもない状態なら、それは相手にする必要ないんじゃないかな。"The Art of Innovation"のIDEOとかだって、それなりにまず最初に人をセレクションしてるし。その上で、スーツは「ギーク」を理解する必要がある。 この業界、「俺、技術はわかんないから。俺は、ビジネスだから。」という人が多いですが、私はそれに対して、それはビジネスじゃない、単なるセールスだ、と考える。ビジネスはセールス以外にも色々とあります。じゃぁ、マーケティングはどうするの？コトラー先生流に言えば、4Pなんていうが、じゃぁ技術分からなくてProductはどうするの？Productの売りは技術なんでは？あるいは、Priceはどうするの？上澄回収戦略で価格をはじくなら、バリューチェーン意識しないといけないよ？あるいは御社は全て市場浸透戦略ですか？おぉ、実に恐ろしい。 ・もの作り魂 デバイスがデジタル化し、ソフトウェアの重要性が増したとは言え、彼らのＤＮＡにはアナログ時代からの「設計技術・実装技術・製造技術で勝負」というエンジニア魂が脈々と流れている。（中略） アップルは「CPU、メモリなどのハードウェア部品は外部から調達。実装・製造はそれが得意な台湾、または中国の会社にアウトソース」というはっきりとした割り切りとともに、ソフトウェア＋サービスで徹底的な「おもてなし」を提供することにより差別化をはかってここまでの成功を収めたとあるが、予想以上にソニー・アップルの違いは大きい。理論上言えば、単にそうやって「もの作り」にこだわらず高付加価値な頭脳勝負へと持って行けよといわれそうだが、これは簡単に切りかえれないと思う。自社（若しくは、自分さえも）を見ていてもしみじみ思う。合言葉は、「やっぱみんな"作り"たいんだよねー」と。とはいえ、「日本はそういうのは苦手だから。。」ですますのはちょっと悔しい。自分は解はまだ持っていないが、いずれチャレンジしたい。 |
|
![Apple iTunes Music プリペイドカード 5,000円 [MA164J/A]](http://images-jp.amazon.com/images/P/B000ALF5H2.09.MZZZZZZZ.jpg)