タグ

SIerとsoftware developmentに関するimai78のブックマーク (6)

  • 間違いだらけの業務システム開発(プロジェクト編その1) (mark-wada blog)

    システム化プロジェクトは開発するもの 前回は、はなからITシステムを入れるということではなく、それぞれの会社の事情や成熟度に応じて、場合によってはITを使わないでシステム化をする方がいいケースもあるというようなことを書いた。ここでは、システム化プロジェクトで開発をしてしまうという間違いについての話です。 こう言うと、怪訝な顔をする人も多いと思います。だれしもが、普通に”システム開発“と言います。しかし、業務アプリケーションのことでいえば、業務の仕組みを開発するのですかとツッコミたくなる。ソフトウエアやツールであれば確かに開発ですが、業務の場合、開発するとはいったいどういうことなのだろうか。 そのまま字句通りに解釈すると、業務の仕組みあるいは業務プロセスをそうしたプロジェクトで開発すなわち新たに作り出すことを意味する。そんなことをシステム化プロジェクトでやるんですか。そもそも何とか管理システ

  • 第3回 なぜ日本のソフトウェアが世界で通用しないのか | gihyo.jp

    日米で異なるソフトウェアの作り方 私がシアトルに来たのは1989年なので、こちらに来てもう20年以上になる。最初の10年をMicrosoftのソフトウェアエンジニアとして過ごし、後半の10年は起業家としてソフトウェアベンチャーを3つほど立ち上げている。こうやって1年の大半を米国西海岸で過ごしながらも、日には毎年数回仕事で帰国しているし、日語でブログや記事を書いてもいて、ある意味で「日のソフトウェアビジネスを、一歩離れてちょうどよい距離で見る」ことができる立場にいる。 そんな私が常々感じているのは、日でのソフトウェアの作り方が米国のそれと大きく違っていること。そして、日のソフトウェアエンジニアの境遇が悪すぎること―そして、それが「日のソフトウェアが世界で通用しない」一番の原因になっていることである。 そもそもの成り立ちが違う日米のソフトウェア業界 日米のソフトウェアの「作り方」の

    第3回 なぜ日本のソフトウェアが世界で通用しないのか | gihyo.jp
  • 指標化しないと気が済まない!膨らみ続ける「形式知」

    「ソフトウエアの品質をどう測るのか」「リスク要因を見積もりにどう反映すればよいか」。多くの現場では経験を積んだベテラン技術者の頭の中にあるだけだろう。ジャステックでは,それを“指標”という形にまとめて業務の中で回している。ベテラン技術者の暗黙知を,指標の項目とその基準値という形式知に変換している。 考えられるあらゆる現場のノウハウを指標に落とし込む。「見積もりの精度を測る指標」「テストの精度を測る指標」――。 どのような指標を設定するかは現場のノウハウの固まりである。それは通常,ベテラン技術者の頭の中に暗黙知として存在しているものだ。ジャステックの開発現場では,その暗黙知を指標という形で形式知化している。指標をすべての現場で共有することで,現場から現場へ技術の伝承が図られているのである。 ここにジャステックの現場のすごみがある。現場の技術者たちの指標への執念が,営業利益率11%(2006年

    指標化しないと気が済まない!膨らみ続ける「形式知」
  • http://chikura.fprog.com/index.php?UID=1216994718

    imai78
    imai78 2008/07/27
    「全ての関係者が、全ての関係者と関係している」という超カオスな状態
  • システム開発はなぜ楽にならないか?

    あるプロジェクトマネージャから、次のような疑問を投げ掛けられました。 「Javaや開発ツールなどの技術は進歩しているのに、開発は少しも楽にならない。技術の進歩は、誰もが簡単にシステム開発ができるようにはしてくれないのか」 確かに、最近の技術の進歩は目覚しいものがあります(いつの世も技術進歩は目覚しいのかもしれませんが……)。しかしながら、確かに私たちシステム開発者が楽になったとは思えません。 急速な技術進歩で高度化、複雑化するシステム システム開発は、事務作業の効率化、省力化からスタートし、ビジネスの発展とともにシステム化される範囲が増え、システムは規模を拡大するとともに、機能の高度化、複雑化が進みました。 こうした傾向に最近拍車を掛けたのが、経済のグローバル化、インターネットの普及、それらを前提としたシステムへの要求かもしれません。 このようにシステムは高度化、複雑化の一歩をたどっている

    システム開発はなぜ楽にならないか?
  • 第5回 推進者の決断力がシステム構築の成否を決める

    システム構築は,推進者の力量が問われる作業である。特に多数の人々がかかわる場合は,さまざまな意見が噴出してまとまらないことが多い。そうした時に推進者は,しっかりした姿勢を維持し,特定の人たちの言いなりにならないように気を付けねばならない。どのような場合にも,推進者の決断が早ければ早いほどロスは少ない。決断が間違っていても早く気づけば間違いを正せる。システム構築の成否は推進者のパワーと決断力にかかっている。 記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが,この記事で焦点を当てたITマネジメントの質は今でも変わりません。 金属加工業のT社は営業システムの刷新を計画した。見積もりから受注,製造,販売,売掛金管理にいたるまでの流れに一貫性を持たせ,製造サイドが常に早めに情報をインプットして原材料や物流の手配までできるよ

    第5回 推進者の決断力がシステム構築の成否を決める
  • 1