[B! IT経営戦略] selpikoのブックマーク

真髄を語る　経営者がITを理解できない本当の理由

しかしながら、残念ながら、私を含めて、現実のCIOなり情報システム部門責任者の仕事の実態は先に書いた通りです。「開発過程にあるシステムが引き起こす様々な問題の対応」に大変な労力を費やしてしまう。はっきり言って、CIOをやっていた時、私の時間の7割から8割がこの問題に費やされました。場合によっては、CIOとしての任期期間一杯を、トラブル対応、つまり「稼働予定までに完成しない」、「当初予定の費用では収まらない」、「期待されたように動かない」といった問題の解決に振り回されてしまいます。自社で抱えている情報システム群を経営の次元から俯瞰して、自分達の情報システムがうまくいっているかいないかという、いわゆるITガバナンスの仕事になかなか時間を割けない。ITの戦略利用となると、さらに時間が取れないのです。 ITの責任はITベンダーが負う経営者のIT理解を妨げ、CIOを忙殺する、システム開発の不確実

selpiko 2008/03/06

IT経営戦略

リンク

TechTargetジャパン

VMware買収で揺れる市場を狙うSUSE【中編】 VMware波乱の余波　SUSEの「StackState買収」による不可避な影響 BroadcomによるVMwareの買収を契機と捉えて、SUSEはプラットフォームエンジニアリング市場での競争力強化に乗り出した。オブザーバビリティベンダーStackStateの統合はどのような影響をもたらすのか。

selpiko 2008/02/14

IT経営戦略

リンク

Amazon.co.jp: 若手SEのための要求仕様のまとめ方: 秋本芳伸, 岡田泰子: 本

selpiko 2007/10/24

IT経営戦略

リンク

システム設計　設計の考え方

要件定義、基本設計、詳細設計、プログラム設計、テスト、運用というシステム構築の手順が一般的に浸透しているが、このプロセスは実践ではほとんど守られておらず、要件定義の中で、ユーザと一緒に一部分を掘り下げて行っているうちに混合されることが多い。ここではその区別について考える。ただし、実践手順が多少、イレギュラーに設計されるのは全体の合理化を促進しようとするためであり、必ずしも良くないこととは言い切れない。基本的には必要とされるアクターを考えることが重要だと思われる。外部設計（システム設計）　＝システム方式設計+ソフトウェア設計内部設計　　　　　　　　　　　＝コンポーネント設計詳細設計　　　　　　　　　　＝プログラム設計　　　（IPA）１．システム方式の決定：アーキテクチャーとして、H/

selpiko 2007/10/24