スタートアップを殺す18の誤り
Paul Graham / 青木靖 訳 2006年10月 最近やった講演の後のQ&Aで、スタートアップを失敗させるのは何かという質問をした人がいた。その場に立ったまま何秒か呆然としていた後、それが一種のひっかけ問題なことに気付いた。これはスタートアップを成功させるのは何かという質問と等価なのだ——失敗の原因となることをすべて避けるようにすれば、成功することができる——そしてこれはその場で答えるにはあまりに大きな問だった。 後になって、私はこの問題をそういう方向から見るのも有効かもしれないと思うようになった。すべきでないことをすべて並べたリストがあれば、それをただ逆にするだけで成功へのレシピに変えることができる。そしてこの形のリストの方が、実践する上で使いやすいかもしれない。やらなければならないことをいつも頭に入れておくよりは、何かやってはいけないことをしているときにそれと気付くというほうが
いいアジャイルと悪いアジャイル
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
ポール・グレアムのエッセイと和訳一覧
ポール・グレアムのエッセイと和訳一覧 (originally maintained by naoya_t) Paul Grahamのエッセイ（原文）と、公開されている日本語訳のリストです。 見つけたらor 訳したら、自由に追加して下さい。複数の訳が存在する場合は全て追加してください。 A Fundraising Survival Guide 資金調達サバイバル・ガイド (lionfan) The Pooled-Risk Company Management Company リスク共有型の企業管理会社 (lionfan) Cities and Ambition 都市と野心 (lionfan) Disconnecting Distraction 気晴らしを断ち切る (lionfan) Lies We Tell Kids 子供につく嘘 (lionfan) Be Good 良くあれ (sirocc
現代という時代は、どのようなプログラミングを求めているのか？ - 分裂勘違い君劇場 by ふろむだ
Rubyを使うべき本当の理由は、根源的には、日本で自殺者が増えた理由と同じです。 今後日本が没落していく理由とも同じです。 団塊の世代に無能な人間が多い理由とも同じです。 サービス残業が増えた理由とも同じです。 日本の多くの若者たちが未来に希望を抱けない理由とも同じです。 いまの学校教育が無能な人間の製造工場になってしまっている理由とも同じです。 その理由は、根本的には、「単純ニーズの飽和」という環境変化に起因します。 そして、それによって、プログラミングが経営行為になってしまったことが原因なのです。 団塊の世代の仕事人生の大部分は、単純ニーズを満たすための仕事に費やされました。 冷蔵庫の普及率が低く、しかも誰もが冷蔵庫を欲しがった時代には、何をやるべきかは、明らかでした。 とにかく、額に汗して働き、安くてよい冷蔵庫をどんどん作れば良かったのです。 冷蔵庫に限らず、洗濯機、ラジオ、テレビ、
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小
OBB vs AABB - Radium Software Development
iPhoneの一般修理店は予約なしでも来店できる？ 基本的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
はてなに入った技術者の皆さんへ （jkondoの日記より）
最近はてなの社内では新しい技術を勉強したり、フレームワークや言語を移し変えようかという話も出ていたりして活気が出てきています。技術者も10人を超えて、色々な考え方をする人同士が刺激を与え合いながら切磋琢磨していて素晴らしいなあと思います。そういう中で、僕が技術について思う事を少しまとめてみました。 アウトプットを出す 新しい技術を習得したり、時間を掛けて作り上げた結果は、何かのアウトプットとして出さなければほとんど意味がありません。知識や結果を自分の中に残すだけで終わるのは、それを活かしてサービスを作りたくさんの人が使えるようにする事に比べると驚くほどちっぽけな仕事です。 また、3日間で作り上げた素晴らしい仕組みをそのまま1週間寝かせてしまうのは、4日目に他の人が使えるようにしてから1週間を過ごすことに比べると随分見劣りしてしまいます。 当たり前ですが、どれだけ素晴らしい仕組みを作っても、
kuranukiの日記 改善型開発について
現在のシステム開発という開発モデルを考えてみると、そのシステムを必要としており開発の依頼を発注する発注側と、実際の開発作業を請け負う開発側の間で、プロジェクトに対し契約を結んだ段階からシステム開発は始まる、というのが当たり前の話。そして、この当たり前と思われている関係でビジネスを続けると問題があるのでは、と考察したのが以前のエントリ、「ディフェンシブな開発*1」だった。 今回は、その当たり前だと思われているところについて、発想の転換を取り入れて考えてみようと思う。社会における通念や物事を大きく変えるためには、コペルニクス的転回が必要だからだ。 ノウハウを集約できないSI企業 まずこの「プロジェクト開始してからシステム開発を始める」という点について、ディフェンシブであるということ以外にも、SI企業として重大な問題点が隠されている。それは、IT技術に対するノウハウの蓄積に関する問題である。今の
技術を活かすための競争戦略 - 雑種路線でいこう
id:mkusunok:20060129:techstrategyで触れた内容について少し掘り下げてみる。これは歴史の勉強をした後の感想のようなものに過ぎないので、今後もこの通りにやれば成功するという意味ではない。ただ、何をやってはいけないか、という参考にはなるだろう。ベンチャーにとって大事なことは、先行する大企業に先行優位性を発揮させないこと、そしてより大きな技術力や資本力を持った後続企業に真似されても差別化し続けられる仕組みをつくることだ。 価格はマーケットインで決めよ これは大企業のイノベーションでよくあることだが、R&Dに大変な金額をかけた割に市場がそれほど大きくない、だから価格を上げてしまおうという失敗である。Xerox StarとかToken RingとかHiSWANaが典型的だ。これらは研究開発予算を正当化するために商品化され、それが素晴らしい革新的なものであることを社内に説
即戦力がいなくなる職場ってどうよ - 雑種路線でいこう
「即戦力」の使い勝手が悪いというのは、その通りなんだろう。彼らは自分の市場価値を理解しているから、労力に見合った賃金を払わない会社や、そこにいると自分の価値が目減りするような経験しかさせてくれない会社からは逃げてしまう。そういうものだ。 結局のところ企業の経営戦略とかポートフォリオの問題である。割高で流動性の高い即戦力に頼るべきか、それとも地道に生え抜きを育てるべきかというのは、 業務に必要とされるスキルが汎用的か 業務の熟練者と非熟練者の間に著しい生産性格差があるか 事業そのものは継続的か 事業の収益性は高いのか といったことに依存する。 極言すれば、事業が汎用的専門スキルを必要とし、熟練による生産性向上が著しく、継続性が低く、収益性が高ければ即戦力を雇うべきである。ITの場合は結構な割合でこれが当てはまる。 きっと大学の先生が始めた翻訳業の場合、業務に必要とされるスキルこそ汎用的だけど
「本物のプログラマ」もNEETになり得る御時世の処世術 - 雑種路線でいこう
ぼくはIT業界の中で技術者からマーケティングに移った人間で、最初こそ張り切ってコトラーとか読んだけど、外資系企業で日本法人にいて3Cとか分析しても4Pのどれも殆ど触れないことに気づいて、これじゃマーケティング戦略の勉強にはならないなぁと感じて途中から技術渉外っぽい仕事に路線変更した。*1技術渉外というのも一風変わった仕事で、似たような仕事があるといっても非常に限られているだろうし、日本企業のそういった部署で中途は採ることは少ないだろうから、日々潰しが利かなくなっているのではないかという不安はある。けれどもまぁ、英語とか段取りとか、自分の苦手なところを鍛えつつ、少し突き放して業界の仕組みを眺める居場所としては面白い。 どこかでいざとなったら技術者に戻れるという気持ちもあって、Virtual PCでLinuxとかの環境はつくっているし、手元の環境には一通りのコンパイラは入れているし、研究所でつ
エンジニアに贈るエール、「理系思考」とは？ － ＠IT自分戦略研究所
加山恵美 2005/12/10 理系であること、またエンジニアであることの尊さを再認識できる本がある。著者は生粋の理系出身でエンジニア経験もある。いわばエンジニアの大先輩だ。本書は随所にエンジニアへの激励が込められており、読めばエンジニアとして働くことに誇りを見いだせるだろう。また、積極的にキャリアを考えるきっかけになるに違いない。 ■エンジニアの先輩から現役エンジニアへ エンジニアにエールを送るのは大滝令嗣氏（現在はヘイ コンサルティング グループ 代表取締役）だ。大滝氏はエンジニアの境遇から気質までをよく理解し、人生設計や経営にも造詣が深い。大滝氏は著書『理系思考 エンジニアだからできること』にエンジニアへのメッセージを記した。そこには現役のエンジニアに能力を開花し、旺盛にキャリアを開拓してもらいたいという願いが込められている。 本書は序盤でエンジニアの苦境を嘆いている。最近では世間一
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
