タグ

システム開発に関するshibacowのブックマーク (4)

  • システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道

    「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか?という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価

    システムの「価値」をどう考えるのか?〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
  • プロジェクトを円滑に回すには 島国大和のド畜生

    色々バタバタしてる最中に、twitterで呟いたらわりと反響があった言葉。 個人的にプロジェクトを円滑に回す仕組みに重要なのは『直接手を動かさない人は最大1名』『ブレない為に権力は一極集中』『問題点を早期に洗い出す為に、チーム単位+偉い人で高頻度レビュー』辺りだと思っている。正直たったコレだけの事を実行するのが組織の中では難しい。 組織にもっとも不要な人というのは『批評家』なのだが、『批評家のポジションは居心地が良すぎる(作業がない、責任がない、口だけでいい)ので、隙あらば誰もがそこに向かう』そして、組織にとっての重しになる。これがプロジェクトで手を動かさない人が増える理由の一つ。 当に能力のある人でも、ある分野では見当違いな批評家になるというのは良くあることなので(意識無意識にかかわらず)だからこそ、発言に責任を伴うかどうかが重要。 とにかく、プロジェクトを船にたとえると。 1.船頭が

  • ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国

    えっらそうに大規模開発を語るような立場じゃないんだけど、何かと話題のこのへんの記事を読んでいろいろと日ごろ思うところがふつふつとわいてきたので……。 Life is beautiful: 特許庁のシステム開発が破綻した当の理由 Fumi's Travelblog: "費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた 特許庁システムのことはそれなりに話題で、日についてから何度も話にあがってきている。まあ不祥事だのなんだのって話もあるがそれはおいとくとしても、設計段階で60人体制ってだけでも多すぎるのに、増員で1300人体制とか……。設計を穴掘りかなにかと勘違いしてるとしか思えない対策でそりゃまあ破綻するよなあと。 それからね、中嶋さんの記事のコメント欄に書き込まれてた、よく言われる大規模開発でのこのへんの話。 SIerが開発を行う場合、この1

    ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国
  • デスマ? いいえ時間が浪費されただけです | おごちゃんの雑文

    説明が面倒臭いんで、今の忙しさを「デスマ」ってことにしてるんだけど、正確にはこれはデスマなんかじゃない。 私が考えるデスマとは、 工程が破綻した結果、 着地点がわからなくなったもの を言うのだ。「破綻」というのは当に破綻で、納期を踏み抜いたという程度のものは破綻とは言わない。それは単なる「遅延」であって破綻じゃない。 じゃあ、「破綻」したとはどんな状態かと言えば、「起きなくていい、起きてはいけない工程の逆流が起きた状態」だ。たとえば、遅延の結果、全く新しい火消しプロジェクトを起こす結果になったとか、「どうせ遅れてるんだから」と仕様が増えてまた設計が始まるとか、そんなものだ。 前者のわかりやすい例で言えば、稼動日に完全に切り換えられるという前提でプロジェクトが始まったのに、稼動日が守れなくなった。そのために、旧システムと新システムの平行稼動をする羽目になり、日時でデータ移行させたり、更新を

  • 1