システム化範囲がぶれていれば失敗する ― ＠IT自分戦略研究所
プロジェクトの失敗例で多いのは プロジェクトの失敗で、一番多いのはシステム化範囲（スコープ）がいつのまにか大きく膨らんでしまい、納期も遅れ、コストも膨らんでしまうケースである。 このようなプロジェクトは昔から後を絶たないのであるが、その対策が十分に取れているとは思えない。今回は、このシステム化範囲がぶれる問題を考えていきたい。 なぜ、システム化範囲はぶれるのか システム化範囲がぶれる理由はいろいろあるが、その代表的なものを挙げてみる。 （1）「ｘｘシステム一式」という契約書は意味があるのか そもそもシステム化範囲は明確になっているのであろうか。最近私が関与した会社で、ベンダから送られてきた契約書を見せてもらったが、そこに記載された委託内容は「生産管理システム一式」という文言が1行書かれているだけであった（図1。この契約書は、一体どういう意味を持っているのであろう。確かに金額や一般的な責任は
ユメのチカラ
インターネットの時代になって、地球規模の知恵の集積が 可能になった。ソフトウェア開発においてもオープンソースソフトウェアのバザール的開発が注目されている。いまおきているその現実を現場の視点から記していきたい。ひょんなことから経済産業省商務情報政策局長から感謝状を頂いた。わたしの年代だとお相撲の優勝者が航空会社の日本支社長(外国の方)から「ひょっうしょぅじょ〜ぅ」というのを懐しく思いだすのであるが、まあ、誰かから賞状を貰うのなんていうのは小学校以来と言っても過言ではない。 経済産業省として「ＩＴ産業の魅力の向上や将来のＩＴ産業の人材育成などについて、企業、教育機関の枠組みを超えて活躍している専門家の活動は、単に関係者間の自主的な取り組みにとどまらず、経済産業省の展開する政策にもご貢献されるものであると認識」し、ついては「この分野でご活躍いただいている専門家の皆様に商務情報政策局長より感謝状
SIer、IT業界構造：一連の記事をツリーっぽく並べました
ネット上や同業者の界隈で、古くから長きに渡って議論されている、日本のSIビジネスにおける問題点の1つ。 ここ数日、わりと濃厚な議論がネット上で交わされていた。 自分も類似の問題意識を持っているので、自分用メモとして、一連の記事を追っかけてみた。 というわけで早速。 親子丼的ビジネス奮闘記（４）IT業界構造（2007年09月19日 09:45 mark-wada blog） たぶんこれが元記事。日米比較対比的な視点からIT業界構造の問題点に言及している。解決策の1つとして BPM on SOA を提案。 see also:「ビジネスから考えてこそSOAの意味がある」、IBMと豆蔵の両エバンジェリストが強調（2007年9月14日 ITPro） [コメント] 恥ずかしながらSOAというものを、最近になってやっと「聞き流しではなく、しっかり見聞」するようになりました。 確かにマクロな流れとしては、
人月を超えるとプログラムしている暇が減る : 404 Blog Not Found
2007年09月26日16:15 カテゴリArtMoney 人月を超えるとプログラムしている暇が減る 人月が銀の弾(たま)ではないことが知られて久しいのに、「人月伝説」が衰えないのは、誰が悪いのだろうか? 矢野勉のはてな日記 - プログラマなら人月なんかさっさと超えろ 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 実は、プログラマー自身なのではないだろうか。 実は人月というのは、発注者側だけではなく、プログラマーにとっても楽なのだ。人月見積において、プログラマーが考えなければならないことは、「それを作るのにどれくらいの時間がかかるか」ということだけだ。「それを完了するのに何と何と何が必要で、それぞれこれくらいの手間がかかる
プログラマなら人月なんかさっさと超えろ - 矢野勉のはてな日記
Java, プログラミングノリノリで書いてみる。 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 そしてJavaの世界というのは、私のようにJavaが大好きだからやってる、という人間はすごく少数派で、「そろそろJavaでもやっとくか」「Strutsの使い方覚えたからもういいか」「できればJavaなんかいじりたくないなー。俺も早くプログラマに『これやっといて』って言えるようになりたい」という人のほうが多いのが実情なんですね。その点Rubyの世界は、今は「好きだからやってる」人が圧倒的でしょう。プログラム能力の高いJavaプログラマを探すのは、プログラム能力の高いRubyプログラマを探すよりずっと大変だろうと思う。 Javaの世
ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
[ThinkIT] 第1回：開発ドキュメント体系と業務フロー (1/4)
ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。 その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者もお互いに手痛い目に遭います。ここで言う"実力"とは、単なる技術力のことではありません。スケジュール管理や品質管理、コスト管理などのプロジェクト管理の技術・体制を社内で持っているかどうかが成否の鍵となるのです。 筆者の会社は創立11年目なのですが、創業以来「常駐・派遣の仕事はやらない！」という起業時のポリシーを貫いて来ました。C/SやWebのシステム開発を主体としているのですが、10年間の中では当然（？）、いくつかの失敗プロジェクトもありました。その苦い経験の中で「成功率と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://zerobase.jp/blog/entry-382.html
イノベーションが目的なの？ - 今年も僅かだはぶにっき
http://chikura.fprog.com/index.php?UID=1186110219