タグ

SIとSEに関するMikatsukiのブックマーク (12)

  • SE転職のすすめ

    SEのキャリアを活かして転職 SI業界に見切りをつけたSEが続々と転職している業界はこちら! 異業種転職なら社内SEでチャンスをつかもう! 社内SEから異業種を目指す堅実な戦略とは? すぐに辞めたい、もう辞めてしまった方は派遣から! IT・WEB系の派遣は高時給で、すぐに働けるのがメリット SEとしてのキャリア・仕事に悩んでいる方必見! レバテックキャリアさんに「SE転職の疑問」をぶつけてきました! ITゼネコンとは? SEが疲弊してしまうのは、えてしてITゼネコンと呼ばれる「下請けありき」で成り立つピラミッド構造が原因と言われています。 一番上に位置する大手ITベンダーの仕事は主に「管理」ばかりとなり、そして下請けや孫請けとして働くSEの多くが「少し慣れたら誰でもできる単調なプログラミングとテスト」に明け暮れます。 今のSI業界の現場は、純粋にスキルを伸ばしたいと考えている人にとっては、

  • ベンダーが確実に支払いを受けるための3つのポイント(検収書裁判解説 後編)

    ベンダーが確実に支払いを受けるための3つのポイント(検収書裁判解説 後編):「訴えてやる!」の前に読む IT訴訟 徹底解説(5)(1/2 ページ) 連載目次 前回は、システム開発において、ユーザーから検収を受けたにもかかわらず、その後に発覚した不具合の多さとその対応のためにベンダーが支払いを受けられなかった紛争について述べた。「システムの完成は認めるが、支払いは認めない」とする裁判所の判断は、私にとっても印象深かった。 裁判所は検収書を軽視しないが盲信もしない 前回も書いたが、この判決は裁判所が検収書を軽んじていることを示すものではない。私が担当した紛争も含め、多くの裁判では、やはり検収書をシステムの完成を示す重要な証拠と考える場合が多い。むしろ、この事件のように検収書が「錦の御旗」とならない判断の方が少数派であろう。 ただ、申し上げたいのは、裁判所は「単に検収書の印鑑だけを見て、債務を履

    ベンダーが確実に支払いを受けるための3つのポイント(検収書裁判解説 後編)
  • ベンダーが確実に支払いを受けるための3つのポイント(検収書裁判解説 後編)

    関連記事 ベンダーよ、シェルパの屍を越えていけ ~ 細川義洋×山一郎「なぜ、システム開発は必ずモメるのか?」 リスペクトなきプロジェクトには死が待っている――山一郎さん(やまもといちろう a.k.a.切込隊長)と、東京地方裁判所 民事調停委員 細川義洋さんによるDevelopers Summit 2014の最終セッションは、雪の寒さとは違う意味で会場を震え上がらせた。 美人弁護士 有栖川塔子のIT事件簿 登場人物紹介 塔子、彩音、イチロに章介。登場人物のプロフィール。 関連リンク 美人弁護士 有栖川塔子のIT事件簿 バックナンバー一覧 要件定義が固まっていない、途中で追加や変更が頻発して大混乱――開発プロジェクトで起こりがちなトラブル事例の対応法を、IT訴訟専門の美人弁護士「塔子」がビシビシと伝授します。

    ベンダーが確実に支払いを受けるための3つのポイント(検収書裁判解説 後編)
  • 2014年のSIビジネスとかそのあたり - 急がば回れ、選ぶなら近道

    というわけで2014年に突入ですが・・・ 景気が回復しつつある現状で、SIの受注も好調なようです。ユーザー企業でも多少の予算の余裕も出てくるところもあり、システム投資には多少前向きになっているところも感じます。多少のでこぼこや、業界・業種によって色合いは異なるでしょうが、今後数年は景気の回復基調はコンセンサスになりつつあるようです。IT業界も例外ではないでしょう。もたもたしているビッグデータ案件を尻目に、システムリプレースや既存改修、新規でのシステム開発もスタートしつつあり、SI業界の件数ベースは今年は昨年を確実に上回るでしょう。 とはいえ一方で不採算案件も相当増えるように見えます。結果、SIビジネスはトレンド的には案件増・売上増ですが、利益減(または横ばい)というのが実態になるかと。要するに単金はそうそう簡単にはあがりませんが、案件は増えて、人繰りが追いつかず、結果限りなく失敗に近い「よ

    2014年のSIビジネスとかそのあたり - 急がば回れ、選ぶなら近道
  • Oracle 悲観的ロックはいいけれど

  • PC資産の調達から廃棄までワンストップでマネジメント!

    The Japanese edition of 'ZDNET' is published under license from A Red Ventures Company., Fort Mill, SC, USA. Editorial items appearing in 'ZDNET Japan' that were originally published in the US Edition of 'ZDNET', 'CNET', and 'CNET News.com' are the copyright properties of A Red Ventures Company. or its suppliers. Copyright (c) A Red Ventures Company. All Rights Reserved. 'ZDNET', 'CNET' and 'CNET

    PC資産の調達から廃棄までワンストップでマネジメント!
    Mikatsuki
    Mikatsuki 2014/08/24
    調達~管理~廃棄のプロセス
  • 無能なプログラマの特徴

    技術書を買っただけで満足するwブクマするだけで理解した気、分かった気になっているw勉強会(笑)には参加するが復習も実践もしないw一つの言語を使い込めてないのに複数言語に手を出すw流行りの技術に飛びつくけど直に飽きるw専門と断言できる技術領域がないwVisualStudioを貶す割には、パフォーマンス分析とかテストなどの便利機能は使えないwWPFが分からないだけなのに、自前で作る方が偉いと思っているwオーバーヘッドやフットプリントなどデメリットを考えず、すぐにtemplateとか純粋仮想関数を使って可読性を落とすwオブジェクト指向/デザインパタンを何か特別の技術だと思っているw無駄なところにラムダ式を使うwメモリ使用量や計算量の予測ができないw最大負荷を予測した上で始めから対策を取った実装が出来ないwHHKでないと仕事できないwとりあえずVim(笑)を使うw用途もないのにマックブックプロを買

    無能なプログラマの特徴
  • 第12回 バーンダウン・チャートで「終わるかどうか」を見える化する ITpro

    前回,タスクかんばんが,現在の状況を見える化するものであり,先を見通すような視点は持ち合せていないことを説明した。この「先を見通す視点」で「進ちょく状況の見える化」を実現するのがバーンダウン・チャートと呼ばれるチャートである。バーンダウン(burn down:燃え落ちる,全焼する)チャートは,一般的なチャートにありがちな右上がりではなく,右下りになっている。チャートを作成する際には,縦軸に残りの作業量を,横軸に時間を割り当てて日々の残り作業量をプロットしていく。右下,つまり残り作業量がゼロ(=全焼)になれば,すべての作業が完了するというわけだ。 バーンダウン・チャートは,元々リリースまでのバック・ログ(プロジェクトとして実施する必要があるすべての作業)の残量を視覚化するチャートだったが,現在はイテレーション単位でのタスクの残作業量(デイリー・バーンダウン・チャート)の見える化にも使われてい

    第12回 バーンダウン・チャートで「終わるかどうか」を見える化する ITpro
  • ページ移動のお知らせ : 富士通

    指定されたページは移動しました。新しいページは以下となります。 https://www.fujitsu.com/jp/products/computing/servers/advantages/special/ ブラウザのお気に入り(ブックマーク)に登録されている場合や、リンクをされている場合は、お手数をおかけいたしますが変更いただきますようお願い致します。

    ページ移動のお知らせ : 富士通
    Mikatsuki
    Mikatsuki 2014/08/16
    ITあるあるらしい
  • よいSEにはよい報酬を,“人月いくら”はもうやめよう

    少し前のIT Proニュースで,日IBM・大歳卓麻社長の「ユーザー企業には,技術者の出席をとらないでいただきたい」,という発言が紹介されている(当該記事)。「技術者の頭数ではなく,成果物について対価を払っていただける商慣習に変えていくよう,広く呼びかけたい」,という主旨だ。 私自身も取材のなかで,技術者の数や開発にかかった時間でシステムの価格を決めるのはおかしい,という声を,多くのSEの方々からお聞きする。ベンダーに籍をおくSEからだけではなく,ユーザー企業の方からもである。 システム開発にかかる工数,すなわち“人月”は,価格見積もりの根拠として,現在でも広く使われている。仮に一月100万円のSEが10カ月働いたから1000万円,という見積もりがあったとしよう。では,そのSEが努力して生産性を向上させ,5カ月でシステムを開発できるようになったら,価格は500万円になってしまうのだろうか。

    よいSEにはよい報酬を,“人月いくら”はもうやめよう
  • 『適正価格』

    令和からの働き方について -TownSoft- 元「傲慢SE日記」で、しばらく放置していました。 2020年からはこれからの働き方などについて書いて行こうかと思います。 この業界にある程度居る人ならば分かると思いますが、実はIT業界には適正価格というものが殆ど存在しません。(パッケージ商品とか、グローバルなものはある程度存在するかもしれませんが・・・。) これは、お客さんがソフトウェア開発を行なう際にも技術者を雇う場合にも当てはまります。 技術者の相場とソフトウェア開発の相場はあるのですが、その金額が何で決められているかと言うものが存在しないのです。 また相場=価値にならないのです。 これはなぜかというと、 技術力の定量化 が出来ていないからなのです。 すなわち、元となる資源の単価・価値が決められていないからなのです。 では、何故この定量化が出来ないのか? それが今回のお話です。 ソフトウ

    『適正価格』
  • 一志達也のSE、魂の叫び 第5回

    一志 達也(ichishi@pochi.tis.co.jp) TIS株式会社 2001/6/27 少しでも高く売ろうとする売り手と、少しでも安く買おうとする買い手。システムに限らず、売り手と買い手がいれば必ずその価値に対する駆け引きが起きる。われわれSEが日常的にかかわっているシステム構築の値段決定に関しても、例に漏れず複雑な駆け引きが繰り広げられている。 今回は、システム構築の価格決定について筆者なりの考えを述べたいと思う。稿の読者には、SE(SI)の立場から価格検討に携わる方と、逆に顧客として価格検討に携わる方がいると思うが、そのどちらにもぜひ一読いただきたい。 システム構築費用の内訳 一般に、「システム構築費用」にはハードウェアやソフトウェアの費用を含める場合と、それらを含めない場合がある。SI企業にとって、ハードウェアやソフトウェアはあくまでも仕入れて売るだけのものだから問題はな

  • 1