タグ

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

  • 炎上プロジェクトでスキルを会得する前にお前は死ぬ - GoTheDistance

    最短でイッセンマンITエンジニアを目指すなら大炎上プロジェクトがオススメ!!経験浅でも採用の可能性が上がるし、週最大7日間1日15時間以上、プロに揉まれながらスキルを磨けるので面倒な家での積み上げは不要!やり遂げた際の経験値はヤバいし、活躍によってはPMが次のPJに引っ張ってくれるよ!— 代表取締役 岩元仁@株式会社ロックシステム (@iwa3nen) 2021年8月28日 経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します) 炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。 僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクト炎上

    炎上プロジェクトでスキルを会得する前にお前は死ぬ - GoTheDistance
    at_yasu
    at_yasu 2021/08/30
  • 【書評】エンジニアがフリーランスで年収1000万円になるための稼ぎ方 - GoTheDistance

    技術評論社傅さんより恵投頂きました。おおきに。 エンジニアフリーランス年収1000万円になるための稼ぎ方 作者: 大和賢一郎出版社/メーカー: 技術評論社発売日: 2016/11/29メディア: Kindle版この商品を含むブログを見る フリーランスで一番大変なのは営業 書は社員の方がフリーランスを検討し始めたときに最初に読む、という位置づけです。細かい話は置いといて、フリーランスと正社員はこういう点が違うという抑えから入り、案件のとり方や自分の売り込み方、地雷案件の見抜き方などの実務に入り、最後にフリーランスで長くやっていくためのポイントを紹介しています。 書に書かれている内容でフリーランスで最もハードだと感じたのが、営業です。僕もまだまだですが、仕事を取ってくるというのは思いの外難しいものです。ほんとにもう。筆者の方は「自分で営業する」「クラウドソーシングを使う」「エージェン

    【書評】エンジニアがフリーランスで年収1000万円になるための稼ぎ方 - GoTheDistance
    at_yasu
    at_yasu 2016/11/22
  • Webマーケターに立て続けに煮え湯を飲まされた件 - GoTheDistance

    2016 - 03 - 09 Webマーケターに立て続けに煮え湯を飲まされた件 とあるWebサイト&ECのリニューアルの提案の機会を頂きました。まずはヒアリングで先方を訪問したら、 外資 系の会社でWeb改善に携わったというWebマーケターがいた。今年からWeb担当になったそうだ。先方のお偉いさんと苗字が同じで顔がよく似ていたので、きっとそういうことなんだろう。 ご高説を賜る所から話は始まった。ECの売上を伸ばすのにWebマーケティングを行います。最も重要なのは顧客の質を掴むことです。その質を見極めてシンプルに考え、Webマーケティングのプロに依頼して集客を行う戦略を当方で考えますので、あなたには制作面でご協力をお願いしたい、だって。きっつー。 「具体的にはどういう施策を打つんですか」と聞いたら、専門家と相談して決めますと言ってた。自分ではノープランと言うことか。帰ってくれないか。

    Webマーケターに立て続けに煮え湯を飲まされた件 - GoTheDistance
    at_yasu
    at_yasu 2016/03/10
    フミコフミオさんの記事かと思った…
  • 【書評】プログラムは技術だけでは動かない - GoTheDistance

    技術評論社、傳様より献御礼。 プログラムは技術だけでは動かない ?プログラミングでべていくために知っておくべきこと 作者: 小俣光之出版社/メーカー: 技術評論社発売日: 2014/06/05メディア: Kindle版この商品を含むブログを見る 書は「技術的な力はあっても、仕事として作った技術を活かした製品やシステムが、使いものにならないことがある。」という問題意識が根幹にあります。技術力を活かして飯をうために「プログラマとしての仕事力」という観点で自分のキャリアを考え直してみたらどうだろうか、という位置づけになっています。決して技術力を卑下しているわけではなく、技術を活かすのであれば仕事として評価されないとダメだという話です。 いくつか、僕が響いた内容をピックアップしていきます。 作るだけでは仕事にならない プログラマとしての仕事力というのは当然いくつかの能力があるわけですけれど

    【書評】プログラムは技術だけでは動かない - GoTheDistance
    at_yasu
    at_yasu 2014/06/09
    「「得意なプログラミング技術を用いて、どんな問題を解決するのが得意なのか」が、プログラマとしての得意分野。」せやな
  • 優れた仕様を決定するために必要なこと - GoTheDistance

    たまにはブログ更新したいから、ついさっき流れてきたエントリにいついちゃうよー。 ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change! 工程の分断はあり得ません ソフトウエアの設計に実装経験が要るか要らないかというのはそもそも議論にならない。「ソフトウエアの設計=仕様の設計+コードの設計」なんだから、例えればコインの表と裏。それらは引き離すことは出来ないのに引き離して分業しようとするからよろしくないことが起きてしまうというのが、上記記事の主題かと思います。簡単に言えば。 僕もこの点については「工程の分断」という言葉で何度も書いています。コインの表と裏であるべきものを分断してしまうと、互いのフィードバックを得る術を無くしてしまいます。そうなったら良いことは無い。ここは誰でも納得がいく所でしょう。 仕様を設計するチャンスって超少ないんじゃない?

    優れた仕様を決定するために必要なこと - GoTheDistance
  • ダメなシステムが無くならない理由はエンジニアを正しく活用できないから - GoTheDistance

    Twitterで流れてきたのでつい見てしまいましたが、この方の連載は全体的にやっつけ感が否めないですね。 なぜ“ダメなシステム”は無くならないのか? - なぜ“ダメなシステム”は無くならないのか?:ITpro この"ダメだしとっつあん"があの手この手で言わんとしてることは「上流工程と下流工程の分断は悪であり、ダメなシステムはそこから生まれている」ということですので、この記事を読んだ人は連載読まなくて大丈夫です。僕が書いたこのエントリ読んでください。もっと突っ込んで書いてあります。 「SIerでのキャリアパスを考える」というイベントに登壇しました - GoTheDistance もうそろそろぶっちゃけてもいいでしょ。ダメなシステムができる理由は簡単だってことに。ウオーターフォールが逆流できないせいだ/丸投げするからダメ/リスクをとらないからダメ/技術力のないやつが舵を取るからダメ・・・ってさ

    ダメなシステムが無くならない理由はエンジニアを正しく活用できないから - GoTheDistance
  • 富士通の3万人SE職務転換大作戦は成功するのか? - GoTheDistance

    全文は紙面でないと読めないのが残念ですが、非常に気になるニュースが飛び込んできました。 富士通、余剰SE変身作戦 富士通がグループで抱える約3万人のシステムエンジニア(SE)の大がかりな職務転換に乗り出した。一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むSEは仕事がなくなり、余剰人員問題が顕在化するからだ。野副州旦元社長の急進的な改革路線を修正した富士通はSE余剰問題で軟着陸を目指すが、クラウドの奔流にのみ込まれる危うさもはらむ。 富士通、余剰SE変身作戦 実は富士通グループさんには弊ブログを頻繁にご覧頂いておりまして、企業ドメインの中では最もアクセスの多いドメインであります。クロールしにきているのかなと思うぐらい。ブログで言及している「なんでもかんでも受託開発では、もうSIビジネスで成長することは出来ない」という危機

    富士通の3万人SE職務転換大作戦は成功するのか? - GoTheDistance
  • 大企業で働くということ - GoTheDistance

    梅田望夫氏の大企業で働くことについてのエントリの尻馬に乗ろうと思い続け、気がつけば尻馬が100マイルぐらい遠くなってしまったのですが、やっぱりこのネタについて書きたいことがあるので、エントリを書きます。すっげー長いエントリになってしまったので、気長に読んでください。連休の夜長にでも。 他の大企業はどうだかわからないけれど、少なくともウチの会社に限って言えば、以下のような事が言えます。 部長レベル以上はやっぱりデキる人が多い 何にも考えなくても給料がもらえる仕組みがある 人がいっぱいいる、それだけでも意味がある 基的に隣の部署が何をやってるかわからない 決定が棚上げされる うっとおしい社内業務が多い こんなところかなぁ。 ウチの会社は社員数4桁の会社です。そんな会社にあって部長クラスになれる人は、どこか一味違います。先を見据えて物を考えていたり、政治力がすごかったり、オレ様全開だけど明

    大企業で働くということ - GoTheDistance
  • 人月商売が悪だと思っている、イノセントなあなたへ - GoTheDistance

    色んな意味で示唆的なエントリ。山さん、どうしちゃったんですか。飲みにでも行きますか。 人月は悪どころか、ものすごい善かもしれない - 山大@クロノスの日記 140文字ぐらいでまとめちゃうと、人月ではなくソフトウエアの持つ価値だけでお金を取ろうとすると、例えばスマホアプリの場合は非常に単価が安いのでペイする算段が立たないこともある。それを鑑みると、エンジニアの稼働ベースで請求できる人月ってなんだかんだでイイとこあるよ、って話です。 人月について語られる記事はエンジニアよりの観点で議論されることが多いんですが、そうなると「人月はエンジニアにとって善か悪か」という方向に話が飛んでしまい、ゼネコンは死ねば良いし多重請負は終わってるし日IT競争力はなんだかんだっていう感じで一定の結論が出しにくい。なので、もっとビジネスよりの観点で整理してみたい。 人月のメリットは成果物ではなく作業内容に対し

    人月商売が悪だと思っている、イノセントなあなたへ - GoTheDistance
    at_yasu
    at_yasu 2011/12/12
    「自分の仕事の対価は給料じゃないんですよ。顧客が払ってくれるお金です。」
  • プログラマ35歳定年説、定年後の未来 - GoTheDistance

    株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは「1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう」ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、「ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える」という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理

    プログラマ35歳定年説、定年後の未来 - GoTheDistance
    at_yasu
    at_yasu 2011/09/29
    「人月ビジネスで利益を最大化するためには、「高い単価で顧客から仕事を請けて安い単価で外部に出す」ことが求められ、それが出世に繋がるからです」アタシの嫌いなDevelopmentな話か…
  • 僕の最初の起業が失敗した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
    at_yasu
    at_yasu 2011/04/28
  • SI業界で技術者が軽視されてしまうのは何故なのか - GoTheDistance

    のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか? - 達人プログラマーを目指してを拝読しました。この手の議論は定期的に出てくる根の深い問題でありまして、1億年と2000年前から多くの方に言及されています。しかし、それほど大きい問題であるということです。一概にああしろこうしろで片付く問題ではありません。 色々論点はありますが、「技術を売って社会貢献している業態なのに、一番重要な技術者を軽視するってどういうこと?」という1点に集約でき、上記エントリの主題も同じです。技術onlyの専門家の存在が認められないのが問題だと。しかしですね、「技術者そのものを売ってるんだから、軽視云々を言ってもどうしようも出来ない」という果てしない平行線を辿っていることが見えているでしょうか?ブルーハーツの「弱いものたちが夕暮れ 更に弱い者を叩く」というフレーズが思い起こされます。 技術

    SI業界で技術者が軽視されてしまうのは何故なのか - GoTheDistance
    at_yasu
    at_yasu 2011/04/06
    「成果責任を負わない派遣形態がかくも横行しているのは日本だけ」
  • 「ITエンジニア生き残りの条件」について思ったこと - GoTheDistance

    日経○○あたりに載りそうなキャリア関係の記事が技術系雑誌のSoftware Design誌にあったので、興味を惹かれて購入しました。 Software Design (ソフトウェア デザイン) 2010年 12月号 [雑誌] 出版社/メーカー: 技術評論社発売日: 2010/11/18メディア: 雑誌購入: 4人 クリック: 80回この商品を含むブログ (15件) を見る 特集記事の「ITエンジニア生き残りの条件」についてちょっと思う所あったので、僕も書いてみます。 ちなみに、僕は雑誌媒体で「SIゼネコン」とハッキリ書かれているのは初めて見ました。これが日経ビジネスに飛び火すればもっと反響がありそうで面白いのに。 特集記事の前半は現状整理。「リーマンショック以降下請けに流せる仕事が無くなった」 & 「クラウドの台頭で今までの価格帯が通用しなくなった」のダブルパンチを受けて、赤壁の合戦の連鎖

    「ITエンジニア生き残りの条件」について思ったこと - GoTheDistance
  • 営業ができる人とできない人の違い - GoTheDistance

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

    営業ができる人とできない人の違い - GoTheDistance
    at_yasu
    at_yasu 2010/11/09
    うん、よし、ちょっと首吊りたい・・・orz
  • 他人からの評価は受け止めちゃいけない - GoTheDistance

    「このままではどこか不安だ。自分の今の状態ってどうなんだろ」っていう意味で、ブログ等で発信を始めたい方はいっぱいいると思います。そんな方へ。 実際には、「自分の考え方を情報発信する」ということは、「批判を受け入れる覚悟を持つ」ということです。 そして「批判を受け入れる覚悟を持ち」「批判を受け入れる」ということは、成長に繋がります。 ビジネスパーソンが、積極的に社外に情報発信すべき理由。そして、最初の一歩としてやるべきこと:永井孝尚のMM21:ITmedia オルタナティブ・ブログ 上記のように「批判を受け入れる覚悟を持ちなさい」と説くケースが典型的だと思うんですが、まるで自分に降って来る全ての批判を受け入れなきゃダメなんだ、と解釈されがちではないでしょうか? 決してそんなことはないですし、これは大きな誤解です。過剰な反論空間は人を歪めるだけです。 批判を恐れずに発信していこうってよく言いま

    他人からの評価は受け止めちゃいけない - GoTheDistance
    at_yasu
    at_yasu 2010/06/21
    「自分が嫌いな人がいる様に、自分を嫌っている人もいる」と悟ってた厨房なあっしは一体・・・
  • アジャイルって受託開発との相性が最悪な気がする - GoTheDistance

    全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え - Publickey 「ウオーターフォールとは」のラベル貼りの議論になるとめんどくさいから、とりあえず「初期段階ですべての意志決定をしようとするシステム開発の進め方」という定義で話を進めたいと思います。 滝 「要件定義」→「設計」→「実装」→「テスト」という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ

    アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
  • 大きな会社と小さな会社のどっちで働くべきか迷っている人へ - GoTheDistance

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

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

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

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
  • おちまさと名言集 - GoTheDistance

    突然ですが、僕はおちまさとをリスペクトしています。 先日のエントリでもおちまさとの名著「企画の教科書」を紹介しましたが、はてブ界隈では全く彼の発言が取り上げられないので、僕がおちまさとの名言をまとめてみました。 追記(2008/01/29 9:00) ダラダラと長すぎたので、要点だけまとめてみました。 オリジナルはこちらのWeb上の連載コラムおちまさと「シゴトの強化書」|キャリア転職ラボ by イーキャリアにあります。是非ご覧ください。 それでは、どうぞ。 仕事に役立つおちまさとのアドバイス 仕事する時、確かに第一印象ってあると思うんですけど、実はそれでは全然遅くて、その前に“第ゼロ印象”というのが既に始まっている。 相手に カワイイと思われれば、その後のコミュニケーションもスムーズになる。といっても、ただカワイイだけじゃなく、自信が伴っていないとダメ。 何か企画を思いついたとき、「これは

    おちまさと名言集 - GoTheDistance
    at_yasu
    at_yasu 2009/01/30
    企画屋さんの考え方。友人にも自分にも通じるところ多々有り
  • 知らないと損するフレームワーク思考活用法 - GoTheDistance

    ホッテントリメーカーからタイトルを頂戴した。id:phaさんありがと。 社会人なら押さえておきたいフレームワーク思考 : LINE Corporation ディレクターブログが非常に人気で今年のアルファブロガー(というかエントリ大賞に見える)大賞にもノミネートされている。こういう記事はニーズがありそうなので、僕なりにフレームワーク思考についていくつかサンプルを用意し、僕が使うチャートのサンプルを紹介しておきます。 というか1000以上のブクマとか・・・嫉妬!激しく嫉妬!!ハンカチ噛んじゃう!!!! そもそも議論しちゃいけないこと 個人の価値観に依拠し、お互いの主張を出し合っても全体として合意が得られそうにないこと。例えば「浮気の定義」とか。こんなのは議論したって全体最適なんて導けるわけが無いので、ビジネスの場では全く持ってムダです。居酒屋でやりましょう。 仕事で議論することの意味 あなた

    知らないと損するフレームワーク思考活用法 - GoTheDistance