最近SIerがだいぶヤバくなっている件 - GoTheDistance
via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃を食らう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムで食い込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
エンジニアの未来サミット0905に行ってきた - GoTheDistance
0905：エンジニア・サバイバル | エンジニアの未来サミット … 技術評論社へいって来たので、速報レポ書いておきますね。 本当は遅刻せずに行くつもりが、本人限定郵便なるものが午前中に来なかったことと弊社社長に捕まってしまい色々コミュニケーションとってたら遅れてしまい、第1部は1時間ばかり最初見れなかった＞＜ 第二部は、後ほどの実況ログをぜひご覧ください！津田さんメソッド、やっぱりすごい有益。この言葉使うの申し訳ないんですが、｢tsudaりに行く｣だけでも結構価値があるんだなーと思った。 こういうイベントって、特定のテーマに沿ったカッチリした結論なんて絶対出ないと思うんですね。パネルなんか特にそうですし。で、200人近くいたら当然各々の問題意識やおかれている状況は異なる。そんな中で、何か1つでも拾って帰って頂けるような言葉・気づきさえあれば、僕はそれでいいんだと思います。その意味で、今回の
泥の業界でも仕事は宝石なこともあるんだよ - GoTheDistance
id:wa-renさんの所でこれと同様の立ち位置のイベントが開かれていた。お疲れさまでした。 ネタ元 "第1回 泥カン"無事終了。まとめと一部スライド公開 泥カンについて一言 情報系学生のための交流企画「IT企業はほんとに泥のように働かされるのか」レポート ITギョーカイ俯瞰図 あの絵はポンチ絵だからあんまりマジで突っ込まれるとwa-renさんもちょっとツラいと思う。でも｢SI目線｣から見たらあの絵はいい絵だと思います。SIの｢S｣は業務システムの｢S｣なので仕事の単位が会社単位になる傾向が圧倒的に強く、id:amachangが疑問に思ってたBtoC市場の仕事はSIにはふってこないことが多いです。個人顧客用のWebサイト(通販とか)は大抵子会社に作らせているんじゃないかなってふと思いました。ツタヤにおけるツタヤオンラインとかね。 泥ってなんやねん それよりも何よりも、｢泥のように働く｣から
SIerという奇形児と、SIという珠玉の仕事 - GoTheDistance
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
JavaとRubyの間にある、ベルリンの壁 - GoTheDistance
ネタ元はこのあたり。 SIer と Rails とエンタープライズと エンタープライズにおけるRailsの価値とは 弊社の某エロい人がRoRに萌えており「おお、なんて生産性が高いんだ。もうWebアプリなんて全部これでいいじゃないか。」とか本気で思ってそうなので萎える。言語の違いは時にはビジネスモデルの違いにつながることが理解できないようだ。言語ってのは文化なの！これからはRubyを全面的に取り入れ開発標準もRubyだぁぁぁぁとか言い出したらどうしよう。グーで殴るしかないかｗ 本来、コード量の少なさや、CoCを前提とした設定の少なさが価値を発揮するのは、メンテナンスの場面です。読み込まないといけないコード量の少なさと、少ないコードの変更で修正ができることが、その理由です。そのためには、大前提として、Ruby（on Rails）らしい、プログラムを作っておくことが必須なので、マネージャはその辺
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
