色んなことをソコソコできる人が、生きる道 - GoTheDistance
僕は器用貧乏です。色んなことがそこそこできるという、一般的なキャリア論では最もダメな部類に入ると思います。餅は餅屋。ドラッカー先生も言うてはる。あなたは何によって知られたいのか、それが重要だと。 エンジニアとしてキャリアをスタートさせて、恐ろしいことに10年以上の月日が経ちました。残念ながら、エンジニアとしては絶対に大成しないという確信があります。コードを書くのは好きです！でも、要素技術を突き詰めようという気持ちがすごく弱いのです。1つに絞り込むってことが、生理的に出来ない...全く違う分野に対して興味を持ったら、もう止められない。 そんな人って、実は技術職のエンジニアでも結構いるんじゃないかなっと感じたので、ブログ書きました。1つの分野の専門性が築けなくて悩んでいるのなら、「そーゆーの向いてないわ、俺」で諦めちゃったらいかがでしょう？ 僕のように。 僕より優れたエンジニア、僕より優れた営
大きな会社と小さな会社のどっちで働くべきか迷っている人へ - GoTheDistance
いきなりポイントから入ります。大企業で働くことと中小企業で働くことの違いは、大企業はルールで動き中小は経営者の恣意で動くということです。ココがすごい重要です。 僕は６年近く大企業にいました。その時に考えたことは大企業で働くということ - GoTheDistanceで書きましたが、大企業の根本的な原理原則はルールで仕事が動くということです。異なる立場・異なるレイヤーの人たちを束ねて１つのサイクルを作るには、ルールを作ってその中でサイクルを回すより他ありません。それの累積によって企業文化なるものが形成されます。 大企業にいてよかったことは｢普通に仕事をさせてもらえる｣ことでした。もちろん仕事を選ぶことは基本的に出来ないんですが、明確に自分の役割が与えられ、そのロールに従いすべきことをして、あるべき成果を出してその仕事を終える。あっちいったりこっちいったりということはない。いきなり全く次元の違う
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
「相手にこう思われたらどうしよう」を、捨てよう。 - GoTheDistance
id:takerunbaのこういう所が大好き。愛してまう！ 発言を額面どおりに受け取る 私もすごくすごくすごおぉぉぉぉぉぉぉぉぉぉくそう思うんですよ。 「空気を読むのはやめましょう」 「行間を読むのはやめましょう」 「言外のことを読むのはやめましょう」 これを「3つの読まない」と申します。「非読宣言」です。私たち「社交辞令が効かない会」は読みません。そのままです。シンプルでストレートな関係の構築を目指しておりますので、言葉とか表情などの表に出てくる要素以外のものは、一切読みません。逆な言い方をすれば、表に出てこないものは無視します。ないモノとして扱います。シンプルでストレートな関係に、存在するかしないかすらわからないものを持ち込まれても困ります。 発言を額面どおりに受け取る なんというオレ！ 僕もこのタイプです。なんでかって？どんな事情があろうとも、本当に大切だと思っているものは絶対に表に
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
スーツにはスーツの道がある - GoTheDistance
勢いで書く。 スーツ側の人は業務内容が密接にプロジェクトや会社の中の話と結びつくことが多いので、はてな界隈ではなかなかスーツ側の人はスーツ側の濃ゆい話を書くことが出来ないことが多いようだ。圧倒的にスーツ側の人間がはてなを始めとしたブロゴスフィア全体で少ないなぁとつくづく思う。QAも少ないけど。この辺をアツく語るブロガー出てこないかなー。 私は200X年に今の会社に入社して、数年間WEBアプリケーションの開発をやった。多くはJavaの案件だった。最後の案件は去年の夏ごろだ。前任のPMが逃げるように辞めていってしまい、非常に複雑なロジックを自分が担当することになった。1500行越えktkr。それを参考にして(これが大間違いだったんだよセニョールorz)２週間かけて作ってみたはいいものの、テストを繰り返しているうちにどんどんボロがでて、結局その当時のPMとパートナーさんに相談して設計からやり直し
プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance
アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大＠クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく２つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ
2年半の結婚生活から学んだこと - GoTheDistance
GoTheDistanceではほとんど結婚・恋愛ネタは書かないんだけど、まぁたまには。失敗事例を共有することはいいことなので。 離婚して1年して思うこと この人と僕とは理由は違うけど、まぁ同じく離婚経験者として一言申し上げておく。 スキンシップがなくなると、必然的に会話も減り、相手の考えていることがわからなくなった。そうして3年くらいかけて、ゆっくりとゆっくりと他人に戻っていった。 離婚して1年して思うこと すごくわかる。特に家庭内や異性におけるコミュニケーションは言葉よりもスキンシップの方が大切です。スキンシップの減少⇒会話の減少⇒共有できる時間の減少⇒相互理解の減少⇒別れというコースをこの人も辿っただろうし、僕も辿った。肌と肌が触れ合うことではじめて伝わってくる情というものがあって、それは決して言葉では埋められないもの。スキンシップがめんどくさくなったら、もう惚れていないんだよ。僕はセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
