Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

ITに関するSo-Kingのブックマーク (11)

  • 情報システム部はどうであると得するのか? - 急がば回れ、選ぶなら近道

    いまさらの感もあるのですが、特にいろいろと日全国を飛び回るようになって、いろいろなお客さんにお世話になっています。ということで、その辺りで感じたことで、特にエンドユーザーの情報システム部はどうあると、「有利」なのか、ということを書いてみます。 対象は、お金を湯水のように使えないエンドユーザーさんです。とにかくリスクヘッジのためなら何百億円使おうと問題ではない、というユーザーさんはフルリスクを取れという要求以外であれば、SI屋さんの方から「無理なので、ご遠慮します」ということはありません。そのようなユーザーさんは、例外だとは思いますので、ちょっと対象外です。(なんか最近そうでもない説はありますが) 以下、あくまで自分の経験なので、不快な気分の方は、完全スルーでご容赦をお願いします。ベンダー風情が生意気な事を書きやがって、という方もいらっしゃると思いますので、そういう方には事前に、謝罪してお

    情報システム部はどうであると得するのか? - 急がば回れ、選ぶなら近道
  • 終わるSIerの底辺を見てきた - ミッションたぶんPossible

    ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この

    終わるSIerの底辺を見てきた - ミッションたぶんPossible
  • 生き残るために「要求エンジニアリング」を学ぶ

    生き残るために「要求エンジニアリング」を学ぶ:上を目指すエンジニアのための要求エンジニアリング入門(1)(1/3 ページ) 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 2009年、世界経済にとって厳しい年を迎えた。IT/ソフトウェア業界においても、ほかの業界と同じく厳しい時代になるだろう。この業界ではコストの大半を固定費である人件費が占めており、経済環境の変化に対応する力が弱い。だから、経済環境がいっそう厳しくなれば、プロジェクト価格の低下はもちろん、プロジェクト件数も減少し、ベンダ間の競争が激化する。企業は利益を出すために――いや、企業を存続させるために、多かれ少なかれ人件費の削減、時間単価の切り下げや時間当た

    生き残るために「要求エンジニアリング」を学ぶ
    So-King
    So-King 2012/02/09
    体系的に学んだ事なし。実務を念頭に置きながら、熟読&取込む
  • 好意的な印象を与える実用的なメール作成 13の技術 < インターネット・IT | RapidHack(ラピッドハック)

    好意的な印象を与える実用的なメール作成 13の技術 2012 年 2 月 5 日 12 時 40 分  インターネット・IT ■ 名前は必ず2つ以上使う ありきたりな文章でも、固有名詞を入れることで特別な印象を演出できます。 ■ 質問メールは二回まで 人は三回連続で質問をされると不愉快に感じるという心理的データがあります。 ■ 質問された場合の返事は文末に入れる お誘いなどの返信をする場合、前文から入れるのではなく文末に入れると余裕のある雰囲気になります。 ■ 自分の話しは後付け程度に押さえる 基は相手の話だけに集中しましょう。自分の話ばかりでは相手が付き合ってあげてるになりかねません。日記になってしまいます。 ■ 夜中や早朝に送るメールは絵文字が派手でないものを 起きがけや、照明の暗い環境の場で読むことが予想される場合、絵文字は時に目の毒になります。 ■ 忙しいあの

  • ついにRFCに登場!Webサーバとの双方向通信を実現する「WebSocket」 - builder

    次世代のWebアプリケーションの中核を担う技術として「HTML5」に注目が集まっているが、それと並んで期待されている技術に「WebSocket」がある。 IETFとW3Cによって仕様の策定が進められており、最初の提案以来幾度もの改訂を経て、2011年12月11日にそのプロトコル仕様がRFCのProposed Standard(RFC 6455)となった。 AjaxからComet、そしてWebSocketへ WebSocketはウェブサーバとブラウザが直接コネクションを張って双方向通信するための技術規格である。HTTPとは異なる独自の軽量プロトコルによって通信を行うため、オーバーヘッドが小さく、長時間に渡って通信する場合でもHTTPコネクションを占有する必要がないというメリットがある。 WebSocketが生まれた背景には、サーバとブラウザがもっとリアルタイムに通信して情報の配信や更新を行え

    ついにRFCに登場!Webサーバとの双方向通信を実現する「WebSocket」 - builder
  • 2011年版「あえて今、『システム内製』の勧め」

    50歳を過ぎたせいかどうか、元々しっかりしているとは言えなかった記憶力が怪しくなってきた。 つい先日も「はじめまして」と言いながら名刺を差し出すと、「以前お目にかかっていますよ」と笑われてしまった。仕事柄、一度会った人のことは忘れないように心掛けているのだが、これはまずい。 原稿を書いていても、途中で「同じことを前に書いたのではないか」「この逸話はすでに使ったはず」と気になってくる。しかも、いつ、どこに書いたのかをなかなか思い出せない。奥田英朗氏の小説集『空中ブランコ』に、同じことを書いてしまうのではないかと悩む女流作家が登場する。あれほどひどくはないが、似た心配をしてしまう。 題名でお分かりかと思うが、この原稿で書きたいのは、自社で利用する情報システムはできれば内製したほうがよい、ということだ。同じ主張を何度か書いた記憶がある。気になっているのは、次のような言い回しに関してである。 「ク

    2011年版「あえて今、『システム内製』の勧め」
  • IT部門と経営の溝を埋めるために必要なたった1つのこと - GoTheDistance

    もう何周目になるのでしょうか。「情報システム部門が経営に貢献できていない」というこの手の話は。 システム部門再生 - 経企部門が吐露する「システム部門への不満」:ITpro なんか色々ダメだしされていますが、重要なポイントは1つだけです。システム部門がビジネスに貢献するためには、自社の事業に対する理解が必要なだけではなく、その遂行手段である業務プロセスの理解が必要だ、という圧倒的な事実があることだけ。WhatとHowはクルマの両輪だと。で、この手の問題はシステム部門の問題ではなく経営の問題だという水掛け論が水びだしになるまで色んな人にされてFUDが残るのも味わい深いポイントであります。 自分達で管理できないものを改善できるわけが無い システム部門が業務プロセスの改善に貢献できない理由。突き詰めれば1つだけです。自分達で管理できずに、安易に外部に投げているからです。管理できないシステムをたく

    IT部門と経営の溝を埋めるために必要なたった1つのこと - GoTheDistance
  • ダメな"システム屋"で終わりますか?

    以下のページでログインをお願いします。 [SSL(Secure Sockets Layer)プロトコルで入力いただいた内容を保護いたします] ■登録されているユーザーIDとパスワードをお忘れの方は,「日経BPパスポート」の「ユーザーID・パスワードのお問い合わせ」ページでご確認いただけます。 ■ITpro-News,ITpro-Reportなどのメール配信サービスをご利用の方も, Web上のコンテンツをご覧いただくためには,改めて登録をお願いいたします。

  • ITエンジニアとして知っておきたい22の会計知識【簿記レベル編】:お茶でも飲みながら会計入門(54) - @IT

    意外と知られていない会計の知識。元ITエンジニアの吉田延史氏が、会計用語や事象をシンプルに解説します。お仕事の合間や、ティータイムなど、すき間時間を利用して会計を気軽に学んでいただければと思います。 「お茶会計」も早いもので50回を超えました。今回は、エンジニアが知っておきたい会計知識をカテゴリ別にまとめた記事リンク集です。 各回とも、前提となる会計知識を含めて解説しています。会計知識を身に付けるための足がかりとしてチェックしてみてください。 ◎ITエンジニアとして知っておきたい22の会計知識【簿記レベル編】 簿記3級&2級レベルの知識を身に付けるための解説 決算書を読むための解説 何かと身近な税金についての解説 ◎続・ITエンジニアとして知っておきたい21の会計知識【ニュース&社内業務編】 経済ニュースを理解するためのキーワード解説 意外と知らない社内業務を知るための解説 会計周囲の法律

    ITエンジニアとして知っておきたい22の会計知識【簿記レベル編】:お茶でも飲みながら会計入門(54) - @IT
  • まとめ:なぜ人月見積がダメか - Zerobase Journal

    社団法人日情報システム・ユーザー協会(JUAS)発行の『ソフトウェアメトリックス調査2007』を取り寄せて読んでみましたよ。SI関係の人は必読ですよね。私はいままで知らずに損していました。 そんなこともあり、年の瀬でもあり、今回の記事では表題の件「なぜ人月見積がダメか」について、現時点での総括をします。 人月見積方式の弊害に対する言論 「ユーザー企業は出席をとるな」,日IBMの大歳社長が提言:ITpro (2001/08/31) 「日の商慣習でぜひとも変えて欲しいのは,ユーザー企業が我々の技術者の出席をとることだ。出席をとられると我々は開発の生産性を挙げようとする努力をしなくなる。1000人でできる仕事を500人でやってのけると,売り上げが半分になってしまうからだ。技術者の頭数ではなく,成果物について対価を払っていただける商慣習に変えていくよう,広く呼びかけたい」。日IBMの大歳卓

    So-King
    So-King 2011/02/07
     いや、その付加価値つけれる企業(結局は人材)がいないから人月がまかり通るんだけど。
  • 「IT投資」という考え方そのものが間違っている - 分裂勘違い君劇場 by ふろむだ

    JTBの元取締役CIO(最高情報責任者)の方が、ITシステム開発が設備への投資であるかのような前提で書いていますが、この前提は間違っていると思います。 ソフトウェアシステムの開発とは、経営行為そのものそのものであり、逆に言えば、江戸時代どころか、ローマの時代から、経営行為とは、ソフトウェアシステムの開発以外のなにものでもありませんでした。 たとえば、新しいビジネスを実現するための、新しい店舗オペレーションや配送システムの開発は、ソフトウェアシステムの開発そのものです。 あたらしいビジネスを立ち上げるために、設計すべきものは、たとえば: ●迅速で高品質な状況対応を可能とする意思決定メカニズムの設計。 ●現場で柔軟な対応が出来、かつ、従業員の士気があがるような、責任・権限メカニズムと、それと連動した人事評価・報酬システムの設計。 ●現実的に調達可能な人材と、十分な投資効果の見込める従業員教育

    「IT投資」という考え方そのものが間違っている - 分裂勘違い君劇場 by ふろむだ
  • 1