スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
プログラマ35歳定年説、定年後の未来 - GoTheDistance
株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは｢1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう｣ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、｢ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える｣という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理
小規模Webサービス向け安上がりシステム構成と開発フロー（怖話.jp） - Fjord, Inc(株式会社フィヨルド)
こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp（kowabana.jp）のシステム構成や開発方法についても公開していこうと思います。 怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。 怖話.jpとは スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト（アプリではありません）です。詳しくは下記エントリーを参照してください。 スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC（合同会社フィヨルド） 7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは１ヶ月経ってないまだまだのサイトです。開発期間は約１ヶ月ぐらいです。 サイト情報 （これAnalyticsを直接貼るのはどうやればいいんだろう？） 直近一ヶ
「1000人の凡人が一人の天才に負けるエンジニアリング」ではなく「凡人1000人で本当に良いプロダクトを作るエンジニアリング」を指向したい - FutureInsight.info
非常に刺激的な記事。 http://engineer.typemag.jp/elife/2011/04/post.php 僕のチームラボ社長猪子寿之氏好きは昔からで、出演する番組やUSTは大体チェックしてるし、昔書いた以下のエントリーをきっかけに一度お話させて頂く機会もあった。 チームラボの猪子社長の常人のものではないアカギ的発想について - FutureInsight.info 今回の対談も非常に面白く読んだのだが、最近よくわからなくなってきたのは、小飼弾氏が述べている「1000人の凡人が一人の天才に負けるエンジニアリング」という言葉。というのも、昔は僕もエンジニアリングは一人の天才で全部ひっくり返される可能性があるなー、と漠然と感じていたが、最近はそれって違うんじゃないかと思っている。 一人のエンジニアが全てをひっくり返すにはレバレッジが必要 特にここでシリコンバレー賛美を始めるつもり
次世代Web構築ワークフロー概要
CMSに関連する部分が変わる 今回は、次世代ワークフローを具体的に説明していきます。 まず、キノトロープがこれまでに使用してきたワークフローを以下に示します。 Phase0 与件策定 オファー内容を確認し、成果の実現がお約束できるか、何をどうするべきかをご提示します。 Phase1 戦略策定/成功予測 調査に基づいてユーザーニーズを洗い出し、何をすれば、どのような成果を出せるか、ビジネス戦略を立案します。 Phase2 戦術策定 ユーザーの満足を獲得し、成果を実現するための具体的な戦術プランおよび詳細要件を確定します。 Phase3 設計(運用設計) Webサイト構造の詳細設計、ページ設計、ビジュアルデザインなど、全ての仕様を確定します。 Phase4 制作/開発 Webサイトの開発(デザイン、システム)およびテストを行い、最終確認後、公開または納品を行います。 Phase5 更新/運用
日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指して
Twitterでフォローさせていただいている@chok12jaさんのつぶやき がきっかけで、外国人の視点から日本のSI業界の問題について分析した面白い英文の記事を見つけました。 How the Japanese IT Industry Destroys Talent | Japan -- Business People Technology | www.japaninc.com [ThinkIT] 第2回：なぜ日本のIT業界ではスーパーSEを育てられないのか (1/4)（New 日本語訳が見つかりました。） 2007年に書かれた記事なのでもう４年も前に書かれたものですが、日頃から私が感じてきた業界の問題点について鋭く批評を加えており、非常に共感する内容が書かれていました。本ブログの主な読者の方々にとっても興味深い内容だと思いますので、ここで簡単に内容について紹介させていただきたいと思います
Google.orgに見る、Larry PageとGoogle流への疑問 | FERMAT
Google.orgに見る、Larry PageとGoogle流への疑問 January 31, 2011 op-ed / commentary authorjunichi ikeda share tweet Googleの社内フィランソロピー組織であるGoogle.org(DotOrgと略称される)の迷走について記した記事。おそらくはLarry PageがCEOに昇格するという報道を受けてのものように思われる。 Google Finds It Hard to Reinvent Philanthropy 【New York Times: January 29, 2011】 あのDotOrgの話か、と軽い気持ちで読み始めたのだけど、途中まで読んで、この記事はなかなかに含みのある記事だと思い始めてきた。 それは、記事自体の「内容」にも、これがこのタイミングで書かれたという「意図」の点でも。 （
客が本気にならないといいシステムができない。東証arrowhead成功の鍵とは ～ Innovation Sprint 2011
客が本気にならないといいシステムができない。東証arrowhead成功の鍵とは ～ Innovation Sprint 2011 2010年から東京証券取引所で稼働を始めた新しい株式売買システムのarrowhead（アローヘッド）は、高速化が進む世界の証券取引所の中でも世界トップレベルのレスポンスを達成したと伝えられています。 そのarrowheadのプロジェクトはどのように運営されていたのか、そしてトラブルなくシステムが稼働した成功の背景に何があったのでしょうか？ 1月14日に都内で行われたイベント「Innovation Sprint 2011」で、東証側のシステム構築担当者だった宇治浩明氏が講演を行いました。 世界の高速化競争とトラブルによる危機感が背景に 東京証券取引所 株式売買システム部長 宇治浩明氏。1年前に投入した東証の新しい株式売買システム「arrowhead」は、それ以前に
Rails3.1の初期化プロセスを細かく追いかけたRailsGuidesの記事を和訳したよ:ミームの死骸を越えてゆけ
This domain may be for sale!
“バカ・マジメ”をメンバーに入れるな！
この法則は、チームメンバー人選に関する法則である。オペレーションズリサーチの初期の名著にあったと記憶している。 将兵は「リコウかバカ」「マジメとズボラ」に区分できるが、 “リコウ・ズボラ”は将校にせよ “リコウ・マジメ”は下士官にせよ “バカ・ズボラ”は炊事当番にせよ “バカ・マジメ”は絶対にメンバーに入れてはならない！ というのだ。 情報システムの開発や保守にかかわる費用は、ブルックスの法則により、規模の指数乗に比例して増大する。それに対して、情報システムの効果はパレートの法則により、機能（規模）の対数に比例して増大するだけである。このことから、上図に示すように「利益＝効果?費用」が最大になる規模が最適規模だと言える。 「ユーザーが必要なニーズを上げてこない」と嘆いたのは昔の話だ。現在では、ユーザーが多様な要求をしてくるし、IT部門はそれを至上命令として受け入れる傾向がある。そのために、
リスク低減を最優先したため、期間とコストは倍に
現在、システム全面刷新と大規模ERPパッケージ導入のプロジェクトに取り組んでいるゴルフダイジェスト・オンライン。前回は、システム刷新プロジェクトの進行状況を紹介した。今回は、プロジェクトが遅延した原因や、その際に同社が何を優先したかなどを紹介する。 2009年12月、株式会社ゴルフダイジェスト・オンライン（以下、GDO）は、社内のほぼすべての業務システムと基幹システムを一斉に刷新する「G10プロジェクト」を発足した。同プロジェクトは、各システムごとに計13の開発プロジェクトを同時平行で走らせ、それらを最終的にはビッグバン方式で一斉に稼働開始させようという大胆な試みだ。 当初は、2010年中にすべてのプロジェクトの開発を完了させ、2011年の1月1日に一斉に稼働開始する予定だった。同社上級執行役員・コーポレートユニット担当 兼 システム戦略担当の大日健氏は、この当初計画について次のように説明
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
