面倒な仕事その2 - naoyaの寿司ブログ
面倒な仕事その2http://naoya.hatenablog.com/entry/2012/01/20/121736に面倒な仕事、ということを書いた。「大きな問題を引き受けるほど、利益は大きい」みたいな話は、まあそれはそうだよねという話でしかなくて、あのポール・グレアムのコラムでぼくが大事だなと思ったところはそこではない。(それに、問題は大きくとらえて解決しろみたいなのはやりたい人はそうすればいい、別に解こうとする問題は必ずしもそんなに大きな問題じゃなくてもいいんじゃないの? 自分たちの解きたいサイズの問題であればそれでいいんじゃないか、と思ったりすることもままあるし。)コラムの中で、大事だなと思ったのは "。無意識に、面倒で嫌な仕事が伴うアイデアが浮かばなくなってしまう。" の「無意識」というところだ。面倒な仕事だって分かってて避けてしまうんだったら、それにちゃんと向き合いましょうね、
「1000人の凡人が一人の天才に負けるエンジニアリング」ではなく「凡人1000人で本当に良いプロダクトを作るエンジニアリング」を指向したい - FutureInsight.info
非常に刺激的な記事。 http://engineer.typemag.jp/elife/2011/04/post.php 僕のチームラボ社長猪子寿之氏好きは昔からで、出演する番組やUSTは大体チェックしてるし、昔書いた以下のエントリーをきっかけに一度お話させて頂く機会もあった。 チームラボの猪子社長の常人のものではないアカギ的発想について - FutureInsight.info 今回の対談も非常に面白く読んだのだが、最近よくわからなくなってきたのは、小飼弾氏が述べている「1000人の凡人が一人の天才に負けるエンジニアリング」という言葉。というのも、昔は僕もエンジニアリングは一人の天才で全部ひっくり返される可能性があるなー、と漠然と感じていたが、最近はそれって違うんじゃないかと思っている。 一人のエンジニアが全てをひっくり返すにはレバレッジが必要 特にここでシリコンバレー賛美を始めるつもり
生活メモ: 就職することにした
長らくニートだったが、就職先が決まったということで、代官山のレストランで妻と娘にお祝いしてもらった。うれしい。そして、新しい道に踏み出すという新鮮な気持ちが何とも心地よい。 2011年2月1日付けで、Googleに入社する。その経緯について記述しておく。個人的事情をわざわざ晒す必要もないのだが、お世話になっている皆様やOSS関連や個人事業関連で関わりのある方々への報告ということでキーを叩く。 経緯 昨年7月末に前職を辞して、自作のOSS製品のデュアルライセンス販売で食っていくべく開発作業や事務作業を半年ほど行ってきた。しかし、地価と物価の高い東京という都市に妻子とともに暮らせる収入を継続して得ていくにはあまりにも頼りないビジネスモデルであるため、それを本業にすることは断念した。 より正確に言えば、当初からOSSで食っていけるとは思っていなかったので、ライセンス販売は妻に任せて俺は就職できる
初心者ディレクターが気をつける10のこと／在宅でライターの仕事ができる「nanapiワークス」をリリースしました - iGirl
【2020年12月追記：nanapiもnanapiワークスも役目を終えられまして、サービスクローズしています。関わって、育ててくださったすべての方に感謝します】 ■ これまでのあらすじ（読み飛ばし可） わたしは約1年前（2009年夏）から（株）ロケットスタートの nanapi という How to サイト運営に携わっています。（参照：（株）ロケットスタートで働くことになりました） 2010年3月、正式にフルコミットすることになり、東京へ引っ越してきました（単身赴任）。 そしてこの度、新サービス「nanapiワークス」のディレクションを1からやるという大役を任していただけました。 ■ 「在宅でライターの仕事をするサイト｜nanapiワークス」 をリリースしました nanapiワークスとは、nanapiに配信される記事を書き、採用されるとポイントが付与されるサービスです。（ポイントは現金とか商
ダメな仕事を受けないためのNGワード | おごちゃんの雑文
体力のある大企業と違って、フリーランスや零細企業だと、「ダメな仕事」を受けてしまうと命取りだ。 もちろん戦略的タダ働きというのもあるのだが、体力がない身ではそれは限界があることを知っておくべきだ。 と共に、そういった仕事を避けることも考えておかなければならない。 弊社はSIを積極的に受けているわけではないが、背に腹は代えられない。お金が厳しくなれば、SIだってホイホイやってしまう。 とは言え、何でもかんでも引き受けていると、身動きが取れなくなってしまう。それでは自分も困るし、お客にも迷惑がかかる。場合によっては、業界に迷惑をかけてしまうことだってある。だいたい、原価割れでも仕事は仕事なんで、そーゆー仕事で苦労している間に、もっと率のいい仕事が目の前を通り過ぎて行かないとも限らない。原価割れの仕事は、 海水で渇きをいやす ようなもので、その瞬間は何とかなっても、さらに厳しくなってしまう。 そ
偽装請負のススメ：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 偽装請負というのは、コの業界（古い隠語だけれどコンピュータ業界のことね）のいわゆる悪弊であったりするのですが、それぞれについて分からないというお話や勘違いしてることも多いかと思うので、ちょっと整理してみよう。 ● まずは言葉の意味から ■ 請負契約 納品物に責任を負う契約。つまり、成果物が完成しなければ報酬はもらえない。どのように作ったかは個別に契約していない限り問われない。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。 ■ 委任契約（準委任契約） 作業に責任を負う契約。ちゃんと作業をしていれば（善管注意義務を果たしていれば）成果物がなくても報酬がもらえる。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。 ※ ここまでを分かりや
任天堂は「やらないこと」で目標を達成した
やらないよりはやった方がいいに決まっている。しかし、ここに落とし穴がある。サウスウェスト航空、任天堂、QBハウスに見る目標達成の方法を個人で実現するためには。 仕事をしているとどこまでやるべきか判断に迷うことも多い。もちろん、なるべくやれることはやった方がいい、そう思うのが一般的だろう。 勉強や自分のスキルを磨く場合も同じだ。やらないよりはやった方がいいに決まっている。できないよりはできる方が価値が高いに決まっている、と素直に思う。……しかし、ここに落とし穴がある。 この考え方の最大の問題点は、すべてが中途半端になりがち、ということだ。より多くのことを成そうとすれば、1つだけに集中している者に勝てるわけはない。企業が競争力を失うケースもこうした原因が少なくない。 「選択と集中」――イケてる企業はやっている こうした企業が取るべき道として「選択と集中」という言葉がある。競争力が高く、独自性の
Q.電球を変えるのに、SE/PGが何人必要か - SiroKuro Page
答え 約2000人月 開発の流れ 要件定義 顧客の発注を受ける １次請け、要件定義書の執筆を始める １次請け、顧客と交渉し、家の中に繋がっている家電製品を全て調べ上げる 一次請け、基本設計実施要領の執筆を始める 基本設計 この工程は、２次請け以下には秘密裏に行われている 詳細設計 １次請け、詳細設計実施要領の執筆を始める １次請け、だいたいこのあたりで２次請けへと乾坤一擲 ２次請け、使用する規格やフレームワークなどの部品を選定開始 詳細設計書の執筆がスタート、電球の大きさや重さ、丸み、光度、味、匂いなどを定義する このあたりで、既に５次請けくらいまで仕事が割り振られている 製造 １次請け、製造工程実施要領の執筆を始める １次請け、単体テスト実施要領の執筆を始まる ５次請け、電球フィラメントのくるくるを手で作成しはじめる ４次請け、求める匂いが上手く出せないと３次請けに駄々をこねる ３次請け
ディレクターが押さえておきたい営業取引の基本的な流れと頻出ワード : LINE Corporation ディレクターブログ
こんにちは、小久保です。 私の経歴は、受託開発のディレクター → 自社媒体のディレクター → 事業責任者 という流れを経ておりまして、以前「受託開発事業から自社媒体事業へシフトするための意識改革のポイントとは？」という記事を書きましたが、実はキャリアパスの中で一番焦ったのが営業面での知識不足でした。 受託開発を担当している時は、開発工数と人月単価さえおさえておけば渉外対応はある程度事足りていたのですが、自社メディアの場合だと提携内容の検討と営業的な話は一体となって進むことが多く、必然的に営業的知識が必要になってきました。 今回は、営業職の経験が無いディレクターの方でも、ビジネス上で最低限これだけは知っておいたほうが良いと思う、営業面での知識について紹介します。 まずは、一般的な取引成立までの流れをまとめてみましょう。以前、弊社の「ビジネススキル勉強会」というブログに「取引行為についての勉強
独自の手法で10倍速開発 7割主義で変化対応力を高める
良品計画は独自の開発手法を採用することで、システム開発の短期化とコスト削減を図った。2006年12月に再構築したMD（マーチャンダイジング）システムを皮切りに、08年12月までに約130のアプリケーションを社内で開発。一方で、IT 投資の売上高比率は04年の1.8％から0.9％に半減させた。「7割主義」と「スピード対応」を方針に掲げ、利用部門の要望に最速1日、遅くとも1～2週間で対応する。開発手法の独創性と、経営に資するシステム部門の姿が評価された。 「無印良品」ブランドの小売店を展開する良品計画は、1週間に1本という猛スピードで新しいアプリケーションを開発したり、機能を強化したりしている。「思い立ったら即実行。合格最低ラインの7割主義で素早くシステムを開発し、検証と改善を繰り返す」。IT戦略を統括する小森孝取締役 情報システム担当部長兼流通推進担当管掌は強調する。 同社は独自の開発方法論
第65回 ［図解］Webサイト構築プロジェクト・ワークフロー - Webデザイン エンジニアリング：ITpro
今回は，Webサイト構築プロジェクトのワークフローを俯瞰してみたいと思います。実際にクライアントから声がかかる場面から納品，つまり開発案件の完了までを12の「ステージ」に分けて図解してみました。思考のプロセス/人的配置/タスク/ツールなども一緒に記しています。少し大きな図になってしまいましたが，ご参考になれば。 図は，一番上は「4つのステップ/3つのタスク/12の要素（第62回 持続可能なWebサイト開発を支える12の要素）」。その下は，人的配置をロール(役割)ごとに記述しています。その下は，大まかなタスクのレベルです。それぞれの期間内に処理すべき項目を列挙しています。その下が，「ステージ」。プロジェクト全体を12のステージに分類して作業内容を整理しています。基本的には，その流れの順で進んでいきます。その下は，それぞれのステージのアウトプットのイメージで，更にその下にはよく使うファイルアイ
バーベキュー優先度問題、あるいは人生における優先度の問題 : 小野和俊のブログ
忘れられない思い出というのは意外とちょっとしたところから生まれるものだが、 私にとってのそんな思い出の一つに、大学生の頃の「バーベキュー優先度問題」というものがある。 簡単に言えば、バーベキューのために買ってきた肉が多すぎたのである。 この多すぎる肉をどのように食べ進めるかについて、私は二つの方法を考えた。 (2) まず安い肉から食べ始める。途中でお腹一杯になってしまっても、デザート別腹理論的に 美味しい肉であれば食べようという気が起きて完食できるだろう。 当時の私は、食べ物を粗末にしてはいけないと殊勝(自己評価)なことを考え、 (2)を選んだ。しかし、肉が別腹に入るはずなど無く、結果として残ったのは 食べきれずに残された大量の上質な肉だった。 買ってきた肉を食べきれず、しかも良い肉の方を残してしまったのである。 「ちくしょう！」、私は自分の判断の誤りを悔やんだ。そして敗北感に打ちひしがれ
2億円の見積もりされたのを820万でできたのはすばらしいと思う - novtan別館
が、過大評価はしない。 「IP電話を導入する場合のベンダーの見積もりは約2億円だった。アナログ交換機を更新する場合でも費用は約2000万円。しかし自分たちで敷設することでサーバーは20万円，電話機500台は800万円で導入でき，電話料金も年間400万円削減できた」---秋田県大館市産業部商工課商業労政係主事の中村芳樹氏は，IP電話導入の経緯と効果をこう振り返る。 見積もり2億円のIP電話を820万円で構築した秋田県大館市から学べること | 日経 xTECH（クロステック） 詳細に要件が見えている状態で2億円提示されたらまあそのベンダーは切ってもよい。逆に、適当にこういうことがしたいんですけどー的なノリで見積もらせたのであれば極大に金がかかるシチュエーションを想定して「最大このくらい」で見積もるだろうから、お役所と思って足元を見る(お役所は緊急時のために無駄を積まなければならない存在ではある
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
「小さなソフトウェアベンダー」という選択肢 : 小野和俊のブログ
「Eric Sink on the Business of Software」読了。献本感謝。 みんな大好きジョエル・スポルスキーも大絶賛の本書であるが、とても面白かった。 そして、本書で指摘される図星としか言いようのない的を得た指摘の数々がつぼにはまり、読みながら頻繁に声を出して大笑いしていたので、家の中で不審がられた。 私たちは、独創的なアイデアでソフトウェア業界の勢力図を書き換えてしまった人たちや、一夜にして巨万の富を手にした人たちにばかり興味が向きがちだ。 しかし、著者はそれに対してはっきりと「No.」を突きつける。 自分たちのソフトウェア製品を持ち、しかし大企業化を志向しない企業のあり方を、著者は「小さなISV」と呼ぶ。 それを私たちがなぜしようとしないのか、著者は次のように分析する。 1. 私たちはそれを見たいと思わない (巨大なマーケットばかり意識して、ニッチマーケットで優れ
Geekなぺーじ : エンジニアが見落としがちなこと
過去に自分が間違っていたと思うことや、身近なエンジニア(技術者/研究者等)が「見落としているんじゃないか」と思える部分を列挙してみました。 ただし、それぞれ状況と立場次第であるものが多いのでご注意下さい。 製品を売る場合や、論文を書く場合、個人の場合など、様々な立場での色々なものをごっちゃに書いてしまいました。 1. 技術の凄さのみが戦局を決めるわけではない 「技術が凄ければユーザは勝手についてくる」という発想に出会う事があります。 それは、正しい場合もあれば正しくない場合もあると感じています。 最近は、得てして「技術だけ」ではあまり成功しないような気がしてきました。 そもそも「凄い技術」とは何なのかという部分が難しいです。 その「凄さ」が実現しているものと、ニーズとの一致などが的確で無い場合、いくら凄くても理解してもらえないことも多いです。 2. 誰が言うか、誰がやるかも大事な要素 全く
顧客対応の超基本「○○はできます、しかし△△日かかります」 - livedoor ディレクター Blog(ブログ)
こんにちは。ディレクターの方の谷口です。 今回は、顧客対応の超基本について、話したいと思います。 【01】顧客対応の基本とは クライアントから発注を受けて成果物を作る場合、ディレクターはよく、顧客と開発側との板バサミに苦しむことになります。この顧客対応は、構成書などを書く等の見えやすい仕事と違い、非常にあいまいな作業で、なにをもってスキルがあるかはカンタンにいえません。 しかし、この顧客対応のもっとも基本としては、「○○はできます、しかし△△日かかります」というフレーズを覚えてもらうことかなと思います。 「○○はできます」だけだと、開発側の負担が強くなりますし、結局できませんでした、という最悪の展開を迎えることが多くなります。「○○はできません」だと、顧客との関係性が深まりません。こう書くと当たり前のような事ではありますが、お金をもらっている以上、断ったらそもそもこの発注自体がなくなるので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記
ywcafe.net
単なる「低コストの外注先」ではなくなりつつあるインドのIT産業