タグ

システムに関するmonochromekkのブックマーク (68)

  • 最強のIT系かあちゃんからたかしへのアドバイス

    バーンれっどさーん @ledsun たかしへ あなたの勤怠確認しました.こんなに残業が多い割に大して売上が上がってないのはどうしてですか?顧客との信頼関係の構築も甘いとと思います.来月からは頑張って下さい.ちなみに母さんは今月、10人月で作ったシステムを3000万で売ってきました。 バーンれっどさーん @ledsun たかしへ あなたの立てたスケジュール読みました。作成工数だけでバッファがありません。予想外の事態が起きた時はどうするのですか?残業でカバーですか?お客様が参加するイベントが入っていません。都度調整ですか?事前に提示していないと都合がつかなくても納期延長できませんが大丈夫ですか? バーンれっどさーん @ledsun たかしへ あなたの作った機能仕様書読みました。技術的面ではチャレンジグで素晴らしかったです。でも、このシステムを使う人にどういうメリットがあるか分かりませんでした。

    最強のIT系かあちゃんからたかしへのアドバイス
  • 上流工程の失敗カタログ - 勘と経験と読経

    他のエントリを書いているところなのだけれど、面白い資料を見つけたので紹介。私は失敗談にこそ学びがあると思っているのだけれども、こんなところに上流工程の失敗カタログがあったのだった。 「要求開発・管理ベストプラクティスとその体系化の調査研究」(PDF) (2019/4/19 リンク切れを修正) 「要求開発・管理ベストプラクティスとその体系化の調査研究」を失敗カタログとして読む 「要求開発・管理ベストプラクティスとその体系化の調査研究」はタイトルの通りベストプラクティス集なのだけれども、それぞれのプラクティス毎に想定しているトラブル事例が興味深く、そして胸が熱くなる。 来あるはずのレアケース、例外に関する要求が出てこない 顧客から要求が出てこない。実はもっと隠された要求があるのに聞き出せていないのかがはっきりしない 顧客との期待とは異なるシステムを開発してしまうことに対して、事前に調整する手

    上流工程の失敗カタログ - 勘と経験と読経
  • 人月を超えるエンジニアリングの未来 - GoTheDistance

    ご無沙汰してしまっているmark-wadaさんより問題提起を頂いたので、最近話題になった「超高速開発」と絡めて書いていきます。 もしSIerエンジニアがジョブズのスピーチを聞いたら(1) - Wadit Blog. もしSIerエンジニアがジョブズのスピーチを聞いたら(2) - Wadit Blog. もしSIerエンジニアがジョブズのスピーチを聞いたら(3) - Wadit Blog. もしSIerエンジニアがジョブズのスピーチを聞いたら(4) - Wadit Blog. 僕のエントリに対する和田さんのご指摘をまとめると、ソフトウェアを作るにあたっては上流と下流の断絶があるのはマイナスなのは理解できるし、コードを書く時にはその断絶があると望むものを作ることは出来ないのも確か。だが、システムを作る時にはそもそもレイヤーをもう1つ上に上げるべき。スクラッチでコードを書く必然性など無い

    人月を超えるエンジニアリングの未来 - GoTheDistance
    monochromekk
    monochromekk 2012/04/17
    「業務がデザインされていればソフトを組み合わせて使えば可能なはずと考えている」 この仮定が成立するエンドユーザが少ないから、SI案件が有るとも言えるし、イノベーティブな案件が出てこないとも言える。
  • IT部門と経営の溝を埋めるために必要なたった1つのこと - GoTheDistance

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

    IT部門と経営の溝を埋めるために必要なたった1つのこと - GoTheDistance
  • クラウド時代にSIerはどう生き残るのか? 人月ビジネスからどう脱却するのか? 大手SIer役員にインタビューしました

    クラウド時代にSIerはどう生き残るのか? 人月ビジネスからどう脱却するのか? 大手SIer役員にインタビューしました リーマンショック以降の決算が軒並み大幅減収だった大手SIer。この状況は、景気が回復すれば持ち直すなどと楽観視できません。その背景には、クラウドや仮想化技術などによるシステム単価の下落や、ユーザー企業による内製化の進展による案件の減少といった構造の変化があるからです。 こうした構造変化の中で、SIerは今後の成長戦略をどう描こうとしているのでしょうか? また、その中でどんなエンジニアが今後必要とされるのでしょうか? ブログ「GoTheDistance」のブロガーで、「ござ先輩」として知られる湯堅隆氏から、こんな主題でインタビューしてみたい、という企画がPublickeyに持ち込まれました。湯氏は、自身もかつてSIerに勤務し、現在は中小企業の情報システム担当に転職した

    クラウド時代にSIerはどう生き残るのか? 人月ビジネスからどう脱却するのか? 大手SIer役員にインタビューしました
  • 第10回 [キャリアアップ編②]大規模サイトのサーバはどのように構成/運用されているのか? | gihyo.jp

    数値は平均化されてコンスタントに処理していることはなく、昼夜、平日休日、コンテンツのイベント的な仕掛けによって大きく左右されます。しかしながら、改めて見ても日有数のPV数を誇るといっても過言でもありません。 大まかな構成 次は実際にどのようなキャスティングでこのPVを処理しているのか見てみましょう。 ①通常、一般的なサービスを構築する際の構成として、アプリケーションサーバ(Webサーバ)とデータベースサーバの関係(階層)に関してほとんど変わりはありません。(⁠図4) 図4 この状態で順調にサービスが成長した場合、Webサーバ側で大量リクエストの処理に詰まってしまう可能性があります(図1の赤い線の部分)理由は先述したサービス成長に伴うリクエスト増加とDBサーバに対する処理応答待ち、すなわちデータ量の増加等が挙げられます。 この問題を解決する場合のインフラ側の対応として、静的コンテンツのキャ

    第10回 [キャリアアップ編②]大規模サイトのサーバはどのように構成/運用されているのか? | gihyo.jp
  • 「プロジェクトの失敗につながる九つの要因に注意」、NTTデータの岩本副社長

    「予算オーバーや納期遅れ、品質低下といった失敗プロジェクトIT企業の視点で調べると、九つの共通点が見つかった。九つのうち三つを満たす案件については、特に注意が必要だ」。NTTデータの岩敏男副社長パブリック&フィナンシャルカンパニー長は2010年1月15日、プロジェクトマネジメント(PM)の国際標準化について議論する「PM国際標準化フォーラム」に登壇し、こう述べた(写真)。 岩副社長が挙げた九つの要因とは、次のものである。一つ目は、対象プロジェクトが新規顧客からの受注であること。二つ目は、新システムの要件が「現行どおり」とされていること。三つ目は、新技術や経験のない処理方式を採用していること。四つ目は、IT企業と顧客との間で一括請負契約を結んでいること。 五つ目は、IT企業のプロジェクト原価率が95%以上であること。六つ目は、開発期間が6カ月以内といった短期プロジェクトであること。七つ

    「プロジェクトの失敗につながる九つの要因に注意」、NTTデータの岩本副社長
  • 特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態

    今週月曜日に公開した記事「特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩順三氏の述懐」は、記事に対して数多くのブックマークやツイートが行われ、大きな反響をいただきました。 その萩氏から「問題提起だけで終わるのではなく、こうあるべきだという提案もしたい」、という依頼をいただいたので、記事にいただいた反響への返答という意味も込めて、萩氏の提案についても掲載したいと思います。 以下からは萩氏の文章となります。 これまでのIT業界の慣習を捨て去り、あるべき姿へ 僕が日記(注:記事の元になったFacebookへの書き込み)を書いたのは、二度とこのような案件が出ないよう質的な問題提起をしようと思ったからです。 それが僕の責任だと思いました。 質的問題を提起したつもりですが、しかし当に理解していただいたのかというのが心配でもあり、また理解していただいたとしても、今後何

    特許庁の基幹システム失敗の背景にある、日本におけるITプロジェクトの実態
    monochromekk
    monochromekk 2012/02/03
    ユーザ企業の情シス部門が現場業務のあり方を考えられる位置付けになっていないのではないでしょうか。日本の場合、情シスでなくコーポレート企画のような部門で面倒を見ないといけないと思う。