複数でサービスを作るコツ | ランサーズ社長日記
いいね！ 2 ツイート B! はてブ 88 Pocket 4 「個人サービスを作るコツ」というエントリーを書いたが、最近、個人ではなく、友人と2人でQuemlというモバイル検索メールサービスを始めた。 基本的には「個人サービスを作るコツ」とノウハウは共有できるが、複数でサービス企画して作っていく作業独特のコツもあると思う。と、いうことで、今回は「複数」にスポットをあてて、個人ではなく複数でサービスを作り個人以上の成果を得るためのコツを書き出してみた。 複数でサービスをつくるコツ １．決起集会を開く ２．ドメインを取る ３．サービスに名前をつける ４．リリース日を決める ５．常に連絡を取れる手段を用意する ６．予定を共有する ７．誰にも依存しない開発環境を用意する ８．良いものは良いという ９．タスクを明確化する 解説 １．決起集会を開く 「こういうサービスあったらいいよね。」というのは飲み
プログラマから起業家へ転身する際の注意点:Geekなぺーじ
「10 Tips for Moving From Programmer to Entrepreneur」 という記事がありました。 面白かったです。 要約してみましたが、間違っているかも知れないので詳細は原文をご覧下さい。 1. コーディングはあなたの仕事の5％でしかない コード書きに夢中になってしまう起業家がいます。 コードを書くことも重要ですが、いくら美しいコードを書いても、誰もその製品を使ってくれないのであれば意味がありません。 税金を払い忘れて逮捕されてしまったら書いたコードは無駄になります。 ソフトウェアのライセンスに無頓着であるために訴えられたら、コードは無駄になります。 ブログやフォーラムでコードの事ばかりを話題にする起業家を見る事がありますが、多くの場合、コードよりもビジネスの側面について考えた方が良いと思われます。 もちろん、コードについて語る方が簡単ですが、そもそも起業
受託からサービスへの移行に必要なこと。
よくwebの受託をメインにやっている会社さんが、儲からないという理由でサービスに行きたいとの話を聞く。 しかし結構、難しいですよね、と、ついつい言ってしまう。 理由のコアは、下記エントリーに書いてあった。 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む １．受託開発では「技術」が蓄積しない ２．受託開発では「人材」が蓄積しない ３．受託開発では「資金」が蓄積しない 技術が蓄積されないのは自社の役割や案件次第では？と思うこと以外は、結構同意だ。 （受託は、自社では実現できない案件に関われることなどが魅力で、そこに技術やノウハウ習得のチャンスは転がっていると思うし。） 一番重要なのは、キャッシュフローが安定しないところではないだろうか。 サービスと受託の大きな違いは、 「受託は技術を売る仕事」 「サービスは、文字通りサービスを売る仕事」 である。 サービスは、お客様がつくと継続的に
「サービスは半日で完成させる」—— SETAKE・たつをさん
「有名人身長推定サイト SETAKE」「EREK」などのサービスを作ったたつをさんはドメイン取得からサービスリリースまでは半日でこなすという。飲み会で生まれたアイデアをもとにサービスを開発することもあるため、ペンはどこにでも持ち歩く工夫をしている。 「ひとりで作るネットサービス」第11回目は、Web APIを活用して次々と小粋なサービスを開発するたつをさん（35）にお話をうかがった。「ドメイン登録からサービスリリースまで半日が目安」と言い切る彼は、どのように企画・開発・運用を行っているのか。その秘訣に迫った。 飲み会の会話から「有名人身長推定サイト」が生まれた 「作ったものはたくさんの人に使ってもらいたいですよ。エンジニアですから」と話すたつをさん。彼が作るサービスはWeb APIを使ったシンプルなものが多い。ちょっとしたアイデアが、情報の見せ方を工夫することで“意外と便利”なサービスにな
大迫正治 REPEDANT BLOG > 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む : ITmedia オルタナティブ・ブログ
日本のソフトウェア産業は「製造業」よりも「サービス業」に分類される。なぜなら、革新的なプロダクトを研究開発し、一気呵成に市場に展開するよりも、顧客ニーズに沿ったオーダーメイドのシステムを逐次的に開発することが主流となっているからだ。 創業期は受託開発で糊口をしのぎ、徐々に自社製品の研究開発に資金を回して、いつかは自社ブランドで世界を席巻する、というストーリーは巷にあふれるが、これは結局のところローリスクでスタートしながらハイリターンを得ようとする野望であり、実現へのハードルは低くない。その理由は、中毒性のある受託開発と、ソフトウェア産業の悲惨この上ない「重層下請け構造」にある。 １．受託開発では「技術」が蓄積しない 住信インベストメントの辻俊彦氏はご自身のブログで次のように述べている。「クオリティの高い受託開発力は、オリジナリティ溢れる尖った自社開発力を生み出す素地になると思っている。投資
「企業理念」の大切さ
UIEvolution の起業は私にとっては初の起業であった。今から思い直してみると、ビギナーだった故のたくさんの失敗をしてきたが、今の私から見て「良くそれなしで会社として成り立ったなァ」と言いたくなるよう恥ずかしいことを一つしている。 「User Experience Matters」、「Pervasive Application」など、会社の外に向けたビジョンやミッションははっきりと打ち出していたものの、どんな人を採用してどんなカルチャーの会社にしたいか、という会社作りにおいてもっとも大切な「企業理念」を目に見える形の言葉にしておかなかったのである。 そもそも「企業カルチャー」の大切さを私が理解していなかったこともあるし、私自身の中でも「どんなカルチャーの会社にしたいか」というイメージが固まっていなかったのもある。Google・Microsoft・Sony・Honda、どれもファウンダ
話をズラす７のテクニック
ものごとを断定するやからは、いつでもあなたの前に現れます。 しかし、世界はもっと曖昧で、境界はハッキリしないはず。 そこで今回は「話をズラす７のテクニック」を伝授します。 話をズラし、対立する○○と▲▲の境界を曖昧にして、問題そのものを消し去ってしまいましょう。 １．○○と▲▲は、昔は同じものだったんだよ 基本テクです。対立する○○と▲▲を実は同じものなんだと言い切ることでその境界を曖昧にし、怒りの立脚点を不明瞭にするテクニックです。 例「山岡家と海原家は、昔は同じものだったんだよ、だから喧嘩するこたないんだ」 山岡「そういう問題じゃない」 おっとダメでした、じゃあ次のテクニック。 ２．○○と▲▲の話をする前に、▲▲についての定義を聞かせてほしいな。 枝葉末節にこだわるのが、話をズラすテクニックのポイントです。▲▲についての定義が間違っていたり、曖昧だったりすればしめたもの。「▲▲について
404 Blog Not Found:翻訳 - 自己管理チェックリスト12条
2007年06月07日20:00 カテゴリ翻訳/紹介 翻訳 - 自己管理チェックリスト12条 まだPOP*POPもGIGAZINEもツバをつけていないようなので。 A self-management checklist どんな人の人生のどんな側面にも、それぞれ異なった挑戦が待ち受けています。サイクリング好きな人は、エクササイズの必要を全く感じないでしょうが、読書のための時間を設けてきちんと本を読むのは苦手かもしれません。その一方、読書好きは本を置いて活動的に振る舞うのが苦手かも知れません。 以下の自己管理チェックリストは、どんな状況であれその状況を掌握するのに何らかの役に立つ事を念頭に置いてます。 目標は具体的に - Set specific goals. 成果測定しようにも、目的地がどこにあるか決まっていなければどうしようもありません。以下は具体的な目標の例です;一日30分歩く。一日10
７つの習慣、GTD に次ぐ第三の潮流、4HWW | Lifehacking.jp
このブログを始めた一つのきっかけは、価値観に根ざした習慣である「７つの習慣」と、日常のタスクマネージメントに密着した「GTD」のバランスこそが今後非常に重要になるだろうと思い、それを両方とも追いかけるブログを作ってみたかったのがあります。 しかしその二つに次ぐ、第三の潮流だと思うのが先日から紹介している Tim Ferris の The Four-hour Work Week です。自分の夢・目標に忠実になり、それに必要ない仕事は消去するか、他人にまかせてしまおうという考え方を説明した本です。 本の中には「トラブルしかもたらさない顧客はこちらから解雇しよう」とか「日常の業務もインドにアウトソーシングしてしまえばいい」といった、字だけを追っていると反感を買いそうなこともたくさん書いてあるので、素顔の Tim がどんな人物かには非常に興味がありました。 先日、Tim Ferris が Scob
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
Concepts Principles - プログラミングの原則 - Concepts Principles - Top
ここはプログラミングの原則を集める Wiki です。巨人の肩に乗って、ふつうの人がよいプログラムを書くための指針を集めたいなと思ってます。 目次 よいデザインのための Concepts + Principles DRY (Don'tRepeatYourself) 名前重要 直交性 トラッシュではなくクラッシュ DuckTyping よいルーチンを書く 凝集性 結合性 契約による設計 (DesignByContract) ルーチンを作る正当な理由 よいモジュールを書く 適切なモジュール性を確保するために守らなければならない5つの原則 開放/閉鎖原則 (OpenClosedPrinciple) よいアプローチのための Concepts + Principles 曳光弾 可逆性
職場の雰囲気を悪くしている、見えない「私」 | Lifehacking.jp
Four letter words: 題名だけではなんのことかさっぱりだと思いますが、これは先日 37Signals のブログ Signal vs Noise での記事「Four letter words」を読んでいて思ったことです。記事では他人、特にプログラマーとデザイナーのように違う畑の人とがコラボレーションしているときに注意しないといけない４文字言葉が紹介されていました。いいえ、f*** とか s*** ではありません。それは、 Need、Must、Can’t、Easy、Just、Only、Fast の７つです。使用例は次のような感じ。ちょっとあきれ気味の口調で読み上げると、やる気減退効果は絶大です。 We really need it. If we don’t we can’t make the customer happy. Wouldn’t it be easy if we j
FPN-ゼイヴェル・大浜史太郎社長へのインタビューを読んだ
2．ビジネスリサーチの情報収集 デスクトップ調査 の基本〜アニュアルレポートなど公開情報から… デスクトップ調査 とは、主にインターネットなどを使用して、公開情報を調査して整理・分析を行うものです。「CIAも収集する情報の95％が公開情報」ということで、情報不足とい… 2021.01.28 2021.05.13 1962 view 4．インプリケーションと提言 リサーチを通じて気付いたことは？公開情報から点と点を結ぶイン… インサイダー情報はそのままでは役に立たない！？ビジネスリサーチの依頼の中で、「業界の空気感はどうなっているか？」「この技術が主流になっているというのは信憑性があるか？… 2021.01.27 2021.05.13 185 view
Geekなぺーじ：選択肢を減らすことの重要性
Google TechTalksでBarry Schwartz博士による講演が公開されていました。 「The Paradox of Choice - Why More Is Less」というタイトルでした。 最初は、UNIXコマンドのmoreがlessよりも劣っている理由の事だと思って見始めましたが、そうではありませんでした。 何でも選べてベストじゃないと満足しないというのは、アメリカ人っぽい気もしましたが、かなり面白かったです。 ユーザビリティと機能の問題は良くある問題ですが、お店で展示されている商品の種類を減らした方が売り上げが上昇する話などが新鮮でした。 以下に要約してみました。 ここでは書いていない部分も多いので、詳細はビデオをご覧下さい。 字幕も入っていますし、ゆっくりと話してくれる人なので非常に見やすいと思います。 ただ、スライド(PPT?)が見られないので、何故観客が笑ってい
- 教えて！goo
掲載情報の著作権は提供元企業等に帰属します。 Copyright(C) 2008 OKWave All right reserved.
オープンソースコミュニティ運営方法:Geekなぺーじ
Google Videoに「 How Open Source Projects Survive Poisonous People (And You Can Too)」という54分のビデオがありました。 Subversionの開発者達が、オープンソースプロジェクトを運営上の注意点を解説していました。 面白かったです。 ボランティア開発者の集合体によって実現しているオープンソースプロジェクトを運営する方法を解説するという題目ですが、 最後のオチでは、「これはオープンソースに限らない」と言っていました。 確かに、一般的な開発でも参考になる部分は多いと思いました。 また、掲示板やブログのコメント欄でも一部は適用できそうなノウハウであると思いました。 要約してみましたが、結構いい加減で間違いなどがあると思うので詳細はビデオをご覧下さい。 「Poisonous People」は「有害な人」と訳してみま
Business Media 誠：ラーメン屋とカレー屋はどちらが儲かるのか？――5分で学ぶ“ロマンとソロバン”
著者プロフィール：山口揚平 トーマツコンサルティング、アーサーアンダーセン、デロイトトーマツコンサルティング等を経て、現在ブルーマーリンパートナーズ代表取締役。M＆Aコンサルタントとして多数の大型買収案件に参画する中で、外資系ファンドの投資手法や財務の本質を学ぶ。現在は、上場企業のIRコンサルティングを手がけるほか、個人投資家向けの投資教育グループ「シェアーズ」を運営している。著書に「なぜか日本人が知らなかった新しい株の本」など。 ある学生と一緒にラーメン屋の行列に並んでいたら、彼が面白い問題を出してきた。「行列のできるラーメン屋とカレー屋を比べると、2つの理由によってカレー屋のほうが儲かるんですよ。なぜだと思います？」 彼によれば、単価も、原価などのコストも同じでお店の大きさや座席数も変わらないとすれば、ある理由によって、行列のできるラーメン屋よりも行列のできるカレー屋のほうが売上が多く
GoogleのCEO、エリック・シュミットによる経営哲学とは？ - GIGAZINE
現在、世界で最も注目されている企業と言えばGoogleですが、先ほどまで放送されていた「NHK プロフェッショナル 仕事の流儀」の中で、そのGoogleの最高経営責任者、エリック・シュミット氏の単独インタビューというものがありました。 「お前、クリエイティブになれ！と言われてもクリエイティブにはなれない」 「大事なのは間違いを認めすぐに修正すること」 「集団の方が個人より優れた判断が出来ると信じている」 などなど、なかなか示唆に富んでいる内容だったので、経営者のみならず普通の人にとってもなかなか考えさせられる面があるのではないかと。 詳細は以下の通り。 スペシャル （2007年5月29日放送） | NHK プロフェッショナル 仕事の流儀 「大事なのは、間違いは誰にでもあるということ。そして間違えたときには、すぐに修正をすることです」。そして、リーダーにとって最も重要な資質は、「聞いて学ぶ能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日経トップリーダーonline: 本田宗一郎 ホンダ創業者
はてなブログ | 無料ブログを作成しよう