色んなことをソコソコできる人が、生きる道 - GoTheDistance
僕は器用貧乏です。色んなことがそこそこできるという、一般的なキャリア論では最もダメな部類に入ると思います。餅は餅屋。ドラッカー先生も言うてはる。あなたは何によって知られたいのか、それが重要だと。 エンジニアとしてキャリアをスタートさせて、恐ろしいことに10年以上の月日が経ちました。残念ながら、エンジニアとしては絶対に大成しないという確信があります。コードを書くのは好きです！でも、要素技術を突き詰めようという気持ちがすごく弱いのです。1つに絞り込むってことが、生理的に出来ない...全く違う分野に対して興味を持ったら、もう止められない。 そんな人って、実は技術職のエンジニアでも結構いるんじゃないかなっと感じたので、ブログ書きました。1つの分野の専門性が築けなくて悩んでいるのなら、「そーゆーの向いてないわ、俺」で諦めちゃったらいかがでしょう？ 僕のように。 僕より優れたエンジニア、僕より優れた営
事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance
言いたいことがストレートに伝わる良い文章だと思います。 simplearchitect.hatenablog.com ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。 では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。 確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？ 僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエア
「これって、ドメイン駆動設計？」という資料を公開しました。 - GoTheDistance
いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。 これって、ドメイン駆動設計？ from Michitaka Yumoto www.slideshare.net ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。 ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。 その世界で現状行われていること 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい) 上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが１つ。 で、ドメイン(特にいまやってる物事)を抽象化す
大企業で働くと毀損されるいくつかのコトについて - GoTheDistance
というわけで今日のお話は、「やった！頑張った甲斐があって、就活もうまく乗り切れた！」とか、「まあ、オレのスペックならちゃんと大企業＆大組織に入れるのも当然だけどね。」とか言ってる人は、実は「完全に周回遅れです」みたいな場所で人生最初の｢働く訓練」を受けることがどれだけ自分の将来価値を毀損する可能性があるか、よーく考えてみたほうがいいんじゃないか、ってことなのでした。 将来有望な若者の将来価値を毀損する、大きなワナ - Chikirinの日記 この記述に思うところがありますので、ちょっと書きたいと思います。 僕は6年間新卒で入社した大企業で働いておりました。今は従業員数人の中小企業で働いています。ちきりんさんが指摘する｢完全に周回遅れです｣の意味を身をもって経験しています。 周回遅れの意味は、その企業から一歩出たら全く役に立たないシゴトのやり方やアウトプットに飼い慣らされていることで、外に出
もしもIT業界の下請け構造が崩壊したら - GoTheDistance
みんな死にかけるかもしれないよ。 ひがさんのSI業界からはさっさと抜けだしたほうがいいを読みました。SIには未来が無いという最後通告のような文面のようにも取れます。江島さんのニッポンIT業界絶望論と併せて読むと、言わんとしていることの輪郭がより鮮明になるかと思います。ご一読を。 非効率極まりない下請け構造でシステムを作る時代が過ぎ去り、プロがはじめから高い品質を提供できるSaaSの時代が到来しているよ、と。ユーザーは必要最低限の投資で済む為、よりスリムで堅牢な企業体になる。IT屋も全部自分で出来るしお客さんが喜んでくれて嬉しいよねというWin-Winなシナリオ。 これが仮に未来像としましょう。そうすると、ちょっと考えれば分かる。ITのサプライサイドにとっては、本当に難しい時代に入るってことが。SaaSの時代というのは、僕ら業界にいる人間にとってみれば「多産多死の時代」ではないでしょうか？変
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
知らないと損するフレームワーク思考活用法 - GoTheDistance
ホッテントリメーカーからタイトルを頂戴した。id:phaさんありがと。 社会人なら押さえておきたいフレームワーク思考 : LINE Corporation ディレクターブログが非常に人気で今年のアルファブロガー(というかエントリ大賞に見える)大賞にもノミネートされている。こういう記事はニーズがありそうなので、僕なりにフレームワーク思考についていくつかサンプルを用意し、僕が使うチャートのサンプルを紹介しておきます。 というか1000以上のﾌﾞｸﾏとか・・・嫉妬！激しく嫉妬！！ハンカチ噛んじゃう！！！！ そもそも議論しちゃいけないこと 個人の価値観に依拠し、お互いの主張を出し合っても全体として合意が得られそうにないこと。例えば｢浮気の定義｣とか。こんなのは議論したって全体最適なんて導けるわけが無いので、ビジネスの場では全く持ってムダです。居酒屋でやりましょう。 仕事で議論することの意味 あなた
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
