愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
iPhoneアプリ
author:えふしん
photo_20.jpg
藤川真一について


初代モバツイ開発者
想創社再創業 / KMD博士課程
著書〜100万人から教わったウェブサービスの極意―「モバツイ」開発1268日の知恵と視点 [Kindle版]
お求めやすい夏休み特価!
このカテゴリ[会社活動]の最新30件
2013年からのWeb関連ビジネスの方向性と、「100万人から教わったウェブサービスの極意」kindle版 320円キャンペーンのお知らせ 3Dプリンターに対する単純な疑問 会社を辞めるまでの期間、1.5ヶ月以上は会社の甘え エンジニアの評価が4以上にならないワケ 嫌な夢を見た シャープの液晶は成長技術や否や 決断力がある人の弱点 うだうだ書く ブラックという言葉から逃げるな 若い奴が抱く年齢への恐怖なんてどうせわかってないで言ってるから気にするな。 人は見たい現実しか見たくないという問題 プレーヤーとして戦い続けるための意志力 エンジニアの未来サミット 2012 for Studentsで話をしてきました。 Amazonの企業理念「Every day is still Day One」が素晴らしすぎる。 「エンジニアの未来サミット for students 2012」に登壇します。 責任フリーのイノベーション 想創社 version2.0を設立しました。 世界は勝手に変わるのではない、誰かの手で変えているのだ。 Webのベンチャーが目指す先はカンバン オワコンのガイドライン ブラック企業の定義 家入さんのラジオ番組に出演した件と、WebSig1日学校で講師をやる件 技術力、ソフトウエア発想共に最もアップルに近かったシャープ…X1/X68の思い出 Twitter api ver1.1、痛いところ、痛くないところ IMJの上場廃止の文章に思うこと。 フリーエージェント社会の到来は、そのまま企業体の没落を示すわけではない。 ミッション・クリティカルについて考える〜AndroidよりiPhoneの方が好きな理由 社員は本当に経営者視点を持つべきなのか。 三木谷社長のインタビューは終わりの始まりになるのか?! ScanSnap+プリンタを1万円で代替するクラウド対応のインクジェット複合機の話
[このカテゴリをもっと見る]
Powered by
Movable Type

October 25, 2006

スポンサーリンク

スケーラビリティと機能性は不可分。発行するSQL文が増える可能性がある以上、明らかにトレードオフの関係となる。
キレイ事や正論やあるべき論ではなく、実際、これでいいんじゃないかと思うんだがどうだろう、と言う質問。

■Webサービス開発:
キーワード:むしろ冗長でも良い、まずは最適化発想禁止、スケーラビリティは運用しながら調整(計算できないし、サービスの発展にあわせて作るかえるべき)

目的:極論だけど日単位で機能追加が可能であることを最重視

■エンタープライズなサービス開発:
キーワード:冗長は害悪、常に100%の最適化発想、スケーラビリティは社員の数と伸びで計算可能

目的:スケーラビリティは基本的に予測可能として考える。安定性と機能完成度重視なので、あらゆることを固める必要あり。アジャイル発想で、最近はそうでもないかもしれないけど、Webサービスほど発展が不明確ではないと思う。(M&Aして社員が2倍になったら機能統合、再編?)


これ、何が違ってくるかというと、仕様要求に対する柔軟性の違い。(って書いてますね)

サービスの仕様要求は、一日単位で変わることがあります。
毎日、ビジネスの状況が変わることがありうるからです。

ところが後者の発想で考えていると、機能追加、変更時の工数がすごく増えることがあります。

ようするに「こう最適化しちゃったから、できません」と。

そこでビジネスチャンスを逃すのが一番、怖い。

エンタープライズでの半年~1年単位などでの機能追加への柔軟性要求の対処と、Webサービスなどの1日単位での機能追加への柔軟性要求の対処は、結構、考え方が違うんじゃないか?、というのがポイント。


エンタープライズ的な観点で優秀なエンジニアが最初に最適化発想で作ってしまうと、サービスとしての拡張性が下がる可能性がある。

もちろんスケーラビリティなどは維持される方向なので、トレードオフの関係。

じゃぁ、mixiはどうなのよって話があるが、そもそも奇跡みたいな例なので、あそこに照準を合わせることがそもそもお門違いだと思うのと、そもそもそんなことを怖がって小さくまとまったサービスは伸びないと思うので、かるあるべし論って、サービスにとっては結構、怖い考え方だなぁと思ったりしています。

もちろんバランスですけどね。

でも、mixiみたいになったら泣きながら頑張れ・・・で良いと思うし、楽天はスケールに応じてシステム構成をかなり作り直しているという話なので、そこでエンジニアが頑張る余地があるハズですし、それを怖がってたらサービスでは生きていけないんでしょう。

例えば楽天だって、多分、今のシステムからしてみたら最初のシステムはめちゃくちゃだったハズです。みんなそこから泣きながら成長してきるのであって、今の楽天のかくあるべしのようなものを、成長途上のサービスに適用したら、完全にオーバースペックになってしまいます。


以前、はてなのnaoyaさんが、ハードを追加するだけでスケーラブルになるなら簡単で、実際はそんなことなく、拡張したいときに拡張できるように作っておくことが重要なんだと的な技術論がありましたが、そこのコンテキストにおいては、

「機能は日単位で柔軟に追加できる前提」

ってのが、暗黙のように存在しているハズです。そこが満たされていないサービスは、そもそも違うと思うところであります。

当たり前だと思う人には当たり前かもしれないけど、企業システムを前提とした最適化発想を是として教育されてきた人の中には、あまり意識されてないケースもあると思うのですが、どうなんでしょうか?


※1:かと言って、スケーラビリティが破綻するのは論外なので、それは一応。それはF-1レーサーがクラッシュするのと同じなので、悪しからず。
※2:そういう意味では、厳密な要求仕様とは、「日々のビジネス変化に対応する設計をすること」ということのような気がする。ここを仕様がいい加減だ!とビジネスにコミットできないエンジニアだと結構、サービスでは辛い思いをすると思う。
※3:まだ曖昧だけどゴールとしての上場モデルってのが頭にある。要はキャズムを超えるまでには、固めなきゃいけない場所ってのはかなり大きくなってると思うのは今のmixiを見てて思うこと。そこまでには不安要素は全部取り除いてスケールするようにしておくのがゴールではないかと。

スポンサーリンク
■同じカテゴリ[会社活動]のエントリー
<<前の記事 dt = 0 , リスク = ∞の不安な人
>>次の記事 犬に学ぶモチベーションマネジメント10か条
■このblogの書き込み最新3件
本ブログは移転しました インターネットの遊び方を身につけよう トトロが陽なら、『風立ちぬ』は陰?〜『風立ちぬ』の感想