タグ

ブックマーク / gothedistance.hatenadiary.jp (13)

  • 能力が高くても仕事を請けることは出来ない - GoTheDistance

    エンジニアのキャリアを考えればフリーになったり起業したりするというのは王道パターンの1つであると言えます。いざその道を歩むとなれば仕事を自分で受注しなくてはならない。そこに存在する落とし穴が表題そのものなんですが、もうちょい詳しく書いてみます。 「取ってきて貰った仕事をする」ヒトが「自分で仕事を取ってきて請け負う」を目指すときに起こる一番の勘違いは「能力が高ければ仕事を請けることが出来る」というものだ。 ここでいう能力というのは、エンジニアで言えば「Javaが書ける」「サーバー構築が出来る」「MySQLDBAをやっている」というような類のモノ。要はスペックと考えるとわかりやすい。単純な話だが、仕事を発注する企業やヒトは技術の専門家じゃないので、ある一定水準以上のスペックは「どんぐりの背比べ」にしかならないことが多い。スペックが高いというのは伝わりますが、伝わったところで「それはすごいです

    能力が高くても仕事を請けることは出来ない - GoTheDistance
  • 僕の最初の起業が失敗した7つの理由について - GoTheDistance

    10代で最初のWebサービスを立ち上げたけど失敗したNeil Patelさんのエントリが面白かったので、英語で分かるITトレンド風にお届けします。 My reasoning behind creating a job board was that if I could make 1% of Monster’s revenue I would be a rich kid. Sadly Advice Monkey never made any money and within two years I closed it down. 7 Reasons My First Business Failed Petelさんが立ち上げたサービスはjob boardのサイト(AdviceMonkey)と言うサイトだったそうですが、2年間1円の稼ぎも生み出さなかったのでサービスを終了したとのことです。以下、

    僕の最初の起業が失敗した7つの理由について - GoTheDistance
  • ミスに関していつも僕が思うこと - GoTheDistance

    先日知人と飲みに行ったんですが、こんなエピソードを聞かせてくれました。 とある小売店に納めた商品の伝票が、システム上に打ち込まれていないにも関わらず切られているというい違いが発生。システム上で計上されていない伝票が宙ぶらりんになっておりました。 ・・・・おかしいですね、と。 「なんで伝票しかないの?」 おっと上司がご立腹でございます。「伝票しかない=誰かが犯した間違い」という図式が先に浮かんできたんでしょう。伝票を入れずに商品を送るなんてあり得ないだろバカかお前と言う5秒前な、爆弾岩がメガンテしそうなピリピリとした雰囲気を目の前に部内の緊張ボルテージは最高潮。しかし、知人は冷静でした。 だって、先方に荷物が着いているかどうかさえ裏を取ればいいだけの話なんです、と。 納品伝票は後付でも構わないし、単純に知人の会社が手順踏まずにかっこわるいだけ。争うことでもない。出荷のミスを経理が気づいてく

    ミスに関していつも僕が思うこと - GoTheDistance
  • 営業ができる人とできない人の違い - GoTheDistance

    営業という言葉に良いイメージを持ってる人はかなり少ないんじゃないかと思います。特にエンジニアは営業さんに「泣かされた」経験がおありの方が多いですし。また、電話爆撃営業や詐欺に近いような営業も多い中、益々うさんくささが先行しやすいのかなぁと思ったりします。 ホントはそういうもんじゃないだろって思うので、自分1人で顧客の所に赴き、話をしに行くことも増え、発注側として営業さんの話を聞くことも増えてきました。そんな中で、営業について感じたことを書いてみます。 1. できる人は相手に問いかける、できない人は自分が話し続ける 相手とのコミュニケーションの中で距離感をつかみ、お互いが負担にならないようなコミュニケーションの土台をまずつかむこと。これが恐らく営業のはじめの一歩なんじゃないか、と思っています。 その土台を作るのに、まず自分のことを立て板に水を流したように話す営業がいますが、その時点で僕は「も

    営業ができる人とできない人の違い - GoTheDistance
  • 自信をつける為に役立つ、ちょっとした3つの方法 - GoTheDistance

    自信過剰な人は苦手だと思う一方で、自信がなさ過ぎる人といっしょに仕事をしたがる人もいないだろうなぁと。 自信を持とう。自信なさげな人に仕事はまわってこない。 - かみんぐあうとっ ほどよい自信ってすごく難しいテーマだと良く思う。そもそも、自信には根拠は要らない。必ず必要なもんじゃない。「この事業はあたる!絶対化ける!」という自信には特に根拠はない。けど、自信がそこある。 仕事でも学業でも何でもかわらないと思うけど、「できること」に対しては誰だって自信がある。出来ちゃうから不安になるような事が無い。逆に、「できないこと」に対しても自信のようなものがある。「プロ野球選手になれ→できるわけねーだろ」というような感じで。例は極端ですが、できる・できないがハッキリしていることについては、あんまり揺れ動く事は無い。 問題は、「できるかもしれないけど、やったことがない」事に対する自信の持ち方になる。これ

    自信をつける為に役立つ、ちょっとした3つの方法 - GoTheDistance
  • はてなのエンジニア退職劇に思うこと - GoTheDistance

    id:naoyaさんがはてな退職し、新しい道を探すことになりました。改めて、はてなユーザーとして感謝申し上げます。はてブというサービスがなければ、その中でアテンションを集めるホッテントリという仕組みがなかったら、今の僕はありません。当にありがとうございます&おつかれさまでした。 id:secondlifeさんが退職のエントリでこのような一文を書かれており、恐らくnaoyaさんも同じような心境だったんだと思います。 エンジニアとしてやっていくとして、はてなに残り 1エンジニアに戻る道ももちろんありました。ただ、自分にとってはてなはあまりにも居心地の良い場所になりすぎてしまっていました。それに自分も慣れすぎて、どうしても他人に甘え仕事に妥協が生まれたり、『会社にとって評価されやすい仕事』を気をつけていてもやってしまう自分がいました。また、長年会社にいるとその会社に役立つスキルを使って仕事

    はてなのエンジニア退職劇に思うこと - GoTheDistance
  • コミュニティ運営の中の人は大変なんです。優しくしてあげてください。 - GoTheDistance

    先日僕の友人・知人が中心となって運営していた技術系イベントの懇親会のキャンセル率が半分以上でポルナレフやる余裕も無く死にかけたというタレコミを聞いたので、ちょっと警鐘を鳴らしておきたいと思います。 僕は2007年にbpminnaというコミュニティの運営をお手伝いさせてもらっていました。で、その当時一番辛かったのなんだと思います?飲み会の設定です。何でつらいと思います?人数が正確にわからないからです。なんで正確な人数が出ないと思います?無断キャンセルが出るからです。参加するって言っているのに当日になったら消えた人が絶対出てくるんです。それも結構な人数で。 キャンセル率の高さの原因に開催者から参加者への連絡手段が無いことが良くあげられるんですが、これは直接的な理由ではありません。最大の理由は「強制力の無さ」です。もっと言えば、「テメー何やってんだよ」って問い詰めることができないということです。

    コミュニティ運営の中の人は大変なんです。優しくしてあげてください。 - GoTheDistance
  • スモールビジネスを興すのに本当に必要なこと - GoTheDistance

    スモールビジネスにトライしている僕がやってきました。 利益率の高い商売 在庫を持たない商売 定期的に一定額の収入が入ってくる商売 資ゼロあるいは小資で始められる商売 競合商品に比べ低価格 商品の再生産が容易(労働集約型でない) 協力(購入や顧客の紹介)してくれる仲間やメンターがいる 貪欲な学習意欲 顧客、従業員、商材、社会とのトラブルリスクが少ない商売 スモールビジネスを興して成功するための9条件 - 人と組織と、fukui's blog 書かれていることは正におっしゃるとおりだと思うのですが、殆どの場合こういうのはビジネスモデルに対する結果論なので部分的にしか参考にならない。この条件をほとんど兼ね揃えていたけど、「その条件を売上に転化できなくて」くたばる会社っていっぱいいる・・・。この条件を否定するのではなくて、モデルは良くてもコケるビジネスがいっぱいあるのはなぜか、ってことを考えた

    スモールビジネスを興すのに本当に必要なこと - GoTheDistance
  • 大手SIerの利益悪化がとどまることを知らない件 - GoTheDistance

    田中克己の針路IT - ソフト会社に明日はない?:ITpro ____ /::::::::::  u\ /:::::::::⌒ 三. ⌒\       ウソだろ!? 今期、いきなり利益半減? /:::::::::: ( ○)三(○)\          会社どーすんだろ・・・orz |::::::::::::::::⌒(__人__)⌒  | ________ \::::::::::   ` ⌒´   ,/ .| |          | ノ::::::::::u         \ | |          | /:::::::::::::::::      u       | |          | |::::::::::::: l  u             | |          | ヽ:::::::::::: -一ー_~、⌒)^),-、   | |_________| ヽ::

    大手SIerの利益悪化がとどまることを知らない件 - GoTheDistance
  • どうしてプログラマがPMになりたくないのか - GoTheDistance

    SIerでプログラマ(PG)からプロマネ(PM)までやった僕が通ります。 PMになりたくない症候群 - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan 一度でも失点をしたらそこからリカバリーすることが困難な立場に放り込まれるし、放り込まれたら現場の裁量で何とかするしかないというデフェンシブなやり方に起因する構造的なPM疲弊体質。確かにコレは、嫌悪される理由の1つにあると思います。ただ、それだけではないな、と。技能という側面で考えても嫌悪される理由があるのかな、と思いました。 要はPG→SE→PMというキャリアパス、についてですね。 色々な議論がありますが、何が問題かと言えばプログラマとして未来を奪い去ってしまう所が過多あるってことに尽きるように思います。技術は移り変わるわけですから、プログラマでありたいなら保有スキルが陳腐化しないようにしなくてはな

    どうしてプログラマがPMになりたくないのか - GoTheDistance
  • 「なんでこんなことやってんだろ」って思った時に考えて欲しいこと - GoTheDistance

    人間だもの、そんな時もありますよね。 僕は転職してから自分で自分のミッションを探さなくてはならないため、昔よりも「なんでこんなことやってんだろ」って思うことが増えました。そんな時に、感じたことをまとめておきます。 手馴れたものに安住していないか 僕が最初に感じたのがこれです。 転職して新しい職場に来れば、当然自分の持っている武器を活用して行こうと思うわけです。僕の場合は業務システムの構築に関する能力でしたが、いきなり社長に言われたのがFLASHを作ってくれ、でした。「ええええ、なんだそりゃあ」って喉元まで出かけましたが、「それが必要なんだから、できるところまでやれ」の一言でパシーン。そういうのが一番苦手なのにな・・・って思いました。 その話は立ち消えになったのもあり結局大した成果は出せませんでしたが、手馴れたものばっかりやっても仕方ないしココに来なければこんなことやる機会も無かったし、ま

    「なんでこんなことやってんだろ」って思った時に考えて欲しいこと - GoTheDistance
  • 大きな会社と小さな会社のどっちで働くべきか迷っている人へ - GoTheDistance

    いきなりポイントから入ります。大企業で働くことと中小企業で働くことの違いは、大企業はルールで動き中小は経営者の恣意で動くということです。ココがすごい重要です。 僕は6年近く大企業にいました。その時に考えたことは大企業で働くということ - GoTheDistanceで書きましたが、大企業の根的な原理原則はルールで仕事が動くということです。異なる立場・異なるレイヤーの人たちを束ねて1つのサイクルを作るには、ルールを作ってその中でサイクルを回すより他ありません。それの累積によって企業文化なるものが形成されます。 大企業にいてよかったことは「普通に仕事をさせてもらえる」ことでした。もちろん仕事を選ぶことは基的に出来ないんですが、明確に自分の役割が与えられ、そのロールに従いすべきことをして、あるべき成果を出してその仕事を終える。あっちいったりこっちいったりということはない。いきなり全く次元の違う

    大きな会社と小さな会社のどっちで働くべきか迷っている人へ - GoTheDistance
  • システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

    先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵「基契約」と「個別覚書」ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 「仕様策定〜開発まで」と「保守運用」で別契約にすることが多い。 「仕様策定フェーズ」で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は「事務作業の代行」という意味合い。委任は「法的効力がある作業」の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で「僕らのコンサル案を僕らが実施し成果が出

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
    hisaichi5518
    hisaichi5518 2009/06/10
    利用規約に使えそうなのがチラホラ
  • 1